Datenverfügbarkeit und -langlebigkeit

Auf dieser Seite werden Konzepte im Zusammenhang mit der Datenverfügbarkeit und Langlebigkeit in Cloud Storage erläutert. Außerdem wird gezeigt, wie Cloud Storage Daten redundant speichert, und das Standardreplikationsverhalten für Dual-Regionen und Multiregionen sowie das Feature der Turboreplikation für Dual-Regionen erläutert.

Wichtige Konzepte

  • Cloud Storage ist auf eine jährliche Verfügbarkeit von 99,999999999 % ausgelegt. Das sind 11 Neuner.

    • Zu diesem Zweck verwendet Cloud Storage Löschcodierung und speichert Daten redundant auf mehreren Geräten, die sich in mehreren Verfügbarkeitszonen befinden.

    • Cloud Storage speichert Objekte redundant, die in mindestens zwei verschiedenen Verfügbarkeitszonen in es geschrieben werden, bevor der Schreibvorgang als erfolgreich betrachtet wird.

    • Prüfsummen werden gespeichert und regelmäßig neu geprüft, um die Integrität aller ruhenden Daten proaktiv zu verifizieren und eine Beschädigung von Daten bei der Übertragung zu erkennen. Bei Bedarf werden mithilfe der redundanten Daten automatisch Korrekturen vorgenommen.

  • Die monatliche Verfügbarkeit der in Cloud Storage gespeicherten Daten hängt von der Speicherklasse der Daten und dem Standorttyp des Buckets ab. Weitere Informationen finden Sie unter verfügbare Speicherklassen.

  • In einem biregionalen oder multiregionalen Bucket gespeicherte Objekte werden redundant an mindestens zwei separaten geografischen Orten gespeichert.

    • Bei Dual-Regionen wählen Sie die spezifischen Regionen aus, in denen Ihre Objekte gespeichert werden.

    • Bei Multiregionen werden die spezifischen Rechenzentren, die zur Speicherung Ihrer Daten verwendet werden, von Cloud Storage nach Bedarf bestimmt. Sie befinden sich jedoch innerhalb der geografischen Grenze der Multiregion und sind mindestens 100 Meilen voneinander entfernt. Dies bietet Redundanz über Regionen hinweg zu geringeren Speicherkosten als Dual-Regionen.

    • Im unwahrscheinlichen Fall eines Ausfalls in der gesamten Region, beispielsweise durch eine Naturkatastrophe, bleiben biregionale und multiregionale Buckets verfügbar, ohne dass die Speicherpfade geändert werden müssen.

  • Objekte, die in bi- oder multiregionalen Buckets gespeichert sind, werden in der Regel über die Standardreplikation an geografischen Orten repliziert.

    • Wenn einer der Orte, an dem ein Objekt gespeichert ist, nicht mehr verfügbar ist, nachdem das Objekt erfolgreich hochgeladen wurde, aber bevor es an den zweiten Standort repliziert wird, sorgt die strikte Konsistenz von Cloud Storage dafür, dass veraltete Versionen des Objekts nicht bereitgestellt und nachfolgende Überschreibungen nicht rückgängig gemacht werden, wenn die Region wieder verfügbar ist.

    • In Dual-Regionen gespeicherte Objekte können optional die Turboreplikation verwenden, um eine schnellere und vorhersehbare Replikation über Regionen hinweg zu erreichen.

  • Zum Erreichen von Redundanz zwischen einem Regionspaar, das nicht als Dual-Region verfügbar ist, sollten Sie einen separaten Bucket in jeder Region erstellen und ereignisgesteuerte Übertragungen des Storage Transfer Service verwenden, um die Buckets synchron zu halten.

Redundanz über Regionen hinweg

Herkömmliche Speichermodelle verwenden häufig einen Aktiv-Passiv-Ansatz mit "primären" und "sekundären" geografischen Standorten. Cloud Storage bietet jedoch eine Aktiv-Aktiv-Architektur, die auf einem einzelnen Bucket mit regionenübergreifender Redundanz basiert. Dies vereinfacht die Notfallwiederherstellung, da Nutzer keine Daten mehr von einem Bucket in einen anderen Bucket replizieren oder bei einem Ausfall der primären Region manuell einen Failover auf einen sekundären Bucket vornehmen müssen.

Cloud Storage erfasst immer den aktuellen Status eines Buckets und stellt Objekte bei Bedarf transparent aus einer verfügbaren Region bereit. Folglich sind bi- und multiregionale Buckets so konzipiert, dass sie ein Recovery Time Objective (RTO) von null haben und vorübergehende regionale Ausfälle für Nutzer normalerweise nicht sichtbar sind. Im Falle eines regionalen Ausfalls stellen bi- und multiregionale Buckets automatisch weiterhin alle Daten bereit, die über Regionen hinweg repliziert wurden.

Die Redundanz über Regionen hinweg ist jedoch asynchron. Daten, die nicht vollständig regionenübergreifend repliziert wurden, bevor eine Region nicht mehr verfügbar ist, sind erst wieder verfügbar, wenn die ausgefallene Region wieder online ist. Daten können im sehr unwahrscheinlichen Fall einer physischen Zerstörung der Region verloren gehen.

Die Standardreplikation in Cloud Storage ist darauf ausgelegt, eine Redundanz über Regionen hinweg für 99,9% der neu geschriebenen Objekte innerhalb eines Ziels von einer Stunde und 100% der neu geschriebenen Objekte innerhalb eines Ziels von 12 Stunden bereitzustellen. Neu geschriebene Objekte umfassen Uploads, Umschreibungen, Kopien und Zusammensetzungen.

Schnelle Replikation

Die Turboreplikation bietet eine schnellere Redundanz über Regionen hinweg für Daten in Ihren Buckets mit zwei Regionen, was das Risiko eines Datenverlusts verringert und einen unterbrechungsfreien Dienst nach einem regionalen Ausfall unterstützt.

  • Wenn die Turboreplikation aktiviert ist, werden 100% der neu geschriebenen Objekte in beiden Regionen, die die Dual-Region darstellen, innerhalb des Recovery Point Objective von 15 Minuten repliziert, unabhängig von der Objektgröße.

Beachten Sie, dass die meisten Objekte auch bei der Standardreplikation innerhalb von Minuten repliziert werden.

Auch wenn regionenübergreifende Redundanz und Turboreplikation Unterstützung für Geschäftskontinuität und Notfallwiederherstellung (BCDR) bieten, sollten Administratoren eine vollständige BCDR-Architektur planen und implementieren, die für ihre Arbeitslast geeignet ist.

Weitere Informationen finden Sie in der detaillierten Anleitung zur Entwicklung der Notfallwiederherstellung für Anwendungen in Google Cloud.

Beschränkungen

  • Die schnelle Replikation ist nur für Buckets in Dual-Regionen verfügbar.

  • Die Turboreplikation kann nicht über die XML API verwaltet werden. Dies gilt auch für die Erstellung eines neuen Buckets mit aktivierter Turboreplikation.

  • Wenn die Turboreplikation für einen Bucket aktiviert ist, kann es bis zu 10 Sekunden dauern, bis sie für neu geschriebene Objekte gilt.

  • Objektschreibvorgänge, die vor der Aktivierung der Turboreplikation für einen Bucket begonnen haben, werden über Regionen hinweg mit der Standardreplikationsrate repliziert.

    • Eine Objektzusammensetzung, die alle Quellobjekte verwendet, die in den letzten 12 Stunden mit Standardreplikation geschrieben wurden, erstellt ein zusammengesetztes Objekt, das ebenfalls die Standardreplikation verwendet.

Leistungsüberwachung

Cloud Storage überwacht die ältesten nicht replizierten Objekte. Wenn ein Objekt länger als seine RPO-Zeit (Recovery Point Objective) nicht repliziert wird, gilt es als außerhalb des RPO-Werts. Jede Minute, in der ein oder mehrere Objekte außerhalb des RPO-Werts liegen, wird als „schlechte“ Minute gezählt.

Wenn z. B. ein Objekt 20 schlechte Minuten von 9:00-9:20 Uhr und ein anderes Objekt 10 schlechte Minuten von 9:15-9:25 Uhr geliefert hat, dann gibt es zwei Objekte für den Monat, die außerhalb des RPO liegen. Die Gesamtzahl der schlechten Minuten für den Monat beträgt 25 Minuten, da von 9:00 Uhr bis 9:25 Uhr mindestens einem Objekt das RPO fehlte.

  • Bei Buckets mit Turboreplikation beträgt der RPO-Wert für Objekte 15 Minuten.

In der Google Cloud Console können Sie mit dem Diagramm Anzahl der fehlenden Minuten RPO die schlechten Minuten in den letzten 30 Tagen für Ihren Bucket überwachen. Mit diesem Service Level Indicator kann die Konformität der monatlichen Replikationszeit Ihres Buckets überwacht werden. In ähnlicher Weise verfolgt die Grafik Objektreplikationen mit Turbo die Objektreplikationen innerhalb des RPO. Mit diesem Service Level Indicator kann die Konformität des Volumes für die monatliche Replikation des Buckets überwacht werden. Weitere Informationen finden Sie unter Cloud Storage-Monitoring und Cloud Storage SLA.

Nächste Schritte