Verschieben von Buckets

Auf dieser Seite erhalten Sie einen Überblick über die Verschiebung von Speicherbereichen, ihre Vorteile, Anwendungsfälle, Funktionsweise und Einschränkungen.

Übersicht

Durch die Verschiebung von Cloud Storage-Buckets können Buckets serverlos zwischen geografischen Standorten migriert werden. Mit der Bucket-Verschiebung können Sie Folgendes tun:

  • Verschieben eines vorhandenen Buckets von einem Speicherort an einen anderen, ohne den Namen zu ändern oder eine manuelle Datenübertragung der Daten im Bucket auszuführen.

  • Verbessern Sie Leistung und Kosteneffizienz, indem Sie die Cloud Storage-Konfiguration Ihrer Arbeitslast an die Compute Engine anpassen.

Vorteile

Die Vorteile der Bucket-Verschiebung:

  • Vereinfachte Migration: Sie können Bucket mit minimalem Betriebsaufwand verschieben. Es sind keine komplexen Scripts oder mehrstufigen Prozesse erforderlich.

  • Kontinuierlicher Betrieb: Ihre Anwendungen sind während des gesamten Umstellungsvorgangs verfügbar, ohne Ausfallzeiten für Lesevorgänge und mit minimalen 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. Wenn Sie die Objektmetadaten beibehalten, ist die Kompatibilität mit vorhandenen Anwendungen und Workflows nach dem Verschieben des Buckets gewährleistet.

  • Konfigurationen für Speicherklassen: Sie können vorhandene Einstellungen für Cloud Storage-Klassen verwalten, einschließlich Autoclass. Wenn Sie die Speicherklasse beibehalten, bleibt Ihre Kostenstruktur nach der Verschiebung gleich.

Warum sollten Sie die Bucket-Verschiebung verwenden?

Im Folgenden sind einige Anwendungsfälle für die Verschiebung von Bucket aufgeführt:

  • Kosten für die Datenübertragung senken: Wenn auf Ihre Daten häufig von einem Standort aus zugegriffen wird, der weit von ihrem Speicherort entfernt ist, können Sie Ihren Bucket an einen Ort verschieben, der sich in der Nähe des Standorts befindet, von dem aus auf die Daten zugegriffen wird. Dadurch lassen sich die Kosten für die Datenübertragung senken. Wenn auf Ihre Daten beispielsweise hauptsächlich aus Europa zugegriffen wird, sie aber in den USA gespeichert sind, können Sie Ihren Bucket an einen Standort in Europa verschieben, um die Kosten zu senken.

  • Leistung verbessern: Sie können die Geschwindigkeit und Reaktion Ihrer Anwendung verbessern, indem Sie Ihre Daten näher an die Compute Engine verschieben. Wenn Ihre Anwendung beispielsweise in us-central1 ausgeführt wird, sich Ihre Daten aber in asia-east1 befinden, können Sie den Bucket an us-central1 verschieben, um die Latenz zu verringern.

  • Resilienz verbessern: Sie können Ihre kritischen Daten vor regionalen Ausfällen schützen. Wenn Ihre Daten beispielsweise in einer einzelnen Region gespeichert sind, können Sie sie an Standorte mit zwei oder mehreren Regionen verschieben, um die Verfügbarkeit zu erhöhen und die Notfallwiederherstellung zu verbessern.

Umzugstypen

Ob bei der Verschiebung eines Buckets eine Schreibausfallzeit auftritt, hängt vom Quell- und Zielstandort des Buckets ab. Informationen dazu, wie sich der Standort auf den Umstellungstyp auswirkt, finden Sie unter Umstellungstyp für Bucket ermitteln. Es gibt zwei Arten der Bucket-Verschiebung:

  • Bucket-Verschiebung mit Schreibausfall: Bei der Bucket-Verschiebung mit Schreibausfall können während des Vorgangs keine Objektschreibvorgänge ausgeführt werden.

  • Bucket-Verschiebung ohne Schreibausfallzeit: Bei der Bucket-Verschiebung ohne Schreibausfallzeit können Sie Objektschreibvorgänge ohne Unterbrechung ausführen, während die Bucket-Verschiebung im Hintergrund erfolgt.

In der folgenden Tabelle werden die wichtigen Unterschiede zwischen den Verschiebungstypen mit und ohne Schreibausfall beschrieben:

Spezifikation Bucket-Verschiebung mit Schreibausfallzeit Bucket-Verschiebung ohne Schreibausfallzeiten
Schreibverfügbarkeit Schreibvorgänge können während des letzten Synchronisierungsschritts nicht ausgeführt werden. Keine Unterbrechung von Schreibvorgängen.
Nutzerbeteiligung Der Nutzer muss den Schritt zum Abschluss der Unterbrechung der Schreibvorgänge ausführen. Es ist kein expliziter Abschlussschritt erforderlich.
Auswirkungen auf die Leistung Während des letzten Synchronisierungsschritts können keine Objekte im Bucket geschrieben oder aktualisiert werden. Es besteht die Möglichkeit, dass die Lese- und Schreiblatenz von Objekten während der Verschiebung zunimmt.
Stornierung des Verschiebens von Buckets Schneller als die Verschiebungen ohne Schreibausfallzeit. Die Kündigung erfolgt nicht sofort. Es kann länger dauern, da Objekte ggf. aufgefüllt werden müssen.
Funktionsunterstützung Es werden weniger Funktionen unterstützt als bei Umstellungen ohne Schreibausfallzeiten. Einschränkungen für Funktionen wie mehrteilige Uploads, Speicherungsrichtlinien, Firebase und Appspot Weitere Informationen zu diesen Einschränkungen finden Sie unter Einschränkungen.

Art der Bucket-Verschiebung bestimmen

Der Typ der Verschiebung wird durch die Speicherorte der Quell- und Ziel-Buckets bestimmt.

Wenn Sie einen Bucket zwischen Regionen, biregionalen oder multiregionalen Speicherorten verschieben, kommt es zu einer Ausfallzeit, während der Sie nicht in den Bucket schreiben können. In den folgenden Fällen können Sie einen Bucket jedoch ohne Ausfallzeit verschieben:

  • Verschieben Sie sich von einem multiregionalen zu einem konfigurierbaren biregionalen Speicherort, wenn beide Standorte denselben Multiregional-Code haben.

  • Sie können zwischen konfigurierbaren Dualregionen wechseln, wenn beide Standorte denselben Multiregion-Code haben.

  • Stellen Sie von einem konfigurierbaren biregionalen zu einem multiregionalen Standort um, wenn beide Standorte denselben multiregionalen Code haben.

Informationen zum Verschieben von Buckets

Mit der Bucket-Verschiebung können Sie 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 die Daten verschieben möchten.

Das folgende Diagramm zeigt den Ablauf der Bucket-Verschiebung.

Ablauf des Bucket-Verschiebungsprozesses
Abbildung 1. Ablauf der Bucket-Verschiebung (zum Vergrößern klicken)

Die nummerierten Schritte beziehen sich auf die Zahlen im Diagramm. Das Diagramm zeigt die folgenden Schritte:

  1. Inkrementelle Datenkopie: Bei diesem Schritt werden Daten aus dem Quell-Bucket in den Ziel-Bucket kopiert. Die Bucket-Metadaten sind schreibgeschützt, um Änderungen am Bucket zu verhindern, die sich auf den Verschiebungsprozess auswirken könnten. Sie können jedoch Objekte im Bucket schreiben, ändern und löschen. Die Dauer hängt von folgenden Faktoren ab:

    • Die Häufigkeit von Objektaktualisierungen, ‑löschungen oder ‑ergänzungen im Bucket wirkt sich direkt auf die Kopierdauer aus. Eine höhere Änderungsrate erfordert mehr Zeit. Es gibt eine maximale Objektbewegungsrate von Rm, objects/second. Bei N Objekten insgesamt und einer Aktualisierungsrate von R objects/second kann die Dauer des Kopierschritts auf N / (Rm - R) Sekunden geschätzt werden.

    • Große Bucket erfordern aufgrund der begrenzten Bandbreite mehr Zeit für die Verschiebung.

    • Die Größe der einzelnen Objekte wirkt sich auf die Kopierzeit aus. Die Übertragung von Objekten mit mehr als 10 GB dauert aufgrund von Bandbreiteneinschränkungen länger als die von Objekten mit weniger als 10 GB. Für ein Objekt mit 1 TB dauert die Kopie beispielsweise einen Tag. Wir empfehlen, große Objekte in kleinere Objekte mit einer Größe von 0,1 bis 1 GB aufzuteilen.

    Weitere Informationen zum Initiieren der inkrementellen Datenkopie finden Sie unter Schritt zum Kopieren inkrementeller Daten.

  2. Inkrementelle Datenkopie beobachten: Den Status des Schritts zur inkrementellen Datenkopie können Sie regelmäßig in der Liste der lang andauernden Vorgänge prüfen. Informationen zum Prüfen des Status des Schritts zum Kopieren inkrementeller Daten finden Sie unter Schritt zum Kopieren inkrementeller Daten überwachen.

  3. Endgültige Synchronisierung: Bei Umstellungen mit Schreibausfallzeiten müssen Sie nach Abschluss der inkrementellen Datenkopie den letzten Synchronisierungsschritt auslösen. Während des letzten Synchronisierungsschritts können Sie nicht in den Bucket schreiben, um für Datenkonsistenz zu sorgen. Der letzte Synchronisierungsschritt umfasst die folgenden Aktionen:

    1. Der Bucket ist vorübergehend für Schreibvorgänge gesperrt. In dieser Zeit können Sie keine Objekte im Bucket schreiben oder aktualisieren, sodass Dateninkonsistenzen vermieden werden.

    2. Alle Änderungen, die seit dem Schritt mit der inkrementellen Kopie an den Objektdaten in einem Bucket vorgenommen wurden, werden in den Ziel-Bucket kopiert. So wird sichergestellt, dass der verschobene Bucket die aktuellsten Daten enthält. Nach Abschluss des Objektkopiervorgangs wird ein Vergleich durchgeführt, um die Datenparität zwischen den Quell- und Ziel-Buckets zu gewährleisten. Nach dem Datenabgleich wird der Speicherort des Buckets aktualisiert und alle Anfragen werden an den neuen Speicherort weitergeleitet.

    3. Sobald alle Daten übertragen und überprüft wurden und der Bucket am neuen Speicherort betriebsbereit ist, wird die Schreibsperre entfernt. Sie können dann wieder mit dem Schreiben und Aktualisieren von Objekten im Bucket fortfahren.

    Informationen zum Initiieren des letzten Synchronisierungsschritts finden Sie unter Letzten Synchronisierungsschritt initiieren.

Beschränkungen

Der Dienst zum Verschieben von Buckets unterstützt bis zu fünf gleichzeitige Verschiebungen vom selben Speicherort innerhalb eines Projekts.

In den folgenden Abschnitten werden die Einschränkungen beschrieben, die für Verschiebungen mit und ohne Schreibausfall gelten.

Verschiebung mit Einschränkungen bei der Schreibausfallzeit

Für die Verschiebung mit Schreibausfall gelten die in den folgenden Abschnitten aufgeführten Einschränkungen.

Einschränkungen bei der Datenverarbeitung

Für die Verarbeitung von Daten während der Umstellung gelten die folgenden Einschränkungen:

  • Tabellenfehler: Externe BigLake-Tabellen und BigQuery-Tabellen mit Apache Iceberg funktionieren nicht mehr und müssen manuell neu erstellt werden. Die automatische Erkennung der betroffenen 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-Verschiebungsprozesses wird Autoclass pausiert und Objekte werden nicht in niedrigere Speicherklassen verschoben. Sobald die endgültige Synchronisierung abgeschlossen ist, wird Autoclass fortgesetzt.

    • Objekte in einer Standardspeicherklasse werden so behandelt:

      • Objekte der Standardspeicherklasse können erst nach 30 Tagen ohne Zugriff in eine kältere Klasse wie Nearline Storage umgestellt werden. Wenn ein Objekt in der Standardspeicherklasse während der Umstellung verschoben wird, wird es so behandelt, als ob darauf zugegriffen wurde. Durch den Verschiebevorgang wird die Zeitspanne ohne Zugriff zurückgesetzt. Selbst wenn ein Objekt vor dem Verschieben kurz vor der Umstellung auf Nearline Storage stand, muss nach Abschluss der Verschiebung noch einmal 30 Tage gewartet werden.

    • Objekte in einer nicht standardmäßigen Speicherklasse werden so behandelt:

      • Das Verschieben von Objekten in Nearline Storage, Coldline Storage oder Archive Storage wird nicht als Zugriff auf die Objekte gezählt. Die Sperrfrist für diese Objekte ist davon nicht betroffen.

      • Wenn Sie während der Verschiebung ein Objekt in einem Bucket mit einer nicht standardmäßigen Speicherklasse lesen oder darauf schreiben, wird es nicht automatisch auf eine Speicherklasse mit kürzerer Zugriffszeit wie Standard Storage umgestellt. So lassen sich unnötige Speicherklassenübergänge während des Verschiebungsprozesses vermeiden.

      • Wenn für ein Objekt ein Downgrade auf eine kältere Speicherklasse geplant war, z. B. von Nearline Storage zu Coldline Storage, beeinträchtigt der Umstellungsprozess den Zeitplan nicht. Das Downgrade wird nach Abschluss der Umstellung wie geplant fortgesetzt.

  • Größenlimit für Objekte: Für die Größe von Objekten, die verschoben werden, gilt ein Limit von 2 TB.

Nicht unterstützte Funktionen

Die folgenden Bucket-Typen können nicht verschoben werden:

Operative Einschränkungen

Für die Bucket-Verschiebung mit Schreibausfall gelten die folgenden Betriebseinschrä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 Datenverluste zu vermeiden.
  • Metadatenaktualisierungen: Während der Verschiebung können die Metadaten eines Buckets nicht aktualisiert werden.
  • Anfrageratenerhöhung: Für verschobene Bucket gelten dieselben Richtlinien für die Anfrageratenerhöhung wie für neu erstellte Bucket.

Verschieben ohne Einschränkungen bei Schreibausfallzeiten

Für die Verschiebung von Buckets ohne Schreibausfall gelten die folgenden Einschränkungen:

  • Mehrteilige Uploads: Unvollständige mehrteilige Uploads werden nicht unterstützt und müssen vor dem Verschieben abgeschlossen oder abgebrochen werden. Neue mehrteilige Uploads werden während der Migration blockiert.
  • Aufbewahrungsrichtlinien: Alle Aufbewahrungsrichtlinien müssen vor dem Verschieben entsperrt werden.
  • Firebase- und Appspot-Buckets: Die Verschiebung wird für Buckets, die mit Firebase oder Appspot verknüpft sind, nicht unterstützt.
  • Fortschrittsberichte: Die Berichte zum Fortschritt der Umstellung sind möglicherweise nicht linear.

Nicht unterstützte Region

In der Region me-central1 ist die Bucket-Verschiebung für Quell- oder Ziel-Buckets nicht verfügbar.

Nächste Schritte