Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung		 Vorhergehende Überarbeitung
de:shibidp3extclustering [2020/11/19 09:40] – Silke Meyerde:shibidp:config-cluster [2022/05/02 14:52] (aktuell) – Wolfgang Pempe
Zeile 3: Zeile 3:
   * Allgemeine Hinweise und verschiedene Strategien finden sich im [[https://wiki.shibboleth.net/confluence/display/IDP4/Clustering|Shibboleth Wiki]] nebst Hinweisen zur Konfiguration des [[https://wiki.shibboleth.net/confluence/display/IDP4/StorageConfiguration#StorageConfiguration-MemcachedStorageService|Memcached Storage Service]].   * Allgemeine Hinweise und verschiedene Strategien finden sich im [[https://wiki.shibboleth.net/confluence/display/IDP4/Clustering|Shibboleth Wiki]] nebst Hinweisen zur Konfiguration des [[https://wiki.shibboleth.net/confluence/display/IDP4/StorageConfiguration#StorageConfiguration-MemcachedStorageService|Memcached Storage Service]].
   * Ausführliche Diskussion bei [[https://www.switch.ch/aai/guides/idp/clustering/|SWITCH]]   * Ausführliche Diskussion bei [[https://www.switch.ch/aai/guides/idp/clustering/|SWITCH]]
-  * [[https://www.aai.dfn.de/fileadmin/documents/idp3_2016/2016-06-17_Clustering.pdf|Präsentation vom IdP 3.x Workshop 2016, FU Berlin]] +  * [[https://download.aai.dfn.de/ws/2016_fub/2016-06-17_Clustering.pdf|Präsentation vom IdP 3.x Workshop 2016, FU Berlin]] 
-  * Thorsten Michels, TU Kaiserslautern: [[https://www.dfn.de/fileadmin/3Beratung/Betriebstagungen/bt65/BT65_AAI_IdP_Keepalive_Michels.pdf|Shibboleth IdP und keepalived]] (Präsentation von der 65. DFN Betriebstagung)+  * Thorsten Michels, TU Kaiserslautern: [[https://www2.dfn.de/fileadmin/3Beratung/Betriebstagungen/bt65/BT65_AAI_IdP_Keepalive_Michels.pdf|Shibboleth IdP und keepalived]] (Präsentation von der 65. DFN Betriebstagung)
  
 ===== Beispiel-Setup der DFN-Geschäftsstelle ===== ===== Beispiel-Setup der DFN-Geschäftsstelle =====
Zeile 18: Zeile 18:
     * der passive Loadbalancer den aktiven nicht mehr über VRRP erreicht oder     * der passive Loadbalancer den aktiven nicht mehr über VRRP erreicht oder
     * der HAProxy auf dem aktiven Loadbalancer nicht mehr läuft     * der HAProxy auf dem aktiven Loadbalancer nicht mehr läuft
-  * **HAProxy** bindet sich an die IP-Adresse(n) des IdP+  * **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     * 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     * 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+    * Backchannel/Port 8443 wird einfach über TCP / auf Layer 4 nach hinten durchgereicht  
 + 
 +<callout color="#ff9900" title="Links zu HAProxy"> 
 +Bei Fragen zu HAProxy konsultieren Sie bitte deren [[http://www.haproxy.org/#docs|Dokumentation]] oder deren [[https://discourse.haproxy.org/|User Forum]]! 
 +</callout> 
 + 
 + 
 +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 [[https://ssl-config.mozilla.org/|Mozilla SSL Configuration Generator]].<file bash> 
 +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 
 +</file>
  
 ==== IdP-Hosts ==== ==== IdP-Hosts ====
   * 2 identisch konfigurierte IdPs   * 2 identisch konfigurierte IdPs
   * Shibboleth-Logs auf zentralen Loghost schicken   * Shibboleth-Logs auf zentralen Loghost schicken
-  * Health Checks zur Datenbank +  * Health Checks zur Datenbank hin 
-  * Anbindung der Datenbank entweder über Service IP oder über lokal installierte HAProxys, die auf jeden IdP-Host einzeln den Zustand der Datenbank-Server prüfen (s.u. zu Percona Clustercheck)+  * 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 ==== ==== Datenbank ====
Zeile 33: Zeile 86:
  
   * MariaDB **Galera** Cluster (synchrone Multimaster-Replikation)   * MariaDB **Galera** Cluster (synchrone Multimaster-Replikation)
 +    * Es gibt verschiedene Distributionen von Galera, MariaDB ist nur eine davon ([[https://mariadb.com/kb/en/getting-started-with-mariadb-galera-cluster/|Doku]]).
     * ist nur ausfallsicher bei einer ungeraden Anzahl von Nodes, z.B. 3 (Quorum)     * 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.   * 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>idp3 idp4}}+{{tag>Hochverfügbarkeit HA Cluster}}
  • Zuletzt geändert: vor 3 Jahren