Esegui la migrazione a Google Cloud: trasferisci i tuoi set di dati di grandi dimensioni

Last reviewed 2023-11-13 UTC

Per molti clienti, il primo passo nell'adozione di un prodotto Google Cloud è inserire i dati in Google Cloud. Questo documento esplora questo processo, dalla pianificazione di un trasferimento di dati all'utilizzo delle best practice per l'implementazione di un piano.

Il trasferimento di set di dati di grandi dimensioni implica la creazione del team giusto, la pianificazione anticipata e il test del piano di trasferimento prima di implementarlo in un ambiente di produzione. Sebbene questi passaggi possano richiedere tutto il tempo del trasferimento stesso, tali preparativi possono aiutare a ridurre al minimo l'interruzione 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 di dati è il processo di spostamento dei dati senza trasformarli, ad esempio lo spostamento di file così come sono all'interno di oggetti.

Il trasferimento di dati non è semplice come sembra

Si potrebbe avere la tentazione di pensare al trasferimento di dati come a una gigantesca sessione FTP, in cui i file vengono posizionati in un lato e si attende che escano dall'altro lato. Tuttavia, nella maggior parte degli ambienti aziendali, il processo di trasferimento coinvolge molti fattori, tra cui:

  • Elaborazione di un piano di trasferimento che tiene conto del tempo amministrativo, tra cui il tempo necessario per decidere un'opzione di trasferimento, ottenere approvazioni e affrontare problemi inaspettati.
  • Coordina 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 possono comportare lo spostamento dei dati.
  • Scegliere lo strumento di trasferimento giusto in base alle tue risorse, ai tuoi costi, ai tuoi tempi e ad altre considerazioni relative al progetto.
  • Superare le sfide del trasferimento dei dati, inclusi i problemi di "velocità della luce" (larghezza di banda insufficiente), lo spostamento di set di dati in uso attivo, la protezione e il monitoraggio dei dati mentre sono in transito e la garanzia che i dati vengano trasferiti correttamente.

Questo documento ha lo scopo di aiutarti a creare un'iniziativa di trasferimento efficace.

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

Passaggio 1: forma il team

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

  • Attivazione delle risorse necessarie per un trasferimento:amministratori di archiviazione, IT e di rete, uno sponsor esecutivo e altri consulenti (ad esempio, un team degli Account Google o partner di integrazione)
  • Approvazione della decisione di trasferimento: proprietari o governatori dei dati (per le norme interne relative a chi è autorizzato a trasferire determinati dati), consulenti legali (per le normative relative ai dati) e un amministratore della sicurezza (per i criteri interni sulla protezione dell'accesso ai dati)
  • Esecuzione del trasferimento: un responsabile del team, un project manager (per l'esecuzione e il monitoraggio del progetto), un team di tecnici e la ricezione e la spedizione in loco (per ricevere l'hardware dell'appliance)

È fondamentale identificare chi è il proprietario delle responsabilità precedenti per il tuo progetto di trasferimento e includerlo nelle riunioni di pianificazione e decisione, quando opportuno. Una pianificazione organizzativa scadente spesso è la causa di iniziative di trasferimento non riuscite.

Raccogliere i requisiti del progetto e le richieste di questi stakeholder può essere impegnativo, ma creare un piano e stabilire ruoli e responsabilità chiari è molto utile. Non ci si può aspettare di conoscere tutti i dettagli dei dati. La creazione di un team ti offre una visione più approfondita delle esigenze dell'azienda. La best practice prevede l'identificazione di potenziali problemi prima di investire tempo, denaro e risorse per completare i trasferimenti.

Passaggio 2: raccogli i requisiti e le risorse disponibili

Quando progetti un piano di trasferimento, ti consigliamo di raccogliere innanzitutto i requisiti per il trasferimento dei dati e poi scegliere 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 i 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 riorganizzarli), valuta la possibilità di utilizzare un prodotto di integrazione dei dati come Dataflow o Cloud Data Fusion oppure un prodotto di orchestrazione del flusso di lavoro come Cloud Composer.
  3. Per i set di dati spostabili, determina dove trasferire ogni 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 applicazioni sono attive, Cloud Storage è un'opzione di archiviazione scalabile e durevole.
    • Scopri quali criteri di accesso ai dati devono essere gestiti dopo la migrazione.
    • Determina se è necessario archiviare questi dati in regioni specifiche.
    • Pianifica come strutturare questi dati nella destinazione. Ad esempio, sarà uguale alla fonte o diversa?
    • Stabilisci se devi trasferire i dati su base continuativa.
  4. Per i set di dati spostabili, determina quali risorse sono disponibili per spostarli.
    • Ora: 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): quanta 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, ti consigliamo di valutare se qualsiasi parte del tuo modello IT può essere migliorata, ad esempio governance dei dati, organizzazione e sicurezza.

Il tuo modello di sicurezza

A molti membri del team di trasferimento potrebbero essere concessi nuovi ruoli nell'organizzazione Google Cloud nell'ambito del progetto di trasferimento dei dati. La pianificazione del trasferimento di dati è un ottimo momento per esaminare le autorizzazioni IAM (Identity and Access Management) e le best practice per l'utilizzo sicuro di IAM. Questi problemi possono influire sulla modalità di concessione dell'accesso allo spazio di archiviazione . Ad esempio, potresti applicare limiti rigorosi sull'accesso in scrittura a 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

Il modo in cui strutturare i dati su Google Cloud dipende da come prevedi di utilizzare Google Cloud. L'archiviazione dei dati nello stesso progetto Google Cloud in cui esegui l'applicazione potrebbe funzionare, ma potrebbe non essere ottimale dal punto di vista della gestione. Alcuni sviluppatori potrebbero non avere il privilegio di poter visualizzare i dati di produzione. In questo caso, uno sviluppatore potrebbe sviluppare codice su dati di esempio, mentre un account di servizio con privilegi potrebbe accedere ai dati di produzione. Potresti quindi voler conservare l'intero set di dati di produzione in un progetto Google Cloud separato e poi utilizzare un account di servizio per consentire l'accesso ai dati di ciascun progetto di applicazione.

Google Cloud è organizzato sulla base di progetti. I progetti possono essere raggruppati in cartelle e le cartelle all'interno dell'organizzazione. I ruoli vengono stabiliti a livello di progetto e le autorizzazioni di accesso vengono aggiunte a questi ruoli a livello dei bucket Cloud Storage. Questa struttura è in linea con la struttura delle autorizzazioni di altri provider di archivi 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: valutazione delle opzioni di trasferimento

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

  • Costo
  • Data/ora 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
    • Il traffico in entrata in Cloud Storage è gratuito. Tuttavia, se ospiti i tuoi dati su un cloud provider pubblico, puoi aspettarti un addebito per il traffico in uscita e potenzialmente dei 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 cloud provider.
    • Se i tuoi dati sono ospitati in un data center privato in uso, potrebbero essere applicati costi aggiuntivi per la configurazione di una larghezza di banda maggiore per Google Cloud.
  • Costi operativi e di archiviazione per Cloud Storage durante e dopo il trasferimento dei dati
  • Costi del prodotto (ad esempio Transfer Appliance)
  • Costi del personale per la formazione del team e l'acquisizione di assistenza logistica

Data/ora trasferimento

Pochi aspetti nel campo dell'informatica mettono in luce i limiti hardware delle reti che comportano il trasferimento di grandi quantità di dati. Idealmente, puoi trasferire 1 GB in otto secondi su una rete da 1 Gbps. Se esegui lo scale up di un set di dati di grandi dimensioni (ad esempio 100 TB), il tempo di trasferimento è di 12 giorni. Il trasferimento di set di dati di grandi dimensioni può testare i limiti della tua infrastruttura e potenzialmente causare problemi alla tua azienda.

Puoi utilizzare il seguente calcolatore per capire quanto tempo potrebbe richiedere un trasferimento, date le dimensioni del set di dati che stai spostando e la larghezza di banda disponibile per il trasferimento. Nei calcoli viene presa in considerazione una certa percentuale del tempo di gestione. Inoltre, viene inclusa un'efficace efficienza della larghezza di banda, quindi i valori risultanti sono più realistici.

Ti consigliamo di non trasferire grandi set di dati dalla rete aziendale durante le ore di lavoro di picco. Se il trasferimento sovraccarica la rete, nessun altro sarà in grado di portare a termine il lavoro necessario o mission critical. Per questo motivo, il team di trasferimento deve considerare il fattore di 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 connetti a Google Cloud.

In un trasferimento da cloud a cloud tra Google Cloud e altri cloud provider, Google fornisce la connessione tra i data center dei fornitori cloud, senza richiedere alcuna configurazione da parte tua.

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

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

Quando valuti questi approcci, è utile considerare le tue esigenze di connettività a lungo termine. Puoi concludere che acquisire una larghezza di banda è proibitiva esclusivamente a fini di trasferimento, ma considerando l'utilizzo a lungo termine di Google Cloud e delle esigenze di rete all'interno dell'organizzazione, l'investimento potrebbe essere vantaggioso. Per ulteriori informazioni su come connettere le tue reti a Google Cloud, consulta Scegliere un prodotto per la connettività di rete.

Se scegli un approccio che prevede il trasferimento dei dati sulla rete internet pubblica, ti consigliamo di verificare con l'amministratore della sicurezza se le norme della tua azienda vietano questi trasferimenti. Controlla inoltre se per il traffico di produzione viene utilizzata la connessione a internet pubblica. Infine, considera che i trasferimenti di dati su larga scala potrebbero influire negativamente sulle prestazioni 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 se eseguire il trasferimento su una rete, che si tratti di Cloud Interconnect o della rete internet pubblica, oppure utilizzando hardware di archiviazione.

Per aiutarti in questa decisione, mettiamo a disposizione un calcolatore dei trasferimenti che ti consente di stimare le differenze di tempo e di costo tra queste due opzioni. Il seguente grafico mostra anche alcune velocità di trasferimento per varie dimensioni e larghezze di banda. In questi calcoli si integra una certa quantità di overhead per la gestione.

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

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

Opzioni disponibili da Google

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

Scelta delle opzioni di trasferimento di Google

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

Da dove trasferisci i dati Scenario Prodotti suggeriti
Un altro cloud provider (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
Il tuo data center privato in Google Cloud Larghezza di banda sufficiente per rispettare la scadenza del progetto Comando gcloud storage
Il tuo data center privato in Google Cloud Larghezza di banda sufficiente per rispettare la scadenza del progetto Storage Transfer Service per dati on-premise
Il tuo data center privato in Google Cloud Larghezza di banda insufficiente per rispettare la scadenza del progetto Transfer Appliance

Comando gcloud storage per trasferimenti più piccoli di dati on-premise

Il comando gcloud storage è lo strumento standard per trasferimenti di piccole e medie dimensioni su una tipica rete di livello aziendale, da un data center privato o da un altro cloud provider a Google Cloud. Mentre gcloud storage supporta il caricamento di oggetti fino alla dimensione massima degli oggetti Cloud Storage, i trasferimenti di oggetti di grandi dimensioni hanno maggiori probabilità di riscontrare errori rispetto ai trasferimenti a breve esecuzione. 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 secondo necessità o durante le sessioni a riga di comando degli utenti.
  • Stai trasferendo solo pochi file, file molto grandi o entrambi.
  • Stai utilizzando l'output di un programma (output del flusso di dati in Cloud Storage).
  • Devi controllare una directory con un numero moderato di file e sincronizzare eventuali aggiornamenti con latenze molto basse.

Storage Transfer Service per trasferimenti di grandi dimensioni di dati on-premise

Come il comando gcloud storage, Storage Transfer Service per i dati on-premise consente il trasferimento dall'archiviazione del file system di rete (NFS) a Cloud Storage. Storage Transfer Service per dati on-premise è progettato per trasferimenti su larga scala (fino a petabyte di dati, miliardi di file). Supporta copie integrali o copie incrementali e funziona su tutte le opzioni di trasferimento elencate in precedenza in Scelta delle opzioni di trasferimento di Google. Dispone inoltre di una Graphic User Interface gestita; anche gli utenti non esperti tecnicamente (dopo la configurazione) possono utilizzarla per spostare i dati.

Storage Transfer Service per i dati on-premise è particolarmente utile nei seguenti scenari:

  • Disponi di larghezza di banda sufficiente per spostare i volumi di dati (consulta il Calcolatore dati di Google Cloud).
  • Supporti un'ampia base di utenti interni che potrebbero trovare difficile da usare uno strumento a riga di comando.
  • Hai bisogno di una solida generazione di report sugli errori e di un record di tutti i file e gli oggetti spostati.
  • Devi limitare l'impatto dei trasferimenti su altri carichi di lavoro 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.

Puoi configurare Storage Transfer Service per i dati on-premise installando software on-premise (noto come agenti) sui computer nel tuo data center.

Dopo aver configurato Storage Transfer Service, puoi avviare i trasferimenti nella console Google Cloud fornendo una directory di origine, un bucket di destinazione e un orario o una pianificazione. Storage Transfer Service esegue in modo ricorsivo le sottodirectory e i 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 riprova automaticamente un trasferimento quando rileva errori temporanei. Mentre sono in esecuzione i trasferimenti, puoi monitorare il numero di file spostati e la velocità complessiva di trasferimento, nonché visualizzare esempi di errori.

Quando Storage Transfer Service completa un trasferimento, genera un file delimitato da tabulazioni (TSV) con un record completo di tutti i file toccati e degli eventuali messaggi di errore ricevuti. Gli agenti sono a tolleranza di errore, quindi se un agente non funziona, il trasferimento continua con gli agenti rimanenti. Gli agenti si aggiornano e si correggono autonomamente, quindi non devi preoccuparti di applicare patch alle versioni più recenti o di riavviare il processo se si verifica un problema imprevisto.

Aspetti da considerare quando si utilizza Storage Transfer Service:

  • Utilizza la stessa configurazione dell'agente su ogni macchina. Tutti gli agenti dovrebbero vedere gli stessi montaggi di file system di rete (NFS) allo stesso modo (stessi percorsi relativi). Questa configurazione è un requisito per il funzionamento del prodotto.
  • Un numero maggiore di agenti aumenta la velocità. Poiché i trasferimenti vengono parallelizzati automaticamente tra tutti gli agenti, ti consigliamo di eseguire il deployment di molti agenti in modo da utilizzare la larghezza di banda disponibile.
  • I limiti di larghezza di banda possono proteggere i carichi di lavoro. È possibile che gli altri carichi di lavoro utilizzino la larghezza di banda del data center, quindi imposta un limite di larghezza di banda per evitare che i trasferimenti influiscano sugli SLA.
  • Pianificare il tempo per la revisione degli errori. I trasferimenti di grandi dimensioni possono spesso causare errori che richiedono una revisione. Storage Transfer Service consente di visualizzare un esempio degli errori che si verificano direttamente nella console Google Cloud. Se necessario, puoi caricare il record completo di tutti gli errori di trasferimento in BigQuery per controllare i file o valutare gli errori rimasti anche dopo nuovi tentativi. Questi errori potrebbero essere causati da app in esecuzione che scrivevano sull'origine durante il trasferimento oppure potrebbero indicare un problema che deve essere risolto (ad esempio un errore relativo alle autorizzazioni).
  • Configura Cloud Monitoring per trasferimenti a lunga esecuzione. Storage Transfer Service consente a Monitoring di monitorare l'integrità e la velocità effettiva degli agenti, consentendoti di impostare avvisi che ti inviano una notifica quando gli agenti non sono attivi o richiedono attenzione. Intervenire sugli errori degli agenti è importante per i trasferimenti che richiedono diversi giorni o settimane, in modo da evitare rallentamenti o interruzioni significative che possono ritardare la tempistica del progetto.

Transfer Appliance per trasferimenti di grandi dimensioni

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

Transfer Appliance è particolarmente utile nei seguenti scenari:

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

Con questa opzione, considera quanto segue:

  • Transfer Appliance richiede che tu possa ricevere e spedire l'hardware di Google.
  • A seconda della connessione a internet, la latenza per il trasferimento dei dati in Google Cloud è in genere superiore con Transfer Appliance che online.
  • Transfer Appliance è disponibile solo in alcuni paesi.

I due criteri principali da considerare con Transfer Appliance sono costo e 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 questo tasso è accettabile, probabilmente un trasferimento online è 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 valutare un'opzione di trasferimento offline come Transfer Appliance.

Ottenere un Transfer Appliance è semplice. Nella console Google Cloud, richiedi un Transfer Appliance, indichi la quantità di dati a tua disposizione e Google spedisce una o più appliance alla località richiesta. Hai a disposizione un determinato numero di giorni per trasferire i tuoi dati all'appliance ("acquisizione dei dati") e spedirli a Google.

Storage Transfer Service per i trasferimenti da cloud a cloud

Storage Transfer Service è un servizio completamente gestito e a scalabilità elevata 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 la scrittura di uno script che fornisca le dimensioni di ogni file in byte, insieme a un hash MD5 codificato in Base64 dei contenuti del file. A volte le dimensioni e l'hash del file sono disponibili nel 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 un trasferimento in corso, Storage Transfer Service è un ottimo modo per ottenere i dati e conservarli, in particolare durante 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 nel cloud.

Sicurezza

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

Product Dati at-rest Dati in transito Accesso al prodotto da trasferire
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 accedere all'origine dati.
Comando gcloud storage Chiavi di accesso necessarie per accedere a Cloud Storage, che è criptato at-rest. I dati vengono inviati tramite HTTPS e criptati in transito. Chiunque può scaricare ed eseguire Google Cloud CLI. Devono disporre delle autorizzazioni per i bucket e i file locali per spostare i dati.
Storage Transfer Service per dati on-premise Chiavi di accesso necessarie per accedere a Cloud Storage, che è criptato at-rest. Il processo dell'agente può accedere ai file locali secondo le autorizzazioni del sistema operativo. I dati vengono inviati tramite HTTPS e criptati in transito. Devi disporre delle autorizzazioni di editor degli oggetti per accedere ai bucket Cloud Storage.
Storage Transfer Service Chiavi di accesso necessarie 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 dell'editor di origine e di oggetti per qualsiasi bucket Cloud Storage.

Per migliorare la sicurezza di base, i trasferimenti online a 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 at-rest. Se utilizzi Transfer Appliance, i token di sicurezza che controlli possono aiutarti a proteggere i tuoi dati. In generale, consigliamo di coinvolgere il team di sicurezza per garantire che il piano di trasferimento soddisfi i requisiti aziendali e normativi.

Prodotti per il trasferimento di terze parti

Per l'ottimizzazione avanzata a livello di rete o i flussi di lavoro di trasferimento dati continui, ti consigliamo di utilizzare strumenti più avanzati. Per informazioni su strumenti più avanzati, consulta la pagina Partner Google Cloud.

Passaggio 4: valuta gli approcci alla migrazione dei dati

Durante la migrazione dei dati, puoi seguire questi passaggi generali:

  1. Trasferisci i dati dal sito precedente a quello nuovo.
  2. Risolvi eventuali problemi di integrazione dei dati, ad esempio sincronizzando gli stessi dati da più origini.
  3. Convalidare la migrazione dei dati.
  4. Promuovi il nuovo sito come testo principale.
  5. Quando non hai più bisogno del sito precedente come opzione di riserva, ritiralo.

Dovresti basare il tuo approccio alla migrazione dei dati sulle seguenti domande:

  • Quanti dati hai bisogno di eseguire la migrazione?
  • Con quale frequenza vengono modificati questi dati?
  • Puoi permetterti il tempo di inattività rappresentato da una finestra di migrazione completa dei dati?
  • Qual è il tuo attuale modello di coerenza dei dati?

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

Le seguenti sezioni presentano quattro approcci alla migrazione dei dati:

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

Ciascun approccio affronta problemi diversi, a seconda della portata e dei requisiti della migrazione dei dati.

L'approccio basato su microservizi di accesso ai dati è l'opzione preferita nell'architettura dei 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 per utilizzare l'approccio basato su microservizi di accesso ai dati.

Il seguente grafico illustra le rispettive dimensioni delle finestre di migrazione completa, lo sforzo di refactoring e le proprietà di flessibilità di ciascuno di questi approcci.

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

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

Manutenzione pianificata

L'approccio di manutenzione pianificata è ideale se i carichi di lavoro possono permettersi una finestra di migrazione completa. È pianificato in modo da consentirti di pianificare quando si verifica la finestra di migrazione completa.

In questo approccio, la migrazione prevede i seguenti passaggi:

  1. Copia i dati del sito precedente nel nuovo sito. La copia iniziale riduce a icona la finestra di migrazione completa; dopo la copia iniziale, devi copiare solo i dati che sono stati modificati durante il periodo in questione.
  2. Esegui controlli di convalida e coerenza dei dati per confrontare i dati del sito precedente con quelli copiati nel nuovo sito.
  3. Arresta 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 che si sono verificate dopo la copia iniziale.
  5. Esegui il refactoring dei carichi di lavoro e dei servizi per utilizzare il nuovo sito.
  6. Avvia i carichi di lavoro e i servizi.
  7. Quando non hai più bisogno del sito legacy come opzione di riserva, ritiralo.

L'approccio di manutenzione programmata pone la maggior parte del carico sul lato operativo, poiché è necessario un refactoring minimo del carico di lavoro e dei servizi.

Replica continua

Poiché non tutti i carichi di lavoro possono permettersi un lungo periodo di migrazione completa, puoi utilizzare l'approccio di manutenzione pianificato 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 due sistemi sincronizzati.

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

  1. Copia i dati del sito precedente nel nuovo sito. La copia iniziale riduce a icona la finestra di migrazione completa; dopo la copia iniziale, devi copiare solo i dati che sono stati modificati durante il periodo in questione.
  2. Esegui controlli di convalida e coerenza dei dati per confrontare i dati del sito precedente con quelli copiati nel nuovo sito.
  3. Configura un meccanismo di replica continua dal sito precedente a quello nuovo.
  4. Arresta i carichi di lavoro 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 esegua la sincronizzazione completa del nuovo sito con il sito legacy.
  7. Avvia i carichi di lavoro e i servizi.
  8. Quando non hai più bisogno del sito legacy come opzione di riserva, ritiralo.

Come per l'approccio di manutenzione pianificata, l'approccio di replica continua pone la maggior parte del carico sul lato operativo.

Sì (scrittura e lettura)

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

Questo approccio è riassunto come segue:

  1. Esegui il refactoring dei carichi di lavoro e dei servizi per scrivere dati sia sul sito precedente sia nel nuovo sito e leggere dal sito precedente.
  2. Identifica i dati scritti prima di abilitare le scritture nel nuovo sito e copiali dal sito precedente a quello nuovo. Insieme al precedente refactoring, questo garantisce l'allineamento dei datastore.
  3. Esegui controlli di convalida e coerenza dei dati per confrontare i dati del sito precedente con quelli del nuovo sito.
  4. Sposta le operazioni di lettura dal sito precedente a quello nuovo.
  5. Esegui un'altra serie di controlli di convalida e coerenza dei dati per confrontare i dati del sito precedente con quelli del nuovo sito.
  6. Disattiva la scrittura nel sito precedente.
  7. Quando non hai più bisogno del sito legacy 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 operazioni 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 mediante il refactoring dei carichi di lavoro e dei servizi in modo che utilizzino un microservizio di accesso ai dati. Questo microservizio scalabile diventa l'unico punto di ingresso per il livello di archiviazione dei dati e funge da proxy per quel livello. Tra gli approcci discussi qui, questo ti offre la massima flessibilità, perché puoi eseguire il refactoring del componente senza influire su altri componenti dell'architettura e senza richiedere una finestra di migrazione completa.

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 sul solo microservizio di accesso ai dati, invece di dover refactoring di tutti i carichi di lavoro e servizi che accedono al livello di archiviazione dei dati. Questo approccio è riassunto come segue:

  1. Esegui il refactoring del microservizio di accesso ai dati per scrivere dati sia nel sito legacy che nel nuovo sito. Le letture vengono eseguite sul sito precedente.
  2. Identifica i dati scritti prima di abilitare le scritture nel nuovo sito e copiali dal sito precedente a quello nuovo. Insieme al precedente refactoring, questo garantisce l'allineamento dei datastore.
  3. Esegui controlli di convalida e coerenza dei dati 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 controlli di convalida e coerenza dei dati confrontando i dati del sito precedente con quelli del nuovo sito.
  6. Esegui il refactoring del microservizio di accesso ai dati in modo che scriva solo nel nuovo sito.
  7. Quando non hai più bisogno del sito legacy come opzione di riserva, ritiralo.

Come l'approccio Y (scrittura e lettura), l'approccio del microservizio di accesso ai dati pone la maggior parte del carico sul lato dello sviluppo. Tuttavia, è notevolmente più leggero rispetto all'approccio Y (scrittura e lettura), perché le attività di refactoring sono incentrate sul microservizio di accesso ai dati.

Passaggio 5: prepara il trasferimento

Per un trasferimento di grandi dimensioni o un trasferimento con dipendenze significative, è importante capire come utilizzare il prodotto di trasferimento. I clienti in genere devono procedere nel seguente modo:

  1. Determinazione del prezzo e stima del ROI. Questo passaggio fornisce molte opzioni per aiutare il processo decisionale.
  2. Test funzionali. In questo passaggio, confermi che il prodotto è stato configurato correttamente e che la connettività di rete (ove applicabile) funziona. Puoi anche verificare di poter spostare un campione rappresentativo dei tuoi dati (inclusi i passaggi di non trasferimento associati, come lo spostamento di un'istanza VM) nella destinazione.

    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 questa fase includono:

    • Conferma di poter installare e utilizzare il trasferimento.
    • Individua i potenziali problemi che interrompono il progetto che bloccano lo spostamento dei dati (ad esempio le route di rete) o le tue operazioni (ad esempio l'addestramento necessario per un passaggio non di trasferimento).
  3. Test delle prestazioni. In questo passaggio, esegui un trasferimento su un grande campione dei tuoi dati (in genere il 3-5%) dopo che le risorse di produzione sono state allocate per:

    • Conferma di poter consumare tutte le risorse allocate e di poter ottenere le velocità previste.
    • Individuare e correggere i colli di bottiglia (ad esempio un sistema di archiviazione di origine lento).

Passaggio 6: verifica dell'integrità del trasferimento

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

  • Abilita il controllo delle versioni e il backup nella tua destinazione per limitare i danni causati da 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 base del sistema di archiviazione di origine sottostante, fino allo 0,0001%, comporta comunque una perdita di dati di migliaia di file e gigabyte. In genere, le applicazioni in esecuzione all'origine tollerano già questi errori, nel qual caso non è necessaria un'ulteriore convalida. In alcuni scenari eccezionali (ad esempio l'archivio a lungo termine), è necessaria una convalida maggiore prima che l'eliminazione dei dati dall'origine sia considerata sicura.

A seconda dei requisiti della tua applicazione, ti consigliamo di eseguire alcuni test di integrità dei dati dopo il completamento del trasferimento per assicurarti che l'applicazione continui a funzionare come previsto. Molti prodotti di trasferimento dispongono di controlli integrati di integrità dei dati. Tuttavia, a seconda del tuo profilo di rischio, potresti voler eseguire un ulteriore insieme di controlli sui dati e sulle app che li leggono prima di eliminare i dati dall'origine. Ad esempio, potresti voler confermare se un checksum che hai registrato e calcolato in modo indipendente corrisponde ai dati scritti nella destinazione oppure confermare che un set di dati utilizzato dall'applicazione sia stato trasferito correttamente.

Passaggi successivi