Come descritto in Disponibilità della piattaforma, l'infrastrutturaGoogle 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 app 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'app viene eseguito su una singola VM e se 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 SPOF. Considera lo stack di applicazioni a più livelli 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 app e un singolo database. Il bilanciatore del carico, il server delle app 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 dell'applicazione, 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 disponibilità è essenziale, come le applicazioni di vendita al dettaglio e social media. |
| Multizona | Workload che richiedono resilienza contro le 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à è più elevato. Inoltre, puoi archiviare e replicare 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 disponibilità 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 carichi di lavoro 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 HTTP(S) 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 HTTP/S. Il MIG 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 del server delle app.
- Un secondo MIG a livello di zona come backend per il bilanciatore del carico interno. Questo MIG 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 zona singola 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) | 99,95% |
Puoi aspettarti che le risorse di 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, vedi 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'istanza di server delle app 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 app 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 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 contro le interruzioni a livello di zona, puoi eseguire il provisioning di più istanze di risorse di zona (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 HTTP/S esterno regionale riceve le richieste degli utenti e risponde.
- Un MIG regionale è il backend per il bilanciatore del carico HTTP/S. Il MIG 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 delle app.
- Un secondo MIG regionale è il backend del bilanciatore del carico TCP. Questo MIG ha due VM Compute Engine in zone diverse. Ogni VM ospita un'istanza di un server delle app.
- 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) | 99,95% |
Puoi aspettarti che le risorse di infrastruttura elencate nella tabella precedente forniscano la seguente disponibilità aggregata e il seguente tempo di inattività mensile massimo stimato: Google Cloud
- 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, vedi 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 degli utenti all'istanza del server web nell'altra zona. Se una VM che ospita un server web o un'istanza del server delle app si arresta in modo anomalo, il MIG 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 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 configurato di VM. 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 regionale, devi attendere che Google risolva l'interruzione e poi 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 di servizio 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 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 per ogni bilanciatore del carico HTTP/S regionale è un MIG regionale. Ogni MIG contiene due VM Compute Engine in zone diverse. Ciascuna 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 delle app.
- Una seconda coppia di MIG regionali è il backend per i bilanciatori del carico interni. Ciascuno di questi MIG contiene due VM di Compute Engine in zone diverse. Ogni VM ospita un'istanza di un server delle app.
- 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 controllo 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, quindi considerare le risorse che si estendono su più regioni. Utilizza la seguente 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 doppia regione 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, vedi Fattori che influiscono sull'affidabilità dell'applicazione.
Effetti delle interruzioni 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 HTTP/S 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 app si arresta in modo anomalo, i bilanciatori del carico interni inviano richieste alle altre istanze del server delle app. 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 app 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.
Per informazioni sul funzionamento della replica multiregionale in Spanner, consulta Configurazioni regionali e multiregionali e Demistificare le configurazioni multiregionali di Spanner.
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. Dopodiché, 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.
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 HTTP/S esterno globale (con Cloud CDN abilitata) 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 verso la 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 a 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ù regioni. 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à delle implementazioni:
- Memorizzazione nella cache perimetrale utilizzando Cloud CDN
- Possibilità di utilizzare bucket Cloud Storage altamente durevoli 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 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 prendere in considerazione l'utilizzo di fallback di difesa in profondità, ove possibile. Per maggiori informazioni, vedi 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 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 bilanciamento 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 multiregionale 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, vedi Fattori che influiscono sull'affidabilità dell'applicazione.
Effetti delle interruzioni 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 HTTP/S esterno globale inoltra le richieste degli utenti alle altre istanze del server web. Se un'istanza del server delle app si arresta in modo anomalo, i bilanciatori del carico interni inviano le richieste alle altre istanze del server delle app. 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 HTTP/S esterno globale è resiliente alle interruzioni di zona e regione. I bilanciatori del carico interni sono risorse a livello di regione, quindi sono resilienti alle interruzioni di zona. Un'interruzione di servizio nella zona potrebbe interessare singole VM di Compute Engine. Tuttavia, le istanze del server web e del server delle app rimangono disponibili, perché le VM fanno parte dei gruppi di istanze gestite a livello di regione. I MIG 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 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 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. Dopo che Google ha risolto l'interruzione, devi 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 Demistificare le configurazioni multiregionali di Spanner.
Se si verificano interruzioni in due delle regioni di questa architettura, 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. 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à delle 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 intraprendere ulteriori passaggi. 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 le analisi retrospettive.
-
Per saperne di più sulle considerazioni specifiche per le regioni, consulta Area geografica e regioni. ↩