Architettare i 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 delle una futura espansione e migrazione dei carichi di lavoro in altre piattaforme Google Cloud regioni o l'impatto di una migrazione di carichi di lavoro tra regioni. Questo documento è utile se hai intenzione di svolgere una di queste attività o se vuoi valutare le opportunità di farlo in futuro e desiderare capire quali un'esperienza utente.

Questo documento fa parte di una serie:

Le indicazioni di questa serie sono utili anche se non hai pianificato una migrazione in più regioni o per un'espansione in più regioni in anticipo. In questo caso, potresti dover dedicare del tempo alla preparazione dell'infrastruttura carichi di lavoro e dati per la migrazione tra regioni e per l'espansione in più regioni.

Questo documento ti aiuta a:

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

Preparare la zona di destinazione

Questa sezione si concentra sulle considerazioni che devi fare per estendere un La zona di destinazione (detta anche piattaforma di base cloud) durante la migrazione tra regioni diverse.

Il primo passo è rivalutare i diversi aspetti di qualsiasi pagina di destinazione esistente zona di destinazione. Per poter eseguire la migrazione di qualsiasi carico di lavoro, devi già disporre di una zona di destinazione in funzione. Anche se potresti già disporre di una zona di destinazione per la regione che ospita i carichi di lavoro, la zona di destinazione potrebbe non supportare il deployment carichi di lavoro in una regione diversa, quindi deve essere esteso alla regione di destinazione. Alcune zone di destinazione già esistenti potrebbero avere un design che supportare un'altra regione senza dover rielaborare in modo significativo la zona di destinazione (ad ad esempio la gestione di identità e accessi o la gestione delle risorse). Tuttavia, ulteriori come la rete o i dati, potrebbe essere necessario pianificare . Il processo di nuova valutazione dovrebbe tenere conto dei principali dei carichi di lavoro per consentirti di configurare una base generica che possono essere specializzate in un secondo momento durante la migrazione.

Considerazioni aziendali

Quando si tratta di aspetti come gli standard del settore e della pubblica amministrazione, normative e certificazioni, lo spostamento dei carichi di lavoro in un'altra regione requisiti diversi. Carichi di lavoro in esecuzione su regioni Google che si trovano fisicamente che si trovano in paesi diversi devono rispettare le leggi e le normative di tale paese paese. Inoltre, standard di settore diversi possono avere particolari per i carichi di lavoro in esecuzione all'estero (soprattutto in termini di sicurezza). Poiché le regioni Google Cloud sono create per eseguire le risorse in un singolo paese, a volte viene eseguita la migrazione dei carichi di lavoro da un'altra regione Google a quella paese per ottemperare a normative specifiche. Quando esegui queste azioni "nel paese" migrazioni, è importante rivalutare i dati in esecuzione on-premise per verificare la nuova regione consente la migrazione dei dati in Google Cloud.

Gestione di identità e accessi

Quando pianifichi una migrazione, probabilmente non devi pianificarne molte modifiche all'identità e all'accesso per le regioni che si trovano già su Google Cloud. Le decisioni sull'identità su Google Cloud e l'accesso alle risorse sono in genere in base alla natura delle risorse anziché alla regione in cui le risorse in esecuzione. Ecco alcune considerazioni che potresti dover fare:

  • Struttura dei team: alcune aziende sono strutturate in modo da avere possono gestire risorse diverse. Quando viene eseguita la migrazione di un carico di lavoro regione, a causa dei cambiamenti nella struttura delle risorse, essere il miglior candidato a essere responsabile di determinate risorse, in questo caso, gli accessi devono essere regolati di conseguenza.
  • Convenzioni di denominazione: anche se le convenzioni di denominazione potrebbero non avere impatto tecnico sulle funzionalità, pertanto potrebbero essere necessarie alcune considerazioni se ci sono risorse definite con convenzioni sui nomi che fanno riferimento una regione specifica. Un esempio tipico è quando ci sono già in regioni replicate, ad esempio le macchine virtuali Compute Engine (VM), che hanno come prefisso la regione, ad esempio europe-west1-backend-1. Durante il processo di migrazione, per evitare confusione o, peggio ancora, interrompere le pipeline che si basano su una convenzione di denominazione specifica, è importante cambiare i nomi per riflettere la nuova regione.

Connettività e networking

La progettazione della tua rete influisce su più aspetti delle modalità di esecuzione della migrazione, quindi è importante affrontare questo progetto prima di pianificare lo spostamento dei carichi di lavoro.

Tieni presente che la connettività on-premise con Google Cloud è uno dei i fattori da rivalutare durante la migrazione, in quanto può essere progettata per specifici per ogni regione. Un esempio di questo fattore è Cloud Interconnect collegato a Google Cloud tramite un collegamento VLAN a specifiche regioni. Devi modificare la regione in cui è connesso il collegamento VLAN prima di chiuderla per evitare il traffico tra regioni. Un altro fattore è che, se utilizzi Partner Interconnect la migrazione della regione può aiutarti a selezionare una località fisica diversa su cui per connettere i tuoi collegamenti VLAN a Google Cloud. Questa considerazione è pertinente anche se utilizzi Cloud VPN e decidi di cambiare gli indirizzi della subnet migrazione: devi riconfigurare i router per riflettere la nuova rete.

Sebbene i VPC (Virtual Private Cloud) su Google Cloud siano risorse globali, le subnet singole sono sempre associate a una regione, il che significa che non puoi usare per i carichi di lavoro dopo la migrazione. Poiché le subnet non possono sovrapporsi Per mantenere gli stessi indirizzi, devi creare un nuovo VPC. Questo processo è semplificati se utilizzi Cloud DNS, che può sfruttare funzionalità come DNS il peering per instradare il traffico per i carichi di lavoro di cui è stata eseguita la migrazione prima di ignorare il vecchio regione.

Per saperne di più sulla creazione di una base su Google Cloud, consulta Esegui la migrazione a Google Cloud: pianifica e costruisci le tue basi.

Prepara i carichi di lavoro per una migrazione tra regioni

Che tu stia configurando la tua infrastruttura su Google Cloud vuoi eseguire la migrazione in un secondo momento in un'altra regione o se sei già su Google Cloud e devi eseguire la migrazione a un'altra regione, devi assicurarti che la migrazione dei carichi di lavoro nel modo più semplice, minimizzare i rischi. Per aiutarti a garantire che tutti i carichi di lavoro siano in uno stato che consente un percorso di migrazione, ti consigliamo di adottare l'approccio seguente:

  • Privilegia progettazioni di rete facilmente replicabili e a basso accoppiamento dalla topologia di rete specifica. Google Cloud offre diversi prodotti che possono aiutarti a disaccoppiare configurazione di rete attuale dalle risorse che la utilizzano. Un un esempio di prodotto è Cloud DNS, che ti consente di disaccoppiare gli IP di subnet delle VM.
  • Configurare prodotti che supportano configurazioni multiregionali o globali. Prodotti che supportano una configurazione che interessa più regioni di solito semplificano il processo di migrazione a un'altra regione.
  • Valutare la possibilità di utilizzare servizi gestiti con repliche tra regioni gestite per i dati. Come descritto nelle seguenti sezioni di questo documento, alcuni servizi gestiti consente di creare una replica in una regione diversa, in genere per il backup per motivi di alta disponibilità. Questa funzionalità può essere importante per la migrazione dei dati da una regione all'altra.

Alcuni servizi Google Cloud sono progettati per supportare deployment multiregionali o deployment globale. Non è necessario eseguire la migrazione di questi servizi, anche se potresti dover regolare configurazioni.

Prepara le risorse di calcolo

Questa sezione fornisce una panoramica delle risorse di computing su Google Cloud. e di progettazione per prepararsi alla migrazione in un'altra regione.

Questo documento è incentrato sui seguenti prodotti di computing di Google Cloud:

Compute Engine

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

Per eseguire la migrazione delle risorse Compute Engine da una regione all'altra, devi valutare diversi fattori, oltre a considerazioni relative al networking.

Ti consigliamo di procedere come segue:

  • Controlla le risorse di computing: una delle prime limitazioni che puoi quando si cambia la regione di hosting di una VM è la disponibilità della piattaforma CPU nella nuova regione target. Se devi modificare una serie di macchine durante migrazione, verifica che il sistema operativo della VM attuale sia supportato per la serie. In generale, questo problema può essere esteso a tutti Google Cloud di computing (alcune nuove regioni potrebbero non offrire servizi Cloud Run o GPU Cloud), quindi prima di pianificare la migrazione, assicurati che tutti i servizi di computing richiesti siano disponibili regione di destinazione.
  • Configurare bilanciamento del carico e 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 gruppi di istanze gestite, in base alla domanda. Ti consigliamo di configurare il bilanciamento del carico e scalare la scalabilità automatica per aumentare l'affidabilità e la flessibilità di Google, evitando il carico della gestione delle soluzioni autogestite. Per Scopri di più sulla configurazione del bilanciamento del carico e della scalabilità per per Compute Engine, consulta 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 presenti nei tuoi ambienti. Google Cloud utilizza nomi DNS di zona delle macchine virtuali Compute Engine per impostazione predefinita. Per ulteriori informazioni come funziona il DNS interno di Compute Engine, vedi Panoramica del DNS interno. Per facilitare una migrazione futura regioni e, per rendere la configurazione più gestibile, consigliamo di i nomi DNS di zona sono considerati parametri di configurazione cambiamento in futuro.
  • Utilizza lo stesso modello di gruppi di istanze gestite: Compute Engine consente crea MIG a livello di regione che eseguono automaticamente il provisioning di macchine virtuali su più zone in regione automaticamente. Se utilizzi un modello nella vecchia regione, puoi usare lo stesso modello per eseguire il deployment dei gruppi di istanze gestite nella nuova regione.

GKE

Google Kubernetes Engine (GKE) ti aiuta a eseguire il deployment, gestire e scalare carichi di lavoro standard su Kubernetes.

Per preparare i tuoi carichi di lavoro GKE per una migrazione, valuta la possibilità di i seguenti punti di progettazione e funzionalità GKE:

  • Cloud Service Mesh: Un'implementazione gestita del mesh Istio. Adozione di Cloud Service Mesh per il tuo cluster ti consente di avere un maggiore livello di controllo sulla 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 cluster GKE nella nuova regione e aggiungendolo al mesh di servizi. Di con questo approccio, è possibile iniziare a eseguire il deployment dei carichi di lavoro nel nuovo cluster e l'indirizzamento graduale del traffico verso questi cluster, consentendoti di testare il nuovo il deployment e la possibilità di eseguire il rollback modificando il routing mesh.
  • Config Sync: Un servizio GitOps basato su un core open source che consente agli operatori del cluster e gli amministratori di piattaforma eseguono il deployment delle configurazioni da un'unica origine. Config Sync supporta uno o più cluster, consentendoti di usare un'unica fonte attendibile e configurare i cluster. Puoi utilizzare questa funzione di Config Sync per la configurazione del cluster esistente sul cluster per la nuova regione, e personalizzare potenzialmente una risorsa specifica per la regione.
  • Backup per GKE: Questa funzionalità consente di eseguire periodicamente il backup dei dati permanenti del cluster ripristinare i dati nello stesso cluster o in uno nuovo.

Cloud Run

Cloud Run offre un approccio leggero al deployment di container su Google Cloud. I servizi Cloud Run sono a livello di regione e le relative risorse vengono replicati in più zone della regione in cui si trovano. Quando eseguire il deployment di un servizio Cloud Run, puoi scegliere regione in cui eseguire il deployment dell'istanza, quindi usa questa funzionalità per in un'altra regione.

VMware Engine

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

Per eseguire la migrazione delle istanze VMware Engine in una regione diversa, dovrebbe crea il tuo cloud privato nella nuova regione e poi usare gli strumenti VMware per spostare le istanze.

Dovresti anche prendere in considerazione il DNS e il bilanciamento del carico in Compute Engine ambienti quando pianifichi la migrazione. VMware Engine utilizza Google Cloud DNS, un servizio di hosting DNS gestito che fornisce autori Hosting DNS pubblicato sulla rete internet pubblica, zone private visibili alle reti VPC, e l'inoltro e il peering DNS per gestire la risoluzione dei nomi sulle reti VPC. Il tuo
Il piano di migrazione può supportare i test del bilanciamento del carico multiregionale e di configurazioni DNS.

Prepara le risorse di archiviazione dati

Questa sezione fornisce una panoramica delle risorse di archiviazione dati Google Cloud e nozioni di base su come prepararsi a una migrazione a un altro regione.

La presenza dei dati già su Google Cloud semplifica perché implica che una soluzione per ospitarli senza dover di trasformazione esiste o può essere ospitata su Google Cloud.

La possibilità di copiare i dati del database in una regione diversa e ripristinarli altrove è un modello comune Ripristino di emergenza (RE). Per questo motivo, alcuni dei pattern descritti in questo documento si basano Meccanismi di RE come backup e ripristino dei database.

In questo documento sono descritti i seguenti servizi gestiti:

Questo documento presuppone che le soluzioni di archiviazione in uso siano a livello di regione, collocate contemporaneamente con le risorse di computing.

Cloud Storage

Offerte di Cloud Storage Storage Transfer Service, che automatizza il trasferimento di file da diverse in Cloud Storage. Può essere utilizzato per replicare i dati in un regione per il backup e anche per la migrazione da regione a regione.

Cloud SQL

Cloud SQL offre un servizio di database relazionale per ospitare diversi tipi di database. Cloud SQL offre 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 di per le istanze Cloud SQL, ma consente anche di promuovere la seconda replica un'altra regione alla replica principale. Puoi utilizzare questa funzionalità per creare una replica di lettura nella seconda regione, quindi promuovila nella replica principale dopo la migrazione carichi di lavoro con scale out impegnativi. In generale, per i database, i servizi gestiti semplificano il processo replica dei dati, per semplificare la creazione di una replica nella nuova regione durante migrazione.

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

Filestore

Come spiegato in precedenza in questo documento, la funzionalità di backup e ripristino Filestore consente di creare un backup di una condivisione file verrà ripristinato in un'altra regione. Questa funzionalità può essere utilizzata per eseguire regioni della regione.

Bigtable

Come con Cloud SQL, Bigtable supporta replica. Puoi usare questa funzionalità per replicare pattern descritto. Controlla nel Elenco località Bigtable se il servizio è disponibile nella destinazione regione.

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

L'ultima opzione è esportare tabelle, ad esempio su Cloud Storage. Questi esporta i dati, che saranno poi disponibili da importare nell'istanza nella regione.

Firestore

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

Se disponi di un località regionale e vuoi eseguire la migrazione in una località diversa, il il servizio gestito di esportazione e importazione consente di importare esporta le entità Firestore usando un bucket Cloud Storage. Questo metodo può essere utilizzato per spostare le istanze da una regione all'altra. L'altro è utilizzare Firestore funzionalità di backup e ripristino. Questa opzione è meno costosa e più diretta rispetto all'importazione e all'esportazione.

Preparati al ritiro dell'ambiente di origine

Devi prepararti in anticipo prima di ritirare l'ambiente di origine e e poi passare alla nuova versione.

A livello generale, prima di ritirare la licenza dell'ambiente di origine:

  • Nuovi test di ambiente: prima di trasferire il traffico dal vecchio al nuovo ambiente, puoi eseguire test per convalidare la correttezza delle applicazioni. A parte l'unità classica e di integrazione che possono essere eseguiti sulle applicazioni di cui è stata appena eseguita la migrazione, sono strategie diverse di test. Il nuovo ambiente può essere trattato una nuova versione del software e la migrazione del traffico implementate con pattern comuni come i test A/B utilizzata per la convalida. Un altro approccio consiste nel replicare il traffico in entrata nell'ambiente di origine e nel nuovo ambiente per verificare che funzioni vengono conservati.
  • Pianificazione del tempo di riposo: se selezioni una strategia di migrazione, ad esempio blu/verde, che permette di passare il traffico da un ambiente a un altro considerare l'adozione di tempi di inattività pianificati. Il tempo di inattività consente la transizione per un monitoraggio più efficace ed evitare errori imprevedibili sul lato client.
  • Rollback: in base alle strategie adottate per la migrazione del potrebbe essere necessario implementare un rollback in caso di errori dell'errata configurazione del nuovo ambiente. Per poter eseguire il rollback devi disporre di un'infrastruttura di monitoraggio per rilevare lo stato del nuovo ambiente.

Puoi arrestare i servizi solo nella prima regione dopo aver eseguito test estesi nella nuova regione e vengono pubblicati nella nuova regione senza errori. Me di conservare i backup della prima regione per un numero limitato di finché non avrai la certezza che non ci siano problemi nella regione appena sottoposta a migrazione.

Dovresti anche considerare se vuoi promuovere la vecchia regione in caso di emergenza sito di ripristino, supponendo che non esista già una soluzione. Questo approccio richiede un design aggiuntivo per garantire l'affidabilità del sito. Per maggiori informazioni su come progettare e pianificare correttamente la RE, consulta le Guida alla pianificazione del ripristino di emergenza.

Passaggi successivi

Collaboratori

Autore: Valerio Ponza | Consulente per le soluzioni tecniche

Altri collaboratori: