Zusammenfassung

  • Die Cloud-Storage-Vorfälle am 8. und 9. Oktober dauerten in us-central1 und us-central1-b zusammen 18 Stunden und 11 Minuten; die gemeldeten Symptome betrafen vor allem Schreibzugriffe.
  • Google führt den ersten Vorfall auf eine Optimierung zurück, die kapazitätsbewusstes Routing umging, und die Wiederholung auf eine unvollständige Rücknahme; betroffene Kunden oder bezifferte Verluste nennt der Bericht nicht.

Bei einem Cloud-Speicherausfall richtet sich die Aufmerksamkeit oft zuerst darauf, wo Kopien liegen. Googles Bericht lenkt auf eine andere Frage: Über welchen Pfad läuft eine Schreibanfrage, bevor daraus ein gespeichertes Objekt wird? Am 8. Oktober erlebten Cloud-Storage-Kunden in us-central1 zwölf Stunden und 30 Minuten lang höhere Schreiblatenzen und mehr Fehler. Am nächsten Tag kehrte das Problem in der Zone us-central1-b für fünf Stunden und 41 Minuten zurück. Google nennt 18 Stunden und 11 Minuten Gesamtdauer. Es waren jedoch zwei Episoden mit einer Erholung dazwischen, kein durchgehender Ausfall über 18 Stunden.

Die öffentlich beschriebenen Symptome sind eng umrissen. Kunden sahen laut Google vor allem HTTP-503-UNAVAILABLE-Antworten bei WriteObject und clientseitige Zeitüberschreitungen; erfolgreiche Schreibvorgänge dauerten ebenfalls deutlich länger. Der Abschlussbericht sagt, andere Cloud-Storage-Regionen und sonstige Google-Cloud-Dienste seien von diesem konkreten Ereignis nicht betroffen gewesen. Ein früherer vorläufiger Abschnitt erwähnte geringe Auswirkungen auf Lesezugriffe, doch die abschließende Wirkungszusammenfassung beziffert sie nicht.

Damit belegt das Protokoll ein begrenztes Problem im Schreibpfad einer Region und bei der Wiederholung in einer Zone. Es zeigt nicht, dass alle Kunden der Region betroffen waren, sämtliche Schreibvorgänge scheiterten oder gespeicherte Objekte verloren gingen.

Google verortet den ersten Auslöser in einer Konfigurationsänderung zur Sortierung des Datenverkehrs, die lokale Kapazitätsengpässe beheben sollte. Die Optimierung umging die übliche kapazitätsbewusste Routinglogik. Daraufhin erhielt ein kleiner Teil der Backend-Speicherknoten mit wenig freier Leistung einen überproportionalen Anteil der Schreiblast. Die Ressourcen dieser Knoten erschöpften sich; Dienste zur Objektaufnahme liefen in Zeitüberschreitungen; Anfragen an diese Knoten wurden langsam oder schlugen fehl. Zusätzlich verursachte ein separates Datenbankproblem während eines Teils des ersten Zeitfensters weitere Metadatenfehler.

Die Kausalkette ist mehrstufig: Eine Verteilungsentscheidung veränderte den Anfragepfad und konzentrierte Arbeit, während daneben ein Metadatenproblem auftrat.

Die Wiederholung am folgenden Tag ist der betrieblich wichtigste Teil des Berichts. Google führt sie auf eine unvollständige Rücknahme einer Upload-Planer-Funktion zurück, die den Lastenausgleich störte und kleinere Backend-Knoten überlastete. Die erste Abhilfe hatte den vorherigen Sicherheitszustand nicht vollständig wiederhergestellt. Das beweist weder, dass Rücknahmen generell unzuverlässig sind, noch dass ein größerer regionaler Ausfall vorlag.

Es zeigt aber, dass Incident-Abschluss und Konfigurationswiederherstellung zwei verschiedene Prüfungen sind: Ein Dienst kann wieder normal wirken, während eine Reständerung denselben Fehlerpfad offenhält.

Auch der Wiederherstellungsbericht macht eine praktische Grenze sichtbar. Google versuchte zunächst, zusätzliche Notfallkapazität bereitzustellen, doch regionale Kapazitätsgrenzen verhinderten das nach eigener Darstellung. Die Ingenieure zogen den überlasteten Knoten Verkehr ab, deaktivierten oder verwarfen die Optimierung, nahmen ein separates Datenbankupdate zurück und leiteten Anfragen um. Erst als sich Verkehr und Auslastung stabilisiert hatten, wurden die zuvor entlasteten Knoten wieder aktiviert.

Zusätzliche Kapazität ist nicht immer der Notausgang; Routing, Verkehrstrennung und eine verifizierte Rücknahme können die verfügbaren Kontrollen sein, wenn eine Region nicht kurzfristig wachsen kann.

Googles Produktdokumentation hilft bei der Einordnung, ohne Aussagen über den konkreten Kundeneinsatz zu erlauben. Regionale Cloud-Storage-Buckets speichern Daten nach Google-Angaben redundant in mindestens zwei Zonen der ausgewählten Region. Dual- und Multi-Region-Buckets replizieren regionsübergreifend asynchron, nachdem ein Schreibvorgang zunächst in einer Region über zwei Zonen gespeichert wurde. Für diese breiter angelegten Speicherorte beschreibt Google eine automatische Bedienung aus einer anderen Region bei einem regionalen Ausfall und weist zugleich auf die asynchrone Replikation hin.

Die Konsistenzdokumentation sagt, ein erfolgreich geschriebenes Objekt sei sofort lesbar. Sie sagt nicht, welche Bucket-Standorte die betroffenen Kunden nutzten.

Diese Grenze darf nicht verwischt werden. Der Bericht sagt nicht, dass Multi-Region-Replikation versagte, Daten verloren gingen oder geografische Kopien unzugänglich waren. Dokumentiert ist ein Engpass auf dem Pfad, der neue Schreibvorgänge annimmt. Geografische Redundanz kann die Abhängigkeit von einem einzelnen Standort mindern; zusätzlich muss die Architektur aber gemeinsame Software- und Kapazitätskontrollen des Schreibdienstes berücksichtigen. Speicherresilienz ist keine einzelne Eigenschaft: Beständigkeit der Kopien, Schreibannahme, Metadatenverarbeitung, Lesezugriff und Anwendungswiederherstellung haben unterschiedliche Abhängigkeiten.

Googles angekündigte Prävention folgt dieser Kette. Änderungen am Lastenausgleich sollen zunächst in kleineren Regionen geprüft werden, bevor sie in größeren, stark ausgelasteten Regionen ausgerollt werden. Kapazitätsgrenzen sollen so durchgesetzt werden, dass die Verkehrslogik vorbeugende Schutzmechanismen nicht umgehen kann. Außerdem sollen interne Datenbewegungen in stark genutzten Storage-Zellen verbessert werden. Das sind von Google angekündigte künftige Maßnahmen, keine unabhängig bestätigten abgeschlossenen Kontrollen.

Der öffentliche Bericht nennt weder Testergebnisse noch Zahl betroffener Anfragen, Kunden, Bucket-Verteilung oder gemessene Verluste. Die belastbare Aussage ist enger: Eine Routingoptimierung und eine unvollständige Rücknahme konnten eine lokale Kapazitätssicherung zweimal aushebeln; die Frage nach geografischer Redundanz bleibt davon getrennt.

Quellen: Googles Abschlussbericht, Verfügbarkeit und Dauerhaftigkeit von Cloud Storage, Bucket-Standorte, Konsistenz, Wiederholungsstrategie.