Netzwerk-Lastverteilungsprobleme entstehen meist durch falsche Algorithmen, fehlschlagende Health Checks, überlastete Backend-Knoten oder blockierende Firewalls. Prüfen Sie zuerst die Verteilungsstatistik am Load Balancer, danach den Zustand der Backends, die Session-Persistenz und schließlich die Netzwerkpfade. So isolieren Sie die Ursache und stellen eine gleichmäßige Verteilung wieder her.
Symptome
- Einzelne Backend-Server tragen 80–100 % des Traffics, andere bleiben nahezu ungenutzt.
- Anfragen laufen in Timeouts oder liefern intermittierend HTTP 502/503/504 zurück.
- Benutzer werden nach dem Login abgemeldet oder verlieren die Sitzung.
- Verbindungsaufbau ist langsam, obwohl CPU und RAM der Backends niedrig sind.
- Der Load Balancer meldet Backends abwechselnd als „down
- ;obwohl sie erreichbar sind.
Häufige Ursachen
Ungeeigneter Lastverteilungsalgorithmus
Round Robin verteilt zwar gleichmäßig, ignoriert aber Sitzungsdauer und Last pro Verbindung. Bei langlebigen Verbindungen führt das zu Schieflagen.
Fehlerhafte Health Checks
Zu strenge Intervalle, falsche Prüf-URL oder ein falscher Status-Code lassen Backends fälschlich als ungesund gelten und schließen sie aus der Rotation aus.
Session-Persistenz falsch konfiguriert
Fehlende oder inkonsistente Sticky Sessions führen zu Logout-Effekten. Eine zu aggressive Persistenz konzentriert dagegen den Traffic auf wenige Knoten.
Firewall- oder Sicherheitsregeln
Regeln zwischen Load Balancer und Backend blockieren den Health-Check-Port oder den Nutz-Traffic, sodass Antworten verworfen werden.
DNS- und Routing-Konflikte
Mehrere A-Records, altes GSLB-Caching oder asymmetrisches Routing leiten Clients an eine einzelne VIP oder um den Load Balancer herum.
Schritt-für-Schritt-Lösung
- Verteilungsstatistik am Load Balancer auslesen
Öffnen Sie die Statusseite (HAProxy Stats, Nginx stub_status, F5 iControl, Azure/AWS Metriken) und vergleichen Sie aktive Verbindungen, Anfragen pro Sekunde und Bytes pro Backend. Erst wenn Sie die reale Verteilung kennen, ergibt jede weitere Prüfung Sinn. - Algorithmus und Gewichtung überprüfen
Kontrollieren Sie in der Konfiguration den Algorithmus (roundrobin, leastconn, source, uri) und die Weight-Werte. Setzen Sie bei ungleicher Hardware unterschiedliche Gewichte. Für langlebige Verbindungen ist leastconn meist stabiler als Round Robin. - Health-Check-Konfiguration validieren
Prüfen Sie Intervall, Timeout, Anzahl der Fehlversuche sowie den erwarteten HTTP-Status oder String. Führen Sie den Check manuell mit curl gegen jeden Backend-Knoten aus. Falsch definierte Prüfpfade sind eine der häufigsten Ursachen für Flapping. - Backend-Server einzeln testen
Nehmen Sie jeden Knoten kurz aus der Rotation und rufen Sie ihn direkt über die interne IP auf. Achten Sie auf Antwortzeit, Fehlerquote und Ressourcenauslastung (CPU, RAM, Sockets, Datei-Handles). Ein überlasteter Knoten verzerrt jede Verteilung. - Firewall- und Netzwerkpfade prüfen
Testen Sie mit tcpdump oder ss/netstat, ob Health-Check- und Nutz-Traffic wirklich am Backend ankommen und Antworten zurückkehren. Prüfen Sie Security Groups, iptables, NSGs und Zwischen-Firewalls auf blockierte Ports und Verbindungslimits. - Session-Persistenz gezielt einstellen
Setzen Sie Sticky Sessions nur dort ein, wo die Anwendung sie braucht (Login, Warenkorb). Nutzen Sie Cookie-basierte Persistenz statt Quell-IP, wenn viele Clients hinter NAT stehen, sonst konzentriert sich der Traffic auf wenige Backends. - DNS, VIPs und Client-Auflösung kontrollieren
Prüfen Sie mit dig oder nslookup, dass Clients die richtige VIP erhalten. Reduzieren Sie TTLs vor Änderungen. Bei aktivem GSLB kontrollieren Sie die Standortzuordnung, damit Anfragen nicht dauerhaft an einen Standort geleitet werden. - Firmware, Logs und Kapazität abschließend prüfen
Kontrollieren Sie Load-Balancer-Logs auf Fehler wie SSL-Handshake-Timeouts, Backend Connection Reset oder erschöpfte Ports. Aktualisieren Sie Firmware nur nach Freigabe des Herstellers und mit Wartungsfenster.
Typische Symptome, wahrscheinliche Ursachen und erste Maßnahme
| Symptom | Wahrscheinliche Ursache | Erste Maßnahme |
|---|---|---|
| Ein Backend erhält fast den gesamten Traffic | Sticky Sessions per Quell-IP hinter NAT | Auf Cookie-basierte Persistenz umstellen |
| Backends flapping (up/down/up) | Health-Check-Timeout zu kurz | Timeout und Fehlerschwelle erhöhen |
| HTTP 502 sporadisch | Backend schließt Keep-Alive vor Load Balancer | Keep-Alive-Timeouts angleichen |
| HTTP 503 „no server available | ||
| Alle Backends als ungesund markiert | Health-Check-Pfad oder Port falsch | Prüfpfad und Status-Code korrigieren |
| Nutzer verlieren Sitzung | Persistenz fehlt oder greift nicht | Session-Cookie im Load Balancer setzen |
| Hohe Latenz trotz niedriger CPU | Erschöpfte ephemere Ports | Portbereich und Verbindungslimits erhöhen |
| Traffic umgeht den Load Balancer | Direkte DNS-Auflösung auf Backend | DNS bereinigen, nur VIP veröffentlichen |
So beugen Sie vor
- Kapazitätsreserven einplanen: kein Backend dauerhaft über 60 % Last.
- Health Checks realistisch dimensionieren (Intervall ≥ 5 s, mindestens 2 Fehlversuche).
- Konfigurationsänderungen versionieren und in einer Staging-Umgebung testen.
- Alarmierung auf Verteilungsschieflage einrichten, nicht nur auf reine Verfügbarkeit.
Häufige Fragen
Welcher Lastverteilungsalgorithmus passt zu meiner Anwendung?
Für kurze, gleichartige HTTP-Anfragen funktioniert Round Robin gut. Bei langlebigen Verbindungen, WebSockets oder unterschiedlicher Anfragedauer ist Least Connections meist stabiler. Wenn Clients zwingend am selben Backend bleiben müssen, kombinieren Sie den Algorithmus mit Cookie-basierter Session-Persistenz statt Quell-IP-Hashing.
Warum markiert der Load Balancer gesunde Server als ausgefallen?
Meist sind Health Checks zu aggressiv konfiguriert oder prüfen die falsche URL. Auch Firewall-Regeln zwischen Load Balancer und Backend, TLS-Zertifikatsfehler oder überlastete Anwendungsserver führen zu Fehlalarmen. Erhöhen Sie Intervall und Fehlerschwelle und prüfen Sie den Endpunkt manuell mit curl von der Load-Balancer-IP aus.
Wie erkenne ich, ob das Problem am Load Balancer oder am Backend liegt?
Nehmen Sie einen Backend-Knoten aus der Rotation und rufen Sie ihn direkt über die interne IP auf. Antwortet er korrekt und schnell, liegt das Problem an Verteilung, Health Checks oder Persistenz. Bleiben die Fehler bestehen, ist der Anwendungs- oder Systemzustand des Backends die Ursache.
Lassen Sie Ihre Load-Balancer-Konfiguration von unserem Netzwerk-Team prüfen und Optimierungspotenzial dokumentieren.