Übertragung zwischen Cloud Storage-Buckets

Storage Transfer Service kann zum Übertragen großer Datenmengen zwischen Cloud Storage-Buckets verwendet werden, entweder innerhalb desselben Google Cloud-Projekts oder zwischen verschiedenen Projekten.

Bucket-Migrationen sind in verschiedenen Szenarien hilfreich. Sie können verwendet werden, um Daten aus separaten Projekten zu konsolidieren, Daten an einen Sicherungsspeicherort zu verschieben oder den Speicherort Ihrer Daten zu ändern.

Wann sollte der Storage Transfer Service verwendet werden?

Google Cloud bietet mehrere Optionen, um Daten zwischen Cloud Storage-Buckets zu übertragen. Wir empfehlen folgende Richtlinien:

• Weniger als 1 TB übertragen: Verwenden Sie gcloud. Eine Anleitung dazu finden Sie unter Buckets verschieben und umbenennen.

• Mehr als 1 TB übertragen: Verwenden Sie Storage Transfer Service. Storage Transfer Service ist eine verwaltete Übertragungsoption, die sofort Sicherheit, Zuverlässigkeit und Leistung bietet. Es ist nicht mehr erforderlich, Scripts zu optimieren und zu verwalten und Wiederholungsversuche zu verarbeiten.

In dieser Anleitung werden Best Practices für die Übertragung von Daten zwischen Cloud Storage-Buckets mit dem Storage Transfer Service erläutert.

Übertragungsstrategie definieren

Wie Ihre Übertragungsstrategie aussieht, hängt von der Komplexität Ihrer Situation ab. Berücksichtigen Sie in Ihrem Plan die folgenden Aspekte.

Bucket-Namen auswählen

Wenn Sie Ihre Daten in einen Speicher-Bucket mit einem anderen Speicherort verschieben möchten, haben Sie folgende Möglichkeiten:

• Neuer Bucket-Name Aktualisieren Sie Ihre Anwendungen so, dass sie auf einen Storage-Bucket mit einem anderen Namen verweisen.
• Bucket-Namen beibehalten Ersetzen Sie Ihren Speicher-Bucket, um den aktuellen Namen beizubehalten. Sie müssen Ihre Anwendungen dann nicht aktualisieren.

In beiden Fällen sollten Sie Ausfallzeiten planen und Ihre Nutzer rechtzeitig darüber informieren. In den folgenden Erläuterungen erfahren Sie, welche Option für Sie am besten geeignet ist.

Neuer Bucket-Name

Wenn Sie einen neuen Bucket-Namen verwenden, müssen Sie den gesamten Code und alle Dienste aktualisieren, die Ihren aktuellen Bucket verwenden. Wie Sie dies tun, hängt davon ab, wie Ihre Anwendungen erstellt und bereitgestellt werden.

Bei bestimmten Konfigurationen kann dieser Ansatz zu weniger Ausfallzeiten führen, erfordert aber mehr Aufwand, um einen reibungslosen Übergang zu ermöglichen. Dazu sind folgende Schritte erforderlich:

1. Kopieren Sie Ihre Daten in einen neuen Speicher-Bucket.
2. Ausfallzeit beginnt
3. Aktualisieren Sie Ihre Anwendungen, damit sie auf den neuen Bucket verweisen.
4. Prüfen, ob alles wie erwartet funktioniert und alle relevanten Systeme und Konten Zugriff auf den Bucket haben.
5. Löschen Sie den ursprünglichen Bucket.
6. Beenden Sie die Ausfallzeit.

Bucket-Name beibehalten

Verwenden Sie diesen Ansatz, wenn Sie Ihren Code nicht so ändern möchten, dass er auf einen neuen Bucketnamen verweist. Dazu sind folgende Schritte erforderlich:

1. Daten in einen temporären Speicher-Bucket kopieren
2. Ausfallzeit beginnt
3. Löschen Sie den ursprünglichen Bucket.
4. Erstellen Sie einen neuen Bucket mit demselben Namen wie der ursprüngliche Bucket.
5. Kopieren Sie die Daten aus dem temporären Bucket in den neuen Bucket.
6. Löschen Sie den temporären Bucket.
7. Prüfen, ob alles wie erwartet funktioniert und alle relevanten Systeme und Konten Zugriff auf den Bucket haben.
8. Beenden Sie die Ausfallzeit.

Ausfallzeiten minimieren

Storage Transfer Service sperrt Lese- oder Schreibvorgänge in den Quell- oder Ziel-Buckets während einer Übertragung nicht.

Wenn Sie Lese-/Schreibzugriff auf Ihrem Bucket manuell sperren, können Sie die Ausfallzeit minimieren, indem Sie Ihre Daten in zwei Schritten übertragen: Seed und Synchronisierung.

1. Seed-Übertragung: Führen Sie eine Bulk-Übertragung durch, ohne die Lese-/Schreibvorgänge für die Quelle zu sperren.

2. Synchronisierungsübertragung: Nach Abschluss der ersten Ausführung sperren Sie den Lese-/Schreibvorgang für den Quell-Bucket und führen Sie eine weitere Übertragung durch. Storage Transfer Service-Übertragungen sind standardmäßig inkrementell. Daher werden bei dieser zweiten Übertragung nur Daten übertragen, die sich während der Seed-Übertragung geändert haben.

Übertragungsgeschwindigkeit optimieren

Berücksichtigen Sie bei der Schätzung der Dauer eines Übertragungsjobs die möglichen Engpässe. Wenn die Quelle beispielsweise Milliarden kleiner Dateien enthält, ist die Übertragungsgeschwindigkeit pro Sekunde gebunden. Wenn die Objektgröße groß ist, kann die Bandbreite der Engpass sein.

Bandbreitenlimits werden auf Regionsebene festgelegt und gleichmäßig auf alle Projekte verteilt. Wenn genügend Bandbreite verfügbar ist, kann der Storage Transfer Service etwa 1.000 Aufgaben pro Übertragungsjob pro Sekunde ausführen. Sie können eine Übertragung in diesem Fall beschleunigen. Teilen Sie dazu Ihren Job in mehrere kleine Übertragungsjobs auf. Verwenden Sie beispielsweise einschließende und ausschließende Präfixe, um bestimmte Dateien zu übertragen.

Wenn der Speicherort, die Speicherklasse und der Verschlüsselungsschlüssel identisch sind, erstellt der Storage Transfer Service keine neue Kopie der Byte. Stattdessen wird ein neuer Metadateneintrag erstellt, der auf das Quell-Blob verweist. Daher werden Kopien eines großen Korpus am selben Standort oder derselben Klasse sehr schnell ausgeführt und sind nur pro Sekunde gebunden.

Löschvorgänge sind auch Metadatenvorgänge. Bei diesen Übertragungen kann die Geschwindigkeit durch Parallelisieren der Übertragung durch Aufteilen auf mehrere kleine Jobs erhöht werden.

Metadaten beibehalten

Die folgenden Objektmetadaten bleiben bei der Übertragung von Daten zwischen Cloud Storage-Buckets mit Storage Transfer Service erhalten:

• Vom Nutzer erstellte benutzerdefinierte Metadaten.
• Cloud Storage-Metadatenfelder mit festem Schlüssel, z. B. Cache-Control, Content-Disposition, Content-Type und Custom-Time.
• Objektgröße.
• Die Generierungsnummer wird als benutzerdefiniertes Metadatenfeld mit dem Schlüssel x-goog-reserved-source-generation beibehalten. Sie können sie später bearbeiten oder entfernen.

Die folgenden Metadatenfelder können bei der Übertragung mithilfe der API optional beibehalten werden:

• ACLs (acl)
• Speicherklasse (storageClass)
• CMEK (kmsKey)
• Vorübergehender Hold (temporaryHold)
• Zeitpunkt der Objekterstellung (customTime)

Weitere Informationen finden Sie in der TransferSpec API-Referenz.

Die folgenden Metadatenfelder werden nicht beibehalten:

• Zuletzt aktualisiert (updated)
• etag
• componentCount

Wenn beibehalten, wird der Zeitpunkt der Objekterstellung als benutzerdefiniertes Feld customTime gespeichert. Die updated-Zeit des Objekts wird bei der Übertragung zurückgesetzt. Daher wird auch die Zeit zurückgesetzt, die das Objekt in seiner Speicherklasse verbracht hat. Das bedeutet, dass ein Objekt nach der Übertragung in Coldline Storage 90 Tage lang am Ziel vorhanden sein muss, um Gebühren für vorzeitiges Löschen zu vermeiden.

Sie können Ihre createTime-basierten Lebenszyklusrichtlinien mit customTime anwenden. Vorhandene customTime-Werte werden überschrieben.

Weitere Informationen dazu, was aufbewahrt wird und was nicht, finden Sie unter Metadatenaufbewahrung.

Versionierte Objekte verarbeiten

Wenn Sie alle Versionen Ihrer Speicherobjekte und nicht nur die neueste übertragen möchten, müssen Sie entweder die gcloud CLI oder die REST API in Kombination mit der Manifest-Funktion des Storage Transfer Service verwenden.

So übertragen Sie alle Objektversionen:

1. Listen Sie die Bucket-Objekte auf und kopieren Sie sie in eine JSON-Datei:

   gcloud storage ls --all-versions --recursive --json [SOURCE_BUCKET] > object-listing.json
   

   Dieser Befehl listet in der Regel etwa 1.000 Objekte pro Sekunde auf.

2. Teilen Sie die JSON-Datei in zwei CSV-Dateien auf: eine Datei mit nicht aktuellen Versionen und eine weitere mit den Live-Versionen:

   jq -r '.[] | select( .type=="cloud_object" and (.metadata | has("timeDeleted") | not)) | [.metadata.name, .metadata.generation] | @csv' object-listing.json > live-object-manifest.csv
   jq -r '.[] | select( .type=="cloud_object" and (.metadata | has("timeDeleted"))) | [.metadata.name, .metadata.generation] | @csv' object-listing.json > non-current-object-manifest.csv
   

3. Aktivieren Sie die Objektversionierung für den Ziel-Bucket.

4. Übertragen Sie zuerst die nicht aktuellen Versionen zuerst. Übergeben Sie dazu die Manifestdatei non-current-object-manifest.csv als den Wert des Felds transferManifest.

5. Übertragen Sie dann die Live-Versionen auf die gleiche Weise und geben Sie live-object-manifest.csv als Manifestdatei an.

Übertragungsoptionen konfigurieren

Einige der Optionen, die Ihnen beim Einrichten Ihrer Übertragung zur Verfügung stehen, sind unten aufgeführt.

• Logging: Cloud Logging bietet detaillierte Logs einzelner Objekte, damit Sie den Übertragungsstatus und zusätzliche Datenintegritätsprüfungen prüfen können.

• Filter: Sie können Präfixe zum Einschließen und Ausschließen verwenden, um die Objekte einzuschränken, mit denen Storage Transfer Service arbeitet. Mit dieser Option können Sie eine Übertragung in mehrere Übertragungsjobs aufteilen, damit sie parallel ausgeführt werden können. Weitere Informationen finden Sie unter Übertragungsgeschwindigkeit optimieren.

• Übertragungsoptionen: Sie können Ihre Übertragung so konfigurieren, dass vorhandene Elemente im Ziel-Bucket überschrieben werden, dass Objekte im Zielbereich gelöscht werden, die nicht in der Übertragungsgruppe vorhanden sind, oder dass übertragene Objekte in der Quelle gelöscht werden.

Daten übertragen

Nachdem Sie Ihre Übertragungsstrategie definiert haben, können Sie die Übertragung selbst ausführen.

Neuen Bucket erstellen

Bevor Sie die Übertragung starten, erstellen Sie einen Storage-Bucket. Informationen zur Auswahl eines geeigneten Speicherorts für den Bucket finden Sie unter location_considerations.

Sie können beim Erstellen des neuen Buckets einige Bucket-Metadaten kopieren. Unter Bucket-Metadaten abrufen erfahren Sie, wie Sie die Metadaten des Quell-Buckets anzeigen lassen, damit Sie dieselben Einstellungen auf Ihren neuen Bucket anwenden können.

Objekte in den neuen Bucket kopieren

Sie können Objekte mit der Google Cloud Console, der gcloud CLI, der REST API oder Clientbibliotheken aus dem Quell-Bucket in einen neuen Bucket kopieren. Welchen Ansatz Sie wählen, hängt von Ihrer Übertragungsstrategie ab.

Die folgende Anleitung bezieht sich auf den grundlegenden Anwendungsfall der Übertragung von Objekten von einem Bucket in einen anderen und sollte an Ihre Anforderungen angepasst werden.

Der Name des Übertragungsjobs darf keine vertraulichen Informationen wie personenidentifizierbare Informationen oder Sicherheitsdaten enthalten. Ressourcennamen können an die Namen anderer Google Cloud-Ressourcen weitergegeben und für interne Google-Systeme außerhalb Ihres Projekts freigegeben werden.

gcloud init

gcloud storage buckets add-iam-policy-binding gs://bucket_name \
--member=serviceAccount:project-12345678@storage-transfer-service.iam.gserviceaccount.com \
--role=roles/storage.admin

gcloud transfer jobs create SOURCE DESTINATION

gcloud transfer jobs create gs://old-bucket gs://new-bucket \
  --include-prefixes="folder1/"

POST https://storagetransfer.googleapis.com/v1/transferJobs
{
  "description": "YOUR DESCRIPTION",
  "status": "ENABLED",
  "projectId": "PROJECT_ID",
  "schedule": {
      "scheduleStartDate": {
          "day": 1,
          "month": 1,
          "year": 2025
      },
      "startTimeOfDay": {
          "hours": 1,
          "minutes": 1
      },
      "scheduleEndDate": {
          "day": 1,
          "month": 1,
          "year": 2025
      }
  },
  "transferSpec": {
      "gcsDataSource": {
          "bucketName": "GCS_SOURCE_NAME"
      },
      "gcsDataSink": {
          "bucketName": "GCS_SINK_NAME"
      },
      "transferOptions": {
          "deleteObjectsFromSourceAfterTransfer": true
      }
  }
}

200 OK
{
  "transferJob": [
      {
          "creationTime": "2015-01-01T01:01:00.000000000Z",
          "description": "YOUR DESCRIPTION",
          "name": "transferJobs/JOB_ID",
          "status": "ENABLED",
          "lastModificationTime": "2015-01-01T01:01:00.000000000Z",
          "projectId": "PROJECT_ID",
          "schedule": {
              "scheduleStartDate": {
                  "day": 1,
                  "month": 1,
                  "year": 2015
              },
              "startTimeOfDay": {
                  "hours": 1,
                  "minutes": 1
              }
          },
          "transferSpec": {
              "gcsDataSource": {
                  "bucketName": "GCS_SOURCE_NAME",
              },
              "gcsDataSink": {
                  "bucketName": "GCS_NEARLINE_SINK_NAME"
              },
              "objectConditions": {
                  "minTimeElapsedSinceLastModification": "2592000.000s"
              },
              "transferOptions": {
                  "deleteObjectsFromSourceAfterTransfer": true
              }
          }
      }
  ]
}

import com.google.protobuf.Duration;
import com.google.storagetransfer.v1.proto.StorageTransferServiceClient;
import com.google.storagetransfer.v1.proto.TransferProto.CreateTransferJobRequest;
import com.google.storagetransfer.v1.proto.TransferTypes.GcsData;
import com.google.storagetransfer.v1.proto.TransferTypes.ObjectConditions;
import com.google.storagetransfer.v1.proto.TransferTypes.Schedule;
import com.google.storagetransfer.v1.proto.TransferTypes.TransferJob;
import com.google.storagetransfer.v1.proto.TransferTypes.TransferJob.Status;
import com.google.storagetransfer.v1.proto.TransferTypes.TransferOptions;
import com.google.storagetransfer.v1.proto.TransferTypes.TransferSpec;
import com.google.type.Date;
import com.google.type.TimeOfDay;
import java.io.IOException;
import java.util.Calendar;

public class TransferToNearline {
  /**
   * Creates a one-off transfer job that transfers objects in a standard GCS bucket that are more
   * than 30 days old to a Nearline GCS bucket.
   */
  public static void transferToNearline(
      String projectId,
      String jobDescription,
      String gcsSourceBucket,
      String gcsNearlineSinkBucket,
      long startDateTime)
      throws IOException {

    // Your Google Cloud Project ID
    // String projectId = "your-project-id";

    // A short description of this job
    // String jobDescription = "Sample transfer job of old objects to a Nearline GCS bucket.";

    // The name of the source GCS bucket to transfer data from
    // String gcsSourceBucket = "your-gcs-source-bucket";

    // The name of the Nearline GCS bucket to transfer old objects to
    // String gcsSinkBucket = "your-nearline-gcs-bucket";

    // What day and time in UTC to start the transfer, expressed as an epoch date timestamp.
    // If this is in the past relative to when the job is created, it will run the next day.
    // long startDateTime =
    //     new SimpleDateFormat("yyyy-MM-dd HH:mm:ss").parse("2000-01-01 00:00:00").getTime();

    // Parse epoch timestamp into the model classes
    Calendar startCalendar = Calendar.getInstance();
    startCalendar.setTimeInMillis(startDateTime);
    // Note that this is a Date from the model class package, not a java.util.Date
    Date date =
        Date.newBuilder()
            .setYear(startCalendar.get(Calendar.YEAR))
            .setMonth(startCalendar.get(Calendar.MONTH) + 1)
            .setDay(startCalendar.get(Calendar.DAY_OF_MONTH))
            .build();
    TimeOfDay time =
        TimeOfDay.newBuilder()
            .setHours(startCalendar.get(Calendar.HOUR_OF_DAY))
            .setMinutes(startCalendar.get(Calendar.MINUTE))
            .setSeconds(startCalendar.get(Calendar.SECOND))
            .build();

    TransferJob transferJob =
        TransferJob.newBuilder()
            .setDescription(jobDescription)
            .setProjectId(projectId)
            .setTransferSpec(
                TransferSpec.newBuilder()
                    .setGcsDataSource(GcsData.newBuilder().setBucketName(gcsSourceBucket))
                    .setGcsDataSink(GcsData.newBuilder().setBucketName(gcsNearlineSinkBucket))
                    .setObjectConditions(
                        ObjectConditions.newBuilder()
                            .setMinTimeElapsedSinceLastModification(
                                Duration.newBuilder().setSeconds(2592000 /* 30 days */)))
                    .setTransferOptions(
                        TransferOptions.newBuilder().setDeleteObjectsFromSourceAfterTransfer(true)))
            .setSchedule(Schedule.newBuilder().setScheduleStartDate(date).setStartTimeOfDay(time))
            .setStatus(Status.ENABLED)
            .build();

    // Create a Transfer Service client
    StorageTransferServiceClient storageTransfer = StorageTransferServiceClient.create();

    // Create the transfer job
    TransferJob response =
        storageTransfer.createTransferJob(
            CreateTransferJobRequest.newBuilder().setTransferJob(transferJob).build());

    System.out.println("Created transfer job from standard bucket to Nearline bucket:");
    System.out.println(response.toString());
  }
}

from datetime import datetime

from google.cloud import storage_transfer
from google.protobuf.duration_pb2 import Duration


def create_daily_nearline_30_day_migration(
    project_id: str,
    description: str,
    source_bucket: str,
    sink_bucket: str,
    start_date: datetime,
):
    """Create a daily migration from a GCS bucket to a Nearline GCS bucket
    for objects untouched for 30 days."""

    client = storage_transfer.StorageTransferServiceClient()

    # The ID of the Google Cloud Platform Project that owns the job
    # project_id = 'my-project-id'

    # A useful description for your transfer job
    # description = 'My transfer job'

    # Google Cloud Storage source bucket name
    # source_bucket = 'my-gcs-source-bucket'

    # Google Cloud Storage destination bucket name
    # sink_bucket = 'my-gcs-destination-bucket'

    transfer_job_request = storage_transfer.CreateTransferJobRequest(
        {
            "transfer_job": {
                "project_id": project_id,
                "description": description,
                "status": storage_transfer.TransferJob.Status.ENABLED,
                "schedule": {
                    "schedule_start_date": {
                        "day": start_date.day,
                        "month": start_date.month,
                        "year": start_date.year,
                    }
                },
                "transfer_spec": {
                    "gcs_data_source": {
                        "bucket_name": source_bucket,
                    },
                    "gcs_data_sink": {
                        "bucket_name": sink_bucket,
                    },
                    "object_conditions": {
                        "min_time_elapsed_since_last_modification": Duration(
                            seconds=2592000  # 30 days
                        )
                    },
                    "transfer_options": {
                        "delete_objects_from_source_after_transfer": True
                    },
                },
            }
        }
    )

    result = client.create_transfer_job(transfer_job_request)
    print(f"Created transferJob: {result.name}")

Kopierte Objekte prüfen

Wenn die Übertragung abgeschlossen ist, sollten Sie zusätzliche Datenintegritätsprüfungen durchführen.

• Prüfen Sie, ob die Objekte korrekt kopiert wurden. Prüfen Sie dazu die Metadaten der Objekte wie Prüfsummen und Größe.

• Prüfen Sie, ob die richtige Version der Objekte kopiert wurde. Storage Transfer Service bietet eine sofort einsatzbereite Option, um zu prüfen, ob Objekte Kopien sind. Wenn Sie das Logging aktiviert haben, können Sie anhand der Logs ansehen, ob alle Objekte erfolgreich kopiert wurden und welche Metadatenfelder sie enthalten.

Ziel-Bucket verwenden

Wenn die Migration abgeschlossen und geprüft ist, aktualisieren Sie alle vorhandenen Anwendungen oder Arbeitslasten so, dass sie den Namen des Ziel-Buckets verwenden. Prüfen Sie die Datenzugriffslogs in den Cloud-Audit-Logs, damit Ihre Operationen Objekte korrekt ändern und lesen.

Ursprünglichen Bucket löschen

Wenn alles gut funktioniert, löschen Sie den ursprünglichen Bucket.

Storage Transfer Service bietet die Möglichkeit, Objekte nach der Übertragung zu löschen. Geben Sie dazu in der Jobkonfiguration deleteObjectsFromSourceAfterTransfer: true an oder wählen Sie die Option in der Cloud Console aus.

Löschen von Objekten planen

Wenn Sie das Löschen Ihrer Objekte zu einem späteren Zeitpunkt planen möchten, verwenden Sie eine Kombination aus einem geplanten Übertragungsjob und der Option deleteObjectsUniqueInSink = true.

Der Übertragungsjob sollte so eingerichtet sein, dass ein leerer Bucket in den Bucket mit Ihren Objekten übertragen wird. Dadurch führt der Storage Transfer Service die Objekte auf und beginnt mit dem Löschen. Da Löschvorgänge nur Metadaten sind, ist der Übertragungsjob nur an die Abfragen pro Sekunde gebunden. Um den Prozess zu beschleunigen, teilen Sie die Übertragung in mehrere Jobs auf, die jeweils mit einem bestimmten Satz von Präfixen arbeiten.

Alternativ bietet Google Cloud einen verwalteten Cronjob-Planer. Weitere Informationen finden Sie unter Google Cloud STS-Übertragungsjob mit Cloud Scheduler planen.