Was ist HAproxy und wie verteilt es Last?
Autor: Redaktion Domeny.ForSale Veröffentlicht
Kurz erklärt: HAProxy ist eine Software, die Netzwerkverkehr entgegennimmt und an ausgewählte Server weiterleitet, auf denen die Anwendung läuft. Sie arbeitet als Reverse Proxy und Load Balancer: Sie vermittelt Verbindungen und verteilt den Datenverkehr auf mehrere Instanzen eines Dienstes. Das hilft, größere Lasten zu bewältigen und ausgefallene Server zu umgehen. Der Einsatz von HAProxy allein garantiert jedoch keine ununterbrochene Verfügbarkeit.
Wie HAProxy zwischen Nutzer und Anwendung arbeitet
Ein Reverse Proxy nimmt Verbindungen stellvertretend für die Anwendungsserver entgegen. Der Nutzer verbindet sich mit der Adresse des Dienstes, hinter der HAProxy steht, statt direkt mit einem bestimmten Backend-Server. HAProxy wählt das Ziel und leitet den Datenverkehr dorthin weiter. Die Antwort kommt über dieselbe vermittelnde Schicht zurück.
Lastverteilung, auch Load Balancing genannt, verteilt den Datenverkehr auf die verfügbaren Server. Das muss keine exakt gleichmäßige Verteilung sein: Ein leistungsfähigerer Rechner kann mehr Aufgaben erhalten, während ein Server bei Wartungsarbeiten von der Bearbeitung neuer Anfragen ausgenommen werden kann.
In der Konfiguration von HAProxy gibt es zwei wichtige Begriffe. Das Frontend legt fest, wo das Programm Verbindungen entgegennimmt, beispielsweise auf Port 443 für HTTPS. Das Backend beschreibt eine Gruppe von Zielservern und die Regeln für deren Auswahl. Ein Frontend kann den Datenverkehr je nach Domain oder URL-Pfad an unterschiedliche Backends weiterleiten.
Unterstützung für TCP, HTTP und Verschlüsselung
HAProxy kann auf unterschiedlichen Kommunikationsebenen arbeiten. Im TCP-Modus leitet es Verbindungen weiter, ohne Entscheidungen anhand des Inhalts von HTTP-Anfragen zu treffen. Das ist auch für andere Dienste als Websites nützlich, sofern sie TCP verwenden.
Im HTTP-Modus versteht HAProxy Bestandteile einer Anfrage wie Hostname, Pfad und Header. Es kann daher Anfragen für /api an API-Server weiterleiten und die übrigen Anfragen an die Anwendung, die die Website bereitstellt. Solche Regeln werden häufig als ACL formuliert: Bedingungen, anhand derer der Datenverkehr bestimmten Regeln zugeordnet wird.
Bei HTTPS ist entscheidend, wo TLS endet – also das Protokoll, das die Verbindung absichert:
- TLS-Terminierung in HAProxy: Das Programm verwaltet das Zertifikat und entschlüsselt den Datenverkehr, sodass es HTTP analysieren kann. Die Verbindung zum Backend kann erneut verschlüsselt werden.
- Weiterleitung der verschlüsselten Verbindung: Der Zielserver übernimmt TLS. HAProxy sieht dann weder Pfade noch HTTP-Header und kann sie deshalb nicht für das Routing verwenden.
Die TLS-Terminierung in HAProxy bedeutet nicht automatisch, dass auch die Verbindung zur Anwendung verschlüsselt ist. Dieser Abschnitt muss separat konfiguriert werden, einschließlich der Prüfung des Zertifikats des Zielservers.
Wie die Lastverteilung bei Ausfällen hilft
Stell dir einen Onlineshop vor, der auf drei Anwendungsservern läuft. HAProxy nimmt die Kundenanfragen entgegen und verteilt sie nach dem Verfahren round robin, also reihum auf die verfügbaren Server. Eine Alternative ist beispielsweise least connections: Dieses Verfahren bevorzugt den Server mit weniger aktiven Verbindungen. Welches Verfahren passt, hängt von der Art des Datenverkehrs ab.
HAProxy kann Health Checks durchführen, also regelmäßige Verfügbarkeitstests der Backend-Server. Besteht einer der Server diese Tests nicht mehr, kann das Programm ihm keinen neuen Datenverkehr mehr zuweisen und die übrigen Rechner die Anfragen bearbeiten lassen. Aktive Verbindungen zum ausgefallenen Server können allerdings abbrechen.
Ein Test, der lediglich prüft, ob ein Port offen ist, bestätigt noch nicht, dass der Shop eine Bestellung bearbeiten kann. Aussagekräftiger ist häufig ein HTTP-Test eines speziellen Prüfendpunkts der Anwendung, der ihre Betriebsbereitschaft meldet. Der Umfang des Tests muss sorgfältig gewählt werden: Ein zu oberflächlicher Test übersieht Ausfälle, ein zu strenger kann funktionierende Instanzen unnötig aus der Verteilung nehmen.
Die Lastverteilung setzt auch eine geeignete Architektur der Anwendung voraus. Ist der Warenkorb eines Kunden ausschließlich im Arbeitsspeicher eines Servers gespeichert, kann eine nachfolgende Anfrage an einen anderen Rechner möglicherweise nicht darauf zugreifen. Ein gemeinsamer Sitzungsspeicher hilft hier. Die feste Zuordnung eines Kunden zu einem Server, sogenannte Sticky Sessions, schützt die Sitzungsdaten dagegen nicht vor einem Ausfall dieses Rechners.
Wie sich HAProxy von einem Webserver unterscheidet
Die Hauptaufgabe von HAProxy besteht darin, Kommunikation zu vermitteln und Datenverkehr zu steuern – nicht darin, wie ein Webserver Website-Dateien auszuliefern oder Anwendungscode auszuführen. In der Praxis ist es den Webservern oder Anwendungsprozessen vorgeschaltet, die die Antworten erzeugen. Es ersetzt auch weder eine Datenbank noch deren Replikationsmechanismus.
NGINX und Apache HTTP Server können ebenfalls als Reverse Proxy arbeiten und zugleich die Rolle eines Webservers übernehmen. Bei der Auswahl geht es daher nicht einfach darum, welches Werkzeug grundsätzlich besser ist. HAProxy kommt sinnvollerweise infrage, wenn eine separate Schicht für die Lastverteilung von TCP- oder HTTP-Verkehr, die Zustandsprüfung der Backend-Server und Regeln zur Weiterleitung von Verbindungen benötigt wird.
Für eine einzelne kleine Website kann der vorhandene Webserver oder der Load Balancer des Cloud-Anbieters ausreichen. HAProxy hinzuzufügen bedeutet, eine weitere Komponente zu betreiben, die aktualisiert und überwacht werden muss und deren Konfiguration gepflegt werden muss.
Was vor dem Einsatz zu prüfen ist
Eine einzelne HAProxy-Instanz kann zum zentralen Ausfallpunkt werden: Ist sie nicht verfügbar, können Nutzer auch funktionierende Anwendungsserver nicht mehr erreichen. In einem System, das hohe Verfügbarkeit erfordert, sind deshalb auch redundante Proxy-Instanzen und ein Mechanismus zur Umschaltung des Datenverkehrs zwischen ihnen nötig.
Prüfe vor dem Produktivbetrieb vier Punkte:
- Backend-Tests: Erkennen sie, wenn die Anwendung nicht betriebsbereit ist, oder prüfen sie nur, ob ein Port erreichbar ist?
- Limits und Timeouts: Wie viele Verbindungen nimmt das System an, und wie lange wartet es auf eine Antwort?
- Client-Adresse: Wie erhält die Anwendung die tatsächliche IP-Adresse des Clients, und welchen Proxy-Headern darf sie vertrauen?
- Beobachtbarkeit: Lassen sich anhand von Logs und Metriken Fehler, Verzögerungen und Überlastung erkennen?
Prüfe in der offiziellen Dokumentation der verwendeten HAProxy-Version, welche Funktionen verfügbar sind und welche Konfigurationssyntax gilt. Führe den ersten Test mit zwei Anwendungsinstanzen durch: Schalte eine davon bei kontrolliertem Datenverkehr ab und prüfe sowohl die Reaktion des Proxys als auch das Verhalten der Nutzersitzungen.
Siehe auch: Was ist 2FA?
Lesen Sie auch
