Verschieben von Buckets

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 in asia-east1 befinden, können Sie den Bucket nach us-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:

  • Regionen
  • Dual-Regionen
  • Multiregionen
  • Multiregionen und vordefinierte Dual-Regionen
  • Mehrere Regionen und konfigurierbare duale Regionen, wenn die beiden Standorte unterschiedliche Codes für mehrere Regionen haben

Beim Verschieben eines Buckets zwischen den folgenden Standorten kommt es zu keinen Ausfallzeiten, wenn die beiden Standorte denselben Multiregionencode haben:

  • Konfigurierbare Dual-Regionen
  • Multiregionen und konfigurierbare Dual-Regionen
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ützungBietet 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:

Prozessablauf für das Verschieben von Buckets.
Abbildung 1. Ablauf des Bucket-Umzugs (zum Vergrößern klicken)

* 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
(Optional)

Simuliert den Prozess der Bucket-Migration, um potenzielle Probleme zu identifizieren, bevor die eigentliche Datenübertragung beginnt.

Inkrementelles Kopieren von Daten starten

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:

  • Die Häufigkeit von Objektaktualisierungen, ‑löschungen oder ‑hinzufügungen im Bucket wirkt sich direkt auf die Kopierdauer aus. Eine höhere Änderungsrate erfordert mehr Zeit. Es gibt eine maximale Bewegungsrate für Objekte `Rm`, `objects/second`. Bei `N` Gesamtobjekten und einer Aktualisierungsrate von `R` `objects/second` kann die Dauer des Kopiervorgangs als `N / (Rm - R)` Sekunden geschätzt werden.
  • Für große Buckets ist aufgrund der begrenzten Bandbreite mehr Zeit für die Verlagerung erforderlich.
  • Die Größe der einzelnen Objekte wirkt sich auf die Kopierzeit aus. Die Übertragung von Objekten, die größer als 10 GB sind, dauert aufgrund von Bandbreitenbeschränkungen länger als die Übertragung von Objekten mit weniger als 10 GB. Das Kopieren eines 1-TB-Objekts dauert beispielsweise einen Tag.

Letzten Synchronisierungsschritt starten
(Nur für Umzüge mit Schreibausfallzeit erforderlich)

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:

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
  • ME-CENTRAL1
  • ME-WEST1
Vordefinierte Dual-Regionen
  • EUR5
  • EUR7
  • EUR8

Preise

Weitere Informationen zu den Preisen für die Bucket-Verlagerung finden Sie unter Cloud Storage – Preise.

Nächste Schritte