I servizi di infrastruttura di Google Cloud vengono eseguiti in località in tutto il mondo. Le località sono suddivise in domini di errore chiamati regioni e zone, che sono i componenti di base per progettare 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 è 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à superiore a quello fornito da ciascun dominio in errore.
Questa parte della guida all'affidabilità dell'infrastruttura Google Cloud descrive i componenti di base dell'affidabilità in Google Cloud e in che modo incidono sulla disponibilità delle risorse cloud.
Aree geografiche e zone
Le regioni sono aree geografiche indipendenti costituite da zone. Le zone e le regioni sono astrattive logiche delle risorse fisiche sottostanti. Una regione è composta da tre o più zone ospitate in tre o più data center fisici. Le regioni Messico, Osaka e Montréal hanno tre zone in uno o due data center fisici. Queste regioni sono in fase di espansione in almeno tre data center fisici. Quando architetti le tue soluzioni in Google Cloud, tieni conto delle indicazioni riportate in Località cloud, SLA (accordi sul livello del servizio) della piattaforma Google Cloud, e nella documentazione del prodotto Google Cloud appropriata.
Disponibilità della piattaforma
L'infrastruttura Google Cloud è progettata per tollerare e recuperare da errori. Google investe continuamente 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 tuoi carichi di lavoro cloud:
- Regioni geograficamente separate per mitigare gli effetti di calamità naturali e interruzioni a livello di regione sui servizi globali.
- Redundanza e replica 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 sicura "by design" per l'infrastruttura fisica e il software su cui viene eseguito Google Cloud, nonché controlli di sicurezza operativa per proteggere i dati e i carichi di lavoro. Per ulteriori informazioni, consulta la Panoramica sulla progettazione della sicurezza dell'infrastruttura Google.
- Una rete backbone ad alte prestazioni che utilizza un approccio avanzato di networking software-defined (SDN) alla gestione della rete, 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 dashboard di Google Cloud Service Health.
- Eventi di test di ripristino di emergenza (DiRT) annuali a livello di azienda per garantire che i servizi Google Cloud e le operazioni aziendali interne continuino a funzionare durante un disastro.
- Un approccio di gestione del cambiamento che enfatizza l'affidabilità in tutte le fasi del ciclo di vita dello sviluppo del software per eventuali modifiche alla piattaforma e ai servizi Google Cloud.
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 | % di disponibilità (tempo di attività) | 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 nove: 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) relativi all'uptime per servizi Google Cloud specifici potrebbero essere diversi da questi obiettivi di disponibilità. Ad esempio, il SLA di uptime per un'istanza Bigtable dipende dal numero di cluster, dalla loro distribuzione nelle località e dal criterio di routing che configuri.
Lo SLA di uptime minimo per un'istanza Bigtable con cluster in tre o più regioni è del 99,999% se è configurato il criterio di routing a cluster multipli. Tuttavia, se è 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 istanze Bigtable con dimensioni del cluster diverse e le conseguenti differenze negli SLA di uptime.
Cluster singolo
Il seguente diagramma mostra un'istanza Bigtable a cluster singolo con uno SLA di tempo di attività 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 di uptime minimo: 99,99%):
Più cluster
Il seguente diagramma mostra un'istanza Bigtable multi-cluster in tre regioni con routing a cluster multipli (SLA di uptime minimo: 99, 999%):
Disponibilità dell'infrastruttura aggregata
Per eseguire le tue applicazioni in Google Cloud, utilizzi risorse di infrastruttura come VM e database. Queste risorse di infrastruttura costituiscono insieme lo stack dell'infrastruttura della tua applicazione.
Il seguente diagramma mostra un esempio di un'infrastruttura in Google Cloud e l'accordo sul livello del servizio (SLA) di 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 (MIG) regionale è il backend per il bilanciatore del carico delle applicazioni esterno regionale. Il gruppo di istanze gestite 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 di applicazioni.
- Un secondo gruppo di istanze gestite regionale è il backend per il bilanciatore del carico interno. Questo gruppo di istanze gestite ha due VM 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 di database principale viene replicata in modo sincrono in un'istanza di database di riserva.
La disponibilità aggregata che puoi aspettarti da uno stack di infrastruttura come quello dell'esempio precedente dipende dai seguenti fattori:
SLA (accordi sul livello del servizio) di Google Cloud
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 seguenti tabelle presentano un confronto degli SLA di uptime per alcuni servizi:
| Servizi di calcolo | SLA per il tempo di attività mensile | Tempo di riposo 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 il tempo di attività mensile | Tempo di riposo massimo stimato in un mese di 30 giorni |
|---|---|---|
| Instanza Cloud SQL per PostgreSQL (versione Enterprise) | 99,95% | 21,6 minuti |
| Instanza AlloyDB per PostgreSQL | 99,99% | 4,3 minuti |
| Istanze Spanner multiregione | 99,999% | 26 secondi |
Per gli SLA di 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 di infrastruttura. Per aumentare la disponibilità prevista di un carico di lavoro di cui è stato eseguito il deployment in 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 indica 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, puoi eseguire il provisioning di un gruppo di istanze gestite contenente più VM Compute Engine identiche.
Se distribuisci un gruppo di risorse in modo ridondante su più domini di errore, ad esempio due zone Google Cloud, la disponibilità delle risorse che puoi aspettarti da questo gruppo è superiore allo SLA di uptime di ogni risorsa nel gruppo. Questa maggiore disponibilità è dovuta al fatto che la probabilità che tutte le risorse del gruppo si guastino 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) di 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 su due istanze di questa risorsa di cui è stato eseguito il provisioning in domini di errore distinti, la probabilità che entrambe le risorse non funzionino contemporaneamente è 0,000001 (ovvero 0,001 x 0,001). Questa probabilità di guasto 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 posizione di implementazione: 99,9% se le risorse si trovano in una singola zona Google Cloud, 99,99% per un'implementazione multizona e 99,999% se le risorse ridondanti sono distribuite su più regioni.
Profondità dello stack
La profondità di uno stack di infrastruttura è il numero di livelli (o livelli) distinti nello stack. Ogni livello in uno stack di infrastruttura contiene risorse che forniscono una funzione distinta per l'applicazione. Ad esempio, il livello intermedio di uno stack a tre livelli potrebbe utilizzare VM Compute Engine o un cluster GKE per ospitare i server delle applicazioni. Ogni livello di un livello di infrastruttura ha in genere una stretta interdipendenza con i livelli adiacenti. Ciò significa che se un livello della pila non è disponibile, l'intera pila diventa non disponibile.
Puoi calcolare la disponibilità aggregata prevista di uno stack di infrastrutture 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 è approssimativamente del 99,7% (0,999 x 0,999 x 0,999). Ciò significa che la disponibilità aggregata di un livello è inferiore alla disponibilità del livello che offre la dispositività minima.
Con l'aumento del numero di livelli interdipendenti in uno stack, la disponibilità aggregata dello stack diminuisce, come mostrato nella tabella seguente. Ogni impostazione di esempio nella tabella ha un numero diverso di livelli e si presume che ogni livello offra una disponibilità del 99,9%.
| Livello | Pila A | Pila B | Pila 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 riposo massimo stimato dello stack in un mese di 30 giorni | 86 minuti | 130 minuti | 173 minuti |
Riepilogo delle considerazioni sul design
Quando progetti le tue applicazioni, considera la disponibilità aggregata dello stack dell'infrastruttura Google Cloud.
- La disponibilità di ogni risorsa Google Cloud nello stack dell'infrastruttura influisce sulla disponibilità aggregata dello stack. Quando scegli i servizi Google Cloud per creare il tuo stack di infrastruttura, prendi in considerazione lo SLA di 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 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 la tua suite.
Per esempi di calcolo della disponibilità aggregata, consulta le seguenti sezioni:
- Calcolo di esempio: implementazione a zona singola
- Calcolo di esempio: deployment multizona
- Calcolo di esempio: implementazione multiregione con bilanciamento del carico a livello di regione
- Calcolo di esempio: deployment multiregione con bilanciamento del carico globale
Ambiti di località
L'ambito della località di una risorsa Google Cloud determina l'entità in cui un errore dell'infrastruttura può influire sulla risorsa. La maggior parte delle risorse che provisioni in Google Cloud ha uno dei seguenti ambiti di località: zonale, regionale, multiregionale o globale.
L'ambito geografico di alcuni tipi di risorse è fisso, ovvero non puoi scegliere o modificare l'ambito geografico. Ad esempio, le reti Virtual Private Cloud (VPC) sono risorse globali, mentre le macchine virtuali (VM) Compute Engine sono risorse zonali. 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 in modo più dettagliato gli ambiti di località.
Risorse di zona
Le risorse di zona vengono implementate all'interno di un'unica zona in una regione Google Cloud. Di seguito sono riportati alcuni esempi di risorse zonali. Questo elenco non è completo.
- VM Compute Engine
- Gruppi di istanze gestite zonali (MIG)
- Dischi permanenti a livello di zona
- Cluster GKE a zona singola
- Istanze Filestore di base e zonali
- Job Dataflow
- Istanze Cloud SQL
- Cluster Dataproc su Compute Engine
Un errore in una zona potrebbe influire sulle risorse di zona di cui è stato eseguito il provisioning in 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 delle altre zone della regione. Inoltre, un guasto in una zona non comporta necessariamente la mancata disponibilità di tutta l'infrastruttura in quella zona. La zona definisce semplicemente il confine previsto per l'effetto di un guasto.
Per proteggere le applicazioni che utilizzano risorse a livello di zona dagli 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 regionali
Le risorse di regione vengono distribuite tramite deployment in modo ridondante in più zone all'interno di una regione. Di seguito sono riportati alcuni esempi di risorse regionali. 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 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 di regione sono resilienti agli incidenti in una zona specifica. Un tempo di inattività della regione può interessare alcune o tutte le risorse regionali di cui è stato eseguito il provisioning all'interno della regione. Queste interruzioni possono essere causate da calamità naturali o da guasti dell'infrastruttura su larga scala.
Risorse multiregione
Le risorse multi-regione sono distribuite in regioni specifiche. Di seguito sono riportati alcuni esempi di risorse multiregione. Questo elenco non è esaustivo.
- Bucket Cloud Storage con due regioni e su più regioni
- Istanze Spanner multiregione
- Istanze Bigtable multi-cluster (multi-regione)
- Portachiavi multiregione in Cloud Key Management Service
Per un elenco completo dei servizi Google disponibili nelle configurazioni multiregione, consulta Prodotti disponibili per località.
Le risorse multiregione 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 multi-regione di cui è stato eseguito il provisioning nelle regioni interessate.
Risorse globali
Le risorse globali sono disponibili in tutte le località di Google Cloud. Di seguito sono riportati alcuni esempi di risorse globali. Questo elenco non è esaustivo.
progetti e pagano per i progetti. Per indicazioni e best practice su come organizzare le risorse Google Cloud in cartelle e progetti, consulta Decidere una gerarchia delle risorse per la zona di destinazione Google Cloud.
Reti VPC, incluse route e regole del 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 zonali e regionali. 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. Inoltre, Google monitora continuamente l'infrastruttura e risolve rapidamente eventuali interruzioni globali.
La tabella seguente riassume la resilienza relativa delle risorse zonali, regionali, su più regioni e globali ai problemi di applicazioni e infrastruttura. Inoltre, descrive lo sforzo necessario per configurare queste risorse e i consigli per mitigare gli effetti delle interruzioni.
| Ambito risorsa | Resilienza | Consigli per ridurre al minimo 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 | Medio | Esegui il deployment delle risorse in modo ridondante in più regioni. |
| Multiregionale o globale | Alta | Gestisci attentamente le modifiche e, se possibile, utilizza strategie di difesa in profondità. Per ulteriori informazioni, consulta Consigli per gestire il rischio di interruzioni delle risorse globali. |
Consigli per gestire il rischio di interruzioni delle risorse globali
Per sfruttare la resilienza delle risorse globali alle interruzioni di zone e regioni, ti consigliamo di utilizzare 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, la configurazione e la gestione di una singola risorsa globale è più semplice rispetto all'utilizzo di più risorse regionali. Tuttavia, un errore critico nella configurazione di una risorsa globale potrebbe renderla un singolo punto di défaillance (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 indisponibilità in tutte le aree geografiche. Per evitare questo rischio, devi gestire attentamente le modifiche alla configurazione delle risorse globali. Per ulteriori informazioni, consulta Controllare le modifiche alle risorse globali.
Utilizzo di risorse regionali come alternative di difesa in profondità
Per le applicazioni con requisiti di disponibilità eccezionalmente elevati, le strategie di riserva regionale di difesa in profondità possono contribuire a ridurre al minimo l'effetto delle interruzioni delle risorse globali. Prendi ad esempio un'applicazione geograficamente distribuita che ha un bilanciatore del carico globale come frontend. Per assicurarti che l'applicazione rimanga accessibile anche se il bilanciatore del carico globale è interessato da un'interruzione globale, puoi implementare 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 regionale più vicino se il bilanciatore del carico globale non è disponibile.
Architettura di esempio con risorse a livello di zona, di regione e globali
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 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 Compute Engine. L'applicazione in esecuzione sulle VM scrive e legge dati da un database Cloud SQL. Il database è configurato per l'alta disponibilità. Le istanze principali e di standby del database vengono provisionate in zone separate e il database principale viene replicato in modo sincrono nel database di standby. Inoltre, il backup del database viene eseguito automaticamente in un bucket multiregione in Cloud Storage.
La tabella seguente riassume le risorse Google Cloud nell'architettura precedente e la resilienza di ogni risorsa alle interruzioni di zone e regioni:
| Risorsa | Resilienza alle interruzioni |
|---|---|
| Rete VPC | Le reti VPC, route associate e regole del firewall incluse, sono risorse globali. Sono resilienti alle interruzioni di zone e regioni. |
| Subnet | Le subnet VPC sono risorse a livello di area geografica. Sono resilienti alle interruzioni di servizio nelle zone. |
| Bilanciatore del carico HTTP/S esterno globale | I bilanciatori del carico HTTP/S esterni globali sono resilienti alle interruzioni di zone e regioni. |
| Gruppo di istanze gestite a livello di regione | I MIG a livello di area geografica sono resilienti alle interruzioni delle zone. |
| VM Compute Engine | Le VM Compute Engine sono risorse zonali. Se si verifica un'interruzione del servizio in una zona, le singole VM Compute Engine potrebbero essere interessate. Tuttavia, l'applicazione può continuare a gestire le richieste perché il backend per il 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 di istanze di database principali e di standby. Il database principale viene replicato in modo sincrono
nel database di standby utilizzando i dischi permanenti a livello di area geografica.
|
| Bucket Cloud Storage multiregionale | I dati archiviati nei bucket Cloud Storage a più regioni sono resilienti alle interruzioni in 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 del servizio nelle zone. Per prepararti al recupero dalle interruzioni di servizio nelle regioni, puoi pianificare gli snapshot dei dischi permanenti e archiviarli in un bucket Cloud Storage multiregionale. |