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

Last reviewed 2023-12-08 UTC

Questo documento ti aiuta a progettare ambienti resilienti di un'unica regione su Google Cloud. Questo documento è utile se prevedi di eseguire la migrazione di un ambiente con 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 singole regioni su Google Cloud e si concentra sui seguenti componenti dell'architettura:

Le indicazioni contenute in questo documento presuppongono che tu stia progettando e implementando ambienti di singole regioni. Se ora utilizzi un ambiente con una sola regione, in futuro potrai eseguire la migrazione a un ambiente multiregionale. Se stai valutando la futura migrazione e l'evoluzione dei tuoi ambienti a livello di zona e di una sola regione ad ambienti multiregionali, consulta Eseguire la migrazione tra regioni Google Cloud: inizia.

Proprietà di diversi archetipi di deployment

Google Cloud offre servizi in diverse regioni in tutto il mondo. Ogni regione è un'area geografica fisicamente indipendente composta da aree di deployment chiamate zone. Per ulteriori informazioni su regioni e 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 crescente di 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 i servizi di zona laddove sono disponibili. Se i servizi di zona non sono disponibili, puoi utilizzare quelli a livello di regione.
  • Archetipo a una singola regione: esegui il provisioning delle risorse Google Cloud in più zone all'interno di una regione e utilizzi i servizi a livello di regione quando possibile.
  • Archetipo multiregionale: esegui il provisioning delle risorse Google Cloud in più zone tra regioni diverse. Il provisioning delle risorse di zona viene eseguito 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à 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 con una singola regione o zona. Per saperne di più sulle proprietà di affidabilità di ogni archetipo dell'architettura, consulta Come sfruttare zone e regioni per ottenere l'affidabilità e la guida all'affidabilità dell'infrastruttura di Google Cloud.

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

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

Nome dell'archetipo architettonico Distribuzione delle risorse Contribuisce a resistere Complessità della progettazione
Ambiente di zona In una singola zona Errori relativi alle risorse Richiede coordinamento all’interno di una singola zona
Ambiente a una singola regione In più zone, in un'unica regione Errori delle risorse, interruzioni a livello di zona Richiede il coordinamento tra più zone, in un’unica regione
Ambiente multiregionale In più zone, in più regioni Errori delle risorse, interruzioni a livello di zona, a livello di regione e di più regioni Richiede il coordinamento tra più zone, in più regioni

Scegli gli archetipi di deployment per i tuoi ambienti

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

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

Definire i modelli di errore

Per definire i modelli di errore, prendi in considerazione le seguenti domande:

  • Quali componenti del tuo ambiente richiedono modelli di errore? I modelli di errore possono essere applicati a qualsiasi attività di cui esegui il provisioning o il deployment su Google Cloud. Un modello di errore può essere applicato a un singolo utente oppure puoi applicare un modello di errore a tutte le risorse in un'intera zona o regione. Ti consigliamo di applicare un modello di errore a tutto ciò che ti offre valore, come carichi di lavoro, dati, processi e qualsiasi risorsa Google Cloud.
  • Quali sono i requisiti di alta disponibilità, continuità aziendale e ripristino di emergenza per questi componenti? Ogni componente dell'ambiente potrebbe avere obiettivi del livello di servizio (SLO) che definiscono i livelli di servizio accettabili per il componente e i propri requisiti per il ripristino di emergenza. Ad esempio, lo SLA di Compute Engine indica che, se hai bisogno di raggiungere oltre il 99,5% di uptime mensile, devi eseguire il provisioning delle istanze in più zone su un'unica 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 garanzie per un tempo di attività più elevato e una maggiore resilienza, di solito devi spendere più risorse e impegno. Quando definisci i modelli di errore, ti consigliamo di prendere in considerazione 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'azienda di solito devono offrire una maggiore affidabilità, anche se potrebbe essere accettabile offrire garanzie di affidabilità inferiori per altri carichi di lavoro meno critici.
  • Di quante risorse hanno bisogno i modelli di errore per proteggere gli errori? Per proteggerti 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 quante risorse hai bisogno di prevenire da ciascun modello di errore definito.
  • Come è possibile rilevare un guasto? Essere in grado di rilevare se un guasto è in corso o sta per verificarsi è fondamentale per poter avviare i processi di mitigazione, ripristino e riconciliazione. Ad esempio, puoi configurare l'osservabilità di Google Cloud 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 ogni modello per verificare che prevenga efficacemente gli errori a cui sono indirizzati i modelli. Ad esempio, puoi inserire gli errori nei tuoi ambienti o valutare la capacità dei tuoi ambienti di tollerare errori, puoi adottare l'ingegneria del caos.
  • Quale impatto ti aspetti se si verifica un determinato modello di errore? Per comprendere l'impatto che un errore potrebbe avere sulla tua attività, ti consigliamo di stimare le conseguenze di ogni errore su cui è progettato il modello per ogni modello di errore. Questa comprensione è utile per stabilire le priorità e gli ordini di ripristino, in modo che tu e i tuoi processi approfitti per primi dei componenti più critici.
  • Quanto tempo ti aspetti che durino gli errori nei modelli di errore 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. Nel valutare la durata di un errore, considera anche quanto tempo è necessario per: identificare un errore, riconciliarlo e ripristinare le risorse non caricate.

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 proteggerti, valuti gli archetipi di deployment per determinare cosa si adatta meglio alle tue esigenze. Quando valuti gli archetipi di deployment, poniti le seguenti domande:

  • Quanti archetipi di deployment hai bisogno? Non è necessario scegliere un solo archetipo di architettura per soddisfare tutti i tuoi ambienti. Puoi invece implementare un approccio ibrido in cui scegli più archetipi di deployment in base alle garanzie di affidabilità di cui hai bisogno per proteggerti dai modelli di errore che hai definito. Ad esempio, se hai definito due modelli di errore, uno che richiede un ambiente a livello di zona e uno che richiede un ambiente a livello di regione, potresti voler scegliere archetipi di deployment separati per evitare ogni modello di errore. Se scegli più archetipi di deployment, ti consigliamo di valutare la complessità potenzialmente crescente associata alla progettazione, all'implementazione e al funzionamento di più ambienti.
  • Quante risorse hai bisogno per progettare e implementare ambienti in base agli archetipi di deployment? Progettare e implementare qualsiasi tipo di ambiente richiede risorse e sforzi. Ti consigliamo di valutare quante risorse pensi che avrai bisogno per progettare e implementare ogni ambiente in base all'archetipo scelto. Una volta compreso il numero di risorse necessarie, puoi bilanciare i compromessi tra le garanzie di affidabilità offerte da ogni archetipo di architettura e il costo e la complessità di progettazione, implementazione e gestione degli ambienti in base a questi archetipi.
  • Prevedi di eseguire la migrazione di un ambiente basato su un archetipo di architettura a un ambiente basato su un altro archetipo? In futuro, potresti eseguire la migrazione di carichi di lavoro, dati e processi da un ambiente Google Cloud a un ambiente Google Cloud diverso. Ad esempio, puoi eseguire la migrazione da un ambiente di zona a un ambiente a livello di regione.
  • 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, nonché di progettare un ambiente di zona o di regione per carichi di lavoro, dati e processi meno critici.
  • Hai bisogno delle funzionalità offerte da particolari archetipi architettonici per determinati ambienti? Oltre all'affidabilità offerta da ogni archetipo di architettura, 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 considerare eventuali requisiti non funzionali, come requisiti normativi, di 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 ambienti con una singola regione, devi determinare la regione che meglio si adatta ai requisiti di ogni ambiente. Le seguenti sezioni descrivono queste due categorie di criteri di selezione:

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

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

Valutare i criteri funzionali

Per valutare i criteri funzionali, poniti le seguenti domande:

  • Quali sono i requisiti di prossimità geografica? Quando scegli una regione Google Cloud, potrebbe essere necessario posizionare i carichi di lavoro, i dati e i processi in prossimità degli utenti o dei 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 l'area geografica di Google Cloud più vicina a quell'area. La scelta di una regione Google Cloud che meglio si adatta ai tuoi requisiti di prossimità geografica consente ai tuoi ambienti di garantire una latenza e tempi di reazione inferiori alle richieste dei tuoi utenti e dei tuoi ambienti esterni a Google Cloud. Strumenti come la dashboard di latenza di Google Cloud e strumenti non ufficiali come GCPing e il selettore per la 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 soddisfano i tuoi requisiti, carichi di lavoro, dati e processi.
  • In quali delle regioni in cui vuoi usufruire dei servizi offerti i prodotti di cui hai bisogno? Ti consigliamo di valutare i prodotti disponibili in ogni regione di Google Cloud e quali regioni 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, consulta le località cloud. Inoltre, alcuni prodotti potrebbero non offrire tutte le funzionalità in ogni regione in cui sono disponibili. Ad esempio, le regioni e le zone disponibili per Compute Engine offrono tipi di macchine specifici in regioni specifiche di Google Cloud. Per ulteriori informazioni sulle funzionalità offerte da ogni prodotto in ogni regione, consulta la documentazione del prodotto.
  • Le risorse di cui hai bisogno in ogni regione di 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 all'utilizzo della risorsa ovunque in Google Cloud, mentre altre sono a livello di regione o di zona e si applicano all'utilizzo della risorsa in una regione specifica 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, si applica a livello di regione. Per ulteriori informazioni sulle quote e su come aumentarle, consulta Utilizzo delle quote.

Valutare i criteri non funzionali

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

  • Preferisci un'impronta di carbonio ridotta? Google Cloud investe costantemente in sostenibilità e in energia a zero emissioni di CO2 per le regioni di Google Cloud, oltre a impegnarsi 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 l'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 normative particolari? I governi e le entità nazionali e sovranazionali spesso regolano rigorosamente alcuni mercati e aree di business, come il settore bancario e il settore pubblico. Queste normative potrebbero imperare che carichi di lavoro, dati e processi risiedano solo in determinate aree geografiche. Ad esempio, i tuoi ambienti potrebbero dover rispettare i requisiti di sovranità dei dati, dei software e operativi 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 imminenti quando scegli le regioni di Google Cloud per i tuoi ambienti e di selezionare quelle di Google Cloud più adatte ai tuoi requisiti normativi.

Progettare e creare ambienti a livello di singola regione

Per progettare un ambiente con una singola regione:

  1. Crea le tue basi su Google Cloud.
  2. Esegui il provisioning e la configurazione delle risorse di calcolo.
  3. Esegui 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, tieni in considerazione i seguenti principi di progettazione generali:

  • Esegui il provisioning delle risorse a livello di regione. Molti prodotti Google Cloud supportano il provisioning delle risorse in più zone all'interno di una regione. Ti consigliamo di eseguire il provisioning delle risorse di regione anziché delle risorse di zona, quando possibile. In teoria, potresti essere in grado di eseguire il provisioning delle risorse di zona in più zone di un'area geografica e di gestirle autonomamente per aumentare l'affidabilità. Tuttavia, questa configurazione non godrebbe pienamente di tutte le funzionalità di affidabilità dell'infrastruttura Google alla base dei servizi Google Cloud.
  • Verifica che gli ambienti funzionino come previsto con le ipotesi del modello di errore. Quando progetti e implementi gli ambienti di una 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 promuoverli come parte dell'ambiente di produzione. Ad esempio, puoi simulare le interruzioni a livello di zona per verificare che i tuoi ambienti di una singola regione possano sopravvivere con interruzioni minime.

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

Crea la tua base su Google Cloud

Per creare la base dei tuoi ambienti con una singola regione, consulta Migrazione a Google Cloud: crea la tua base. Le indicazioni contenute in questo documento sono finalizzate a costruire le basi per la migrazione di carichi di lavoro, dati e processi a Google Cloud, ma sono anche applicabili a creare le basi per i tuoi ambienti con un'unica regione. Dopo aver letto il documento, continua a leggerlo.

Dopo aver creato le basi su Google Cloud, progetti e implementi controlli e confini di sicurezza. 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 inoltre a garantire che le risorse non raggiungano altre regioni a causa di bug, configurazioni errate o attacchi dannosi.

Esegui il provisioning e la configurazione delle risorse di calcolo

Dopo aver creato la base dei tuoi ambienti a una singola regione, esegui 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 è il servizio IaaS 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 di Compute Engine sono a livello di zona, ad esempio macchine virtuali o disco permanente a livello di zona, a livello di regione, ad esempio indirizzi IP esterni statici, oppure globali, come gli 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 migliorare la flessibilità e la gestione delle risorse fisiche, Compute Engine disaccoppia le zone dalle risorse fisiche. Per saperne di più su questa astrazione e su cosa potrebbe significare per te, 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 di Compute Engine sono risorse di zona, pertanto non saranno disponibili in caso di interruzione di zona. Per limitare questo problema, Compute Engine consente di creare gruppi di istanze gestite a livello di regione che eseguono automaticamente il provisioning delle macchine virtuali in più zone all'interno di una regione, in base alla domanda e alla disponibilità a livello regionale. Se i carichi di lavoro sono stateful, puoi anche creare MIG stateful a livello di regione per conservare le configurazioni e i dati stateful. I gruppi di istanze gestite a livello di regione supportano la simulazione degli errori a livello di zona. Per informazioni su come simulare un errore a livello di zona quando utilizzi 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 sulle differenze tra i gruppi di istanze gestite a livello di regione e altre opzioni di deployment, consulta Scegliere una strategia di deployment di Compute Engine per il tuo carico di lavoro.
  • Forma di distribuzione di destinazione. I gruppi di istanze gestite a livello di regione distribuiscono le macchine virtuali in base alla forma di distribuzione target. Per assicurarti che la distribuzione delle macchine virtuali non differisca di più di un'unità tra due zone in 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 dei target, consulta la pagina Confronto delle 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 denominato modelli di istanza. Anche se i modelli di istanza sono 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 rispetto alle risorse 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 quel modello in altre zone perché il volume di Persistent Disk non è disponibile in quelle altre 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 supporta 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 di gestione delle soluzioni autogestite, ti consigliamo di configurare il bilanciamento del carico e la scalabilità automatica. Per saperne di più sulla configurazione del bilanciamento del carico e della scalabilità per Compute Engine, consulta Bilanciamento del carico e scalabilità.
  • Configura le prenotazioni di risorse. Per assicurarti 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 Compute Engine a livello di zona. Ad esempio, in caso di interruzione di una 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 di risorse assicurano che tu abbia 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 i nomi DNS di zona per identificare in modo univoco le macchine virtuali che utilizzano nomi DNS nei tuoi ambienti. Per impostazione predefinita, Google Cloud utilizza i nomi DNS di zona per le macchine virtuali di Compute Engine. Per saperne di più sul funzionamento del DNS interno di Compute Engine, consulta DNS interno. Per facilitare la migrazione futura tra regioni e rendere la configurazione più gestibile, ti consigliamo di considerare i nomi DNS di zona come parametri di configurazione che in futuro potrai modificare.
  • Scegliere le opzioni di archiviazione appropriate. Compute Engine supporta diverse opzioni di archiviazione per le tue macchine virtuali, come volumi diPersistent Diski e unità a stato solido (SSD) locali:
    • I volumi dei Persistent Disk sono distribuiti su più dischi fisici e si trovano in modo indipendente dalle 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 un'unica 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 a singola regione, ti consigliamo di scegliere 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à che utilizzano il 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. Di conseguenza, le SSd locali sono ideali per archiviare dati, cache e dati temporanei che puoi ricostruire con altri mezzi. I dischi permanenti sono dispositivi di archiviazione durevoli a cui le VM possono accedere come se fossero dischi fisici.
  • Progettare e implementare meccanismi per la protezione dei dati. Quando progetti i tuoi ambienti con una singola regione, ti consigliamo di predisporre meccanismi automatici per proteggere i tuoi dati in caso di eventi avversi, come errori a livello di zona, di regione o multiregionale, oppure attacchi deliberati di terze parti dannose. Compute Engine offre varie opzioni per proteggere i dati. Puoi utilizzare queste funzionalità delle opzioni di dati come componenti di base per progettare e implementare i processi di protezione dei dati.

GKE

GKE ti aiuta a distribuire, gestire e scalare i carichi di lavoro containerizzati su Kubernetes. GKE si basa su Compute Engine, pertanto i suggerimenti su Compute Engine nella sezione precedente 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 tuoi cluster, a seconda del tipo di cluster necessario. I cluster GKE possono avere un piano di controllo a livello di zona o di regione e possono avere nodi in esecuzione in una singola zona o in più zone all'interno di una regione. Diversi tipi di cluster offrono anche accordi sul livello del servizio (SLA) diversi. Per aumentare l'affidabilità degli ambienti, ti consigliamo di scegliere cluster a livello di regione. Se utilizzi la funzionalità GKE Autopilot, puoi eseguire il provisioning solo di cluster a livello di regione.
  • Valuta un ambiente multi-cluster. Il deployment di più cluster GKE può aumentare la flessibilità e le proprietà di disponibilità del tuo ambiente, a costo di aumentare la complessità. Ad esempio, se devi utilizzare una nuova funzionalità GKE che puoi abilitare 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 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 Migrazione dei container in Google Cloud: migrazione a un ambiente GKE multi-cluster. Per aiutarti a gestire la complessità della migrazione, Google Cloud offre 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 in questi cluster.
  • Configura Backup per GKE. Backup per GKE è un servizio a livello di regione che consente di eseguire il backup della configurazione e dei volumi dei carichi di lavoro in un cluster GKE di origine e di ripristinarli 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 eseguire carichi di lavoro containerizzati. Cloud Run utilizza i servizi per fornirti l'infrastruttura per eseguire i carichi di lavoro. I servizi Cloud Run sono risorse a livello di regione e sono replicati in più zone nella regione in cui si trovano. Quando esegui il deployment di un servizio Cloud Run, puoi scegliere una regione. Poi, Cloud Run sceglie 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 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 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 risiedono 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 cloud privati a nodo singolo, ma consigliamo di utilizzare cloud privati a nodo singolo solo per proof of concept e per scopi di test. Per gli ambienti di produzione, consigliamo di utilizzare i cloud privati multinodo predefiniti.
  • Esegui il provisioning di cloud privati estesi di VMware Engine. Un cloud privato ampliato è un cloud privato multinodo i cui nodi sono distribuiti tra le zone di una regione. Un cloud privato esteso protegge l'ambiente da interruzioni di zona.

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

Esegui il provisioning e la configurazione delle risorse di archiviazione dati

Dopo aver eseguito il provisioning e la configurazione delle risorse di calcolo per i tuoi ambienti di una singola regione, esegui il provisioning e la configurazione delle risorse per archiviare e gestire i dati. Le seguenti sezioni descrivono i prodotti di gestione e archiviazione dei dati di Google Cloud che supportano le configurazioni a livello di una o più regioni.

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à dei bucket più adatto ai tuoi requisiti di disponibilità, normative e altro. I tipi di località hanno garanzie di disponibilità diverse. Per proteggere i tuoi dati da guasti e interruzioni, Cloud Storage rende ridondanti i dati 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 o più regioni e in due o più regioni per i bucket con tipo di località a più regioni. Ad esempio, se hai bisogno di rendere disponibile un bucket Cloud Storage in caso di interruzioni a livello di zona, puoi eseguirne il provisioning con un tipo di località a livello di regione.

Per ulteriori informazioni sulla progettazione di meccanismi di emergenza per i dati archiviati in Cloud Storage e su come Cloud Storage reagisce a interruzioni di zona e regionali, consulta Architettura del ripristino di emergenza per le 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 macchine on-premise. Filestore offre diversi livelli di servizio. Ogni livello offre funzionalità univoche 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 di zona.

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 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 ulteriori informazioni sul funzionamento della replica in Bigtable, consulta Informazioni sulla replica e Architettura del ripristino di emergenza in caso di 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à a livello di regione, replica i dati in diverse zone all'interno di una regione. Un database multiregionale replica i dati in più regioni.

Per informazioni su come funziona la replica in Firestore e su come Firestore reagisce alle interruzioni a livello di zona e regione, consulta le pagine Località Firestore e Architettura del ripristino di emergenza in caso di interruzioni dell'infrastruttura cloud: Firestore.

Memorystore

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

Quando esegui il provisioning di istanze di Memorystore for Redis, selezioni un livello di servizio per l'istanza. Memorystore per Redis supporta diversi livelli di servizio delle istanze e ogni livello offre funzionalità univoche relative a 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 di Memorystore in questi due livelli replicano automaticamente i dati in più zone di una regione. Per maggiori informazioni su come Memorystore for Redis raggiunge l'alta disponibilità, consulta Alta disponibilità per Memorystore for Redis.

Quando esegui il provisioning di istanze di Memorystore for Memcached, considera quanto segue:

  • Selezione della zona. Quando esegui il provisioning delle istanze Memorystore for Memcached, selezioni 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 lasciare che Memorystore per Memcached distribuisca automaticamente i nodi tra le zone. Per posizionare le istanze in modo ottimale ed evitare problemi di provisioning come il posizionamento di tutti i nodi all'interno della stessa zona, ti consigliamo di consentire a Memorystore for Memcached di distribuire automaticamente i nodi tra le zone all'interno di una regione.
  • Replica dei dati tra zone. Le istanze di Memorystore for Memcached non replicano i dati in più 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 la pagina Architettura del ripristino di emergenza per le 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, devi eseguire il provisioning di 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 a livello di una o più regioni.
  • 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 repliche tra regioni e ambienti. Le istanze di Spanner con una configurazione a livello di regione 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 ti consente di spostare un'istanza da qualsiasi configurazione dell'istanza a qualsiasi altra configurazione dell'istanza senza causare tempi di inattività o interruzioni delle garanzie delle transazioni durante lo spostamento.

Per ulteriori informazioni sulla replica di Spanner e su come Spanner reagisce a interruzioni a livello di zona e di regione, consulta Replica di Spanner e Architettura del ripristino di emergenza per le interruzioni dell'infrastruttura cloud: Spanner.

Esegui 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 i tuoi ambienti di una singola regione, esegui il provisioning e la configurazione delle risorse di analisi dei dati. Le seguenti sezioni descrivono i prodotti di analisi dei dati Google Cloud che supportano le configurazioni a livello di regione.

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, esegui il provisioning di container di primo livello chiamati set di dati. Quando esegui il provisioning di un set di dati BigQuery, considera quanto segue:

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

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

Dataproc

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

Per utilizzare Dataproc, devi creare cluster Dataproc. I cluster Dataproc sono risorse a livello 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 oppure lasciare che il posizionamento automatico della zona Dataproc selezioni automaticamente la zona. Ti consigliamo di utilizzare il posizionamento automatico delle zone, a meno che non sia necessario ottimizzare il posizionamento delle zone dei nodi 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 hai bisogno che il cluster sia resiliente ai guasti di un singolo nodo coordinatore o a parziali interruzioni di zona. I cluster Dataproc ad alta disponibilità sono risorse di zona.

Per ulteriori informazioni su come Dataproc reagisce alle interruzioni a livello di zona e regionale e su come aumentare l'affidabilità dei cluster Dataproc in caso di errori, consulta Architettura del ripristino di emergenza in caso di 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 di zona, quando usi le risorse Dataflow, considera 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 posizionamento delle risorse di calcolo e 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, in base al 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 di un'area geografica. Per ridurre i problemi causati da interruzioni a livello di zona, ti consigliamo di consentire a Dataflow di selezionare automaticamente il posizionamento migliore per la zona, a meno che tu non debba posizionare i nodi worker in una zona specifica.

Per ulteriori informazioni su come Dataproc reagisce alle interruzioni di zona e a livello di regione e su come aumentare l'affidabilità dei cluster Dataproc in caso di errori, consulta Architettura del ripristino di emergenza in caso di 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, mentre i sottoscritti ricevono i messaggi dagli argomenti. Pub/Sub archivia ciascun messaggio in un'unica regione e lo replica in almeno due zone all'interno di quella regione. Per ulteriori informazioni, consulta la pagina Panoramica dell'architettura di Pub/Sub.

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

  • Endpoint globali e a livello di regione. Pub/Sub supporta endpoint globali e a livello di regione 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 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 ti consente di configurare criteri di archiviazione dei messaggi per limitare il luogo in cui Pub/Sub elabora e archivia i messaggi, indipendentemente dall'origine della richiesta e dall'endpoint utilizzato dal publisher per pubblicare il messaggio. Ti consigliamo di configurare i criteri di archiviazione dei messaggi per assicurarti che i messaggi non escano dal tuo ambiente a singola regione.

Per ulteriori informazioni su come Pub/Sub gestisce le interruzioni a livello di zona e di regione, consulta Architettura del ripristino di emergenza per le interruzioni dell'infrastruttura cloud: Pub/Sub.

Adatta i carichi di lavoro ad ambienti di una singola regione

Quando completi il provisioning e la configurazione dei tuoi ambienti, devi valutare come rendere i carichi di lavoro più resilienti in caso di errori a livello di zona e di regione. Ogni carico di lavoro può avere i propri requisiti e proprietà di disponibilità e affidabilità, ma esistono alcuni principi di progettazione che puoi applicare e strategie che puoi adottare per migliorare la tua strategia di resilienza complessiva nell'improbabile caso di errori a livello di zona e di regione. Quando progetti e implementi i carichi di lavoro, considera quanto segue:

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

Passaggi successivi

Collaboratori

Autori:

Altri collaboratori:

Accedi a LinkedIn per vedere i profili LinkedIn non pubblici.