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

Last reviewed 2024-11-13 UTC

Per molti clienti, il primo passo per adottare un prodotto Google Cloud è inserire i propri 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. Sebbene questi passaggi possano richiedere lo stesso tempo del trasferimento stesso, questi preparativi possono contribuire a ridurre al minimo le interruzioni delle operazioni della tua attività durante il trasferimento.

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

Che cos'è il trasferimento dei 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 negli oggetti.

Il trasferimento dei dati non è così semplice come sembra

È allettante pensare al trasferimento dei dati come a una sessione FTP gigante, 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, ad esempio:

  • Elaborare un piano di trasferimento che tenga conto dei tempi amministrativi, inclusi i tempi per decidere un'opzione di trasferimento, ottenere le approvazioni e gestire 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 lo spostamento dei dati può comportare.
  • Scegliere lo strumento di trasferimento giusto in base a risorse, costi, tempi e altre considerazioni sul progetto.
  • Superare le sfide del 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 vengano trasferiti correttamente.

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

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

Passaggio 1: crea il tuo team

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

  • Attivazione delle risorse necessarie per un trasferimento: amministratori di archiviazione, IT e rete, uno sponsor esecutivo e altri consulenti (ad esempio, un team dell'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 leader, un project manager (per l'esecuzione e il monitoraggio del progetto), un team di ingegneria e un team di ricezione e spedizione in loco (per ricevere l'hardware dell'appliance)

È fondamentale identificare chi è responsabile delle attività precedenti per il tuo progetto di trasferimento e includerlo nelle riunioni di pianificazione e decisione, se opportuno. Una pianificazione organizzativa inadeguata è spesso la causa del mancato trasferimento delle iniziative.

Raccogliere i requisiti del progetto e l'input di questi stakeholder può essere difficile, ma creare un piano e stabilire ruoli e responsabilità chiari ripaga. Non puoi sapere tutti i dettagli dei tuoi dati. La creazione di un team ti consente di comprendere meglio le esigenze dell'attività. È una best practice identificare 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 prima i requisiti per il trasferimento dei dati e poi 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 vietano 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 trasferibili, determina dove trasferire ciascun set di dati.
    • Registra l'opzione di archiviazione selezionata per archiviare i tuoi 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 esecuzione, Cloud Storage è un'opzione di archiviazione scalabile e durevole.
    • Comprendi 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'origine o diverso?
    • Determina se devi trasferire i dati in modo continuativo.
  4. Per i set di dati spostabili, determina quali risorse sono disponibili per spostarli.
    • Tempistiche: quando deve essere completato il trasferimento?
    • Costo: qual è il budget disponibile per la squadra e i costi di trasferimento?
    • Persone: chi è disponibile per eseguire il trasferimento?
    • Larghezza di banda (per i trasferimenti online): quanta 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, ti consigliamo di valutare se è possibile migliorare una parte del tuo modello IT, come la governance, l'organizzazione e la sicurezza dei dati.

Il tuo modello di sicurezza

A molti membri del team di trasferimento potrebbero essere assegnati nuovi ruoli nella tua organizzazione Google Cloud nell'ambito del progetto di trasferimento dei dati. La pianificazione del trasferimento dei dati è un ottimo momento per rivedere le tue autorizzazioni Identity and Access Management (IAM) e le best practice per utilizzare IAM in modo sicuro. Questi problemi possono influire sul modo in cui concedi l'accesso al tuo spazio di archiviazione. Ad esempio, potresti imporre 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 Google Cloud organizzazione

La strutturazione dei dati su Google Cloud dipende da come prevedi di utilizzare Google Cloud. L'archiviazione dei dati nello stesso Google Cloud progetto in cui esegui l'applicazione potrebbe funzionare, ma potrebbe non essere ottimale dal punto di vista della gestione. Alcuni dei tuoi sviluppatori potrebbero non avere il privilegio di 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. Pertanto, ti consigliamo di conservare l'intero set di dati di produzione in unGoogle Cloud progetto separato e poi utilizzare un account di servizio per consentire l'accesso ai dati da ogni progetto di applicazione.

Google Cloud è organizzato in base ai progetti. I progetti possono essere raggruppati in cartelle e le cartelle possono essere raggruppate nella 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 fornitori di object store.

Per le best practice per strutturare un'organizzazione Google Cloud , vedi Decidere una gerarchia delle risorse per la Google Cloud landing zone.

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
    • Il traffico in entrata verso Cloud Storage è gratuito. Tuttavia, se ospiti i tuoi dati su un provider di cloud pubblico, puoi aspettarti di pagare un costo 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 cloud provider.
    • Se i tuoi dati sono ospitati in un data center privato che gestisci, potresti anche sostenere costi aggiuntivi per la configurazione di una maggiore larghezza di banda per Google Cloud.
  • Costi di archiviazione e operazione per Cloud Storage durante e dopo il trasferimento dei dati
  • Costi del prodotto (ad esempio, un Transfer Appliance)
  • Costi del personale per la creazione del team e l'acquisizione di supporto logistico

Tempo di trasferimento

Poche cose nel computing evidenziano i limiti hardware delle reti come il trasferimento di grandi quantità di dati. Idealmente, puoi trasferire 1 GB in 8 secondi su una rete da 1 Gbps. Se aumenti le dimensioni fino a un set di dati enorme (ad esempio 100 TB), il tempo di trasferimento è di 12 giorni. Il trasferimento di enormi set di dati può mettere alla prova i limiti della tua infrastruttura e potenzialmente causare problemi per la tua attività.

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

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

Potresti non voler trasferire set di dati di grandi dimensioni dalla rete aziendale durante le ore di lavoro di punta. Se il trasferimento sovraccarica la rete, nessun altro sarà in grado di completare il lavoro necessario o mission critical. Per questo motivo, il team di trasferimento deve tenere conto del fattore tempo.

Una volta trasferiti i dati in Cloud Storage, puoi utilizzare diverse 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 provider cloud, Google esegue il provisioning della connessione tra i data center dei fornitori di servizi cloud, senza richiedere alcuna configurazione da parte tua.

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

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

Quando valuti questi approcci, è utile considerare le tue esigenze di connettività a lungo termine. Potresti concludere che l'acquisizione di larghezza di banda solo a scopo di trasferimento è troppo costosa, ma se consideri l'utilizzo a lungo termine di Google Cloud e le esigenze di rete della tua organizzazione, l'investimento potrebbe valere la pena. Per saperne di più su come connettere le tue reti a Google Cloud, consulta Scegliere una Connettività di rete Connectivity.

Se scegli un approccio che prevede il trasferimento di dati tramite internet pubblico, ti consigliamo di verificare con l'amministratore della sicurezza se le norme aziendali vietano tali trasferimenti. Inoltre, verifica 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 rete di produzione.

Trasferimento online e offline

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

Per aiutarti a prendere questa decisione, il seguente grafico mostra anche alcune velocità di trasferimento per varie dimensioni del set di dati e larghezze di banda. In questi calcoli è integrato un certo overhead di gestione.

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

Come accennato in precedenza, potrebbe essere necessario valutare se il costo per ottenere latenze inferiori per il trasferimento dei dati (ad esempio l'acquisizione di larghezza di banda di 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.

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.

L'origine della migrazione dei dati Scenario Prodotti suggeriti
Un altro provider cloud (ad esempio Amazon Web Services o Microsoft Azure) per Google Cloud — Storage Transfer Service
Da Cloud Storage a Cloud Storage (due bucket diversi) — Storage Transfer Service
Il tuo data center privato per Google Cloud Larghezza di banda sufficiente per rispettare la scadenza del progetto Comando gcloud storage
Il tuo data center privato per Google Cloud Larghezza di banda sufficiente per rispettare la scadenza del progetto Storage Transfer Service for On Premises Data
Il tuo data center privato per 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 i 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. Sebbene gcloud storage supporti il caricamento di oggetti fino alle dimensioni massime 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 a 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 necessità o durante le sessioni della riga di comando dagli utenti.
  • Stai trasferendo solo pochi file o file molto grandi oppure entrambi.
  • Stai utilizzando l'output di un programma (trasmettendo l'output in streaming a Cloud Storage).
  • Devi monitorare una directory con un numero moderato di file e sincronizzare gli 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 for On Premises Data consente i trasferimenti dall'archiviazione del file system di rete (NFS) 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 nella sezione Scegliere tra le opzioni di trasferimento di Google. Dispone anche di un'interfaccia utente grafica gestita; anche gli utenti non 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 un'ampia base di utenti interni che potrebbero trovare difficile l'utilizzo di uno strumento a riga di comando.
  • Devi disporre di una solida funzionalità di segnalazione degli errori e di un registro di tutti i file e gli oggetti che vengono spostati.
  • 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.

Configuri Storage Transfer Service for On Premises Data installando un software on-premise (noto come agenti) sui computer del tuo data center.

Dopo aver configurato Storage Transfer Service, puoi avviare i trasferimenti nella consoleGoogle Cloud fornendo una directory di origine, un bucket di destinazione e un orario o una pianificazione. Storage Transfer Service esegue la scansione ricorsiva di sottodirectory e 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 ritenta automaticamente un trasferimento quando rileva errori temporanei. Durante 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 tabulazione (TSV) con un record completo di tutti i file modificati e di tutti i messaggi di errore ricevuti. Gli agenti sono tolleranti agli errori, quindi se un agente smette di funzionare, il trasferimento continua con gli agenti rimanenti. Gli agenti si aggiornano e si riparano automaticamente, quindi non devi preoccuparti di applicare patch alle versioni più recenti o di riavviare il processo se si interrompe 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 visualizzare gli stessi montaggi del Network File System (NFS) nello stesso modo (stessi percorsi relativi). Questa configurazione è un requisito per il funzionamento del prodotto.
  • Più agenti significano più velocità. Poiché i trasferimenti vengono parallelizzati 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 workload. Gli altri workload 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 causare errori che richiedono una revisione. Storage Transfer Service ti consente di visualizzare un campione degli errori riscontrati 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 i tentativi. Questi errori potrebbero essere causati dall'esecuzione di app che scrivevano nell'origine durante il trasferimento oppure potrebbero rivelare un problema che richiede la risoluzione dei problemi (ad esempio, un errore di autorizzazioni).
  • 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 informano quando gli agenti non funzionano o richiedono attenzione. Intervenire in caso di errori dell'agente è importante per i trasferimenti che richiedono diversi giorni o settimane, in modo da evitare rallentamenti o interruzioni significativi che possono ritardare la cronologia del progetto.

Transfer Appliance per trasferimenti più grandi

Per i trasferimenti su larga scala (soprattutto quelli con larghezza di banda di rete limitata), Transfer Appliance è un'ottima opzione, soprattutto quando non è disponibile una connessione di rete veloce 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 connettere gli elettrodomestici alla tua rete.

Con questa opzione, tieni presente quanto segue:

  • Transfer Appliance richiede la possibilità di 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 superiore con Transfer Appliance rispetto a quella 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 online di 100 TB di dati richiede più di 10 giorni. Se questo tasso è accettabile, un bonifico online è probabilmente una buona soluzione per le tue esigenze. Se hai solo una connessione a 100 Mbps (o peggiore 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.

L'acquisizione di un Transfer Appliance è semplice. Nella consoleGoogle Cloud , richiedi un Transfer Appliance, indica la quantità di dati che hai e poi Google spedisce una o più appliance alla località che hai richiesto. Ti viene concesso un numero di 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 codificato in 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, nel qual 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 quando li trasferisci da un altro cloud pubblico.

Se vuoi spostare 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 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 per prodotto.

Prodotto Dati at-rest Dati in transito Accesso al prodotto di trasferimento
Transfer Appliance Tutti i dati sono criptati at-rest. 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 richieste per accedere a Cloud Storage, che è criptato a riposo. 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 for On Premises Data Chiavi di accesso richieste per accedere a Cloud Storage, che è criptato a 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 risorse nonGoogle Cloud (ad esempio, Amazon S3). Per accedere a Cloud Storage, che è criptato a riposo, sono necessarie chiavi di accesso. 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 origine e di modifica degli oggetti per qualsiasi bucket Cloud Storage.

Per ottenere miglioramenti della 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 contribuire a proteggere i tuoi dati. In generale, ti consigliamo di coinvolgere il tuo team di sicurezza per assicurarti che il piano di trasferimento soddisfi i requisiti aziendali e normativi.

Prodotti di trasferimento di terze parti

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

Passaggio 4: valuta gli approcci di migrazione dei dati

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

  1. Trasferisci i dati dal sito legacy al nuovo sito.
  2. Risolvi eventuali problemi di integrazione dei dati che si presentano, ad esempio la sincronizzazione degli stessi dati da più origini.
  3. Convalida la migrazione dei dati.
  4. Promuovi il nuovo sito in modo che diventi la copia principale.
  5. Quando non hai più bisogno del sito legacy come opzione di riserva, ritiralo.

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

  • Quanti dati devi migrare?
  • Con quale frequenza cambiano questi dati?
  • Puoi permetterti il tempo di inattività rappresentato da una finestra di cutover 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 seguenti sezioni presentano quattro approcci per la migrazione dei dati:

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

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

L'approccio ai microservizi di 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 e utilizzare l'approccio dei microservizi di accesso ai dati.

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

Grafico a barre in cui ogni barra mostra i valori relativi di 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 (chiamato anche migrazione una tantum o big bang migration) è ideale se i tuoi carichi di lavoro possono permettersi una finestra di cutover. È pianificata nel senso che puoi programmare quando si verifica la finestra di transizione.

Con questo approccio, la migrazione prevede i seguenti passaggi:

  1. Copia i dati del sito legacy nel nuovo sito. Questa copia iniziale riduce al minimo la finestra di trasferimento. Dopo questa copia iniziale, devi copiare solo i dati modificati durante questa finestra.
  2. Esegui controlli di convalida e coerenza dei dati per confrontare i dati del sito legacy con i dati 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 workload e servizi.
  7. Quando non hai più bisogno del sito legacy come opzione di riserva, ritiralo.

L'approccio di manutenzione pianificata pone la maggior parte del carico sul lato delle operazioni, perché è necessario un refactoring minimo di workload e servizi.

Replica continua

Poiché non tutti i workload possono permettersi una lunga finestra di cutover, puoi basarti sull'approccio di manutenzione pianificata fornendo un meccanismo di replica continua dopo i passaggi iniziali di copia e convalida. Quando progetti un meccanismo di questo tipo, devi anche tenere conto della velocità con cui le modifiche vengono applicate ai tuoi dati; potrebbe essere difficile mantenere sincronizzati due sistemi.

L'approccio di replica continua (chiamato anche migrazione online o migrazione a goccia) è più complesso dell'approccio di manutenzione pianificata. Tuttavia, l'approccio di replica continua riduce al minimo il tempo 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 legacy nel nuovo sito. Questa copia iniziale riduce al minimo la finestra di trasferimento; dopo la copia iniziale, devi copiare solo i dati modificati durante questa finestra.
  2. Esegui controlli di convalida e coerenza dei dati per confrontare i dati del sito legacy con i dati copiati nel nuovo sito.
  3. Configura un meccanismo di replica continua dal sito legacy al nuovo sito.
  4. Arresta i workload e i servizi che hanno accesso ai dati da migrare (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 workload e 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 delle operazioni.

Y (scrittura e lettura)

Se i tuoi carichi di lavoro hanno requisiti di alta disponibilità rigidi e non puoi permetterti i tempi di inattività rappresentati da una finestra di cutover, devi adottare un approccio diverso. Per questo scenario, puoi utilizzare un approccio che in questo documento viene definito Y (scrittura e lettura), che è una forma di migrazione parallela. Con questo approccio, il workload scrive e legge i dati sia nel sito legacy che nel nuovo sito durante la migrazione. (La lettera Y viene utilizzata qui come rappresentazione 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 legacy sia nel nuovo sito e per leggere dal sito legacy.
  2. Identifica i dati scritti prima di aver abilitato le scritture nel nuovo sito e copiali dal sito legacy al nuovo sito. Insieme al refactoring precedente, questo garantisce l'allineamento dei datastore.
  3. Esegui controlli di convalida e coerenza dei dati che confrontano i dati del sito legacy con quelli del nuovo sito.
  4. Passa dalle operazioni di lettura dal sito legacy al nuovo sito.
  5. Esegui un altro ciclo di controlli di convalida e coerenza dei dati per confrontare i dati nel sito legacy con quelli del nuovo sito.
  6. Disattiva la scrittura nel sito legacy.
  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 delle operazioni al lato dello sviluppo a causa dei numerosi 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 eseguendo il refactoring dei carichi di lavoro e dei servizi per utilizzare un microservizio di accesso ai dati. Questo microservizio scalabile diventa l'unico punto di accesso al livello di archiviazione dei dati e funge da proxy per questo livello. Tra gli approcci descritti qui, questo offre la massima flessibilità, perché puoi eseguire il refactoring di questo componente senza influire sugli altri componenti dell'architettura e senza richiedere una finestra di cutover.

L'utilizzo di un microservizio di accesso ai dati è molto simile all'approccio Y (scrittura e lettura). La differenza è che gli sforzi 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 dati. Questo approccio è riassunto come segue:

  1. Esegui il refactoring del microservizio di accesso ai dati per scrivere i dati sia nel sito legacy che nel nuovo sito. Le letture vengono eseguite sul sito legacy.
  2. Identifica i dati scritti prima di aver abilitato le scritture nel nuovo sito e copiali dal sito legacy al nuovo sito. Insieme al refactoring precedente, questo garantisce l'allineamento dei datastore.
  3. Esegui controlli di convalida e coerenza dei dati confrontando i dati del sito legacy con quelli del nuovo sito.
  4. Esegui il refactoring del microservizio di accesso ai dati per leggere 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 per scrivere 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 basato sui microservizi di accesso ai dati pone la maggior parte del carico sul lato dello sviluppo. Tuttavia, è molto più leggero rispetto all'approccio Y (scrittura e lettura), perché gli sforzi di refactoring si concentrano sul microservizio di accesso ai dati.

Passaggio 5: prepararsi al trasferimento

Per un trasferimento di grandi dimensioni o con dipendenze significative, è importante capire come utilizzare il prodotto di trasferimento. I clienti in genere seguono 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) funziona. Inoltre, verifica di poter spostare un campione rappresentativo dei tuoi dati (inclusi i passaggi di trasferimento non accompagnati, come lo spostamento di un'istanza VM) nella destinazione.

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

    • Conferma di poter installare ed eseguire il trasferimento.
    • Identifica i potenziali problemi che bloccano il progetto e il movimento dei dati (ad esempio, le route di rete) o le tue operazioni (ad esempio, la formazione necessaria per un passaggio non di trasferimento).

  3. Test delle prestazioni. In questo passaggio, esegui un trasferimento su un campione di grandi dimensioni dei tuoi dati (in genere il 3-5%) dopo che le risorse di produzione sono state allocate per eseguire le seguenti operazioni:

    • Conferma di poter utilizzare tutte le risorse allocate e di poter raggiungere le velocità che ti aspetti.
    • Individua e risolvi i colli di bottiglia (ad esempio, il sistema di archiviazione dell'origine lento).

Passaggio 6: garantisci l'integrità del trasferimento

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

  • Abilita il controllo delle versioni e il backup nella 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 pari a 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 a questi errori, nel qual caso non è necessaria una convalida aggiuntiva. In alcuni scenari eccezionali (ad esempio, l'archivio a lungo termine), è necessaria una maggiore convalida prima che venga considerato sicuro eliminare i dati dall'origine.

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 hanno controlli integrati per l'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 eliminarli dall'origine. Ad esempio, potresti voler verificare se un checksum che hai 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: