Come descritto in Disponibilità della piattaforma, l'infrastruttura Google Cloud è progettata per supportare una disponibilità target del 99,9% per un carico di lavoro di cui viene eseguito il deployment in una singola zona. La disponibilità target è del 99,99% per un deployment multizona e del 99,999% per un deployment multiregionale. Questa parte della guida all'affidabilità dell'infrastruttura Google Cloud fornisce indicazioni sul deployment, architetture di esempio e tecniche di progettazione che possono aiutarti a proteggere i tuoi carichi di lavoro da errori a livello di risorsa, zona e regione.
Evita i single point of failure
Le applicazioni sono in genere composte da più componenti interdipendenti, ciascuno progettato per svolgere una funzione specifica. Questi componenti sono in genere raggruppati in livelli in base alla funzione che eseguono e alla loro relazione con gli altri componenti. Ad esempio, un'applicazione di pubblicazione di contenuti potrebbe avere tre livelli: un livello web contenente un bilanciatore del carico e server web, un livello app con un cluster di server delle applicazioni e un livello dati per la persistenza. Se uno o più componenti di questo stack di applicazioni dipende da una singola risorsa di infrastruttura, un errore della risorsa può influire sulla disponibilità dell'intero stack. Ad esempio, se il livello app viene eseguito su una singola VM e se quest'ultima si arresta in modo anomalo, l'intero stack non è effettivamente disponibile. Un componente di questo tipo è un singolo punto di errore (SPOF).
Uno stack di applicazioni potrebbe avere più di un SPOF. Considera lo stack di applicazioni multi-livello mostrato nel seguente diagramma:
Come mostrato nel diagramma precedente, questa architettura di esempio contiene un singolo bilanciatore del carico, due server web, un singolo server di app e un singolo database. In questo esempio, il bilanciatore del carico, il server delle app e il database sono SPOF. Un errore di uno di questi componenti può causare l'esito negativo delle richieste degli utenti all'applicazione.
Per rimuovere gli SPOF dallo stack di applicazioni, distribuisci le risorse tra località ed esegui il deployment di risorse ridondanti.
Distribuisci le risorse e crea ridondanza
A seconda dei requisiti di affidabilità della tua applicazione, puoi scegliere tra le seguenti architetture di deployment:
| Architettura | Suggerimento per il carico di lavoro |
|---|---|
| Più regioni | Carichi di lavoro critici per l'azienda in cui l'alta disponibilità è essenziale, come le applicazioni retail e di social media. |
| Multizona | Carichi di lavoro che richiedono resilienza contro le interruzioni delle zone, ma possono tollerare alcuni tempi di inattività causati da interruzioni delle regioni. |
| Zona singola | Carichi di lavoro in grado di tollerare tempi di inattività o di cui è possibile eseguire il deployment in un'altra località quando necessario, con il minimo sforzo. |
Considerazioni su costi, latenza e operazioni
Quando progetti un'architettura distribuita con risorse ridondanti, oltre ai requisiti di disponibilità dell'applicazione, devi considerare anche gli effetti su complessità operativa, latenza e costi.
In un'architettura distribuita, esegui il provisioning e la gestione di un numero più elevato di risorse. Il volume di traffico di rete tra più località è più elevato. Puoi anche archiviare e replicare più dati. Di conseguenza, il costo delle risorse cloud in un'architettura distribuita è più elevato e il funzionamento di questi deployment comporta una maggiore complessità. Per le applicazioni business-critical, il vantaggio in termini di disponibilità di un'architettura distribuita potrebbe superare i costi e la complessità operativa maggiori.
Per le applicazioni non business critical, l'alta disponibilità offerta da un'architettura distribuita potrebbe non essere essenziale. Alcune applicazioni hanno altri requisiti più importanti della disponibilità. Ad esempio, le applicazioni di computing in batch richiedono connessioni di rete a bassa latenza e ad alta larghezza di banda tra le VM. Un'architettura a zona singola potrebbe essere adatta per queste applicazioni e può anche aiutarti a ridurre i costi di trasferimento dei dati.
Architetture di deployment
Questa sezione presenta le seguenti opzioni architetturali per creare l'infrastruttura per i tuoi carichi di lavoro in Google Cloud:
- Deployment a zona singola
- Implementazione multizona
- Deployment su più regioni con bilanciamento del carico a livello di regione
- Deployment su più regioni con bilanciamento del carico globale
Deployment a zona singola
Il seguente diagramma mostra un'architettura delle applicazioni a zona singola con ridondanza in ogni livello, per ottenere una maggiore disponibilità delle funzioni eseguite da ciascun componente:
Come mostrato nel diagramma precedente, questa architettura di esempio include i seguenti componenti:
- Un bilanciatore del carico HTTP/S esterno a livello di regione per ricevere e rispondere alle richieste degli utenti.
- Un gruppo di istanze gestite a livello di zona (MIG) come backend per il bilanciatore del carico HTTP/S. Il gruppo di istanze gestite ha due VM di Compute Engine. Ogni VM ospita un'istanza di un server web.
- Un bilanciatore del carico interno per gestire la comunicazione tra il server web e le istanze dell'app server.
- Un secondo gruppo di istanze gestite a livello di zona come backend per il bilanciatore del carico interno. Questo gruppo di istanze gestite contiene due VM di Compute Engine. Ogni VM ospita un'istanza di un server di applicazioni.
- Un'istanza di database Cloud SQL (versione Enterprise) in cui l'applicazione scrive i dati e da cui legge. Il database viene replicato manualmente in una seconda istanza del database Cloud SQL nella stessa zona.
Disponibilità aggregata: deployment a zona singola
La tabella seguente mostra la disponibilità di ogni livello nel precedente diagramma dell'architettura a zona singola:
| Risorsa | SLA (accordo sul livello del servizio) |
|---|---|
| Bilanciatore del carico esterno | 99,99% |
| Livello web: VM di Compute Engine in una zona singola | 99,9% |
| Bilanciatore del carico interno | 99,99% |
| Livello di applicazione: VM di Compute Engine in una zona singola | 99,9% |
| Istanza Cloud SQL (versione Enterprise) | 99,95% |
Prevediamo che le risorse dell'infrastruttura Google Cloud elencate nella tabella precedente forniscano la seguente disponibilità aggregata e il tempo di inattività mensile massimo stimato:
- Disponibilità aggregata: 0,9999 x 0,999 x 0,9999 x 0,999 x 0,9995 = 99,73%
- Tempo di inattività mensile massimo stimato: circa 1 ora e 57 minuti
Questo calcolo considera solo le risorse di infrastruttura mostrate nel diagramma dell'architettura precedente. Per valutare la disponibilità di un'applicazione in Google Cloud, è necessario considerare anche altri fattori, tra cui:
- Il design interno dell'applicazione
- I processi e gli strumenti DevOps utilizzati per creare, eseguire il deployment e gestire l'applicazione, le sue dipendenze
Per maggiori informazioni, consulta Fattori che influiscono sull'affidabilità dell'applicazione.
Effetti delle interruzioni e indicazioni per il ripristino
In un'architettura di deployment a zona singola, in caso di errore di un componente, l'applicazione può elaborare le richieste se ogni livello contiene almeno un componente funzionante con capacità adeguata. Ad esempio, in caso di errore dell'istanza di un server web, il bilanciatore del carico inoltra le richieste degli utenti alle altre istanze del server web. Se una VM che ospita un server web o un'istanza dell'app server si arresta in modo anomalo, il gruppo di istanze gestite garantisce la creazione automatica di una nuova VM. Se il database si arresta in modo anomalo, devi attivare manualmente il secondo database e aggiornare le istanze dell'app server in modo che si connetta al database.
Un'interruzione di una zona o di una regione interessa le VM di Compute Engine e le istanze del database Cloud SQL in un deployment a zona singola. Un'interruzione di una zona non influisce sul bilanciatore del carico in questa architettura perché è una risorsa a livello di regione. Tuttavia, il bilanciatore del carico non può distribuire il traffico, perché non ci sono backend disponibili. In caso di interruzione di una zona, devi attendere che Google risolva l'interruzione, quindi verificare che l'applicazione funzioni come previsto.
La prossima sezione descrive un approccio all'architettura che puoi utilizzare per distribuire le risorse su più zone, il che contribuisce a migliorare la resilienza dell'applicazione alle interruzioni delle zone.
Deployment multizona
In un deployment a zona singola, se si verifica un'interruzione della zona, l'applicazione potrebbe non essere in grado di gestire le richieste fino a quando il problema non viene risolto. Per migliorare la resilienza della tua applicazione contro le interruzioni delle zone, puoi eseguire il provisioning di più istanze di risorse di zona (ad esempio VM di Compute Engine) in due o più zone. Per i servizi che supportano risorse con ambito a livello di regione (come i bucket Cloud Storage), puoi eseguire il deployment delle risorse a livello di regione.
Il seguente diagramma mostra un'architettura tra zone ad alta disponibilità, con i componenti in ogni livello dello stack di applicazioni distribuiti in due zone:
Come mostrato nel diagramma precedente, questa architettura di esempio include i seguenti componenti:
- Un bilanciatore del carico HTTP/S esterno regionale riceve e risponde alle richieste degli utenti.
- Un gruppo di istanze gestite a livello di regione è il backend per il bilanciatore del carico HTTP/S. 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 dell'app server.
- Un secondo gruppo di istanze gestite a livello di regione è il backend per il bilanciatore del carico TCP. Questo gruppo di istanze gestite ha due VM di Compute Engine in zone diverse. Ogni VM ospita un'istanza di un server app.
- Un'istanza Cloud SQL (versione Enterprise) configurata per l'alta disponibilità è il database dell'applicazione. L'istanza del database principale viene replicata in modo sincrono in un'istanza del database in standby.
Disponibilità aggregata: deployment multizona
La tabella seguente mostra la disponibilità di ciascun livello nel precedente diagramma dell'architettura a due zone:
| Risorsa | SLA (accordo sul livello del servizio) |
|---|---|
| Bilanciatore del carico esterno | 99,99% |
| Livello web: VM di Compute Engine in zone separate | 99,99% |
| Bilanciatore del carico interno | 99,99% |
| Livello di applicazione: VM di Compute Engine in zone distinte | 99,99% |
| Istanza Cloud SQL (versione Enterprise) | 99,95% |
Le risorse dell'infrastruttura Google Cloud elencate nella tabella precedente forniscono la seguente disponibilità aggregata e il tempo di inattività mensile massimo stimato:
- Disponibilità complessiva: 0,9999 x 0,9999 x 0,9999 x 0,9999 x 0,9995 = 99,91%
- Tempo di inattività mensile massimo stimato: circa 39 minuti
Questo calcolo considera solo le risorse di infrastruttura mostrate nel diagramma dell'architettura precedente. Per valutare la disponibilità di un'applicazione in Google Cloud, è necessario considerare anche altri fattori, tra cui:
- Il design interno dell'applicazione
- I processi e gli strumenti DevOps utilizzati per creare, eseguire il deployment e gestire l'applicazione, le sue dipendenze
Per maggiori informazioni, consulta Fattori che influiscono sull'affidabilità dell'applicazione.
Effetti delle interruzioni e indicazioni per il ripristino
In un deployment a due zone, in caso di errore di un componente, l'applicazione può elaborare le richieste se in ogni livello è presente almeno un componente funzionante con capacità adeguata. Ad esempio, in caso di errore dell'istanza di un server web, il bilanciatore del carico inoltra le richieste degli utenti all'istanza del server web nell'altra zona. Se una VM che ospita un server web o un'istanza del server dell'app si arresta in modo anomalo, il gruppo di istanze gestite garantisce la creazione automatica di una nuova VM. Se il database Cloud SQL principale si arresta in modo anomalo, Cloud SQL esegue il failover automatico nell'istanza del database in standby.
Il seguente diagramma mostra la stessa architettura del diagramma precedente e gli effetti di un'interruzione di una zona sulla disponibilità dell'applicazione:
Come mostrato nel diagramma precedente, se si verifica un'interruzione in una delle zone, il bilanciatore del carico in questa architettura non è interessato, perché è una risorsa di regione. Un'interruzione della zona potrebbe interessare singole VM di Compute Engine e una delle istanze del database Cloud SQL. Tuttavia, l'applicazione rimane disponibile e reattiva, perché le VM si trovano in gruppi di istanze gestite a livello di regione e il database Cloud SQL è configurato per l'alta disponibilità. I gruppi di istanze gestite assicurano che le nuove VM vengano create automaticamente per mantenere il numero minimo configurato. Se l'istanza del database Cloud SQL principale è interessata da un'interruzione di una zona, Cloud SQL avvia automaticamente l'istanza in standby nell'altra zona. Dopo che Google ha risolto l'interruzione, devi verificare che l'applicazione venga eseguita come previsto in tutte le zone in cui è stato eseguito il deployment.
Se entrambe le zone di questa architettura presentano un'interruzione, l'applicazione non è disponibile. Il bilanciatore del carico continua a essere disponibile, a meno che non si verifichi un'interruzione a livello di regione. Tuttavia, il bilanciatore del carico non può distribuire il traffico, perché non ci sono backend disponibili. Se si verifica un'interruzione multizona o a livello di regione, devi attendere che Google risolva l'interruzione, quindi verificare che l'applicazione funzioni come previsto.
Le sezioni successive illustrano le opzioni architetturali per proteggere l'applicazione da interruzioni multizona e interruzioni a livello di regione.
Deployment su più regioni con bilanciamento del carico a livello di regione
In un deployment a zona singola o multizona, se si verifica un'interruzione della regione, l'applicazione non può gestire le richieste fino a quando il problema non viene risolto. Per proteggere la tua applicazione da interruzioni della regione, puoi distribuire le risorse Google Cloud in due o più regioni.
Il seguente diagramma mostra un'architettura tra regioni ad alta disponibilità, con i componenti di ogni livello dello stack di applicazioni distribuiti in più regioni:
Come mostrato nel diagramma precedente, questa architettura di esempio include i seguenti componenti:
- Una zona Cloud DNS pubblica con un criterio di routing che indirizza il traffico a due regioni Google Cloud.
- Un bilanciatore del carico HTTP/S esterno a livello di regione in ogni regione per ricevere e rispondere alle richieste degli utenti.
- Il backend per ogni bilanciatore del carico HTTP/S a livello di regione è un gruppo di istanze gestite a livello di regione. Ogni gruppo di istanze gestite contiene due VM di Compute Engine in zone diverse. Ognuna di queste VM ospita un'istanza di un server web.
- Un bilanciatore del carico interno in ogni regione gestisce la comunicazione tra le istanze del server web e le istanze dell'app server.
- Una seconda coppia di gruppi di istanze gestite a livello di regione rappresenta il backend per i bilanciatori del carico interni. Ciascuno di questi gruppi di istanze gestite contiene due VM di Compute Engine in zone diverse. Ogni VM ospita un'istanza di un server di app.
- L'applicazione scrive e legge i dati da un'istanza di Spanner multiregionale. La configurazione per più regioni utilizzata in questa
architettura (
eur5) include quattro repliche di lettura e scrittura. Il provisioning delle repliche di lettura e scrittura viene eseguito allo stesso modo in due regioni e in zone separate. La configurazione di Spanner per più regioni include anche una replica di testimoni in una terza regione.
Disponibilità aggregata: deployment multiregionale con bilanciamento del carico a livello di regione
Nel deployment multiregionale mostrato nel diagramma precedente, viene eseguito il provisioning ridondante dei bilanciatori del carico e delle VM in due regioni. La zona DNS è una risorsa globale, mentre l'istanza Spanner è una risorsa multiregionale.
Per calcolare la disponibilità aggregata dell'infrastruttura di Google Cloud mostrata in questa architettura, dobbiamo prima calcolare la disponibilità aggregata delle risorse in ogni regione, quindi considerare le risorse su più regioni. Segui questa procedura:
- Calcola la disponibilità aggregata delle risorse di infrastruttura per regione, escludendo quindi le risorse DNS e di database:
Risorsa e SLA SLA (accordo sul livello del servizio) Bilanciatore del carico esterno 99,99% Livello web: VM di Compute Engine in zone separate 99,99% Bilanciatore del carico interno 99,99% Livello di applicazione: VM di Compute Engine in zone distinte 99,99% Disponibilità aggregata per regione: 0,9999 x 0,9999 x 0,9999 x 0,9999 = 99,96%
Calcola la disponibilità aggregata delle risorse dell'infrastruttura considerando la ridondanza a due regioni dei bilanciatori del carico e delle VM di Compute Engine.
La disponibilità teorica è 1-(1-0,9996)(1-0,9996) = 99,999984%. Tuttavia, la disponibilità effettiva prevista è limitata alla disponibilità target per i deployment in più regioni, ovvero del 99,999%.
Calcola la disponibilità aggregata di tutte le risorse di infrastruttura, tra cui le risorse Cloud DNS e Spanner:
- Disponibilità aggregata: 0,99999 x 1 x 0,99999 = 99,998%
- Tempo di inattività mensile massimo stimato: circa 52 secondi
Questo calcolo considera solo le risorse di infrastruttura mostrate nel diagramma dell'architettura precedente. Per valutare la disponibilità di un'applicazione in Google Cloud, è necessario considerare anche altri fattori, tra cui:
- Il design interno dell'applicazione
- I processi e gli strumenti DevOps utilizzati per creare, eseguire il deployment e gestire l'applicazione, le sue dipendenze
Per maggiori informazioni, consulta Fattori che influiscono sull'affidabilità dell'applicazione.
Effetti delle interruzioni e indicazioni per il ripristino
Se un componente di questo deployment multiregionale presenta errori, ma è presente almeno un componente funzionante con capacità adeguata in ogni livello, l'applicazione continua a funzionare. Ad esempio, in caso di errore di un'istanza del server web, il bilanciatore del carico HTTP/S esterno regionale inoltra le richieste degli utenti alle altre istanze del server web nella regione. Analogamente, se una delle istanze dell'app server si arresta in modo anomalo, i bilanciatori del carico interni inviano le richieste alle altre istanze dell'app server. Se una delle VM si arresta in modo anomalo, i gruppi di istanze gestite assicurano che le nuove VM vengano create automaticamente per mantenere il numero minimo configurato di VM.
Un'interruzione in una singola zona non influisce sui bilanciatori del carico, in quanto sono risorse di regione e sono resilienti in caso di interruzioni delle zone. L'interruzione di una zona potrebbe influire sulle singole VM di Compute Engine. Tuttavia, le istanze del server web e dell'app server rimangono disponibili perché le VM fanno parte di MIG a livello di regione. I gruppi di istanze gestite assicurano che le nuove VM vengano create automaticamente per mantenere il numero minimo configurato di VM. L'istanza Spanner in questa architettura utilizza una configurazione per più regioni, resiliente in caso di interruzioni delle zone.
Per informazioni sul funzionamento della replica su più regioni in Spanner, consulta gli articoli Configurazioni a livello di regione e multiregionale e Demistificazione delle configurazioni di Spanner per più regioni.
Il seguente diagramma mostra la stessa architettura multiregionale del diagramma precedente e gli effetti di un'interruzione di una singola regione sulla disponibilità dell'applicazione:
Come mostrato nel diagramma precedente, anche se si verifica un'interruzione in entrambe le zone in qualsiasi regione, l'applicazione rimane disponibile, perché in ogni regione viene eseguito il deployment di uno stack di applicazioni indipendente. La zona DNS indirizza le richieste degli utenti alla regione non interessata dall'interruzione. L'istanza di Spanner per più regioni è resiliente in caso di interruzioni delle regioni. Una volta che Google ha risolto l'interruzione, devi verificare che l'applicazione venga eseguita come previsto nella regione in cui si è verificata l'interruzione.
Se due regioni di questa architettura presentano interruzioni, l'applicazione non è disponibile. Attendi che Google risolva le interruzioni. Poi, verifica che l'applicazione venga eseguita come previsto in tutte le regioni in cui è stato eseguito il deployment.
Per i deployment in più regioni, invece di utilizzare bilanciatori del carico a livello di regione, puoi utilizzare un bilanciatore del carico globale. La prossima sezione presenta un'architettura di deployment su più regioni che utilizza un bilanciatore del carico globale e descrive i vantaggi e i rischi di questo approccio.
Deployment su più regioni con bilanciamento del carico globale
Il seguente diagramma mostra un deployment alternativo in più regioni che utilizza un bilanciatore del carico globale anziché bilanciatori del carico a livello di regione:
Come mostrato nel diagramma precedente, questa architettura utilizza un bilanciatore del carico HTTP/S esterno globale (con Cloud CDN abilitato) per ricevere e rispondere alle richieste degli utenti. Ogni regola di forwarding del bilanciatore del carico utilizza un singolo indirizzo IP esterno; non è necessario configurare un record DNS separato per ogni regione. I backend per il bilanciatore del carico HTTP/S esterno globale sono due gruppi di istanze gestite a livello di regione. Il bilanciatore del carico instrada le richieste alla regione più vicina agli utenti.
Tutti gli altri componenti di questa architettura sono identici all'architettura mostrata in Deployment per più regioni con bilanciamento del carico a livello di regione.
Vantaggi e rischi del bilanciamento del carico globale per deployment in più regioni
Per bilanciare il carico del traffico esterno verso un'applicazione distribuita in più regioni, puoi utilizzare un bilanciatore del carico globale o più bilanciatori del carico a livello di regione.
Di seguito sono riportati i vantaggi di un'architettura che utilizza un bilanciatore del carico globale:
- Devi gestire un solo bilanciatore del carico.
- I bilanciatori del carico globali utilizzano un singolo indirizzo IP anycast per fornire il bilanciamento del carico nelle regioni di Google Cloud.
- I bilanciatori del carico globali sono resilienti alle interruzioni delle regioni e forniscono il failover automatico tra regioni.
- I bilanciatori del carico globali supportano le seguenti funzionalità, che possono contribuire a migliorare l'affidabilità dei deployment:
- Memorizzazione in una cache perimetrale mediante Cloud CDN
- Possibilità di utilizzare bucket Cloud Storage a elevata durabilità come backend
- Criteri di sicurezza di Google Cloud Armor
Di seguito sono riportati i rischi di un'architettura che utilizza un bilanciatore del carico globale:
- Una modifica errata della configurazione del bilanciatore del carico globale potrebbe rendere l'applicazione non disponibile per gli utenti. Ad esempio, durante l'aggiornamento del frontend del bilanciatore del carico globale, se elimini accidentalmente una regola di forwarding, il bilanciatore del carico smette di ricevere le richieste degli utenti. L'effetto di questo rischio è inferiore nel caso di un'architettura multiregionale che utilizza bilanciatori del carico a livello di regione, perché, anche se il bilanciatore del carico a livello di regione in una delle regioni è interessato da un errore di configurazione, i bilanciatori del carico nelle altre regioni continuano a funzionare.
- Un'interruzione dell'infrastruttura che interessa le risorse globali potrebbe rendere non disponibile il bilanciatore del carico globale.
Per mitigare questi rischi, devi gestire con attenzione le modifiche al bilanciatore del carico globale e, ove possibile, utilizzare soluzioni di fallback della difesa in profondità. Per saperne di più, consulta Suggerimenti per gestire il rischio di interruzioni delle risorse globali.
Disponibilità aggregata: deployment multiregionale con bilanciamento del carico globale
Nel deployment multiregionale mostrato nel diagramma precedente, le VM e i bilanciatori del carico interni sono distribuiti in modo ridondante in due regioni. Il bilanciatore del carico esterno è una risorsa globale, mentre l'istanza Spanner è una risorsa multiregionale.
Per calcolare la disponibilità aggregata di questo deployment, prima calcoliamo la disponibilità aggregata delle risorse in ogni regione, quindi valutiamo le risorse su più regioni.
- Calcola la disponibilità aggregata delle risorse di infrastruttura per regione, esclusi il bilanciatore del carico esterno e il database:
Risorsa SLA (accordo sul livello del servizio) Livello web: VM di Compute Engine in zone separate 99,99% Bilanciatore del carico interno 99,99% Livello web: VM di Compute Engine in zone separate 99,99% Disponibilità aggregata per regione: 0,9999 x 0,9999 x 0,9999 = 99,97%
Calcola la disponibilità aggregata delle risorse dell'infrastruttura considerando la ridondanza a due regioni del bilanciatore del carico interno e delle VM di Compute Engine.
La disponibilità teorica è 1-(1-0,9997)(1-0,9997) = 99,999991%. Tuttavia, la disponibilità effettiva prevista è limitata alla disponibilità target per i deployment in più regioni, ovvero del 99,999%.
Calcola la disponibilità aggregata di tutte le risorse dell'infrastruttura, tra cui il bilanciatore del carico globale e le risorse Spanner:
- Disponibilità aggregata: 0,99999 x 0,9999 x 0,99999 = 99,988%
- Tempo di inattività mensile massimo stimato: circa 5 minuti e 11 secondi
Questo calcolo considera solo le risorse di infrastruttura mostrate nel diagramma dell'architettura precedente. Per valutare la disponibilità di un'applicazione in Google Cloud, è necessario considerare anche altri fattori, tra cui:
- Il design interno dell'applicazione
- I processi e gli strumenti DevOps utilizzati per creare, eseguire il deployment e gestire l'applicazione, le sue dipendenze
Per maggiori informazioni, consulta Fattori che influiscono sull'affidabilità dell'applicazione.
Effetti delle interruzioni e indicazioni per il ripristino
Se si verifica un errore in un componente di questa architettura, l'applicazione continua a funzionare se in ogni livello è presente almeno un componente funzionante con capacità adeguata. Ad esempio, in caso di errore dell'istanza di un server web, il bilanciatore del carico HTTP/S esterno globale inoltra le richieste degli utenti alle altre istanze del server web. Se un'istanza dell'app server si arresta in modo anomalo, i bilanciatori del carico interni inviano le richieste alle altre istanze dell'app server. In caso di arresto anomalo di una VM, i gruppi di istanze gestite assicurano che le nuove VM vengano create automaticamente per mantenere il numero minimo configurato di VM.
Un'interruzione del servizio in una delle zone di qualsiasi regione non influisce sul bilanciatore del carico. Il bilanciatore del carico HTTP/S esterno globale è resiliente in caso di interruzioni di zone e regioni. I bilanciatori del carico interni sono risorse a livello di regione e sono resilienti alle interruzioni delle zone. Un'interruzione di una zona potrebbe interessare singole VM di Compute Engine. Le istanze del server web e del server delle app rimangono però disponibili, perché le VM fanno parte di gruppi di istanze gestite a livello di regione. I gruppi di istanze gestite assicurano che le nuove VM vengano create automaticamente per mantenere il numero minimo configurato di VM. L'istanza Spanner in questa architettura utilizza una configurazione multiregionale, resiliente in caso di interruzioni delle zone.
Il seguente diagramma mostra la stessa architettura multiregionale del diagramma precedente e gli effetti di un'interruzione di una singola regione sulla disponibilità dell'applicazione:
Come mostrato nel diagramma precedente, anche se si verifica un'interruzione in entrambe le zone in qualsiasi regione, l'applicazione rimane disponibile, perché in ogni regione viene eseguito il deployment di uno stack di applicazioni indipendente. Il bilanciatore del carico HTTP/S esterno globale instrada le richieste degli utenti all'applicazione nella regione non interessata dall'interruzione. L'istanza di Spanner multiregionale è resiliente in caso di interruzioni delle regioni. Una volta che Google ha risolto l'interruzione, devi verificare che l'applicazione venga eseguita come previsto nella regione in cui si è verificata l'interruzione.
Per informazioni sul funzionamento della replica su più regioni in Spanner, consulta gli articoli Configurazioni a livello di regione e multiregionale e Demistificazione delle configurazioni di Spanner per più regioni.
Se due regioni di questa architettura presentano interruzioni, l'applicazione non è disponibile. È disponibile il bilanciatore del carico HTTP/S esterno globale, ma non può distribuire il traffico perché non sono disponibili backend. Attendi che Google risolva le interruzioni. Poi, verifica che l'applicazione venga eseguita come previsto in tutte le regioni in cui è stato eseguito il deployment.
I deployment in più regioni possono contribuire a garantire un'alta disponibilità per le tue applicazioni aziendali più critiche. Per garantire la continuità aziendale durante gli eventi di errore, oltre a eseguire il deployment dell'applicazione in più regioni, devi eseguire alcuni passaggi aggiuntivi. Ad esempio, devi eseguire la pianificazione della capacità per assicurarti che venga prenotata capacità sufficiente in tutte le regioni o che i rischi associati alla scalabilità automatica di emergenza siano accettabili. Devi inoltre implementare pratiche operative per i test di RE, la gestione degli incidenti, la verifica dello stato dell'applicazione dopo gli incidenti e l'esecuzione di retrospettive.