Werden Server für ein Update neu gestartet, ohne die Verbindungen umzuziehen, verlieren alle Spieler auf diesem Server die Verbindung. Speichervorgänge kurz vor dem Herunterfahren und anschließende Reconnects ballen sich.
Warum Server werden für ein Hotfix-Deployment nacheinander neu gestartet → Folge Herunterfahren ohne Umzug der Verbindungen auf andere Server, Speichervorgänge aller Spieler dieses Servers treffen gleichzeitig die DB → Auf dem Bildschirm Verbindungsabbruch ohne Ankündigung, Reconnect-Ansturm
Draining-Funktion (nur neue Verbindungen sperren und warten, bis die vorhandenen Spieler gegangen sind), Charaktere auf andere Server verschieben, Speichern vor dem Herunterfahren zeitlich verteilen, nach dem Neustart erst Cache-Laden und JIT-Warm-up abschließen und dann Bereitschaft melden, bei Hot Reload vorab in einem eigenen Thread einlesen und zwischen zwei Ticks auf einmal austauschen.
Aufgaben Infrastrukturteam
Deployment-Tool wartet pro Maschine das Draining ab und startet dann neu, neu gestartete Server erst nach bestätigter Bereitschaft (Warm-up abgeschlossen) Traffic annehmen lassen, Deployment-Zeitpunkt ankündigen.
Größenordnungen
Bei 5.000 Spielern auf einem Server treffen kurz vor dem Herunterfahren innerhalb weniger Sekunden 5.000 Speichervorgänge auf die DB.
Im Graphen
Verbindungen brechen gleichzeitig ab · Verbindungen pro Server, DB-Schreibvorgänge
Wo nachsehen
Aufzeichnungen des Deployment-Tools (Neustartzeit pro Server) als vertikale Linien (Annotationen) über die Graphen von Verbindungen, Verbindungsabbrüchen, DB-Schreibvorgängen und Login-Anfragen legen
Spricht dafür
Verbindungen pro Server brechen zu den Neustartzeiten nacheinander Server für Server ein, kurz davor schießen die DB-Schreibvorgänge hoch, kurz danach die Login-Anfragen
Spricht dagegen
Zeitpunkt der Abbrüche passt nicht zu den Aufzeichnungen über Deployment und Neustart: eher „Serverabsturz“ oder Netzwerkgeräte
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Auch die ersten Minuten nach dem Neustart sind langsam. Der Cache ist leer, DB-Abfragen häufen sich, und bei Java- oder C#-Servern ist die Optimierung des Codes zur Laufzeit (JIT-Warm-up) noch nicht abgeschlossen, sodass dieselbe Arbeit länger dauert. Auch das Neuladen von Skripten oder Datentabellen ohne Neustart (Hot Reload) hält den Tick während des Einlesens an und verursacht einen kurzen Freeze.
Quellen
Site Reliability Engineering, Chapter 20: Load Balancing in the DatacenterGoogle Ein Server, der SIGTERM erhält, leitet im Lame-Duck-Zustand neue Anfragen an andere Server um und schließt nur laufende Anfragen ab. In den ersten Minuten nach dem Neustart fehlt noch die JIT-Optimierung, er braucht mehr Ressourcen und nimmt deshalb erst nach dem Warm-up Traffic an
Liveness, Readiness, and Startup ProbesKubernetes Readiness-Prüfung: kein Traffic, bis Verbindungsaufbau, Laden von Dateien und Cache-Warm-up abgeschlossen sind