Esempi di configurazioni di replica
Questa pagina descrive alcuni casi d'uso comuni per Bigtable della replica e presenta le impostazioni che puoi usare per supportare queste d'uso diversi.
- Isolare i carichi di lavoro di analisi batch di altre applicazioni
- Crea alta disponibilità
- Fornire backup quasi in tempo reale
- Mantieni alta disponibilità e resilienza regionale
- Archiviare i dati vicino agli utenti
In questa pagina viene inoltre spiegato come stabilire quali impostazioni utilizzare per altri usi di assistenza.
Prima di leggere questa pagina, dovresti conoscere le panoramica della replica Bigtable.
Prima di aggiungere cluster a un'istanza, devi conoscere le Limitazioni applicate quando modifichi i criteri di garbage collection nelle tabelle replicate.
Nella maggior parte dei casi, abilita la scalabilità automatica dei cluster dell'istanza. La scalabilità automatica consente a Bigtable di aggiungere e rimuovere automaticamente nodi a un cluster in base al carico di lavoro.
Se invece scegli l'allocazione manuale dei nodi, esegui il provisioning di un numero sufficiente di nodi ogni cluster in un'istanza per garantire che ogni cluster possa gestire oltre al carico che riceve dalle applicazioni. Se un cluster non ha nodi sufficienti, il ritardo di replica può aumentare, il cluster può riscontra problemi di prestazioni dovuti all'accumulo di memoria e scritture ad altri cluster dell'istanza potrebbero essere rifiutati.
Gli esempi in questo documento descrivono la creazione di un'istanza, ma puoi anche aggiungere di cluster a un'istanza esistente.
Isola i carichi di lavoro di analisi batch da altre applicazioni
Quando utilizzi un singolo cluster per eseguire un job di analisi batch che esegue numerose letture di grandi dimensioni e se un'applicazione esegue una combinazione di letture e scritture, il job batch di grandi dimensioni può rallentare per gli utenti dell'applicazione. Con la replica, puoi utilizzare i profili delle app il routing a cluster singolo per instradare job di analisi batch e traffico delle applicazioni a cluster diversi in modo che i job batch non influiscano utenti.
Per isolare due carichi di lavoro:
Creare un'istanza con due cluster.
Crea due profili di app, uno denominato
live-traffic
e un'altra chiamatabatch-analytics
.Se i tuoi ID cluster sono
cluster-a
ecluster-b
, l'applive-traffic
profilo deve indirizzare le richieste acluster-a
ebatch-analytics
il profilo dell'app deve indirizzare le richieste acluster-b
. Questa configurazione offre la coerenza in lettura/scrittura per le applicazioni usando lo stesso profilo di app, ma non per applicazioni che usano app diverse. profili.Puoi attivare le transazioni su riga singola nel Profilo app
live-traffic
, se necessario. Non è necessario abilitare transazioni su riga singola nel profilo dell'appbatch-analytics
, supponendo che utilizzerai questo profilo dell'app solo per le letture.Utilizza il profilo dell'app
live-traffic
per eseguire un carico di lavoro con traffico in tempo reale.Mentre è in esecuzione il carico di lavoro del traffico in tempo reale, utilizza
batch-analytics
del profilo dell'app per eseguire un carico di lavoro batch di sola lettura.
Per isolare due carichi di lavoro più piccoli da un carico di lavoro più grande:
Creare un'istanza con tre cluster.
Questi passaggi presuppongono che i cluster utilizzino gli ID
cluster-a
,cluster-b
ecluster-c
.Crea i seguenti profili dell'app:
live-traffic-app-a
: routing a cluster singolo dall'applicazione acluster-a
live-traffic-app-b
: routing a cluster singolo dall'applicazione acluster-b
batch-analytics
: routing a cluster singolo dal job di analisi batch acluster-c
Utilizza i profili delle app con traffico in tempo reale per eseguire carichi di lavoro con traffico in tempo reale.
Mentre sono in esecuzione i carichi di lavoro del traffico in tempo reale, utilizza
batch-analytics
del profilo dell'app per eseguire un carico di lavoro batch di sola lettura.
Crea alta disponibilità (HA)
Se un'istanza ha un solo cluster, la durabilità e la disponibilità dei dati sono limitate alla zona in cui si trova il cluster. La replica può migliorare sia la durabilità che la disponibilità mediante l'archiviazione separate dei dati in più zone o regioni e con errori automatici cluster, se necessario.
Per configurare l'istanza per un caso d'uso ad alta disponibilità, crea un nuovo profilo dell'app che utilizza cluster multipli routing o aggiorna il profilo dell'app predefinito per utilizzare il routing multi-cluster. Questa configurazione fornisce la coerenza finale. Non puoi attivare le transazioni su riga singola poiché le transazioni su riga singola possono causare conflitti di dati quando utilizzi il routing multi-cluster.
Le configurazioni per migliorare la disponibilità includono le seguenti.
Cluster in tre o più regioni diverse (consigliato automatica). La configurazione consigliata per l'alta disponibilità è un'istanza ha N+2 cluster che si trovano ognuno in una regione diversa. Ad esempio, se il numero minimo di cluster necessari per pubblicare i tuoi dati è 2, necessita di un'istanza con quattro cluster per mantenere l'alta disponibilità. Questa configurazione offre uptime anche nel raro caso in cui due regioni non siano più disponibili. Ti consigliamo di distribuire i cluster in più continenti.
Configurazione di esempio:
cluster-a
nella zonaus-central1-a
in Iowacluster-b
nella zonaeurope-west1-d
in Belgiocluster-c
nella zonaasia-east1-b
a Taiwan
Due cluster nella stessa regione, ma in zone diverse. Questa opzione offre un'alta disponibilità all'interno della disponibilità della regione, la possibilità eseguire il failover senza generare costi di replica tra regioni e e la latenza minima per il failover. I tuoi dati in una Bigtable replicata l'istanza è disponibile purché una qualsiasi delle zone in cui viene replicata disponibili.
Configurazione di esempio:
cluster-a
nella zonaaustralia-southeast1-a
a Sydneycluster-b
nella zonaaustralia-southeast1-b
a Sydney
Due cluster in regioni diverse. Questa configurazione multiregionale offre un'alta disponibilità come la precedente configurazione multizona, ma i tuoi dati sono disponibili anche se non puoi connetterti a una delle regioni.
Ti vengono addebitati i costi per replicare le scritture tra regioni.
Configurazione di esempio:
cluster-a
nella zonaasia-northeast1-c
a Tokyocluster-b
nella zonaasia-east2-b
di Hong Kong
Due cluster nella regione A e un terzo cluster nella regione B. Questa opzione rende disponibili i dati anche se non puoi connetterti a una delle regioni fornisce capacità aggiuntiva nella regione A.
Ti vengono addebitati i costi per replicare le scritture tra regioni. Se scrivi nell'area geografica A, ti viene addebitato un importo perché hai un solo cluster nella regione B. Se scrivi nell'area B, l'addebito avviene due volte perché hai due cluster nella regione A.
Configurazione di esempio:
cluster-a
nella zonaeurope-west1-b
in Belgiocluster-b
nella zonaeurope-west1-d
in Belgiocluster-c
nella zonaeurope-north1-c
in Finlandia
Il backup è quasi in tempo reale
In alcuni casi, ad esempio se non puoi permetterti di leggere dati obsoleti, dovrai sempre indirizzare a un singolo cluster. Tuttavia, puoi comunque utilizzare la replica gestendo le richieste con uno cluster e di conservare un altro cluster come backup quasi in tempo reale. Se il cluster di gestione diventa non disponibile, puoi ridurre al minimo il tempo di inattività eseguendo manualmente il failover sul cluster di backup.
Per configurare l'istanza per questo caso d'uso, crea un profilo di app che utilizzi il routing a cluster singolo o aggiorna il valore predefinito profilo app per utilizzare il routing a cluster singolo. La che hai specificato nel profilo dell'app gestisce le richieste in entrata. L'altro cluster funge da backup in caso di failover. Questo la disposizione è a volte nota come configurazione attiva-passiva e offre elevata coerenza e coerenza in lettura/scrittura. Se necessario, puoi attivare le transazioni su riga singola nel profilo dell'app.
Per implementare questa configurazione:
Utilizza un profilo dell'app con routing a cluster singolo per eseguire un carico di lavoro.
Utilizza la console Google Cloud per monitorare i cluster dell'istanza e verificare che solo un cluster gestisca i cluster in entrata richieste.
L'altro cluster utilizzerà comunque le risorse della CPU per eseguire la replica e di altre attività di manutenzione.
Aggiorna il profilo dell'app in modo che rimandi a secondo cluster nella tua istanza.
Ricevi un avviso relativo alla perdita di lettura-scrittura coerenza, il che comporta anche una perdita di coerenza.
Se hai attivato le transazioni su riga singola, ricevi anche un avviso sul potenziale di perdita di dati. Perdi i dati se invii scritture in conflitto durante il failover.
Continua a monitorare l'istanza. Dovresti vedere che il secondo cluster per gestire le richieste in entrata.
Mantieni alta disponibilità e resilienza regionale
Supponiamo che tu abbia concentrazioni di clienti in due regioni distinte all'interno di un continente. Vuoi servire ogni concentrazione di clienti con i cluster Bigtable il più vicini possibile ai clienti. Vuoi garantire la disponibilità elevata all'interno di ogni regione e potresti volere di failover se uno o più cluster non sono disponibili.
Per questo caso d'uso, puoi creare un'istanza con due cluster nella regione A e cluster nella regione B. Questa configurazione offre disponibilità elevata anche non può connettersi a una regione Google Cloud. Offre inoltre informazioni resilienza perché anche se una zona non è più disponibile, l'altro cluster in la regione della zona è ancora disponibile.
Per questa operazione puoi scegliere di utilizzare il routing multi-cluster o a cluster singolo al caso d'uso, a seconda delle esigenze aziendali.
Per configurare l'istanza per questo caso d'uso:
Crea un'istanza Bigtable con quattro cluster: due nella regione A e due nella regione B. I cluster nella stessa regione devono trovarsi in zone diverse.
Configurazione di esempio:
cluster-a
nella zonaasia-south1-a
a Mumbaicluster-b
nella zonaasia-south1-c
a Mumbaicluster-c
nella zonaasia-northeast1-a
a Tokyocluster-d
nella zonaasia-northeast1-b
a Tokyo
Posiziona un server delle applicazioni vicino a ogni regione.
Per questa operazione puoi scegliere di utilizzare il routing multi-cluster o a cluster singolo al caso d'uso, a seconda delle esigenze aziendali. Se utilizzi il routing multi-cluster, Bigtable gestisce automaticamente i failover. Se utilizzi a cluster singolo, è l'utente a decidere quando eseguire il failover in un cluster diverso.
Opzione di routing su cluster singolo
Per questo caso d'uso puoi utilizzare il routing a cluster singolo se non vuoi che Esegui il failover automatico del cluster Bigtable se una zona o una regione diventa non disponibile. Questa opzione è ideale per gestire i costi e la latenza che potrebbe verificarsi se Bigtable avvia il routing da e verso una regione lontana o se preferisci eseguire il failover decisioni basate sul tuo giudizio o sulle tue regole aziendali.
Per implementare questa configurazione, crea almeno un profilo di app che utilizzi il routing a cluster singolo per ogni applicazione
che invia richieste all'istanza. Puoi indirizzare i profili delle app
a qualsiasi cluster nell'istanza Bigtable. Ad esempio, se
tre applicazioni in esecuzione a Mumbai e sei a Tokyo, puoi configurare
un profilo dell'app per l'applicazione Mumbai per il routing a asia-south1-a
e due
quel percorso verso asia-south1-c
. Per l'applicazione Tokyo, configura tre
profili delle app che indirizzano a asia-northeast1-a
e tre che indirizzano a
asia-northeast1-b
.
Con questa configurazione, se uno o più cluster non sono disponibili, puoi eseguire un failover manuale o lasciare che i dati non sarà temporaneamente disponibile in quella zona finché non sarà nuovamente disponibile.
Opzione di routing multi-cluster
Se stai implementando questo caso d'uso e vuoi che Bigtable il failover automatico in una regione se l'applicazione non può raggiungere l'altra utilizza il routing multi-cluster.
Per implementare questa configurazione, crea un nuovo profilo app che utilizzi il routing a cluster multipli per ogni applicazione oppure aggiorna il profilo dell'app predefinito per utilizzare la configurazione multi-cluster i percorsi dei carichi di lavoro.
Questa configurazione fornisce la coerenza finale. Se una regione non è più disponibile, le richieste Bigtable inviati automaticamente all'altra regione. In questi casi, addebitato il traffico di rete per l'altra regione e la latenza dell'applicazione potrebbe essere maggiore a causa della maggiore a distanza.
Archivia i dati vicino agli utenti
Se hai utenti in tutto il mondo, puoi ridurre la latenza eseguendo il tuo vicina all'applicazione e avvicinando i dati all'applicazione il più possibile. Con Bigtable puoi creare un'istanza in diverse regioni Google Cloud e i tuoi dati vengono automaticamente replicati in ogni regione.
Per questo caso d'uso, utilizza i profili delle app con routing a cluster singolo. Multi-cluster il routing non è desiderato per questo caso d'uso a causa della distanza tra cluster. Se un cluster non è più disponibile e il relativo profilo app multi-cluster reindirizza automaticamente il traffico su una grande distanza, subire una latenza inaccettabile e costi di rete aggiuntivi imprevisti.
Per configurare l'istanza per questo caso d'uso:
Crea un'istanza con cluster in tre regioni geografiche distinte, ad esempio Stati Uniti, Europa e Asia.
Posiziona un server delle applicazioni vicino a ogni regione.
Crea profili delle app simili ai seguenti:
clickstream-us
: routing a cluster singolo al cluster negli Stati Uniti Staticlickstream-eu
: routing a cluster singolo al cluster in Europaclickstream-asia
: routing a cluster singolo al cluster in Asia
In questa configurazione, la tua applicazione utilizza il profilo dell'app per cluster più vicino. Le scritture in qualsiasi cluster vengono replicate automaticamente e gli altri due cluster.
Altri casi d'uso
Se il tuo caso d'uso non è descritto in questa pagina, usa quanto segue che ti aiuteranno a decidere come configurare i profili delle tue app:
Devi eseguire transazioni su riga singola, come le operazioni di lettura, modifica e scrittura (inclusi incrementi e aggiunte) e operazioni di verifica e mutazione (note anche come mutazioni condizionali o )?
In questo caso, i profili delle app devono utilizzare cluster singoli il routing per evitare perdite di dati e devi gestire manualmente.
Vuoi che Bigtable gestisca automaticamente i failover?
In questo caso, i profili delle app devono utilizzare multi-cluster di routing. Se un cluster non è in grado di elaborare una richiesta Bigtable, esegue automaticamente il failover sull'altra cluster. Scopri di più sui failover automatici.
Per evitare perdite di dati, non puoi abilitare riga singola delle transazioni quando utilizzi il routing multi-cluster. Scopri di più.
Vuoi mantenere un cluster di backup o di riserva nel caso in cui l'istanza principale cluster non è disponibile?
In questo caso, utilizza il routing a cluster singolo nell'app profili ed eseguire il failover manuale nel cluster di backup se necessario.
Questa configurazione consente anche di utilizzare riga singola transazioni se necessario.
Vuoi inviare tipi di traffico diversi a cluster diversi?
In questo caso, utilizza il routing a cluster singolo nell'app profili e indirizza ogni tipo di traffico al proprio cluster. Esegui manualmente il failover tra cluster se necessario.
Puoi attivare le transazioni su riga singola nel tuo profili delle app, se necessario.
Passaggi successivi
- Scopri di più sui profili delle app.
- Creare un profilo dell'app o aggiornarne uno esistente.
- Scopri come funzionano i failover.