Wartet der Cloud-Anbieter einen physischen Server (Host), verschiebt er die VMs auf einen anderen Host (Live-Migration) oder hält sie kurz an. Währenddessen steht der ganze Server still, und dauert der Stillstand lange, brechen Verbindungen ab.
Warum Anbieter verschiebt die VM wegen Host-Wartung oder vorhergesagtem Ausfall auf einen anderen Host oder pausiert sie kurz → Folge Während der Verschiebung werden CPU, Arbeitsspeicher und Netzwerk langsamer, am Ende steht die VM kurz komplett still (je nach Anbieter und Verfahren unter 1 s bis etwa 30 s) → Auf dem Bildschirm Alle auf dem Server gleichzeitig im Freeze, danach Zeitraffer und Teleportieren. Dauert der Stillstand länger als das Timeout: massenhaft Verbindungsabbrüche
Timeouts so wählen, dass einige Sekunden Stillstand verkraftet werden, Zahl der nachzuholenden Ticks nach einem Stillstand begrenzen, verstrichene Zeit mit der Monotonic Clock messen, Ablauf festlegen, der bei einer Wartungsankündigung den Spielstand sichert und Spieler auf andere Server verschiebt.
Aufgaben Infrastrukturteam
Wartungsankündigungen abonnieren und alarmieren (Google Cloud maintenance-event, geplante Ereignisse von AWS und AWS Health, Azure Scheduled Events), nach einer Ankündigung den Server vorab zu einer Zeit mit wenigen Spielern austauschen, Wartungszeitpunkt verschieben, sofern der Anbieter das erlaubt (Azure Maintenance Configuration, je nach Typ geplante Ereignisse bei AWS), Wartungsprotokolle mit Störungsberichten abgleichen.
Aufgaben Extern
Beim Cloud-Anbieter Wartungsplan und Auswirkungen erfragen, wiederholte Stillstände derselben Instanz melden.
Größenordnungen
Laut Google ist die Pause bei einer Live-Migration in Compute Engine meist deutlich kürzer als 1 s, dabei kann die Systemuhr um bis zu 5 s vorspringen. Der Metadatenwert maintenance-event ändert sich 60 s vor der Verschiebung (sofern dieser Wert vorher mindestens einmal abgefragt wurde). Bei Azure dauern Wartungen, die keinen Neustart erfordern, fast immer unter 10 s, selten (bei allgemeinen VM-Größen höchstens einmal in 18 Monaten) etwa 30 s, Live-Migrationen meist höchstens 5 s. Azure Scheduled Events kündigt solche Pausen (Freeze) mindestens 15 Minuten vorher an. Fällt die Host-Hardware jedoch plötzlich aus, beginnt die Wiederherstellung sofort und ohne Ankündigung.
Im Graphen
Lücke, dann alles auf einmal · Gesendete und empfangene Pakete des Servers, Tick-Intervall
Wo nachsehen
Zeitpunkt des Stillstands mit den Aufzeichnungen des Anbieters abgleichen. Google Cloud: compute.instances.migrateOnHostMaintenance im Audit-Log, AWS: geplante Ereignisse in describe-instance-status und AWS Health, Azure: Microsoft.Compute/virtualMachines/liveMigration/action im Aktivitätsprotokoll (Activity Log) und der Zeitpunkt, an dem die VM-Verfügbarkeitsmetrik (VmAvailabilityMetric) auf 0 fiel. Auf dem Server prüfen, ob Metriken und Logs während des Stillstands leer sind und die Uhr direkt danach gesprungen ist (Log der Zeitsynchronisation)
Spricht dafür
Der Stillstand des ganzen Servers fällt mit einem vom Anbieter protokollierten Wartungs- oder Migrationszeitpunkt zusammen, und in diesen Sekunden sind alle Metriken und Logs auf dem Server leer
Spricht dagegen
Nicht in den Aufzeichnungen des Anbieters, kurze Stillstände wiederholen sich häufig: „CPU-Steal (virtuelle Maschine)“. Kernel-Log enthält einen NIC-Reset: „Probleme mit NIC-Treiber oder -Firmware“
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
AWS kündigt Wartungen über geplante Ereignisse (Scheduled Events) an. system-reboot bedeutet einen Neustart mit Umzug auf einen neuen Host, system-maintenance bedeutet, dass Netzwerk- oder Stromwartungen kurz Auswirkungen haben können. Selbst wenn der Stillstand nur einige Sekunden dauert, verdoppeln Clients, die in dieser Zeit keine ACKs für an den Server gesendete Pakete erhalten, ihre Wartezeit für Retransmissions immer weiter. Deshalb kann eine TCP-Verbindung auch nach dem Ende des Stillstands noch länger hängen („TCP-RTO und exponentielles Backoff“). Nach dem Aufwachen springt die Uhr, was zu „Sprung der Systemuhr (NTP-Step)“ führen kann, und Health-Checks des Load-Balancers können scheitern, sodass der Server vorübergehend herausgenommen wird. Instanzen, die sich nicht verschieben lassen (etwa Bare-Metal-Instanzen in Google Cloud), werden bei Wartungen gestoppt oder neu gestartet.
Quellen
Live migration process during maintenance eventsGoogle Cloud Die Pause bei einer Live-Migration ist meist deutlich kürzer als 1 s, die Systemuhr springt dabei um bis zu 5 s vor, während der Verschiebung sinkt die Leistung von Disk, CPU, Arbeitsspeicher und Netzwerk kurzzeitig, VMs ohne Live-Migration werden bei Wartungen beendet (Bare-Metal-Instanzen unterstützen sie nicht)
Query metadata server for maintenance event noticesGoogle Cloud Der Metadatenwert maintenance-event ändert sich 60 s vor einer Live-Migration (sofern Live-Migration eingestellt ist und der Wert seit der letzten Wartung mindestens einmal abgefragt wurde)
Scheduled events for Amazon EC2 instancesAWS Arten geplanter Ereignisse (system-reboot: Neustart mit Umzug auf einen neuen Host, system-maintenance: kurze Auswirkungen durch Netzwerk- oder Stromwartung), Benachrichtigung per E-Mail und AWS Health, Abfrage mit describe-instance-status, Zeitpunkt je nach Typ verschiebbar
Maintenance and updatesMicrosoft Azure Wartungen ohne Neustart pausieren fast immer unter 10 s, selten (bei allgemeinen VM-Größen höchstens einmal in 18 Monaten) etwa 30 s, Live-Migration meist höchstens 5 s, nach der Pause automatische Uhrsynchronisation, lange TCP-Verbindungen können abbrechen, oder die Gegenseite sendet Daten an die pausierte VM per exponentiellem Backoff erneut, was die Erholung verzögern kann, Health-Checks des Load-Balancers stufen die VM innerhalb von etwa 10 s als nicht gesund ein, Nachweis über Microsoft.Compute/virtualMachines/liveMigration/action im Aktivitätsprotokoll und die während der Pause auf 0 fallende VmAvailabilityMetric, Wahl des Zeitpunkts per Maintenance Configuration
Scheduled Events for Linux VMs in AzureMicrosoft Azure Freeze (Pause von einigen Sekunden, CPU und Netzwerk können stehen bleiben) wird mindestens 15 Minuten vorher angekündigt, bei Ausfall der Host-Hardware beginnt die Wiederherstellung sofort ohne Vorlaufzeit