Esegui la migrazione tra regioni Google Cloud: progetta ambienti resilienti a una sola regione su Google Cloud

Last reviewed 2024-12-08 UTC

Questo documento ti aiuta a progettare ambienti resilienti a regione singola su Google Cloud. Questo documento è utile se prevedi di eseguire la migrazione di un ambiente a una sola regione o se stai valutando l'opportunità di farlo in futuro e vuoi capire come potrebbe essere.

Questo documento fa parte di una serie:

Questo documento ha lo scopo di fornire indicazioni su come progettare ambienti resilienti a una singola regione su Google Cloude si concentra sui seguenti componenti architetturali:

Le indicazioni contenute in questo documento presuppongono che tu stia progettando e implementando ambienti a una sola regione. Se ora utilizzi un ambiente a regione singola, in futuro potrai eseguire la migrazione a un ambiente multiregionale. Se stai valutando una migrazione ed evoluzione future dei tuoi ambienti zonali e a regione singola in ambienti multiregionali, consulta Eseguire la migrazione tra regioni: guida introduttiva. Google Cloud

Proprietà dei diversi archetipi di distribuzione

Google Cloud sono forniti in molte regioni e zone.

Quando progetti il tuo ambiente Google Cloud , puoi scegliere tra i seguenti archetipi di deployment, presentati in ordine di affidabilità e overhead operativo crescente:

  • Zonale: esegui il provisioning delle risorse Google Cloud in una singola zona all'interno di una regione e utilizzi i servizi zonali dove sono disponibili. Se i servizi zonali non sono disponibili, utilizzi i servizi regionali.
  • Regionale: esegui il provisioning delle risorse in più zone all'interno di una regione e utilizzi i servizi regionali quando possibile. Google Cloud
  • Multi-regione: esegui il provisioning delle risorse Google Cloud in più zone in diverse regioni. Le risorse di zona vengono sottoposte a provisioning in una o più zone di ogni regione.
  • Globale: esegui il provisioning delle risorse in più zone in diverse regioni in tutto il mondo. Google Cloud Le risorse di zona vengono provisionate in una o più zone di ogni regione.

Gli archetipi di deployment precedenti hanno proprietà di affidabilità diverse e puoi utilizzarli per fornire le garanzie di affidabilità necessarie per il tuo ambiente. Ad esempio, un ambiente multiregionale ha maggiori probabilità di sopravvivere a un'interruzione regionale rispetto a un ambiente zonale o a una singola regione. Per saperne di più sulle proprietà di affidabilità di ogni archetipo di deployment, consulta Come sfruttare zone e regioni per ottenere affidabilità e la guida all'affidabilità dell'infrastruttura.Google Cloud

La progettazione, l'implementazione e il funzionamento di un ambiente basato su questi archetipi di deployment richiedono diversi livelli di impegno a causa delle proprietà di costo e complessità di ciascun archetipo di deployment. Ad esempio, un ambiente zonale potrebbe essere più economico e più facile da progettare, implementare e gestire rispetto a un ambiente regionale o multiregionale. Il potenziale minore impegno e costo dell'ambiente zonale è dovuto al sovraccarico aggiuntivo che devi gestire per coordinare i carichi di lavoro, i dati e i processi che risiedono in regioni diverse.

La tabella seguente riepiloga la distribuzione delle risorse, le proprietà di affidabilità e la complessità di ogni archetipo di deployment. Inoltre, descrive l'impegno necessario per progettare e implementare un ambiente in base a ciascuna di queste.

Nome dell'archetipo di deployment Distribuzione delle risorse Aiuta a resistere Complessità del design
Ambiente di zona In una singola zona Errori delle risorse Richiede il coordinamento all'interno di una singola zona
Ambiente a regione singola In più zone, in una singola regione Errori delle risorse, interruzioni a livello di zona Richiede il coordinamento tra più zone in una singola regione
Ambiente multiregionale In più zone, in più regioni Errori delle risorse, interruzioni a livello di zona, interruzioni a livello di regione, interruzioni multiregionali Richiede il coordinamento in più zone e regioni
Ambiente globale In più zone, in più regioni a livello globale Errori delle risorse, interruzioni a livello di zona, interruzioni a livello di regione, interruzioni multiregionali Richiede il coordinamento in più zone e regioni

Per ulteriori informazioni su questi e altri archetipi di deployment, consulta Google Cloud archetipi di deployment.

Scegliere gli archetipi di deployment per gli ambienti

Per scegliere l'archetipo di deployment più adatto alle tue esigenze, procedi nel seguente modo:

  1. Definisci i modelli di errore da cui vuoi proteggerti.
  2. Valuta gli archetipi di deployment per determinare quale si adatta meglio alle tue esigenze.

Definisci i modelli di errore

Per definire i modelli di errore, considera le seguenti domande:

  • Quali componenti del tuo ambiente necessitano di modelli di guasto? I modelli di errore possono essere applicati a qualsiasi elemento di cui esegui il provisioning o il deployment suGoogle Cloud. Un modello di errore può essere applicato a un singolo utente oppure a tutte le risorse di un'intera zona o regione. Ti consigliamo di applicare un modello di guasto a qualsiasi elemento che ti fornisca valore, come carichi di lavoro, dati, processi e qualsiasi Google Cloud risorsa.
  • Quali sono i requisiti di alta disponibilità, continuità aziendale e ripristino di emergenza per questi componenti? Ogni componente del tuo ambiente potrebbe avere i propri obiettivi del livello di servizio (SLO) che definiscono i livelli di servizio accettabili per quel componente e i propri requisiti di ripristino di emergenza. Ad esempio, lo SLA di Compute Engine indica che se devi raggiungere un uptime mensile superiore al 99,5%, devi eseguire il provisioning delle istanze in più zone in un'unica regione. Per ulteriori informazioni, vedi la Guida alla pianificazione del disaster recovery.
  • Quanti modelli di guasto devi definire? In un ambiente tipico, non tutti i componenti devono fornire le stesse garanzie di affidabilità. Se offri garanzie per un uptime più elevato e una resilienza maggiore, di solito devi impiegare più impegno e risorse. Quando definisci i modelli di guasto, ti consigliamo di adottare un approccio in cui definisci più modelli di guasto per ogni componente e non solo uno per tutti i componenti. Ad esempio, i workload business-critical di solito devono offrire una maggiore affidabilità, anche se potrebbe essere accettabile offrire garanzie di affidabilità inferiori per altri workload meno critici.
  • Di quante risorse hanno bisogno i modelli di errore per proteggersi dagli errori? Per proteggerti dai modelli di guasto che hai definito, utilizzi risorse come il tempo e il costo necessari per progettare, eseguire il provisioning e configurare meccanismi di protezione e processi automatizzati. Ti consigliamo di valutare il numero di risorse necessarie per proteggerti da ogni modello di errore che definisci.
  • Come rileverai che si sta verificando un errore? La capacità di rilevare che si sta verificando o sta per verificarsi un errore è fondamentale per poter avviare i processi di mitigazione, ripristino e riconciliazione. Ad esempio, puoi configurare Google Cloud Observability in modo che ti avvisi in caso di prestazioni ridotte.
  • Come puoi testare i modelli di errore che stai definendo? Quando definisci i modelli di errore, ti consigliamo di pensare a come testare continuamente ogni modello per verificare che protegga efficacemente dagli errori a cui sono destinati. Ad esempio, puoi inserire errori nei tuoi ambienti oppure, per valutare la capacità dei tuoi ambienti di tollerare i guasti, puoi adottare l'ingegneria del caos.
  • Quale impatto ti aspetti se si verifica un particolare modello di guasto? Per comprendere l'impatto che un guasto potrebbe avere sulla tua attività, ti consigliamo di stimare, per ogni modello di guasto, le conseguenze di ogni guasto per cui è progettato il modello. Questa comprensione è utile per stabilire le priorità e gli ordini di recupero in modo che tu e i tuoi processi vi occupiate prima dei componenti più critici.
  • Quanto tempo prevedi che dureranno gli errori nei modelli di guasto che stai definendo? La durata di un errore può influire notevolmente sui piani di mitigazione e ripristino. Pertanto, quando definisci i modelli di errore, ti consigliamo di tenere conto della durata di un errore. Quando valuti la durata di un errore, considera anche il tempo necessario per: identificare un errore, risolverlo e ripristinare le risorse che hanno generato l'errore.

Per ulteriori considerazioni sui modelli di errore e su come progettare un piano di ripristino di emergenza affidabile, consulta Progettazione del ripristino di emergenza per interruzioni dell'infrastruttura cloud.

Valutare gli archetipi di deployment

Dopo aver definito i modelli di errore da cui vuoi proteggerti, valuta gli archetipi di deployment per determinare quello più adatto alle tue esigenze. Quando valuti gli archetipi di deployment, considera le seguenti domande:

  • Di quanti archetipi di deployment hai bisogno? Non devi scegliere un solo archetipo di deployment per adattarlo a tutti i tuoi ambienti. In alternativa, puoi implementare un approccio ibrido in cui scegli più archetipi di deployment in base alle garanzie di affidabilità che ti servono per proteggerti dai modelli di errore che hai definito. Ad esempio, se hai definito due modelli di errore, uno che richiede un ambiente zonale e uno che richiede un ambiente regionale, potresti scegliere archetipi di deployment separati per proteggerti da ogni modello di errore. Se scegli più archetipi di deployment, ti consigliamo di valutare la potenziale crescente complessità della progettazione, dell'implementazione e del funzionamento di più ambienti.
  • Quante risorse ti servono per progettare e implementare ambienti basati sugli archetipi di deployment? La progettazione e l'implementazione di qualsiasi tipo di ambiente richiedono risorse e impegno. Ti consigliamo di valutare il numero di risorse che ritieni necessarie per progettare e implementare ogni ambiente in base all'archetipo scelto. Quando hai una comprensione completa di quante risorse ti servono, puoi bilanciare i compromessi tra le garanzie di affidabilità offerte da ogni archetipo di deployment e il costo e la complessità della progettazione, dell'implementazione e del funzionamento degli ambienti basati su questi archetipi.
  • Prevedi di eseguire la migrazione di un ambiente basato su un archetipo di deployment a un ambiente basato su un archetipo diverso? In futuro, potresti eseguire la migrazione di carichi di lavoro, dati e processi da un ambienteGoogle Cloud a un altro ambiente Google Cloud. Ad esempio, potresti eseguire la migrazione da un ambiente zonale a un ambiente regionale.
  • Quanto sono fondamentali per l'attività gli ambienti che stai progettando e implementando? Gli ambienti business-critical probabilmente richiedono maggiori garanzie di affidabilità. Ad esempio, potresti scegliere di progettare e implementare un ambiente multiregionale per carichi di lavoro, dati e processi business-critical e progettare un ambiente zonale o regionale per carichi di lavoro, dati e processi meno critici.
  • Hai bisogno delle funzionalità offerte da particolari archetipi di deployment per determinati ambienti? Oltre alle garanzie di affidabilità offerte da ogni archetipo di deployment, gli archetipi offrono anche diverse garanzie di scalabilità, prossimità geografica, latenza e località dei dati. Ti consigliamo di prendere in considerazione queste garanzie quando scegli gli archetipi di deployment per i tuoi ambienti.

Oltre agli aspetti tecnici delle modalità di errore che hai definito seguendo le indicazioni precedenti, ti consigliamo di prendere in considerazione eventuali requisiti non funzionali, come quelli normativi, di località e di sovranità. Questi requisiti possono limitare le opzioni a tua disposizione. Ad esempio, se devi soddisfare requisiti normativi che impongono l'utilizzo di una regione specifica, devi progettare e implementare un ambiente a una sola regione o un ambiente zonale in quella regione.

Scegli una regione Google Cloud per il tuo ambiente

Quando inizi a progettare gli ambienti a singola regione, devi determinare la regione che meglio si adatta ai requisiti di ciascun ambiente. Le sezioni seguenti descrivono queste due categorie di criteri di selezione:

  • Criteri funzionali. Questi criteri riguardano i Google Cloud prodotti offerti da una determinata regione e se una determinata regione soddisfa i requisiti di latenza e prossimità geografica agli utenti e ad altri ambienti esterni Google Cloud. Ad esempio, se i tuoi carichi di lavoro e dati hanno requisiti di latenza per i tuoi utenti o altri ambienti esterni Google Cloud, potresti dover scegliere la regione più vicina ai tuoi utenti o ad altri ambienti per ridurre al minimo la latenza.
  • Criteri non funzionali. Questi criteri riguardano i prezzi dei prodotti associati a regioni specifiche, i requisiti relativi all'impronta di carbonio e i requisiti e i regolamenti obbligatori in vigore per la tua attività. Ad esempio, mercati altamente regolamentati come il settore bancario e quello pubblico hanno requisiti molto rigorosi e specifici in merito alla località dei dati e dei carichi di lavoro e alle modalità di condivisione dell'infrastruttura del cloud provider con altri clienti.

Se scegli una regione Google Cloud specifica ora, in futuro potrai eseguire la migrazione a regioni diverse o a un ambiente multiregionale. Se stai valutando una futura migrazione ad altre regioni, consulta Eseguire la migrazione tra Google Cloud regioni: guida introduttiva.

Valutare i criteri funzionali

Per valutare i criteri funzionali, considera le seguenti domande:

  • Quali sono i requisiti di prossimità geografica? Quando scegli una Google Cloud regione, potresti dover posizionare i carichi di lavoro, i dati e i processi vicino ai tuoi utenti o ai tuoi ambienti esterni Google Cloud, ad esempio gli ambienti on-premise. Ad esempio, se il tuo target è una base di utenti concentrata in una particolare area geografica, ti consigliamo di scegliere una regione Google Cloud più vicina a quell'area geografica. La scelta di una Google Cloud regione che soddisfi al meglio i tuoi requisiti di vicinanza geografica consente ai tuoi ambienti di garantire una latenza inferiore e tempi di reazione più rapidi alle richieste dei tuoi utenti e dei tuoi ambienti esterni Google Cloud. Strumenti come la Google Cloud dashboard della latenza e strumenti non ufficiali come GCPing e lo Google Cloud strumento di selezione della regione possono darti un'idea generale delle caratteristiche di latenza delle regioniGoogle Cloud . Tuttavia, ti consigliamo di eseguire una valutazione completa per verificare se le proprietà di latenza soddisfano i tuoi requisiti, carichi di lavoro, dati e processi.
  • Quale delle regioni che vuoi utilizzare offre i prodotti di cui hai bisogno? Ti consigliamo di valutare i prodotti disponibili in ogni regione Google Cloud e quali regioni forniscono i servizi necessari per progettare e implementare i tuoi ambienti. Per ulteriori informazioni sui prodotti disponibili in ogni regione e sui relativi tempi di disponibilità, consulta Località cloud. Inoltre, alcuni prodotti potrebbero non offrire tutte le loro funzionalità in ogni regione in cui sono disponibili. Ad esempio, le regioni e zone disponibili per Compute Engine offrono tipi di macchine specifici in Google Cloud regioni specifiche. Per saperne di più sulle funzionalità offerte da ogni prodotto in ogni regione, consulta la documentazione del prodotto.
  • Le risorse di cui hai bisogno in ogni regione Google Cloud rientrano nei limiti di quota per regione? Google Cloud utilizza le quote per limitare la quantità di una risorsa Google Cloud condivisa che puoi utilizzare. Alcune quote sono globali e si applicano all'utilizzo della risorsa ovunque inGoogle Cloud, mentre altre sono regionali o di zona e si applicano all'utilizzo della risorsa in una regione Google Cloud specifica. Ad esempio, la maggior parte delle quote di utilizzo delle risorse Compute Engine, come il numero di macchine virtuali che puoi creare, sono regionali. Per saperne di più sulle quote e su come aumentarle, consulta Utilizzo delle quote.

Valutare i criteri non funzionali

Per valutare i criteri non funzionali, considera le seguenti domande:

  • Preferisci un'impronta di carbonio ridotta? Google Cloud investe continuamente in sostenibilità e in energia a zero emissioni di CO2 per le regioni Google Cloud , ed è impegnata a utilizzare energia a zero emissioni di CO2 per tutte le regioni cloud. Le regioniGoogle Cloud hanno impronte di carbonio diverse. Per informazioni sull'impronta di carbonio di ciascuna Google Cloud regione e su come incorporare energia a zero emissioni di CO2 nella tua strategia di localizzazione, consulta Energia a zero emissioni di CO2 per le Google Cloud regioni.
  • I tuoi ambienti devono rispettare normative particolari? I governi e gli enti nazionali e sovranazionali spesso regolamentano rigorosamente determinati mercati e settori aziendali, come quello bancario e il settore pubblico. Questi regolamenti potrebbero imporre che i workload, i dati e i processi risiedano solo in determinate regioni geografiche. Ad esempio, i tuoi ambienti potrebbero dover rispettare i requisiti di sovranità dei dati, operativi e del software per garantire determinati livelli di controllo e trasparenza per i dati sensibili e i workload in esecuzione nel cloud. Ti consigliamo di valutare i requisiti normativi attuali e futuri quando scegli leGoogle Cloud regioni per i tuoi ambienti e di selezionare leGoogle Cloud regioni più adatte ai tuoi requisiti normativi.

Progetta e crea i tuoi ambienti a una sola regione

Per progettare un ambiente a singola regione:

  1. Crea le basi su Google Cloud.
  2. Esegui il provisioning e configura le risorse di computing.
  3. Esegui il provisioning e configura le risorse di archiviazione dei dati.
  4. Esegui il provisioning e configura le risorse di analisi dei dati.

Quando progetti l'ambiente, considera i seguenti principi di progettazione generali:

  • Esegui il provisioning delle risorse regionali. Molti prodotti Google Cloud supportano il provisioning delle risorse in più zone di una regione. Ti consigliamo di eseguire il provisioning delle risorse regionali anziché di quelle a livello di zona quando possibile. In teoria, potresti essere in grado di eseguire il provisioning di risorse zonali in più zone di una regione e gestirle autonomamente per ottenere un'affidabilità maggiore. Tuttavia, questa configurazione non trarrebbe pieno vantaggio da tutte le funzionalità di affidabilità dell'infrastruttura Google che sostengono i servizi Google Cloud .
  • Verifica che gli ambienti funzionino come previsto con le ipotesi del modello di guasto. Quando progetti e implementi gli ambienti a singola regione, ti consigliamo di verificare se soddisfano i requisiti per proteggerti dai modelli di errore che stai prendendo in considerazione, prima di promuoverli come parte dell'ambiente di produzione. Ad esempio, puoi simulare interruzioni a livello di zona per verificare che i tuoi ambienti a singola regione possano sopravvivere con interruzioni minime.

Per principi di progettazione più generali per la progettazione di ambienti monoregionali e multiregionali affidabili e per informazioni su come Google ottiene una migliore affidabilità con i servizi regionali e multiregionali, consulta Progettazione ripristino di emergenza per interruzioni dell'infrastruttura cloud: temi comuni.

Crea le tue basi su Google Cloud

Per creare le basi degli ambienti a singola regione, consulta Eseguire la migrazione a Google Cloud: pianificare e creare le basi. Le indicazioni contenute in questo documento mirano a creare una base per la migrazione di carichi di lavoro, dati e processi a Google Cloud, ma sono applicabili anche per creare la base per gli ambienti a una sola regione. Dopo aver letto questo documento, continua a leggere questo documento.

Dopo aver creato le basi su Google Cloud, progetta e implementa controlli e limiti di sicurezza. Queste misure di sicurezza contribuiscono a garantire che i tuoi carichi di lavoro, dati e processi rimangano all'interno delle rispettive regioni. Le misure di sicurezza contribuiscono anche a garantire che le tue risorse non divulghino nulla ad altre regioni a causa di bug, configurazioni errate o attacchi dannosi.

Esegui il provisioning e la configurazione delle risorse di computing

Dopo aver creato le basi degli ambienti a regione singola, esegui il provisioning e la configurazione delle risorse di computing. Le seguenti sezioni descrivono i prodotti di computingGoogle Cloud che supportano i deployment regionali.

Compute Engine

Compute Engine è il servizio Infrastructure as a Service (IaaS) di Google Cloud. Utilizza l'infrastruttura mondiale di Google per offrire macchine virtuali e servizi correlati ai clienti.

Le risorse di Compute Engine sono di zona, ad esempio macchine virtuali o Persistent Disk di zona; regionali, ad esempio indirizzi IP esterni statici; o globali, ad esempio snapshot Persistent Disk. Per saperne di più sulle risorse di zona, regionali e globali supportate da Compute Engine, consulta Risorse globali, regionali e di zona.

Per consentire una migliore flessibilità e gestione delle risorse fisiche, Compute Engine separa le zone dalle risorse fisiche. Per saperne di più su questa astrazione e sulle sue possibili implicazioni, consulta Zone e cluster.

Per aumentare l'affidabilità degli ambienti che utilizzano Compute Engine, valuta quanto segue:

  • Gruppi di istanze gestite (MIG) a livello di regione. Le macchine virtuali Compute Engine sono risorse di zona, pertanto non saranno disponibili in caso di interruzione di zona. Per risolvere questo problema, Compute Engine ti consente di creare MIG regionali che eseguono il provisioning delle macchine virtuali in più zone di una regione automaticamente, in base alla domanda e alla disponibilità regionale.

    Se i tuoi carichi di lavoro sono stateful, puoi anche creare MIG stateful regionali per conservare dati e configurazioni stateful. I MIG regionali supportano la simulazione di errori a livello di zona. Per informazioni su come simulare un errore a livello di zona quando utilizzi un MIG regionale, consulta Simula un'interruzione del servizio in una zona per un MIG regionale. Per informazioni sul confronto tra i MIG a livello di regione e altre opzioni di deployment, consulta Scegliere una strategia di deployment di Compute Engine per il tuo workload.

  • Forma di distribuzione target. I MIG a livello di regione distribuiscono le macchine virtuali in base alla forma di distribuzione target. Per garantire che la distribuzione delle macchine virtuali non differisca di più di un'unità tra due zone qualsiasi di una regione, ti consigliamo di scegliere la forma di distribuzione EVEN quando crei i MIG a livello di regione. Per informazioni sulle differenze tra le forme di distribuzione target, consulta Confronto tra le forme.

  • Modelli di istanza. Per definire le macchine virtuali da eseguire il provisioning, i MIG utilizzano un tipo di risorsa globale chiamato modelli di istanza. Sebbene i modelli di istanza siano risorse globali, potrebbero fare riferimento a risorse zonali o regionali. Quando crei modelli di istanza, ti consigliamo di fare riferimento alle risorse regionali anziché a quelle di zona, se possibile. Se utilizzi risorse di zona, ti consigliamo di valutare l'impatto del loro utilizzo. Ad esempio, se crei un modello di istanza che fa riferimento a un volume Persistent Disk disponibile solo in una determinata zona, non puoi utilizzare il modello in altre zone perché il volume Persistent Disk non è disponibile in queste zone.

  • 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. Per aumentare l'affidabilità e la flessibilità degli ambienti ed evitare l'onere di gestione delle soluzioni autogestite, ti consigliamo di configurare il bilanciamento del carico e lo scaling automatico. Per saperne di più sulla configurazione del bilanciamento del carico e dello scaling per Compute Engine, consulta Bilanciamento del carico e scalabilità.

  • Configura le prenotazioni delle risorse. Per assicurarti che i tuoi ambienti dispongano delle risorse necessarie quando ne hai bisogno, ti consigliamo di configurare prenotazioni di risorse per garantire l'ottenimento della capacità per le risorse Compute Engine di zona. Ad esempio, se si verifica un'interruzione a livello di zona, potresti dover eseguire il provisioning di macchine virtuali in un'altra zona per fornire la capacità necessaria a compensare quelle non disponibili a causa dell'interruzione. Le prenotazioni delle risorse assicurano di avere le risorse disponibili per eseguire il provisioning delle macchine virtuali aggiuntive.

  • 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 che utilizzano nomi DNS nei tuoi ambienti. Google Cloud utilizza i 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 DNS interno. Per facilitare una futura migrazione tra regioni e rendere più gestibile la tua configurazione, ti consigliamo di considerare i nomi DNS di zona come parametri di configurazione che potrai modificare in futuro.

  • Scegliere le opzioni di archiviazione appropriate. Compute Engine supporta diverse opzioni di archiviazione per le tue macchine virtuali, come volumi Persistent Disk e unità a stato solido (SSD) locali:

    • I volumi Persistent Disk sono distribuiti su più dischi fisici e si trovano indipendentemente dalle tue macchine virtuali. I dischi permanenti possono essere a livello di zona o di regione. I dischi permanenti zonali archiviano i dati in una singola zona, mentre i dischi permanenti regionali replicano i dati in due zone diverse. Quando scegli le opzioni di archiviazione per gli ambienti a regione singola, ti consigliamo di scegliere dischi permanenti regionali perché forniscono opzioni di failover in caso di errori a livello di zona. Per saperne di più su come reagire agli errori di zona quando utilizzi dischi permanenti regionali, consulta Opzioni di alta disponibilità che utilizzano dischi permanenti regionali e Failover dei dischi permanenti regionali.
    • Gli SSD locali hanno una velocità effettiva elevata, ma archiviano i dati solo fino a quando un'istanza non viene arrestata o eliminata. Pertanto, gli SSD locali sono ideali per archiviare dati temporanei, cache e dati che puoi ricostruire con altri mezzi. I dischi permanenti sono dispositivi di archiviazione durevoli a cui le macchine virtuali possono accedere come se si trattasse di dischi fisici.

  • Progettare e implementare meccanismi per la protezione dei dati. Quando progetti i tuoi ambienti a singola regione, ti consigliamo di implementare meccanismi automatizzati per proteggere i tuoi dati in caso di eventi avversi, ad esempio errori zonali, regionali o multiregionali o attacchi deliberati da parte di terze parti malintenzionate. Compute Engine offre diverse opzioni per proteggere i tuoi dati. Puoi utilizzare queste funzionalità delle opzioni di dati come elementi costitutivi per progettare e implementare i tuoi processi di protezione dei dati.

GKE

GKE ti aiuta a eseguire il deployment, gestire e scalare i carichi di lavoro containerizzati su Kubernetes. GKE si basa su Compute Engine, quindi i consigli della sezione precedente su Compute Engine si applicano parzialmente a GKE.

Per aumentare l'affidabilità degli ambienti che utilizzano GKE, considera i seguenti punti di progettazione e le funzionalità di GKE:

  • Utilizza i cluster GKE regionali per aumentare la disponibilità. GKE supporta diversi tipi di disponibilità per i tuoi cluster, a seconda del tipo di cluster di cui hai bisogno. I cluster GKE possono avere un control plane a livello di zona o di regione e possono avere nodi eseguiti in una singola zona o in più zone all'interno di una regione. Inoltre, i diversi tipi di cluster offrono diversi contratti di livello di servizio (SLA). Per aumentare l'affidabilità dei tuoi ambienti, ti consigliamo di scegliere cluster regionali.

    Se utilizzi la funzionalità GKE Autopilot, puoi eseguire il provisioning solo dei cluster regionali.

  • Valuta un ambiente multicluster. Il deployment di più cluster GKE può aumentare la flessibilità e le proprietà di disponibilità del tuo ambiente, a costo di una maggiore complessità. Ad esempio, se devi utilizzare una nuova funzionalità GKE che puoi attivare solo quando crei un cluster GKE, puoi evitare tempi di inattività e ridurre la complessità della migrazione aggiungendo un nuovo cluster GKE al tuo ambiente multicluster, eseguendo il deployment dei workload nel nuovo cluster ed eliminando il vecchio cluster. Per maggiori informazioni sui vantaggi di un ambiente GKE multi-cluster, consulta Casi d'uso multi-cluster. Per aiutarti a gestire la complessità della migrazione, Google Cloud offre Gestione dei parchi risorse, un insieme di funzionalità per gestire un gruppo di cluster GKE, la loro infrastruttura e i carichi di lavoro di cui è stato eseguito il deployment in questi cluster.

  • Configura Backup per GKE. Backup per GKE è un servizio regionale per il backup della configurazione e dei volumi dei carichi di lavoro in un cluster GKE di origine e il loro ripristino in un cluster GKE di destinazione. Per proteggere la configurazione e i dati dei workload da possibili perdite, ti consigliamo di abilitare e configurare Backup per GKE. Per maggiori informazioni, consulta la panoramica di Backup per GKE.

Cloud Run

Cloud Run è una piattaforma di computing gestita per eseguire carichi di lavoro containerizzati. Cloud Run utilizza i servizi per fornirti l'infrastruttura per eseguire i tuoi carichi di lavoro. 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. Dopodiché, Cloud Run sceglie automaticamente le zone all'interno di quella regione in cui eseguire il deployment delle istanze del servizio. Cloud Run bilancia automaticamente il traffico tra le istanze di servizio ed è progettato per mitigare notevolmente gli effetti di un'interruzione zonale.

VMware Engine

VMware Engine è un servizio completamente gestito che ti consente di eseguire la piattaforma VMware inGoogle Cloud. Per aumentare l'affidabilità degli ambienti che utilizzano VMware Engine, ti consigliamo di procedere nel seguente modo:

  • Esegui il provisioning di cloud privati VMware Engine multi-nodo. VMware Engine supporta il provisioning di stack VMware isolati chiamati cloud privati e tutti i nodi che compongono un cloud privato si trovano nella stessa regione. I nodi del cloud privato vengono eseguiti su nodi hardware bare metal dedicati e isolati e sono configurati per eliminare i single point of failure. VMware Engine supporta i cloud privati a nodo singolo, ma consigliamo di utilizzarli solo per prove concettuali e scopi di test. Per gli ambienti di produzione, ti consigliamo di utilizzare i cloud privati multimodali predefiniti.
  • Esegui il provisioning dei cloud privati estesi di VMware Engine. Un cloud privato esteso è un cloud privato multi-nodo i cui nodi sono distribuiti nelle zone di una regione. Un cloud privato esteso protegge il tuo ambiente da interruzioni zonali.

Per ulteriori informazioni sulle funzionalità di alta disponibilità e ridondanza di VMware Engine, consulta Disponibilità e ridondanza.

Esegui il provisioning e configura le risorse di archiviazione dei dati

Dopo aver eseguito il provisioning e la configurazione delle risorse di computing per gli ambienti a singola regione, esegui il provisioning e la configurazione delle risorse per archiviare e gestire i dati. Le seguenti sezioni descrivono i prodotti di archiviazione e gestione dei dati Google Cloud che supportano configurazioni regionali e multiregionali.

Cloud Storage

Cloud Storage è un servizio per archiviare oggetti, ovvero dati immutabili, in bucket, che sono i container di base in cui vengono archiviati i dati. Quando crei un bucket, seleziona il tipo di località del bucket che soddisfa al meglio i tuoi requisiti di disponibilità, normativi e di altro tipo. I tipi di località hanno garanzie di disponibilità diverse. Per proteggere i dati da errori e interruzioni, Cloud Storage rende i dati ridondanti in almeno due zone per i bucket con un tipo di località regione, in due regioni per i bucket con un tipo di località a due regioni e in due o più regioni per i bucket con un tipo di località multiregionale. Ad esempio, se devi rendere disponibile un bucket Cloud Storage in caso di interruzioni zonali, puoi eseguirne il provisioning con un tipo di località di regione.

Per saperne di più su come progettare meccanismi di ripristino di emergenza per i dati archiviati in Cloud Storage e su come Cloud Storage reagisce alle interruzioni zonali e regionali, consulta Progettazione del ripristino di emergenza per interruzioni dell'infrastruttura cloud: Cloud Storage.

Filestore

Filestore fornisce file server completamente gestiti su Google Cloud che possono essere connessi a istanze Compute Engine, cluster GKE e macchine on-premise. Filestore offre diversi livelli di servizio. Ogni livello offre funzionalità uniche di disponibilità, scalabilità, prestazioni, capacità e recupero dei dati. Quando esegui il provisioning delle istanze Filestore, ti consigliamo di scegliere il livello Enterprise perché supporta l'alta disponibilità e la ridondanza dei dati in più zone di una regione; le istanze che si trovano in altri livelli sono risorse zonali.

Bigtable

Bigtable è un servizio di database completamente gestito, ad alte prestazioni e ad alta scalabilità per carichi di lavoro analitici e operativi di grandi dimensioni. Le istanze Bigtable sono risorse a livello di zona. Per aumentare l'affidabilità delle tue istanze, puoi configurare Bigtable in modo che replichi i dati in più zone all'interno della stessa regione o in più regioni.

Quando la replica è abilitata, in caso di interruzione, Bigtable esegue automaticamente il failover delle richieste alle altre istanze disponibili in cui hai replicato i dati.

Per ulteriori informazioni su come funziona la replica in Bigtable, consulta Informazioni sulla replica e Progettazione del ripristino di emergenza per interruzioni dell'infrastruttura cloud: Bigtable.

Firestore

Firestore è un database flessibile e scalabile per lo sviluppo mobile, web e server di Firebase e Google Cloud. Quando esegui il provisioning di un database Firestore, selezioni la sua posizione. Le località possono essere multiregionali o regionali e offrono garanzie di affidabilità diverse. Se un database ha una località regionale, replica i dati in diverse zone all'interno di una regione. Un database multiregionale replica i dati in più di una regione.

Per informazioni su come funziona la replica in Firestore e su come Firestore reagisce alle interruzioni zonali e regionali, consulta Località Firestore e Progettazione del ripristino di emergenza per interruzioni dell'infrastruttura cloud: Firestore.

Memorystore

Memorystore ti consente di configurare servizi di archiviazione dei dati in memoria scalabili, sicuri e a disponibilità elevata. Supporta i backend di dati per Redis, Memcached, e Valkey.

Quando esegui il provisioning delle istanze Memorystore for Redis, selezioni un livello di servizio per l'istanza. Memorystore for Redis supporta diversi livelli di servizio delle istanze e ogni livello offre funzionalità uniche di disponibilità, dimensioni dei nodi e larghezza di banda. Quando esegui il provisioning di un'istanza Memorystore for Redis, ti consigliamo di scegliere un livello Standard o un livello Standard con repliche di lettura. Le istanze Memorystore in questi due livelli replicano automaticamente i dati in più zone di una regione.

Per saperne di più su come Memorystore for Redis raggiunge l'alta disponibilità, consulta Alta disponibilità per Memorystore for Redis.

Quando esegui il provisioning delle istanze Memorystore for Memcached, tieni presente quanto segue:

  • Selezione della zona. Quando esegui il provisioning delle istanze Memorystore for Memcached, seleziona la regione in cui vuoi eseguire il deployment dell'istanza. Poi, puoi selezionare le zone all'interno di quella regione in cui vuoi eseguire il deployment dei nodi dell'istanza oppure puoi lasciare che Memorystore for Memcached distribuisca automaticamente i nodi tra le zone. Per posizionare in modo ottimale le istanze ed evitare problemi di provisioning, ad esempio il posizionamento di tutti i nodi nella stessa zona, ti consigliamo di lasciare che Memorystore for Memcached distribuisca automaticamente i nodi nelle zone all'interno di una regione.
  • Replica dei dati tra le zone. Le istanze di Memorystore for Memcached non replicano i dati tra zone o regioni. Per ulteriori informazioni sul funzionamento delle istanze Memorystore for Memcached in caso di interruzioni zonali o regionali, consulta Progettazione del ripristino di emergenza per interruzioni dell'infrastruttura cloud: Memorystore for Memcached.

Quando esegui il provisioning delle istanze Memorystore for Valkey, scegli le opzioni di disponibilità e affidabilità. Memorystore for Valkey supporta diverse configurazioni, come istanze zonali e multizona. Per saperne di più sulla disponibilità e sull'affidabilità di Memorystore for Valkey, consulta Memorystore for Valkey: alta disponibilità e repliche.

Spanner

Spanner è un database relazionale completamente gestito con scalabilità illimitata, elevata coerenza e disponibilità fino al 99,999%. Per utilizzare Spanner, devi eseguire il provisioning delle istanze Spanner. Quando esegui il provisioning delle istanze Spanner, considera quanto segue:

  • Configurazione dell'istanza. Una configurazione dell'istanza definisce il posizionamento geografico e la replica dei database in un'istanza Spanner. Quando crei un'istanza Spanner, la configuri come regionale o multiregionale.
  • Replica. Spanner supporta la replica automatica a livello di byte e la creazione di repliche in base alle tue esigenze di disponibilità, affidabilità e scalabilità. Puoi distribuire le repliche tra regioni e ambienti. Le istanze Spanner con una configurazione regionale mantengono una replica di lettura e scrittura per ogni zona all'interno di una regione. Le istanze con una configurazione multiregionale replicano i dati in più zone di più regioni.
  • Spostamento delle istanze. Spanner ti consente di spostare un'istanza da una configurazione di istanza a un'altra senza causare tempi di inattività o interruzioni delle garanzie delle transazioni durante lo spostamento.

Per saperne di più sulla replica di Spanner e su come Spanner reagisce alle interruzioni zonali e regionali, consulta Replica di Spanner e Progettazione del ripristino di emergenza per interruzioni dell'infrastruttura cloud: Spanner.

Esegui il provisioning e configura le risorse di analisi dei dati

Dopo aver eseguito il provisioning e la configurazione delle risorse di archiviazione dei dati per gli ambienti a una sola regione, esegui il provisioning e la configurazione delle risorse di analisi dei dati. Le sezioni seguenti descrivono i prodotti di analisi dei dati Google Cloud che supportano le configurazioni regionali.

BigQuery

BigQuery è un data warehouse aziendale completamente gestito che ti aiuta a gestire e analizzare i dati con funzionalità integrate come machine learning, analisi geospaziale e business intelligence.

Per organizzare e controllare l'accesso ai dati in BigQuery, devi eseguire il provisioning di container di primo livello chiamati set di dati. Quando esegui il provisioning dei set di dati BigQuery, tieni presente quanto segue:

  • Posizione del set di dati. Per selezionare la località BigQuery in cui vuoi archiviare i dati, configura la località del set di dati. Una posizione può essere regionale o multiregionale. Per entrambi i tipi di località, BigQuery archivia copie dei dati in due zone diverse all'interno della località selezionata. Non puoi modificare la posizione del set di dati dopo averlo creato.
  • Pianificazione in caso di emergenza. BigQuery è un servizio regionale e gestisce automaticamente gli errori di zona per il calcolo e per i dati. Tuttavia, ci sono alcuni scenari che devi pianificare autonomamente, come le interruzioni regionali. Ti consigliamo di prendere in considerazione questi scenari quando progetti i tuoi ambienti.

Per ulteriori informazioni sulla pianificazione ripristino di emergenza di BigQuery e sulle funzionalità, consulta Comprendere l'affidabilità: pianificazione del disaster recovery nella documentazione di BigQuery e Progettazione ripristino di emergenza per interruzioni dell'infrastruttura cloud: BigQuery.

Dataproc

Dataproc è un servizio gestito che ti consente di sfruttare gli strumenti per i dati open source per elaborazione batch, esecuzione di query, inserimento di flussi e machine learning. Dataproc si basa su Compute Engine, pertanto i consigli della sezione precedente su Compute Engine si applicano parzialmente anche a Dataproc.

Per utilizzare Dataproc, devi creare cluster Dataproc. I cluster Dataproc sono risorse di zona. Quando crei cluster Dataproc, considera quanto segue:

  • Posizionamento automatico della zona. Quando crei un cluster, puoi specificare la zona all'interno di una regione in cui vuoi eseguire il provisioning dei nodi del cluster oppure lasciare che il posizionamento automatico delle zone di Dataproc selezioni automaticamente la zona. Ti consigliamo di utilizzare il posizionamento automatico delle zone, a meno che tu non debba perfezionare il posizionamento delle zone dei nodi del cluster all'interno della regione.
  • Modalità ad alta disponibilità. Quando crei un cluster, puoi attivare la modalità ad alta disponibilità. Non puoi attivare la modalità ad alta disponibilità dopo aver creato un cluster. Ti consigliamo di attivare la modalità ad alta disponibilità se hai bisogno che il cluster sia resiliente all'errore di un singolo nodo coordinatore o a interruzioni zonali parziali. I cluster Dataproc ad alta disponibilità sono risorse zonali.

Per saperne di più su come Dataproc reagisce alle interruzioni zonali e regionali e su come aumentare l'affidabilità dei tuoi cluster Dataproc in caso di errori, consulta Progettazione del ripristino di emergenza per interruzioni dell'infrastruttura cloud: Dataproc.

Dataflow

Dataflow è un servizio completamente gestito per l'esecuzione di pipeline di elaborazione dei dati in modalità flusso e batch. Per utilizzare Dataflow, devi creare pipeline Dataflow, e poi Dataflow esegue job, che sono istanze di queste pipeline, sui nodi worker. Poiché i job sono risorse a livello di zona, quando utilizzi le risorse Dataflow, devi considerare quanto segue:

  • Endpoint regionali. Quando crei un job, Dataflow richiede di configurare un endpoint regionale. Configurando un endpoint regionale per il job, limiti il posizionamento delle risorse di calcolo e dati a una regione specifica.
  • Posizionamento zonale. Dataflow distribuisce automaticamente i nodi worker in tutte le zone di una regione o nella zona migliore di una regione, a seconda del tipo di job. Dataflow ti consente di ignorare il posizionamento zonale dei nodi worker inserendoli tutti nella stessa zona all'interno di una regione. Per mitigare i problemi causati dalle interruzioni zonali, ti consigliamo di lasciare che Dataflow selezioni automaticamente il miglior posizionamento della zona, a meno che tu non debba posizionare i nodi worker in una zona specifica.

Per saperne di più su come Dataproc reagisce alle interruzioni zonali e regionali e su come aumentare l'affidabilità dei tuoi cluster Dataproc in caso di errori, consulta Progettazione del ripristino di emergenza per interruzioni dell'infrastruttura cloud: Dataflow.

Pub/Sub

Pub/Sub è un servizio di messaggistica asincrono e scalabile che disaccoppia i servizi che producono messaggi dai servizi che li elaborano. Pub/Sub organizza i messaggi in argomenti. I publisher (servizi che producono messaggi) inviano messaggi agli argomenti e i sottoscrittori ricevono messaggi dagli argomenti. Pub/Sub archivia ogni messaggio in una singola regione e lo replica in almeno due zone all'interno di quella regione. Per maggiori informazioni, consulta la panoramica dell'architettura di Pub/Sub.

Quando configuri l'ambiente Pub/Sub, considera quanto segue:

  • Endpoint globali e regionali. Pub/Sub supporta endpoint globali e regionali per pubblicare messaggi. Quando un publisher invia un messaggio all'endpoint globale, Pub/Sub seleziona automaticamente la regione più vicina per elaborare il messaggio. Quando un produttore invia un messaggio a un endpoint regionale, Pub/Sub lo elabora in quella regione.
  • Criteri di archiviazione dei messaggi. Pub/Sub ti consente di configurare policy di archiviazione dei messaggi per limitare la posizione in cui Pub/Sub elabora e archivia i messaggi, indipendentemente dall'origine della richiesta e dall'endpoint utilizzato dall'editore per pubblicare il messaggio. Ti consigliamo di configurare le norme di archiviazione dei messaggi per assicurarti che i messaggi non escano dal tuo ambiente a una sola regione.

Per ulteriori informazioni su come Pub/Sub gestisce le interruzioni zonali e regionali, consulta Progettazione ripristino di emergenza per interruzioni dell'infrastruttura cloud: Pub/Sub.

Adattare i carichi di lavoro agli ambienti a singola regione

Una volta completato il provisioning e la configurazione degli ambienti, devi valutare come rendere i tuoi workload più resilienti agli errori zonali e regionali. Ogni carico di lavoro può avere requisiti e proprietà di disponibilità e affidabilità propri, ma esistono alcuni principi di progettazione che puoi applicare e strategie che puoi adottare per migliorare la tua resilienza complessiva nell'improbabile eventualità di errori zonali e regionali. Quando progetti e implementi i tuoi workload, considera quanto segue:

  • Implementa le pratiche e i principi di Site Reliability Engineering (SRE). L'Automation e il monitoraggio esteso fanno parte dei principi fondamentali di SRE. Google Cloud fornisce gli strumenti e i servizi professionali per implementare SRE per aumentare la resilienza e l'affidabilità dei tuoi ambienti e ridurre il lavoro manuale.
  • Progettare per la scalabilità e la resilienza. Quando progetti carichi di lavoro destinati agli ambienti cloud, ti consigliamo di considerare la scalabilità e la resilienza come requisiti intrinseci che i tuoi carichi di lavoro devono rispettare. Per saperne di più su questo tipo di progettazione, consulta Pattern per app scalabili e resilienti.
  • Progettare il recupero da interruzioni dell'infrastruttura cloud. Le garanzie di disponibilità diGoogle Cloud sono definite dagli Google Cloud accordi sul livello del servizio. Nell'improbabile caso di un errore a livello di zona o regione, ti consigliamo di progettare i tuoi carichi di lavoro in modo che siano resilienti agli errori a livello di zona e regione.
  • Implementa la perdita di carico e la riduzione controllata. In caso di errori dell'infrastruttura cloud o di altre dipendenze dei tuoi carichi di lavoro, ti consigliamo di progettare i carichi di lavoro in modo che siano resilienti. I tuoi workload devono mantenere livelli di funzionalità certi e ben definiti anche in caso di errori (degradazione controllata) e devono essere in grado di ridurre una parte del carico quando si avvicinano a condizioni di sovraccarico (riduzione del carico).
  • Pianifica la manutenzione regolare. Quando progetti i tuoi processi di deployment e i tuoi processi operativi, ti consigliamo di pensare anche a tutte le attività che devi svolgere nell'ambito della manutenzione regolare dei tuoi ambienti. La manutenzione regolare deve includere attività come l'applicazione di aggiornamenti e modifiche alla configurazione ai tuoi workload e alle relative dipendenze e in che modo queste attività potrebbero influire sulla disponibilità dei tuoi ambienti. Ad esempio, puoi configurare una policy di manutenzione dell'host per le tue istanze Compute Engine.
  • Adotta un approccio di sviluppo basato sui test. Quando progetti i tuoi carichi di lavoro, ti consigliamo di adottare un approccio di sviluppo basato sui test per assicurarti che i tuoi carichi di lavoro si comportino come previsto da tutti i punti di vista. Ad esempio, puoi verificare se i tuoi workload e la tua infrastruttura cloud soddisfano i requisiti funzionali, non funzionali e di sicurezza che ti servono.

Passaggi successivi

Collaboratori

Autore: Marco Ferrari | Cloud Solutions Architect

Altri collaboratori: