Esegui la migrazione a Google Cloud: trasferisci 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 propri 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 comporta 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 lo stesso tempo del trasferimento stesso, questi interventi possono aiutare 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 del presente documento, il trasferimento di dati è il processo di spostamento dei dati senza trasformarli, ad esempio lo spostamento di file così come sono in oggetti.

Il trasferimento di dati non è semplice come sembra

Si può avere la tentazione di considerare il trasferimento di dati come una gigantesca sessione FTP, in cui si mettono i file da un lato e si attendono che escano dall'altro lato. Tuttavia, nella maggior parte degli ambienti aziendali, il processo di trasferimento coinvolge molti fattori, tra cui:

  • Creare un piano di trasferimento che tenga conto del tempo amministrativo, incluso il tempo per decidere un'opzione di trasferimento, ottenere l'approvazione e gestire problemi imprevisti.
  • 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 che sono preoccupati del valore e delle interruzioni che possono causare il trasferimento dei dati.
  • Scelta dello strumento di trasferimento giusto in base a risorse, costi, tempo e altre considerazioni relative al progetto.
  • Superare le sfide del trasferimento di 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 mentre sono in transito e garantire che i dati vengano trasferiti correttamente.

Questo documento ha lo scopo di 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: riunire il team

In genere, la pianificazione di un trasferimento richiede personale con i ruoli e responsabilità seguenti:

  • Attivazione delle risorse necessarie per un trasferimento: amministratori dello spazio 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 su chi è autorizzato a trasferire determinati dati), consulenti legali (per le normative relative ai dati) e un amministratore della sicurezza (per le norme interne relative alla 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 detiene le precedenti responsabilità per il progetto di trasferimento e includerli nelle riunioni di pianificazione e decisionali, quando opportuno. Una pianificazione organizzativa scadente è spesso la causa di un calo delle iniziative di trasferimento.

Raccogliere i requisiti del progetto e il contributo di questi stakeholder può essere difficile, ma creare un piano e stabilire ruoli e responsabilità chiari ripaga. Non è facile conoscere tutti i dettagli dei tuoi dati. L'assemblaggio di un team offre maggiori informazioni sulle esigenze dell'azienda. È una best practice identificare potenziali problemi prima di investire tempo, denaro e risorse per completare i trasferimenti.

Passaggio 2: raccolta dei requisiti e delle risorse disponibili

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

  1. Identifica quali set di dati devi spostare.
    • Seleziona strumenti come Data Catalog per organizzare i tuoi dati in raggruppamenti logici che vengono spostati e utilizzati insieme.
    • Collabora con i team all'interno della tua organizzazione per convalidare o aggiornare questi raggruppamenti.
  2. Identifica quali set di dati puoi spostare.
    • Valuta se i fattori normativi, di sicurezza o di altro tipo proibiscono 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 per l'orchestrazione del flusso di lavoro come Cloud Composer.
  3. Per i set di dati mobili, 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 l'avvio delle applicazioni, Cloud Storage è un'opzione di archiviazione scalabile e durevole.
    • Comprendere quali criteri di accesso ai dati devono essere gestiti dopo la migrazione.
    • Determina se devi archiviare questi dati in regioni specifiche.
    • Pianifica come strutturare questi dati a destinazione. Ad esempio, sarà uguale o diverso alla fonte?
    • Determina se devi trasferire i dati in modo continuativo.
  4. Per i set di dati mobili, determina quali risorse sono disponibili per spostarli.
    • Data/ora: quando deve essere completato il trasferimento?
    • Costo: qual è il budget disponibile per il team e i costi del 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 la governance dei dati, l'organizzazione e la sicurezza.

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 di dati è il momento ideale per esaminare le autorizzazioni di Identity and Access Management (IAM) e le best practice per l'utilizzo sicuro di IAM. Questi problemi possono influire sul modo in cui concedi l'accesso al tuo spazio di archiviazione. Ad esempio, potresti applicare limiti rigidi 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

Il modo in cui strutturi i tuoi 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 dei tuoi sviluppatori potrebbero non avere i privilegi necessari per 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. Di conseguenza, potresti voler mantenere 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 ogni progetto di applicazione.

Google Cloud è organizzato in base ai progetti. I progetti possono essere raggruppati in cartelle e le cartelle 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 archivi di oggetti.

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

Passaggio 3. Valutazione delle opzioni di trasferimento

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

  • Costo
  • Data/ora trasferimento
  • Opzioni di trasferimento offline e online
  • Strumenti e tecnologie per il 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 di pagare un addebito per il traffico in uscita e potenziali costi di archiviazione (ad esempio, le 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 cui operi, ti potrebbero venire addebitati dei costi aggiuntivi per l'impostazione di una maggiore larghezza di banda in Google Cloud.
  • I costi operativi e di archiviazione di Cloud Storage durante e dopo il trasferimento dei dati
  • Costi del prodotto (ad esempio, Transfer Appliance)
  • Costi del personale per l'assemblaggio del team e l'acquisizione di assistenza logistica

Data/ora trasferimento

Pochi aspetti dell'informatica evidenziano le limitazioni hardware delle reti come il trasferimento di grandi quantità di dati. Idealmente, puoi trasferire 1 GB in otto secondi su una rete da 1 Gbps. Se fai lo scale up per un set di dati enorme (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 causare potenziali problemi per la 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. È inclusa anche un'efficienza di larghezza di banda effettiva, quindi i risultati sono più realistici.

Potresti non voler trasferire grandi set di dati dalla rete aziendale durante le ore di punta di lavoro. 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.

Aumento della larghezza di banda della rete

Le modalità di aumento della larghezza di banda della rete dipendono da come ti connetti a Google Cloud.

In un trasferimento da cloud a cloud tra Google Cloud e altri cloud provider, Google esegue il provisioning della connessione tra i data center dei fornitori di servizi cloud, senza bisogno di alcuna configurazione da parte tua.

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

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

Nel valutare questi approcci, è utile considerare le tue esigenze di connettività a lungo termine. Potremmo concludere che acquisire larghezza di banda solo a scopo di trasferimento è proibitivo in termini di costi, ma se si tiene conto dell'uso a lungo termine di Google Cloud e delle esigenze della rete all'interno dell'organizzazione, l'investimento potrebbe valere la pena. Per ulteriori informazioni su come connettere le tue reti a Google Cloud, vedi Scegliere un prodotto per la connettività di rete.

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

Trasferimento online e offline

Una decisione fondamentale è decidere se utilizzare un processo offline o online per il trasferimento dei dati. In altre parole, devi scegliere tra il trasferimento su una rete (Cloud Interconnect o la rete internet pubblica) oppure tramite l'utilizzo di hardware di archiviazione.

Per aiutarti con questa decisione, forniamo un calcolatore dei trasferimenti che ti aiuterà a stimare le differenze in termini di tempi e costi tra queste due opzioni. Il grafico seguente mostra anche alcune velocità di trasferimento per diverse dimensioni e larghezze di banda del set di dati. In questi calcoli è incorporata una certa quantità di overhead per la gestione.

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

Come indicato in precedenza, potresti dover considerare 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 dell'investimento per la tua organizzazione.

Opzioni disponibili da Google

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

Scelta tra le opzioni di trasferimento di Google

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

Da dove sposti i dati Scenario Prodotti consigliati
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
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 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 piccoli trasferimenti 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 enterprise, da un data center privato o da un altro cloud provider a Google Cloud. Sebbene gcloud storage supporti il caricamento di oggetti fino alla dimensione massima degli oggetti di 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 grandi trasferimenti di dati on-premise.

Il comando gcloud storage è particolarmente utile nei seguenti scenari:

  • I trasferimenti devono essere eseguiti secondo le esigenze o durante le sessioni della riga di comando degli utenti.
  • Stai trasferendo pochi file, file molto grandi o entrambi.
  • Stai consumando l'output di un programma (flusso di output in Cloud Storage).
  • Devi controllare una directory con un numero moderato di file e sincronizzare gli eventuali aggiornamenti con latenze molto basse.

Storage Transfer Service per grandi trasferimenti 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 le copie complete o le copie incrementali e funziona su tutte le opzioni di trasferimento elencate in precedenza in Scegliere le opzioni di trasferimento di Google. Dispone inoltre di una Graphic User Interface gestita; anche gli utenti non esperti di tecnologia (dopo la configurazione) possono utilizzarla per spostare dati.

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

  • La larghezza di banda disponibile è sufficiente per spostare i volumi di dati (vedi il Calcolatore Data Transfer di Google Cloud).
  • Supporti un'ampia base di utenti interni che potrebbero trovare uno strumento a riga di comando difficile da usare.
  • Hai bisogno di un buon rapporto 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 del limite di larghezza di banda specificato dall'utente).
  • Vuoi eseguire trasferimenti ricorrenti in base a una pianificazione.

Per configurare Storage Transfer Service per i dati on-premise, devi installare un software on-premise (noto come agenti) sui computer del 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 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 di nuovo automaticamente un trasferimento quando rileva errori temporanei. Mentre i trasferimenti sono in esecuzione, puoi monitorare quanti file vengono spostati e la velocità di trasferimento complessiva e puoi visualizzare esempi di errore.

Quando Storage Transfer Service completa un trasferimento, genera un file delimitato da tabulazioni (TSV) con un record completo di tutti i file interessati e gli 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. Inoltre, gli agenti si aggiornano autonomamente e si ripristinano in autonomia, pertanto non devi preoccuparti di applicare patch alle ultime versioni o di riavviare il processo se il problema si interrompe a causa di un problema imprevisto.

Aspetti da considerare quando si utilizza Storage Transfer Service:

  • Utilizza la stessa configurazione dell'agente su ogni macchina. Tutti gli agenti devono vedere gli stessi montaggi di Network File System (NFS) nello stesso modo (stessi percorsi relativi). Questa configurazione è un requisito per il funzionamento del prodotto.
  • Più agenti si traduce in una maggiore velocità. Poiché i trasferimenti sono automaticamente parallelizzati 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 consentono di proteggere i carichi di lavoro. Gli altri 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 sugli SLA (accordi sul livello del servizio).
  • Pianifica il tempo per la revisione degli errori. I trasferimenti di grandi dimensioni possono spesso generare errori nella richiesta di revisione. Storage Transfer Service consente di visualizzare un esempio 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 che sono rimasti anche dopo nuovi 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 a lunga esecuzione. Storage Transfer Service consente a Monitoring di monitorare l'integrità e la velocità effettiva degli agenti, in modo da poter impostare avvisi che ti informano quando gli agenti non sono disponibili o richiedono attenzione. Intervenire in caso di errori degli agenti è importante 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 di maggiori dimensioni

Per 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 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 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 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 quella online.
  • Transfer Appliance è disponibile solo in alcuni paesi.

I due criteri principali da considerare per Transfer Appliance sono il costo e la velocità. Con una connettività di rete ragionevole (ad es. 1 Gbps), il trasferimento online di 100 TB di dati richiede più di 10 giorni. Se questo tasso è accettabile, un trasferimento online è probabilmente una buona soluzione per le tue esigenze. Se hai 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.

L'acquisizione di Transfer Appliance è semplice. Nella console Google Cloud, richiedi Transfer Appliance, indichi la quantità di dati di cui disponi, quindi Google spedisce una o più appliance alla località richiesta. Hai a disposizione alcuni giorni per trasferire i dati all'appliance ("acquisizione dei dati") e rispedirli a Google.

Storage Transfer Service per 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 i dati da Amazon S3 in 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 del file e l'hash sono disponibili dal sito web di origine. In caso contrario, devi disporre dell'accesso locale ai file. In tal caso, potrebbe essere più semplice utilizzare il comando gcloud storage, come descritto in precedenza.

Se hai in atto un trasferimento, Storage Transfer Service è un ottimo modo per ottenere 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'aspetto 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. Nella tabella che segue vengono descritti questi aspetti della sicurezza per prodotto.

Product Dati at-rest Dati in transito Accesso per trasferire il prodotto
Transfer Appliance Tutti i dati at-rest sono criptati. I dati sono protetti con chiavi gestite dal cliente. Chiunque può ordinare un'appliance, ma per utilizzarla deve poter 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 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 necessarie per 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 affinché l'account di servizio possa accedere alle autorizzazioni di modifica dell'origine e degli oggetti per tutti i bucket Cloud Storage.

Per ottenere miglioramenti di base per la sicurezza, i trasferimenti online a Google Cloud tramite 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 controllati da te possono aiutarti a proteggere i tuoi dati. In genere, consigliamo di coinvolgere il team di sicurezza per garantire che il piano di trasferimento soddisfi i requisiti normativi e aziendali.

Prodotti per il trasferimento di terze parti

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

Passaggio 4: valutazione degli 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 la sincronizzazione degli stessi dati da più origini.
  3. Convalida 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.

Il tuo approccio alla migrazione dei dati dovrebbe essere basato sulle seguenti domande:

  • Quanti dati servono per la migrazione?
  • Con quale frequenza cambiano questi dati?
  • Puoi permetterti il tempo di inattività rappresentato da una finestra di migrazione completa durante la migrazione dei dati?
  • Qual è il tuo attuale modello di coerenza dei dati?

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

Le seguenti sezioni presentano quattro approcci alla migrazione dei dati:

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

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

L'approccio basato sui 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 la tua infrastruttura e utilizzare l'approccio del microservizio di accesso ai dati.

Il seguente grafico illustra le dimensioni delle rispettive 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à, sforzo di refactoring e dimensioni delle finestre di migrazione completa per ciascuno dei 4 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 carichi di lavoro possono permettersi una finestra di cut-over. È programmata in modo da poter pianificare quando si verifica il periodo di cut-over.

In questo approccio, la migrazione prevede i seguenti passaggi:

  1. Copia i dati del sito precedente nel nuovo sito. Questa copia iniziale riduce al minimo la finestra di migrazione completa; dopo questa copia iniziale, devi copiare solo i dati che sono stati modificati durante questa finestra.
  2. Esegui controlli di convalida e coerenza dei dati per confrontare i dati del sito legacy 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 apportate dopo la copia iniziale.
  5. Esegui il refactoring dei carichi di lavoro e dei servizi in modo che utilizzino il nuovo sito.
  6. Avvia i tuoi carichi di lavoro e i tuoi servizi.
  7. Quando non hai più bisogno del sito precedente come opzione di riserva, ritiralo.

L'approccio della manutenzione pianificata grava 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, puoi basarti sull'approccio alla manutenzione pianificata fornendo un meccanismo di replica continua dopo le fasi iniziali di copia e convalida. Quando progetti un meccanismo come questo, devi anche prendere in considerazione la frequenza con cui le modifiche vengono applicate ai tuoi dati: può essere difficile mantenere due sistemi sincronizzati.

La replica continua è più complessa di quella pianificata. Tuttavia, l'approccio alla replica continua riduce al minimo il tempo necessario per la finestra di migrazione completa richiesta, in quanto riduce al minimo la quantità di dati da sincronizzare. La sequenza per una migrazione della replica continua è la seguente:

  1. Copia i dati del sito precedente nel nuovo sito. Questa copia iniziale riduce al minimo la finestra di migrazione completa; dopo la copia iniziale, devi copiare solo i dati che sono stati modificati durante questa finestra.
  2. Esegui controlli di convalida e coerenza dei dati per confrontare i dati del sito legacy con quelli copiati nel nuovo sito.
  3. Configura un meccanismo di replica continua dal sito legacy al nuovo sito.
  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 in modo che utilizzino il nuovo sito.
  6. Attendi che la replica sincronizzi completamente il nuovo sito con il sito legacy.
  7. Avvia i tuoi carichi di lavoro e i tuoi servizi.
  8. Quando non hai più bisogno del sito precedente come opzione di riserva, ritiralo.

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

Y (scrittura e lettura)

Se i tuoi carichi di lavoro prevedono requisiti rigidi per l'alta disponibilità e non puoi risparmiare il tempo di inattività rappresentato da una finestra di migrazione completa, devi adottare un approccio diverso. Per questo scenario, puoi utilizzare un approccio denominato Y (scrittura e lettura), che è una forma di migrazione parallela. Con questo approccio, il carico di lavoro scrive e legge i dati sia nel sito legacy che in quello nuovo 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 dati sia sul sito precedente che sul nuovo sito e per leggere dal sito precedente.
  2. Identifica i dati scritti prima dell'attivazione delle scritture nel nuovo sito e copiali dal sito precedente a quello nuovo. 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. Sposta le operazioni di lettura dal sito precedente al nuovo sito.
  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 precedente 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 dello 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 da utilizzare un microservizio di accesso ai dati. Questo microservizio scalabile diventa l'unico punto di ingresso al livello di archiviazione dei dati e funge da proxy per quel livello. Tra gli approcci discussi qui, questo offre la massima flessibilità, perché puoi eseguire il refactoring di questo 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 iniziative di refactoring si concentrano sul solo microservizio di accesso ai dati, invece di dover eseguire il refactoring di tutti i carichi di lavoro e i servizi che accedono al livello di archiviazione dei dati. Questo approccio è riassunto come segue:

  1. Esegui il refactoring del microservizio di accesso ai dati in modo da scrivere dati sia nel sito legacy che in quello nuovo. Le letture vengono eseguite sul sito precedente.
  2. Identifica i dati scritti prima dell'attivazione delle scritture nel nuovo sito e copiali dal sito precedente a quello nuovo. 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. Esegui il refactoring del microservizio di accesso ai dati in modo che possa leggere dal nuovo sito.
  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. 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 precedente come opzione di riserva, ritiralo.

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

Passaggio 5: prepara il trasferimento

Per un trasferimento di grandi dimensioni o con dipendenze significative, è importante capire come utilizzare il prodotto di trasferimento. I clienti in genere seguono questi passaggi:

  1. Determinazione dei prezzi e stima del ROI. Questa fase offre molte opzioni utili nel processo decisionale.

  2. Test funzionale. In questo passaggio confermerai che il prodotto può essere configurato correttamente e che la connettività di rete (ove applicabile) funziona. Verifica inoltre di poter spostare un campione rappresentativo dei tuoi dati (inclusi i passaggi associati di non trasferimento, come lo spostamento di un'istanza VM) nella destinazione.

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

    • Conferma di poter installare e gestire il trasferimento.
    • Rileva i potenziali problemi di interruzione del progetto che bloccano lo spostamento dei dati (ad esempio, route di rete) o le tue operazioni (ad esempio, l'addestramento necessario in una fase di non trasferimento).

  3. Test delle prestazioni. In questo passaggio, eseguirai 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 utilizzare tutte le risorse allocate e di poter ottenere le velocità previste.
    • Individuare e risolvere i colli di bottiglia (ad esempio, un sistema di archiviazione di origine lento).

Passaggio 6: verifica l'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 delle eliminazioni accidentali.
  • Convalida i dati prima di rimuovere i dati di origine.

Per trasferimenti di dati su larga scala (con petabyte di dati e miliardi di file), una percentuale di errori latenti di base del sistema di archiviazione di origine sottostante, pari allo 0,0001%, determina 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'archiviazione a lungo termine), è necessaria un'ulteriore convalida prima che sia considerato sicuro l'eliminazione dei dati dall'origine.

A seconda dei requisiti dell'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 integrati 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 eliminare i dati dall'origine. Ad esempio, potresti voler confermare se un checksum 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