한국어English日本語简体中文繁體中文DeutschไทยTiếng ViệtРусскийPortuguês (Brasil)EspañolBahasa Indonesia

Game-Lag-Whitepaper › L5 Netzwerkgeräte im Rechenzentrum

Load-Balancer-Schieflast und fehlerhafte Health-Checks LB imbalance, bad health checks

Ursachen-ID dc-lb-imbalance · Hauptzuständig Netzwerk-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)

In der interaktiven Fassung mit Grafiken und Experimenten öffnen →

Verbindungen landen alle auf einem Server, oder Spieler werden weiter zu einem Server geschickt, der längst ausgefallen ist.

Warum Verteilungsregel passt nicht, oder der Health-Check erkennt den tatsächlichen Zustand nicht → Folge Nur ein Server überlastet oder Verbindungsversuche zu einem ausgefallenen Server → Auf dem Bildschirm Nur in einigen Kanälen oder für einige Spieler: Zeitlupe, Kein Login / Endlos-Laden

Symptome
Zeitlupe, Kein Login / Endlos-Laden
Faktoren
Stillstand, Paketverlust
Wer ist betroffen
Bestimmter Ort oder Kanal
Wann
Direkt nach Login oder Wartung, Bei großem Andrang
Zuständigkeit
Hauptzuständig Netzwerk-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
Aufgaben Entwicklungsteam
Health-Check implementieren, der auf Anfragen des Load-Balancers anhand des tatsächlichen Spielzustands antwortet (Tick läuft, DB-Verbindung steht), dabei auch die Serverlast melden.
Aufgaben Infrastrukturteam
Health-Checks auf die Prüfung echter Spielantworten umstellen, lastbasiert verteilen, Unterschiede in der Verbindungszahl pro Server überwachen.
Im Graphen
Nur einzelne Ausreißer · Verbindungen und CPU-Auslastung pro Server
Wo nachsehen
Verbindungen (ss -s) und CPU-Auslastung jedes Servers hinter dem Load-Balancer in einem Graphen übereinanderlegen und den Health-Status der Ziele im Load-Balancer (bei AWS HealthyHostCount und UnHealthyHostCount in CloudWatch) mit dem tatsächlichen Zustand der Spielserver vergleichen
Spricht dafür
Nur ein, zwei Server haben deutlich mehr Verbindungen und CPU-Last als die übrigen, oder ein Server mit stehendem Tick bleibt im Health-Status „healthy“ und nimmt weiter neue Verbindungen an
Spricht dagegen
Verbindungen gleichmäßig verteilt, nur ein Kanal langsam: Last innerhalb dieses Kanals („Überlastetes Gebiet auf einem einzelnen Thread (Hotspot)“)
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Reale Fälle
AWS 2025: AWS us-east-1: DNS-Störung bei DynamoDB und langwierige Wiederherstellung

Quellen

  1. Load Balancing in the Datacenter Google
    Einfaches Round Robin lässt die CPU-Last zwischen Tasks um bis zum Faktor 2 auseinanderklaffen, gewichtete Verteilung, bei der Backends ihre Last in Antworten und Health-Checks mitsenden, Lame-Duck-Zustand, in dem ein Backend keine Anfragen mehr annehmen will
  2. Health checks for Network Load Balancer target groups AWS
    Health-Checks standardmäßig alle 30 s, nach 2 Fehlschlägen wird das Ziel herausgenommen, UDP-Dienste werden per TCP- oder HTTP-Health-Check geprüft, daher wird eine Konfiguration empfohlen, die den tatsächlichen Dienstzustand widerspiegelt
  3. CloudWatch metrics for your Network Load Balancer AWS
    HealthyHostCount, UnHealthyHostCount: Zahl der als gesund bzw. nicht gesund eingestuften Ziele

Verwandte Ursachen

Gleiche Schicht: L5 Netzwerkgeräte im Rechenzentrum

Ursachen aus anderen Schichten mit demselben Symptom (Zeitlupe)

Karte in der interaktiven Fassung mit Grafiken und Experimenten ansehen