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 multizona e del 99,999% per un deployment multiregionale. Questa parte della guida all'affidabilità dell'infrastruttura Google Cloud fornisce indicazioni sul deployment, architetture di esempio e tecniche di progettazione che possono aiutarti a proteggere i tuoi carichi di lavoro da errori a livello di risorsa, zona e regione.
Evita i single point of failure
Le applicazioni sono generalmente composte da più componenti interdipendenti, ciascuno progettati per svolgere 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. Per Ad esempio, se il livello app 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 è SPOF (Single point of failure).
Uno stack di applicazioni potrebbe avere più di un punto SPOF. Considera l'approccio multilivello illustrato nel seguente diagramma:
Come mostrato nel diagramma precedente, questa architettura di esempio contiene un singolo bilanciatore del carico, due server web, un singolo server di app e un singolo database. Il bilanciatore del carico, il server app e il database in questo esempio sono SPOF. Un errore di uno qualsiasi di questi componenti può causare la mancata riuscita delle richieste dell'utente all'applicazione.
Per rimuovere i punti di vulnerabilità singoli nello stack dell'applicazione, 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 sul carico di lavoro |
|---|---|
| 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. |
Costi, latenza e considerazioni operative
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 per archiviare e replicare più dati. Di conseguenza, il costo delle tue risorse cloud un'architettura distribuita è più elevata e il funzionamento di tali deployment implica una maggiore complessità. Per le applicazioni business-critical, il vantaggio della disponibilità di un'architettura distribuita potrebbe superare l'aumento dei costi e dei costi complessità.
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 una rete a bassa latenza e a larghezza di banda elevata e connessioni tra le VM. Un'architettura a zona singola potrebbe essere adatta applicazioni come questo. Inoltre, può aiutarti a ridurre i costi del trasferimento di 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 multiregionale 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 all'utente richieste.
- 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 alle istanze dell'app server.
- Un secondo gruppo di istanze gestite di zona come backend per il bilanciatore del carico interno. Questo gruppo di istanze gestite contiene due VM di Compute Engine. Ogni VM ospita un'istanza di un server di applicazioni.
- Un'istanza di database Cloud SQL (versione Enterprise) che l'applicazione scrive e da cui legge i dati. Il database viene replicato manualmente in un secondo Istanza di database Cloud SQL nella stessa zona.
Disponibilità aggregata: deployment in una singola zona
La tabella seguente mostra la disponibilità di ogni livello nell'istruzione precedente diagramma dell'architettura a zona singola:
| Risorsa | SLA (accordo sul livello del servizio) |
|---|---|
| Bilanciatore del carico esterno | 99,99% |
| Livello web: VM di Compute Engine in una zona singola | 99,9% |
| Bilanciatore del carico interno | 99,99% |
| Livello 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 inattività 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 dell'applicazione in Google Cloud, è necessario considerare anche altri fattori, le seguenti:
- 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 ripristino
In un'architettura di deployment a zona singola, in caso di errore di un componente, l'applicazione può elaborare le richieste se ogni livello contiene almeno un modello componente con capacità adeguata. Ad esempio, in caso di errore di un'istanza del server web, il bilanciatore del carico inoltra le richieste dell'utente alle altre istanze del server web. Se La VM che ospita un server web o un'istanza del server di app si arresta in modo anomalo, il gruppo di istanze gestite garantisce che viene creata automaticamente una nuova VM. Se il database si arresta in modo anomalo, devi manualmente attivare il secondo database e aggiornare le istanze dell'app server a cui connettersi del database.
Un'interruzione della zona o della regione influisce sulle VM di Compute Engine e Istanze di database Cloud SQL in un deployment a zona singola. Un'interruzione del 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. In caso di interruzione di una zona, devi attendere che Google risolvere l'interruzione e 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 a zona singola, se si verifica un'interruzione in una zona, l'applicazione potrebbe non sarà in grado di gestire le richieste finché il problema non verrà 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 risorse con ambito a livello di regione ad esempio i bucket Cloud Storage, puoi eseguire il deployment di risorse a livello di regione.
Il seguente diagramma mostra un'architettura multizona ad alta disponibilità con i componenti di ogni livello dello stack di applicazioni distribuiti tra 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 di Compute Engine in zone diverse. Ogni VM ospita un'istanza un server web.
- Un bilanciatore del carico interno gestisce la comunicazione tra il server web e alle istanze dell'app server.
- Un secondo gruppo di istanze gestite regionale è il backend per il bilanciatore del carico TCP. Questo gruppo di istanze gestite ha due VM di Compute Engine in zone diverse. Ogni VM ospita un'istanza su un server di app.
- Un'istanza Cloud SQL (versione Enterprise) configurata per l'HA è il database dell'applicazione. L'istanza del database principale è replicata in modo sincrono con un'istanza di database in standby.
Disponibilità aggregata: deployment multizona
La tabella seguente mostra la disponibilità di ogni livello nell'istruzione precedente diagramma dell'architettura a doppia zona:
| Risorsa | SLA (accordo sul livello del servizio) |
|---|---|
| Bilanciatore del carico esterno | 99,99% |
| Livello web: VM di Compute Engine in zone separate | 99,99% |
| Bilanciatore del carico interno | 99,99% |
| Livello 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 per fornire la seguente disponibilità aggregata e 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 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 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, in caso di errore di un'istanza del server web, il carico inoltra le richieste dell'utente 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, perché si tratta di di 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 fanno in modo che le nuove VM vengono creati automaticamente per mantenere il numero minimo configurato di VM. Se l'istanza del database Cloud SQL principale è interessata da un'interruzione del servizio Cloud SQL fail over automaticamente all'istanza in 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.
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 venga applicato a livello regionale in cui si verifica un'interruzione del servizio. 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 il problema, quindi verificare che l'applicazione funzioni come previsto.
Le sezioni successive presentano opzioni di architettura per proteggere la tua applicazione contro le interruzioni multizona e a livello di regione.
Deployment su più regioni con bilanciamento del carico a livello di regione
In un deployment a zona singola o multizona, se si verifica un'interruzione in una regione, l'applicazione non può gestire le richieste finché 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 a disponibilità elevata tra regioni, con i componenti di ogni livello dello stack di applicazioni distribuiti in più regioni:
Come mostrato nel diagramma precedente, questa architettura di esempio include i seguenti componenti:
- Una zona Cloud DNS pubblica con un criterio di routing che indirizza il traffico 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 per più regioni utilizzata in questo
(
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 un file witness replica in una terza regione.
Disponibilità aggregata: più regioni con il 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 di 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%
Calcolare la disponibilità aggregata delle risorse dell'infrastruttura considerando la ridondanza a due regioni dei bilanciatori del carico 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%.
Calcolare la disponibilità aggregata di tutta l'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 di infrastruttura mostrate nel diagramma dell'architettura precedente. Per valutare la disponibilità di un dell'applicazione in Google Cloud, è necessario considerare anche altri fattori, le seguenti:
- Il design interno dell'applicazione
- I processi e gli strumenti DevOps utilizzati per creare, eseguire il deployment e dell'applicazione, le sue dipendenze e l'infrastruttura
Per ulteriori informazioni, vedi Fattori che influiscono sull'affidabilità dell'applicazione.
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, in caso di errore di un'istanza del server web, l'istanza regionale il bilanciatore del carico HTTP/S esterno inoltra le richieste dell'utente all'altro server web di archiviazione nella regione. Analogamente, se una delle istanze del server di app si arresta in modo anomalo, i bilanciatori del carico interni inviano richieste alle altre istanze dell'app server. 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. Una zona potrebbe interessare le singole VM di 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 fanno in modo che le nuove VM vengano create automaticamente per mantenere il numero minimo configurato di VM. L'istanza Spanner in questo usa una configurazione multiregionale, resiliente alle zone o in caso di interruzione del servizio.
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 multiregionale 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 in qualsiasi regione, l'applicazione rimane disponibile, viene eseguito il deployment dello stack di applicazioni in ogni regione. La zona DNS indirizza le richieste degli utenti alla regione non interessata dall'interruzione del servizio. La località multiregionale L'istanza Spanner è resiliente alle interruzioni delle regioni. Dopo la risoluzione di Google l'interruzione, devi verificare che l'applicazione venga eseguita come previsto nella regione su 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 di deployment multiregionale che utilizza un bilanciatore del carico globale ne descrivano i vantaggi e i rischi.
Deployment multiregionale con bilanciamento del carico globale
Il seguente diagramma mostra un deployment multiregionale alternativo che utilizza un bilanciatore del carico globale anziché a livello di regione:
Come mostrato nel diagramma precedente, questa architettura utilizza un bilanciatore del carico HTTP/S esterno globale (con Cloud CDN abilitato) per ricevere e rispondere alle richieste degli utenti. Ogni regola di forwarding del bilanciatore del carico utilizza un singolo Indirizzo IP; Non devi configurare un record DNS separato per ogni regione. I backend per il bilanciatore del carico HTTP/S esterno globale sono due gruppi di istanze gestite a livello di regione. Il bilanciatore del carico indirizza le richieste alla regione più vicina agli utenti.
Tutti gli altri componenti di questa architettura sono identici dell'architettura mostrata Deployment in più regioni con bilanciamento del carico a livello di regione.
Vantaggi e rischi del bilanciamento del carico globale per i deployment multiregionali
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 caricamento globale bilanciatore del carico:
- Devi gestire un solo bilanciatore del carico.
- I bilanciatori del carico globali utilizzano un singolo indirizzo IP anycast per fornire carico il bilanciamento del carico tra le regioni di Google Cloud.
- I bilanciatori del carico globali sono resilienti alle interruzioni delle regioni e offrono tra regioni diverse.
- I bilanciatori del carico globali supportano le seguenti funzionalità, che possono contribuire a migliorare
l'affidabilità dei tuoi deployment:
- 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 per errore elimini una regola di forwarding, 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 influisce risorse globali potrebbero rendere non disponibile il bilanciatore del carico globale.
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 pagina Suggerimenti per gestire il rischio di interruzioni delle risorse globali.
Disponibilità aggregata: più regioni deployment 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 è un globale e l'istanza Spanner è a più regioni risorsa.
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 di 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%
Calcolare la disponibilità aggregata delle risorse dell'infrastruttura considerando la ridondanza a due regioni del bilanciatore del carico interno 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 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 inattività mensile massimo stimato: circa 5 minuti e 11 secondi
Questo calcolo considera solo le risorse di infrastruttura mostrate nel precedente diagramma dell'architettura. Per valutare la disponibilità di un dell'applicazione in Google Cloud, è necessario considerare anche altri fattori, le seguenti:
- Il design interno dell'applicazione
- I processi e gli strumenti DevOps utilizzati per creare, eseguire il deployment e dell'applicazione, le sue dipendenze e l'infrastruttura
Per ulteriori informazioni, consulta Fattori che influiscono sull'affidabilità delle applicazioni.
Effetti delle interruzioni e indicazioni per il ripristino
Se un componente di questa architettura presenta errori, l'applicazione continua funzionano se in ogni progetto esiste almeno un componente funzionante con capacità adeguata livello. Ad esempio, in caso di errore di un'istanza del server web, il traffico HTTP/S esterno globale Il bilanciatore del carico inoltra le richieste dell'utente 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 le nuove VM vengono create automaticamente per mantenere il numero minimo configurato delle VM in esecuzione.
Se si verifica un'interruzione in una delle zone di qualsiasi 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 di una zona può interessare di 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 multiregionale 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 in qualsiasi regione, l'applicazione rimane disponibile, viene eseguito il deployment dello stack di applicazioni in ogni regione. Il carico HTTP/S esterno globale il bilanciatore del carico instrada le richieste dell'utente all'applicazione nella regione interessate dall'interruzione. L'istanza Spanner multiregionale è resiliente alle interruzioni a livello di regione. Una volta che Google ha risolto l'interruzione, devi verificare che il l'applicazione viene eseguita 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 di backend. Attendi che Google risolva le interruzioni. Quindi, verifica che dell'applicazione viene eseguita come previsto in tutte le regioni in cui è stata eseguita il deployment.
Gli implementazioni multiregione possono contribuire a garantire l'alta disponibilità per le 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 svolgere alcuni passaggi aggiuntivi. Ad esempio, devi eseguire pianificazione della capacità per garantire che venga prenotata capacità sufficiente tutte le regioni o i rischi associati alla scalabilità automatica di emergenza accettabile. Devi anche implementare pratiche operative per i test di ripristino dei dati, la gestione degli incidenti, la verifica dello stato dell'applicazione dopo gli incidenti e l'esecuzione di analisi retrospettive.