Google Cloud i servizi di infrastruttura vengono eseguiti in località in tutto il mondo. Le località sono suddivise in domini di errore, chiamati regioni e zone, che sono i blocchi di base per la progettazione di un'infrastruttura affidabile per i tuoi carichi di lavoro cloud.
Un dominio in errore è una risorsa o un gruppo di risorse che può avere esito negativo indipendentemente dalle altre risorse. Una VM Compute Engine autonoma è un esempio di risorsa che è un dominio in errore. Una regione o una zona Google Cloud è un esempio di dominio in errore costituito da un gruppo di risorse. Quando un'applicazione viene distribuita in modo ridondante tra i domini di errore, può raggiungere un livello di disponibilità aggregato superiore a quello fornito da ciascun dominio di errore.
Questa parte della Google Cloud guida all'affidabilità dell'infrastruttura descrive i componenti fondamentali dell'affidabilità in Google Cloud e il modo in cui influiscono sulla disponibilità delle risorse cloud.
Regioni e zone
Le regioni sono aree geografiche indipendenti costituite da zone. Zone e regioni sono astrazioni logiche delle risorse fisiche sottostanti. Per saperne di più sulle considerazioni specifiche per le regioni, consulta Area geografica e regioni.
Disponibilità delle piattaforme
L'infrastrutturaGoogle Cloud è progettata per tollerare e ripristinare gli errori. Google investe continuamente in approcci innovativi per mantenere e migliorare l'affidabilità di Google Cloud. Le seguenti funzionalità dell'infrastrutturaGoogle Cloud contribuiscono a fornire una piattaforma affidabile per i tuoi carichi di lavoro cloud:
- Regioni separate geograficamente per mitigare gli effetti di disastri naturali e interruzioni del servizio a livello regionale sui servizi globali.
- Ridondanza e replica dell'hardware per evitare single point of failure.
- Migrazione live delle risorse durante gli eventi di manutenzione. Ad esempio, durante la manutenzione pianificata dell'infrastruttura, le VM Compute Engine possono essere spostate su un altro host nella stessa zona utilizzando la migrazione live.
- Una base di infrastruttura progettata per la sicurezza per l'infrastruttura fisica e il software su cui Google Cloud viene eseguito e controlli di sicurezza operativa per proteggere i tuoi dati e i tuoi workload. Per saperne di più, consulta Panoramica sulla progettazione della sicurezza dell'infrastruttura Google.
- Una rete backbone ad alte prestazioni che utilizza un approccio di gestione della rete di networking software-defined (SDN) avanzato, con servizi di memorizzazione nella cache perimetrale per offrire prestazioni coerenti e scalabili.
- Monitoraggio e generazione di report continui. Puoi visualizzare lo stato dei servizi Google Cloud in ogni località utilizzando la Google Cloud dashboard di Service Health.
- Eventi annuali di test di ripristino di emergenza (DiRT) a livello aziendale per garantire che Google Cloud i servizi e le operazioni aziendali interne continuino a funzionare durante un'emergenza.
- Un approccio di gestione delle modifiche che enfatizza l'affidabilità in tutte le fasi del ciclo di vita dello sviluppo software per qualsiasi modifica alla piattaforma e ai servizi Google Cloud .
L'infrastrutturaGoogle Cloud è progettata per supportare i seguenti livelli di disponibilità target per la maggior parte dei workload dei clienti:
| Località di deployment | % di disponibilità (uptime) | Tempo di inattività massimo stimato |
|---|---|---|
| Zona singola | Tre nove: 99,9% | 43,2 minuti in un mese di 30 giorni |
| Più zone in una regione | Quattro 9: 99,99% | 4,3 minuti in un mese di 30 giorni |
| Più regioni | 5 nove: 99,999% | 26 secondi in un mese di 30 giorni |
Le percentuali di disponibilità nella tabella precedente sono target. Gli accordi sul livello del servizio (SLA) per servizi Google Cloud specifici potrebbero essere diversi da questi target di disponibilità. Ad esempio, l'SLA di uptime per un'istanza Bigtable dipende dal numero di cluster, dalla loro distribuzione nelle località e dalla policy di routing che configuri.
Lo SLA con uptime minimo per un'istanza Bigtable con cluster in tre o più regioni è del 99,999% se è configurato il criterio di routing multi-cluster. Tuttavia, se è configurata la policy di routing a cluster singolo, lo SLA di uptime minimo è del 99,9%, indipendentemente dal numero di cluster e dalla loro distribuzione.
I diagrammi in questa sezione mostrano istanze Bigtable con dimensioni dei cluster variabili e le conseguenti differenze nei relativi SLA di uptime.
Singolo cluster
Il seguente diagramma mostra un'istanza Bigtable a cluster singolo, con uno SLA di uptime minimo del 99,9%:
Più cluster
Il seguente diagramma mostra un'istanza Bigtable multicluster in più zone all'interno di una singola regione, con routing multicluster (SLA di uptime minimo: 99,99%):
Più cluster
Il seguente diagramma mostra un'istanza Bigtable multicluster in tre regioni, con routing multicluster (SLA di uptime minimo: 99,999%):
Disponibilità aggregata dell'infrastruttura
Questa sezione descrive come calcolare la disponibilità aggregata di uno stack di infrastruttura in Google Cloud. Descrive i fattori che influenzano la disponibilità aggregata e fornisce esempi di calcoli.
Per eseguire le tue applicazioni in Google Cloud, utilizzi risorse dell'infrastruttura come VM e database. Queste risorse dell'infrastruttura costituiscono insieme lo stack dell'infrastruttura della tua applicazione. Il seguente diagramma mostra un esempio di stack dell'infrastruttura in Google Cloud e lo SLA di disponibilità per ogni risorsa dello stack:
Questo stack di infrastruttura di esempio include le seguenti Google Cloud risorse:
- Un bilanciatore del carico delle applicazioni esterno regionale riceve e risponde alle richieste degli utenti.
- Un gruppo di istanze gestite (MIG) regionale è il backend del bilanciatore del carico delle applicazioni esterno regionale. Il MIG contiene due VM Compute Engine in zone diverse. Ogni VM ospita un'istanza di un server web.
- Un bilanciatore del carico interno gestisce la comunicazione tra i server web e i server delle applicazioni.
- Un secondo MIG regionale è il backend del bilanciatore del carico interno. Questo MIG ha due VM di Compute Engine in zone diverse. Ogni VM ospita un'istanza di un server delle applicazioni.
- Un'istanza Cloud SQL configurata per l'alta disponibilità è il database per l'applicazione. L'istanza di database primaria viene replicata in modo sincrono in un'istanza di database in standby.
La disponibilità aggregata che puoi aspettarti da uno stack di infrastruttura come l'esempio precedente dipende dai seguenti fattori:
Google Cloud SLA
Gli SLA di uptime dei servizi Google Cloud che utilizzi nello stack dell'infrastruttura influiscono sulla disponibilità aggregata minima che puoi aspettarti dallo stack.
Le tabelle seguenti presentano un confronto degli SLA di uptime per alcuni servizi:
| Servizi di computing | SLA per il tempo di attività mensile | Tempo di inattività massimo stimato in un mese di 30 giorni |
|---|---|---|
| VM di Compute Engine | 99,9% | 43,2 minuti |
| Pod Google Kubernetes Engine (GKE) Autopilot in più zone | 99,9% | 43,2 minuti |
| Servizio Cloud Run | 99,95% | 21,6 minuti |
| Servizi di database | SLA per il tempo di attività mensile | Tempo di inattività massimo stimato in un mese di 30 giorni |
|---|---|---|
| Istanza Cloud SQL per PostgreSQL (Enterprise Edition, configurazione HA) | 99,95% | 21,6 minuti |
| Istanza AlloyDB per PostgreSQL (configurazione HA) | 99,99% | 4,3 minuti |
| Istanza Spanner multiregionale | 99,999% | 26 secondi |
Per gli SLA di altri servizi Google Cloud , consulta gli Google Cloud accordi sul livello del servizio.
Come mostrano le tabelle precedenti, i servizi Google Cloud che scegli per ogni livello dello stack dell'infrastruttura influiscono direttamente sull'uptime complessivo che puoi aspettarti dallo stack dell'infrastruttura. Per aumentare la disponibilità prevista di un workload di cui è stato eseguito il deployment su una risorsa Google Cloud , puoi eseguire il provisioning di istanze ridondanti della risorsa, come descritto nella sezione successiva.
Ridondanza delle risorse
La ridondanza delle risorse prevede il provisioning di due o più istanze identiche di una risorsa e il deployment dello stesso carico di lavoro su tutte le risorse del gruppo. Ad esempio, per ospitare il livello web di un'applicazione, potresti eseguire il provisioning di un MIG contenente più VM Compute Engine identiche.
Se distribuisci un gruppo di risorse in modo ridondante in più domini di errore, ad esempio due Google Cloud zone, la disponibilità delle risorse che puoi aspettarti da quel gruppo è superiore allo SLA di uptime di ogni risorsa del gruppo. Questa maggiore disponibilità è dovuta al fatto che la probabilità che ogni risorsa del gruppo non funzioni contemporaneamente è inferiore alla probabilità che le risorse di un singolo dominio in errore abbiano un errore coordinato.
Ad esempio, se lo SLA (accordo sul livello del servizio) per una risorsa è del 99,9%, la probabilità che la risorsa non funzioni è dello 0,001 (1 meno lo SLA). Se distribuisci un carico di lavoro su due istanze di questa risorsa di cui è stato eseguito il provisioning in domini di errore separati, la probabilità che entrambe le risorse non funzionino contemporaneamente è 0,000001 (ovvero 0,001 x 0,001). Questa probabilità di errore si traduce in una disponibilità teorica del 99,9999% per il gruppo di due risorse. Tuttavia, la disponibilità effettiva che puoi aspettarti è limitata alla disponibilità di destinazione della località di deployment: 99,9% se le risorse si trovano in una singola zonaGoogle Cloud , 99,99% per un deployment multi-zona e 99,999% se le risorse ridondanti sono distribuite in più regioni.
Profondità dello stack
La profondità di uno stack di infrastruttura è il numero di livelli distinti nello stack. Ogni livello di uno stack dell'infrastruttura contiene risorse che forniscono una funzione distinta per l'applicazione. Ad esempio, il livello intermedio in uno stack a tre livelli potrebbe utilizzare VM di Compute Engine o un cluster GKE per ospitare i server delle applicazioni. Ogni livello di uno stack di infrastruttura in genere ha una stretta interdipendenza con i livelli adiacenti. Ciò significa che se un livello dello stack non è disponibile, l'intero stack diventa non disponibile.
Puoi calcolare la disponibilità aggregata prevista di uno stack di infrastruttura a N livelli utilizzando la seguente formula:
Ad esempio, se ogni livello di uno stack a tre livelli è progettato per fornire una disponibilità del 99,9%, la disponibilità aggregata dello stack è di circa il 99,7% (0,999 x 0,999 x 0,999). Ciò significa che la disponibilità aggregata di uno stack multi-livello è inferiore alla disponibilità del livello che offre la disponibilità minima.
Man mano che il numero di livelli interdipendenti in uno stack aumenta, la disponibilità aggregata dello stack diminuisce, come mostrato nella tabella seguente. Ogni stack di esempio nella tabella ha un numero diverso di livelli e ogni livello fornisce una disponibilità del 99,9%.
| Livello | Stack A | Stack B | Stack C |
|---|---|---|---|
| Frontend | 99,9% | 99,9% | 99,9% |
| Livello di applicazione | 99,9% | 99,9% | 99,9% |
| Livello medio | – | 99,9% | 99,9% |
| Livello dei dati | – | – | 99,9% |
| Disponibilità aggregata della serie | 99,8% | 99,7% | 99,6% |
| Tempo di inattività massimo stimato dello stack in un mese di 30 giorni | 86 minuti | 130 minuti | 173 minuti |
Riepilogo delle considerazioni sulla progettazione
Quando progetti le tue applicazioni, considera la disponibilità aggregata dello stack dell'infrastrutturaGoogle Cloud .
- La disponibilità di ogni risorsa Google Cloud nello stack dell'infrastruttura influisce sulla disponibilità aggregata dello stack. Quando scegli i Google Cloud servizi per creare lo stack dell'infrastruttura, considera lo SLA di disponibilità dei servizi.
- Per migliorare la disponibilità della funzione (ad esempio, di calcolo o di database) fornita da una risorsa, puoi eseguire il provisioning di istanze ridondanti della risorsa. Quando progetti un'architettura con risorse ridondanti, oltre ai vantaggi in termini di disponibilità, devi considerare anche i potenziali effetti su complessità operativa, latenza e costi.
- Il numero di livelli in uno stack dell'infrastruttura (ovvero la profondità dello stack) ha una relazione inversa con la disponibilità aggregata dello stack. Tieni presente questa relazione quando progetti o modifichi il tuo stack.
Per altri esempi di calcolo della disponibilità aggregata, consulta le sezioni seguenti:
- Esempio di calcolo: deployment in una sola zona
- Esempio di calcolo: deployment multizona
- Esempio di calcolo: deployment multiregionale con bilanciamento del carico regionale
- Esempio di calcolo: deployment multiregionale con bilanciamento del carico globale
Ambiti delle località
L'ambito della località di una Google Cloud risorsa determina la misura in cui un errore dell'infrastruttura può influire sulla risorsa. La maggior parte delle risorse di cui esegui il provisioning in Google Cloud ha uno dei seguenti ambiti di località: zona, regione, più regioni o globale.
L'ambito della località di alcuni tipi di risorse è fisso, ovvero non puoi scegliere o modificare l'ambito della località. Ad esempio, le reti Virtual Private Cloud (VPC) sono risorse globali, mentre le macchine virtuali (VM) di Compute Engine sono risorse di zona. Per alcune risorse, puoi scegliere l'ambito della località durante il provisioning della risorsa. Ad esempio, quando crei un cluster GKE, puoi scegliere di creare un cluster GKE zonale o regionale.
Le sezioni seguenti descrivono in modo più dettagliato gli ambiti delle località.
Risorse di zona
Le risorse di zona vengono implementate all'interno di una singola zona in una Google Cloud regione. Di seguito sono riportati alcuni esempi di risorse zonali. Questo elenco non è esaustivo.
- VM Compute Engine
- MIG a livello di zona
- Volumi Google Cloud Hyperdisk
- Cluster GKE a zona singola
- Istanze Filestore Basic e Zonal
- Job Dataflow
- Istanze Cloud SQL
- Cluster Managed Service for Apache Spark su Compute Engine
Un errore in una zona potrebbe influire sulle risorse zonali di cui è stato eseguito il provisioning all'interno di quella zona. Le zone sono progettate per ridurre al minimo il rischio di errori correlati con altre zone della regione. Un errore in una zona di solito non influisce sulle risorse nelle altre zone della regione. Inoltre, un errore in una zona non causa necessariamente l'indisponibilità di tutta l'infrastruttura in quella zona. La zona definisce semplicemente il limite previsto per l'effetto di un errore.
Per proteggere le applicazioni che utilizzano risorse a livello di zona da incidenti a livello di zona, puoi distribuire o replicare le risorse in più zone o regioni. Per saperne di più, consulta Progettare un'infrastruttura affidabile per i carichi di lavoro in Google Cloud.
Risorse di regione
Le risorse regionali vengono distribuite in modo ridondante in più zone all'interno di una regione. Di seguito sono riportati alcuni esempi di risorse regionali. Questo elenco non è esaustivo.
- MIG a livello di area geografica
- Bucket Cloud Storage regionali
- Volumi Hyperdisk Balanced High Availability
- Cluster GKE regionali con la configurazione predefinita (multizona)
- Subnet VPC
- Bilanciatori del carico delle applicazioni esterni regionali
- Istanze Spanner regionali
- Istanze Filestore Enterprise
- Servizi Cloud Run
Le risorse regionali sono resilienti agli incidenti in una zona specifica. Un'interruzione di una regione può interessare alcune o tutte le risorse regionali di cui è stato eseguito il provisioning all'interno di quella regione. Queste interruzioni possono essere causate da calamità naturali o da guasti su larga scala dell'infrastruttura.
Risorse multi-regione
Le risorse multiregionali sono distribuite in regioni specifiche. Di seguito sono riportati alcuni esempi di risorse multiregionali. Questo elenco non è esaustivo.
- Bucket Cloud Storage a due regioni e multiregionali
- Istanze Spanner multiregionali
- Istanze Bigtable multi-cluster (multi-regionali)
- Key ring multiregionali in Cloud Key Management Service
Per un elenco completo dei servizi Google disponibili nelle configurazioni multiregionali, consulta Prodotti disponibili per località.
Le risorse multiregionali sono resilienti agli incidenti in regioni e zone specifiche. Un'interruzione dell'infrastruttura che si verifica in più regioni può influire sulla disponibilità di alcune o di tutte le risorse multiregionali di cui è stato eseguito il provisioning nelle regioni interessate.
Risorse globali
Le risorse globali sono disponibili in tutte le Google Cloud località. Di seguito sono riportati alcuni esempi di risorse globali. Questo elenco non è esaustivo.
progetti e pagano per i progetti. Per indicazioni e best practice sull'organizzazione delle risorseGoogle Cloud in cartelle e progetti, consulta Decidere una gerarchia delle risorse per la tua Google Cloud landing zone.
Reti VPC, incluse route e regole firewall associate
Zone Cloud DNS
Bilanciatori del carico delle applicazioni esterni globali
Key Ring globali in Cloud Key Management Service
Argomenti Pub/Sub
Secret in Secret Manager
Per un elenco completo dei servizi Google disponibili a livello globale, consulta Prodotti globali.
Le risorse globali sono resilienti agli incidenti a livello di zona e regione. Queste risorse non si basano sull'infrastruttura di una regione specifica. Google Cloud Dispone di sistemi e processi che contribuiscono a ridurre al minimo il rischio di interruzioni dell'infrastruttura globale. Google monitora costantemente l'infrastruttura e risolve rapidamente eventuali interruzioni globali.
La tabella seguente riassume la resilienza relativa delle risorse a livello di zona, regionale, multiregionale e globale ai problemi di applicazioni e infrastrutture. Descrive anche l'impegno necessario per configurare queste risorse e i consigli per mitigare gli effetti delle interruzioni.
| Ambito risorsa | Resilienza | Suggerimenti per mitigare gli effetti delle interruzioni dell'infrastruttura |
|---|---|---|
| A livello di zona | Bassa | Esegui il deployment delle risorse in modo ridondante in più zone o regioni. |
| Regionale | Media | Esegui il deployment delle risorse in modo ridondante in più regioni. |
| Multi-regione o globale | Alta | Gestisci attentamente le modifiche e utilizza i fallback di difesa in profondità ove possibile. Per saperne di più, consulta Consigli per gestire il rischio di interruzioni delle risorse globali. |
Suggerimenti per gestire il rischio di interruzioni delle risorse globali
Per sfruttare la resilienza delle risorse globali alle interruzioni di zona e regione, potresti prendere in considerazione l'utilizzo di determinate risorse globali nella tua architettura. Google consiglia i seguenti approcci per gestire il rischio di interruzioni delle risorse globali:
Gestione attenta delle modifiche alle risorse globali
Le risorse globali sono resilienti agli errori fisici. La configurazione di queste risorse ha ambito globale. Pertanto, configurare e configurare una singola risorsa globale è più semplice che gestire più risorse regionali. Tuttavia, un errore critico nella configurazione di una risorsa globale potrebbe renderla un singolo punto di errore (SPOF). Ad esempio, puoi utilizzare un bilanciatore del carico globale come frontend per un'applicazione distribuita geograficamente. Un bilanciatore del carico globale è spesso una buona scelta per un'applicazione di questo tipo. Tuttavia, un errore nella configurazione del bilanciatore del carico può renderlo non disponibile in tutte le aree geografiche. Per evitare questo rischio, devi gestire attentamente le modifiche alla configurazione delle risorse globali. Per saperne di più, vedi Controllare le modifiche alle risorse globali.
Utilizzo di risorse regionali come fallback di difesa in profondità
Per le applicazioni con requisiti di alta affidabilità eccezionalmente elevati, i fallback di difesa in profondità regionali possono contribuire a ridurre al minimo l'effetto delle interruzioni delle risorse globali. Prendi in considerazione l'esempio di un'applicazione distribuita geograficamente che ha un bilanciatore del carico globale come frontend. Per garantire che l'applicazione rimanga accessibile anche se il bilanciatore del carico globale è interessato da un'interruzione globale, puoi eseguire il deployment di bilanciatori del carico regionali. Puoi configurare i client in modo che preferiscano il bilanciatore del carico globale, ma che eseguano il failover sul bilanciatore del carico regionale più vicino se il bilanciatore del carico globale non è disponibile.
Per proteggerti da interruzioni e errori di configurazione del bilanciatore del carico globale, puoi implementare una strategia di failover o bypass automatica utilizzando Cloud DNS e bilanciatori del carico di backup regionali. Per saperne di più, consulta Strategie di failover per i bilanciatori del carico delle applicazioni esterni globali.
Architettura di esempio con risorse a livello di zona, regionale e globale
La topologia cloud può includere una combinazione di risorse zonali, regionali e globali, come mostrato nel seguente diagramma. Il seguente diagramma mostra un'architettura di esempio per un'applicazione a più livelli di cui è stato eseguito il deployment inGoogle Cloud.
Come mostrato nel diagramma precedente, un bilanciatore del carico delle applicazioni esterno globale riceve le richieste dei client. Il bilanciatore del carico distribuisce le richieste al backend, che è un MIG regionale con due VM di Compute Engine. L'applicazione in esecuzione sulle VM scrive dati in un database Cloud SQL e li legge. Il database è configurato per l'alta disponibilità. Le istanze primaria e in standby del database vengono sottoposte a provisioning in zone separate e il database principale viene replicato in modo sincrono nel database in standby. Inoltre, viene eseguito automaticamente il backup del database in un bucket multiregionale in Cloud Storage.
La tabella seguente riepiloga le risorse Google Cloud nell'architettura precedente e la resilienza di ciascuna risorsa alle interruzioni di zona e regione:
| Risorsa | Resilienza alle interruzioni |
|---|---|
| Rete VPC | Le reti VPC, incluse le route e le regole firewall associate, sono risorse globali. Sono resilienti alle interruzioni di zona e regione. |
| Subnet | Le subnet VPC sono risorse regionali. Sono resilienti alle interruzioni di zona. |
| Bilanciatore del carico delle applicazioni esterno globale | I bilanciatori del carico delle applicazioni esterni globali sono resilienti alle interruzioni di zona e regione. |
| MIG regionale | I MIG regionali sono resilienti alle interruzioni del servizio a livello di zona. |
| VM Compute Engine | Le VM Compute Engine sono risorse di zona. In caso di interruzione di una zona, le singole VM di Compute Engine potrebbero essere interessate. Tuttavia, l'applicazione può continuare a gestire le richieste perché il backend del bilanciatore del carico è un MIG regionale e non VM autonome. |
| Istanze Cloud SQL | Il deployment di Cloud SQL in questa architettura è configurato
per l'alta disponibilità, ovvero include una coppia principale-standby di
istanze di database. Il database primario viene replicato in modo sincrono
nel database di standby utilizzando volumi Hyperdisk bilanciati ad alta
affidabilità.
|
| Bucket Cloud Storage multiregionale | I dati archiviati nei bucket Cloud Storage multiregionali sono resilienti alle interruzioni di una singola regione. |
| Volumi Hyperdisk | I volumi Hyperdisk sono risorse a livello di zona. Per l'alta affidabilità, puoi utilizzare i volumi Hyperdisk Balanced High Availability. I dati vengono replicati in modo sincrono in due zone della stessa regione.Per prepararti al ripristino in caso di interruzioni a livello di regione, puoi pianificare snapshot dei volumi Hyperdisk e archiviarli in un bucket Cloud Storage multiregionale. |