Hochverfügbarkeit

• Allgemeine Hinweise und verschiedene Strategien finden sich im Shibboleth Wiki nebst Hinweisen zur Konfiguration des Memcached Storage Service.
• Ausführliche Diskussion bei SWITCH
• Präsentation vom IdP 3.x Workshop 2016, FU Berlin
• Thorsten Michels, TU Kaiserslautern: Shibboleth IdP und keepalived (Präsentation von der 65. DFN Betriebstagung)

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

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.