Load Balancer Setup mit HAProxy: Traffic sicher verteilen

1. Wozu ein Load Balancer wie HAProxy nötig ist

HAProxy ist einer der am weitesten verbreiteten Software-Loadbalancer im Linux-Umfeld und löst zwei Probleme gleichzeitig: Skalierung und Ausfallsicherheit. Ein einzelner Applikationsserver hat eine feste Obergrenze an gleichzeitigen Verbindungen und CPU-Kapazität, unabhängig davon, wie gut die Anwendung optimiert ist. Sobald diese Grenze erreicht wird, hilft nur, den Traffic auf mehrere Server zu verteilen, statt einen einzelnen immer größer zu dimensionieren.

Gleichzeitig ist ein einzelner Applikationsserver auch ein Single Point of Failure. Fällt er aus, ist der Dienst komplett offline, selbst wenn die Anwendung selbst fehlerfrei läuft. HAProxy setzt genau hier an: Es verteilt eingehende Anfragen über konfigurierbare Algorithmen auf eine Gruppe von Backend-Servern und entfernt automatisch jeden Server aus der Rotation, der bei einem Health-Check nicht mehr antwortet. Für Clients ändert sich dabei nichts, sie sprechen weiterhin nur eine einzige Adresse an.

In typischen PHP- und Magento-Setups steht HAProxy vor mehreren identisch konfigurierten Applikationsservern, die alle auf denselben Session-Storage und dieselbe Datenbank zugreifen. Damit wird horizontale Skalierung möglich: Steigt die Last, wird ein weiterer Applikationsserver hinzugefügt und in die HAProxy-Konfiguration eingetragen, ohne dass Downtime oder eine Anwendungsänderung nötig wäre. Die folgenden Abschnitte zeigen den kompletten Weg von der Installation bis zum produktionsreifen Setup mit SSL und Monitoring.

2. Architektur: Frontend, Backend und ACLs

Die Konfigurationsdatei von HAProxy, standardmäßig unter /etc/haproxy/haproxy.cfg, ist in klar getrennte Blöcke unterteilt. Ein frontend-Block definiert, auf welchem Port und Protokoll HAProxy Anfragen entgegennimmt, während ein backend-Block die Liste der tatsächlichen Zielserver enthält, an die diese Anfragen weitergeleitet werden. Diese strikte Trennung erlaubt es, ein einzelnes Frontend an mehrere unterschiedliche Backends zu koppeln, abhängig von Regeln wie URL-Pfad oder Host-Header.

Access Control Lists, kurz ACLs, sind das Werkzeug, mit dem diese Routing-Entscheidungen getroffen werden. Eine ACL prüft eine Bedingung, etwa ob der Pfad mit /api/ beginnt, und leitet auf Basis des Ergebnisses in ein bestimmtes Backend um. Damit lässt sich mit einer einzigen HAProxy-Instanz sowohl statischer Content als auch dynamischer PHP-Traffic auf unterschiedliche Backend-Gruppen verteilen, ohne dass zwei separate Loadbalancer nötig wären.

Ein weiterer wichtiger Baustein ist der defaults-Block, in dem gemeinsame Timeout-Werte, Logging-Optionen und Modus (http oder tcp) für alle nachfolgenden Frontend- und Backend-Blöcke zentral gesetzt werden. Diese Struktur macht HAProxy-Konfigurationen auch bei vielen Backends übersichtlich, weil wiederkehrende Einstellungen nicht in jedem Block erneut definiert werden müssen.

3. Installation und eine erste haproxy.cfg

Die Installation von HAProxy erfolgt über den Paketmanager der Distribution, wobei aktuellere Versionen häufig über zusätzliche Repositories bezogen werden, um von neueren Features wie verbesserten HTTP/2-Fähigkeiten zu profitieren. Nach der Installation validiert haproxy -c -f /etc/haproxy/haproxy.cfg die Konfiguration auf Syntaxfehler, bevor der Dienst neu gestartet wird, was in produktiven Umgebungen vor jedem Deployment zur Pflicht werden sollte.

# Install HAProxy on Debian/Ubuntu
sudo apt update && sudo apt install -y haproxy

# Install HAProxy on RHEL/AlmaLinux
sudo dnf install -y haproxy

# Validate configuration syntax before reloading (always run this first)
sudo haproxy -c -f /etc/haproxy/haproxy.cfg

# Reload without dropping active connections
sudo systemctl reload haproxy

# Enable on boot
sudo systemctl enable haproxy

# /etc/haproxy/haproxy.cfg — minimal working configuration
global
    log /dev/log local0
    maxconn 4096
    user haproxy
    group haproxy

defaults
    mode http
    log global
    option httplog
    timeout connect 5s
    timeout client 30s
    timeout server 30s

frontend web_front
    bind *:80
    default_backend app_servers

backend app_servers
    balance roundrobin
    option httpchk GET /healthz
    server app1 10.0.0.11:80 check
    server app2 10.0.0.12:80 check
    server app3 10.0.0.13:80 check

Dieses minimale Setup nimmt HTTP-Anfragen auf Port 80 entgegen und verteilt sie per Round-Robin auf drei Backend-Server, wobei check bei jedem Server einen aktiven Health-Check aktiviert. Bereits mit dieser wenigen Zeilen Konfiguration lässt sich ein funktionierender Loadbalancer betreiben, den man anschließend um Balancing-Strategie, SSL und Monitoring erweitert.

4. Balancing-Algorithmen im Vergleich

HAProxy unterstützt mehrere Verteilungsalgorithmen, die je nach Anwendungsfall unterschiedlich gut geeignet sind. roundrobin verteilt Anfragen reihum gleichmäßig auf alle verfügbaren Server und eignet sich, wenn alle Backend-Server ungefähr gleich leistungsfähig sind und Anfragen ähnlich viel Last erzeugen. leastconn hingegen schickt jede neue Anfrage an den Server mit der aktuell geringsten Anzahl offener Verbindungen, was besonders bei langlebigen Verbindungen oder stark unterschiedlicher Anfragedauer fairer verteilt.

Der Algorithmus source leitet Anfragen anhand eines Hash-Werts der Client-IP-Adresse konsistent an denselben Server weiter, was eine einfache Form von Sitzungspersistenz ohne Cookies ermöglicht, aber problematisch wird, wenn viele Clients hinter einem gemeinsamen NAT-Gateway dieselbe IP teilen. Für gewichtete Verteilung, etwa wenn ein Backend-Server leistungsfähigere Hardware hat, lässt sich jedem Algorithmus zusätzlich ein weight-Parameter pro Server mitgeben, der die relative Anteilsmenge des Traffics steuert.

5. Health-Checks und automatisches Server-Entfernen

Die Option option httpchk aktiviert Layer-7-Health-Checks, bei denen HAProxy periodisch eine echte HTTP-Anfrage an jeden Backend-Server sendet und den Statuscode auswertet. Antwortet ein Server mit einem Fehlercode oder gar nicht, markiert HAProxy ihn nach einer konfigurierbaren Anzahl fehlgeschlagener Checks als down und nimmt ihn automatisch aus der Rotation, ohne dass ein Mensch eingreifen muss.

Wichtig ist, einen dedizierten Health-Check-Endpunkt zu bauen, der die tatsächliche Anwendungsgesundheit widerspiegelt, etwa eine Datenbankverbindung testet, statt nur eine statische Seite auszuliefern. Ein Endpunkt wie /healthz, der bei fehlgeschlagener Datenbankverbindung mit Statuscode 503 antwortet, sorgt dafür, dass HAProxy einen Server auch dann korrekt entfernt, wenn der Webserver selbst noch läuft, die Anwendung dahinter aber nicht mehr funktionsfähig ist.

backend app_servers
    balance leastconn
    option httpchk GET /healthz
    http-check expect status 200
    default-server inter 3s fall 3 rise 2

    server app1 10.0.0.11:80 check weight 100
    server app2 10.0.0.12:80 check weight 100
    server app3 10.0.0.13:80 check weight 50 backup

Der Parameter inter 3s definiert das Prüfintervall, fall 3 die Anzahl der nötigen fehlgeschlagenen Prüfungen bis zur Entfernung und rise 2 die Anzahl der nötigen erfolgreichen Prüfungen bis zur Wiederaufnahme. Der Server mit dem Flag backup erhält nur dann Traffic, wenn alle primären Server ausgefallen sind, was sich gut für einen kostengünstigeren Notfall-Server eignet, der im Normalbetrieb ungenutzt bleibt.

6. Sticky Sessions für zustandsbehaftete Anwendungen

Wenn eine Anwendung Sitzungsdaten lokal auf dem jeweiligen Applikationsserver speichert, statt sie in einem zentralen Session-Storage wie Redis abzulegen, muss jede Anfrage eines Clients konsequent an denselben Server geleitet werden. Diese Technik heißt Sticky Session und wird in HAProxy über cookie-basierte Persistenz umgesetzt, bei der HAProxy ein zusätzliches Cookie in die Antwort einfügt, das den zugewiesenen Server identifiziert.

Architektonisch ist eine zentrale Session-Ablage in Redis oder Memcached fast immer der bessere Ansatz, weil dann jeder Backend-Server zustandslos wird und HAProxy frei zwischen ihnen wechseln kann, ohne dass Nutzer ihre Session verlieren. Sticky Sessions über Cookies bleiben aber eine pragmatische Lösung für Legacy-Anwendungen, bei denen eine Umstellung auf zentrale Session-Speicherung kurzfristig nicht möglich ist.

backend app_servers
    balance roundrobin
    cookie SRVID insert indirect nocache
    option httpchk GET /healthz

    server app1 10.0.0.11:80 check cookie app1
    server app2 10.0.0.12:80 check cookie app2
    server app3 10.0.0.13:80 check cookie app3

7. SSL-Termination und Layer-7-Routing

Ein häufiger Anwendungsfall für HAProxy ist SSL-Termination: HAProxy nimmt die verschlüsselte HTTPS-Verbindung vom Client entgegen, entschlüsselt sie und leitet die Anfrage unverschlüsselt oder erneut verschlüsselt an die Backend-Server weiter. Das zentralisiert die Zertifikatsverwaltung an einer einzigen Stelle, statt jedes Backend einzeln mit Zertifikaten auszustatten, und vereinfacht sowohl Zertifikatserneuerung als auch TLS-Konfiguration erheblich.

Für Layer-7-Routing auf Basis des Host-Headers oder Pfads nutzt man ACL-Regeln im Frontend, um verschiedene Domains oder URL-Präfixe auf unterschiedliche Backend-Gruppen zu verteilen. Das ist besonders nützlich, wenn eine einzige öffentliche IP-Adresse mehrere Anwendungen bedienen soll, etwa einen Magento-Shop unter der Hauptdomain und eine separate API unter einem Unterpfad.

frontend web_front
    bind *:443 ssl crt /etc/haproxy/certs/mironsoft.pem
    mode http

    # Route based on URL path prefix
    acl is_api path_beg /api/
    use_backend api_servers if is_api
    default_backend app_servers

backend api_servers
    balance leastconn
    server api1 10.0.0.21:8080 check
    server api2 10.0.0.22:8080 check

backend app_servers
    balance roundrobin
    server app1 10.0.0.11:80 check
    server app2 10.0.0.12:80 check

8. Stats-Dashboard und Monitoring

HAProxy bringt ein eingebautes Stats-Dashboard mit, das über einen dedizierten Port aktiviert wird und in Echtzeit den Status jedes Backend-Servers, aktuelle Verbindungszahlen, Fehlerraten und Response-Zeiten anzeigt. Dieses Dashboard ist eine der schnellsten Möglichkeiten, um bei Problemen sofort zu sehen, welcher Server gerade als down markiert ist oder ungewöhnlich viele Fehler produziert.

Für automatisiertes Monitoring exponiert HAProxy zusätzlich einen CSV-Export der Statistiken über dieselbe Stats-URL, den Prometheus, Grafana oder eigene Skripte einlesen können. In produktiven Setups ist es üblich, den Stats-Port hinter einer Basic-Auth oder einer IP-Whitelist zu verstecken, da er sonst detaillierte Infrastrukturinformationen öffentlich preisgeben würde.

listen stats
    bind *:8404
    stats enable
    stats uri /stats
    stats auth admin:s3cr3tPassword
    stats refresh 10s

9. HAProxy im Vergleich zu nginx und Cloud-Loadbalancern

HAProxy ist auf reine Lastverteilung spezialisiert und bietet dafür tiefere Kontrolle über Balancing-Algorithmen, Health-Checks und Layer-7-Routing als generische Webserver, die ebenfalls als Loadbalancer eingesetzt werden können. nginx bietet in der Open-Source-Version ähnliche Grundfunktionen, aber weniger detaillierte Health-Check-Optionen, dafür oft die vertrautere Konfigurationssyntax für Teams, die bereits nginx als Webserver einsetzen. Cloud-native Loadbalancer wiederum nehmen die komplette Betriebsverantwortung ab, kosten dafür laufend und bieten weniger granulare Kontrolle über einzelne Balancing-Details.

Für Teams mit eigener Linux-Infrastruktur und dem Wunsch nach präziser Kontrolle über Balancing-Verhalten bleibt HAProxy häufig die bevorzugte Wahl. In Kombination mit keepalived für die Ausfallsicherheit der HAProxy-Instanz selbst entsteht ein vollständig redundantes Setup ohne Abhängigkeit von einem einzelnen Cloud-Anbieter.

10. Zusammenfassung

HAProxy löst zwei Probleme in einer Konfigurationsdatei: horizontale Skalierung über mehrere Backend-Server und Ausfallsicherheit durch automatisches Entfernen kranker Server aus der Rotation. Die klare Trennung zwischen Frontend, Backend und ACLs macht auch komplexes Layer-7-Routing über mehrere Anwendungen hinweg beherrschbar, während Balancing-Algorithmen wie roundrobin und leastconn für unterschiedliche Lastprofile passende Verteilungsstrategien bieten.

Health-Checks über echte Anwendungsendpunkte statt reiner Portprüfung stellen sicher, dass HAProxy nur wirklich funktionsfähige Server bedient. SSL-Termination zentralisiert Zertifikatsverwaltung an einer einzigen Stelle, und das eingebaute Stats-Dashboard liefert sofortige Sichtbarkeit in den Zustand jedes Backend-Servers. In Kombination mit keepalived für die Redundanz von HAProxy selbst entsteht eine vollständig ausfallsichere Verteilungsebene für produktive Linux-Infrastrukturen.

11. FAQ: Load Balancer Setup mit HAProxy