Hochverfügbarkeit

Es gibt viele Möglichkeiten, ein ausfallsicheres Setup aufzubauen. Dies als Beispiel dafür gedacht, wie man ohne Loadbalancer-Appliance, den IdP redundant aufsetzen kann.

  • 2 VMs (VRRP-Protokoll zwischen den Loadbalancern)
  • keepalived zur Steuerung, welcher LB gerade aktiv ist
    • Koppelung an laufenden HAProxy-Prozess → Schwenken der IP-Adressen wenn
    • der passive Loadbalancer den aktiven nicht mehr über VRRP erreicht oder
    • der HAProxy auf dem aktiven Loadbalancer nicht mehr läuft
  • HAProxy (Community Edition) bindet sich an die IP-Adresse(n) des IdP (https://www.haproxy.com/)
    • terminiert die SSL-Verbindung, setzt ein Cookie zur Wiederverbindung mit demselben Backend, verschlüsselt den Traffic zum gewählten IdP
    • führt Health Checks aus, z.B. auf Layer 7 gegen die Statusseite des IdP
    • Backchannel/Port 8443 wird einfach über TCP / auf Layer 4 nach hinten durchgereicht

Links zu HAProxy

Bei Fragen zu HAProxy konsultieren Sie bitte deren Dokumentation oder deren User Forum!

Dies ist ein beispielhafter Auszug aus /etc/haproxy/haproxy.cfg. Bitte denken Sie daran, dass der Loadbalancer im Abschnitt global eine sichere TLS-Konfiguration bekommt! Dabei hilft Ihnen z.B. der Mozilla SSL Configuration Generator.

frontend idp_frontchannel
    mode http
    option httplog
    bind <IPv4 Service-IP Ihres IdP>:80
    # Die key.pem-Datei muss ALLES enthalten: Private Key, Server-Zertifikat, Intermediate und Root-Zertifikat!
    bind <IPv4 Service-IP Ihres IdP>:443 ssl crt /etc/ssl/private/key.pem alpn h2,http/1.1
    bind <IPv6 Service-IP Ihres IdP>:80
    bind <IPv6 Service-IP Ihres IdP>:443 ssl crt /etc/ssl/private/key.pem alpn h2,http/1.1
    http-request deny if HTTP_1.0
    option forwardfor
    redirect scheme https if !{ ssl_fc }
    default_backend idp_frontchannel
 
# Bei Backchannel-Kommunikation wird teilweise ein Client-Zertifikat verwendet.
# Reichen Sie daher den Traffic einfach auf Layer 4 durch.
frontend idp_backchannel
    mode tcp
    option tcplog
    bind <IPv4-Adresse Ihres IdP>:8443
    bind <IPv6-Adresse Ihres IdP>:8443
    default_backend idp_backchannel
 
backend idp_frontchannel
    # Hier wählen Sie die Loadbalancing-Strategie:
    balance           roundrobin
    timeout check     10s
    # Hier präzisieren Sie, dass der Health Check ein HTTP-Check gegen die Statusseite sein soll:
    option httpchk  GET /idp/status HTTP/1.1\r\nHost:\ idp.beispiel-uni.de
    # Hier definieren Sie, wie das Cookie gesetzt wird:
    cookie BEISPIELUNI-IDP insert secure
    # Hier definieren Sie die realen Hosts, auf denen die IdPs laufen.
    # Jeder setzt ein Cookie mit dem Hostname.
    # Zu jedem wird der Traffic erneut verschlüsselt.
    # Die Health Checks erfolgen ohne DNS, direkt auf der Host-IP über TLS mit Server Name Indication. (Die ist wichtig, wenn auf den Real Servern mehr als eine Shibboleth-Instanz läuft und die separat geprüft werden sollen, z.B. Dev-Instanz und Produktiv-Instanz.)
    server idp1 <IPv4-Adresse 1. IdP-Host>:443 ssl sni str(idp.beispiel-uni.de) ca-file <das CA-File, mit dem verschlüsselt werden soll> cookie idp1 check check-ssl addr <IPv4-Adresse 1. IdP-Host> port 443 check-sni idp.beispiel-uni.de downinter 10s on-marked-down shutdown-sessions
    server idp2 <IPv4-Adresse 2. IdP-Host>:443 ssl sni str(idp.beispiel-uni.de) ca-file <das CA-File, mit dem verschlüsselt werden soll> cookie idp2 check check-ssl addr <IPv4-Adresse 2. IdP-Host> port 443 check-sni idp.beispiel-uni.de downinter 10s on-marked-down shutdown-sessions
 
backend idp_backchannel
    balance           roundrobin
    timeout check     10s
    # Legen Sie auf den IdPs eine Prüfdatei unter http(s)://idp.beispiel-uni.de/httpchk ab und schützen Sie sie ggf. gegen Zugriffe von außen.
    option httpchk /httpchk
    mode tcp
    server idp1 <IPv4-Adresse 1. IdP-Host>:8443 check addr <IPv4-Adresse 1. IdP-Host> port 80 downinter 10s on-marked-down shutdown-sessions
    server idp2 <IPv4-Adresse 2. IdP-Host>:8443 check addr <IPv4-Adresse 2. IdP-Host> port 80 downinter 10s on-marked-down shutdown-sessions
  • 2 identisch konfigurierte IdPs
  • Shibboleth-Logs auf zentralen Loghost schicken
  • Health Checks zur Datenbank hin
  • Anbindung der Datenbank entweder über eine Service IP / einen entsprechenden DNS-Namen („galera.beispiel-uni.de“) oder über lokal installierte HAProxys, die auf jeden IdP-Host einzeln den Zustand der Datenbank-Server prüfen (s.u. zu Percona Clustercheck)

In einem ersten Schritt könnten Sie einen Standalone Datenbank-Server hinter die beiden IdPs stellen. Um die Datenbank auch ausfallsicher zu machen, ist eine Möglichkeit ein Galera Cluster.

  • MariaDB Galera Cluster (synchrone Multimaster-Replikation)
    • Es gibt verschiedene Distributionen von Galera, MariaDB ist nur eine davon (Doku).
    • ist nur ausfallsicher bei einer ungeraden Anzahl von Nodes, z.B. 3 (Quorum)
  • Mit xinetd und Percona Clustercheck kann auf Port 9200 ein Dienst für Health Checks zur Verfügung gestellt werden. So kann man erkennen, dass nicht nur eine TCP-Verbindung zu Port 3006 aufgebaut werden kann, sondern dass der jeweilige Clusterknoten innerhalb des Galera Clusters in einem integeren Zustand ist.
  • Zuletzt geändert: vor 6 Tagen