Load Balancing verteilt Anfragen (Traffic) auf mehrere Server, um Verfügbarkeit, Leistung und Ausfallsicherheit zu erhöhen.

Typische Einsatzgebiete:

• Webseiten (z. B. www.example.com)
• APIs & Microservices
• Docker / Kubernetes
• Unternehmensanwendungen
• Datenbanken (Read-Replicas)
• E-Mail-Cluster
• VPN-Gateways

• höhere Verfügbarkeit (kein Single Point of Failure)
• bessere Performance
• mehr Kapazität
• Wartung ohne Downtime
• DDoS-Abmilderung

• Layer 4 Load Balancing (Transport Layer)
• Layer 7 Load Balancing (Application Layer)

L4 arbeitet auf Basis von:

• IP-Adresse
• Port
• TCP/UDP

Der Load Balancer weiß NICHT, was im HTTP/TLS passiert – er verteilt nur Verbindungen.

ASCII:

 Client → LB (L4) → Server1
                  → Server2
                  → Server3

• sehr schnell
• arbeitet mit TCP/UDP direkt
• keine Inhalteinsicht
• gut für VPN, Datenbanken, SMTP, Spiele-Server

• HAProxy (L4/L7)
• Linux IPVS (z. B. keepalived)
• LVS Load Balancer
• AWS NLB (Network Load Balancer)

• Round Robin
• Least Connections
• Source IP Hash
• Weighted Scheduling

L7 „versteht“, was im HTTP/HTTPS passiert, und kann Inhalte analysieren.

Kann abhängig machen von:

• URLs
• Headern
• Cookies
• Benutzeragenten
• Sessions
• APIs

ASCII:

 Client → LB (L7)
             ├── /api → Server1
             ├── /images → Server2
             └── /admin → Server3

• sehr flexibel
• Routing nach Inhalt
• SSL/TLS-Terminierung möglich
• ideal für Webservices

• Nginx
• Traefik
• HAProxy (kann L7)
• Envoy
• F5 Big-IP
• AWS ALB (Application Load Balancer)

• intelligenter Trafficfluss
• HTTPS-Aufbrechen & Analyse
• API-Gateway-Funktionen

• mehr CPU-Bedarf
• komplexer
• TLS-Handling muss sauber sein

Jede Anfrage nacheinander an anderen Server.

 1 → S1  
 2 → S2  
 3 → S3  
 4 → S1  

Der Server mit den wenigsten aktiven Verbindungen bekommt die nächste Anfrage.

Gleiche Quell-IP → immer gleicher Server (Sessionstickiness).

Server mit mehr Leistung bekommen mehr Anfragen.

Ein Load Balancer prüft regelmäßig, ob ein Server gesund ist.

Beispiele:

• Ping
• TCP-Port erreichbar
• HTTP-Status 200
• eigene API-Healthchecks

Wenn ein Server nicht gesund ist → automatisch herausgenommen.

ASCII:

 Server2 DOWN → Traffic nur an Server1 & Server3

Der Load Balancer entschlüsselt HTTPS und leitet intern HTTP weiter.

Vorteile:

• geringere Serverlast
• zentrale Zertifikatsverwaltung
• Content-based Routing möglich

Beispiel (Traefik, Nginx):

 Client → HTTPS → LB → HTTP → Backend

 Nginx/Traefik LB → 3× Apache/PHP Server

 HAProxy (L4) → 2× Dovecot IMAP Server

 HAProxy (L4) → 2× WireGuard Gateways

K8s nutzt:

• kube-proxy
• ingress controller (Traefik, Nginx)
• LoadBalancer Services

Load Balancer:

• verteilt Traffic
• kann L4 oder L7 sein

Reverse Proxy:

• immer L7
• nimmt Anfragen entgegen und leitet an Backend weiter
• z. B. Traefik, Nginx, Apache mod_proxy

Viele Produkte kombinieren beides.

Oft nutzt man:

• VRRP (Keepalived)
• Heartbeat
• Pacemaker

ASCII:

 VIP (Virtuelle IP)
      ↓
 [LB1] <→> [LB2]

Wenn LB1 ausfällt → LB2 übernimmt.

• Load Balancing verteilt Anfragen auf mehrere Server
• L4 = schnelles Routing nach IP/Port
• L7 = Routing nach Inhalten (URLs, Header)
• Health Checks prüfen Serverzustand
• TLS-Offloading erleichtert Verwaltung
• in modernen Architekturen unverzichtbar
• Docker, Kubernetes, Cloud nutzen fast immer L7 Load Balancer