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 Google Cloud regioni 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 l'opportunità di farlo in futuro e vuoi esplorare 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 in più regioni. In questo caso, potrebbe essere necessario dedicare ulteriore impegno alla preparazione dell'infrastruttura, dei workload e dei 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 computing
  4. Prepara le risorse di archiviazione dei dati
  5. Prepararsi per il ritiro dell'ambiente di origine

Prepara la zona di destinazione

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

Il primo passaggio consiste nel rivalutare i diversi aspetti di qualsiasi zona di destinazione esistente. Prima di poter eseguire la migrazione di un workload, devi già avere una landing zone. Anche se potresti già avere una landing zone per la regione che ospita i carichi di lavoro, la landing zone potrebbe non supportare il deployment dei carichi di lavoro in un'altra regione, quindi deve essere estesa alla regione di destinazione. Alcune zone di destinazione già in uso potrebbero avere una progettazione in grado di supportare un'altra regione senza modifiche significative alla zona di destinazione (ad esempio, gestione di identità e accessi o gestione delle risorse). Tuttavia, fattori aggiuntivi come la rete o i dati potrebbero richiedere una 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 per le aziende

Per quanto riguarda aspetti come standard di settore e governativi, normative e certificazioni, lo spostamento dei carichi di lavoro in un'altra regione può comportare requisiti diversi. I carichi di lavoro in esecuzione nelle regioni Google situate fisicamente in paesi diversi devono rispettare le leggi e i regolamenti di quel paese. Inoltre, standard di settore diversi potrebbero avere requisiti particolari per i carichi di lavoro eseguiti all'estero (soprattutto in termini di sicurezza). Poiché le Google Cloud regioni sono create 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 "nel paese", è importante rivalutare i dati eseguiti 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 pianificare molte modifiche all'identità e all'accesso per le regioni che utilizzano già Google Cloud. Le decisioni sull'identità Google Cloud e sull'accesso alle risorse si basano in genere sulla natura delle risorse piuttosto che sulla regione in cui vengono eseguite. Di seguito sono riportate alcune considerazioni che potresti dover fare:

  • Struttura dei team: alcune aziende sono strutturate in modo da avere team diversi per gestire risorse diverse. Quando un carico di lavoro viene migrato 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, nel qual caso, gli accessi devono essere modificati 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 alcune 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, denominate con la regione come prefisso, ad esempio europe-west1-backend-1. Durante il processo di migrazione, per evitare confusione o, peggio ancora, l'interruzione 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 diversi aspetti dell'esecuzione della migrazione, quindi è importante affrontare questo aspetto prima di pianificare lo spostamento dei carichi di lavoro.

Tieni presente che la connettività on-premise con Google Cloud è uno dei fattori che devi rivalutare nella migrazione, in quanto 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 è connesso il collegamento VLAN prima di chiudere 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 a cui collegare i tuoi collegamenti VLAN a Google Cloud. Questa considerazione è pertinente anche se utilizzi una Cloud VPN e decidi di modificare gli indirizzi delle subnet durante la migrazione: devi riconfigurare i router in modo che riflettano la nuova rete.

Sebbene i virtual private cloud (VPC) 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 sovrapporsi agli indirizzi IP, per mantenere gli stessi indirizzi devi creare un nuovo VPC. Questo processo è semplificato se utilizzi Cloud DNS, che può sfruttare funzionalità come il peering DNS per indirizzare il traffico per i carichi di lavoro migrati prima di chiudere la vecchia regione.

Per saperne di più su come creare una base su Google Cloud, consulta la pagina Eseguire la migrazione a Google Cloud: pianificare e creare la base.

Preparare i workload per una migrazione tra regioni

Se stai configurando la tua infrastruttura su Google Cloud e prevedi di eseguire la migrazione a un'altra regione in un secondo momento oppure se utilizzi già Google Cloude devi eseguire la migrazione a un'altra regione, devi assicurarti che i tuoi carichi di lavoro possano essere migrati nel modo più semplice per ridurre l'impegno e minimizzare i rischi. Per assicurarti che tutti i carichi di lavoro siano in uno stato che consenta un percorso di migrazione, ti consigliamo di adottare il seguente approccio:

  • Preferisci progetti di rete facilmente replicabili e con a basso accoppiamento rispetto alla topologia di rete specifica. Google Cloud offre diversi prodotti che possono aiutarti a separare la configurazione di rete attuale dalle risorse che utilizzano la rete. Un esempio di questo prodotto è Cloud DNS, che consente di separare gli IP delle subnet interne dalle VM.
  • Configura i prodotti che supportano configurazioni globali o multiregionali. I prodotti che supportano una configurazione che coinvolge più di una regione di solito semplificano il processo di migrazione a 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 a scopo di backup o di alta disponibilità. Questa funzionalità può essere importante per eseguire la migrazione dei dati da una regione all'altra.

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

Prepara le risorse di computing

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

Questo documento è incentrato sui seguenti prodotti Google Cloud informatici:

Compute Engine

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

Per eseguire la migrazione delle risorse Compute Engine da una regione a un'altra, devi valutare diversi fattori oltre alle considerazioni sul networking.

Ti consigliamo di procedere come segue:

  • Controlla le risorse di calcolo: una delle prime limitazioni che puoi riscontrare quando modifichi la regione di hosting di una VM è la disponibilità della piattaforma CPU nella nuova regione di destinazione. Se devi modificare 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 ogni Google Cloud servizio di computing (alcune nuove regioni potrebbero non disporre di servizi come Cloud Run o Cloud GPU), quindi prima di pianificare la migrazione, assicurati che tutti i servizi di computing che ti servono 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 di Compute Engine e la scalabilità automatica per aggiungere o rimuovere automaticamente le macchine virtuali dai MIG, in base alla domanda. Ti consigliamo di configurare il bilanciamento del carico e lo scaling automatico per aumentare l'affidabilità e la flessibilità dei tuoi ambienti, evitando l'onere di gestione delle soluzioni autogestite. Per ulteriori informazioni sulla configurazione del bilanciamento del carico e dello scaling per Compute Engine, vedi Bilanciamento del carico e scalabilità.
  • Utilizza 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 utilizzando nomi DNS nei tuoi ambienti. Google Cloud utilizza nomi DNS di zona per le macchine virtuali Compute Engine per impostazione predefinita. Per saperne di più 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 modificare in futuro.
  • Utilizza lo stesso modello di gruppi di istanze gestite (MIG): Compute Engine ti consente di creare MIG a livello di regione che eseguono automaticamente il provisioning delle macchine virtuali in più zone di una regione. Se utilizzi un modello nella tua 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, considera i seguenti punti di progettazione e funzionalità 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 controllo sul traffico di rete nel 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. Utilizzando questo approccio, è possibile iniziare a eseguire il deployment dei carichi di lavoro nel nuovo cluster e a indirizzare gradualmente il traffico verso di essi, consentendoti 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 sul 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 leggero per 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 workload 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 su Google Cloud infrastruttura bare metal in Google Cloud posizioni che includono 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 cloud privato nella nuova regione e poi utilizzare gli strumenti VMware per spostare le istanze.

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

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 per una migrazione a un'altra regione.

La presenza dei dati già su Google Cloud semplifica la migrazione, perché implica che esiste o può essere ospitata su Google Clouduna soluzione per ospitarli senza alcuna trasformazione.

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

In questo documento vengono descritti i seguenti servizi gestiti:

Questo documento presuppone che le soluzioni di archiviazione che utilizzi siano istanze regionali collocate insieme alle 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 dell'istanza in una regione diversa. Questa funzionalità è un pattern 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 aver eseguito la migrazione dei carichi di lavoro. In generale, per i database, i servizi gestiti semplificano il processo di replica dei dati, per facilitare 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 origini diverse a Google Cloud. Tra le origini supportate c'è 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 pattern descritto. Controlla nell'elenco delle località Bigtable se il servizio è disponibile nella regione di destinazione.

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

L'ultima opzione è l'esportazione delle tabelle, ad esempio su Cloud Storage. Queste esportazioni ospiteranno i dati in un altro servizio, che saranno poi disponibili per l'importazione nell'istanza nella regione.

Firestore

Le località Firestore potrebbero essere vincolate alla presenza di App Engine nel tuo progetto, il che in alcuni scenari forza l'istanza Firestore a essere multiregionale. 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 regionale e vuoi eseguire la migrazione a una posizione diversa, il servizio di esportazione e importazione gestito ti consente di importare ed 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 per il ritiro dell'ambiente di origine

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

A livello generale, prima di ritirare l'ambiente di origine, devi considerare quanto segue:

  • Nuovi test dell'ambiente: prima di trasferire il traffico dal vecchio ambiente al nuovo, puoi eseguire test per convalidare la correttezza delle applicazioni. Oltre ai test di unità e di integrazione classici che possono essere eseguiti sulle applicazioni appena migrate, esistono diverse strategie di test. Il nuovo ambiente può essere trattato 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 entrata nell'ambiente di origine e nel nuovo ambiente per verificare che le funzioni vengano mantenute.
  • Pianificazione dei tempi di inattività: se selezioni una strategia di migrazione come blue-green, in cui sposti il traffico da un ambiente a un altro, valuta l'adozione di tempi di inattività pianificati. Il tempo di inattività 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 errata 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 ed essere passati alla nuova regione senza errori. Ti consigliamo di conservare i backup della prima regione per un periodo di tempo limitato, finché non avrai la certezza che non ci siano problemi nella regione di cui è stata eseguita la migrazione.

Devi anche valutare se promuovere la vecchia regione a sito di disaster recovery, supponendo che non esista già una soluzione. Questo approccio richiede una progettazione aggiuntiva per garantire l'affidabilità del sito. Per ulteriori informazioni su come progettare e pianificare correttamente il ripristino di emergenza, consulta la Guida alla pianificazione del ripristino di emergenza.

Passaggi successivi

Collaboratori

Autore: Valerio Ponza | Technical Solution Consultant

Altri collaboratori: