Progettazione del ripristino di emergenza per le interruzioni dell'infrastruttura cloud

Last reviewed 2024-05-10 UTC

Questo articolo fa parte di una serie che tratta Ripristino di emergenza (RE) in Google Cloud. Questa parte illustra il processo per la progettazione dell'architettura dei carichi di lavoro utilizzando Google Cloud e componenti di base resilienti alle interruzioni dell'infrastruttura cloud.

La serie è costituita dai seguenti componenti:

• Guida alla pianificazione del ripristino di emergenza
• Componenti di base per il ripristino di emergenza
• Scenari di ripristino di emergenza per i dati
• Scenari di ripristino di emergenza per le applicazioni
• Architettura del ripristino di emergenza per carichi di lavoro con limitazioni a livello di località
• Casi d'uso per il ripristino di emergenza: applicazioni di analisi dei dati con limitazioni a livello di località
• Progettazione del ripristino di emergenza per le interruzioni dell'infrastruttura cloud (questo documento)

Introduzione

Quando le aziende spostano i carichi di lavoro nel cloud pubblico, devono tradurre la loro comprensione della creazione di sistemi on-premise resilienti all'iperscalabilità dei cloud provider come Google Cloud. Questo articolo mappa i concetti standard del settore relativi al ripristino di emergenza come RTO (Recovery Time Objective) e RPO (Recovery Point Objective) a Google Cloud dell'infrastruttura.

Le indicazioni contenute in questo documento seguono uno dei principi fondamentali di Google per la: ottenere una disponibilità del servizio estremamente elevata: pianifica gli errori. Mentre Google Cloud offre un servizio estremamente affidabile, le emergenze - disastri naturali, tagli di fibre ottiche e infrastrutture complesse e imprevedibili errori, che causano interruzioni del servizio. La pianificazione delle interruzioni consente ai clienti Google Cloud di creare applicazioni con prestazioni prevedibili a questi eventi inevitabili, grazie all'uso dei prodotti Google Cloud con "integrato" i meccanismi di RE.

Il ripristino di emergenza è un argomento vasto che copre molto di più del semplice guasti dell'infrastruttura, come bug del software o corruzione dei dati, devono avere un piano end-to-end completo. Tuttavia, questo articolo si concentra su una di un piano generale di RE: come progettare applicazioni resilienti in caso di interruzioni dell'infrastruttura cloud. Nello specifico, questo articolo illustra i seguenti argomenti:

1. L'infrastruttura Google Cloud, il modo in cui gli eventi di emergenza si manifestano interruzioni di Google Cloud e come Google Cloud è progettato per ridurre al minimo la frequenza e l'ambito delle interruzioni.
2. Una guida alla pianificazione dell'architettura che fornisce un framework per la classificazione e la progettazione di applicazioni in base ai risultati di affidabilità desiderati.
3. Un elenco dettagliato di prodotti Google Cloud selezionati che offrono RE integrata che potresti voler usare nella tua applicazione.

Per ulteriori dettagli sulla pianificazione generale di RE e sull'utilizzo di Google Cloud come componente nella tua strategia di RE on-premise, guida alla pianificazione del ripristino di emergenza. Inoltre, anche se Disponibilità elevata è un concetto strettamente correlato al ripristino di emergenza, non è trattato in questo . Per ulteriori dettagli sulla progettazione dell'alta disponibilità, consulta framework dell'architettura Google Cloud.

Nota sulla terminologia: questo articolo fa riferimento alla disponibilità quando sul fatto che un prodotto è accessibile e utilizzabile in modo significativo nel tempo, mentre con affidabilità si intende un insieme di attributi, tra cui disponibilità, ma anche aspetti come durabilità e correttezza.

In che modo Google Cloud è progettato per la resilienza

Data center di Google

I data center tradizionali si basano sulla massimizzazione della disponibilità componenti. Nel cloud, la scalabilità consente a operatori come Google di distribuire i servizi in molti componenti utilizzando tecnologie di virtualizzazione e quindi superano l'affidabilità dei componenti tradizionali. Ciò significa che puoi spostare il tuo modo di pensare all'architettura di affidabilità lontano dalla miriade di dettagli che una volta on-premise. Piuttosto che preoccuparsi delle varie modalità di errore del come il raffreddamento e l'erogazione di energia, puoi pianificare sui prodotti Google Cloud e sulle metriche di affidabilità dichiarate. Queste metriche riflettono il rischio aggregato di interruzione dell'intero l'infrastruttura sottostante. Questo ti permette di concentrarti progettazione dell'applicazione, deployment e operazioni invece che infrastruttura. gestione dei dispositivi.

Google progetta la propria infrastruttura in modo da raggiungere target di disponibilità aggressivi in base sulla nostra vasta esperienza nello sviluppo e nella gestione di data center moderni. Google sta leader mondiale nella progettazione di data center. Dall'alimentazione al raffreddamento alle reti, ogni la tecnologia dei data center presenta le proprie ridondanze e misure di mitigazione, tra cui: FMEA piani. I data center di Google sono integrati un modo che bilancia questi numerosi rischi diversi e presenti ai clienti una previsto e coerente per quanto riguarda i prodotti Google Cloud. Google utilizza la sua esperienza per modellare la disponibilità del servizio fisico in generale logica del sistema per assicurare che la progettazione del data center le aspettative. I tecnici di Google si impegnano a fondo dal punto di vista operativo per garantire vengono soddisfatte. La disponibilità effettiva misurata di solito supera le nostre definire i target con un margine ragionevole.

Riassumendo tutti questi rischi e le relative mitigazioni dei data center, rivolti all'utente Google Cloud, Google Cloud ti solleva dal e le responsabilità aziendali. Puoi invece concentrarti sull'affidabilità progettata regioni e zone di Google Cloud.

Aree geografiche e zone

I prodotti Google Cloud sono forniti in un gran numero regioni e zone. Le regioni sono aree geografiche fisicamente indipendenti che contengono tre o più diverse. Le zone rappresentano gruppi di risorse di calcolo fisico all'interno di una regione che hanno un elevato grado di indipendenza l’uno dall’altro in termini di e logica. Offrono un'elevata larghezza di banda e una rete a bassa latenza con altre zone nella stessa regione. Ad esempio, La regione asia-northeast1 del Giappone include tre zone: asia-northeast1-a, asia-northeast1-b e asia-northeast1-c.

I prodotti Google Cloud sono suddivisi in risorse di zona, risorse regionali o di risorse multiregionali.

Le risorse di zona sono ospitate all'interno di una singola zona. Un'interruzione del servizio di la zona può interessare tutte le risorse al suo interno. Ad esempio, un L'istanza Compute Engine viene eseguita in una singola zona specificata; in caso di guasto hardware interrompe il servizio in quella zona, l'istanza Compute Engine non disponibile per tutta la durata dell'interruzione.

Il deployment delle risorse di regione viene eseguito in modo ridondante in più zone all'interno di un regione. Ciò offre loro una maggiore affidabilità rispetto alle risorse di zona.

Le risorse per più regioni sono distribuite all'interno e tra le regioni. Nel le risorse generiche multiregionali hanno un'affidabilità maggiore rispetto a quella Google Cloud. A questo livello, però, i prodotti devono ottimizzare la disponibilità, prestazioni ed efficienza delle risorse. Di conseguenza, è importante comprendere i compromessi di ciascun prodotto multiregionale che decidi di utilizzare. Questi I compromessi sono documentati in base al prodotto specifico più avanti in questo documento.

Come sfruttare zone e regioni per ottenere affidabilità

Gli SRE di Google gestiscono e scalano prodotti utente globali e altamente affidabili come Gmail e cerca attraverso una varietà di tecniche e tecnologie che permettono sfruttare infrastrutture informatiche in tutto il mondo. Sono inclusi i reindirizzamenti il traffico proveniente da località non disponibili utilizzando il bilanciamento del carico globale, in numerose repliche di luoghi in tutto il mondo e la replica di dati tra più località. Queste stesse funzionalità sono disponibili per Google Cloud attraverso prodotti come Cloud Load Balancing, Google Kubernetes Engine (GKE), e Spanner.

In genere Google Cloud progetta prodotti che offrono i seguenti livelli di per zone e regioni:

Risorsa	Esempi	Obiettivo di progettazione della disponibilità	Tempo di inattività implicito
A livello di zona	Compute Engine, Persistent Disk	99,9%	8,75 ore / anno
Regionale	Cloud Storage a livello di regione, disco permanente replicato, GKE a livello di regione	99,99%	52 minuti all'anno

Nota: queste sono linee guida per la progettazione. Gli impegni sul livello di servizio di Google Cloud disponibile in Accordi sul livello del servizio di Google Cloud.

Confronta gli obiettivi di progettazione della disponibilità di Google Cloud con di tempo di inattività per identificare le risorse Google Cloud appropriate. Mentre i design tradizionali si concentrano sul miglioramento della disponibilità a livello di componente per migliorare la disponibilità dell'applicazione risultante, i modelli cloud si concentrano invece dei componenti per raggiungere questo obiettivo. Molti prodotti in Google Cloud utilizza questa tecnica. Ad esempio, Spanner offre una che compone più regioni al fine di fornire il 99,999% la disponibilità del servizio.

La composizione è importante perché, senza di essa, la disponibilità dell'applicazione Non può superare quello dei prodotti Google Cloud che utilizzi. di fatto, a meno che l'applicazione non si verifica mai, avrà una disponibilità inferiore rispetto a quella sottostante Google Cloud. Il resto di questa sezione mostra in generale come una composizione di prodotti a livello di zona e di regione per ottenere rispetto a quella fornita da una singola zona o regione. La sezione successiva fornisce una guida pratica per applicare questi principi alle tue applicazioni.

Pianificazione per gli ambiti di interruzione delle zone

I guasti dell'infrastruttura di solito causano interruzioni del servizio in una singola zona. Entro una regione, le zone sono progettate per ridurre al minimo il rischio di errori correlati nelle altre zone e un'interruzione del servizio in una zona di solito non da un'altra zona nella stessa regione. Un'interruzione con ambito in una zona non significa necessariamente che l'intera zona non è disponibile, definisce solo limite dell'incidente. Un'interruzione di una zona può non avere sulle tue risorse specifiche in quella zona.

Si tratta di un caso più raro, ma è anche fondamentale notare che più zone alla fine subiscono ancora un'interruzione correlata a un certo punto all'interno di una singola regione. Quando si verifica un'interruzione in due o più zone, l'ambito di interruzione regionale la seguente strategia.

Le risorse regionali sono progettate per resistere alle interruzioni di zona che fornisce un servizio da una composizione di più zone. Se una delle zone quando una risorsa di regione viene interrotta, la risorsa la disponibilità da un'altra zona. Controlla attentamente la funzionalità del prodotto descrizione nell'appendice per ulteriori dettagli.

Google Cloud offre solo poche risorse di zona, ovvero Compute Engine macchine virtuali (VM) e Persistent Disk. Se prevedi di utilizzare risorse a livello di zona, dovrai eseguire personalmente la composizione delle risorse progettando, creando e testare failover e ripristino tra risorse di zona situate in diverse. Ecco alcune strategie:

• Instradamento rapido del traffico alle macchine virtuali in un'altra zona utilizzando Cloud Load Balancing quando un controllo di integrità determina che una zona è che stanno riscontrando problemi.
• Usa i modelli di istanza Compute Engine e/o i gruppi di istanze gestite per di eseguire e scalare istanze VM identiche in più zone.
• Usa un Persistent Disk regionale per replicare in modo sincrono i dati in un altro in una regione. Consulta Opzioni di alta disponibilità che utilizzano DP regionali per ulteriori dettagli.

Pianificazione per gli ambiti di interruzione a livello di regione

Un'interruzione a livello di regione è un'interruzione del servizio che interessa più di una zona in un in una singola regione. Si tratta di interruzioni su scala più ampia, meno frequenti e che possono da calamità naturali o guasti dell'infrastruttura su larga scala.

Per un prodotto regionale progettato per fornire una disponibilità del 99,99%, viene un'interruzione del servizio può comunque tradursi in quasi un'ora di inattività per un prodotto ogni anno. Pertanto, le applicazioni critiche potrebbero dover disporre piano di RE multiregionale se la durata dell'interruzione non è accettabile.

Le risorse multiregionali sono progettate per resistere alle interruzioni delle regioni che fornisce un servizio da più regioni. Come descritto in precedenza, dei prodotti devono trovare un compromesso tra latenza, coerenza e costo. Il tipo di operazione più comune è disattivata tra la replica dei dati sincrona e quella asincrona. Asincrona la replica offre una latenza minore a scapito del rischio di perdita di dati durante o un'interruzione del servizio. Pertanto, è importante controllare la descrizione delle funzionalità del prodotto Appendice per maggiori dettagli.

Nota: in BigQuery, una località multiregionale non fornisce la replica tra regioni o la ridondanza a livello di regione. I dati verranno archiviati in un a una singola regione all'interno della posizione geografica.

Se vuoi utilizzare risorse regionali e rimanere resiliente alle regioni di servizio, devi eseguire la tua composizione delle risorse progettando, creando e testando il failover e il ripristino tra regioni in più regioni. Oltre alle strategie a livello di zona, di cui sopra, che puoi applicare anche a più regioni, considera:

• Le risorse di regione devono replicare i dati in una regione secondaria, un'opzione di archiviazione multiregionale, come Cloud Storage, o un cloud ibrido come GKE Enterprise.
• Dopo aver implementato una mitigazione delle interruzioni a livello di regione, testala regolarmente. Ci sono poche cose peggiori che pensare di essere resistenti a una singola regione per poi scoprire che non è così quando si verifica davvero.

Approccio a resilienza e disponibilità di Google Cloud

Google Cloud supera regolarmente i propri target di progettazione della disponibilità, ma dovresti non dare per scontato che questo importante rendimento passato sia la disponibilità minima che puoi progettare. Dovresti invece selezionare le dipendenze Google Cloud progettati per i target superano l'affidabilità prevista dell'applicazione, il tempo di inattività delle applicazioni più il tempo di inattività di Google Cloud offre che stai cercando.

Un sistema ben progettato è in grado di rispondere alla domanda: "Cosa succede quando un o la regione ha subito un'interruzione di 1, 5, 10 o 30 minuti?" Questo aspetto deve essere preso in considerazione in molti livelli, tra cui:

• Che esperienza avranno i miei clienti durante un'interruzione del servizio?
• Come faccio a rilevare un'interruzione del servizio?
• Cosa succede alla mia applicazione durante un'interruzione?
• Cosa succede ai miei dati durante un'interruzione del servizio?
• Cosa succede alle mie altre applicazioni a causa di un'interruzione (a causa di cross-dependencies)?
• Cosa devo fare per recuperare il servizio dopo la risoluzione di un'interruzione? Chi ce l'hai?
• Chi devo avvisare in caso di interruzione, entro quale periodo di tempo?

Guida passo passo alla progettazione del ripristino di emergenza per le applicazioni in Google Cloud

Le sezioni precedenti hanno parlato di come Google crea l'infrastruttura cloud, e alcuni approcci per gestire le interruzioni a livello di zona e di regione.

Questa sezione ti aiuta a sviluppare un framework per l'applicazione di questo principio. di composizione alle applicazioni in base ai risultati di affidabilità desiderati.

Applicazioni dei clienti in Google Cloud destinate al ripristino di emergenza come RTO e RPO, devono essere progettati in modo da operazioni, soggette a RTO/RPO, hanno dipendenze solo sul piano dati responsabili del trattamento continuo delle operazioni per il servizio. In altre parole, queste operazioni critiche per l'attività del cliente devono non dipendono dalle operazioni del piano di gestione, che gestiscono lo stato della configurazione ed eseguire il push della configurazione al piano di controllo e al piano dati.

Ad esempio, i clienti di Google Cloud che intendono ottenere un RTO per le operazioni business-critical non devono dipendere da un'API di creazione delle VM o aggiornamento di un'autorizzazione IAM.

Passaggio 1: raccogli i requisiti esistenti

Il primo passaggio consiste nel definire i requisiti di disponibilità per le tue applicazioni. La maggior parte delle aziende ha già un certo livello di indicazioni di progettazione in questo che può essere sviluppato internamente o derivato da regolamenti o altre requisiti legali. Queste linee guida di progettazione sono normalmente codificate in due metriche: RTO (Recovery Time Objective) e RPO (Recovery Point Objective). Nel termini commerciali, RTO si traduce come "Quanto tempo dopo un disastro in esecuzione." RPO si traduce come "Quanti dati posso permettermi di perdere in caso di un disastro".

Storicamente, le imprese hanno definito requisiti RTO e RPO per un'ampia gamma di eventi disastrosi, da guasti dei componenti a terremoti. Questo aveva senso il mondo on-premise dove i planner dovevano mappare i requisiti RTO/RPO attraverso l'intero stack software e hardware. Nel cloud, non è più necessario devono definire i requisiti con questi dettagli, perché è il fornitore a occuparsi quello. Puoi invece definire i tuoi requisiti RTO e RPO in termini di ambito di perdita (intere zone o regioni) senza specificare in modo specifico motivi alla base. Per Google Cloud questo semplifica la raccolta dei requisiti a 3 scenari: un'interruzione a livello di zona, un'interruzione regionale o un'interruzione in più regioni.

Riconoscendo che non tutte le applicazioni hanno la stessa criticità, la maggior parte dei clienti a classificare le proprie applicazioni in livelli di criticità rispetto ai quali È possibile applicare il requisito RTO/RPO. Se considerati insieme, RTO/RPO e applicazione le criticità semplificano il processo di progettazione di una determinata applicazione risposta:

1. L'applicazione deve essere eseguita in più zone nella stessa regione o in più zone in più regioni?
2. Da quali prodotti Google Cloud può dipendere l'applicazione?

Ecco un esempio di output dell'esercizio di raccolta dei requisiti:

RTO e RPO per criticità dell'applicazione per l'organizzazione di esempio:

Criticità dell'applicazione	% di app	App di esempio	Interruzione zona	Interruzione per regione
Livello 1 (più importante)	5%	Applicazioni tipicamente globali o esterne rivolte ai clienti, come pagamenti in tempo reale e negozi di e-commerce.	RTO Zero RPO Zero	RTO Zero RPO Zero
Livello 2	35%	In genere per applicazioni regionali o importanti applicazioni interne, come CRM o ERP.	RTO 15 min RPO 15 min	RTO 1 ora RPO 1 ora
Livello 3 (meno importante)	60%	Generalmente le domande a livello di team o dipartimenti, ad esempio back office, lasciare prenotazioni, viaggi interni, contabilità e RU.	RTO 1 ora RPO 1 ora	RTO 12 ore RPO 12 ore

Passaggio 2: mappatura delle funzionalità ai prodotti disponibili

Il secondo passaggio consiste nel comprendere le capacità di resilienza di Google Cloud utilizzati dalle tue applicazioni. La maggior parte delle aziende esamina le informazioni pertinenti sul prodotto e poi aggiungi indicazioni su come modificare le relative per colmare eventuali lacune tra le funzionalità del prodotto e i loro di resilienza. Questa sezione illustra alcune aree comuni i suggerimenti riguardanti i dati e le limitazioni delle applicazioni in questo ambito.

Come accennato in precedenza, i prodotti abilitati alla RE di Google soddisfano in generale due tipi di ambiti di interruzione: a livello di regione e zona. È necessario pianificare le interruzioni parziali allo stesso modo di un'interruzione completa quando si tratta di RE. Questo ti consente di ottenere matrice di alto livello dei prodotti idonei per ogni scenario per impostazione predefinita:

Funzionalità generali dei prodotti Google Cloud
(consulta l'Appendice per informazioni sulle funzionalità specifiche del prodotto)

	Tutti i prodotti Google Cloud	Prodotti Google Cloud a livello di regione con replica automatica zone	Prodotti Google Cloud globali o multiregionali con servizio replica tra regioni
Errore di un componente all'interno di una zona	Con copertura*	Con copertura	Con copertura
Interruzione zona	Non inclusi	Con copertura	Con copertura
Interruzione per regione	Non inclusi	Non inclusi	Con copertura

* Tutti i prodotti Google Cloud sono resilienti agli errori dei componenti, ad eccezione di e casi specifici indicati nella documentazione del prodotto. Di solito si tratta di scenari in cui il prodotto offre l'accesso diretto o una mappatura statica a un come memoria o dischi a stato solido (SSD).

In che modo l'RPO limita le scelte dei prodotti

Nella maggior parte dei deployment cloud, l'integrità dei dati è la priorità aspetto significativo da prendere in considerazione per un servizio. Almeno alcune applicazioni avere un requisito RPO pari a zero, il che significa che non dovrebbero esserci perdite di dati in caso di interruzione del servizio. Questo di solito richiede che i dati siano in modalità sincrona replicati in un'altra zona o regione. La replica sincrona ha costi e compromessi in termini di latenza. Di conseguenza, mentre molti prodotti Google Cloud offrono la replica tra zone diverse, solo poche la offrono in più regioni. Questo costo e compromesso in termini di complessità significa che non è insolito per diversi tipi di dati all'interno di un'applicazione per avere valori RPO diversi.

Per i dati con un RPO maggiore di zero, le applicazioni possono sfruttare e la replica asincrona. La replica asincrona è accettabile in caso di perdita di dati possono essere ricreati facilmente o essere recuperati da una fonte di dati aurea se necessario. Può essere una scelta ragionevole anche quando una piccola quantità di perdita di dati è un compromesso accettabile nel contesto dell'interruzione prevista a livello di zona e di regione diverse. È inoltre importante che durante un'interruzione temporanea, i dati scritti la località interessata, ma non è stata ancora replicata in un'altra posizione in genere diventa disponibile dopo la risoluzione dell'interruzione. Ciò significa che il rischio una perdita di dati permanente è inferiore al rischio di perdere l'accesso ai dati durante una o un'interruzione del servizio.

Azioni chiave: stabilisci se hai effettivamente bisogno di un RPO zero e, in questo caso, di un RPO se puoi farlo per un sottoinsieme dei tuoi dati, la cosa si aumenta la gamma di servizi abilitati per RE a tua disposizione. In Google Cloud, Ottenere un RPO pari a zero significa utilizzare prodotti prevalentemente regionali per il tuo che per impostazione predefinita sono resilienti alla scalabilità in base alle zone, ma a livello di regione, senza interruzioni.

Come RTO limita le scelte relative ai prodotti

Uno dei principali vantaggi del cloud computing è la possibilità di eseguire l'infrastruttura on demand; ma non è la stessa cosa e deployment continuo. Il valore RTO per la tua applicazione deve soddisfare le RTO combinato dei prodotti Google Cloud utilizzati dalla tua applicazione e qualsiasi azioni che i tuoi ingegneri o SRE devono eseguire per riavviare le VM o l'applicazione componenti. Un RTO misurato in minuti significa progettare un'applicazione che esegue automaticamente il ripristino da un'emergenza senza intervento umano oppure con con passaggi minimi, come la pressione di un pulsante per il failover. Il costo e la complessità questo tipo di sistema è sempre stato molto alto, ma i prodotti Google Cloud come i bilanciatori del carico e i gruppi di istanze, rendono questa progettazione conveniente e semplice. Pertanto, devi considerare e ripristino automatici per la maggior parte delle applicazioni. Ricorda che la progettazione di un per questo tipo di failover a caldo tra regioni è sia complicato sia costoso; solo una piccola parte dei servizi critici garantisce che funzionalità.

La maggior parte delle applicazioni avrà un RTO compreso tra un'ora e un giorno, il che consente per un failover a caldo in uno scenario di emergenza, con alcuni componenti sempre in esecuzione in modalità standby, come i database, altre vengono implementate in caso di disastro reale, come ad esempio i server web. Per queste applicazioni, dovresti considerare con attenzione l'automazione di scale out. I servizi con un RTO nell'arco di un giorno sono la criticità più bassa spesso possono essere recuperati da un backup o ricreati da zero.

Azioni chiave:stabilisci se è necessario un RTO (vicino) pari a zero per a livello di regione e, in questo caso, se puoi farlo per un sottoinsieme i servizi di machine learning. che modifica i costi di esecuzione e manutenzione del servizio.

Passaggio 3: sviluppa le tue architetture e guide di riferimento

L'ultimo passaggio consigliato consiste nel creare un'architettura specifica per la tua azienda per aiutare i team a standardizzare l'approccio al ripristino di emergenza. La maggior parte dei clienti di Google Cloud produce una guida per i propri team di sviluppo che corrisponda alle proprie aspettative in termini di resilienza aziendale ai due principali di scenari di interruzione su Google Cloud. In questo modo i team possono classificare i prodotti abilitati per RE più adatti a ogni livello di criticità.

Crea le linee guida per i prodotti

Osservando di nuovo la tabella RTO/RPO di esempio in alto, c'è una guida ipotetica che elenca quali prodotti sarebbero consentiti per impostazione predefinita ogni livello di criticità. Tieni presente che alcuni prodotti sono stati identificati come non è adatta per impostazione predefinita, puoi sempre aggiungere la tua replica meccanismi di failover per abilitare la sincronizzazione tra zone o regioni, ma questo esercizio esula dall'ambito di questo articolo. Le tabelle rimandano anche ad altri informazioni su ciascun prodotto per aiutarti a comprenderne le capacità della gestione delle interruzioni di zone o regioni.

Esempi di modelli di architettura per l'organizzazione di esempio - Interruzione di zona Resilienza

Prodotto Google Cloud	Il prodotto soddisfa i requisiti di interruzione di zona per Ad esempio? Organizzazione (con la configurazione del prodotto appropriata)
	Livello 1	Livello 2	Livello 3
Compute Engine	No	No	No
Dataflow	No	No	No
BigQuery	No	No	Sì
GKE	Sì	Sì	Sì
Cloud Storage	Sì	Sì	Sì
Cloud SQL	No	Sì	Sì
Spanner	Sì	Sì	Sì
Cloud Load Balancing	Sì	Sì	Sì

Questa tabella è un esempio basato solo sui livelli ipotetici mostrati sopra.

Esempi di pattern di architettura di un'organizzazione di esempio - Interruzione della regione Resilienza

Prodotto Google Cloud	Il prodotto soddisfa i requisiti di interruzione per regione ad esempio? Organizzazione (con la configurazione del prodotto appropriata)
	Livello 1	Livello 2	Livello 3
Compute Engine	Sì	Sì	Sì
Dataflow	No	No	No
BigQuery	No	No	Sì
GKE	Sì	Sì	Sì
Cloud Storage	No	No	No
Cloud SQL	No	Sì	Sì
Spanner	Sì	Sì	Sì
Cloud Load Balancing	Sì	Sì	Sì

Questa tabella è un esempio basato solo sui livelli ipotetici mostrati sopra.

Per mostrare come vengono utilizzati questi prodotti, le seguenti sezioni descrivono nel dettaglio alcune architetture di riferimento per ciascuna delle applicazioni ipotetiche livelli di criticità. Si tratta di descrizioni volutamente di alto livello per illustrare le decisioni chiave sull'architettura e non sono rappresentativi di un la progettazione della soluzione.

Esempio di architettura di livello 3

Criticità dell'applicazione	Interruzione zona	Interruzione per regione
Livello 3 (meno importante)	RTO 12 ore RPO 24 ore	RTO 28 giorni RPO 24 ore

(Le icone in grigio indicano che l'infrastruttura deve essere abilitata per il ripristino)

Questa architettura descrive un'applicazione client/server tradizionale: internal Gli utenti si connettono a un'applicazione in esecuzione su un'istanza Compute supportata un database per l'archiviazione permanente.

È importante notare che questa architettura supporta valori RTO e RPO migliori. di quanto richiesto. Tuttavia, valuta la possibilità di eliminare passaggi in cui possono rivelarsi costosi o inaffidabili. Ad esempio, il recupero di un di un backup notturno potrebbe supportare l'RPO di 24 ore, ma questo di solito hanno bisogno di una persona competente, come un amministratore di database, soprattutto se sono stati interessati più servizi contemporaneamente. Con l'infrastruttura on demand di Google Cloud puoi creare senza dover scendere a compromessi in termini di costi. Per questo motivo questa architettura usa ad alta disponibilità di Cloud SQL anziché un backup/ripristino manuale per le interruzioni a livello di zona.

Decisioni chiave sull'architettura per l'interruzione della zona - RTO di 12 ore e RPO di 24 ore:

• Un bilanciatore del carico interno viene utilizzato per fornire agli utenti un punto di accesso scalabile, che consente il failover a un'altra zona. Anche se il RTO è di 12 ore, le modifiche manuali Gli indirizzi IP o persino gli aggiornamenti DNS possono richiedere più tempo del previsto.
• R gruppo di istanze gestite a livello di regione è configurato con più zone, ma con risorse minime. Questo ottimizza ma consente comunque lo scale out rapido delle macchine virtuali zona di backup.
• R configurazione di Cloud SQL ad alta disponibilità consente il failover automatico in un'altra zona. I database sono significativamente più difficili da ricreare e ripristinare rispetto alla Compute Engine virtuale machine learning.

Decisioni in materia di architettura chiave per l'interruzione della regione: RTO di 28 giorni e RPO di 24 orari:

• Un bilanciatore del carico sarebbe creato nella regione 2 solo in caso di interruzione del servizio a livello di regione. Cloud DNS viene utilizzato per fornire una funzionalità di failover regionale orchestrata ma manuale, poiché l'infrastruttura nella regione 2 viene resa disponibile di un'interruzione della regione.
• Un nuovo gruppo di istanze gestite verrà creato solo in caso di interruzione di una regione. Questo ottimizza per i costi ed è improbabile che venga richiamata, data la breve durata a livello di regione. Nota che per semplicità il diagramma non mostra gli strumenti associati necessari per rieseguire il deployment o la copia necessarie le immagini.
• Un nuovo file Cloud SQL viene ricreato l'istanza e i dati ripristinati da un backup. Di nuovo, il rischio di un'interruzione prolungata una regione è estremamente bassa, pertanto si tratta di un altro compromesso per l'ottimizzazione dei costi.
• Cloud Storage multiregionale è utilizzato per e archiviare questi backup. Questo fornisce una zona automatica e una resilienza regionale all'interno dell'RTO e dell'RPO.

Esempio di architettura di livello 2

Criticità dell'applicazione	Interruzione zona	Interruzione per regione
Livello 2	RTO 4 ore RPO zero	RTO 24 ore RPO 4 ore

Questa architettura descrive un data warehouse con utenti interni che si connettono a una un livello di visualizzazione dell'istanza di computing e un livello di importazione e trasformazione dei dati che popola il data warehouse di backend.

Alcuni singoli componenti di questa architettura non supportano direttamente l'RPO richiesto per il livello. Tuttavia, dato il modo in cui vengono utilizzati insieme, nel complesso soddisfa l'RPO. In questo caso, poiché Dataflow è un a livello di zona, segui i suggerimenti progettazione ad alta disponibilità. per evitare perdite di dati durante un'interruzione. Tuttavia, Il livello Cloud Storage è la fonte primaria di questi dati e supporta un RPO di zero. Di conseguenza, puoi importare nuovamente i dati persi in BigQuery utilizzando zona b in caso di interruzione nella zona a.

Decisioni in materia di architettura chiave per l'interruzione della zona - RTO di 4 ore e RPO di zero:

• Un bilanciatore del carico è utilizzato per offrono agli utenti un punto di accesso scalabile, che consente il failover a un'altra zona. Anche se il RTO è di 4 ore, le modifiche manuali Gli indirizzi IP o persino gli aggiornamenti DNS possono richiedere più tempo del previsto.
• R gruppo di istanze gestite a livello di regione per il livello di computing della visualizzazione dei dati è configurato con più zone ma con risorse minime. Questo ottimizza i costi, ma consente comunque per fare lo scale out rapido.
• Cloud Storage a livello di regione viene utilizzato come di gestione temporanea per l'importazione iniziale dei dati, fornendo zone automatiche resilienza.
• Dataflow viene utilizzato per estrarre dati da Cloud Storage e trasformarlo prima di caricarlo in BigQuery. Nella di un'interruzione di una zona, questo è un processo stateless che può essere riavviato in un'altra zona.
• BigQuery fornisce il data warehouse per il front-end della visualizzazione dei dati. In caso di interruzione di una zona, eventuali dati persi verranno importati nuovamente da Cloud Storage.

Decisioni in materia di architettura chiave per l'interruzione della regione: RTO di 24 ore e RPO di 4 orari:

• Un bilanciatore del carico in ogni regione è utilizzati per fornire agli utenti un punto di accesso scalabile. Cloud DNS viene utilizzato una capacità di failover regionale orchestrata ma manuale, poiché nella regione 2 sarebbe resa disponibile solo nel caso di un interruzione del servizio in una regione specifica.
• R gruppo di istanze gestite a livello di regione per il livello di computing della visualizzazione dei dati è configurato con più zone ma con risorse minime. Non sarà accessibile finché il bilanciatore del carico non sarà riconfigurate, ma in caso contrario non richiedono alcun intervento manuale.
• Cloud Storage a livello di regione viene utilizzato come di gestione temporanea per l'importazione iniziale dei dati. Questo viene caricato all'indirizzo in entrambe le regioni per soddisfare i requisiti dell'RPO.
• Dataflow viene utilizzato per estrarre dati da Cloud Storage e trasformarlo prima di caricarlo in BigQuery. Nella di un'interruzione di una regione, questo compilerebbe BigQuery con i dati più recenti di Cloud Storage.
• BigQuery fornisce il data warehouse backend. In caso di normali operazioni, l'aggiornamento viene eseguito a intermittenza. Nel in caso di interruzione di una regione, i dati più recenti verranno importati nuovamente tramite Dataflow da Cloud Storage.

Esempio di architettura di livello 1

Criticità dell'applicazione	Interruzione zona	Interruzione per regione
Livello 1 (più importante)	RTO zero RPO zero	RTO 4 ore RPO 1 ora

Questa architettura descrive un'infrastruttura di backend per app mobile con di utenti che si connettono a un set di microservizi in esecuzione su GKE. Spanner fornisce il livello di archiviazione dei dati backend per i dati in tempo reale e i dati storici vengono trasmessi in flusso a un data lake BigQuery in ogni regione.

Anche in questo caso, alcuni singoli componenti di questa architettura non supportano l'RPO richiesto per il livello, ma per via del modo in cui vengono utilizzati insieme nel suo complesso. In questo caso, BigQuery viene utilizzato per l'analisi query. Ogni regione viene alimentata contemporaneamente da Spanner.

Decisioni chiave sull'architettura per l'interruzione di una zona: RTO pari a zero e RPO pari a zero:

• Un bilanciatore del carico è utilizzato per offrono agli utenti un punto di accesso scalabile, che consente il failover a un'altra zona.
• R cluster GKE a livello di regione viene utilizzato per il livello di applicazione, che è configurato con più zone. In questo modo viene raggiunto un RTO pari a zero all'interno di ciascuna regione.
• Più regioni Spanner viene utilizzato come livello di persistenza dei dati, fornendo dati automatici sulle zone resilienza e coerenza delle transazioni.
• BigQuery fornisce i dati e le analisi la capacità di archiviazione per l'applicazione. Ogni regione riceve dati alimentati in modo indipendente a Spanner e accessibile in modo indipendente dall'applicazione.

Decisioni chiave sull'architettura per l'interruzione della regione: RTO di 4 ore e RPO di 1 h:

• Un bilanciatore del carico è utilizzato per offrono agli utenti un punto di accesso scalabile, che consente il failover a un'altra regione.
• R cluster GKE a livello di regione viene utilizzato per il livello di applicazione, che è configurato con più zone. In caso di interruzione di una regione, il cluster nella regione alternativa scala automaticamente per adeguarsi al carico di elaborazione aggiuntivo.
• Più regioni Spanner viene utilizzato come livello di persistenza dei dati, fornendo dati automatici a livello di regione resilienza e coerenza delle transazioni. Questo è il componente fondamentale raggiungere l'RPO tra regioni di 1 ora.
• BigQuery fornisce i dati e le analisi la capacità di archiviazione per l'applicazione. Ogni regione riceve dati alimentati in modo indipendente a Spanner e accessibile in modo indipendente dall'applicazione. Questo compensa il componente BigQuery, consentendogli di ai requisiti generali dell'applicazione.

Appendice: Riferimento prodotto

Questa sezione descrive l'architettura e le funzionalità di RE di Google Cloud più comunemente usati nelle applicazioni dei clienti e che possono essere facilmente sfruttabili per soddisfare i requisiti di RE.

Temi comuni

Molti prodotti Google Cloud offrono configurazioni a livello di una o più regioni. I prodotti regionali sono resilienti alle interruzioni di zona e multiregionali e globali sono resilienti alle interruzioni delle regioni. In generale, questo significa che durante la tua applicazione subisce interruzioni minime. Google raggiunge questi risultati attraverso alcuni approcci architetturali comuni, che rispecchiano guida architetturale.

• Deployment ridondante: i backend delle applicazioni e l'archiviazione dei dati sono distribuito in più zone all'interno di una regione e in più regioni all'interno di un una località multiregionale.

• Replica dei dati: i prodotti utilizzano la modalità sincrona o asincrona la replica tra le località ridondanti.

  • La replica sincrona significa che, quando l'applicazione effettua una Chiamata API per creare o modificare i dati memorizzati dal prodotto, che riceve solo dopo che il prodotto ha scritto i dati più posizioni. La replica sincrona garantisce che perdere l'accesso a uno qualsiasi dei tuoi dati durante un'infrastruttura Google Cloud perché tutti i tuoi dati sono disponibili in uno dei delle località di backend disponibili.

    Sebbene questa tecnica offra la massima protezione dei dati, può avere compromessi in termini di latenza e prestazioni. Prodotti multiregionali replica sincrona, questo compromesso Significativamente, generalmente nell'ordine di 10 o 100 secondi una maggiore latenza.

  • La replica asincrona indica che, quando l'applicazione effettua una Chiamata API per creare o modificare i dati memorizzati dal prodotto, che riceve una risposta corretta dopo che il prodotto ha scritto i dati in una singola in ogni località. Dopo la tua richiesta di scrittura, il prodotto replica i tuoi dati in altre località.

    Questa tecnica fornisce una latenza più bassa e una velocità effettiva superiore nell'API rispetto alla replica sincrona, ma a scapito della protezione dei dati. Se il luogo in cui hai scritto i dati subisce un'interruzione prima replica completata, perderai l'accesso a quei dati finché l'interruzione della posizione è stata risolta.

• Gestione delle interruzioni con il bilanciamento del carico: Google Cloud utilizza il carico del software per instradare le richieste ai backend dell'applicazione appropriati. Rispetto ad altri approcci come il bilanciamento del carico DNS, questo approccio riduce il tempo di risposta del sistema a un'interruzione. Quando un'interruzione della località di Google Cloud , il bilanciatore del carico rileva rapidamente che il backend è stato eseguito località è diventata "insalubre" e indirizza tutte le richieste a un backend in un località alternativa. In questo modo, il prodotto può continuare a essere pubblicato durante un'interruzione della posizione. Quando l'interruzione della posizione viene risolto, il bilanciatore del carico rileva la disponibilità dei backend dei prodotti in quella località e riprende a inviare traffico lì.

Gestore contesto accesso

Il Gestore contesto accesso consente alle aziende di configurare livelli di accesso mappati a un criterio definito negli attributi della richiesta. I criteri vengono rispecchiati a livello di regione.

In caso di interruzione a livello di zona, le richieste alle zone non disponibili vengono automaticamente e in modo trasparente da altre zone disponibili nella regione.

In caso di interruzione del servizio a livello di regione, i calcoli dei criteri della regione interessata vengono non disponibile fino a quando la regione non tornerà disponibile.

Access Transparency

Access Transparency consente a Google Cloud di organizzare gli amministratori definiscono un controllo dell'accesso ai progetti granulare e basato su attributi e le risorse in Google Cloud. Occasionalmente, Google deve accedere ai per scopi amministrativi. Quando accediamo ai dati dei clienti, Access Transparency fornisce i log degli accessi a Google Cloud interessato clienti. Questi log di Access Transparency contribuiscono a garantire l'impegno di Google in relazione ai dati sicurezza e trasparenza nella gestione dei dati.

Access Transparency è resiliente in caso di interruzioni a livello di zona e di regione. Se a livello di zona o un'interruzione regionale, Access Transparency continua a elaborare i log degli accessi amministrativi in un'altra zona o regione.

AlloyDB per PostgreSQL

AlloyDB per PostgreSQL è un servizio di database completamente gestito e compatibile con PostgreSQL. AlloyDB per PostgreSQL offre alta disponibilità in una regione attraverso il suo i nodi ridondanti dell'istanza che si trovano in due diverse zone regione. L'istanza principale mantiene la disponibilità regionale attivando un'opzione failover automatico alla zona di standby se si verifica un problema nella zona attiva. Regional Storage garantisce la durabilità dei dati in caso di perdita in una singola zona.

Come ulteriore metodo di ripristino di emergenza, AlloyDB per PostgreSQL utilizza per offrire funzionalità di ripristino di emergenza replicare in modo asincrono i dati del cluster principale nei cluster secondari in regioni Google Cloud separate.

Interruzione a livello di zona: durante il normale funzionamento, solo uno dei due nodi di un l'istanza principale ad alta disponibilità è attiva e gestisce tutte le scritture dei dati. Questo nodo attivo archivia i dati in uno spazio di archiviazione regionale separato del cluster livello di sicurezza.

AlloyDB per PostgreSQL rileva automaticamente errori a livello di zona e attiva un per ripristinare la disponibilità del database. Durante il failover, AlloyDB per PostgreSQL avvia il database sul nodo in standby, che è già in un'altra zona. Le nuove connessioni di database ricevono automaticamente indirizzato a questa zona.

Dal punto di vista di un'applicazione client, un'interruzione a livello di zona è simile un'interruzione temporanea della connettività di rete. Al termine del failover, il client possa riconnettersi all'istanza allo stesso indirizzo, utilizzando senza alcuna perdita di dati.

Interruzione regionale: la replica tra regioni utilizza la replica asincrona, che consente all'istanza principale di eseguire il commit delle transazioni prima durante il commit delle repliche. La differenza di tempo tra il momento in cui una transazione il commit sull'istanza principale e il relativo commit sulla replica sono noto come tempo della replica. La differenza di tempo tra il momento in cui genera il log write-ahead (WAL) e quando WAL raggiunge la replica viene noto come flush lag. Il ritardo della replica e il tempo di svuotamento dipendono dall'istanza del database configurazione e sul carico di lavoro generato dall'utente.

In caso di interruzione a livello di regione, puoi promuovere cluster secondari in una regione diversa a un cluster principale autonomo e scrivibile. Questo elemento promosso non replica più i dati del cluster principale originale con cui in precedenza era associato a. A causa del ritardo di svuotamento, potrebbe verificarsi una perdita di dati perché potrebbero esserci transazioni nell'istanza principale originale che non erano propagati al cluster secondario.

L'RPO di replica tra regioni è influenzato sia dall'utilizzo della CPU del cluster principale e la distanza fisica tra la regione del cluster principale e della regione del cluster secondario. Per ottimizzare l'RPO, ti consigliamo di testare carico di lavoro con una configurazione che include una replica per stabilire di transazioni al secondo (TPS), ossia il TPS più elevato sostenuto non accumula flush lag. Se il carico di lavoro supera il limite TPS sicuro, esegui il svuotamento si accumulano, con un conseguente impatto sull'RPO. Per limitare il ritardo della rete, scegli coppie di regioni all'interno dello stesso continente.

Per ulteriori informazioni sul monitoraggio del ritardo di rete Metriche di AlloyDB per PostgreSQL; consulta Monitorare di Compute Engine.

Anti Money Laundering AI

Anti Money Laundering AI (AML AI) fornisce un'API per aiutare i rilevare in modo più efficace ed efficiente il riciclaggio di denaro. Anti L'IA per il riciclaggio di denaro è un'offerta regionale, il che significa che i clienti possono scegliere ma non le zone che compongono una regione. I dati e il traffico viene bilanciato automaticamente il carico tra le zone all'interno di una regione. Le operazioni (per ad esempio per creare una pipeline o eseguire una previsione), vengono scalati automaticamente in background e vengono bilanciati il carico tra le zone in base alle esigenze.

Interruzione a livello di zona: AML AI archivia i dati per le proprie risorse a livello di regione, replicati in modo sincrono. Quando un'operazione a lunga esecuzione termina correttamente, è possibile fare affidamento sulle risorse indipendentemente errori. L'elaborazione viene replicata anche tra le zone, ma questa replica mira del carico e non ad alta disponibilità, quindi un errore a livello di zona può causare un errore dell'operazione. In questo caso, riprova operativa può risolvere il problema. Durante un'interruzione del servizio a livello di zona, i tempi di elaborazione potrebbero essere interessate.

Interruzione a livello di regione: i clienti scelgono la regione Google Cloud che vogliono e creare le proprie risorse di IA AML. I dati non vengono mai replicati regioni. Il traffico dei clienti non viene mai instradato a una regione diversa tramite AML AI. In caso di errore a livello di regione, AML AI tornerà disponibile non appena l'interruzione verrà risolta.

Chiavi API

Le chiavi API offrono una gestione scalabile delle risorse delle chiavi API per un progetto. Le chiavi API sono un servizio globale, vale a dire che le chiavi sono visibili accessibile da qualsiasi località Google Cloud. I relativi dati e metadati vengono archiviati in modo ridondante in più zone e regioni.

Le chiavi API sono resilienti alle interruzioni sia a livello di zona che di regione. Nel caso di interruzione del servizio a livello di zona o di regione, le chiavi API continuano richieste da un'altra zona nella stessa regione o in una regione diversa.

Per ulteriori informazioni sulle chiavi API, consulta Panoramica dell'API delle chiavi API.

Apigee

Apigee offre una piattaforma sicura, scalabile e affidabile per lo sviluppo e la gestione delle API. Apigee offre deployment a livello di una o più regioni.

Interruzione a livello di zona: i dati relativi al tempo di esecuzione dei clienti vengono replicati su con più zone di disponibilità. Di conseguenza, un'interruzione su una singola zona non ha alcun impatto su Apigee.

Interruzione regionale: per le istanze Apigee di una singola regione, se una regione non è più disponibile, le istanze Apigee non sono disponibili regione e non possono essere ripristinati in regioni diverse. Per di istanze Apigee multiregionali, i dati vengono replicati tutte le regioni in modo asincrono. Di conseguenza, il mancato funzionamento di una regione non riduce del tutto il traffico. Tuttavia, non sarà in grado di accedere ai dati di cui non è stato eseguito il commit nella regione in errore. Tu può deviare il traffico da regioni non integre. Per raggiungere il failover automatico del traffico, puoi configurare il routing utilizzando gruppi di istanze gestite.

AutoML Translation

AutoML Translation è un servizio di traduzione automatica che ti consente importare i tuoi dati (coppie di frasi) per addestrare modelli personalizzati specifiche del dominio.

Interruzione a livello di zona: AutoML Translation ha server di computing attivi in in più zone e regioni. it supporta anche la replica sincrona dei dati tra zone all'interno delle regioni. Questi consentono ad AutoML Translation di raggiungere failover istantaneo senza perdita di dati per errori a livello di zona che richiedono input o aggiustamenti da parte del cliente.

Interruzione a livello di regione: in caso di errore a livello di regione, AutoML Translation non è disponibile.

AutoML Vision

AutoML Vision fa parte di Vertex AI. Offre una panoramica framework per creare set di dati, importare dati, addestrare modelli e fornire modelli previsione online e batch.

AutoML Vision è un'offerta regionale. I clienti possono scegliere regione da cui vuole avviare un job, ma non può scegliere le zone specifiche all'interno di quella regione. Il servizio bilancia automaticamente il carico dei carichi di lavoro tra in varie zone all'interno della regione.

Interruzione a livello di zona: AutoML Vision archivia i metadati per i job a livello di regione e scrive in modo sincrono tra le zone all'interno della regione. I job vengono avviate in una zona specifica, come selezionata da Cloud Load Balancing.

• Job di addestramento AutoML Vision: un'interruzione a livello di zona causa qualsiasi esecuzione job non riusciti e lo stato del job verrà aggiornato in Non riuscito. Se un job non va a buon fine, riprova immediatamente. Il nuovo job viene instradato a una zona disponibile.

• Job di previsione batch AutoML Vision: la previsione batch viene creata si basa sulla previsione batch di Vertex AI. Quando si verifica un'interruzione a livello di zona, il servizio ritenta automaticamente il job eseguendo il routing alle zone disponibili. Se più tentativi non vanno a buon fine, lo stato del job viene aggiornato in non riuscito. Le successive richieste dell'utente per eseguire il job vengono instradate a una zona disponibile.

Interruzione a livello di regione: i clienti scelgono la regione Google Cloud che vogliono per eseguire i propri job. I dati non vengono mai replicati tra regioni. In una regione in un errore, il servizio AutoML Vision non è disponibile in quella regione. it torna disponibile alla risoluzione dell'interruzione. Per eseguire i loro job, di utilizzare più regioni. Nel caso in cui si verifichi un'interruzione a livello di regione, indirizzare i job a un'altra regione disponibile.

Batch

Batch è un servizio completamente gestito che consente di inserire in coda, pianificare ed eseguire operazioni batch su Google Cloud. Le impostazioni batch sono definite a livello di regione livello. I clienti devono scegliere una regione in cui inviare i job batch, non una zona in una regione. Quando un job viene inviato, Batch scrive in modo sincrono i dati dei clienti in più zone. Tuttavia, i clienti possono specificare le zone in cui Le VM in batch eseguono job.

Errore di zona: in caso di errore in una singola zona, vengono eseguite le attività in esecuzione al suo interno anch'esso falliranno. Se le attività hanno impostazioni per i nuovi tentativi, Batch automaticamente esegue il failover di queste attività in altre zone attive nella stessa regione. L'impostazione automatica il failover è soggetto alla disponibilità di risorse nelle zone attive nello stesso regione. Job che richiedono risorse a livello di zona (come VM, GPU o dischi permanenti a livello di zona i dischi permanenti) disponibili solo nella zona con errori vengono messi in coda fino al o fino al raggiungimento dei timeout per l'accodamento dei job. Quando più possibile, consigliamo ai clienti di consentire a Batch di scegliere il traffico e risorse per eseguire i loro job. In questo modo contribuirai a garantire la resilienza dei job a un'interruzione del servizio a livello di zona.

Errore regionale:in caso di errore a livello di regione, il piano di controllo del servizio non è disponibile nella regione. Il servizio non replica i dati né reindirizza richieste tra regioni diverse. Consigliamo ai clienti di utilizzare più regioni per i job e reindirizzano i job a un'altra regione in caso di errore di una regione.

Protezione dei dati e tutela dalle minacce di Chrome Enterprise Premium

Protezione dei dati e dalle minacce di Chrome Enterprise Premium fa parte di Chrome Enterprise Premium soluzione. Estende Chrome con una serie di funzionalità di sicurezza, tra cui protezione da malware e phishing, Prevenzione della perdita di dati (DLP), regole di filtro degli URL e report sulla sicurezza.

Gli amministratori di Chrome Enterprise Premium possono attivare l'archiviazione dei contenuti principali dei clienti che violano Criteri DLP o malware in eventi del log delle regole di Google Workspace e/o Cloud Storage per indagini future. Gli eventi del log delle regole di Google Workspace si basano su più regioni il database Spanner. Il rilevamento di Chrome Enterprise Premium può richiedere diverse ore violazioni delle norme. Durante questo periodo, tutti i dati non elaborati sono soggetti a a causa di un'interruzione a livello di zona o di regione. Una volta rilevata una violazione, i contenuti che violano i tuoi criteri vengono scritte nel log delle regole di Google Workspace eventi e/o a Cloud Storage.

Interruzione a livello di zona e di regione: La protezione dei dati e la protezione dalle minacce di Chrome Enterprise Premium sono multi-zona e multiregionale, può sopravvivere a una perdita completa e non pianificata di una zona o di una regione senza una perdita di disponibilità. Offre questo livello di affidabilità reindirizzando il traffico al suo servizio in altre zone attive o regioni. Tuttavia, perché possono volerci diverse ore per la protezione dei dati e le minacce di Chrome Enterprise Premium rilevare violazioni delle regole DLP e malware, eventuali dati non elaborati in una zona specifica di una regione è soggetta a perdita a causa di un'interruzione del servizio a livello di zona o di regione.

BigQuery

BigQuery è un cloud serverless, a scalabilità elevata ed economico un data warehouse progettato per l'agilità aziendale. BigQuery supporta seguenti tipi di località per i set di dati degli utenti:

• Una regione: una località geografica specifica, ad esempio Iowa (us-central1) o Montréal (northamerica-northeast1).
• Una multiregione: una grande area geografica che contiene due o più aree geografiche località, come gli Stati Uniti (US) o l'Europa (EU).

In entrambi i casi, i dati vengono archiviati in modo ridondante in due zone all'interno una singola regione all'interno della località selezionata. Dati scritti in BigQuery viene scritto in modo sincrono sia nella zona primaria che in quella secondaria. Questo protegge dall'indisponibilità di una singola zona all'interno della regione, ma non da un'interruzione regionale.

Autorizzazione binaria

Autorizzazione binaria è un prodotto per la sicurezza della catena di fornitura del software per GKE e Cloud Run.

Tutti i criteri di Autorizzazione binaria vengono replicati in più zone all'interno di ogni regione. La replica consente alle operazioni di lettura dei criteri di Autorizzazione binaria il ripristino da errori di altre regioni. La replica rende anche e compatibili con gli errori a livello di zona all'interno di ogni regione.

Le operazioni di applicazione di Autorizzazione binaria sono resilienti ma non sono resilienti con le interruzioni a livello di regione. Applicazione operazioni vengono eseguite nella stessa regione del cluster GKE un job Cloud Run che sta rendendo la richiesta. Pertanto, in caso di interruzione a livello di regione, non c'è in esecuzione per effettuare richieste di applicazione di Autorizzazione binaria.

Gestore certificati

Gestore certificati consente di acquisire e gestire Transport Layer Security (TLS) da utilizzare con diversi tipi di Cloud Load Balancing.

In caso di interruzione a livello di zona, Gestore certificati a livello di zona e di regione sono resilienti agli errori a livello di zona, poiché i job e i database sono ridondanti in più zone all'interno di una regione. In caso di interruzione del servizio a livello di regione, il Gestore certificati globale viene resilienti agli errori regionali poiché i job e i database sono ridondanti in più regioni. Regional Certificate Manager è un prodotto regionale, per evitare errori a livello di regione.

Cloud Intrusion Detection System

Cloud Intrusion Detection System (Cloud IDS) è un servizio di zona che fornisce IDS con ambito a livello di zona Endpoint, che elaborano il traffico delle VM in una zona specifica e, di conseguenza, non tollera interruzioni a livello di zona o di regione.

Interruzione a livello di zona: Cloud IDS è collegato alle istanze VM. Se un cliente prevede di mitigare le interruzioni dei servizi a livello di zona eseguendo il deployment delle VM in più zone (manualmente tramite gruppi di istanze gestite a livello di regione), dovranno eseguire Cloud IDS endpoint anche in quelle zone.

Interruzione regionale: Cloud IDS è un prodotto regionale. Non forniscono funzionalità interregionali. Un errore a livello di regione richiederà tutte le funzionalità di Cloud IDS in tutte le zone di quella regione.

Google Security Operations SIEM

Google Security Operations SIEM (che fa parte di Google Security Operations) è una piattaforma che aiuta i team di sicurezza a rilevare, analizzare e rispondere alle minacce.

Google Security Operations SIEM offre offerte regionali e multiregionali.

• Nelle offerte regionali, i dati e il traffico vengono automaticamente bilanciati zone all'interno della regione scelta e i dati vengono archiviati in modo ridondante le zone di disponibilità all'interno della regione.

• Le regioni multiple sono con ridondanza geografica. Questa ridondanza fornisce un insieme di protezioni più ampio rispetto a Regional Storage. Contribuisce anche a garantire che il servizio continui a funzionare anche in caso di viene persa.

• La maggior parte dei percorsi di importazione dati replica i dati dei clienti in modo sincrono in più località. Quando i dati vengono replicati in modo asincrono, finestra temporale (Recovery Point Objective o RPO) durante la quale i dati non sono ancora replicati in diverse località. Questo è il caso quando importi con in deployment multiregionali. Dopo l'RPO, i dati è disponibile in più località.

Interruzione a livello di zona:

• Deployment regionali: le richieste vengono gestite da qualsiasi zona all'interno della regione. I dati vengono replicati in modo sincrono su più zone. Nel caso di una zona intera un'interruzione del servizio, le zone restanti continuano a gestire il traffico e a elaborare i dati. Provisioning ridondante e scalabilità automatica per La soluzione SIEM per le operazioni di sicurezza di Google aiuta a garantire che il servizio resti operativo in le zone rimanenti durante questi spostamenti del carico.

• Deployment in più regioni: le interruzioni a livello di zona equivalgono a quelle a livello di regione.

Interruzione a livello di regione:

• Implementazioni regionali: la SIEM per le operazioni di sicurezza di Google archivia tutti i dati dei clienti all'interno una sola regione e il traffico non viene mai instradato tra regioni. In caso di a livello di regione, Google Security Operations SIEM non sarà disponibile nella regione fino al sia stata risolta.

• Deployment in più regioni (senza feed): le richieste vengono pubblicate da qualsiasi regione del deployment multiregionale. I dati vengono replicati in modo sincrono in più regioni. In caso di interruzione di un'intera regione, le regioni rimanenti a gestire il traffico e a elaborare i dati. Ridondante il provisioning e la scalabilità automatica per Google Security Operations SIEM contribuiscono ad assicurare il servizio rimane operativo nelle regioni rimanenti durante questo carico senza interruzioni.

• Deployment in più regioni (con feed): le richieste vengono pubblicate da qualsiasi regione del deployment multiregionale. I dati vengono replicati in modo asincrono in più regioni con l'RPO fornito. In caso di interruzione in tutta una regione, archiviati dopo che l'RPO è disponibile nelle regioni rimanenti. I dati all'interno La finestra RPO potrebbe non essere replicata.

Cloud Asset Inventory

Cloud Asset Inventory è un servizio globale, resiliente e ad alte prestazioni che mantiene un dei metadati di risorse e criteri di Google Cloud. Cloud Asset Inventory fornisce strumenti di ricerca e analisi che ti aiutano a tenere traccia degli asset di cui hai eseguito il deployment per organizzazioni, cartelle e progetti.

In caso di interruzione di una zona, Cloud Asset Inventory continua a gestire le richieste da un'altra zona nella stessa regione o in una regione diversa.

In caso di interruzione regionale, Cloud Asset Inventory continua a gestire le richieste da altre regioni.

Bigtable

Bigtable è un servizio di database NoSQL ad alte prestazioni completamente gestito grandi carichi di lavoro analitici e operativi.

Panoramica della replica Bigtable

Bigtable offre una replica flessibile e completamente configurabile funzionalità, che puoi utilizzare per aumentare la disponibilità e la durabilità del tuo copiandoli su di cluster in più regioni o in più zone all'interno della stessa regione. Bigtable può anche fornire Failover automatico per le tue richieste quando utilizzi la replica.

Quando utilizzi configurazioni multi-zona o multiregionali con routing multi-cluster, in caso di interruzione a livello di zona o di regione, Bigtable reinstrada il traffico e gestisce le richieste dal cluster più vicino disponibile. Poiché La replica di Bigtable è asincrona e alla fine coerenti, modifiche molto recenti ai dati nel luogo dell'interruzione potrebbero non essere disponibili se non sono ancora stati replicati in altre posizioni.

Considerazioni sulle prestazioni

Importante: devi assicurarti che l'utilizzo della CPU e dimensioni dei dati devono rientrare nei valori massimi consigliati e i cluster devono rimanere di un provisioning adeguato in modo che la replica in modo prevedibile.

Quando le richieste di risorse della CPU superano la capacità disponibile per i nodi, Bigtable dà sempre la priorità alla gestione delle richieste in entrata prima del traffico di replica.

Per ulteriori informazioni su come utilizzare la replica Bigtable per il carico di lavoro, consulta la panoramica della replica Cloud Bigtable ed esempi di impostazioni di replica.

I nodi Bigtable utilizzata sia per gestire le richieste in entrata sia per eseguire la replica provenienti da altri cluster. Oltre a mantenere un numero di nodi sufficiente per cluster, devi anche assicurarti che le applicazioni utilizzino uno schema appropriato evitando gli hotspot il che può causare un utilizzo eccessivo o sbilanciato della CPU e un aumento della replica una latenza di pochi millisecondi.

Per saperne di più sulla progettazione dello schema dell'applicazione per massimizzare Prestazioni ed efficienza di Bigtable, consulta le best practice per la progettazione di schemi.

Monitoraggio

Bigtable offre diversi modi per monitorare visivamente la replica latenza di istanze e cluster utilizzando di grafici per la replica disponibile nella console Google Cloud.

Puoi anche monitorare in modo programmatico la replica di Bigtable metriche utilizzando l'API Cloud Monitoring.

Certificate Authority Service

Certificate Authority Service (CA Service) consente ai clienti di semplificare, automatizzare e personalizzare il deployment, la gestione e la sicurezza di autorità di certificazione private (CA) ed emettere certificati in modo resiliente su larga scala.

Interruzione a livello di zona: il servizio CA è resiliente agli errori a livello di zona poiché il suo piano di controllo è ridondante in più zone all'interno di una regione. In caso di interruzione a livello di zona, CA Service continua a gestire richieste da un'altra zona nella stessa regione senza interruzioni. Poiché i dati vengono replicati in modo sincrono e non avvengono perdite o danneggiamenti dei dati.

Interruzione a livello di regione: CA Service è un prodotto regionale, perciò non è in grado di sostenere un errore a livello di regione. Se hai bisogno di resilienza agli errori regionali, possono creare CA di emissione in due regioni diverse. Crea la CA emittente principale in la regione per cui sono necessari i certificati. Crea una CA di riserva in un'altra regione. Utilizza il fallback quando si verifica un'interruzione nella regione della CA subordinata principale. Se necessario, entrambe le CA possono concatenare la stessa CA radice.

Cloud Billing

L'API Cloud Billing consente agli sviluppatori di gestire la fatturazione per i progetti Google Cloud in modo programmatico. L'API Cloud Billing progettato come sistema globale con aggiornamenti scritti in modo sincrono su più zone e regioni.

Errore a livello di zona o di regione: l'API Cloud Billing eseguirà automaticamente in un'altra zona o regione. Le richieste individuali potrebbero non andare a buon fine, ma un nuovo tentativo dovrebbe consentire la riuscita dei tentativi successivi.

Cloud Build

Cloud Build è un servizio che esegue le tue build su Google Cloud.

Cloud Build è composto da istanze isolate a livello di regione, di replicare in modo sincrono i dati tra le zone all'interno della regione. È consigliabile utilizzi regioni specifiche di Google Cloud anziché la regione globale e assicurati usate dalle risorse utilizzate dalla build (inclusi i bucket di log, Artifact Registry repository e così via) sono allineati alla regione in cui viene eseguita la build.

In caso di interruzione a livello di zona, le operazioni del piano di controllo non sono interessate. Tuttavia, le build attualmente in esecuzione all'interno della zona in errore verranno ritardate hanno perso definitivamente. Le build appena attivate verranno distribuite automaticamente le restanti zone di funzionamento.

In caso di errore a livello di regione, il piano di controllo sarà offline e le build attualmente in esecuzione verranno ritardate o perse definitivamente. Trigger, worker e i dati di build non vengono mai replicati tra regioni. Ti consigliamo di preparare trigger e pool di worker in più regioni per mitigare un l'interruzione del servizio.

Cloud CDN

Cloud CDN distribuisce e memorizza nella cache i contenuti in diverse località sui per ridurre la latenza di servizio per i client. I contenuti memorizzati nella cache vengono pubblicati su un secondo il criterio del "best effort": quando una richiesta non può essere gestita dalla cache di Cloud CDN, la richiesta viene inoltrata ai server di origine, come VM di backend Bucket Cloud Storage in cui sono archiviati i contenuti originali.

In caso di errore in una zona o in una regione, le cache nelle località interessate vengono non disponibile. Le richieste in entrata vengono instradate alle località perimetrali di Google disponibili e cache. Se queste cache alternative non possono soddisfare la richiesta, le inoltreranno la richiesta a un server di origine disponibile. A condizione che il server possa pubblicare richiesta con dati aggiornati, non si verifichi alcuna perdita di contenuti. Un aumento di fallimenti della cache comporterà un'esperienza dei server di origine superiore a i normali volumi di traffico quando le cache sono riempite. Le richieste successive vengono gestito dalle cache non interessate dall'interruzione della zona o della regione.

Per ulteriori informazioni su Cloud CDN e sul comportamento della cache, consulta Documentazione di Cloud CDN.

Cloud Composer

Cloud Composer è un servizio gestito di orchestrazione del flusso di lavoro che consente puoi creare, pianificare, monitorare e gestire flussi di lavoro che interessano più cloud e i data center on-premise. Gli ambienti Cloud Composer si basano su nel progetto open source Apache Airflow.

La disponibilità dell'API Cloud Composer non è influenzata dall'indisponibilità a livello di zona. Durante a livello di zona, manterrai l'accesso all'API Cloud Composer, che include la possibilità di creare nuovi ambienti Cloud Composer.

Un ambiente Cloud Composer include un cluster GKE e la sua architettura. Durante un'interruzione a livello di zona, i flussi di lavoro nel cluster potrebbero subire interruzioni:

• In Cloud Composer 1, il cluster dell'ambiente è una risorsa di zona, pertanto un'interruzione a livello di zona potrebbe rendere il cluster non disponibile. Workflows l'esecuzione al momento dell'interruzione potrebbe essere arrestata prima del completamento.
• In Cloud Composer 2, il cluster dell'ambiente è una regione risorsa. Tuttavia, i flussi di lavoro eseguiti sui nodi nelle zone che interessati da un'interruzione a livello di zona potrebbero essere arrestati prima del completamento.

In entrambe le versioni di Cloud Composer, un'interruzione a livello di zona potrebbe per interrompere l'esecuzione di flussi di lavoro eseguiti parzialmente, incluse eventuali azioni esterne per eseguire il flusso di lavoro configurato da te. In base questo può causare incoerenze esternamente, ad esempio se il flusso si ferma a metà di un'esecuzione in più fasi per modificare datastore esterni. Dovresti quindi prendere in considerazione il processo di ripristino quando progetti Flusso di lavoro Airflow, inclusa la modalità di rilevamento degli stati del flusso di lavoro parzialmente non eseguiti e correggere eventuali modifiche parziali ai dati.

In Cloud Composer 1, durante un'interruzione di una zona, puoi scegliere di avviare nel nuovo ambiente Cloud Composer in un'altra zona. Poiché Airflow mantiene lo stato dei flussi di lavoro nel database di metadati, trasferendo in un nuovo ambiente Cloud Composer può richiedere passaggi e preparazione.

In Cloud Composer 2, puoi risolvere le interruzioni a livello di zona configurando ripristino di emergenza con snapshot dell'ambiente in anticipo. Durante un'interruzione di una zona, puoi passare a un altro ambiente trasferendo lo stato dei flussi di lavoro con di uno snapshot di ambiente. Solo Cloud Composer 2 supporta le emergenze il ripristino con snapshot dell'ambiente.

Cloud Data Fusion

Cloud Data Fusion è un'integrazione di dati aziendali completamente gestita per creare e gestire rapidamente pipeline di dati. Offre tre .

• Le interruzioni a livello di zona influiscono sulle istanze della versione Developer.

• Le interruzioni a livello di regione influiscono sulle istanze delle versioni Basic ed Enterprise.

Per controllare l'accesso alle risorse, puoi progettare ed eseguire pipeline in ambienti separati. Questa separazione ti consente di progettare una pipeline una volta sola e quindi di eseguirla in più ambienti cloud-native. Puoi ripristinare le pipeline in entrambi gli ambienti. Per ulteriori informazioni, vedi Esegui il backup e ripristina i dati dell'istanza.

I consigli seguenti riguardano le interruzioni a livello di regionale e a livello di zona.

Interruzioni nell'ambiente di progettazione delle pipeline

Nell'ambiente di progettazione, salva le bozze della pipeline in caso di interruzione. A seconda dei requisiti RTO e RPO specifici, puoi utilizzare le bozze salvate ripristinare la pipeline in un'altra istanza di Cloud Data Fusion un'interruzione del servizio.

Interruzioni nell'ambiente di esecuzione della pipeline

Nell'ambiente di esecuzione, la pipeline viene avviata internamente con Attivatori o pianificazioni di Cloud Data Fusion oppure esternamente con di orchestrazione dei container, come Cloud Composer. Per poter recuperare configurazioni di runtime delle pipeline, eseguire il backup di pipeline e configurazioni, come plug-in e pianificazioni. In caso di interruzione, puoi utilizzare il modello per replicare un'istanza in una regione o zona non interessata.

Un altro modo per prepararsi alle interruzioni è avere più istanze in e regioni con la stessa configurazione e lo stesso set di pipeline. Se utilizzi sorgenti di traffico esterne dell'orchestrazione, le pipeline in esecuzione possono essere bilanciate automaticamente di Compute Engine. Presta particolare attenzione per assicurarti che non vi siano risorse (ad esempio, dati o strumenti di orchestrazione) legati a una singola regione e utilizzati da tutti poiché potrebbe diventare il punto di errore centrale in un'interruzione. Per Ad esempio, puoi avere più istanze in diverse regioni e utilizzare Cloud Load Balancing e Cloud DNS per indirizzare le richieste di esecuzione della pipeline a un su un'istanza non interessata da un'interruzione (vedi l'esempio di livello 1 e architetture di livello 3).

Interruzioni per altri servizi dati Google Cloud nella pipeline

L'istanza potrebbe utilizzare altri servizi Google Cloud come origini dati degli ambienti di esecuzione delle pipeline, come Dataproc, Cloud Storage o BigQuery. Questi servizi possono essere regioni diverse. Quando è richiesta l'esecuzione tra regioni, si verifica un errore in entrambe le regioni si verifica un'interruzione. In questo scenario, segui le passaggi per il ripristino di emergenza, tenendo presente che la configurazione interregionale con servizi critici è meno resiliente.

Cloud Deploy

Cloud Deploy fornisce la distribuzione continua di carichi di lavoro in servizi di runtime ad esempio GKE e Cloud Run. Il servizio è composto di istanze a livello di regione che replicano in modo sincrono i dati tra le zone regione.

Interruzione a livello di zona: le operazioni del piano di controllo non sono interessate. Tuttavia, Build di Cloud Build (ad esempio operazioni di rendering o deployment) in esecuzione quando un guasto di una zona viene ritardato o viene perso definitivamente. Durante un un'interruzione del servizio, la risorsa Cloud Deploy che ha attivato la build (una release o implementazione) mostra uno stato di errore che indica l'operazione sottostante non riuscito. Puoi ricreare la risorsa per avviare una nuova build nel zone di funzionamento. Ad esempio, crea una nuova implementazione eseguendo di nuovo il deployment della release a un obiettivo.

Interruzione a livello di regione: le operazioni del piano di controllo non sono disponibili, così come i dati da Cloud Deploy, fino al ripristino della regione. Per semplificare la servizio di ripristino in caso di interruzione del servizio a livello di regione, ti consigliamo di archiviare la pipeline di distribuzione e le definizioni dei target nel controllo del codice sorgente. Puoi utilizzare questi file di configurazione per ricreare le pipeline di Cloud Deploy regione di funzionamento. Durante un'interruzione, i dati relativi alle release esistenti vengono persi. Crea una nuova release per continuare a eseguire il deployment del software nelle tue destinazioni.

Cloud DNS

Cloud DNS è un DNS (Domain Name System) globale, resiliente e ad alte prestazioni che pubblica i tuoi nomi di dominio nel DNS globale in una in molti modi diversi.

In caso di interruzione a livello di zona, Cloud DNS continua a gestire le richieste in un'altra zona nella stessa regione o in una diversa regione senza interruzioni. Aggiornamenti a I record Cloud DNS vengono replicati in modo sincrono tra le zone all'interno della regione e dove li ricevono. Pertanto, non si verificano perdite di dati.

In caso di interruzione del servizio a livello di regione, Cloud DNS continua a gestire le richieste in altre regioni. È possibile che gli aggiornamenti molto recenti ai record Cloud DNS non sarà disponibile perché gli aggiornamenti vengono prima elaborati in una singola regione prima di essere replicata in modo asincrono in altre regioni.

Cloud Functions

Cloud Functions è un ambiente di computing stateless in cui i clienti possono eseguire della loro funzione sull'infrastruttura di Google. Cloud Functions è un servizio di gestione dell'offerta, il che significa che i clienti possono scegliere la regione ma non le zone che lo compongono una regione. I dati e il traffico vengono automaticamente bilanciati del carico tra le zone all'interno di una regione. Le funzioni vengono scalate automaticamente per soddisfare il traffico in entrata e vengono caricate bilanciato tra le zone in base alle esigenze. Ogni zona mantiene uno scheduler fornisce questa scalabilità automatica per zona. È inoltre consapevole del carico ricevuto dalle altre zone ed eseguirà il provisioning nella zona per consentire eventuali errori a livello di zona.

Interruzione a livello di zona: Cloud Functions archivia i metadati e i dati personalizzata. Questi dati vengono archiviati a livello di regione e scritti in modo sincrono. L'API Cloud Functions Admin restituisce la chiamata API solo dopo che i dati sono stati impegnate a raggiungere il quorum in una regione. Poiché i dati sono archiviati a livello di regione, le operazioni del piano dati non sono interessate . Il traffico viene instradato automaticamente ad altre zone in caso di errore a livello di zona.

Interruzione a livello di regione: i clienti scelgono la regione Google Cloud di loro interesse in cui creare la propria funzione. I dati non vengono mai replicati tra regioni. Il traffico dei clienti non verrà mai instradato in un'altra regione da Cloud Functions. In caso di errore a livello di regione, Cloud Functions sarà di nuovo disponibile non appena l'interruzione verrà risolta. I clienti sono incoraggiati a eseguire il deployment in più regioni e a utilizzare Cloud Load Balancing per ottenere una disponibilità maggiore, se necessario.

API Cloud Healthcare

L'API Cloud Healthcare, un servizio per l'archiviazione e la gestione dei dati sanitari, progettato per offrire disponibilità elevata e protezione dall'ambiente di gestione a livello di regione, in base alla configurazione scelta.

Configurazione regionale: nella configurazione predefinita, l'API Cloud Healthcare offre per evitare guasti a livello di zona. Il deployment del servizio viene eseguito in tre zone in una regione, con i dati anche triplicati in diverse zone all'interno della regione. Nel in caso di errore a livello di zona che interessa il livello di servizio o il livello dati, le zone rimanenti prendono il controllo senza interruzioni. Con la configurazione a livello di regione, se un'intera regione in cui si trova il servizio subisce un'interruzione, il servizio non sarà disponibile finché la regione non tornerà online. In caso di evento imprevisto di un'intera regione, i dati archiviati in quella regione andranno persi.

Configurazione per più regioni: nella configurazione per più regioni, Il deployment dell'API Cloud Healthcare viene eseguito in tre zone appartenenti a tre diverse regioni. I dati vengono inoltre replicati in tre regioni. Protegge contro le perdite del servizio in caso di interruzione dell'intera regione, poiché le regioni rimanenti prenderanno automaticamente il controllo. I dati strutturati, come FHIR, sono in modo sincrono è replicata in più regioni, così è protetta dalla perdita di dati in caso di di un'interruzione dell'intera regione. I dati archiviati nei bucket Cloud Storage, come DICOM e dettatura o oggetti HL7v2/FHIR di grandi dimensioni, vengono replicati in modo asincrono. in più regioni.

Cloud Identity

I servizi di Cloud Identity sono distribuiti in più regioni e utilizzano con il bilanciamento del carico dinamico. Cloud Identity non consente agli utenti di selezionare un nell'ambito delle risorse. Se si verifica un'interruzione in una zona o regione specifica, il traffico viene vengono distribuiti automaticamente in altre zone o regioni.

Il mirroring dei dati permanenti avviene in più regioni, con replica sincrona in nella maggior parte dei casi. Per motivi legati alle prestazioni, alcuni sistemi, come cache o modifiche che interessano un numero elevato di entità, vengono replicati in modo asincrono regioni. Se la regione principale in cui sono archiviati i dati più aggiornati subisce un'interruzione, Cloud Identity gestisce i dati inattivi da un'altra posizione fino a quando la regione principale non diventa disponibile.

Cloud Interconnect

Cloud Interconnect offre ai clienti RFC 1918 l'accesso alle reti Google Cloud dai loro data center on-premise tramite cavi fisici connessi al perimetro del peering di Google.

Cloud Interconnect fornisce ai clienti uno SLA del 99,9% se eseguono il provisioning a due EAD (Edge disponibilità Domains) in un'area metropolitana. R È disponibile uno SLA del 99,99% se il cliente esegue il provisioning delle connessioni in due EAD in da due aree metropolitane a due regioni con routing globale. Consulta Panoramica della topologia per le applicazioni non critiche e Panoramica della topologia per le applicazioni a livello di produzione per ulteriori informazioni.

Cloud Interconnect è indipendente dalla zona di computing e offre disponibilità elevata sotto forma di EAD. In caso di errore EAD, la sessione BGP a quell'EAD e il failover del traffico viene eseguito verso l'altro EAD.

In caso di errore a livello di regione, le sessioni BGP in quella regione si interrompono e il failover del traffico verso le risorse nella regione di lavoro viene eseguito. Ciò si applica nei casi in cui Il routing globale è abilitato.

Cloud Key Management Service

Cloud Key Management Service (Cloud KMS) fornisce scalabilità e durabilità elevata la gestione delle risorse delle chiavi di crittografia. Cloud KMS archivia tutti i suoi dati e metadati nei database Spanner, che offrono un'elevata durabilità dei dati e la disponibilità con la replica sincrona.

Le risorse Cloud KMS possono essere create in una singola regione, regioni o a livello globale.

In caso di interruzione a livello di zona, Cloud KMS continua a gestire le richieste in un'altra zona nella stessa regione o in una diversa regione senza interruzioni. Poiché i dati viene replicata in modo sincrono, senza alcuna perdita o danneggiamento dei dati. Quando la zona l'interruzione del servizio è stata risolta, viene ripristinata la ridondanza completa.

In caso di interruzione del servizio a livello di regione, le risorse di quella regione vengono offline finché la regione non sarà di nuovo disponibile. Tieni presente che anche all'interno di regione, almeno tre repliche sono mantenute in zone separate. Quando è più alta se la disponibilità è obbligatoria, le risorse devono essere archiviate in più regioni o configurazione. Le configurazioni multiregionali e globali sono progettate per rimanere disponibili durante un'interruzione regionale mediante l'archiviazione e la gestione dei dati con ridondanza geografica. in più di una regione.

Cloud External Key Manager (Cloud EKM)

Cloud External Key Manager è integrato con Cloud Key Management Service per consentirti di controllare e accedere alle chiavi esterne tramite partner terzi supportati. Puoi utilizzare queste chiavi esterne per criptare i dati at-rest da utilizzare per altri servizi Google Cloud che supportano l'integrazione delle chiavi di crittografia gestite dal cliente (CMEK).

• Interruzione a livello di zona: Cloud External Key Manager è resiliente alle interruzioni a livello di zona grazie alla ridondanza fornita da più zone in una regione. Se si verifica un'interruzione a livello di zona, il traffico viene reindirizzato ad altre zone all'interno della regione. Durante il reindirizzamento del traffico, potresti notare un aumento degli errori, ma il servizio è ancora disponibile.

• Interruzione a livello di regione: Cloud External Key Manager non è disponibile durante un'interruzione a livello di regione nella regione interessata. Non esiste un meccanismo di failover che reindirizza le richieste tra regioni. Consigliamo ai clienti di utilizzare più regioni per eseguire i propri job.

Cloud External Key Manager non archivia i dati dei clienti in modo permanente. Di conseguenza, non si verificano perdite di dati durante un'interruzione regionale nel sistema Cloud External Key Manager. Tuttavia, Cloud External Key Manager dipende dalla disponibilità di altri servizi, come Cloud Key Management Service e fornitori di terze parti esterni. Se questi sistemi presentano errori durante un'interruzione del servizio a livello di regione, potresti perdere i dati. L'RPO/RTO di questi sistemi non rientra nell'ambito degli impegni del gestore delle chiavi esterne di Cloud.

Cloud Load Balancing

Cloud Load Balancing è un servizio gestito completamente distribuito e software-defined. Con Cloud Load Balancing, un singolo indirizzo IP anycast può fungere da frontend per i backend in regioni di tutto il mondo. Non è basato su hardware, quindi non devi gestire un'infrastruttura fisica di bilanciamento del carico. I bilanciatori del carico sono un'infrastruttura della maggior parte delle applicazioni ad alta disponibilità.

Cloud Load Balancing offre bilanciatori del carico a livello di regione e globale. Inoltre, offre il bilanciamento del carico tra regioni, compreso il failover automatico multiregione, che trasferisce il traffico nei backend di failover se i backend primari non sono integri.

I bilanciatori del carico globali sono resilienti alle interruzioni di servizio sia a livello di zona che a livello di regione. La i bilanciatori del carico regionali sono resilienti alle interruzioni a livello di zona, ma sono interessati dalle interruzioni nella loro regione. In entrambi i casi, però, è importante comprendere che la resilienza dell'applicazione complessiva non dipende solo dal tipo di bilanciatore del carico di cui esegui il deployment, ma anche sulla ridondanza dei tuoi backend.

Per saperne di più su Cloud Load Balancing e sulle sue funzionalità, vedi Panoramica di Cloud Load Balancing.

Cloud Logging

Cloud Logging è costituito da due parti principali: il router dei log e spazio di archiviazione di Cloud Logging.

Il router dei log gestisce il flusso degli eventi dei log e indirizza i log alla Cloud Storage, Pub/Sub, BigQuery o Cloud Logging archiviazione.

Lo spazio di archiviazione di Cloud Logging è un servizio per l'archiviazione, l'esecuzione di query e la gestione la conformità per i log. Supporta molti utenti e flussi di lavoro, inclusi sviluppo, conformità, risoluzione dei problemi e avvisi proattivi.

Router dei log e log in entrata: durante un'interruzione del servizio a livello di zona, l'API Cloud Logging instrada i log ad altre zone della regione. Normalmente, i log vengono instradati Il router dei log per Cloud Logging, BigQuery o Pub/Sub vengono scritti nella destinazione finale il prima possibile, mentre i log vengono inviati I dati di Cloud Storage vengono inseriti nel buffer e scritti in batch ogni ora.

Voci di log: in caso di interruzione del servizio a livello di zona o di regione, le voci di log che sono stati inseriti nel buffer nella zona o regione interessata e non sono stati scritti nell'esportazione di destinazione diventano inaccessibili. Anche le metriche basate su log vengono calcolate il router dei log e soggetto agli stessi vincoli. Una volta inviati al località di esportazione dei log selezionata, i log vengono replicati in base alla destinazione completamente gestito di Google Cloud. I log esportati nello spazio di archiviazione di Cloud Logging sono in modo sincrono sono replicati in due zone di una regione. Per il comportamento di replica di altri i tipi di destinazione, consulta la sezione pertinente di questo articolo. Tieni presente che i log esportati in Cloud Storage vengono raggruppati e scritti ogni ora. Consigliamo quindi di usare Cloud Logging, BigQuery, per Pub/Sub al minimo la quantità di dati interessati da un'interruzione.

Metadati di log:vengono archiviati i metadati come la configurazione di sink ed esclusione a livello globale ma memorizzati a livello regionale. In caso di interruzione, il log regionale Le istanze del router potrebbero funzionare. Le interruzioni in una singola regione non hanno alcun impatto al di fuori regione.

Cloud Monitoring

Cloud Monitoring è costituito da una varietà di funzionalità interconnesse, come dashboard (integrate e definite dall'utente), avvisi e monitoraggio dell'uptime.

Tutte le configurazioni di Cloud Monitoring, tra cui dashboard, controlli di uptime e sono definiti a livello globale. Tutte le modifiche apportate vengono replicate in modo sincrono a più regioni. Pertanto, sia a livello di zona che di regione alla configurazione in caso di interruzione del servizio, le modifiche apportate correttamente alla configurazione sono durature. Inoltre, sebbene gli errori temporanei di lettura e scrittura possono verificarsi quando inizialmente una zona o una regione degli errori, Cloud Monitoring reindirizza le richieste alle zone disponibili regioni. In questo caso, puoi riprovare a modificare la configurazione con regole esponenziali il backoff.

Quando scrivi le metriche per una risorsa specifica, Cloud Monitoring prima di tutto identifica la regione in cui si trova la risorsa. Quindi scrive tre repliche indipendenti dei dati delle metriche all'interno della regione. Le metriche regionali nel complesso la scrittura della metrica viene restituita correttamente non appena una delle tre scritture . Non è garantito che le tre repliche si trovino in zone diverse all'interno regione.

• A livello di zona: durante un'interruzione a livello di zona, le scritture e le letture delle metriche sono completamente non è disponibile per le risorse nella zona interessata. In effetti, Cloud Monitoring funziona come se la zona interessata non esistesse.

• A livello di regione: durante un'interruzione a livello di regione, le scritture e le letture delle metriche sono completamente non è disponibile per le risorse nella regione interessata. In effetti, Cloud Monitoring funziona come se la regione interessata non esistesse.

Cloud NAT

Cloud NAT (Network Address Translation) è un servizio gestito, distribuito e software-defined, che consente a determinate risorse senza indirizzi IP esterni creano connessioni in uscita verso internet. È non basate su VM o appliance proxy. Cloud NAT configura invece Software Andromeda che alimenta la tua rete Virtual Private Cloud in modo da fornire Network Address Translation (NAT di origine o SNAT) per VM senza IP esterno indirizzi IP esterni. Cloud NAT fornisce inoltre Network Address Translation di destinazione (destination NAT o DNAT) per i pacchetti di risposta in entrata stabiliti.

Per ulteriori informazioni sulla funzionalità di Cloud NAT, consulta documentazione.

Interruzione a livello di zona: Cloud NAT è resiliente agli errori a livello di zona poiché e il piano dati di rete sono ridondanti in più zone all'interno una regione.

Interruzione a livello di regione: Cloud NAT è un prodotto regionale, quindi non può resistere a livello di regione.

Router Cloud

Router Cloud è un servizio Google Cloud completamente distribuito e gestito che utilizza il protocollo BGP (Border Gateway Protocol) per pubblicizzare gli intervalli di indirizzi IP. it programma route dinamiche in base agli annunci BGP che riceve da un peer. Anziché un dispositivo o un'appliance fisica, ciascun router Cloud consiste delle attività software che fungono da relatori BGP.

In caso di interruzione a livello di zona, il router Cloud con disponibilità elevata (HA) è resiliente agli errori a livello di zona. In questo caso, un'interfaccia potrebbe perde la connettività, ma il traffico viene reindirizzato all'altra interfaccia il routing dinamico mediante BGP.

Nel caso di un'interruzione regionale, il router Cloud è un prodotto regionale, quindi non è in grado di sostenere un errore a livello di regione. Se i clienti hanno attivato il routing globale questa modalità, il routing tra la regione in errore e altre regioni potrebbe essere interessato.

Cloud Run

Cloud Run è un ambiente di computing stateless in cui i clienti possono eseguire e il loro codice containerizzato sull'infrastruttura di Google. Cloud Run è un'offerta regionale, il che significa che i clienti possono scegliere ma non alle zone che compongono una regione. I dati e il traffico vengono automaticamente bilanciati del carico tra le zone all'interno di una regione. Le istanze di container vengono scalate automaticamente per soddisfare il traffico in entrata e bilanciare il carico tra le zone in base alle esigenze. Ogni zona gestisce uno scheduler che fornisce questa scalabilità automatica per zona. È inoltre consapevole del carico ricevuto dalle altre zone ed eseguirà il provisioning nella zona per consentire eventuali errori a livello di zona.

Interruzione a livello di zona: Cloud Run archivia i metadati e i dati di cui è stato eseguito il deployment containerizzato. Questi dati vengono archiviati a livello di regione e scritti in modo sincrono. L'API Cloud Run Admin restituisce la chiamata API solo una volta che i dati è stato impegnato a raggiungere il quorum all'interno di una regione. Poiché i dati sono archiviati a livello di regione, le operazioni del piano dati non sono interessate . Il traffico verrà instradato automaticamente ad altre zone in caso di errore di una zona.

Interruzione a livello di regione: i clienti scelgono la regione Google Cloud di loro interesse in cui creare il proprio servizio Cloud Run. I dati non vengono mai replicati regioni. Il traffico dei clienti non verrà mai instradato a una regione diversa in Cloud Run. In caso di errore a livello di regione, Cloud Run tornano disponibili non appena l'interruzione viene risolta. I clienti sono di eseguire il deployment in più regioni e di utilizzare Cloud Load Balancing per ottenere una disponibilità maggiore, se necessario.

Cloud Shell

Cloud Shell fornisce agli utenti Google Cloud l'accesso a un singolo utente Istanze di Compute Engine preconfigurate per l'onboarding, l'istruzione sviluppo e attività degli operatori.

Cloud Shell non è adatto all'esecuzione di carichi di lavoro delle applicazioni intese invece a casi d'uso didattici e di sviluppo interattivi. Ha limiti di quota di runtime per utente e viene arrestato automaticamente dopo un per un breve periodo di inattività e l'istanza è accessibile solo al utente.

Le istanze di Compute Engine a supporto del servizio sono risorse a livello di zona, quindi in caso di interruzione di una zona, Cloud Shell di un utente non è disponibile.

Cloud Source Repositories

Cloud Source Repositories consente agli utenti di creare e gestire codice sorgente privato repository. Questo prodotto è stato progettato con un modello globale, pertanto non è necessario configurarla per la resilienza a livello di regione o zona.

Al contrario, le operazioni git push su Cloud Source Repositories in modo sincrono replicare l'aggiornamento del repository di codice sorgente in più zone regioni. Ciò significa che il servizio è resiliente alle interruzioni in qualsiasi regione.

Se si verifica un'interruzione in una zona o regione specifica, il traffico viene automaticamente in altre zone o regioni.

La funzionalità per eseguire automaticamente il mirroring dei repository da GitHub o Bitbucket può essere che presentano problemi in questi prodotti. Ad esempio, il mirroring è influenzato se GitHub o Bitbucket non possono avvisare Cloud Source Repositories dei nuovi commit. se Cloud Source Repositories non riesce a recuperare contenuti dall'elenco repository Git.

Spanner

Spanner è una piattaforma multiversione, scalabile, replicato in modo sincrono e a elevata coerenza la semantica.

Le istanze Spanner a livello di regione replicano in modo sincrono i dati tra in una singola regione. Una scrittura su un'istanza Spanner a livello di regione inviato in modo sincrono a tutte e 3 le repliche e confermato al client in seguito alle almeno 2 repliche (quorum di maggioranza di 2 su 3) hanno commesso la scrittura. Questo rende Spanner resiliente a un errore di una zona fornendo l'accesso a tutti poiché le ultime scritture sono state persistenti e il quorum di maggioranza è stato raggiunto le scritture possono ancora essere ottenute con 2 repliche.

Le istanze multiregionali di Spanner includono un quorum di scrittura che replica in modo sincrono i dati in 5 zone situate in tre regioni (due repliche di lettura e scrittura, ciascuna nella regione leader predefinita e in un'altra; e una replica nella regione di testimonianza). Una scrittura su uno Spanner multiregionale dell'istanza viene confermata dopo almeno 3 repliche (quorum di maggioranza di 3 di 5) hanno eseguito il commit della scrittura. In caso di errore di una zona o di una regione, Spanner ha accesso a tutti i dati (incluse le ultime scritture) e pubblica Richieste di lettura/scrittura quando i dati sono persistenti in almeno 3 zone in 2 al momento della conferma di scrittura al client.

Visualizza Spanner documentazione relativa all'istanza per ulteriori informazioni al riguardo configurazioni e documentazione sulla replica per saperne di più sul funzionamento della replica di Spanner.

Cloud SQL

Cloud SQL è un servizio di database relazionale completamente gestito per MySQL, PostgreSQL e SQL Server. Cloud SQL utilizza servizi virtuali gestiti di Compute Engine per eseguire il software del database. Offre un'alta disponibilità per la ridondanza a livello di regione, proteggendo il database da una zona o un'interruzione del servizio. È possibile eseguire il provisioning delle repliche tra regioni per proteggere il database da interruzione del servizio in una regione specifica. Poiché il prodotto offre anche un'opzione a livello di zona, che non è resiliente a un'interruzione di una zona o una regione, devi fare attenzione a selezionare il livello configurazione della disponibilità, repliche tra regioni o entrambe.

Interruzione a livello di zona: l'opzione alta disponibilità crea un ambiente principale e uno in standby di un'istanza VM in due zone distinte all'interno di una regione. Durante il normale funzionamento, l'istanza VM principale gestisce tutte le richieste, scrivendo i file di database il disco permanente regionale, replicato in modo sincrono nell'istanza zone di standby. Se un'interruzione di una zona interessa l'istanza principale, Cloud SQL avvia un failover durante il quale il Persistent Disk è collegato La VM e il traffico vengono reindirizzati.

Durante questo processo, è necessario inizializzare il database, inclusa l'elaborazione eventuali transazioni scritte nel log Transaction (Transazione), ma non applicate al database. Il numero e il tipo di transazioni non elaborate possono aumentare il tempo RTO. Elevata operazioni di scrittura recenti possono portare a un backlog di transazioni non elaborate. Il tempo RTO è maggiormente influenzata da (a) attività di scrittura recenti e (b) modifiche recenti agli schemi dei database.

Infine, una volta risolta l'interruzione del servizio a livello di zona, puoi attivare manualmente per riprendere l'elaborazione nella zona principale.

Per maggiori dettagli sull'opzione per l'alta disponibilità, consulta la documentazione di Cloud SQL alta disponibilità documentazione.

Interruzione a livello di regione: l'opzione di replica tra regioni protegge il database da interruzioni regionali creando repliche di lettura dell'istanza principale in altre regioni. La replica tra regioni utilizza la replica asincrona, consente all'istanza principale di eseguire il commit delle transazioni prima del commit replicas. La differenza di tempo tra il momento in cui viene impegnata una transazione sulla dell'istanza principale e il relativo commit nella replica è noto "tempo di replica" (che può essere monitorato). Questa metrica riflette entrambe le transazioni che non sono state inviate dall'account principale alle repliche, così come alle transazioni ricevute ma che non sono state elaborati dalla replica. Le transazioni non inviate alla replica diventeranno durante un'interruzione regionale. Transazioni ricevute ma non elaborate da la replica influisce sul tempo di ripristino, come descritto di seguito.

Cloud SQL consiglia di testare il carico di lavoro con una configurazione che includa una replica per stabilire una "transazioni sicure al secondo (TPS)" di sicurezza, ovvero il TPS sostenuto più alto che non accumula il ritardo di replica. Se le tue carico di lavoro supera il limite TPS sicuro, il ritardo della replica si accumula, che influiscono sui valori RPO e RTO. Come indicazione generale, evita di utilizzare istanze di piccole dimensioni (<2 core vCPU, dischi da <100 GB o DP-HDD), che sono suscettibili al ritardo della replica.

In caso di interruzione a livello di regione, devi decidere se promuovere manualmente una di lettura. Questa è un'operazione manuale perché la promozione può causare un cervello spaccato scenario in cui la replica promossa accetta nuove transazioni nonostante il ritardo nella principale al momento della promozione. Ciò può causare problemi quando a livello di regione è stata risolta e devi riconciliare le transazioni non è mai stato propagato dall'istanza principale a quella di replica. Se questo è problematico per le tue esigenze, puoi prendere in considerazione un database di replica sincrona tra regioni prodotto come Spanner.

Una volta attivata dall'utente, il processo di promozione segue passaggi simili alla l'attivazione di un'istanza in standby nella configurazione ad alta disponibilità. In questo processo, la replica di lettura deve elaborare il log delle transazioni che tempo di recupero totale. Poiché nella configurazione non è coinvolto un bilanciatore del carico la promozione della replica, reindirizza manualmente le applicazioni all'istanza principale promossa.

Per maggiori dettagli sull'opzione di replica tra regioni, consulta la documentazione di Cloud SQL replica tra regioni documentazione.

Per saperne di più sulla RE di Cloud SQL, consulta quanto segue:

• Ripristino di emergenza del database Cloud SQL per MySQL
• Ripristino di emergenza dei database Cloud SQL per PostgreSQL
• Ripristino di emergenza dei database Cloud SQL per SQL Server

Cloud Storage

Cloud Storage fornisce un oggetto unificato a livello globale, scalabile e a elevata durabilità archiviazione. I bucket Cloud Storage possono essere creati in uno dei tre seguenti tipi di località: in una singola regione, in una doppia regione o in più regioni all'interno di continente. Con i bucket a livello di regione, gli oggetti vengono archiviati in modo ridondante le zone di disponibilità in una singola regione. Bucket a due e più regioni, on dall'altro lato, sono georidondanti. Ciò significa che, dopo che i dati appena scritti vengono replicati in almeno una regione remota, gli oggetti sono archiviati in modo ridondante regioni. Questo approccio offre ai dati in bucket a due e più regioni un insieme più ampio di protezioni aggiuntive rispetto a quelle ottenibili con Regional Storage.

I bucket a livello di regione sono progettati per essere resilienti in caso di interruzione in una singola zona di disponibilità. Se una zona subisce un'interruzione, gli oggetti nella zona non disponibile vengono offerti in modo automatico e trasparente da qualunque punto della regione. Dati e i metadati sono archiviati in modo ridondante nelle varie zone, a partire dal e scrivere. Nessuna scrittura viene persa se una zona non è più disponibile. Nel caso di un a livello di regione, i bucket a livello di regione in quella regione sono offline fino a quando torna disponibile.

Se hai bisogno di una maggiore disponibilità, puoi archiviare i dati in un o la configurazione a due o più regioni. Bucket a due e più regioni sono singoli bucket (nessuna località principale e secondaria separata), ma archiviano in modo ridondante tra dati e metadati. In caso di interruzione a livello di regione, non venga interrotto. Sono due o più regioni attivi/attivi, in quanto consente di leggere e scrivere carichi di lavoro più di una regione contemporaneamente mentre il bucket rimane coerente. Questo può essere particolarmente interessante per i clienti che vogliono suddividere il proprio carico di lavoro nelle due regioni nell'ambito di un ripristino di emergenza dell'architettura.

Le due o più regioni sono a elevata coerenza perché i metadati e sono sempre scritte in modo sincrono tra le regioni. Questo approccio consente al servizio determinano qual è la versione più recente di un oggetto e dove può essere pubblicata anche da regioni remote.

I dati vengono replicati in modo asincrono. Ciò significa che esiste una finestra temporale RPO in cui le gli oggetti sono inizialmente protetti come oggetti regionali, con ridondanza le zone di disponibilità all'interno di una singola regione. Il servizio replica quindi oggetti all'interno di quella finestra RPO in una o più regioni remote per renderli con ridondanza geografica. Al termine della replica, i dati possono essere gestiti automaticamente e in modo trasparente da un'altra regione nel caso di una o un'interruzione del servizio. La replica turbo è una funzionalità premium disponibile su un bucket a due regioni per ottenere una finestra RPO più piccola, che abbia come target il 100% degli oggetti appena scritti replicati e resi geo-ridondanti in 15 minuti.

L'RPO è una considerazione importante perché, durante un'interruzione regionale, i dati scritto di recente nella regione interessata all'interno della finestra RPO potrebbe non essere ancora è stato replicato in altre regioni. Di conseguenza, questi dati potrebbero non essere accessibili durante l'interruzione del servizio e che potrebbero andare persa in caso di distruzione fisica nella regione interessata.

Cloud Translation

Cloud Translation ha server di computing attivi in più zone e regioni. it supporta anche la replica sincrona dei dati tra zone all'interno delle regioni. Questi aiutano Translation a raggiungere failover istantaneo senza perdita di dati per errori a livello di zona che richiedono input o aggiustamenti da parte del cliente. In caso di errore a livello di regione, Cloud Translation non è disponibile.

Compute Engine

Compute Engine è uno dei servizi Infrastructure as a Service di Google Cloud le opzioni di CPU e memoria disponibili. Utilizza l'infrastruttura globale di Google per offrire macchine virtuali (e servizi correlati) ai clienti.

Le istanze di Compute Engine sono risorse di zona quindi, in caso di interruzione di una zona, non sono disponibili per impostazione predefinita. Compute Engine offre gruppi di istanze gestite (MIG) che possono fare automaticamente lo scale up di VM aggiuntive da VM preconfigurate sia all'interno di una singola zona che in più zone all'interno di un regione. I gruppi di istanze gestite sono ideali per le applicazioni che richiedono resilienza alla perdita di zone sono stateless, ma richiedono configurazione e pianificazione delle risorse. È possibile utilizzare più MIG a livello di regione per ottenere la resilienza delle interruzioni a livello di regione per le applicazioni stateless.

Le applicazioni con carichi di lavoro stateful possono comunque MIG stateful, ma occorre prestare particolare attenzione nella pianificazione delle capacità poiché scalare orizzontalmente. In entrambi gli scenari è importante configurare e testare in anticipo i modelli di istanza Compute Engine e i gruppi di istanze gestite per garantire di failover in altre zone. Consulta le Nella sezione precedente Sviluppa le tue architetture di riferimento e le tue guide per saperne di più informazioni.

Single-tenancy

Single-tenancy ti consente di avere accesso esclusivo a un nodo single-tenant, ovvero un server Compute Engine fisico dedicato esclusivamente all'hosting alle VM del progetto.

I nodi single-tenant, come le istanze di Compute Engine, sono risorse di zona. Nella di un'interruzione del servizio a livello di zona, non sono disponibili. per ridurre i costi errori, puoi creare un nodo single-tenant in un'altra zona. Dato che carichi di lavoro potrebbero trarre vantaggio da nodi single-tenant per le licenze o la contabilità CAPEX è consigliabile pianificare in anticipo una strategia di failover.

La ricreazione di queste risorse in una località diversa potrebbe comportare ulteriori costi di licenza o violano i requisiti contabili CAPEX. Per indicazioni generali, vedi Sviluppa le tue architetture di riferimento e le tue guide.

I nodi single-tenant sono risorse di zona e non possono tollerare errori a livello di regione. Per scalare tra zone, usa MIG regionali.

Networking per Compute Engine

Per informazioni sulle configurazioni ad alta disponibilità per le connessioni Interconnect, vedi i seguenti documenti:

• Disponibilità del 99,99% per Dedicated Interconnect
• Disponibilità del 99,99% per Partner Interconnect

Puoi eseguire il provisioning degli indirizzi IP esterni globale o regionale, il che ne influisce sulla disponibilità in caso di errore a livello di regione.

Resilienza di Cloud Load Balancing

I bilanciatori del carico sono un componente fondamentale della maggior parte delle applicazioni ad alta disponibilità. È importante capire che la resilienza dell'applicazione nel suo complesso dipende non solo dall'ambito del bilanciatore del carico che scegli (globale a livello di regione), ma anche in base alla ridondanza dei tuoi servizi di backend.

La tabella seguente riassume la resilienza del bilanciatore del carico in base al carico la distribuzione o l'ambito del bilanciatore.

Ambito del bilanciatore del carico	Architettura	Resistente alle interruzioni a livello di zona	Resistente all'interruzione regionale
Globale	Ogni bilanciatore del carico è distribuito in tutte le regioni
Tra regioni	Ogni bilanciatore del carico è distribuito in più regioni
Regionale	Ogni bilanciatore del carico è distribuito in più zone della regione		Un'interruzione in una determinata regione influisce I bilanciatori del carico a livello di regione in quella regione

Per saperne di più sulla scelta di un bilanciatore del carico, consulta Cloud Load Balancing documentazione.

Connectivity Tests

Connectivity Tests è uno strumento di diagnostica che ti consente di controllare la connettività tra gli endpoint di rete. Analizza la configurazione e, in alcuni casi, esegue un'analisi del piano dati in tempo reale tra gli endpoint. Un endpoint è un'origine o una destinazione del traffico di rete, come una VM, un cluster Google Kubernetes Engine (GKE), una regola di forwarding del bilanciatore del carico o un indirizzo IP . Connectivity Tests è uno strumento di diagnostica senza componenti del piano dati. Non elabora né genera traffico di utenti.

Interruzione a livello di zona: le risorse di Connectivity Tests sono globali. Puoi gestire e visualizzarle in caso di interruzione a livello di zona. Risorse Connectivity Tests sono i risultati dei test di configurazione. Questi risultati potrebbero includere i dati di configurazione delle risorse di zona (ad esempio le istanze VM) in un zona di destinazione. In caso di interruzione, i risultati dell'analisi non sono accurati perché l'analisi si basa su dati inattivi prima dell'interruzione. Non fare affidamento su questo.

Interruzione a livello di regione: in un'interruzione a livello di regione, puoi comunque gestire e visualizzare Risorse di Connectivity Tests. Le risorse di Connectivity Tests potrebbero includere di configurazione dei dati di configurazione delle risorse di regione, come le subnet, regione. In caso di interruzione, i risultati dell'analisi non sono accurati perché l'analisi si basa su dati inattivi prima dell'interruzione. Non fare affidamento su questo.

Container Registry

Container Registry fornisce un'implementazione scalabile del Docker Registry in hosting per l'archiviazione sicura e privata delle immagini container Docker. Container Registry implementa API HTTP Docker Registry.

Container Registry è un servizio globale che archivia in modo sincrono i metadati delle immagini in modo ridondante in più zone e regioni per impostazione predefinita. Le immagini container archiviati in bucket multiregionali di Cloud Storage. Con questa strategia di archiviazione, Container Registry offre resilienza in caso di interruzione a livello di zona in tutti i casi e a livello di regione la resilienza dell'interruzione per i dati che sono stati replicati in modo asincrono in più regioni da Cloud Storage.

Database Migration Service

Database Migration Service è un servizio Google Cloud completamente gestito per la migrazione dei database da altri cloud provider o dai data center on-premise a Google Cloud.

Database Migration Service è progettato come piano di controllo a livello di regione. Il piano di controllo non dipende da una singola zona in una determinata regione. Durante un'interruzione a livello di zona, manterrai l'accesso alle API Database Migration Service, inclusa la possibilità di creare e gestire i job di migrazione. Durante un'interruzione a livello di regione, perderai l'accesso alle risorse di Database Migration Service che appartengono a quella regione finché l'interruzione non viene risolta.

Database Migration Service dipende dalla disponibilità dei database di origine e di destinazione utilizzate per il processo di migrazione. Se un database di origine o di destinazione di Database Migration Service non è disponibile, le migrazioni non progrediscono, ma i dati principali dei clienti o i dati del job non vengono persi. I job di migrazione riprendono quando i database di origine e di destinazione diventano di nuovo disponibili.

Ad esempio, puoi configurare un database Cloud SQL di destinazione con l'alta disponibilità abilitata per ottenere un database di destinazione resiliente per le interruzioni a livello di zona.

Le migrazioni di Database Migration Service passano attraverso due fasi:

• Dump completo: esegue una copia completa dei dati dall'origine alla destinazione in base alle specifiche del job di migrazione.
• Change Data Capture (CDC): replica le modifiche incrementali dall'origine alla destinazione.

Interruzione a livello di zona: se si verifica un errore di zona durante una di queste fasi, puoi comunque accedere e gestire in Database Migration Service. La migrazione dei dati è interessata come segue:

• Dump completo: la migrazione dei dati non riesce; devi riavviare il job di migrazione il database di destinazione completa l'operazione di failover.
• CDC: la migrazione dei dati è in pausa. Il job di migrazione riprende automaticamente una volta che la destinazione completa l'operazione di failover.

Interruzione a livello di regione: Database Migration Service non supporta le risorse tra regioni, pertanto non è resiliente in caso di errori a livello di regione.

Dataflow

Dataflow è il sistema di elaborazione dei dati serverless e completamente gestito di Google Cloud per pipeline di flusso e batch. Per impostazione predefinita, un endpoint a livello di regione configura il worker Dataflow per utilizzare tutte le zone disponibili all'interno della regione. La selezione della zona è calcolato per ciascun worker al momento della creazione del worker, ottimizzandolo in base alla risorsa acquisizione e utilizzo di dati prenotazioni. Nella configurazione predefinita per i job Dataflow, i dati intermedi sono dal servizio Dataflow, mentre lo stato del job viene archiviato e il backend. In caso di errore di una zona, i job Dataflow possono continuano a essere eseguiti perché i worker vengono ricreati in altre zone.

Si applicano le seguenti limitazioni:

• Il posizionamento a livello di regione è supportato solo per i job che utilizzano Streaming Engine oppure Dataflow Shuffle. Job che hanno disattivato Streaming Engine o Dataflow Shuffle non può utilizzare il posizionamento a livello di regione.
• Il posizionamento regionale si applica solo alle VM. Non si applica allo streaming Risorse correlate a Dataflow e a Dataflow.
• Le VM non vengono replicate in più zone. Se una VM non è più disponibile, i suoi elementi di lavoro vengono considerati persi e vengono rielaborati da un altro VM.
• Se si verifica uno stockout a livello di regione, il servizio Dataflow non può creare ad altre VM.

Architettura di pipeline Dataflow per l'alta disponibilità

Puoi eseguire più pipeline di flusso in parallelo per dati ad alta disponibilità e l'elaborazione dei dati. Ad esempio, puoi eseguire due job di flussi di dati paralleli regioni. L'esecuzione di pipeline parallele fornisce ridondanza geografica e tolleranza di errore per i dati e l'elaborazione dei dati. Considerando la disponibilità geografica delle origini dati e puoi eseguire pipeline end-to-end in un ambiente multiregionale a disponibilità elevata configurazione. Per ulteriori informazioni, vedi Alta disponibilità e ridondanza geografica in "Progettare flussi di lavoro della pipeline Dataflow".

In caso di interruzione di una zona o di una regione, puoi evitare la perdita di dati riutilizzando stessa sottoscrizione all'argomento Pub/Sub. Per garantire che i record non siano persi durante lo shuffle, Dataflow usa il backup upstream, che il worker che invia i record riprovi RPC finché non riceve che i dati sono stati ricevuti e che gli effetti collaterali di durante l'elaborazione del record si impegnano nell'archiviazione permanente a valle. Dataflow continua anche a riprovare RPC se il worker invia i record diventa non disponibile. I nuovi tentativi delle RPC assicurano che ogni record venga consegnato esattamente una volta. Per ulteriori informazioni sulla garanzia "exactly-once" di Dataflow, consulta exactly-once in Dataflow.

Se la pipeline utilizza il raggruppamento o il time-windowing, puoi utilizzare il metodo Cerca la funzionalità Pub/Sub o la funzionalità Replay di Kafka dopo un a livello di zona o di regione per rielaborare gli elementi di dati e arrivare allo stesso risultati del calcolo. Se la logica di business utilizzata dalla pipeline non si basa sui dati prima dell'interruzione, la perdita di dati degli output della pipeline può essere ridotta al minimo fino a 0 elementi. Se la logica di business della pipeline si basa su dati sia stata elaborata prima dell'interruzione (ad esempio, se vengono usate finestre scorrevoli lunghe, o se in una finestra temporale globale vengono memorizzati contatori sempre crescenti), Utilizzare gli snapshot di Dataflow per salvare lo stato della pipeline in modalità flusso e avviare una nuova versione del job senza perdere lo stato.

Dataproc

Dataproc offre funzionalità di elaborazione dei dati in modalità flusso e batch. Dataproc è progettato come piano di controllo a livello di regione che consente agli utenti per gestire i cluster Dataproc. Il piano di controllo non dipende alla singola zona di una data regione. Pertanto, durante un'interruzione a livello di zona, alle API Dataproc, inclusa la possibilità di creare nuovi cluster.

Puoi creare cluster Dataproc su:

• Cluster Dataproc su Compute Engine
• Cluster Dataproc su GKE

Cluster Dataproc su Compute Engine

Poiché un cluster Dataproc su Compute Engine è una risorsa di zona, un'interruzione a livello di zona rende il cluster non disponibile o lo distrugge. Dataproc non esegue automaticamente lo snapshot dello stato del cluster, quindi una zona un'interruzione del servizio potrebbe causare la perdita dei dati elaborati. Dataproc non i dati utente all'interno del servizio. Gli utenti possono configurare le pipeline scrivere risultati in molti datastore; dovresti considerare l'architettura un datastore e scegliere un prodotto che offra la resilienza alle emergenze necessaria.

Se una zona subisce un'interruzione, puoi scegliere di ricreare una nuova istanza in un'altra zona, selezionando una zona diversa o utilizzando il menu Funzione di posizionamento in Dataproc per selezionare automaticamente un modello zona di destinazione. Una volta che il cluster è disponibile, l'elaborazione dei dati può riprendere. Puoi anche un cluster con la modalità ad alta disponibilità abilitata, riducendo la probabilità un'interruzione parziale della zona influirà su un nodo master e, di conseguenza, sull'intero cluster.

Cluster Dataproc su GKE

Cluster Dataproc su GKE a livello di zona o di regione.

Per ulteriori informazioni sull'architettura e sulle funzionalità di RE cluster GKE a livello di zona e di regione, consulta sezione Google Kubernetes Engine più avanti in questo documento.

Datastream

Datastream è una tecnologia CDC (Change Data Capture) e di replica serverless che consente di sincronizzare i dati in modo affidabile e con latenza minima. Datastream fornisce la replica dei dati da database operativi BigQuery e Cloud Storage. Inoltre, offre funzionalità semplificate l'integrazione con i modelli Dataflow per creare flussi di lavoro personalizzati caricare i dati in un'ampia gamma di destinazioni, come Cloud SQL Spanner.

Interruzione a livello di zona: Datastream è un servizio multi-zona. Può resistere un'interruzione completa e non pianificata a livello di zona senza alcuna perdita di dati o disponibilità. Se si verifica un errore a livello di zona, puoi comunque accedere alle tue risorse e gestirle in Datastream.

Interruzione a livello di regione: in caso di interruzione a livello di regione, Datastream torna disponibile non appena l'interruzione viene risolta.

Document AI

Document AI è una piattaforma di comprensione dei documenti che prende i dati non strutturati documenti e li trasforma in dati strutturati, semplificando comprendere, analizzare e utilizzare. Document AI è un servizio di Google Cloud. I clienti possono scegliere la regione, ma non le zone al suo interno. I dati e il traffico vengono automaticamente bilanciati del carico tra le zone all'interno di una regione. I server vengono scalati automaticamente per soddisfare il traffico in entrata e bilanciati il carico tra zone diverse, se necessario. Ogni zona mantiene uno scheduler che fornisce e la scalabilità automatica per zona. Lo scheduler è inoltre consapevole del carico che le altre zone ricezione ed esegue il provisioning di capacità aggiuntiva nella zona per consentire qualsiasi errore a livello di zona.

Interruzione a livello di zona: Document AI archivia i documenti utente e il processore i dati della versione. Questi dati vengono archiviati a livello di regione e scritti in modo sincrono. Dal giorno i dati sono archiviati a livello di regione, le operazioni del piano dati non sono interessate errori. Il traffico viene instradato automaticamente ad altre zone nel caso di un traffico in un errore, con un ritardo basato sul tempo necessario per i servizi dipendenti, come Vertex AI, per recuperare.

Interruzione a livello di regione: i dati non vengono mai replicati tra regioni. Nel corso di una regione un'interruzione del servizio, Document AI non eseguirà il failover. I clienti scelgono Regione Google Cloud in cui vuole utilizzare Document AI. Tuttavia, il traffico dei clienti non viene mai instradato a un'altra regione.

Verifica degli endpoint

La verifica degli endpoint consente agli amministratori e ai professionisti delle operazioni di sicurezza di creare un inventario dei dispositivi che accedono ai dati di un'organizzazione. La verifica degli endpoint offre inoltre un'affidabilità critica dei dispositivi e servizi controllo dell'accesso come parte della soluzione Chrome Enterprise Premium.

Utilizza Verifica endpoint per avere una panoramica del livello di sicurezza dei tuoi laptop e computer desktop di un'organizzazione. Con la verifica degli endpoint è abbinata alle offerte Chrome Enterprise Premium, la verifica degli endpoint aiuta ad applicare un controllo granulare degli accessi alle risorse Google Cloud.

La verifica degli endpoint è disponibile per Google Cloud, Cloud Identity Google Workspace Business e Google Workspace Enterprise.

Eventarc

Eventarc fornisce eventi distribuiti in modo asincrono da Google provider (proprietari), app utente (di terze parti) e Software as a Service (di terze parti) che utilizza servizi a basso accoppiamento che reagiscono ai cambiamenti di stato. it consente ai clienti di configurare le destinazioni (ad esempio, un'istanza Cloud Run o una funzione Cloud Function (2ª generazione.) viene attivato quando si verifica un evento in un servizio del fornitore di eventi o nella le API nel tuo codice.

Interruzione a livello di zona: Eventarc archivia i metadati relativi ai trigger. Questi dati vengono archiviati a livello di regione e scritti in modo sincrono. L'API Eventarc che crea e gestisce trigger e canali restituisce la chiamata API solo quando i dati sono stati impegnati per raggiungere il quorum all'interno di una regione. Poiché i dati sono a livello di regione, le operazioni del piano dati non sono interessate da errori a livello di zona. Nel in caso di errore a livello di zona, il traffico viene automaticamente instradato ad altre zone. Servizi Eventarc per la ricezione e l'erogazione di servizi e gli eventi di terze parti vengono replicati nelle zone. Questi servizi operano a livello regionale distribuiti in tempo reale. Le richieste alle zone non disponibili vengono fornite automaticamente disponibili nella regione.

Interruzione a livello di regione:i clienti scelgono la regione Google Cloud in cui che vuole creare i propri trigger Eventarc. I dati non vengono mai replicati tra regioni. Il traffico dei clienti non viene mai instradato da Eventarc in una regione diversa. Nel caso di un progetto un errore, Eventarc torna disponibile non appena viene interrotta sia stato risolto. Per ottenere una disponibilità maggiore, i clienti sono incoraggiati a eseguire il deployment si attiva in più regioni, se necessario.

Tieni presente quanto segue:

• Servizi Eventarc per la ricezione e l'erogazione di servizi proprietari vengono forniti secondo il criterio del "best effort" e non sono coperti da RTO/RPO.
• Distribuzione di eventi Eventarc per i servizi Google Kubernetes Engine sono fornite secondo il criterio del "best effort" e non sono coperte da RTO/RPO.

Filestore

I livelli Basic e HighScale sono risorse a livello di zona. Non tollerano della zona o della regione di cui è stato eseguito il deployment.

Le istanze Filestore di livello Enterprise sono risorse a livello di regione. Filestore adotta i criteri di coerenza rigorosa richiesti da NFS. Quando un client scrive dati, Filestore non restituisce conferma fino a quando la modifica non viene persistente e replicata in due zone, le letture successive restituiscono i dati corretti.

In caso di errore di una zona, un'istanza di livello Enterprise continua a gestire i dati di altre zone e nel frattempo accetta nuove scritture. Sia i sistemi di lettura operazioni di scrittura potrebbero avere prestazioni ridotte; l'operazione di scrittura non essere replicati. La crittografia non è compromessa perché la chiave verrà gestita da altre zone.

Consigliamo ai client di creare backup esterni in caso di ulteriori interruzioni in nella stessa regione. Il backup può essere utilizzato per ripristinare l'istanza ad altre regioni.

Firestore

Firestore è un database flessibile e scalabile per dispositivi mobili, web e server da Firebase e Google Cloud. Offerte Firestore replica automatica dei dati multiregione, garanzie di elevata coerenza, operazioni batch e transazioni ACID.

Firestore offre località a singola regione e a più regioni ai clienti. Il traffico viene automaticamente bilanciato del carico tra le zone di una regione.

Le istanze Firestore a livello di regione replicano in modo sincrono i dati almeno tre zone. In caso di errore a livello di zona, le scritture possono comunque il commit delle due (o più) repliche rimanenti e i dati di cui è stato eseguito il commit persistenti. Il traffico viene instradato automaticamente ad altre zone. Una località regionale offre costi inferiori, minore latenza di scrittura e colocation con altri servizi Google Cloud Google Cloud.

Le istanze Firestore in più regioni replicano in modo sincrono i dati in cinque zone in tre regioni (due regioni di servizio e una regione di testimonianza), e sono resistenti agli errori di zona e di regione. In caso di configurazione a livello di zona o di regione un errore, i dati di cui è stato eseguito il commit vengono mantenuti. Il traffico viene instradato automaticamente alla gestione in zone/regioni e i commit vengono comunque gestiti da almeno tre zone le due regioni rimanenti. Le regioni multiple massimizzano la disponibilità la durabilità dei database.

Firewall Insights

Firewall Insights ti aiuta a comprendere e ottimizzare le tue regole firewall. Fornisce insight, suggerimenti e metriche su come le regole firewall sono in uso. Firewall Insights usa anche il machine learning per prevedere l'utilizzo futuro delle regole firewall. Firewall Insights ti consente di migliorare durante l'ottimizzazione delle regole firewall. Ad esempio: Firewall Insights identifica le regole che classifica come eccessivamente permissiva. Puoi utilizzare queste informazioni per rendere più restrittiva la configurazione del firewall.

Interruzione a livello di zona: poiché i dati di Firewall Insights vengono replicati su zone, non subisce interruzioni a livello di zona e il traffico dei clienti instradato automaticamente ad altre zone.

Interruzione a livello di regione: poiché i dati di Firewall Insights vengono replicati su regioni non subisce interruzioni a livello di regione e il traffico dei clienti vengono indirizzati automaticamente ad altre regioni.

Parco risorse

I parchi risorse consentono ai clienti di gestire Kubernetes come gruppo e consentono agli amministratori di piattaforma utilizza servizi multi-cluster. Ad esempio, i parchi risorse consentono agli amministratori di applicare in modo uniforme su tutti i cluster o configurare Ingress multi-cluster.

Quando registri un cluster GKE in un parco risorse, per impostazione predefinita un cluster presenta un'appartenenza a livello di regione nella stessa regione. Quando ti registri da un cluster non Google Cloud a un parco risorse, puoi scegliere qualsiasi regione o globale. La best practice consiste nello scegliere una regione vicina al la località fisica del cluster. Ciò fornisce una latenza ottimale quando si utilizza Connetti gateway per accedere al cluster.

In caso di interruzione a livello di zona, le funzionalità del parco risorse non sono interessate, a meno che il cluster sottostante è a livello di zona e non è disponibile.

In caso di interruzione a livello di regione, le funzionalità del parco risorse non funzionano in modo statico per il di appartenenza alla regione. La mitigazione di un'interruzione a livello di regione richiede il deployment in più regioni, come suggerito Architettura del ripristino di emergenza per le interruzioni dell'infrastruttura cloud.

Google Cloud Armor

Google Cloud Armor ti aiuta a proteggere i tuoi deployment e le tue applicazioni da diversi tipi di minacce, tra cui: attacchi DDoS volumetrici e attacchi alle applicazioni come cross-site scripting (XSS) e SQL injection. Google Cloud Armor filtra il traffico indesiderato su Google Cloud bilanciatori del carico e impedisce che questo traffico entri nel tuo VPC e consumi Google Cloud. Alcune di queste protezioni sono automatiche. Alcune richiedono configurare criteri di sicurezza e collegarli a servizi di backend o regioni. I criteri di sicurezza di Google Cloud Armor con ambito globale vengono applicati a livello globale bilanciatori del carico. I criteri di sicurezza con ambito regionale vengono applicati a livello di regione bilanciatori del carico.

Interruzione a livello di zona: in caso di interruzione a livello di zona, i bilanciatori del carico Google Cloud reindirizzare il traffico ad altre zone in cui le istanze di backend integre disponibili. La protezione di Google Cloud Armor è disponibile subito dopo il del traffico, perché i criteri di sicurezza di Google Cloud Armor replicata in modo sincrono in tutte le zone di una regione.

Interruzione a livello di regione: in caso di interruzioni a livello di regione, carico globale di Google Cloud i bilanciatori reindirizzano il traffico ad altre regioni in cui il backend è integro di Compute Engine. La protezione di Google Cloud Armor è disponibile subito dopo il failover del traffico poiché la piattaforma Google Cloud Armor i criteri di sicurezza vengono replicati in modo sincrono in tutte le regioni. Per essere resiliente in caso di errori a livello di regione, devi configurare Google Cloud Armor a livello di regione di sicurezza per tutte le regioni.

Google Kubernetes Engine

Google Kubernetes Engine (GKE) offre il servizio Kubernetes gestito semplificare il deployment di applicazioni containerizzate su Google Cloud. Tu puoi scegliere tra topologie di cluster a livello di regione o di zona.

• Durante la creazione di un cluster di zona, GKE esegue il provisioning di un controllo macchina piana nella zona scelta, nonché le macchine worker (nodi) all'interno nella stessa zona.
• Per i cluster regionali, GKE esegue il provisioning di tre piani di controllo in tre diverse zone all'interno della regione scelta. Per impostazione predefinita, nodi sono distribuiti in tre zone, sebbene tu possa scegliere di creare a livello di regione con nodi di cui è stato eseguito il provisioning solo in una zona.
• I cluster multi-zona sono simili ai cluster di zona in quanto includono una macchina master, ma offre anche la possibilità di abbracciare i nodi in più zone.

Interruzione a livello di zona: per evitare interruzioni a livello di zona, utilizza i cluster a livello di regione. Il gruppo di controllo e i nodi sono distribuiti in tre zone diverse all'interno di un regione. Un'interruzione della zona non influisce sul piano di controllo e sui nodi worker di cui è stato eseguito il deployment in nelle altre due zone.

Interruzione a livello di regione: la mitigazione di un'interruzione a livello di regione richiede il deployment in tutta in più regioni. Sebbene al momento non sia offerto come prodotto integrato la topologia multiregionale è un approccio adottato da ai clienti GKE e possono essere implementati manualmente. Puoi creare più cluster a livello di regione per replicare i carichi di lavoro regioni e controllare il traffico verso questi cluster Ingress multi-cluster.

VPN ad alta disponibilità

La VPN ad alta disponibilità (alta disponibilità) è un'offerta Cloud VPN resiliente che cripta in modo sicuro il traffico dal cloud privato on-premise, da Virtual private cloud o un'altra rete di provider di servizi cloud alla tua rete Cloud Virtual Private Cloud (VPC).

I gateway della VPN ad alta disponibilità hanno due interfacce, ciascuna con un indirizzo IP da pool di indirizzi IP separati, suddivisi in modo logico e fisico tra diversi PoP e cluster, per garantire una ridondanza ottimale.

Interruzione di zona: in caso di interruzione a livello di zona, un'interfaccia potrebbe perdere ma il traffico viene reindirizzato all'altra interfaccia tramite di routing tramite BGP (Border Gateway Protocol).

Interruzione a livello di regione: in caso di interruzione a livello di regione, entrambe le interfacce potrebbero perdere la connettività per un breve periodo.

Identity and Access Management

Identity and Access Management (IAM) è responsabile di tutte le decisioni di autorizzazione per azioni sulle risorse cloud. IAM conferma che un criterio concede per ogni azione (nel piano dati) ed elabora gli aggiornamenti di questi criteri tramite una chiamata SetPolicy (nel piano di controllo).

Tutti i criteri IAM vengono replicati in più zone all'interno di in ogni regione, aiutando le operazioni del piano dati IAM a recuperare gli errori di altre regioni e tollerante agli errori di zona all'interno di ogni regione. La resilienza del piano dati IAM contro errori di zona e di regione consente architetture multiregionali e multizona per un'alta disponibilità.

Le operazioni del piano di controllo IAM possono dipendere da più regioni la replica dei dati. Quando le chiamate a SetPolicy hanno esito positivo, i dati vengono scritti in in più regioni, ma la propagazione in altre regioni è alla fine coerente. Il piano di controllo IAM è resiliente agli errori a livello di una singola regione.

Identity-Aware Proxy

Identity-Aware Proxy consente di accedere alle applicazioni ospitate su Google Cloud, tra cloud e on-premise. Gli IAP sono distribuiti a livello regionale le richieste a zone non disponibili vengono automaticamente fornite da altre zone della regione.

Le interruzioni regionali in IAP influiscono sull'accesso alle applicazioni in hosting nella regione interessata. Ti consigliamo di eseguire il deployment in più regioni e utilizzare Cloud Load Balancing per ottenere disponibilità e resilienza maggiori a fronte di interruzioni regionali.

Identity Platform

Identity Platform consente ai clienti di aggiungere alle proprie app la gestione personalizzabile di identità e accessi di livello Google. Identity Platform è un'offerta globale. I clienti non possono scegliere le regioni o le zone in cui sono archiviati i loro dati.

Interruzione di zona: durante un'interruzione a livello di zona, Identity Platform esegue il failover delle richieste alla cella più vicina successiva. Tutti i dati vengono salvati su scala globale, quindi non c'è perdita di dati.

Interruzione a livello di regione:durante un'interruzione a livello di regione, le richieste di Identity Platform alla regione non disponibile non vanno a buon fine, mentre Identity Platform rimuove il traffico dalla regione interessata. Quando il traffico verso la regione interessata è esaurito, un servizio di bilanciamento del carico del server globale instrada le richieste alla regione integro più vicino disponibile. Tutti i dati vengono salvati a livello globale, quindi non c'è perdita di dati.

Knative serving

Knative serving è un servizio globale che consente ai clienti di eseguire carichi di lavoro serverless su cluster dei clienti. Il suo scopo è garantire che Il deployment dei carichi di lavoro di Knative serving viene eseguito correttamente sui cluster dei clienti e che lo stato di installazione di Knative serving si rifletta nella risorsa di funzionalità dell'API GKE Fleet. Questo servizio è disponibile solo in caso di installazione o upgrade Risorse Knative serving sui cluster dei clienti. Non è coinvolto nell'esecuzione dei carichi di lavoro dei cluster. Cluster di clienti appartenenti a progetti con Knative serving vengono distribuite tra le repliche in più regioni e zone: è monitorato da una replica.

Interruzione a livello di zona e di regione: cluster monitorati da repliche che sono state ospitati in una località in cui si è verificata un'interruzione, vengono ridistribuiti automaticamente tra repliche integre in altre zone e regioni. Mentre questa riassegnazione è in corso, potrebbe trascorrere un po' di tempo quando non vengono monitorati da Knative serving. Se durante questo periodo l'utente decide di abilitare Knative serving sul cluster, l'installazione di Knative serving le risorse sul cluster inizieranno dopo la riconnessione del cluster di una replica di servizio Knative serving integro.

Looker (Google Cloud core)

Looker (Google Cloud core) è una piattaforma di business intelligence che fornisce provisioning, configurazione e gestione semplificati e semplificati di un'istanza di Looker dalla console Google Cloud. Looker (Google Cloud core) consente agli utenti di esplorare i dati, creare dashboard, configurare avvisi e condividere report. Inoltre, Looker (Google Cloud core) offre un IDE per i creatori di modelli di dati e funzionalità avanzate di incorporamento e API per gli sviluppatori.

Looker (Google Cloud core) è composto da istanze isolate a livello di regione che di replicare in modo sincrono i dati tra le zone all'interno della regione. Assicurati che le risorse utilizzate dall'istanza, ad esempio le origini dati Looker (Google Cloud core) si connette, si trova nella stessa regione in cui in cui viene eseguita l'istanza.

Interruzione a livello di zona:le istanze di Looker (Google Cloud core) archiviano i metadati e i propri di cui è stato eseguito il deployment. I dati sono scritti in modo sincrono tra di Compute Engine. In un'interruzione a livello di zona, le istanze di Looker (Google Cloud core) continuano per la pubblicazione da altre zone disponibili nella stessa regione. Qualsiasi transazione o Le chiamate API vengono restituite dopo il commit dei dati che è stato raggiunto il quorum in un regione. Se la replica non riesce, il commit della transazione non viene eseguito e l'utente viene avvisato dell'errore. Se si verifica un errore in più zone, anche le transazioni non vanno a buon fine e l'utente viene avvisato. Looker (Google Cloud core) interrompe le pianificazioni o le query attualmente in esecuzione. Devi riprogrammarle o accodarle di nuovo una volta risolto l'errore.

Interruzione a livello di regione: istanze di Looker (Google Cloud core) all'interno delle aree interessate regione non sono disponibili. Looker (Google Cloud core) interrompe qualsiasi pianificazione o query attualmente in esecuzione. Devi riprogrammare o mettere in coda dopo aver risolto l'errore. Puoi creare manualmente nuovi in una regione diversa. Puoi anche ripristinare le istanze utilizzando il processo definito in Importa o esporta i dati da un'istanza di Looker (Google Cloud core). Ti consigliamo di configurare un processo di esportazione dei dati periodico per copiare le risorse in anticipo, nell'improbabile caso di interruzione del servizio a livello di regione.

Looker Studio

Looker Studio è una soluzione di visualizzazione dei dati e business intelligence prodotto. Consente ai clienti di connettersi ai propri dati archiviati in altri sistemi, creare report e dashboard utilizzando questi dati e condividere i report e all'interno dell'organizzazione. Looker Studio è una piattaforma globale e non consente agli utenti di selezionare un ambito delle risorse.

In caso di interruzione a livello di zona, Looker Studio continua a pubblicare richieste da un'altra zona nella stessa regione o in una regione diversa senza un'interruzione del servizio. Gli asset utente vengono replicati in modo sincrono tra le regioni. Pertanto, non si verificano perdite di dati.

In caso di interruzione regionale, Looker Studio continua a pubblicare richieste da un'altra regione senza interruzioni. Gli asset utente sono in modo sincrono replicati tra regioni. Pertanto, non si verificano perdite di dati.

Memorystore for Memcached

Memorystore for Memcached è l'offerta Memcached gestita di Google Cloud. Memorystore for Memcached consente ai clienti di creare cluster Memcached utilizzati come database di coppie chiave-valore e ad alta velocità effettiva per le applicazioni.

I cluster Memcached sono a livello di regione, con nodi distribuiti in in zone specificate dal cliente. Tuttavia, Memcached non replica alcun dato nodi. Pertanto, un errore a livello di zona può causare la perdita di dati, come descritto anche uno svuotamento parziale della cache. Le istanze Memcached continueranno a funzionare, il numero di nodi sarà inferiore, il servizio non avvierà nessun nuovo nodo durante un errore a livello di zona. I nodi Memcached nelle zone non interessate continueranno a essere gestire il traffico, anche se l'errore a livello di zona si tradurrà in una percentuale di successo della cache inferiore fino al recupero della zona.

In caso di errore a livello di regione, i nodi Memcached non gestiscono il traffico. Nel in quel caso i dati andranno persi e, di conseguenza, la cache verrà svuotata completamente. Per mitigare un a livello di regione, puoi implementare un'architettura che esegue il deployment dell'applicazione e Memorystore for Memcached in più regioni.

Memorystore for Redis

Memorystore for Redis è un servizio Redis completamente gestito per Google Cloud che possono ridurre il carico di lavoro necessario per la gestione di deployment Redis complessi. Al momento offre 2 livelli: livello base e standard. Per il livello base, a livello di zona o di regione l'interruzione causerà la perdita di dati, anche nota come svuotamento completo della cache. Per standard A livello di regione, un'interruzione regionale causerà la perdita di dati. Un'interruzione a livello di zona potrebbe causare perdita di dati parziale sull'istanza di livello Standard dovuta alla replica asincrona.

Importante: affinché la replica sia prevedibile, assicurati che Utilizzo CPU e Rapporto di utilizzo della memoria di sistema rimangono entro i valori consigliati.

Interruzione a livello di zona: le istanze del livello Standard replicano in modo asincrono il set di dati operazioni dal set di dati nel nodo primario al nodo di replica. Quando che si verifica quando un'interruzione del servizio si verifica nella zona del nodo primario, il nodo promosso in nodo primario. Durante la promozione, si verifica un failover e il client Redis deve riconnettersi all'istanza. Dopo la riconnessione, e riprendere le operazioni. Per ulteriori informazioni sull'alta disponibilità Istanze di Memorystore for Redis nel livello Standard, consulta Alta disponibilità di Memorystore for Redis

Se attivi repliche di lettura nell'istanza del livello Standard e hai una sola replica, l'endpoint di lettura non è disponibile per la durata di un'interruzione a livello di zona. Per ulteriori informazioni il ripristino di emergenza delle repliche di lettura, Modalità di errore per le repliche di lettura.

Interruzione a livello di regione: Memorystore for Redis è un prodotto regionale, quindi una singola un'istanza non può tollerare un errore a livello di regione. Puoi programmare e attività periodiche per esportare un'istanza Redis in un bucket Cloud Storage in un'altra regione. Quando si verifica un'interruzione a livello di regione, puoi ripristinare il database Redis in una regione diversa dal set di dati che hai esportato.

Rilevamento servizi multi-cluster e Ingress multi-cluster

I servizi multi-cluster GKE sono costituiti da più servizi componenti. I componenti includono l'hub Google Kubernetes Engine (che orchestra più cluster Google Kubernetes Engine mediante le appartenenze), i cluster stessi, e i controller dell'hub GKE (Ingress multi-cluster, rilevamento dei servizi multi-cluster). I controller hub orchestrano la configurazione del bilanciatore del carico di Compute Engine utilizzando backend su più cluster.

In caso di interruzione a livello di zona, Multi-Cluster Service Discovery continua a gestire le richieste da in un'altra zona o regione. In caso di interruzione a livello di regione, Multi-Cluster Service Discovery non esegue il failover.

In caso di interruzione di Ingress multi-cluster a livello di zona, se il cluster di configurazione è a livello di zona e, nell'ambito dell'errore, l'utente deve eseguire manualmente il failover. I dati è statico e continuerà a gestire il traffico finché l'utente non avrà non riuscito. Per evitare il failover manuale, usa un cluster a livello di regione il cluster di configurazione.

In caso di interruzione a livello di regione, Ingress multi-cluster non esegue il failover. Gli utenti devono disporre di un piano di RE per il failover manuale del cluster di configurazione. Per ulteriori informazioni, vedi Configurazione di Ingress multi-cluster e Configurazione di servizi multi-cluster.

Per ulteriori informazioni su GKE, consulta "Google Kubernetes Engine" in Architettura del ripristino di emergenza per le interruzioni dell'infrastruttura cloud.

Network Analyzer

Network Analyzer monitora automaticamente le configurazioni di rete VPC rileva errori di configurazione e configurazioni non ottimali. Fornisce approfondimenti di rete, regole firewall, route, dipendenze di configurazione e la connettività a servizi e applicazioni. Identifica gli errori di rete, fornisce informazioni sulla causa principale e suggerisce possibili risoluzioni.

Network Analyzer è in esecuzione continua e attiva le analisi pertinenti in base a della configurazione quasi in tempo reale nella tua rete. Se Network Analyzer rileva un errore di rete, cerca di correlarlo con modifiche alla configurazione per identificare le cause principali. Ove possibile, fornisce consigli per suggerire dettagli su come risolvere i problemi.

Network Analyzer è uno strumento di diagnostica senza componenti del piano dati. Non elabora né genera traffico di utenti.

Interruzione a livello di zona: il servizio Network Analyzer viene replicato a livello globale e i suoi e la disponibilità non è influenzata da un'interruzione del servizio a livello di zona.

Se gli insight di Network Analyzer contengono configurazioni di un che subisce un'interruzione, influisce sulla qualità dei dati. Le statistiche sulla rete le configurazioni in quella zona diventano obsolete. Non fare affidamento su nessuna gli insight forniti da Network Analyzer durante le interruzioni.

Interruzione a livello di regione: il servizio Network Analyzer viene replicato a livello globale e i suoi e la disponibilità non è influenzata da un'interruzione regionale.

Se gli insight di Network Analyzer contengono configurazioni di un che subisce un'interruzione, influisce sulla qualità dei dati. Le statistiche sulla rete le configurazioni in quella regione diventano obsolete. Non fare affidamento su nessuna gli insight forniti da Network Analyzer durante le interruzioni.

Network Topology

Network Topology è uno strumento di visualizzazione che mostra la topologia dell'infrastruttura di rete. La visualizzazione Infrastruttura mostra le reti Virtual Private Cloud (VPC), la connettività ibrida da e verso le reti on-premise, la connettività ai servizi gestiti da Google e le metriche associate.

Interruzione a livello di zona: in caso di interruzione a livello di zona, i relativi dati non verranno visualizzati in Network Topology. I dati relativi alle altre zone non sono interessati.

Interruzione a livello di regione: in caso di interruzione a livello di regione, i dati per quella regione non verranno mostrati in Network Topology. I dati relativi ad altre regioni non sono interessati.

Performance Dashboard

Performance Dashboard ti offre visibilità sulle prestazioni dell'intera rete Google Cloud e delle risorse del tuo progetto.

Con queste funzionalità di monitoraggio delle prestazioni, puoi distinguere un problema nella tua applicazione da uno nella rete Google Cloud sottostante. Puoi anche analizzare i problemi storici di prestazioni della rete. Performance Dashboard esporta anche i dati in Cloud Monitoring. Puoi utilizzare Monitoring per eseguire query sui dati e ottenere l'accesso a informazioni aggiuntive.

Interruzione a livello di zona:

In caso di interruzione a livello di zona, i dati relativi a latenza e perdita di pacchetti relativi al traffico proveniente dalla zona interessata non verranno visualizzati in Performance Dashboard. I dati sulla latenza e sulla perdita di pacchetti per il traffico proveniente da altre zone non sono interessati. Al termine dell'interruzione, i dati di latenza e perdita di pacchetti riprenderanno.

Interruzione a livello di regione:

In caso di interruzione a livello di regione, i dati relativi a latenza e perdita di pacchetti relativi al traffico dalla regione interessata non verranno visualizzati in Performance Dashboard. I dati sulla latenza e sulla perdita di pacchetti per il traffico proveniente da altre regioni non sono interessati. Al termine dell'interruzione, i dati di latenza e perdita di pacchetti riprenderanno.

Network Connectivity Center

Network Connectivity Center è un prodotto per la gestione della connettività di rete che utilizza una hub e spoke. Con questa architettura, una gestione centralizzata una risorsa che funge da hub e ogni risorsa di connettività funge da spoke. Attualmente gli spoke ibridi supportano VPN ad alta disponibilità, Dedicated e Partner Interconnect, e router SD-WAN dei principali fornitori di terze parti. Con gli spoke ibridi di Network Connectivity Center, le aziende possono connettere carichi di lavoro Google Cloud e ai data center on-premise, ad altri cloud e alle relative filiali grazie alla portata globale della rete Google Cloud.

Interruzione a livello di zona: uno spoke ibrido di Network Connectivity Center con alta disponibilità è resiliente agli errori a livello di zona, poiché il piano di controllo sono ridondanti in più zone all'interno di una regione.

Interruzione a livello di regione: uno spoke ibrido di Network Connectivity Center è una risorsa di regione, quindi e non è in grado di resistere a un errore a livello di regione.

Network Service Tiers

Network Service Tiers ti consente di ottimizzare la connettività tra i sistemi su internet e delle tue istanze Google Cloud. Offre due livelli di servizio distintiPremium e il livello Standard. Con il livello Premium, un anycast annunciato a livello globale L'indirizzo IP del livello Premium può fungere da frontend sia per l'area geografica che per quella globale di backend. Con il livello Standard, un IP di livello Standard annunciato a livello regionale di destinazione può fungere da frontend per i backend regionali. La resilienza complessiva di un'applicazione è influenzato sia dal livello di servizio di rete che ridondanza dei backend a cui è associato.

Interruzione a livello di zona: sia il livello Premium che il livello Standard offrono resilienza a livello di zona quando sono associati a backend ridondanti a livello di regione. Quando a livello di zona, il comportamento di failover per i casi che usano sono determinati dai backend associati stessi. Se associato con backend di zona, il servizio sarà di nuovo disponibile non appena sia stata risolta.

Interruzione a livello di regione: il livello Premium offre resilienza contro le interruzioni regionali quando è associato a backend ridondanti a livello globale. Nel livello Standard, tutto il traffico verso la regione interessata avrà esito negativo. Il traffico verso tutte le altre regioni è non interessate. Quando si verifica un'interruzione a livello di regione, il comportamento di failover per i casi il livello Premium con backend ridondanti a livello globale è determinato ai backend associati. Quando utilizzi il livello Premium con le opzioni regionali o al livello Standard, il servizio sarà di nuovo disponibile quando l'interruzione viene risolta.

Mirroring pacchetto

Mirroring pacchetto clona il traffico delle istanze specificate nella rete Virtual Private Cloud (VPC) e inoltra i dati clonati alle istanze dietro un bilanciatore del carico interno a livello di regione per l'analisi. Mirroring pacchetto acquisisce tutto il traffico e i dati dei pacchetti, inclusi payload e intestazioni.

Per ulteriori informazioni sulla funzionalità del servizio Mirroring pacchetto, consulta la pagina di riepilogo del servizio Mirroring pacchetto.

Interruzione a livello di zona: configura il bilanciatore del carico interno in modo che ci siano istanze in più zone. Se si verifica un'interruzione a livello di zona, il mirroring pacchetto devia i pacchetti clonati a una zona integro.

Interruzione a livello di regione: il mirroring pacchetto è un prodotto a livello di regione. In caso di interruzione a livello di regione, i pacchetti nella regione interessata non vengono clonati.

Persistent Disk

I dischi permanenti sono disponibili in configurazioni a livello di zona e di regione.

I dischi permanenti a livello di zona sono ospitati in un'unica zona. Se la zona del disco è non disponibile, il Persistent Disk non sarà disponibile finché l'interruzione non risolto.

I dischi permanenti a livello di regione offrono la replica sincrona dei dati tra in una regione. In caso di interruzione nella zona della tua macchina virtuale, può forzare il collegamento di un Persistent Disk a livello di regione a un'istanza VM in una zona secondaria. Per eseguire questa attività, devi avviare un'altra istanza VM in quella zona o mantenere un'istanza VM hot standby in quella zona.

Per replicare in modo asincrono i dati in un Persistent Disk regioni, puoi utilizzare Replica asincrona del disco permanente (replica PD asincrona), che offre una replica di archiviazione a blocchi con RTO e RPO ridotto per tra regioni attiva/passiva. Nell'improbabile caso di interruzione del servizio a livello di regione, La replica asincrona PD consente di eseguire il failover dei dati in una regione secondaria riavvia il carico di lavoro in quella regione.

Personalized Service Health

Personalized Service Health comunica le interruzioni dei servizi pertinenti ai tuoi progetti Google Cloud. Fornisce diversi canali e processi per visualizzare o integrare eventi di disturbo (incidenti, manutenzione pianificata) nel processo di risposta agli incidenti, tra cui:

• Una dashboard nella console Google Cloud
• Un'API di servizio
• Avvisi configurabili
• Log generati e inviati a Cloud Logging

Interruzione a livello di zona: i dati vengono forniti da un database globale senza alcuna dipendenza da località specifiche. Se si verifica un'interruzione a livello di zona, Service Health è in grado di gestire le richieste e reindirizzare automaticamente il traffico a zone della stessa regione ancora funzionanti. Service Health può restituire correttamente chiamate API se è in grado di recuperare i dati sugli eventi dal database Service Health.

Interruzione a livello di regione:i dati vengono forniti da un database globale senza alcuna dipendenza da località specifiche. In caso di interruzione a livello di regione, Service Health è comunque in grado di gestire le richieste, ma potrebbe operare con una capacità ridotta. Gli errori regionali nelle località di Logging potrebbero influire sugli utenti di Service Health che utilizzano i log o le notifiche di avviso su cloud.

Private Service Connect

Private Service Connect è una funzionalità di Google Cloud che consente ai consumatori di accedere privatamente ai servizi gestiti dall'interno la propria rete VPC. Analogamente, consente ai producer di servizi gestiti per ospitare questi servizi nelle proprie reti VPC separate offrono una connessione privata ai loro consumatori.

Endpoint Private Service Connect per i servizi pubblicati

Un endpoint Private Service Connect si connette ai servizi nel servizio della rete VPC dei producer utilizzando una regola di forwarding Private Service Connect. Il producer di servizi fornisce un servizio utilizzando la connettività privata a un servizio mediante l'esposizione di un singolo collegamento a un servizio. Quindi il consumer di servizi sarà in grado di assegnare un indirizzo IP virtuale dal proprio VPC per questo servizio.

Interruzione a livello di zona: traffico di Private Service Connect che proviene dal traffico delle VM generato dagli endpoint client VPC consumer possono comunque accedere ai servizi gestiti esposti sul producer di servizi rete VPC interna. Questo accesso è possibile perché Esegui il failover del traffico di Private Service Connect allo stato più integro in una zona diversa.

Interruzione a livello di regione: Private Service Connect è un servizio a livello di regione prodotto. Non è resiliente alle interruzioni regionali. Servizi gestiti multiregionali può ottenere una disponibilità elevata durante le interruzioni a livello di regione configurando Endpoint Private Service Connect in più regioni.

Endpoint Private Service Connect per le API di Google

Un endpoint Private Service Connect si connette alle API di Google utilizzando una regola di forwarding di Private Service Connect. Questa regola di forwarding consente i clienti utilizzano nomi personalizzati degli endpoint con i loro indirizzi IP interni.

Interruzione a livello di zona: traffico di Private Service Connect proveniente dal consumer Gli endpoint client VPC possono comunque accedere alle API di Google perché la connettività il failover automatico della VM e dell'endpoint verrà eseguito in un'altra zona funzionale nella stessa regione. Richieste già in corso quando inizia un'interruzione dipenderà dal protocollo TCP del client un comportamento di timeout e di nuovi tentativi per il recupero.

Consulta Compute Engine ripristino per ulteriori dettagli.

Interruzione a livello di regione: Private Service Connect è un servizio a livello di regione prodotto. Non è resiliente alle interruzioni regionali. Servizi gestiti multiregionali può ottenere una disponibilità elevata durante le interruzioni a livello di regione configurando Endpoint Private Service Connect in più regioni.

Per ulteriori informazioni su Private Service Connect, consulta la sezione "Endpoint" in Tipi di Private Service Connect.

Pub/Sub

Pub/Sub è un servizio di messaggistica per l'integrazione delle applicazioni e dei flussi di dati Analytics. Gli argomenti Pub/Sub sono globali, ovvero sono visibili accessibile da qualsiasi località Google Cloud. Tuttavia, ogni singolo messaggio viene archiviato in una singola regione Google Cloud, il più vicino all'editore e consentito criterio di località delle risorse. Di conseguenza, un argomento può avere messaggi archiviati in regioni in Google Cloud. Pub/Sub criteri di archiviazione dei messaggi può limitare le regioni in cui sono archiviati i messaggi.

Interruzione a livello di zona: quando un messaggio Pub/Sub viene pubblicato, vengono scritti in modo sincrono nell'archiviazione in almeno due zone all'interno della regione. Pertanto, se una singola zona non è più disponibile, non impatto.

Interruzione a livello di regione: durante un'interruzione di una regione, i messaggi archiviati all'interno dell'area interessata regione non è accessibile. i publisher e gli abbonati che si collegano la regione interessata, tramite un endpoint a livello di regione o di endpoint globale, riuscire a connettersi. I publisher e gli abbonati che si connettono ad altre regioni possono continuano a connettersi e i messaggi disponibili in altre regioni vengono recapitati gli abbonati più vicini alla rete con capacità.

Se la tua applicazione si basa sull'ordinamento dei messaggi, esamina il consigli dettagliati del team Pub/Sub. Le garanzie di ordinamento dei messaggi forniti in base alla regione e possono subire interruzioni se utilizzi un endpoint.

reCAPTCHA

reCAPTCHA è un servizio globale che rileva attività fraudolente, spam e abusi. Non richiede né consente la configurazione per regioni o zone resilienza. Gli aggiornamenti ai metadati di configurazione vengono replicati in modo asincrono in ogni regione in cui viene eseguito reCAPTCHA.

In caso di interruzione a livello di zona, reCAPTCHA continua a gestire le richieste. da un'altra zona nella stessa regione o in una regione diversa senza interruzioni.

In caso di interruzione a livello di regione, reCAPTCHA continua a gestire le richieste da un'altra regione senza interruzioni.

Secret Manager

Secret Manager è un prodotto di gestione di secret e credenziali per in Google Cloud. Con Secret Manager, puoi facilmente eseguire controlli limitare l'accesso ai secret, criptare i secret at-rest e garantire che la sicurezza delle informazioni in Google Cloud.

In genere, le risorse di Secret Manager vengono create con criterio di replica automatica (consigliato), che ne fa sì che vengano replicati a livello globale. Se la tua organizzazione ha criteri che non consentono replica dei dati secret, le risorse di Secret Manager possono creati con criteri di replica gestiti dall'utente, in cui una o più regioni sono per la replica di un secret.

Interruzione a livello di zona: in caso di interruzione a livello di zona, Secret Manager continua a gestire le richieste da un'altra zona nella stessa regione o in una regione diversa senza interruzioni. All'interno di ogni regione, Secret Manager mantiene almeno 2 repliche in zone separate (nella maggior parte delle regioni, 3 repliche). Una volta risolta l'interruzione della zona, viene ripristinata la ridondanza completa.

Interruzione a livello di regione: nel caso di un'interruzione a livello di regione, Secret Manager continua a gestire le richieste da un'altra regione senza interruzioni, supponendo che i dati siano stati replicati in più di una regione (tramite la replica automatica o gestita dall'utente replica in più di una regione). Quando l'interruzione della regione viene risolta, viene ripristinata la ridondanza completa.

Security Command Center

Security Command Center è la piattaforma globale e in tempo reale di gestione dei rischi per Google Cloud. Consiste di due componenti principali: rilevatori e risultati.

I rilevatori sono interessati da interruzioni sia a livello di regione che di zona, in modi diversi. Durante un'interruzione a livello di regione, i rilevatori non possono generare nuovi risultati per perché quelle che dovrebbero analizzare non sono disponibili.

Durante un'interruzione a livello di zona, i rilevatori possono richiedere diversi minuti o ore per riprendere il normale funzionamento. Security Command Center non perderà i dati dei risultati. Inoltre, non genererà nuovi dati sui risultati per le risorse non disponibili. Nel peggiore dei casi dello scenario di richiesta, gli agenti di Container Threat Detection potrebbero esaurire lo spazio del buffer durante la connessione a una cellula sana, il che potrebbe comportare la perdita di rilevamenti.

I risultati sono resilienti alle interruzioni regionali e a livello di zona replicati in modo sincrono tra le regioni.

Sensitive Data Protection (compresa l'API DLP)

Sensitive Data Protection offre classificazione dei dati sensibili, servizi di profilazione, anonimizzazione, tokenizzazione e analisi del rischio relativo alla privacy. Funziona in modo sincrono con i dati inviati nel corpo delle richieste. in modo asincrono sui dati già presenti nei sistemi di spazio di archiviazione sul cloud. Sensitive Data Protection può essere richiamato tramite gli endpoint globali o specifici per regione.

Endpoint globale: il servizio è progettato per essere resiliente sia a livello di regione a livello di zona e di errore. Se il servizio è sovraccarico durante un errore, i dati inviati a hybridInspect del servizio potrebbe andare perso.

Per creare un'architettura a prova di errore, includi la logica per esaminare risultato recente di pre-errore generato dal metodo hybridInspect. Nel in caso di interruzione, i dati inviati al metodo potrebbero andare persi, ma rispetto agli ultimi 10 minuti". prima dell'evento di errore. Se ci sono più recenti di 10 minuti prima dell'inizio dell'interruzione, che i dati non sono andati persi. In tal caso, non è necessario riprodurre nuovamente i dati che si trovano prima del timestamp del risultato, anche se sono all'interno Intervallo di 10 minuti.

Endpoint a livello di regione:gli endpoint a livello di regione non sono resilienti a livello di regione errori. Se è necessaria la resilienza rispetto a un errore a livello di regione, considera l'errore in altre regioni. Le caratteristiche di errore a livello di zona sono le stesse di cui sopra.

Utilizzo dei servizi

L'API Service Usage è un servizio di infrastruttura di Google Cloud che ti consente per elencare e gestire le API e i servizi nei progetti Google Cloud. Puoi elencare e gestire API e servizi forniti da Google, Google Cloud e produttori di terze parti. L'API Service Usage è un servizio globale resiliente sia a livello di zona che di regione o in caso di interruzione del servizio. In caso di interruzione a livello di zona o di regione, l'API Service Usage continua a gestire le richieste da un'altra zona in diverse regioni.

Per ulteriori informazioni su Service Usage, consulta Documentazione sull'utilizzo del servizio.

Speech-to-Text

Speech-to-Text consente di convertire l'audio della voce in testo utilizzando tecniche di machine learning come i modelli di rete neurale. L'audio viene inviato in tempo reale dal microfono di un'applicazione oppure elaborato come batch di file audio.

Interruzione a livello di zona:

• API Speech-to-Text v1: durante un'interruzione a livello di zona, la versione 1 dell'API Speech-to-Text continua a gestire le richieste da un'altra zona nella stessa regione senza interruzioni. Tuttavia, tutti i job attualmente in esecuzione all'interno della zona con errori andranno persi. Gli utenti devono riprovare a eseguire i job non riusciti, che verranno instradati automaticamente a una zona disponibile.

• API Speech-to-Text v2: durante un'interruzione a livello di zona, la versione 2 dell'API Speech-to-Text continua a gestire le richieste da un'altra zona nella stessa regione. Tuttavia, tutti i job attualmente in esecuzione all'interno della zona con errori andranno persi. Gli utenti devono riprovare a eseguire i job non riusciti, che verranno instradati automaticamente a una zona disponibile. L'API Speech-to-Text restituisce la chiamata API solo dopo che è stato eseguito il commit dei dati per un quorum all'interno di una regione. In alcune regioni, gli acceleratori AI (TPU) sono disponibili solo in una zona. In questo caso, un'interruzione del servizio in quella zona impedisce il riconoscimento vocale, ma non perde i dati.

Interruzione a livello di regione:

• API Speech-to-Text v1: la versione 1 dell'API Speech-to-Text non è interessata dall'errore regionale perché si tratta di un servizio globale multiregionale. Il servizio continua a gestire le richieste da un'altra regione senza interruzioni. Tuttavia, i job attualmente in esecuzione all'interno della regione con errori andranno persi. Gli utenti devono riprovare a questi job non riusciti, che verranno instradati automaticamente a una regione disponibile.

• API Speech-to-Text v2:

  • L'API Speech-to-Text in più regioni versione 2, il servizio continua a gestire senza interruzioni le richieste da un'altra zona nella stessa regione.

  • API Speech-to-Text versione 2 a regione singola, il servizio limita l'esecuzione del job alla regione richiesta. La versione 2 dell'API Speech-to-Text non instrada il traffico a una regione diversa e i dati non vengono replicati in un'altra regione. Durante un errore a livello di regione, la versione 2 dell'API Speech-to-Text non è disponibile nella regione. Tuttavia, tornerà disponibile una volta risolta l'interruzione.

Storage Transfer Service

Storage Transfer Service gestisce i trasferimenti di dati da varie origini cloud a Cloud Storage, nonché da, verso e tra file system.

L'API Storage Transfer Service è una risorsa globale.

Storage Transfer Service dipende dalla disponibilità dell'origine e della destinazione un trasferimento. Se un'origine o una destinazione di trasferimento non è disponibile, i trasferimenti si interrompono fare progressi. Tuttavia, i dati principali dei clienti o i dati dei job non andranno persi. Trasferimenti riprenderanno quando l'origine e la destinazione saranno di nuovo disponibili.

Puoi utilizzare Storage Transfer Service con o senza un agente, come segue:

• I trasferimenti senza agente utilizzano worker regionali per orchestrare i job di trasferimento.

• I trasferimenti basati su agenti utilizzano gli agenti software installati della tua infrastruttura. I trasferimenti basati sugli agenti si basano sulla disponibilità di gli agenti di trasferimento e sulla loro capacità di connettersi file system in-app. Quando decidi dove installare gli agenti di trasferimento, considera la disponibilità del file system. Ad esempio, se stai eseguendo il trasferimento su più VM di Compute Engine per trasferire i dati Un'istanza Filestore di livello Enterprise (una risorsa di regione), valuta la possibilità di posizionare le VM in zone diverse all'interno Regione dell'istanza Filestore.

  Se gli agenti non sono più disponibili o se la loro connessione al file system è interrotta, l'avanzamento dei trasferimenti viene interrotto ma i dati non vengono persi. Se tutte vengono terminati, il job di trasferimento viene messo in pausa fino a quando e gli agenti vengono aggiunti al pool di agenti del trasferimento.

Durante un'interruzione, il comportamento di Storage Transfer Service è il seguente:

• Interruzione a livello di zona: durante un'interruzione a livello di zona, le API Storage Transfer Service rimangono disponibili e potrai continuare a creare job di trasferimento. Dati continua il trasferimento.

• Interruzione a livello di regione: durante un'interruzione a livello di regione, Storage Transfer Service Le API rimangono disponibili e puoi continuare a creare job di trasferimento. Se i worker del trasferimento si trovano nella regione interessata, Data Transfer si interrompe finché la regione non diventa di nuovo disponibile e il trasferimento automaticamente.

Vertex ML Metadata

Vertex ML Metadata consente di registrare i metadati e gli artefatti prodotti il tuo sistema ML ed eseguire query su questi metadati per aiutare ad analizzare, eseguire il debug e le prestazioni del tuo sistema ML o degli artefatti che produce.

Interruzione a livello di zona: nella configurazione predefinita, Vertex ML Metadata offre per evitare guasti a livello di zona. Il deployment del servizio è stato eseguito in più zone in ogni regione, con i dati replicati in modo sincrono tra zone diverse all'interno di ogni regione. In caso di errore a livello di zona, le zone rimanenti prendono il controllo con interruzioni minime.

Interruzione a livello di regione: Vertex ML Metadata è un servizio regionalizzato. Nella di un'interruzione del servizio a livello di regione, Vertex ML Metadata non eseguirà il failover in un'altra regione.

Previsione batch di Vertex AI

La previsione batch consente agli utenti di eseguire previsioni batch su AI/ML modelli sull'infrastruttura di Google. La previsione batch è un regionale. I clienti possono scegliere la regione in cui eseguono i job, ma e non le zone specifiche all'interno di quella regione. La previsione batch bilancia automaticamente il carico del job tra diverse zone all'interno regione scelta.

Interruzione a livello di zona: la previsione batch archivia i metadati per per i job di previsione batch all'interno di una regione. I dati vengono scritti in modo sincrono, in più zone all'interno di quella regione. In un'interruzione a livello di zona, la previsione batch perde parzialmente i worker che eseguono lavori, ma li riaggiunge automaticamente le altre zone disponibili. Se più tentativi di previsione batch non vanno a buon fine, La UI elenca lo stato del job come non riuscito nella UI e nelle richieste di chiamata API. Le successive richieste dell'utente per eseguire il job vengono instradate alle zone disponibili.

Interruzione a livello di regione: i clienti scelgono la regione Google Cloud in cui per eseguire i job di previsione batch. I dati non vengono mai replicati regioni. La previsione batch limita l'esecuzione del job agli regione richiesta e non instrada mai richieste di previsione a una regione diversa. Quando si verifica un errore a livello di regione, la previsione batch non è disponibile in quella regione. Sarà di nuovo disponibile quando l'interruzione verrà risolta. Consigliamo ai clienti di utilizzare più regioni per eseguire i propri job. Nel in caso di interruzione del servizio a livello di regione, indirizza i job a un'altra regione disponibile.

Vertex AI Model Registry

Vertex AI Model Registry consente agli utenti di semplificare il modello gestione, governance e deployment dei modelli ML in un repository centrale. Vertex AI Model Registry è un'offerta regionale con disponibilità elevata offre protezione contro le interruzioni a livello di zona.

Interruzione a livello di zona: Vertex AI Model Registry offre protezione contro le interruzioni a livello di zona. Il deployment del servizio viene eseguito in tre zone in ogni regione, con i dati replicati in modo sincrono tra zone diverse all'interno della regione. In caso di errore di una zona, le zone rimanenti impiegheranno senza perdita di dati e minima interruzione del servizio.

Interruzione regionale: Vertex AI Model Registry è un servizio regionalizzato. In caso di errore di una regione, Model Registry fare il failover.

Previsione online di Vertex AI

La previsione online consente agli utenti di eseguire il deployment di modelli AI/ML su Google Cloud. La previsione online è un'offerta regionale. I clienti possono scegliere la regione in cui eseguire il deployment dei modelli, ma non le zone specifiche all'interno della regione. Il servizio di previsione bilancia automaticamente il carico di lavoro tra diverse zone all'interno della regione selezionata.

Interruzione a livello di zona: la previsione online non memorizza i contenuti dei clienti. Un'interruzione a livello di zona porta all'errore dell'esecuzione della richiesta di previsione attuale. La previsione online può riprovare automaticamente a eseguire la richiesta, a seconda del tipo di endpoint utilizzato. In particolare, un endpoint pubblico riproverà automaticamente, mentre l'endpoint privato no. Per gestire gli errori e migliorare la resilienza, incorpora nel codice una logica di ripetizione con una back off esponenziale.

Interruzione a livello di regione:i clienti scelgono la regione Google Cloud in cui vogliono eseguire i propri modelli di AI/ML e i propri servizi di previsione online. I dati non vengono mai replicati tra regioni. La previsione online limita l'esecuzione del modello AI/ML alla regione richiesta e non instrada mai le richieste di previsione a una regione diversa. Quando si verifica un errore a livello di regione, il servizio di previsione online non è disponibile nella regione in questione. Sarà di nuovo disponibile una volta risolta l'interruzione. Consigliamo ai clienti di utilizzare più regioni per eseguire i propri modelli IA/ML. In caso di interruzione a livello di regione, indirizza il traffico a un'altra regione disponibile.

Vertex AI Pipelines

Vertex AI Pipelines è un servizio Vertex AI che ti consente di automatizzare, monitorare e gestire i flussi di lavoro di machine learning (ML) in modo serverless. Vertex AI Pipelines è progettato per fornire disponibilità elevata e offre per evitare errori a livello di zona.

Interruzione a livello di zona: nella configurazione predefinita, Vertex AI Pipelines offre per evitare guasti a livello di zona. Il deployment del servizio è stato eseguito in più zone in ogni regione, con i dati replicati in modo sincrono tra zone diverse all'interno della regione. In caso di errore a livello di zona, le zone rimanenti prendono il controllo con interruzioni minime.

Interruzione regionale: Vertex AI Pipelines è un servizio regionalizzato. Nella in caso di interruzione del servizio a livello di regione, non verrà eseguito il failover di Vertex AI Pipelines in un'altra regione. Se si verifica un'interruzione regionale, ti consigliamo di eseguire in una regione di backup.

Vertex AI Search

Vertex AI Search è una soluzione di ricerca personalizzabile con IA generativa e conformità aziendale nativa. Il deployment di Vertex AI Search viene eseguito e replicato automaticamente in più regioni all'interno di Google Cloud. Puoi configurare dove si trovano i dati Archiviati scegliendo una località multiregionale supportata, ad esempio globale, USA o UE.

Interruzione a livello di zona e di regione: UserEvents caricato su Vertex AI Search potrebbe non essere recuperabile a causa della il ritardo di replica. Altri dati e servizi forniti da Vertex AI Search resta disponibile grazie di failover e sincrona per la replica dei dati.

Vertex AI Training

Vertex AI Training offre agli utenti la possibilità di eseguire job di addestramento personalizzato sull'infrastruttura di Google. Vertex AI Training è una piattaforma dell'addestramento, i clienti possono scegliere la regione in cui eseguire il di lavoro. Tuttavia, i clienti non possono scegliere le zone specifiche all'interno di quella regione. La di addestramento può bilanciare automaticamente il carico in varie zone all'interno della regione.

Interruzione a livello di zona: Vertex AI Training archivia i metadati per l'istanza un lavoro di addestramento lungo. Questi dati vengono archiviati a livello di regione e scritti in modo sincrono. La La chiamata API Vertex AI Training restituisce solo una volta che questi metadati sono stati impegnate a raggiungere il quorum in una regione. Il job di addestramento può essere eseguito in una zona di destinazione. Un'interruzione a livello di zona porta all'errore dell'esecuzione attuale del job. In tal caso, il servizio riprova automaticamente a eseguire il job instradandolo a un'altra zona. Se più tentativi non riusciti, lo stato del job viene aggiornato a non riuscito. Le successive richieste dell'utente a che eseguono il job vengono indirizzate a una zona disponibile.

Interruzione a livello di regione: i clienti scelgono la regione Google Cloud che vogliono dei job di addestramento. I dati non vengono mai replicati tra regioni. Vertex AI Training limita l'esecuzione del job alla regione richiesta e non instrada mai i job di addestramento a una regione diversa. Nel caso di un progetto errore, il servizio Vertex AI Training non è disponibile in quella regione e diventa di nuovo disponibile una volta risolta l'interruzione. È consigliabile i clienti utilizzano più regioni per eseguire i propri job e, nel caso di una un'interruzione del servizio, per indirizzare i job a una diversa regione disponibile.

Virtual Private Cloud (VPC)

Il VPC è un servizio globale che fornisce connettività di rete (ad esempio le VM). Gli errori, tuttavia, sono a livello di zona. In caso di errore a livello di zona, le risorse in quella zona non sono disponibili. Analogamente, se una regione non riesce, viene interessato solo il traffico da e verso la regione in errore. La connettività delle regioni sane non è interessato.

Interruzione a livello di zona: se una rete VPC copre più zone e un un errore nella zona, la rete VPC sarà comunque integra diverse. Il traffico di rete tra le risorse nelle zone integre continuerà a funzionare normalmente durante l'errore. Un errore a livello di zona influisce solo sul traffico di rete verso da risorse nella zona in errore. Per mitigare l'impatto degli errori a livello di zona, è consigliabile non creare tutte le risorse in una singola zona. Invece, quando per creare le risorse e distribuirle nelle zone.

Interruzione a livello di regione: se una rete VPC copre più regioni e si verifica un errore in una regione, la rete VPC sarà comunque integra regioni. Il traffico di rete tra le risorse nelle regioni integrali continuerà a funzionano normalmente durante l'errore. Un errore regionale interessa solo la rete del traffico da e verso le risorse nella regione in errore. Per mitigare l’impatto a livello di regione, ti consigliamo di distribuire le risorse su regioni.

Controlli di servizio VPC

Controlli di servizio VPC è un servizio a livello di regione. Utilizzando i Controlli di servizio VPC, i team di sicurezza possono definire controlli perimetrali granulari e applicare strategia di sicurezza per numerosi servizi e progetti Google Cloud. I criteri dei clienti vengono applicati a livello regionale.

Interruzione a livello di zona: i Controlli di servizio VPC continuano a gestire le richieste da un'altra zona nella stessa regione senza interruzioni.

Interruzione a livello di regione: API configurate per l'applicazione dei criteri dei Controlli di servizio VPC nella regione interessata non saranno disponibili finché la regione non tornerà disponibile. Consigliamo ai clienti di eseguire il deployment di servizi applicati dei Controlli di servizio VPC in più regioni, se si desidera una maggiore disponibilità.

Flussi di lavoro

Workflows è un prodotto di orchestrazione che consente a Google Cloud clienti:

• il deployment e l'esecuzione di flussi di lavoro che collegano altri servizi esistenti utilizzando HTTP
• automatizzano i processi, tra cui l'attesa delle risposte HTTP con per un massimo di un anno
• di implementare processi in tempo reale con esecuzioni a bassa latenza basate su eventi.

Un cliente Workflows può eseguire il deployment di flussi di lavoro che descrivono l'azienda logica che desiderano eseguire, quindi eseguire i flussi di lavoro direttamente con l'API o con trigger basati su eventi (attualmente limitati a Pub/Sub o Eventarc). Il flusso di lavoro in esecuzione può manipolare le variabili, rendere HTTP chiama e archivia i risultati oppure definisci i callback e attende che venga ripreso un altro servizio.

Interruzione a livello di zona: il codice sorgente di Workflows non è influenzato dall'ambiente di zona o in caso di interruzione del servizio. Workflows archivia il codice sorgente dei flussi di lavoro, con i valori delle variabili e le risposte HTTP ricevute dai flussi di lavoro in esecuzione. Il codice sorgente viene archiviato a livello di regione e scritto in modo sincrono: l'API plane restituisce solo una volta raggiunto il quorum dei metadati una regione. Anche le variabili e i risultati HTTP vengono archiviati a livello di regione e scritti in modo sincrono, almeno ogni cinque secondi.

In caso di errore di una zona, i flussi di lavoro vengono ripresi automaticamente in base all'ultima e i dati di Google Cloud. Tuttavia, le richieste HTTP che non hanno già ricevuto risposte nuovo tentativo automaticamente. Utilizza i criteri relativi ai nuovi tentativi per le richieste con affidabilità ha riprovato come descritto documentazione.

Interruzione a livello di regione: Workflows è un servizio regionalizzato. nel caso di un'interruzione regionale, Workflows non eseguirà il failover. I clienti sono incoraggiato a eseguire il deployment di Workflows in più regioni se superiore la disponibilità del servizio.

Cloud Service Mesh

Cloud Service Mesh ti consente di configurare un mesh di servizi gestito che comprende più cluster GKE. Questa documentazione riguarda solo Cloud Service Mesh gestito, la variante nel cluster è self-hosted e le linee guida della piattaforma.

Interruzione di zona: configurazione mesh, poiché viene archiviata nella Cluster GKE è resiliente alle interruzioni a livello di zona, purché a livello di regione. I dati utilizzati dal prodotto per la tenuta contabile interna sono a livello di regione o globale e non è interessata dal fatto che una singola zona fuori servizio. Il piano di controllo viene eseguito nella stessa regione del per il cluster GKE che supporta (per i cluster di zona che contiene la regione) e non è interessato da interruzioni all'interno di una singola zona.

Interruzione a livello di regione: Cloud Service Mesh fornisce servizi a GKE a livello di regione o zona. In caso di interruzione a livello di regione, Cloud Service Mesh non eseguirà il failover. Neanche GKE. I clienti sono incoraggiati a implementare mesh che costituiscono di cluster GKE che coprono diverse regioni.

Service Directory

Service Directory è una piattaforma per il rilevamento, la pubblicazione e di connessione dei servizi. Fornisce informazioni in tempo reale, in un unico posto, su per tutti i tuoi servizi. Service Directory consente di eseguire la gestione dell'inventario su larga scala, sia che tu abbia pochi endpoint di servizio migliaia.

Le risorse di Service Directory vengono create a livello di regione, in base al parametro di località specificato dall'utente.

Interruzione a livello di zona: durante un'interruzione a livello di zona, Service Directory continua a gestire le richieste da un'altra zona nella stessa regione o in una regione diversa senza interruzioni. All'interno di ogni regione, Service Directory gestisce più repliche. Una volta risolta l'interruzione a livello di zona, viene ripristinata la ridondanza completa.

Interruzione a livello di regione: Service Directory non è resiliente alle interruzioni a livello di regione.