Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- de:shibidp3extclustering [2020/11/19 08:17] – Silke Meyer
+++ de:shibidp:config-cluster [2021/04/26 15:20] – idp3 und idp4 tags entfernt Silke Meyer
@@ Zeile 8: / Zeile 8: @@
 ===== 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.
+{{:de:idp4:dfnaai-ha-setup.png?800|}}
+==== 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
-{{tag>idp3 idp4}}
+<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 ====
+  * 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 ([[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)
+  * 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>Hochverfügbarkeit HA Cluster}}

hochverfuegbarkeit ha cluster