Datenverfügbarkeit und -langlebigkeit (original) (raw)
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.
- Zu diesem Zweck verwendet Cloud Storage Löschcoding 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 Cloud Storage geschrieben werden, bevor der Schreibvorgang als erfolgreich betrachtet wird.
- Prüfsummen werden gespeichert und regelmäßig überprüft, um die Integrität aller inaktiven 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.
Weitere Informationen zu regionsspezifischen Aspekten finden Sie unter Geografie und Regionen
- 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-Dual-Regionen und ‑Multiregionen bieten 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.
Cloud Storage bietet auch die Möglichkeit zur Bucket-übergreifenden Replikation, mit der Daten zwischen unabhängigen Buckets repliziert werden können, um zusätzliche Anforderungen an die Datenreplikation zu erfüllen, die durch biregionale oder multiregionale Standorte nicht abgedeckt werden.
Turboreplikation
Die Turboreplikation bietet eine schnellere Redundanz über Regionen hinweg für Daten in Ihren biregionalen Buckets, 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 Redundanz über Regionen hinweg 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 Turboreplikation 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 Turboreplikation dadurch, dass Ihre Daten in zwei unabhängigen Buckets vorhanden sind, die jeweils eigene Konfigurationen wie Speicherort, Verschlüsselung, Zugriff und Speicherklasse haben. Sie eignet sich besonders für:
- Datenhoheit: Daten in geografisch entfernten Regionen aufbewahren
- Separate Entwicklungs- und Produktionsversionen verwalten: Separate Buckets und Namespaces verwalten, damit sich die Entwicklung nicht auf Ihre Produktionsarbeitslast auswirkt
- Daten freigeben: Daten in einem Bucket replizieren, der einem Händler oder Partner gehört
- Datenaggregation: Daten aus verschiedenen Buckets in einem einzigen Bucket zusammenführen, um Analysearbeitslasten auszuführen
- Kosten, Sicherheit und Compliance verwalten: Daten mit unterschiedlichen Eigentumsrechten, Speicherklassen und Aufbewahrungsdauern verwalten.
Bei der Bucket-übergreifenden Replikation werden Objekte mit dem Storage Transfer Service repliziert. Pub/Sub wird für Benachrichtigungen über Änderungen an den Quell- und Ziel-Buckets verwendet. Die Bucket-übergreifende Replikation kann für neue und vorhandene Buckets aktiviert werden.
Bei Buckets, in denen die Änderungsrate für Objekte unter 3.000 Objekten pro Sekunde liegt und Objekte unter 1 GiB groß sind, dauert die Bucket-übergreifende Replikation in der Regel einige Minuten bis zu zehn Minuten. Es wird jedoch keine bestimmte Obergrenze unterstützt. Bei Buckets mit höheren Änderungsraten oder größeren Objekten kann es zu längeren Replikationsverzögerungen kommen.
Eine Anleitung zur Verwendung der Bucket-übergreifenden Replikation finden Sie unter Bucket-übergreifende Replikation verwenden.
Beschränkungen
- Die Bucket-übergreifende Replikation wird für Buckets mit hierarchischem Namespace nicht unterstützt.
- 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.
timeCreatedundtimeUpdated) nicht beibehalten. Weitere Informationen zur Metadatenaufbewahrung finden Sie unter [Übertragungen zwischen Cloud Storage-Buckets][22]. - Da die Bucket-übergreifende Replikation verwendet werden kann, um Daten zwischen Buckets an einem beliebigen Google Cloud Standort zu replizieren, variiert die Leistung der Bucket-übergreifenden Replikation je nach den ausgewählten Standorten. Daher bietet die Bucket-übergreifende Replikation kein Recovery Point Objective (RPO).
- Objekte, die sich bereits im Bucket befinden, wenn ein Replikationsjob erstellt wird, werden nicht automatisch repliziert. Es werden nur neue und aktualisierte Objekte repliziert. Wenn Sie vorhandene Objekte replizieren möchten, erstellen Sie einen einmaligen Storage Transfer Service-Übertragungsjob von Ihrem vorhandenen Bucket zum neuen Bucket. Eine Anleitung finden Sie unter Übertragungen erstellen.
Leistungsüberwachung
Cloud Storage überwacht die ältesten nicht replizierten Objekte in biregionalen und multiregionalen Buckets mit Standardreplikation oder Turboreplikation. 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-Werts liegen. Die Gesamtzahl der schlechten Minuten für den Monat beträgt 25 Minuten, da von 9:00 Uhr bis 9:25 Uhr mindestens ein Objekt außerhalb des RPO-Werts lag.
- 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 hat keinen RPO-Wert.
In der Google Cloud Console können Sie mit dem Diagramm Prozentsatz der Minuten außerhalb des RPO-Werts den Prozentsatz der schlechten Minuten in den letzten 30 Tagen für Ihren Bucket überwachen, wenn Sie die Standardreplikation oder die Turboreplikation in biregionalen oder multiregionalen Buckets verwenden. Mit diesem Service Level Indicator kann die Konformität der monatlichen Replikationszeit Ihres Buckets überwacht werden. Der Prozentsatz der Objekte außerhalb des Ziels verfolgt die Objektreplikationen, die nicht innerhalb des RPO-Werts lagen. 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.