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 è stato eseguito il deployment in un'unica zona. La disponibilità target è del 99,99% per un deployment multizona1 e del 99,999% per un deployment multiregione. 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 eseguire una funzione specifica. Questi componenti sono in genere raggruppati in livelli in base alla funzione che svolgono 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 applicazioni e un livello di dati per la persistenza. Se un componente di questo stack di applicazioni dipende da una singola risorsa di infrastruttura, un errore di questa risorsa può influire sulla disponibilità dell'intero stack. Ad esempio, se il livello dell'app viene eseguito su una singola VM e la VM si arresta in modo anomalo, l'intero stack non è effettivamente disponibile. Un componente di questo tipo è un single point of failure (SPOF).
Uno stack di applicazioni potrebbe avere più di un punto SPOF. Prendi in considerazione la pila di applicazioni a più livelli mostrata nel seguente diagramma:
Come mostrato nel diagramma precedente, questa architettura di esempio contiene un singolo bilanciatore del carico, due server web, un singolo server app e un singolo database. Il bilanciatore del carico, il server app e il database in questo esempio sono SPOF. Il malfunzionamento di uno di questi componenti può causare l'errore delle richieste degli utenti all'applicazione.
Per rimuovere i punti di vulnerabilità SPOF nello stack delle applicazioni, distribuisci le risorse tra più 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 workload |
|---|---|
| Più regioni | Carichi di lavoro business critical per i quali è essenziale la disponibilità elevata, ad esempio applicazioni di vendita al dettaglio e social media. |
| Multizona | Carichi di lavoro che richiedono resilienza contro le interruzioni delle zone, ma possono tollerare un certo tempo di riposo causato da interruzioni della regione. |
| Zona singola | Carichi di lavoro che possono tollerare i tempi di inattività o che possono essere implementati in un'altra posizione, se necessario, con il minimo sforzo. |
Considerazioni su costi, latenza e operatività
Quando progetti un'architettura distribuita con risorse ridondanti, oltre ai requisiti di disponibilità dell'applicazione, devi considerare anche gli effetti sulla complessità operativa, sulla latenza e sui costi.
In un'architettura distribuita, esegui il provisioning e gestisci un numero maggiore di risorse. Il volume del traffico di rete tra sedi è più elevato. Inoltre, memorizzi e replichi più dati. Di conseguenza, il costo delle risorse cloud in un'architettura distribuita è più elevato e l'utilizzo di questi deployment comporta una maggiore complessità. Per le applicazioni business-critical, il vantaggio della disponibilità di un'architettura distribuita potrebbe superare l'aumento dei costi e la complessità operativa.
Per le applicazioni non business-critical, l'alta disponibilità fornita da un'architettura distribuita potrebbe non essere essenziale. Alcune applicazioni hanno altri requisiti più importanti della disponibilità. Ad esempio, le applicazioni di calcolo collettivo 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 di architettura per creare l'infrastruttura per i tuoi carichi di lavoro in Google Cloud:
- Deployment a zona singola
- Deployment multizona
- Deployment multiregionale con bilanciamento del carico a livello di regione
- Deployment multiregione con bilanciamento del carico globale
Deployment a zona singola
Il seguente diagramma mostra un'architettura di applicazione 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 regionale per ricevere e rispondere alle richieste degli utenti.
- Un gruppo di istanze gestite (MIG) zonale come backend per il bilanciatore del carico HTTP/S. Il gruppo di istanze gestite ha due VM 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 del server app.
- 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 Compute Engine. Ogni VM ospita un'istanza di un server di applicazioni.
- Un'istanza del database Cloud SQL (versione Enterprise) in cui l'applicazione scrive e legge i dati. Il database viene replicato manualmente in una seconda istanza di database Cloud SQL nella stessa zona.
Disponibilità aggregata: deployment in una singola zona
La tabella seguente mostra la disponibilità di ogni livello nel diagramma dell'architettura a zona singola precedente:
| Risorsa | SLA (accordo sul livello del servizio) |
|---|---|
| Bilanciatore del carico esterno | 99,99% |
| Livello web: VM Compute Engine in un'unica zona | 99,9% |
| Bilanciatore del carico interno | 99,99% |
| Livello dell'applicazione: VM Compute Engine in un'unica zona | 99,9% |
| Istanza Cloud SQL (versione Enterprise) | 99,95% |
Le risorse dell'infrastruttura Google Cloud elencate nella tabella precedente dovrebbero fornire la seguente disponibilità aggregata e il tempo di riposo mensile massimo stimato:
- Disponibilità aggregata: 0,9999 x 0,999 x 0,9999 x 0,999 x 0,9995 = 99,73%
- Tempo di riposo mensile massimo stimato: circa 1 ora e 57 minuti
Questo calcolo prende in considerazione solo le risorse di infrastruttura mostrate nel diagramma dell'architettura precedente. Per valutare la disponibilità di un'applicazione in Google Cloud, devi prendere in considerazione anche altri fattori, ad esempio:
- Il design interno dell'applicazione
- Le procedure e gli strumenti DevOps utilizzati per creare, eseguire il deployment e gestire l'applicazione, le relative dipendenze e l'infrastruttura Google Cloud
Per ulteriori informazioni, consulta Fattori che influiscono sull'affidabilità delle applicazioni.
Effetti delle interruzioni e indicazioni per il recupero
In un'architettura di implementazione a zona singola, se un componente non funziona, l'applicazione può elaborare le richieste se ogni livello contiene almeno un componente funzionante con capacità adeguata. Ad esempio, se un'istanza del server web non funziona, il bilanciatore del carico inoltra le richieste degli utenti alle altre istanze del server web. Se una VM che ospita un'istanza di server web o di server app 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 del server app per connetterti al database.
Un'interruzione del servizio in una zona o in una regione interessa le VM Compute Engine e le istanze di database Cloud SQL in un deployment a zona singola. Un'interruzione di servizio in una zona non influisce sul bilanciatore del carico in questa architettura perché si tratta di una risorsa regionale. Tuttavia, il bilanciatore del carico non può distribuire il traffico perché non sono disponibili backend. Se si verifica un'interruzione del servizio in una zona, devi attendere che Google risolva il problema e poi verificare che l'applicazione funzioni come previsto.
La sezione successiva descrive un approccio di 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 in una singola zona, se si verifica un'interruzione della zona, l'applicazione potrebbe non essere in grado di gestire le richieste finché il problema non viene risolto. Per contribuire a migliorare la resilienza della tua applicazione in caso di interruzioni della zona, puoi eseguire il provisioning di più istanze di risorse zonali (ad esempio VM Compute Engine) in due o più zone. Per i servizi che supportano le risorse a livello di regione (ad esempio i bucket Cloud Storage), puoi eseguire il deployment di risorse regionali.
Il seguente diagramma mostra un'architettura cross-zone ad alta disponibilità, con i componenti di ogni livello dello stack dell'applicazione distribuiti su 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 regionale è il backend per il bilanciatore del carico HTTP/S. 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 app.
- Un secondo gruppo di istanze gestite regionale è il backend per il bilanciatore del carico TCP. Questo gruppo di istanze gestite ha due VM Compute Engine in zone diverse. Ogni VM ospita un'istanza di un server app.
- Un'istanza Cloud SQL (versione Enterprise) configurata per l'HA è il database dell'applicazione. L'istanza di database principale viene replicata in modo sincrono in un'istanza di database di standby.
Disponibilità aggregata: deployment multizona
La tabella seguente mostra la disponibilità di ogni livello nel diagramma dell'architettura a due zone precedente:
| Risorsa | SLA (accordo sul livello del servizio) |
|---|---|
| Bilanciatore del carico esterno | 99,99% |
| Livello web: VM Compute Engine in zone separate | 99,99% |
| Bilanciatore del carico interno | 99,99% |
| Livello dell'applicazione: VM Compute Engine in zone separate | 99,99% |
| Istanza Cloud SQL (versione Enterprise) | 99,95% |
Le risorse dell'infrastruttura Google Cloud elencate nella tabella precedente dovrebbero fornire la seguente disponibilità aggregata e il tempo di riposo mensile massimo stimato:
- Disponibilità aggregata: 0,9999 x 0,9999 x 0,9999 x 0,9999 x 0,9995 = 99,91%
- Tempo di riposo mensile massimo stimato: circa 39 minuti
Questo calcolo prende in considerazione solo le risorse di infrastruttura mostrate nel diagramma dell'architettura precedente. Per valutare la disponibilità di un'applicazione in Google Cloud, devi prendere in considerazione anche altri fattori, ad esempio:
- Il design interno dell'applicazione
- Le procedure e gli strumenti DevOps utilizzati per creare, eseguire il deployment e gestire l'applicazione, le relative dipendenze e l'infrastruttura Google Cloud
Per ulteriori informazioni, consulta Fattori che influiscono sull'affidabilità delle applicazioni.
Effetti delle interruzioni e indicazioni per il recupero
In un deployment a due zone, se un componente non funziona, l'applicazione può elaborare le richieste se in ogni livello esiste almeno un componente funzionante con una capacità adeguata. Ad esempio, se un'istanza del server web non funziona, il bilanciamento del carico inoltra le richieste degli utenti all'istanza del server web nell'altra zona. Se una VM che ospita un'istanza di server web o server app si arresta in modo anomalo, il gruppo di istanze gestite garantisce che venga creata automaticamente una nuova VM. Se il database Cloud SQL principale si arresta in modo anomalo, Cloud SQL esegue automaticamente il failover sull'istanza del database in standby.
Il seguente diagramma mostra la stessa architettura del diagramma precedente e gli effetti di un'interruzione del servizio in 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, in quanto si tratta di una risorsa di regione. Un'interruzione del servizio in una zona potrebbe interessare singole VM Compute Engine e una delle istanze di database Cloud SQL. Tuttavia, l'applicazione rimane disponibile e reattiva, perché le VM si trovano in MIG regionali 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 di VM configurato. Se l'istanza del database Cloud SQL principale è interessata da un'interruzione della zona, Cloud SQL esegue il failover automaticamente sull'istanza di standby nell'altra zona. Una volta che Google ha risolto l'interruzione, devi verificare che l'applicazione funzioni come previsto in tutte le zone in cui è stata implementata.
Nota: le regioni Messico, Montréal e Osaka hanno tre zone in uno o due data center fisici. Queste regioni sono in fase di espansione ad almeno tre data center fisici. Per ulteriori informazioni, consulta Località cloud e SLA della piattaforma Google Cloud. Per contribuire a migliorare l'affidabilità dei carichi di lavoro, valuta la possibilità di eseguire un deployment multiregionale.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 del servizio su larga scala nella regione. Tuttavia, il bilanciatore del carico non può distribuire il traffico perché non sono disponibili backend. Se si verifica un'interruzione multizonale o a livello di regione, devi attendere che Google risolva l'interruzione e poi verificare che l'applicazione funzioni come previsto.
Le sezioni successive presentano opzioni di architettura per proteggere l'applicazione da interruzioni a livello di più zone e a livello di regione.
Deployment su più regioni con bilanciamento del carico a livello di regione
In un deployment in una singola zona o in più zone, se si verifica un'interruzione nella regione, l'applicazione non può gestire le richieste fino a quando il problema non viene risolto. Per proteggere la tua applicazione dalle interruzioni regionali, puoi distribuire le risorse Google Cloud in due o più regioni.
Il seguente diagramma mostra un'architettura cross-region ad alta disponibilità, con i componenti di ogni livello dello stack delle applicazioni distribuiti su 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 verso due regioni Google Cloud.
- Un bilanciatore del carico HTTP/S esterno regionale in ogni regione per ricevere e rispondere alle richieste degli utenti.
- Il backend di ogni bilanciatore del carico HTTP/S regionale è un gruppo di istanze gestite regionale. Ogni MIG contiene due VM 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 del server app.
- Una seconda coppia di MIG regionali è il backend per i bilanciatori del carico interni. Ciascuno di questi gruppi di istanze gestite contiene due VM Compute Engine in zone diverse. Ogni VM ospita un'istanza di un server app.
- L'applicazione scrive e legge dati in un'istanza Spanner multiregionale. La configurazione multiregione utilizzata in questa
architettura (
eur5) include quattro repliche di lettura e scrittura. Le repliche di lettura e scrittura vengono provisionate in modo uguale in due regioni e in zone separate. La configurazione Spanner multiregionale include anche una replica Witness in una terza regione.
Disponibilità aggregata: distribuzione su più regioni con bilanciamento del carico a livello di regione
Nel deployment multiregione mostrato nel diagramma precedente, il provisioning dei bilanciatori del carico e delle VM viene eseguito in modo ridondante in due regioni. La zona DNS è una risorsa globale e l'istanza Spanner è una risorsa multi-regione.
Per calcolare la disponibilità aggregata dell'infrastruttura Google Cloud mostrata in questa architettura, dobbiamo prima calcolare la disponibilità aggregata delle risorse in ogni regione e poi prendere in considerazione le risorse che si estendono su più regioni. Procedi nel seguente modo:
- Calcola la disponibilità aggregata delle risorse di infrastruttura
per regione, ovvero escludendo le risorse DNS e di database:
Risorsa e SLA SLA (accordo sul livello del servizio) Bilanciatore del carico esterno 99,99% Livello web: VM Compute Engine in zone separate 99,99% Bilanciatore del carico interno 99,99% Livello dell'applicazione: VM Compute Engine in zone separate 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 di infrastruttura considerando la ridondanza a due regioni dei bilanciatori del carico e delle VM Compute Engine.
La disponibilità teorica è 1-(1-0,9996)(1-0,9996) = 99,999984%. Tuttavia, la disponibilità effettiva che puoi aspettarti è limitata alla disponibilità target per i deployment multiregionali, ovvero il 99,999%.
Calcola la disponibilità aggregata di tutte le risorse di infrastruttura, incluse le risorse Cloud DNS e Spanner:
- Disponibilità aggregata: 0,99999 x 1 x 0,99999 = 99,998%
- Tempo di riposo mensile massimo stimato: circa 52 secondi
Questo calcolo prende in considerazione solo le risorse di infrastruttura mostrate nel diagramma dell'architettura precedente. Per valutare la disponibilità di un'applicazione in Google Cloud, devi prendere in considerazione anche altri fattori, ad esempio:
- Il design interno dell'applicazione
- Le procedure e gli strumenti DevOps utilizzati per creare, eseguire il deployment e gestire l'applicazione, le relative dipendenze e l'infrastruttura Google Cloud
Per ulteriori informazioni, consulta Fattori che influiscono sull'affidabilità delle applicazioni.
Effetti delle interruzioni e indicazioni per il recupero
Se un componente di questo deployment multiregione non funziona, ma è presente almeno un componente funzionante con capacità adeguata in ogni livello, l'applicazione continua a funzionare. Ad esempio, se un'istanza del server web non funziona, 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 del server app si arresta in modo anomalo, i bilanciatori del carico interni inviano richieste alle altre istanze del server app. Se una delle VM si arresta in modo anomalo, i gruppi di istanze gestite assicurano che vengano create automaticamente nuove VM per mantenere il numero minimo di VM configurato.
Un'interruzione in una singola zona non influisce sui bilanciatori del carico, poiché sono risorse regionali e sono resilienti alle interruzioni delle zone. Un interruzione del servizio in una zona potrebbe interessare singole VM Compute Engine. Tuttavia, le istanze del server web e del server app rimangono disponibili, perché le VM fanno parte di MIG regionali. I gruppi di istanze gestite assicurano che le nuove VM vengano create automaticamente per mantenere il numero minimo di VM configurate. L'istanza Spanner in questa architettura utilizza una configurazione multiregionale, che è resiliente alle interruzioni di servizio delle zone.
Per informazioni su come funziona la replica multiregionale in Spanner, consulta Configurazioni a livello di una o più regioni e Demystifying Spanner multi-region configurations.
Il seguente diagramma mostra la stessa architettura multi-regione del diagramma precedente e gli effetti di un'interruzione in una singola regione sulla disponibilità dell'applicazione:
Come mostrato nel diagramma precedente, anche se si verifica un'interruzione in entrambe le zone di 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 del servizio. L'istanza Spanner su più regioni è resiliente alle interruzioni a livello di regione. Una volta che Google ha risolto l'interruzione, devi verificare che l'applicazione funzioni come previsto nella regione in cui si è verificata l'interruzione.
Se due delle regioni di questa architettura presentano interruzioni, l'applicazione non è disponibile. Attendi che Google risolva le interruzioni. Poi verifica che l'applicazione funzioni come previsto in tutte le regioni in cui è stata dispiata.
Per i deployment multiregione, anziché utilizzare bilanciatori del carico regionali, puoi optare per un bilanciatore del carico globale. La sezione successiva presenta un'architettura di deployment multiregione che utilizza un bilanciatore del carico globale e descrive i vantaggi e i rischi di questo approccio.
Deployment multiregionale con bilanciamento del carico globale
Il seguente diagramma mostra un deployment multi-regione alternativo che utilizza un bilanciatore del carico globale anziché bilanciatori del carico regionali:
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 MIG regionali. Il bilanciatore del carico indirizza le richieste alla regione più vicina agli utenti.
Tutti gli altri componenti di questa architettura sono identici all'architettura mostrata in Deployment multi-regione con bilanciamento del carico a livello di regione.
Vantaggi e rischi del bilanciamento del carico globale per i deployment multi-regione
Per bilanciare il carico del traffico esterno su un'applicazione distribuita su più regioni, puoi utilizzare un bilanciatore del carico globale o più bilanciatori del carico regionali.
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 tra le regioni Google Cloud.
- I bilanciatori del carico globali sono resilienti alle interruzioni a livello di regione e forniscono il failover automatico tra regioni.
- I bilanciatori del carico globali supportano le seguenti funzionalità, che possono contribuire a migliorare la affidabilità dei tuoi implementazioni:
- Memorizzazione nella cache di Edge utilizzando Cloud CDN
- Possibilità di utilizzare bucket Cloud Storage altamente duraturi 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 di configurazione errata al 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 multiregione che utilizza bilanciatori del carico a livello di regione, perché anche se il bilanciatore del carico regionale 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 il bilanciatore del carico globale non disponibile.
Per ridurre questi rischi, devi gestire attentamente le modifiche al bilanciatore del carico globale e, se possibile, valutare la possibilità di utilizzare strategie di difesa in profondità. Per maggiori informazioni, consulta la sezione Suggerimenti per gestire il rischio di interruzioni delle risorse globali.
Disponibilità aggregata: deployment in più regioni con bilanciamento del carico globale
Nel deployment multi-regione 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 e l'istanza Spanner è una risorsa multiregione.
Per calcolare la disponibilità aggregata di questo deployment, prima calcoliamo la disponibilità aggregata delle risorse in ogni regione e poi prendiamo in considerazione le risorse che si estendono su più regioni.
- Calcola la disponibilità aggregata delle risorse di infrastruttura
per regione, escludendo il bilanciatore del carico esterno e il database:
Risorsa SLA (accordo sul livello del servizio) Livello web: VM Compute Engine in zone separate 99,99% Bilanciatore del carico interno 99,99% Livello dell'applicazione: VM 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 di infrastruttura considerando la ridondanza a due regioni del bilanciatore del carico interno e delle VM Compute Engine.
La disponibilità teorica è 1-(1-0,9997)(1-0,9997) = 99,999991%. Tuttavia, la disponibilità effettiva che puoi aspettarti è limitata alla disponibilità target per i deployment multiregionali, ovvero il 99,999%.
Calcola la disponibilità aggregata di tutte le risorse di 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 riposo mensile massimo stimato: circa 5 minuti e 11 secondi
Questo calcolo prende in considerazione solo le risorse di infrastruttura mostrate nel diagramma dell'architettura precedente. Per valutare la disponibilità di un'applicazione in Google Cloud, devi prendere in considerazione anche altri fattori, ad esempio:
- Il design interno dell'applicazione
- Le procedure e gli strumenti DevOps utilizzati per creare, eseguire il deployment e gestire l'applicazione, le relative dipendenze e l'infrastruttura Google Cloud
Per ulteriori informazioni, consulta Fattori che influiscono sull'affidabilità delle applicazioni.
Effetti delle interruzioni e indicazioni per il recupero
Se un componente di questa architettura non funziona, l'applicazione continua a lavorare se in ogni livello è presente almeno un componente funzionante con capacità adeguata. Ad esempio, se un'istanza del server web non funziona, il bilanciatore del carico HTTP/S esterno globale inoltra le richieste degli utenti alle altre istanze del server web. Se un'istanza del server app si arresta in modo anomalo, i bilanciatori del carico interni inviano le richieste alle altre istanze del server app. Se una delle VM si arresta in modo anomalo, i gruppi di istanze gestite assicurano che vengano create automaticamente nuove VM per mantenere il numero minimo di VM configurato.
Se si verifica un'interruzione in una delle zone di una regione, il bilanciatore del carico non è interessato. Il bilanciatore del carico HTTP/S esterno globale è resiliente alle 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 del servizio in una zona potrebbe interessare singole VM Compute Engine. Tuttavia, le istanze del server web e del server app rimangono disponibili perché le VM fanno parte di MIG regionali. I gruppi di istanze gestite assicurano che le nuove VM vengano create automaticamente per mantenere il numero minimo di VM configurato. L'istanza Spanner in questa architettura utilizza una configurazione per più regioni, che è resiliente alle interruzioni delle zone.
Il seguente diagramma mostra la stessa architettura multi-regione del diagramma precedente e gli effetti di un'interruzione in una singola regione sulla disponibilità dell'applicazione:
Come mostrato nel diagramma precedente, anche se si verifica un'interruzione in entrambe le zone di 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 indirizza le richieste degli utenti all'applicazione nella regione non interessata dall'interruzione. L'istanza Spanner multiregionale è resiliente alle interruzioni a livello di regione. Una volta che Google ha risolto l'interruzione, devi verificare che l'applicazione funzioni come previsto nella regione in cui si è verificata l'interruzione.
Per informazioni su come funziona la replica multiregionale in Spanner, consulta Configurazioni a livello di una o più regioni e Demystifying Spanner multi-region configurations.
Se due delle regioni di questa architettura presentano interruzioni, l'applicazione non è disponibile. Il bilanciatore del carico HTTP/S esterno globale è disponibile, ma non può distribuire il traffico perché non sono disponibili backend. Attendi che Google risolva le interruzioni. Poi, verifica che l'applicazione funzioni come previsto in tutte le regioni in cui è dipiattata.
Gli implementazioni multiregione possono contribuire a garantire un'alta disponibilità per le applicazioni aziendali più critiche. Per garantire la continuità aziendale durante gli eventi di guasto, oltre a eseguire il deployment dell'applicazione in più regioni, devi svolgere alcuni passaggi aggiuntivi. Ad esempio, devi eseguire la pianificazione della capacità per assicurarti che sia riservata una capacità sufficiente in tutte le regioni o che i rischi associati alla scalabilità automatica di emergenza siano accettabili. Devi anche 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 analisi retrospettive.
-
Le regioni Messico, Montréal e Osaka hanno tre zone in uno o due data center fisici. Queste regioni sono in fase di espansione ad almeno tre data center fisici. Per ulteriori informazioni, consulta Località cloud e SLA della piattaforma Google Cloud. Per contribuire a migliorare l'affidabilità dei carichi di lavoro, valuta la possibilità di eseguire un deployment multiregionale. ↩