Questo documento introduce le strategie di ripristino di emergenza (RE) per Microsoft SQL Server per gli architetti e i responsabili tecnici responsabili della progettazione e dell'implementazione del ripristino di emergenza su Google Cloud.
I database potrebbero non essere più disponibili per vari motivi, ad esempio guasti hardware o di rete. Per fornire accesso continuo al database durante gli errori, viene gestito un database secondario che è una replica di un database principale. Avere il database secondario in una località diversa aumenta le probabilità che sia disponibile quando il database principale non è più disponibile.
Se il database principale non è più disponibile, l'app mission critical si connette a un database secondario, continuando dallo stato dei dati coerente noto più di recente per fornire servizi agli utenti con tempi di inattività minimi o nulli.
Il processo per rendere disponibile un database secondario in caso di errore del database principale è chiamato ripristino di emergenza (RE) del database. Il database secondario esegue il ripristino dall'indisponibilità del database principale. Idealmente, il database secondario ha esattamente lo stesso stato coerente del database principale quando non è disponibile o se manca solo un set minimo di transazioni recenti del database primario.
Il ripristino di emergenza del database è una funzionalità essenziale per i clienti aziendali. Il fattore principale è la continuità aziendale per le app mission critical. Ad esempio, un'app mission-critical genera entrate (e-commerce), fornisce servizi continuativi e affidabili (gestione dei voli o dei gruppi propulsori) o supporta funzionalità salvavita (monitoraggio dei pazienti). In tutti questi esempi, è della massima importanza che l'app sia sempre disponibile perché è considerata mission critical.
La maggior parte dei sistemi di gestione dei database offre funzionalità di ripristino di emergenza, tra cui Microsoft SQL Server. Questo documento sull'architettura illustra come le funzionalità di RE fornite da SQL Server vengono implementate nel contesto di Google Cloud.
Terminologia
Le sezioni seguenti illustrano i termini utilizzati nel documento.
Architettura generale di RE
Il seguente diagramma illustra la topologia generale dell'architettura di ripristino di emergenza.
Nel diagramma precedente, un'app accede a un database principale mentre un database secondario è in attesa e rispecchia lo stato del database principale. I client accedono all'app eseguita su Google Cloud.
Se il database principale non è più disponibile, gli amministratori del database o il team operativo devono decidere di avviare il processo di ripristino di emergenza. Se viene avviato il ripristino di emergenza del database, l'app viene ricollegata al database secondario. Una volta collegata, l'app può servire di nuovo i suoi client. In una situazione ideale, l'app è disponibile nel database secondario il prima possibile, quindi i client potrebbero non riscontrare nemmeno un'interruzione. Un'alternativa è attendere che il database principale diventi di nuovo accessibile, anziché avviare il ripristino di emergenza. Ad esempio, se il disastro è intermittente, potrebbe essere più rapido risolvere il problema anziché un problema.
Database primari e secondari
Una o più app possono accedere a un database principale per fornire servizi di persistenza per la gestione dello stato dell'app. Un database secondario è correlato a un database principale e contiene una replica del database principale. Idealmente, il contenuto del database secondario corrisponde esattamente al contenuto del database principale in qualsiasi momento. In molti casi, il database secondario è in ritardo rispetto al database principale a causa dei ritardi nell'applicazione delle modifiche transazionali apportate al database principale. A seconda della tecnologia del database, è possibile associare più di un database secondario a un database primario. SQL Server supporta l'associazione di più di un database secondario a un database principale.
Ripristino di emergenza
Se un database principale non è più disponibile, RE modifica il ruolo del database secondario per diventare il database principale. Se è presente più di un database secondario, uno di questi viene selezionato manualmente o in base a un elenco di failover preferito. Le app devono riconnettersi al nuovo database principale per continuare ad accedere al loro stato. Se il nuovo database principale non era sincronizzato con l'ultimo stato noto del precedente database principale, l'app inizia da uno stato passato (chiamato anche flashback).
È importante avere almeno un database secondario sempre per ogni database primario. Dopo un ripristino di emergenza, assicurati che sia configurato un nuovo database secondario per gestire scenari di ripristino di emergenza futuri.
Failover, passaggio e fallback
Esistono diversi scenari per la modifica del ruolo tra database principali e secondari:
- Failover: il processo di modifica del ruolo di un database secondario in modo che diventi il nuovo database principale e di connessione di tutte le app al database principale. Il failover è involontario perché viene attivato dall'indisponibilità di un database principale. Puoi configurare il failover in modo che venga attivato automaticamente o manualmente.
- Passaggio: al contrario del failover, il passaggio da un database primario a un database secondario (nuovo database principale) viene attivato intenzionalmente per il test iniziale e la manutenzione pianificata. Testa il tuo sistema di RE con una commutazione periodica regolare per garantire l'affidabilità continua del ripristino di emergenza.
- Di riserva: il fallback comporta l'inversione del processo in cui il nuovo database principale diventa il database secondario, dopo la riparazione del database principale. Un fallback viene attivato intenzionalmente per ristabilire lo stato prima dell'inizio del failover o del passaggio. Non è strettamente necessario, ma può essere fatto in base ai requisiti di ripristino di emergenza, come la località o le risorse disponibili.
Zone e regioni Google Cloud
Le risorse come i database si trovano in zone e regioni di Google Cloud, dove ogni zona appartiene a una regione. Una zona è un dominio single point of failure. Consigliamo di eseguire il deployment di una risorsa a disponibilità elevata e a tolleranza di errore in più zone all'interno di una regione.
Per evitare l'interruzione di un'intera regione, stabilisci strategie multiregionali per il ripristino di emergenza. Ad esempio, il database principale si trova in un'area geografica e il database secondario corrispondente si trova in un'altra.
Modalità attive: attivo-passivo e attivo-attivo
Un database principale è un database aperto per operazioni di lettura e scrittura (operazioni DML) in modo che le app che vi accedono possano gestire il proprio stato. Il database primario è chiamato database attivo. Il database secondario corrispondente è passivo perché replica il database principale, ma non è disponibile per nessuna app per le operazioni di modifica dello stato. Dopo un failover o un passaggio, il database secondario diventa il nuovo database principale e diventa un database attivo.
Il database primario e quello secondario possono essere entrambi database attivi, se la tecnologia di database supporta questa funzionalità, chiamata modalità attivo-attivo. In questo caso, le app possono connettersi tra loro perché entrambi i database sono disponibili per la gestione dello stato. Il ripristino di emergenza in modalità attivo-attivo non richiede un failover se solo uno dei database attivi diventa non disponibile. Se un database attivo non è disponibile, l'altro database attivo continuerà a esserlo. La modalità Active-active non rientra nell'ambito di questo articolo perché SQL Server non la supporta.
Modalità standby: caldo, caldo, freddo e nessuna modalità standby
Affinché il database principale sia attivo, deve essere in esecuzione e in grado di eseguire istruzioni DML. Il database secondario non deve essere in esecuzione, ma può essere arrestato. Se non è in esecuzione, il tempo necessario per il ripristino da un'emergenza aumenta perché il nuovo database principale deve essere portato in stato di esecuzione prima di assumere il ruolo del nuovo database principale.
Esistono diverse variazioni nella configurazione del database secondario:
- Hot standby: il database secondario è in esecuzione e pronto per essere connesso dai client. L'ultima modifica disponibile dal database principale viene sempre applicata non appena diventa disponibile.
- Warm standby: un database secondario è attivo e in esecuzione, ma non tutte le modifiche provenienti dal database principale sono state necessariamente ancora applicate.
- Cold standby: non è in esecuzione nessun database secondario. Per prima cosa, deve essere avviato e poi sincronizzato con l'ultimo stato disponibile.
- Nessun standby: il software del database deve essere installato e successivamente avviato per poter applicare tutte le modifiche del database principale. Questa è la modalità meno costosa perché non consuma risorse quando non è necessario, ma rispetto alle altre modalità impiega più tempo per diventare un nuovo database primario.
Strategie di RE
Nelle sezioni seguenti vengono spiegate le strategie di RE supportate da Microsoft SQL Server.
Dimensioni della strategia di recupero
Ci sono diverse dimensioni chiave da considerare quando selezioni o implementi una strategia di ripristino di emergenza del database. Ogni dimensione ha uno spettro e il comportamento e le aspettative della strategia di ripristino di emergenza dipendono dalla selezione dei punti dello spettro. Le dimensioni principali sono le seguenti:
- RPO (Recovery Point Objective): il periodo di tempo massimo accettabile durante il quale potrebbero essere persi dati dalla tua app a causa di un incidente grave. Questa dimensione varia in base alle modalità di utilizzo dei dati. L'RPO può essere espresso in termini di durata (secondi, minuti o ore) dal momento dell'indisponibilità del database principale oppure può essere espresso come stati di elaborazione identificabili (ultimo backup completo o ultimo backup incrementale). Indipendentemente da come l'RPO sia specificato, la strategia di ripristino di emergenza deve implementare la misura specifica in modo da soddisfare il requisito dell'RPO. Il caso più impegnativo è l'ultima transazione impegnata, il che significa che non deve verificarsi alcuna perdita dal database principale al database secondario.
- RTO (Recovery Time Objective). Il periodo di tempo massimo accettabile durante il quale la tua app può essere offline. Questo valore è in genere specificato nell'ambito di un accordo sul livello del servizio più ampio. L'RTO di solito viene espresso in termini di durata dal momento in cui il database principale non è disponibile; ad esempio, l'app deve essere completamente operativa entro 5 minuti. Il caso più impegnativo è immediato, in modo che gli utenti delle app non si accorgano che è stato eseguito il ripristino di emergenza.
- Dominio Single point of failure. Spetta a te decidere se un'area geografica è considerata un singolo dominio point of failure per i tuoi requisiti di ripristino di emergenza. Se una regione è un singolo dominio point of failure, è necessario configurare il ripristino di emergenza in modo che la configurazione effettiva coinvolga due o più regioni. In caso di errore nella regione contenente il database principale, il database secondario in un'altra regione corrisponde al nuovo database principale. Se si presume che il dominio single point of failure sia una zona, il ripristino di emergenza può essere configurato per più zone all'interno di una singola area geografica. Se si verifica un errore in una zona, il ripristino di emergenza utilizza una seconda zona e rende disponibile al suo interno il nuovo database principale.
La scelta di queste dimensioni chiave sta nel prendere una decisione tra costo e qualità. Più bassi sono l'RTO e l'RPO, più costosa può diventare la soluzione di ripristino di emergenza man mano che vengono utilizzate più risorse attive. Nelle sezioni seguenti vengono descritte diverse strategie di RE alternative che rappresentano i punti sulle dimensioni nel contesto del database Microsoft SQL Server.
Strategie di RE per SQL Server
Continuità aziendale e ripristino del database - SQL Server descrive le funzionalità di disponibilità che puoi utilizzare per implementare strategie di ripristino di emergenza.
Preliminari
SQL Server viene eseguito sia su Windows che su Linux. Tuttavia, non tutte le funzionalità di disponibilità sono disponibili su Linux. SQL Server offre diverse versioni, ma non tutte le funzionalità di disponibilità sono disponibili in ogni versione.
SQL Server distingue le istanze dai database. Un'istanza è il software SQL Server in esecuzione, mentre un database è l'insieme di dati gestito da un'istanza SQL Server.
Gruppi di disponibilità sempre attivi
I gruppi di disponibilità sempre attiva forniscono una protezione a livello di database. Un gruppo di disponibilità ha due o più repliche. Una replica è quella principale con accesso in lettura e scrittura, mentre le repliche rimanenti sono repliche secondarie che possono fornire accesso in lettura. Ogni replica del database è gestita da un'istanza SQL Server autonoma. Un gruppo di disponibilità può contenere uno o più database. Il numero di database che possono essere inclusi in un gruppo di disponibilità e il numero di repliche secondarie supportate dipende dalla versione di SQL Server. Tutti i database di un gruppo di disponibilità vengono sottoposti alle stesse modifiche del ciclo di vita contemporaneamente. I gruppi di disponibilità implementano la modalità attivo-passivo perché solo il database principale supporta l'accesso in scrittura.
Quando si verifica un failover, una replica secondaria diventa la nuova replica primaria. Poiché un gruppo di disponibilità include istanze autonome di SQL Server, tutte le operazioni acquisite nei log delle transazioni sono disponibili nelle repliche. Eventuali modifiche non acquisite in un log delle transazioni devono essere sincronizzate manualmente, ad esempio gli accessi a livello di istanza SQL Server o i job di SQL Server Agent. Per fornire una protezione a livello di database e una protezione delle istanze SQL Server, devi configurare le istanze del cluster di failover (FCI). Questa architettura di deployment viene discussa più avanti nella sezione Istanza cluster di failover sempre attiva.
Puoi impedire le modifiche ai ruoli delle app utilizzando un listener. Un listener supporta le app che si connettono al gruppo di disponibilità. Le app non sanno quali istanze SQL Server gestiscono il database principale o le repliche secondarie in qualsiasi momento. I listener richiedono che i client utilizzino almeno la versione .NET 3.5 con un aggiornamento o 4.0 e versioni successive, come descritto in Continuità aziendale e ripristino del database - SQL Server.
I gruppi di disponibilità si basano sui livelli di astrazione sottostanti per fornire la loro funzionalità. I gruppi di disponibilità vengono eseguiti in un cluster di failover di Windows Server (WSFC) come descritto in Cluster di failover di Windows Server con SQL Server. Tutti i nodi che eseguono istanze SQL Server devono far parte della stessa WSFC.
Le transazioni vengono inviate dal database principale a tutte le repliche secondarie. Esistono due modalità di invio per inviare le transazioni: sincrona e asincrona. Puoi configurare in modo indipendente ogni replica in modo che utilizzi l'una o l'altra modalità. Nella modalità di invio sincrona, la transazione sul database principale ha esito positivo solo se ha esito positivo in tutte le repliche secondarie collegate in modo sincrono. In modalità asincrona, la transazione sul database principale può avere esito positivo anche se non a tutte le repliche secondarie è stata applicata la transazione.
La scelta della modalità di invio influenza l'RTO, l'RPO e la modalità standby possibili. Ad esempio, se le transazioni vengono inviate a tutte le repliche in modalità sincrona, tutte le repliche si trovano nello stesso esatto stato. L'RPO (transazione più recente) più impegnativo viene completato poiché tutte le repliche sono completamente sincronizzate. Le repliche secondarie sono hot standby, quindi possono essere utilizzate immediatamente come database primario.
Il failover può essere automatico o manuale. Un failover automatico è possibile se tutte le repliche sono completamente sincronizzate. Nell'esempio precedente ciò è possibile poiché tutte le repliche sono sempre completamente sincronizzate.
La figura seguente mostra un gruppo di disponibilità Sempre attivo in una singola regione.
Il gruppo di disponibilità è rappresentato da un rettangolo che comprende le zone. Questo è a solo scopo illustrativo per indicare che tutti i database appartengono allo stesso gruppo di disponibilità. Il gruppo di disponibilità non è una risorsa cloud e, come tale, non è implementato in un nodo o in qualsiasi altro tipo di risorsa.
Istanza cluster di failover sempre attiva
Per evitare errori dei nodi, puoi utilizzare istanze di cluster di failover (FCI) anziché istanze SQL Server autonome. Esistono due o più nodi che eseguono istanze SQL Server per gestire un database (primario o secondario). I nodi che gestiscono un database formano un cluster di failover. Un nodo nel cluster sta eseguendo attivamente un'istanza SQL Server, mentre gli altri nodi non stanno eseguendo istanze SQL Server. In caso di errore del nodo che esegue l'istanza SQL Server, un altro nodo nel cluster avvia un'istanza SQL Server, prendendo il controllo della gestione del database (Failover del nodo). Questo processo di avvio automatico di un'istanza SQL Server fornisce funzionalità ad alta disponibilità.
Il cluster FCI appare come singola unità e i client che accedono al cluster non vedono il failover tra i nodi, tranne forse per un breve periodo di indisponibilità. Quando si verifica un failover del nodo, non si verifica alcuna perdita di dati. Tutto ciò in esecuzione all'interno dell'istanza SQL Server non riuscita viene spostato in un'altra istanza SQL Server nello stesso cluster. Ad esempio, i job di SQL Server Agent o i server collegati vengono spostati in un'altra istanza.
I nodi dei cluster FCI possono essere configurati in zone Google Cloud diverse. Questa architettura non offre solo disponibilità elevata in caso di errore dei nodi, ma anche per gli errori della zona. Un deployment di esempio di questa strategia è discusso nella sezione sulle alternative di deployment di RE.
Anche se nodi diversi gestiscono lo stesso database e lo condividono, non è richiesta alcuna archiviazione comune tra i nodi di un cluster FCI. SQL Server utilizza la funzionalità Storage Space Direct (S2D) per gestire i database su dischi di nodi dedicati. Per ulteriori informazioni, consulta Configurazione delle istanze del cluster di failover di SQL Server.
L'esempio della sezione precedente sui gruppi di disponibilità sempre attivi con FCI anziché con istanze SQL Server autonome è mostrato nella figura seguente. Ogni FCI ha un'istanza SQL Server attiva che gestisce il database.
Come nel caso del gruppo di disponibilità, una risorsa FCI è rappresentata da un rettangolo. Questo è a solo scopo illustrativo per indicare che i nodi appartengono tutti alla stessa FCI. Un FCI non è una risorsa cloud e, come tale, non è implementata in un nodo o in qualsiasi altro tipo di risorsa.
Per una discussione più dettagliata, consulta Istanze di cluster di failover sempre attive (SQL Server).
Gruppi di disponibilità distribuiti
I gruppi di disponibilità distribuita sono un tipo speciale di gruppi di disponibilità. Un gruppo di disponibilità distribuito comprende due gruppi di disponibilità, uno nel gruppo di disponibilità principale e l'altro nel gruppo di disponibilità secondario. I gruppi di disponibilità distribuita possono inoltrare le transazioni in modalità sincrona e asincrona dal gruppo di disponibilità principale al gruppo di disponibilità secondario.
Anche se ogni gruppo di disponibilità ha il proprio database principale, questo deployment non è un deployment attivo-attivo. Solo il database principale del gruppo di disponibilità principale può ricevere operazioni di scrittura. Il database principale del gruppo di disponibilità secondario è chiamato forwarding. Lo spedizioniere riceve le transazioni dal gruppo di disponibilità principale e le inoltra ai database secondari del gruppo di disponibilità secondario. Un failover dal gruppo di disponibilità principale al gruppo di disponibilità secondario renderebbe accessibile il database principale del nuovo gruppo di disponibilità principale per le operazioni di scrittura.
I gruppi di disponibilità principale e secondario non devono trovarsi nella stessa località e non devono trovarsi nello stesso sistema operativo. Tuttavia, per ogni gruppo di disponibilità deve essere installato un listener. Il gruppo di disponibilità distribuita non ha un listener. I gruppi di disponibilità distribuiti non richiedono che i due gruppi di disponibilità siano nello stesso WSFC. Tutte le funzionalità necessarie per far funzionare i gruppi di disponibilità distribuiti sono incluse nella funzionalità SQL Server e non richiedono l'installazione aggiuntiva dei componenti sottostanti.
Un gruppo di disponibilità distribuito comprende esattamente due gruppi di disponibilità. Un gruppo di disponibilità può far parte di due gruppi di disponibilità distribuiti. Questa possibilità supporta topologie diverse. Uno è una topologia daisy-chaining da gruppo di disponibilità a gruppo di disponibilità in più località. Un'altra topologia è ad albero, in cui il gruppo di disponibilità principale fa parte di due gruppi di disponibilità distribuiti diversi e separati.
I gruppi di disponibilità distribuita sono il mezzo principale per implementare il ripristino di emergenza nei vari sistemi operativi. Ad esempio, il gruppo di disponibilità principale può essere configurato su Windows e un secondo gruppo di disponibilità corrispondente su Linux, con entrambi i gruppi di disponibilità che formano un gruppo di disponibilità distribuito.
Il seguente diagramma mostra due gruppi di disponibilità che fanno parte di un gruppo di disponibilità distribuito.
Il gruppo di disponibilità 1 è il gruppo di disponibilità principale e il gruppo di disponibilità 2 è il gruppo di disponibilità secondario.
Come nel caso degli FCI, un gruppo di disponibilità distribuito è rappresentato da un rettangolo. Questo è a solo scopo illustrativo per indicare che i gruppi di disponibilità appartengono tutti allo stesso gruppo di disponibilità distribuita. Un gruppo di disponibilità distribuito, ad esempio un gruppo di disponibilità, non è una risorsa cloud e, in quanto tale, non è implementato in un nodo o in qualsiasi altro tipo di risorsa.
Per ulteriori informazioni, consulta Gruppi di disponibilità distribuiti.
Registra spedizione
La spedizione dei log delle transazioni è una funzionalità di disponibilità di SQL Server quando l'RTO e l'RPO non sono così rigidi (RTO basso e/o RPO recente) perché la discrepanza di stato tra un database principale e il relativo database secondario è notevolmente maggiore. La discrepanza è maggiore in termini di stato perché un file di log delle transazioni contiene molte modifiche di stato. La discrepanza è maggiore in termini di tempo di attesa, perché i file di log delle transazioni vengono trasportati in modo asincrono e devono essere applicati nella loro interezza a un database secondario.
I file di log delle transazioni vengono creati dal database principale e ne viene eseguito il backup, ad esempio, in Cloud Storage. Ogni file di log delle transazioni viene copiato in ogni database secondario e vi viene applicato. Poiché il database secondario è in ritardo rispetto al database principale, è in modalità standby tiepido. Le modifiche e gli oggetti non acquisiti dai log delle transazioni devono essere applicati manualmente ai database secondari per stabilire una sincronizzazione completa senza perdite.
SQL Server Agent automatizza il processo complessivo di creazione, copia e applicazione dei log delle transazioni. La spedizione dei log deve essere configurata singolarmente per ogni database. Se un gruppo di disponibilità gestisce più di un database, è necessario configurare così tanti processi di spedizione dei log.
In caso di errore, il processo di ripristino di emergenza deve essere avviato manualmente perché non esiste supporto automatico. Inoltre, l'accesso client non viene rimosso dal database principale e dai database secondari da parte di un listener. In caso di failover, i client devono essere in grado di gestire autonomamente la modifica del ruolo di un database passando dal ruolo secondario al nuovo ruolo principale connettendosi al nuovo ruolo principale dopo un ripristino di emergenza. È possibile creare astrazioni separate indipendentemente dalle istanze SQL Server, ad esempio indirizzi IP mobili come descritto nelle Best practice per gli indirizzi IP mobili.
Poiché l'invio dei log è in parte un processo manuale, puoi ritardare l'applicazione intenzionale dei file di log copiati ai database secondari (a differenza dei gruppi di disponibilità e dei gruppi di disponibilità distribuiti in cui le modifiche vengono applicate immediatamente). Un possibile caso d'uso impedisce che gli errori di modifica dei dati nel database principale vengano applicati ai database secondari fino a quando gli errori di modifica dei dati non vengono risolti. In questo caso, un database secondario a cui non è ancora applicato un errore di modifica dei dati potrebbe diventare il database principale fino a quando l'errore di modifica dei dati non viene risolto. Dopodiché potrà riprendere la normale elaborazione.
Come nel caso dei gruppi di disponibilità distribuiti, puoi utilizzare la spedizione dei log per soluzioni multipiattaforma in cui, ad esempio, il database principale è in esecuzione su Linux, mentre i database secondari su Linux e Windows.
Il seguente diagramma illustra un deployment multipiattaforma con la spedizione dei log. Tieni presente che non esiste una configurazione comune tra le regioni come un gruppo di disponibilità distribuito in questa topologia.
I gruppi di disponibilità si trovano in regioni separate, una in esecuzione su Linux e l'altra su Windows.
Per saperne di più sulla spedizione dei log di SQL Server, consulta Informazioni sulla spedizione dei log (SQL Server).
Combinazione delle funzionalità di disponibilità di SQL Server
Puoi eseguire il deployment delle funzionalità di disponibilità di SQL Server in diverse combinazioni. Ad esempio, nel caso d'uso precedente, la spedizione dei log è stata utilizzata con diversi gruppi di disponibilità installati su sistemi operativi diversi.
Di seguito è riportato un elenco di possibili combinazioni di funzionalità di disponibilità di SQL Server:
- Utilizza la spedizione dei log tra i gruppi di disponibilità installati sullo stesso sistema operativo.
- Avere un gruppo di disponibilità principale che utilizza le FCI con un gruppo di disponibilità secondario che utilizza solo istanze SQL Server indipendenti.
- Utilizza un gruppo di disponibilità distribuito tra regioni vicine e la spedizione dei log tra regioni situate in continenti diversi.
Queste sono solo alcune delle possibili combinazioni di funzionalità di disponibilità di SQL Server.
La flessibilità offerta dalle funzionalità di disponibilità di SQL Server supporta il perfezionamento di una strategia di ripristino di emergenza in base ai requisiti dichiarati.
Replica SQL Server
La replica SQL Server non è in genere considerata una funzionalità di disponibilità, ma questa sezione descrive brevemente come può essere utilizzata per il ripristino di emergenza.
La funzionalità di replica supporta la creazione e la manutenzione di repliche di database. Diversi tipi di agenti SQL Server collaborano per acquisire le modifiche, trasmettere le modifiche acquisite e applicarle alle repliche. Questo processo è asincrono e le repliche di solito sono in ritardo rispetto al database di replica a vari gradi.
Ad esempio, è possibile avere una replica di un database di produzione. In termini di ripristino di emergenza, il database di produzione è il database principale, mentre la replica è il database secondario. La funzionalità di replica SQL Server non sa che i database assumono ruoli diversi nel contesto del ripristino di emergenza. Di conseguenza, la replica non prevede operazioni che supportano il processo di ripristino di emergenza, ad esempio le modifiche dei ruoli. Il processo di ripristino di emergenza deve essere implementato separatamente dalla funzionalità SQL Server ed essere eseguito dall'organizzazione che lo implementa perché non ci sono interruzioni dell'accesso client.
Spedizione dei file di backup
La spedizione dei file di backup è un'altra strategia di implementazione del ripristino di emergenza. Un approccio standard alla configurazione e all'aggiornamento continuo di un database secondario prevede l'esecuzione di un backup completo iniziale del database principale e successivamente di backup incrementali. Tutti i backup incrementali vengono applicati ai database secondari nell'ordine corretto. Esistono molte varianti di questo approccio a seconda della frequenza dei backup incrementali e della posizione di archiviazione dei file di backup (posizione globale o effettivamente copiati tra le località).
Questa strategia non prevede alcuna funzionalità di disponibilità di SQL Server quando lo stato di replica cambia dal database principale a qualsiasi database secondario. Non utilizza l'agente SQL Server usato per la spedizione dei log.
Per ulteriori informazioni, consulta la sezione Esempio: strategia di RE di backup e ripristino.
Le istruzioni dettagliate per il backup e il ripristino di SQL Server sono illustrate nella seguente soluzione: Utilizzo dei backup di Microsoft SQL Server per il recupero point-in-time su Compute Engine.
Rispetto all'approccio di replica descritto nella sezione precedente, sia la replica che la spedizione dei file di backup hanno in comune il fatto che il processo di ripristino di emergenza viene implementato all'esterno e separato dal set di funzionalità di SQL Server. Dal punto di vista dell'invio delle modifiche acquisite, la replica di SQL Server è più comoda in quanto implementa automaticamente questa parte tramite agenti SQL Server.
Nota sull'interazione tra il ciclo di vita del database e il ciclo di vita dell'app
Il failover di un database non è completamente separato e non dipende dalle app che accedono al database. In linea di principio, esistono due scenari di errore.
Innanzitutto, l'app rimane operativa durante l'esecuzione del failover del database. Dal momento dell'indisponibilità del database principale fino al momento in cui il nuovo database principale è operativo, le app non possono accedere al database. Le connessioni esistenti non riescono e non vengono stabilite nuove connessioni. Durante questo periodo, l'app non è in grado di gestire i propri client, almeno nella misura in cui la funzionalità richieda l'accesso al database. Le app devono riconoscere quando è disponibile il nuovo database principale per poter riprendere la normale elaborazione.
Le app potrebbero avere uno stato esterno al database, ad esempio nelle cache della memoria principale. L'app si assicura che la cache sia coerente (sincronizzata) con il nuovo database principale. Se non si è verificata alcuna perdita di transazioni durante il failover, la cache potrebbe essere coerente senza ulteriore manutenzione. Tuttavia, se si verifica una perdita di transazioni (dati) durante il failover, la cache potrebbe non essere coerente con il nuovo database principale. La discussione analoga si applica allo stato condiviso quando, ad esempio, alcuni dati nel database fanno parte anche di messaggi in code o di file nel file system. Questo aspetto della coerenza dei dati non rientra nell'ambito di questo documento perché non è direttamente correlato al ripristino di emergenza del database.
In secondo luogo, una o più app potrebbero non essere più disponibili nello stesso momento in cui il database principale diventa non disponibile. Ad esempio, se una regione risulta offline, un sistema di applicazioni in esecuzione in quella regione non sarà disponibile come il database principale nella stessa regione. In questo caso, deve essere recuperata anche l'app, non solo il sistema di database principale. Insieme al processo di ripristino di emergenza del database, devi avviare una procedura di ripristino delle app simile. L'app recuperata deve connettersi al nuovo database principale ed essere riconfigurata (ad esempio, indirizzi IP mobili). Il recupero delle app non rientra nell'ambito di questo documento.
Relazione tra backup e ripristino per il ripristino di emergenza
Il backup di un database è indipendente e ortogonale al ripristino di emergenza del database. Lo scopo del backup del database è quello di poter ripristinare uno stato coerente, ad esempio nel caso in cui un database venga perso o danneggiato o sia necessario ripristinare uno stato precedente a causa di errori o bug dell'app. Backup, archiviazione e ripristino nel contesto di Google Cloud è descritto in Utilizzo dei backup di Microsoft SQL Server per il recupero point-in-time su Compute Engine.
La seguente sezione illustra come utilizzare i backup come possibile meccanismo per implementare il ripristino di emergenza del database. In questo scenario, copierai i file di backup nel percorso del database secondario in modo che il database secondario possa essere ripristinato. Tuttavia, i file di backup non sono un prerequisito per il ripristino di emergenza; la precedente discussione sulle funzionalità di disponibilità ha presentato alternative.
Alta disponibilità e ripristino di emergenza
L'alta disponibilità e il ripristino di emergenza hanno in comune il fatto di fornire soluzioni per l'indisponibilità del database. Se un database primario non è disponibile, un database secondario diventa il nuovo database primario coerente e disponibile.
La differenza tra alta disponibilità e ripristino di emergenza è il dominio single point of failure. L'alta disponibilità risolve un'interruzione all'interno di una regione, ad esempio in caso di errore di una singola zona o di un nodo. Una soluzione ad alta disponibilità fornisce un nuovo database principale in un'altra zona nella stessa regione. Inoltre, l'alta disponibilità consente di risolvere gli errori dei nodi, non solo del database. In caso di errore di un nodo che esegue un'istanza SQL Server, viene reso disponibile un nuovo nodo che esegue una nuova istanza SQL Server (consulta la discussione nella sezione Istanza del cluster di failover sempre attiva).
Il ripristino di emergenza interessa almeno due regioni. Riguarda il caso in cui un'intera regione non sia più disponibile. Il ripristino di emergenza può fornire un nuovo database principale in un'altra regione.
Le funzionalità ad alta disponibilità di SQL Server supportano contemporaneamente soluzioni per l'alta disponibilità e il ripristino di emergenza. Un singolo gruppo di disponibilità può abbracciare le zone di una regione e le regioni stesse. Un gruppo di disponibilità può contenere istanze di cluster di failover per gestire l'alta disponibilità.
SQL Server può stabilire gruppi di disponibilità all'interno di un'area geografica per l'alta disponibilità e gli errori di zona, nonché combinarli con la distribuzione dei log in più regioni per affrontare il ripristino di emergenza.
Alternative di deployment di RE
Nelle sezioni seguenti sono mostrate alcune possibili topologie di ripristino di emergenza in aggiunta a quelle discusse finora. Queste topologie soddisfano requisiti RPO e RTO diversi. Questo elenco non è completo.
RE e alta disponibilità intraregionali
Questo deployment è una variante di un gruppo di disponibilità che contiene FCI, all'interno di una regione composta da tre zone. In questo scenario, le zone sono considerate il dominio single point of failure.
Rispetto al deployment mostrato in precedenza, ogni FCI è composta da tre nodi in cui ogni nodo è in esecuzione in una zona diversa. Il vantaggio di questa configurazione è che una o due zone possono avere esito negativo senza richiedere un processo di ripristino di emergenza.
Il seguente diagramma mostra questa configurazione.
Gli FCI coprono tutte le zone e ogni FCI ha un'istanza SQL Server in esecuzione che accede al database corrispondente. Esistono altre due istanze SQL Server non in esecuzione in ogni FCI che possono essere avviate in caso di errore di una zona. I database sono visualizzati nelle varie zone poiché ogni database utilizza i dischi di tutti i nodi in un determinato FCI. Non viene mostrata un'app per maggiore chiarezza.
RE interregionale: gruppo di disponibilità che comprende le regioni
In questo scenario, un gruppo di disponibilità viene eseguito su un cluster di failover di Windows Server e copre due regioni. Le regioni sono considerate un singolo dominio point of failure.
Il seguente diagramma illustra questa configurazione.
Per risolvere potenziali problemi di latenza, puoi configurare le repliche nella regione R1 in modo da utilizzare la propagazione delle transazioni sincrone, mentre le repliche nella regione R2 sono configurate per l'uso della propagazione asincrona delle transazioni.
RE tra regioni: trasferimento di file di backup
Questo scenario utilizza il trasferimento di file di backup. Sono collegati due gruppi di disponibilità in due regioni. Ogni gruppo di disponibilità ha le sue repliche che ricevono le transazioni in modo sincrono. Di conseguenza, le repliche secondarie di ogni regione si trovano in una configurazione in standby.
Il seguente diagramma illustra questa configurazione.
Tuttavia, i due gruppi di disponibilità vengono collegati tramite trasferimento di file di backup. Il gruppo di disponibilità AG1 è il gruppo di disponibilità principale, mentre il gruppo di disponibilità AG2 è il gruppo di disponibilità secondario. Quando i file di backup vengono resi disponibili per il gruppo di disponibilità secondario, vengono applicati lì. Questo scenario è discusso in modo più dettagliato nella sezione seguente, Esempio: strategia di ripristino di emergenza di backup e ripristino.
Topologia a doppia posizione e località terziaria
Se sono presenti solo due database, uno principale e uno secondario, ciascuno in una regione separata, esiste una durata non protetta dopo un failover dal momento in cui il nuovo database principale è in esecuzione e il nuovo database secondario è pronto. Se il nuovo database principale non è disponibile mentre il database secondario non è ancora in esecuzione, si verifica un tempo di inattività rigido, che può essere ripristinato solo a partire dalla creazione di un nuovo database principale. Lo stesso vale per i gruppi di disponibilità.
Una terza località che esegue un altro database o gruppo di disponibilità secondario può eliminare la durata non protetta dopo un failover. Questa configurazione deve garantire che uno dei due database secondari rimanga un database secondario e venga riassegnato a un nuovo database primario in modo che non si verifichi alcuna perdita di dati. Lo stesso vale per i gruppi di disponibilità.
Ciclo di vita di RE
Indipendentemente dalla soluzione di ripristino di emergenza che scegli, esistono passaggi del ciclo di vita comuni.
In una situazione effettiva di ripristino di emergenza, tutti gli stakeholder (proprietari di app, gruppi operativi e amministratori di database) devono essere disponibili e partecipare attivamente alla gestione del ripristino di emergenza. Gli stakeholder devono decidere l'autorità decisionale (a volte definita master della cerimonia) e i processi decisionali che seguono. Inoltre, gli stakeholder devono concordare sulla terminologia e sui metodi di comunicazione.
Scelta dell'avvio di un processo di failover
A meno che il failover non venga avviato automaticamente, gli stakeholder devono decidere di avviare un failover. I vari stakeholder devono coordinarsi strettamente sulla decisione quando decidono di avviare il failover.
L'avvio di un processo di failover dipende da diversi fattori, principalmente dalla causa principale del database primario che diventa non disponibile.
Se il processo di ripristino di emergenza richiede più tempo del tempo previsto per risolvere l'indisponibilità del database principale, un failover sarebbe dannoso. Innanzitutto, devi valutare se è possibile ripristinare il database principale.
Migliore è la sperimentazione della strategia di ripristino di emergenza, più rapido è l'implementazione, più facile è l'avvio del processo di failover perché meno incertezza deve essere presa in considerazione nella decisione.
Esecuzione del processo di failover
Idealmente, il processo di failover viene testato regolarmente e pertanto è noto ai vari stakeholder.
L'autorità decisionale deve essere a conoscenza di tutte le fasi in corso e di tutti i problemi imprevisti che si presentano. L'autorità decisionale guida il processo di failover e gli stakeholder sono responsabili del supporto dell'autorità di decisione.
Dovresti conservare le statistiche per il miglioramento dell'analisi post mortem e del processo di failover, incluse la durata delle attività, i problemi emersi e l'eventuale confusione nei passaggi del processo di failover.
Protezione mancante
Se hai un solo database secondario, dal momento in cui il nuovo database primario è disponibile e operativo fino alla configurazione di un nuovo database secondario, non esiste alcuna protezione RE. Un'indisponibilità durante questo periodo potrebbe causare un arresto anomalo perché non è possibile alcun failover a un altro database. Se si verifica questa situazione, è necessario configurare un altro database principale e l'RPA è l'ultimo punto da ricostruire in base ai backup disponibili.
A meno che la strategia di ripristino di emergenza non sia impostata in modo da garantire protezione in ogni momento, ogni stakeholder deve essere consapevole della durata della mancanza di protezione per prendere precauzioni aggiuntive durante le modifiche alla configurazione o alla configurazione dell'ambiente.
Puoi evitare questo periodo di non protezione se l'accesso dell'app al nuovo database principale viene ritardato finché il nuovo database secondario non è in esecuzione. Non appena vengono applicate le modifiche del database principale, il database principale è disponibile per le app. Anche se questo approccio evita qualsiasi momento in cui le app non sono protette dal RE, ritarda il completamento del processo di ripristino di emergenza.
Evitare situazioni di divisione cerebrale
È importante che le app non possano accedere contemporaneamente a un database principale e a un database secondario, generando operazioni DML. In questa situazione, si verifica un'incoerenza tra i dati in cui sia il database principale sia il database secondario non sono d'accordo sui valori dei dati dello stesso elemento di dati (Split-brain). Questa architettura è particolarmente importante se il database principale non è disponibile mentre è in esecuzione e può ricevere operazioni di scrittura. Se l'indisponibilità è causata da un partizionamento di rete intermittente, il partizionamento può interrompersi in qualsiasi momento e un'app potrebbe avere di nuovo accesso. Se in quel momento è in corso un processo di failover, le modifiche al vecchio database principale potrebbero andare perse oppure alcune app iniziano a funzionare sul nuovo database principale mentre altre accedono ancora al vecchio database principale.
L'accesso a tutte le app viene disattivato per qualsiasi database durante il processo di failover in modo che non possa verificarsi alcuna modifica dello stato in nessuno dei database. Dopo il failover, è disponibile un solo database per le operazioni di scrittura: il nuovo database primario.
Dichiarazione di completamento
Una volta completato il processo di failover, tutti gli stakeholder devono essere informati esplicitamente dall'autorità decisionale che il processo è stato completato. Qualsiasi problema che si verifica dopo il completamento deve essere trattato come un incidente separato che non fa più parte del processo di failover, ma parte della normale elaborazione. Il problema potrebbe essere una conseguenza di un problema con il processo di failover o di un problema indipendente del tutto. Tuttavia, l'approccio per affrontare il problema dopo il completamento del processo di failover potrebbe essere diverso da come viene gestito durante l'esecuzione del processo di failover.
Analisi e report post mortem
Come riferimento futuro e per migliorare il processo di failover, organizza immediatamente un'analisi post mortem per prendere nota di aspetti importanti, risultati e azioni.
Scrivi un report che riassuma l'evento di ripristino di emergenza, le cause principali e tutte le azioni intraprese. Questo report potrebbe essere obbligatorio se implementi requisiti normativi.
Test e verifica di RE
Poiché il ripristino di emergenza non fa parte delle normali operazioni quotidiane, la soluzione di RE deve essere testata regolarmente per verificarne il corretto funzionamento quando è effettivamente necessaria.
La frequenza dei test dipende dai requisiti operativi e varia a seconda del database, dell'app e dell'azienda. Inoltre, modifiche all'ambiente, come modifiche alla configurazione di rete e aggiornamenti dei componenti dell'infrastruttura, dovrebbero attivare un test di ripristino di emergenza se le modifiche vengono apportate ai sistemi su cui si basa la soluzione di ripristino di emergenza scelta. Qualsiasi modifica potrebbe causare l'esito negativo della soluzione di ripristino di emergenza o richiedere la modifica del processo di ripristino di emergenza.
Puoi eseguire test manualmente avviando il processo di passaggio oppure automaticamente seguendo un approccio ingegneristico del caos come descritto nell'articolo Ingegneria del caos. Con i test manuali puoi ridurre al minimo l'impatto sull'attività nel caso in cui sia previsto un tempo di inattività notevole.
Un aspetto importante dei test è la raccolta di statistiche ben definite. Ecco alcune statistiche importanti da considerare:
- Tempo di ripristino effettivo: misura il tempo di ripristino effettivo e confrontalo con l'RTO.
- Recovery point effettivo: osserva il punto di ripristino effettivo e confrontalo con l'RPO.
- Rilevamento del tempo di errore: il tempo impiegato dagli autori di database o dal team operativo per realizzare la necessità del failover.
- Tempo di avvio del ripristino: il tempo necessario per avviare il processo di failover dopo il rilevamento dell'errore.
- Affidabilità: quanto è stato seguito il processo di failover o sono state necessarie deviazioni da esso? Si sono verificati problemi imprevisti che hanno bisogno di essere indagati, il che potrebbe portare a un cambio di strategia di ripristino?
In base alle statistiche raccolte, potrebbe essere necessario regolare o migliorare il processo di failover per soddisfare meglio le aspettative dell'RPO e dell'RTO.
Esempio: strategia di ripristino di emergenza di backup e ripristino
Le seguenti sezioni descrivono una strategia di esempio per il ripristino di emergenza di backup e ripristino. Questo scenario riduce al minimo l'uso delle funzionalità di disponibilità di SQL Server per dimostrare lo sforzo necessario per specificare una strategia di backup e ripristino di ripristino di emergenza e per discutere di aspetti invisibili in configurazioni più automatizzate. Fa riferimento alla soluzione correlata, Utilizzo dei backup di Microsoft SQL Server per il recupero point-in-time su Compute Engine.
Caso d'uso
Un gruppo principale di disponibilità sempre attivo si trova e operativo nella regione R1. Il gruppo secondario di disponibilità sempre attiva viene aggiunto nella regione R2 per un'ulteriore protezione tra regioni ed è disponibile come destinazione di failover o commutazione.
Strategia
La strategia di ripristino di emergenza si basa sui backup dei database. Viene eseguito un backup completo iniziale seguito dai backup differenziali successivi. I backup vengono applicati al gruppo di disponibilità sempre attivo secondario man mano che vengono acquisiti. Tutti i backup sono archiviati in un bucket Cloud Storage.
In questo esempio, dopo il completamento del failover è accettabile che il nuovo gruppo di disponibilità Sempre attivo principale in R2 sia attivo e non protetto per un periodo di tempo limitato finché il nuovo gruppo di disponibilità Sempre attivo secondario in R1 non sarà operativo.
Non deve essere eseguito alcun fallback, poiché il gruppo di disponibilità sempre attivo in ciascuna delle regioni è idoneo a fungere da gruppo di disponibilità sempre attivo di produzione.
RTO e RPO
In questo esempio l'RPO è definito come un massimo di 60 minuti, pertanto viene eseguito un backup differenziale ogni 60 minuti.
L'RTO non è impostato esplicitamente su una durata di tempo, ma deve essere il più minimo possibile, l'immediato è il caso migliore. Il gruppo di disponibilità secondario deve essere configurato come hot standby. In caso di hot standby, tutti i backup vengono applicati immediatamente, in modo che il failover non venga ritardato grazie all'applicazione dei backup.
Strategia generale di RE
Le sezioni seguenti descrivono la strategia di RE. Si mantiene breve per concentrarsi sui passaggi essenziali.
Impostazione iniziale
- Crea un gruppo di disponibilità sempre attivo secondario nella regione R2.
- Impedisci l'accesso delle app al gruppo di disponibilità secondario in modo che non si verifichi accidentalmente la situazione di suddivisione del cervello.
- Crea il bucket dei file di backup B1 in Cloud Storage in modo da contenere il backup completo iniziale del gruppo di disponibilità sempre attivo in R1 e i backup differenziali orari successivi del gruppo di disponibilità sempre attivo in R1. È necessario stabilire l'ordine corretto dei backup differenziali in modo che il processo di applicazione dei backup al gruppo di disponibilità secondario possa dedurre l'ordine corretto. Un approccio potrebbe essere una convenzione di denominazione che consente di stabilire l'ordine cronologico corretto in base alla data e all'ora presenti nei vari nomi dei file.
Strategia di lancio
- Applica il backup completo al gruppo di disponibilità sempre attivo secondario nell'area geografica R2.
- Man mano che i backup differenziali diventano disponibili, applicali immediatamente al gruppo secondario di disponibilità sempre attivo in R2. L'applicazione immediata è necessaria per risolvere l'RTO.
- Dopo l'applicazione del backup completo iniziale e di tutti i backup incrementali, il gruppo di disponibilità sempre attivo secondario è pronto.
- Testa la strategia di RE eseguendo un passaggio dal gruppo di disponibilità principale a quello secondario. Durante il test deve essere disponibile almeno un backup incrementale.
Failover o caso di passaggio
In R2, i passaggi essenziali sono i seguenti:
- Assicurati che l'ultimo backup differenziale sia stato applicato al gruppo secondario di disponibilità sempre attivo in R2.
- Specifica R2 come nuovo gruppo principale di disponibilità sempre attivo.
- Crea un nuovo bucket B2, esegui un backup completo come base di riferimento e apri il nuovo gruppo di disponibilità principale per l'accesso all'app.
- Inizia a eseguire backup differenziali.
In R1, i passaggi essenziali sono i seguenti:
- Rimuovi il bucket B1 perché non è più necessario.
- Quando il gruppo di disponibilità Sempre attivo in R1 diventa di nuovo disponibile (come nuovo gruppo di disponibilità sempre attivo secondario), impedisci l'accesso all'app e rimuovi tutti i dati dal database o reimpostalo allo stato iniziale (vuoto), a meno che non sia stato creato di recente.
- Applica il backup completo dal nuovo gruppo di disponibilità sempre attivo principale in R2 e continua ad applicare backup differenziali immediatamente non appena diventano disponibili (memorizzati nel bucket B2).
Possibili miglioramenti
Un possibile miglioramento alla strategia di RE è evitare di eseguire un backup completo dopo un failover o un cambio, pur continuando a configurare rapidamente il nuovo gruppo di disponibilità secondario. Invece di un singolo backup completo e dei successivi backup differenziali, esegui un backup completo ogni settimana e crea un bucket settimanale che contenga il backup completo della settimana e tutti i backup differenziali successivi per quella settimana. Il nuovo gruppo di disponibilità principale deve creare backup differenziali solo dopo il failover (e non un backup completo) e aggiungerli al bucket. Il nuovo gruppo di disponibilità secondario applica semplicemente tutti i backup nel bucket della settimana in corso. Se utilizzi questo approccio settimanale, devi implementare una strategia di pulizia o di eliminazione definitiva per rimuovere i backup obsoleti.
Un altro miglioramento è basato sul fatto che il nuovo gruppo di disponibilità secondario era il precedente gruppo di disponibilità principale. Se il database esiste ed è operativo dopo essere stato nuovamente disponibile, un recupero point-in-time all'ultimo backup differenziale evita di doverlo ripristinare completamente dall'ultimo backup completo, come descritto in Ripristinare un database SQL Server in un point-in-time (modello di ripristino completo). Questo scenario riduce lo sforzo e il periodo di tempo in cui il nuovo gruppo di disponibilità principale non viene protetto.
Best practice per la produzione
Questa soluzione non specifica se le istanze SQL Server nei gruppi di disponibilità sempre attiva sono istanze autonome o FCI. Il tipo di istanze utilizzate deve essere deciso prima dell'implementazione.
Fino a quando un nuovo gruppo di disponibilità sempre attivo secondario non è operativo dopo un failover, c'è un periodo in cui RE non è protetto. Devi configurare un terzo gruppo di disponibilità sempre attivo in una terza regione.
Inoltre, devi implementare il monitoraggio per garantire che vengano rilevati guasti o errori. Il monitoraggio non rientra nell'ambito di questo documento, ma è essenziale per una soluzione funzionante di ripristino di emergenza.
Passaggi successivi
- Configurazione dei gruppi di disponibilità sempre attiva di SQL Server.
- Deployment di un gruppo di disponibilità sempre attivo di SQL Server 2016 con più subnet su Compute Engine.
- Configurazione delle istanze del cluster di failover SQL Server.
- Esecuzione del clustering di failover di Windows Server.
- Come abilitare Cloud Logging, Cloud Monitoring ed Error Reporting per le app .NET
- Installazione dell'agente Cloud Monitoring.
- Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Dai un'occhiata al nostro Cloud Architecture Center.