Progetta i tuoi carichi di lavoro

Last reviewed 2024-07-24 UTC

Questo documento ti aiuta a progettare i carichi di lavoro in modo da ridurre al minimo l'impatto di una futura espansione e migrazione dei carichi di lavoro in altre regioni Google Cloud o l'impatto di una migrazione dei carichi di lavoro tra regioni. Questo documento è utile se prevedi di svolgere una di queste attività o se stai valutando la possibilità di farlo in futuro e vuoi scoprire come potrebbe essere il lavoro.

Questo documento fa parte di una serie:

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 ti aiuta a:

  1. Prepara la zona di destinazione
  2. Preparare i workload per una migrazione tra regioni
  3. Prepara le risorse di calcolo
  4. Prepara le risorse di archiviazione dei dati
  5. Prepararsi al ritiro dell'ambiente di origine

Prepara la zona di destinazione

Questa sezione si concentra sulle considerazioni che devi fare per estendere una zona di destinazione (chiamata anche cloud foundation) durante la migrazione tra regioni.

Il primo passaggio consiste nel rivalutare i diversi aspetti di eventuali zone di destinazione esistenti. Prima di poter eseguire la migrazione di qualsiasi carico di lavoro, devi già avere una landing zone. Anche se potresti avere già implementato una landing zone per la regione che ospita i carichi di lavoro, la landing zone potrebbe non supportare il deployment di carichi di lavoro in una regione diversa, quindi deve essere estesa alla regione di destinazione. Alcune zone di destinazione già implementate potrebbero avere un design che può supportare un'altra regione senza modifiche significative alla zona di destinazione (ad esempio, gestione delle identità e dell'accesso o gestione delle risorse). Tuttavia, fattori aggiuntivi come la rete o i dati potrebbero richiedere una certa pianificazione per l'estensione. Il processo di rivalutazione deve tenere conto dei principali requisiti dei carichi di lavoro per consentirti di configurare una base generica che può essere specializzata in un secondo momento durante la migrazione.

Considerazioni aziendali

Per quanto riguarda aspetti quali standard, normative e certificazioni di settore e governative, il trasferimento dei carichi di lavoro in un'altra regione può avere requisiti diversi. I carichi di lavoro in esecuzione nelle regioni Google fisicamente situate in paesi diversi devono rispettare le leggi e le normative di quel paese. Inoltre, diversi standard di settore potrebbero avere requisiti specifici per i carichi di lavoro eseguiti all'estero (in particolare in termini di sicurezza). Poiché le regioni Google Cloud sono progettate per eseguire risorse in un singolo paese, a volte i carichi di lavoro vengono migrati da un'altra regione Google a quel paese per rispettare normative specifiche. Quando esegui queste migrazioni "in-country", è importante rivalutare i dati in esecuzione on-premise per verificare se la nuova regione consente la migrazione dei dati a Google Cloud.

Gestione di identità e accessi

Quando pianifichi una migrazione, probabilmente non devi prevedere molte modifiche di identità e accesso per le regioni già su Google Cloud. Le decisioni relative all'identità su Google Cloud e all'accesso alle risorse si basano in genere sulla natura delle risorse anziché sulla regione in cui vengono eseguite. Di seguito sono riportate alcune considerazioni che potresti dover fare:

  • Design dei team: alcune aziende sono strutturate in modo da avere team diversi per gestire risorse diverse. Quando viene eseguita la migrazione di un carico di lavoro in un'altra regione a causa della modifica della struttura delle risorse, un altro team potrebbe essere il candidato migliore per essere responsabile di determinate risorse. In questo caso, gli accessi devono essere adeguati di conseguenza.
  • Convenzioni di denominazione: anche se le convenzioni di denominazione potrebbero non avere alcun impatto tecnico sulle funzionalità, potrebbe essere necessario prendere in considerazione alcuni aspetti se esistono risorse definite con convenzioni di denominazione che fanno riferimento alla regione specifica. Un esempio tipico è quando sono già presenti più regioni replicate, ad esempio le macchine virtuali (VM) Compute Engine, che sono denominate con la regione come prefisso, ad esempioeurope-west1-backend-1. Durante la procedura di migrazione, per evitare confusione o, peggio, interruzioni delle pipeline che si basano su una convenzione di denominazione specifica, è importante modificare i nomi in modo che riflettano la nuova regione.

Connettività e reti

La progettazione della rete influisce su più aspetti dell'esecuzione della migrazione, quindi è importante occuparsene prima di pianificare il trasferimento dei carichi di lavoro.

Tieni presente che la connettività on-premise con Google Cloud è uno dei fattori che devi rivalutare durante la migrazione, poiché può essere progettata per essere specifica per regione. Un esempio di questo fattore è Cloud Interconnect, che è connesso a Google Cloud tramite un collegamento VLAN a regioni specifiche. Devi modificare la regione in cui è collegato il collegamento VLAN prima di ignorare la regione per evitare il traffico tra regioni. Un altro fattore da considerare è che, se utilizzi Partner Interconnect, la migrazione della regione può aiutarti a selezionare una posizione fisica diversa su cui collegare i tuoi allegati VLAN a Google Cloud. Questa considerazione è anche pertinente se utilizzi una Cloud VPN e decidi di modificare gli indirizzi di sottorete durante la migrazione: devi ricollegare i router in base alla nuova rete.

Sebbene i VPC (Virtual Private Cloud) su Google Cloud siano risorse globali, le singole subnet sono sempre associate a una regione, il che significa che non puoi utilizzare la stessa subnet per i carichi di lavoro dopo la migrazione. Poiché le subnet non possono avere indirizzi IP sovrapposti, per mantenere gli stessi indirizzi devi creare una nuova VPC. Questa procedura è semplificata se utilizzi Cloud DNS, che può sfruttare funzionalità come il peering DNS per indirizzare il traffico per i carichi di lavoro di cui è stata eseguita la migrazione prima di ignorare la vecchia regione.

Per ulteriori informazioni sulla creazione di una base su Google Cloud, consulta Eseguire la migrazione a Google Cloud: pianificare e creare le basi.

Preparare i workload per una migrazione tra regioni

Che tu stia configurando la tua infrastruttura su Google Cloud e preveda di eseguire in un secondo momento la migrazione in un'altra regione o che tu stia già utilizzando Google Cloud e debba eseguire la migrazione in un'altra regione, devi assicurarti che sia possibile eseguire la migrazione dei tuoi carichi di lavoro nel modo più semplice per ridurre le attività e minimizzare i rischi. Per aiutarti ad assicurarti che tutti i carichi di lavoro siano in uno stato che consenta un percorso per la migrazione, ti consigliamo di seguire il seguente approccio:

  • Preferisci design di rete facilmente replicabili e a basso accoppiamento dalla topologia di rete specifica. Google Cloud offre diversi prodotti che possono aiutarti a disaccoppiare la tua attuale configurazione di rete dalle risorse che la utilizzano. Un esempio di questo tipo di prodotto è Cloud DNS, che consente di disaccoppiare gli indirizzi IP delle sottoreti interne dalle VM.
  • Configura i prodotti che supportano configurazioni multiregionali o globali. I prodotti che supportano una configurazione che coinvolge più regioni solitamente semplificano la procedura di migrazione in un'altra regione.
  • Valuta la possibilità di utilizzare servizi gestiti con repliche tra regioni gestite per i dati. Come descritto nelle sezioni seguenti di questo documento, alcuni servizi gestiti consentono di creare una replica in una regione diversa, in genere per il backup o per scopi di alta disponibilità. Questa funzionalità può essere importante per eseguire la migrazione dei dati da una regione all'altra.

Alcuni servizi Google Cloud sono progettati per supportare deployment multiregione o deployment globale. Non è necessario eseguire la migrazione di questi servizi, anche se potrebbe essere necessario modificare alcune configurazioni.

Prepara le risorse di calcolo

Questa sezione fornisce una panoramica delle risorse di calcolo su Google Cloud e dei principi di progettazione per prepararsi a una migrazione in un'altra regione.

Questo documento si concentra sui seguenti prodotti di cloud computing di Google Cloud:

Compute Engine

Compute Engine è il servizio di Google Cloud che fornisce VM ai clienti.

Per eseguire la migrazione delle risorse Compute Engine da una regione all'altra, devi valutare diversi fattori, oltre alle considerazioni sulla rete.

Ti consigliamo di procedere come segue:

  • Controlla le risorse di calcolo: uno dei primi limiti che puoi riscontrare quando cambi la regione di hosting di una VM è la disponibilità della piattaforma CPU nella nuova regione di destinazione. Se devi cambiare una serie di macchine durante la migrazione, verifica che il sistema operativo della tua VM attuale sia supportato per la serie. In generale, questo problema può essere esteso a tutti i servizi di calcolo di Google Cloud (alcune nuove regioni potrebbero non avere servizi come Cloud Run o Cloud GPU), quindi prima di pianificare la migrazione, assicurati che tutti i servizi di calcolo di cui hai bisogno siano disponibili nella regione di destinazione.
  • Configura il bilanciamento del carico e la scalabilità: Compute Engine supporta il bilanciamento del carico del traffico tra le istanze Compute Engine e la scalabilità automatica per aggiungere o rimuovere automaticamente le macchine virtuali dai gruppi di istanze gestite in base alla domanda. Ti consigliamo di configurare il bilanciamento del carico e l'autoscaling per aumentare l'affidabilità e la flessibilità dei tuoi ambienti, evitando il carico di gestione delle soluzioni self-managed. Per maggiori informazioni sulla configurazione del bilanciamento del carico e della scalabilità per Compute Engine, consulta Bilanciamento del carico e scalabilità.
  • Utilizza i nomi DNS di zona: per ridurre il rischio di interruzioni tra regioni, ti consigliamo di utilizzare nomi DNS di zona per identificare in modo univoco le macchine virtuali che utilizzano nomi DNS nei tuoi ambienti. Google Cloud utilizza per impostazione predefinita i nomi DNS zonali per le macchine virtuali Compute Engine. Per ulteriori informazioni su come funziona il DNS interno di Compute Engine, consulta la Panoramica del DNS interno. Per facilitare una futura migrazione tra regioni e per rendere la configurazione più gestibile, ti consigliamo di considerare i nomi DNS di zona come parametri di configurazione che potrai eventualmente modificare in futuro.
  • Utilizza lo stesso modello di gruppi di istanze gestite: Compute Engine ti consente di creare gruppi di istanze gestite a livello di regione che eseguono il provisioning automatico delle macchine virtuali in più zone di una regione. Se utilizzi un modello nella vecchia regione, puoi utilizzare lo stesso modello per eseguire il deployment dei MIG nella nuova regione.

GKE

Google Kubernetes Engine (GKE) ti aiuta a eseguire il deployment, gestire e scalare i workload containerizzati su Kubernetes.

Per preparare i carichi di lavoro GKE per una migrazione, tieni conto delle seguenti funzionalità e dei seguenti punti di progettazione di GKE:

  • Cloud Service Mesh: un'implementazione gestita del mesh Istio. L'adozione di Cloud Service Mesh per il tuo cluster ti consente di avere un maggiore livello di controllo sul traffico di rete all'interno del cluster. Una delle funzionalità principali di Cloud Service Mesh è che consente di creare un mesh di servizi tra due cluster. Puoi utilizzare questa funzionalità per pianificare la migrazione da una regione all'altra creando il cluster GKE nella nuova regione e aggiungendolo al mesh di servizi. Con questo approccio è possibile iniziare a eseguire il deployment dei carichi di lavoro nel nuovo cluster e a instradare gradualmente il traffico verso di essi, il che ti consente di testare il nuovo deployment e di eseguire il rollback modificando il routing mesh.
  • Config Sync: un servizio GitOps basato su un core open source che consente agli operatori di cluster e agli amministratori della piattaforma di eseguire il deployment delle configurazioni da un'unica origine. Config Sync può supportare uno o più cluster, consentendoti di utilizzare un'unica fonte attendibile per configurare i cluster. Puoi utilizzare questa funzione di Config Sync per replicare la configurazione del cluster esistente nel cluster per la nuova regione e potenzialmente personalizzare una risorsa specifica per la regione.
  • Backup per GKE: questa funzionalità consente di eseguire periodicamente il backup dei dati persistenti del cluster e di ripristinarli nello stesso cluster o in uno nuovo.

Cloud Run

Cloud Run offre un approccio snello per eseguire il deployment dei container su Google Cloud. I servizi Cloud Run sono risorse regionali e vengono replicati in più zone della regione in cui si trovano. Quando esegui il deployment di un servizio Cloud Run, puoi scegliere una regione in cui eseguire il deployment dell'istanza e poi utilizzare questa funzionalità per eseguire il deployment del carico di lavoro in un'altra regione.

VMware Engine

Google Cloud VMware Engine è un servizio completamente gestito che ti consente di eseguire la piattaforma VMware in Google Cloud. L'ambiente VMware viene eseguito in modo nativo sull'infrastruttura bare metal di Google Cloud nelle località di Google Cloud, tra cui vSphere, vCenter, vSAN, NSX-T, HCX e gli strumenti corrispondenti.

Per eseguire la migrazione delle istanze VMware Engine in un'altra regione, devi creare il tuo cloud privato nella nuova regione e poi utilizzare gli strumenti VMware per spostare le istanze.

Quando pianifichi la migrazione, devi anche considerare il DNS e il bilanciamento del carico negli ambienti Compute Engine. VMware Engine utilizza Google Cloud DNS, un servizio di hosting DNS gestito che fornisce hosting DNS autorevole pubblicato su internet pubblico, zone private visibili alle reti VPC e inoltro e peering DNS per la gestione della risoluzione dei nomi sulle reti VPC. Il
piano di migrazione può supportare il test del bilanciamento del carico multiregionale e delle configurazioni DNS.

Prepara le risorse di archiviazione dei dati

Questa sezione fornisce una panoramica delle risorse di archiviazione dei dati su Google Cloud e le nozioni di base su come prepararsi a una migrazione in un'altra regione.

La presenza dei dati già su Google Cloud semplifica la migrazione, perché implica che esista o possa essere ospitata su Google Cloud una soluzione per ospitarli senza alcuna trasformazione.

La possibilità di copiare i dati di un database in un'altra regione e ripristinarli altrove è uno schema comune nel ripristino di emergenza (RE). Per questo motivo, alcuni dei pattern descritti in questo documento si basano su meccanismi di RE come il backup e il recupero del database.

In questo documento sono descritti i seguenti servizi gestiti:

Questo documento presuppone che le soluzioni di archiviazione in uso siano istanze regionali colocate con le risorse di calcolo.

Cloud Storage

Cloud Storage offre Storage Transfer Service, che automatizza il trasferimento di file da diversi sistemi a Cloud Storage. Può essere utilizzato per replicare i dati in una regione diversa per il backup e anche per la migrazione da una regione all'altra.

Cloud SQL

Cloud SQL offre un servizio di database relazionale per ospitare diversi tipi di database. Cloud SQL offre una funzionalità di replica tra regioni che consente di replicare i dati delle istanze in una regione diversa. Questa funzionalità è uno schema comune per il backup e il ripristino delle istanze Cloud SQL, ma ti consente anche di promuovere la seconda replica nell'altra regione a replica principale. Puoi utilizzare questa funzionalità per creare una replica di lettura nella seconda regione e poi promuoverla a replica principale dopo la migrazione dei carichi di lavoro. In generale, per i database, i servizi gestiti semplificano il processo di replica dei dati per semplificare la creazione di una replica nella nuova regione durante la migrazione.

Un altro modo per gestire la migrazione è utilizzare Database Migration Service, che consente di eseguire la migrazione dei database SQL da diverse origini a Google Cloud. Tra le origini supportate è presente anche un'altra istanza Cloud SQL, con l'unica limitazione che puoi eseguire la migrazione a una regione diversa, ma non a un progetto diverso.

Filestore

Come spiegato in precedenza in questo documento, la funzionalità di backup e ripristino di Filestore consente di creare un backup di una condivisione file che può essere ripristinata in un'altra regione. Questa funzionalità può essere utilizzata per eseguire la migrazione da una regione all'altra.

Bigtable

Come per Cloud SQL, Bigtable supporta la replica. Puoi utilizzare questa funzionalità per replicare lo stesso schema descritto. Controlla nell'elenco delle località Bigtable se il servizio è disponibile nella regione di destinazione.

Inoltre, come per Filestore, Bigtable supporta il backup e il ripristino. Questa funzionalità può essere utilizzata, come per Filestore, per implementare la migrazione creando un backup e ripristinandolo in un'altra istanza nella nuova regione.

L'ultima opzione è esportare le tabelle, ad esempio in Cloud Storage. Queste esportazioni ospiteranno i dati in un altro servizio, che potranno poi essere importati nell'istanza nella regione.

Firestore

Le località di Firestore potrebbero essere legate alla presenza di App Engine nel progetto, il che in alcuni scenari forza l'istanza Firestore a essere multi-regione. In questi scenari di migrazione, è necessario prendere in considerazione anche App Engine per progettare la soluzione giusta per Firestore. Infatti, se hai già un'app App Engine con una località us-central o
europe-west, il tuo database Firestore è considerato multiregionale.

Se hai una posizione a livello di regione e vuoi eseguire la migrazione a una posizione diversa, il servizio di esportazione e importazione gestito ti consente di importare e esportare entità Firestore utilizzando un bucket Cloud Storage. Questo metodo può essere utilizzato per spostare le istanze da una regione all'altra. L'altra opzione è utilizzare la funzionalità di backup e ripristino di Firestore. Questa opzione è meno costosa e più semplice rispetto all'importazione e all'esportazione.

Prepararsi al ritiro dell'ambiente di origine

Devi prepararti in anticipo prima di ritirare l'ambiente di origine e passare al nuovo.

A livello generale, prima di eseguire il ritiro dell'ambiente di origine, devi prendere in considerazione quanto segue:

  • Test del nuovo ambiente: prima di trasferire il traffico dall'ambiente precedente a quello nuovo, puoi eseguire test per convalidare la correttezza delle applicazioni. Oltre ai classici test di unità e di integrazione che possono essere eseguiti sulle applicazioni di cui è stata eseguita la migrazione di recente, esistono diverse strategie di test. Il nuovo ambiente può essere considerato come una nuova versione del software e la migrazione del traffico può essere implementata con pattern comuni come i test A/B utilizzati per la convalida. Un altro approccio consiste nel replicare il traffico in input nell'ambiente di origine e nel nuovo ambiente per verificare che le funzioni siano conservate.
  • Pianificazione del tempo di riposo: se selezioni una strategia di migrazione come quella blue-green, in cui trasferisci il traffico da un ambiente all'altro, valuta la possibilità di adottare un tempo di riposo pianificato. Il tempo di riposo consente di monitorare meglio la transizione ed evitare errori imprevedibili sul lato client.
  • Rollback: a seconda delle strategie adottate per la migrazione del traffico, potrebbe essere necessario implementare un rollback in caso di errori o di mancata configurazione del nuovo ambiente. Per poter eseguire il rollback dell'ambiente, devi disporre di un'infrastruttura di monitoraggio per rilevare lo stato del nuovo ambiente.

È possibile arrestare i servizi nella prima regione solo dopo aver eseguito test estesi nella nuova regione e averla messa in produzione senza errori. Ti consigliamo di conservare i backup della prima regione per un periodo di tempo limitato, fino a quando non avrai la certezza che non ci siano problemi nella regione di nuova migrazione.

Valuta anche se vuoi promuovere la vecchia regione a un sito di recupero in caso di catastrofe, supponendo che non sia già stata implementata una soluzione. Questo approccio richiede un design aggiuntivo per garantire l'affidabilità del sito. Per ulteriori informazioni su come progettare e pianificare correttamente il RE, consulta la guida alla pianificazione del ripristino di emergenza.

Passaggi successivi

Collaboratori

Autore: Valerio Ponza | Technical Solution Consultant

Altri collaboratori: