Load Balancing in der Praxis: nginx und HAProxy konfigurieren

Ein Load Balancer verteilt eingehende Anfragen auf mehrere Server. Er ist die Grundlage dafür, dass ein Dienst mehr Verkehr bewältigen kann als ein einzelner Rechner, und dass der Ausfall einer Instanz nicht zum Ausfall des Dienstes führt. Dieser Artikel erklärt die Verfahren und zeigt eine funktionierende Konfiguration.

Warum überhaupt verteilen?

Zwei Gründe, die oft verwechselt werden:

  • Leistung: Ein einzelner Server hat Grenzen bei Prozessorkernen, Speicher und Netzwerkdurchsatz. Mehrere Server vervielfachen die Kapazität.
  • Verfügbarkeit: Fällt eine Instanz aus, übernimmt eine andere. Der Dienst bleibt erreichbar, wenn die Verteilung den Ausfall erkennt.

Beides erreicht man nur, wenn die verteilten Instanzen zustandslos sind – also keine Sitzung im lokalen Speicher halten. Andernfalls braucht es Sticky Sessions oder eine gemeinsame Sitzungsablage (Redis, Datenbank).

Verteilungsverfahren

  • Round Robin: der Reihe nach. Einfach und bei gleichartigen Servern und gleichmäßiger Last gut geeignet.
  • Least Connections: an den Server mit den wenigsten offenen Verbindungen. Deutlich besser bei Anfragen sehr unterschiedlicher Dauer.
  • Weighted: Server mit unterschiedlicher Leistung bekommen Anteile entsprechend ihrer Kapazität. Auch beim schrittweisen Ausrollen neuer Versionen nützlich.
  • IP Hash / Consistent Hash: dieselbe Quelladresse landet immer beim selben Server. Damit entsteht Sitzungstreue ohne gemeinsame Ablage – aber die Verteilung wird schief, wenn viele Clients über eine Adresse kommen (Firmennetz, Mobilfunk).
  • Least Response Time: wählt den schnellsten Server. Berücksichtigt die tatsächliche Antwortzeit, ist aber rechenintensiver.

Schicht 4 gegen Schicht 7

  • Layer 4 (Transport): Der Verteiler arbeitet auf TCP/UDP-Ebene und leitet Pakete weiter, ohne den Inhalt zu kennen. Sehr schnell und protokollunabhängig, aber ohne inhaltliche Regeln.
  • Layer 7 (Anwendung): Der Verteiler liest die HTTP-Anfrage. Damit sind Regeln nach Pfad, Hostname, Kopfzeilen und Cookies möglich – auch das Beenden von TLS und das Umschreiben von Adressen. Dafür langsamer und speicherintensiver.

Konfiguration mit nginx (Layer 7)

upstream webapp {
    least_conn;
    server 10.0.0.11:8080 weight=3 max_fails=2 fail_timeout=10s;
    server 10.0.0.12:8080 weight=1 max_fails=2 fail_timeout=10s;
    server 10.0.0.13:8080 backup;        # nur wenn die anderen ausfallen
    keepalive 32;                         # Verbindungen wiederverwenden
}

server {
    listen 443 ssl;
    server_name app.example.org;

    ssl_certificate     /etc/letsencrypt/live/app.example.org/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/app.example.org/privkey.pem;

    location /api/ {
        proxy_pass http://webapp;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_set_header Host              $host;
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Die X-Forwarded-*-Kopfzeilen sind wichtig: Ohne sie sieht die Anwendung nur die Adresse des Verteilers, und jede Zugriffsprüfung sowie jedes Protokoll wird wertlos.

HAProxy (Layer 4 und 7)

frontend https_in
    bind *:443 ssl crt /etc/haproxy/certs/app.pem
    default_backend webapp_pool

backend webapp_pool
    balance leastconn
    option httpchk GET /health
    http-check expect status 200
    default-server inter 3s fall 3 rise 2
    server web01 10.0.0.11:8080 check
    server web02 10.0.0.12:8080 check
    server web03 10.0.0.13:8080 check backup

# Statistikoberflaeche (nur intern erreichbar!)
listen stats
    bind 127.0.0.1:8404
    stats enable
    stats uri /stats

HAProxy ist die erste Wahl, wenn viele Verbindungen bei geringer Latenz durchgeleitet werden sollen. Die Konfiguration ist knapper als bei nginx, und die Auswahl der Prüfverfahren ist feiner.

Zustandsprüfung (Health Check)

Eine Verteilung ist nur so gut wie ihre Erkennung ausgefallener Server. Drei Punkte sind entscheidend:

  1. Der Prüfendpunkt muss den Dienst prüfen, nicht nur den Prozess. Ein /health, das immer 200 liefert, ist nutzlos. Ein guter Endpunkt prüft auch Datenbankverbindung und Abhängigkeiten – solange die Prüfung nicht selbst zum Flaschenhals wird.
  2. Schwellwerte bewusst setzen. fall und rise verhindern, dass eine einzelne langsame Antwort einen Server aus der Rotation nimmt. Ein Server, der wegen einer Sekundenverzögerung herausfliegt und wieder hereinkommt, erzeugt Verkehrsspitzen auf den übrigen.
  3. Den Prüfendpunkt nicht veröffentlichen. Er gehört nur ins interne Netz.

Was ein Load Balancer nicht löst

  • Er ist selbst ein einzelner Punkt. Aus dem Grund betreibt man zwei Verteiler mit einer gemeinsamen virtuellen Adresse (VRRP, keepalived) oder nutzt mehrere DNS-Einträge.
  • Langsame Anwendung bleibt langsam. Verteilen erhöht den Durchsatz, nicht die Geschwindigkeit einer einzelnen Anfrage.
  • Zustand verschwindet nicht. Wer Hochverfügbarkeit will, muss Sitzungen und Daten aus den Instanzen herausnehmen – das ist oft der aufwendigste Teil.
  • Datenbanken skalieren anders. Ein Load Balancer vor einer Datenbank ohne Replikation bringt nichts.

Verwandte Grundlagen: Load Balancer, Reverse-Proxy, Hochverfügbarkeit, Kubernetes.