Gestione di 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 di database multi-cloud. È destinato ad architetti 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 dal caso d'uso. Nessuna architettura di applicazioni stateful può supportare tutti i casi d'uso multi-cloud. Ad esempio, la migliore soluzione di database per un caso d'uso cloud burst è diversa dalla migliore soluzione di database per un'applicazione che viene eseguita contemporaneamente in più ambienti cloud.

Per i cloud pubblici come Google Cloud, esistono diverse tecnologie di database che si adattano a specifici casi d'uso multi-cloud. Per eseguire il deployment di un'applicazione in più aree geografiche all'interno di un singolo cloud pubblico, puoi utilizzare un database pubblico gestito da un provider multi-regionale, ad esempio Cloud Spanner. Per eseguire il deployment di un'applicazione da rendere portabile nei cloud pubblici, un database indipendente dalla piattaforma potrebbe essere una scelta migliore, come PostgreSQL.

Questo documento introduce una definizione per un'applicazione di database stateful seguita da un'analisi dei casi d'uso dei database multi-cloud. Dopodiché presenta una categorizzazione dettagliata dei sistemi di database per le architetture di deployment multi-cloud in base ai casi d'uso.

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

Termini e definizioni chiave

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

Terminologia

  • Cloud pubblico. Un cloud pubblico fornisce un'infrastruttura multi-tenant (generalmente globale) e servizi 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, Anthos e database gestiti.
  • Cloud ibrido. Un cloud ibrido è una combinazione di un cloud pubblico con uno o più data center on-premise. I clienti di cloud ibrido possono combinare i propri servizi on-premise con servizi aggiuntivi forniti da un cloud pubblico.
  • Multi-cloud. Un multi-cloud è una combinazione di diversi cloud pubblici e data center on-premise. Un cloud ibrido è un sottoinsieme del multi-cloud.
  • Posizione di deployment. Una località dell'infrastruttura è una località fisica in cui è possibile eseguire ed eseguire il deployment di carichi di lavoro, inclusi applicazioni e database. Ad esempio, in Google Cloud, le località del deployment sono zone e aree geografiche. A livello astratto, un'area geografica o una zona cloud pubblica 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 di applicazione di database stateful generica, come mostrato nel diagramma seguente.

Architettura generica delle applicazioni stateful.

Il diagramma mostra i seguenti componenti:

  • Database. Un database può essere una singola istanza, più istanze o un database distribuito, il cui deployment è eseguito su nodi di computing o è disponibile come servizio gestito su cloud.
  • Servizi per applicazioni. Questi servizi vengono combinati come un'applicazione che implementa la logica di business. I servizi per le applicazioni possono essere:
    • Microservizi su Kubernetes.
    • Processi granulari in esecuzione su una o più macchine virtuali.
    • Un'applicazione monolitica su un'unica macchina virtuale di grandi dimensioni.
    • Codice serverless in Cloud Functions o Cloud Run. Alcuni servizi per applicazioni possono accedere al database. È possibile eseguire il deployment di ogni servizio dell'applicazione più volte. Ogni deployment di un servizio di applicazione è un'istanza di tale servizio.
  • Client di applicazioni. I client delle applicazioni accedono alla funzionalità fornita dai servizi delle applicazioni. I client delle applicazioni possono essere uno dei seguenti:
    • Client di cui è stato eseguito il deployment, dove il codice viene eseguito su una macchina, un laptop o un telefono 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 del servizio dell'applicazione.

Nell'ambito di una discussione su database multi-cloud, l'astrazione architetturale di un'applicazione stateful consiste di un database, servizi di applicazioni e client di applicazioni. Nell'implementazione di un'applicazione, fattori come l'utilizzo dei sistemi operativi o i linguaggi di programmazione utilizzati possono variare. Tuttavia, questi dettagli non influiscono sulla gestione dei database multi-cloud.

Code e file come servizi di archiviazione dati

Sono disponibili molte risorse di persistenza per il mantenimento dei dati da parte dei servizi delle applicazioni. tra cui 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 file system siano utilizzati dalle applicazioni, nella sezione seguente si concentrano specificamente sui database.

Anche se le stesse considerazioni per fattori come la località di deployment, la condivisione dello stato, la replica sincrona e asincrona per i database multi-cloud sono 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 sulla connessione di rete, ad esempio un client che accede a un servizio dell'applicazione.

Architettura generica delle applicazioni stateful.

Una connessione può trovarsi all'interno di una zona o tra zone, aree geografiche o nuvole. Possono esistere connessioni tra qualsiasi combinazione di località di deployment. In ambienti multi-cloud, il networking tra i cloud è una considerazione importante e puoi scegliere tra diverse opzioni. Per ulteriori informazioni sul networking tra cloud, consulta la sezione Connettersi a Google Cloud: le opzioni di networking.

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

  • È presente 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, ossia la velocità effettiva e la latenza, potrebbero influire sulla latenza e sulla velocità effettiva del database. Da un punto di vista funzionale, il networking in genere non ha 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 ci sia connettività di rete sicura tra i cloud e i nodi del database.

Migrazione di applicazioni

Nel contesto della gestione di database multi-cloud, la migrazione delle applicazioni si riferisce alla migrazione di un'applicazione, a tutti i servizi dell'applicazione e al database dal cloud corrente a un cloud di destinazione. Sono molte le ragioni per cui un'azienda può decidere di eseguire la migrazione di un'applicazione, ad esempio per evitare una situazione concorrenziale con il cloud provider, per modernizzare la tecnologia o ridurre il costo totale di proprietà (TCO).

Nella migrazione delle applicazioni, lo scopo è interrompere la produzione nel cloud corrente e continuare la produzione nel cloud di destinazione al termine della migrazione. I servizi dell'applicazione devono essere eseguiti nel cloud di destinazione. Per implementare i servizi, è possibile utilizzare un approccio lift and shift. In 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 del database, considera le seguenti opzioni alternative per la migrazione delle applicazioni:

  • Incremento e spostamento del database: se lo stesso motore di database è disponibile nel cloud di destinazione, è possibile sollevare e spostare il database per creare un deployment identico nel cloud di destinazione.
  • Incremento del database e passaggio all'equivalente gestito: un database autogestito può essere migrato a una versione gestita dello stesso motore di database se fornito dal cloud di destinazione.
  • Modernizzazione dei database: diversi cloud offrono tecnologie di database diverse. I database gestiti da un cloud provider 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 dei database è un processo che richiede del tempo a causa della necessità di spostare i dati dal cloud corrente al cloud di destinazione. Anche se è possibile seguire un approccio di esportazione e importazione che comporta un tempo di inattività, è preferibile utilizzare una migrazione minima o nulla di inattività. Questo approccio riduce al minimo il tempo di inattività dell'applicazione e ha il minimo impatto su un'azienda e i suoi clienti.

Ripristino di emergenza

Il ripristino di emergenza indica la capacità di un'applicazione di continuare a fornire i servizi ai client delle applicazioni durante le interruzioni di area geografica. Per garantire il ripristino di emergenza, è necessario eseguire il deployment di un'applicazione in almeno due aree geografiche ed essere pronta per l'esecuzione in qualsiasi momento. In produzione, l'applicazione viene eseguita nell'area geografica principale. Tuttavia, se si verifica un'interruzione, un'area geografica secondaria diventa l'area geografica principale. Di seguito sono riportati diversi modelli di recupero durante il ripristino di emergenza:

  • Hot standby Viene eseguito il deployment dell'applicazione in due o più aree geografiche (principale e secondaria) e l'applicazione funziona completamente in ogni area geografica. In caso di errore dell'area geografica principale, l'applicazione nell'area geografica secondaria può gestire immediatamente il traffico client delle applicazioni.
  • cold standby. L'applicazione è in esecuzione nell'area geografica principale, ma è pronta per l'avvio in un'area geografica secondaria (ma non in esecuzione). Se l'area geografica non riesce, l'applicazione viene avviata nell'area geografica secondaria. Si verifica un'interruzione dell'applicazione finché l'applicazione non è in grado di eseguire e fornire tutti i servizi dell'applicazione ai client dell'applicazione.
  • Nessuno standby. In questo modello, il codice dell'applicazione è pronto per il deployment ma non è ancora stato eseguito il deployment nell'area geografica secondaria (e quindi non sono utilizzate risorse di cui è stato eseguito il deployment). Se un'area geografica principale presenta un'interruzione, il primo deployment dell'applicazione deve trovarsi nell'area geografica secondaria. Questo deployment mette l'applicazione nello stesso stato di un cold standby, il che significa che deve essere avviato. In questo approccio, l'interruzione dell'applicazione è più lunga rispetto al caso di standby freddo perché deve essere eseguito prima il deployment delle applicazioni, inclusa la creazione di risorse cloud.

Dal punto di vista del database, i modelli di idoneità illustrati nell'elenco precedente corrispondono ai seguenti approcci al database:

  • Database sincronizzato a livello di transazione. Questo database corrisponde al modello di standby attivo. Ogni transazione nell'area geografica principale si impegna in coordinamento sincrono in un'area geografica secondaria. Quando l'area geografica secondaria diventa l'area geografica principale durante un'interruzione, il database è coerente e disponibile immediatamente. In questo modello, l'obiettivo del punto di ripristino (RPO) e l'obiettivo del tempo di ripristino (RTO) sono pari a zero.
  • Database replicato in modo asincrono. Questo database corrisponde anche al modello di hot standby. Poiché la replica del database dall'area geografica principale all'area geografica secondaria è asincrona, esiste la possibilità che, se l'area geografica non riesce, alcune transazioni possano essere replicate nell'area geografica secondaria. Anche se il database nell'area geografica secondaria è pronto per il carico di produzione, potrebbe non avere i dati più aggiornati. Per questo motivo, l'applicazione potrebbe comportare la perdita delle transazioni non recuperabili. A causa di questo rischio, questo approccio ha un RTO pari a zero, ma il valore RPO è maggiore di zero.
  • Database inattivo. Questo database corrisponde al modello di standby completo. Il database viene creato senza alcun dato. Se l'area geografica non riesce, i dati devono essere caricati nel database di inattività. Per abilitare questa azione, è necessario eseguire un backup standard nell'area geografica principale e trasferirlo nell'area geografica secondaria. Il backup può essere completo o incrementale, a seconda del supporto supportato dal motore di database. In entrambi i casi, il database viene riportato all'ultimo backup e, dal punto di vista dell'applicazione, molte transazioni possono andare perse rispetto all'area geografica principale. Anche se questo approccio potrebbe essere conveniente, il valore è ridotto 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 equivale alla richiesta di tipo no standby. L'area geografica secondaria non ha un database installato e, se l'area geografica principale non funziona, è necessario creare un database. Una volta creato, il database, come nel caso del database inattivo, deve essere caricato con dati disponibili prima dell'applicazione.

Gli approcci per il ripristino di emergenza illustrati in questo documento vengono applicati anche se vengono utilizzati un cloud principale e uno secondario anziché un'area geografica principale e secondaria. La differenza principale è che, a causa dell'eterogeneità della rete tra i cloud, la latenza tra le cloud potrebbe aumentare rispetto alla distanza di rete tra le aree geografiche all'interno di una cloud.

La probabilità di errore di un intero cloud è inferiore a quella di un errore di un'area geografica. Tuttavia, potrebbe essere comunque utile che le aziende abbiano il deployment di un'applicazione in due cloud. Questo approccio potrebbe aiutarti a proteggere un'azienda da errori o a rispettare le normative aziendali o di settore.

Un altro approccio al ripristino di emergenza consiste nell'avere un'area geografica principale e una secondaria e un cloud principale e secondario. Questo approccio consente alle aziende di scegliere la migliore procedura di ripristino di emergenza per risolvere una situazione di errore. Per abilitare l'esecuzione di un'applicazione, è possibile utilizzare un'area geografica secondaria o un cloud secondario, a seconda della gravità dell'interruzione.

Cloud bursting

Il burst di Cloud si riferisce a una configurazione che consente lo scale up del traffico dei client delle applicazioni in diverse località di deployment. Un'applicazione esplode quando la domanda di aumento della capacità aumenta e una posizione di standby fornisce capacità aggiuntiva. Una località principale supporta il traffico normale, mentre una località di standby può fornire capacità aggiuntiva nel caso in cui il traffico client dell'applicazione aumenti oltre a quello supportato dalla località principale. Nelle istanze di servizio sia quelle principali sia quelle di standby sono sottoposte a deployment.

Il burst di cloud è implementato in più nuvole in cui un cloud è il cloud principale e un secondo cloud è il cloud standby. Viene utilizzato in un contesto di cloud ibrido per aumentare un numero limitato di risorse di computing nei data center on-premise con risorse di computing elastiche in un cloud pubblico.

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

  • Deployment della località principale. In questo deployment, viene eseguito il deployment del database solo nella località principale e non in quella di standby. Quando un'applicazione scoppia, l'applicazione in posizione standby accede al database nella posizione principale.
  • Deployment di posizioni principale e in standby. Questo deployment supporta sia la posizione principale sia quella in standby. Il deployment di un'istanza di database viene eseguito in entrambe le posizioni e vi si accede dalle relative istanze del servizio dell'applicazione, soprattutto nel caso di burst. Come in Ripristino di emergenza all'interno e tra i cloud, i due database possono essere sincronizzati transazionali o sincronizzati in modo asincrono. Nella sincronizzazione asincrona, potrebbe verificarsi un ritardo. Se gli aggiornamenti avvengono nella posizione standby, devono essere propagati alla posizione principale. Se in entrambi i paesi sono possibili aggiornamenti simultanei, è necessario implementare la risoluzione dei conflitti.

Il burst di Cloud è 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 diversi cloud pubblici quando i dati devono rimanere all'interno di un paese. Nei casi in cui un cloud pubblico abbia una sola area geografica in un paese, è possibile burst in un'area geografica di un cloud pubblico diverso nello stesso paese. Questo approccio garantisce che i dati rimangano nel paese, pur rispettando i vincoli delle risorse nell'area geografica delle aree geografiche del cloud pubblico.

Il meglio del servizio cloud

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

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 tra loro. L'applicazione che gestisce i dati scrive tutti i dati che devono essere disponibili in due 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 di set di dati per un'applicazione aziendale, quest'ultimo può essere replicato tra i cloud.
  • Database sincronizzato a livello di transazione. Questi tipi di database consentono di rendere disponibili i dati per entrambe le parti dell'applicazione. Ogni aggiornamento da ciascuna applicazione è coerente dal punto di vista transazionale e è disponibile immediatamente per entrambi i database (partizioni). I database con sincronizzazione transazionale funzionano in modo efficace come un unico database distribuito.

Servizi distribuiti

Viene eseguito il deployment e l'esecuzione di un servizio distribuito in due o più località. È 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 solo in una di queste, in base a fattori quali la disponibilità dell'hardware o il carico limitato previsto.

I dati in un database con transazioni transazionali sono coerenti in tutte le località. Di conseguenza, 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 dati venga modificato in due località di deployment contemporaneamente. Per determinare quale di queste due modifiche in conflitto sia lo stato coerente finale, deve essere implementata una strategia di risoluzione dei conflitti. Sebbene sia possibile implementare una risoluzione in conflitto, non è sempre facile e a volte è necessario l'intervento manuale per riportare i dati a uno stato coerente.

Distribuzione e failover del servizio distribuiti

In caso di errore di un'intera area geografica del cloud, viene avviato il ripristino di emergenza. Se un singolo servizio in un'applicazione di database stateful non funziona (non l'area geografica o l'intera applicazione), il servizio deve essere ripristinato e riavviato.

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

Tuttavia, se questo approccio al riavvio sul posto non riesce, un'alternativa consiste nel riavviare il servizio in una località secondaria. Il servizio non riesce a passare dalla sua località principale a una località secondaria. Se il deployment dell'applicazione viene eseguito come un 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 sua località di deployment originale non richiede un deployment di database specifico. Quando un servizio viene spostato in una località di deployment alternativa e accede al database, vengono applicati gli stessi modelli di idoneità illustrati nella sezione precedente di Servizi distribuiti di questo documento.

Se un servizio viene spostato temporaneamente e se le latenze più elevate sono accettabili per un'azienda durante il trasferimento, il servizio potrebbe accedere al database nelle varie località del deployment. Anche se il servizio viene spostato, continuerà ad accedere al database nello stesso modo in cui lo farà dalla località di deployment originale.

Deployment dipendente dal contesto

In generale, un deployment di singole applicazioni per gestire tutti i client delle applicazioni include tutti i relativi servizi e database. Tuttavia, esistono casi d'uso eccezionali. Il deployment di una singola applicazione può gestire solo un sottoinsieme di client (in base a criteri specifici). Ciò significa che è necessario più deployment di applicazioni. Ogni deployment offre un sottoinsieme di client e tutti i deployment servono insieme tutti i client.

Di seguito sono riportati alcuni casi d'uso di esempio per un deployment che dipende dal contesto:

  • Quando esegui il deployment di un'applicazione multi-tenant per cui viene eseguito il deployment di un'applicazione per tutti i piccoli tenant, viene eseguito il deployment di un'altra applicazione per ogni tenant medio e 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, temporaneo e produzione.

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

Il deployment di ogni applicazione include un database separato.

Il diagramma precedente mostra quanto segue:

  • Una configurazione con tre deployment di un'applicazione.
  • Ogni set di dati ha il proprio database.
  • Non viene condiviso alcun dato tra i deployment.

In molte situazioni, un deployment one-to-one è la strategia più appropriata, tuttavia esistono delle alternative.

In caso di multi-tenancy, i tenant potrebbero essere ricollocati. Un piccolo tenant potrebbe trasformarsi in un tenant medio e deve essere spostato in un'altra applicazione. In questo caso, i 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 tenant risiedono in un unico sistema di database. Per questo motivo, lo spostamento di un tenant tra un database e l'altro non richiede la migrazione dei database. Il seguente diagramma mostra un esempio di questo tipo di database:

Tutti i deployment delle applicazioni condividono un database distribuito.

Il diagramma precedente mostra quanto segue:

  • Tre deployment di un'applicazione.
  • I deployment condividono tutti un singolo database distribuito.
  • Le applicazioni possono accedere a tutti i dati di ciascun deployment.
  • Non è stato implementato il partizionamento dei dati.

Se un'azienda spesso trasferisce i tenant come parte delle operazioni del ciclo di vita, la replica del database potrebbe essere un'alternativa utile. In questo approccio, i dati tenant vengono replicati tra i database prima di una migrazione tenant. In questo caso, i database indipendenti vengono utilizzati per diversi deployment di applicazioni e configurati per la replica immediatamente prima e durante la migrazione del tenant. Il seguente diagramma mostra una replica temporanea tra due deployment di applicazioni durante una migrazione tenant.

Replica temporanea del database tra due deployment delle applicazioni.

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

Portabilità delle applicazioni

La portabilità delle applicazioni assicura che sia possibile eseguire il deployment di applicazioni in località di deployment diverse, in particolare nel cloud diverso. Questa portabilità garantisce la migrazione di un'applicazione in qualsiasi momento, senza la necessità di una riprogettazione specifica per la migrazione o di sviluppo aggiuntivo delle applicazioni per prepararsi a una migrazione dell'applicazione.

Per garantire la portabilità delle applicazioni, 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 su sistema utilizza gli stessi componenti tecnici utilizzati in tutti i deployment possibili. 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 è un 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 i linguaggi di programmazione e le tecnologie di infrastruttura. Come mostrato nel diagramma seguente, questo approccio definisce un insieme di funzionalità comuni in tutte le località di deployment, basate sulla tecnologia.

Portabilità implementando la stessa tecnologia.

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

Nell'ambito dei database, nel sistema di compatibilità API, il client utilizza una specifica libreria di accesso ai database (ad esempio, una libreria client MySQL) per garantire la connessione a qualsiasi implementazione conforme che sia disponibile in un ambiente cloud. Il seguente diagramma illustra la compatibilità dell'API.

Portabilità mediante il deployment di una tecnologia diversa che supporta la stessa API.

Il diagramma precedente mostra la portabilità delle applicazioni in base all'API del sistema di database anziché al sistema di database. Anche se i sistemi di database possono essere diversi in ciascuna località, l'API è la stessa e presenta le stesse funzionalità. L'applicazione è portatile perché può assumere la stessa API in ogni località, anche se il sistema di database sottostante è una tecnologia di database diversa.

Per la portabilità basata sulle funzionalità, è possibile utilizzare diverse tecnologie in grado di offrire le stesse funzionalità. Ad esempio, potrebbe essere possibile limitare l'uso dei database al modello relazionale. Poiché qualsiasi sistema di database relazionale può supportare l'applicazione, è possibile utilizzare diversi sistemi di database in versioni diverse su 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, è necessario utilizzare un modello di database. Il seguente diagramma mostra un'architettura di esempio per la portabilità basata sulla funzionalità.

Portabilità mediante il deployment di una tecnologia diversa, API diversa ma stesso modello di database.

Come mostra il diagramma precedente, l'API del sistema di database e il sistema di database potrebbero essere diversi in ciascuna località. Per garantire la portabilità, l'applicazione deve utilizzare solo le parti di ciascun sistema di database e ogni API disponibili in ogni località. Poiché in ciascuna località è attualmente disponibile solo un sottoinsieme di ciascun sistema di database, l'applicazione deve limitarne l'utilizzo a quel sottoinsieme secondario.

Per garantire la portabilità di tutte le opzioni in questa sezione, devi 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 per questi deployment. Si tratta di requisiti essenziali per rilevare tempestivamente e risolvere le modifiche alle infrastrutture e alle tecnologie.

Prevenzione delle dipendenze del fornitore

La prevenzione della dipendenza dal fornitore (lock-in) aiuta a mitigare il rischio di dipendenza da una tecnologia e un fornitore specifici. È poco 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 c'è dipendenza dal punto di vista del cloud, ma c'è una dipendenza da MySQL. Un'applicazione il cui portabilità tra i cloud potrebbe dipendere ancora dalle tecnologie fornite da diversi fornitori rispetto al cloud.

Per evitare la dipendenza dai fornitori, è necessario sostituire tutte le tecnologie. Per questo motivo, è necessaria un'astrazione completa e strutturata di tutte le funzionalità dell'applicazione, in modo che ogni servizio dell'applicazione possa essere implementato nuovamente in 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 determinato sistema di gestione del database.

Sistema di gestione di database di produzione esistente

Sebbene molte applicazioni multi-cloud siano sviluppate con sistemi di database nell'ambito della 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 accede ai database esistenti.

Esistono molti motivi per non incorporare database esistenti in uno sforzo di modernizzazione. Potrebbero essere in uso funzioni specifiche che non sono disponibili da altri sistemi di database. Un'azienda potrebbe avere database con processi di gestione complessi e consolidati, che consentono di passare a un sistema diverso poco pratico o non economico. 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 le diverse località di deployment. Ad esempio, se un database viene utilizzato on-premise e l'applicazione deve essere eseguita anche in Google Cloud, deve valutare se i servizi dell'applicazione di cui è stato eseguito il deployment in Google Cloud accedono al database on-premise. In alternativa, se è necessario eseguire il deployment di un secondo database sia in Google Cloud sia per i servizi di applicazioni in esecuzione localmente.

Se viene eseguito il deployment di un secondo database in Google Cloud, il caso d'uso potrebbe essere uguale a quello dei casi d'uso illustrati in Cloud burst o nei servizi distribuiti. In entrambi i casi, la stessa database si applica come in queste sezioni. Tuttavia, è limitata alla funzionalità cross-location supportata dal database esistente, ad esempio la sincronizzazione e la replica.

Pattern di deployment

I casi d'uso illustrati 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 (pattern di deployment), illustrati nella sezione successiva, sono i seguenti:

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

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

Nella discussione che segue si presume 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 diagramma seguente.

Accesso client tramite bilanciamento del carico.

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

Partizionate senza dipendenza tra database

Questo pattern di deployment è il più semplice tra tutti i pattern illustrati 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 viene archiviato in un solo database. Ogni partizione di dati si trova nel proprio database. Un esempio per questo pattern è un'applicazione multi-tenant in cui un set di dati si trova in un altro database. Il seguente diagramma mostra due applicazioni completamente partizionate.

Deployment del database completamente partizionato.

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

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

Un'unica istanza di database che supporta più località.

Il diagramma precedente mostra quanto segue:

  • Due deployment di applicazioni che condividono un database comune, situato 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 si replica 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 determinato caso d'uso viene utilizzato come database principale e quello secondario per l'analisi. Il seguente diagramma mostra due applicazioni che accedono a database con replica unidirezionale.

Replica unidirezionale asincrona.

Come mostra il diagramma precedente, uno dei due database è una replica dell'altro. La freccia nel diagramma indica la direzione della replica: i dati del sistema di database in posizione 1 vengono replicati nel sistema di database in posizione 2.

Replica bidirezionale con risoluzione dei conflitti

Questo pattern di deployment ha due database principali che vengono replicati in modo asincrono tra loro. Se gli stessi dati vengono scritti contemporaneamente in tutti i database (ad esempio, la stessa chiave primaria), è possibile che si verifichi un conflitto di scrittura-scrittura. A causa di questo rischio, deve essere presente una risoluzione in conflitto per determinare quale stato è l'ultimo stato durante la replica. Questo pattern può essere utilizzato in situazioni in cui esiste la possibilità di un conflitto di scrittura-scrittura. Il seguente diagramma mostra due applicazioni che accedono a database replicati in modo bidirezionale.

Replica bidirezionale con risoluzione dei conflitti.

Come mostra il 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 lo stesso elemento di dati l'elemento viene modificato da ciascuna delle applicazioni e contemporaneamente replicato. In questo caso, deve effettuare la risoluzione dei conflitti.

Sistema distribuito sincronizzato completamente attivo

Questo pattern di deployment ha un singolo database con una configurazione attiva-attiva (anche principale o principale). In una configurazione attiva, un aggiornamento dei dati in ogni database principale viene coerentemente sincronizzato e sincronizzato a livello di transazione. Un esempio di caso d'uso per questo pattern è il computing distribuito. Il seguente diagramma mostra due applicazioni che accedono a un database principale principale sincronizzato.

Database distribuito completamente principale-sincronizzato.

Come mostra il diagramma precedente, questa disposizione assicura 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 si riflette in entrambi i database quando si verifica un commit della transazione.

Classificazione del sistema di database

Non tutti i sistemi di gestione dei database possono essere utilizzati allo stesso modo per i pattern di deployment illustrati in questo documento. A seconda del caso d'uso, potrebbe essere possibile implementare solo un 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.

È possibile classificare i database in base a diverse dimensioni, come il modello dei dati, l'architettura interna, il modello di deployment e i tipi di transazione. Nella sezione seguente, ai fini della gestione di database multi-cloud, vengono utilizzate due dimensioni:

  • Architettura di deployment. L'architettura di deployment di un sistema di gestione di database su risorse di cloud (ad esempio, Compute Engine o gestito nel cloud).
  • Modello di distribuzione: Il modello di distribuzione supportato da un sistema di database (ad esempio, una singola istanza 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 dei database multi-cloud. Una classificazione comune è basata sui modelli di dati supportati da un sistema di gestione di database. Alcuni sistemi supportano un solo modello (ad esempio, un modello di grafico). Altri sistemi supportano diversi modelli di dati contemporaneamente (ad esempio, modelli relazionali e documenti). Nel contesto della gestione di database multi-cloud, questa classificazione non è pertinente perché le applicazioni multi-cloud possono utilizzare qualsiasi modello di dati per il deployment multi-cloud.

Sistema di database per architettura di deployment

La gestione di 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 usano le funzionalità di Kubernetes. CockroachDB e YugaByte sono esempi di questo tipo di database. Il deployment può essere eseguito su qualsiasi cloud che supporti Kubernetes.
  • Database gestiti da cloud. I database gestiti da un cloud provider sono basati su tecnologia specifica del cloud provider e sono un servizio di database gestito da un provider cloud specifico. Cloud Spanner e Cloud Bigtable. sono esempi di questo tipo di database. I database gestiti da un cloud provider sono disponibili solo nel cloud del cloud provider e non possono essere installati ed eseguiti altrove.
  • Database pre-cloud. I database pre-cloud esistevano prima dello sviluppo della tecnologia cloud (a volte per molto tempo) e di solito venivano eseguiti su hardware bare metal e macchine virtuali (VM). PostgreSQL e MySQL sono esempi di questo tipo di database. Questi sistemi possono essere eseguiti su qualsiasi cloud che supporta le macchine virtuali richieste o l'hardware Bare Metal.
  • Database gestiti da partner. Alcuni cloud pubblici dispongono di partner di database che installano e gestiscono i clienti nella cloud pubblica. Per questo motivo, i clienti non devono gestire questi database in autonomia. 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 sulla tecnologia creata per il cloud e un'offerta gestita per i clienti nel proprio cloud fornito dal fornitore. Questo approccio equivale al fornitore che fornisce un cloud pubblico che supporta solo il proprio database come singolo servizio.

I database pre-cloud possono essere anche in container e possono essere sottoposti a deployment in un cluster Kubernetes. Tuttavia, questi database non utilizzano funzionalità specifiche di Kubernetes come scalabilità, deployment multiservizio o deployment multi-pod.

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

Sistema di database per modello di distribuzione

Diversi sistemi di gestione dei database sono implementati in base ai modelli di distribuzione dell'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 tutto l'accesso al database. Poiché la singola istanza non può essere collegata a nessun'altra istanza, il sistema di database non supporta la replica.
  • Più istanze attive-passive In questa architettura comune sono collegate diverse istanze di database. Il collegamento più comune è una relazione attiva-passiva in cui un'istanza è l'istanza di database attiva che supporta sia istanze sia operazioni di scrittura e lettura. Uno o più sistemi passivi sono di sola lettura e ricevono tutte le modifiche al database dalla principale in modo sincrono o asincrono. I sistemi passivi possono fornire accesso in lettura. La funzionalità passiva attiva è anche nota come secondaria secondaria o master-slave.
  • Più istanze attive-attive. 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 sono sempre sincronizzate.
  • Più istanze attive-attive con risoluzione dei conflitti. Si tratta inoltre di un sistema relativamente insolito. Ogni istanza è disponibile per l'accesso in lettura e scrittura; tuttavia, i database sono sincronizzati in modalità asincrona. Sono consentiti aggiornamenti simultanei dello stesso elemento di dati, che causa uno stato incoerente. Un criterio di risoluzione dei conflitti deve decidere quale degli stati è l'ultimo stato coerente.
  • partizionamento orizzontale multi-istanza. Lo partizionamento orizzontale si basa sulla gestione delle partizioni di dati (scollegati). Ogni partizione di database gestisce un'istanza separata. Questa distribuzione è scalabile perché è possibile aggiungere più shard in modo dinamico nel tempo. Tuttavia, potrebbero non essere possibili query incrociate perché questa funzionalità non è supportata da tutti i sistemi.

Tutti i modelli di distribuzione illustrati in questa sezione possono supportare l'impostazione della partizione e possono essere suddivisi in un sistema con partizionamento orizzontale. Tuttavia, non tutti i sistemi sono progettati per fornire un'opzione di partizionamento orizzontale. Il partizionamento orizzontale è un concetto di scalabilità e in genere non è pertinente per la selezione di database architettonici in ambienti multi-cloud.

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

  • Sistema zoologico. Un sistema di database gestito a livello di zona è associato a una zona. Quando è disponibile la zona, viene attivato 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 area geografica è associato a un'area geografica ed è accessibile quando almeno una zona è accessibile. Qualsiasi combinazione di zone può diventare inaccessibile.
  • Sistema tra aree geografiche diverse. Un sistema tra aree geografiche è associato a due o più aree geografiche e funziona correttamente quando è disponibile almeno un'area geografica.

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

Esistono altre possibili alternative alle architetture di database gestite descritte in questa sezione. Un sistema a livello di area geografica potrebbe condividere un disco tra due zone. Se una delle due zone non è accessibile, 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 le altre zone potrebbero essere ancora completamente online.

Mappatura dei sistemi di database ai pattern di deployment

La tabella seguente descrive in che modo i pattern di deployment e le architetture di deployment discussi in questo documento sono correlati tra loro. I campi indicano le condizioni necessarie affinché una combinazione sia possibile, in base al pattern di deployment e all'architettura di deployment.

Architettura di deployment Pattern di deployment
Partizionate senza dipendenza tra database Replica unidirezionale asincrona Replica bidirezionale con risoluzione dei conflitti Sistema distribuito sincronizzato completamente 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 replica bidirezionale. Database cloud che fornisce la sincronizzazione con il sistema principale.
Database gestiti da cloud del provider I sistemi di database possono essere diversi a seconda del cloud. La replica non deve essere il database gestito dal cloud provider (vedi Il ruolo della tecnologia di migrazione dei database nei pattern di deployment). Solo all'interno di un cloud, non tra i cloud, se il database fornisce la replica bidirezionale. Solo all'interno di un cloud, non tra i cloud, se il database fornisce la sincronizzazione principale principale.
Database pre-cloud I sistemi di database possono essere uguali o diversi nei cloud. La replica è possibile su diversi cloud. Il sistema di database fornisce la replica bidirezionale e la risoluzione dei conflitti. Il sistema di database consente la sincronizzazione principale-principale.
Database gestiti da partner del 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 cloud provider.

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 consente la sincronizzazione principale-principale.

Se un sistema di database non fornisce la replica integrata, potrebbe essere possibile utilizzare la tecnologia di replica di database. Per scoprire di più, consulta il ruolo della tecnologia di migrazione dei database nei pattern di deployment.

La tabella seguente riguarda i pattern di deployment con i modelli di distribuzione. I campi indicano le condizioni per le quali è possibile effettuare una combinazione con un modello di deployment e un modello di distribuzione.

Modello di distribuzione Pattern di deployment
Partizionate senza dipendenza tra database Replica unidirezionale asincrona Replica bidirezionale con risoluzione dei conflitti Sistema distribuito sincronizzato completamente attivo
Singola istanza Possibile con lo stesso o diverso sistema di database nei cloud coinvolti. Non applicabile Non applicabile Non applicabile


Multi-istanza Attiva-Passiva
Possibile con lo stesso o diverso sistema di database nei cloud coinvolti. La replica è possibile tra i cloud. La replica è possibile tra i cloud. Non applicabile


Multi-istanza active-active
Possibile con lo stesso o diverso sistema di database nei cloud coinvolti. Non applicabile Non applicabile La sincronizzazione è possibile tra i cloud.


Un'istanza attiva-attiva con risoluzione dei conflitti
Possibile con lo stesso o diverso sistema di database nei cloud coinvolti. Non applicabile Non applicabile Applicabile se la replica bidirezionale è possibile tra i cloud.

Alcune implementazioni dei modelli di distribuzione che aggiungono ulteriori astrazioni sulla base della tecnologia di database sottostante non contengono un modello di distribuzione di questo tipo, ad esempio Postgres-BDR, un sistema attivo-attivo. Tali sistemi sono inclusi nella tabella precedente nella rispettiva categoria. Da un punto di vista multi-cloud, è irrilevante 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 una località di deployment a un'altra. In alternativa, per l'elaborazione downstream, potrebbe essere necessario replicare i dati di un database in un'altra posizione. Nella sezione seguente, la migrazione e la replica dei database sono trattate in modo più dettagliato.

Migrazione dei database

La migrazione dei database viene utilizzata quando un database viene spostato da una località 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 arrestato nel data center on-premise.

Gli approcci principali alla migrazione dei database sono i seguenti:

  • Incremento e variazione. La VM e i dischi che eseguono le istanze di database vengono copiati nell'ambiente di destinazione così come sono. Una volta copiati, vengono avviati e la migrazione completata.
  • Esportazione e importazione, nonché backup e ripristino. Questi approcci utilizzano entrambe le funzionalità di sistema del database per esternalizzare un database e ricrearlo nella posizione di destinazione. L'esportazione/importazione è basata in genere su un formato ASCII, mentre backup e ripristino si basano su un formato binario.
  • Migrazione senza tempo di inattività. In questo approccio, un database viene migrato mentre i sistemi di applicazione accedono al sistema di origine. Dopo un caricamento iniziale, le modifiche vengono trasmesse dall'origine al database di destinazione usando le tecnologie di CDC (Change Data Capture). L'applicazione presenta un tempo di inattività dal momento dell'arresto sul sistema di database di origine, fino a quando non viene riavviato nel sistema di database di destinazione dopo il completamento della migrazione.

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

La migrazione del database è un processo variegato. Per ulteriori informazioni, consulta Migrazione dei 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 dei database, ad esempio protocolli di esportazione/importazione, backup/ripristino o replica integrata. 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 finché ogni modifica viene trasmessa al database di destinazione.

La replica del database è un processo continuo che invia 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 prassi comune è replicare i dati da un database di origine a un sistema di analisi di destinazione.

Come per la migrazione dei database, se sono integrati i protocolli di replica, è possibile utilizzare la tecnologia integrata per i database per la replica dei database. Se non sono presenti protocolli di replica integrati, è possibile utilizzare la tecnologia di replica, ad esempio 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 genere disponibile quando sistemi di database diversi vengono utilizzati nei pattern di deployment, ad esempio la replica asincrona (eterogenea). È invece possibile eseguire il deployment di tecnologia di migrazione del database per abilitare questo tipo di replica. Alcuni di questi sistemi di migrazione implementano anche la replica bidirezionale.

Se è disponibile la tecnologia di migrazione o replica dei database per i sistemi di database utilizzati in 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 utilizzarlo per la replica del database. Il seguente diagramma mostra un approccio per la replica dei database tramite una tecnologia di migrazione.

Replica utilizzando la tecnologia di migrazione e replica dei database.

Nel diagramma precedente, il database nella località 1 viene replicato nel database nella località 2. Invece di una replica diretta del sistema di database, viene implementato un server di migrazione per implementare la replica. Questo approccio viene utilizzato per i sistemi di database in cui non è incorporata la funzionalità di replica di database e che devono fare affidamento su un sistema separato da quello del database per implementare la replica.

Selezione di database multi-cloud

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

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

Best practice per i sistemi di database esistenti

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

Albero decisionale per il sistema di database esistente.

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

  • È un sistema di database in produzione?
  • Se un sistema di database è in produzione, valuta se deve essere conservato.
    • Se il sistema di database deve essere mantenuto, viene presa una decisione e il processo è completato.
    • Se il sistema di database deve essere modificato o se la decisione è ancora in corso, seleziona un sistema di database (vai alla Decisione sulla gestione di database multi-cloud).

Decisione sulla gestione di database multi-cloud

La seguente struttura decisionale è relativa a un caso d'uso con requisiti di database multi-località (incluso un deployment di database multi-cloud). Utilizza i modelli di deployment come base per i criteri decisionali.

Albero decisionale per la gestione di database multi-cloud.

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

  • I dati sono partizionati in database diversi senza alcuna dipendenza tra database?
    • Se sì, puoi selezionare uno o più sistemi di database per ciascuna località.
    • In caso contrario, vai alla domanda successiva.
  • È necessaria una replica unidirezionale asincrona?
    • Se sì, valuta se un sistema di replica dei database è accettabile.
      • In caso affermativo, seleziona lo stesso o diversi sistemi di database compatibili con il sistema di replica.
      • In caso contrario, seleziona un sistema di database in grado di implementare un modello di distribuzione passivo attivo.
      • In caso contrario, vai alla domanda successiva.
  • Seleziona un sistema di database con istanze sincronizzate.
    • La risoluzione dei conflitti è accettabile?
      • In caso affermativo, seleziona un sistema di database di replica bidirezionale o un sistema di database attivo.
      • In caso contrario, seleziona un sistema attivo.

Se sono implementati più casi 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 unico sistema di database per supportare tutti i casi d'uso, il sistema con la sincronizzazione migliore è la scelta migliore. Ad esempio, se sono necessarie la replica unidirezionale e le istanze sincronizzate, la scelta migliore sono le istanze sincronizzate.

La gerarchia della qualità della sincronizzazione è compresa tra le seguenti (nessuna risposta migliore): replica partizionata, replica unidirezionale, replica bidirezionale e replica completamente sincronizzata.

Best practice per il deployment

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

Sistema di gestione di database esistente

Potrebbe essere buona norma conservare un database e non apportare modifiche al sistema del database, a meno che non sia necessario per un caso d'uso specifico. Per un'azienda con un sistema di gestione di database esistente e che dispone di processi di sviluppo, operativi e di manutenzione efficaci, potrebbe essere meglio evitare di apportare modifiche.

Un caso d'uso del bursting cloud 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 a 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 al momento di accedere al database.

Database System come servizio Kubernetes

Se un'azienda sta valutando l'esecuzione di un sistema di database in Kubernetes come servizio basato su StatefulSet, devono essere considerati i seguenti fattori:

  • Se il database fornisce il modello di database richiesto dall'applicazione.
  • Fattori non funzionali che determinano come viene implementata l'operatività in un sistema di database come servizio Kubernetes, ad esempio come viene eseguita la scalabilità (scalabilità in alto e in basso), come vengono gestiti il backup e il ripristino e come viene reso disponibile il monitoraggio dal sistema. Per aiutarli a comprendere i requisiti di un sistema di database basato su Kubernetes, le aziende dovrebbero utilizzare le proprie esperienze con i database come punto di confronto.
  • Alta disponibilità e ripristino di emergenza. Per garantire l'alta disponibilità, il sistema deve continuare a funzionare anche in caso di guasto di una zona all'interno di un'area geografica. Il database deve essere in grado di eseguire il failover rapido da una zona all'altra. Nel migliore dei casi, l'istanza del database è in esecuzione in ciascuna zona completamente sincronizzata con un RTO e un RPO pari a zero.
  • Ripristino di emergenza per risolvere un errore di un'area geografica (o cloud). In uno scenario ideale, il database continua a funzionare in una seconda area geografica con RPO e RTO pari a zero. In uno scenario meno ideale, il database nell'area geografica secondaria potrebbe non essere recuperato in modo completo in tutte le transazioni dal database principale.

Per determinare il modo migliore per eseguire un database all'interno di Kubernetes, una valutazione completa del database è un approccio corretto, soprattutto quando il sistema deve essere confrontabile con un sistema in produzione esterno a Kubernetes.

Sistema di database indipendente da Kubernetes

Non è sempre necessario per un'applicazione implementata come servizi in Kubernetes per eseguire il database in Kubernetes contemporaneamente. Ci sono molti motivi per cui un sistema di database deve essere eseguito al di fuori di Kubernetes, ad esempio processi consolidati, conoscenze dei prodotti all'interno di un'azienda o indisponibilità. In questa categoria rientrano sia i cloud provider sia i database gestiti da partner.

È ugualmente possibile e possibile eseguire un database su un motore di calcolo. Quando si seleziona un sistema di database, è buona norma eseguire una valutazione completa del database per assicurarsi che tutti i requisiti relativi a un'applicazione siano soddisfatti.

Dal punto di vista della progettazione dell'applicazione, il pool di connessioni è un fattore importante per la progettazione. Un servizio applicazioni che accede a un database potrebbe utilizzare internamente un pool di connessioni. L'utilizzo di un pool di connessioni è utile per l'efficienza e la latenza ridotta. Le richieste vengono recuperate dal pool senza che sia necessario l'avvio e non c'è nessuna attesa di creazione delle connessioni. Se l'applicazione è scaleup aggiungendo istanze del servizio dell'applicazione, ogni istanza crea un pool di connessioni. Se si seguono le best practice, ogni pool crea in anticipo un insieme minimo di connessioni. Ogni volta che viene creata un'altra istanza del servizio di applicazioni per la scalabilità delle applicazioni, vengono aggiunte connessioni al database. Dal punto di vista della progettazione, poiché i database non supportano 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 si selezionano sistemi di database, è comune per le aziende scegliere il sistema di database migliore per soddisfare i requisiti di un'applicazione. In un ambiente multi-cloud, è 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, è buona norma valutare e valutare contemporaneamente un approccio per un sistema di database disponibile in tutti i cloud richiesti. Un database di questo tipo potrebbe non essere ideale come l'opzione migliore, ma potrebbe essere molto più facile implementare, gestire e mantenere un sistema di questo tipo.

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

Replica di sistemi di database integrati e esterni

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

Per i sistemi che non supportano la replica nell'ambito della replica dell'implementazione del sistema, è possibile utilizzare sistemi come Striim per integrarne l'architettura (come spiegato nella migrazione del database).

Una best practice consiste nella valutazione di sistemi di gestione di 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 un terzo livello di tecnologia assume un ruolo significativo in questo caso. Questa classe fornisce componenti aggiuntivi ai sistemi di database esistenti per la replica. Un esempio è MariaDB Galera Cluster. Se il processo di valutazione lo consente, è buona norma valutare questi sistemi.

Passaggi successivi