Migrazione a Google Cloud: trasferimento dei tuoi set di dati di grandi dimensioni

Last reviewed 2023-11-13 UTC

Per molti clienti, il primo passaggio per adottare un prodotto Google Cloud è importare i dati in Google Cloud. Questo documento esamina questo processo, dalla pianificazione di un trasferimento dati all'utilizzo delle best practice durante l'implementazione di un piano.

Il trasferimento di grandi set di dati comporta la creazione del team giusto, la pianificazione anticipata, e testare il piano di trasferimento prima di implementarlo in un ambiente di produzione completamente gestito di Google Cloud. Anche se questi passaggi possono richiedere lo stesso tempo del trasferimento stesso, queste preparazioni 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 a Google Cloud:

Che cos'è il trasferimento di dati?

Ai fini del presente documento, per trasferimento di dati si intende il processo di spostamento dei dati senza trasformarli, ad esempio spostando i file in oggetti.

Il trasferimento dei dati non è così semplice come sembra

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

  • Un piano di trasferimento che tenga conto del tempo amministrativo, incluso il tempo per decidere l'opzione di trasferimento, ottenere le approvazioni e gestire e inaspettati.
  • 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 il trasferimento dei dati può comportare.
  • Scegliere lo strumento di trasferimento giusto in base alle risorse, ai costi, ai tempi e ad altri aspetti del progetto.
  • Superare le sfide del trasferimento di dati, inclusa la "velocità della luce" problemi (larghezza di banda insufficiente), spostare i set di dati in uso attivo proteggendo e monitorando i dati mentre sono in transito e garantendo che dati trasferiti correttamente.

Lo scopo di questo documento è aiutarti a iniziare un'iniziativa di trasferimento di successo.

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

  • Se devi trasformare i dati (ad esempio, combinare righe, unire set di dati o filtrare le informazioni che consentono l'identificazione personale), prendi in considerazione una soluzione ETL (Extract, Transform, Load) in grado di depositare dati in un data warehouse di Google Cloud.
  • Se devi eseguire la migrazione di un database e di app correlate (ad esempio, per eseguire la migrazione) un'app di database), consulta Migrazione dei database: concetti e principi.

Passaggio 1: riunire il team

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

  • Abilitazione delle risorse necessarie per un trasferimento: spazio di archiviazione, IT e rete amministratori, uno sponsor esecutivo e altri consulenti (ad esempio, un team dedicato all'account o partner di integrazione)
  • Approvazione della decisione di trasferimento: proprietari o governatori dei dati (per team interni norme relative a chi è autorizzato a trasferire determinati dati), i consulenti legali (per normative relative ai dati) e un amministratore della sicurezza (per i criteri su come viene protetto l'accesso ai dati)
  • Esecuzione del trasferimento:un responsabile del team, un project manager (per esecuzione e monitoraggio del progetto), un team di tecnici e un team ricezione e spedizione (per ricevere l'hardware dell'appliance)

È fondamentale identificare chi detiene le responsabilità precedenti per il progetto di trasferimento e includerlo nelle riunioni di pianificazione e decisione, se opportuno. Una pianificazione organizzativa scadente è spesso la causa del mancato trasferimento di Google Cloud.

Raccogliere i requisiti del progetto e l'input di questi stakeholder può essere impegnativi, ma elaborando un piano e stabilendo ruoli e responsabilità chiari ripaga. Non è detto che tu conosca tutti i dettagli dei tuoi dati. Assemblaggio un team ti offre maggiori informazioni sulle esigenze dell'azienda. È una identificare potenziali problemi prima di investire tempo, denaro e per completare i trasferimenti.

Passaggio 2: raccolta dei requisiti e delle risorse disponibili

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

  1. Identifica quali set di dati devi spostare.
    • Seleziona strumenti come Data Catalog per organizzare i dati in raggruppamenti logici che vengono spostati e utilizzati insieme.
    • Collabora con i team della tua organizzazione per convalidare o aggiornare questi raggruppamenti.
  2. Identifica quali set di dati puoi spostare.
    • Valuta se fattori normativi, di sicurezza o di altro tipo impediscono il trasferimento di alcuni set di dati.
    • Se devi trasformare alcuni dati prima di spostarli (ad esempio per rimuovere dati sensibili o riorganizzare i tuoi dati), valuta la possibilità di utilizzare un prodotto di integrazione dei dati Dataflow o Cloud Data Fusion, o un prodotto per l'orchestrazione del flusso di lavoro, Cloud Composer.
  3. Per i set di dati spostabili, 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 Google Cloud è Cloud Storage. Anche se hai bisogno di soluzioni più complesse dopo che le applicazioni sono state avviate, 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 nella destinazione. Ad esempio, sarà uguale all'originale o diverso?
    • 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): quanto 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, consigliamo di valutare se è possibile migliorare parte del modello IT, ad esempio la governance, l'organizzazione e la sicurezza dei dati.

Il tuo modello di sicurezza

Molti membri del team addetto ai trasferimenti potrebbero ti sono stati concessi nuovi ruoli nella tua organizzazione Google Cloud come parte dei tuoi dati trasferire il progetto. La pianificazione del trasferimento dei dati è un'ottima occasione per rivedere le autorizzazioni 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 allo spazio di archiviazione. Ad esempio, potresti applicare limiti rigorosi all'accesso in scrittura ai dati archiviati per motivi normativi, ma consentire a molti utenti e applicazioni di scrivere dati nel tuo ambiente di test.

La tua organizzazione Google Cloud

La struttura dei tuoi dati su Google Cloud dipende da come prevedi di utilizzare in Google Cloud. L'archiviazione dei dati nello stesso progetto Google Cloud in cui viene eseguita l'applicazione potrebbe funzionare, ma potrebbe non essere ottimale dal punto di vista della gestione. Alcuni dei tuoi sviluppatori potrebbero non disporre dei privilegi visualizzare i dati di produzione. In questo caso, uno sviluppatore potrebbe sviluppare codice su dati di esempio, mentre un account di servizio privilegiato potrebbe accedere ai dati di produzione. Pertanto, ti consigliamo di mantenere l'intero set di dati di produzione in un progetto Google Cloud separato e di utilizzare un account di servizio per consentire l'accesso ai dati da ogni progetto dell'applicazione.

Google Cloud è organizzato in progetti. I progetti possono essere raggruppati puoi raggruppare cartelle e cartelle all'interno della tua organizzazione. I ruoli sono stabilite 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 provider di archivi di oggetti.

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

Passaggio 3. Valutazione delle opzioni di trasferimento

Per valutare le opzioni a tua disposizione per il trasferimento di dati, il team addetto ai trasferimenti deve valutare diversi fattori, tra cui:

  • Costo
  • Data/ora trasferimento
  • Opzioni di trasferimento offline e online
  • Strumenti e tecnologie di trasferimento
  • Sicurezza

Costo

La maggior parte dei costi associati al trasferimento dei dati include quanto segue:

  • Costi di networking
    • Il traffico in entrata in Cloud Storage è gratuito. Tuttavia, se i tuoi dati su un cloud provider pubblico, puoi aspettarti di pagare un costo del traffico in uscita e potenzialmente costi di archiviazione (ad esempio, operazioni di lettura) trasferire i dati. Questo addebito si applica ai dati provenienti da Google o da un altro provider cloud.
    • Se i tuoi dati sono ospitati in un data center privato di tua proprietà, potresti anche sostenere costi aggiuntivi per configurare una maggiore larghezza di banda per Google Cloud.
  • Costi di archiviazione e gestione di Cloud Storage durante e dopo il trasferimento dei dati
  • Costi del prodotto (ad esempio, un Transfer Appliance)
  • Costi del personale per l'assemblaggio del team e l'acquisizione di assistenza logistica

Data/ora trasferimento

Pochi aspetti dell'informatica evidenziano i limiti hardware delle reti che trasferiscono grandi quantità di dati. L'ideale è trasferire 1 GB in entrata per otto secondi su una rete da 1 Gbps. Se fai lo scale up fino a un enorme set di dati (ad es. 100 TB), il tempo di trasferimento è di 12 giorni. Trasferimento di grandi quantitativi di set di dati possono testare i limiti della tua infrastruttura e causare per risolvere i problemi della tua attività.

Puoi utilizzare il seguente calcolatore per capire quanto tempo potrebbe richiedere un trasferimento, in base alle dimensioni del set di dati che stai spostando e alla larghezza di banda disponibile per il trasferimento. Una determinata percentuale del tempo di gestione preso in considerazione nei calcoli. Inoltre, un'efficienza effettiva della larghezza di banda viene incluso, quindi i numeri risultanti sono più realistici.

Potresti non voler trasferire set di dati di grandi dimensioni dalla rete aziendale durante le ore di punta. Se il trasferimento sovraccarica la rete, nessun altro essere in grado di portare a termine il lavoro necessario o mission critical. Per questo motivo, il team di trasferimento deve prendere in considerazione il fattore tempo.

Dopo aver trasferito i dati 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

Il modo in cui aumenti la larghezza di banda della rete dipende da come ti colleghi a Google Cloud.

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

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

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

Quando valuti questi approcci, è utile prendere in considerazione le tue esigenze di connettività a lungo termine. Potreste concludere che è proibitivo acquistare larghezza di banda limitata esclusivamente al trasferimento, ma quando si considera l'uso a lungo termine Google Cloud e la rete necessitano di tutta l'organizzazione, l'investimento potrebbe essere utile. Per ulteriori informazioni su come collegare le tue reti a Google Cloud, consulta Scegliere un prodotto di connettività di rete.

Se opti per un approccio che prevede il trasferimento dei dati al pubblico internet, ti consigliamo di consultare l'amministratore della sicurezza per se le norme della tua azienda vietano tali 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 sul rendimento della tua rete di produzione.

Trasferimento online e offline

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

Per aiutarti a prendere questa decisione, offriamo un calcolatore per i trasferimenti per aiutarti a stimare le differenze in termini di tempo e costi tra queste due opzioni. Il grafico seguente mostra anche alcune velocità di trasferimento per diverse dimensioni di set di dati e le larghezze di banda. Questi calcoli prevedono un certo carico di gestione.

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

Come già detto in precedenza, potresti dover valutare se il costo per ottenere latenze più basse per il trasferimento dei dati (come l'acquisizione di larghezza di banda) viene compensato dal valore dell'investimento per la tua organizzazione.

Opzioni disponibili da Google

Google offre diversi strumenti e tecnologie per aiutarti a eseguire una trasferimento.

Scegliere tra le opzioni di trasferimento di Google

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

Da dove sposti i dati Scenario Prodotti consigliati
Da un altro provider cloud (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 i 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 trasferimenti di dimensioni ridotte di dati on-premise

Il comando gcloud storage è lo strumento standard per trasferimenti di piccole e medie dimensioni su un su scala aziendale, da un data center privato o da un altro cloud a Google Cloud. Sebbene gcloud storage supporti il caricamento di oggetti fino al dimensione massima degli oggetti Cloud Storage, i trasferimenti di oggetti di grandi dimensioni hanno maggiori probabilità di riscontrare errori rispetto ai trasferimenti di breve durata. Per ulteriori informazioni sul trasferimento di oggetti di grandi dimensioni 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 esigenze o durante le sessioni a riga di comando da parte degli utenti.
  • Stai trasferendo pochi file, file molto grandi o entrambi.
  • Utilizzi l'output di un programma (output in streaming su Cloud Storage).
  • Devi monitorare una directory con un numero moderato di file e sincronizzare eventuali aggiornamenti con latenze molto basse.

Storage Transfer Service per grandi trasferimenti di dati on-premise

Come per il comando gcloud storage, Storage Transfer Service for On Premises Data consente i trasferimenti dall'archiviazione del file system di rete (NFS) di archiviazione ideale in Cloud Storage. Storage Transfer Service for On Premises Data è progettato per trasferimenti su larga scala (fino a petabyte di dati, miliardi di file). it supporta le copie complete o incrementali e funziona su tutte le opzioni di trasferimento elencate in precedenza in Scelta delle opzioni di trasferimento di Google. Ha anche un'interfaccia utente grafica gestita; anche gli utenti meno 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 una larghezza di banda sufficiente per spostare i volumi di dati (consulta il Calcolatore di trasferimento dati di Google Cloud).
  • Supporti un'ampia base di utenti interni che potrebbero trovare un prompt uno strumento difficile da usare.
  • Hai bisogno di un sistema di generazione di report sugli errori affidabile e di un record di tutti i file e gli oggetti trasferiti.
  • Devi limitare l'impatto dei trasferimenti su altri carichi di lavoro nel tuo data center (questo prodotto può rimanere al di sotto di un limite di larghezza di banda specificato dall'utente).
  • Vuoi eseguire trasferimenti ricorrenti in base a una pianificazione.

Per configurare Storage Transfer Service for On Premises Data, devi installare software on-premise (noti come agenti) installato sui computer del data center.

Dopo aver configurato Storage Transfer Service, puoi avviare i trasferimenti nella console Google Cloud specificando 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 nella directory di origine e crea oggetti con un nome corrispondente Cloud Storage (l'oggetto /dir/foo/file.txt diventa un oggetto nel bucket di destinazione denominato /dir/foo/file.txt). Storage Transfer Service e un nuovo tentativo automatico di trasferimento quando si verificano errori temporanei. Mentre i trasferimenti sono in esecuzione, puoi monitorare il numero di file spostati e la velocità di trasferimento complessiva, nonché visualizzare i campioni di errore.

Quando Storage Transfer Service completa un trasferimento, genera un file delimitato da tabule (TSV) con un record completo di tutti i file interessati e gli eventuali messaggi di errore ricevuti. Gli agenti sono fault tolerant, quindi se un agente si arresta in modo anomalo, il trasferimento prosegue con gli agenti rimanenti. Gli agenti si aggiornano autonomamente che si ripara automaticamente, così non c'è bisogno di installare patch alle versioni più recenti se si verifica un problema non previsto 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 gli stessi montaggi di Network File System (NFS) allo stesso modo (lo stesso percorsi relativi). Questa configurazione è un requisito per il funzionamento del prodotto.
  • Più agenti significa maggiore velocità. Poiché i trasferimenti vengono parallelo tra tutti gli agenti, consigliamo di eseguire il deployment in modo da utilizzare la larghezza di banda disponibile.
  • I limiti di larghezza di banda possono proteggere i tuoi carichi di lavoro. Gli altri carichi di lavoro potrebbero utilizzano la larghezza di banda del data center, quindi imposta un limite per la larghezza di banda per evitare dall'impatto dei trasferimenti sui tuoi SLA.
  • Pianifica il tempo necessario per esaminare gli errori. Trasbordi di grandi dimensioni spesso comportano errori da esaminare. Storage Transfer Service ti consente di visualizzare un esempio gli errori riscontrati direttamente nella console Google Cloud. Se necessario, puoi caricare il record completo di tutti gli errori di trasferimento in BigQuery controllare i file o valutare gli errori rimasti anche dopo nuovi tentativi. Questi errori potrebbero essere causati dall'esecuzione di app che stavano scrivendo all'origine durante la transazione oppure potrebbero indicare un problema che richiede la risoluzione dei problemi (ad es. un errore di autorizzazione).
  • Configura Cloud Monitoring per i trasferimenti a lunga esecuzione. Storage Transfer Service consente a Monitoring di monitorare l'integrità dell'agente e la velocità effettiva, in modo da poter impostare avvisi che ti avvisano quando gli agenti non sono disponibili o richiedono attenzione. È importante intervenire in caso di errori dell'agente 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 i 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 rapida 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 connetterti di rete 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 quanto avviene 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 di 100 TB di dati online richiede più di 10 giorni. Se questo tasso 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 il trasferimento richiede più di 100 giorni. A questo punto, vale la pena prendere in considerazione un'opzione di trasferimento offline come Transfer Appliance.

Acquistare un Transfer Appliance è semplice. Nella nella console Google Cloud, richiedi Transfer Appliance, indicare la quantità di dati di cui disponi e Google invia una o più appliance la posizione richiesta. Hai a disposizione alcuni giorni per trasferire i dati all'appliance ("acquisizione dei dati") e rispedirla a Google.

Storage Transfer Service per i trasferimenti da cloud a cloud

Storage Transfer Service è un servizio completamente gestito e altamente scalabile per automatizzare i trasferimenti da altri cloud pubblici a Cloud Storage. Ad esempio, puoi utilizzare Storage Transfer Service per trasferire dati da Amazon S3 a Cloud Storage.

Per HTTP, puoi fornire a Storage Transfer Service un elenco di URL pubblici in un formato specificato. Questo approccio richiede di scrivere uno script che fornisca le dimensioni di ciascun 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 disporre dell'accesso locale ai file. In questo caso, potrebbe essere più semplice utilizzare il comando gcloud storage, come descritto in precedenza.

Se hai già eseguito un trasferimento, Storage Transfer Service è un ottimo modo per recuperare i dati e conservarli, in particolare quando esegui 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 su cloud.

Sicurezza

Per molti utenti di Google Cloud, la sicurezza è la priorità principale e sono disponibili diversi livelli di sicurezza. Alcuni aspetti della sicurezza prendere in considerazione la protezione dei dati at-rest (autorizzazione e accesso e il sistema di archiviazione di destinazione), proteggendo i dati durante il transito e per proteggere l'accesso al prodotto di trasferimento. La tabella seguente illustra questi aspetti della sicurezza in base al prodotto.

Prodotto Dati at-rest Dati in transito Accesso al prodotto di trasferimento
Transfer Appliance Tutti i dati sono criptati quando sono inattivi. I dati sono protetti con chiavi gestite dal cliente. Chiunque può ordinare un'appliance, ma per utilizzarla deve poter accedere ai dati sorgente.
Comando gcloud storage Le chiavi di accesso necessarie per accedere a Cloud Storage, che è criptato a riposo. I dati vengono inviati tramite HTTPS e criptati in transito. Chiunque può scaricare ed eseguire Google Cloud CLI. Devono avere autorizzazioni ai bucket e ai file locali per spostare i dati.
Storage Transfer Service per i dati on-premise Chiavi di accesso necessarie per accedere a Cloud Storage, che è criptato in stato di riposo. Il processo dell'agente può accedere ai file locali in base alle autorizzazioni del sistema operativo. I dati vengono inviati tramite HTTPS e criptati in transito. Per accedere a Cloud Storage devi disporre delle autorizzazioni di editor di oggetti bucket.
Storage Transfer Service Chiavi di accesso richieste per le risorse non Google Cloud (ad esempio, Amazon S3). Sono necessarie chiavi di accesso per accedere a Cloud Storage, la crittografia at-rest è crittografata. I dati vengono inviati tramite HTTPS e criptati in transito. Devi disporre delle autorizzazioni IAM per consentire all'account di servizio di accedere alle autorizzazioni di editor degli oggetti e dell'origine per qualsiasi di archiviazione dei bucket Cloud Storage.

Per ottenere miglioramenti di base per la sicurezza, i trasferimenti online Google Cloud utilizzando il comando gcloud storage vengono eseguiti tramite HTTPS, i dati vengono criptati in transito e tutti i dati Per impostazione predefinita, Cloud Storage è criptato at-rest. Se utilizzi Transfer Appliance, i token di sicurezza che controlli possono contribuire a proteggere i tuoi dati. In genere, consigliamo di coinvolgere il team di sicurezza per assicurarti che il piano di trasferimento soddisfi i requisiti della tua azienda e delle normative.

Prodotti per il trasferimento di terze parti

Per l'ottimizzazione avanzata a livello di rete o i flussi di lavoro continui di trasferimento di dati, potresti voler utilizzare strumenti più avanzati. Per informazioni sulle impostazioni vedi gli strumenti Partner Google Cloud.

Passaggio 4: valutazione degli approcci alla migrazione dei dati

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

  1. Trasferisci i dati dal sito precedente al nuovo sito.
  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 copia principale.
  5. Quando il sito precedente non è più necessario come opzione di riserva, ritiralo.

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

  • Quanti dati devi migrare?
  • Con quale frequenza cambiano questi dati?
  • Puoi permetterti il tempo di inattività rappresentato da un intervallo di apertura mentre eseguire la migrazione dei dati?
  • Qual è il tuo attuale modello di coerenza dei dati?

Non esiste un approccio migliore, la scelta di una di queste dipende dall'ambiente e i 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 del i requisiti della migrazione dei dati.

L'approccio di 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 il microservizio accesso ai dati l'importanza di un approccio umile.

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

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

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

Manutenzione pianificata

L'approccio alla manutenzione pianificata è ideale se i carichi di lavoro possono permettersi finestra di cutover. È programmata nel senso che puoi pianificare quando si verifica il periodo di transizione.

In questo approccio, la migrazione è composta dai seguenti passaggi:

  1. Copia i dati del sito precedente nel nuovo sito. Questa copia iniziale riduce al minimo la finestra di transizione. Dopo questa copia iniziale, devi copiare solo i dati che sono cambiati durante questa finestra.
  2. Esegui la convalida dei dati e i controlli di coerenza per confrontare i dati nel sito precedente con quelli copiati nel nuovo sito.
  3. Interrompi i carichi di lavoro e i servizi che hanno accesso in scrittura ai dati copiati, in modo che non vengano apportate ulteriori modifiche.
  4. Sincronizza le modifiche apportate dopo la copia iniziale.
  5. Esegui il refactoring dei carichi di lavoro e dei servizi per utilizzare il nuovo sito.
  6. Avvia i tuoi 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 principalmente sulle operazioni perché è necessario un refactoring minimo del carico di lavoro e dei servizi.

Replica continua

Poiché non tutti i carichi di lavoro possono permettersi un periodo di transizione lungo, puoi sviluppare l'approccio di manutenzione pianificata fornendo un meccanismo di replica continua dopo i passaggi iniziali di copia e convalida. Quando progetti un meccanismo come questo, devi anche tenere conto della frequenza con cui le modifiche vengono applicate ai dati. Potrebbe essere difficile mantenere sincronizzati due sistemi.

L'approccio di replica continua è più complesso dell'approccio di manutenzione pianificata. Tuttavia, l'approccio alla replica continua riduce al minimo per la finestra di migrazione completa richiesta, poiché riduce al minimo la quantità di dati che devi sincronizzare. La sequenza per una replica continua la migrazione è il seguente:

  1. Copia i dati del sito precedente nel nuovo sito. Questo il testo 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 la convalida dei dati e i controlli di coerenza per confrontare i dati nel sito precedente con quelli copiati nel nuovo sito.
  3. Configura un meccanismo di replica continua dal sito legacy 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 quello precedente.
  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 l'approccio di manutenzione pianificata, l'approccio di replica continua pone la maggior parte del carico sulle operazioni.

Y (scrittura e lettura)

Se i tuoi carichi di lavoro hanno requisiti rigidi per l'alta disponibilità e non puoi per garantire il tempo di inattività rappresentato da una finestra temporale, è necessario un approccio diverso. Per questo scenario, puoi utilizzare un approccio in questo documento viene definito Y (scrittura e lettura), un tipo di migrazione parallela. Con questo approccio, il carico di lavoro è scrivere e leggere i dati sia nell'infrastruttura sito nella nuova versione di Sites durante la migrazione. (in questo caso la lettera Y viene utilizzata 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 legacy e al nuovo sito e leggere dal sito precedente.
  2. Identifica i dati scritti prima di attivare le scritture nel nuovo sito e copiali dal sito precedente a quello nuovo. Insieme al refactoring precedente, questo garantisce l'allineamento degli archivi dati.
  3. Esegui convalida dei dati e controlli di coerenza che confrontino i dati nel sito precedente con quelli nel nuovo sito.
  4. Sposta le operazioni di lettura dal sito precedente al nuovo sito.
  5. Esegui un altro ciclo di convalida dei dati e controlli di coerenza per confrontare i dati nel 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 di sviluppo a causa dei molteplici refactoring.

Microservizio di accesso ai dati

Se vuoi ridurre lo sforzo di refactoring necessario per seguire l'approccio Y (scrittura e lettura), puoi centralizzare le operazioni di lettura e scrittura dei dati ristrutturando i carichi di lavoro e i servizi in modo da utilizzare un microservizio di accesso ai dati. Questo il microservizio scalabile diventa l'unica voce puntano al livello di archiviazione dei dati e funge da proxy per livello di sicurezza. Tra gli approcci discussi qui, questo offre la massima flessibilità, poiché puoi eseguire il refactoring di questo componente senza influire su altri componenti dell'architettura e senza richiedere una finestra di transizione.

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 eseguire il refactoring di tutti i carichi di lavoro e i servizi che accedono al livello di archiviazione dei dati. Questo approccio si riassume come segue:

  1. Esegui il refactoring del microservizio di accesso ai dati per scrivere dati sia nell'ambiente legacy sito nella nuova versione di Sites. Le letture vengono eseguite sul sito precedente.
  2. Identifica i dati scritti prima di attivare le scritture nel nuovo sito e copiali dal sito precedente al nuovo. Insieme alle precedente il refactoring, in questo modo ci assicuriamo che i datastore siano allineati.
  3. Esegui la convalida dei dati e i controlli di coerenza confrontando i dati nel sito precedente con quelli nel nuovo sito.
  4. Esegui il refactoring del microservizio di accesso ai dati in modo che possa leggere dal nuovo sito.
  5. Esegui un altro ciclo di convalida dei dati e controlli di coerenza confrontando i dati del sito precedente con quelli del nuovo sito.
  6. Esegui il refactoring del microservizio di accesso ai dati in modo che sia in sola scrittura 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 al microservice per l'accesso ai dati pone la maggior parte del carico sul lato dello sviluppo. Tuttavia, è molto più leggero rispetto all'approccio Y (scrittura e lettura), perché gli sforzi di refactoring sono incentrati sul microservizio di accesso ai dati.

Passaggio 5: prepara il trasferimento

Per un trasferimento di grandi dimensioni o con dipendenze significative, è importante per capire come far funzionare il tuo prodotto di trasferimento. Clienti in genere svolge questa procedura:

  1. Stima dei prezzi e del ROI. Questo passaggio offre molte opzioni per aiutarti a prendere una decisione.

  2. Test funzionale. In questo passaggio, confermi che il prodotto può essere sia stata configurata correttamente e che la connettività di rete (ove applicabile) funziona. Verifica inoltre di poter spostare un campione rappresentativo dei tuoi (inclusi i passaggi associati al mancato trasferimento, come lo spostamento di un'istanza VM) per viaggiare dall'origine alla destinazione.

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

    • Verifica di poter installare e utilizzare il trasferimento.
    • Evidenzia potenziali problemi che bloccano il movimento dei dati (ad es. percorsi di rete) o le tue operazioni (ad es. formazione necessaria in un passaggio non di trasferimento).

  3. Test delle prestazioni. In questo passaggio, esegui un trasferimento su un ampio campione di dati (in genere il 3-5%) dopo l'allocazione delle risorse di produzione per eseguire le seguenti operazioni:

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

Passaggio 6: garantire l'integrità del trasferimento

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

  • Attiva il controllo delle versioni e il backup nella destinazione per limitare i danni causati dalle 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), tasso di errori latenti di base del sistema di archiviazione di origine sottostante a partire da 0,0001% comporta comunque una perdita di dati di migliaia di file e gigabyte. In genere, le applicazioni in esecuzione all'origine tollerano già questi requisiti errori e, in questo caso, non è necessaria un'ulteriore convalida. In alcuni casi eccezionali scenari specifici (ad esempio, archiviazione a lungo termine), è necessaria un'ulteriore è considerata sicura l'eliminazione dei dati dall'origine.

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 per il trasferimento hanno e controlli di integrità dei dati. Tuttavia, a seconda del tuo profilo di rischio, potresti voler eseguire un ulteriore insieme di controlli sui dati e sulle app che li leggono prima di eliminarli dall'origine. Ad esempio, potresti voler verificare se un controllo di congruenza registrato e calcolato in modo indipendente corrisponde ai dati scritti nella destinazione o confermare che un set di dati utilizzato dall'applicazione è stato trasferito correttamente.

Passaggi successivi