# Load Balancing Masterclass: HAProxy & Keepalived

TL;DR / Management Summary Ein einzelner Load Balancer ist ein Single Point of Failure. In diesem Modul bauen wir ein hochverfügbares Gateway: Keepalived verwaltet eine virtuelle IP (VIP), die zwischen zwei Nodes schwenkt, während HAProxy den eingehenden Traffic intelligent auf Backend-Server verteilt. Empfehlung: HAProxy für maximale Flexibilität (Layer 7), Nginx für einfache Web-Setups und Keepalived als unverzichtbares Fundament für das IP-Failover.

# 1. Einführung & Architektur

Die Schichten des Load Balancings.

• Layer 4 (Transport): Keepalived (VRRP). Arbeitet auf IP/Port Ebene. Schnell, merkt sich keine Sessions.
• Layer 7 (Application): HAProxy / Nginx. Erkennt HTTP-Header, Cookies und Pfade. Erlaubt intelligentes Routing.

# Architektur-Übersicht (Mermaid)

graph TD
    A[Client: Internet] -->|Traffic| B[Virtual IP: 10.0.0.100]
    subgraph "HA Balancer Stack"
        B --- C[Node 1: Keepalived + HAProxy]
        B --- D[Node 2: Keepalived + HAProxy]
        C <..>|VRRP Heartbeat| D
    end
    C --> E[Backend Web 1]
    C --> F[Backend Web 2]
    D --> E
    D --> F

# 2. Keepalived: Die virtuelle IP (VIP)

Das Fundament.

Keepalived nutzt das VRRP-Protokoll. Der Node mit der höchsten Priorität hält die IP.

# Konfiguration (/etc/keepalived/keepalived.conf)

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass secret
    }
    virtual_ipaddress {
        10.0.0.100/24
    }
}

# 3. HAProxy: Intelligente Verteilung

Der Traffic-Manager.

HAProxy bietet ungeschlagene Performance und detaillierte Statistiken.

# Konfiguration (/etc/haproxy/haproxy.cfg)

frontend main_gateway
    bind *:80
    acl is_api path_beg /api
    use_backend api_servers if is_api
    default_backend web_servers

backend web_servers
    balance roundrobin
    server srv1 10.0.0.51:80 check
    server srv2 10.0.0.52:80 check

backend api_servers
    balance leastconn
    server api1 10.0.0.61:8080 check

# 4. Day-2 Operations: Monitoring & Health-Checks

Wann ist ein Backend “down”?

# HAProxy Stats Page

Aktivieren Sie die grafische Übersicht:

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

# Keepalived Checks

Stellen Sie sicher, dass Keepalived die IP abgibt, wenn HAProxy stirbt:

vrrp_script check_haproxy {
    script "killall -0 haproxy"
    interval 2
    weight 2
}

# 5. Troubleshooting & “War Stories”

Praxisfallen.

# Story 1: “Der Split-Brain VIP”

Symptom: Beide Balancer-Nodes behaupten “MASTER” zu sein. Die VIP ist doppelt im Netz (IP-Konflikt). Ursache: Die Balancer können sich gegenseitig nicht mehr per UDP/Multicast (Port 112) erreichen (Firewall!). Lösung: Erlauben Sie VRRP-Traffic in UFW/Iptables: ufw allow proto vrrp.

# Story 2: “Session-Verlust bei Failover”

Symptom: Wenn der Balancer schwenkt, fliegen alle User aus der Applikation (Login weg). Ursache: HAProxy verteilt zwar Last, aber die Sessions liegen lokal auf den Webservern. Lösung: Nutzen Sie Redis für zentrales Session-Management oder setzen Sie stick-table in HAProxy ein, damit User immer zum gleichen Backend geschickt werden (Persistence).

# 6. Fazit & Empfehlung

• Redundanz: Betreiben Sie Load Balancer niemals als Single Node.
• Layer 7: Nutzen Sie HAProxy, wenn Sie Header-Manipulation oder komplexes Path-Routing brauchen.
• Performance: HAProxy ist für reine Load-Balancing-Aufgaben effizienter als Nginx.

# Anhang: Cheatsheet