Load Balancing mit Dedicated Servers: Architektur, Algorithmen und Implementierung in der Praxis

Load Balancing ist der Prozess der Verteilung des eingehenden Netzwerkverkehrs auf mehrere Server, sodass kein einzelner Knoten zum Engpass wird, und gewährleistet konsistente Leistung, Fehlertoleranz und horizontale Skalierbarkeit. In einer Dedicated-Server-Umgebung sitzt ein Load Balancer vor Ihrem Server-Pool und trifft Echtzeit-Routing-Entscheidungen basierend auf Server-Gesundheit, aktiven Verbindungen, Antwortlatenz oder benutzerdefinierten Richtlinienregeln.

Für jede Infrastruktur, die latenzempfindliche Workloads betreibt – E-Commerce-Plattformen, SaaS-Anwendungen, APIs mit hohem Datenverkehr oder Media-Streaming – ist Load Balancing keine Option. Es ist das architektonische Fundament, das ein fragiles Single-Point-of-Failure-Setup von einem produktionsreifen, widerstandsfähigen System trennt.

Wie Load Balancing tatsächlich funktioniert: Der technische Ablauf

Das Verständnis von Load Balancing erfordert das Verständnis des vollständigen Request-Lebenszyklus, nicht nur des abstrakten Konzepts der „Verkehrsverteilung”.

Die Request-Routing-Pipeline

1. DNS-Auflösung verweist den Client auf die IP-Adresse des Load Balancers (oder eine virtuelle IP in einem Anycast-Setup), nicht auf einen einzelnen Server.
2. Der Load Balancer empfängt die Verbindung entweder auf Layer 4 (TCP/UDP) oder Layer 7 (HTTP/HTTPS) des OSI-Modells.
3. Der Balancer wertet seine Routing-Tabelle aus, wendet den konfigurierten Algorithmus an und prüft den aktuellen Gesundheitsstatus jedes Backend-Knotens.
4. Die Anfrage wird weitergeleitet an den ausgewählten Backend-Server. Abhängig vom Modus (NAT, Direct Server Return oder IP-Tunneling) kann der Antwortpfad über den Balancer zurückführen oder nicht.
5. Health-Check-Daemons laufen parallel und prüfen kontinuierlich jeden Backend-Server via TCP-Ping, HTTP-Statuscodes oder benutzerdefinierte Skripte. Ein fehlerhafter Knoten wird innerhalb von Sekunden aus dem Pool entfernt.

Layer 4 vs. Layer 7 Load Balancing

Diese Unterscheidung ist eine der folgenreichsten architektonischen Entscheidungen, die Sie treffen werden.

Für die meisten auf Dedicated Servern gehosteten Webanwendungen ist Layer 7 die richtige Wahl, da es intelligentes Routing, SSL-Offloading und granulare Health Checks basierend auf HTTP-Antwortcodes statt auf roher TCP-Konnektivität ermöglicht.

Load-Balancing-Algorithmen: Die richtige Strategie wählen

Der Algorithmus bestimmt, welcher Backend-Server jede eingehende Anfrage erhält. Die falsche Wahl für Ihr Workload-Profil ist eine häufige Ursache für ungleichmäßige Ressourcenauslastung.

Round Robin

Anfragen werden sequenziell auf alle gesunden Knoten verteilt. Einfach und effektiv, wenn alle Server identische Hardware-Spezifikationen haben und die Anfrageverarbeitungszeiten ungefähr gleich sind.

Fallstrick: Wenn eine Anfrage 10 Sekunden dauert und die nächste 10 Millisekunden, berücksichtigt Round Robin diese Diskrepanz nicht. Ein langsamer Backend-Server akkumuliert eine Warteschlange, während andere im Leerlauf sind.

Weighted Round Robin

Jedem Server wird ein numerisches Gewicht zugewiesen. Ein Server mit Gewicht 3 erhält dreimal so viele Anfragen wie einer mit Gewicht 1. Verwenden Sie dies, wenn Ihr Pool heterogene Hardware enthält – zum Beispiel die Kombination eines 32-Kern-Knotens mit einem 16-Kern-Knoten.

Least Connections

Der Balancer verfolgt die Anzahl der aktiven Verbindungen zu jedem Backend und leitet neue Anfragen an den Server mit den wenigsten offenen Verbindungen weiter. Dies ist der am besten geeignete Standard-Algorithmus für Workloads mit variablen Anfragedauern, wie datenbankgestützte Webanwendungen.

Least Response Time

Eine Erweiterung von Least Connections, die auch die gemessene Backend-Latenz berücksichtigt. Der Server mit der niedrigsten Kombination aus aktiven Verbindungen und durchschnittlicher Antwortzeit gewinnt. Dies erfordert, dass der Balancer Latenzmetriken pflegt, was einen geringen Overhead hinzufügt, aber die Verteilungsqualität unter gemischter Last erheblich verbessert.

IP Hash (Source Affinity)

Die Quell-IP-Adresse des Clients wird gehasht, um deterministisch ein Backend auszuwählen. Derselbe Client erreicht immer denselben Server, solange sich die Pool-Mitgliedschaft nicht ändert. Dies bietet eine primitive Form der Session-Persistenz ohne gemeinsamen Session-Speicher.

Kritischer Grenzfall: Wenn ein großer Teil Ihres Datenverkehrs hinter einem Unternehmens-NAT oder dem Gateway eines Mobilfunkanbieters stammt, können Tausende von Benutzern eine einzige Quell-IP teilen, was zu schwerwiegenden Ungleichgewichten führt. Prüfen Sie immer Ihre Datenverkehrsverteilung, bevor Sie sich in der Produktion auf IP Hash verlassen.

Random with Two Choices (Power of Two)

Der Balancer wählt zufällig zwei Kandidaten-Server aus und leitet an den mit weniger aktiven Verbindungen weiter. Dieser probabilistische Ansatz skaliert in großen Pools (50+ Knoten) extrem gut, da er den Koordinations-Overhead eines globalen Least-Connections-Scans vermeidet und gleichzeitig das Worst-Case-Ungleichgewicht einer reinen Zufallsauswahl verhindert.

Session-Persistenz: Wenn Stateless keine Option ist

Viele Legacy-Anwendungen speichern den Session-Zustand lokal auf dem Server (z. B. PHP $_SESSION auf Disk geschrieben). In diesen Fällen führt das Routing eines zurückkehrenden Benutzers zu einem anderen Backend zu einem Session-Verlust, der sich als unerwartete Abmeldungen oder verlorene Warenkorb-Daten manifestiert.

Load Balancer lösen dies mit Sticky Sessions, implementiert über:

• Cookie-Injection: Der Balancer fügt ein Cookie (z. B. SERVERID=node2) in die HTTP-Antwort ein. Nachfolgende Anfragen von diesem Client tragen das Cookie, und der Balancer liest es, um zurück zum selben Knoten zu routen.
• Source-IP-Affinität: Wie oben beschrieben, weniger zuverlässig, erfordert aber keine Cookie-Unterstützung von der Anwendung.

Die langfristig richtige Lösung ist die Auslagerung des Session-Speichers in ein gemeinsames Backend – Redis oder Memcached – sodass jeder Backend-Knoten jeden Benutzer bedienen kann. Dies eliminiert die Abhängigkeit von Sticky Sessions vollständig und macht Ihren Pool vollständig zustandslos, was Skalierung und Failover erheblich vereinfacht. Wenn Sie eine neue Anwendung entwickeln, entwerfen Sie von Anfang an für zustandslose Backends.

Health Checks: Der Mechanismus hinter automatischem Failover

Ein Load Balancer ist nur so zuverlässig wie seine Health-Check-Konfiguration. Falsch konfigurierte Health Checks sind für einen erheblichen Anteil realer Load-Balancer-Vorfälle verantwortlich.

Health-Check-Typen

• TCP-Check: Öffnet eine TCP-Verbindung zum Backend-Port. Bestätigt, dass der Prozess lauscht, überprüft aber nicht die Korrektheit auf Anwendungsebene.
• HTTP/HTTPS-Check: Sendet eine HTTP-Anfrage an einen definierten Endpunkt (z. B. /health) und erwartet einen bestimmten Statuscode (typischerweise 200 OK). Dies ist der Mindeststandard für Webanwendungen.
• Custom-Script-Check: Führt ein beliebiges Skript aus, das eine Datenbank abfragen, den Festplattenspeicher prüfen oder den Anwendungszustand validieren kann. Gibt 0 für gesund zurück, ungleich null für ungesund.

Kritische Konfigurationsparameter

• interval: Wie häufig der Check ausgeführt wird (z. B. alle 5 Sekunden).
• timeout: Wie lange auf eine Antwort gewartet wird, bevor der Check als fehlgeschlagen markiert wird.
• rise: Anzahl aufeinanderfolgender erfolgreicher Checks, die erforderlich sind, um einen Knoten als gesund zu markieren (verhindert Flapping).
• fall: Anzahl aufeinanderfolgender fehlgeschlagener Checks, die erforderlich sind, um einen Knoten aus dem Pool zu entfernen.

Eine gängige Produktionskonfiguration für HAProxy sieht folgendermaßen aus:

backend web_servers
    balance leastconn
    option httpchk GET /health HTTP/1.1rnHost: example.com
    http-check expect status 200
    default-server inter 5s fall 3 rise 2 slowstart 60s
    server node1 192.168.1.10:80 check weight 10
    server node2 192.168.1.11:80 check weight 10
    server node3 192.168.1.12:80 check weight 5

Die slowstart 60s-Direktive ist besonders wertvoll: Sie erhöht den Datenverkehr zu einem neu wiederhergestellten Knoten über 60 Sekunden schrittweise, anstatt ihn sofort mit voller Last zu belasten, und verhindert so ein Thundering-Herd-Problem, wenn ein Backend nach der Wartung wieder online geht.

SSL-Terminierung und TLS-Offloading

Die Handhabung von TLS-Verschlüsselung und -Entschlüsselung ist rechenintensiv. In einem naiven Setup führt jeder Backend-Server diese Arbeit unabhängig durch. SSL-Terminierung am Load Balancer bedeutet, dass der Balancer eingehenden HTTPS-Datenverkehr entschlüsselt und einfaches HTTP über ein vertrauenswürdiges internes Netzwerk an die Backends weiterleitet.

Vorteile:

• Reduziert die CPU-Last auf Backend-Servern und gibt Zyklen für die Anwendungslogik frei.
• Zentralisiert das Zertifikatsmanagement – erneuern Sie ein Zertifikat auf dem Balancer statt auf jedem Knoten.
• Ermöglicht Layer-7-Inspektion des Anfrageinhalts (unmöglich bei verschlüsseltem Pass-through).

Sicherheitsüberlegung: Der Datenverkehr zwischen dem Load Balancer und den Backends ist unverschlüsselt. Dies ist akzeptabel, wenn sich alle Knoten in einem isolierten privaten VLAN oder einem dedizierten Management-Netzwerk befinden. Wenn Ihre Compliance-Anforderungen (PCI-DSS, HIPAA) eine Ende-zu-Ende-Verschlüsselung vorschreiben, verwenden Sie SSL-Re-Encryption: Der Balancer beendet die clientseitige TLS-Sitzung und stellt eine neue TLS-Sitzung zu jedem Backend her. Dies gewährleistet vollständige Verschlüsselung und ermöglicht gleichzeitig Layer-7-Routing.

Die Kombination von SSL-Terminierung mit ordnungsgemäß ausgestellten SSL-Zertifikaten stellt sicher, dass Ihre load-balancierte Infrastruktur sowohl Leistungs- als auch Compliance-Anforderungen erfüllt.

Hochverfügbarkeit für den Load Balancer selbst

Ein Load Balancer, der selbst ein Single Point of Failure ist, verfehlt den Zweck der gesamten Architektur. Produktionsdeployments erfordern ein hochverfügbares Load-Balancer-Paar.

Active-Passive mit VRRP/Keepalived

Zwei Load-Balancer-Knoten teilen sich eine Virtual IP (VIP). Der aktive Knoten hält die VIP und verarbeitet den gesamten Datenverkehr. Der passive Knoten überwacht den aktiven Knoten via Heartbeat. Wenn der aktive Knoten ausfällt, löst keepalived ein VRRP-Failover aus, und der passive Knoten beansprucht die VIP innerhalb von 1–3 Sekunden.

# Install keepalived on both load balancer nodes (Debian/Ubuntu)
apt-get install keepalived

# /etc/keepalived/keepalived.conf on the MASTER node
vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass securepassword
    }
    virtual_ipaddress {
        203.0.113.10/24
    }
}

Setzen Sie auf dem Backup-Knoten state BACKUP und priority 90. Der Knoten mit der höheren Priorität gewinnt die VIP-Wahl.

Active-Active mit DNS Round Robin oder Anycast

Beide Load-Balancer-Knoten verarbeiten gleichzeitig aktiv Datenverkehr. DNS gibt mehrere A-Records zurück und verteilt Clients auf beide Balancer. Dies verdoppelt die Durchsatzkapazität, erfordert aber eine sorgfältige Zustandssynchronisierung, wenn Sie Sticky Sessions verwenden.

Für groß angelegte Deployments auf Dedicated Servern bietet eine Active-Active-Konfiguration mit BGP-Anycast-Routing den höchsten Durchsatz und geografische Redundanz.

DDoS-Mitigation auf der Load-Balancer-Ebene

Ein Load Balancer, der am Netzwerkrand positioniert ist, ist ein natürlicher Ort zur Implementierung von Traffic-Scrubbing und Rate-Limiting, bevor bösartige Anfragen Ihre Anwendungsserver erreichen.

Connection Rate Limiting (HAProxy)

frontend http_in
    bind *:80
    bind *:443 ssl crt /etc/haproxy/certs/
    stick-table type ip size 100k expire 30s store conn_rate(3s),http_req_rate(10s)
    tcp-request connection track-sc0 src
    tcp-request connection reject if { sc_conn_rate(0) gt 100 }
    http-request deny if { sc_http_req_rate(0) gt 300 }

Diese Konfiguration verfolgt Verbindungsraten pro Quell-IP in einer Stick-Table und lehnt Clients ab, die 100 neue TCP-Verbindungen pro 3 Sekunden oder 300 HTTP-Anfragen pro 10 Sekunden überschreiten – Schwellenwerte, die die meisten volumetrischen HTTP-Flood-Angriffe blockieren und gleichzeitig legitimen Burst-Datenverkehr zulassen.

SYN-Flood-Schutz

Aktivieren Sie SYN-Cookies auf Kernel-Ebene auf Ihren Load-Balancer-Knoten, um SYN-Flood-Angriffe zu bewältigen, ohne die Verbindungstabelle zu erschöpfen:

sysctl -w net.ipv4.tcp_syncookies=1
sysctl -w net.ipv4.tcp_max_syn_backlog=4096
sysctl -w net.ipv4.tcp_synack_retries=2

Machen Sie diese persistent, indem Sie sie zu /etc/sysctl.conf hinzufügen.

NGINX als Layer-7-Load-Balancer: Produktionskonfiguration

NGINX ist eine weit verbreitete Option für HTTP-Load-Balancing, insbesondere wenn Sie eine enge Integration mit Funktionen auf Anwendungsebene benötigen.

upstream backend_pool {
    least_conn;
    keepalive 32;

    server 192.168.1.10:8080 weight=3 max_fails=3 fail_timeout=30s;
    server 192.168.1.11:8080 weight=3 max_fails=3 fail_timeout=30s;
    server 192.168.1.12:8080 weight=1 max_fails=3 fail_timeout=30s;
    server 192.168.1.13:8080 backup;
}

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate     /etc/nginx/ssl/example.com.crt;
    ssl_certificate_key /etc/nginx/ssl/example.com.key;
    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_ciphers         HIGH:!aNULL:!MD5;

    location / {
        proxy_pass         http://backend_pool;
        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;
        proxy_connect_timeout 5s;
        proxy_read_timeout    60s;
        proxy_next_upstream   error timeout http_502 http_503;
    }
}

Wichtige Details in dieser Konfiguration:

• keepalive 32 pflegt persistente Verbindungen zu Backends und eliminiert TCP-Handshake-Overhead für hochfrequente Anfragen.
• proxy_next_upstream wiederholt fehlgeschlagene Anfragen automatisch auf dem nächsten gesunden Backend.
• Die backup-Direktive designiert node4 als Standby, der nur Datenverkehr erhält, wenn alle primären Knoten nicht verfügbar sind.
• X-Forwarded-For stellt sicher, dass Backend-Anwendungen die echte Client-IP statt der IP des Balancers sehen.

Vergleich der Load-Balancer-Software-Optionen

Für selbstverwaltete Dedicated Server decken HAProxy und NGINX die große Mehrheit der Produktionsanwendungsfälle ab. Traefik ist die pragmatische Wahl für Docker-Swarm- oder Kubernetes-Workloads aufgrund seiner automatischen Service-Discovery.

Reale Architektur: E-Commerce-Plattform unter Spitzenlast

Betrachten Sie ein konkretes Szenario: eine E-Commerce-Plattform, die während eines Werbeereignisses 50.000 gleichzeitige Benutzer erwartet.

Infrastruktur-Layout:

• 2x HAProxy-Knoten in Active-Passive-Konfiguration, die sich eine VIP teilen (via Keepalived)
• 6x Anwendungsserver, die die Web-Tier betreiben
• 2x dedizierte Datenbankserver (nicht im Load-Balancer-Pool – sie verwenden ihre eigene Replikation)
• 1x Redis-Cluster für gemeinsamen Session-Speicher (eliminiert die Abhängigkeit von Sticky Sessions)
• Gemeinsamer NFS oder Objektspeicher für vom Benutzer hochgeladene Assets

Datenverkehrsfluss:

1. Client-DNS löst zur VIP auf, die vom aktiven HAProxy-Knoten gehalten wird.
2. HAProxy wendet den leastconn-Algorithmus an und verteilt Anfragen auf 6 App-Server.
3. Jeder App-Server liest/schreibt Session-Daten aus Redis – keine Session-Affinität erforderlich.
4. Statische Assets werden direkt aus dem Objektspeicher über ein CDN bereitgestellt, umgehen den Load Balancer vollständig und reduzieren seine Last um 60–70%.
5. Wenn der Health Check eines App-Servers dreimal hintereinander fehlschlägt, entfernt HAProxy ihn innerhalb von 15 Sekunden aus dem Pool. Die verbleibenden 5 Server übernehmen seinen Datenverkehr.
6. Wenn der aktive HAProxy-Knoten ausfällt, überträgt Keepalived die VIP innerhalb von 2 Sekunden auf den passiven Knoten – für alle Clients transparent.

Diese Architektur bewältigt den Werbespike, ohne dass eine einzelne Komponente zum Engpass wird, und skaliert horizontal durch Hinzufügen weiterer App-Server zum HAProxy-Pool ohne Ausfallzeiten.

Wenn Sie GPU-beschleunigte Inferenz-Workloads hinter einem Load Balancer betreiben – zum Beispiel die Verteilung von ML-Modell-Serving-Anfragen – gelten dieselben Prinzipien, aber Backend-Health-Checks sollten die GPU-Verfügbarkeit und den VRAM-Headroom validieren, nicht nur die HTTP-Erreichbarkeit. GPU-Hosting-Infrastruktur profitiert erheblich vom Least-Response-Time-Balancing aufgrund der hohen Varianz in der Inferenzlatenz über verschiedene Anfragetypen.

Überwachung einer load-balancierten Infrastruktur

Den Betrieb eines Load Balancers ohne Observability ist blindes Operieren. Dies sind die Metriken, die wichtig sind:

• Aktive Verbindungen pro Backend: Zeigt Ungleichgewichte im Verteilungsalgorithmus oder Sticky-Session-Konzentration.
• Anfragerate (RPS) pro Backend: Sollte proportional zu den Server-Gewichten sein.
• Backend-Antwortzeit (p50, p95, p99): p99-Latenzspitzen auf einem Knoten weisen auf ein Problem hin, bevor Health Checks ausgelöst werden.
• Health-Check-Fehlerrate: Ein Backend, das zwischen gesund und ungesund oszilliert (Flapping), weist auf eine zugrunde liegende Instabilität hin, die untersucht werden muss.
• Verbindungswarteschlangentiefe: Wenn die Warteschlange des Balancers wächst, ist Ihr Backend-Pool für den aktuellen Datenverkehr zu klein.
• SSL-Handshake-Rate: Hohe Raten weisen auf einen potenziellen TLS-Erschöpfungsangriff oder einen falsch konfigurierten Client hin, der aggressiv wiederholt.

HAProxy stellt eine Statistikseite bereit (aktivieren mit stats enable im Frontend) und einen Unix-Socket für programmatische Abfragen. Speisen Sie diese Metriken über haproxy_exporter in Prometheus ein und visualisieren Sie sie in Grafana für einen vollständigen Observability-Stack.

Praktische Entscheidungs-Checkliste

Verwenden Sie diese Matrix vor dem Deployment oder der Änderung einer load-balancierten Architektur:

• Zustandsbehaftete Anwendung? Migrieren Sie den Session-Speicher zu Redis oder Memcached, bevor Sie Load Balancing aktivieren. Verlassen Sie sich nicht dauerhaft auf Sticky Sessions.
• TLS erforderlich? Terminieren Sie SSL am Load Balancer. Stellen Sie sicher, dass das Backend-Netzwerk isoliert ist. Beschaffen und verwalten Sie Zertifikate zentral über SSL-Zertifikate.
• Variable Anfragedauer? Verwenden Sie leastconn, nicht Round Robin.
• Heterogene Hardware? Wenden Sie weight-Werte proportional zur Server-Kapazität an.
• Load-Balancer-HA? Deployen Sie zwei Balancer-Knoten mit Keepalived/VRRP. Betreiben Sie niemals einen einzelnen Load Balancer in der Produktion.
• DDoS-Exposition? Implementieren Sie Connection Rate Limiting und SYN-Cookie-Schutz auf Kernel- und Balancer-Ebene.
• Health-Check-Tiefe? Verwenden Sie HTTP-Checks gegen einen dedizierten /health-Endpunkt, der die Datenbankverbindung validiert, nicht nur die TCP-Port-Verfügbarkeit.
• Skalierungsplan? Das Hinzufügen eines neuen Backend-Knotens zu einem HAProxy- oder NGINX-Pool erfordert ein Konfigurations-Reload (haproxy -sf $(cat /var/run/haproxy.pid) für Zero-Downtime-Reload) – planen Sie Ihren Change-Management-Prozess entsprechend.
• Monitoring? Instrumentieren Sie HAProxy oder NGINX mit Prometheus-Exportern vor dem Go-Live, nicht nach einem Vorfall.
• Control-Panel-Präferenz? Wenn Sie GUI-basiertes Server-Management neben manueller Load-Balancer-Konfiguration bevorzugen, evaluieren Sie VPS Control Panels für administrative Aufgaben auf einzelnen Knoten.

FAQ

Was ist der Unterschied zwischen einem Load Balancer und einem Reverse Proxy?

Ein Reverse Proxy leitet Client-Anfragen an einen oder mehrere Backend-Server weiter und gibt die Antwort an den Client zurück – er übernimmt Routing, Caching und SSL-Terminierung. Ein Load Balancer ist eine spezifische Art von Reverse Proxy, dessen Hauptfunktion die Verteilung von Anfragen auf mehrere Backends mithilfe eines definierten Algorithmus ist. Alle Load Balancer sind Reverse Proxies, aber nicht alle Reverse Proxies führen Load Balancing durch.

Kann Load Balancing mit einem einzelnen Dedicated Server funktionieren?

Technisch ja – Sie können einen Load Balancer vor einem einzelnen Server für SSL-Terminierung, Caching und Rate Limiting betreiben. Die Fehlertoleranz- und horizontalen Skalierungsvorteile materialisieren sich jedoch nur mit zwei oder mehr Backend-Knoten. Ein Einzelserver-Setup hinter einem Load Balancer ist eine valide Übergangsarchitektur, die zukünftige Skalierung operativ trivial macht.

Wie behandelt ein Load Balancer WebSocket-Verbindungen?

WebSockets erfordern persistente, langlebige TCP-Verbindungen. Layer-7-Load-Balancer müssen explizit konfiguriert werden, um den HTTP-Upgrade-Handshake zu verarbeiten und dann die Verbindungsaffinität für die Dauer der WebSocket-Sitzung aufrechtzuerhalten. Setzen Sie in NGINX proxy_http_version 1.1 und proxy_set_header Upgrade $http_upgrade mit proxy_set_header Connection "upgrade". Verwenden Sie in HAProxy option http-server-close und konfigurieren Sie geeignete Timeout-Werte (timeout tunnel 1h für langlebige Verbindungen).

Was passiert mit laufenden Anfragen, wenn ein Backend-Server ausfällt?

Mit proxy_next_upstream in NGINX oder retries in HAProxy erkennt der Balancer beim ersten Versuch einen Verbindungsfehler oder Timeout und wiederholt die Anfrage sofort auf dem nächsten gesunden Backend. Diese Wiederholung ist für den Client transparent. Idempotente Anfragen (GET, HEAD) können automatisch wiederholt werden. Nicht-idempotente Anfragen (POST, PUT) sollten mit Vorsicht wiederholt werden – konfigurieren Sie proxy_next_upstream, um http_500 für POST-Routen auszuschließen, um eine Doppelverarbeitung einer Zahlung oder Formularübermittlung zu vermeiden.

Wie viele Backend-Server werden benötigt, bevor Load Balancing einen nennenswerten Nutzen bringt?

Zwei Server bieten sofortige Failover-Fähigkeit und ungefähr doppelte Kapazität. Drei oder mehr Server bieten eine sinnvolle statistische Verteilung und ermöglichen Rolling-Maintenance (einen Knoten für Updates offline nehmen, während die anderen den Datenverkehr absorbieren). Für Produktions-Workloads sind drei Knoten das praktische Minimum für einen widerstandsfähigen Pool – zwei Knoten bedeuten, dass ein einzelner Ausfall Ihre Kapazität um 50% reduziert, was unter Spitzenlast möglicherweise Ihre Performance-SLA verletzt.