In diesem Dokument wird beschrieben, wie Sie mit der Verlagerung von Cloud Storage-Buckets Buckets serverlos zwischen geografischen Standorten verlagern können. Mit dem Verschieben von Buckets können Sie einen vorhandenen Bucket von einem Speicherort zu einem anderen verschieben, ohne dass sich der Name des Buckets ändert oder Daten im Bucket manuell übertragen werden müssen.
Bevor Sie mit der Migration beginnen, planen Sie die Bucketmigration, um Unterbrechungen zu minimieren. Eine Anleitung zum Verschieben von Buckets finden Sie unter Buckets verschieben.
Vorteile
Vorteile des Bucket-Umzugs:
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 aufrechterhalten.
Speicherklassenkonfigurationen: Sie können vorhandene Cloud Storage-Klasseneinstellungen beibehalten, einschließlich Autoclass. Wenn Sie die Speicherklasse beibehalten, bleibt Ihre Kostenstruktur nach der Migration konsistent.
Anwendungsfälle
Im Folgenden finden Sie Anwendungsfälle, die Sie durch das Verschieben Ihrer Buckets erreichen können:
Kosten für die Datenübertragung reduzieren: 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 verschieben. Wenn Ihre Anwendung beispielsweise in
us-central1ausgeführt wird, Ihre Daten sich aber inasia-east1befinden, können Sie den Bucket nachus-central1verschieben, 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-Verschiebungen:
Bucket-Migration mit Schreibausfallzeit: Bei der Bucket-Migration mit Schreibausfallzeit gibt es einen Zeitraum, in dem Sie während des Bucket-Migrationsvorgangs keine Objekt-Schreibvorgänge 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 der Verlagerung eines Buckets Schreibausfallzeiten auftreten. In der folgenden Tabelle sehen Sie, wie sich der Standort Ihres Buckets auf die Schreibausfallzeit während einer Migration auswirkt, einschließlich der Unterschiede zwischen Migrationen mit und ohne Ausfallzeit.
| Spezifikation | Verschieben von Buckets mit Schreibausfall | 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 Sie keine Schreibvorgänge ausführen. | Schreibvorgänge werden während der Migration ohne Unterbrechung fortgesetzt. Hinweis: Richtlinienänderungen ohne Schreibausfallzeit dauern mindestens sieben Tage, da sie erst abgeschlossen werden können, wenn laufende fortsetzbare Uploads abgeschlossen sind. |
| Einbeziehung von Nutzern | 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 abschließenden 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 Umzüge ohne Schreibausfallzeiten. Weitere Informationen zu den nicht unterstützten Funktionen finden Sie unter Nicht unterstützte Funktionen. | Es gibt Einschränkungen für Funktionen wie mehrteilige Uploads, Aufbewahrungsrichtlinien, Firebase und appspot. Weitere Informationen zu diesen Einschränkungen finden Sie unter Einschränkungen. |
| Mindestdauer der Umsiedlung | 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 endgültige Synchronisierung ist nur für 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 Bucket-Migrationsprozess, um potenzielle Probleme zu erkennen, 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 sich auf die Dauer auswirken, sind:
|
|
Endgültige Synchronisierung starten | Sobald Sie die endgültige 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 Bucket-Migrationsdienst unterstützt bis zu fünf gleichzeitige Migrationen vom selben Standort innerhalb eines Projekts.
In den folgenden Abschnitten werden die Einschränkungen beschrieben, die für Migrationen 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 Datenübertragung 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 abschließenden Synchronisierung des Bucket-Verschiebungsvorgangs wird Autoclass pausiert und Objekte werden nicht in niedrigere Speicherklassen verschoben. Nach Abschluss der endgültigen Synchronisierung wird Autoclass 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 Verlagerung der Zeitraum ohne Zugriff zurückgesetzt. Selbst wenn ein Objekt vor der Verlagerung kurz vor der Umstellung auf Nearline Storage stand, muss es nach Abschluss der Verlagerung 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 für diese Objekte ist davon nicht betroffen.
Wenn Sie einen Bucket verschieben 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 nach Abschluss des Umzugs wie geplant.
Limit für Objektgröße: Für die Objektgrößen bei der Verlagerung gilt ein Limit von 2 TB.
Mehrteilige Uploads
Mehrteilige Uploads werden für die Bucket-Umstellung mit Schreibausfallzeit nicht unterstützt, unabhängig von ihrem Status (abgeschlossen, in Bearbeitung oder während der Umstellung gestartet). Wenn Sie mehrteilige Uploads im Bucket abgeschlossen haben, den Sie verschieben möchten, müssen Sie die Objekte ohne Verwendung mehrteiliger Methoden neu hochladen und die mehrteiligen Uploads löschen. Andernfalls schlägt die Verschiebung fehl. Wenn Sie Objekte während der Bucket-Umstellung mit Schreibausfall über 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 Migration wird nicht empfohlen, da dies zu einem Fehler im Migrationsprozess führt.
Anywhere Cache Anywhere Cache kann zwar während der Bucket-Migration aktiviert werden, verhindert aber, dass der Schritt der endgültigen Synchronisierung 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 Buckets verschieben, die mit Firebase verknüpft sind.
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 endgültigen Synchronisierungsschritt abgeschlossen werden, um Datenverluste zu vermeiden.
Metadatenaktualisierungen: Während der Migration können Sie die Metadaten eines Buckets 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 Verlagerung wird für Buckets, die mit Firebase oder Appspot verknüpft sind, nicht unterstützt.
Fortschrittsaktualisierungen: Der Fortschritt bei der Migration ist möglicherweise nicht linear.
Mehrteilige Uploads: Bei der Bucket-Umstellung werden nur abgeschlossene mehrteilige Uploads unterstützt. Laufende mehrteilige Uploads werden für Objekte während der Bucket-Migration nicht unterstützt und müssen vor der Bucket-Migration abgeschlossen oder abgebrochen werden. Sie müssen die Objekte ohne Verwendung von Multipart-Methoden noch einmal hochladen. 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 |
|
Preise
Weitere Informationen zu den Preisen für die Bucket-Verlagerung finden Sie unter Cloud Storage – Preise.
Nächste Schritte
- Bucket-Verschiebung planen
- Informationen zu Buckets verschieben