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

Last reviewed 2024-03-06 UTC

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

Le architetture di applicazioni multicloud che accedono ai database dipendono dal caso d'uso. Nessuna singola architettura di applicazioni con stato può supportare tutti i casi d'uso multicloud. Ad esempio, la soluzione di database migliore per un caso d'uso di esplosione del cloud è diversa dalla soluzione di database migliore per un'applicazione che viene eseguita contemporaneamente in più ambienti cloud.

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

Questo documento introduce una definizione di applicazione di database con stato seguita da un'analisi del caso d'uso del database multicloud. Presenta poi una classificazione dettagliata dei sistemi di database per le architetture di deployment multicloud in base ai casi d'uso.

Il documento introduce anche una struttura decisionale per la selezione dei database che illustra i punti decisionali chiave per la selezione di una tecnologia di database appropriata. Termina con una discussione sulle best practice per la gestione dei database multicloud.

Termini e definizioni chiave

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

Terminologia

• Cloud pubblico. Un cloud pubblico fornisce un'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 è una combinazione di un cloud pubblico con uno o più data center on-premise. I clienti del cloud ibrido possono combinare i propri servizi on-premise con servizi aggiuntivi forniti da un cloud pubblico.
• Multicloud. Un multicloud è una combinazione di diversi cloud pubblici e data center on-premise. Un cloud ibrido è un sottoinsieme del cloud multi.
• Posizione di deployment. Una località dell'infrastruttura è una località fisica in cui è possibile eseguire il deployment ed eseguire i workload, tra cui applicazioni e database. Ad esempio, in Google Cloud le località di deployment sono zone e regioni. A livello astratto, una regione o una zona del cloud pubblico e un data center on-premise sono località di deployment.

Applicazioni di database stateful

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

Il diagramma mostra i seguenti componenti:

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

Nel contesto di una discussione sul database multicloud, l'astrazione architettonica di un'applicazione con stato è costituita da un database, da servizi e client di applicazioni. In un'implementazione di un'applicazione, fattori come l'utilizzo dei sistemi operativi o i linguaggi di programmazione impiegati possono variare. Tuttavia, questi dettagli non influiscono sulla gestione dei database multicloud.

Code e file come servizi di archiviazione dati

Esistono molte risorse di persistenza disponibili per i servizi di applicazione per memorizzare i dati. Queste risorse includono database, code di attesa e file. Ogni risorsa di persistenza fornisce modelli di dati di archiviazione e pattern di accesso specializzati per questi modelli. Sebbene le code, i sistemi di messaggistica e i sistemi di file siano utilizzati dalle applicazioni, nella sezione seguente l'attenzione è rivolta specificamente ai database.

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

Networking

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

Una connessione può trovarsi all'interno di una zona o in più zone, regioni o cloud. Le connessioni possono esistere tra qualsiasi combinazione di località di deployment. Negli ambienti multicloud, la rete tra i cloud è un aspetto importante da considerare 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 descritti in questo documento si presume quanto segue:

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

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

Casi d'uso dei database multicloud

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

Migrazione di applicazioni

Nel contesto della gestione dei database multicloud, la migrazione delle applicazioni si riferisce alla migrazione di un'applicazione, di tutti i servizi dell'applicazione 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 fornitore di cloud, per modernizzare la tecnologia o per ridurre il costo totale di proprietà (TCO).

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

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

• Migrazione lift and shift del database: se nello stesso cloud di destinazione è disponibile lo stesso motore del database, è possibile eseguire la migrazione lift and shift del database per creare un deployment identico nel cloud di destinazione.
• Eseguire il lift e il trasferimento di un database a un equivalente gestito: è possibile eseguire la migrazione di un database autonomo a una versione gestita dello stesso motore del database se il cloud di destinazione la fornisce.
• Modernizzazione dei database: i diversi cloud offrono tecnologie di database diverse. I database gestiti da un provider cloud potrebbero avere vantaggi come accordi sul livello del servizio (SLA) più rigorosi, scalabilità e ripristino automatico dei disastri.

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

Ripristino di emergenza

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

• Hot standby. L'applicazione viene dispiattata in due o più regioni (principale e secondaria) ed è completamente operativa in ogni regione. Se la regione principale non funziona, l'applicazione nella regione secondaria può assumere immediatamente il traffico dei client dell'applicazione.
• Modalità standby a freddo. L'applicazione è in esecuzione nella regione principale, ma è pronta per l'avvio in una regione secondaria (ma non è in esecuzione). Se la regione principale non funziona, l'applicazione viene avviata nella regione secondaria. Un'interruzione dell'applicazione si verifica finché l'applicazione non è in grado di funzionare e di fornire tutti i servizi dell'applicazione ai client dell'applicazione.
• Nessuna modalità standby. In questo modello, il codice dell'applicazione è pronto per il deployment, ma non è ancora stato implementato nella regione secondaria (e quindi non utilizza alcuna risorsa di cui è stato eseguito il deployment). Se si verifica un'interruzione nella regione principale, il primo deployment dell'applicazione deve essere nella regione secondaria. Questo deployment mette l'applicazione nello stesso stato di una modalità di attesa a freddo, il che significa che deve essere avviata. In questo approccio, l'interruzione dell'applicazione è più lunga rispetto al caso di standby a freddo perché deve prima essere eseguito il deployment dell'applicazione, che include la creazione di risorse cloud.

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

• Database sincronizzato tramite transazioni. Questo database corrisponde al modello di hot standby. Ogni transazione nella regione principale viene confermata in coordinamento sincrono in una regione secondaria. Quando la regione secondaria diventa la regione principale durante un'interruzione, il database è coerente e disponibile immediatamente. In questo modello, il Recovery Point Objective (RPO) e il Recovery Time Objective (RTO) sono entrambi equali a zero.
• Database con replica asincrona. Questo database corrisponde anche al modello di hot standby. Poiché la replica del database dalla regione principale alla regione secondaria è asincrona, è possibile che, in caso di errore nella regione principale, alcune transazioni vengano replicate nella regione secondaria. Anche se il database nella regione secondaria è pronto per il caricamento in produzione, potrebbe non contenere i dati più recenti. Per questo motivo, l'applicazione potrebbe subire una perdita di transazioni non recuperabili. A causa di questo rischio, questo approccio ha un RTO pari a zero, ma l'RPO è maggiore di zero.
• Database inattivo. Questo database corrisponde al modello di standby a freddo. Il database viene creato senza dati. Quando la regione principale non funziona, i dati devono essere caricati nel database inattivo. Per attivare 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 supporta il motore del database. In entrambi i casi, il database viene ripristinato all'ultimo backup e, dal punto di vista dell'applicazione, molte transazioni possono andare perse rispetto alla regione principale. Anche se questo approccio potrebbe essere conveniente, il valore è mitigato dal rischio che tutte le transazioni dall'ultimo backup disponibile possano andare perse a causa dell'aggiornamento dello stato del database.
• Nessun database. Questo modello è equivalente al caso no standby. Nella regione secondaria non è installato alcun database e, se la regione principale non funziona, è necessario crearne uno. Una volta creato il database, come nel caso del database inattivo, deve essere caricato con i dati prima di essere disponibile per l'applicazione.

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

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

Un altro approccio di ripristino di emergenza è avere una regione principale e una secondaria, nonché un cloud principale e uno secondario. Questo approccio consente alle aziende di scegliere il processo di ripristino di emergenza migliore per gestire 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

Per esplosione cloud si intende una configurazione che consente di aumentare il traffico dei client delle applicazioni su diverse località di deployment. Un'applicazione aumenta quando la domanda di capacità aumenta e un sito di riserva fornisce capacità aggiuntiva. Una località principale supporta il traffico regolare, mentre una località di riserva può fornire capacità aggiuntiva nel caso in cui il traffico dei client dell'applicazione aumenti oltre il limite supportato dalla località principale. Sia la posizione principale che quella di standby hanno istanze di servizi per applicazioni di cui è stato eseguito il deployment.

L'esplosione del cloud è implementata su cloud in cui un cloud è il cloud principale e un secondo cloud è il cloud di riserva. Viene utilizzato in un contesto di cloud ibrido per aumentare un numero limitato di risorse di calcolo nei data center on-premise con risorse di calcolo cloud elastiche in un cloud pubblico.

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

• Deployment della località principale. In questo deployment, il database viene eseguito solo nella posizione principale e non in quella di standby. Quando un'applicazione si espande, l'applicazione nella posizione di standby accede al database nella posizione principale.
• Deployment delle località principali e di riserva. Questo deployment supporta sia la posizione principale sia quella di riserva. Un'istanza di database viene dispiattata in entrambe le località e vi accedono le istanze di servizio di applicazione di quella località, in particolare in caso di picco. Come nel caso del ripristino di emergenza all'interno e tra cloud, i due database possono essere sincronizzati in base alle transazioni o in modo asincrono. Nella sincronizzazione asincrona può verificarsi un ritardo. Se gli aggiornamenti vengono eseguiti nella posizione di standby, devono essere propagati nuovamente alla posizione principale. Se sono possibili aggiornamenti contemporaneamente in entrambe le posizioni, è necessario implementare la risoluzione dei conflitti.

L'esplosione del 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 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 un'esplosione in una regione di un altro cloud pubblico nello stesso paese. Questo approccio garantisce che i dati rimangano all'interno del paese, risolvendo al contempo i vincoli delle risorse nelle regioni del cloud pubblico.

Utilizzo del servizio cloud migliore

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 aziendale dei dati aziendali in un cloud e l'analisi dei dati aziendali in un altro cloud. In questo caso d'uso, le parti di elaborazione della logica di business e quelle di analisi dell'applicazione vengono implementate in cloud diversi.

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

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

Servizi distribuiti

Un servizio distribuito viene implementato 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 implementare alcuni servizi in tutte le sedi e altri solo in una delle sedi, in base a fattori quali la disponibilità dell'hardware o il carico limitato previsto.

I dati in un database sincronizzato tramite transazioni sono coerenti in tutte le posizioni. Pertanto, questo tipo di database è la scelta migliore per eseguire il deployment delle istanze di servizio in tutte le località di deployment.

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

Trasferimento e failover dei servizi distribuiti

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

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

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

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

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

Deployment dipendente dal contesto

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

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

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

Dal punto di vista del database, è possibile eseguire il deployment di un database per ogni deployment dell'applicazione in una strategia di deployment uno a uno. Come mostrato nel diagramma seguente, questa strategia è un approccio diretto in cui vengono creati i dati partitioned perché ogni implementazione ha il proprio set di dati.

Il diagramma precedente mostra quanto segue:

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

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

In caso di multitenancy, gli utenti potrebbero essere spostati. Un tenant di piccole dimensioni potrebbe diventare di medie dimensioni e dover essere spostato in un'altra applicazione. In questo caso, i deployment dei database separati richiedono la migrazione del database. Se un database distribuito viene implementato e utilizzato contemporaneamente da tutti i deployment, tutti i dati del tenant risiedono in un unico sistema di database. Per questo motivo, il trasferimento di un tenant da un database all'altro 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 di ogni implementazione.
• Non è stato implementato alcun partizionamento dei dati.

Se un'azienda sposta spesso gli utenti 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 i database prima di una migrazione del tenant. In questo caso, vengono utilizzati database indipendenti per i diversi implementazioni dell'applicazione e vengono configurati per la replica solo immediatamente prima e durante la migrazione del tenant. Il diagramma seguente mostra una replica temporanea tra due deployment dell'applicazione durante la migrazione di un tenant.

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

Portabilità delle applicazioni

La portabilità delle applicazioni garantisce che un'applicazione possa essere implementata in diverse località di implementazione, in particolare in cloud diversi. Questa portabilità garantisce che sia possibile eseguire la migrazione di un'applicazione in qualsiasi momento, senza bisogno di eseguire la riprogettazione specifica per la migrazione o di sviluppare ulteriormente l'applicazione per prepararsi alla migrazione.

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

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

La portabilità basata sul sistema utilizza gli stessi componenti tecnici utilizzati in tutti i possibili implementazioni. Per garantire la portabilità basata sul sistema, ogni tecnologia deve essere disponibile in tutte le potenziali località di implementazione. Ad esempio, se un database come PostgreSQL è un candidato, la sua disponibilità in tutte le potenziali località di implementazione 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 seguente diagramma, questo approccio stabilisce un insieme di funzionalità comuni in tutte le località di implementazione in base alla tecnologia.

Il diagramma precedente mostra un deployment di un'applicazione portatile in cui l'applicazione si aspetta lo stesso sistema di database in ogni posizione in cui viene eseguita la distribuzione. Poiché in ogni località viene utilizzato lo stesso sistema di database, l'applicazione è trasportabile. L'applicazione può prevedere che verrà utilizzato lo stesso sistema di database in tutto il deployment. Pertanto, si può assumere che l'interfaccia e il comportamento del sistema di database siano esattamente gli stessi.

Nel contesto dei database, nel sistema di compatibilità con le API, il client utilizza una libreria di accesso al 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 ciascuna località, l'API è la stessa ed espone le stesse funzionalità. L'applicazione è portabile perché può assumere la stessa API in ogni posizione, anche se il sistema di database sottostante è una tecnologia di database diversa.

Nella portabilità basata sulla funzionalità, potrebbero essere utilizzate tecnologie diverse in cloud diversi che forniscono la stessa funzionalità. Ad esempio, potrebbe essere possibile limitare l'utilizzo dei database al modello relazionale. Poiché qualsiasi sistema di database relazionale può supportare l'applicazione, è possibile utilizzare diversi sistemi di database su versioni diverse in cloud diversi senza influire sulla portabilità dell'applicazione. Uno svantaggio della portabilità basata sulle funzionalità è che può utilizzare solo le parti del modello di database supportate da tutti i sistemi di database relazionali. 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 mostrato nel diagramma precedente, l'API del sistema di database e il sistema di database potrebbero essere diversi in ogni località. Per garantire la portabilità, l'applicazione deve utilizzare solo le parti di ciascun sistema di database e di ciascuna API disponibili in ogni località. Poiché in ogni località è comunemente disponibile solo un sottoinsieme di ciascun sistema di database, l'applicazione deve limitare il proprio utilizzo a questo sottoinsieme.

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

Prevenzione della dipendenza dai fornitori

La prevenzione della dipendenza dal fornitore (lock-in) contribuisce a ridurre il rischio di dipendenza da una tecnologia e da un fornitore specifici. È superficialmente simile alla portabilità delle applicazioni. La prevenzione della dipendenza dai fornitori 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 in cloud, non esiste dipendenza dal punto di vista del cloud, ma esiste una dipendenza da MySQL. Un'applicazione trasferibile tra cloud potrebbe comunque dipendere da tecnologie fornite da fornitori diversi 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 in una base di tecnologia diversa senza influire sul modo in cui l'applicazione è implementata. Dal punto di vista del database, questa astrazione può essere eseguita separando l'utilizzo di un modello di database da un determinato sistema di gestione del database.

Sistema di gestione del database di produzione esistente

Sebbene molte applicazioni multicloud vengano sviluppate con sistemi di database come parte del loro design, molte aziende sviluppano applicazioni multicloud nell'ambito del loro impegno di modernizzazione delle applicazioni. Queste applicazioni vengono sviluppate con la premessa che l'applicazione appena progettata e implementata acceda ai database esistenti.

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

Quando un'azienda utilizza un sistema di database esistente, il progettista dell'applicazione multicloud deve decidere se sarà l'unico database utilizzato o se è necessario aggiungere un altro sistema di database per località di implementazione 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 dell'applicazione di cui è stato eseguito il deployment su Google Cloud accedono al database on-premise. In alternativa, se è necessario implementare un secondo database sia in Google Cloud sia per i servizi di applicazione in esecuzione locale.

Se in Google Cloud viene eseguito il deployment di un secondo database, il caso d'uso potrebbe essere lo stesso dei casi d'uso descritti in Espansione in cloud o Servizi distribuiti. In entrambi i casi, si applica la stessa discussione sul database riportata in queste sezioni. Tuttavia, è limitata alle funzionalità tra sedi supportate dal database on-premise esistente, ad esempio la sincronizzazione e la replica.

Pattern di deployment

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

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

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

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

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

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

Partizionato senza dipendenza tra database

Questo modello di implementazione è il più semplice di tutti quelli discussi 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 dati viene memorizzato 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 mostrato nel diagramma precedente, un'applicazione viene dispiattata in due posizioni, ciascuna responsabile di una partizione dell'intero set di dati. Ogni elemento di dati si trova in una sola delle posizioni, garantendo un set di dati partizionato senza alcuna replica tra le due.

Un modello di implementazione alternativo per i database partizionati è quando il set di dati è completamente partizionato, ma comunque archiviato nello stesso database. Esiste un solo database contenente tutti i set di dati. Sebbene i set di dati siano archiviati nello stesso database, sono completamente separati (partizionati) e una modifica di uno non causa modifiche in un altro. Il seguente diagramma mostra due applicazioni che condividono un unico database.

Il diagramma precedente mostra quanto segue:

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

Replica unidirezionale asincrona

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

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

Replica bidirezionale con risoluzione dei conflitti

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

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

Sistema distribuito completamente attivo-attivo e sincronizzato

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

Come mostrato nel 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 database. Qualsiasi modifica viene applicata a entrambi i database quando avviene un commit di transazioni con modifiche.

Classificazione del sistema di database

Non tutti i sistemi di gestione del database possono essere utilizzati allo stesso modo per gli schemi di implementazione descritti 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 solo un sottoinsieme di sistemi di database.

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

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

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

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

Sistema di database per architettura di deployment

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

• Database cloud integrati. I database cloud integrati sono progettati, costruiti e ottimizzati per funzionare con la tecnologia cloud. Ad esempio, alcuni sistemi di database utilizzano Kubernetes come piattaforma di implementazione e le relative funzionalità. CockroachDB e YugaByte sono esempi di questo tipo di database. Possono essere implementati in qualsiasi cloud che supporta Kubernetes.
• Database gestiti dal provider cloud. I database gestiti dal provider cloud sono basati su tecnologia specifica del provider cloud e sono un servizio di database gestito da un provider cloud specifico. Spanner, Bigtable e AlloyDB per PostgreSQL sono esempi di questo tipo di database. I database gestiti dal provider cloud sono disponibili solo nel cloud del provider cloud e non possono essere installati ed eseguiti altrove. Tuttavia, AlloyDB per PostgreSQL è completamente compatibile con PostgreSQL.
• Database pre-cloud. I database pre-cloud esistevano prima dello sviluppo della tecnologia cloud (a volte per molto tempo) e di solito vengono eseguiti su hardware bare metal e macchine virtuali (VM). PostgreSQL, MySQL e SQL Server sono esempi di questo tipo di database. Questi sistemi possono essere eseguiti su qualsiasi cloud che supporti le VM o l'hardware bare metal richieste.
• Database gestiti da partner cloud. Alcuni cloud pubblici hanno partner di database che installano e gestiscono i database dei clienti nel cloud pubblico. Per questo motivo, i clienti non devono gestire questi database autonomamente. 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 tecnologia creata per il cloud e un'offerta gestita ai clienti nel cloud fornito dal fornitore. Questo approccio è equivalente al fornitore che fornisce un cloud pubblico che supporta solo il proprio database come singolo servizio.

I database pre-cloud potrebbero anche essere in container e potrebbero essere dispiabili in un cluster Kubernetes. Tuttavia, questi database non utilizzano funzionalità specifiche di Kubernetes come il ridimensionamento, il multiservizio o il deployment multi-pod.

I fornitori di database potrebbero collaborare con più di un provider di cloud pubblico contemporaneamente, offrendo il proprio 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 del database vengono implementati in base ai modelli di distribuzione nell'architettura di un database. I modelli per i database sono i seguenti:

• Singola istanza. Una singola istanza di database viene eseguita su una VM o un container e funge da sistema centralizzato. Questo sistema gestisce tutto l'accesso al database. Poiché la singola istanza non può essere collegata a nessun'altra istanza, il sistema di database non supporta la replica.
• Multi-istanza attivo-passivo. In questa architettura comune, diverse istanze di database sono collegate tra loro. Il collegamento più comune è una relazione attiva-passiva in cui un'istanza è l'istanza di database attiva che supporta entrambe le istanze e le operazioni di scrittura e lettura. Uno o più sistemi passivi sono di sola lettura e ricevono tutte le modifiche al database dal principale in modo sincrono o asincrono. I sistemi passivi possono fornire l'accesso in lettura. La configurazione attiva-passiva è indicata anche come principale-secondario o sorgente-replica.
• Multi-istanza active-active. In questa architettura relativamente insolita, ogni 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.
• Multi-istanza active-active con risoluzione dei conflitti. Si tratta anche di un sistema relativamente insolito. Ogni istanza è disponibile per l'accesso in lettura e scrittura, tuttavia i database vengono sincronizzati in modalità asincrona. Sono consentiti aggiornamenti simultanei dello stesso elemento di dati, il che porta a uno stato inconsistente. Un criterio di risoluzione dei conflitti deve decidere quale stato è l'ultimo stato coerente.
• Sharding multi-istanza. Lo sharding si basa sulla gestione di partizioni (disconnesse) di dati. Ogni partizione viene gestita da un'istanza del database separata. Questa distribuzione è scalabile perché è possibile aggiungere più frammenti dinamicamente nel tempo. Tuttavia, le query tra shard potrebbero non essere possibili perché questa funzionalità non è supportata da tutti i sistemi.

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

I modelli di distribuzione sono diversi per i database cloud e gestiti dal partner. Poiché questi database sono legati all'architettura di un provider cloud, questi sistemi implementano architetture in base alle seguenti posizioni di implementazione:

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

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

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

Mappatura dei sistemi di database ai pattern di deployment

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

Architettura di deployment	Modello di deployment
	Partizionato senza dipendenza tra database	Replica unidirezionale asincrona	Replica bidirezionale con risoluzione dei conflitti	Sistema distribuito completamente attivo-attivo e sincronizzato
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 diversi sistemi di database.	Database cloud che fornisce la replica.	Database cloud che fornisce la replica bidirezionale.	Database cloud che fornisce la sincronizzazione primaria-principale.
Database gestiti dal provider cloud	I sistemi di database possono essere diversi in cloud diversi.	La replica non deve essere il database gestito dal provider cloud (consulta Il ruolo della tecnologia di migrazione del database nei pattern di implementazione).	Solo all'interno di un cloud, non tra cloud, se il database fornisce la 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 in più cloud.	Il sistema di database fornisce la replica bidirezionale e la risoluzione dei conflitti.	Il sistema di database fornisce la sincronizzazione principale-principale.
Database gestiti da partner cloud	I sistemi di database possono essere diversi in cloud diversi. Se il partner fornisce un sistema di database gestito in tutti i cloud richiesti, è possibile utilizzare lo stesso database.	La replica non deve essere il database gestito dal provider cloud. Se il partner fornisce un sistema di database gestito in tutti i cloud richiesti, è possibile utilizzare lo stesso database.	Il sistema di database fornisce la replica bidirezionale e la risoluzione dei conflitti.	Il sistema di database fornisce la sincronizzazione principale-principale.

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

La tabella seguente mette in relazione i pattern di implementazione con i modelli di distribuzione. I campi indicano le condizioni per le quali è possibile la combinazione in base a un pattern di implementazione e a un modello di distribuzione.

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

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

Migrazione e replica del database

A seconda del caso d'uso, un'azienda potrebbe dover eseguire la migrazione di un database da un sito di implementazione a un altro. In alternativa, per l'elaborazione a valle, potrebbe essere necessario replicare i dati di un database in un'altra posizione. Nella sezione seguente, la migrazione e la replica del database vengono discusse in più dettaglio.

Migrazione del database

La migrazione del database viene utilizzata quando un database viene spostato da una posizione di deployment a un'altra. Ad esempio, viene eseguita la migrazione di un database in esecuzione in un data center on-premise in modo che venga eseguito nel cloud. Al termine della migrazione, il database viene arrestato nel data center on-premise.

I principali approcci alla migrazione del database sono i seguenti:

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

La migrazione del database diventa pertinente nei casi d'uso multicloud quando un database viene trasferito da un cloud all'altro o da un tipo di motore del database a un altro.

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

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

Replica dei database

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

La replica del database è un processo continuo che invia le modifiche dal database di origine al database di destinazione. Quando questo processo è asincrono, le modifiche arrivano al database di destinazione dopo un breve ritardo. Se la procedura è sincrona, le modifiche apportate al sistema di origine vengono applicate al sistema di destinazione contemporaneamente 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 del database, se sono disponibili protocolli di replica, la tecnologia del database integrata può essere utilizzata per la replica del 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 del database nei pattern di implementazione

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

Se è disponibile una tecnologia di migrazione o replica del database 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 implementazione, potrebbe essere possibile utilizzarla per la replica del database. Il seguente diagramma mostra un approccio per la replica del database utilizzando una tecnologia di migrazione.

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

Selezione di database multicloud

I casi d'uso dei database multicloud combinati con la classificazione del sistema di database ti aiutano a decidere quali database sono i migliori per un determinato caso d'uso. Ad esempio, per implementare il caso d'uso nella portabilità delle applicazioni, sono disponibili due opzioni. La prima opzione è assicurarti che lo stesso motore del database sia disponibile in tutti i cloud. Questo approccio garantisce la portabilità del sistema. La seconda opzione è assicurarti che lo stesso modello dei dati e la stessa interfaccia di query siano disponibili per tutti i cloud. Sebbene i sistemi di database possano essere diversi, la portabilità viene fornita su un'interfaccia funzionale.

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

Best practice per il sistema di database esistente

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

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

• Esiste un sistema di database in produzione?
  • Se non è presente alcun sistema di database di produzione, selezionane uno (vai alla sezione Decisione sulla gestione del database multicloud).
  • Se un sistema di database è in produzione, valuta se deve essere mantenuto.
• Se un sistema di database è in produzione, valuta se deve essere mantenuto.
  • Se il sistema di database deve essere mantenuto, la decisione è stata presa e la procedura decisionale è completata.
  • Se il sistema di database deve essere modificato o se la decisione è ancora in corso, seleziona un sistema di database (vai alla sezione Decisione sulla gestione del database multicloud).

Decisione sulla gestione del database multicloud

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

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

• I dati sono suddivisi in database diversi senza alcuna dipendenza tra database?
  • In caso affermativo, è possibile selezionare sistemi di database uguali o diversi per ogni località.
  • In caso contrario, vai alla domanda successiva.
• È necessaria la replica unidirezionale asincrona?
  • In caso affermativo, valuta se è accettabile un sistema di replica del database.
    • In caso affermativo, seleziona sistemi di database uguali o diversi compatibili con il sistema di replica.
    • In caso contrario, seleziona un sistema di database in grado di implementare un modello di distribuzione attivo-passivo.
    • 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 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 multicloud, un'azienda deve decidere se 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 è necessaria la replica unidirezionale e le istanze sincronizzate, la scelta migliore è quella delle istanze sincronizzate.

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

Best practice per l'implementazione

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

Sistema di gestione del database esistente

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

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

Sistema di database come servizio Kubernetes

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

• Se il database fornisce il modello di database richiesto dall'applicazione.
• Fattori non funzionali che determinano come viene implementata l'operatività in un sistema di database come servizio Kubernetes, ad esempio come viene eseguito il ridimensionamento (up e down), come vengono gestiti il backup e il ripristino e come il monitoraggio viene reso disponibile dal sistema. Per aiutarle a comprendere i requisiti di un sistema di database basato su Kubernetes, le aziende devono utilizzare le loro esperienze con i database come punto di confronto.
• Alta disponibilità e ripristino di emergenza. Per garantire un'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 rapidamente 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 gestire l'errore di una regione (o di un cloud). In uno scenario ideale, il database continua a funzionare in una seconda regione con RPO e RTO pari a zero. In uno scenario meno ideale, il database nella regione secondaria potrebbe non essere completamente aggiornato su tutte le transazioni del database principale.

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

Sistema di database indipendente da Kubernetes

Non è sempre necessario che un'applicazione implementata come servizi in Kubernetes esegua contemporaneamente il database 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à. In questa categoria rientrano sia i provider cloud sia i database gestiti da partner cloud.

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

Dal punto di vista della progettazione dell'applicazione, il pooling delle connessioni è un'importante considerazione di progettazione. Un servizio di applicazione 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 riduzione della latenza. Le richieste vengono invece prese dal pool senza bisogno di essere avviate e non è necessario attendere la creazione delle connessioni. Se l'applicazione viene scalata aggiungendo istanze di servizio dell'applicazione, ogni istanza crea un pool di connessioni. Se vengono seguite le best practice, ogni pool pre-crea un insieme minimo di connessioni. Ogni volta che viene creata un'altra istanza di servizio dell'applicazione per l'escaling dell'applicazione, vengono aggiunte connessioni al database. Dal punto di vista del design, poiché i database non possono supportare un numero illimitato di connessioni, l'aggiunta di connessioni deve essere gestita per evitare il sovraccarico.

Il miglior sistema di database rispetto alla portabilità del sistema di database

Quando selezionano i sistemi di database, le aziende scelgono spesso il sistema 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 un impegno significativo. Questo approccio potrebbe essere giustificato se il vantaggio dell'utilizzo del sistema migliore supera lo sforzo necessario per implementarlo.

Tuttavia, è buona norma prendere in considerazione 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 implementare, gestire e mantenere un sistema di questo tipo.

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

Replica del sistema di database integrato ed esterno

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

Per i sistemi che non supportano la replica nell'ambito della replica dell'implementazione del sistema, è possibile utilizzare sistemi come Striim per integrare l'architettura (come discusso in Migrazione del database).

Una best practice consiste nel valutare sistemi di gestione del 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 in questo caso è presente una terza classe di tecnologia. Questa classe fornisce componenti aggiuntivi ai sistemi di database esistenti per fornire la replica. Un esempio è MariaDB Galera Cluster. Se il processo di valutazione lo consente, è buona prassi valutare questi sistemi.

Passaggi successivi

• Scopri di più su modelli e best practice per ambienti ibridi e multi-cloud.
• Scopri i pattern per connettere altri fornitori di servizi cloud a Google Cloud.
• Scopri le architetture di monitoraggio e logging per i deployment ibridi e multi-cloud su Google Cloud.
• Per altre architetture di riferimento, diagrammi e best practice, visita il Cloud Architecture Center.

Collaboratori

Autore: Alex Cârciu | Solutions Architect