I servizi di infrastruttura di Google Cloud vengono eseguiti in località in tutto il mondo. Le località sono divise in domini in errore chiamati regioni e zone, che sono i componenti di base di base per la progettazione di un'infrastruttura affidabile per i carichi di lavoro cloud.
Un dominio in errore è una risorsa o un gruppo di risorse che possono restituire errori indipendentemente dalle altre. 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 in errore, può raggiungere un livello aggregato di disponibilità più elevato rispetto a quello fornito da ciascun dominio in errore.
Questa parte della guida all'affidabilità dell'infrastruttura di Google Cloud descrive i componenti di base dell'affidabilità in Google Cloud e come influiscono sulla disponibilità delle tue risorse cloud.
Aree geografiche e zone
Le regioni di Google Cloud sono località geografiche indipendenti. Ogni regione Google Cloud contiene più zone. È improbabile che un guasto in una zona influisca sull'infrastruttura nelle altre zone. Una dorsale di rete globale fornisce connettività a bassa latenza e a larghezza di banda elevata in tutte le zone e le regioni di Google Cloud.
Disponibilità delle piattaforme
L'infrastruttura di Google Cloud è progettata per tollerare e riprendersi dai guasti. Google investe costantemente in approcci innovativi per mantenere e migliorare l'affidabilità di Google Cloud. Le seguenti funzionalità dell'infrastruttura Google Cloud contribuiscono a fornire una piattaforma affidabile per i carichi di lavoro cloud:
- Regioni separate geograficamente per mitigare gli effetti di disastri naturali e interruzioni delle 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 di Compute Engine possono essere spostate su un altro host nella stessa zona utilizzando la migrazione live.
- Una base di infrastruttura secure-by-design per l'infrastruttura fisica e il software su cui viene eseguito Google Cloud, nonché per i controlli di sicurezza operativi per proteggere i dati e i carichi di lavoro. Per ulteriori informazioni, consulta la panoramica sulla progettazione della sicurezza dell'infrastruttura di Google.
- Una rete backbone ad alte prestazioni che utilizza un approccio avanzato di networking software-defined per la gestione della rete, con servizi di memorizzazione in una cache perimetrale per offrire prestazioni coerenti e scalabili.
- Monitoraggio e reporting continui. Puoi visualizzare lo stato dei servizi Google Cloud in ogni località utilizzando la dashboard di integrità dei servizi Google Cloud.
- Eventi annuali di test di ripristino di emergenza (DiRT) a livello aziendale per garantire che i servizi Google Cloud e le operazioni aziendali interne continuino a essere eseguiti durante un'emergenza.
L'infrastruttura Google Cloud è progettata per supportare i seguenti livelli di disponibilità target per la maggior parte dei carichi di lavoro dei clienti:
| Località di deployment | % disponibilità (tempo di attività) | Tempo di inattività massimo stimato |
|---|---|---|
| Zona singola | 3 nove: 99,9% | 43,2 minuti in un mese di 30 giorni |
| Più zone in un'area geografica | 4 nove: 99,99% | 4,3 minuti in un mese di 30 giorni |
| Più aree geografiche | 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) di uptime per specifici servizi Google Cloud potrebbero essere diversi da questi target di disponibilità. Ad esempio, lo SLA (accordo sul livello del servizio) di uptime per un'istanza Bigtable dipende dal numero di cluster, dalla loro distribuzione tra le località e dal criterio di routing che configuri.
Lo SLA (accordo sul livello del servizio) 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 viene configurato il criterio di routing a cluster singolo, lo SLA (accordo sul livello del servizio) con uptime minimo è del 99,9%, indipendentemente dal numero di cluster e dalla loro distribuzione.
I diagrammi in questa sezione mostrano le istanze Bigtable con diverse dimensioni dei cluster e le conseguenti differenze negli SLA (accordi sul livello del servizio) con uptime.
Cluster singolo
Il seguente diagramma mostra un'istanza Bigtable a cluster singolo, con uno SLA con uptime minimo del 99,9%:
Più cluster
Il seguente diagramma mostra un'istanza Bigtable multi-cluster in più zone all'interno di una singola regione, con routing a cluster multipli (SLA con uptime minimo: 99,99%):
Più cluster
Il seguente diagramma mostra un'istanza Bigtable multi-cluster in tre regioni, con routing multi-cluster (SLA con uptime minimo: 99,999%):
Disponibilità aggregata dell'infrastruttura
Per eseguire le tue applicazioni in Google Cloud, utilizzi risorse di infrastruttura come VM e database. Queste risorse di infrastruttura, insieme, costituiscono lo stack di infrastruttura dell'applicazione.
Il seguente diagramma mostra un esempio di stack di infrastruttura in Google Cloud e lo SLA (accordo sul livello del servizio) relativo alla disponibilità per ogni risorsa nello stack:
Questo stack di infrastruttura di esempio include le seguenti risorse Google Cloud:
- Un bilanciatore del carico delle applicazioni esterno regionale riceve e risponde alle richieste degli utenti.
- Un gruppo di istanze gestite a livello di regione è il backend per l'Application Load Balancer esterno regionale. Il gruppo di istanze gestite contiene due VM di 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 applicazioni.
- Un secondo gruppo di istanze gestite a livello di regione è il backend per il bilanciatore del carico interno. Questo gruppo di istanze gestite ha due VM di Compute Engine in zone diverse. Ogni VM ospita un'istanza di un server di applicazioni.
- Un'istanza Cloud SQL configurata per l'alta disponibilità è il database per l'applicazione. L'istanza del database principale 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:
SLA di Google Cloud
Gli SLA (accordi sul livello del servizio) relativi all'uptime dei servizi Google Cloud che utilizzi nello stack di infrastruttura influiscono sulla disponibilità aggregata minima che puoi aspettarti dallo stack.
Le seguenti tabelle mostrano un confronto degli SLA con uptime per alcuni servizi:
| Servizi di computing | SLA (accordo sul livello del servizio) mensile per il tempo di attività | 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 (accordo sul livello del servizio) mensile per il tempo di attività | Tempo di inattività massimo stimato in un mese di 30 giorni |
|---|---|---|
| Istanza Cloud SQL per PostgreSQL (versione Enterprise) | 99,95% | 21,6 minuti |
| Istanza AlloyDB per PostgreSQL | 99,99% | 4,3 minuti |
| Istanza Spanner multiregionale | 99,999% | 26 secondi |
Per gli SLA (accordi sul livello del servizio) degli altri servizi Google Cloud, consulta gli accordi sul livello del servizio di Google Cloud.
Come mostrano le tabelle precedenti, i servizi Google Cloud che scegli per ogni livello dello stack di 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
Ridondanza delle risorse significa provisioning di due o più istanze identiche di una risorsa e deployment dello stesso carico di lavoro su tutte le risorse del gruppo. Ad esempio, per ospitare il livello web di un'applicazione, puoi eseguire il provisioning di un gruppo di istanze gestite contenente più VM di Compute Engine identiche.
Se distribuisci un gruppo di risorse in modo ridondante su più domini con errori, ad esempio due zone Google Cloud, la disponibilità delle risorse che puoi aspettarti da quel gruppo è superiore allo SLA (accordo sul livello del servizio) con uptime di ogni risorsa del gruppo. Questa disponibilità più elevata si verifica perché la probabilità che ogni risorsa del gruppo si guasti nello stesso momento è inferiore alla probabilità che le risorse in un singolo dominio in errore abbiano un errore coordinato.
Ad esempio, se lo SLA (accordo sul livello del servizio) con disponibilità per una risorsa è del 99,9%, la probabilità che la risorsa non funzioni è 0,001 (1 meno lo SLA). Se distribuisci un carico di lavoro in due istanze di questa risorsa di cui è stato eseguito il provisioning in domini di errore separati, la probabilità che entrambe le risorse abbiano esito negativo è 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 prevista è limitata alla disponibilità target della località di deployment: 99,9% se le risorse si trovano in una singola zona Google 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 di infrastruttura equivale al numero di livelli (o livelli) distinti nello stack. Ogni livello dello stack di infrastruttura contiene risorse che forniscono una funzione distinta per l'applicazione. Ad esempio, il livello intermedio in uno stack a tre livelli potrebbe utilizzare le VM di Compute Engine o un cluster GKE per ospitare i server delle applicazioni. Ogni livello di uno stack di infrastruttura ha in genere una stretta interdipendenza con i livelli adiacenti. Ciò significa che se uno o più livelli dello stack non è disponibile, l'intero stack diventa non disponibile.
Puoi calcolare la disponibilità aggregata prevista di uno stack di infrastruttura di livello N utilizzando la formula seguente:
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 a più livelli è inferiore alla disponibilità del livello che fornisce la disponibilità minima.
All'aumento del numero di livelli interdipendenti in uno stack, la disponibilità aggregata dello stack diminuisce, come mostrato nella tabella seguente. Ogni stack di esempio nella tabella ha un numero diverso di livelli. Per un facile confronto, si presume che ogni livello offra una disponibilità del 99,9%.
| Livello | Gruppo A | Gruppo B | Gruppo C |
|---|---|---|---|
| Frontend | 99,9% | 99,9% | 99,9% |
| Livello di applicazioni | 99,9% | 99,9% | 99,9% |
| Livello intermedio | – | 99,9% | 99,9% |
| Livello 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 di infrastruttura di Google Cloud.
- La disponibilità di ogni risorsa Google Cloud nello stack di infrastruttura influisce sulla disponibilità aggregata dello stack. Quando scegli i servizi Google Cloud per creare il tuo stack di infrastruttura, considera lo SLA (accordo sul livello del servizio) della disponibilità dei servizi.
- Per migliorare la disponibilità della funzione (ad esempio calcolo o 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 sulla complessità operativa, sulla latenza e sui 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. Considera questa relazione quando progetti o modifichi il tuo stack.
Per i calcoli di esempio di disponibilità aggregata, consulta le seguenti sezioni:
- Esempio di calcolo: deployment a zona singola
- Esempio di calcolo: deployment multizona
- Esempio di calcolo: deployment in più regioni con bilanciamento del carico a livello di regione
- Esempio di calcolo: deployment in più regioni con bilanciamento del carico globale
Ambiti di località
L'ambito della località di una risorsa Google Cloud determina la misura in cui un errore dell'infrastruttura può interessare la risorsa. La maggior parte delle risorse di cui esegui il provisioning in Google Cloud ha uno dei seguenti ambiti di località: a livello di zona, a livello di regione, multiregionale o globale.
L'ambito relativo alla 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) Compute Engine sono risorse di zona. Per determinate 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 a livello di zona o di regione.
Le seguenti sezioni descrivono gli ambiti delle località in modo più dettagliato.
Risorse di zona
Il deployment delle risorse di zona viene eseguito all'interno di una singola zona in una regione Google Cloud. Di seguito sono riportati alcuni esempi di risorse di zona. Questo elenco non è completo.
- VM Compute Engine
- Gruppi di istanze gestite a livello di zona (MIG)
- Dischi permanenti a livello di zona
- Cluster GKE a zona singola
- Istanze Filestore Basic e di zona
- Job Dataflow
- Istanze Cloud SQL
- Cluster Dataproc su Compute Engine
Un errore in una zona potrebbe influire sulle risorse di zona di cui viene eseguito il provisioning all'interno di quella zona. Le zone sono progettate per ridurre al minimo il rischio di guasti 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 rende necessariamente non disponibile tutte l'infrastruttura in quella zona. La zona definisce semplicemente il confine previsto per l'effetto di un errore.
Per proteggere le applicazioni che utilizzano risorse di zona, puoi distribuire o replicare le risorse su più zone o regioni. Per saperne di più, consulta Progettare un'infrastruttura affidabile per i carichi di lavoro in Google Cloud.
Risorse a livello di regione
Il deployment delle risorse di regione viene eseguito in modo ridondante in più zone all'interno di un'area geografica. Di seguito sono riportati alcuni esempi di risorse di regione. Questo elenco non è completo.
- MIG a livello di area geografica
- Bucket Cloud Storage regionali
- Dischi permanenti a livello di regione
- Cluster GKE a livello di regione con configurazione predefinita (multizona)
- Subnet VPC
- Bilanciatori del carico delle applicazioni esterni regionali
- Istanze Spanner a livello di regione
- Istanze Filestore Enterprise
- Servizi Cloud Run
Le risorse di regione sono resilienti agli incidenti in una zona specifica. Un'interruzione della regione può interessare alcune o tutte le risorse a livello di regione di cui è stato eseguito il provisioning in quella regione. Tali interruzioni possono essere causate da calamità naturali o da guasti dell'infrastruttura su larga scala.
Risorse in più regioni
Le risorse in più regioni sono distribuite in regioni specifiche. Di seguito sono riportati alcuni esempi di risorse multiregionali. Questo elenco non è completo.
- Bucket Cloud Storage a due e più regioni
- Istanze Spanner multiregionali
- Istanze Bigtable multi-cluster (più regioni)
- Keyring multiregionali in Cloud Key Management Service
Per un elenco completo dei servizi Google disponibili nelle configurazioni multiregionali, vedi Prodotti disponibili per località.
Le risorse su più regioni 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 viene eseguito il provisioning nelle regioni interessate.
Risorse globali
Sono disponibili risorse globali in tutte le località Google Cloud. Di seguito sono riportati alcuni esempi di risorse globali. Questo elenco non è completo.
progetti e pagano per i progetti. Per indicazioni e best practice sull'organizzazione delle risorse Google Cloud in cartelle e progetti, consulta Decidere una gerarchia delle risorse per la tua zona di destinazione Google Cloud.
Reti VPC, incluse route e regole firewall associate
Zone Cloud DNS
Bilanciatori del carico delle applicazioni esterni globali
Keyring globali in Cloud Key Management Service
argomenti Pub/Sub
Secret in Secret Manager
Per un elenco completo dei servizi Google disponibili a livello globale, vedi Prodotti globali.
Le risorse globali sono resilienti agli incidenti a livello di zona e regione. Queste risorse non si basano sull'infrastruttura in nessuna regione specifica. Google Cloud dispone di sistemi e processi che consentono di ridurre al minimo il rischio di interruzioni dell'infrastruttura globali. Inoltre, Google monitora costantemente l'infrastruttura e risolve rapidamente eventuali interruzioni.
La seguente tabella riassume la resilienza relativa delle risorse a livello di zona, a livello di regione, multiregionale e globale ai problemi relativi ad applicazioni e infrastruttura. Viene inoltre descritto l'impegno necessario per configurare queste risorse e i suggerimenti per mitigare gli effetti delle interruzioni.
| Ambito risorsa | Resilienza | Consigli per mitigare gli effetti delle interruzioni dell'infrastruttura |
|---|---|---|
| Zonale | Bassa | Esegui il deployment delle risorse in modo ridondante in più zone o aree geografiche. |
| Regionale | Medio | Esegui il deployment delle risorse in modo ridondante in più regioni. |
| Più regioni o globale | Alta | Gestisci le modifiche con attenzione e, ove possibile, utilizza i fallback di difesa in profondità. Per maggiori informazioni, consulta i 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 zone e regioni, puoi considerare l'utilizzo di alcune risorse globali nella tua architettura. Google consiglia i seguenti approcci per gestire il rischio di interruzioni delle risorse globali:
Gestione accurata delle modifiche alle risorse globali
Le risorse globali sono resilienti ai guasti fisici. La configurazione di queste risorse ha un ambito globale. Pertanto, impostare e configurare un'unica risorsa globale è più facile che gestire più risorse a livello di regione. Tuttavia, un errore critico nella configurazione di una risorsa globale potrebbe trasformarla in un single point of failure (SPOF). Ad esempio, potresti 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ò causarne la mancata disponibilità in tutte le aree geografiche. Per evitare questo rischio, devi gestire attentamente le modifiche alla configurazione delle risorse globali. Per maggiori informazioni, consulta Controllare le modifiche alle risorse globali.
Uso di risorse regionali come fallback di difesa in profondità
Per le applicazioni con requisiti di disponibilità eccezionalmente elevata, i sistemi di riserva per la difesa in profondità a livello di regione possono aiutare a ridurre al minimo l'effetto delle interruzioni delle risorse globali. Prendiamo come esempio un'applicazione distribuita geograficamente con 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 dei bilanciatori del carico a livello di regione. Puoi configurare i client in modo che preferiscano il bilanciatore del carico globale, ma esegui il failover al bilanciatore del carico a livello di regione più vicino se il bilanciatore del carico globale non è disponibile.
Architettura di esempio con risorse a livello di zona, di regione e globale
La topologia cloud può includere una combinazione di risorse a livello di zona, di regione e globali, come illustrato nel diagramma seguente. Il seguente diagramma mostra un'architettura di esempio per un'applicazione multi-livello di cui è stato eseguito il deployment in Google Cloud.
Come mostrato nel diagramma precedente, un bilanciatore del carico HTTP/S esterno globale riceve le richieste dei client. Il bilanciatore del carico distribuisce le richieste al backend, ovvero un gruppo di istanze gestite a livello di regione con due VM di Compute Engine. L'applicazione in esecuzione sulle VM scrive i dati e legge da un database Cloud SQL. Il database è configurato per l'alta disponibilità. Il provisioning delle istanze primarie e in standby del database viene eseguito in zone separate e il database primario 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 seguente tabella riassume le risorse Google Cloud nell'architettura precedente e la resilienza di ogni risorsa in caso di interruzioni di zone e regioni:
| Risorsa | Resistenza alle interruzioni |
|---|---|
| Rete VPC | Le reti VPC, incluse le route e le regole firewall associate, sono risorse globali. Sono resilienti in caso di interruzioni di zone e regioni. |
| Subnet | Le subnet VPC sono risorse a livello di regione. Sono resilienti alle interruzioni delle zone. |
| Bilanciatore del carico HTTP/S esterno globale | I bilanciatori del carico HTTP/S esterni globali sono resilienti in caso di interruzioni di zone e regioni. |
| MIG a livello di regione | I gruppi di istanze gestite a livello di regione sono resilienti alle interruzioni delle zone. |
| VM Compute Engine | Le VM di Compute Engine sono risorse di zona. Un'interruzione di una zona potrebbe influire sulle singole VM di Compute Engine. Tuttavia, l'applicazione può continuare a gestire le richieste perché il backend per il bilanciatore del carico è un gruppo di istanze gestite a livello di regione e non di VM autonome. |
| Istanze Cloud SQL | Il deployment di Cloud SQL in questa architettura è configurato per l'alta disponibilità, ovvero il deployment include una coppia principale di istanze di database in standby. Il database primario viene replicato in modo sincrono nel database in standby utilizzando dischi permanenti a livello di regione.
|
| Bucket Cloud Storage per più regioni | I dati archiviati in bucket Cloud Storage multiregionali sono resilienti in caso di 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 in caso di interruzioni della zona. Per prepararti al ripristino in caso di interruzioni delle regioni, puoi pianificare snapshot di dischi permanenti e archiviarli in un bucket Cloud Storage a più regioni. |