Migrazione a Google Cloud: trasferimento dei tuoi set di dati di grandi dimensioni

Last reviewed 2024-11-13 UTC

Per molti clienti, il primo passaggio per adottare un prodotto Google Cloud è importare i dati in Google Cloud. Questo documento esamina questo processo, dalla pianificazione di un trasferimento dati all'utilizzo delle best practice durante l'implementazione di un piano.

Il trasferimento di set di dati di grandi dimensioni richiede la creazione del team giusto, una pianificazione anticipata e il test del piano di trasferimento prima di implementarlo in un ambiente di produzione. Anche se questi passaggi possono richiedere lo stesso tempo del trasferimento stesso, queste preparazioni possono contribuire a ridurre al minimo le interruzioni delle operazioni aziendali durante il trasferimento.

Questo documento fa parte della seguente serie in più parti sulla migrazione a Google Cloud:

Che cos'è il trasferimento di dati?

Ai fini di questo documento, il trasferimento dei dati è il processo di spostamento dei dati senza trasformarli, ad esempio lo spostamento dei file così come sono in oggetti.

Il trasferimento dei dati non è così semplice come sembra

È facile pensare al trasferimento dei dati come a una sessione FTP di grandi dimensioni, in cui inserisci i file da un lato e aspetti che escano dall'altro. Tuttavia, nella maggior parte degli ambienti aziendali, il processo di trasferimento coinvolge molti fattori, tra cui:

  • Elaborare un piano di trasferimento che tenga conto del tempo necessario per le attività amministrative, incluso il tempo necessario per decidere su un'opzione di trasferimento, ottenere le approvazioni e gestire i problemi imprevisti.
  • Coordinare le persone della tua organizzazione, ad esempio il team che esegue il trasferimento, il personale che approva gli strumenti e l'architettura e gli stakeholder aziendali interessati al valore e alle interruzioni che il trasferimento dei dati può comportare.
  • Scegli lo strumento di trasferimento giusto in base alle tue risorse, ai costi, ai tempi e ad altre considerazioni relative al progetto.
  • Superare le sfide relative al trasferimento dei dati, inclusi i problemi di "velocità della luce" (larghezza di banda insufficiente), spostare i set di dati in uso attivo, proteggere e monitorare i dati durante il trasferimento e garantire che i dati vengano trasferiti correttamente.

Lo scopo di questo documento è aiutarti a iniziare un'iniziativa di trasferimento di successo.

Il seguente elenco include risorse per altri tipi di progetti di trasferimento di dati non trattati in questo documento:

Passaggio 1: forma il tuo team

La pianificazione di un trasferimento in genere richiede personale con i seguenti ruoli e responsabilità:

  • Abilitazione delle risorse necessarie per un trasferimento: amministratori di rete, IT e archiviazione, uno sponsor esecutivo e altri consulenti (ad esempio un team degli account Google o partner di integrazione).
  • Approvazione della decisione di trasferimento: proprietari o responsabili dei dati (per le norme interne su chi è autorizzato a trasferire quali dati), consulenti legali (per le normative relative ai dati) e un amministratore della sicurezza (per le norme interne su come viene protetto l'accesso ai dati).
  • Esecuzione del trasferimento: un team lead, un project manager (per eseguire e monitorare il progetto), un team tecnico e la ricezione e la spedizione on-site (per ricevere l'hardware dell'appliance)

È fondamentale identificare chi detiene le responsabilità precedenti per il progetto di trasferimento e includerlo nelle riunioni di pianificazione e decisione, se opportuno. Una scarsa pianificazione organizzativa è spesso la causa di iniziative di trasferimento non riuscite.

Raccogliere i requisiti del progetto e il feedback di questi stakeholder può essere difficile, ma fare un piano e stabilire ruoli e responsabilità chiari paga. Non puoi aspettarti di conoscere tutti i dettagli dei tuoi dati. Formare un team ti consente di comprendere meglio le esigenze dell'attività. È buona pratica identificare potenziali problemi prima di investire tempo, denaro e risorse per completare i trasferimenti.

Passaggio 2: raccolta dei requisiti e delle risorse disponibili

Quando crei un piano di trasferimento, ti consigliamo di raccogliere prima i requisiti per il trasferimento dei dati e poi di decidere un'opzione di trasferimento. Per raccogliere i requisiti, puoi utilizzare la seguente procedura:

  1. Identifica i set di dati che devi spostare.
    • Seleziona strumenti come Data Catalog per organizzare i dati in raggruppamenti logici che vengono spostati e utilizzati insieme.
    • Collabora con i team della tua organizzazione per convalidare o aggiornare questi raggruppamenti.
  2. Identifica i set di dati che puoi spostare.
    • Valuta se fattori normativi, di sicurezza o di altro tipo impediscono il trasferimento di alcuni set di dati.
    • Se devi trasformare alcuni dati prima di spostarli (ad esempio per rimuovere dati sensibili o riorganizzare i dati), valuta la possibilità di utilizzare un prodotto di integrazione dei dati come Dataflow o Cloud Data Fusion, o un prodotto di orchestrazione dei flussi di lavoro come Cloud Composer.
  3. Per i set di dati spostabili, determina dove trasferire ciascun set di dati.
    • Registra l'opzione di archiviazione selezionata per archiviare i dati. In genere, il sistema di archiviazione di destinazione su Google Cloud è Cloud Storage. Anche se hai bisogno di soluzioni più complesse dopo che le tue applicazioni sono in funzione, Cloud Storage è un'opzione di archiviazione scalabile e durevole.
    • Scopri quali criteri di accesso ai dati devono essere mantenuti dopo la migrazione.
    • Determina se devi archiviare questi dati in regioni specifiche.
    • Pianifica come strutturare questi dati nella destinazione. Ad esempio, sarà uguale all'originale o diverso?
    • Determina se devi trasferire i dati su base continuativa.
  4. Per i set di dati spostabili, determina quali risorse sono disponibili per spostarli.
    • Tempo: quando deve essere completato il trasferimento?
    • Costo: qual è il budget disponibile per il team e i costi di trasferimento?
    • Persone: chi è disponibile per eseguire il trasferimento?
    • Larghezza di banda (per i trasferimenti online): quanto della larghezza di banda disponibile per Google Cloud può essere allocata per un trasferimento e per quale periodo di tempo?

Prima di valutare e selezionare le opzioni di trasferimento nella fase successiva della pianificazione, consigliamo di valutare se è possibile migliorare parte del modello IT, ad esempio la governance, l'organizzazione e la sicurezza dei dati.

Il tuo modello di sicurezza

Molti membri del team di trasferimento potrebbero ricevere nuovi ruoli nella tua organizzazione Google Cloud nell'ambito del progetto di trasferimento dei dati. La pianificazione del trasferimento dei dati è un'ottima occasione per rivedere le autorizzazioni Identity and Access Management (IAM) e le best practice per l'utilizzo sicuro di IAM. Questi problemi possono influire sulla modalità di assegnazione dell'accesso allo spazio di archiviazione. Ad esempio, potresti applicare limiti rigorosi all'accesso in scrittura ai dati archiviati per motivi normativi, ma potresti consentire a molti utenti e applicazioni di scrivere dati nel tuo ambiente di test.

La tua organizzazione Google Cloud

La strutturazione dei dati su Google Cloud dipende da come prevedi di utilizzare Google Cloud. L'archiviazione dei dati nello stesso progetto Google Cloud in cui viene eseguita l'applicazione potrebbe funzionare, ma potrebbe non essere ottimale dal punto di vista della gestione. Alcuni sviluppatori potrebbero non disporre del privilegio di visualizzare i dati di produzione. In questo caso, uno sviluppatore potrebbe sviluppare codice su dati di esempio, mentre un account di servizio privilegiato potrebbe accedere ai dati di produzione. Pertanto, ti consigliamo di mantenere l'intero set di dati di produzione in un progetto Google Cloud separato e di utilizzare un account di servizio per consentire l'accesso ai dati da ogni progetto dell'applicazione.

Google Cloud è organizzato in progetti. I progetti possono essere raggruppati in cartelle e le cartelle possono essere raggruppate all'interno della tua organizzazione. I ruoli vengono stabiliti a livello di progetto e le autorizzazioni di accesso vengono aggiunte a questi ruoli a livello di bucket Cloud Storage. Questa struttura è in linea con la struttura delle autorizzazioni di altri provider di oggetti.

Per le best practice per strutturare un'organizzazione Google Cloud, consulta Decidere una gerarchia delle risorse per la zona di destinazione Google Cloud.

Passaggio 3: valuta le opzioni di trasferimento

Per valutare le opzioni di trasferimento dei dati, il team di trasferimento deve prendere in considerazione diversi fattori, tra cui:

  • Costo
  • Tempo di trasferimento
  • Opzioni di trasferimento offline e online
  • Strumenti e tecnologie di trasferimento
  • Sicurezza

Costo

La maggior parte dei costi associati al trasferimento dei dati include quanto segue:

  • Costi di networking
    • L'ingresso a Cloud Storage è gratuito. Tuttavia, se ospiti i tuoi dati su un provider cloud pubblico, devi aspettarti di pagare un addebito per il traffico in uscita e potenzialmente costi di archiviazione (ad esempio operazioni di lettura) per il trasferimento dei dati. Questo addebito si applica ai dati provenienti da Google o da un altro provider cloud.
    • Se i tuoi dati sono ospitati in un data center privato di tua proprietà, potresti anche sostenere costi aggiuntivi per configurare una maggiore larghezza di banda per Google Cloud.
  • Costi di archiviazione e gestione di Cloud Storage durante e dopo il trasferimento dei dati
  • Costi del prodotto (ad esempio, un Transfer Appliance)
  • Costi del personale per la formazione del team e l'acquisizione di assistenza logistica

Tempo di trasferimento

Poche cose nell'informatica mettono in evidenza le limitazioni hardware delle reti come il trasferimento di grandi quantità di dati. Idealmente, puoi trasferire 1 GB in acht secondi su una rete di 1 Gbps. Se aumenti le dimensioni fino a un set di dati enorme (ad es. 100 TB), il tempo di trasferimento è di 12 giorni. Il trasferimento di set di dati enormi può mettere alla prova i limiti della tua infrastruttura e potenzialmente causare problemi alla tua attività.

Quando stimi il tempo necessario per un trasferimento, includi i seguenti fattori nei calcoli:

  • Le dimensioni del set di dati che stai spostando.
  • La larghezza di banda disponibile per il trasferimento.
  • Una certa percentuale di tempo di gestione.
  • L'efficienza della larghezza di banda, che può avere un impatto anche sul tempo di trasferimento.

Potresti non voler trasferire set di dati di grandi dimensioni dalla rete aziendale durante le ore di punta del lavoro. Se il trasferimento sovraccarica la rete, nessun altro potrà completare il lavoro necessario o di importanza fondamentale. Per questo motivo, il team di trasferimento deve prendere in considerazione il fattore tempo.

Dopo che i dati sono stati trasferiti in Cloud Storage, puoi utilizzare una serie di tecnologie per elaborare i nuovi file man mano che arrivano, ad esempio Dataflow.

Aumentare la larghezza di banda della rete

Il modo in cui aumenti la larghezza di banda della rete dipende da come ti colleghi a Google Cloud.

In un trasferimento da cloud a cloud tra Google Cloud e altri fornitori di servizi cloud, Google esegue il provisioning della connessione tra i data center dei fornitori di cloud, senza che tu debba eseguire alcuna configurazione.

Se trasferisci dati tra il tuo data center privato e Google Cloud, esistono diversi approcci, ad esempio:

  • Una connessione a internet pubblica tramite un'API pubblica
  • Peering diretto mediante un'API pubblica
  • Cloud Interconnect utilizzando un'API privata

Quando valuti questi approcci, è utile prendere in considerazione le tue esigenze di connettività a lungo termine. Potresti concludere che i costi di acquisizione della larghezza di banda sono proibitivi solo a scopo di trasferimento, ma se prendi in considerazione l'utilizzo a lungo termine di Google Cloud e le esigenze di rete della tua organizzazione, l'investimento potrebbe essere utile. Per ulteriori informazioni su come collegare le tue reti a Google Cloud, consulta Scegliere un prodotto di connettività di rete.

Se scegli un approccio che prevede il trasferimento di dati tramite internet pubblico, ti consigliamo di verificare con l'amministratore della sicurezza se i criteri della tua azienda vietano questi trasferimenti. Inoltre, controlla se la connessione a internet pubblica viene utilizzata per il traffico di produzione. Infine, tieni presente che i trasferimenti di dati su larga scala potrebbero influire negativamente sul rendimento della tua rete di produzione.

Trasferimento online e offline

Una decisione fondamentale è se utilizzare una procedura offline o online per il trasferimento dei dati. In altre parole, devi scegliere tra il trasferimento tramite una rete, che si tratti di Cloud Interconnect o della rete internet pubblica, o tramite hardware di archiviazione.

Per aiutarti a prendere questa decisione, il seguente grafico mostra anche alcune velocità di trasferimento per varie dimensioni e larghezze di banda dei set di dati. Questi calcoli prevedono un determinato overhead di gestione.

Grafico che mostra la relazione tra dimensioni e velocità di trasferimento.

Come indicato in precedenza, potrebbe essere necessario valutare se il costo per ottenere latenze inferiori per il trasferimento dei dati (ad esempio l'acquisizione della larghezza di banda di rete) è compensato dal valore dell'investimento per la tua organizzazione.

Opzioni disponibili da Google

Google offre diversi strumenti e tecnologie per aiutarti a eseguire un trasferimento di dati.

Scegliere tra le opzioni di trasferimento di Google

La scelta di un'opzione di trasferimento dipende dal caso d'uso, come mostrato nella tabella seguente.

Da dove stai spostando i dati Scenario Prodotti consigliati
Da un altro provider cloud (ad esempio Amazon Web Services o Microsoft Azure) a Google Cloud — Storage Transfer Service
Da Cloud Storage a Cloud Storage (due bucket diversi) — Storage Transfer Service
Dal tuo data center privato a Google Cloud Larghezza di banda sufficiente per rispettare la scadenza del progetto Comando gcloud storage
Dal tuo data center privato a Google Cloud Larghezza di banda sufficiente per rispettare la scadenza del progetto Storage Transfer Service per i dati on-premise
Dal tuo data center privato a Google Cloud Larghezza di banda insufficiente per rispettare la scadenza del progetto Transfer Appliance

Comando gcloud storage per trasferimenti di dimensioni ridotte di dati on-premise

Il comando gcloud storage è lo strumento standard per i trasferimenti di piccole e medie dimensioni su una rete di tipo aziendale, da un data center privato o da un altro cloud provider a Google Cloud. Sebbene gcloud storage supporti il caricamento di oggetti fino al dimensione massima degli oggetti Cloud Storage, i trasferimenti di oggetti di grandi dimensioni hanno maggiori probabilità di riscontrare errori rispetto ai trasferimenti di breve durata. Per ulteriori informazioni sul trasferimento di oggetti di grandi dimensioni in Cloud Storage, consulta Storage Transfer Service per trasferimenti di grandi dimensioni di dati on-premise.

Il comando gcloud storage è particolarmente utile nei seguenti scenari:

  • I trasferimenti devono essere eseguiti in base alle esigenze o durante le sessioni a riga di comando da parte degli utenti.
  • Stai trasferendo solo alcuni file o file molto grandi oppure entrambi.
  • Utilizzi l'output di un programma (output in streaming su Cloud Storage).
  • Devi monitorare una directory con un numero moderato di file e sincronizzare eventuali aggiornamenti con latenze molto basse.

Storage Transfer Service per trasferimenti di grandi quantità di dati on-premise

Come il comando gcloud storage, Storage Transfer Service for On Premises Data consente i trasferimenti dallo spazio di archiviazione NFS (Network File System) a Cloud Storage. Storage Transfer Service for On Premises Data è progettato per trasferimenti su larga scala (fino a petabyte di dati, miliardi di file). supporta copie complete o incrementali e funziona con tutte le opzioni di trasferimento elencate in precedenza in Scegliere tra le opzioni di trasferimento di Google. Ha anche un'interfaccia utente grafica gestita; anche gli utenti meno esperti di tecnologia (dopo la configurazione) possono utilizzarla per spostare i dati.

Storage Transfer Service for On Premises Data è particolarmente utile nei seguenti scenari:

  • Disponi di larghezza di banda sufficiente per spostare i volumi di dati.
  • Supporti una vasta base di utenti interni che potrebbero trovare difficile utilizzare uno strumento a riga di comando.
  • Hai bisogno di un sistema di generazione di report sugli errori affidabile e di un record di tutti i file e gli oggetti trasferiti.
  • Devi limitare l'impatto dei trasferimenti su altri workload nel tuo data center (questo prodotto può rimanere al di sotto di un limite di larghezza di banda specificato dall'utente).
  • Vuoi eseguire trasferimenti ricorrenti in base a una pianificazione.

Per configurare Storage Transfer Service for On Premises Data, installa il software on-premise (chiamato agenti) sui computer del tuo data center.

Dopo aver configurato Storage Transfer Service, puoi avviare i trasferimenti nella console Google Cloud specificando una directory di origine, un bucket di destinazione e un orario o una pianificazione. Storage Transfer Service esegue la scansione ricorsiva delle sottodirectory e dei file nella directory di origine e crea oggetti con un nome corrispondente in Cloud Storage (l'oggetto /dir/foo/file.txt diventa un oggetto nel bucket di destinazione denominato /dir/foo/file.txt). Storage Transfer Service tenta nuovamente automaticamente un trasferimento quando rileva errori temporanei. Mentre i trasferimenti sono in esecuzione, puoi monitorare il numero di file spostati e la velocità di trasferimento complessiva, nonché visualizzare i campioni di errore.

Quando Storage Transfer Service completa un trasferimento, genera un file delimitato da tabule (TSV) con un record completo di tutti i file interessati e gli eventuali messaggi di errore ricevuti. Gli agenti sono fault tolerant, quindi se un agente si arresta in modo anomalo, il trasferimento prosegue con gli agenti rimanenti. Gli agenti sono inoltre in grado di aggiornarsi autonomamente e di eseguire il ripristino automatico, quindi non devi preoccuparti di applicare le patch alle versioni più recenti o di riavviare il processo se si arresta in modo anomalo a causa di un problema imprevisto.

Aspetti da considerare quando utilizzi Storage Transfer Service:

  • Utilizza una configurazione dell'agente identica su ogni macchina. Tutti gli agenti devono vedere gli stessi mount NFS (Network File System) nello stesso modo (stesse vie relative). Questa configurazione è un requisito per il funzionamento del prodotto.
  • Più agenti significa maggiore velocità. Poiché i trasferimenti vengono paralleizzati automaticamente su tutti gli agenti, ti consigliamo di implementare molti agenti in modo da utilizzare la larghezza di banda disponibile.
  • I limiti di larghezza di banda possono proteggere i tuoi carichi di lavoro. Gli altri tuoi carichi di lavoro potrebbero utilizzare la larghezza di banda del data center, quindi imposta un limite di larghezza di banda per evitare che i trasferimenti influiscano sui tuoi SLA.
  • Pianifica il tempo per esaminare gli errori. I trasferimenti di grandi dimensioni possono spesso comportare errori che richiedono la revisione. Storage Transfer Service ti consente di visualizzare un esempio degli errori riscontrati direttamente nella console Google Cloud. Se necessario, puoi caricare in BigQuery il record completo di tutti gli errori di trasferimento per controllare i file o valutare gli errori che sono rimasti anche dopo i tentativi di ripetizione. Questi errori potrebbero essere causati dall'esecuzione di app che stavano scrivendo all'origine durante la transazione oppure potrebbero indicare un problema che richiede la risoluzione dei problemi (ad es. un errore di autorizzazione).
  • Configura Cloud Monitoring per i trasferimenti di lunga durata. Storage Transfer Service consente a Monitoring di monitorare l'integrità e il throughput degli agenti, in modo da poter impostare avvisi che ti inviano una notifica quando gli agenti non sono attivi o richiedono attenzione. È importante intervenire in caso di errori dell'agente per i trasferimenti che richiedono diversi giorni o settimane, in modo da evitare rallentamenti o interruzioni significativi che possono ritardare la tempistica del progetto.

Transfer Appliance per trasferimenti più grandi

Per i trasferimenti su larga scala (in particolare quelli con larghezza di banda di rete limitata), Transfer Appliance è un'opzione eccellente, soprattutto quando non è disponibile una connessione di rete rapida ed è troppo costoso acquisire più larghezza di banda.

Transfer Appliance è particolarmente utile nei seguenti scenari:

  • Il tuo data center si trova in una località remota con accesso limitato o nullo alla larghezza di banda.
  • La larghezza di banda è disponibile, ma non può essere acquisita in tempo per rispettare la scadenza.
  • Hai accesso a risorse logistiche per ricevere e collegare gli elettrodomestici alla tua rete.

Con questa opzione, tieni presente quanto segue:

  • Transfer Appliance richiede che tu possa ricevere e rispedire l'hardware di proprietà di Google.
  • A seconda della connessione a internet, la latenza per il trasferimento dei dati in Google Cloud è in genere più elevata con Transfer Appliance rispetto a quanto avviene online.
  • Transfer Appliance è disponibile solo in alcuni paesi.

I due criteri principali da considerare con Transfer Appliance sono il costo e la velocità. Con una connettività di rete ragionevole (ad esempio 1 Gbps), il trasferimento di 100 TB di dati online richiede più di 10 giorni. Se questa percentuale è accettabile, un trasferimento online è probabilmente una buona soluzione per le tue esigenze. Se hai solo una connessione a 100 Mbps (o peggio da una località remota), lo stesso trasferimento richiede più di 100 giorni. A questo punto, vale la pena prendere in considerazione un'opzione di trasferimento offline come Transfer Appliance.

Acquistare un Transfer Appliance è semplice. Nella console Google Cloud, richiedi un Transfer Appliance, indica la quantità di dati di cui disponi e Google spedisce uno o più appliance nella località richiesta. Hai a disposizione alcuni giorni per trasferire i dati all'appliance ("acquisizione dei dati") e rispedirla a Google.

Storage Transfer Service per i trasferimenti da cloud a cloud

Storage Transfer Service è un servizio completamente gestito e altamente scalabile per automatizzare i trasferimenti da altri cloud pubblici a Cloud Storage. Ad esempio, puoi utilizzare Storage Transfer Service per trasferire dati da Amazon S3 a Cloud Storage.

Per HTTP, puoi fornire a Storage Transfer Service un elenco di URL pubblici in un formato specificato. Questo approccio richiede di scrivere uno script che fornisca le dimensioni di ogni file in byte, insieme a un hash MD5 con codifica Base64 dei contenuti del file. A volte le dimensioni e l'hash del file sono disponibili sul sito web di origine. In caso contrario, devi disporre dell'accesso locale ai file. In questo caso, potrebbe essere più semplice utilizzare il comando gcloud storage, come descritto in precedenza.

Se hai già eseguito un trasferimento, Storage Transfer Service è un ottimo modo per recuperare i dati e conservarli, in particolare quando esegui il trasferimento da un altro cloud pubblico.

Se vuoi spostare i dati da un altro cloud non supportato da Storage Transfer Service, puoi utilizzare il comando gcloud storage da un istanza di macchina virtuale ospitata sul cloud.

Sicurezza

Per molti utenti di Google Cloud, la sicurezza è la priorità principale e sono disponibili diversi livelli di sicurezza. Alcuni aspetti della sicurezza da considerare includono la protezione dei dati at-rest (autorizzazione e accesso al sistema di archiviazione di origine e di destinazione), la protezione dei dati durante il transito e la protezione dell'accesso al prodotto di trasferimento. La tabella seguente illustra questi aspetti della sicurezza in base al prodotto.

Prodotto Dati at-rest Dati in transito Accesso al prodotto di trasferimento
Transfer Appliance Tutti i dati sono criptati quando sono inattivi. I dati sono protetti con chiavi gestite dal cliente. Chiunque può ordinare un'appliance, ma per utilizzarla deve avere accesso all'origine dati.
Comando gcloud storage Chiavi di accesso necessarie per accedere a Cloud Storage, che è criptato in stato di riposo. I dati vengono inviati tramite HTTPS e criptati in transito. Chiunque può scaricare ed eseguire Google Cloud CLI. Per poter spostare i dati, devono disporre delle autorizzazioni per i bucket e i file locali.
Storage Transfer Service per i dati on-premise Chiavi di accesso necessarie per accedere a Cloud Storage, che è criptato in stato di riposo. Il processo dell'agente può accedere ai file locali in base alle autorizzazioni del sistema operativo. I dati vengono inviati tramite HTTPS e criptati in transito. Per accedere ai bucket Cloud Storage, devi disporre delle autorizzazioni di editor degli oggetti.
Storage Transfer Service Chiavi di accesso richieste per le risorse non Google Cloud (ad esempio, Amazon S3). Le chiavi di accesso sono necessarie per accedere a Cloud Storage, che è criptato at-rest. I dati vengono inviati tramite HTTPS e criptati in transito. Devi disporre delle autorizzazioni IAM per l'account di servizio per accedere alle autorizzazioni di editor di origini e oggetti per qualsiasi bucket Cloud Storage.

Per ottenere miglioramenti di sicurezza di base, i trasferimenti online su Google Cloud utilizzando il comando gcloud storage vengono eseguiti tramite HTTPS, i dati vengono criptati in transito e tutti i dati in Cloud Storage sono, per impostazione predefinita, criptati quando inattivi. Se utilizzi Transfer Appliance, i token di sicurezza che controlli possono contribuire a proteggere i tuoi dati. In genere, consigliamo di coinvolgere il team di sicurezza per assicurarti che il piano di trasferimento soddisfi i requisiti della tua azienda e delle normative.

Prodotti di trasferimento di terze parti

Per l'ottimizzazione avanzata a livello di rete o per flussi di lavoro di trasferimento dati continuativi, hai a disposizione strumenti ancora più avanzati. Per informazioni su strumenti più avanzati, consulta i partner Google Cloud.

Passaggio 4: valutazione degli approcci di migrazione dei dati

Quando esegui la migrazione dei dati, puoi seguire questi passaggi generali:

  1. Trasferisci i dati dal sito precedente al nuovo sito.
  2. Risolvi eventuali problemi di integrazione dei dati, ad esempio la sincronizzazione degli stessi dati da più origini.
  3. Convalida la migrazione dei dati.
  4. Promuovi il nuovo sito come copia principale.
  5. Quando il sito precedente non è più necessario come opzione di riserva, ritiralo.

L'approccio alla migrazione dei dati deve basarsi sulle seguenti domande:

  • Quanti dati devi migrare?
  • Con quale frequenza cambiano questi dati?
  • Puoi permetterti il tempo di riposo rappresentato da un periodo di transizione durante la migrazione dei dati?
  • Qual è il tuo attuale modello di coerenza dei dati?

Non esiste un approccio migliore; la scelta dipende dall'ambiente e dai tuoi requisiti.

Le sezioni seguenti presentano quattro approcci alla migrazione dei dati:

  • Manutenzione pianificata
  • Replica continua
  • Y (scrittura e lettura)
  • Microservizio di accesso ai dati

Ogni approccio affronta problemi diversi, a seconda delle dimensioni e dei requisiti della migrazione dei dati.

L'approccio di microservizi per l'accesso ai dati è l'opzione preferita in un'architettura di microservizi. Tuttavia, gli altri approcci sono utili per la migrazione dei dati. Sono utili anche durante il periodo di transizione necessario per modernizzare l'infrastruttura in modo da utilizzare l'approccio dei microservizi per l'accesso ai dati.

Il seguente grafico illustra le rispettive dimensioni delle finestre di transizione, l'impegno di refactoring e le proprietà di flessibilità di ciascuno di questi approcci.

Grafico a barre con ogni barra che mostra i valori relativi a flessibilità, impegno di refactoring e dimensioni della finestra di transizione per ciascuno dei quattro approcci

Prima di seguire uno di questi approcci, assicurati di aver configurato l'infrastruttura richiesta nel nuovo ambiente.

Manutenzione pianificata

L'approccio di manutenzione pianificata è ideale se i tuoi carichi di lavoro possono permettersi un periodo di transizione. È programmata nel senso che puoi pianificare quando si verifica il periodo di transizione.

In questo approccio, la migrazione è composta dai seguenti passaggi:

  1. Copia i dati del sito precedente nel nuovo sito. Questa copia iniziale riduce al minimo la finestra di transizione. Dopo questa copia iniziale, devi copiare solo i dati che sono cambiati durante questa finestra.
  2. Esegui la convalida dei dati e i controlli di coerenza per confrontare i dati nel sito precedente con quelli copiati nel nuovo sito.
  3. Interrompi i carichi di lavoro e i servizi che hanno accesso in scrittura ai dati copiati, in modo che non vengano apportate ulteriori modifiche.
  4. Sincronizza le modifiche apportate dopo la copia iniziale.
  5. Esegui il refactoring dei carichi di lavoro e dei servizi per utilizzare il nuovo sito.
  6. Avvia i tuoi carichi di lavoro e servizi.
  7. Quando il sito precedente non serve più come opzione di riserva, ritiralo.

L'approccio di manutenzione pianificata pone la maggior parte del carico sul lato operativo, in quanto è necessario un refactoring minimo del workload e dei servizi.

Replica continua

Poiché non tutti i carichi di lavoro possono permettersi un periodo di transizione lungo, puoi sviluppare l'approccio di manutenzione pianificata fornendo un meccanismo di replica continua dopo i passaggi iniziali di copia e convalida. Quando progetti un meccanismo come questo, devi anche tenere conto della frequenza con cui le modifiche vengono applicate ai dati. Potrebbe essere difficile mantenere sincronizzati due sistemi.

L'approccio di replica continua è più complesso dell'approccio di manutenzione pianificata. Tuttavia, l'approccio di replica continua riduce al minimo il tempo necessario per la finestra di cutover richiesta, perché riduce al minimo la quantità di dati da sincronizzare. La sequenza per una migrazione con replica continua è la seguente:

  1. Copia i dati del sito precedente nel nuovo sito. Questa copia iniziale riduce al minimo la finestra di transizione. Dopo la copia iniziale, devi copiare solo i dati modificati durante questa finestra.
  2. Esegui la convalida dei dati e i controlli di coerenza per confrontare i dati nel sito precedente con quelli copiati nel nuovo sito.
  3. Configura un meccanismo di replica continua dal sito precedente al nuovo sito.
  4. Interrompi i workload e i servizi che hanno accesso ai dati di cui eseguire la migrazione (ovvero ai dati coinvolti nel passaggio precedente).
  5. Esegui il refactoring dei carichi di lavoro e dei servizi per utilizzare il nuovo sito.
  6. Attendi che la replica sincronizzi completamente il nuovo sito con quello precedente.
  7. Avvia i tuoi carichi di lavoro e servizi.
  8. Quando il sito precedente non serve più come opzione di riserva, ritiralo.

Come per l'approccio di manutenzione pianificata, l'approccio di replica continua pone la maggior parte del carico sulle operazioni.

Y (scrittura e lettura)

Se i tuoi carichi di lavoro hanno requisiti di alta disponibilità rigidi e non puoi permetterti il tempo di riposo rappresentato da una finestra di transizione, devi adottare un approccio diverso. Per questo scenario, puoi utilizzare un approccio definito in questo documento come Y (scrittura e lettura), che è una forma di migrazione parallela. Con questo approccio, il workload scrive e legge i dati sia nel sito legacy sia nel nuovo sito durante la migrazione. La lettera Y viene utilizzata qui come representatione grafica del flusso di dati durante il periodo di migrazione.

Questo approccio è riassunto come segue:

  1. Esegui il refactoring dei carichi di lavoro e dei servizi per scrivere i dati sia nel sito precedente sia nel nuovo sito e per leggere dal sito precedente.
  2. Identifica i dati scritti prima di attivare le scritture nel nuovo sito e copiali dal sito precedente al nuovo. Insieme al refactoring precedente, questo garantisce l'allineamento degli archivi dati.
  3. Esegui convalida dei dati e controlli di coerenza che confrontino i dati nel sito precedente con quelli nel nuovo sito.
  4. Sposta le operazioni di lettura dal sito precedente al nuovo sito.
  5. Esegui un altro ciclo di convalida dei dati e controlli di coerenza per confrontare i dati nel sito precedente con quelli del nuovo sito.
  6. Disattivare la scrittura nel sito precedente.
  7. Quando il sito precedente non serve più come opzione di riserva, ritiralo.

A differenza degli approcci di manutenzione pianificata e replica continua, l'approccio Y (scrittura e lettura) sposta la maggior parte degli sforzi dal lato operativo a quello di sviluppo a causa dei molteplici refactoring.

Microservizio di accesso ai dati

Se vuoi ridurre lo sforzo di refactoring necessario per seguire l'approccio Y (scrittura e lettura), puoi centralizzare le operazioni di lettura e scrittura dei dati ristrutturando i carichi di lavoro e i servizi in modo da utilizzare un microservizio di accesso ai dati. Questo microservizio scalabile diventa l'unico punto di accesso al tuo livello di archiviazione dei dati e funge da proxy per questo livello. Tra gli approcci discussi qui, questo offre la massima flessibilità, poiché puoi eseguire il refactoring di questo componente senza influire su altri componenti dell'architettura e senza richiedere una finestra di transizione.

L'utilizzo di un microservizio di accesso ai dati è molto simile all'approccio Y (scrittura e lettura). La differenza è che le attività di refactoring si concentrano solo sul microservizio di accesso ai dati, anziché dover eseguire il refactoring di tutti i carichi di lavoro e i servizi che accedono al livello di archiviazione dei dati. Questo approccio si riassume come segue:

  1. Esegui il refactoring del microservizio di accesso ai dati per scrivere i dati sia nel sito legacy sia nel nuovo sito. Le letture vengono eseguite sul sito precedente.
  2. Identifica i dati scritti prima di attivare le scritture nel nuovo sito e copiali dal sito precedente al nuovo. Insieme al refactoring precedente, questo garantisce l'allineamento degli archivi dati.
  3. Esegui la convalida dei dati e i controlli di coerenza confrontando i dati del sito precedente con quelli del nuovo sito.
  4. Esegui il refactoring del microservizio di accesso ai dati in modo che legga dal nuovo sito.
  5. Esegui un altro ciclo di convalida dei dati e controlli di coerenza confrontando i dati del sito precedente con quelli del nuovo sito.
  6. Esegui il refactoring del microservizio di accesso ai dati in modo che sia in sola scrittura nel nuovo sito.
  7. Quando il sito precedente non serve più come opzione di riserva, ritiralo.

Come l'approccio Y (scrittura e lettura), l'approccio al microservice per l'accesso ai dati pone la maggior parte del carico sul lato dello sviluppo. Tuttavia, è sostanzialmente più leggero rispetto all'approccio Y (scrittura e lettura), perché gli sforzi di refactoring sono incentrati sul microservizio di accesso ai dati.

Passaggio 5: preparazione del trasferimento

Per un trasferimento di grandi dimensioni o con dipendenze significative, è importante capire come utilizzare il prodotto di trasferimento. I clienti solitamente svolgono i seguenti passaggi:

  1. Stima dei prezzi e del ROI. Questo passaggio offre molte opzioni per aiutarti a prendere una decisione.

  2. Test funzionali. In questo passaggio confermi che il prodotto può essere configurato correttamente e che la connettività di rete (se applicabile) è in funzione. Inoltre, verifichi di poter spostare nella destinazione un campione rappresentativo dei tuoi dati (inclusi i passaggi non di trasferimento associati, come lo spostamento di un'istanza VM).

    In genere, puoi eseguire questo passaggio prima di allocare tutte le risorse, come le macchine di trasferimento o la larghezza di banda. Gli obiettivi di questo passaggio includono:

    • Verifica di poter installare e utilizzare il trasferimento.
    • Evidenzia potenziali problemi che bloccano il movimento dei dati (ad es. percorsi di rete) o le tue operazioni (ad es. formazione necessaria in un passaggio di non trasferimento).

  3. Test delle prestazioni. In questo passaggio, esegui un trasferimento su un ampio campione di dati (in genere il 3-5%) dopo l'allocazione delle risorse di produzione per eseguire le seguenti operazioni:

    • Verifica di poter utilizzare tutte le risorse allocate e di poter ottenere le velocità previste.
    • Individua e correggi i colli di bottiglia (ad esempio, un sistema di archiviazione delle origini lento).

Passaggio 6: garantire l'integrità del trasferimento

Per contribuire a garantire l'integrità dei dati durante un trasferimento, ti consigliamo di adottare le seguenti precauzioni:

  • Abilita il controllo delle versioni e il backup nella destinazione per limitare i danni causati dalle eliminazioni accidentali.
  • Convalida i dati prima di rimuovere i dati di origine.

Per i trasferimenti di dati su larga scala (con petabyte di dati e miliardi di file), un tasso di errore latente di riferimento del sistema di archiviazione di origine sottostante basso al 0,0001% comporta comunque una perdita di dati di migliaia di file e gigabyte. In genere, le applicazioni in esecuzione all'origine sono già tolleranti di questi errori, nel qual caso non è necessaria una convalida aggiuntiva. In alcuni scenari eccezionali (ad esempio l'archiviazione a lungo termine), è necessaria una maggiore convalida prima che sia considerato sicuro eliminare i dati dall'origine.

A seconda dei requisiti della tua applicazione, ti consigliamo di eseguire alcuni test di integrità dei dati al termine del trasferimento per assicurarti che l'applicazione continui a funzionare come previsto. Molti prodotti di trasferimento dispongono di controlli predefiniti per l'integrità dei dati. Tuttavia, a seconda del tuo profilo di rischio, potresti voler eseguire un ulteriore serie di controlli sui dati e sulle app che li leggono prima di eliminarli dall'origine. Ad esempio, potresti voler verificare se un controllo di congruenza registrato e calcolato in modo indipendente corrisponde ai dati scritti nella destinazione o confermare che un set di dati utilizzato dall'applicazione è stato trasferito correttamente.

Passaggi successivi

Collaboratori

Autori: