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

Last reviewed 2023-12-08 UTC

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

Questo documento fa parte di una serie:

Questo documento mira a fornire indicazioni su come progettare ambienti resilienti a una singola regione su Google Cloud e si concentra sui seguenti componenti architetturali:

Le indicazioni contenute in questo documento presuppongono che tu stia progettando e implementando ambienti a singola regione. Se utilizzi ora un ambiente a singola regione, in futuro puoi eseguire la migrazione a un ambiente multiregionale. Se stai prendendo in considerazione una migrazione e un'evoluzione future dei tuoi ambienti di zona o di una singola regione verso ambienti multiregionali, consulta Eseguire la migrazione tra regioni Google Cloud: inizia.

Proprietà dei diversi archetipi di deployment

Google Cloud fornisce servizi da diverse regioni del mondo. Ogni regione è un'area geografica fisicamente indipendente composta da aree di deployment chiamate zone. Per ulteriori informazioni sulle regioni e sulle zone di Google Cloud, consulta Area geografica e località.

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

  • Archetipo di zona: esegui il provisioning delle risorse Google Cloud in una singola zona all'interno di una regione e utilizzi servizi di zona dove sono disponibili. Se i servizi di zona non sono disponibili, puoi usare i servizi regionali.
  • Archetipo a regione singola: esegui il provisioning delle risorse Google Cloud in più zone all'interno di una regione e utilizzi servizi regionali quando possibile.
  • Archetipo multiregionale: esegui il provisioning delle risorse Google Cloud in più zone in diverse regioni. Il provisioning delle risorse di zona viene eseguito in una o più zone di ciascuna regione.

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

Progettare, implementare e gestire un ambiente basato su questi archetipi di deployment richiede diversi livelli di impegno a causa delle proprietà di costo e di complessità di ciascun archetipo. Ad esempio, un ambiente a livello di zona potrebbe essere più economico e più facile da progettare, implementare e gestire rispetto a un ambiente regionale o multiregionale. L'impegno e i costi potenzialmente inferiori dell'ambiente di zona sono dovuti all'overhead aggiuntivo che devi gestire per coordinare i carichi di lavoro, i dati e i processi che risiedono in regioni diverse.

La tabella seguente riassume la distribuzione delle risorse, le proprietà di affidabilità e la complessità di ciascun archetipo architetturale. Descrive inoltre l'impegno necessario per progettare e implementare un ambiente in base a ciascun ambiente.

Nome dell'archetipo architettonico Distribuzione delle risorse Aiuta a resistere Complessità progettata
Ambiente di zona In una zona singola Errori delle risorse Richiede coordinazione all’interno di una singola zona
Ambiente a regione singola In più zone, in un'unica regione Errori delle risorse, interruzioni a livello di zona Richiede coordinamento tra più zone, in un’unica regione
Ambiente multiregionale In più zone, in più regioni Errori delle risorse, interruzioni a livello di zona, di interruzione a livello di regione e di più regioni Richiede coordinamento in più zone, in più regioni

Scegli gli archetipi di deployment per i tuoi ambienti

Per scegliere l'archetipo architetturale più adatto alle tue esigenze, segui questi passaggi:

  1. Definisci i modelli di errore da cui eseguire la protezione.
  2. Valuta gli archetipi di deployment per determinare quale risponde meglio alle tue esigenze.

Definisci i modelli di errore

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

  • Quali componenti del tuo ambiente richiedono modelli di errore? I modelli di errore possono essere applicati a tutto ciò di cui esegui il provisioning o il deployment su Google Cloud. Un modello di errore può essere applicato a un singolo utente oppure puoi applicarlo a tutte le risorse di un'intera zona o regione. Ti consigliamo di applicare un modello di errore a tutto ciò che fornisce valore, ad esempio carichi di lavoro, dati, processi e qualsiasi risorsa Google Cloud.
  • Quali sono i tuoi requisiti di alta disponibilità, continuità aziendale e ripristino di emergenza per questi componenti? Ogni componente dell'ambiente potrebbe avere i propri obiettivi del livello di servizio (SLO) che definiscono i livelli di servizio accettabili per il componente e requisiti di ripristino di emergenza specifici. Ad esempio, lo SLA di Compute Engine indica che se devi raggiungere oltre il 99,5% del tempo di attività mensile, devi eseguire il provisioning delle istanze in più zone all'interno di una singola regione. Per ulteriori informazioni, consulta la Guida alla pianificazione del ripristino di emergenza.
  • Quanti modelli di errore devi definire? In un ambiente tipico, non tutti i componenti devono fornire le stesse garanzie di affidabilità. Se offri delle garanzie per un tempo di attività più elevato e una maggiore resilienza, di solito devi spendere più risorse e sforzi. Quando definisci i modelli di errore, consigliamo di utilizzare un approccio in cui definire più modelli di errore per ogni componente e non solo uno per tutti i componenti. Ad esempio, i carichi di lavoro critici per l'attività di solito devono offrire un'affidabilità maggiore, anche se potrebbe essere accettabile offrire garanzie di affidabilità minori per altri carichi di lavoro meno critici.
  • Di quante risorse hanno bisogno i modelli di errore per la protezione dagli errori? Per difendersi dai modelli di errore che hai definito, spendi risorse come il tempo e il costo necessari alle persone per progettare, eseguire il provisioning e configurare meccanismi di protezione e processi automatizzati. Ti consigliamo di valutare il numero di risorse necessarie per evitare i modelli di errore che definisci.
  • Come viene rilevato un errore? La possibilità di rilevare se un errore si sta verificando o sta per verificarsi è fondamentale per poter avviare processi di mitigazione, ripristino e riconciliazione. Ad esempio, puoi configurare Google Cloud Observability per ricevere 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 ciascun modello per verificare che sia protetto in modo efficace dagli errori a cui sono destinati. Ad esempio, puoi inserire guasti nei tuoi ambienti o valutare la capacità degli ambienti di tollerare gli errori, puoi adottare l'ingegneria del caos.
  • Quale sarà l'impatto previsto se si verifica un particolare modello di errore? Per comprendere l'impatto che un errore potrebbe avere sulla tua attività, ti consigliamo di stimare le conseguenze di ogni errore sulla base di ogni modello di errore. Queste informazioni sono utili per stabilire priorità e ordini di ripristino, in modo che tu e i tuoi processi possiate occuparvi prima dei componenti più importanti.
  • Quanto tempo pensi che durino gli errori nei modelli di errore che stai definendo? La durata di un errore può influire notevolmente sui piani di mitigazione e recupero. Pertanto, quando definisci i modelli di errore, ti consigliamo di tenere conto della durata di un errore. Quando valuti la durata di un errore, valuta anche quanto tempo occorre per identificare un errore, riconciliare l'errore e ripristinare le risorse non riuscite.

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

Valuta gli archetipi di deployment

Dopo aver definito i modelli di errore da cui difendersi, valuti gli archetipi di deployment per determinare quale sia il più adatto alle tue esigenze. Quando valuti gli archetipi del deployment, rispondi alle seguenti domande:

  • Quanti archetipi di deployment ti servono? Non è necessario scegliere un solo archetipo architetturale per adattarsi a tutti gli ambienti. Puoi invece implementare un approccio ibrido in cui scegliere più archetipi di deployment in base alle garanzie di affidabilità necessarie per difenderti dai modelli di errore definiti. Ad esempio, se hai definito due modelli di errore, uno che richiede un ambiente di zona e uno che richiede un ambiente regionale, potresti voler scegliere archetipi di deployment separati da proteggere 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 hai bisogno per progettare e implementare ambienti in base agli archetipi di deployment? La progettazione e l'implementazione di qualsiasi tipo di ambiente richiede risorse e sforzi. Ti consigliamo di valutare quante risorse pensi siano necessarie per progettare e implementare ogni ambiente in base all'archetipo scelto. Una volta capito tutte le risorse di cui hai bisogno, puoi bilanciare i compromessi tra l'affidabilità garantita da ogni archetipo dell'architettura e i costi e la complessità della progettazione, dell'implementazione e dei processi operativi basati su questi archetipi.
  • Intendi eseguire la migrazione di un ambiente basato su un archetipo architetturale a un ambiente basato su un archetipo diverso? In futuro, potresti eseguire la migrazione di carichi di lavoro, dati e processi da un ambiente Google Cloud a un altro ambiente Google Cloud. Ad esempio, potresti eseguire la migrazione da un ambiente di zona a un ambiente regionale.
  • Quanto sono critici 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 di progettare un ambiente a livello di zona o di regione per carichi di lavoro, dati e processi meno critici.
  • Hai bisogno delle caratteristiche offerte da particolari archetipi architettonici per determinati ambienti? Oltre all'affidabilità offerta da ogni archetipo architetturale, gli archetipi offrono anche garanzie diverse 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, relativi a località e 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 singola regione o un ambiente di zona in quella regione.

Scegli una regione Google Cloud per il tuo ambiente

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

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

Se scegli una determinata regione Google Cloud ora, in futuro puoi eseguire la migrazione a regioni diverse o a un ambiente multiregionale. Se stai prendendo in considerazione una migrazione futura ad altre regioni, consulta Eseguire la migrazione tra regioni Google Cloud: inizia.

Valutare i criteri funzionali

Per valutare i criteri funzionali, poniti le seguenti domande:

  • Quali sono i tuoi requisiti di prossimità geografica? Quando scegli una regione Google Cloud, potrebbe essere necessario collocare i carichi di lavoro, i dati e i processi vicino agli utenti o ai tuoi ambienti al di fuori di Google Cloud, ad esempio gli ambienti on-premise. Ad esempio, se scegli come target una base utenti concentrata in una determinata area geografica, ti consigliamo di scegliere una regione Google Cloud più vicina a quell'area geografica. La scelta di una regione Google Cloud più adatta ai requisiti di prossimità geografica consente ai tuoi ambienti di garantire una latenza inferiore e tempi di reazione più bassi alle richieste dei tuoi utenti e dei tuoi ambienti al di fuori di Google Cloud. Strumenti come la dashboard di latenza di Google Cloud e quelli non ufficiali come GCPing e il selettore della regione di Google Cloud possono darti un'idea generale delle caratteristiche di latenza delle regioni di Google Cloud. Tuttavia, ti consigliamo di eseguire una valutazione completa per valutare se le proprietà di latenza si adattano ai tuoi requisiti, carichi di lavoro, dati e processi.
  • Quali delle regioni in cui vuoi utilizzare offrono i prodotti di cui hai bisogno? Ti consigliamo di valutare i prodotti disponibili in ogni regione di Google Cloud e le regioni che forniscono i servizi necessari per progettare e implementare i tuoi ambienti. Per ulteriori informazioni su quali prodotti sono disponibili in ogni regione e sulle relative tempistiche di disponibilità, consulta Località cloud. Inoltre, alcuni prodotti potrebbero non offrire tutte le loro funzionalità in tutte le regioni in cui sono disponibili. Ad esempio, le regioni e le zone disponibili per Compute Engine offrono tipi di macchine specifici in specifiche regioni di Google Cloud. Per ulteriori informazioni sulle funzionalità offerte da ciascun 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 risorsa Google Cloud condivisa che puoi utilizzare. Alcune quote sono globali e si applicano al tuo utilizzo della risorsa ovunque in Google Cloud, mentre altre sono a livello di regione o zona e si applicano al tuo utilizzo della risorsa in una specifica regione di Google Cloud. Ad esempio, la maggior parte delle quote di utilizzo delle risorse di Compute Engine, come il numero di macchine virtuali che puoi creare, è regionale. Per ulteriori informazioni sulle quote e su come aumentarle, consulta Utilizzo delle quote.

Valutare criteri non funzionali

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

  • Preferisci un impatto ambientale ridotto? Google Cloud investe costantemente nella sostenibilità e nell'energia a zero emissioni di CO2 per le regioni di Google Cloud ed è impegnato a utilizzare energia a zero emissioni di CO2 per tutte le regioni cloud. Le regioni di Google Cloud hanno un'impronta di carbonio diversa. Per informazioni sull'impronta di carbonio di ogni regione Google Cloud e su come incorporare energia a zero emissioni di CO2 nella tua strategia di geolocalizzazione, consulta Energia a zero emissioni di CO2 per le regioni di Google Cloud.
  • I tuoi ambienti devono soddisfare particolari normative? I governi e gli enti nazionali e sovranazionali spesso regolamentano rigorosamente determinati mercati e aree commerciali, come le banche e il settore pubblico. Queste normative potrebbero imporre che i carichi di lavoro, i dati e i processi si trovino solo in determinate aree geografiche. Ad esempio, i tuoi ambienti potrebbero dover rispettare i requisiti di sovranità dei dati, operativa e del software per garantire determinati livelli di controllo e trasparenza per i dati sensibili e i carichi di lavoro in esecuzione nel cloud. Ti consigliamo di valutare i requisiti normativi attuali e futuri quando scegli le regioni Google Cloud per i tuoi ambienti e di selezionare quelle che meglio si adattano ai tuoi requisiti normativi.

Progetta e crea ambienti a singola regione

Per progettare un ambiente a una singola regione:

  1. Crea le tue basi su Google Cloud.
  2. Esegui il provisioning e la configurazione delle risorse di calcolo.
  3. Eseguire il provisioning e la configurazione delle risorse di archiviazione dati.
  4. Esegui il provisioning e la configurazione delle risorse di analisi dei dati.

Quando progetti il tuo ambiente, considera i seguenti principi generali:

  • Esegui il provisioning delle risorse di regione. Molti prodotti Google Cloud supportano il provisioning delle risorse in più zone di una regione. Quando possibile, ti consigliamo di eseguire il provisioning di risorse di regione anziché di risorse di zona. In teoria, potresti essere in grado di eseguire il provisioning di risorse di zona in più zone di una regione e gestirle autonomamente per ottenere una maggiore affidabilità. Tuttavia, questa configurazione non trarrebbe appieno da tutte le funzionalità di affidabilità dell'infrastruttura Google alla base dei servizi Google Cloud.
  • Verifica che gli ambienti funzionino come previsto con i presupposti dei modelli di errore. Quando progetti e implementi gli ambienti a singola regione, ti consigliamo di verificare se questi ambienti soddisfano i requisiti per la protezione dai modelli di errore che stai prendendo in considerazione, prima di promuovere questi ambienti come parte dell'ambiente di produzione. Ad esempio, puoi simulare le interruzioni a livello di zona per verificare che gli ambienti a una singola regione possano sopravvivere con interruzioni minime.

Per informazioni più generali sui principi di progettazione per la progettazione di ambienti affidabili a una o più regioni e per informazioni su come Google migliora l'affidabilità con i servizi regionali e multiregionali, consulta Architetazione del ripristino di emergenza per interruzioni dell'infrastruttura cloud: temi comuni.

Crea le tue basi su Google Cloud

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

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

Eseguire il provisioning e la configurazione delle risorse di calcolo

Dopo aver creato le basi per i tuoi ambienti a una singola regione, puoi eseguire il provisioning e la configurazione delle risorse di calcolo. Le seguenti sezioni descrivono i prodotti di computing di Google Cloud che supportano i deployment a livello di regione.

Compute Engine

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

Le risorse Compute Engine sono a livello di zona, ad esempio macchine virtuali o dischi permanenti a livello di zona, a livello di regione, ad esempio indirizzi IP esterni statici, o globali, ad esempio snapshot di dischi permanenti. Per ulteriori informazioni sulle risorse a livello di zona, di regione e globali supportate da Compute Engine, consulta Risorse globali, a livello di regione e di zona.

Per consentire una maggiore flessibilità e una migliore gestione delle risorse fisiche, Compute Engine disaccoppia le zone dalle risorse fisiche. Per ulteriori informazioni su questa astrazione e sul suo significato, consulta Zone e cluster.

Per aumentare l'affidabilità dei tuoi ambienti che utilizzano Compute Engine, considera quanto segue:

  • Gruppi di istanze gestite a livello di regione. Le macchine virtuali Compute Engine sono risorse a livello di zona, pertanto non saranno disponibili in caso di interruzione a livello di zona. Per mitigare questo problema, Compute Engine consente di creare gruppi di istanze gestite a livello di regione che eseguono automaticamente il provisioning di macchine virtuali su più zone all'interno di una regione, in base alla domanda e alla disponibilità regionale. Se i tuoi carichi di lavoro sono stateful, puoi anche creare MIG stateful a livello di regione per conservare i dati e le configurazioni stateful. I gruppi di istanze gestite a livello di regione supportano la simulazione di errori a livello di zona. Per informazioni su come simulare un errore a livello di zona quando si utilizza un gruppo di istanze gestite a livello di regione, consulta Simulare un'interruzione di una zona per un gruppo di istanze gestite a livello di regione. Per informazioni su come i gruppi di istanze gestite a livello di regione confrontano con altre opzioni di deployment, consulta Scegliere una strategia di deployment di Compute Engine per il carico di lavoro.
  • Forma di distribuzione target. I gruppi di istanze gestite a livello regionale distribuiscono macchine virtuali in base alla forma Per assicurarti che la distribuzione di 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 gruppi di istanze gestite a livello di regione. Per informazioni sulle differenze tra le forme di distribuzione di destinazione, consulta Confronto di forme.
  • Modelli di istanza. Per definire le macchine virtuali di cui eseguire il provisioning, i gruppi di istanze gestite utilizzano un tipo di risorsa globale chiamato modelli di istanza. Sebbene i modelli di istanza siano risorse globali, potrebbero fare riferimento a risorse di zona o di regione. Quando crei modelli di istanza, ti consigliamo di fare riferimento alle risorse di regione 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 di Persistent Disk disponibile solo in una determinata zona, non puoi utilizzare il modello in altre zone perché il volume del Persistent Disk non è disponibile in quelle altre zone.
  • Configurare bilanciamento del carico e scalabilità. Compute Engine supporta il bilanciamento del carico del traffico tra istanze Compute Engine e la scalabilità automatica per aggiungere o rimuovere automaticamente le macchine virtuali dai gruppi di istanze gestite, in base alla domanda. Per aumentare l'affidabilità e la flessibilità dei tuoi ambienti ed evitare il carico della gestione delle soluzioni autogestite, ti consigliamo di configurare il bilanciamento del carico e la scalabilità automatica. Per ulteriori informazioni sulla configurazione del bilanciamento del carico e della scalabilità per Compute Engine, consulta Bilanciamento del carico e scalabilità.
  • Configura le prenotazioni delle risorse. Per garantire che i tuoi ambienti dispongano delle risorse necessarie quando ne hai bisogno, ti consigliamo di configurare le prenotazioni di risorse per garantire l'ottenimento di capacità per le risorse di Compute Engine di zona. Ad esempio, in caso di interruzione a livello di zona, potresti dover eseguire il provisioning delle macchine virtuali in un'altra zona per fornire la capacità necessaria per compensare quelle non disponibili a causa dell'interruzione. Le prenotazioni delle risorse garantiscono la disponibilità delle risorse 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. Per impostazione predefinita, Google Cloud usa nomi DNS di zona per le macchine virtuali. Per ulteriori informazioni su come funziona il DNS interno di Compute Engine, consulta DNS interno. Per facilitare la migrazione in futuro tra regioni e rendere la configurazione più gestibile, ti consigliamo di prendere in considerazione 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, tra cui volumi di Persistent Disk e unità a stato solido (SSD) locali:
    • I volumi dei Persistent Disk sono distribuiti su più dischi fisici e sono localizzati in modo indipendente dalle tue macchine virtuali. I dischi permanenti possono essere a livello di zona o di regione. I dischi permanenti a livello di zona archiviano i dati in una singola zona, mentre i dischi permanenti a livello di regione replicano i dati in due zone diverse. Quando scegli le opzioni di archiviazione per i tuoi ambienti con una singola regione, ti consigliamo di scegliere i dischi permanenti a livello di regione perché offrono opzioni di failover in caso di errori a livello di zona. Per ulteriori informazioni su come reagire agli errori a livello di zona quando utilizzi dischi permanenti a livello di regione, consulta Opzioni di alta disponibilità utilizzando un disco permanente a livello di regione e Failover del disco permanente a livello di regione.
    • Le unità 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 dischi fisici.
  • Progettare e implementare meccanismi per la protezione dei dati. Quando progetti gli ambienti a una singola regione, ti consigliamo di implementare meccanismi automatici per proteggere i dati in caso di eventi avversi, come errori a livello di zona, di regione o di più regioni oppure attacchi deliberati di terze parti dannose. Compute Engine offre varie opzioni per proteggere i tuoi dati. Puoi utilizzare queste funzionalità delle opzioni dei dati come componenti di base per progettare e implementare i processi di protezione dei dati.

GKE

GKE consente di eseguire il deployment, gestire e scalare carichi di lavoro containerizzati su Kubernetes. GKE si basa su Compute Engine, quindi i suggerimenti nella sezione precedente relativi a Compute Engine si applicano parzialmente a GKE.

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

  • Utilizza i cluster GKE a livello di regione per aumentare la disponibilità. GKE supporta diversi tipi di disponibilità per i cluster, a seconda del tipo di cluster di cui hai bisogno. I cluster GKE possono avere un piano di controllo a livello di zona o di regione e possono avere nodi eseguiti in un'unica zona o in più zone all'interno di una regione. Diversi tipi di cluster offrono inoltre accordi sul livello del servizio (SLA) diversi. 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 a livello di regione.
  • Prendi in considerazione un ambiente multi-cluster. Il deployment di più cluster GKE può aumentare la flessibilità e le proprietà di disponibilità del tuo ambiente, a scapito della complessità crescente. Ad esempio, se devi utilizzare una nuova funzionalità GKE abilitabile solo quando crei un cluster GKE, puoi evitare tempi di inattività e ridurre la complessità della migrazione aggiungendo un nuovo cluster GKE all'ambiente multi-cluster, eseguendo il deployment dei carichi di lavoro nel nuovo cluster ed eliminando il cluster precedente. Per ulteriori 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 la gestione del parco risorse, un insieme di funzionalità per gestire un gruppo di cluster GKE, la relativa infrastruttura e i carichi di lavoro di cui viene eseguito il deployment nei cluster.
  • Configura Backup per GKE. Backup per GKE è un servizio a livello di regione per il backup della configurazione e dei volumi dei carichi di lavoro in un cluster GKE di origine e il ripristino in un cluster GKE di destinazione. Per proteggere la configurazione e i dati dei carichi di lavoro da possibili perdite, ti consigliamo di abilitare e configurare Backup per GKE. Per maggiori informazioni, consulta Panoramica di Backup per GKE.

Cloud Run

Cloud Run è una piattaforma di computing gestita per l'esecuzione di carichi di lavoro containerizzati. Cloud Run utilizza i servizi per fornirti l'infrastruttura necessaria per eseguire i carichi di lavoro. I servizi di Cloud Run sono risorse di regione e sono replicati in più zone della regione in cui si trovano. Quando esegui il deployment di un servizio Cloud Run, puoi scegliere una regione. Cloud Run sceglie quindi automaticamente le zone all'interno della 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 del servizio a livello di zona.

VMware Engine

VMware Engine è un servizio completamente gestito che consente di eseguire la piattaforma VMware in Google Cloud. Per aumentare l'affidabilità dei tuoi ambienti che utilizzano VMware Engine, ti consigliamo quanto segue:

  • Esegui il provisioning dei cloud privati VMware Engine multinodo. VMware Engine supporta il provisioning di stack VMware isolati, denominati cloud privati, e tutti i nodi che compongono un cloud privato risiedono nella stessa regione. I nodi del cloud privato vengono eseguiti su nodi hardware Bare Metal dedicati e isolati e sono configurati in modo da eliminare i single point of failure. VMware Engine supporta i cloud privati a nodo singolo, ma consigliamo di utilizzarli solo per scopi di proof of concept e di test. Per gli ambienti di produzione, consigliamo di usare i cloud privati multinodi predefiniti.
  • Esegui il provisioning dei cloud privati ampliati di VMware Engine. Un cloud privato ampliato è un cloud privato a più nodi i cui nodi sono distribuiti tra le zone all'interno di una regione. Un cloud privato esteso protegge il tuo ambiente da interruzioni a livello di zona.

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

Eseguire il provisioning e la configurazione delle risorse di archiviazione dati

Dopo aver eseguito il provisioning e la configurazione delle risorse di calcolo 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 di Google Cloud che supportano le configurazioni regionali e multiregionali.

Cloud Storage

Cloud Storage è un servizio per archiviare oggetti, ovvero pezzi di dati immutabili, in bucket, ovvero container di base in cui conservare i dati. Quando crei un bucket, selezioni il tipo di località del bucket che meglio soddisfa i requisiti di disponibilità, normativi e di altro tipo. I tipi di località hanno garanzie di disponibilità diverse. Per proteggere i tuoi dati da guasti e interruzioni, Cloud Storage rende i tuoi dati ridondanti in almeno due zone per i bucket con tipo di località a livello di 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 a livello di zona, puoi eseguire il provisioning con un tipo di località a livello di regione.

Per ulteriori informazioni su come progettare meccanismi di emergenza per i dati archiviati in Cloud Storage e su come Cloud Storage reagisce a interruzioni a livello di zona e di regione, consulta Architecting ripristino di emergenza per interruzioni dell'infrastruttura cloud: Cloud Storage.

Filestore

Filestore fornisce su Google Cloud file server completamente gestiti che possono essere connessi a istanze di Compute Engine, cluster GKE e alle tue macchine on-premise. Filestore offre diversi livelli di servizio. Ogni livello offre funzionalità uniche per 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 di zona.

Bigtable

Bigtable è un servizio di database completamente gestito, con prestazioni elevate e scalabilità elevata per carichi di lavoro analitici e operativi di grandi dimensioni. Le istanze Bigtable sono risorse di zona. Per aumentare l'affidabilità delle istanze, puoi configurare Bigtable per replicare 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 ad altre istanze disponibili in cui hai replicato i dati.

Per saperne di più su come funziona la replica in Bigtable, consulta Informazioni sulla replica e Architettura 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, ne selezioni la località. Le località possono essere multiregionali o regionali e offrono diverse garanzie di affidabilità. 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ù regioni.

Per informazioni sul funzionamento della replica in Firestore e su come Firestore reagisce a interruzioni di zona e regionali, consulta Località di Firestore e Architettura del ripristino di emergenza per le interruzioni dell'infrastruttura cloud: Firestore.

Memorystore

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

Quando esegui il provisioning di Memorystore per istanze 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à, dimensione 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 ulteriori informazioni su come Memorystore for Redis raggiunge l'alta disponibilità, consulta Disponibilità elevata per Memorystore for Redis.

Quando esegui il provisioning di Memorystore per istanze Memcached, tieni presente quanto segue:

  • Selezione zona. Quando esegui il provisioning di istanze Memorystore for Memcached, devi selezionare la regione in cui vuoi eseguire il deployment dell'istanza. Quindi, puoi selezionare le zone all'interno della regione in cui vuoi eseguire il deployment dei nodi dell'istanza oppure puoi consentire a Memorystore for Memcached di distribuire automaticamente i nodi tra le zone. Per posizionare le istanze in modo ottimale ed evitare problemi di provisioning, ad esempio il posizionamento di tutti i nodi all'interno della stessa zona, ti consigliamo di consentire a Memorystore per Memcached di distribuire automaticamente i nodi tra le zone all'interno di una regione.
  • Replica dei dati tra zone. Le istanze 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 a livello di zona o di regione, consulta Architecting ripristino di emergenza in caso di interruzioni dell'infrastruttura cloud: Memorystore for Memcached.

Spanner

Spanner è un database relazionale completamente gestito con scalabilità illimitata, elevata coerenza e disponibilità fino al 99,999%. Per utilizzare Spanner, esegui il provisioning delle istanze di 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 di 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 replicas 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 su più regioni.
  • Spostamento delle istanze. Spanner consente di spostare un'istanza da qualsiasi configurazione di istanza a qualsiasi altra configurazione senza causare tempi di inattività o interruzioni delle transazioni garantite durante il trasferimento.

Per saperne di più sulla replica di Spanner e su come Spanner reagisce alle interruzioni a livello di zona e di regione, consulta Replica di Spanner e Architecting ripristino di emergenza per interruzioni dell'infrastruttura cloud: Spanner.

Eseguire il provisioning e la configurazione delle risorse di analisi dei dati

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

BigQuery

BigQuery è un data warehouse aziendale completamente gestito che ti consente di gestire e analizzare i tuoi 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 denominati set di dati. Quando esegui il provisioning di un set di dati BigQuery, considera quanto segue:

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

Per ulteriori informazioni sulla pianificazione e sulle funzionalità del ripristino di emergenza di BigQuery, vedi Informazioni sull'affidabilità: pianificazione in caso di emergenza nella documentazione di BigQuery e consulta Architettura del ripristino di emergenza per le interruzioni dell'infrastruttura cloud: BigQuery.

Dataproc

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

Per utilizzare Dataproc, devi creare dei 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 eseguire il provisioning dei nodi del cluster o lasciare che il posizionamento della zona automatica di Dataproc selezioni automaticamente la zona. Ti consigliamo di utilizzare il posizionamento automatico della zona, a meno che non sia necessario ottimizzare il posizionamento della zona dei nodi del cluster all'interno della regione.
  • Modalità alta disponibilità. Quando crei un cluster, puoi abilitare la modalità ad alta disponibilità. Non puoi abilitare la modalità ad alta disponibilità dopo aver creato un cluster. Ti consigliamo di abilitare la modalità ad alta disponibilità se devi rendere il cluster resiliente in caso di errore di un singolo nodo coordinatore o di interruzioni parziali di zona. I cluster Dataproc ad alta disponibilità sono risorse a livello di zona.

Per ulteriori informazioni su come Dataproc reagisce alle interruzioni a livello di zona e regione e su come aumentare l'affidabilità dei cluster Dataproc in caso di errori, consulta Architettura 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, quindi Dataflow esegue i job, che sono istanze di queste pipeline, sui nodi worker. Poiché i job sono risorse a livello di zona, quando utilizzi le risorse Dataflow dovresti considerare quanto segue:

  • Endpoint a livello di regione. Quando crei un job, Dataflow richiede la configurazione di un endpoint a livello di regione. Configurando un endpoint a livello di regione per il job, limiti il calcolo e il posizionamento delle risorse di dati a una determinata regione.
  • Posizionamento a livello di zona. Dataflow distribuisce automaticamente i nodi worker in tutte le zone all'interno di una regione o nella zona migliore di una regione, a seconda del tipo di job. Dataflow consente di eseguire l'override del posizionamento a livello di zona dei nodi worker posizionando tutti i nodi worker nella stessa zona all'interno di una regione. Per mitigare i problemi causati da interruzioni a livello di zona, ti consigliamo di consentire a Dataflow di selezionare automaticamente il posizionamento della zona migliore, a meno che tu non debba posizionare i nodi worker in una zona specifica.

Per ulteriori informazioni su come Dataproc reagisce alle interruzioni a livello di zona e regione e su come aumentare l'affidabilità dei cluster Dataproc in caso di errori, consulta Architettura 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 generano 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 li replica in almeno due zone all'interno di quella regione. Per maggiori informazioni, consulta la Panoramica architetturale di Pub/Sub.

Quando configuri il tuo ambiente Pub/Sub, considera quanto segue:

  • Endpoint globali e a livello di regione. Pub/Sub supporta endpoint globali e a livello di regione per la pubblicazione dei messaggi. Quando un editore invia un messaggio all'endpoint globale, Pub/Sub seleziona automaticamente la regione più vicina per elaborare il messaggio. Quando un producer invia un messaggio a un endpoint a livello di regione, Pub/Sub elabora il messaggio in quella regione.
  • Criteri di archiviazione dei messaggi. Pub/Sub consente di configurare criteri 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 i criteri di archiviazione dei messaggi per assicurarti che i messaggi non escano dall'ambiente a singola regione.

Per saperne di più su come Pub/Sub gestisce le interruzioni a livello di zona e di regione, consulta Architecting ripristino di emergenza per interruzioni dell'infrastruttura cloud: Pub/Sub.

Adatta i carichi di lavoro ad ambienti con una singola regione

Una volta completato il provisioning e la configurazione degli ambienti, devi valutare come rendere i carichi di lavoro più resilienti agli errori a livello di zona e di regione. Ogni carico di lavoro può avere requisiti e proprietà di disponibilità e affidabilità specifici, ma è possibile applicare alcuni principi di progettazione e strategie che è possibile adottare per migliorare la postura di resilienza complessiva nell'improbabile caso di errori a livello di zona e di regione. Quando progetti e implementi i tuoi carichi di lavoro, considera quanto segue:

  • Implementare le pratiche e i principi di Site Reliability Engineering (SRE). L'Automation e il monitoraggio esteso sono i principi fondamentali di SRE. Google Cloud fornisce gli strumenti e i servizi professionali per implementare l'SRE al fine di aumentare la resilienza e l'affidabilità dei tuoi ambienti e per ridurre il lavoro manuale.
  • Progetta per la scalabilità e la resilienza. Quando si progettano carichi di lavoro rivolti ad ambienti cloud, consigliamo di considerare la scalabilità e la resilienza come requisiti intrinseci che i carichi di lavoro devono rispettare. Per ulteriori informazioni su questo tipo di progettazione, consulta Pattern per app scalabili e resilienti.
  • Progettazione per il ripristino da interruzioni dell'infrastruttura cloud. Le garanzie di disponibilità di Google Cloud sono definite dagli accordi sul livello del servizio di Google Cloud. Nell'improbabile caso in cui si verifichi un errore a livello di zona o di regione, ti consigliamo di progettare i carichi di lavoro in modo che siano resilienti agli errori a livello di zona e di regione.
  • Implementa la suddivisione del carico e la riduzione controllata. In caso di errori dell'infrastruttura cloud o in altre dipendenze dei carichi di lavoro, ti consigliamo di progettare i carichi di lavoro in modo che siano resilienti. I carichi di lavoro devono mantenere determinati e livelli di funzionalità ben definiti anche in caso di errori (degradazione graziosa) ed essere in grado di ridurre una parte del carico man mano che si avvicinano alle condizioni di sovraccarico (perdita del carico).
  • Pianificare una manutenzione regolare. Quando progetti i processi di deployment e i processi operativi, ti consigliamo di pensare anche a tutte le attività da eseguire nell'ambito della regolare manutenzione degli ambienti. La manutenzione regolare dovrebbe includere attività come l'applicazione di aggiornamenti e modifiche alla configurazione dei carichi di lavoro e delle relative dipendenze, nonché il modo in cui queste attività potrebbero influire sulla disponibilità degli ambienti. Ad esempio, puoi configurare un criterio di manutenzione dell'host per le tue istanze Compute Engine.
  • Adotta un approccio di sviluppo basato su test. Quando progetti i carichi di lavoro, ti consigliamo di adottare un approccio allo sviluppo basato su test, per assicurarti che i carichi di lavoro si comportino come previsto da tutte le angolazioni. Ad esempio, puoi testare se i tuoi carichi di lavoro e la tua infrastruttura cloud soddisfano i requisiti funzionali, non funzionali e di sicurezza di cui hai bisogno.

Passaggi successivi

Collaboratori

Autori:

Altri collaboratori:

Per vedere profili di LinkedIn non pubblici, accedi a LinkedIn.