Workshop: Hochverfügbarer Load Balancer mit Heartbeat und HA-Proxy

Volle Balance

Zwei identisch konfigurierte Server hinter einem Load Balancer sind ein häufig anzutreffendes Setup. Der Balancer sorgt nicht nur für eine Verteilung der Last, sondern prüft auch zyklisch, ob seine beiden Schutzbefohlenen im Backend noch erreichbar sind. Fällt einer aus, muss der zweite Server solange die gesamte Last stemmen, aber besser als ein kompletter Ausfall ist das allemal. Damit ist ein Single Point of Failure eliminiert, aber dafür gibt es einen neuen, nämlich den Load Balancer. Wer es mit der Verfügbarkeit ernst meint, muss auch diesen doppelt vorhalten. Die entsprechende Konfiguration zeigt dieser Workshop.
Der Verlust wichtiger Daten ist für jedes Unternehmen eine Katastrophe. Daher dreht sich in der Juli-Ausgabe des IT-Administrator alles um das Thema ... (mehr)

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.

Konfiguration von HA-Proxy

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.

Ähnliche Artikel

comments powered by Disqus
Mehr zum Thema

Passthrough und Offloading: HTTPS Load Balancing mit HA-Proxy 1.5

HA-Proxy verteilt die Besucherströme vielgenutzter Webseiten auf verschiedene Server; die nächste Version optimiert auch verschlüsselte Verbindungen. Zu den Nutzern des Loadbalancer zählen unter anderem die extrem häufig frequentierten Seiten Twitter, Stack Overflow, Reddit und Tumblr.

Artikel der Woche

Systeme mit Vamigru verwalten

Auch wer nur kleine Flotten von Linux-Servern verwaltet, freut sich über Werkzeuge, die ihm diese Arbeit erleichtern. Vamigru tritt mit diesem Versprechen an. Wir verraten, was es leistet und wie Sie es in der eigenen Umgebung in Betrieb nehmen. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Container

Wie setzen Sie Container ein?

  • Gar nicht
  • Docker standalone
  • Docker mit Kubernetes
  • Docker mit Swarm
  • Docker mit anderem Management
  • LXC/LXD
  • Rocket
  • CRI-O auf Kubernetes
  • Container auf vSphere
  • Andere (siehe Kommentare auf der Ergebnisseite)

Google+

Ausgabe /2018

Microsite