Gestione del database multi-cloud: architetture, casi d'uso e best practice

Questo documento descrive le architetture di deployment, i casi d'uso e le best practice per la gestione dei database multicloud. È destinato ad architetti e ingegneri che progettano e implementano applicazioni stateful all'interno e tra più cloud.

Le architetture delle applicazioni multicloud che accedono ai database dipendono dal caso d'uso. Nessuna architettura di applicazione stateful può supportare tutti i casi d'uso multicloud. Ad esempio, la soluzione di database migliore per un caso d'uso di cloud bursting è diversa da quella per un'applicazione che viene eseguita contemporaneamente in più ambienti cloud.

Per i cloud pubblici come Google Cloud, esistono varie tecnologie di database adatte a casi d'uso multicloud specifici. Per eseguire il deployment di un'applicazione in più regioni all'interno di un singolo cloud pubblico, un'opzione è utilizzare un database multiregionale gestito dal provider di cloud pubblico, come Spanner. Per eseguire il deployment di un'applicazione portatile su più cloud pubblici, un database indipendente dalla piattaforma potrebbe essere una scelta migliore, ad esempio AlloyDB Omni o PostgreSQL.

Questo documento introduce una definizione di applicazione di database stateful, seguita da un'analisi del caso d'uso del database multicloud. Viene quindi presentata una classificazione dettagliata dei sistemi di database per le architetture di deployment multicloud in base ai casi d'uso.

Il documento introduce anche un albero decisionale per la selezione dei database che delinea i punti decisionali chiave per la selezione di una tecnologia di database appropriata. Si conclude con una discussione sulle best practice per la gestione dei database multicloud.

Termini e definizioni chiave

Questa sezione fornisce una terminologia e definisce l'applicazione di database stateful generica utilizzata in questo documento.

Terminologia

• Cloud pubblico. Un cloud pubblico fornisce infrastrutture (generalmente globali) e servizi multi-tenant che i clienti possono utilizzare per eseguire i propri carichi di lavoro di produzione. Google Cloud è un cloud pubblico che fornisce molti servizi gestiti, tra cui GKE, GKE Enterprise e database gestiti.
• Cloud ibrido. Un cloud ibrido è una combinazione di un cloud pubblico con uno o più data center on-premise. I clienti del cloud ibrido possono combinare i propri servizi on-premise con servizi aggiuntivi forniti da un cloud pubblico.
• Multi-cloud. Un multicloud è una combinazione di diversi cloud pubblici e data center on-premise. Un cloud ibrido è un sottoinsieme del multicloud.
• Posizione del deployment. Una località dell'infrastruttura è una posizione fisica che può eseguire il deployment ed eseguire workload, tra cui applicazioni e database. Ad esempio, in Google Cloud, le località di deployment sono zone e regioni. A livello astratto, una regione o una zona cloud pubblico e un data center on-premise sono località di deployment.

Applicazioni di database stateful

Per definire i casi d'uso multicloud, in questo documento viene utilizzata un'architettura di applicazione di database stateful generica, come mostrato nel seguente diagramma.

Il diagramma mostra i seguenti componenti:

• Database. Un database può essere un'istanza singola, più istanze o un database distribuito, di cui è stato eseguito il deployment su nodi di computing o disponibile come servizio gestito dal cloud.
• Servizi per le applicazioni. Questi servizi vengono combinati come un'applicazione che implementa la logica di business. I servizi per le applicazioni possono essere uno dei seguenti:
  • Microservizi su Kubernetes.
  • Processi granulari eseguiti su una o più macchine virtuali.
  • Un'applicazione monolitica su una macchina virtuale di grandi dimensioni.
  • Codice serverless in Cloud Run Functions o Cloud Run. Alcuni servizi applicativi possono accedere al database. È possibile eseguire il deployment di ogni servizio applicativo più volte. Ogni deployment di un servizio dell'applicazione è un'istanza di quel servizio dell'applicazione.
• Client delle applicazioni. I client delle applicazioni accedono alle funzionalità fornite dai servizi delle applicazioni. I client delle applicazioni possono essere uno dei seguenti:
  • Client di cui è stato eseguito il deployment, in cui il codice viene eseguito su un computer, un laptop o un cellulare.
  • Client non implementati, in cui il codice client viene eseguito in un browser. Le istanze client dell'applicazione accedono sempre a una o più istanze del servizio dell'applicazione.

Nel contesto di una discussione sul database multicloud, l'astrazione architetturale di un'applicazione stateful è costituita da un database, servizi dell'applicazione e client dell'applicazione. Nell'implementazione di un'applicazione, possono variare fattori come l'utilizzo di sistemi operativi o i linguaggi di programmazione utilizzati. Tuttavia, questi dettagli non influiscono sulla gestione dei database multicloud.

Code e file come servizi di archiviazione dati

Sono disponibili molte risorse di persistenza per i servizi applicativi per rendere persistenti i dati. Queste risorse includono database, code e file. Ogni risorsa di persistenza fornisce modelli di dati di archiviazione e pattern di accesso specializzati per questi modelli. Sebbene le code, i sistemi di messaggistica e i sistemi di file vengano utilizzati dalle applicazioni, nella sezione seguente l'attenzione è rivolta in particolare ai database.

Sebbene le stesse considerazioni per fattori quali la posizione di deployment, la condivisione dello stato e la replica sincrona e asincrona per i database multicloud siano applicabili a code e file, questa discussione non rientra nell'ambito di questo documento.

Networking

Nell'architettura di un'applicazione stateful generica (mostrata di nuovo nel diagramma seguente), ogni freccia tra i componenti rappresenta una relazione di comunicazione su una connessione di rete, ad esempio un client dell'applicazione che accede a un servizio dell'applicazione.

Una connessione può trovarsi all'interno di una zona o in più zone, regioni o cloud. Le connessioni possono esistere tra qualsiasi combinazione di località di deployment. Negli ambienti multicloud, il networking tra i cloud è una considerazione importante e ci sono diverse opzioni che puoi utilizzare. Per ulteriori informazioni sul networking tra cloud, vedi Cross-Cloud Network per applicazioni distribuite e Connessione a Google Cloud: le opzioni di networking spiegate.

Nei casi d'uso descritti in questo documento, si presuppone quanto segue:

• Esiste una connessione di rete sicura tra i cloud.
• I database e i relativi componenti possono comunicare tra loro.

Da un punto di vista non funzionale, le dimensioni della rete, ovvero la velocità effettiva e la latenza, potrebbero influire sulla latenza e sulla velocità effettiva del database. Dal punto di vista funzionale, la rete in genere non ha alcun effetto.

Casi d'uso del database multicloud

Questa sezione presenta una selezione dei casi d'uso più comuni per la gestione dei database multi-cloud. Per questi casi d'uso, si presuppone che esista una connettività di rete sicura tra i cloud e i nodi di database.

Migrazione di applicazioni

Nel contesto della gestione dei database multicloud, la migrazione delle applicazioni si riferisce alla migrazione di un'applicazione, di tutti i servizi applicativi e del database dal cloud attuale a un cloud di destinazione. Esistono molti motivi per cui un'azienda potrebbe decidere di eseguire la migrazione di un'applicazione, ad esempio per evitare una situazione competitiva con il cloud provider, per modernizzare la tecnologia o per ridurre il costo totale di proprietà (TCO).

Nella migrazione delle applicazioni, l'obiettivo è interrompere la produzione nel cloud attuale e continuare la produzione nel cloud di destinazione dopo il completamento della migrazione. I servizi dell'applicazione devono essere eseguiti nel cloud di destinazione. Per implementare i servizi, è possibile utilizzare un approccio di lift and shift. Con questo approccio, lo stesso codice viene implementato nel cloud di destinazione. Per implementare nuovamente il servizio, è possibile utilizzare le moderne tecnologie cloud disponibili nel cloud di destinazione.

Dal punto di vista del database, considera le seguenti scelte alternative per la migrazione delle applicazioni:

• Lift and shift del database: se lo stesso motore del database è disponibile nel cloud di destinazione, è possibile eseguire il lift and shift del database per creare un deployment identico nel cloud di destinazione.
• Lift and shift del database all'equivalente gestito: un database autogestito può essere migrato a una versione gestita dello stesso motore del database se il cloud di destinazione lo fornisce.
• Modernizzazione dei database: i diversi cloud offrono tecnologie di database diverse. I database gestiti da un provider cloud potrebbero avere vantaggi come accordi sul livello del servizio (SLA) più rigorosi, scalabilità e ripristino di emergenza automatico.

Indipendentemente dalla strategia di deployment, la migrazione del database è un processo che richiede tempo a causa della necessità di spostare i dati dal cloud attuale al cloud di destinazione. Sebbene sia possibile seguire un approccio di esportazione e importazione che comporti tempi di inattività, è preferibile la migrazione con tempi di inattività minimi o nulli. Questo approccio riduce al minimo i tempi di inattività dell'applicazione e ha il minimo impatto su un'azienda e sui suoi clienti. Tuttavia, in genere richiede una configurazione di migrazione più complessa, in quanto comporta un caricamento iniziale, una replica continua, il monitoraggio, la convalida granulare e la sincronizzazione durante il passaggio. Per supportare scenari di fallback, devi implementare un meccanismo di replica inversa per sincronizzare le modifiche nel database di origine dopo il passaggio al database di destinazione.

Disaster recovery

Il disaster recovery si riferisce alla capacità di un'applicazione di continuare a fornire servizi ai client dell'applicazione durante un'interruzione a livello di regione. Per garantire il disaster recovery, un'applicazione deve essere implementata in almeno due regioni ed essere pronta per l'esecuzione in qualsiasi momento. In produzione, l'applicazione viene eseguita nella regione principale. Tuttavia, se si verifica un'interruzione, una regione secondaria diventa la regione principale. Di seguito sono riportati diversi modelli di preparazione al ripristino di emergenza:

• Hot standby. L'applicazione viene implementata in due o più regioni (principale e secondaria) e funziona perfettamente in ogni regione. Se la regione principale non funziona, l'applicazione nella regione secondaria può gestire immediatamente il traffico dei client dell'applicazione.
• Cold standby. L'applicazione è in esecuzione nella regione primaria, tuttavia è pronta per l'avvio in una regione secondaria (ma non è in esecuzione). Se la regione principale non funziona, l'applicazione viene avviata nella regione secondaria. Si verifica un'interruzione dell'applicazione finché non è in grado di essere eseguita e fornire tutti i servizi ai client dell'applicazione.
• Nessuna attesa. In questo modello, il codice dell'applicazione è pronto per il deployment, ma non è ancora stato eseguito nella regione secondaria (e quindi non utilizza risorse di cui è stato eseguito il deployment). Se una regione principale ha un'interruzione, il primo deployment dell'applicazione deve avvenire nella regione secondaria. Questo deployment mette l'applicazione nello stesso stato di uno standby a freddo, il che significa che deve essere avviata. Con questo approccio, l'interruzione dell'applicazione è più lunga rispetto al caso di standby a freddo perché il deployment dell'applicazione deve avvenire prima, il che include la creazione di risorse cloud.

Dal punto di vista del database, i modelli di preparazione discussi nell'elenco precedente corrispondono ai seguenti approcci al database:

• Database sincronizzato in modo transazionale. Questo database corrisponde al modello hot standby. Ogni transazione nella regione primaria viene eseguita in coordinamento sincrono in una regione secondaria. Quando la regione secondaria diventa la regione principale durante un'interruzione, il database è coerente e immediatamente disponibile. In questo modello, il Recovery Point Objective (RPO) e il Recovery Time Objective (RTO) sono entrambi pari a zero.
• Database replicato in modo asincrono. Questo database corrisponde anche al modello di standby attivo. Poiché la replica del database dalla regione principale a quella secondaria è asincrona, è possibile che se la regione principale non funziona, alcune transazioni vengano replicate nella regione secondaria. Anche se il database nella regione secondaria è pronto per il carico di produzione, potrebbe non contenere i dati più recenti. Per questo motivo, l'applicazione potrebbe subire una perdita di transazioni non recuperabili. A causa di questo rischio, questo approccio ha un RTO pari a zero, ma l'RPO è maggiore di zero.
• Database inattivo. Questo database corrisponde al modello di standby a freddo. Il database viene creato senza dati. Quando la regione principale non funziona, i dati devono essere caricati nel database inattivo. Per abilitare questa azione, è necessario eseguire un backup regolare nella regione primaria e trasferirlo nella regione secondaria. Il backup può essere completo o incrementale, a seconda di ciò che supporta ilmotore del databasee. In entrambi i casi, il database viene ripristinato all'ultimo backup e, dal punto di vista dell'applicazione, molte transazioni possono essere perse rispetto alla regione principale. Anche se questo approccio potrebbe essere conveniente, il valore è mitigato dal rischio che tutte le transazioni dall'ultimo backup disponibile potrebbero andare perse a causa dello stato del database non aggiornato.
• Nessun database. Questo modello è equivalente al caso nessuno standby. Nella regione secondaria non è installato alcun database e, se la regione principale non funziona, è necessario creare un database. Una volta creato il database, come nel caso del database inattivo, deve essere caricato con i dati prima di essere disponibile per l'applicazione.

Gli approcci di ripristino di emergenza descritti in questo documento si applicano anche se vengono utilizzati un cloud principale e uno secondario anziché una regione principale e una secondaria. La differenza principale è che, a causa dell'eterogeneità della rete tra i cloud, la latenza tra i cloud potrebbe aumentare rispetto alla distanza di rete tra le regioni all'interno di un cloud. Altre discrepanze possono derivare da funzionalità e impostazioni predefinite diverse dei database gestiti di diversi provider cloud.

La probabilità che un intero cloud non funzioni è inferiore a quella che non funzioni una regione. Tuttavia, per le aziende potrebbe essere comunque utile avere un'applicazione di cui è stato eseguito il deployment in due cloud. Questo approccio potrebbe contribuire a proteggere un'azienda da guasti o aiutarla a rispettare le normative aziendali o di settore.

Un altro approccio di ripristino di emergenza consiste nell'avere una regione primaria e una secondaria e un cloud primario e uno secondario. Questo approccio consente alle aziende di scegliere la procedura di ripristino di emergenza migliore per affrontare una situazione di errore. Per consentire l'esecuzione di un'applicazione, è possibile utilizzare una regione secondaria o un cloud secondario, a seconda della gravità dell'interruzione.

Cloud bursting

Il cloud bursting si riferisce a una configurazione che consente di scalare il traffico client dell'applicazione in diverse località di deployment. Un'applicazione esegue il burst quando la domanda di capacità aumenta e una posizione di standby fornisce capacità aggiuntiva. Una posizione principale supporta il traffico regolare, mentre una posizione di standby può fornire capacità aggiuntiva nel caso in cui il traffico client dell'applicazione aumenti oltre a quanto può supportare la posizione principale. Sono state implementate istanze del servizio di applicazione sia nella località principale che in quella di standby.

Il cloud bursting viene implementato su più cloud, dove uno è il cloud principale e un secondo è il cloud di standby. Viene utilizzato in un contesto di cloud ibrido per aumentare un numero limitato di risorse di calcolo nei data center on-premise con risorse di calcolo cloud elastiche in un cloud pubblico.

Per l'assistenza per i database, sono disponibili le seguenti opzioni:

• Deployment della posizione principale. In questo deployment, il database viene implementato solo nella località principale e non in quella di standby. Quando un'applicazione esegue un burst, l'applicazione nella posizione di standby accede al database nella posizione principale.
• Deployment della località principale e di standby. Questo deployment supporta sia la località principale che quella di standby. Un'istanza di database viene implementata in entrambe le località e vi si accede dalle istanze del servizio applicazione di quella località, soprattutto in caso di burst. Come in Recupero di emergenza all'interno e tra i cloud, i due database possono essere sincronizzati in modo transazionale o asincrono. Nella sincronizzazione asincrona, può verificarsi un ritardo. Se gli aggiornamenti vengono eseguiti nella posizione di standby, devono essere propagati di nuovo alla posizione principale. Se sono possibili aggiornamenti simultanei in entrambe le posizioni, è necessario implementare la risoluzione dei conflitti.

Il cloud bursting è un caso d'uso comune nei cloud ibridi per aumentare la capacità nei data center on-premise. È anche un approccio che può essere utilizzato in tutti i cloud pubblici quando i dati devono rimanere all'interno di un paese. Nelle situazioni in cui un cloud pubblico ha una sola regione in un paese, è possibile eseguire il burst in una regione di un cloud pubblico diverso nello stesso paese. Questo approccio garantisce che i dati rimangano all'interno del paese, pur affrontando i vincoli delle risorse nella regione delle regioni del cloud pubblico.

Utilizzo di servizi cloud senza pari

Alcune applicazioni richiedono prodotti e servizi cloud specializzati che non sono disponibili in un singolo cloud. Ad esempio, un'applicazione potrebbe eseguire l'elaborazione della logica aziendale dei dati aziendali in un cloud e l'analisi dei dati aziendali in un altro cloud. In questo caso d'uso, le parti di elaborazione della logica di business e le parti di analisi dell'applicazione vengono implementate in cloud diversi.

Dal punto di vista della gestione dei dati, i casi d'uso sono i seguenti:

• Dati partizionati. Ogni parte dell'applicazione ha un proprio database (partizione separata) e nessuno dei database è collegato direttamente all'altro. L'applicazione che gestisce i dati scrive due volte tutti i dati che devono essere disponibili in entrambi i database (partizioni).
• Database replicato in modo asincrono. Se i dati di un cloud devono essere disponibili nell'altro cloud, potrebbe essere appropriata una relazione di replica asincrona. Ad esempio, se un'applicazione di analisi richiede lo stesso set di dati o un sottoinsieme del set di dati per un'applicazione aziendale, quest'ultima può essere replicata tra i cloud.
• Database sincronizzato in modo transazionale. Questi tipi di database ti consentono di rendere i dati disponibili a entrambe le parti dell'applicazione. Ogni aggiornamento di ciascuna applicazione è coerente a livello transazionale e disponibile immediatamente per entrambi i database (partizioni). I database sincronizzati in modo transazionale fungono da unico database distribuito.

Servizi distribuiti

Un servizio distribuito viene implementato ed eseguito in due o più posizioni di deployment. È possibile eseguire il deployment di tutte le istanze di servizio in tutte le località di deployment. In alternativa, è possibile implementare alcuni servizi in tutte le località e altri solo in una delle località, in base a fattori quali la disponibilità dell'hardware o il carico limitato previsto.

I dati in un database sincronizzato a livello transazionale sono coerenti in tutte le posizioni. Pertanto, un database di questo tipo è l'opzione migliore per eseguire il deployment delle istanze di servizio in tutte le località di deployment.

Quando utilizzi un database replicato in modo asincrono, esiste il rischio che lo stesso elemento di dati venga modificato contemporaneamente in due posizioni di deployment. Per determinare quale delle due modifiche in conflitto rappresenta lo stato finale coerente, è necessario implementare una strategia di risoluzione dei conflitti. Sebbene sia possibile implementare una strategia di risoluzione dei conflitti, non è sempre semplice e in alcuni casi è necessario un intervento manuale per ripristinare i dati in uno stato coerente.

Failover e riassegnazione del servizio distribuito

Se si verifica un errore in un'intera regione cloud, viene avviato il disaster recovery. Se un singolo servizio in un'applicazione di database stateful non funziona (non la regione o l'intera applicazione), il servizio deve essere recuperato e riavviato.

Un approccio iniziale per ripristino di emergenza consiste nel riavviare il servizio non riuscito nella posizione di deployment originale (un approccio di riavvio sul posto). Tecnologie come Kubernetes riavviano automaticamente un servizio in base alla sua configurazione.

Tuttavia, se questo approccio di riavvio sul posto non va a buon fine, un'alternativa è riavviare il servizio in una posizione secondaria. Il servizio esegue il failover dalla posizione principale a una posizione secondaria. Se l'applicazione viene implementata come insieme di servizi distribuiti, il failover di un singolo servizio può avvenire in modo dinamico.

Dal punto di vista del database, il riavvio del servizio nella posizione di deployment originale non richiede un deployment specifico del database. Quando un servizio viene spostato in una posizione di deployment alternativa e il servizio accede al database, si applicano gli stessi modelli di preparazione discussi in Servizi distribuiti in precedenza in questo documento.

Se un servizio viene trasferito temporaneamente e se latenze più elevate sono accettabili per un'azienda durante il trasferimento, il servizio potrebbe accedere al database nelle diverse località di deployment. Sebbene il servizio venga spostato, continua ad accedere al database nello stesso modo in cui lo farebbe dalla posizione di deployment originale.

Deployment dipendente dal contesto

In generale, un singolo deployment dell'applicazione per servire tutti i client dell'applicazione include tutti i servizi e i database dell'applicazione. Tuttavia, esistono casi d'uso eccezionali. Una singola implementazione dell'applicazione può servire solo un sottoinsieme di client (in base a criteri specifici), il che significa che è necessaria più di un'implementazione dell'applicazione. Ogni deployment gestisce un sottoinsieme diverso di clienti e tutti i deployment insieme gestiscono tutti i clienti.

Di seguito sono riportati esempi di casi d'uso per un deployment dipendente dal contesto:

• Quando viene eseguito il deployment di un'applicazione multitenant per la quale viene eseguito il deployment di un'applicazione per tutti i tenant di piccole dimensioni, viene eseguito il deployment di un'altra applicazione per ogni 10 tenant di medie dimensioni e viene eseguito il deployment di un'applicazione per ogni tenant premium.
• Quando è necessario separare i clienti, ad esempio i clienti aziendali e i clienti governativi.
• Quando è necessario separare gli ambienti di sviluppo, gestione temporanea e produzione.

Dal punto di vista del database, è possibile eseguire il deployment di un database per ogni deployment dell'applicazione in una strategia di deployment one-to-one. Come mostrato nel diagramma seguente, questa strategia è un approccio semplice in cui vengono creati dati partizionati perché ogni deployment ha il proprio set di dati.

Il diagramma precedente mostra quanto segue:

• Una configurazione con tre deployment di un'applicazione.
• Ogni set di dati ha il proprio database.
• Non vengono condivisi dati tra le implementazioni.

In molte situazioni, la strategia di implementazione uno a uno è la più appropriata, ma esistono alternative.

In caso di multi-tenancy, gli inquilini potrebbero essere trasferiti. Un piccolo tenant potrebbe diventare un tenant medio e dover essere trasferito a un'altra applicazione. In questo caso, le implementazioni di database separate richiedono la migrazione del database. Se viene implementato un database distribuito e viene utilizzato da tutte le implementazioni contemporaneamente, tutti i dati dei tenant risiedono in un unico sistema di database. Per questo motivo, lo spostamento di un tenant tra database non richiede la migrazione del database. Il seguente diagramma mostra un esempio di questo tipo di database:

Il diagramma precedente mostra quanto segue:

• Tre deployment di un'applicazione.
• Tutti i deployment condividono un unico database distribuito.
• Le applicazioni possono accedere a tutti i dati in ogni deployment.
• Non è stata implementata alcuna partizione dei dati.

Se un'azienda sposta spesso i tenant nell'ambito delle operazioni del ciclo di vita, la replica del database potrebbe essere un'alternativa utile. Con questo approccio, i dati del tenant vengono replicati tra i database prima della migrazione del tenant. In questo caso, vengono utilizzati database indipendenti per implementazioni di applicazioni diverse e configurati per la replica solo immediatamente prima e durante la migrazione del tenant. Il diagramma seguente mostra una replica temporanea tra due deployment dell'applicazione durante una migrazione del tenant.

Il diagramma precedente mostra tre deployment di un'applicazione con tre database separati che contengono i dati associati a ogni deployment. Per eseguire la migrazione dei dati da un database a un altro, è possibile configurare la migrazione temporanea del database.

Portabilità delle applicazioni

La portabilità delle applicazioni garantisce che un'applicazione possa essere implementata in diverse posizioni di deployment, in particolare in cloud diversi. Questa portabilità garantisce che un'applicazione possa essere migrata in qualsiasi momento, senza la necessità di riprogettazione specifica per la migrazione o sviluppo di applicazioni aggiuntivo per prepararsi a una migrazione.

Per garantire la portabilità dell'applicazione, puoi utilizzare uno dei seguenti approcci, descritti più avanti in questa sezione:

• Portabilità basata sul sistema
• Compatibilità API
• Portabilità basata sulle funzionalità

La portabilità basata sul sistema utilizza gli stessi componenti tecnici utilizzati in tutte le implementazioni possibili. Per garantire la portabilità basata sul sistema, ogni tecnologia deve essere disponibile in tutte le potenziali posizioni di deployment. Ad esempio, se un database come PostgreSQL è un candidato, la sua disponibilità in tutte le potenziali posizioni di deployment deve essere verificata per il periodo di tempo previsto. Lo stesso vale per tutte le altre tecnologie, ad esempio i linguaggi di programmazione e le tecnologie dell'infrastruttura. Come mostrato nel seguente diagramma, questo approccio stabilisce un insieme di funzionalità comuni in tutte le posizioni di deployment in base alla tecnologia.

Il diagramma precedente mostra un deployment di applicazioni portatili in cui l'applicazione si aspetta esattamente lo stesso sistema di database in ogni posizione in cui viene eseguito il deployment. Poiché in ogni località viene utilizzato lo stesso sistema di database, l'applicazione è portabile. L'applicazione può prevedere che lo stesso sistema di database venga utilizzato in tutto il deployment. Pertanto, si può presumere la stessa interfaccia e lo stesso comportamento del sistema di database.

Nel contesto dei database, nel sistema di compatibilità delle API, il client utilizza una libreria di accesso al database specifica (ad esempio, una libreria client MySQL) per garantire di potersi connettere a qualsiasi implementazione conforme che potrebbe essere disponibile in un ambiente cloud. Il seguente diagramma illustra la compatibilità dell'API.

Il diagramma precedente mostra la portabilità dell'applicazione in base all'API del sistema di database anziché al sistema di database. Sebbene i sistemi di database possano essere diversi in ciascuna delle posizioni, l'API è la stessa ed espone la stessa funzionalità. L'applicazione è portabile perché può utilizzare la stessa API in ogni posizione, anche se il sistema di database sottostante è una tecnologia di database diversa.

Nella portabilità basata sulla funzionalità, potrebbero essere utilizzate tecnologie diverse in cloud diversi che forniscono la stessa funzionalità. Ad esempio, potrebbe essere possibile limitare l'utilizzo dei database al modello relazionale. Poiché qualsiasi sistema di database relazionale può supportare l'applicazione, è possibile utilizzare diversi sistemi di database su versioni diverse in cloud diversi senza influire sulla portabilità dell'applicazione. Uno svantaggio della portabilità basata sulle funzionalità è che può utilizzare solo le parti del modello di database supportate da tutti i sistemi di database relazionali. Invece di un sistema di database compatibile con tutti i cloud, deve essere utilizzato un modello di database. Il seguente diagramma mostra un'architettura di esempio per la portabilità basata sulla funzionalità.

Come mostrato nel diagramma precedente, l'API del sistema di database e il sistema di database potrebbero essere diversi in ogni località. Per garantire la portabilità, l'applicazione deve utilizzare solo le parti di ogni sistema di database e di ogni API disponibili in ogni località. Poiché in ogni località è comunemente disponibile solo un sottoinsieme di ciascun sistema di database, l'applicazione deve limitare il proprio utilizzo a questo sottoinsieme.

Per garantire la portabilità di tutte le opzioni in questa sezione, l'architettura completa deve essere implementata continuamente in tutte le località di destinazione. Tutti i casi di test delle unità e del sistema devono essere eseguiti in base a questi deployment. Questi sono requisiti essenziali per rilevare e risolvere tempestivamente i cambiamenti nelle infrastrutture e nelle tecnologie.

Prevenzione della dipendenza dal fornitore

La prevenzione della dipendenza da un fornitore contribuisce a mitigare il rischio di dipendenza da una tecnologia e da un fornitore specifici. È simile superficialmente alla portabilità delle applicazioni. La prevenzione della dipendenza dal fornitore si applica a tutte le tecnologie utilizzate, non solo ai servizi cloud. Ad esempio, se MySQL viene utilizzato come sistema di database e installato su macchine virtuali nei cloud, non esiste una dipendenza dal punto di vista del cloud, ma esiste una dipendenza da MySQL. Un'applicazione portatile tra i cloud potrebbe comunque dipendere da tecnologie fornite da fornitori diversi dal cloud.

Per evitare la dipendenza dai fornitori, tutte le tecnologie devono essere sostituibili. Per questo motivo, è necessaria un'astrazione completa e strutturata di tutte le funzionalità dell'applicazione in modo che ogni servizio dell'applicazione possa essere reimplementato in una base tecnologica diversa senza influire sul modo in cui l'applicazione viene implementata. Dal punto di vista del database, questa astrazione può essere eseguita separando l'utilizzo di un modello di database da un particolare sistema di gestione del database.

Sistema di gestione di database di produzione esistente

Sebbene molte applicazioni multi-cloud vengano sviluppate con sistemi di database come parte della loro progettazione, molte aziende sviluppano applicazioni multi-cloud nell'ambito del loro impegno per la modernizzazione delle applicazioni. Queste applicazioni vengono sviluppate partendo dal presupposto che l'applicazione appena progettata e implementata acceda ai database esistenti.

Esistono molti motivi per non incorporare i database esistenti in un progetto di modernizzazione. Potrebbero essere in uso funzionalità specifiche non disponibili in altri sistemi di database. Un'azienda potrebbe disporre di database con processi di gestione complessi e consolidati, il che rende impraticabile o antieconomico il passaggio a un sistema diverso. In alternativa, un'azienda potrebbe scegliere di modernizzare un'applicazione nella prima fase e il database nella seconda fase.

Quando un'azienda utilizza un sistema di database esistente, il progettista dell'applicazione multicloud deve decidere se sarà l'unico database utilizzato o se è necessario aggiungere un sistema di database diverso per diverse posizioni di deployment. Ad esempio, se un database viene utilizzato on-premise e l'applicazione deve essere eseguita anche in Google Cloud, è necessario valutare se i servizi applicativi di cui è stato eseguito il deployment su Google Cloud accedono al database on-premise. In alternativa, se un secondo database deve essere implementato sia in Google Cloud sia per i servizi applicativi in esecuzione in locale.

Se viene eseguito il deployment di un secondo database in Google Cloud, il caso d'uso potrebbe essere lo stesso di quelli descritti in Cloud bursting o Servizi distribuiti. In entrambi i casi, la stessa discussione sul database si applica come in queste sezioni. Tuttavia, è limitata alla funzionalità cross-location supportata dal database on-premise esistente, ad esempio sincronizzazione e replica.

Pattern di deployment

I casi d'uso descritti in questo documento sollevano una domanda comune dal punto di vista del database: se i database si trovano in più di una località di deployment, qual è la loro relazione?

I principali tipi di relazioni (modelli di deployment), che vengono discussi nella sezione successiva, sono i seguenti:

• Partizionato senza dipendenza tra database
• Replica unidirezionale asincrona
• Replica bidirezionale con risoluzione dei conflitti
• Sistema distribuito sincronizzato completamente attivo-attivo

È possibile mappare ogni caso d'uso in questo documento a uno o più dei quattro pattern di deployment.

Nella discussione che segue, si presuppone che i client accedano direttamente ai servizi dell'applicazione. A seconda del caso d'uso, potrebbe essere necessario un bilanciatore del carico per indirizzare dinamicamente l'accesso client alle applicazioni, come mostrato nel seguente diagramma.

Nel diagramma precedente, un bilanciatore del carico cloud indirizza le chiamate client a una delle posizioni disponibili. Il bilanciatore del carico garantisce l'applicazione delle norme di bilanciamento del carico e che i client vengano indirizzati alla posizione corretta dell'applicazione e del relativo database.

Partizionato senza dipendenza tra database

Questo pattern di deployment è il più semplice di tutti quelli descritti in questo documento: ogni posizione o cloud ha un database e i database contengono set di dati partizionati che non dipendono l'uno dall'altro. Un elemento di dati viene archiviato in un solo database. Ogni partizione di dati si trova nel proprio database. Un esempio di questo pattern è un'applicazione multi-tenant in cui un set di dati si trova in un database o nell'altro. Il seguente diagramma mostra due applicazioni completamente partizionate.

Come mostra il diagramma precedente, un'applicazione viene implementata in due posizioni, ognuna responsabile di una partizione dell'intero set di dati. Ogni elemento di dati si trova in una sola delle posizioni, garantendo un set di dati partizionato senza alcuna replica tra le due.

Un pattern di deployment alternativo per i database partizionati prevede che il set di dati sia completamente partizionato, ma comunque archiviato nello stesso database. Esiste un solo database contenente tutti i set di dati. Anche se i set di dati sono archiviati nello stesso database, sono completamente separati (partizionati) e una modifica a uno non causa modifiche a un altro. Il seguente diagramma mostra due applicazioni che condividono un unico database.

Il diagramma precedente mostra quanto segue:

• Due deployment di applicazioni che condividono un database comune, che si trova nella prima posizione.
• Ogni applicazione può accedere a tutti i dati nell'implementazione perché il set di dati non è partizionato.

Replica unidirezionale asincrona

Questo pattern di deployment ha un database principale che viene replicato in uno o più database secondari. Il database secondario può essere utilizzato per l'accesso in lettura, ma l'applicazione deve tenere conto del potenziale ritardo di replica. Un esempio di questo pattern si verifica quando il database migliore per un determinato caso d'uso viene utilizzato come database principale e il database secondario viene utilizzato per l'analisi. Il seguente diagramma mostra due applicazioni che accedono a database replicati in modo unidirezionale.

Come mostrato nel diagramma precedente, uno dei due database è una replica dell'altro. La freccia nel diagramma indica la direzione di replica: i dati del sistema di database nella località 1 vengono replicati nel sistema di database nella località 2.

Replica bidirezionale con risoluzione dei conflitti

Questo pattern di deployment ha due database primari che vengono replicati in modo asincrono l'uno nell'altro. Se gli stessi dati vengono scritti contemporaneamente in ogni database (ad esempio, la stessa chiave primaria), può verificarsi un conflitto di scrittura-scrittura. A causa di questo rischio, deve essere in atto una risoluzione dei conflitti per determinare quale stato è l'ultimo durante la replica. Questo pattern può essere utilizzato in situazioni in cui la possibilità di un conflitto di scrittura-scrittura è rara. Il seguente diagramma mostra due applicazioni che accedono a database replicati in modo bidirezionale.

Come mostrato nel diagramma precedente, ogni database viene replicato nell'altro database. Le due repliche sono indipendenti l'una dall'altra, come indicato nel diagramma da due frecce blu separate. Poiché le due repliche sono indipendenti, può verificarsi un conflitto se per caso lo stesso elemento di dati viene modificato da ciascuna delle applicazioni e replicato contemporaneamente. In questo caso, deve essere risolto il conflitto.

Sistema distribuito sincronizzato completamente attivo-attivo

Questo pattern di deployment ha un unico database con una configurazione attiva-attiva (anche principale-principale). In una configurazione active-active, un aggiornamento dei dati in qualsiasi database principale è coerente a livello transazionale e replicato in modo sincrono. Un esempio di caso d'uso per questo pattern è il calcolo distribuito. Il seguente diagramma mostra due applicazioni che accedono a un database principale-principale completamente sincronizzato.

Come mostra il diagramma precedente, questa disposizione garantisce che ogni applicazione acceda sempre all'ultimo stato coerente, senza ritardi o rischi di conflitti. Una modifica in un database è immediatamente disponibile nell'altro database. Qualsiasi modifica viene applicata a entrambi i database quando viene eseguito il commit di una transazione di modifica.

Categorizzazione del sistema di database

Non tutti i sistemi di gestione dei database possono essere utilizzati altrettanto bene per i pattern di deployment descritti in questo documento. A seconda del caso d'uso, potrebbe essere possibile implementare un solo pattern di deployment o una combinazione di pattern di deployment con solo un sottoinsieme di sistemi di database.

Nella sezione seguente, i diversi sistemi di database sono classificati e mappati ai quattro pattern di deployment.

È possibile classificare i database in base a diverse dimensioni, come modello dei dati, architettura interna, modello di deployment e tipi di transazione. Nella sezione successiva, ai fini della gestione dei database multicloud, vengono utilizzate due dimensioni:

• Architettura di deployment. L'architettura di come un sistema di gestione del database viene implementato sulle risorse dei cloud (ad esempio, motori di calcolo o gestiti dal cloud).
• Modello di distribuzione. Il modello di distribuzione supportato da un sistema di database (ad esempio, singola istanza o completamente distribuito).

Queste due dimensioni sono le più pertinenti nel contesto dei casi d'uso multicloud e possono supportare i quattro pattern di deployment derivati dai casi d'uso del database multicloud. Una classificazione comune si basa sui modelli di dati supportati da un sistema di gestione di database. Alcuni sistemi supportano un solo modello (ad esempio, un modello a grafo). Altri sistemi supportano più modelli di dati contemporaneamente (ad esempio, modelli relazionali e di documenti). Tuttavia, nel contesto della gestione dei database multicloud, questa classificazione non è pertinente perché le applicazioni multicloud possono utilizzare qualsiasi modello di dati per il loro deployment multicloud.

Sistema di database per architettura di deployment

La gestione di database multicloud include le seguenti quattro classi principali di architettura di deployment per i sistemi di gestione dei database:

• Database cloud integrati. I database cloud integrati sono progettati, creati e ottimizzati per funzionare con la tecnologia cloud. Ad esempio, alcuni sistemi di database utilizzano Kubernetes come piattaforma di implementazione e funzionalità di Kubernetes. CockroachDB e YugaByte sono esempi di questo tipo di database. Possono essere implementati in qualsiasi cloud che supporta Kubernetes.
• Database gestiti dal provider cloud. I database gestiti dal provider cloud sono basati su una tecnologia specifica del provider cloud e sono un servizio di database gestito da un provider cloud specifico. Spanner, Bigtable, Firestore e AlloyDB per PostgreSQL sono esempi di questo tipo di database. I database gestiti dal provider cloud sono disponibili solo nel cloud del provider cloud e non possono essere installati ed eseguiti altrove. Tuttavia, AlloyDB per PostgreSQL è completamente compatibile con PostgreSQL.
• Database pre-cloud. I database pre-cloud esistevano prima dello sviluppo della tecnologia cloud (a volte per molto tempo) e di solito vengono eseguiti su hardware bare metal e macchine virtuali (VM). PostgreSQL, MySQL e SQL Server sono esempi di questo tipo di database. Questi sistemi possono essere eseguiti su qualsiasi cloud che supporti le VM o l'hardware bare metal richiesti.
• Database gestiti dai partner cloud. Alcuni cloud pubblici hanno partner di database che installano e gestiscono i database dei clienti nel cloud pubblico. Per questo motivo, i clienti non devono gestire personalmente questi database. MongoDB Atlas, MariaDB, e ScyllaDB sono esempi di questo tipo di database.

Esistono alcune varianti di queste categorie principali. Ad esempio, un fornitore di database che implementa un database creato per il cloud potrebbe anche fornire un'installazione su una tecnologia creata per il cloud e un'offerta gestita ai clienti nel cloud fornito dal fornitore. Questo approccio è equivalente a quello in cui il fornitore fornisce un cloud pubblico che supporta solo il proprio database come unico servizio.

I database pre-cloud potrebbero anche trovarsi in container ed essere implementabili in un cluster Kubernetes. Tuttavia, questi database non utilizzano funzionalità specifiche di Kubernetes come scalabilità, multi-servizio o deployment multi-pod.

I fornitori di database possono collaborare con più di un cloud provider pubblico contemporaneamente, offrendo il proprio database come database gestito dal partner cloud in più di un cloud pubblico.

Sistema di database per modello di distribuzione

I diversi sistemi di gestione dei database vengono implementati in base ai modelli di distribuzione nell'architettura di un database. I modelli per i database sono i seguenti:

• Singola istanza. Una singola istanza di database viene eseguita su una VM o un container e funge da sistema centralizzato. Questo sistema gestisce tutto l'accesso al database. Poiché la singola istanza non può essere connessa a nessun'altra istanza, il sistema di database non supporta la replica.
• Multi-instance active-passive. In questa architettura comune, diverse istanze di database sono collegate tra loro. Il collegamento più comune è una relazione attiva-passiva in cui un'istanza è l'istanza di database attiva che supporta entrambe le istanze e le operazioni di lettura e scrittura. Uno o più sistemi passivi sono di sola lettura e ricevono tutte le modifiche al database dal sistema primario in modo sincrono o asincrono. I sistemi passivi possono fornire l'accesso in lettura. La modalità attiva-passiva è anche chiamata primario-secondario o origine-replica.
• Multi-instance active-active. In questa architettura relativamente rara, ogni istanza è un'istanza attiva. In questo caso, ogni istanza può eseguire transazioni di lettura e scrittura e garantire la coerenza dei dati. Per questo motivo, per evitare incoerenze nei dati, tutte le istanze vengono sempre sincronizzate.
• Multi-instance active-active con risoluzione dei conflitti. Si tratta anche di un sistema relativamente raro. Ogni istanza è disponibile per l'accesso in lettura e scrittura, tuttavia i database vengono sincronizzati in modalità asincrona. Sono consentiti aggiornamenti simultanei dello stesso elemento di dati, il che porta a uno stato incoerente. Una policy di risoluzione dei conflitti deve decidere quale stato è l'ultimo stato coerente.
• Sharding multi-istanza. Lo sharding si basa sulla gestione di partizioni di dati (disgiunte). Una singola istanza del database gestisce ogni partizione. Questa distribuzione è scalabile perché è possibile aggiungere dinamicamente più shard nel tempo. Tuttavia, le query cross-shard potrebbero non essere possibili perché questa funzionalità non è supportata da tutti i sistemi.

Tutti i modelli di distribuzione descritti in questa sezione possono supportare lo sharding e possono essere un sistema con sharding. Tuttavia, non tutti i sistemi sono progettati per fornire un'opzione di partizionamento. Lo sharding è un concetto di scalabilità e in genere non è pertinente per la selezione di database architetturali in ambienti multicloud.

I modelli di distribuzione sono diversi per i database gestiti dal cloud e dai partner. Poiché questi database sono legati all'architettura di un provider di servizi cloud, questi sistemi implementano architetture basate sulle seguenti posizioni di deployment:

• Sistema zonale. Un sistema di database gestito a livello di zona è associato a una zona. Quando la zona è disponibile, lo è anche il sistema di database. Tuttavia, se la zona non è più disponibile, non è possibile accedere al database.
• Sistema regionale. Un database gestito a livello regionale è associato a una regione ed è accessibile quando è accessibile almeno una zona. Qualsiasi combinazione di zone può diventare inaccessibile.
• Sistema cross-regionale. Un sistema cross-region è collegato a due o più regioni e funziona correttamente quando almeno una regione è disponibile.

Un sistema cross-region può supportare anche un sistema cross-cloud se il database può essere installato in tutti i cloud che un'azienda intende utilizzare.

Esistono altre alternative possibili alle architetture di database gestiti descritte in questa sezione. Un sistema regionale potrebbe condividere un disco tra due zone. Se una delle due zone diventa inaccessibile, il sistema di database può continuare nella zona rimanente. Tuttavia, se un'interruzione interessa entrambe le zone, il sistema di database non è disponibile anche se altre zone potrebbero essere ancora completamente online.

Mappare i sistemi di database ai pattern di deployment

La tabella seguente descrive la relazione tra i pattern di deployment e le architetture di deployment descritti in questo documento. I campi indicano le condizioni necessarie per una combinazione, in base al pattern di deployment e all'architettura di deployment.

Architettura di deployment	Pattern di deployment
	Partizionato senza dipendenza tra database	Replica unidirezionale asincrona	Replica bidirezionale con risoluzione dei conflitti	Sistema distribuito sincronizzato completamente attivo-attivo
Database cloud integrati	Possibile per tutti i cloud che forniscono tecnologia cloud integrata utilizzata dai sistemi di database. Se lo stesso database non è disponibile, è possibile utilizzare sistemi di database diversi.	Database cloud che fornisce la replica.	Database cloud che fornisce la replica bidirezionale.	Database cloud che fornisce la sincronizzazione primaria-primaria.
Database gestiti dal provider cloud	I sistemi di database possono essere diversi in cloud diversi.	La replica non deve essere il database gestito dal provider di servizi cloud (vedi Il ruolo della tecnologia di migrazione del database nei pattern di deployment).	Solo all'interno di un cloud, non tra cloud diversi, se il database fornisce la replica bidirezionale.	Solo all'interno di un cloud, non tra cloud diversi, se il database fornisce la sincronizzazione primaria-primaria.
Database pre-cloud	I sistemi di database possono essere uguali o diversi in cloud diversi.	La replica è possibile in più cloud.	Il sistema di database fornisce la replica bidirezionale e la risoluzione dei conflitti.	Il sistema di database fornisce la sincronizzazione principale-principale.
Database gestiti dai partner cloud	I sistemi di database possono essere diversi in cloud diversi. Se il partner fornisce un sistema di database gestito in tutti i cloud richiesti, è possibile utilizzare lo stesso database.	La replica non deve essere il database gestito dal provider cloud. Se il partner fornisce un sistema di database gestito in tutti i cloud richiesti, è possibile utilizzare lo stesso database.	Il sistema di database fornisce la replica bidirezionale e la risoluzione dei conflitti.	Il sistema di database fornisce la sincronizzazione principale-principale.

Se un sistema di database non fornisce la replica integrata, potrebbe essere possibile utilizzare la tecnologia di replica del database. Per maggiori informazioni, vedi Il ruolo della tecnologia di migrazione del database nei pattern di deployment.

La tabella seguente mette in relazione i pattern di deployment con i modelli di distribuzione. I campi indicano le condizioni per cui la combinazione è possibile dato un pattern di deployment e un modello di distribuzione.

Modello di distribuzione	Pattern di deployment
	Partizionato senza dipendenza tra database	Replica unidirezionale asincrona	Replica bidirezionale con risoluzione dei conflitti	Sistema distribuito sincronizzato completamente attivo-attivo
Singola istanza	Possibile con lo stesso sistema di database o con un sistema diverso nei cloud coinvolti.	Non applicabile	Non applicabile	Non applicabile
Attiva/passiva multi-istanza	Possibile con lo stesso sistema di database o con sistemi diversi nei cloud coinvolti.	La replica è possibile tra i cloud.	La replica è possibile tra i cloud.	Non applicabile
Multi-instance active-active	Possibile con lo stesso sistema di database o con sistemi diversi nei cloud coinvolti.	Non applicabile	Non applicabile	La sincronizzazione è possibile tra i cloud.
Multi-instance active-active con risoluzione dei conflitti	Possibile con lo stesso sistema di database o con sistemi diversi nei cloud coinvolti.	Non applicabile	Non applicabile	Applicabile se la replica bidirezionale è possibile tra i cloud.

Alcune implementazioni di modelli di distribuzione che aggiungono un'ulteriore astrazione in base alla tecnologia del database sottostante non hanno un modello di distribuzione integrato, ad esempio Postgres-BDR, un sistema attivo-attivo. Questi sistemi sono inclusi nella tabella precedente nella rispettiva categoria. Da un punto di vista multicloud, non è importante come viene implementato un modello di distribuzione.

Migrazione e replica del database

A seconda del caso d'uso, un'azienda potrebbe dover eseguire la migrazione di un database da una posizione di deployment a un'altra. In alternativa, per l'elaborazione a valle, potrebbe essere necessario replicare i dati di un database in un'altra posizione. Nella sezione seguente, la migrazione e la replica del database sono descritte in maggior dettaglio.

Migrazione del database

La migrazione del database viene utilizzata quando un database viene spostato da una posizione di deployment a un'altra. Ad esempio, un database in esecuzione in un data center on-premise viene migrato per essere eseguito nel cloud. Al termine della migrazione, il database viene chiuso nel data center on-premise.

Gli approcci principali alla migrazione dei database sono i seguenti:

• Lift and shift. La VM e i dischi che eseguono le istanze del database vengono copiati nell'ambiente di destinazione così come sono. Una volta copiati, vengono avviati e la migrazione è completata.
• Esportazione e importazione, backup e ripristino. Entrambi gli approcci utilizzano la funzionalità del sistema di database per esternalizzare un database e ricrearlo nella posizione di destinazione. L'esportazione/importazione si basa in genere su un formato ASCII, mentre il backup e il ripristino si basano su un formato binario.
• Migrazione senza tempi di inattività. Con questo approccio, un database viene migrato mentre i sistemi applicativi accedono al sistema di origine. Dopo un caricamento iniziale, le modifiche vengono trasmesse dall'origine al database di destinazione utilizzando le tecnologie Change Data Capture (CDC). L'applicazione subisce tempi di inattività dal momento in cui viene arrestata sul sistema di database di origine fino al riavvio sul sistema di database di destinazione al termine della migrazione.

La migrazione del database diventa pertinente nei casi d'uso multicloud quando un database viene spostato da un cloud a un altro o da un tipo dimotore del databasee a un altro.

La migrazione del database è un processo complesso. Per ulteriori informazioni, consulta Migrazione del database: concetti e principi (parte 1) e Migrazione del database: concetti e principi (parte 2).

Le tecnologie di database integrate possono essere utilizzate per eseguire la migrazione del database, ad esempio esportazione e importazione, backup e ripristino o protocolli di replica integrati. Quando il sistema di origine e di destinazione sono sistemi di database diversi, le tecnologie di migrazione sono l'opzione migliore per la migrazione del database. Database Migration Service, Striim e Debezium sono esempi di tecnologie di migrazione dei database.

Replica dei database

La replica del database è simile alla migrazione del database. Tuttavia, durante la replica del database, il sistema di database di origine rimane in posizione mentre ogni modifica viene trasmessa al database di destinazione.

La replica del database è un processo continuo che invia le modifiche dal database di origine al database di destinazione. Quando questo processo è asincrono, le modifiche arrivano al database di destinazione dopo un breve ritardo. Se il processo è sincrono, le modifiche al sistema di origine vengono apportate al sistema di destinazione contemporaneamente e alle stesse transazioni.

Oltre a replicare un'origine in un database di destinazione, una pratica comune è quella di replicare i dati da un database di origine a un sistema di analisi di destinazione.

Come per la migrazione del database, se sono disponibili protocolli di replica, è possibile utilizzare la tecnologia di database integrata per la replica del database. Se non sono presenti protocolli di replica integrati, è possibile utilizzare tecnologie di replica come Datastream, Striim o Debezium.

Il ruolo della tecnologia di migrazione del database nei pattern di deployment

La tecnologia di database integrata per abilitare la replica non è generalmente disponibile quando vengono utilizzati sistemi di database diversi nei pattern di deployment, ad esempio la replica asincrona (eterogenea). In alternativa, è possibile implementare la tecnologia di migrazione del database per abilitare questo tipo di replica. Alcuni di questi sistemi di migrazione implementano anche la replica bidirezionale.

Se la tecnologia di migrazione o replica del database è disponibile per i sistemi di database utilizzati nelle combinazioni contrassegnate come "Non applicabile" nella Tabella 1 o nella Tabella 2 in Mapping dei sistemi di database ai pattern di deployment, potrebbe essere possibile utilizzarla per la replica del database. Il seguente diagramma mostra un approccio per la replica del database utilizzando una tecnologia di migrazione.

Nel diagramma precedente, il database nella località 1 viene replicato nel database nella località 2. Anziché una replica diretta del sistema di database, viene implementato un server di migrazione per eseguire la replica. Questo approccio viene utilizzato per i sistemi di database che non hanno funzionalità di replica del database integrate nella loro implementazione e che devono fare affidamento su un sistema separato dal sistema di database per implementare la replica.

Selezione del database multicloud

I casi d'uso del database multicloud combinati con la classificazione del sistema di database ti aiutano a decidere quali database sono più adatti a un determinato caso d'uso. Ad esempio, per implementare lo scenario d'uso in Portabilità dell'applicazione, sono disponibili due opzioni. La prima opzione consiste nell'assicurarsi che lo stessomotore del databasee sia disponibile in tutti i cloud. Questo approccio garantisce la portabilità del sistema. La seconda opzione è garantire che lo stessomodello dei datii e la stessa interfaccia di query siano disponibili per tutti i cloud. Sebbene i sistemi di database possano essere diversi, la portabilità viene fornita su un'interfaccia funzionale.

Gli alberi decisionali nelle sezioni seguenti mostrano i criteri decisionali per i casi d'uso del database multicloud in questo documento. Gli alberi decisionali suggeriscono il database migliore da prendere in considerazione per ogni caso d'uso.

Best practice per il sistema di database esistente

Se un sistema di database è in produzione, è necessario decidere se mantenerlo o sostituirlo. Il seguente diagramma mostra le domande da porre nel processo decisionale:

Le domande e le risposte nell'albero decisionale sono le seguenti:

• È in produzione un sistema di database?
  • Se non è in produzione alcun sistema di database, seleziona un sistema di database (vai alla sezione Decisione sulla gestione dei database multicloud).
  • Se un sistema di database è in produzione, valuta se deve essere mantenuto.
• Se un sistema di database è in produzione, valuta se deve essere mantenuto.
  • Se il sistema di database deve essere mantenuto, la decisione è presa e la procedura decisionale è completata.
  • Se il sistema di database deve essere modificato o se la decisione è ancora in fase di elaborazione, seleziona un sistema di database (vai a Decisione sulla gestione del database multicloud).

Decisione sulla gestione dei database multicloud

La seguente struttura decisionale è per un caso d'uso con un requisito di database multisede (incluso un deployment di database multicloud). Utilizza il pattern di deployment come base per i criteri decisionali.

Le domande e le risposte nell'albero decisionale sono le seguenti:

• I dati sono partizionati in database diversi senza alcuna dipendenza tra database?
  • In caso affermativo, è possibile selezionare sistemi di database uguali o diversi per ogni località.
  • In caso contrario, continua con la domanda successiva.
• È necessaria la replica asincrona unidirezionale?
  • In caso affermativo, valuta se un sistema di replica del database è accettabile.
    • In caso affermativo, seleziona sistemi di database uguali o diversi compatibili con il sistema di replica.
    • In caso contrario, seleziona un sistema di database che possa implementare un modello di distribuzione attivo-passivo.
    • In caso contrario, continua con la domanda successiva.
• Seleziona un sistema di database con istanze sincronizzate.
  • La risoluzione dei conflitti è accettabile?
    • In caso affermativo, seleziona un sistema di database con replica bidirezionale o un sistema di database attivo-attivo.
    • In caso contrario, seleziona un sistema attivo-attivo.

Se vengono implementati più casi d'uso multicloud, un'azienda deve decidere se utilizzare un unico sistema di database per supportare tutti i casi d'uso o più sistemi di database.

Se un'azienda vuole utilizzare un unico sistema di database per supportare tutti i casi d'uso, il sistema con la migliore sincronizzazione è la scelta migliore. Ad esempio, se è necessaria la replica unidirezionale e le istanze sincronizzate, la scelta migliore sono le istanze sincronizzate.

La gerarchia della qualità di sincronizzazione è (da nessuna a migliore): partizionata, replica unidirezionale, replica bidirezionale e replica completamente sincronizzata.

Best practice per l'implementazione

Questa sezione evidenzia le best practice da seguire quando scegli un database per la migrazione o lo sviluppo di applicazioni multicloud.

Sistema di gestione di database esistente

Può essere una buona pratica conservare un database e non apportare modifiche al sistema di database, a meno che non sia richiesto da un caso d'uso specifico. Per un'azienda con un sistema di gestione dei database consolidato e processi di sviluppo, operativi e di manutenzione efficaci, potrebbe essere meglio evitare di apportare modifiche.

Un caso d'uso di cloud bursting che non richiede un sistema di database nel cloud potrebbe non richiedere una modifica del database. Un altro caso d'uso è la replica asincrona in una posizione di deployment diversa all'interno dello stesso cloud o in un altro cloud. Per questi casi d'uso, un buon approccio è implementare un benchmark e verificare che la comunicazione tra località e la latenza soddisfino i requisiti dell'applicazione quando si accede al database.

Sistema di database come servizio Kubernetes

Se un'azienda sta valutando la possibilità di eseguire un sistema di database all'interno di Kubernetes come servizio basato su StatefulSets, devono essere presi in considerazione i seguenti fattori:

• Se il database fornisce il modello di database richiesto dall'applicazione.
• Fattori non funzionali che determinano come viene implementata l'operazionalizzazione in un sistema di database come servizio Kubernetes, ad esempio come viene eseguito lo scaling (aumento e riduzione), come vengono gestiti il backup e il ripristino e come viene reso disponibile il monitoraggio dal sistema. Per aiutarle a comprendere i requisiti di un sistema di database basato su Kubernetes, le aziende devono utilizzare le loro esperienze con i database come punto di confronto.
• Alta disponibilità e ripristino di emergenza. Per fornire alta disponibilità, il sistema deve continuare a funzionare quando si verifica un errore in una zona all'interno di una regione. Il database deve essere in grado di eseguire rapidamente il failover da una zona all'altra. Nello scenario migliore, il database ha un'istanza in esecuzione in ogni zona completamente sincronizzata per un RTO e un RPO pari a zero.
• Ripristino di emergenza per risolvere l'errore di una regione (o di un cloud). In uno scenario ideale, il database continua a operare in una seconda regione con un RPO e un RTO pari a zero. In uno scenario meno ideale, il database nella regione secondaria potrebbe non essere completamente aggiornato con tutte le transazioni del database primario.

Per determinare il modo migliore per eseguire un database in Kubernetes, un'analisi completa del database è un buon approccio, soprattutto quando il sistema deve essere paragonabile a un sistema in produzione al di fuori di Kubernetes.

Sistema di database indipendente da Kubernetes

Non è sempre necessario che un'applicazione implementata come servizi in Kubernetes abbia il database in esecuzione in Kubernetes contemporaneamente. Esistono molti motivi per cui un sistema di database deve essere eseguito al di fuori di Kubernetes, ad esempio processi consolidati, conoscenza del prodotto all'interno di un'azienda o indisponibilità. In questa categoria rientrano sia i provider cloud sia i database gestiti dai partner cloud.

È altrettanto possibile ed fattibile eseguire un database su Compute Engine. Quando selezioni un sistema di database, è buona prassi eseguire una valutazione completa del database per assicurarti che tutti i requisiti di un'applicazione siano soddisfatti.

Dal punto di vista della progettazione delle applicazioni, il pooling delle connessioni è un aspetto importante da tenere in considerazione. Un servizio applicativo che accede a un database potrebbe utilizzare internamente un pool di connessioni. L'utilizzo di un pool di connessioni è utile per l'efficienza e riduce la latenza. Le richieste vengono prelevate dal pool senza la necessità di essere avviate e non è necessario attendere la creazione delle connessioni. Se l'applicazione viene scalata aggiungendo istanze del servizio di applicazione, ogni istanza crea un pool di connessioni. Se vengono seguite le best practice, ogni pool pre-crea un insieme minimo di connessioni. Ogni volta che viene creata un'altra istanza del servizio applicazione per lo scaling dell'applicazione, vengono aggiunte connessioni al database. Dal punto di vista della progettazione, poiché i database non possono supportare un numero illimitato di connessioni, l'aggiunta di connessioni deve essere gestita per evitare il sovraccarico.

Miglior sistema di database rispetto alla portabilità del sistema di database

Quando selezionano i sistemi di database, le aziende scelgono spesso il sistema di database migliore per soddisfare i requisiti di un'applicazione. In un ambiente multicloud, è possibile selezionare il database migliore in ogni cloud e collegarli tra loro in base al caso d'uso. Se questi sistemi sono diversi, qualsiasi replica, unidirezionale o bidirezionale, richiede uno sforzo significativo. Questo approccio potrebbe essere giustificato se il vantaggio di utilizzare il sistema migliore supera l'impegno necessario per implementarlo.

Tuttavia, una buona pratica è considerare e valutare contemporaneamente un approccio per un sistema di database disponibile in tutti i cloud richiesti. Anche se un database di questo tipo potrebbe non essere la soluzione ideale, potrebbe essere molto più facile da implementare, gestire e mantenere.

Una valutazione simultanea del sistema di database dimostra i vantaggi e gli svantaggi di entrambi i sistemi di database, fornendo una base solida per la selezione.

Replica del sistema di database integrato e di quello esterno

Per i casi d'uso che richiedono un sistema di database in tutte le località di deployment (zone, regioni o cloud), la replica è una funzionalità importante. La replica può essere asincrona, bidirezionale o attiva/attiva completamente sincronizzata. Non tutti i sistemi di database supportano tutte queste forme di replica.

Per i sistemi che non supportano la replica come parte della loro implementazione, è possibile utilizzare sistemi come Striim per integrare l'architettura (come descritto in Migrazione del database).

Una best practice consiste nel valutare sistemi di gestione dei database alternativi per determinare i vantaggi e gli svantaggi di un sistema con replica integrata o di un sistema che richiede la tecnologia di replica.

Anche una terza classe di tecnologia svolge un ruolo in questo caso. Questa classe fornisce componenti aggiuntivi ai sistemi di database esistenti per fornire la replica. Un esempio è MariaDB Galera Cluster. Se il processo di valutazione lo consente, valutare questi sistemi è una buona pratica.

Database multimodello

I database multimodello forniscono una gestione dei dati flessibile e scalabile nel cloud e nelle applicazioni in tempo reale. I database multimodello supportano più modelli di dati come documenti, grafici, coppie chiave-valore, famiglie di colonne e relazioni in un'unica interfaccia di query e motore di archiviazione. Queste funzionalità offrono vantaggi come i seguenti:

• Gestione semplificata: gli sviluppatori gestiscono vari tipi di dati all'interno di un unico sistema di database, il che contribuisce a ridurre la complessità operativa e i costi generali.
• Sviluppo più rapido: i database multimodello offrono la flessibilità di utilizzare ilmodello dei datii ottimale per esigenze diverse. Questa flessibilità può accelerare lo sviluppo e aiutarti ad adattarti più rapidamente ai requisiti in evoluzione.
• Integrazione più semplice: un motore di archiviazione e un'interfaccia di query unificati riducono al minimo la complessità del collegamento e della sincronizzazione di database diversi.
• Query avanzate: gli sviluppatori possono eseguire query e combinare dati in diversi modelli, il che consente di ottenere approfondimenti più ricchi e funzionalità delle applicazioni più sofisticate.
• Risparmio sui costi: un numero inferiore di sistemi di database si traduce in costi inferiori per licenze, hardware e spese operative.
• Rendimento ottimizzato: scegliendo il modello dei dati più adatto per attività specifiche, puoi potenzialmente migliorare il rendimento dell'applicazione.

Ad esempio, Spanner offre funzionalità multimodello con supporto del dialetto PostgreSQL. Questa funzionalità ti consente di creare app intelligenti basate sull'AI utilizzando dati relazionali e NoSQL, eseguire query su relazioni complesse con Spanner Graph e utilizzare la ricerca vettoriale per la ricerca semantica.

Passaggi successivi

• Scopri di più sui pattern di architettura ibrida e multi-cloud.
• Scopri di più sui pattern per connettere altri fornitori di servizi cloud a Google Cloud.
• Scopri di più sulle architetture di monitoraggio e logging per deployment ibridi e multi-cloud su Google Cloud.
• Per ulteriori architetture di riferimento, diagrammi e best practice, esplora il Cloud Architecture Center.

Collaboratori

Autore: Alex Cârciu | Solutions Architect