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 und die Bucket-übergreifende Replikation 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.

  • Wenn Sie Redundanz zwischen einem Regionspaar erreichen möchten, das nicht als Dual-Region verfügbar ist, sollten Sie einen separaten Bucket in jeder Region erstellen und ereignisgesteuerte Übertragungen oder Bucket-übergreifende Replikation 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 den zwei 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.

Bucket-übergreifende Replikation

In einigen Fällen kann es sinnvoll sein, eine Kopie Ihrer Daten in einem zweiten Bucket zu speichern. Bei der Bucket-übergreifenden Replikation werden neue und aktualisierte Objekte asynchron aus einem Quell-Bucket in einen Ziel-Bucket kopiert.

Die Buckets-übergreifende Replikation unterscheidet sich von der Standard- und der Turbo-Replikation dadurch, dass Ihre Daten in zwei Buckets vorhanden sind, die jeweils eigene Konfigurationen wie Speicherort, Verschlüsselung, Zugriff und Speicherklasse haben. So bietet es nicht nur Datenwiederherstellung und -verfügbarkeit, sondern eignet sich auch für:

  • Datenhoheit: Daten in geografisch entfernten Regionen aufbewahren.
  • Separate Entwicklungs- und Produktionsversionen verwalten: Erstellen Sie separate Buckets und Namespaces, damit sich die Entwicklung nicht auf Ihre Produktionsarbeitslast auswirkt.
  • Daten freigeben: Daten in einem Bucket replizieren, der einem Anbieter oder Partner gehört.
  • Datenaggregation: Daten aus verschiedenen Buckets in einem einzigen Bucket zusammenführen, um Analysearbeitslasten auszuführen.
  • Kosten, Sicherheit und Compliance verwalten: Sie können Ihre Daten mit unterschiedlichen Eigentumsrechten, Speicherklassen und Aufbewahrungsfristen verwalten.

Bei der Bucket-übergreifenden Replikation werden Objekte mit dem Storage Transfer Service repliziert und Pub/Sub wird verwendet, um über Änderungen an den Quell- und Ziel-Buckets benachrichtigt zu werden. Die Bucket-übergreifende Replikation kann für neue und vorhandene Buckets aktiviert werden. Die meisten Objekte können innerhalb weniger Minuten repliziert werden, bei Objekten mit mehr als einem GiB kann es jedoch mehrere Stunden dauern.

Eine Anleitung zur Verwendung der Bucket-übergreifenden Replikation finden Sie unter Bucket-übergreifende Replikation verwenden.

Beschränkungen

  • Das Löschen von Objekten im Quell-Bucket wird nicht in den Ziel-Bucket repliziert.

  • Konfigurationen für den Objektlebenszyklus werden nicht repliziert.

  • Bei der Replikation von Objekten werden Zeitstempelmetadaten (z. B. timeCreated und timeUpdated) nicht beibehalten. Weitere Informationen zur Metadatenaufbewahrung finden Sie unter Übertragungen zwischen Cloud Storage-Buckets.

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.

  • Bei Buckets mit Standardreplikation beträgt der RPO-Wert für Objekte 12 Stunden.

    • Bei Buckets mit Standardreplikation werden Objekte in der Regel innerhalb einer Stunde repliziert.

  • Die bucketübergreifende Replikation bietet kein RPO.

In der Google Cloud Console können Sie mit dem Diagramm Prozentsatz der Minuten außerhalb des RPO den Prozentsatz der 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. Ebenso wird mit dem Messwert Prozentsatz der Objekte außerhalb des Ziels die Anzahl der Objektreplikationen erfasst, die nicht innerhalb des RPO stattgefunden haben. 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