I servizi di infrastruttura di Google Cloud vengono eseguiti in località in tutto il mondo. Le località sono suddivise in domini in errore chiamati regioni e zone. che sono i componenti di base fondamentali 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ò generare errori indipendentemente da altre risorse. Una VM autonoma di Compute Engine è un esempio di una risorsa che è un dominio in errore. Una regione o una zona Google Cloud è esempio di dominio in errore che consiste in un gruppo di risorse. Quando distribuita in modo ridondante tra domini in errore, può raggiungere un livello aggregato di disponibilità più elevato rispetto a quello fornito da ogni errore dominio.
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 Google Cloud sono località geografiche indipendenti. Ogni regione Google Cloud contiene più zone. È improbabile che un errore in una zona influisca sull'infrastruttura nelle altre zone. Una rete globale il backbone fornisce una connettività a bassa latenza e a larghezza di banda elevata in zone e regioni Google Cloud.
Disponibilità della piattaforma
L'infrastruttura Google Cloud è progettata per tollerare errori. Google investe continuamente in approcci innovativi per mantenere e migliorare l'affidabilità di Google Cloud. Le seguenti funzionalità L'infrastruttura Google Cloud contribuisce a fornire una piattaforma affidabile carichi di lavoro cloud:
- Regioni geograficamente separate per mitigare gli effetti di calamità naturali e interruzioni a livello di regione 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, possono essere spostati in un altro host nella stessa zona migrazione live.
- Un'infrastruttura di base secure-by-design per l'infrastruttura fisica l'infrastruttura e il software su cui viene eseguito Google Cloud. di sicurezza operativa per proteggere dati e carichi di lavoro. Per maggiori informazioni le informazioni, vedi 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 dello stato dei servizi Google Cloud.
- 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.
- R approccio alla gestione dei cambiamenti che enfatizza l'affidabilità in tutte le fasi del software ciclo di sviluppo del prodotto per qualsiasi modifica alla piattaforma Google Cloud i servizi di machine learning.
L'infrastruttura Google Cloud è progettata per supportare i seguenti target livelli di disponibilità 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 | 3 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. Il tempo di attività Accordi sul livello del servizio (SLA) servizi Google Cloud specifici possono essere diversi da questi target di disponibilità. Ad esempio, SLA (accordo sul livello del servizio) di uptime per un'istanza Bigtable dipende dal numero cluster, la loro distribuzione nelle diverse località criterio di routing configurato.
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. Se invece è 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 distribuzione dei contenuti.
I diagrammi in questa sezione mostrano istanze Bigtable con le dimensioni dei cluster e le conseguenti differenze negli SLA con 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 (minimo SLA (accordo sul livello del servizio) con uptime del 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 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 di disponibilità per ogni risorsa nello stack:
Questo esempio di stack di infrastruttura include le seguenti risorse Google Cloud:
- Un bilanciatore del carico delle applicazioni esterno regionale riceve e risponde all'utente richieste.
- Un gruppo di istanze gestite a livello di regione è il backend per un bilanciatore del carico delle applicazioni esterno regionale. Il gruppo di istanze gestite contiene due VM di Compute Engine zone diverse. Ogni VM ospita un'istanza di un server web.
- Un bilanciatore del carico interno gestisce la comunicazione tra il server web e alle istanze del server delle 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 delle applicazioni.
- Un'istanza Cloud SQL configurata per l'alta disponibilità è il database un'applicazione. L'istanza di database principale viene replicata in modo sincrono in un'istanza di database di riserva.
La disponibilità aggregata che ci si aspetta da uno stack dell'infrastruttura come l'esempio precedente dipende dai seguenti fattori:
SLA di Google Cloud
Gli SLA per il tempo di attività dei servizi Google Cloud che utilizzi nelle lo stack dell'infrastruttura influenza la disponibilità minima aggregata che puoi che si aspettano dallo stack.
Le tabelle seguenti mostrano un confronto degli SLA del tempo di attività per alcuni Google Cloud:
| Servizi di calcolo | SLA (accordo sul livello del servizio) sul 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 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) sul tempo di attività mensile | Tempo di inattività massimo stimato in un mese di 30 giorni |
|---|---|---|
| Instanza Cloud SQL per PostgreSQL (versione Enterprise) | 99,95% | 21,6 minuti |
| Istanza AlloyDB per PostgreSQL | 99,99% | 4,3 minuti |
| Istanze Spanner multiregione | 99,999% | 26 secondi |
Per gli SLA (accordi sul livello del servizio) di altri servizi Google Cloud, vedi Accordi sul livello del servizio di Google Cloud.
Come mostrano le tabelle precedenti, i servizi Google Cloud che scegli per ogni livello dello stack dell'infrastruttura influiscono direttamente sul tempo di attività complessivo che puoi aspettarti dallo stack dell'infrastruttura. Per aumentare il valore previsto di un carico di lavoro di cui è stato eseguito il deployment su una risorsa Google Cloud, eseguire il provisioning di istanze ridondanti della risorsa, come descritto .
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. Per Ad esempio, per ospitare il livello web di un'applicazione, potresti eseguire il provisioning contenente più VM di Compute Engine identiche.
Se distribuisci un gruppo di risorse in modo ridondante in 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 di errore abbiano un errore coordinato.
Ad esempio, se la disponibilità garantita da SLA per una risorsa è del 99,9%, la probabilità indica che la risorsa non riesce è 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 al target disponibilità della località di deployment: 99,9% se le risorse si trovano zona Google Cloud, 99,99% per un deployment multizona e 99,999% per le risorse ridondanti sono distribuite in più regioni.
Profondità dello stack
La profondità di uno stack dell'infrastruttura è data dal numero di livelli distinti (o strati) nell'elenco filtri. Ogni livello in uno stack di infrastruttura contiene risorse che forniscono una funzione distinta per l'applicazione. Ad esempio, la parte centrale di un livello in uno stack a tre livelli potrebbe utilizzare le VM di Compute Engine o cluster GKE all'hosting dei server delle applicazioni. Ogni livello di un livello di infrastruttura ha in genere una stretta interdipendenza con i livelli adiacenti. Ciò significa che se qualsiasi livello dello stack non è disponibile, l'intero stack diventa non disponibile.
Puoi calcolare la disponibilità aggregata prevista di un livello N utilizzando la formula seguente:
Ad esempio, se ogni livello di uno stack a tre livelli è progettato per fornire il 99,9% la disponibilità aggregata dello stack è pari a circa 99,7% (0,999 x 0,999 x 0,999). Ciò significa che la disponibilità aggregata lo stack multi-livello è inferiore alla disponibilità del livello che fornisce la disponibilità minima.
Con l'aumento del numero di livelli interdipendenti in uno stack, la disponibilità aggregata dello stack diminuisce, come mostrato nella tabella seguente. Ciascuna stack di esempio nella tabella ha un numero diverso di livelli. Per facilitare il confronto, si presume che ogni livello offra il 99,9% di disponibilità.
| 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 di 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 sulla progettazione
Quando progetti le tue applicazioni, considera la disponibilità aggregata dei lo stack dell'infrastruttura Google Cloud.
- La disponibilità di ogni risorsa Google Cloud lo stack dell'infrastruttura influenza la 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, computing o fornito da una risorsa, puoi eseguire il provisioning più istanze 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à lo stack) ha una relazione inversa con la disponibilità aggregata lo stack. Prendi in considerazione questa relazione quando progetti o modifichi il tuo stack.
Ad esempio, per i calcoli della disponibilità aggregata, consulta le sezioni seguenti:
- Esempio di calcolo: deployment a zona singola
- Esempio di calcolo: 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) e le macchine virtuali (VM) Compute Engine sono a livello di zona, Google Cloud. 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
Il deployment delle risorse di zona viene eseguito all'interno di una singola zona in Google Cloud regione. Di seguito sono riportati alcuni esempi di risorse a livello di zona. Questo elenco non è esaustivi.
- 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 a livello di zona
- Job Dataflow
- Istanze Cloud SQL
- Cluster Dataproc su Compute Engine
Un errore in una zona potrebbe interessare le 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 errori correlati con altre zone della regione. Un errore in una zona di solito non influisce sulle risorse delle altre zone della regione. Inoltre, un errore in una zona non causa necessariamente tutta l'infrastruttura in quella zona non disponibile. 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 è esaustivi.
- 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 a livello di regione
- 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. Tali interruzioni possono essere causate da calamità naturali o da calamità naturali gli errori dell'infrastruttura.
Risorse multiregionali
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 in più regioni configurazioni, consulta Prodotti disponibili in base alla 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 la 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 località di Google Cloud. La 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 l'accesso alle risorse Google Cloud in cartelle e progetti, Decidi una gerarchia delle risorse per la tua zona di destinazione di 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, vedi Prodotti a livello globale.
Le risorse globali sono resilienti agli incidenti a livello di zona e di regione. Queste risorse non fanno affidamento sull'infrastruttura in nessuna 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, in più regioni e globali ai problemi di applicazioni e infrastruttura. it descrive anche l'impegno richiesto per configurare queste risorse, e per ridurre gli effetti delle interruzioni.
| Ambito risorsa | Resilienza | Consigli per mitigare gli effetti interruzioni dell'infrastruttura |
|---|---|---|
| A livello di zona | Bassa | Esegui il deployment delle risorse in modo ridondante in più zone regioni. |
| Regionale | Medio | Esegui il deployment delle risorse in modo ridondante in più regioni. |
| Più regioni o globale | Alta | Gestisci le modifiche con attenzione e utilizza i fallback di difesa in profondità ove possibile. Per ulteriori informazioni, vedi Consigli per 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 questo tipo con ambito 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 le modifiche alla configurazione in le risorse globali. Per ulteriori 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, regionale difesa in profondità possono aiutare 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 da preferire il carico globale ma il failover sul bilanciatore del carico regionale più vicino se il carico globale non è disponibile.
Architettura di esempio con risorse a livello di zona, di regione e globali
La tua topologia cloud può includere una combinazione di impostazioni a livello di zona, di regione e globali come mostrato nel diagramma seguente. Il seguente diagramma mostra un per un'applicazione multi-livello di cui viene eseguito il deployment in Google Cloud.
Come mostrato nel diagramma precedente, un bilanciatore del carico HTTP/S esterno globale riceve richieste del client. Il bilanciatore del carico distribuisce le richieste un gruppo di istanze gestite a livello di regione con due VM di Compute Engine. L'applicazione in esecuzione sulle VM scrive e legge dati da un database Cloud SQL. Il database è configurato per l'alta disponibilità. L'account principale le istanze in standby del database vengono sottoposte a provisioning in zone separate e viene replicato in modo sincrono al database in standby. Nella Inoltre, viene eseguito automaticamente il backup del database su un bucket multiregionale in di archiviazione ideale 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 | sulle reti VPC, incluse route associate e regole firewall, 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 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 di Compute Engine sono risorse a livello 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 Il bilanciatore del carico è un gruppo di istanze gestite a livello di regione e non è una VM autonoma. |
| Istanze Cloud SQL | Il deployment di Cloud SQL in questa architettura è configurato per l'alta disponibilità, ovvero include una coppia di istanze di database principale e di standby. Il database principale viene replicato in modo sincrono
nel database di standby utilizzando i dischi permanenti a livello di regione.
|
| Bucket Cloud Storage multiregionale | Dati archiviati in Cloud Storage multiregionale è resiliente alle interruzioni di una singola regione. |
| Dischi permanenti | I dischi permanenti possono essere a livello di zona o di regione. Dischi permanenti a livello di regione sono resilienti alle interruzioni di zona. per prepararti al recupero dalla regione le interruzioni del servizio, puoi pianificare snapshot di dischi permanenti e archiviare snapshot in un bucket Cloud Storage multiregionale. |