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 da altre risorse. Una VM Compute Engine autonoma è un esempio di risorsa che è undominio in erroree. 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 gli elementi costitutivi 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à della piattaforma
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 calamità naturali e interruzioni del servizio sulle regioni 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 dell'infrastruttura sicura "by design" per l'infrastruttura fisica e il software su cui viene eseguito Google Cloud e controlli di sicurezza operativa per proteggere i dati e i carichi di lavoro. Per ulteriori informazioni, consulta Panoramica sulla progettazione della sicurezza dell'infrastruttura Google.
- Una rete backbone ad alte prestazioni che utilizza un approccio di gestione della rete basato su 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 serviziGoogle 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 i servizi e le operazioni aziendali interne continuino a funzionare durante un'emergenza. Google Cloud
- 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 carichi di lavoro dei clienti:
| Località di deployment | % di disponibilità (uptime) | Tempo di inattività massimo stimato |
|---|---|---|
| Zona singola | Tre 9: 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 | Cinque 9: 99,999% | 26 secondi in un mese di 30 giorni |
Le percentuali di disponibilità nella tabella precedente sono obiettivi. 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 è configurato il criterio di routing a cluster singolo, lo SLA con 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à dell'infrastruttura aggregata
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 il contratto di servizio per la disponibilità di ogni risorsa nello 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 il server web e le istanze del 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 principale viene replicata in modo sincrono in un'istanza di database di 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 relativi al tempo di attività dei servizi Google Cloud che utilizzi nello stack dell'infrastruttura influiscono sulla disponibilità aggregata minima che puoi aspettarti dallo stack.
Le seguenti tabelle mostrano un confronto degli SLA di uptime per alcuni servizi:
| Servizi di calcolo | SLA per l'uptime mensile | Tempo di inattività massimo stimato in un mese di 30 giorni |
|---|---|---|
| VM di Compute Engine | 99,9% | 43,2 minuti |
| Pod GKE Autopilot in più zone | 99,9% | 43,2 minuti |
| Servizio Cloud Run | 99,95% | 21,6 minuti |
| Servizi di database | SLA per l'uptime mensile | Tempo di inattività massimo stimato in un mese di 30 giorni |
|---|---|---|
| Istanza Cloud SQL per PostgreSQL (Enterprise Edition) | 99,95% | 21,6 minuti |
| Istanza AlloyDB per PostgreSQL | 99,99% | 4,3 minuti |
| Istanza Spanner multiregionale | 99,999% | 26 secondi |
Per gli SLA di altri servizi Google Cloud , consulta gli accordi sul livello del servizio.Google Cloud
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 carico di lavoro 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 zone, la disponibilità delle risorse che puoi aspettarti da quel gruppo è superiore allo SLA di uptime di ogni risorsa del gruppo. Google Cloud 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 singoldominio in errorere abbiano un errore coordinato.
Ad esempio, se lo SLA (accordo sul livello del servizio) di disponibilità 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à target della località di deployment: 99,9% se le risorse si trovano in una singola zonaGoogle Cloud , 99,99% per un deployment multizona e 99,999% se le risorse ridondanti sono distribuite in più regioni.
Profondità dello stack
La profondità di uno stack dell'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 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 multilivello è 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 si presume che ogni livello offra 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 intermedio | – | 99,9% | 99,9% |
| Livello dei dati | – | – | 99,9% |
| Disponibilità aggregata dello stack | 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 Google Cloud risorsa 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 anche considerare i potenziali effetti su complessità operativa, latenza e costi.
- Il numero di livelli in uno stack di 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 singola 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 posizioni
L'ambito della località di una risorsa Google Cloud 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 Google Kubernetes Engine (GKE), puoi scegliere di creare un cluster GKE zonale o regionale.
Le sezioni seguenti descrivono gli ambiti della posizione in modo più dettagliato.
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 di zona. Questo elenco non è esaustivo.
- VM Compute Engine
- Gruppi di istanze gestite (MIG) a livello di zona
- Dischi permanenti a livello di zona
- Cluster GKE a zona singola
- Istanze Filestore Basic e zonali
- Job Dataflow
- Istanze Cloud SQL
- Cluster Dataproc 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 in genere 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 maggiori informazioni, consulta Progettare un'infrastruttura affidabile per i carichi di lavoro in Google Cloud.
Risorse di regione
Le risorse regionali vengono implementate 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
- Dischi permanenti a livello di regione
- Cluster GKE regionali con la configurazione predefinita (multi-zona)
- 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 in più regioni
Le risorse multiregionali sono distribuite in regioni specifiche. Di seguito sono riportati alcuni esempi di risorse multiregionali. Questo elenco non è esaustivo.
- Bucket Cloud Storage con due e più regioni
- Istanze Spanner multiregionali
- Istanze Bigtable multi-cluster (multi-regione)
- Portachiavi 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 Scegliere 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
Portachiavi 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 su un'infrastruttura in 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 seguente tabella riassume la resilienza relativa delle risorse a livello di zona, regione, 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 | Consigli 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. |
| Più regioni o globale | Alta | Gestisci attentamente le modifiche e utilizza i fallback di difesa in profondità ove possibile. Per ulteriori informazioni, vedi Suggerimenti 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 ai guasti fisici. La configurazione di queste risorse è a livello globale. Pertanto, configurare e impostare 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ò causare la sua mancata disponibilità in tutte le aree geografiche. Per evitare questo rischio, devi gestire con attenzione 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 che hanno requisiti di disponibilità eccezionalmente elevati, i fallback defense-in-depth 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 a livello di regione. 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.
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 HTTP/S esterno globale riceve le richieste 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, il database viene sottoposto a backup automatico 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 zone e regioni:
| 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 zone e regioni. |
| Subnet | Le subnet VPC sono risorse a livello di regione. Sono resilienti alle interruzioni di zona. |
| Bilanciatore del carico HTTP/S esterno globale | I bilanciatori del carico HTTP/S esterni globali sono resilienti alle interruzioni di zona e regione. |
| MIG regionale | I MIG a livello di regione 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 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 primaria-standby di
istanze di database. Il database primario viene replicato in modo sincrono
nel database di standby utilizzando dischi permanenti regionali.
|
| Bucket Cloud Storage multiregionale | I dati archiviati nei bucket Cloud Storage multiregionali sono resilienti alle interruzioni di una singola regione. |
| Dischi permanenti | I dischi permanenti possono essere a livello di zona o di regione. I dischi permanenti a livello di regione sono resilienti alle interruzioni di zona. Per prepararti al recupero da interruzioni della regione, puoi pianificare snapshot di dischi permanenti e archiviarli in un bucket Cloud Storage multiregionale. |