Esegui la migrazione tra regioni Google Cloud: prepara i dati e i carichi di lavoro batch per la migrazione tra regioni

Last reviewed 2023-12-08 UTC

Questo documento descrive come progettare una piattaforma di dati su Google Cloud per minimizzare l'impatto di un'espansione futura in altre regioni o di una migrazione da una regione all'altra. Questo documento fa parte di una serie che ti aiuta a comprendere l'impatto dell'espansione della tua piattaforma di dati in un'altra regione. Ti aiuta a imparare a:

  • Preparati a spostare i dati e le pipeline di dati.
  • Configura i controlli durante le fasi di migrazione.
  • Crea una strategia di migrazione flessibile separando lo spazio di archiviazione dei dati e il calcolo dei dati.

Le indicazioni di questa serie sono utili anche se non hai pianificato in anticipo una migrazione tra regioni o un'espansione a più regioni. In questo caso, potrebbe essere necessario un impegno aggiuntivo per preparare l'infrastruttura, i carichi di lavoro e i dati per la migrazione tra regioni e per l'espansione a più regioni.

Questo documento fa parte di una serie:

Questa serie presuppone che tu abbia letto e che tu abbia familiarità con i seguenti documenti:

Il seguente diagramma illustra il percorso del tuo percorso di migrazione.

Percorso di migrazione con quattro fasi.

Durante ogni passaggio di migrazione, segui le fasi definite in Migrazione a Google Cloud: inizia:

  1. Valuta e scopri i tuoi carichi di lavoro.
  2. Pianifica e crea una base.
  3. Esegui il deployment dei carichi di lavoro.
  4. Ottimizza l'ambiente.

La piattaforma di dati moderna su Google Cloud

Questa sezione descrive le diverse parti di una piattaforma di dati moderna e come vengono solitamente costruite in Google Cloud. Le piattaforme di dati come concetto generale possono essere suddivise in due sezioni:

  • Il livello di archiviazione dei dati è il luogo in cui vengono salvati i dati. I dati che salvi possono essere sotto forma di file in cui gestisci i byte effettivi su un file system come Hadoop Distributed File System (HDFS) o Cloud Storage oppure puoi utilizzare un linguaggio DSL (domain-specific language) per gestire i dati in un sistema di gestione del database.
  • Il livello di calcolo dei dati è qualsiasi elaborazione dei dati che potresti attivare sul sistema di archiviazione. Come per il livello di archiviazione, esistono molte implementazioni possibili e alcuni strumenti di archiviazione dei dati gestiscono anche il calcolo dei dati. Il ruolo del livello di calcolo dei dati nella piattaforma è caricare i dati dal livello di archiviazione, elaborarli e salvare i risultati in un sistema di destinazione. Il sistema di destinazione può essere il livello di archiviazione di origine.

Alcune piattaforme di dati utilizzano più sistemi di archiviazione per il livello di archiviazione dei dati e più sistemi di calcolo dei dati per il livello di elaborazione dei dati. Nella maggior parte dei casi, il livello di archiviazione dei dati e il livello di calcolo dei dati sono separati. Ad esempio, potresti aver implementato il livello di archiviazione dei dati utilizzando questi servizi Google Cloud:

Potresti aver implementato il livello di calcolo dei dati utilizzando altri servizi Google Cloud come:

Per ridurre il tempo e la latenza della comunicazione, il costo del trasferimento di dati in uscita e il numero di operazioni di I/O tra il livello di archiviazione e il livello di calcolo, ti consigliamo di archiviare i dati nella stessa zona in cui li elabori.

Ti consigliamo inoltre di mantenere separato il livello di archiviazione dei dati dal livello di calcolo dei dati. Mantenere separati questi livelli migliora la flessibilità per quanto riguarda la modifica dei livelli di calcolo e la migrazione dei dati. Mantenere separati i livelli consente inoltre di ridurre l'utilizzo delle risorse perché non è necessario mantenere in esecuzione il livello di calcolo. Pertanto, ti consigliamo di eseguire il deployment dell'archiviazione e del calcolo dei dati su piattaforme separate nella stessa zona e nella stessa regione. Ad esempio, puoi spostare lo spazio di archiviazione dei dati da HDFS a Cloud Storage e utilizzare un cluster Dataproc per il calcolo.

Valutare il tuo ambiente

Nella fase di valutazione, devi determinare i requisiti e le dipendenze per eseguire la migrazione delle pipeline di dati batch che hai disegnato:

  1. Crea un inventario completo delle tue pipeline di dati.
  2. Cataloga le pipeline in base alle loro proprietà e dipendenze.
  3. Forma e istruisci i tuoi team su Google Cloud.
  4. Crea un esperimento e una proof of concept su Google Cloud.
  5. Calcola il costo totale di proprietà (TCO) dell'ambiente di destinazione.
  6. Scegli i workload di cui vuoi eseguire prima la migrazione.

Per ulteriori informazioni sulla fase di valutazione e su queste attività, consulta Migrazione a Google Cloud: valuta e scopri i tuoi carichi di lavoro. Le sezioni seguenti si basano sulle informazioni contenute nel documento.

Creare gli inventari

Per definire l'ambito della migrazione, devi comprendere l'ambiente della piattaforma dati in cui sono implementate le pipeline di dati:

  1. Crea un inventario della tua infrastruttura dati: i diversi livelli di archiviazione e di calcolo che utilizzi per l'archiviazione dei dati e l'elaborazione batch dei dati.
  2. Crea un inventario delle pipeline di dati di cui è pianificata la migrazione.
  3. Crea un inventario dei set di dati letti dalle pipeline di dati e di cui è necessaria la migrazione.

Per creare un inventario della tua piattaforma di dati, prendi in considerazione quanto segue per ogni componente dell'infrastruttura di dati:

  • Livelli di archiviazione. Oltre alle piattaforme di archiviazione standard come Cloud Storage, valuta altri livelli di archiviazione, ad esempio database come Firebase, BigQuery, Bigtable e Postgres o altri cluster come Apache Kafka. Ogni piattaforma di archiviazione ha la propria strategia e il proprio metodo per completare la migrazione. Ad esempio, Cloud Storage offre servizi di migrazione dei dati e un database potrebbe avere uno strumento di migrazione integrato. Assicurati che ogni prodotto che utilizzi per lo stoccaggio dei dati sia disponibile nel tuo ambiente di destinazione o che tu abbia un prodotto sostitutivo compatibile. Fai pratica e verifica la procedura tecnica di trasferimento dei dati per ciascuna delle piattaforme di archiviazione coinvolte.
  • Livelli di calcolo. Per ogni piattaforma di calcolo, verifica il piano di implementazione e eventuali modifiche alla configurazione apportate alle diverse piattaforme.
  • Latenza di rete. Testa e verifica la latenza della rete tra l'ambiente di origine e quello di destinazione. È importante capire quanto tempo occorre per la copia dei dati. Devi anche verificare la latenza della rete dai client e dagli ambienti esterni (ad esempio un ambiente on-premise) all'ambiente di destinazione rispetto all'ambiente di origine.

  • Configurazioni e deployment. Ogni prodotto dell'infrastruttura dati ha i propri metodi di configurazione. Fai l'inventario delle configurazioni personalizzate che hai creato per ogni componente e dei componenti di cui utilizzi le versioni predefinite per ogni piattaforma (ad esempio, la versione di Dataproc o Apache Kafka che utilizzi). Assicurati che queste configurazioni siano diponibili per il deployment nell'ambito del processo di deployment automatico.

    Devi sapere come è configurato ogni componente perché i motori di calcolo potrebbero comportarsi in modo diverso se sono configurati in modo diverso, in particolare se il framework del livello di elaborazione cambia durante la migrazione. Ad esempio, se nell'ambiente di destinazione è in esecuzione una versione diversa di Apache Spark, alcune configurazioni del framework Spark potrebbero essere cambiate tra le versioni. Questo tipo di modifica della configurazione può causare modifiche in output, serializzazioni e calcoli.

    Durante la migrazione, ti consigliamo di utilizzare le implementazioni automatiche per assicurarti che le versioni e le configurazioni rimangano invariate. Se non puoi mantenere invariate le versioni e le configurazioni, assicurati di disporre di test che convalidino le uscite di dati calcolate dal framework.

  • Dimensioni dei cluster. Per i cluster autogestiti, ad esempio un cluster Dataproc di lunga durata o un cluster Apache Kafka in esecuzione su Compute Engine, prendi nota del numero di nodi e CPU e della memoria per ogni nodo nei cluster. La migrazione a un'altra regione potrebbe comportare una variazione del processore utilizzato dal tuo deployment. Pertanto, ti consigliamo di eseguire il profiling e l'ottimizzazione dei carichi di lavoro dopo aver eseguito il deployment dell'infrastruttura di cui è stata eseguita la migrazione in produzione. Se un componente è completamente gestito o serverless (ad esempio Dataflow), la definizione delle dimensioni fa parte di ogni singolo job e non del cluster stesso.

I seguenti elementi che valuti nel tuo inventario si concentrano sulle pipeline di dati:

  • Origini dati e sink. Assicurati di tenere conto delle origini e delle destinazioni utilizzate da ogni pipeline di dati per leggere e scrivere i dati.
  • Accordi sul livello del servizio (SLA) e obiettivi del livello di servizio (SLO). Gli SLA e gli SLO delle pipeline di dati batch vengono in genere misurati in termini di tempo di completamento, ma possono essere misurati anche in altri modi, ad esempio in termini di potenza di calcolo utilizzata. Questi metadati aziendali sono importanti per gestire i processi di continuità aziendale e del piano di ripristino di emergenza (BCDR), ad esempio il failover di un sottoinsieme delle pipeline più importanti in un'altra regione in caso di guasto zonale o regionale.
  • Dipendenze delle pipeline di dati. Alcune pipeline di dati si basano su dati generati da un'altra pipeline di dati. Quando dividi le pipeline in sprint di migrazione, assicurati di prendere in considerazione le dipendenze dei dati.
  • Set di dati generati e utilizzati. Per ogni pipeline di dati, identifica i set di dati che vengono utilizzati e quelli generati. In questo modo, puoi identificare le dipendenze tra le pipeline e tra altri sistemi o componenti dell'architettura complessiva.

I seguenti elementi che valuti nel tuo inventario si concentrano sui set di dati di cui eseguire la migrazione:

  • Set di dati. Identifica i set di dati di cui è necessaria la migrazione nell'ambiente di destinazione. Potresti considerare alcuni dati storici non necessari per la migrazione o da migrare in un secondo momento, se sono archiviati e non vengono utilizzati attivamente. Definire l'ambito della procedura di migrazione e gli sprint di migrazione consente di ridurre i rischi della migrazione.
  • Dimensioni dei dati. Se prevedi di comprimere i file prima di trasferirli, assicurati di annotare le dimensioni dei file prima e dopo la compressione. Le dimensioni degli dati influiscono sul tempo e sul costo necessari per copiarli dalla sorgente alla destinazione. Tenere in considerazione questi fattori ti aiuterà a scegliere tra le strategie di tempo di riposo, come descritto più avanti in questo documento.
  • Struttura dei dati. Classifica ogni set di dati di cui vuoi eseguire la migrazione e assicurati di capire se i dati sono strutturati, semistrutturati o non strutturati. La comprensione della struttura dei dati può aiutarti a definire la strategia per verificare che la migrazione dei dati sia corretta e completa.

Completa la valutazione

Dopo aver creato gli inventari relativi ai tuoi cluster e ai tuoi carichi di lavoro Kubernetes, completa le restanti attività della fase di valutazione in Migrazione a Google Cloud: valuta e scopri i tuoi carichi di lavoro.

Pianifica e crea le basi

La fase di pianificazione e creazione della migrazione a Google Cloud è costituita dalle seguenti attività:

  1. Crea una gerarchia di risorse.
  2. Configura Identity and Access Management (IAM).
  3. Configura la fatturazione.
  4. Configura la connettività di rete.
  5. Rafforza la sicurezza.
  6. Configura il logging, il monitoraggio e gli avvisi.

Per ulteriori informazioni su ciascuna di queste attività, consulta Eseguire la migrazione a Google Cloud: pianificare e creare le basi.

Esegui la migrazione dei dati e delle pipeline di dati

Le sezioni seguenti descrivono alcuni aspetti del piano per la migrazione delle pipeline di dati e dei dati batch. Definisce alcuni concetti relativi alle caratteristiche delle pipeline di dati che è importante comprendere quando crei il piano di migrazione. Vengono inoltre descritti alcuni concetti di test dei dati che possono contribuire ad aumentare la tua fiducia nella migrazione dei dati.

Piano di migrazione

Nel piano di migrazione devi includere il tempo necessario per completare il trasferimento dei dati. Il piano deve tenere conto della latenza della rete, del tempo necessario per verificare la completezza dei dati e per recuperare i dati di cui non è stata eseguita la migrazione, nonché di eventuali costi di rete. Poiché i dati verranno copiati da una regione all'altra, il piano per i costi di rete deve includere i costi di rete interregionali.

Ti consigliamo di suddividere le diverse pipeline e i set di dati in sprint e di eseguirne la migrazione separatamente. Questo approccio consente di ridurre i rischi per ogni sprint di migrazione e di apportare miglioramenti in ogni sprint. Per migliorare la strategia di migrazione e rilevare i problemi in anticipo, ti consigliamo di dare la priorità ai carichi di lavoro più piccoli e non critici prima di eseguire la migrazione di quelli più grandi e critici.

Un'altra parte importante di un piano di migrazione è descrivere la strategia, le dipendenze e la natura delle diverse pipeline di dati dal livello di calcolo. Se il livello di archiviazione dei dati e il livello di calcolo dei dati sono basati sullo stesso sistema, ti consigliamo di monitorare le prestazioni del sistema durante la copia dei dati. In genere, la copia di grandi quantità di dati può causare un overhead I/O sul sistema e ridurre le prestazioni nel livello di calcolo. Ad esempio, se esegui un carico di lavoro per estrarre i dati da un cluster Kafka in batch, le operazioni I/O aggiuntive per leggere grandi quantità di dati possono causare un calo delle prestazioni di eventuali pipeline di dati attive ancora in esecuzione nell'ambiente di origine. In questo tipo di scenario, devi monitorare il rendimento del sistema utilizzando le metriche integrate o personalizzate. Per evitare di sovraccaricare il sistema, ti consigliamo di pianificare il ritiro di alcuni carichi di lavoro durante la procedura di copia dei dati o di ridurre la velocità della fase di copia.

Poiché la copia dei dati rende la migrazione un processo lungo, ti consigliamo di predisporre piani di emergenza per risolvere eventuali problemi durante la migrazione. Ad esempio, se il trasferimento dei dati richiede più tempo del previsto o se i test di integrità non vanno a buon fine prima di mettere il nuovo sistema online, valuta se eseguire il rollback o provare a correggere e riprovare le operazioni non riuscite. Anche se un rollback può essere una soluzione più chiara, può essere dispendioso in termini di tempo e denaro copiare set di dati di grandi dimensioni più volte. Ti consigliamo di avere una conoscenza chiara e test predefiniti per determinare quali azioni intraprendere in quali condizioni, quanto tempo concedere per provare a creare patch e quando eseguire un rollback completo.

È importante distinguere tra gli strumenti e gli script che utilizzi per la migrazione e i dati che stai copiando. Il rollback del movimento dei dati significa che devi copiare di nuovo i dati e sostituire o eliminare i dati che hai già copiato. Il rollback delle modifiche agli strumenti e agli script è potenzialmente più semplice e meno costoso, ma le modifiche agli strumenti potrebbero costringerti a ricopiare i dati. Ad esempio, potrebbe essere necessario copiare di nuovo i dati se crei un nuovo percorso di destinazione in uno script che genera dinamicamente una posizione Cloud Storage. Per evitare di copiare di nuovo i dati, crea gli script in modo da consentire la ripresa e l'idempotenza.

Caratteristiche della pipeline di dati

Per creare un piano di migrazione ottimale, devi comprendere le caratteristiche delle diverse pipeline di dati. È importante ricordare che le pipeline batch che scrivono dati sono diverse da quelle che li leggono:

  • Pipeline di dati che scrivono dati: poiché modificano lo stato del sistema di origine, può essere difficile scrivere dati nell'ambiente di origine contemporaneamente alla loro copia nell'ambiente di destinazione. Tieni conto dei tempi di esecuzione delle pipeline che scrivono i dati e cerca di dare la priorità alla loro migrazione all'inizio del processo complessivo. In questo modo, avrai i dati pronti nell'ambiente di destinazione prima di eseguire la migrazione delle pipeline che li leggono.
  • Pipeline di dati che leggono i dati: le pipeline che leggono i dati potrebbero avere requisiti diversi per l'aggiornamento dei dati. Se le pipeline che generano dati sono interrotte sul sistema di origine, le pipeline che leggono i dati potrebbero essere in grado di funzionare durante la copia dei dati nell'ambiente di destinazione.

I dati sono uno stato e la loro copia tra regioni non è un'operazione atomica. Pertanto, devi essere consapevole delle modifiche dello stato durante la copia dei dati.

Nel piano di migrazione è importante anche distinguere tra i sistemi. I tuoi sistemi potrebbero avere requisiti funzionali e non funzionali diversi (ad esempio, un sistema per i batch e un altro per lo streaming). Pertanto, il tuo piano deve includere strategie diverse per la migrazione di ciascun impianto. Assicurati di specificare le dipendenze tra i sistemi e di specificare in che modo ridurrete il tempo di riposo per ciascun sistema durante ogni fase della migrazione.

Un piano tipico per uno sprint di migrazione deve includere quanto segue:

  • Strategia generale. Descrivi la strategia per gestire la migrazione in questo sprint. Per le strategie comuni, consulta Eseguire il deployment dei carichi di lavoro.
  • Elenco di strumenti e metodi per la copia dei dati e il deployment delle risorse. Specifica gli strumenti che prevedi di utilizzare per copiare i dati o eseguire il deployment delle risorse nell'ambiente di destinazione. Questo elenco deve includere script personalizzati utilizzati per copiare gli asset Cloud Storage, strumenti standard come l'interfaccia a riga di comando Google Cloud e strumenti Google Cloud come Migration Services.
  • Elenco delle risorse da eseguire nell'ambiente di destinazione. Elenca tutte le risorse che devono essere implementate nell'ambiente di destinazione. Questo elenco deve includere tutti i componenti dell'infrastruttura dati, come i bucket Cloud Storage, i set di dati BigQuery e i cluster Dataproc. In alcuni casi, gli sprint iniziali di migrazione includeranno il deployment di un cluster di dimensioni (ad esempio un cluster Dataproc) in una capacità inferiore, mentre gli sprint successivi includeranno il ridimensionamento in base ai nuovi carichi di lavoro. Assicurati che il piano includa il potenziale ridimensionamento.
  • Elenco dei set di dati da copiare. Per ogni set di dati, assicurati di specificare le seguenti informazioni:
    • Ordine di copia (se applicabile): per la maggior parte delle strategie, l'ordine di operazione potrebbe essere importante. Un'eccezione è la strategia di manutenzione programmata descritta più avanti in questo documento.
    • Dimensioni
    • Statistiche chiave: le statistiche chiave del grafico, ad esempio il numero di riga, che possono aiutarti a verificare che l'insieme di dati sia stato copiato correttamente.
    • Tempo stimato per la copia: il tempo necessario per completare il trasferimento dei dati, in base al piano di migrazione.
    • Metodo di copia: consulta l'elenco di strumenti e metodi descritto in precedenza in questo documento.
    • Test di verifica: elenca esplicitamente i test che prevedi di completare per verificare che i dati siano stati copiati per intero.
    • Piano di emergenza: descrivi cosa fare in caso di fallimento dei test di verifica. Il piano di emergenza deve specificare quando riprovare e riprendere la copia o colmare la lacuna, nonché quando eseguire un rollback completo e copiare di nuovo l'intero set di dati.

Test

Questa sezione descrive alcuni tipi di test tipici che puoi pianificare. I test possono aiutarti a garantire l'integrità e la completezza dei dati. Inoltre, possono aiutarti a verificare che il livello di calcolo funzioni come previsto ed è pronto per eseguire le pipeline di dati.

  • Riepilogo o confronto con hashing: per convalidare la completezza dei dati dopo la copia, devi confrontare il set di dati originale con la nuova copia nell'ambiente di destinazione. Se i dati sono strutturati all'interno delle tabelle BigQuery, non puoi unire le due tabelle in una query per verificare se esistono tutti i dati, perché le tabelle si trovano in regioni diverse. A causa del costo e della latenza, BigQuery non consente di eseguire query per unire i dati tra regioni. Il metodo di confronto deve invece riassumere ogni set di dati e confrontare i risultati. A seconda della struttura del set di dati, il metodo di sintesi potrebbe essere diverso. Ad esempio, una tabella BigQuery potrebbe utilizzare una query di aggregazione, ma un insieme di file su Cloud Storage potrebbe utilizzare una pipeline Spark per calcolare un hash di ogni file e poi aggregare gli hash.

  • Flussi canary: i flussi canary attivano job creati per convalidare l'integrità e la completezza dei dati. Prima di passare ai casi d'uso aziendali come l'analisi dei dati, può essere utile eseguire job di flusso canary per assicurarti che i dati di input siano conformi a un insieme di prerequisiti. Puoi implementare i flussi Canary come pipeline di dati personalizzate o come flussi in un DAG basato su Cloud Composer. I flussi Canary possono aiutarti a completare attività come verificare che non siano presenti valori mancanti per determinati campi o convalidare che il conteggio delle righe di set di dati specifici corrisponda al conteggio previsto.

    Puoi anche utilizzare i flussi canary per creare digest o altre aggregazioni di una colonna o di un sottoinsieme di dati. Puoi quindi utilizzare il flusso canary per confrontare i dati con un digest o un'aggregazione simile ricavata dalla copia dei dati.

    I metodi di flusso canary sono utili quando devi valutare l'accuratezza degli dati archiviati e copiati in formati di file, come i file Avro, su Cloud Storage. In genere, i flussi Canary non generano nuovi dati, ma non vanno a buon fine se un insieme di regole non viene soddisfatto all'interno dei dati di input.

  • Ambiente di test: dopo aver completato il piano di migrazione, devi testarlo in un ambiente di test. L'ambiente di test deve includere la copia di dati campionati o di dati di staging in un'altra regione per stimare il tempo necessario per copiare i dati sulla rete. Questi test ti aiutano a identificare eventuali problemi con il piano di migrazione e a verificare che sia possibile eseguire la migrazione dei dati. I test devono includere sia i test funzionali che quelli non funzionali. I test di funzionalità verificano che la migrazione dei dati sia avvenuta correttamente. I test non funzionali verificano che la migrazione soddisfi i requisiti di prestazioni, sicurezza e altri requisiti non funzionali. Ogni passaggio di migrazione nel piano deve includere criteri di convalida che descrivono quando il passaggio può essere considerato completato.

Per facilitare la convalida dei dati, puoi utilizzare lo strumento di convalida dei dati (DVT). Lo strumento esegue funzioni di convalida dei dati a più livelli, dal livello della tabella al livello della riga, e ti aiuta a confrontare i risultati dei sistemi di origine e di destinazione.

I test devono verificare il deployment del livello di calcolo e testare i set di dati che sono stati copiati. Un approccio per farlo è creare una pipeline di test che possa calcolare alcune aggregazioni dei set di dati copiati e assicurarsi che i set di dati di origine e di destinazione corrispondano. Un mancato accoppiamento tra i set di dati di origine e di destinazione è più comune quando i file che copi tra le regioni non sono rappresentazioni esatte di copie di byte tra i sistemi di origine e di destinazione (ad esempio quando modifichi i formati dei file o le compressioni dei file).

Ad esempio, prendi in considerazione un set di dati composto da file JSON delimitati da una nuova riga. I file sono archiviati in un bucket Cloud Storage e montati come tabella esterna in BigQuery. Per ridurre la quantità di dati spostati tramite la rete, puoi eseguire la compressione Avro nell'ambito della migrazione, prima di copiare i file nell'ambiente di destinazione. Questa conversione presenta molti vantaggi, ma anche alcuni rischi, perché i file scritti nell'ambiente di destinazione non sono una rappresentazione in byte dei file nell'ambiente di origine.

Per ridurre i rischi dello scenario di conversione, puoi creare un job Dataflow o utilizzare BigQuery per calcolare alcune aggregazioni e hash di checksum del set di dati (ad esempio calcolando somme, medie o quantili per ogni colonna numerica). Per le colonne di stringhe, puoi calcolare le aggregazioni in base alla lunghezza della stringa o al codice hash della stringa. Per ogni riga, puoi calcolare un hash aggregato da una combinazione di tutte le altre colonne, che può verificare con elevata precisione che una riga sia uguale alla sua origine. Questi calcoli vengono eseguiti sia negli ambienti di destinazione che di origine e poi confrontati. In alcuni casi, ad esempio se il set di dati è archiviato in BigQuery, non puoi unire le tabelle degli ambienti di origine e di destinazione perché si trovano in regioni diverse, quindi devi utilizzare un client che possa connettersi a entrambi gli ambienti.

Puoi implementare i metodi di test precedenti in BigQuery o come job batch (ad esempio in Dataflow). Puoi quindi eseguire i job di aggregazione e confrontare i risultati calcolati per l'ambiente di origine con quelli calcolati per l'ambiente di destinazione. Questo approccio può aiutarti ad assicurarti che i dati siano completi e accurati.

Un altro aspetto importante del test del livello di calcolo è eseguire pipeline che includono tutte le varianti degli engine di elaborazione e dei metodi di calcolo. Il test della pipeline è meno importante per i motori di calcolo gestiti come BigQuery o Dataflow. Tuttavia, è importante eseguire il test della pipeline per i motori di calcolo non gestiti come Dataproc. Ad esempio, se hai un cluster Dataproc che gestisce diversi tipi di calcolo, come Apache Spark, Apache Hive, Apache Flink o Apache MapReduce, devi testare ogni runtime per assicurarti che i diversi tipi di carico di lavoro siano pronti per essere trasferiti.

Strategie di migrazione

Dopo aver verificato il piano di migrazione con test adeguati, puoi eseguire la migrazione dei dati. Quando esegui la migrazione dei dati, puoi utilizzare strategie diverse per carichi di lavoro diversi. Di seguito sono riportati alcuni esempi di strategie di migrazione che puoi utilizzare così come sono o personalizzare in base alle tue esigenze:

  • Manutenzione pianificata: puoi pianificare il periodo di transizione. Questa strategia è utile quando i dati vengono modificati di frequente, ma gli SLO e gli SLA possono sopportare un certo tempo di riposo. Questa strategia offre un'elevata affidabilità dei dati trasferiti perché i dati sono completamente inattivi durante la copia. Per ulteriori informazioni, consulta Manutenzione pianificata in "Migrazione a Google Cloud: trasferimento dei tuoi set di dati di grandi dimensioni".
  • Transizione in sola lettura: una leggera variazione della strategia di manutenzione pianificata, in cui la piattaforma di dati di sistema di origine consente alle pipeline di dati in sola lettura di continuare a leggere i dati durante la loro copia. Questa strategia è utile perché alcune pipeline di dati possono continuare a funzionare e fornire approfondimenti ai sistemi di destinazione. Lo svantaggio di questa strategia è che i dati prodotti non sono aggiornati durante la migrazione, perché i dati di origine non vengono aggiornati. Pertanto, dopo la migrazione potrebbe essere necessario adottare una strategia di recupero per tenere conto dei dati non aggiornati nei sistemi di destinazione.
  • Completamente attivo: i dati vengono copiati in un timestamp specifico, mentre l'ambiente di origine è ancora attivo sia per le pipeline di lettura sia per quelle di scrittura dei dati. Dopo aver copiato i dati e aver eseguito la transizione al nuovo deployment, esegui una fase di copia delta per recuperare i dati generati dopo il timestamp della migrazione nell'ambiente di origine. Questo approccio richiede più coordinamento e considerazione rispetto ad altre strategie. Pertanto, il piano di migrazione deve includere la modalità di gestione delle operazioni di aggiornamento ed eliminazione sui dati di origine.
  • Doppie scritture: le pipeline di dati possono essere eseguite sia nell'ambiente di origine sia in quello di destinazione durante la copia dei dati. Questa strategia evita la fase di copia delta necessaria per il completamento dei dati se utilizzi le strategie completamente attive o di sola lettura. Tuttavia, per assicurarti che le pipeline di dati producano risultati identici, una strategia di doppie scritture richiede più test prima della migrazione. Se non esegui test preliminari, incontrerai problemi nel tentativo di consolidare uno scenario di split-brain. La strategia di scrittura doppia introduce anche potenziali costi per l'esecuzione degli stessi carichi di lavoro due volte in regioni diverse. Questa strategia ha il potenziale per eseguire la migrazione della piattaforma senza tempi di riposo, ma richiede molto più coordinamento per essere eseguita correttamente.

Test post-migrazione

Al termine della migrazione, devi verificare la completezza dei dati e la validità delle pipeline di dati. Se completi la migrazione in sprint, devi eseguire questi test dopo ogni sprint. I test eseguiti in questa fase sono simili ai test di integrazione: testano la validità di una pipeline di dati che esegue casi d'uso aziendali con dati di produzione completi come input, quindi controllano la validità dell'output. Puoi confrontare l'output del test di integrazione con l'output dell'ambiente di origine eseguendo la stessa pipeline di dati sia nell'ambiente di origine sia nell'ambiente di destinazione. Questo tipo di test funziona solo se la pipeline di dati è deterministica e se puoi assicurarti che l'input in entrambi gli ambienti sia identico.

Puoi confermare che i dati sono completi quando soddisfano un insieme di criteri predefiniti, in cui i dati nell'ambiente di origine sono uguali (o abbastanza simili) ai dati nell'ambiente di destinazione. A seconda della strategia utilizzata nella sezione precedente, i dati potrebbero non corrispondere uno a uno. Di conseguenza, devi predefinire i criteri per descrivere la completezza dei dati per il tuo caso d'uso. Ad esempio, per i dati delle serie temporali, potresti considerare i dati completi quando il record più aggiornato non è in ritardo di più di cinque minuti rispetto al timestamp corrente.

Cutover

Dopo aver verificato e testato i dati e le pipeline di dati nell'ambiente di destinazione, puoi iniziare la fase di transizione. L'avvio di questa fase comporta che i clienti potrebbero dover modificare la propria configurazione per fare riferimento ai nuovi sistemi. In alcuni casi, la configurazione non può essere la stessa di quella che fa riferimento al sistema di origine. Ad esempio, se un servizio deve leggere i dati da un bucket Cloud Storage, i client devono modificare la configurazione del bucket da utilizzare. I nomi dei bucket Cloud Storage sono univoci a livello globale, pertanto il bucket Cloud Storage dell'ambiente di destinazione sarà diverso da quello dell'ambiente di origine.

Durante la fase di passaggio, devi ritirare e annullare la pianificazione dei carichi di lavoro dell'ambiente di origine. Ti consigliamo di conservare i dati dell'ambiente di origine per un po' di tempo, nel caso in cui sia necessario eseguire il rollback.

La fase di test pre-migrazione non è completa come un'esecuzione di produzione di una pipeline di dati. Pertanto, una volta completato il passaggio e il sistema di destinazione è operativo, devi monitorare le metriche, i runtime e gli output semantici delle tue pipeline di dati. Questo monitoraggio ti aiuterà a rilevare gli errori che potresti aver perso durante la fase di test e a garantire il buon esito della migrazione.

Ottimizza il tuo ambiente

L'ottimizzazione è l'ultima fase della migrazione. In questa fase, rendi il tuo ambiente più efficiente eseguendo più iterazioni di un ciclo ripetibile finché non soddisfa i tuoi requisiti di ottimizzazione:

  1. Valuta il tuo ambiente, i tuoi team e il tuo ciclo di ottimizzazione attuale.
  2. Stabilisci i requisiti e gli obiettivi di ottimizzazione.
  3. Ottimizza il tuo ambiente e i tuoi team.
  4. Ottimizza il ciclo di ottimizzazione.

Per saperne di più su come ottimizzare il tuo ambiente Google Cloud, consulta Migrazione a Google Cloud: ottimizzare l'ambiente.

Preparare i dati e le risorse di calcolo di Google Cloud per una migrazione tra regioni

Questa sezione fornisce una panoramica delle risorse di dati e di calcolo su Google Cloud e dei principi di progettazione per prepararsi a una migrazione tra regioni.

BigQuery

Poiché BigQuery è un data warehouse SQL serverless, non devi eseguire il deployment del livello di calcolo. Se alcuni dei tuoi clienti BigQuery specificano regioni per l'elaborazione, dovrai modificarli. In caso contrario, BigQuery è uguale nell'ambiente di origine e nell'ambiente di destinazione. I dati di BigQuery vengono archiviati in due tipi di tabella:

  • Tabelle BigQuery: tabelle nel formato BigQuery. BigQuery gestisce i file di dati per te. Per ulteriori informazioni sulla migrazione dei dati nel formato BigQuery, consulta Gestire i set di dati.
  • Tabelle esterne BigQuery: tabelle per le quali i dati sono memorizzati al di fuori di BigQuery. Dopo aver spostato i dati, dovrai ricreare le tabelle esterne nella nuova destinazione. Per ulteriori informazioni sulla migrazione delle tabelle esterne, consulta Introduzione alle tabelle esterne.

Cloud Storage

Cloud Storage offre un servizio Storage Transfer Service che può aiutarti a eseguire la migrazione dei dati.

Dataflow (batch)

Dataflow è un motore di elaborazione dei dati gestito da Google. Per contribuire a semplificare la migrazione di Dataflow e assicurarti che i job possano essere facilmente dipiazzati in qualsiasi regione, devi inserire tutti gli input e le uscite come parametri nel job. Anziché scrivere le posizioni dei dati di input e di output nel codice sorgente, ti consigliamo di passare i percorsi Cloud Storage e le stringhe di connessione al database come argomenti o parametri.

Dataproc

Dataproc è un ambiente Apache Hadoop gestito che può eseguire qualsiasi caricamento di lavoro compatibile con il framework Apache Hadoop. È compatibile con framework come Apache Spark, Apache Flink e Apache Hive.

Puoi utilizzare Dataproc nei seguenti modi, che influiscono sul modo in cui eseguire la migrazione dell'ambiente Dataproc tra le regioni:

  • Cluster effimeri con dati su Cloud Storage: i cluster vengono creati per eseguire job specifici e vengono distrutti al termine dei job. Ciò significa che anche il livello HDFS o qualsiasi altro stato del cluster viene distrutto. Se la tua configurazione soddisfa i seguenti criteri, la migrazione di questo tipo di utilizzo è più semplice rispetto ad altri tipi di utilizzo:
    • Gli input e gli output dei job non sono hardcoded nel codice sorgente. I job ricevono invece input e output come argomenti.
    • Il provisioning dell'ambiente Dataproc è automatico, incluse le configurazioni per i singoli framework utilizzati dall'ambiente.
  • Cluster permanenti con dati esterni: hai uno o più cluster, ma sono permanenti: anche se non sono in esecuzione lavori sul cluster, il cluster è ancora attivo. I dati e il calcolo sono separati perché i dati vengono salvati al di fuori del cluster su soluzioni Google Cloud come Cloud Storage o BigQuery. Questo modello è solitamente efficace quando sul cluster sono sempre in esecuzione job, quindi non ha senso smontare e configurare i cluster come nel modello temporaneo. Poiché i dati e il calcolo sono separati, la migrazione è simile a quella del modello temporaneo.
  • Cluster a vita lunga con dati al loro interno: il cluster è a vita lunga, ma mantiene anche stato, dati o entrambi al suo interno, più comunemente come dati su HDFS. Questo tipo di utilizzo complica le operazioni di migrazione perché i dati e l'elaborazione non sono separati. Se esegui la migrazione di uno senza l'altro, esiste un rischio elevato di creare incoerenze. In questo scenario, valuta la possibilità di spostare i dati e lo stato al di fuori del cluster prima della migrazione per separarli. Se non è possibile, ti consigliamo di utilizzare la strategia di manutenzione pianificata per ridurre il rischio di creare incoerenze nei dati.

Poiché esistono molti potenziali framework e molte versioni e configurazioni di questi framework, devi eseguire test approfonditi prima di eseguire il piano di migrazione.

Cloud Composer

Cloud Composer è la versione gestita di Apache Airflow di Google Cloud, per l'orchestrazione e la pianificazione dei flussi. I DAG, le configurazioni e i log vengono gestiti in un bucket Cloud Storage di cui deve essere eseguita la migrazione con il deployment di Cloud Composer. Per eseguire la migrazione dello stato del tuo deployment di Cloud Composer, puoi salvare e caricare gli snapshot dell'ambiente.

Se hai eseguito il deployment di plug-in personalizzati nell'istanza Cloud Composer, ti consigliamo di applicare una metodologia di infrastruttura come codice per ricreare l'ambiente in modo completamente automatico.

Cloud Composer non gestisce i dati, ma attiva altri framework e piattaforme di elaborazione dei dati. Pertanto, la migrazione di Cloud Composer può essere completamente isolata dai dati. Anche Cloud Composer non elabora i dati, pertanto il deployment non deve necessariamente trovarsi nella stessa regione dei dati. Pertanto, puoi creare un deployment di Cloud Composer nell'ambiente di destinazione ed eseguire comunque le pipeline nell'ambiente di origine. In alcuni casi, questa operazione può essere utile per gestire pipeline diverse in regioni diverse durante la migrazione dell'intera piattaforma.

Cloud Data Fusion

Cloud Data Fusion è uno strumento di integrazione visiva che ti aiuta a creare pipeline di dati utilizzando un editor visivo. Cloud Data Fusion si basa sul progetto open source CDAP. Come Cloud Composer, Cloud Data Fusion non gestisce i dati in sé, ma attiva altri framework e piattaforme di elaborazione dei dati. Le tue pipeline Cloud Data Fusion devono essere esportate dall'ambiente di origine e importate nell'ambiente di destinazione in uno dei seguenti modi:

A seconda della quantità di flussi di cui devi eseguire la migrazione, potresti preferire un metodo rispetto all'altro. L'utilizzo dell'API CDAP per creare uno script di migrazione potrebbe essere difficile e richiede maggiori competenze di ingegneria del software. Tuttavia, se hai molti flussi o se questi cambiano relativamente di frequente, un processo automatizzato potrebbe essere l'approccio migliore.

Passaggi successivi

Collaboratori

Autore: Eyal Ben Ivri | Cloud Solutions Architect

Altro collaboratore: Marco Ferrari | Cloud Solutions Architect