Trasferimento tra bucket Cloud Storage

Storage Transfer Service può essere utilizzato per trasferire grandi quantità di dati tra i bucket Cloud Storage, all'interno dello stesso progetto o tra progetti diversi. Google Cloud

Le migrazioni dei bucket sono utili in diversi scenari. Possono essere utilizzati per consolidare i dati di progetti separati, per spostare i dati in una posizione di backup o per modificare la posizione dei dati.

Quando utilizzare Storage Transfer Service

Google Cloud offre diverse opzioni per trasferire i dati tra i bucket Cloud Storage. Ti consigliamo di seguire le seguenti linee guida:

• Trasferimento di meno di 1 TB: utilizza gcloud. Per istruzioni, consulta Spostare e rinominare i bucket.

• Trasferimento di più di 1 TB: utilizza Storage Transfer Service. Storage Transfer Service è un'opzione di trasferimento gestita che offre sicurezza, affidabilità e prestazioni pronte all'uso. Elimina la necessità di ottimizzare e gestire gli script e di gestire i nuovi tentativi.

Questa guida illustra le best practice per il trasferimento dei dati tra i bucket Cloud Storage utilizzando Storage Transfer Service.

Definisci una strategia di trasferimento

L'aspetto della strategia di trasferimento dipende dalla complessità della tua situazione. Assicurati di includere le seguenti considerazioni nel tuo piano.

Scegli un nome per il bucket

Per spostare i dati in un bucket di archiviazione con una località diversa, scegli uno dei seguenti approcci:

• Nuovo nome del bucket. Aggiorna le tue applicazioni in modo che puntino a un bucket di archiviazione con un nome diverso.
• Mantieni il nome del bucket. Sostituisci il bucket di archiviazione per mantenere il nome attuale, in modo da non dover aggiornare le applicazioni.

In entrambi i casi, devi pianificare il tempo di inattività e avvisare gli utenti in modo adeguato che il tempo di inattività è imminente. Esamina le seguenti spiegazioni per capire quale scelta è più adatta alle tue esigenze.

Nuovo nome bucket

Con un nuovo nome bucket, devi aggiornare tutto il codice e i servizi che utilizzano il bucket corrente. La procedura dipende dalla modalità di creazione e deployment delle applicazioni.

Per alcune configurazioni, questo approccio potrebbe comportare meno tempi di inattività, ma richiede più lavoro per garantire una transizione senza problemi. che include i seguenti passaggi:

1. Copia dei dati in un nuovo bucket di archiviazione.
2. Inizio del tempo di riposo.
3. Aggiornamento delle applicazioni in modo che puntino al nuovo bucket.
4. Verificando che tutto funzioni come previsto e che tutti i sistemi e gli account pertinenti abbiano accesso al bucket.
5. Eliminazione del bucket originale.
6. Terminare il tempo di riposo.

Mantieni il nome del bucket

Utilizza questo approccio se preferisci non modificare il codice in modo che rimandi a un nuovo nome del bucket. che include i seguenti passaggi:

1. Copia dei dati in un bucket di archiviazione temporaneo.
2. Inizio del tempo di riposo.
3. Eliminazione del bucket originale.
4. Creazione di un nuovo bucket con lo stesso nome del bucket originale.
5. Copia i dati nel nuovo bucket dal bucket temporaneo.
6. Eliminazione del bucket temporaneo.
7. Verificando che tutto funzioni come previsto e che tutti i sistemi e gli account pertinenti abbiano accesso al bucket.
8. Terminare il tempo di riposo.

Ridurre al minimo i tempi di inattività

Storage Transfer Service non blocca le letture o le scritture nei bucket di origine o di destinazione durante un trasferimento.

Se scegli di bloccare manualmente le letture/scritture nel bucket, puoi ridurre al minimo i tempi di inattività trasferendo i dati in due passaggi: seeding e sincronizzazione.

1. Trasferimento iniziale: esegui un trasferimento collettivo senza bloccare la lettura/scrittura sull'origine.

2. Trasferimento della sincronizzazione: una volta completata la prima esecuzione, blocca la lettura/scrittura nel bucket di origine ed esegui un altro trasferimento. I trasferimenti di Storage Transfer Service sono incrementali per impostazione predefinita, quindi questo secondo trasferimento trasferisce solo i dati modificati durante il trasferimento iniziale.

Ottimizzare la velocità di trasferimento

Quando stimi la durata di un job di trasferimento, considera i possibili colli di bottiglia. Ad esempio, se l'origine contiene miliardi di file di piccole dimensioni, la velocità di trasferimento sarà limitata QPS. Se le dimensioni degli oggetti sono grandi, la larghezza di banda potrebbe essere il collo di bottiglia.

I limiti di larghezza di banda sono impostati a livello di regione e vengono distribuiti equamente tra tutti i progetti. Se è disponibile una larghezza di banda sufficiente, Storage Transfer Service può completare circa 1000 attività al secondo per job di trasferimento. In questo caso, puoi accelerare un trasferimento dividendo il job in più job di trasferimento di piccole dimensioni, ad esempio utilizzando i prefissi di inclusione ed esclusione per trasferire determinati file.

Nei casi in cui la località, la classe di archiviazione e la chiave di crittografia sono le stesse, Storage Transfer Service non crea una nuova copia dei byte, ma una nuova voce di metadati che punta al blob di origine. Di conseguenza, le copie della stessa posizione e della stessa classe di un corpus di grandi dimensioni vengono completate molto rapidamente e sono vincolate solo al QPS.

Anche le eliminazioni sono operazioni solo sui metadati. Per questi trasferimenti, la parallelizzazione del trasferimento suddividendolo in più job di piccole dimensioni può aumentare la velocità.

Conservare i metadati

I seguenti metadati degli oggetti vengono conservati durante il trasferimento dei dati tra bucket Cloud Storage con Storage Transfer Service:

• Metadati personalizzati creati dall'utente.
• Campi dei metadati con chiave fissa di Cloud Storage, come Cache-Control, Content-Disposition, Content-Type e Custom-Time.
• Dimensioni dell'oggetto.
• Il numero di generazione viene conservato come campo di metadati personalizzati con la chiave x-goog-reserved-source-generation, che puoi modificare o rimuovere in un secondo momento.

I seguenti campi di metadati possono essere conservati facoltativamente durante il trasferimento tramite l'API:

• ACL (acl)
• Classe di archiviazione (storageClass)
• CMEK (kmsKey)
• Blocco temporaneo (temporaryHold)
• Data/ora creazione oggetto (customTime)

Per ulteriori dettagli, consulta il riferimento API TransferSpec.

I seguenti campi di metadati non vengono conservati:

• Ultimo aggiornamento (updated)
• etag
• componentCount

Se conservata, l'ora di creazione dell'oggetto viene memorizzata come campo personalizzato, customTime. Il tempo updated dell'oggetto viene reimpostato al momento del trasferimento, quindi viene reimpostato anche il tempo trascorso dall'oggetto nella sua classe di archiviazione. Ciò significa che un oggetto in Coldline Storage, dopo il trasferimento, deve esistere di nuovo per 90 giorni nella destinazione per evitare addebiti per eliminazione anticipata.

Puoi applicare i criteri del ciclo di vita basati su createTime utilizzando customTime. I valori customTime esistenti vengono sovrascritti.

Per maggiori dettagli su cosa viene e cosa non viene conservato, consulta Conservazione dei metadati.

Gestire gli oggetti sottoposti al controllo delle versioni

Se vuoi trasferire tutte le versioni degli oggetti di archiviazione e non solo l'ultima, devi utilizzare l'interfaccia a riga di comando gcloud o l'API REST per trasferire i dati, in combinazione con la funzionalità manifest di Storage Transfer Service.

Per trasferire tutte le versioni dell'oggetto:

1. Elenca gli oggetti del bucket e copiali in un file JSON:

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

   Questo comando in genere elenca circa 1000 oggetti al secondo.

2. Dividi il file JSON in due file CSV, uno con le versioni non correnti e l'altro con le versioni attive:

   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. Attiva il controllo delle versioni degli oggetti nel bucket di destinazione.

4. Trasferisci prima le versioni non attuali passando il file manifest non-current-object-manifest.csv come valore del campo transferManifest.

5. Poi, trasferisci le versioni live allo stesso modo, specificando live-object-manifest.csv come file manifest.

Configurare le opzioni di trasferimento

Ecco alcune delle opzioni a tua disposizione quando configuri il trasferimento:

• Logging: Cloud Logging fornisce log dettagliati dei singoli oggetti, consentendoti di verificare lo stato del trasferimento ed eseguire controlli aggiuntivi dell'integrità dei dati.

• Filtro: puoi utilizzare i prefissi di inclusione ed esclusione per limitare gli oggetti su cui opera Storage Transfer Service. Questa opzione può essere utilizzata per dividere un trasferimento in più job di trasferimento in modo che possano essere eseguiti in parallelo. Per ulteriori informazioni, vedi Ottimizzare la velocità di trasferimento.

• Opzioni di trasferimento: Puoi configurare il trasferimento in modo da sovrascrivere gli elementi esistenti nel bucket di destinazione, eliminare gli oggetti nella destinazione che non esistono nel set di trasferimento o eliminare gli oggetti trasferiti dall'origine.

Trasferire i dati

Dopo aver definito la strategia di trasferimento, puoi eseguire il trasferimento stesso.

Creazione di un nuovo bucket

Prima di iniziare il trasferimento, crea un bucket di archiviazione. Consulta location_considerations per ricevere assistenza nella scelta di una posizione del bucket appropriata.

Quando crei il nuovo bucket, potresti voler copiare alcuni metadati del bucket. Consulta Recuperare i metadati del bucket per scoprire come visualizzare i metadati del bucket di origine, in modo da poter applicare le stesse impostazioni al nuovo bucket.

Copia gli oggetti nel nuovo bucket

Puoi copiare gli oggetti dal bucket di origine a un nuovo bucket utilizzando la consoleGoogle Cloud , l'interfaccia a riga di comandogcloud, l'API REST o le librerie client. L'approccio che scegli dipende dalla tua strategia di trasferimento.

Le seguenti istruzioni riguardano il caso d'uso di base del trasferimento di oggetti da un bucket a un altro e devono essere modificate in base alle tue esigenze.

Non includere informazioni sensibili come quelle che consentono l'identificazione personale (PII) o dati di sicurezza nel nome del job di trasferimento. I nomi delle risorse potrebbero essere propagato ai nomi di altre risorse Google Cloud e potrebbero essere esposti a sistemi interni di Google al di fuori del tuo progetto.

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}")

Verifica gli oggetti copiati

Una volta completato il trasferimento, ti consigliamo di eseguire ulteriori controlli di integrità dei dati.

• Verifica che gli oggetti siano stati copiati correttamente controllando i metadati degli oggetti, ad esempio checksum e dimensioni.

• Verifica che sia stata copiata la versione corretta degli oggetti. Storage Transfer Service offre un'opzione predefinita per verificare che gli oggetti siano copie. Se hai attivato la registrazione, visualizza i log per verificare se tutti gli oggetti sono stati copiati correttamente, inclusi i campi dei metadati corrispondenti.

Inizia a utilizzare il bucket di destinazione

Una volta completata e verificata la migrazione, aggiorna le applicazioni o i carichi di lavoro esistenti in modo che utilizzino il nome del bucket di destinazione. Controlla i log di accesso ai dati in Cloud Audit Logs per assicurarti che le tue operazioni modifichino e leggano correttamente gli oggetti.

Elimina il bucket originale

Dopo che tutto funziona correttamente, elimina il bucket originale.

Storage Transfer Service offre la possibilità di eliminare gli oggetti dopo il trasferimento specificando deleteObjectsFromSourceAfterTransfer: true nella configurazione del job o selezionando l'opzione nella console Google Cloud .

Pianificare l'eliminazione degli oggetti

Per programmare l'eliminazione degli oggetti in un secondo momento, utilizza una combinazione di un job di trasferimento pianificato e dell'opzione deleteObjectsUniqueInSink = true.

Il job di trasferimento deve essere configurato per trasferire un bucket vuoto nel bucket contenente gli oggetti. In questo modo, Storage Transfer Service elenca gli oggetti e inizia a eliminarli. Poiché le eliminazioni sono un'operazione solo sui metadati, il job di trasferimento è vincolato solo alle QPS. Per velocizzare il processo, dividi il trasferimento in più job, ognuno dei quali agisce su un insieme distinto di prefissi.

In alternativa, Google Cloud offre uno scheduler per cron job gestito. Per ulteriori informazioni, vedi Pianificare il job di trasferimento STS di Google Cloud con Cloud Scheduler.