Ein Load Balancer verteilt eingehende Anfragen auf mehrere Server. Das verbessert Performance, Verfügbarkeit und Skalierbarkeit.

Grundprinzip

Ohne Load Balancer:
Besucher → Server (Single Point of Failure)

Mit Load Balancer:
              ┌→ Server 1
Besucher → LB ├→ Server 2
              └→ Server 3

Warum Load Balancing?

Verfügbarkeit

Server 1 fällt aus:
              ┌→ Server 1 (down) ✗
Besucher → LB ├→ Server 2 ← Traffic umgeleitet
              └→ Server 3 ←

Website bleibt erreichbar!

Skalierbarkeit

Mehr Traffic? Mehr Server hinzufügen:

              ┌→ Server 1
              ├→ Server 2
Besucher → LB ├→ Server 3
              ├→ Server 4 (neu)
              └→ Server 5 (neu)

Performance

Last wird verteilt:
- Kein Server überlastet
- Schnellere Antwortzeiten
- Bessere Ressourcennutzung

Load-Balancing-Algorithmen

Round Robin

Anfragen werden reihum verteilt:

Anfrage 1 → Server 1
Anfrage 2 → Server 2
Anfrage 3 → Server 3
Anfrage 4 → Server 1
...

Vorteile: Einfach, gleichmäßig Nachteile: Ignoriert Serverlast

Weighted Round Robin

Server mit Gewichtung:

Server 1 (weight=3): 3 von 6 Anfragen
Server 2 (weight=2): 2 von 6 Anfragen
Server 3 (weight=1): 1 von 6 Anfragen

Verwendung: Unterschiedlich leistungsstarke Server

Least Connections

Anfrage geht an Server mit wenigsten Verbindungen:

Server 1: 50 Verbindungen
Server 2: 30 Verbindungen ← nächste Anfrage
Server 3: 45 Verbindungen

Vorteile: Berücksichtigt aktuelle Last Verwendung: Unterschiedlich lange Anfragen

IP Hash

Gleiche Client-IP immer zum gleichen Server:

IP 192.168.1.10 → immer Server 2
IP 192.168.1.20 → immer Server 1

Vorteile: Session-Persistenz Nachteile: Ungleiche Verteilung möglich

Least Response Time

Schnellster Server bekommt die Anfrage:

Server 1: 50ms Antwortzeit
Server 2: 30ms Antwortzeit ← nächste Anfrage
Server 3: 45ms Antwortzeit

Layer 4 vs. Layer 7

Layer 4 (Transport)

Arbeitet auf TCP/UDP-Ebene:

Entscheidung basiert auf:
- IP-Adresse
- Port
- Protokoll (TCP/UDP)

Schneller, weniger Overhead
Keine Inhaltsanalyse

Layer 7 (Application)

Arbeitet auf HTTP-Ebene:

Entscheidung basiert auf:
- URL-Pfad
- HTTP-Header
- Cookies
- Host-Header

Mehr Möglichkeiten
Höherer Overhead

Load Balancer mit Nginx

Installation

apt install nginx

Grundkonfiguration

# /etc/nginx/conf.d/loadbalancer.conf

upstream backend {
    server 192.168.1.10:80;
    server 192.168.1.11:80;
    server 192.168.1.12:80;
}

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Mit Gewichtung

upstream backend {
    server 192.168.1.10:80 weight=3;
    server 192.168.1.11:80 weight=2;
    server 192.168.1.12:80 weight=1;
}

Least Connections

upstream backend {
    least_conn;
    server 192.168.1.10:80;
    server 192.168.1.11:80;
    server 192.168.1.12:80;
}

IP Hash (Sticky Sessions)

upstream backend {
    ip_hash;
    server 192.168.1.10:80;
    server 192.168.1.11:80;
    server 192.168.1.12:80;
}

Health Checks

upstream backend {
    server 192.168.1.10:80 max_fails=3 fail_timeout=30s;
    server 192.168.1.11:80 max_fails=3 fail_timeout=30s;
    server 192.168.1.12:80 backup;  # Nur bei Ausfall
}

Load Balancer mit HAProxy

Installation

apt install haproxy

Grundkonfiguration

# /etc/haproxy/haproxy.cfg

global
    log /dev/log local0
    maxconn 4096

defaults
    mode http
    timeout connect 5s
    timeout client 50s
    timeout server 50s

frontend http_front
    bind *:80
    default_backend http_back

backend http_back
    balance roundrobin
    server server1 192.168.1.10:80 check
    server server2 192.168.1.11:80 check
    server server3 192.168.1.12:80 check

Verschiedene Algorithmen

backend http_back
    balance roundrobin     # Standard
    # balance leastconn    # Wenigste Verbindungen
    # balance source       # IP Hash
    # balance uri          # URL Hash

Health Checks

backend http_back
    option httpchk GET /health
    server server1 192.168.1.10:80 check inter 5s fall 3 rise 2
    server server2 192.168.1.11:80 check inter 5s fall 3 rise 2

Statistik-Seite

listen stats
    bind *:8080
    stats enable
    stats uri /stats
    stats auth admin:password

Zugriff: http://loadbalancer:8080/stats

Session-Persistenz

Problem: Benutzer-Sessions bei mehreren Servern.

Lösung 1: Sticky Sessions

# Nginx
upstream backend {
    ip_hash;
    server 192.168.1.10:80;
    server 192.168.1.11:80;
}

Lösung 2: Zentrale Session-Speicherung

              ┌→ Server 1 ─┐
Besucher → LB ├→ Server 2 ─┼→ Redis (Sessions)
              └→ Server 3 ─┘
// PHP-Session in Redis
ini_set('session.save_handler', 'redis');
ini_set('session.save_path', 'tcp://redis-server:6379');

Lösung 3: JWT (Stateless)

Keine Server-Session nötig
Token enthält alle Informationen
Beliebiger Server kann verifizieren

SSL/TLS mit Load Balancer

SSL-Terminierung am LB

              ┌→ Server 1 (HTTP)
Besucher ──SSL──→ LB ├→ Server 2 (HTTP)
              └→ Server 3 (HTTP)
server {
    listen 443 ssl;
    ssl_certificate /etc/ssl/certs/example.com.crt;
    ssl_certificate_key /etc/ssl/private/example.com.key;

    location / {
        proxy_pass http://backend;
    }
}

Vorteile:

  • Zertifikat nur einmal installieren
  • Backend-Server entlastet
  • Einfaches Zertifikatsmanagement

SSL-Passthrough

              ┌→ Server 1 (HTTPS)
Besucher ──SSL──→ LB ├→ Server 2 (HTTPS)
              └→ Server 3 (HTTPS)

LB leitet verschlüsselten Traffic durch.

Hochverfügbarkeit des Load Balancers

Der Load Balancer selbst darf nicht ausfallen:

Lösung: Redundante Load Balancer

                   ┌→ Server 1
        ┌→ LB 1 ───├→ Server 2
VIP ────┤         └→ Server 3
        └→ LB 2 (Standby)

Mit Keepalived:

# /etc/keepalived/keepalived.conf

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    virtual_ipaddress {
        192.168.1.100
    }
}

Cloud Load Balancer

AWS Elastic Load Balancer

  • Application LB (Layer 7)
  • Network LB (Layer 4)
  • Gateway LB
  • Managed Service

Google Cloud Load Balancing

  • HTTP(S) LB
  • TCP/UDP LB
  • Global Load Balancing

Azure Load Balancer

  • Basic und Standard
  • Integriert mit Azure-Diensten

Wann Load Balancing?

Sinnvoll bei

  • Hohem Traffic (tausende Besucher/Stunde)
  • Hochverfügbarkeitsanforderungen
  • Wachsenden Anwendungen
  • Microservices-Architekturen

Nicht nötig bei

  • Kleinen Websites
  • Geringem Traffic
  • Einfachen Blogs
  • Testumgebungen

Fazit

Load Balancer sind essentiell für skalierbare und hochverfügbare Anwendungen. Nginx und HAProxy bieten kostenlose, leistungsfähige Lösungen. Für einfache Setups reicht Round Robin, für komplexere Anforderungen empfiehlt sich Least Connections mit Health Checks. Vergessen Sie nicht die Session-Persistenz und SSL-Terminierung in Ihrer Planung.