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

Last reviewed 2023-12-08 UTC

Questo documento ti aiuta a progettare ambienti resilienti a una sola regione su Google Cloud. Questo documento è utile se stai pianificando la migrazione di un ambiente a singola regione o se stai valutando la possibilità di farlo in futuro e vuoi esplorare le possibili modalità.

Questo documento fa parte di una serie:

Lo scopo di questo documento è fornire indicazioni su come progettare ambienti resilienti monoregione su Google Cloud e si concentra sui seguenti componenti dell'architettura:

Le indicazioni riportate in questo documento presuppongono che tu stia progettando e implementando ambienti monoregione. Se al momento utilizzi un ambiente a regione singola, in futuro potrai eseguire la migrazione a un ambiente multi-regione. Se stai valutando la possibilità di eseguire una migrazione futura ed evolvere i tuoi ambienti zonali e a una sola regione in ambienti multiregione, consulta Eseguire la migrazione tra regioni Google Cloud: inizia.

Proprietà di diversi archetipi di distribuzione

Google Cloud fornisce servizi da diverse regioni in tutto il mondo. Ogni regione è un'area geografica fisicamente indipendente costituita da aree di implementazione chiamate zone. Per ulteriori informazioni sulle regioni e sulle zone di Google Cloud, consulta Geografia e località.

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

  • Archetipo zonale: esegui il provisioning delle risorse Google Cloud in una singola zona all'interno di una regione e utilizzi i servizi zonali se sono disponibili. Se i servizi zonali non sono disponibili, utilizza i servizi regionali.
  • Archetipo a regione singola: esegui il provisioning delle risorse Google Cloud in più zone all'interno di una regione e utilizzi i servizi regionali, se possibile.
  • Archetipo multiregione: esegui il provisioning delle risorse Google Cloud in più zone in regioni diverse. Il provisioning delle risorse di zona viene eseguito in una o più zone in 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 multi-regione ha maggiori probabilità di sopravvivere a un'interruzione regionale rispetto a un ambiente a livello di singola regione o zona. Per ulteriori informazioni sulle proprietà di affidabilità di ciascun archetipo di architettura, consulta Come sfruttare le zone e le regioni per ottenere l'affidabilità e la guida sull'affidabilità dell'infrastruttura di Google Cloud.

La progettazione, l'implementazione e il funzionamento di un ambiente basato su questi arcatipi di implementazione richiedono diversi livelli di impegno a causa delle proprietà di costo e complessità di ciascun arcatipo. Ad esempio, un ambiente zonale potrebbe essere più economico e facile da progettare, implementare e gestire rispetto a un ambiente regionale o multiregionale. L'impegno e il costo potenzialmente inferiori dell'ambiente zonale sono dovuti al sovraccarico aggiuntivo che devi gestire per coordinare i carichi di lavoro, i dati e i processi che si trovano in regioni diverse.

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

Nome dell'archetipo architettonico Distribuzione delle risorse Aiuta a resistere Complessità del design
Ambiente zonale In una singola zona Errori delle risorse Richiede la coordinazione all'interno di una singola zona
Ambiente a regione singola In più zone, in una singola regione Errori delle risorse, interruzioni a livello di zona Richiede il coordinamento di più zone in un'unica regione
Ambiente multi-regione In più zone e in più regioni Errori relativi alle risorse, interruzioni a livello di zona, interruzioni a livello di regione, interruzioni su più regioni Richiede il coordinamento di più zone e più regioni

Scegliere gli archetipi di deployment per gli ambienti

Per scegliere l'archetipo architettonico più adatto alle tue esigenze, procedi come segue:

  1. Definisci i modelli di errore da cui vuoi proteggerti.
  2. Valuta gli archetipi di implementazione per determinare quello più adatto 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 qualsiasi elemento di cui esegui il provisioning o il deployment su Google Cloud. Un modello di errore può essere applicato a un singolo utente oppure a tutte le risorse di un'intera zona o regione. Ti consigliamo di applicare un modello di errore a tutto ciò che ti offre valore, ad esempio 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 del tuo ambiente potrebbe avere i propri obiettivi del livello di servizio (SLO) che definiscono i livelli di servizio accettabili per quel componente e i propri requisiti di ripristino di emergenza. Ad esempio, lo SLA di Compute Engine indica che, se devi raggiungere più del 99,5% di uptime mensile, devi eseguire il provisioning delle istanze in più zone di 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 resilienza più forte, di solito devi impegnare più impegno e risorse. Quando definisci i modelli di errore, ti consigliamo di prendere in considerazione un approccio in cui definisci 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 solitamente devono offrire un'affidabilità maggiore, anche se potrebbe essere accettabile offrire garanzie di affidabilità inferiori per altri carichi di lavoro meno critici.
  • Quante risorse sono necessarie ai modelli di errore per proteggersi dagli errori? Per proteggerti dai modelli di errore che hai definito, devi investire risorse come il tempo e il costo necessari per far sì che le persone progettino, eseguino il provisioning e configurino meccanismi di protezione e procedure automatiche. Ti consigliamo di valutare quante risorse ti servono per difenderti da ogni modello di errore che definisci.
  • Come rileverai che si sta verificando un errore? È fondamentale poter rilevare che si sta verificando o sta per verificarsi un errore in modo da poter avviare le procedure di mitigazione, recupero e riconciliazione. Ad esempio, puoi configurare Google Cloud Observability per ricevere avvisi in caso di prestazioni inferiori.
  • Come puoi testare i modelli di errore che stai definendo? Quando definisci i modelli di errore, ti consigliamo di pensare a come effettuare test continui su ogni modello per verificare che protegga efficacemente dagli errori a cui sono destinati. Ad esempio, puoi iniettare errori nei tuoi ambienti oppure, per valutare la capacità dei tuoi ambienti di tolterare gli errori, puoi adottare la tecnica del caos.
  • Quale impatto prevedi 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 per cui è progettato il modello per ogni modello di errore. Questa conoscenza è utile per stabilire le priorità e l'ordine di recupero in modo che tu e le tue procedure gestiscano per primi i componenti più critici.
  • Per quanto tempo prevedi che i guasti durino nei modelli di errore che stai definendo? La durata di un errore può influire notevolmente sui piani di mitigazione e di recupero. Pertanto, quando definisci i modelli di errore, ti consigliamo di tenere conto del tempo di durata di un errore. Quando valuti la durata di un errore, tieni conto anche del tempo necessario per identificare l'errore, riconciliare l'errore e ripristinare le risorse che non sono riuscite.

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

Valutare gli archetipi di deployment

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

  • Di quanti archetipi di deployment hai bisogno? Non devi scegliere un solo archetipo architettonico adatto a tutti i tuoi ambienti. In alternativa, puoi implementare un approccio ibrido in cui scegli più arcatipi di implementazione 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 zonale e uno che richiede un ambiente regionale, ti consigliamo di scegliere archetipi di deployment separati per proteggerti da ciascun modello di errore. Se scegli più archetipi di deployment, ti consigliamo di valutare la complessità potenzialmente crescente della progettazione, dell'implementazione e del funzionamento di più ambienti.
  • Quante risorse ti occorrono per progettare e implementare ambienti basati sugli archetipi di deployment? La progettazione e l'implementazione di qualsiasi tipo di ambiente richiedono risorse e impegno. Ti consigliamo di valutare quante risorse ritieni di dover utilizzare per progettare e implementare ogni ambiente in base all'archetipo scelto. Quando hai acquisito una conoscenza completa del numero di risorse di cui hai bisogno, puoi bilanciare i compromessi tra le garanzie di affidabilità offerte da ogni archetipo di architettura e il costo e la complessità della progettazione, dell'implementazione e del funzionamento degli ambienti in base a questi archetipi.
  • Pensi di eseguire la migrazione di un ambiente basato su un archetipo architettonico 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. Ad esempio, puoi eseguire la migrazione da un ambiente zonale a uno regionale.
  • Quanto sono fondamentali per l'attività gli ambienti che stai progettando e implementando? Gli ambienti critici per l'attività probabilmente richiedono maggiori garanzie di affidabilità. Ad esempio, puoi scegliere di progettare e implementare un ambiente multi-regione per carichi di lavoro, dati e processi aziendali critici e progettare un ambiente zonale o regionale per carichi di lavoro, dati e processi meno critici.
  • Hai bisogno delle funzionalità offerte da determinati archetipi di architettura per determinati ambienti? Oltre alle garanzie di affidabilità offerte 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 dei modi di guasto che hai definito seguendo le indicazioni precedenti, ti consigliamo di prendere in considerazione eventuali requisiti non funzionali, come quelli normativi, relativi alla località e alla sovranità. Questi requisiti possono limitare le opzioni a tua disposizione. Ad esempio, se devi soddisfare requisiti normativi che richiedono l'utilizzo di una regione specifica, devi progettare e implementare un ambiente a singola regione o un ambiente zonale in quella regione.

Scegli una regione Google Cloud per il tuo ambiente

Quando inizi a progettare gli ambienti a una sola regione, devi determinare la regione che soddisfa al meglio i requisiti di ciascun ambiente. Le sezioni seguenti 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 esterni a Google Cloud. Ad esempio, se i tuoi carichi di lavoro e i tuoi dati hanno requisiti di latenza per gli utenti o altri ambienti esterni a Google Cloud, potresti dover scegliere la regione più vicina agli utenti o ad altri ambienti per ridurre al minimo la latenza.
  • Criteri non funzionali. Questi criteri riguardano i prezzi dei prodotti associati a regioni specifiche, requisiti relativi all'impronta di carbonio e requisiti e normative obbligatori vigenti per la tua attività. Ad esempio, i mercati altamente regolamentati come il settore bancario e pubblico hanno requisiti molto rigorosi e specifici in merito alla località dei dati e dei carichi di lavoro e alla modalità di condivisione dell'infrastruttura del provider cloud con altri clienti.

Se scegli una determinata regione Google Cloud ora, in futuro potrai eseguire la migrazione a regioni diverse o a un ambiente multiregione. Se stai valutando una migrazione futura in 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 requisiti di prossimità geografica? Quando scegli una regione Google Cloud, potresti dover posizionare i tuoi carichi di lavoro, i tuoi dati e le tue procedure vicino ai tuoi utenti o ai tuoi ambienti esterni a Google Cloud, ad esempio gli ambienti on-premise. Ad esempio, se scegli come target una base di 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 che meglio si adatti ai tuoi requisiti di prossimità geografica consente ai tuoi ambienti di garantire una latenza e tempi di reazione inferiori alle richieste degli utenti e degli ambienti esterni a Google Cloud. Strumenti come la dashboard della latenza di Google Cloud e strumenti non ufficiali come GCPing e lo strumento per la selezione della regione Google Cloud possono darti un'idea generale delle caratteristiche di latenza delle regioni Google Cloud. Tuttavia, ti consigliamo di eseguire una valutazione completa per valutare se le proprietà di latenza sono adatte ai tuoi requisiti, carichi di lavoro, dati e processi.
  • Quale delle regioni che vuoi utilizzare offre i prodotti di cui hai bisogno? Ti consigliamo di valutare i prodotti disponibili in ogni regione Google Cloud e le regioni che forniscono i servizi di cui hai bisogno 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à di 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 determinate regioni 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 una risorsa Google Cloud condivisa che puoi utilizzare. Alcune quote sono globali e si applicano all'utilizzo della risorsa in qualsiasi punto di Google Cloud, mentre altre sono regionali o zonali e si applicano all'utilizzo della risorsa in una regione Google Cloud specifica. Ad esempio, la maggior parte delle quote di utilizzo delle risorse Compute Engine, come il numero di macchine virtuali che puoi creare, è regionale. Per ulteriori informazioni sulle quote e su come aumentarle, consulta Utilizzo delle quote.

Valutare i criteri non funzionali

Per valutare i criteri non funzionali, prendi in considerazione le seguenti domande:

  • Preferisci un'impronta di carbonio ridotta? Google Cloud investe continuamente in sostenibilità ed energia a zero emissioni di CO2 per le regioni Google Cloud e si è impegnato a utilizzare energia a zero emissioni di CO2 per tutte le regioni cloud. Le regioni Google Cloud hanno un impatto ambientale diverso. 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 località, consulta Energia a zero emissioni di CO2 per le regioni Google Cloud.
  • I tuoi ambienti devono rispettare normative particolari? I governi e le persone giuridiche nazionali e sovranazionali spesso regolamentano rigorosamente alcuni mercati e aree di attività, come il settore bancario e pubblico. Questi regolamenti potrebbero prevedere che i carichi di lavoro, i dati e i processi si trovino solo in determinate regioni geografiche. Ad esempio, i tuoi ambienti potrebbero dover essere conformi ai requisiti di sovranità dei dati, operativi e del software per garantire determinati livelli di controllo e trasparenza per i dati sensibili e i workload in esecuzione nel cloud. Ti consigliamo di valutare i requisiti normativi attuali e futuri quando scegli le regioni Google Cloud per i tuoi ambienti e di selezionare quelle più adatte alle tue esigenze.

Progetta e crea i tuoi ambienti a singola regione

Per progettare un ambiente a una sola regione:

  1. Crea la tua base su Google Cloud.
  2. Esegui il provisioning e configura le risorse di calcolo.
  3. Esegui il provisioning e configura le risorse di archiviazione dei dati.
  4. Esegui il provisioning e configura le risorse di analisi dei dati.

Quando progetti il tuo ambiente, tieni conto dei seguenti principi di progettazione generale:

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

Per principi di progettazione più generali per la progettazione di ambienti affidabili monoregione e multiregione e per informazioni su come Google ottiene una maggiore affidabilità con i servizi regionali e multiregione, consulta Architecting ripristino di emergenza for cloud infrastructure outages: Common themes.

Crea la tua base su Google Cloud

Per creare le basi dei tuoi ambienti a una sola regione, consulta Eseguire la migrazione a Google Cloud: pianificare e creare le basi. Le indicazioni riportate nel documento hanno lo scopo di creare le basi per la migrazione di carichi di lavoro, dati e processi a Google Cloud, ma sono applicabili anche per creare le basi per gli ambienti a singola regione. Dopo aver letto questo documento, continua a leggere questo documento.

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

Esegui il provisioning e la configurazione delle risorse di calcolo

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

Compute Engine

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

Le risorse Compute Engine sono di zona, ad esempio macchine virtuali o dischi permanenti a livello di zona; regionali, ad esempio indirizzi IP esterni statici; o globali, ad esempio snapshot dei dischi permanenti. Per saperne di più sulle risorse di zona, regionali e globali supportate da Compute Engine, consulta Risorse di aree geografiche, zone e globali.

Per consentire una maggiore flessibilità e gestione delle risorse fisiche, Compute Engine disaccoppia le zone dalle relative risorse fisiche. Per ulteriori informazioni su questa astrazione e su cosa potrebbe comportare per te, consulta Zone e cluster.

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

  • Gruppi di istanze gestite a livello di regione. Le macchine virtuali Compute Engine sono risorse di zona, pertanto non saranno disponibili in caso di interruzione di servizio a livello di zona. Per mitigare questo problema, Compute Engine consente di creare gruppi di istanze gestite a livello di regione che eseguono il provisioning automatico delle macchine virtuali in più zone di una regione in base alla domanda e alla disponibilità a livello di regione. Se i tuoi carichi di lavoro sono stateful, puoi anche creare MIG stateful regionali per conservare i dati e le configurazioni stateful. I MIG a livello di area geografica supportano la simulazione di 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 servizio in una zona per un gruppo di istanze gestite a livello di regione. Per informazioni sul confronto 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 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 di destinazione. Per assicurarti che la distribuzione delle VM non differisca di più di un'unità tra due zone di una regione, ti consigliamo di scegliere la forma di distribuzione EVEN quando crei i gruppi di istanze gestite a livello di regione. Per informazioni sulle differenze tra le forme di distribuzione target, consulta Confronto delle forme.
  • Modelli di istanza. Per definire le macchine virtuali da 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 regionali o di zona. Quando crei modelli di istanze, ti consigliamo di fare riferimento alle risorse regionali anziché a quelle zonali, se possibile. Se utilizzi risorse zonali, ti consigliamo di valutare l'impatto del loro utilizzo. Ad esempio, se crei un modello di istanza che fa riferimento a un volume del Persistent Disk disponibile solo in una determinata zona, non puoi utilizzarlo in altre zone perché il volume del Persistent Disk non è disponibile in queste altre zone.
  • Configura il bilanciamento del carico e la scalabilità. Compute Engine supporta il bilanciamento del carico del traffico tra le 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 di gestione delle soluzioni self-managed, ti consigliamo di configurare il bilanciamento del carico e l'autoscaling. 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 assicurarti che i tuoi ambienti abbiano le risorse necessarie quando ti servono, ti consigliamo di configurare le prenotazioni delle risorse per avere la certezza di ottenere la capacità per le risorse Compute Engine di zona. Ad esempio, se si verifica un'interruzione di servizio a livello di zona, potresti dover eseguire il provisioning di macchine virtuali in un'altra zona per fornire la capacità necessaria per compensare quelle non disponibili a causa dell'interruzione. Le prenotazioni delle risorse ti assicurano di avere le risorse disponibili per eseguire il provisioning delle macchine virtuali aggiuntive.
  • Utilizza nomi DNS di zona. Per ridurre il rischio di interruzioni tra regioni, ti consigliamo di utilizzare nomi DNS di zona per identificare in modo univoco le macchine virtuali che utilizzano nomi DNS nei tuoi ambienti. Google Cloud utilizza per impostazione predefinita i nomi DNS zonali per le macchine virtuali Compute Engine. Per ulteriori informazioni sul funzionamento del DNS interno di Compute Engine, consulta DNS interno. Per facilitare una futura migrazione tra regioni e per rendere la configurazione più gestibile, ti consigliamo di considerare i nomi DNS zonali come parametri di configurazione che potrai eventualmente modificare in futuro.
  • Scegli le opzioni di archiviazione appropriate. Compute Engine supporta diverse opzioni di archiviazione per le tue macchine virtuali, ad esempio volumi su Persistent Disk e unità a stato solido (SSD) locali:
    • I volumi Persistent Disk sono distribuiti su più dischi fisici e si trovano indipendentemente 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 regionali li replicano in due zone diverse. Quando scegli le opzioni di archiviazione per i tuoi ambienti a una singola regione, ti consigliamo di scegliere i dischi permanenti regionali perché offrono opzioni di failover in caso di guasti zonali. Per ulteriori informazioni su come reagire ai guasti zonali quando utilizzi i dischi permanenti regionali, consulta Opzioni di alta disponibilità che utilizzano i dischi permanenti regionali e Failover dei dischi permanenti regionali.
    • Le unità SSD locali hanno un'elevata velocità effettiva, ma archiviano i dati solo fino a quando un'istanza non viene interrotta o eliminata. Pertanto, le unità SSD locali sono ideali per archiviare dati temporanei, cache e dati che puoi ricostruire con altri mezzi. I dischi permanenti sono dispositivi di archiviazione durevoli a cui le macchine virtuali possono accedere come se si trattasse di dischi fisici.
  • Progettare e implementare meccanismi per la protezione dei dati. Quando progetti i tuoi ambienti a singola regione, ti consigliamo di implementare meccanismi automatici per proteggere i tuoi dati in caso di eventi avversi, come errori zonali, regionali o multiregionali o attacchi deliberati da parte di terze parti malintenzionate. Compute Engine fornisce diverse opzioni per proteggere i tuoi dati. Puoi utilizzare queste funzionalità di opzioni di dati come elementi costitutivi per progettare e implementare le tue procedure di protezione dei dati.

GKE

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

Per aumentare l'affidabilità dei tuoi ambienti che utilizzano GKE, tieni presenti i seguenti punti di progettazione e le 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 di cui hai bisogno. 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. I diversi tipi di cluster offrono anche diversi contratti di livello di servizio (SLA). Per aumentare l'affidabilità dei tuoi ambienti, ti consigliamo di scegliere cluster regionali. Se utilizzi la funzionalità GKE Autopilot, puoi eseguire il provisioning solo dei cluster regionali.
  • Valuta la possibilità di utilizzare un ambiente multicluster. Il deployment di più cluster GKE può aumentare la flessibilità e le proprietà di disponibilità del tuo ambiente, a costo di una maggiore complessità. Ad esempio, se devi utilizzare una nuova funzionalità GKE che puoi attivare solo quando crei un cluster GKE, puoi evitare i tempi di riposo e ridurre la complessità della migrazione aggiungendo un nuovo cluster GKE al tuo ambiente multi-cluster, eseguendo il deployment dei workload nel nuovo cluster e distruggendo il vecchio cluster. Per maggiori informazioni sui vantaggi di un ambiente GKE multi-cluster, consulta Casi d'uso multi-cluster. Per aiutarti a gestire la complessità della migrazione, Google Cloud offre Fleet Management, un insieme di funzionalità per gestire un gruppo di cluster GKE, la relativa infrastruttura e i carichi di lavoro di cui è stato eseguito il deployment in questi cluster.
  • Configura Backup per GKE. Backup per GKE è un servizio regionale per eseguire il backup della configurazione dei carichi di lavoro e dei volumi in un cluster GKE di origine e ripristinarli in un cluster GKE di destinazione. Per proteggere la configurazione e i dati dei carichi di lavoro da possibili perdite, ti consigliamo di attivare e configurare Backup per GKE. Per ulteriori informazioni, consulta la panoramica di Backup per GKE.

Cloud Run

Cloud Run è una piattaforma di calcolo gestita per l'esecuzione di carichi di lavoro containerizzati. Cloud Run utilizza i servizi per fornirti l'infrastruttura necessaria per eseguire i tuoi carichi di lavoro. I servizi Cloud Run sono risorse regionali e vengono replicati in più zone della regione in cui si trovano. Quando esegui il deployment di un servizio Cloud Run, puoi scegliere una regione. 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 attenuare notevolmente gli effetti di un'interruzione di servizio a livello di zona.

VMware Engine

VMware Engine è un servizio completamente gestito che ti consente di eseguire la piattaforma VMware in Google Cloud. Per aumentare l'affidabilità dei tuoi ambienti che utilizzano VMware Engine, 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 si trovano nella stessa regione. I nodi del cloud privato vengono eseguiti su nodi hardware bare metal dedicati e isolati e sono configurati per eliminare i single point of failure. VMware Engine supporta i cloud privati a nodo singolo, ma consigliamo di utilizzarli solo per prove di concetto e scopi di test. Per gli ambienti di produzione, ti consigliamo di utilizzare i cloud privati multi-nodo predefiniti.
  • Esegui il provisioning di cloud privati estesi VMware Engine. Un cloud privato ampliato è un cloud privato multi-nodo i cui nodi sono distribuiti tra le zone in una regione. Un cloud privato esteso protegge il tuo ambiente dalle interruzioni zonali.

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

Esegui il provisioning e configura le risorse di archiviazione dei dati

Dopo aver eseguito il provisioning e la configurazione delle risorse di calcolo per gli ambienti con una sola 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 configurazioni regionali e multiregionali.

Cloud Storage

Cloud Storage è un servizio per archiviare oggetti, ovvero elementi di dati immutabili, in bucket, ovvero contenitori di base per contenere i dati. Quando crei un bucket, seleziona il tipo di posizione del bucket che soddisfa al meglio i tuoi requisiti di disponibilità, normativi e di altro tipo. I tipi di località hanno garanzie di disponibilità diverse. Per proteggere i dati da guasti e interruzioni, Cloud Storage rende i dati ridondanti in almeno due zone per i bucket con un tipo di località regionale, 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à di più regioni. Ad esempio, se devi rendere disponibile un bucket Cloud Storage in caso di interruzioni di servizio zonali, puoi eseguirne il provisioning con un tipo di località di regione.

Per ulteriori informazioni su come progettare meccanismi di risposta agli incidenti per i dati archiviati in Cloud Storage e su come Cloud Storage reagisce alle interruzioni zonali e regionali, consulta Architecting disaster recovery for cloud infrastructure outages: Cloud Storage (Architettare il disaster recovery per le interruzioni dell'infrastruttura cloud: Cloud Storage).

Filestore

Filestore fornisce file server completamente gestiti su Google Cloud che possono essere collegati alle istanze Compute Engine, ai cluster GKE e alle tue macchine on-premise. Filestore offre diversi livelli di servizio. Ogni livello offre disponibilità, scalabilità, prestazioni, capacità e funzionalità di recupero dei dati uniche. Quando esegui il provisioning delle istanze Filestore, consigliamo di scegliere il livello Enterprise perché supporta la disponibilità elevata e la redundanza dei dati in più zone di una regione. Le istanze di altri livelli sono risorse zonali.

Bigtable

Bigtable è un servizio di database completamente gestito, ad alte prestazioni e ad alta scalabilità per carichi di lavoro analitici e operativi di grandi dimensioni. Le istanze Bigtable sono risorse a livello di zona. Per aumentare l'affidabilità delle tue istanze, puoi configurare Bigtable in modo da replicare i dati in più zone all'interno della stessa regione o in più regioni. Quando la replica è attiva, in caso di interruzione del servizio, Bigtable rifiuta automaticamente le richieste alle altre istanze disponibili in cui hai replicato i dati.

Per ulteriori informazioni sul funzionamento della replica in Bigtable, consulta Informazioni sulla replica e Architettare il ripristino di emergenza per le interruzioni dell'infrastruttura cloud: Bigtable.

Firestore

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

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

Memorystore

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

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

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

  • Selezione della zona. Quando esegui il provisioning 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 lasciare che Memorystore per Memcached distribuisca automaticamente i nodi nelle zone. Per posizionare in modo ottimale le istanze ed evitare problemi di provisioning come il posizionamento di tutti i nodi all'interno della stessa zona, ti consigliamo di lasciare che Memorystore per Memcached distribuisca automaticamente i nodi nelle zone all'interno di una regione.
  • Replica dei dati tra zone. Le istanze di Memorystore for Memcached non replicano i dati tra zone o regioni. Per ulteriori informazioni sul funzionamento delle istanze Memorystore for Memcached in caso di interruzioni zonali o regionali, consulta Architettare il 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, esegui il provisioning delle istanze Spanner. Quando esegui il provisioning delle istanze Spanner, tieni presente quanto segue:

  • Configurazione dell'istanza. Una configurazione dell'istanza definisce il posizionamento geografico e la replica dei database in un' istanza Spanner. Quando crei un'istanza Spanner, la configurerai come regionale o multiregionale.
  • Replica. Spanner supporta la replica automatica a livello di byte e la creazione di repliche in base alle tue esigenze di disponibilità, affidabilità e scalabilità. Puoi distribuire le repliche in regioni ed ambienti. Le istanze Spanner con una configurazione a livello di regione gestiscono 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 in più regioni.
  • Spostamento delle istanze. Spanner ti consente di spostare un'istanza da una configurazione a un'altra senza causare tempi di inattività o interruzioni delle garanzie delle transazioni durante lo spostamento.

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

Esegui il provisioning e configura le risorse di analisi dei dati

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

BigQuery

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

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

  • Posizione del set di dati. Per selezionare la località BigQuery in cui vuoi archiviare i dati, configura la posizione del set di dati. Una località può essere regionale o multiregionale. Per entrambi i tipi di località, BigQuery archivia copie dei dati in due zone diverse all'interno della località selezionata. Non puoi modificare la posizione del set di dati dopo la sua creazione.
  • Pianificazione in caso di emergenza. BigQuery è un servizio regionale e gestisce automaticamente gli errori zonali per l'elaborazione e i dati. Tuttavia, ci sono alcuni scenari che devi pianificare autonomamente, 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à di ripristino di emergenza di BigQuery, consulta Informazioni sull'affidabilità: pianificazione dei disastri nella documentazione di BigQuery e Architettare ripristino di emergenza per le interruzioni dell'infrastruttura cloud: BigQuery.

Dataproc

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

Per utilizzare Dataproc, crei cluster Dataproc. I cluster Dataproc sono risorse zonali. Quando crei cluster Dataproc, tieni presente quanto segue:

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

Per saperne di più su come Dataproc reagisce alle interruzioni zonali e regionali e su come aumentare l'affidabilità dei cluster Dataproc in caso di errori, consulta Architettare il ripristino di emergenza per le 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, crei pipeline Dataflow, e poi Dataflow esegue i job, che sono istanze di queste pipeline, sui nodi worker. Poiché i job sono risorse zonali, quando utilizzi le risorse Dataflow, devi considerare quanto segue:

  • Endpoint regionali. Quando crei un job, Dataflow richiede di configurare un endpoint a livello di area geografica. Se configuri un endpoint a livello di area geografica per il tuo job, limiti il posizionamento delle risorse di calcolo e dati a una determinata regione.
  • Posizionamento zonale. Dataflow distribuisce automaticamente i nodi worker in tutte le zone di una regione o nella migliore zona di una regione, in base al tipo di job. Dataflow consente di ignorare il posizionamento zonale dei nodi worker inserendo tutti i nodi worker nella stessa zona all'interno di una regione. Per ridurre i problemi causati da interruzioni zonali, ti consigliamo di lasciare che sia Dataflow a selezionare automaticamente la zona migliore, a meno che tu non debba posizionare i nodi worker in una zona specifica.

Per saperne di più su come Dataproc reagisce alle interruzioni zonali e regionali e su come aumentare l'affidabilità dei cluster Dataproc in caso di errori, consulta Architettare il ripristino di emergenza per le 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 gli abbonati li ricevono. Pub/Sub archivia ogni messaggio in un'unica regione e lo replica in almeno due zone all'interno della regione. Per ulteriori informazioni, consulta la Panoramica dell'architettura di Pub/Sub.

Quando configuri l'ambiente Pub/Sub, tieni conto di quanto segue:

  • Endpoint globali e regionali. Pub/Sub supporta endpoint globali e regionali per pubblicare messaggi. Quando un publisher invia un messaggio all'endpoint globale, Pub/Sub seleziona automaticamente la regione più vicina per elaborare il messaggio. Quando un publisher invia un messaggio a un endpoint regionale, Pub/Sub lo elabora in quella regione.
  • Criteri di archiviazione dei messaggi. Pub/Sub ti consente di configurare criteri di archiviazione dei messaggi per limitare dove 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 non escano dall'ambiente con una sola regione.

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

Adatta i tuoi carichi di lavoro a ambienti monoregione

Quando completi il provisioning e la configurazione degli ambienti, devi valutare come rendere i tuoi workload più resilienti ai guasti regionali e zonali. Ogni carico di lavoro può avere requisiti e proprietà di disponibilità e affidabilità propri, ma esistono alcuni principi di progettazione che puoi applicare e strategie che puoi adottare per migliorare la tua postura di resilienza complessiva nell'improbabile evento di guasti zonali e regionali. Quando progetti e implementi i carichi di lavoro, tieni presente quanto segue:

  • Implementa le pratiche e i principi di Site Reliability Engineering (SRE). L'Automation e il monitoraggio completo fanno parte dei principi fondamentali dell'SRE. Google Cloud fornisce gli strumenti e i servizi professionali per implementare SRE per aumentare la resilienza e l'affidabilità dei tuoi ambienti e per ridurre il lavoro manuale.
  • Progettare per la scalabilità e la resilienza. Quando progetti carichi di lavoro destinati a ambienti cloud, ti consigliamo di considerare la scalabilità e la resilienza come requisiti inerenti che i tuoi carichi di lavoro devono rispettare. Per ulteriori informazioni su questo tipo di progettazione, consulta Pattern per app scalabili e resilienti.
  • Progetta per il recupero dalle 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 guasto zonale o regionale, ti consigliamo di progettare i tuoi carichi di lavoro in modo che siano resilienti ai guasti zonali e regionali.
  • Implementa la perdita di carico e la riduzione controllata. Se si verificano errori nell'infrastruttura cloud o in altre dipendenze dei tuoi carichi di lavoro, ti consigliamo di progettarli in modo che siano resilienti. I carichi di lavoro devono mantenere livelli di funzionalità determinati e ben definiti anche in caso di errori (degradamento graduale) e devono essere in grado di ridurre una parte del carico man mano che si avvicinano a condizioni di sovraccarico (shedding del carico).
  • Pianifica la manutenzione regolare. Quando progetti le procedure di implementazione e le procedure operative, ti consigliamo di prendere in considerazione anche tutte le attività che devi svolgere 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 relative dipendenze e in che modo 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 di sviluppo basato sui test. Quando progetti i carichi di lavoro, ti consigliamo di adottare un approccio di sviluppo basato sui test per assicurarti che si comportino come previsto da tutti i punti di vista. Ad esempio, puoi verificare se i tuoi carichi di lavoro e l'infrastruttura cloud soddisfano i requisiti funzionali, non funzionali e di sicurezza di cui hai bisogno.

Passaggi successivi

Collaboratori

Autore: Marco Ferrari | Cloud Solutions Architect

Altri collaboratori: