Zusammenfassung

  • Ein Konfigurationsupdate für das Google Cloud-Netzwerk störte VMware Engine Stretched-Cluster in Sydney, Melbourne und Frankfurt für fast 12 Stunden.
  • Compute- und Speicherressourcen blieben verfügbar, doch ausgefallene Verbindungen zwischen den Cluster-Zonen und der Witness-Instanz isolierten einige virtuelle Maschinen.

Der Sachverhalt

Ein Konfigurationsupdate für das Google Cloud-Netzwerk störte am 14. Juli VMware Engine Stretched-Cluster in Sydney, Melbourne und Frankfurt. Der Vorfall dauerte 11 Stunden und 46 Minuten an. Google stellte den Dienst wieder her, indem die Konfiguration auf den letzten bekannten funktionsfähigen Zustand zurückgesetzt wurde.

Google gab an, dass Compute- und Speicherressourcen offenbar weiterhin verfügbar blieben, jedoch die Kommunikation zwischen den Cluster-Zonen fehlschlug. Die betroffenen Zonen verloren zudem den Kontakt zur Witness-Appliance, was eine sichere Synchronisierung des Cluster-Status verhinderte. Einige virtuelle Maschinen wurden isoliert, wodurch das Risiko bestand, dass sie keinen Zugriff mehr auf schreibbare Daten hatten. Google riet Kunden, den Support zu konsultieren, bevor sie betroffene Workloads auf die funktionsfähige Seite eines Clusters verschieben.

Die Analyse

Der Vorfall betraf Kunden, die Stretched-Cluster nutzen, um die Verfügbarkeit über mehrere Zonen hinweg aufrechterzuerhalten. Compute und Speicher liefen zwar weiter, aber die für die Koordinierung der Cluster erforderlichen Netzwerk- und Witness-Verbindungen fielen aus. Für Enterprise-Cloud- und Business-Continuity-Teams bedeutete dies, dass Workloads zwar aktiv bleiben konnten, während das für die Synchronisierung beider Seiten zuständige System jedoch nicht mehr ordnungsgemäß funktionierte.

VMware Engine Stretched-Cluster verteilen Datenknoten auf zwei Zonen und nutzen eine Witness-Instanz in einer dritten. Als die Kommunikation zwischen ihnen unterbrochen wurde, isolierten sich einige virtuelle Maschinen und liefen Gefahr, den Zugriff auf schreibbare Daten zu verlieren. Google empfahl, betroffene Workloads nach Möglichkeit auf die fehlerfreie Seite zu verschieben, riet Kunden jedoch aufgrund von Failover-Risiken und Unklarheiten über den Zustand der sekundären Zone auch dringend dazu, den Support zu kontaktieren. Die Wiederherstellung hing daher sowohl vom Cluster-Design als auch von Googles betrieblicher Reaktion ab.

Für BTW-Leser zeigt sich, dass die Verteilung von Workloads auf mehrere Zonen die einzelnen Dienstkomponenten nicht völlig unabhängig macht. Kunden sind weiterhin auf das Netzwerk und den Witness-Dienst des Anbieters angewiesen, damit diese Zonen als ein einziger Cluster zusammenarbeiten. Kontinuitätspläne müssen den Ausfall dieses Kommunikationspfads abdecken, einschließlich der Frage, wie Workloads verschoben werden und wann Support des Anbieters erforderlich ist.

Worauf zu achten ist

Zu beobachten sind Googles abschließender Ursachenbericht (Root-Cause-Analyse), Änderungen an den Kontrollen für Netzwerk-Updates sowie etwaige überarbeitete Wiederherstellungsrichtlinien für Ausfälle, die die zonenübergreifende Verbindung oder die Witness-Konnektivität betreffen.