Schritt-für-Schritt: Hochverfügbaren NGINX-Load-Balancer mit Keepalived und HAProxy einrichten

Ein hochverfügbarer NGINX-Load-Balancer beseitigt den Single Point of Failure am Netzwerkrand, indem zwei Linux-Knoten eine virtuelle IP (VIP) per VRRP bereitstellen und lokal NGINX und HAProxy für TLS, Routing und Health Checks betreiben. In diesem praxisorientierten How‑to beschreibe ich nicht nur Konfigurationen, sondern auch die Betriebsfolgen, typische Fehlerursachen, Mess- und Prüfbefehle sowie eine praktische Rückfallstrategie.

hochverfügbarer NGINX-Load-Balancer: Architektur und Verantwortungsaufteilung

Kurz: Keepalived (VRRP) stellt eine VIP bereit, die Clients ansprechen. Der aktive Knoten hat die VIP lokal gebunden und beantwortet ARP. NGINX übernimmt TLS‑Terminierung, Header‑Policy und Redirects; HAProxy läuft lokal und übernimmt präzise Health Checks und Backend‑Routing. Diese Trennung erlaubt klare Verantwortungsbereiche: TLS- und Sicherheits-Policy in NGINX, Zustands- und Performance‑Kontrolle in HAProxy.

Voraussetzungen, Netzwerk und Design-Entscheidungen

Wesentliche Annahmen: beide Load‑Balancer in derselben Layer‑2‑Domain (VLAN), VIP innerhalb desselben Subnets, VRRP‑Traffic (IP‑Protokoll 112) darf zwischen den Hosts fließen. Wenn Anwendungen Session‑State lokal speichern, planen Sie Sticky Sessions oder ein zentrales Session‑Store (z. B. Redis) ein — andernfalls führen Failovers zu verlorener Session‑Information.

Beispiel-Parameter

• LB1: 10.10.10.11/24, LB2: 10.10.10.12/24, VIP: 10.10.10.10/24
• Interface: eth0, Backends: 10.10.20.21:8080, 10.10.20.22:8080
• DNS: Ein A‑Record auf die VIP; TTL ist sekundensache, VIP-Failover ist transparent für Clients

Installation: Pakete, Dienste, Reihenfolge

Installieren Sie NGINX, HAProxy und Keepalived auf beiden Knoten. Aktivieren und starten Sie die Dienste nach Konfigurations‑Checks.

sudo apt-get update
sudo apt-get install -y nginx haproxy keepalived curl iproute2 iputils-arping

sudo systemctl enable --now nginx
sudo systemctl enable --now haproxy
sudo systemctl enable --now keepalived

Kernel‑ und ARP‑Tuning: Warum das wichtig ist

Wenn Linux falsch auf ARP‑Anfragen reagiert, entsteht Traffic‑Blackholing oder Split Brain. Die folgenden sysctl‑Einstellungen reduzieren unerwünschtes ARP‑Antwortverhalten; setzen Sie diese auf beiden Knoten.

sudo tee /etc/sysctl.d/99-lb-ha.conf >/dev/null <<'EOF'
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.default.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2
net.ipv4.conf.default.arp_announce = 2
EOF

sudo sysctl --system

Erklärung: arp_ignore steuert, ob das System ARP‑Anfragen für lokal nicht konfigurierte IPs beantwortet; arp_announce beeinflusst, welche Quell‑IP in ARP‑Requests verwendet wird. Falsche Einstellungen erlauben dem Backup, ARP für die VIP zu beantworten und erzeugen Split Brain.

HAProxy: lokale Backend‑Schicht, Health Checks und Metriken

HAProxy liefert robuste Health Checks (HTTP, TCP, SSL), Weight‑ und Rise/Fall‑Einstellungen. Verwenden Sie einen lokalen Bind (127.0.0.1), damit NGINX intern weiterleiten kann. Statistiken lassen sich für Monitoring nutzen oder per Prometheus‑Exporter exportieren.

# /etc/haproxy/haproxy.cfg
global
  log /dev/log local0
  tune.maxaccept 1000
  maxconn 50000
  daemon

defaults
  mode http
  option httplog
  timeout connect 5s
  timeout client 60s
  timeout server 60s

frontend fe_local
  bind 127.0.0.1:9000
  default_backend be_app

backend be_app
  balance roundrobin
  option httpchk GET /healthz
  http-check expect status 200
  default-server inter 2s fall 3 rise 2
  server app1 10.10.20.21:8080 check
  server app2 10.10.20.22:8080 check

listen stats
  bind 127.0.0.1:8404
  stats enable
  stats uri /stats

Prüfen Sie HAProxy vor dem Neustart:

sudo haproxy -c -f /etc/haproxy/haproxy.cfg
sudo systemctl reload haproxy

NGINX: TLS, Proxy-Pfade und Timeouts

NGINX übernimmt TLS‑Termination. Automatisieren Sie Zertifikate (z. B. certbot/ACME) oder nutzen Sie Ihre interne PKI. Achten Sie auf proxy_read_timeout und buffer‑Settings, damit lange Backend‑Antworten nicht die Verbindung blockieren.

# /etc/nginx/sites-available/lb.conf
server {
  listen 80;
  server_name _;
  return 301 https://$host$request_uri;
}

server {
  listen 443 ssl http2;
  server_name _;
  ssl_certificate     /etc/ssl/certs/lb.pem;
  ssl_certificate_key /etc/ssl/private/lb.key;
  client_max_body_size 50m;
  proxy_read_timeout 120s;
  location / {
    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;
    proxy_pass http://127.0.0.1:9000;
  }
}

Keepalived: VRRP‑Konfiguration, Track‑Skript und Timer

Keepalived bestimmt, welcher Knoten die VIP hält. Track‑Skripte reduzieren die Priorität bei Dienstfehlern, sodass ein gesunder Backup‑Knoten übernehmen kann. Die Advert‑Interval‑ und Priority‑Werte steuern Umschaltzeit und Vorzugsreihenfolge.

Track‑Skript mit Exit‑Codes

sudo tee /usr/local/sbin/chk_proxy.sh >/dev/null <<'EOF'
#!/usr/bin/env bash
set -euo pipefail

# Prüft Dienste und lokales HAProxy Health-Endpoint
systemctl is-active --quiet nginx || exit 1
systemctl is-active --quiet haproxy || exit 1
curl -fsS --max-time 1 http://127.0.0.1:9000/healthz >/dev/null || exit 1
exit 0
EOF
sudo chmod 0755 /usr/local/sbin/chk_proxy.sh

Keepalived-Konfiguration (Master/Backup)

# /etc/keepalived/keepalived.conf (Beispiel MASTER)
vrrp_script chk_proxy {
  script "/usr/local/sbin/chk_proxy.sh"
  interval 2
  timeout 2
  fall 2
  rise 2
  weight -30
}

vrrp_instance VI_10 {
  state MASTER
  interface eth0
  virtual_router_id 10
  priority 110
  advert_int 1
  authentication { auth_type PASS; auth_pass 7f3c9d2a }
  virtual_ipaddress { 10.10.10.10/24 }
  track_script { chk_proxy }
}

# Backup hat priority 100 und state BACKUP

Hinweis: Authentifizierung in Keepalived (auth_pass) ist ein einfacher Mechanismus; in unsicheren Netzen sollten Sie zusätzliche Netzwerk‑Segmentierung nutzen, da VRRP selbst keine starke Kryptographie bietet.

Fehlerquellen: ARP, Switch‑Funktionen, Firewalls

Häufige Ursachen für unerwartetes Verhalten:

• Switch‑Funktionen wie Dynamic ARP Inspection (DAI) blockieren Gratuitous ARP nach einem Failover — in solchen Netzwerken ist eine Switch‑Konfiguration notwendig.
• Host‑Firewall oder Cloud Security Groups blockieren IP‑Protokoll 112 (VRRP) — prüfen Sie dies mit tcpdump.
• Conntrack (Stateful NAT/Firewall): Bei NAT‑Übersetzung kann ein Failover vorhandene Verbindungen unterbrechen, weil die NAT‑Tabelle am neuen Knoten fehlt.

Diagnose mit tcpdump, arping und Logs

Nützliche Prüfungen zur Analyse:

# VRRP traffic beobachten (Protocol 112)
sudo tcpdump -n -i eth0 proto 112

# ARP prüfen
sudo tcpdump -n -i eth0 arp

# GARP senden (nach Failover)
sudo arping -U -I eth0 -c 5 10.10.10.10

# Keepalived logs
sudo journalctl -u keepalived -f

Wenn tcpdump keine VRRP‑Pakete zeigt, ist oft eine Firewall oder ein Switch dazwischen die Ursache. Wenn GARP vom Master nicht durchkommt, erscheinen Clients mit alter MAC‑Zuordnung in arp‑Tabellen und müssen neu lernen.

Conntrack- und NAT-Effekte bei Failover

In Setups mit NAT oder Statefull Firewalls ist die Conntrack‑Tabelle hostspezifisch. Nach einem VIP‑Failover fehlen etablierte Conntrack‑Einträge auf dem neuen Knoten, was zu abgebrochenen Sessions führt. Mögliche Maßnahmen:

• Keepalived mit Conntrack‑Sync betreiben (z. B. conntrackd) — erhöht Komplexität.
• Verbindungserneuerung tolerieren: kurze Reconnects akzeptieren, Clients reconnecten lassen.
• Aktiv/Aktiv-Architektur erwägen, wenn Session‑Kontinuität entscheidend ist.

Sicherheitsaspekte und Zertifikatsmanagement

TLS‑Zertifikate müssen auf beiden LBs identisch sein. Automatisieren Sie Deployments mit Certbot (ACME) oder Ihrer internen PKI und validieren Sie private Keys mit Dateiberechtigungen. Hinterlegen Sie Zertifikate versioniert in einem sicheren Artefakt‑Repo oder Secret‑Store.

# Beispiel Certbot (Let's Encrypt) - nicht für private PKI
sudo apt-get install -y certbot
sudo certbot certonly --standalone -d lb.example.com
# Verteilen Sie das resultierende PEM sicher auf beide Nodes (scp/Ansible)

Rollout- und Patch-Prozess — konkretes Runbook

Ein typischer, getesteter Ablauf zum Patchen oder Konfig‑Update minimiert Risiko:

1. Plan: Maintenance‑Fenster kommunizieren, Monitoring‑Alerts temporär drosseln.
2. Traffic auf Backup bringen: entweder Keepalived auf Master stoppen oder dessen Priority senken.
3. Validierung: Auf Backup prüfen, ob VIP übernommen wurde und Latenz/Errors normal sind.
4. Master patchen, testen (NGINX/HAProxy lokal prüfen), in den Pool zurückschalten.
5. Zweiten Knoten patchen.
6. Post‑Checks: Failover‑Test, Health‑Checks, Log‑Analyse.

# Beispiel: Traffic auf Backup bringen
# Auf Master:
sudo systemctl stop keepalived
# Auf Backup prüfen:
ip -br addr show dev eth0
sudo curl -I --resolve lb.example.com:443:10.10.10.10 https://lb.example.com/
# Nach Patch:
sudo systemctl start keepalived

Monitoring, Kennzahlen und Alerts

Wichtige Metriken, die Sie überwachen sollten:

• Keepalived VRRP‑Transitions (häufige Switchover deuten auf Instabilität hin)
• VIP‑Bindungszeitpunkt und GARP‑Events
• NGINX 4xx/5xx‑Raten
• HAProxy Backend‑Status, Response‑Time und Queueing
• System‑Metriken: File‑Descriptors, netstat für offene Sockets, loadavg

Exportieren Sie HAProxy‑Stats via Exporter für Prometheus oder nutzen Sie das interne stats‑Endpoint für Alerting‑Regeln.

Erweiterte Design‑Alternativen

Wenn Sie höhere Skalierung oder globale Verfügbarkeit benötigen, prüfen Sie andere Muster:

• Public Cloud: Managed Load Balancer verhindert ARP/VRRP‑Probleme.
• Anycast/BGP: Für globale Verteilung und niedrigere Latenz, erfordert Netzwerk‑Routing‑Expertise.
• Aktiv/Aktiv: Beide LBs tragen Traffic; erfordert Session‑Synchronisation oder zustandslose Anwendungen.

Checkliste vor Produktivsetzung

• VRRP (IP 112) zwischen LBs und im Netz durch Firewall/Switch erlaubt?
• sysctl‑ARP‑Einstellungen auf beiden Knoten gesetzt und geladen?
• Keepalived Track‑Skript funktioniert und Exit‑Codes sind valide?
• HAProxy Health Checks erzielen erwartete Antworten (200/OK)?
• TLS‑Zertifikate auf beiden Knoten installiert und synchronisiert?
• Switch‑Features (DAI, Port Security) geprüft und ggf. angepasst?
• Monitoring und Alerting für VRRP‑Transitions und Backend‑Health eingerichtet?
• Rollback‑Plan getestet (manuelles ip addr add, Keepalived Start/Stop)?

Typische Stolperfallen und schnelle Gegenmaßnahmen

Split Brain: Prüfen Sie VRRP‑Packets, Auth‑Token, virtual_router_id und Prioritäten. Wenn Switches DAI aktiv haben, konfigurieren Sie passende DHCP/ARP‑Bindings oder whitelist die LB‑MACs.

Langsame Umschaltzeiten: Advert‑Interval zu groß, ARP‑Caching bei Clients/Switches oder GARP unterdrückt. Senken Sie advert_int und testen Sie GARP‑Sendeverhalten, aber bedenken Sie, dass sehr kurze Intervalle mehr VRRP‑Traffic erzeugen.

Fazit und Betriebsrelevanz

Ein hochverfügbarer NGINX‑Load‑Balancer mit Keepalived und HAProxy ist eine pragmatische Lösung, um Ausfallrisiken am Netzwerkrand zu reduzieren. Entscheidend sind nicht nur korrekte Konfigurationsdateien, sondern Netz‑ und Switch‑Einstellungen, ARP‑Verhalten, robuste Health‑Checks und ein getesteter Rollout‑Prozess. Investieren Sie Zeit in Monitoring, dokumentierte Runbooks und regelmäßige Failover‑Tests — das sorgt für planbare Betriebsreife.

Weiterführende Prüfbefehle (Quick Reference)

# Wer hat die VIP?
ip -br addr show dev eth0 | grep 10.10.10.10 || true

# VRRP‑Traffic live beobachten
sudo tcpdump -n -i eth0 proto 112

# Prüfen ob Keepalived Track‑Skript läuft und Exit‑Code liefert
/usr/local/sbin/chk_proxy.sh && echo OK || echo FAIL

# GARP senden (Master)
sudo arping -U -I eth0 -c 5 10.10.10.10

# HAProxy Stats (lokal)
curl -sS http://127.0.0.1:8404/stats

Betriebssicherheit: Konfigurationsmanagement, Tests und Schnellwiederherstellung

Nach der technischen Inbetriebnahme entscheidet das Änderungsmanagement über langfristige Stabilität. Legen Sie alle Keepalived-, NGINX- und HAProxy‑Konfigurationen in einem Git‑Repo ab, versionieren Sie Templates und erzeugen aus automatisierten CI‑Pipelines idempotente Artefakte. So lassen sich Rollbacks per Commit sauber nachvollziehen und Konfig‑Drifts vermeiden.

Praktische Ergänzungen:

• Canary‑Rollout: Verteilen Sie config‑Änderungen erst auf den Backup‑Knoten, verifizieren Sie Health‑Checks und Logs, dann auf den Master.
• Schnellwiederherstellung: Dokumentierte Schritte für manuelles Setzen der VIP, Notfall‑SSH‑Access und Wiederherstellung von Git‑Konfigurationen minimalisieren Downtime.
• Erweiterte Fail‑Detection: BFD (Bidirectional Forwarding Detection) für schnellere Erkennung von Linkausfällen zusätzlich zu VRRP nutzen, besonders bei kritischen Latenzanforderungen.
• Netzwerk‑Segmentierung: Führen Sie VRRP‑Signalisierung über ein dediziertes HA‑VLAN/VRF, um Angriffsflächen zu reduzieren — VRRP bietet keine starke Kryptographie.
• Monitoring‑Integration: Pushen Sie VRRP‑States, config‑hashes und Config‑Change‑Events in Ihr zentrales Alerting/Ticketing, damit Konfigurationsänderungen sofort sichtbar sind.

Diese Betriebsbausteine reduzieren menschliche Fehler, beschleunigen Wiederherstellung und machen den LB‑Betrieb reproduzierbar und auditierbar — entscheidend für prozessnahe Unternehmenslösungen mit hohen Verfügbarkeitsanforderungen.

Für dieses Thema sind auch Haproxy High Availability und Load Balancing Layer 4 Und Layer 7 wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.