In diesem Workshop lösen wir das Problem mit der bekannten HA-Software “Heartbeat”. Die beiden Load Balancer bilden einen Aktiv-Passiv-Verbund, es arbeitet also immer nur einer von beiden, der zweite springt im Fehlerfall ein. Die Webserver verbergen sich aus Sicht des Load Balancers hinter einer virtuellen IP-Adresse, die im Fehlerfall von Heartbeat auf den zweiten Load Balancer migriert wird (“floating IP”). Im Detail besteht unser Beispiel-Setup aus diesen Komponenten Webserver (web1.example.com mit der IP-Adresse 10.0.0.30 und web2.example.com, IP-Adresse 10.0.0.31) und Load Balancer (haproxy1.example.com, IP-Adresse 10.0.0.20, haproxy2.example.com, IP-Adresse 10.0.0.21).
Die wandernde IP-Adresse, die der jeweils aktive Load Balancer erhält, ist die 10.0.0.100. Doch bevor es an die Konfiguration des Failover-Systems geht, kümmern wir uns zunächst um die Konfiguration der Load Balancer.
Die Konfigurationsdatei für HA-Proxy ist . Die folgende Konfiguration ist so ausgelegt, dass Sessions auf dem Webserver nicht zerrissen werden. Über Cookies stellen wir sicher, dass ein Client immer dem gleichen Server zugeordnet wird. Kommt die Anfrage eines Clients ohne passenden Cookie am Balancer an, fügt HA-Proxy einen “SERVERID”-Cookie in die Antwort ein, der den Namen des Servers enthält, etwa “web1” (siehe Listing: Cookie in ). Bei der nächsten Verbindung vom gleichen Client – dieses Mal mit Cookie – weiß HA-Proxy, zu welchem Server er die Anfrage schicken soll.
Die Zeile “option httpchk HEAD /” im Kasten “Listing: Cookie in ” weist HA-Proxy an, die Gesundheit der Webserver zu prüfen, indem es regelmäßig einen HEAD-Request an die Server schickt. Antworten die Server mit einem Statuscode von “2xx” oder “3xx”, gilt der Server als gesund.
Damit HA-Poxy überhaupt startet, ist noch eine kleine Änderung in der
...Der komplette Artikel ist nur für Abonnenten des ADMIN Archiv-Abos verfügbar.