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 passaggio per l'adozione di un prodotto Google Cloudè l'inserimento dei dati in Google Cloud. Questo documento illustra 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. Anche se questi passaggi possono richiedere lo stesso tempo del trasferimento, questi preparativi possono contribuire a ridurre al minimo le interruzioni delle operazioni aziendali durante il trasferimento.

Questo documento fa parte della seguente serie in più parti sulla migrazione ad 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 negli oggetti.

Il trasferimento di dati non è così semplice come sembra

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

  • Elaborare un piano di trasferimento che tenga conto dei tempi amministrativi, tra cui il tempo necessario per decidere un'opzione di trasferimento, ottenere le approvazioni e gestire i problemi imprevisti.
  • Coordinare le persone della tua organizzazione, ad esempio il team che esegue il trasferimento, il personale che approva gli strumenti e l'architettura e gli stakeholder aziendali interessati al valore e alle interruzioni che lo spostamento dei dati può comportare.
  • Scegliere lo strumento di trasferimento giusto in base alle risorse, ai costi, al tempo e ad altre considerazioni sul 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 durante il trasferimento e la garanzia 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: 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 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 responsabili dei dati (per le policy interne su chi è autorizzato a trasferire quali dati), consulenti legali (per le normative relative ai dati) e un amministratore della sicurezza (per le policy interne su come viene protetto l'accesso ai dati)
  • Esecuzione del trasferimento: un responsabile del team, un project manager (per l'esecuzione e il monitoraggio del progetto), un team di ingegneri 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 fallimento delle iniziative di trasferimento.

Raccogliere i requisiti del progetto e gli input di questi stakeholder può essere difficile, ma creare un piano e stabilire ruoli e responsabilità chiari ripaga. Non ci si può aspettare che tu conosca tutti i dettagli dei tuoi dati. La creazione di un team ti consente di comprendere meglio le esigenze dell'attività. È una best practice identificare i 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 di dati e poi di decidere un'opzione di trasferimento. Per raccogliere i requisiti, puoi utilizzare la seguente procedura:

  1. Identifica i set di dati che devi spostare.
    • Seleziona strumenti come Knowledge Catalog per organizzare i dati in gruppi 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 dei tuoi 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 dei workflow come Managed Service for Apache Airflow.
  3. Per i set di dati che possono essere spostati, determina dove trasferire ciascun set di dati.
    • Registra l'opzione di archiviazione che selezioni per archiviare i tuoi dati. In genere, il sistema di archiviazione di destinazione suGoogle Cloud è Cloud Storage. Anche se hai bisogno di soluzioni più complesse dopo che le tue applicazioni sono attive e funzionanti, Cloud Storage è un'opzione di archiviazione scalabile e durevole.
    • Comprendere quali policy di accesso ai dati devono essere mantenute dopo la migrazione.
    • Determina se devi archiviare questi dati in regioni specifiche.
    • Pianifica come strutturare questi dati nella destinazione. Ad esempio, sarà uguale o diverso dall'origine?
    • Determina se devi trasferire i dati su base continuativa.
  4. Per i set di dati che possono essere spostati, determina quali risorse sono disponibili per spostarli.
    • Tempo: quando deve essere completato il trasferimento?
    • Costo: qual è il budget disponibile per il team e i costi di trasferimento?
    • Persone: chi è disponibile per eseguire il trasferimento?
    • Larghezza di banda (per i trasferimenti online): 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, 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 concessi nuovi ruoli nella tua organizzazione Google Cloud nell'ambito del progetto di trasferimento dei dati. La pianificazione del trasferimento di dati è un ottimo momento per esaminare le tue autorizzazioni di Identity and Access Management (IAM) 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 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 modalità di strutturazione dei dati su Google Cloud dipende da come prevedi di utilizzare Google Cloud. L'archiviazione dei dati nello stesso progetto Google Cloud in cui 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 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. Pertanto, potresti voler conservare l'intero set di dati di produzione in un progettoGoogle Cloud separato, quindi utilizzare un account di servizio per consentire l'accesso ai dati da ogni progetto di applicazione.

Google Cloud è organizzato in 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 provider di archivi di oggetti.

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

Passaggio 3: valuta le opzioni di trasferimento

Per valutare le opzioni di trasferimento dei dati, il team di trasferimento deve considerare 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 è senza costi. Tuttavia, se ospiti i tuoi dati su un provider di cloud pubblico, puoi aspettarti di pagare una tariffa 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 dover sostenere costi aggiuntivi per la configurazione di una maggiore larghezza di banda per Google Cloud.
  • Costi di archiviazione e operativi per Cloud Storage durante e dopo il trasferimento dei dati
  • Costi dei prodotti (ad esempio, un'appliance Transfer Appliance)
  • Costi del personale per la creazione del team e l'acquisizione del supporto logistico

Tempo di trasferimento

Poche cose nel computing evidenziano i limiti hardware delle reti come il trasferimento di grandi quantità di dati. In teoria, puoi trasferire 1 GB in otto secondi su una rete da 1 Gbps. Se lo scali a 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ò mettere a dura prova i limiti della tua infrastruttura e potenzialmente causare problemi alla tua attività.

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

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

Potresti non voler trasferire set di dati di grandi dimensioni al di fuori della rete aziendale durante le ore 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 considerare il fattore tempo.

Dopo aver trasferito i dati in Cloud Storage, puoi utilizzare diverse tecnologie per elaborare i nuovi file man mano che arrivano, ad esempio Dataflow.

Aumento della 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 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 utilizzando 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 della larghezza di banda esclusivamente per scopi di trasferimento è proibitiva, ma se consideri l'utilizzo a lungo termine diGoogle 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 aGoogle Cloud, consulta Scegli un prodotto per la connettività di rete.

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

Trasferimento online e offline

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

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

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

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

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

Da dove stai spostando i dati Scenario Prodotti suggeriti
Un altro cloud provider (ad esempio Amazon Web Services o Microsoft Azure) in 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

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 enterprise, 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 non riuscire rispetto ai trasferimenti di breve durata. Per ulteriori informazioni sul trasferimento di oggetti di grandi dimensioni in Cloud Storage, consulta Storage Transfer Service per trasferimenti di grandi dimensioni di dati on-premise.

Il comando gcloud storage è particolarmente utile nei seguenti scenari:

  • I trasferimenti devono essere eseguiti in base alle necessità o durante le sessioni da riga di comando degli utenti.
  • Stai trasferendo solo pochi file o file molto grandi o entrambi.
  • Stai utilizzando l'output di un programma (output in streaming su 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 dallo spazio di archiviazione Network File System (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 su tutte le opzioni di trasferimento elencate in precedenza in Scelta 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.
  • Hai bisogno di un sistema di segnalazione degli errori efficace 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.

Per configurare Storage Transfer Service for On Premises Data, installa il 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'ora 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 automaticamente di eseguire nuovamente un trasferimento quando rileva errori temporanei. Durante l'esecuzione dei trasferimenti, puoi monitorare il numero di file spostati e la velocità di trasferimento complessiva, 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 interessati e di eventuali messaggi di errore ricevuti. Gli agenti sono a tolleranza di errore, quindi se un agente non è disponibile, il trasferimento continua con gli agenti rimanenti. Inoltre, gli agenti si aggiornano e si riparano automaticamente, quindi non devi preoccuparti di applicare patch alle ultime versioni o di riavviare il processo se si arresta 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 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 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 tuoi workload. Gli altri workload potrebbero utilizzare la larghezza di banda del tuo data center, quindi imposta un limite di larghezza di banda per evitare che i trasferimenti influiscano sui tuoi SLA.
  • Pianifica il tempo per la revisione degli errori. I trasferimenti di grandi dimensioni possono spesso causare errori che richiedono una revisione. Storage Transfer Service ti 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 persistono anche dopo i 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 autorizzazione).
  • 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 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 significativi che possono ritardare la sequenza temporale del progetto.

Transfer Appliance per trasferimenti di grandi dimensioni

Per i trasferimenti su larga scala (soprattutto 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, tieni presente quanto segue:

  • Transfer Appliance richiede che tu sia in grado 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 più elevata con Transfer Appliance rispetto a quella online.
  • Transfer Appliance è disponibile solo in alcuni paesi.

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

Acquisire un Transfer Appliance è semplice. Nella consoleGoogle Cloud , richiedi un Transfer Appliance, indichi la quantità di dati di cui disponi e Google spedisce una o più appliance alla località richiesta. Ti viene concesso un certo 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 la scrittura di uno script che fornisca le dimensioni di ogni file in byte, insieme a un hash MD5 con codifica Base64 dei contenuti del file. A volte le dimensioni e l'hash del file sono disponibili sul sito web di origine. In caso contrario, devi avere 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 ingresso in corso, Storage Transfer Service è un ottimo modo per ottenere i dati e conservarli, in particolare quando il trasferimento avviene 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 Google Cloud la sicurezza è l'aspetto più importante 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 avere accesso 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 for On Premises Data 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. Devi disporre delle autorizzazioni di editor degli oggetti per accedere ai bucket Cloud Storage.
Storage Transfer Service Chiavi di accesso richieste per risorse nonGoogle 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 il account di servizio per accedere all'origine e delle autorizzazioni di editor degli oggetti per tutti i bucket Cloud Storage.

Per ottenere miglioramenti della sicurezza di base, i trasferimenti online aGoogle Cloud utilizzando il comando gcloud storage vengono eseguiti tramite HTTPS, i dati vengono criptati in transito e tutti i dati in Cloud Storage vengono, per impostazione predefinita, crittografati at-rest. Se utilizzi Transfer Appliance, le chiavi di sicurezza che controlli possono contribuire a proteggere i tuoi dati. In genere, ti consigliamo di coinvolgere il tuo team di sicurezza per assicurarti 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 per i flussi di lavoro di trasferimento di dati in corso, potresti voler utilizzare strumenti più avanzati. Per informazioni su strumenti più avanzati, consulta i partner diGoogle Cloud .

Passaggio 4: valuta gli approcci alla migrazione dei dati

Per eseguire la migrazione dei dati, puoi seguire questi passaggi generali:

  1. Trasferisci i dati dal sito precedente alla nuova versione di Sites.
  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 sito nella nuova versione di Sites in modo che diventi la copia principale.
  5. Quando non hai più bisogno del sito legacy come opzione di riserva, ritiralo.

Il tuo approccio alla migrazione dei dati deve basarsi sulle seguenti domande:

  • Di quanti dati devi eseguire la migrazione?
  • 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 modello di coerenza dei dati attuale?

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

Le sezioni seguenti presentano quattro approcci alla migrazione dei dati:

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

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

L'approccio del microservizio 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 in modo da utilizzare l'approccio dei microservizi di accesso ai dati.

Il grafico seguente illustra le rispettive dimensioni delle finestre di cutover, 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 per flessibilità, impegno di refactoring e dimensioni della finestra di cutover 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 (chiamato anche migrazione una tantum o migrazione big bang) è ideale se i tuoi workload possono permettersi una finestra di cutover. È pianificata nel senso che puoi pianificare quando si verifica la finestra di transizione.

In questo approccio, la migrazione prevede i seguenti passaggi:

  1. Copia i dati presenti nel sito legacy nella nuova versione di Sites. Questa copia iniziale riduce al minimo la finestra di cutover. 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 nel sito legacy con i dati copiati nel sito nella nuova versione di Sites.
  3. Interrompi i workload 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. Rifattorizza i workload e i servizi per utilizzare il sito nella nuova versione di Sites.
  6. Avvia i workload e i servizi.
  7. Quando non hai più bisogno del sito legacy come opzione di riserva, ritiralo.

L'approccio della manutenzione pianificata grava principalmente sul lato operativo, poiché è necessario un refactoring minimo del workload e dei 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 frequenza con cui le modifiche vengono applicate ai 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 necessario per la finestra di cutover richiesta, perché riduce al minimo la quantità di dati da sincronizzare.La sequenza per una migrazione con replica continua è la seguente:

  1. Copia i dati presenti nel sito legacy nella nuova versione di Sites. Questa copia iniziale riduce al minimo la finestra di cutover. 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 nel sito legacy con i dati copiati nel sito nella nuova versione di Sites.
  3. Configura un meccanismo di replica continua dal sito legacy al sito nella nuova versione di Sites.
  4. Interrompi i workload e i servizi che hanno accesso ai dati di cui eseguire la migrazione (ovvero ai dati coinvolti nel passaggio precedente).
  5. Rifattorizza i workload e i servizi per utilizzare il sito nella nuova versione di Sites.
  6. Attendi che la replica sincronizzi completamente il sito nella nuova versione di Sites con quello precedente.
  7. Avvia i workload 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 dell'onere sul lato delle operazioni.

Y (scrittura e lettura)

Se i tuoi workload hanno requisiti di alta affidabilità rigidi e non puoi permetterti il tempo di inattività rappresentato 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 sia nel sito nella nuova versione di Sites durante la migrazione. (La lettera Y viene utilizzata qui come rappresentazione grafica del flusso di dati durante il periodo di migrazione).

Questo approccio è riassunto di seguito:

  1. Rifattorizza i workload e i servizi per scrivere i dati sia nel sito precedente che nel sito nella nuova versione di Sites e per leggere dal sito precedente.
  2. Identifica i dati scritti prima di abilitare le scritture nel sito nella nuova versione di Sites e copiali dal sito precedente al sito nella nuova versione di Sites. Insieme al refactoring precedente, questo garantisce che i datastore siano allineati.
  3. Esegui controlli di convalida e coerenza dei dati che confrontano i dati nel sito precedente con quelli nel sito nella nuova versione di Sites.
  4. Passa le operazioni di lettura dal sito precedente al sito nella nuova versione di Sites.
  5. Esegui un altro ciclo di convalida dei dati e controlli di coerenza per confrontare i dati nel sito legacy con quelli del sito nella nuova versione di Sites.
  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 operativo a quello di sviluppo a causa dei molteplici refactoring.

Microservizio di accesso ai dati

Se vuoi ridurre l'impegno di refactoring necessario per seguire l'approccio Y (scrittura e lettura), puoi centralizzare le operazioni di lettura e scrittura dei dati eseguendo il refactoring di workload e 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 quel livello. Tra gli approcci discussi qui, questo offre la massima flessibilità, perché puoi rifattorizzare 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 le attività di refactoring si concentrano solo sul microservizio di accesso ai dati, anziché dover rifattorizzare tutti i workload e i servizi che accedono al livello di archiviazione dei dati. Questo approccio è riassunto di seguito:

  1. Rifattorizza il microservizio di accesso ai dati per scrivere i dati sia nel sito legacy sia nella nuova versione di Sites. Le letture vengono eseguite sul sito legacy.
  2. Identifica i dati scritti prima di abilitare le scritture nel sito nella nuova versione di Sites e copiali dal sito precedente al sito nella nuova versione di Sites. Insieme al refactoring precedente, questo garantisce che i datastore siano allineati.
  3. Esegui la convalida dei dati e i controlli di coerenza confrontando i dati del sito precedente con quelli del sito nella nuova versione di Sites.
  4. Rifattorizzare il microservizio di accesso ai dati per leggere dal sito nella nuova versione di Sites.
  5. Esegui un altro ciclo di convalida dei dati e controlli di coerenza confrontando i dati del sito precedente con quelli del sito nella nuova versione di Sites.
  6. Rifattorizza il microservizio di accesso ai dati per scrivere solo nel sito nella nuova versione di Sites.
  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 dell'onere sul lato dello sviluppo. Tuttavia, è molto più leggero rispetto all'approccio Y (scrittura e lettura), perché le attività di rifattorizzazione si concentrano sul microservizio di accesso ai dati.

Passaggio 5: preparati per il trasferimento

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

  1. Prezzi e stima del ROI. Questo passaggio offre molte opzioni per facilitare il processo decisionale.

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

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

    • Conferma di poter installare e utilizzare il trasferimento.
    • Individua potenziali problemi che potrebbero bloccare il progetto e impedire lo spostamento dei dati (ad esempio, route di rete) o le operazioni (ad esempio, formazione necessaria su 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 l'allocazione delle risorse di produzione per:

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

Passaggio 6: assicurati l'integrità del trasferimento

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

  • Abilita il controllo delle versioni e il backup sulla destinazione per limitare i danni delle 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 allo 0,0001% comporta comunque una perdita di dati di migliaia di file e gigabyte. In genere, le applicazioni in esecuzione nell'origine tollerano già questi errori, nel qual caso non è necessaria una convalida aggiuntiva. In alcuni scenari eccezionali (ad esempio, l'archiviazione a lungo termine), è necessaria una maggiore convalida prima che 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 al termine del trasferimento per assicurarti che l'applicazione continui a funzionare come previsto. Molti prodotti di trasferimento dispongono di controlli integrati dell'integrità dei dati. Tuttavia, a seconda del tuo profilo di rischio, potresti voler eseguire una serie di controlli aggiuntivi 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 verificare che un set di dati utilizzato dall'applicazione sia stato trasferito correttamente.

Passaggi successivi

Collaboratori

Autori: