Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende ÜberarbeitungLetzte ÜberarbeitungBeide Seiten der Revision | ||
de:shibidp3extclustering [2019/08/20 15:12] – Thorsten Michels | de:shibidp:config-cluster [2021/04/26 15:20] – idp3 und idp4 tags entfernt Silke Meyer | ||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
- | ====== | + | ====== |
- | * Generische Betrachtungen zum Thema finden sich im [[https:// | + | * Allgemeine Hinweise und verschiedene Strategien |
* Ausführliche Diskussion bei [[https:// | * Ausführliche Diskussion bei [[https:// | ||
* [[https:// | * [[https:// | ||
* Thorsten Michels, TU Kaiserslautern: | * Thorsten Michels, TU Kaiserslautern: | ||
+ | |||
+ | ===== Beispiel-Setup der DFN-Geschäftsstelle ===== | ||
+ | |||
+ | Es gibt viele Möglichkeiten, | ||
+ | |||
+ | {{: | ||
+ | |||
+ | ==== 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:// | ||
+ | * terminiert die SSL-Verbindung, | ||
+ | * führt Health Checks aus, z.B. auf Layer 7 gegen die Statusseite des IdP | ||
+ | * Backchannel/ | ||
+ | |||
+ | <callout color="# | ||
+ | Bei Fragen zu HAProxy konsultieren Sie bitte deren [[http:// | ||
+ | </ | ||
+ | |||
+ | |||
+ | Dies ist ein beispielhafter Auszug aus ''/ | ||
+ | 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, | ||
+ | bind <IPv4 Service-IP Ihres IdP>:443 ssl crt / | ||
+ | bind <IPv6 Service-IP Ihres IdP>:80 | ||
+ | bind <IPv6 Service-IP Ihres IdP>:443 ssl crt / | ||
+ | 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 < | ||
+ | bind < | ||
+ | default_backend idp_backchannel | ||
+ | |||
+ | backend idp_frontchannel | ||
+ | # Hier wählen Sie die Loadbalancing-Strategie: | ||
+ | balance | ||
+ | timeout check 10s | ||
+ | # Hier präzisieren Sie, dass der Health Check ein HTTP-Check gegen die Statusseite sein soll: | ||
+ | option httpchk | ||
+ | # 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 < | ||
+ | server idp2 < | ||
+ | |||
+ | backend idp_backchannel | ||
+ | balance | ||
+ | timeout check 10s | ||
+ | # Legen Sie auf den IdPs eine Prüfdatei unter http(s):// | ||
+ | option httpchk /httpchk | ||
+ | mode tcp | ||
+ | server idp1 < | ||
+ | server idp2 < | ||
+ | </ | ||
+ | |||
+ | ==== 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 (" | ||
+ | |||
+ | ==== 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 ([[https:// | ||
+ | * 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. | ||
+ | |||
+ | {{tag> |