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

Last reviewed 2023-12-08 UTC

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

Questo documento fa parte di una serie:

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

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

Proprietà dei diversi archetipi di deployment

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

Quando progetti il tuo ambiente Google Cloud, puoi scegliere tra secondo archetipi di deployment, presentati in ordine di crescente affidabilità e costi operativi generali:

  • 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 disponibili. Se i servizi di zona non sono disponibili, puoi usare i servizi regionali.
  • Archetipo a regione singola: esegui il provisioning di Google Cloud in più zone all'interno di una regione e utilizzi i servizi regionali quando possibile.
  • Archetipo multiregionale: esegui il provisioning delle risorse Google Cloud in più zone su regioni diverse. È stato eseguito il provisioning delle risorse di zona in una o più zone di ogni regione.

Gli archetipi di deployment precedenti hanno diverse proprietà di affidabilità, e puoi utilizzarli per fornire le garanzie di affidabilità che il tuo ambiente e alle esigenze aziendali. Ad esempio, un ambiente multiregionale ha maggiori probabilità di sopravvivere a un a livello di regione rispetto a un ambiente a singola regione o a livello di zona. Per maggiori informazioni informazioni sulle proprietà di affidabilità di ciascun archetipo architettonico, vedi Come sfruttare zone e regioni per ottenere affidabilità e ai Guida all'affidabilità dell'infrastruttura Google Cloud.

Progettare, implementare e gestire un ambiente in base a questi degli archetipi di deployment richiede diversi livelli di sforzo a causa dei costi e le proprietà della complessità di ogni archetipo. Ad esempio, un ambiente di zona più economico e semplice da progettare, implementare e gestire rispetto a un o un ambiente multiregionale. L'impegno e il costo potenzialmente inferiori a livello di zona è dovuto all'overhead aggiuntivo che devi gestire per coordinare carichi di lavoro, dati e processi che risiedono in regioni diverse.

La tabella seguente riassume la distribuzione delle risorse, l'affidabilità proprietà e la complessità di ciascun archetipo architettonico. Inoltre, descrive l'impegno necessario per progettare e implementare un ambiente basate su ciascuna.

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

Scegli gli archetipi di deployment per i tuoi ambienti

Per scegliere l'archetipo architettonico più adatto alle tue esigenze, esegui le seguenti:

  1. Definisci i modelli di errore da cui eseguire la protezione.
  2. Valutare gli archetipi di deployment per determinare cosa si adatta meglio le 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? Errore possono essere applicati a tutto ciò di cui esegui il provisioning o il deployment in Google Cloud. Un modello di errore può essere applicato a un individuo e applicare un modello di errore a tutte le risorse di un'intera zona o regione. Me di applicare un modello di errore a tutto ciò che ti fornisce come carichi di lavoro, dati, processi e qualsiasi risorsa.
  • Quali sono l'alta disponibilità, la continuità aziendale e le emergenze di ripristino per questi componenti? Ogni componente del tuo potrebbe avere le sue obiettivi del livello di servizio (SLO) che definiscono i livelli di servizio accettabili per quel componente e i propri per il ripristino di emergenza. Ad esempio, SLA (accordo sul livello del servizio) di Compute Engine indica che se devi raggiungere più del 99,5% del tempo di attività mensile, devi eseguire il provisioning delle istanze in più zone all'interno di una singola regione. Per ulteriori informazioni, consulta Guida alla pianificazione del ripristino di emergenza.
  • Quanti modelli di errore devi definire? In un tipico non tutti i componenti devono offrire la stessa garantiti. Se offri garanzie per tempi di attività più elevati resilienza, in genere si devono dedicare più risorse e sforzi. Quando definire i modelli di errore, consigliamo di utilizzare un approccio in cui definisci più modelli di errore per ogni componente e non solo una per tutti i componenti. Ad esempio, carichi di lavoro critici per l'attività di solito devono offrire un'affidabilità maggiore, sebbene possa essere accettabile offrono garanzie di affidabilità minori per altri carichi di lavoro meno critici.
  • Quante risorse hanno bisogno i modelli di errore per proteggere dagli errori? Per proteggerti dai modelli di errore che hai definito, spendere risorse come il tempo e il costo necessari alle persone per progettare, eseguire il provisioning e configurare meccanismi di protezione e strumenti automatizzati i processi di machine learning. Ti consigliamo di valutare quante risorse hai bisogno per ogni modello di errore che definisci.
  • Come viene rilevato un errore? Essere in grado di rilevare che un errore è già in corso o sta per verificarsi è fondamentale per di poter avviare processi di mitigazione, recupero e riconciliazione. Per Ad esempio, puoi configurare Osservabilità di Google Cloud per avvisarti di prestazioni ridotte.
  • Come puoi testare i modelli di errore che stai definendo? Quando definire i modelli di errore, consigliamo di pensare a come testare continuamente ogni modello per verificare che sia efficace gli errori a cui sono rivolti i modelli. Ad esempio, puoi inserisci guasti nei tuoi ambienti o per valutare la capacità degli ambienti degli errori tollerati, puoi adottare ingegneria del caos.
  • Quale sarà l'impatto previsto se si verifica un particolare modello di errore? Per comprendere l'impatto che un errore potrebbe avere sui tuoi Per ogni modello di errore, consigliamo di stimare le conseguenze di ogni errore in base al quale è progettato il modello. Questo la comprensione è utile per stabilire priorità e ordini di ripristino in modo che tu e i tuoi processi possiate affrontare per primi i componenti più importanti.
  • Quanto tempo ti aspetti che durino gli errori nei modelli di errore che stai definendo? La durata di un errore può influire notevolmente sulla mitigazione e piani di ripristino. Pertanto, quando definisci i modelli di errore, ti consigliamo che devi tenere conto di quanto tempo può durare un errore. Quando si considerano quanto può durare un errore, valuta anche quanto tempo impiega a: identificare un errore, riconciliare l'errore e ripristinare le risorse che non è riuscito.

Per ulteriori considerazioni sui modelli di errore e su come progettare una di ripristino di emergenza, 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, valutare gli archetipi di deployment per determinare quale risponde e alle esigenze aziendali. Quando valuti gli archetipi di deployment, considera quanto segue domande:

  • Quanti archetipi di deployment ti servono? Non è necessario scegli un solo archetipo architettonico adatto a tutti i tuoi ambienti. È invece possibile implementare un approccio ibrido in cui scegliere più degli archetipi del deployment in base all'affidabilità garantisce necessarie per proteggersi 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 una che richiede un ambiente regionale, ti consigliamo di archetipi di deployment separati per proteggersi da ogni modello di errore. Se di scegliere più archetipi di deployment, ti consigliamo di valutare la complessità potenzialmente crescente della progettazione, dell'implementazione e gestire diversi ambienti.
  • Di quante risorse hai bisogno per progettare e implementare ambienti in base agli archetipi di deployment? Progettare e implementare qualsiasi ambiente richiede risorse e sforzi. Ti consigliamo di valuta quante risorse pensi di aver bisogno per progettare e implementare ciascun ambiente in base all'archetipo scelto. Se hai una comprensione completa di quante risorse hai bisogno, puoi trovare il giusto equilibrio il compromesso tra l'affidabilità garantisce che ogni architettura offerte di archetipi, nonché il costo e la complessità della progettazione, l'implementazione e gli ambienti operativi basati su questi archetipi.
  • Prevedi di eseguire la migrazione di un ambiente in base a un'architettura un archetipo a un ambiente basato su un archetipo diverso? Nella In futuro, potresti eseguire la migrazione di carichi di lavoro, dati e processi a un altro ambiente Google Cloud completamente gestito di Google Cloud. Ad esempio, potresti eseguire la migrazione da un ambiente a livello di zona a livello di regione.
  • In che misura sono critici per l'attività gli ambienti che stai progettando e implementazione? Gli ambienti business-critical probabilmente richiedono maggiore affidabilità garantiti. Ad esempio, puoi scegliere di progettare e implementare una un ambiente multiregionale per carichi di lavoro, dati e processi e progetta un ambiente di zona o di regione per carichi di lavoro, dati e processi.
  • Hai bisogno delle funzionalità offerte da un'architettura archetipi per determinati ambienti? Oltre all'affidabilità garantisce che ogni archetipo architettonico offre, anche gli archetipi offrono scalabilità, prossimità geografica, latenza e dati diversi locali garantiti. Ti consigliamo di prendere in considerazione queste garanzie quando puoi scegliere gli archetipi di deployment per i tuoi ambienti.

Oltre agli aspetti tecnici delle modalità di errore definite a seguire le indicazioni precedenti, ti consigliamo di prendere in considerazione Requisiti non funzionali quali normative, località e sovranità i tuoi requisiti. Questi requisiti possono limitare le opzioni disponibili te. Ad esempio, se devi soddisfare requisiti normativi che impongono all'uso di una regione specifica, devi progettare e implementare a una singola regione o a un ambiente di zona all'interno di quella regione.

Scegli una regione Google Cloud per il tuo ambiente

Quando inizi a progettare i tuoi ambienti a una singola regione, devi determinare la regione più adatta ai requisiti di ciascun ambiente. Le seguenti queste due categorie di criteri di selezione:

  • Criteri funzionali. Questi criteri riguardano I prodotti Google Cloud offerti da una determinata regione e indica se una determinata regione soddisfa la latenza e la vicinanza geografica agli utenti e altri ambienti esterni a Google Cloud. Ad esempio, se carichi di lavoro e dati hanno requisiti di latenza per gli utenti o al di fuori di Google Cloud, potresti dover scegliere regione più vicina ai tuoi utenti o ad altri ambienti per ridurre al minimo una latenza di pochi millisecondi.
  • Criteri non funzionali. Questi criteri riguardano i prezzi dei prodotti associate a regioni specifiche, requisiti di impronta di carbonio e ai requisiti e alle normative obbligatori in vigore per il tuo attività. Ad esempio, mercati altamente regolamentati come i servizi bancari e settore hanno requisiti molto rigorosi e specifici in materia di località dei carichi di lavoro e come condividono l'infrastruttura del cloud provider con altri clienti.

Se scegli una determinata regione Google Cloud ora, in futuro potrai eseguire la migrazione in regioni diverse o in un ambiente multiregionale. Se considerare una migrazione futura ad altre regioni, vedi 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 tuoi requisiti di prossimità geografica? Quando scegli in una regione Google Cloud, potresti dover posizionare i carichi di lavoro, e processi in prossimità dei tuoi utenti o dei tuoi ambienti esterni come gli ambienti on-premise. Ad esempio, se scegli come target una base utenti concentrata in un'area geografica particolare ti consigliamo di scegliere una regione Google Cloud che più vicino a quell'area geografica. Scegliere una regione Google Cloud più adatta ai requisiti di prossimità geografica consente ai tuoi ambienti garantire tempi di reazione più bassi alle richieste dal tuo e dai tuoi ambienti esterni a Google Cloud. Strumenti come dashboard Latenza di Google Cloud, e non ufficiali, come GCPing e ai Selettore regione Google Cloud può darti un'idea generale delle caratteristiche di latenza regioni di Google Cloud. Tuttavia, ti consigliamo di eseguire una valutazione completa per valutare se le proprietà di latenza si adattano requisiti, carichi di lavoro, dati e processi.
  • Le regioni in cui vuoi utilizzare i prodotti che offri ? Ti consigliamo di valutare i prodotti disponibili in ogni regione Google Cloud e quali regioni forniscono i servizi per progettare e implementare gli ambienti. Per ulteriori informazioni sui prodotti disponibili in ogni regione e sulla loro disponibilità le sequenze temporali, consulta Località cloud. Inoltre, alcuni prodotti potrebbero non offrire tutte le loro funzionalità in ogni regione in cui sono disponibili. Ad esempio, regioni e zone disponibili per Compute Engine offrono tipi di macchine regioni di Google Cloud. Per ulteriori informazioni sulle funzionalità di prodotto in ogni regione, consulta la documentazione del prodotto.
  • Le risorse di cui hai bisogno in ogni regione di Google Cloud sono? entro i limiti di quota per regione? Google Cloud utilizza le quote per limitare la quantità di risorse Google Cloud condivise che puoi utilizzare. Alcune quote sono globali e si applicano all'utilizzo della risorsa ovunque in Google Cloud, mentre altri operano a livello di regione o zona e si applicano della risorsa in una specifica regione di Google Cloud. Ad esempio: la maggior parte Quote di utilizzo delle risorse Compute Engine, come il numero di macchine virtuali che puoi creare, sono a livello di regione. Per ulteriori informazioni sulle quote e su come aumentarle, consulta Utilizzo delle quote.

Valutare criteri non funzionali

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

  • Preferisci un impatto ambientale ridotto? Google Cloud investe costantemente in sostenibilità e in energia a zero emissioni di CO2 per le regioni di Google Cloud, con impegno per l'energia a zero emissioni di CO2 per tutte le regioni cloud. Le regioni di Google Cloud hanno un'impronta di carbonio diversa. Per informazioni sull'impronta di carbonio di ogni regione Google Cloud, e su come incorporare energia a zero emissioni di CO2 nella tua strategia di localizzazione, consulta Energia a zero emissioni di CO2 per le regioni di Google Cloud.
  • I tuoi ambienti devono soddisfare particolari normative? I governi e gli enti nazionali e sovranazionali spesso regolamentano rigorosamente alcuni mercati e aree di business, come il settore bancario e il settore pubblico. Questi regolamenti potrebbero imporre la residenza dei carichi di lavoro, dei dati e dei processi solo in determinate aree geografiche. Ad esempio, i tuoi ambienti devono rispettare requisiti relativi ai dati, alle operazioni e alla sovranità del software garantire determinati livelli di controllo e trasparenza per i dati sensibili e carichi di lavoro in esecuzione nel cloud. Ti consigliamo di valutare i requisiti normativi attuali e futuri al momento di scegliere le regioni di Google Cloud per i tuoi ambienti e seleziona Regioni di Google Cloud più adatte ai tuoi requisiti normativi.

Progetta e crea ambienti a singola regione

Per progettare un ambiente a una singola regione:

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

Quando progetti il tuo ambiente, considera le seguenti caratteristiche generali principi:

  • Esegui il provisioning delle risorse di regione. Molti prodotti Google Cloud supporta il provisioning delle risorse in più zone all'interno di una regione. Me consigliamo di eseguire il provisioning di risorse a livello di regione anziché di risorse di zona laddove possibile. In teoria, potresti essere in grado di eseguire il provisioning in più zone di una regione e gestiscile autonomamente a ottenere una maggiore affidabilità. Tuttavia, questa configurazione trarre vantaggio da tutte le funzionalità di affidabilità dell'infrastruttura Google è alla base dei servizi Google Cloud.
  • Verifica che gli ambienti funzionino come previsto con il modello di errore ipotesi. Quando progetti e implementi un'unica regione ambienti, ti consigliamo di verificare se questi ambienti soddisfano i requisiti per proteggersi dai modelli di errore che prendere in considerazione, prima di promuovere questi ambienti come parte nell'ambiente di produzione. Ad esempio, puoi simulano interruzioni a livello di zona per verificare che gli ambienti a una singola regione possano sopravvivere con un minimo e un'interruzione del servizio.

Per conoscere i principi di progettazione più generali per la progettazione ambienti multiregionali e per informazioni su come Google ottiene con i servizi regionali e multiregionali, vedi Architettura per il ripristino di emergenza in caso di interruzioni dell'infrastruttura cloud: temi comuni.

Crea le tue basi su Google Cloud

Per creare le basi dei tuoi ambienti con una singola regione, consulta Migrazione a Google Cloud: crea la tua base. Le linee guida contenute in questo documento mirano a creare le basi per la migrazione carichi di lavoro, dati e processi in Google Cloud, ma è anche applicabile per creare le basi per ambienti con una singola regione. Dopo averlo letto, documento, continua a leggere questo documento.

Dopo aver creato le basi su Google Cloud, dovrai progettare e implementare controlli e confini di sicurezza. Queste misure di sicurezza aiutano a garantire i carichi di lavoro, i dati e i processi rimangono all'interno delle rispettive regioni. La misure di sicurezza aiutano anche a garantire che le risorse non cedano nulla ai in altre regioni a causa di bug, configurazioni errate o attacchi dannosi.

Eseguire il provisioning e la configurazione delle risorse di calcolo

Dopo aver creato le basi per i tuoi ambienti a una singola regione, il provisioning e la configurazione delle risorse di calcolo. Nelle sezioni seguenti vengono descritte le Prodotti di computing di Google Cloud che supportano i deployment a livello regionale.

Compute Engine

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

Le risorse Compute Engine sono a livello di zona, ad esempio macchine virtuali o disco permanente a livello di zona; regionale, ad esempio indirizzi IP esterni statici; o globali, ad esempio Snapshot di dischi permanenti. Per ulteriori informazioni sulle risorse a livello di zona, di regione e globali Compute Engine supporta, vedi Risorse globali, a livello di regione e zona.

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

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

  • Gruppi di istanze gestite a livello di regione. Google Compute Engine le macchine virtuali sono risorse a livello di zona, pertanto non saranno di un'interruzione del servizio a livello di zona. Per mitigare il problema, Compute Engine consente di crea MIG a livello di regione che eseguono il provisioning di macchine virtuali su più zone di una regione automaticamente, in base alla domanda e alla disponibilità regionale. Se le tue carichi di lavoro stateful, puoi anche crea MIG stateful a livello di regione per conservare i dati e le configurazioni stateful. Supporto dei gruppi di istanze gestite a livello di regione 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 Simula un'interruzione di una zona per un gruppo di istanze gestite a livello di regione. Per informazioni su come i gruppi di istanze gestite a livello di regione confrontano con altri deployment vedi le opzioni disponibili. Scegli una strategia di deployment di Compute Engine per il tuo carico di lavoro.
  • Forma di distribuzione target. I gruppi di istanze gestite a livello di regione distribuiscono macchine virtuali in base alla forma di distribuzione di destinazione. Per assicurarti che la macchina virtuale distribuzione non differisce di più di un'unità tra due zone in una regione, ti consigliamo di scegliere la forma di distribuzione EVEN quando devi creare gruppi di istanze gestite a livello di regione. Per informazioni sulle differenze tra forme di distribuzione target, vedi Confronto di forme.
  • Modelli di istanza. Per definire le macchine virtuali di cui eseguire il provisioning, I gruppi di istanze gestite utilizzano un tipo di risorsa globale denominato modelli di istanze. Sebbene i modelli di istanza siano risorse globali, potrebbero fare riferimento a livello di zona a livello di regione o di regione. Quando crei modelli di istanza, ti consigliamo di fare riferimento alle risorse di regione anziché a quelle di zona, se possibile. Se utilizzi risorse di zona, ti consigliamo di valutare l'impatto a utilizzarli. Ad esempio, se crei un modello di istanza che fa riferimento a un volume Persistent Disk disponibile solo in una determinata zona, lo userai in qualsiasi altra zona, poiché il volume non è disponibile in quelle altre zone.
  • Configurare bilanciamento del carico e scalabilità. Google Compute Engine supporta il bilanciamento del carico del traffico tra istanze 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 flessibilità dei tuoi ambienti ed evitare l'onere della gestione autogestite, consigliamo di configurare il bilanciamento del carico e la scalabilità automatica. Per ulteriori informazioni sulla configurazione del bilanciamento del carico per Compute Engine, consulta Bilanciamento del carico e scalabilità.
  • Configura le prenotazioni delle risorse. Per assicurarti che gli ambienti disporre delle risorse necessarie quando ne hai bisogno, ti consigliamo di configura prenotazioni di risorse per garantire l'ottenimento di capacità per Compute Engine a livello di zona, Google Cloud. Ad esempio, se c'è un'interruzione a livello di zona, Esegui il provisioning di macchine virtuali in un'altra zona per fornire la capacità necessaria per rimediare a quelle non disponibili a causa dell'interruzione. Le prenotazioni delle risorse assicurano che tu abbia le risorse disponibili 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 i nomi DNS ambienti cloud-native. Google Cloud utilizza nomi DNS di zona delle macchine virtuali Compute Engine per impostazione predefinita. Per ulteriori informazioni su come funziona il DNS interno di Compute Engine, consulta DNS interno. Per facilitare una migrazione futura tra regioni e fare in modo che più gestibile, consigliamo di prendere in considerazione il DNS di zona come parametri di configurazione che potrai modificare in futuro.
  • Scegliere le opzioni di archiviazione appropriate. Compute Engine supporta diversi opzioni di archiviazione per le tue macchine virtuali, come volumi Persistent Disk e solidi locali unità statali (SSD):
    • I volumi di Persistent Disk sono distribuiti su più dischi fisici, e sono situati in modo indipendente rispetto alle tue macchine virtuali. I dischi permanenti possono essere a livello di zona o di regione. Persistente a livello di zona i dischi archiviano i dati in una singola zona, mentre i dischi permanenti a livello di regione di replicare i dati in due zone diverse. Quando scegli lo spazio di archiviazione per ambienti a singola regione, ti consigliamo di scegli i dischi permanenti a livello di regione perché ti offrono in caso di errori a livello di zona. Per ulteriori informazioni su come reagire agli errori a livello di zona quando utilizzi dischi permanenti a livello di regione; consulta Opzioni di alta disponibilità utilizzando Persistent Disk regionale e Failover di un disco permanente a livello di regione.
    • Gli SSD locali hanno una velocità effettiva elevata, ma archiviano i dati solo fino a quando viene arrestata o eliminata. Pertanto, gli annunci SSd locali sono ideali per archiviare dati temporanei, cache e dati che puoi ricostruire e i relativi vantaggi. I dischi permanenti sono dispositivi di archiviazione durevoli a cui le macchine possono accedere come dischi fisici.
  • Progettare e implementare meccanismi per la protezione dei dati. Quando progetti ambienti a una singola regione, ti consigliamo di meccanismi automatici per proteggere i tuoi dati in caso di eventi avversi, come a livello di zona, di regione o di più regioni oppure attacchi intenzionali dannose di terze parti. Compute Engine fornisce varie opzioni per proteggere i tuoi dati. Puoi utilizzare queste funzioni delle opzioni dei dati come componenti di base per progettare e a implementare le procedure di protezione dei dati.

GKE

GKE ti aiuta a eseguire il deployment, gestire e scalare carichi di lavoro standard su Kubernetes. GKE si basa su in Compute Engine, quindi i suggerimenti nella sezione precedente Compute Engine si applica parzialmente a GKE.

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

  • Usa cluster GKE a livello di regione per aumentare la disponibilità del servizio. GKE supporta diverse tipi di disponibilità per i tuoi cluster, a seconda del tipo di cluster di cui hai bisogno. I cluster GKE possono avere un controllo a livello di zona o di regione e possono avere nodi eseguiti in una singola zona o zone all'interno di una regione. Tipi di cluster diversi offrono inoltre servizi diversi gli accordi sul livello del servizio (SLA). Per aumentare l'affidabilità dei tuoi ambienti, ti consigliamo di scegliere cluster a livello di regione. Se utilizzi la funzionalità GKE Autopilot, puoi a livello di regione.
  • Prendi in considerazione un ambiente multi-cluster. Il deployment di più istanze I cluster GKE possono essere aumentare la flessibilità e le proprietà di disponibilità del tuo ambiente, a scapito di una complessità crescente. Ad esempio, se devi utilizzare una nuova funzionalità GKE quando crei un cluster GKE, puoi evitare tempi di inattività e per ridurre la complessità della migrazione aggiungendo dal cluster GKE all'ambiente multi-cluster, eseguendo il deployment dei carichi di lavoro nel nuovo cluster e distruggendo quello precedente. Per Scopri di più sui vantaggi di un cluster multi-cluster per l'ambiente GKE, consulta Casi d'uso multi-cluster. Per aiutarti a gestire la complessità della migrazione, Google Cloud offerte Gestione della flotta un insieme di funzionalità per gestire un gruppo i cluster, la loro infrastruttura e i carichi di lavoro per i cluster.
  • Configura Backup per GKE. Backup per GKE è una servizio regionale per il backup della configurazione e dei volumi del carico di lavoro in un'origine cluster GKE e ripristinarli in una destinazione cluster GKE. Per proteggere la configurazione dei carichi di lavoro da eventuali perdite, ti consigliamo di abilitare e configurare Backup per GKE. Per ulteriori informazioni, vedi 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 necessaria per l'esecuzione dei carichi di lavoro. I servizi Cloud Run sono risorse a livello di regione, e i servizi sono riplicati in più zone della regione in cui si trovano. Quando eseguire il deployment di un servizio Cloud Run, puoi scegliere una regione. Quindi, 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 i servizi ed è progettato per mitigare notevolmente gli effetti di un'interruzione del servizio a livello di zona.

VMware Engine

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

  • Esegui il provisioning dei cloud privati VMware Engine multinodo. VMware Engine supporta il provisioning di stack VMware isolati chiamata 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 i cloud privati a nodo, ma consiglia di utilizzare cloud privati a nodo singolo per proof of concept e ai fini di test. Per gli ambienti di produzione, consigliamo di utilizzare i cloud privati multinodi predefiniti.
  • Esegui il provisioning dei cloud privati ampliati di VMware Engine. R cloud privato ampliato è un cloud privato a più nodi i cui nodi sono distribuiti tra le zone in una regione. Un cloud privato esteso protegge il tuo ambiente a livello di zona.

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

Eseguire il provisioning e la configurazione delle risorse di archiviazione dati

Dopo aver eseguito il provisioning e la configurazione delle risorse di calcolo per la singola regione ambienti, eseguire il provisioning e configurare le risorse per archiviare e gestire i dati. Le seguenti sezioni descrivono gli scenari di archiviazione e prodotti di gestione che supportano configurazioni regionali e multiregionali.

Cloud Storage

Cloud Storage è un servizio per archiviare oggetti, che sono parti immutabili di dati, bucket, ovvero container di base in cui conservare i dati. Quando crea un bucket, selezioni tipo di località del bucket che meglio soddisfa i requisiti di disponibilità, normativi e di altro tipo. Luogo i tipi hanno garanzie di disponibilità diverse. Per proteggere i tuoi dati da guasti e interruzioni, Cloud Storage ti offre i dati ridondanti in almeno due zone per i bucket che hanno una regione tipo di località, in due regioni per i bucket con una località a due regioni e tra due o più regioni per i bucket con più regioni tipo di località. Ad esempio, se devi creare un bucket Cloud Storage, in caso di interruzioni a livello di zona, puoi eseguirne il provisioning con una regione tipo di località.

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

Filestore

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

Bigtable

Bigtable è un servizio di database completamente gestito, ad alte prestazioni e a scalabilità elevata grandi carichi di lavoro analitici e operativi. Istanze Bigtable sono risorse di zona. Per aumentare l'affidabilità delle istanze, puoi configurare Bigtable per replicare i dati in più zone all'interno dello stesso in una singola regione o in più regioni. Quando la replica è abilitata, se è presente un'interruzione del servizio, Bigtable esegue automaticamente il failover delle richieste le istanze disponibili in cui hai replicato i dati.

Per saperne di più su come funziona la replica in Bigtable, vedi Informazioni sulla replica e Architettura del ripristino di emergenza per le interruzioni dell'infrastruttura cloud: Bigtable.

Firestore

Firestore è un database flessibile e scalabile per dispositivi mobili, web lo sviluppo dei server web da Firebase e Google Cloud. Quando eseguire il provisioning di un database Firestore, devi selezionare la relativa località. Le località possono essere multiregionali o regionali e offrono diverse le garanzie di affidabilità. Se un database ha una località regionale, viene replicato tra più zone all'interno di una regione. Un database multiregionale replica in più di una regione.

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

Memorystore

Memorystore ti consente di configurare soluzioni scalabili, sicure e di archiviazione dati in memoria disponibili. Supporta backend di dati Redis e Memcached.

Quando esegui il provisioning Memorystore per istanze Redis, selezioni un livello di servizio per quell'istanza. Memorystore for Redis supporta diversi servizi di istanze e ciascun livello offre disponibilità, dimensione dei nodi e larghezza di banda univoche le funzionalità di machine learning. Quando esegui il provisioning di un'istanza Memorystore for Redis, ti consigliamo puoi scegliere un livello Standard o un livello Standard con repliche di lettura. Le istanze Memorystore in questi due livelli vengono replicate automaticamente in più zone di una regione. Per ulteriori informazioni Memorystore for Redis raggiunge una disponibilità elevata, vedi Disponibilità elevata per Memorystore for Redis

Quando esegui il provisioning Memorystore per istanze Memcached, tieni in considerazione quanto segue:

  • Selezione zona. Quando eseguire 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 dai nodi di quell'istanza oppure puoi lasciare che Memorystore for Memcached a distribuire automaticamente i nodi tra le zone. Per posizionare in modo ottimale ed evitare problemi di provisioning, come il posizionamento di tutti i nodi all'interno della stessa zona, ti consigliamo Memorystore for Memcached distribuisce automaticamente i nodi zone all'interno di una regione.
  • Replica dei dati tra zone. Memorystore for Memcached e non replicano i dati tra zone o regioni. Per maggiori informazioni informazioni su come funzionano le istanze Memorystore for Memcached a livello di zona o di regione, vedi 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 una disponibilità fino al 99,999%. Per utilizzare Spanner, esegui il provisioning Istanze di Spanner. Quando esegui il provisioning delle istanze Spanner, considera quanto segue:

  • Configurazione dell'istanza. Un configurazione dell'istanza definisce il posizionamento geografico e la replica dei database in un Spanner. Quando crei un'istanza Spanner, configurala come regionale o multiregionale.
  • Replica. Spanner supporta l'automazione automatica a livello di byte di replica e supporta la creazione repliche in base alle tue esigenze di disponibilità, affidabilità e scalabilità. Puoi distribuiscono le repliche tra regioni e ambienti. Spanner con configurazione a livello di regione, ne mantengono uno replica di lettura/scrittura per ogni zona all'interno di una regione. Istanze con più regioni di replicare i dati in più zone su più regioni.
  • Spostamento delle istanze. Spanner ti consente spostare un'istanza da qualsiasi configurazione di istanza a qualsiasi altra configurazione di istanza senza causare tempi di inattività o interruzioni delle transazioni garantiti durante spostare l'attività.

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

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

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

BigQuery

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

Per organizzare e controllare l'accesso ai dati in BigQuery, di container di primo livello, set di dati. Quando esegui il provisioning di un set di dati BigQuery, considera quanto segue:

  • Posizione del set di dati. Per selezionare Posizione BigQuery in cui archiviare i dati, devi configurare la posizione del set di dati. R la 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 modificare la posizione del set di dati dopo crei un set di dati.
  • Pianificazione in caso di emergenza. BigQuery è un servizio regionale, e gestisce automaticamente gli errori a livello di zona, di computing e di dati. Tuttavia, ci sono alcuni scenari che devi pianificare in autonomia. ad esempio interruzioni a livello di regione. Ti consigliamo di prendere in considerazione questi scenari quando si progettano gli ambienti.

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

Dataproc

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

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

  • Posizionamento automatico della zona. Quando crei un cluster, puoi specificare la zona all'interno di una regione in cui eseguire il provisioning nel cluster oppure lascia che Posizionamento automatico della zona Dataproc selezionare automaticamente la zona. Ti consigliamo di usare la zona automatica a meno che tu non debba ottimizzare il posizionamento della zona dei nodi del cluster all'interno della regione.
  • Modalità alta disponibilità. Quando crei un cluster, puoi abilitare modalità alta disponibilità. Non puoi abilitare la modalità ad alta disponibilità dopo aver creato un cluster. Me ti consigliamo di abilitare la modalità ad alta disponibilità se hai bisogno che il cluster essere resilienti ai guasti di un singolo nodo coordinatore o a a livello di zona. I cluster Dataproc ad alta disponibilità sono a livello di zona Google Cloud.

Per ulteriori informazioni su come Dataproc reagisce alle esigenze a livello di regione e come aumentare l'affidabilità per i cluster Dataproc in caso di errori, consulta Architettura del ripristino di emergenza per interruzioni dell'infrastruttura cloud: Dataproc.

Dataflow

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

  • Endpoint a livello di regione. Quando crei un job, Dataflow richiede la configurazione di un endpoint regionale. Configurando un endpoint a livello di regione per il job, limiti il computing e il posizionamento delle risorse di dati in una particolare regione.
  • Posizionamento a livello di zona. Dataflow distribuisce automaticamente nodi worker in tutte le zone di una regione o nel migliore zona all'interno 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 all'interno di una regione. Per limitare i problemi causate da interruzioni a livello di zona, ti consigliamo di lasciare che Dataflow selezionerà automaticamente il posizionamento migliore nella zona, a meno che non sia necessario posizionare il di nodi worker in una zona specifica.

Per ulteriori informazioni su come Dataproc reagisce alle esigenze a livello di regione e come aumentare l'affidabilità per i cluster Dataproc in caso di errori, consulta Architettura del 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 produrre messaggi dai servizi che li elaborano. Pub/Sub organizza i messaggi in argomenti. Publisher (servizi che generare messaggi) inviare messaggi agli argomenti e i sottoscrittori ricevono messaggi dagli argomenti. Pub/Sub archivia ogni messaggio in una singola regione lo replica in almeno due zone all'interno della regione. Per ulteriori informazioni, vedi Panoramica dell'architettura in Pub/Sub.

Quando configuri il tuo ambiente Pub/Sub, considera la seguenti:

  • Endpoint globali e a livello di regione. Pub/Sub supporta endpoint globali e regionali per pubblicare i messaggi. Quando un publisher invia un messaggio all'endpoint globale, Pub/Sub seleziona automaticamente la regione più vicina da elaborare quel messaggio. Quando un producer invia un messaggio a un endpoint a livello di regione, Pub/Sub elabora il messaggio in quella regione.
  • Criteri di archiviazione dei messaggi. Pub/Sub consente di configurare criteri di archiviazione dei messaggi per limitare le posizioni in cui Pub/Sub elabora e archivia i messaggi, a prescindere dall'origine della richiesta e dall'endpoint a cui il publisher utilizzati per pubblicare il messaggio. Ti consigliamo di configurare il messaggio Criteri di archiviazione per garantire che i messaggi non lascino la tua unica regione completamente gestito di Google Cloud.

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

Adatta i carichi di lavoro ad ambienti con una singola regione

Una volta completato il provisioning e la configurazione degli ambienti, devi considerare come rendere i carichi di lavoro più resilienti a livello di regione. Ogni carico di lavoro può avere le proprie disponibilità e affidabilità requisiti e proprietà, ma ci sono alcuni principi di progettazione che e le strategie che puoi adottare per migliorare la resilienza complessiva la postura nell'improbabile caso di errori a livello di zona e di regione. Quando progetti e implementare i carichi di lavoro, considera quanto segue:

  • Implementare le pratiche di Site Reliability Engineering (SRE) e principi. Automation e il monitoraggio esteso sono gli aspetti fondamentali principi di SRE. Google Cloud fornisce gli strumenti e i servizi professionali per implementare l'SRE per aumentare la resilienza e l'affidabilità dei tuoi ambienti e ridurre il lavoro manuale.
  • Progetta per la scalabilità e la resilienza. Quando progetti i carichi di lavoro per ambienti cloud, consigliamo di valutare la scalabilità la resilienza è un requisito intrinseco che i carichi di lavoro devono rispettare. Per ulteriori informazioni su questo tipo di progettazione, vedi Pattern per app scalabili e resilienti.
  • Progettazione per il ripristino da interruzioni dell'infrastruttura cloud. Le garanzie di disponibilità di Google Cloud sono definite Accordi sul livello del servizio di Google Cloud. Nell'improbabile caso che si verifichi un errore a livello di zona o di regione, di consigliarti progettare i tuoi carichi di lavoro in modo che siano resilienti agli errori a livello di zona e di regione.
  • Implementa perdita del carico e riduzione controllata. In caso di guasti dell'infrastruttura cloud o di altri delle dipendenze dai carichi di lavoro, ti consigliamo di progettarli in modo che siano resilienti. I carichi di lavoro devono mantenere livelli di funzionalità ben definiti anche in caso di errori (grazie degrado) ed essere in grado di ridurre una parte del carico man mano che si avvicinano alle condizioni di sovraccarico (perdita del carico).
  • Pianificare una manutenzione regolare. Quando progetti di deployment e sui tuoi processi operativi, ti consigliamo di pensare anche a tutti le attività che devi eseguire nell'ambito della normale manutenzione dei tuoi ambienti. La manutenzione regolare dovrebbe includere attività come e applicare aggiornamenti e modifiche alla configurazione ai carichi di lavoro e ai relativi delle dipendenze e come queste attività possono influire sulla disponibilità dei tuoi ambienti. Ad esempio, puoi configurare criterio di manutenzione dell'host per le tue istanze Compute Engine.
  • Adotta un approccio di sviluppo basato su test. Quando progetti carichi di lavoro, ti consigliamo di adottare approccio allo sviluppo basato sui test per assicurarti che i carichi di lavoro si comportino come previsto da tutte le angolazioni. Per Ad esempio, puoi verificare se i carichi di lavoro e l'infrastruttura cloud soddisfano funzionali, non funzionali e di sicurezza richiesti.

Passaggi successivi

Collaboratori

Autore: Marco Ferrari | Cloud Solutions Architect

Altri collaboratori: