Gestione di 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 di database multi-cloud. È destinata ad architetti e ingegneri che progettano e implementano applicazioni stateful all'interno e all'interno nuvole.

Le architetture di applicazioni multi-cloud che accedono ai database sono casi d'uso dipendono da te. Nessuna singola architettura delle applicazioni stateful è in grado di supportare e i casi d'uso multi-cloud. Ad esempio, la migliore soluzione di database per esplosione di nuvole è diverso dalla migliore soluzione di database per un'applicazione vengono eseguite contemporaneamente in più ambienti cloud.

Per i cloud pubblici come Google Cloud, esistono varie tecnologie di database per casi d'uso multi-cloud specifici. Per eseguire il deployment di un'applicazione: in più regioni all'interno di un singolo cloud pubblico, un'opzione è utilizzare un per un database multiregionale gestito da provider, Spanner. Per eseguire il deployment di un'applicazione in modo che sia portabile tra cloud pubblici, potrebbe essere una scelta migliore, ad esempio PostgreSQL.

Questo documento introduce una definizione di applicazione di database stateful seguita da un'analisi del caso d'uso di un database multi-cloud. Quindi presenta una dettagliato categorizzazione dei sistemi di database per architetture di deployment multi-cloud basate sui casi d'uso.

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

Termini chiave e definizioni

Questa sezione fornisce una terminologia e definisce il tipo un'applicazione di database utilizzata in questo documento.

Terminologia

• Cloud pubblico. Un cloud pubblico offre dell'infrastruttura (generalmente globale) e dei servizi che i clienti possono usare dei carichi di lavoro di produzione. Google Cloud è un cloud pubblico offre molti servizi gestiti, inclusi GKE GKE Enterprise e database gestiti.
• Cloud ibrido. Un cloud ibrido è una combinazione di cloud pubblico uno o più data center on-premise. I clienti del cloud ibrido possono combinare i propri servizi on-premise con servizi aggiuntivi forniti da nel cloud pubblico.
• Multi-cloud Un multi-cloud è la combinazione di più cloud pubblici cloud e on-premise. Un cloud ibrido è un sottoinsieme e multi-cloud.
• Località di deployment. Una località dell'infrastruttura è una posizione in cui eseguire il deployment e i carichi di lavoro, incluse applicazioni o Microsoft SQL Server. Ad esempio, in Google Cloud, le località di deployment in zone e regioni. A livello astratto, una regione o una zona cloud pubblico sono le località di deployment di un data center on-premise.

Applicazioni di database stateful

Per definire i casi d'uso multi-cloud, un'applicazione di database stateful generica è usata in questo documento, come illustrato nel diagramma seguente.

Il diagramma mostra i seguenti componenti:

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

Nel contesto di una discussione sui database multi-cloud, l'architettura di un'applicazione stateful è composta da un database, un'applicazione e client di applicazioni. Nell'implementazione di un'applicazione, come l'uso dei sistemi operativi o dei linguaggi di programmazione che possono variare. Tuttavia, questi dettagli non influiscono sul multi-cloud e la gestione dei database.

Code e file come servizi di archiviazione dati

Sono disponibili molte risorse di persistenza per i servizi delle applicazioni di conservare i dati in modo permanente. tra cui database, code e file. Ciascuna una risorsa di persistenza fornisce modelli dei dati di archiviazione e pattern di accesso specializzato per questi modelli. Sebbene code, sistemi di messaggistica e sistemi usati dalle applicazioni. Nella sezione seguente, in particolare sui database.

Anche se le stesse considerazioni per fattori come la località di deployment, condivisione dello stato, replica sincrona e asincrona per multi-cloud applicabili a code e file, questa discussione è al di fuori nell'ambito di questo documento.

Networking

Nell'architettura di un'applicazione stateful generica (mostrata nuovamente nell'illustrazione seguente), ciascuna freccia tra i componenti rappresenta una relazione su una connessione di rete, ad esempio un client applicazione che accede al servizio di un'applicazione.

Una connessione può trovarsi all'interno di una zona o tra zone, regioni o cloud. Possono esistere connessioni tra qualsiasi combinazione di località di deployment. Nella ambienti multi-cloud, il networking tra cloud è un e ci sono diverse opzioni a tua disposizione. Per maggiori informazioni per informazioni sul networking tra cloud, consulta Connessione a Google Cloud: spiegazione delle opzioni di networking.

Nei casi d'uso del presente documento si presume quanto segue:

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

Da un punto di vista non funzionale, la dimensione della rete, vale a dire e la latenza, potrebbero influire sulla latenza e sulla velocità effettiva del database. Da un funzionale, il networking in genere non ha alcun effetto.

Casi d'uso dei database multi-cloud

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

Migrazione di applicazioni

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

Nella migrazione delle applicazioni, l'intento è quello di interrompere la produzione nell'attuale cloud e continuare la produzione nel cloud di destinazione al termine della migrazione. La devono essere eseguiti nel cloud di destinazione. Per implementare i servizi, lift and shift dell'IA generativa. In questo approccio, il deployment dello stesso codice viene eseguito cloud. Per reimplementare il servizio, le moderne tecnologie cloud che disponibili nel cloud di destinazione.

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

• Impatto e spostamento del database: se è disponibile lo stesso motore del database nel cloud di destinazione, è possibile eseguire il lift and shift del database per creare e un deployment identico nel cloud di destinazione.
• Impatto del database e passaggio all'equivalente gestito: una soluzione autogestita è possibile eseguire la migrazione del database a una versione gestita dello stesso motore del database se viene fornito dal cloud di destinazione.
• Modernizzazione dei database: cloud diversi offrono database diversi tecnologie. I database gestiti da un provider cloud potrebbero avere vantaggi come gli accordi sul livello del servizio (SLA) più rigidi, la scalabilità e ripristino di emergenza.

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

Ripristino di emergenza

Per ripristino di emergenza si intende la capacità di un'applicazione di continuare ai client delle applicazioni durante l'interruzione di una regione. Per garantire il disastro il ripristino, un'applicazione deve essere sottoposta a deployment in almeno due regioni ed essere pronta in qualsiasi momento. In produzione, l'applicazione viene eseguita nell'istanza regione. Tuttavia, in caso di interruzione, una regione secondaria diventa la regione principale regione. Di seguito sono riportati diversi modelli di idoneità per il ripristino di emergenza:

• Hot standby. Il deployment dell'applicazione viene eseguito in due o più regioni (primari e secondari) e l'applicazione funziona perfettamente in ogni regione. In caso di errore della regione principale, l'applicazione nella regione secondaria possono gestire immediatamente il traffico del client dell'applicazione.
• Modalità freddo. L'applicazione è in esecuzione nella regione principale, Tuttavia, è pronto per l'avvio in una regione secondaria (ma non in esecuzione). Se si verifica un errore della regione principale, l'applicazione viene avviata regione. Si verifica un'interruzione dell'applicazione finché non può essere eseguita e fornire tutti i servizi per le applicazioni ai client di applicazioni.
• Nessun standby. In questo modello, il codice dell'applicazione è pronto ma non nella regione secondaria (quindi non utilizzando risorse di cui è stato eseguito il deployment). Se si verifica un'interruzione in una regione principale, la prima il deployment dell'applicazione deve trovarsi nella regione secondaria. Questo il deployment mette l'applicazione nello stesso stato di un cold standby, che deve essere avviato. In questo approccio, l'interruzione del servizio è più lungo rispetto al caso in cold standby perché il deployment dell'applicazione deve avvenire prima, con la creazione di risorse cloud.

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

• Database con sincronizzazione delle transazioni. Questo database corrisponde il modello hot_standby. Ogni transazione nella regione principale è impegnata nel coordinamento sincrono in una regione secondaria. Quando l'oggetto secondario principale diventa la regione principale durante un'interruzione, il database coerente e immediatamente disponibile. In questo modello, il Recovery Point Objective (RPO) e il Recovery Time Objective (RTO) entrambi zero.
• Database replicato in modo asincrono. Questo database corrisponde anche al modello hot_standby. Poiché la replica del database dall'istanza principale regione secondaria alla regione secondaria è asincrona, c'è la possibilità che Se la regione principale non riesce, alcune transazioni potrebbero essere replicate la regione secondaria. Mentre il database nella regione secondaria è pronto per di produzione, potrebbe non avere i dati più aggiornati. 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 diverso da zero.
• Database in modalità di inattività: Questo database corrisponde al modello cold standby. La viene creato senza dati. In caso di errore della regione principale, deve essere caricato nel database inattivo. Per attivare questa azione, viene utilizzata il backup deve essere eseguito nella regione principale e trasferito regione secondaria. Il backup può essere completo o incrementale, a seconda supportate dal motore del database. In entrambi i casi, il database viene reimpostato su dall'ultimo backup e, dal punto di vista dell'applicazione, molte transazioni potrebbero andare perse rispetto alla regione principale. Anche se questo potrebbe essere conveniente, il valore è mitigato dal rischio che tutte le transazioni dall'ultimo backup disponibile potrebbero andare perse a causa lo stato del database non è aggiornato.
• Nessun database. Questo modello è equivalente alla richiesta no standby. La regione secondaria non ha database installato e se la regione principale un errore, è necessario creare un database. Dopo aver creato il database, come caso del database inattivo, deve essere caricato con dati prima che sia disponibile per l'applicazione.

Gli approcci al ripristino di emergenza descritti in questo documento si applicano anche se vengono utilizzati un cloud primario e uno secondario al posto di uno regione. La differenza principale è che, a causa dell'eterogeneità di rete tra tra le nuvole, la latenza tra le nuvole potrebbe aumentare rispetto alla rete tra regioni all'interno di un cloud. Altre discrepanze possono funzionalità diverse e impostazioni predefinite dei database gestiti di database di Google Cloud.

La probabilità di errore dell'intero cloud è inferiore a quella di errore di una regione. Tuttavia, per le aziende potrebbe essere comunque utile avere distribuite in due cloud. Questo approccio può aiutare a proteggere la società contro i fallimenti o per aiutarla a soddisfare i regolamenti aziendali o di settore.

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

Cloud bursting

Il cloud bursting è una configurazione che consente lo scale up del traffico client dell'applicazione in diverse località di deployment. Un'applicazione esegue il burst quando la domanda per aumentare la capacità, mentre una posizione in standby fornisce capacità aggiuntiva. R principale supporta il traffico regolare, mentre una località in standby può forniscono capacità aggiuntiva in caso di aumento del traffico client dell'applicazione oltre a quelli supportati dalla sede principale. Sia l'interfaccia principale sia quella di standby in cui è stato eseguito il deployment delle istanze del servizio delle applicazioni.

Il cloud bursting viene implementato in più cloud dove un cloud è il cloud primario mentre un secondo è il cloud in standby. Viene utilizzato in un cloud ibrido contesto per aumentare un numero limitato di risorse di calcolo nei dati on-premise con risorse di calcolo cloud elastiche in un cloud pubblico.

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

• Deployment della località principale. In questo deployment, il database il deployment viene eseguito solo nella località principale e non in quella in standby. Quando un'applicazione esegue il burst, l'applicazione nella posizione in standby accede del database nella località principale.
• Deployment della località principale e in standby. Questo deployment supporta sia quella principale sia quella di standby. Il deployment di un'istanza di database viene eseguito entrambe le località e vi si accede dalle istanze del servizio delle applicazioni in ogni posizione, soprattutto in caso di scoppi. Come in Ripristino di emergenza all'interno e tra i cloud, I due database possono essere sincronizzati con le transazioni o in modo asincrono sincronizzati. Nella sincronizzazione asincrona può verificarsi un ritardo. Se gli aggiornamenti sono in corso nella posizione di standby, questi aggiornamenti hanno vengano propagati nella località principale. Se gli aggiornamenti simultanei vengono possibile in entrambe le località, occorre implementare la risoluzione dei conflitti.

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

Utilizzo dei servizi cloud senza pari

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

Per quanto riguarda la 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 è connesso direttamente tra loro. L'applicazione che gestisce i dati scrive tutti i dati che deve essere disponibile due volte in entrambi i database (partizioni).
• Database replicato in modo asincrono. Se i dati di un cloud devono nell'altro cloud, una relazione di replica asincrona potrebbero essere appropriati. Ad esempio, se un'applicazione di analisi richiede lo stesso set di dati o un sottoinsieme per un'applicazione aziendale, quest'ultimo può essere replicato tra le nuvole.
• Database con sincronizzazione delle transazioni. Questi tipi di database consentono per rendere i dati disponibili per entrambe le parti dell'applicazione. Ogni aggiornamento da ciascuna delle applicazioni è coerente dal punto di vista transazionale e disponibile entrambi i database (partizioni). Sincronizzazione transazionale agiscono efficacemente come un unico database distribuito.

Servizi distribuiti

Il deployment di un servizio distribuito viene eseguito in due o più deployment. luoghi. È possibile eseguire il deployment di tutte le istanze di servizio luoghi. In alternativa, è possibile eseguire il deployment di alcuni servizi di località e alcune solo in una di esse, in base a fattori quali la disponibilità dell'hardware o un carico limitato previsto.

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

Quando utilizzi un database replicato asincrono, esiste il rischio che lo stesso dell'elemento dati da modificare contemporaneamente in due località di deployment. Per determinare quale delle due modifiche in conflitto è lo stato coerente finale, strategia di risoluzione dei conflitti. Sebbene sia possibile implementare una strategia di risoluzione dei conflitti, non è sempre facile e ci sono casi in cui è necessario un intervento manuale per ripristinare i dati coerente.

Relocation e failover dei servizi distribuiti

In caso di errore di un'intera regione cloud, ripristino di emergenza viene avviata. In caso di errore di un singolo servizio in un'applicazione di database stateful (non la regione o l'intera applicazione), il servizio deve essere è stato recuperato e riavviato.

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

Tuttavia, se questo approccio di riavvio in loco non ha esito positivo, è disponibile un'alternativa per riavviare il servizio in una località secondaria. Il failover del servizio viene eseguito dalla località principale a una seconda. Se l'applicazione è di cui è stato eseguito il deployment servizi distribuiti, il failover di un singolo servizio può avvenire in modo dinamico.

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

Se un servizio viene trasferito temporaneamente e se la latenza è elevata accettabili per un'azienda durante il trasferimento, il servizio potrebbe accedere con il database nelle varie località di deployment. Anche se il servizio viene trasferito, continua ad accedere al database come farebbe dalla sua origine della località di deployment.

Deployment dipendente dal contesto

In generale, il deployment di un'unica applicazione per gestire tutti i client dell'applicazione include tutti i servizi per le applicazioni e i database. Tuttavia, ci sono casi d'uso eccezionali. Il deployment di una singola applicazione può gestire solo un sottoinsieme di clienti (in base a criteri specifici), il che significa che del deployment dell'applicazione. Ogni deployment gestisce un sottoinsieme diverso e tutti i deployment insieme servono tutti i client.

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

• Quando viene eseguito il deployment di un'applicazione multi-tenant per la quale è stato eseguito il deployment di un'applicazione per tutti i tenant di piccole dimensioni, viene eseguito il deployment di un'altra applicazione ogni 10 medi tenant, e viene eseguito il deployment di un'applicazione per ogni tenant premium.
• Quando è necessario separare i clienti, ad esempio se l'attività e clienti del settore pubblico.
• Quando è necessario separare i processi di sviluppo, gestione temporanea e produzione ambienti cloud-native.

Dal punto di vista dei database, è possibile eseguire il deployment di il deployment delle applicazioni in una strategia di deployment one-to-one. Come mostrato in diagramma seguente, questa strategia è un approccio semplice in cui i dati poiché ogni deployment ha il proprio set di dati.

Il diagramma precedente mostra quanto segue:

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

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

Nel caso della multitenancy, i tenant potrebbero essere trasferiti. Un piccolo un tenant può trasformarsi in un tenant di medie dimensioni e deve essere un'applicazione. In questo caso, i deployment di database separati richiedono migrazione. Se viene eseguito il deployment di un database distribuito che viene utilizzato da tutti i deployment contemporaneamente, tutti i dati tenant risiedono in un unico sistema di database. Per questo motivo, lo spostamento di un tenant tra database non richiede la migrazione del database. Il seguente diagramma mostra un esempio di questo tipo di database:

Il diagramma precedente mostra quanto segue:

• Tre deployment di un'applicazione.
• Tutti i deployment condividono un unico database distribuito.
• Le applicazioni possono accedere a tutti i dati in ogni deployment.
• Il partizionamento dei dati non è stato implementato.

Se un'azienda spesso riposiziona i tenant nell'ambito delle operazioni del ciclo di vita, la replica del database può essere un'alternativa utile. In questo approccio, il tenant i dati vengono replicati tra i database prima di una migrazione del tenant. In questo caso, per i diversi deployment delle applicazioni e solo e la configurazione per la replica immediatamente prima e durante la migrazione del tenant. La il seguente diagramma mostra una replica temporanea tra due applicazioni durante una migrazione del tenant.

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

Portabilità delle applicazioni

La portabilità dell'applicazione garantisce che sia possibile eseguire il deployment da diverse località di deployment, in particolare da cloud diversi. Questa portabilità garantisce la possibilità di eseguire la migrazione di un'applicazione in qualsiasi momento, senza la necessità il reengineering specifico per la migrazione o lo sviluppo di applicazioni aggiuntive per la migrazione delle applicazioni.

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 sul sistema utilizza gli stessi componenti tecnici utilizzati in tutte deployment possibili. Per garantire la portabilità basata sul sistema, ogni tecnologia deve in tutte le potenziali località di deployment. Ad esempio, se un database come PostgreSQL, la sua disponibilità in tutti i potenziali deployment delle sedi devono essere verificate per il periodo di tempo previsto. Lo stesso vale per tutte le altre tecnologie, come i linguaggi di programmazione e tecnologie di infrastruttura. Come mostrato nel diagramma seguente, questo approccio stabilisce un insieme di funzionalità comuni in tutte le località di deployment basate sulla tecnologia.

Il diagramma precedente mostra un deployment di applicazioni portatili in cui l'applicazione richiede lo stesso identico sistema di database in ogni località in cui viene eseguito il deployment. Poiché in ogni località viene utilizzato lo stesso sistema di database, l'applicazione portabile. L'applicazione può aspettarsi che lo stesso sistema di database utilizzate durante il deployment. Pertanto, la stessa interfaccia di sistema di database e il relativo comportamento.

Nell'ambito dei database, nel sistema di compatibilità delle API, il client utilizza una una libreria di accesso al database specifica (ad esempio, una libreria client MySQL) per garantire in modo da potersi collegare a qualsiasi implementazione conforme disponibile nell'ambiente cloud. Il seguente diagramma illustra la compatibilità delle API.

Il diagramma precedente mostra la portabilità dell'applicazione in base al sistema di database piuttosto che il sistema di database. Sebbene i sistemi di database possano se ogni località è diversa, l'API è la stessa e mostra la stessa funzionalità. L'applicazione è portabile perché può utilizzare la stessa API ogni località, anche se il sistema di database sottostante è un database diverso tecnologia.

Nella portabilità basata sulla funzionalità, tecnologie diverse in cloud diversi che forniscono la stessa funzionalità. Ad esempio, possibile limitare l'uso dei database al modello relazionale. Poiché qualsiasi relazionale in grado di supportare l'applicazione, diversi database sistemi su versioni diverse possono essere utilizzati in cloud diversi senza influire la portabilità dell'applicazione. Uno svantaggio di un approccio basato sulla funzionalità la portabilità è che può usare solo le parti del modello di database che i sistemi di database relazionale. 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à.

Come mostra il diagramma precedente, l'API del sistema di database e il sistema di database potrebbe essere diversa a seconda della località. Per garantire la portabilità, l'applicazione deve utilizzare solo le parti di ciascun sistema di database e ogni API disponibili ciascuna località. Perché solo un sottoinsieme di ogni sistema di database è disponibile in ogni località, l'applicazione deve limitarne l'uso a quel di Google Cloud.

Per garantire la portabilità di tutte le opzioni di questa sezione, la documentazione completa dell'architettura deve essere eseguito continuamente in tutte le località di destinazione. Tutte le unità e è necessario eseguire scenari di test di sistema su questi deployment. Si tratta di requisiti essenziali per l'applicazione delle modifiche a infrastrutture e tecnologie individuati tempestivamente e affrontati.

Prevenzione delle dipendenze del fornitore

La prevenzione della dipendenza dal fornitore (lock-in) aiuta a ridurre il rischio di dipendenza da una tecnologia specifica e o il fornitore di contenuti. È superficialmente simile alla portabilità delle applicazioni. Dipendenza dal fornitore La prevenzione 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 di macchine nei cloud, non c'è alcuna dipendenza dal punto di vista del cloud, c'è una dipendenza da MySQL. Un'applicazione portabile tra cloud potrebbero dipendere comunque da tecnologie fornite da fornitori diversi nel cloud.

Per evitare la dipendenza dal fornitore, tutte le tecnologie devono essere sostituibili. Per questo ragione, un'astrazione completa e strutturata di tutte le funzionalità dell'applicazione necessari in modo che ogni servizio dell'applicazione possa essere reimplementato senza influire sul modo in cui viene implementata l'applicazione. Da un dal punto di vista del database, questa astrazione può essere fatta separando l'uso di modello di database da un particolare sistema di gestione dei database.

Sistema di gestione dei database di produzione esistente

Sebbene molte applicazioni multi-cloud siano sviluppate con sistemi di database come parte progettazione, molte aziende sviluppano applicazioni multi-cloud nell'ambito delle loro attività di modernizzazione delle applicazioni. Queste applicazioni sono sviluppate partendo dal presupposto che l'applicazione appena progettata e implementata accede i database esistenti.

Ci sono molte ragioni per non incorporare database esistenti in un impegno di modernizzazione. Alcune funzionalità specifiche in uso potrebbero non disponibili in altri sistemi di database. Un'azienda potrebbe avere database con processi di gestione complessi e consolidati, passando a in pratica o antieconomico. Oppure, un'azienda potrebbe scegliere modernizzare un'applicazione nella prima fase e modernizzare il database nella seconda fase.

Quando un'azienda utilizza un sistema di database esistente, il progettista del un'applicazione multi-cloud deve decidere se sarà l'unico database utilizzato, oppure se è necessario aggiungere un sistema di database diverso per un deployment diverso luoghi. Ad esempio, se un database viene utilizzato on-premise e l'applicazione devono essere eseguiti in Google Cloud, devono valutare se i servizi per le applicazioni di cui è stato eseguito il deployment su Google Cloud accedono al database on-premise. Oppure, in alternativa, se occorre eseguire il deployment di un secondo database sia in in Google Cloud e per i servizi per applicazioni in esecuzione in locale.

Se in Google Cloud viene eseguito il deployment di un secondo database, il caso d'uso potrebbe essere come per i casi d'uso discussi in Cloud bursting. o Servizi distribuiti. In entrambi i casi, lo stesso la discussione sul database si applica come illustrato in queste sezioni. Tuttavia, è limitato una funzionalità cross-location che il database on-premise esistente può come sincronizzazione e replica.

Pattern di deployment

I casi d'uso discussi in questo documento sollevano una domanda comune da prospettiva dei database: se i database si trovano in più di una località di deployment, qual è il loro rapporto?

I principali tipi di relazioni (pattern di deployment), che vengono discussi alla sezione successiva:

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

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

Nella discussione seguente, si presume che i client accedano a applicazioni direttamente i servizi Google. A seconda del caso d'uso, potrebbe essere necessario un bilanciatore del carico indirizzare dinamicamente l'accesso client alle applicazioni, come illustrato di seguito in un diagramma.

Nel diagramma precedente, un bilanciatore del carico Cloud indirizza il client a una delle località disponibili. Il bilanciatore del carico fa in modo che i criteri di bilanciamento del carico vengano applicati e che i clienti dell'applicazione e del relativo database.

Partizionata senza dipendenza tra database

Questo pattern di deployment è il più semplice di tutti quelli discussi in documento: ogni località o nuvola dispone di un database e i database contengono partizionati che non dipendono l'uno dall'altro. Un dato viene archiviato in un solo database. Ogni partizione dati si trova nel proprio database. Un un esempio di questo pattern è un'applicazione multi-tenant in cui un set di dati si trova in o l'altro database. Il seguente diagramma mostra due partizioni diverse applicazioni.

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

Un pattern di deployment alternativo per i database partizionati è quando il set di dati è partizionato completamente ma è comunque archiviato nello stesso database. C'è 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) una modifica a uno non causi cambiamenti in un'altra. Il seguente diagramma mostra due applicazioni che condividono lo stesso database.

Il diagramma precedente mostra quanto segue:

• Due deployment di applicazioni che condividono entrambi un database comune, la prima località.
• Ogni applicazione può accedere a tutti i dati nel deployment, poiché e il set di dati non sia partizionato.

Replica unidirezionale asincrona

Questo pattern di deployment ha un database principale che si replica in uno o più o database secondari. Il database secondario può essere utilizzato per l'accesso in lettura, l'applicazione deve tenere conto del potenziale ritardo di replica. Un esempio. si verifica quando il database migliore per un particolare caso d'uso viene utilizzato come per l'analisi si utilizzano anche il database principale e il database secondario. La il seguente diagramma mostra due applicazioni che accedono alla replica unidirezionale o Microsoft SQL Server.

Come mostra il diagramma precedente, uno dei due database è una replica del e l'altro. La freccia nel diagramma indica la direzione di replica: i dati dal sistema di database nella località 1 viene replicato nel sistema di database posizione 2.

Replica bidirezionale con risoluzione dei conflitti

Questo pattern di deployment ha due database primari che sono replicati l'uno con l'altro. Se gli stessi dati vengono scritti contemporaneamente in ogni (ad esempio, la stessa chiave primaria) può causare in conflitto. A causa di questo rischio, deve essere in atto una risoluzione del conflitto per Determina quale è l'ultimo stato durante la replica. Questo pattern può essere utilizzata in situazioni in cui è rara la possibilità di un conflitto di scrittura-scrittura. La il seguente diagramma mostra due applicazioni che accedono alla replica in modo bidirezionale o Microsoft SQL Server.

Come mostra il diagramma precedente, ciascun database viene replicato per configurare un database. Le due repliche sono indipendenti tra loro, come indicato in il diagramma con due frecce blu separate. Poiché le due repliche sono indipendenti, può verificarsi un conflitto se per caso lo stesso dato viene modificato per ciascuna applicazione e contemporaneamente replicati. In questo caso, il conflitto risoluzione deve essere applicata.

Sistema distribuito sincronizzato completamente attivo e attivo

Questo pattern di deployment ha un singolo database con un'espressione principale-principale). In una configurazione attiva-attiva, un aggiornamento I dati di qualsiasi database primario siano a coerenza transazionale e in modo sincrono replicati. Un caso d'uso di esempio per questo pattern è il computing distribuito. La il seguente diagramma mostra due applicazioni che accedono a un modello e il database principale.

Come mostra il diagramma precedente, questa disposizione garantisce che ogni applicazione accede sempre all'ultimo stato coerente, senza ritardo o rischio di conflitto. Una modifica in un database è immediatamente disponibile nell'altro. Qualsiasi la modifica si riflette in entrambi i database quando un commit della transazione cambia .

Classificazione dei sistemi di database

Non tutti i sistemi di gestione dei database possono essere usati altrettanto bene per i pattern di deployment discussi 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 dei sistemi di database.

Nella sezione seguente, i diversi sistemi di database sono classificati e mappata 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. Nel seguente ai fini della gestione dei database multi-cloud, vengono utilizzate due dimensioni utilizzata:

• Architettura di deployment. L'architettura di un database su risorse cloud (ad esempio, per i motori di computing o gestiti da cloud).
• Modello di distribuzione. Il modello di distribuzione di un sistema di database (ad esempio, istanza singola o completamente distribuita).

Queste due dimensioni sono le più pertinenti nel contesto dell'uso del multi-cloud casi d'uso e può supportare i quattro pattern di deployment derivati dai casi d'uso dei database multi-cloud. Una categorizzazione molto diffusa si basa sui dati supportati da un sistema di gestione dei database. Alcuni sistemi supportano un solo modello (ad esempio, un modello grafico). Supporto di altri sistemi diversi modelli di dati contemporaneamente (ad esempio, relazionali e modelli di machine learning). Tuttavia, nel contesto della gestione dei database multi-cloud, la categorizzazione non è pertinente perché le applicazioni multi-cloud possono utilizzare qualsiasi dato 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 deployment per sistemi di gestione dei database:

• Database cloud integrati. I database cloud integrati sono progettati, creati e ottimizzate per lavorare con la tecnologia cloud. Ad esempio, alcuni database utilizzano Kubernetes come piattaforma di implementazione e usano Kubernetes funzionalità. CockroachDB e YugaByte sono esempi di questo tipo di database. Il deployment può essere eseguito in qualsiasi cloud che supporta Kubernetes.
• Database gestiti da cloud provider. Database gestiti dal provider cloud sono basati su una tecnologia specifica del cloud provider e sono un servizio di database gestite da uno specifico cloud provider. Spanner, Bigtable e AlloyDB per PostgreSQL sono esempi di questo tipo di database. I database gestiti da provider di servizi cloud disponibile solo nel cloud del provider cloud e non può essere installata eseguire altrove. Tuttavia, AlloyDB per PostgreSQL è completamente PostgreSQL compatibili.
• Database pre-cloud. I database pre-cloud esistevano prima della sviluppo della tecnologia cloud (a volte per molto tempo) e di solito vengono eseguite su hardware bare metal e su 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 richieste o in metallo.
• Database Cloud gestiti dai partner. Alcuni cloud pubblici dispongono di database che installano e gestiscono nel cloud pubblico. Per questo motivo, i clienti non devono gestire autonomamente questi database. Atlante MongoDB e MariaDB sono esempi di questo tipo di database.

Esistono alcune varianti di queste categorie principali. Ad esempio, un fornitore di database l'implementazione di un database creato per il cloud può fornire anche un'installazione basata sulla tecnologia creata per il cloud e un'offerta gestita nel cloud fornito dal fornitore. Questo approccio equivale alla che fornisce un cloud pubblico che supporta solo il proprio database come completamente gestito di Google Cloud.

I database pre-cloud potrebbero trovarsi anche in container ed essere di cui è possibile eseguire il deployment in un cluster Kubernetes. Tuttavia, questi database non utilizzano Funzionalità specifiche di Kubernetes come scalabilità, multiservizio deployment multi-pod.

I fornitori di database possono collaborare con più di un cloud provider pubblico al contemporaneamente, offrendo il proprio database come database cloud gestito dai partner rispetto a un cloud pubblico.

Sistema di database per modello di distribuzione

Vengono implementati diversi sistemi di gestione dei database a seconda di distribuzione dei dati nell'architettura di un database. I modelli per i database sono i seguenti:

• Istanza singola. Una singola istanza di database viene eseguita su una o una VM container e funge da sistema centralizzato. Questo sistema gestisce per l'accesso a tutti i database. Poiché la singola istanza non può essere connessa in un'altra istanza, il sistema del database non supporta la replica.
• Attivo-passivo multiistanza. In questa architettura comune, sono collegate tra loro. Il collegamento più comune è una relazione attiva-passiva in cui è l'istanza di database attiva che supporta sia le istanze operazioni di scrittura e lettura. Uno o più sistemi passivi sono di sola lettura e ricevono tutte le modifiche al database da quella principale in modo sincrono o asincrono. Sistemi passivi può fornire accesso in lettura. Attivo-passivo è anche noto come principale-secondaria o replica di origine.
• Attiva/attiva su più istanze. In questa architettura relativamente insolita, ognuna delle quali è attiva. In questo caso, ogni istanza può eseguire le transazioni in lettura e scrittura e la coerenza dei dati. Per questo motivo, evitare incoerenze nei dati, tutte le istanze vengono sempre sincronizzate.
• Attiva/attiva su più istanze con risoluzione dei conflitti. Questo è anche un relativamente insolito. Ogni istanza è disponibile per la scrittura e la lettura tuttavia, i database vengono sincronizzati in modalità asincrona. Gli aggiornamenti simultanei dello stesso elemento dati sono consentiti, il che comporta incoerente. Una politica di risoluzione dei conflitti deve decidere quale dei è l'ultimo stato coerente.
• Lo sharding di più istanze. Lo sharding si basa sulla gestione partizioni di dati separate. Un'istanza di database separata gestisce ogni della partizione di testo. Questa distribuzione è scalabile perché è possibile aggiungere più shard in modo dinamico nel tempo. Tuttavia, le query cross-shard potrebbero non essere possibili perché questa funzionalità non è supportata da tutti i sistemi.

Tutti i modelli di distribuzione descritti in questa sezione possono supportare con sharding e può essere un sistema con sharding. Tuttavia, non tutti i sistemi sono progettati per fornire un'opzione dello sharding. Lo sharding è un concetto di scalabilità e in genere non pertinente per la selezione dei database dell'architettura in ambienti multi-cloud.

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

• Sistema a zone. Un sistema di database gestito a livello di zona è legato a una zona. Quando se la zona è disponibile, è disponibile anche il sistema del database. Tuttavia, se la zona non è più disponibile, non è possibile accedere del database.
• Sistema regionale. Un database gestito a livello di regione è collegato a una regione è accessibile quando almeno una zona è accessibile. Qualsiasi combinazione di zone possono diventare inaccessibili.
• Sistema interregionale. Un sistema interregionale è legato a due più regioni e funzioni correttamente quando è disponibile almeno una regione.

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

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

Mappatura dei sistemi di database ai pattern di deployment

La tabella seguente descrive in che modo i pattern di deployment e il deployment architetture trattate in questo documento sono correlate tra loro. La indica le condizioni necessarie affinché sia possibile una combinazione, in base al pattern e all'architettura di deployment.

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

Se un sistema di database non fornisce la replica integrata, potrebbe essere è possibile usare la tecnologia di replica dei database. Per ulteriori informazioni, vedi Il ruolo della tecnologia di migrazione dei database nei pattern di deployment.

La tabella seguente collega i pattern di deployment ai modelli di distribuzione. I campi indicano le condizioni per le quali è possibile eseguire la combinazione in base a un un pattern di deployment e un modello di distribuzione.

Modello di distribuzione	Pattern di deployment
	Partizionata senza dipendenza tra database	Replica unidirezionale asincrona	Replica bidirezionale con risoluzione dei conflitti	Sistema distribuito sincronizzato completamente attivo e attivo
Istanza singola	Possibile con lo stesso sistema di database o un sistema di database diverso nella zona interessata nuvole.	Non applicabile	Non applicabile	Non applicabile
Attivo-passivo multiistanza	Possibile con lo stesso sistema di database o un sistema di database diverso nella zona interessata nuvole.	La replica è possibile tra cloud.	La replica è possibile tra cloud.	Non applicabile
Attivo/attivo su più istanze	Possibile con lo stesso sistema di database o un sistema di database diverso nella zona interessata nuvole.	Non applicabile	Non applicabile	La sincronizzazione è possibile tra cloud.
Attivo/attivo su più istanze con risoluzione dei conflitti	Possibile con lo stesso sistema di database o un sistema di database diverso nella zona interessata nuvole.	Non applicabile	Non applicabile	Applicabile se la replica bidirezionale è possibile tra cloud.

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

Migrazione del database

La migrazione del database viene utilizzata quando un database viene spostato da un deployment posizione a un'altra. Ad esempio, un database in esecuzione in un database di Google Cloud viene migrata per l'esecuzione sul cloud. Al termine della migrazione, viene arrestato nel data center on-premise.

Gli approcci principali alla migrazione dei database sono i seguenti:

• Solleva e sposta. La VM e i dischi che eseguono le istanze di database vengono copiate nell'ambiente di destinazione così come sono. Dopo la copia, vengono avviati e la migrazione è completata.
• Esportazione e importazione, backup e ripristino. Entrambi questi approcci usano database la funzionalità di sistema per esternalizzare un database e ricrearlo località target. L'esportazione/l'importazione di solito si basa su un formato ASCII, mentre il backup e ripristino è basato su un formato binario.
• Migrazione senza tempi di inattività. In questo approccio, viene eseguita la migrazione mentre i sistemi delle applicazioni accedono al sistema di origine. Dopo un'iniziale caricamento, le modifiche vengono trasmesse dall'origine al database di destinazione tecnologie CDC (Change Data Capture). L'applicazione presenta tempi di inattività dal momento in cui sul sistema di database di origine, finché non viene riavviato del sistema di database di destinazione al termine della migrazione.

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

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

Per eseguire la migrazione dei database si possono utilizzare tecnologie di database integrate, ad esempio come 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, sono l'opzione migliore per la migrazione dei database. Database Migration Service, Striscia e Debezium sono esempi di tecnologie di migrazione dei database.

Replica dei database

La replica dei database è simile alla migrazione del database. Tuttavia, durante il database di replica, il sistema del database di origine rimane attivo mentre ogni modifica viene trasmesse 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 con le stesse transazioni.

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

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

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

La tecnologia di database integrata per abilitare la replica non è in disponibilità generale quando vengono utilizzati diversi sistemi di database nei pattern di deployment, ad esempio di replica asincrona (eterogenea). La tecnologia di migrazione dei database il deployment per abilitare questo tipo di replica. Alcuni di questi sistemi di migrazione implementano anche replica bidirezionale.

Se per il database è disponibile la tecnologia di migrazione o replica del database sistemi utilizzati nelle combinazioni contrassegnate come "Non applicabile" nella tabella 1 o nella tabella 2 pollici Mappatura dei sistemi di database a pattern di deployment potrebbe essere possibile usarlo per la replica del database. Le seguenti mostra un approccio alla replica dei database utilizzando una tecnologia di migrazione.

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

Selezione dei database multi-cloud

I casi d'uso dei database multi-cloud combinati con il sistema di database La categorizzazione ti aiuta a decidere quali database sono migliori per un determinato utilizzo per verificare se è così. Ad esempio, per implementare il caso d'uso in Application per la portabilità, esistono due opzioni. La la prima opzione è garantire che lo stesso motore del database sia disponibile in tutti nuvole. Questo approccio garantisce la portabilità del sistema. La seconda opzione è garantire la disponibilità dello stesso modello dei dati e della stessa interfaccia di query per tutti i cloud. Sebbene i sistemi di database possano essere diversi, la portabilità è fornita su un'interfaccia funzionale.

Gli alberi decisionali nelle sezioni seguenti mostrano i criteri decisionali per i casi d'uso dei database multi-cloud. Alberi decisionali suggerire il miglior database da considerare per ogni caso d'uso.

Best practice per il sistema di database esistente

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

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

• Un sistema di database è in produzione?
  • Se nessun sistema di database è in produzione, seleziona un database (vai alla sezione Decisione sulla gestione di database multi-cloud).
  • Se un sistema di database è in produzione, valuta se devono essere conservati.
• Se un sistema di database è in produzione, valuta se deve essere conservato.
  • Se il sistema di database deve essere conservato, la decisione viene presa e il processo decisionale è completato.
  • 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 di database multi-cloud).

Decisione sulla gestione dei database multi-cloud

Il seguente albero decisionale riguarda un caso d'uso con un database multilocalità (incluso il deployment di un database multi-cloud). Utilizza la classe di deployment come base per i criteri decisionali.

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

• I dati sono partizionati in database diversi senza la dipendenza tra database?
  • In caso affermativo, è possibile utilizzare lo stesso database o altri sistemi selezionate per ciascuna località.
  • In caso contrario, passa alla domanda successiva.
• È necessaria la replica unidirezionale asincrona?
  • In caso affermativo, valuta se un sistema di replica del database è accettabile.
    • In caso affermativo, seleziona lo stesso sistema di database o altri sistemi compatibili con il sistema di replica.
    • In caso contrario, seleziona un sistema di database che possa implementare un modello attivo-passivo. di distribuzione dei contenuti.
    • In caso contrario, passa alla domanda successiva.
• Seleziona un sistema di database con istanze sincronizzate.
  • La risoluzione dei conflitti è accettabile?
    • In caso affermativo, seleziona una replica bidirezionale un sistema di database o un sistema di database active-active.
    • In caso contrario, seleziona un sistema attivo-attivo.

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

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

La gerarchia della qualità della sincronizzazione è (da nessuna alla migliore): partizionata, unidirezionale, bidirezionale e completamente sincronizzato la replica dei dati.

Best practice per l'implementazione

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

Sistema di gestione dei database esistente

È consigliabile conservare un database e non apportare modifiche a meno che non sia richiesto da un caso d'uso specifico. Per un'azienda con un sistema di gestione dei database consolidato che sia efficace di sviluppo, operativi e di manutenzione, l'ideale sarebbe evitare apportare modifiche.

Un caso d'uso di cloud bursting che non richiede un sistema di database in potrebbe non richiedere una modifica del database. Un altro caso d'uso è quello asincrono in una località di deployment diversa all'interno dello stesso cloud in un altro cloud. Per questi casi d'uso, un buon approccio consiste nell'implementare un benchmark e verificare che la comunicazione tra località la comunicazione e la latenza soddisfano i requisiti dell'applicazione quando si accede per configurare un database.

Sistema di database come servizio Kubernetes

Se un'azienda sta considerando la possibilità di eseguire un sistema di database all'interno di Kubernetes un servizio basato su StatefulSets, è necessario considerare i seguenti fattori:

• Se il database fornisce di database richiesto dall'applicazione.
• Fattori non funzionali che determinano il modo in cui l'operazionalizzazione è implementato in un sistema di database come servizio Kubernetes, ad esempio la scalabilità (scalabilità verso l'alto e verso il basso), la gestione di backup e ripristino e come il sistema mette a disposizione il monitoraggio. Per aiutarli a comprendere i requisiti di un sistema di database basato su Kubernetes, le aziende dovrebbero usare le loro esperienze con i database come punto di confronto.
• Disponibilità elevata e ripristino di emergenza. Per fornire l'alta disponibilità, il sistema deve continuare a funzionare quando una zona all'interno di regione non riesce. Il database deve essere in grado di eseguire rapidamente il failover da una zona un'altra. Nel caso migliore, il database ha un'istanza in esecuzione in ogni completamente sincronizzata per un RTO e un RPO pari a zero.
• Ripristino di emergenza per risolvere l'errore di una regione (o di un cloud). In un 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 di tutte le transazioni del database principale.

Per determinare il modo migliore per eseguire un database in Kubernetes, la valutazione dei database è un buon approccio, soprattutto quando il sistema deve è paragonabile a un sistema di produzione esterno a Kubernetes.

Sistema di database indipendente da Kubernetes

Non è sempre necessario per un'applicazione implementata come servizi in Kubernetes in modo che il database venga eseguito in Kubernetes contemporaneamente. Là esistono molti motivi per cui un sistema di database deve essere eseguito al di fuori di Kubernetes, ad esempio processi consolidati, conoscenza dei prodotti o indisponibilità. Sia i cloud provider che quelli cloud gestiti da partner i database rientrano in questa categoria.

È altrettanto possibile e fattibile eseguire un database su Compute Engine. Quando un sistema di database, è buona norma eseguire un database completo per garantire che tutti i requisiti per un'applicazione siano soddisfatti.

Dal punto di vista della progettazione delle applicazioni, il pool di connessioni è un considerazione del progetto. Un servizio delle applicazioni che accede a un database potrebbe utilizzare un'istanza di un pool di connessioni interne. L'utilizzo di un pool di connessioni favorisce l'efficienza e con una latenza ridotta. Le richieste vengono prese dal pool senza la necessità per l'avvio e non è necessario attendere la creazione delle connessioni. Se lo scale up dell'applicazione viene fatto aggiungendo istanze del servizio delle applicazioni, a ogni istanza crea un pool di connessioni. Se vengono seguite le best practice, ogni pool viene creato preventivamente un insieme minimo di connessioni. Ogni volta che un'altra istanza del servizio dell'applicazione viene create per la scalabilità delle applicazioni, vengono aggiunte al database le connessioni. Da un dal punto di vista della progettazione, poiché i database non possono supportare collegate, l'aggiunta di connessioni deve essere gestita per evitare il sovraccarico.

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

Nella scelta dei sistemi di database, capita spesso alle aziende di scegliere per soddisfare i requisiti di un'applicazione. In un multi-cloud ambiente, si può selezionare il database migliore in ogni cloud e possono essere connessi tra loro in base al caso d'uso. Se questi sistemi sono diversi, qualsiasi replica, unidirezionale o bidirezionale, richiede molto impegno. Questo approccio potrebbe essere giustificato se il vantaggio di usare il miglior sistema supera l'impegno richiesto per implementarlo.

Tuttavia, è buona norma considerare e valutare contemporaneamente un approccio per un sistema di database disponibile in tutti i cloud richiesti. Sebbene questo tipo di potrebbe non essere l'opzione ideale, ma potrebbe essere molto più facile implementare, gestire e mantenere tale sistema.

La valutazione simultanea di un sistema di database ne dimostra i vantaggi e svantaggi di entrambi i sistemi di database, offrendo una solida base per la selezione.

Replica integrata e di sistema di database esterno

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

Per i sistemi che non supportano la replica come parte del sistema di implementazione della replica di implementazione, sistemi come Striim possono essere usati per l'architettura (come discusso in Migrazione del database).

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

Anche in questo caso la tecnologia di una terza classe gioca un ruolo importante. Questo corso fornisce componenti aggiuntivi ai sistemi di database esistenti per fornire la replica. Uno. ad esempio MariaDB Galera Cluster. Se il processo di valutazione lo consente, la valutazione di questi sistemi è una buona pratica.

Passaggi successivi

• Informazioni su modelli e pratiche ibridi e multi-cloud.
• Scopri di più sui pattern per connettere altri provider di servizi cloud a Google Cloud.
• Scopri di più sulle architetture di monitoraggio e logging per deployment ibridi e multi-cloud su Google Cloud.
• Per altre architetture di riferimento, diagrammi e best practice, esplora il Centro architetture cloud.

Collaboratori

Autore: Alex Cârciu | Architetto di soluzioni