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

Last reviewed 2023-11-13 UTC

Per molti clienti, il primo passo verso l'adozione di Google Cloud importa i propri dati in Google Cloud. Questo documento esplora il processo, dalla pianificazione di un trasferimento di dati all'uso delle best practice a implementare 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. Sebbene questi passaggi possano richiedere lo stesso tempo del trasferimento stesso, preparazioni di questo tipo possono aiutare a ridurre al minimo le interruzioni delle operazioni aziendali, durante il trasferimento.

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

Che cos'è il trasferimento di dati?

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

Il trasferimento di dati non è semplice come sembra

Si può avere la tentazione di considerare il trasferimento di dati come una gigantesca sessione FTP, in cui 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 si occupa il trasferimento, il personale che approva gli strumenti e l'architettura e stakeholder aziendali preoccupati del valore e delle interruzioni può portare i dati in movimento.
  • Scelta dello strumento di trasferimento più adatto in base a risorse, costi, tempo e altre considerazioni sul 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.

Questo documento ha lo scopo di aiutarti a iniziare a eseguire correttamente il trasferimento dell'IA.

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 richiede in genere 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 è responsabile delle precedenti responsabilità per il tuo trasferire il progetto e includerli nelle riunioni di pianificazione e decisionali appropriato. 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 in sinergia.
    • Collabora con i team all'interno della tua organizzazione per convalidarli o aggiornarli e i raggruppamenti.
  2. Identifica quali set di dati puoi spostare.
    • Valuta se i fattori normativi, di sicurezza o di altro tipo impedire 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 mobili, determina dove trasferire ciascun set di dati.
    • Registra l'opzione di archiviazione selezionata per archiviare i dati. In genere, il sistema di archiviazione di destinazione Google Cloud è Cloud Storage. Anche se hai bisogno di soluzioni più complesse una volta che le tue applicazioni sono attive e in esecuzione, Cloud Storage è un'opzione di archiviazione scalabile e durevole.
    • Comprendere quali criteri di accesso ai dati devono essere gestiti dopo la migrazione.
    • Determina se devi archiviare questi dati in regioni specifiche.
    • Pianifica come strutturare questi dati a destinazione. Per Ad esempio, sarà uguale o diverso alla fonte?
    • Determina se devi trasferire i dati in modo continuativo.
  4. Per i set di dati mobili, determina quali risorse sono disponibili per spostarli.
    • Data/ora: quando deve essere completato il trasferimento?
    • Costo: qual è il budget disponibile per il team e i costi del trasferimento?
    • Persone: chi è disponibile per eseguire il trasferimento?
    • Larghezza di banda (per i trasferimenti online): quanta larghezza è disponibile. la larghezza di banda per Google Cloud può essere allocata per un trasferimento quale periodo di tempo?

Prima di valutare e selezionare le opzioni di trasferimento nella fase successiva della pianificazione, ti consigliamo di valutare se una parte del tuo modello IT può essere migliorata, come governance dei dati, organizzazione e sicurezza.

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. Pianificare il trasferimento di dati è il momento ideale per analizzare le autorizzazioni IAM (Identity and Access Management) best practice per l'utilizzo sicuro di IAM. Questi problemi possono influire concedere l'accesso a spazio di archiviazione. Ad esempio, potresti porre dei limiti rigidi all'accesso in scrittura archiviati per motivi normativi, ma potresti consentire agli utenti e alle 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. Archiviazione dei dati nello stesso progetto Google Cloud in cui la tua applicazione potrebbe funzionare, ma potrebbe non essere ottimale da un punto di vista gestionale. Alcuni dei tuoi sviluppatori potrebbero non disporre dei privilegi visualizzare i dati di produzione. In questo caso, uno sviluppatore potrebbe sviluppare codice su un modello mentre un account di servizio con privilegi potrebbe accedere ai dati di produzione. Pertanto, potresti voler mantenere l'intero set di dati di produzione in un progetto Google Cloud, quindi utilizza un account di servizio per consentire l'accesso da ogni progetto dell'applicazione.

Google Cloud è organizzato in base ai 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 di trasferimento di dati, il team addetto ai trasferimenti deve prendere in considerazione diversi fattori, tra cui:

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

Costo

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

  • Costi di networking
    • Il traffico in entrata in Cloud Storage è gratuito. Tuttavia, se i tuoi dati su un cloud provider pubblico, puoi aspettarti di pagare 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 un altro cloud provider.
    • Se i tuoi dati sono ospitati in un data center privato ma potresti incorrere in costi aggiuntivi per a Google Cloud.
  • Costi di archiviazione e operazioni per Cloud Storage durante e dopo il trasferimento dei dati
  • Costi del prodotto (ad esempio, Transfer Appliance)
  • Costi del personale per l'assemblaggio del team e l'acquisizione di assistenza logistica

Data/ora trasferimento

Pochi aspetti dell'informatica evidenziano i limiti hardware delle reti trasferire grandi quantità di dati. Idealmente, puoi trasferire 1 GB in 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 per la tua attività.

Puoi usare la seguente calcolatrice per capire per quanto tempo viene effettuato un trasferimento potrebbe richiedere, date le dimensioni del set di dati che stai spostando e la larghezza disponibili 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 in grado di portare a termine il lavoro necessario o mission critical. Per questo motivo, il team di trasferimento deve considerare il fattore di tempo.

Dopo aver trasferito i dati in Cloud Storage, puoi utilizzare una serie di tecnologie per elaborare i nuovi file all'arrivo, come e Dataflow.

Aumento della larghezza di banda della rete

Il modo in cui aumenti la larghezza di banda della rete dipende dal modo in cui ti connetti in 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 stai trasferendo dati tra il tuo data center privato e Google Cloud, esistono diversi approcci, tra cui:

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

Nel valutare questi approcci, è utile considerare le opportunità a lungo termine le esigenze di connettività. 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 connettere le tue reti a per Google Cloud, consulta Scegli un prodotto per la 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. Controlla inoltre se il pubblico connessione a internet viene utilizzata per il traffico di produzione. Infine, considera che trasferimenti di dati su larga scala possono influire negativamente le prestazioni della tua rete di produzione.

Trasferimento online e offline

Una decisione fondamentale è se utilizzare un processo offline o online per i dati trasferimento. In altre parole, devi scegliere tra il trasferimento su una rete, Cloud Interconnect o la rete internet pubblica oppure il trasferimento mediante hardware di archiviazione.

Per aiutarti a prendere questa decisione, ti forniamo un calcolatore trasferimento per aiutarti a stimare le differenze in termini di tempi e costi tra queste due opzioni. Il grafico seguente mostra anche alcune velocità di trasferimento per diverse dimensioni di set di dati e le larghezze di banda. In queste risorse è incorporato un certo overhead di gestione calcoli.

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.

Scelta delle 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
Un altro cloud provider (ad esempio Amazon Web Services o Microsoft Azure) a Google Cloud. — Storage Transfer Service
Da Cloud Storage a Cloud Storage (due bucket diversi) — Storage Transfer Service
Dal tuo data center privato a Google Cloud Larghezza di banda sufficiente per rispettare la scadenza del progetto Comando gcloud storage
Dal tuo data center privato a Google Cloud Larghezza di banda sufficiente per rispettare la scadenza del progetto Storage Transfer Service per 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 piccoli trasferimenti 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. Mentre gcloud storage supporta il caricamento di oggetti verso l'alto alla dimensioni massime degli oggetti Cloud Storage, i trasferimenti di oggetti di grandi dimensioni hanno più probabilità di riscontrare errori rispetto ai trasferimenti a breve esecuzione. Per ulteriori informazioni sul trasferimento di oggetti di grandi dimensioni in Cloud Storage, consulta Storage Transfer Service per grandi trasferimenti di dati on-premise.

Il comando gcloud storage è particolarmente utile nei seguenti scenari:

  • I trasferimenti devono essere eseguiti secondo le necessità o durante e sessioni dalla riga di comando degli utenti.
  • Stai trasferendo pochi file, file molto grandi o entrambi.
  • Stai consumando l'output di un programma (flussi di dati Cloud Storage).
  • Devi controllare una directory con un numero moderato di file e sincronizzare 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. it dispone inoltre di una Graphic User Interface gestita; anche chi non ha competenze tecniche gli utenti (dopo la configurazione) possono utilizzarla per spostare i dati.

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

  • La larghezza di banda disponibile è sufficiente per spostare i volumi di dati (vedi il Calcolatore Data Transfer di Google Cloud).
  • Supporti un'ampia base di utenti interni che potrebbero trovare un prompt uno strumento difficile da usare.
  • Hai bisogno di un efficace rapporto degli errori e di un record di tutti i file e gli oggetti che vengono spostati.
  • Devi limitare l'impatto dei trasferimenti su altri carichi di lavoro nel tuo data center (questo prodotto può rimanere al di sotto del limite di larghezza di banda specificato dall'utente).
  • Vuoi eseguire trasferimenti ricorrenti in base a una pianificazione.

Per configurare Storage Transfer Service 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 trasferimenti in Console Google Cloud fornendo una directory di origine, un bucket di destinazione e un orario o la programmazione. 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 quanti file vengono spostati la velocità di trasferimento complessiva e potrai visualizzare esempi di errore.

Quando Storage Transfer Service completa un trasferimento, genera un testo delimitato da tabulazioni file (TSV) con un record completo di tutti i file interessati e gli eventuali messaggi di errore ricevuto. Gli agenti sono a tolleranza di errore, quindi se un agente non funziona, il trasferimento continua 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 si utilizza Storage Transfer Service:

  • Utilizza la stessa configurazione dell'agente 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 si traduce in una 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 consentono di proteggere i 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 per la revisione degli 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 gli errori potrebbero essere causati dall'esecuzione di app che scrivevano nell'origine è stato eseguito il trasferimento oppure gli errori potrebbero indicare un problema che richiede risoluzione dei problemi (ad esempio, un errore di autorizzazioni).
  • Configura Cloud Monitoring per i trasferimenti a lunga esecuzione. Storage Transfer Service consente a Monitoring di monitorare l'integrità dell'agente e la velocità effettiva, in modo da poter impostare avvisi che ti avvisano quando gli agenti non sono disponibili o richiedono attenzione. Intervenire in caso di errori degli agenti è importante per i trasferimenti richiedere diversi giorni o settimane, in modo da evitare rallentamenti o interruzioni che possono ritardare la sequenza temporale del progetto.

Transfer Appliance per trasferimenti di maggiori dimensioni

Per trasferimenti su larga scala (in particolare quelli con larghezza di banda di rete limitata), Transfer Appliance è un'opzione eccellente, soprattutto quando non è disponibile una connessione di rete veloce ed è troppo costoso acquisire più larghezza di banda.

Transfer Appliance è particolarmente utile nelle seguenti scenari aggiuntivi:

  • Il tuo data center si trova in una località remota con accesso limitato o assente alle e la larghezza di banda.
  • La larghezza di banda è disponibile, ma non può essere acquisita in tempo per soddisfare le tue la scadenza del periodo di conservazione.
  • Hai accesso alle risorse logistiche per ricevere e connetterti di rete alla tua rete.

Con questa opzione, considera quanto segue:

  • Transfer Appliance richiede che tu possa ricevere e rispedire l'hardware di proprietà di Google.
  • In base alla connessione a internet, la latenza per il trasferimento dei dati in Google Cloud è in genere più elevata Transfer Appliance piuttosto che online.
  • Transfer Appliance è disponibile solo in alcuni paesi.

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

L'acquisizione di 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 un numero di giorni per trasferire i tuoi dati l'appliance ("acquisizione dei dati") e spedirlo a Google.

Storage Transfer Service per trasferimenti da cloud a cloud

Storage Transfer Service è un servizio completamente gestito e a scalabilità elevata per automatizzare i trasferimenti da altri in Cloud Storage. Ad esempio, puoi utilizzare Storage Transfer Service da cui trasferire i 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 in byte, insieme a un hash MD5 codificato in Base64 dei contenuti del file. A volte le dimensioni del file e l'hash sono disponibili dal sito web di origine. Se non devi avere accesso locale ai file. In questo caso, potrebbe essere più semplice usa il comando gcloud storage, come descritto in precedenza.

Se hai in atto un trasferimento, Storage Transfer Service è un ottimo modo per e conservarli, in particolare durante il trasferimento da un altro cloud pubblico.

Se vuoi spostare i dati da un altro cloud non supportato da Storage Transfer Service, puoi utilizzare il comando gcloud storage da una di macchina virtuale ospitata nel 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. Nella tabella che segue vengono descritti questi degli aspetti della sicurezza per prodotto.

Prodotto Dati at-rest Dati in transito Accesso per trasferire il prodotto
Transfer Appliance Tutti i dati at-rest sono criptati. I dati sono protetti con chiavi gestite dal cliente. Chiunque può ordinare un'appliance, ma per utilizzarla deve poter accedere ai dati sorgente.
Comando gcloud storage 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 a riposo. Il processo dell'agente può accedere ai file locali in base alle autorizzazioni del sistema operativo. I dati vengono inviati tramite HTTPS e criptati in transito. Per accedere a Cloud Storage devi disporre delle autorizzazioni di editor di oggetti bucket.
Storage Transfer Service Chiavi di accesso necessarie per 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 contattare il team di sicurezza per verificare che il piano di trasferimento soddisfa i requisiti normativi e aziendali della tua azienda.

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

Durante la migrazione dei dati, puoi seguire questi passaggi generali:

  1. Trasferisci i dati dal sito precedente a quello nuovo.
  2. Risolvi eventuali problemi di integrazione dei dati, ad esempio la sincronizzazione degli stessi dati da più origini.
  3. Convalida la migrazione dei dati.
  4. Promuovi il nuovo sito come testo principale.
  5. Quando non hai più bisogno del sito precedente come opzione di riserva, ritiralo.

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

  • Quanti dati servono per la migrazione?
  • Con quale frequenza cambiano questi dati?
  • Puoi permetterti il tempo di inattività rappresentato da una finestra di migrazione completa 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 ai requisiti della migrazione dei dati.

L'approccio basato sui microservizi di accesso ai dati è l'opzione preferita in una di microservizi. Tuttavia, gli altri approcci sono utili per i dati migrazione. 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 grafico seguente delinea le dimensioni delle rispettive finestre di cut-over, refactoring le proprietà di ciascuno di questi approcci in termini di impegno e flessibilità.

Grafico a barre con ciascuna barra che mostra i valori relativi di flessibilità, sforzo di refactoring e dimensioni delle finestre di migrazione completa per ciascuno dei 4 approcci

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

Manutenzione pianificata

L'approccio alla manutenzione pianificata è ideale se i carichi di lavoro possono permettersi finestra di apertura. È stato pianificato nel senso che potete pianificare quando o una finestra di cutover.

In questo approccio, la migrazione prevede i seguenti passaggi:

  1. Copia i dati del sito precedente nel nuovo sito. Questo il testo iniziale riduce al minimo la finestra di migrazione completa; Dopo questa copia iniziale, devi copiare solo i dati che sono stati modificati in questa finestra.
  2. Esegui controlli di convalida e coerenza dei dati per confrontare i dati in rispetto ai dati copiati nel nuovo sito.
  3. Arresta i carichi di lavoro e i servizi con accesso in scrittura al file copiato dati in modo che non si verifichino ulteriori modifiche.
  4. Sincronizza le modifiche apportate dopo la copia iniziale.
  5. Esegui il refactoring dei carichi di lavoro e dei servizi in modo che utilizzino il nuovo sito.
  6. Avvia i tuoi carichi di lavoro e i tuoi servizi.
  7. Quando non hai più bisogno del sito precedente come opzione di riserva ritiralo.

L'approccio della manutenzione pianificata grava 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 lungo periodo di migrazione, puoi basarti su l'approccio alla manutenzione pianificata fornendo una replica continua meccanismo di attenzione dopo le fasi iniziali di copia e convalida. Quando progetti meccanismo di attenzione, come questo, dovresti prendere in considerazione anche la frequenza con cui cambia vengono applicate ai dati dell'organizzazione; potrebbe essere difficile mantenere due sistemi sincronizzati.

L'approccio di replica continua è più complesso di quello pianificato di manutenzione. 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 controlli di convalida e coerenza dei dati per confrontare i dati in rispetto ai dati 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 il sito precedente sito.
  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.

Analogamente all'approccio della manutenzione pianificata, l'approccio alla replica continua il carico sul fronte operativo.

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 al nuovo sito e leggere dal sito precedente.
  2. Identifica i dati scritti prima dell'attivazione delle scritture nel nuovo sito e copiarlo dal sito precedente a quello nuovo. Insieme alle precedente il refactoring, in questo modo ci assicuriamo che i datastore siano allineati.
  3. Esegui controlli di convalida e coerenza dei dati che confrontano i dati in del sito precedente rispetto ai dati nel nuovo sito.
  4. Sposta le operazioni di lettura dal sito precedente al nuovo sito.
  5. Esegui un'altra serie di controlli di convalida e coerenza dei dati per Confrontare i dati del sito precedente con quelli del nuovo sito.
  6. Disattiva la scrittura nel sito precedente.
  7. Quando non hai più bisogno del sito precedente come opzione di riserva ritiralo.

A differenza degli approcci di manutenzione pianificata e replica continua, L'approccio Y (scrittura e lettura) sposta la maggior parte degli sforzi dalle operazioni lato sviluppo a causa dei molteplici refactoring.

Microservizio di accesso ai dati

Se volete ridurre il refactoring necessario per seguire la Y (scrivendo e lettura), puoi centralizzare le operazioni di lettura e scrittura dei dati il refactoring di carichi di lavoro e 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à, perché puoi eseguire il refactoring di questo componente senza influire sugli altri componenti dell'architettura e senza richiedere una finestra di migrazione completa.

L'utilizzo di un microservizio di accesso ai dati è molto simile alla Y (scrittura e lettura) l'importanza di un approccio umile. La differenza è che le iniziative di refactoring si concentrano il solo microservizio di accesso ai dati, invece di dover eseguire il refactoring di tutti i carichi di lavoro e i servizi che accedono al livello di archiviazione dei dati. Questo approccio è riassunto come che 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 dell'attivazione delle scritture nel nuovo e copiarlo dal sito precedente a quello nuovo. Insieme alle precedente il refactoring, in questo modo ci assicuriamo che i datastore siano allineati.
  3. Esegui controlli di convalida e coerenza dei dati che mettono a confronto i dati del sito precedente rispetto ai dati nel nuovo sito.
  4. Esegui il refactoring del microservizio di accesso ai dati in modo che possa leggere dal nuovo sito.
  5. Esegui un'altra serie di controlli di convalida e coerenza dei dati Confrontando i dati del sito precedente con quelli del nuovo sito.
  6. Esegui il refactoring del microservizio di accesso ai dati in modo che scriva solo nel nuovo sito.
  7. Quando non hai più bisogno del sito precedente come opzione di riserva ritiralo.

Come l'approccio Y (scrittura e lettura), il microservizio di accesso ai dati grava sul lato dello sviluppo. Tuttavia, molto più leggero rispetto all'approccio Y (scrittura e lettura), perché le attività di refactoring si concentrano sul microservizio accesso ai dati.

Passaggio 5: prepara il trasferimento

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

  1. Determinazione dei prezzi e stima del ROI. Questo passaggio offre molte opzioni per nel processo decisionale.

  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, ad esempio macchine per il trasferimento o per la larghezza di banda. Gli obiettivi di questo passaggio includono:

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

  3. Test delle prestazioni. In questo passaggio, eseguirai un trasferimento su un dei dati (in genere il 3-5%) dopo che le risorse di produzione allocati per:

    • 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: verifica l'integrità del trasferimento

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

  • Abilita il controllo delle versioni e il backup nella tua destinazione per limitare i danni dei 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 di archiviazione a lungo termine, è necessaria un'ulteriore convalida prima è 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 dopo il completamento del trasferimento per garantire che continua 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 di eseguire una serie di controlli aggiuntivi sui dati e sulle app che li leggono prima elimini i dati dall'origine. Ad esempio, potresti voler verificare se un checksum registrato e calcolato in modo indipendente che corrisponde ai dati scritti o conferma che un set di dati utilizzato dall'applicazione Trasferimento riuscito.

Passaggi successivi