In diesem Dokument wird der Cloud Storage-Bucket-Umzugsdienst beschrieben, mit dem Buckets serverlos zwischen geografischen Standorten verschoben werden. Mit der Bucket-Umstellung können Sie einen vorhandenen Bucket von einem Standort zu einem anderen verschieben, ohne seinen Namen zu ändern oder Daten im Bucket manuell übertragen zu müssen.
Basierend auf Ihren Zielen und der Bucket-Nutzung müssen Sie das Verschieben der Buckets sorgfältig planen, um Unterbrechungen zu minimieren und die Buckets erfolgreich zu verschieben. Weitere Informationen zum Verschieben von Buckets finden Sie unter Buckets verschieben.
Vorteile
Vorteile der Bucket-Umstellung:
Vereinfachte Migration: Sie können Buckets mit minimalem Betriebsaufwand verschieben. Es sind keine komplexen Skripts oder mehrstufigen Prozesse erforderlich.
Kontinuierlicher Betrieb: Ihre Anwendungen bleiben während des gesamten Migrationsprozesses zugänglich. Es gibt keine Ausfallzeiten für Lesevorgänge und nur minimale Ausfallzeiten für Schreibvorgänge.
Verbesserte Leistung: Wenn Sie Compute Engine- und Cloud Storage-Ressourcen in derselben Region platzieren, können Sie die Latenz verringern und die Leistung verbessern.
Metadaten beibehalten: Beim Verschieben von Buckets werden die Objektmetadaten beibehalten. Durch das Beibehalten der Objektmetadaten wird die Kompatibilität mit vorhandenen Anwendungen und Workflows nach dem Verschieben des Buckets sichergestellt.
Speicherklassenkonfigurationen: Sie können vorhandene Cloud Storage-Klasseneinstellungen beibehalten, einschließlich Autoclass. Wenn Sie die Speicherklasse beibehalten, bleibt Ihre Kostenstruktur nach der Migration unverändert.
Anwendungsfälle
Im Folgenden finden Sie Anwendungsfälle, die Sie durch das Verschieben Ihrer Buckets erreichen können:
Kosten für die Datenübertragung senken: Vermeiden Sie Kosten für die Datenübertragung, indem Sie Ihren Bucket näher an die Arbeitslasten verlagern, die auf die Daten des Buckets zugreifen. Wenn Ihre Daten beispielsweise in den USA gespeichert und hauptsächlich von Europa aus aufgerufen werden, können Sie Ihren Bucket an einen europäischen Standort verschieben, um die Kosten für die Datenübertragung zu senken.
Leistung verbessern: Sie können die Geschwindigkeit und Reaktionsfähigkeit Ihrer Anwendung verbessern, indem Sie Ihre Daten näher an Ihre Compute Engine-Arbeitslasten verlagern. Wenn Ihre Anwendung beispielsweise in
us-central1
ausgeführt wird, Ihre Daten sich aber inasia-east1
befinden, können Sie den Bucket nachus-central1
verschieben, um die Latenz zu verringern.Resilienz verbessern: Schützen Sie Ihre kritischen Daten vor regionalen Ausfällen. Wenn Ihre Daten beispielsweise in einer einzelnen Region gespeichert sind, können Sie sie für eine höhere Verfügbarkeit und Notfallwiederherstellung in eine Dual-Region oder Multi-Region verschieben.
Umzugstypen
Es gibt zwei Arten von Bucket-Umzügen:
Bucket-Verschiebung mit Schreibausfallzeit: Bei der Bucket-Verschiebung mit Schreibausfallzeit gibt es einen Zeitraum, in dem Sie während des Bucket-Verschiebungsvorgangs keine Schreibvorgänge für Objekte ausführen können.
Bucket-Umzug ohne Schreibausfallzeiten: Bei einem Bucket-Umzug ohne Schreibausfallzeiten können Sie Objekt-Schreibvorgänge ohne Unterbrechung fortsetzen, während der Bucket-Umzug im Hintergrund erfolgt.
Die Quell- und Zielstandorte des Buckets bestimmen, ob bei einer Bucket-Umstellung Schreibausfallzeiten auftreten. In der folgenden Tabelle sehen Sie, wie sich der Standort Ihres Buckets auf die Schreibausfallzeit während einer Verlagerung auswirkt, einschließlich der Unterschiede zwischen Verlagerungen mit und ohne Ausfallzeit.
Spezifikation | Verschieben von Buckets mit Schreibausfallzeit | Verschieben von Buckets ohne Schreibausfallzeiten |
---|---|---|
Bucket-Standort | Das Verschieben eines Buckets zwischen den folgenden Standorten führt zu Ausfallzeiten:
|
Beim Verschieben eines Buckets zwischen den folgenden Standorten kommt es zu keinen Ausfallzeiten, wenn die beiden Standorte denselben Multiregionencode haben:
|
Verfügbarkeit von Schreibvorgängen | Während des letzten Synchronisierungsschritts können keine Schreibvorgänge ausgeführt werden. | Schreibvorgänge werden während der Verlagerung ohne Unterbrechung fortgesetzt. Hinweis: Richtlinienänderungen ohne Schreibausfallzeit dauern mindestens sieben Tage, da sie erst abgeschlossen werden können, wenn alle laufenden fortsetzbaren Uploads abgeschlossen sind. |
Nutzerbeteiligung | Sie müssen den Finalisierungsschritt für die Unterbrechung der Schreibvorgänge initiieren. | Es ist kein expliziter Finalisierungsschritt erforderlich. |
Auswirkungen auf die Leistung | Während des letzten Synchronisierungsschritts können Sie keine Objekte in den Bucket schreiben oder aktualisieren. | Die Latenz beim Lesen und Schreiben von Objekten kann während der Verlagerung zunehmen. |
Verschieben von Buckets abbrechen | Schneller als Umzüge ohne Schreibausfallzeiten. | Die Kündigung erfolgt nicht sofort und kann länger dauern, da Objekte nachgefüllt werden müssen. |
Funktionsunterstützung | Bietet weniger Funktionsunterstützung als Relocations ohne Schreibausfallzeiten. Weitere Informationen zu den nicht unterstützten Funktionen finden Sie unter Nicht unterstützte Funktionen. | Für Funktionen wie mehrteilige Uploads, Aufbewahrungsrichtlinien, Firebase und appspot gelten Einschränkungen. Weitere Informationen zu diesen Einschränkungen finden Sie unter Einschränkungen. |
Mindestdauer des Umzugs | Keine | Sieben Tage |
Verschieben von Buckets
Mit der Bucket-Umstellung können Sie Ihre Daten aus einem Quell-Bucket in einen Ziel-Bucket verschieben. Der Quell-Bucket enthält die Daten, die Sie verschieben möchten, und der Ziel-Bucket ist der Ort, an den Sie Ihre Daten verschieben möchten.
Das folgende Diagramm zeigt den Ablauf des Bucket-Umzugsprozesses:

* Die letzte Synchronisierung ist nur bei Migrationen mit Schreibausfallzeit erforderlich.
In der folgenden Tabelle sind die drei primären Schritte und die Beschreibung für jeden Schritt aufgeführt:
Schritt | Beschreibung |
---|---|
Probelauf durchführen | Simuliert den Prozess der Bucket-Migration, um potenzielle Probleme zu identifizieren, bevor die eigentliche Datenübertragung beginnt. |
Kopiert Daten aus dem Quell-Bucket in den Ziel-Bucket. Die Bucket-Metadaten sind schreibgeschützt, um Änderungen am Bucket zu verhindern, die sich auf den Verlagerungsprozess auswirken könnten. Sie können jedoch Objekte im Bucket schreiben, ändern und löschen. Die Faktoren, die die Dauer beeinflussen, sind:
|
|
Letzten Synchronisierungsschritt starten | Sobald Sie die letzte Synchronisierung starten, wird der Bucket schreibgeschützt. Daher können Sie in diesem Zeitraum keine Objekte in den Bucket schreiben oder aktualisieren, wodurch Dateninkonsistenzen vermieden werden. Sie können jedoch weiterhin aus dem Bucket lesen. Sobald alle Daten übertragen und überprüft wurden und der Bucket am neuen Standort betriebsbereit ist, wird die Schreibsperre automatisch entfernt. Sie können dann wieder Objekte in den Bucket schreiben und aktualisieren. |
Beschränkungen
Der Dienst zur Bucket-Verlagerung unterstützt bis zu fünf gleichzeitige Verlagerungen vom selben Standort innerhalb eines Projekts.
In den folgenden Abschnitten werden die Einschränkungen beschrieben, die für Umzüge mit und ohne Schreibausfallzeit gelten.
Verschieben mit Einschränkungen bei der Schreibausfallzeit
Für die Standortverlagerung mit Schreibausfallzeit gelten die in den folgenden Abschnitten aufgeführten Einschränkungen.
Einschränkungen bei der Datenverarbeitung
Bei der Verarbeitung von Daten während der Migration gelten die folgenden Einschränkungen:
Tabellenfehler: Externe BigLake-Tabellen und BigQuery-Tabellen, die Apache Iceberg verwenden, werden beschädigt und müssen manuell neu erstellt werden. Die automatische Erkennung betroffener Tabellen ist nicht verfügbar.
Autoclass-Objektverwaltung: Autoclass verwendet Zugriffsmuster, um zu bestimmen, wann Objekte in kältere Speicherklassen verschoben werden sollen. Während der finalen Synchronisierung des Bucket-Umzugsprozesses wird Autoclass pausiert und Objekte werden nicht in niedrigere Speicherklassen verschoben. Nach Abschluss der endgültigen Synchronisierung wird die automatische Klassifizierung fortgesetzt.
Objekte in einer Standard-Speicherklasse werden so behandelt:
- Objekte der Speicherklasse „Standard“ müssen 30 Tage lang nicht aufgerufen werden, bevor sie in eine kältere Klasse wie Nearline Storage übertragen werden können. Wenn ein Objekt in der Speicherklasse „Standard“ während der Verlagerung verschoben wird, wird es so behandelt, als ob darauf zugegriffen wurde. Daher wird durch die Verschiebung der Zeitraum ohne Zugriff zurückgesetzt. Selbst wenn ein Objekt vor der Verschiebung kurz vor der Umstellung auf Nearline Storage stand, muss es nach Abschluss der Verschiebung weitere 30 Tage warten.
Objekte in einer anderen Speicherklasse als Standard werden so behandelt:
Das Verschieben von Objekten in den Speicherklassen „Nearline Storage“, „Coldline Storage“ oder „Archive Storage“ gilt nicht als Zugriff. Der Zeitraum ohne Zugriff auf diese Objekte ist davon nicht betroffen.
Wenn Sie einen Bucket verlagern und häufig auf Objekte in Buckets mit einer Nicht-Standard-Speicherklasse wie Nearline Storage, Coldline Storage oder Archive Storage zugreifen, wird der Bucket nicht automatisch in eine wärmere Speicherklasse verschoben. Der Bucket wird beispielsweise nicht automatisch von Archive Storage zu Coldline Storage oder von Coldline Storage zu Standard Storage übertragen, auch wenn häufig auf die Objekte zugegriffen wird. Dieses Verhalten verhindert automatische Übergänge der Speicherklasse während der Verlagerung.
Wenn ein Objekt für die Übertragung in eine niedrigere Speicherklasse geplant war, z. B. von Nearline Storage in Coldline Storage, wird der Zeitplan durch die Verlagerung nicht beeinträchtigt. Die Umstellung erfolgt wie geplant, nachdem der Umzug abgeschlossen ist.
Objektgrößenlimit: Für die Verlagerung gilt ein Limit von 2 TB für Objektgrößen.
Mehrteilige Uploads
Mehrteilige Uploads werden für die Bucket-Verlagerung mit Schreibausfallzeit nicht unterstützt, unabhängig von ihrem Status (abgeschlossen, in Bearbeitung oder während der Verlagerung gestartet). Wenn Sie mehrteilige Uploads in dem Bucket abgeschlossen haben, den Sie verschieben möchten, müssen Sie die Objekte ohne Verwendung von mehrteiligen Methoden noch einmal hochladen und die mehrteiligen Uploads löschen. Andernfalls schlägt die Verschiebung fehl. Wenn Sie Objekte während der Bucket-Umstellung mit Schreibausfall mithilfe von Multipart-Uploads hochladen, tritt ein FAILED_PRECONDITION
-Fehler auf.
Nicht unterstützte Funktionen
Buckets, die die folgenden Funktionen verwenden, können nicht verschoben werden:
Vom Kunden verwaltete Verschlüsselungsschlüssel (CMEK) oder vom Kunden bereitgestellte Verschlüsselungsschlüssel (CSEK).
Gesperrte Aufbewahrungsrichtlinien.
Objekte mit temporären Holds.
Buckets mit aktiviertem hierarchischen Namespace.
Tags Das Hinzufügen von Tags während der Standortverlagerung wird nicht empfohlen, da dies dazu führt, dass die Standortverlagerung fehlschlägt.
Deaktivieren Sie Anywhere Cache. Anywhere Cache kann zwar während des inkrementellen Datenkopierschritts aktiviert werden, verhindert jedoch, dass der abschließende Synchronisierungsschritt abgeschlossen wird.
Appspot-Buckets Als Workaround für Standard-Buckets, die von App Engine erstellt wurden, können Sie Container Registry zu Artifact Registry migrieren.
Firebase-Buckets. Sie können keine mit Firebase verknüpften Buckets verschieben.
Operative Einschränkungen
Für die Bucket-Verlagerung mit Schreibausfallzeit gelten die folgenden betrieblichen Einschränkungen:
Projekteinschränkung: Buckets können nicht projektübergreifend verschoben werden.
Fortsetzbare Uploads: Laufende fortsetzbare Uploads müssen vor dem letzten Synchronisierungsschritt abgeschlossen werden, um Datenverlust zu vermeiden.
Metadatenaktualisierungen: Sie können die Metadaten eines Buckets während der Migration nicht aktualisieren.
Anfrageraten-Ramp-up: Für verschobene Buckets gelten dieselben Richtlinien für das Anfrageraten-Ramp-up wie für neu erstellte Buckets.
Verschieben ohne Einschränkungen bei Schreibausfallzeiten
Für das Verschieben von Buckets ohne Schreibausfallzeit gelten die folgenden Einschränkungen:
Aufbewahrungsrichtlinien: Alle Aufbewahrungsrichtlinien müssen vor der Migration entsperrt werden.
Firebase- und Appspot-Buckets: Die Verschiebung wird für Buckets, die mit Firebase oder Appspot verknüpft sind, nicht unterstützt.
Fortschrittsaktualisierungen: Der Fortschritt der Migration ist möglicherweise nicht linear.
Mehrteilige Uploads: Bei der Bucket-Umstellung werden nur abgeschlossene mehrteilige Uploads unterstützt. Mehrteilige Uploads, die gerade laufen, werden für Objekte während der Bucket-Umstellung nicht unterstützt und müssen vor der Bucket-Umstellung abgeschlossen oder abgebrochen werden. Sie müssen die Objekte noch einmal hochladen, ohne mehrteilige Methoden zu verwenden. Wenn Sie während der Bucket-Umstellung Objekte mit mehrteiligen Uploads hochladen, tritt ein
FAILED_PRECONDITION
-Fehler auf.
Nicht unterstützte Standorte
Das Verschieben von Buckets wird für die Quell- und Ziel-Buckets an den folgenden Standorten nicht unterstützt:
Standorttyp | Nicht unterstützte Standorte |
---|---|
Regionen |
|
Vordefinierte Dual-Regionen |
|
Preise
Weitere Informationen zu den Preisen für die Bucket-Verlagerung finden Sie unter Cloud Storage – Preise.