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

Last reviewed 2022-10-28 UTC

Questo documento descrive le architetture di deployment, i casi d'uso e le best practice per la gestione di database multi-cloud. È rivolto ad architect e ingegneri che progettano e implementano applicazioni stateful all'interno e su più cloud.

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

Esistono varie tecnologie di database per cloud pubblici come Google Cloud, che si adattano a specifici casi d'uso multi-cloud. Per eseguire il deployment di un'applicazione in più regioni all'interno di un singolo cloud pubblico, un'opzione è utilizzare un cloud pubblico, un database multiregionale gestito dal provider come Spanner. Per eseguire il deployment di un'applicazione in modo che sia portabile su cloud pubblici, un database indipendente dalla piattaforma potrebbe essere una scelta migliore, come PostgreSQL.

Questo documento introduce la definizione di un'applicazione di database stateful seguita da un'analisi dei casi d'uso di database multi-cloud. Presenta quindi una classificazione del sistema di database dettagliata per le architetture di deployment multi-cloud in base ai casi d'uso.

Il documento introduce inoltre un albero decisionale per la selezione dei database che delinea i punti decisionali chiave per la selezione di una tecnologia di database adeguata. Si conclude con una discussione sulle best practice per la gestione di database multi-cloud.

Termini chiave e definizioni

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

Terminologia

• Cloud pubblico. Un cloud pubblico fornisce infrastruttura multi-tenant (generalmente globale) e servizi che i clienti possono utilizzare per eseguire i loro 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 è la combinazione di un cloud pubblico con uno o più data center on-premise. I clienti del cloud ibrido possono combinare i servizi on-premise con servizi aggiuntivi forniti dal cloud pubblico.
• Multi-cloud. Un multi-cloud è una combinazione di vari cloud pubblici e data center on-premise. Un cloud ibrido è un sottoinsieme del multi-cloud.
• Località di deployment. Una località dell'infrastruttura è una località fisica in cui è possibile eseguire il deployment e carichi di lavoro, tra cui database e applicazioni. 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 multi-cloud, in questo documento viene utilizzata un'architettura delle applicazioni di database stateful generica, come mostrato nel diagramma seguente.

Il diagramma mostra i seguenti componenti:

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

Nel contesto di una discussione su un database multi-cloud, l'astrazione architetturale di un'applicazione stateful è costituita da un database, servizi per le applicazioni e client di applicazioni. Nell'implementazione di un'applicazione, fattori come l'uso dei sistemi operativi o dei linguaggi di programmazione utilizzati possono variare. Tuttavia, questi dettagli non influiscono sulla gestione del database multi-cloud.

Code e file come servizi di archiviazione dati

Per la persistenza dei dati, sono disponibili molte risorse di persistenza disponibili per i servizi delle applicazioni. Queste risorse includono database, code e file. Ogni risorsa di persistenza fornisce modelli dei dati di archiviazione e pattern di accesso specifici per questi modelli. Sebbene code, sistemi di messaggistica e file system siano utilizzati dalle applicazioni, nella sezione che segue ci concentreremo specificamente sui 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 multi-cloud 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ò essere all'interno di una zona o tra zone, regioni o cloud. Le connessioni possono esistere tra qualsiasi combinazione di località di deployment. Negli ambienti multi-cloud, il networking tra cloud è un aspetto importante e sono disponibili diverse opzioni. Per ulteriori informazioni sul networking tra cloud, consulta Connessione a Google Cloud: spiegazione delle opzioni di networking.

Nei casi d'uso illustrati nel presente documento, si presume quanto segue:

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

Da un punto di vista non funzionale, la dimensione della rete, ovvero la velocità effettiva e la latenza, potrebbe influire sulla latenza e la velocità effettiva del database. Da un punto di vista funzionale, il networking non ha generalmente alcun effetto.

Casi d'uso di database multi-cloud

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

Migrazione di applicazioni

Nel contesto della gestione di database multi-cloud, 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 provider cloud, modernizzare la tecnologia o ridurre il costo totale di proprietà (TCO).

Nella migrazione delle applicazioni, l'intento è interrompere la produzione nel cloud attuale e continuare la produzione nel cloud di destinazione al termine della migrazione. I servizi per le applicazioni devono essere eseguiti nel cloud di destinazione. Per implementare i servizi, è possibile utilizzare un approccio lift and shift. Con questo approccio, viene eseguito il deployment dello stesso codice nel cloud di destinazione. Per implementare nuovamente il servizio, è possibile utilizzare le moderne tecnologie cloud disponibili nel cloud di destinazione.

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

• lift and shift del database: se nel cloud di destinazione è disponibile lo stesso motore del database, è possibile eseguire il lift and shift del database per creare un deployment identico nel cloud di destinazione.
• Incremento del database e spostamento in equivalente gestito: è possibile eseguire la migrazione di un database autogestito a una versione gestita dello stesso motore del database, se il cloud di destinazione lo fornisce.
• Modernizzazione dei database: cloud diversi offrono tecnologie di database diverse. I database gestiti da un cloud provider potrebbero offrire vantaggi come accordi sul livello del servizio (SLA) più rigidi, 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 a quello di destinazione. Sebbene sia possibile seguire un approccio di esportazione e importazione che comporta tempi di inattività, è preferibile una migrazione con tempi di inattività minimi o pari a zero. Questo approccio riduce al minimo i tempi di inattività delle applicazioni e ha il minimo impatto su un'azienda e sui suoi clienti.

Ripristino di emergenza

Il ripristino di emergenza si riferisce alla capacità di un'applicazione di continuare a fornire servizi ai client dell'applicazione durante un'interruzione di una regione. Per garantire il ripristino di emergenza, è necessario eseguire il deployment di un'applicazione in almeno due regioni ed essere pronta per l'esecuzione in qualsiasi momento. In produzione, l'applicazione viene eseguita nell'area geografica principale. Tuttavia, in caso di interruzione, una regione secondaria diventa la regione principale. Di seguito sono riportati diversi modelli di idoneità per il ripristino di emergenza:

• Hot standby. Il deployment dell'applicazione è stato eseguito in due o più regioni (primarie e secondarie) e l'applicazione funziona completamente in ogni regione. In caso di errore della regione principale, l'applicazione nella regione secondaria può gestire immediatamente il traffico client dell'applicazione.
• Cold standby. L'applicazione è in esecuzione nella regione principale, ma è pronta per l'avvio in una regione secondaria (ma non è in esecuzione). In caso di errore della regione principale, l'applicazione viene avviata nella regione secondaria. Un'interruzione dell'applicazione si verifica finché l'applicazione non è in grado di essere eseguita e di fornire tutti i servizi ai client delle applicazioni.
• Nessuno standby. In questo modello, il codice dell'applicazione è pronto per il deployment, ma non ne è ancora stato eseguito il deployment nella regione secondaria (quindi non utilizza risorse di cui è stato eseguito il deployment). In caso di interruzione di una regione principale, il primo deployment dell'applicazione deve avvenire nella regione secondaria. Questo deployment mette l'applicazione nello stesso stato di un Cold standby, il che significa che deve essere avviata. In questo approccio, l'interruzione dell'applicazione è più lunga rispetto al caso in standby a freddo perché deve essere eseguito prima il deployment dell'applicazione, inclusa la creazione di risorse cloud.

Dal punto di vista dei database, i modelli di idoneità discussi nell'elenco precedente corrispondono ai seguenti approcci ai database:

• Database sincronizzato transazionale: Questo database corrisponde al modello hot standby. Ogni transazione nella regione principale è sottoposta a commit nel 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, l'RPO (Recovery Point Objective) e l'RTO (Recovery Time Objective) sono entrambi pari a zero.
• Database replicato in modo asincrono. Questo database corrisponde anche al modello hot standby. Poiché la replica del database dall'area geografica principale a quella secondaria è asincrona, è possibile che in caso di errore della regione principale, alcune transazioni vengano replicate nella regione secondaria. Anche se il database nella regione secondaria è pronto per il carico di produzione, potrebbe non disporre dei dati più aggiornati. Per questo motivo, l'applicazione potrebbe comportare la 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 Cold standby. Il database viene creato senza dati. In caso di errore della regione principale, i dati devono essere caricati nel database inattivo. Per abilitare questa azione, è necessario eseguire un backup regolare nella regione principale e trasferirlo nella regione secondaria. Il backup può essere completo o incrementale, a seconda di ciò che è supportato dal motore del database. In entrambi i casi, il database viene impostato nuovamente sull'ultimo backup e, dal punto di vista dell'applicazione, molte transazioni possono andare perse rispetto alla regione principale. Sebbene questo approccio possa essere conveniente, il valore è ridotto dal rischio che tutte le transazioni dall'ultimo backup disponibile vadano perse a causa dello stato del database non aggiornato.
• Nessun database. Questo modello equivale alla richiesta senza standby. Nella regione secondaria non è installato alcun database. Se l'errore della regione principale non va a buon fine, è necessario creare un database. Dopo la creazione del database, come nel caso del database inattivo, deve essere caricato con i dati prima di essere disponibile per l'applicazione.

Gli approcci per il ripristino di emergenza descritti in questo documento si applicano anche se vengono utilizzati un cloud primario e uno secondario al posto di un'area geografica principale e secondaria. La differenza principale è che, a causa dell'eterogeneità della rete tra i cloud, la latenza tra i cloud potrebbe aumentare rispetto alla distanza della rete tra le regioni all'interno di un cloud.

La probabilità di un errore dell'intero cloud è inferiore a quella di un errore di una regione. Tuttavia, potrebbe essere comunque utile per le aziende distribuire un'applicazione su due cloud. Questo approccio può contribuire a proteggere un'azienda dai guasti o a rispettare le normative aziendali o di settore.

Un altro approccio per il ripristino di emergenza consiste nell'avere una regione principale e una secondaria, oltre a un cloud primario e secondario. Questo approccio consente alle aziende di scegliere il processo di ripristino di emergenza migliore per risolvere 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 bursting del cloud si riferisce a una configurazione che consente lo scale up del traffico client delle applicazioni in diverse località di deployment. Un'applicazione esegue il bursting quando la domanda di capacità aumenta e una località in standby fornisce capacità aggiuntiva. Una località principale supporta il traffico regolare, mentre una località in standby può fornire capacità aggiuntiva nel caso in cui il traffico del client dell'applicazione aumenti oltre a quello supportato dalla località principale. Sia la località principale sia quella in standby hanno il deployment delle istanze del servizio delle applicazioni.

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

Per il supporto del database, sono disponibili le seguenti opzioni:

• Deployment della località principale. In questo deployment, il deployment del database viene eseguito solo nella località principale e non in quella in standby. Quando un'applicazione esegue il burst, l'applicazione nella località in standby accede al database nella località principale.
• Deployment nella località principale e in standby. Questo deployment supporta sia la località principale sia quella in standby. Il deployment di un'istanza di database viene eseguito in entrambe le località e le istanze del servizio dell'applicazione nella località in questione sono accessibili, soprattutto in caso di bursting. Come nel caso del Ripristino di emergenza all'interno e tra i cloud, i due database possono essere sincronizzati in modo transazionale o asincrono. Nella sincronizzazione asincrona, potrebbe verificarsi un ritardo. Se vengono eseguiti aggiornamenti nella località in standby, questi devono essere propagati alla località principale. Se sono possibili aggiornamenti simultanei in entrambe le posizioni, deve essere implementata 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 utilizzabile nei cloud pubblici quando i dati devono rimanere all'interno di un paese. In 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, rispettando al contempo i vincoli delle risorse nelle regioni delle regioni del cloud pubblico.

Utilizzo del servizio cloud all'avanguardia

Alcune applicazioni richiedono servizi e prodotti cloud specializzati che non sono disponibili in un singolo cloud. Ad esempio, un'applicazione potrebbe eseguire l'elaborazione della logica di business dei dati aziendali in un cloud e l'analisi dei dati aziendali in un altro cloud. In questo caso d'uso, il deployment delle parti di elaborazione della logica di business e di analisi dell'applicazione viene eseguito 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 il proprio database (partizione separata) e nessuno dei database è collegato direttamente l'uno all'altro. L'applicazione che gestisce i dati scrive tutti i dati che devono essere disponibili in entrambi i database (partizioni) due volte.
• 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, il secondo può essere replicato tra i cloud.
• Database sincronizzato transazionale: Questi tipi di database consentono di rendere i dati disponibili a entrambe le parti dell'applicazione. Ogni aggiornamento di ciascuna applicazione è coerente dal punto di vista transazionale e disponibile immediatamente per entrambi i database (partizioni). I database sincronizzati a livello transazionale agiscono come un unico database distribuito.

Servizi distribuiti

Il deployment di un servizio distribuito viene eseguito ed eseguito in due o più località di deployment. È possibile eseguire il deployment di tutte le istanze di servizio in tutte le località di deployment. In alternativa, è possibile eseguire il deployment di 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 in modo transazionale sono coerenti in tutte le località. 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 asincrono, c'è il rischio che lo stesso elemento di dati venga modificato contemporaneamente in due località di deployment. Per determinare quale delle due modifiche in conflitto rappresenta lo stato coerente finale, è necessario implementare una strategia di risoluzione dei conflitti. Sebbene sia possibile implementare una risoluzione dei conflitti, non è sempre facile e a volte è necessario un intervento manuale per riportare i dati a uno stato coerente.

Relocation e failover di servizi distribuiti

Se si verifica un errore in un'intera regione cloud, viene avviato il ripristino di emergenza. In caso di errore di un singolo servizio in un'applicazione di database stateful (non dell'intera regione o dell'intera applicazione), il servizio deve essere recuperato e riavviato.

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

Tuttavia, se questo approccio di riavvio in loco non ha esito positivo, un'alternativa è riavviare il servizio in una posizione secondaria. Il servizio esegue il failover dalla sua località principale a una località secondaria. Se il deployment dell'applicazione viene eseguito 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 località di deployment originale non richiede un deployment specifico del database. Quando un servizio viene spostato in una posizione di deployment alternativa e accede al database, vengono applicati gli stessi modelli di idoneità descritti in Servizi distribuiti in precedenza in questo documento.

Se un servizio viene trasferito su base temporanea e se per un'azienda sono accettabili latenze più elevate durante lo spostamento, il servizio potrebbe accedere al database tra le località di deployment. Anche se il servizio viene trasferito, continua ad accedere al database come farebbe dalla località di deployment originale.

Deployment dipendente dal contesto

In generale, un singolo deployment dell'applicazione per gestire tutti i client delle applicazioni include tutti i servizi e i database delle applicazioni. Tuttavia, esistono casi d'uso eccezionali. Il deployment di un'applicazione singola può gestire solo un sottoinsieme di client (in base a criteri specifici), il che significa che è necessario eseguire più di un deployment di applicazioni. Ogni deployment gestisce un sottoinsieme diverso di client e tutti i deployment servono per tutti i client.

Ecco alcuni casi d'uso di esempio per un'implementazione dipendente dal contesto:

• Quando esegui il deployment di un'applicazione multi-tenant per cui viene eseguito il deployment di un'applicazione per tutti i tenant di piccole dimensioni, viene eseguito il deployment di un'altra applicazione ogni 10 tenant medi e di un'applicazione per ogni tenant premium.
• Quando c'è la necessità di separare i clienti, ad esempio, quelli aziendali da quelli della pubblica amministrazione.
• Quando è necessario separare gli ambienti di sviluppo, gestione temporanea e produzione.

Dal punto di vista dei 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 specifico.
• I dati non vengono condivisi tra i deployment.

In molte situazioni, il deployment one-to-one è la strategia più appropriata, ma ci sono alternative.

Nel caso dell'architettura multi-tenancy, i tenant potrebbero essere riposizionati. Un tenant di piccole dimensioni potrebbe trasformarsi in un tenant di livello medio e dover essere trasferito a un'altra applicazione. In questo caso, deployment di database separati richiedono la migrazione del database. Se viene eseguito il deployment di un database distribuito che viene utilizzato contemporaneamente da tutti i deployment, tutti i dati del tenant risiedono in un unico sistema di database. Per questo motivo, lo spostamento di un tenant tra i 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 è stato implementato il partizionamento 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. In questo approccio, i dati del tenant vengono replicati tra database prima di una migrazione del tenant. In questo caso, i database indipendenti vengono utilizzati per deployment di applicazioni diverse e sono configurati per la replica solo immediatamente prima e durante la migrazione del tenant. Il seguente diagramma mostra una replica temporanea tra due deployment delle applicazioni 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 rispettivo deployment. Per eseguire la migrazione dei dati da un database a un altro, è possibile configurare una migrazione temporanea del database.

Portabilità delle applicazioni

La portabilità delle applicazioni garantisce il deployment di un'applicazione in diverse posizioni, soprattutto in cloud diversi. Questa portabilità garantisce la possibilità di eseguire la migrazione di un'applicazione in qualsiasi momento, senza la necessità di una riprogettazione specifica della migrazione o di uno sviluppo aggiuntivo di applicazioni per prepararsi alla migrazione.

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

• Portabilità basata sul sistema
• Compatibilità delle API
• Portabilità basata sulla funzionalità

La portabilità basata sul sistema utilizza gli stessi componenti tecnici utilizzati in tutti i possibili deployment. Per garantire la portabilità basata sul sistema, ogni tecnologia deve essere disponibile in tutte le potenziali località di deployment. Ad esempio, se un database come PostgreSQL è candidato, la sua disponibilità in tutte le potenziali località di deployment deve essere verificata per il periodo di tempo previsto. Lo stesso vale per tutte le altre tecnologie, ad esempio linguaggi di programmazione e tecnologie di 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 il deployment di un'applicazione portabile in cui l'applicazione prevede lo stesso esatto sistema di database in ogni località in cui viene eseguito il deployment. Poiché in ogni località viene utilizzato lo stesso sistema di database, l'applicazione è portabile. L'applicazione può aspettarsi che verrà utilizzato lo stesso sistema di database in tutto il deployment. Pertanto, si può presumere che la stessa interfaccia e lo stesso comportamento del sistema di database siano uguali.

Nel contesto dei database, nel sistema di compatibilità delle API il client utilizza una libreria di accesso ai database specifica (ad esempio, una libreria client MySQL) per assicurarsi 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à delle applicazioni in base all'API del sistema di database anziché al sistema di database. Sebbene i sistemi di database possano essere diversi in ogni località, l'API è la stessa e offre la stessa funzionalità. L'applicazione è portabile perché può utilizzare la stessa API in ogni località, anche se il sistema di database sottostante è una tecnologia di database diversa.

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

Come mostra il 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 ogni API disponibili in ogni località. Poiché solo un sottoinsieme di ciascun sistema di database è comunemente disponibile in ciascuna località, l'applicazione deve limitare il proprio utilizzo a quel sottoinsieme.

Per garantire la portabilità di tutte le opzioni in questa sezione, è necessario eseguire il deployment continuo dell'architettura completa in tutte le località di destinazione. Tutti gli scenari di test delle unità e del sistema devono essere eseguiti su questi deployment. Si tratta di requisiti essenziali per individuare tempestivamente e risolvere i cambiamenti nelle infrastrutture e nelle tecnologie.

Prevenzione delle dipendenze del fornitore

La prevenzione della dipendenza del fornitore (lock-in) consente di ridurre il rischio di dipendenza da una tecnologia e un fornitore specifici. È simile alla portabilità delle applicazioni. La prevenzione delle dipendenze del 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 vi è alcuna dipendenza dal punto di vista del cloud, ma una dipendenza da MySQL. Un'applicazione portabile tra cloud potrebbe comunque dipendere da tecnologie fornite da diversi fornitori rispetto al cloud.

Per evitare la dipendenza dal fornitore, 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 su una base tecnologica diversa senza influire sull'implementazione dell'applicazione. Dal punto di vista del database, questa astrazione può essere eseguita separando l'uso di un modello di database da un particolare sistema di gestione del database.

Sistema di gestione dei database di produzione esistente

Sebbene molte applicazioni multi-cloud vengano sviluppate con sistemi di database all'interno della propria progettazione, molte aziende sviluppano applicazioni multi-cloud nell'ambito del proprio impegno di modernizzazione delle applicazioni. Queste applicazioni sono sviluppate partendo dal presupposto che l'applicazione appena progettata e implementata acceda ai database esistenti.

Ci sono molti motivi per non incorporare i database esistenti in un'iniziativa di modernizzazione. Potrebbero essere in uso funzionalità specifiche che non sono disponibili in altri sistemi di database. Un'azienda potrebbe avere database con processi di gestione complessi e consolidati, rendendo inattuabile o antieconomico il passaggio a un sistema diverso. Oppure, un'azienda potrebbe scegliere di modernizzare un'applicazione nella prima fase e modernizzare il database nella seconda fase.

Quando un'azienda utilizza un sistema di database esistente, il designer dell'applicazione multi-cloud deve decidere se sarà l'unico database utilizzato o se è necessario aggiungere un sistema di database diverso per località di deployment diverse. Ad esempio, se un database viene utilizzato on-premise e l'applicazione deve essere eseguita anche in Google Cloud, è necessario valutare se i servizi per le applicazioni di cui è stato eseguito il deployment su Google Cloud accedono al database on-premise. Oppure, se è necessario eseguire il deployment di un secondo database sia in Google Cloud sia per i servizi delle applicazioni in esecuzione localmente.

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

Pattern di deployment

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

I principali tipi di relazioni (pattern di deployment), descritti nella prossima sezione, sono i seguenti:

• Partizionata 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 seguente, si presume che i client accedano direttamente ai servizi delle applicazioni. A seconda del caso d'uso, potrebbe essere necessario un bilanciatore del carico per indirizzare dinamicamente l'accesso client alle applicazioni, come illustrato nel seguente schema.

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

Partizionata senza dipendenza tra database

Questo pattern di deployment è il più semplice di tutti i pattern descritti in questo documento: ogni località o cloud ha un database e i database contengono set di dati partizionati che non dipendono l'uno dall'altro. Un elemento di dati è 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 uno o nell'altro database. Il seguente diagramma mostra due applicazioni completamente partizionate.

Come mostra il diagramma precedente, il deployment di un'applicazione viene eseguito in due posizioni, ciascuna responsabile di una partizione dell'intero set di dati. Ogni elemento di dati risiede in una sola delle località, garantendo un set di dati partizionato senza alcuna replica tra i due.

Un pattern di deployment alternativo per i database partizionati è il set di dati completamente partizionato, ma ancora archiviato nello stesso database. Esiste un solo database contenente tutti i set di dati. Sebbene i set di dati siano archiviati all'interno dello stesso database, sono completamente separati (partizionati) e una modifica a uno non causa modifiche in un altro. Il seguente diagramma mostra due applicazioni che condividono un singolo database.

Il diagramma precedente mostra quanto segue:

• Due deployment di applicazioni che condividono entrambi lo stesso database, che si trova nella prima posizione.
• Ogni applicazione può accedere a tutti i dati nel deployment 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. Un esempio di questo pattern è quando il database migliore per un particolare 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 unidirezionalmente.

Come mostra il diagramma precedente, uno dei due database è la 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 principali replicati l'uno all'altro in modo asincrono. Se gli stessi dati vengono scritti contemporaneamente in ogni database (ad esempio, la stessa chiave primaria), può causare un conflitto di scrittura-scrittura. A causa di questo rischio, deve essere attiva una risoluzione dei conflitti per determinare quale stato è l'ultimo stato 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 bidirezionale.

Come mostra il diagramma precedente, ogni database viene replicato nell'altro. Le due repliche sono indipendenti tra loro, 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 eseguita la risoluzione del conflitto.

Sistema distribuito sincronizzato completamente attivo-attivo

Questo pattern di deployment ha un singolo database con una configurazione di tipo attivo-attivo (anche primario-primario o master-master). In una configurazione attiva-attiva, un aggiornamento dei dati in qualsiasi database primario è coerente dal punto di vista transazionale e replicato in modo sincrono. Un esempio di caso d'uso di questo pattern è il computing distribuito. Il seguente diagramma mostra due applicazioni che accedono a un database primario-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 conflitto. Una modifica in un database è immediatamente disponibile nell'altro. Qualsiasi modifica si riflette in entrambi i database quando si verifica un commit di transazione modificato.

Classificazione del sistema di database

Non tutti i sistemi di gestione dei database possono essere utilizzati allo stesso modo 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 un solo sottoinsieme di sistemi di database.

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

Puoi classificare i database in base a dimensioni diverse, ad esempio modello dei dati, architettura interna, modello di deployment e tipi di transazioni. Nella sezione seguente, ai fini della gestione di database multi-cloud, vengono utilizzate due dimensioni:

• Architettura di deployment. L'architettura del deployment di un sistema di gestione di database su risorse cloud (ad esempio Compute Engine o gestite nel cloud).
• Modello di distribuzione. Il modello di distribuzione supportato da un sistema di database (ad esempio, a istanza singola o completamente distribuito).

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

Sistema di database per architettura di deployment

La gestione dei database multi-cloud 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 la funzionalità Kubernetes. CockroachDB e YugaByte sono esempi di questo tipo di database. e possono essere implementate in qualsiasi cloud che supporti Kubernetes.
• Database gestiti dal provider cloud. I database gestiti dal cloud provider sono basati su una tecnologia specifica del cloud provider e sono un servizio di database gestito da uno specifico cloud provider. Spanner e Bigtable sono esempi di questo tipo di database. I database gestiti dal cloud provider sono disponibili solo nel cloud del provider cloud e non possono essere installati ed eseguiti altrove.
• Database pre-cloud. I database pre-cloud esistono prima dello sviluppo della tecnologia cloud (a volte per molto tempo) e di solito vengono eseguiti su hardware e macchine virtuali (VM) bare metal. PostgreSQL e MySQL sono esempi di questo tipo di database. Questi sistemi possono essere eseguiti su qualsiasi cloud che supporti le macchine virtuali o l'hardware bare metal richiesti.
• Database gestiti da partner cloud. Alcuni cloud pubblici dispongono di partner di database che installano e gestiscono i database dei clienti nel cloud pubblico. Per questo motivo, i clienti non devono gestire autonomamente questi database. MongoDB Atlas e MariaDB 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 loro cloud fornito dal fornitore. Questo approccio è equivalente al fornitore che fornisce un cloud pubblico che supporta solo il proprio database come servizio singolo.

I database pre-cloud potrebbero essere anche all'interno di container e di cui è possibile eseguire il deployment in un cluster Kubernetes. Tuttavia, questi database non utilizzano funzionalità specifiche di Kubernetes come la scalabilità, il deployment multiservizio o il deployment di più pod.

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

Sistema di database per modello di distribuzione

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

• Istanza singola. Una singola istanza di database viene eseguita su una VM o su un container e funge da sistema centralizzato. Questo sistema gestisce tutti gli accessi ai database. Poiché la singola istanza non può essere connessa a nessun'altra istanza, il sistema di database non supporta la replica.
• Attivo-passivo multi-istanza. In questa architettura comune, diverse istanze di database sono collegate. Il collegamento più comune è una relazione attivo-passivo in cui un'istanza è quella del database attiva che supporta sia le istanze che le operazioni di scrittura e lettura. Uno o più sistemi passivi sono di sola lettura e ricevono tutte le modifiche del database da quello primario in modo sincrono o asincrono. I sistemi passivi possono fornire l'accesso in lettura. Il termine Attivo-Passivo è chiamato anche primario-secondario o master-slave.
• Attiva/attiva multi-istanza. In questa architettura relativamente insolita, ogni istanza è attiva. In questo caso, ogni istanza può eseguire transazioni di lettura e scrittura e fornire coerenza dei dati. Per questo motivo, per evitare incongruenze nei dati, tutte le istanze vengono sempre sincronizzate.
• Attiva-attiva multi-istanza con risoluzione dei conflitti. Anche questo è un sistema relativamente raro. Ogni istanza è disponibile per l'accesso in scrittura e in lettura, ma i database sono sincronizzati in modalità asincrona. Sono consentiti aggiornamenti simultanei dello stesso elemento di dati, il che genera uno stato incoerente. Una politica di risoluzione dei conflitti deve decidere quale di essere l'ultimo stato coerente.
• Partizionamento orizzontale multi-ista. Lo sharding si basa sulla gestione di partizioni (sconnesse) dei dati. Un'istanza di database separata gestisce ogni partizione. Questa distribuzione è scalabile perché è possibile aggiungere altri shard in modo dinamico nel tempo. Tuttavia, questa funzionalità non è supportata da tutti i sistemi, poiché 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 sharding. Lo sharding è un concetto di scalabilità e in genere non è rilevante per la selezione dei database dell'architettura in ambienti multi-cloud.

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

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

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

Esistono altre possibili alternative alle architetture di database gestito spiegate in questa sezione. Un sistema a livello di regione 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 del database non è disponibile anche se le altre zone potrebbero essere ancora completamente online.

Mappatura dei sistemi di database ai pattern di deployment

La tabella seguente descrive la correlazione tra i pattern e le architetture di deployment descritti in questo documento. I campi indicano le condizioni necessarie affinché una combinazione sia possibile, in base al modello e all'architettura del deployment.

Architettura di deployment	Pattern di deployment
	Partizionata 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, possono essere utilizzati sistemi di database diversi.	Database cloud che fornisce la replica.	Database cloud che fornisce una replica bidirezionale.	Database cloud che fornisce la sincronizzazione principale-principale.
Database gestiti da cloud provider	I sistemi di database possono essere diversi a seconda del cloud.	La replica non deve necessariamente essere il database gestito dal provider cloud (consulta Il ruolo della tecnologia di migrazione dei database nei pattern di deployment).	Solo all'interno di un cloud, non tra cloud, se il database offre una replica bidirezionale.	Solo all'interno di un cloud, non tra cloud, se il database fornisce la sincronizzazione principale-principale.
Database pre-cloud	I sistemi di database possono essere uguali o diversi in cloud diversi.	La replica è possibile su più cloud.	Il sistema di database fornisce replica bidirezionale e risoluzione dei conflitti.	Il sistema di database fornisce la sincronizzazione principale-principale.
Database gestiti da partner cloud	I sistemi di database possono essere diversi a seconda del cloud. 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 replica bidirezionale e 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 invece la tecnologia di replica del database. Per ulteriori informazioni, vedi Il ruolo della tecnologia di migrazione dei 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 è possibile la combinazione in base a un modello di deployment e a un modello di distribuzione.

Modello di distribuzione	Pattern di deployment
	Partizionata senza dipendenza tra database	Replica unidirezionale asincrona	Replica bidirezionale con risoluzione dei conflitti	Sistema distribuito sincronizzato completamente attivo-attivo
Istanza singola	Possibile con lo stesso sistema di database o con sistemi di database diversi nei cloud interessati.	Non applicabile	Non applicabile	Non applicabile
Attivo-passivo multi-istanza	Possibile con lo stesso sistema di database o con sistemi di database diversi nei cloud coinvolti.	La replica è possibile tra cloud.	La replica è possibile tra cloud.	Non applicabile
Attiva/attiva multi-istanza	Possibile con lo stesso sistema di database o con sistemi di database diversi nei cloud coinvolti.	Non applicabile	Non applicabile	La sincronizzazione è possibile tra cloud.
Attivo multi-istanza con risoluzione dei conflitti	Possibile con lo stesso sistema di database o con sistemi di database diversi nei cloud coinvolti.	Non applicabile	Non applicabile	Applicabile se è possibile la replica bidirezionale tra i cloud.

Alcune implementazioni di modelli di distribuzione che aggiungono ulteriori astrazioni basate sulla tecnologia di database sottostante non dispongono di un modello di distribuzione di questo tipo, ad esempio Postgres-BDR, un sistema attivo attivo. Questi sistemi sono inclusi nella tabella precedente nella rispettiva categoria. Da un punto di vista multi-cloud, non è rilevante come viene implementato un modello di distribuzione.

Migrazione e replica dei database

A seconda del caso d'uso, un'azienda potrebbe dover eseguire la migrazione di un database da un percorso di deployment a un altro. In alternativa, per l'elaborazione downstream, potrebbe essere necessario replicare i dati di un database in un'altra località. Nella sezione seguente, la migrazione e la replica dei database sono trattate in modo più dettagliato.

Migrazione dei database

La migrazione del database viene utilizzata quando un database viene spostato da una località di deployment a un'altra. Ad esempio, viene eseguita la migrazione di un database in esecuzione in un data center on-premise per l'esecuzione sul cloud. Al termine della migrazione, il database viene arrestato nel data center on-premise.

Gli approcci principali alla migrazione dei database sono i seguenti:

• Solleva e sposta. La VM e i dischi che eseguono le istanze di database vengono copiati nell'ambiente di destinazione così come sono. Dopo essere stati copiati, vengono avviati e la migrazione è completata.
• Esportazione e importazione nonché backup e ripristino. Questi approcci utilizzano entrambi la funzionalità del sistema di database per esternalizzare un database e ricrearlo nella località di destinazione. L'esportazione/l'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, viene eseguita la migrazione di un database 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 di Change Data Capture (CDC). L'applicazione comporta tempi di inattività dal momento in cui viene arrestata nel sistema di database di origine fino al riavvio nel sistema di database di destinazione al termine della migrazione.

La migrazione dei database diventa rilevante nei casi d'uso multi-cloud, quando un database viene spostato da un cloud all'altro o da un tipo di motore del database a un altro.

La migrazione dei database è un processo multiforme. Per maggiori informazioni, consulta Migrazione dei database: concetti e principi (Parte 1) e Migrazione dei database: concetti e principi (Parte 2).

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

Replica dei database

La replica dei database è simile alla migrazione dei database. Tuttavia, durante la replica del database, il sistema del database di origine rimane attivo 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 nel database di destinazione con un breve ritardo. Se il processo è sincrono, le modifiche al sistema di origine vengono apportate al sistema di destinazione nello stesso momento e alle stesse transazioni.

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

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

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

La tecnologia di database integrata per abilitare la replica non è in disponibilità generale quando nei pattern di deployment vengono utilizzati diversi sistemi di database, ad esempio la replica asincrona (eterogenea). È possibile invece eseguire il deployment della 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 dei database è disponibile per i sistemi di database utilizzati nelle combinazioni contrassegnate come "Non applicabile" nella Tabella 1 o nella Tabella 2 in Mappatura dei sistemi di database ai pattern di deployment, potrebbe essere possibile utilizzarla per la replica del database. Il seguente schema mostra un approccio per la replica dei 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 eseguito il deployment di un server di migrazione per implementare la replica. Questo approccio viene utilizzato per i sistemi di database che non dispongono della funzionalità di replica dei database integrata nella propria implementazione e che devono fare affidamento su un sistema separato dal sistema di database per implementare la replica.

Selezione dei database multi-cloud

I casi d'uso dei database multi-cloud combinati con la categorizzazione del sistema di database consentono di decidere quali database sono migliori per un determinato caso d'uso. Ad esempio, per implementare il caso d'uso in Portabilità delle applicazioni, esistono due opzioni. La prima opzione è garantire che lo stesso motore del database sia disponibile in tutti i cloud. Questo approccio garantisce la portabilità del sistema. La seconda opzione consiste nell'assicurare che per tutti i cloud siano disponibili lo stesso modello dei dati e la stessa interfaccia di query. Sebbene i sistemi di database possano essere diversi, la portabilità è fornita su un'interfaccia funzionale.

Le strutture decisionali nelle sezioni seguenti mostrano i criteri decisionali per i casi d'uso dei database multi-cloud in questo documento. Le strutture decisionali suggeriscono il database migliore da considerare per ogni caso d'uso.

Best practice per un sistema di database esistente

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

Ecco le domande e le risposte nell'albero decisionale:

• È un sistema di database in produzione?
  • Se nessun sistema di database è in produzione, selezionane uno (vai a Decisione sulla gestione di database multi-cloud).
  • Se un sistema di database è in produzione, valuta se deve essere conservato.
• Se un sistema di database è in produzione, valuta se deve essere conservato.
  • Se il sistema di database deve essere conservato, la decisione viene presa e il processo decisionale è completo.
  • Se il sistema di database deve essere modificato o se la decisione è ancora in corso, seleziona un sistema di database (vai a Decisione sulla gestione di database multi-cloud).

Decisione sulla gestione di database multi-cloud

Il seguente albero decisionale è relativo a un caso d'uso con un requisito di database multi-località (compreso il deployment di un database multi-cloud). Utilizza il modello di deployment come base per i criteri decisionali.

Ecco le domande e le risposte nell'albero decisionale:

• I dati sono partizionati in database diversi senza dipendenze cross-database?
  • In caso affermativo, è possibile selezionare lo stesso sistema di database o sistemi di database diversi per ogni località.
  • In caso contrario, passa alla domanda successiva.
• È necessaria la replica unidirezionale asincrona?
  • In caso affermativo, valuta se un sistema di replica del database è accettabile.
    • In caso affermativo, seleziona gli stessi sistemi di database o più sistemi di database 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, passa alla domanda successiva.
• Seleziona un sistema di database con istanze sincronizzate.
  • La risoluzione del conflitto è accettabile?
    • Se sì, seleziona un sistema di database con replica bidirezionale o un sistema di database attivo-attivo.
    • In caso contrario, seleziona un sistema attivo-attivo.

Se viene implementato più di un caso d'uso multi-cloud, un'azienda deve decidere se vuole utilizzare un sistema di database per supportare tutti i casi d'uso o più sistemi di database.

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

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

Best practice per l'implementazione

Questa sezione evidenzia le best practice da seguire nella scelta di un database per la migrazione o lo sviluppo di applicazioni multi-cloud.

Sistema di gestione dei database esistente

Può essere buona prassi conservare un database e non apportare modifiche al sistema del 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 che dispone di processi di sviluppo, operativi e manutenzione efficaci, potrebbe essere preferibile evitare di apportare modifiche.

Un caso d'uso di cloud bursting che non richiede un sistema di database nel cloud potrebbe non aver bisogno di una modifica del database. Un altro caso d'uso è la replica asincrona in una località 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 e la comunicazione tra località soddisfino i requisiti dell'applicazione quando si accede al database.

Sistema di database come servizio Kubernetes

Se un'azienda sta prendendo in considerazione l'esecuzione di un sistema di database in Kubernetes come servizio basato sugli StatefulSets, è necessario considerare 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 scale up e lo scale down, come vengono gestiti backup e ripristino e in che modo il sistema rende disponibile il monitoraggio. Per aiutarle a comprendere i requisiti di un sistema di database basato su Kubernetes, le aziende dovrebbero utilizzare le loro esperienze con i database come punto di confronto.
• Alta disponibilità e ripristino di emergenza. Per offrire l'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 il failover rapido da una zona all'altra. Nel migliore dei casi, 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 i guasti di una regione (o 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 recuperato per tutte le transazioni del database primario.

Per determinare il modo migliore per eseguire un database all'interno di Kubernetes, una valutazione 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

Per un'applicazione implementata come servizi in Kubernetes non è sempre necessario che il database sia in esecuzione contemporaneamente in Kubernetes. Esistono molti motivi per cui un sistema di database deve essere eseguito al di fuori di Kubernetes, ad esempio processi consolidati, conoscenza dei prodotti all'interno di un'azienda o indisponibilità. Rientrano in questa categoria sia i provider di servizi cloud che i database gestiti da partner.

È ugualmente possibile e fattibile eseguire un database su Compute Engine. Quando selezioni un sistema di database, è buona norma eseguire una valutazione completa del database per garantire che tutti i requisiti per un'applicazione siano soddisfatti.

Dal punto di vista della progettazione delle applicazioni, il pooling delle connessioni è un aspetto importante. Un servizio dell'applicazione che accede a un database potrebbe utilizzare un pool di connessioni internamente. L'utilizzo di un pool di connessioni è positivo per l'efficienza e ha ridotto la latenza. Le richieste vengono invece acquisite dal pool senza dover essere avviate e non è necessario attendere la creazione delle connessioni. Se viene fatto lo scale up dell'applicazione aggiungendo istanze di servizio dell'applicazione, ogni istanza crea un pool di connessioni. Se vengono seguite le best practice, ogni pool crea preventivamente un insieme minimo di connessioni. Ogni volta che viene creata un'altra istanza del servizio delle applicazioni per la scalabilità delle applicazioni, le connessioni vengono aggiunte al database. Dal punto di vista della progettazione, poiché i database non possono supportare connessioni illimitate, 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 comunemente il miglior sistema di database per soddisfare i requisiti di un'applicazione. In un ambiente multi-cloud, è possibile selezionare il database migliore in ogni cloud e connetterli tra loro in base al caso d'uso. Se questi sistemi sono diversi, qualsiasi replica, unidirezionale o bidirezionale, richiede un impegno significativo. Questo approccio potrebbe essere giustificato se il vantaggio dell'utilizzo del sistema migliore supera gli sforzi necessari 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 l'opzione migliore, potrebbe essere molto più semplice da implementare, utilizzare e gestire.

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

Replica del sistema di database interno ed 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 completamente sincronizzata con l'opzione attiva-attiva. I sistemi di database non supportano tutte queste forme di replica.

Per i sistemi che non supportano la replica nell'ambito della replica di implementazione del sistema, è possibile utilizzare sistemi come Striim per completare 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 una tecnologia di replica.

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

Passaggi successivi

• Scopri di più su pattern e pratiche ibridi e multi-cloud.
• Scopri i pattern per la connessione di altri provider di servizi cloud con Google Cloud.
• Scopri di più sulle architetture di monitoraggio e logging per i deployment ibridi e multi-cloud su Google Cloud.
• Per altre architetture di riferimento, diagrammi e best practice, esplora il Cloud Architecture Center.