Come descritto in Disponibilità della piattaforma, l'infrastruttura diGoogle Cloud è progettata per supportare una disponibilità target del 99,9% per un carico di lavoro di cui è stato eseguito il deployment in una singola zona. La disponibilità target è del 99,99% per un deployment multizona1 e del 99,999% per un deployment multiregionale. Questa parte della Google Cloud guida all'affidabilità dell'infrastruttura fornisce indicazioni per il 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, ognuno progettato per svolgere una funzione specifica. Questi componenti sono in genere raggruppati in livelli in base alla funzione che svolgono e al loro rapporto 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 applicazione con un cluster di server delle applicazioni e un livello dati per la persistenza. Se un componente di questo stack di applicazioni dipende da una singola risorsa dell'infrastruttura, un errore di questa risorsa può influire sulla disponibilità dell'intero stack. Ad esempio, se il livello dell'applicazione viene eseguito su una singola VM e se la VM si arresta in modo anomalo, l'intero stack non è disponibile. Un componente di questo tipo è un single point of failure (SPOF).
Uno stack di applicazioni potrebbe avere più di un SPOF. Considera lo stack di applicazioni multilivello 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 delle applicazioni e un singolo database. Il bilanciatore del carico, il server delle applicazioni e il database in questo esempio sono SPOF. Un errore di uno di questi componenti può causare il mancato funzionamento delle richieste degli utenti all'applicazione.
Per rimuovere i SPOF nello stack di applicazioni, distribuisci le risorse in più posizioni ed esegui il deployment di risorse ridondanti.
Distribuire le risorse e creare 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 | Workload business critical in cui l'alta affidabilità (HA) è essenziale, come le applicazioni di vendita al dettaglio e social media. |
| Multizona | Workload che richiedono resilienza alle interruzioni di zona, ma possono tollerare alcuni tempi di inattività causati da interruzioni a livello di regione. |
| Zona singola | Carichi di lavoro che possono tollerare tempi di inattività o che possono essere implementati in un'altra posizione, se 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 gestisci un numero maggiore di risorse. Il volume di traffico di rete tra località diverse è maggiore. Inoltre, memorizzi e replichi più dati. Di conseguenza, il costo delle risorse cloud in un'architettura distribuita è più elevato e il funzionamento di questi deployment è più complesso. Per le applicazioni business-critical, il vantaggio di disponibilità di un'architettura distribuita potrebbe superare l'aumento dei costi e della complessità operativa.
Per le applicazioni non business-critical, l'alta affidabilità fornita da un'architettura distribuita potrebbe non essere essenziale. Alcune applicazioni hanno altri requisiti più importanti della disponibilità. Ad esempio, le applicazioni di batch computing richiedono connessioni di rete a bassa latenza e ad alta larghezza di banda tra le VM. Un'architettura a zona singola potrebbe essere adatta a 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 workload in Google Cloud:
- Deployment a zona singola
- Deployment multizona
- Deployment multiregionale con bilanciamento del carico regionale
- Deployment multiregionale con bilanciamento del carico globale
Deployment a zona singola
Il seguente diagramma mostra un'architettura dell'applicazione a zona singola con ridondanza in ogni livello, per ottenere una maggiore disponibilità delle funzioni eseguite da ogni componente:
Come mostrato nel diagramma precedente, questa architettura di esempio include i seguenti componenti:
- Un bilanciatore del carico delle applicazioni esterno regionale per ricevere e rispondere alle richieste degli utenti.
- Un gruppo di istanze gestite (MIG) a livello di zona come backend per il bilanciatore del carico delle applicazioni esterno regionale. Il gruppo di istanze gestite ha due VM di Compute Engine. Ogni VM ospita un'istanza di un server web.
- Un bilanciatore del carico di rete passthrough interno regionale per gestire la comunicazione tra i server web e i server delle applicazioni.
- Un secondo MIG 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 delle applicazioni.
- Un'istanza di database Cloud SQL (versione Enterprise) in cui l'applicazione scrive e legge i dati. 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 diagramma dell'architettura a una sola zona precedente:
| Risorsa | SLA (accordo sul livello del servizio) |
|---|---|
| Bilanciatore del carico esterno | 99,99% |
| Livello web: VM Compute Engine in una singola zona | 99,9% |
| Bilanciatore del carico interno | 99,99% |
| Livello applicazione: VM Compute Engine in una singola zona | 99,9% |
| Istanza Cloud SQL (versione Enterprise, configurazione HA) | 99,95% |
Puoi aspettarti che le risorse dell'infrastruttura Google Cloud elencate nella tabella precedente forniscano la seguente disponibilità aggregata e il seguente 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 prende in considerazione solo le risorse dell'infrastruttura mostrate nel diagramma dell'architettura precedente. Per valutare la disponibilità di un'applicazione in Google Cloud, devi prendere in considerazione anche altri fattori, come i seguenti:
- La progettazione interna dell'applicazione
- I processi 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à dell'applicazione.
Effetti delle interruzioni e indicazioni per il ripristino
In un'architettura di deployment 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 server web o un server delle applicazioni si arresta in modo anomalo, il MIG 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 delle applicazioni per connetterti al database.
Un'interruzione della zona o della regione influisce sulle VM Compute Engine e sulle istanze del database Cloud SQL in un deployment a zona singola. Un'interruzione della zona non influisce sul bilanciatore del carico in questa architettura perché è una risorsa regionale. Tuttavia, il bilanciatore del carico non può distribuire il traffico perché non ci sono backend disponibili. Se si verifica un'interruzione della zona, devi attendere che Google risolva l'interruzione, quindi verificare che l'applicazione funzioni come previsto.
La sezione successiva descrive un approccio architetturale che puoi utilizzare per distribuire le risorse su più zone, il che contribuisce a migliorare la resilienza dell'applicazione alle interruzioni di zona.
Deployment multizona
In un deployment in una singola zona, se si verifica un'interruzione del servizio, l'applicazione potrebbe non essere in grado di gestire le richieste finché il problema non viene risolto. Per migliorare la resilienza della tua applicazione contro le interruzioni di zona, puoi eseguire il provisioning di più istanze di risorse zonali (come le VM Compute Engine) in due o più zone. Per i servizi che supportano risorse con ambito regionale (come i bucket Cloud Storage), puoi eseguire il deployment di risorse regionali.
Il seguente diagramma mostra un'architettura multizona 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 delle applicazioni esterno regionale riceve e risponde alle richieste degli utenti.
- Un MIG regionale è il backend del 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 di rete passthrough interno regionale gestisce la comunicazione tra i server web e i server delle applicazioni.
- Un secondo MIG regionale è il backend del bilanciatore del carico interno. Questo MIG ha due VM Compute Engine in zone diverse. Ogni VM ospita un'istanza di un server delle applicazioni.
- Un'istanza Cloud SQL (versione Enterprise) 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 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 applicazione: VM Compute Engine in zone separate | 99,99% |
| Istanza Cloud SQL (versione Enterprise, configurazione HA) | 99,95% |
Puoi aspettarti 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,9999 x 0,9999 x 0,9999 x 0,9995 = 99,91%
- Tempo di inattività mensile massimo stimato: circa 39 minuti
Questo calcolo prende in considerazione solo le risorse dell'infrastruttura mostrate nel diagramma dell'architettura precedente. Per valutare la disponibilità di un'applicazione in Google Cloud, devi prendere in considerazione anche altri fattori, come i seguenti:
- La progettazione interna dell'applicazione
- I processi 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à dell'applicazione.
Effetti delle interruzioni e indicazioni per il ripristino
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 capacità adeguata. Ad esempio, se un'istanza del server web non funziona, il bilanciatore del carico inoltra le richieste utente all'istanza del server web nell'altra zona. Se una VM che ospita un'istanza di server web o server delle applicazioni 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 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 della zona sulla disponibilità dell'applicazione:
Come mostrato nel diagramma precedente, se si verifica un'interruzione del servizio 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 Compute Engine e una delle istanze del database Cloud SQL. ma 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 MIG garantiscono la creazione automatica di nuove VM 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. Dopo che Google avrà risolto l'interruzione, devi verificare che l'applicazione funzioni come previsto in tutte le zone in cui è implementata.
Se si verifica un'interruzione del servizio in entrambe le zone di questa architettura, 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 sono disponibili backend. 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 presentano opzioni architetturali per proteggere l'applicazione da interruzioni multizona e interruzioni a livello di regione.
Deployment multiregionale con bilanciamento del carico regionale
In un deployment a zona singola o multizona, se si verifica un'interruzione del servizio a livello di regione, l'applicazione non può gestire le richieste finché il problema non viene risolto. Per proteggere la tua applicazione da interruzioni a livello di regione, puoi distribuire le Google Cloud risorse in due o più regioni.
Il seguente diagramma mostra un'architettura multiregionale ad alta disponibilità, con i componenti di ogni livello dello stack dell'applicazione distribuiti su più regioni:
Come mostrato nel diagramma precedente, questa architettura di esempio include i seguenti componenti:
- Una zona Cloud DNS pubblica con una policy di routing che indirizza il traffico a due regioni Google Cloud .
- Un bilanciatore del carico delle applicazioni esterno regionale in ogni regione per ricevere e rispondere alle richieste degli utenti.
- Il backend per ogni bilanciatore del carico delle applicazioni esterno regionale è un MIG regionale. Ogni MIG contiene due VM di Compute Engine in zone diverse. Ciascuna di queste VM ospita un'istanza di un server web.
- Un bilanciatore del carico di rete passthrough interno regionale in ogni regione gestisce la comunicazione tra i server web e i server delle applicazioni.
- Una seconda coppia di MIG regionali è il backend per i bilanciatori del carico interni. Ciascuno di questi MIG contiene due VM Compute Engine in zone diverse. Ogni VM ospita un'istanza di un server delle applicazioni.
- L'applicazione scrive e legge dati da un'istanza Spanner multiregionale. La configurazione multiregionale utilizzata in questa
architettura (
eur6) include quattro repliche di lettura e scrittura. Le repliche di lettura e scrittura vengono sottoposte a provisioning in modo uniforme in due regioni e in zone separate. La configurazione multiregionale di Spanner include anche una replica di testimone in una terza regione.
Disponibilità aggregata: deployment multiregionale con bilanciamento del carico regionale
Nel deployment multiregionale mostrato nel diagramma precedente, i bilanciatori del carico e le VM vengono sottoposti a provisioning in modo ridondante in due regioni. La zona DNS è una risorsa globale e l'istanza Spanner è una risorsa multiregionale.
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 considerare le risorse che si estendono su più regioni. Segui questa procedura:
- Calcola la disponibilità aggregata delle risorse dell'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 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 dell'infrastruttura tenendo conto della 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 che puoi aspettarti è limitata alla disponibilità target per i deployment multiregionali, ovvero il 99,999%.
Calcola la disponibilità aggregata di tutte le risorse dell'infrastruttura, incluse 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 prende in considerazione solo le risorse dell'infrastruttura mostrate nel diagramma dell'architettura precedente. Per valutare la disponibilità di un'applicazione in Google Cloud, devi prendere in considerazione anche altri fattori, come i seguenti:
- La progettazione interna dell'applicazione
- I processi 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à dell'applicazione.
Effetti delle interruzioni del servizio e indicazioni per il ripristino
Se un componente di questo deployment multiregionale 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 delle applicazioni esterno regionale inoltra le richieste degli utenti alle altre istanze del server web nella regione. Allo stesso modo, se una delle istanze del server delle applicazioni si arresta in modo anomalo, i bilanciatori del carico interni inviano richieste alle altre istanze del server delle applicazioni. Se una delle VM si arresta in modo anomalo, i MIG assicurano che vengano create automaticamente nuove VM per mantenere il numero minimo configurato di VM.
Un'interruzione in una singola zona non influisce sui bilanciatori del carico, perché sono risorse regionali e sono resilienti alle interruzioni di zona. Un'interruzione di servizio nella zona potrebbe interessare singole VM Compute Engine. Tuttavia, le istanze del server web e del server delle applicazioni rimangono disponibili perché le VM fanno parte dei MIG regionali. I MIG assicurano che vengano create automaticamente nuove VM per mantenere il numero minimo configurato di VM. L'istanza Spanner in questa architettura utilizza una configurazione multiregionale, resiliente alle interruzioni delle zone.
Per informazioni sul funzionamento della replica multiregionale in Spanner, consulta Configurazioni regionali e multiregionali e Demystifying Spanner multi-region configurations.
Il seguente diagramma mostra la stessa architettura multiregionale del diagramma precedente e gli effetti di un'interruzione a livello di una singola regione sulla disponibilità dell'applicazione:
Come mostrato nel diagramma precedente, anche se si verifica un'interruzione in entrambe le zone di una 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 Spanner multiregionale è resiliente alle interruzioni a livello di regione. Dopo che Google ha risolto l'interruzione, devi verificare che l'applicazione funzioni come previsto nella regione che ha subito l'interruzione.
Se si verificano interruzioni in due delle regioni di questa architettura, l'applicazione non è disponibile. Attendi che Google risolva le interruzioni. Poi verifica che l'applicazione funzioni come previsto in tutte le regioni in cui è implementata.
Per i deployment multiregionali, anziché utilizzare bilanciatori del carico regionali, puoi valutare l'utilizzo di un bilanciatore del carico globale. La sezione successiva presenta un'architettura di deployment multiregionale che utilizza un bilanciatore del carico globale e descrive i vantaggi e i rischi di questo approccio.
Per scoprire come progettare e configurare le policy di routing Cloud DNS con bilanciatori del carico esterni regionali per la resilienza multiregionale, consulta Alta affidabilità per i bilanciatori del carico delle applicazioni esterni regionali.
Deployment multiregionale con bilanciamento del carico globale
Il seguente diagramma mostra un deployment multiregionale 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 delle applicazioni 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 del bilanciatore del carico delle applicazioni 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 a quelli dell'architettura mostrata in Deployment multiregionale con bilanciamento del carico regionale.
Vantaggi e rischi del bilanciamento del carico globale per i deployment multiregionali
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 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 in più Google Cloud regioni.
- 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 tuoi deployment:
- Edge caching utilizzando Cloud CDN
- Possibilità di utilizzare bucket Cloud Storage altamente durevoli come backend
- Policy 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 regionali, 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 risorse globali potrebbe rendere non disponibile il bilanciatore del carico globale.
Per mitigare questi rischi, devi gestire attentamente le modifiche al bilanciatore del carico globale e, se possibile, prendere in considerazione l'utilizzo di fallback di difesa in profondità. Per maggiori informazioni, 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 vengono sottoposti a deployment in modo ridondante in due regioni. Il bilanciatore del carico esterno è una risorsa globale e l'istanza Spanner è una risorsa multiregionale.
Per calcolare la disponibilità aggregata di questo deployment, calcoliamo innanzitutto la disponibilità aggregata delle risorse in ogni regione, quindi prendiamo in considerazione le risorse che si estendono su più regioni.
- Calcola la disponibilità aggregata delle risorse dell'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 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 dell'infrastruttura tenendo conto della 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 che puoi aspettarti è limitata alla disponibilità target per i deployment multiregionali, ovvero il 99,999%.
Calcola la disponibilità aggregata di tutte le risorse dell'infrastruttura, inclusi 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 prende in considerazione solo le risorse dell'infrastruttura mostrate nel diagramma dell'architettura precedente. Per valutare la disponibilità di un'applicazione in Google Cloud, devi prendere in considerazione anche altri fattori, come i seguenti:
- La progettazione interna dell'applicazione
- I processi 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à dell'applicazione.
Effetti delle interruzioni del servizio e indicazioni per il ripristino
Se un componente di questa architettura non funziona, l'applicazione continua a funzionare se in ogni livello esiste almeno un componente funzionante con capacità adeguata. Ad esempio, se un'istanza del server web non funziona, il bilanciatore del carico delle applicazioni esterno globale inoltra le richieste degli utenti alle altre istanze del server web. Se un'istanza del server delle applicazioni si arresta in modo anomalo, i bilanciatori del carico interni inviano le richieste alle altre istanze del server delle applicazioni. Se una delle VM si arresta in modo anomalo, i MIG assicurano che vengano create automaticamente nuove VM per mantenere il numero minimo configurato di VM.
Se si verifica un'interruzione del servizio in una delle zone di una regione, il bilanciatore del carico non viene interessato. Il bilanciatore del carico delle applicazioni esterno globale è resiliente alle interruzioni di zona e regione. I bilanciatori del carico interni sono risorse a livello di regione e sono resilienti alle interruzioni di zona. Un'interruzione di servizio nella zona potrebbe interessare singole VM di Compute Engine. Tuttavia, i server web e i server delle applicazioni rimangono disponibili, perché le VM fanno parte dei MIG regionali. I MIG garantiscono la creazione automatica di nuove VM per mantenere il numero minimo configurato di VM. L'istanza Spanner in questa architettura utilizza una configurazione multiregionale, resiliente alle interruzioni di zona.
Il seguente diagramma mostra la stessa architettura multiregionale del diagramma precedente e gli effetti di un'interruzione a livello di una singola regione sulla disponibilità dell'applicazione:
Come mostrato nel diagramma precedente, anche se si verifica un'interruzione in entrambe le zone di una regione, l'applicazione rimane disponibile perché in ogni regione viene eseguito il deployment di uno stack di applicazioni indipendente. Il bilanciatore del carico delle applicazioni esterno globale instrada le richieste degli utenti all'applicazione nella regione non interessata dall'interruzione. L'istanza Spanner multiregionale è resiliente alle interruzioni a livello di regione. Dopo che Google avrà risolto l'interruzione, dovrai verificare che l'applicazione funzioni come previsto nella regione interessata dall'interruzione.
Per informazioni sul funzionamento della replica multiregionale in Spanner, consulta Configurazioni regionali e multiregionali e Demystifying Spanner multi-region configurations.
Se si verificano interruzioni in due delle regioni di questa architettura, l'applicazione non è disponibile. Il bilanciatore del carico delle applicazioni esterno globale è disponibile, ma non può distribuire il traffico perché non sono disponibili backend. Attendi che Google risolva le interruzioni. Dopodiché, verifica che l'applicazione funzioni come previsto in tutte le regioni in cui è implementata.
I deployment multiregionali possono contribuire a garantire l'alta disponibilità per le applicazioni aziendali più critiche. Per garantire la continuità operativa 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 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, gestire gli incidenti, verificare lo stato dell'applicazione dopo gli incidenti ed eseguire analisi retrospettive.
Per proteggerti da interruzioni e errori di configurazione del bilanciatore del carico globale, puoi implementare una strategia di failover o bypass automatica utilizzando Cloud DNS e bilanciatori del carico di backup regionali. Per saperne di più, consulta Strategie di failover per i bilanciatori del carico delle applicazioni esterni globali.
-
Per saperne di più sulle considerazioni specifiche per le regioni, consulta Area geografica e regioni. ↩