Esempi di configurazioni di replica
Questa pagina descrive alcuni casi d'uso comuni per la replica di Bigtable e presenta le impostazioni che puoi utilizzare per supportarli.
- 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
Questa pagina spiega anche come decidere quali impostazioni utilizzare per altri casi d'uso.
Prima di leggere questa pagina, dovresti avere familiarità con la panoramica della replica di Bigtable.
Prima di aggiungere cluster a un'istanza, devi conoscere le restrizioni che si applicano quando modifichi i criteri di garbage collection nelle tabelle replicate.
Nella maggior parte dei casi, abilita la scalabilità automatica per i cluster della tua istanza. La scalabilità automatica consente a Bigtable di aggiungere e rimuovere automaticamente nodi in 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 in ogni cluster di un'istanza per assicurarti che ogni cluster possa gestire la replica oltre al carico che riceve dalle applicazioni. Se un cluster non ha abbastanza nodi, il ritardo di replica può aumentare, il cluster può riscontrare problemi di prestazioni dovuti all'accumulo di memoria e le scritture su altri cluster dell'istanza potrebbero essere rifiutate.
Gli esempi in questo documento descrivono la creazione di un'istanza, ma puoi anche aggiungere 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 operazioni di lettura di grandi dimensioni insieme a un'applicazione che esegue una combinazione di letture e scritture, il job batch di grandi dimensioni può rallentare le cose per gli utenti dell'applicazione. Con la replica, puoi utilizzare i profili delle app con il routing a cluster singolo per instradare i job di analisi batch e il traffico delle applicazioni a cluster diversi, in modo che i job batch non influiscano sugli utenti delle applicazioni.
Per isolare due carichi di lavoro:
Creare un'istanza con due cluster.
Crea due profili di app, uno denominato
live-traffic
e un altro denominatobatch-analytics
.Se i tuoi ID cluster sono
cluster-a
ecluster-b
, il profilo dell'applive-traffic
deve instradare le richieste acluster-a
e il profilo dell'appbatch-analytics
deve instradare le richieste acluster-b
. Questa configurazione fornisce la coerenza di lettura/scrittura per le applicazioni che utilizzano lo stesso profilo dell'app, ma non per quelle che utilizzano profili app diversi.Se necessario, puoi attivare le transazioni su riga singola nel profilo dell'app
live-traffic
. Non è necessario attivare le 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 il carico di lavoro con traffico in tempo reale è in esecuzione, utilizza il profilo dell'app
batch-analytics
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 il profilo dell'app
batch-analytics
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 la durabilità e la disponibilità archiviando copie separate dei dati in più zone o regioni ed eseguendo automaticamente il failover tra i cluster, se necessario.
Per configurare l'istanza per un caso d'uso ad alta disponibilità, crea un nuovo profilo dell'app che utilizzi il routing multi-cluster oppure aggiorna il profilo predefinito dell'app per utilizzare il routing multi-cluster. Questa configurazione fornisce la coerenza finale. Non puoi abilitare 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 (configurazione consigliata). La configurazione consigliata per l'alta disponibilità è un'istanza con N+2 cluster che si trovano ciascuno in una regione diversa. Ad esempio, se il numero minimo di cluster necessari per gestire i dati è 2, hai bisogno 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 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 alta disponibilità all'interno della disponibilità della regione, la possibilità di eseguire il failover senza generare costi di replica tra regioni e nessun aumento della latenza in caso di failover. I dati contenuti in un'istanza Bigtable replicata sono disponibili fintanto che sono disponibili tutte le zone in cui vengono replicati.
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 per più regioni offre disponibilità elevata 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 e 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 solo costo, perché nella regione B è presente un solo cluster. Se scrivi nell'area geografica B, ti viene addebitato 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 inattivi, dovrai sempre instradare le richieste a un singolo cluster. Tuttavia, puoi comunque utilizzare la replica gestendo le richieste con un cluster e conservando un altro cluster come backup quasi in tempo reale. Se il cluster di gestione non è più 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 dell'app che utilizzi il routing a cluster singolo o aggiorna il profilo di app predefinito per utilizzare il routing a cluster singolo. Il cluster che hai specificato nel profilo dell'app gestisce le richieste in entrata. L'altro cluster funge da backup in caso di failover. Questa soluzione a volte è nota come configurazione attiva-passiva e fornisce 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 le richieste in entrata.
L'altro cluster utilizzerà comunque le risorse della CPU per eseguire la replica e altre attività di manutenzione.
Aggiorna il profilo dell'app in modo che punti al secondo cluster nella tua istanza.
Ricevi un avviso relativo alla perdita della coerenza di lettura/scrittura, il che significa anche una perdita di elevata coerenza.
Se hai abilitato le transazioni su riga singola, riceverai anche un avviso sulla potenziale 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 gestisce 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 cluster Bigtable il più vicini possibile ai clienti. Vuoi che i tuoi dati siano ad alta disponibilità all'interno di ogni regione e potresti voler utilizzare un'opzione di failover se uno o più cluster non sono disponibili.
Per questo caso d'uso, puoi creare un'istanza con due cluster nell'area geografica A e due cluster nell'area geografica B. Questa configurazione offre disponibilità elevata anche se non puoi connetterti a una regione Google Cloud. Fornisce inoltre resilienza a livello di regione perché, anche se una zona non è più disponibile, l'altro cluster nella regione di quella zona rimane disponibile.
Puoi scegliere di utilizzare il routing multi-cluster o a cluster singolo per questo 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.
Puoi scegliere di utilizzare il routing multi-cluster o a cluster singolo per questo caso d'uso, a seconda delle esigenze aziendali. Se usi il routing multi-cluster, Bigtable gestisce i failover automaticamente. Se utilizzi il routing a cluster singolo, puoi decidere in modo autonomo quando eseguire il failover su 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 il cluster Bigtable esegua il failover automatico se una zona o una regione non è disponibile. Questa opzione è una buona scelta se vuoi gestire i costi e la latenza che potrebbero verificarsi se Bigtable inizia a instradare il traffico da e verso una regione lontana o se preferisci prendere decisioni di failover in base al tuo giudizio o alle 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 dell'app
a qualsiasi cluster nell'istanza Bigtable. Ad esempio, se hai tre applicazioni in esecuzione a Mumbai e sei a Tokyo, puoi configurare un profilo dell'app per l'applicazione di Mumbai da instradare verso asia-south1-a
e due applicazioni che indirizzano a asia-south1-c
. Per l'applicazione Tokyo, configura tre
profili di 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 scegliere di lasciare temporaneamente non disponibili i dati in quella zona finché la zona non sarà nuovamente disponibile.
Opzione di routing multi-cluster
Se stai implementando questo caso d'uso e vuoi che Bigtable esegua 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 dell'app che utilizzi il routing multi-cluster per ogni applicazione oppure aggiorna il profilo predefinito dell'app per utilizzare il routing multi-cluster.
Questa configurazione fornisce la coerenza finale. Se una regione non è più disponibile, le richieste Bigtable vengono inviate automaticamente all'altra. In questi casi, ti viene addebitato il costo di rete per l'altra regione e la tua applicazione potrebbe riscontrare una latenza maggiore a causa della maggiore distanza.
Archivia i dati vicino agli utenti
Se hai utenti in tutto il mondo, puoi ridurre la latenza eseguendo l'applicazione vicino agli utenti e inserendo i dati il più vicino possibile all'applicazione. Con Bigtable puoi creare un'istanza con cluster in diverse regioni Google Cloud e i tuoi dati vengono replicati automaticamente in ogni regione.
Per questo caso d'uso, utilizza i profili delle app con routing a cluster singolo. Il routing multi-cluster non è desiderabile per questo caso d'uso a causa della distanza tra i cluster. Se un cluster non è più disponibile e il suo profilo app multi-cluster reinstrada automaticamente il traffico su una grande distanza, l'applicazione potrebbe riscontrare una latenza inaccettabile e costi di rete aggiuntivi imprevisti.
Per configurare l'istanza per questo caso d'uso:
Creare 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 Uniticlickstream-eu
: routing a cluster singolo al cluster in Europaclickstream-asia
: routing a cluster singolo al cluster in Asia
In questa configurazione, l'applicazione utilizza il profilo dell'app per il cluster più vicino. Le scritture in qualsiasi cluster vengono replicate automaticamente negli altri due cluster.
Altri casi d'uso
Se il tuo caso d'uso non è descritto in questa pagina, utilizza le seguenti domande per decidere come configurare i profili delle app:
Devi eseguire transazioni su riga singola, come operazioni di lettura, modifica e scrittura (inclusi incrementi e aggiunte) e operazioni di verifica e modifica (note anche come mutazioni condizionali o scritture condizionali)?
In questo caso, i profili delle app devono utilizzare il routing a cluster singolo per evitare la perdita di dati e devi gestire manualmente i failover.
Vuoi che Bigtable gestisca automaticamente i failover?
In questo caso, i profili delle app devono utilizzare il routing multi-cluster. Se un cluster non può elaborare una richiesta in entrata, Bigtable esegue automaticamente il failover sugli altri cluster. Scopri di più sui failover automatici.
Per evitare perdite di dati, non puoi abilitare le transazioni su riga singola quando utilizzi il routing multi-cluster. Scopri di più.
Vuoi mantenere un cluster di backup o di riserva nel caso in cui il cluster principale non sia disponibile?
In questo caso, utilizza il routing a cluster singolo nei profili delle app e, se necessario, esegui il failover manuale al cluster di backup.
Questa configurazione consente anche di utilizzare transazioni su riga singola, se necessario.
Vuoi inviare tipi di traffico diversi a cluster diversi?
In tal caso, utilizza il routing a cluster singolo nei profili delle app e indirizza ogni tipo di traffico al proprio cluster. Esegui manualmente il failover tra cluster se necessario.
Se necessario, puoi attivare le transazioni su riga singola nei profili delle app.
Passaggi successivi
- Scopri di più sui profili delle app.
- Creare un profilo dell'app o aggiornarne uno esistente.
- Scopri come funzionano i failover.