Zeige QuelltextÄltere VersionenLinks hierherNach oben Letzte ÄnderungenPer E-Mail sendenDruckenPermalink × Inhaltsverzeichnis Hochverfügbarkeit Beispiel-Setup der DFN-Geschäftsstelle Loadbalancer IdP-Hosts Datenbank 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) Beispiel-Setup der DFN-Geschäftsstelle 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. Loadbalancer 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 HAProxyBei 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 IdP-Hosts 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) Datenbank 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. Hochverfügbarkeit, HA, Cluster hochverfuegbarkeit ha cluster Zuletzt geändert: vor 17 Monaten Anmelden