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
Letzte ÜberarbeitungBeide Seiten der Revision
de:shibidp3extclustering [2020/11/19 10:13] – Silke Meyerde:shibidp:config-cluster [2021/04/26 15:20] – idp3 und idp4 tags entfernt Silke Meyer
Zeile 62: Zeile 62:
     # Jeder setzt ein Cookie mit dem Hostname.     # Jeder setzt ein Cookie mit dem Hostname.
     # Zu jedem wird der Traffic erneut verschlüsselt.     # 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 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 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     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
Zeile 80: Zeile 80:
   * Shibboleth-Logs auf zentralen Loghost schicken   * Shibboleth-Logs auf zentralen Loghost schicken
   * Health Checks zur Datenbank hin   * 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 86: 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 2 Jahren