Google Cloud: Spannungseinbruch von 3 Millisekunden löst Ausfall von fast 15 Stunden aus

Unternehmen und Produkt

Google Cloud ist die Cloud-Computing-Plattform von Google und stellt Unternehmen weltweit Infrastruktur, Storage, Networking, Datenbanken, Analytics und Managed Application Services zur Verfügung.

Der Incident betraf drei Services, die in der Zone europe-west4-a gehostet werden. Google Cloud VMware Engine bietet verwaltete private VMware-Clouds auf der Infrastruktur von Google Cloud. Bare Metal Solution stellt dedizierte physische Server und Storage für Enterprise-Workloads bereit, die direkten Zugriff auf die Hardware benötigen. Google Cloud NetApp Volumes bietet verwalteten File Storage für Anwendungen mit hohen Anforderungen an Performance und Verfügbarkeit.

Im Gegensatz zu Services, die vollständig auf virtualisierter Infrastruktur laufen, sind diese Produkte stark von physischen Rechenzentrumssystemen abhängig. Dazu gehören die Stromversorgung aus dem Versorgungsnetz, DRUPS-Notstromsysteme, Umschalteinrichtungen, Kaltwasserkühlung, Netzwerk-Switches, Storage-Systeme und physische Server.

Ein Ausfall gemeinsam genutzter Stromversorgungs- oder Kühlinfrastruktur kann daher mehrere Managed Services gleichzeitig beeinträchtigen, auch wenn Google-Cloud-Services in anderen Zonen weiterhin verfügbar sind.

Was war passiert?

Um 16:24 Uhr PDT führte eine Störung im vorgelagerten Stromnetz zu einem drei Millisekunden langen Spannungseinbruch bei den beiden Stromversorgungen A und B.

Beide Schutzschalter lösten aus und leiteten die Umschaltung auf die DRUPS-Notstromversorgung ein. Feed B wurde erfolgreich umgeschaltet, doch das DRUPS von Feed A konnte die Last des Rechenzentrums aufgrund defekter elektrischer Komponenten nicht übernehmen.

Der Ausfall löste eine automatische Umschaltung von drei Reihen von Feed A auf Feed B aus:

• Die Reihen 1 und 2 wurden erfolgreich umgeschaltet.
• Die Umschaltung von Reihe 3 schlug fehl.
• Ein Überlastschutzschalter löste aus.
• Die Stromversorgung von Reihe 3 fiel aus.

Google führte die fehlgeschlagene Umschaltung von Reihe 3 auf eine Abweichung bei der Lastverteilung zurück, deren Ursache zum Zeitpunkt des Abschlussberichts noch untersucht wurde.

Gleichzeitig fiel ein Controller der Kühlanlage aus und gab kein Signal zum Neustart der Kaltwasserverteilungspumpen. Obwohl die Kältemaschinen weiterhin mit Strom versorgt wurden, führte die fehlende Wasserzirkulation zur Abschaltung des Kühlsystems A.

Die redundante Kühlquelle stand aufgrund laufender Bauarbeiten nicht zur Verfügung. Die Temperaturen stiegen, bis in der Data Hall der Grenzwert für einen sicheren Betrieb überschritten wurde.

Google schaltete daraufhin alle erreichbaren Systeme ab, um Schäden an der Hardware zu verhindern. Der lang anhaltende Ausfall war nicht auf die Dauer des ursprünglichen Spannungseinbruchs zurückzuführen, sondern auf das Zusammenspiel von Stromausfall, Ausfall der Kühlung, Notabschaltung und kontrolliertem Neustart.

Timeline

• 15. Juli, 16:24 Uhr PDT: Ein drei Millisekunden langer Spannungseinbruch betrifft beide Stromversorgungen.
• 16:24 Uhr PDT: Das DRUPS von Feed A fällt aus und ein Controller der Kühlanlage geht offline.
• 16:30 Uhr PDT: Das Power Monitoring der VMware Engine löst die erste Alarmierung aus.
• 16:32 Uhr PDT: Das NetApp-Monitoring meldet hohe Temperaturen und Ausfälle von Netzwerk-Switches.
• 16:37 Uhr PDT: Die Reihen 1 und 2 werden auf Feed B umgeschaltet; in Reihe 3 löst ein Schutzschalter aus und die Stromversorgung fällt aus.
• 16:39 Uhr PDT: Erste Auswirkungen auf Nutzer von NetApp Volumes.
• 17:09 Uhr PDT: Erste Auswirkungen auf Nutzer der VMware Engine.
• 17:32 Uhr PDT: Alle sechs betroffenen NetApp-Cluster werden aufgrund hoher Temperaturen heruntergefahren.
• 17:52 Uhr PDT: Das Monitoring der Bare Metal Solution erkennt steigende Temperaturen.
• 18:29 Uhr PDT: Die Temperaturen in der Data Hall erreichen 44 °C.
• 18:37 Uhr PDT: Erste Auswirkungen auf Nutzer der Bare Metal Solution.
• 19:55 Uhr PDT: Die Abschaltung der erreichbaren Server und Netzwerkgeräte ist abgeschlossen.
• 21:05 Uhr PDT: Die Kühlung ist wiederhergestellt und die Temperaturen beginnen sich zu normalisieren.
• 16. Juli, 01:10 Uhr PDT: Ende der Auswirkungen auf NetApp Volumes.
• 02:33 Uhr PDT: Ende der Auswirkungen auf die VMware Engine.
• 07:34 Uhr PDT: Ende der Auswirkungen auf die Bare Metal Solution.

Time to Detect (TTD): Etwa sechs Minuten – von der Störung um 16:24 Uhr PDT bis zur ersten Alarmierung der Stromversorgung um 16:30 Uhr PDT.

Time to Resolve (TTR): 14 Stunden und 55 Minuten für den gesamten Zeitraum mit Auswirkungen auf Kunden.

Wer war betroffen?

• VMware Engine: 24 Private Clouds von 20 Kunden verloren ihre Konnektivität.
• Bare Metal Solution: Neun Kunden verloren den Zugriff auf Server und Storage-Systeme.
• NetApp Volumes: Kunden der Tarife Standard, Premium und Extreme verloren den Zugriff auf ihre Storage Volumes.
• Control-Plane-Nutzer: Das Erstellen von Storage Pools, Volumes und Backups schlug in der betroffenen Region fehl.
• Single-Zone-Deployments: Kunden, die ausschließlich auf europe-west4-a setzten, hatten innerhalb der Zone keine Alternative.
• Multi-Region-Deployments: Google empfahl Kunden, den Traffic an einen anderen Standort umzuleiten.

Google veröffentlichte die Anzahl der betroffenen NetApp Volumes-Kunden nicht.

Wie reagierte Google?

Für Google hatte der Schutz der physischen Infrastruktur und der Kundendaten höchste Priorität.

Als die Temperaturen sichere Grenzwerte überschritten, fuhren die Teams Server, Storage-Systeme, Private Clouds und Netzwerkgeräte herunter. Facility Engineers stellten die Kaltwasserpumpen manuell von Automatik- auf Handbetrieb um und stellten so die Wasserzirkulation wieder her.

Zur Unterstützung der Controller der Kühlanlage wurde vorübergehend eine mobile USV eingesetzt. Nachdem die Stromversorgung aus dem Versorgungsnetz wiederhergestellt war, überprüften Engineers die Remote Power Panels, setzten ausgelöste Schutzschalter zurück und stellten die Stromversorgung der betroffenen Racks wieder her.

Eine zusätzliche DRUPS-Einheit wurde mit Feed A verbunden, um die redundante Notstromkapazität wiederherzustellen, während das ausgefallene DRUPS repariert wurde.

Anschließend stellte Google die Infrastruktur in der Reihenfolge ihrer Abhängigkeiten wieder her:

• Netzwerk und Routing
• Storage-Cluster
• Physische Hosts
• VMware Private Clouds
• Kunden-Workloads
• Überprüfung des Service-Zustands

Google kündigte folgende Maßnahmen mit veröffentlichten Zeitplänen an:

• Untersuchung des DRUPS-Ausfalls von Feed A bis August 2026.
• Behebung des Überlastungsproblems in Reihe 3 bis August 2026.
• Überprüfung der Redundanz der Kühlungssteuerung bis September 2026.
• Einführung schnellerer Alarmierungen für Stromversorgung und Kühlung bis August 2026.
• Verbesserung der automatisierten temperaturbedingten Abschaltung bis Oktober 2026.
• Aktualisierung der BMS-Incident-Klassifizierungen und SLOs bis September 2026.
• Überprüfung der NetApp-Recovery-Runbooks und Einführung monatlicher Tests bis August 2026.

Wie kommunizierte Google?

Google nutzte sein Service Health Dashboard für produktspezifische Updates.

In den ersten Meldungen wurde vor steigenden Temperaturen gewarnt und erklärt, dass Systeme zum Schutz der Infrastruktur gezielt heruntergefahren wurden. Die Updates behandelten VMware Engine, Bare Metal Solution und NetApp Volumes getrennt, sodass Kunden die Wiederherstellung ihrer jeweiligen Services verfolgen konnten.

Google erklärte, dass für Single-Zone-Deployments kein Workaround verfügbar war. Kunden mit Multi-Region-Architekturen wurde empfohlen, den Traffic an einen anderen Standort umzuleiten.
Ein vorläufiger Bericht wurde am 17. Juli veröffentlicht, der Abschlussbericht folgte am 25. Juli.

Wichtige Erkenntnisse für andere Teams

• Gesamte Stromversorgung testen: DRUPS, Schutzschalter, Umschaltungen, Panels und die tatsächlich anliegende Last.
• Bauarbeiten als reduzierte Redundanz behandeln: Zeitweise Wartungs- oder Bauarbeiten erfordern zusätzliche Schutzmaßnahmen oder die Verlagerung von Workloads.
• Kühlung als produktionskritische Infrastruktur überwachen: Controller, Pumpen, Wasserdurchfluss und Temperaturentwicklung benötigen Alarmierungen mit hoher Priorität.
• Automatisches Neustartverhalten überprüfen: Auch mit Strom versorgte Systeme können ausfallen, wenn ihre Steuerungssysteme nicht neu starten.
• Tatsächliche Last auf Reihenebene überwachen: Die Umschaltkapazität muss die reale Belegung widerspiegeln und darf sich nicht nur am geplanten Design orientieren.
• Thermische Eskalation früher erkennen: Frühere Schwellenwerte schaffen mehr Zeit für ein kontrolliertes Herunterfahren.
• Schutzmechanismen für Notfälle automatisieren: Bei schnellen Temperaturänderungen kann eine manuelle Reaktion zu spät kommen.
• Für mehrere Zonen planen: Für kritische Workloads sollte ein getestetes Failover außerhalb eines einzelnen Standorts vorhanden sein.
• In Abhängigkeitsreihenfolge wiederherstellen: Stromversorgung und Kühlung müssen stabil sein, bevor Netzwerk, Storage, Compute und Workloads wiederhergestellt werden.
• Wiederherstellung von Infrastruktur und Services getrennt betrachten: Eine wiederhergestellte Strom- und Kühlversorgung bedeutet nicht automatisch, dass auch die Kundenumgebungen wieder verfügbar sind.

Zusammenfassung

Am 15. Juli 2026 löste ein drei Millisekunden langer Spannungseinbruch einen größeren Ausfall von Google Cloud in europe-west4-a aus. Feed B wurde erfolgreich auf die DRUPS-Notstromversorgung umgeschaltet, während das DRUPS von Feed A aufgrund defekter elektrischer Komponenten ausfiel. Die Reihen 1 und 2 wurden auf Feed B umgeschaltet, doch in Reihe 3 löste ein Überlastschutzschalter aus und die Stromversorgung fiel aus. Google führte dies auf eine Abweichung bei der Lastverteilung zurück, die noch untersucht wurde. Dieselbe Störung setzte einen Controller der Kühlanlage außer Betrieb, sodass die Verteilungspumpen nicht neu starteten, während die redundante Kühlung aufgrund von Bauarbeiten nicht verfügbar war. Die Temperaturen stiegen auf 44 °C und erzwangen die Abschaltung von Servern, Storage-Systemen, Netzwerkkomponenten und Kunden-Workloads. Google stellte die Kühlwasserzirkulation manuell wieder her, reparierte den Stromversorgungspfad, schaltete eine zusätzliche DRUPS-Einheit zu und stellte die Services in der Reihenfolge ihrer Abhängigkeiten wieder her. Insgesamt dauerten die Auswirkungen 14 Stunden und 55 Minuten.

So kann ilert helfen

Incidents in der Rechenzentrumsinfrastruktur erfordern eine enge Koordination zwischen Infrastruktur-, SRE-, Rechenzentrums- und Vendor-Teams.

• Alarmierung bei kritischen Betriebsbedingungen: Signale zu Stromversorgung, DRUPS, Kühlung, Pumpen, Temperaturen und Erreichbarkeit können direkt an ilert weitergeleitet werden.
• Zusammengehörige Alarmierungen gruppieren: Anzeichen für Probleme bei Stromversorgung, Kühlung, Netzwerk, Storage und Services werden in einem Incident zusammengeführt.
• Thermische Notfälle eskalieren: Einsatz von Eskalationsrichtlinien mit hoher Priorität, die Backup-Responder sofort benachrichtigen.
• Teamübergreifende Koordination: Mithilfe von ilert ChatOps können Rechenzentrums-, Netzwerk-, Storage-, Compute-, SRE- und Vendor-Teams in dedizierten Incident-Kanälen zusammengebracht und die Zusammenarbeit in Echtzeit koordiniert werden.
• Kontrollierte Wiederherstellung: Wiederherstellung von Kühlung, Stromversorgung, Netzwerk, Storage, Compute und Workloads in der Reihenfolge ihrer Abhängigkeiten nachverfolgen.
• Regionale Kommunikation: Über die ilert Statusseiten können die betroffenen Zonen gekennzeichnet und verfügbare Failover-Optionen erläutert werden.