Esempi di impostazioni della replica

Questa pagina descrive alcuni casi d'uso comuni per abilitare la replica Bigtable e presenta le impostazioni che puoi utilizzare per supportare questi casi d'uso.

Isolare i carichi di lavoro di analisi batch da altre applicazioni
Crea disponibilità elevata
Fornire backup quasi in tempo reale
Mantenere alta disponibilità e resilienza regionale
Archivia i dati nelle vicinanze degli utenti

In questa pagina viene inoltre spiegato come decidere quali impostazioni utilizzare se il tuo caso d'uso non è elencato qui.

Prima di leggere questa pagina, dovresti acquisire familiarità con la panoramica sulla replica di Bigtable.

Prima di aggiungere cluster a un'istanza, è bene conoscere le limitazioni che si applicano quando modifichi i criteri di garbage collection nelle tabelle replicate.

A prescindere dal caso d'uso, esegui sempre il provisioning di un numero sufficiente di nodi in ogni cluster di un'istanza per assicurarti che ogni cluster sia in grado di 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 in altri cluster nell'istanza potrebbero essere rifiutate.

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 insieme a un'applicazione che esegue una combinazione di letture e scritture, il job batch di grandi dimensioni può rallentare le operazioni per gli utenti dell'applicazione. Con la replica puoi utilizzare profili di app con 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:

Crea una nuova istanza con 2 cluster o aggiungi un secondo cluster a un'istanza esistente.

Segui i suggerimenti per l'utilizzo della CPU standard per questa configurazione.
Crea due profili app, uno chiamato live-traffic e un altro chiamato batch-analytics.

Se gli ID cluster sono cluster-a e cluster-b, il profilo dell'app live-traffic deve indirizzare le richieste a cluster-a e il profilo dell'app batch-analytics deve instradare le richieste a cluster-b. Questa configurazione offre coerenza della lettura/scrittura per le applicazioni che utilizzano lo stesso profilo di app, ma non per le applicazioni che utilizzano profili di app diversi.

Se necessario, puoi abilitare le transazioni su riga singola nel profilo dell'app live-traffic. Non è necessario abilitare le transazioni su riga singola nel profilo dell'app batch-analytics, supponendo che utilizzerai questo profilo dell'app solo per le letture.
Usa il profilo dell'app live-traffic per eseguire un carico di lavoro del traffico in tempo reale.
Mentre il carico di lavoro per il traffico in tempo reale è in esecuzione, utilizza il profilo dell'app batch-analytics per eseguire un carico di lavoro batch di sola lettura.
Monitora l'utilizzo della CPU per i cluster dell'istanza e, se necessario, aggiungi nodi ai cluster.
Monitora la latenza lato client utilizzando uno strumento a tua scelta. Se utilizzi il client HBase per Java, puoi monitorare la latenza con le relative metriche lato client.

Per isolare due carichi di lavoro più piccoli da un carico di lavoro più grande:

Crea una nuova istanza con 3 cluster o aggiungili a un'istanza esistente fino a quando non ne saranno disponibili altri.

Segui i suggerimenti per l'utilizzo della CPU standard per questa configurazione.

Questi passaggi presuppongono che i cluster utilizzino gli ID cluster-a, cluster-b e cluster-c.

Utilizza lo stesso numero di nodi in cluster-a e cluster-b se gestiscono la stessa applicazione. Utilizza un numero maggiore di nodi in cluster-c per supportare il carico di lavoro più grande.
Crea i seguenti profili di app:
- live-traffic-app-a: routing a cluster singolo dalla tua applicazione a cluster-a
- live-traffic-app-b: routing a cluster singolo dalla tua applicazione a cluster-b
- batch-analytics: routing a cluster singolo dal job di analisi batch a cluster-c
Utilizza i profili delle app per il 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.
Monitora l'utilizzo della CPU per i cluster dell'istanza e, se necessario, aggiungi nodi ai cluster.
Monitora la latenza lato client utilizzando uno strumento a tua scelta. Se utilizzi il client HBase per Java, puoi monitorare la latenza con le relative metriche lato client.

Crea disponibilità elevata (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à archiviando copie separate dei tuoi dati in più zone o regioni ed eseguendo automaticamente il failover tra cluster, se necessario.

Per configurare l'istanza per un caso d'uso ad alta disponibilità, crea un nuovo profilo di app che utilizzi il routing multi-cluster oppure aggiorna il profilo dell'app predefinito per utilizzare il routing multi-cluster. Questa configurazione fornisce coerenza finale. Non potrai abilitare le transazioni su riga singola perché queste possono causare conflitti di dati quando utilizzi il routing multi-cluster.

Per saperne di più su come Bigtable contribuisce a raggiungere l'alta disponibilità, consulta Creazione di una presenza di dati globale con Bigtable .

Di seguito sono riportate le configurazioni per migliorare la disponibilità.

Cluster in 3 o più regioni diverse (configurazione consigliata). La configurazione consigliata per l'alta disponibilità è un'istanza con N+2 cluster, ciascuno in una regione diversa. Ad esempio, se il numero minimo di cluster di cui hai bisogno per gestire i tuoi dati è 2, avrai bisogno di un'istanza a 4 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 in zona us-central1-a in Iowa
- cluster-b nella zona europe-west1-d in Belgio
- cluster-c in zona asia-east1-b a Taiwan
Per questa configurazione, esegui il provisioning di un numero sufficiente di nodi per mantenere un target del 23% di utilizzo della CPU per un'istanza a tre cluster, tre regioni e il 35% di utilizzo della CPU per un'istanza di quattro cluster e quattro regioni. In questo modo, anche se non sono disponibili due regioni, il cluster o i cluster rimanenti possano gestire tutto il traffico.
Due cluster nella stessa regione, ma in zone diverse. Questa opzione offre disponibilità elevata all'interno della disponibilità della regione, la possibilità di eseguire il failover senza generare costi di replica tra regioni e nessun aumento della latenza sul failover. I tuoi dati in un'istanza Bigtable replicata sono disponibili purché sia disponibile una delle zone in cui sono replicati.

Configurazione di esempio:
- cluster-a in zona australia-southeast1-a a Sydney
- cluster-b in zona australia-southeast1-b a Sydney
Segui i suggerimenti per l'utilizzo della CPU standard per questa configurazione.
Due cluster in regioni diverse. Questa configurazione per più regioni offre un'alta disponibilità come la precedente configurazione multizona, ma i tuoi dati sono disponibili anche se non riesci a connetterti a una delle regioni.

Ti vengono addebitati i costi per le replicazioni delle scritture tra regioni.

Configurazione di esempio:
- cluster-a in zona asia-northeast1-c a Tokyo
- cluster-b in zona asia-east2-b a Hong Kong
Segui i suggerimenti per l'utilizzo della CPU standard per questa configurazione.
Due cluster nella regione A e un terzo cluster nella regione B. Questa opzione rende i tuoi dati disponibili anche se non riesci a connetterti a una delle regioni e fornisce capacità aggiuntiva nella regione A.

Ti vengono addebitati i costi per le replicazioni delle scritture tra regioni. Se scrivi nella regione A, l'addebito viene eseguito una sola volta perché hai un solo cluster nella regione B. Se scrivi nella regione B, ti viene addebitato due volte l'importo perché hai 2 cluster nella regione A.

Configurazione di esempio:
- cluster-a nella zona europe-west1-b in Belgio
- cluster-b nella zona europe-west1-d in Belgio
- cluster-c in zona europe-north1-c in Finlandia
Inizia con un target del 35% di utilizzo della CPU nella regione con 2 cluster e del 70% nell'altra. Monitora i cluster dell'istanza e regola il numero di nodi secondo necessità in modo che ogni cluster disponga di risorse sufficienti per gestire un failover.

Puoi simulare il failover per questo caso d'uso per testare l'applicazione:

Utilizza un profilo di app con routing multi-cluster per eseguire un carico di lavoro di test.
Utilizza la console Google Cloud per monitorare i cluster dell'istanza e verificare che i cluster stiano gestendo le richieste in entrata.
Elimina uno dei cluster per simulare un'interruzione.

Questa modifica elimina anche la copia dei dati archiviati con il cluster.
Continua a monitorare latenza e tassi di errore. Se i cluster rimanenti hanno risorse CPU sufficienti, dovrebbero essere in grado di stare al passo con le richieste in arrivo.
Aggiungi un cluster all'istanza e continua a monitorarla. La replica dei dati nel nuovo cluster dovrebbe iniziare.

Fornisci backup quasi in tempo reale

In alcuni casi, ad esempio se non puoi permetterti di leggere i dati inattivi, dovrai sempre instradare le richieste a un singolo cluster. Tuttavia, puoi comunque utilizzare la replica gestendo le richieste con un cluster e mantenendo un altro cluster come backup quasi in tempo reale. Se il cluster di gestione non è più disponibile, puoi ridurre al minimo i tempi di inattività eseguendo il failover manuale 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 oppure aggiorna il profilo dell'app predefinito in modo che utilizzi il routing a cluster singolo. Il cluster specificato nel profilo dell'app gestisce le richieste in entrata. L'altro cluster funge da backup nel caso in cui sia necessario eseguire il failover. Questa disposizione è a volte nota come configurazione attiva-passiva e offre un'elevata coerenza e coerenza di lettura/scrittura. Se necessario, puoi attivare le transazioni su riga singola nel profilo dell'app.

Segui i suggerimenti per l'utilizzo della CPU standard per questa configurazione.

Per implementare questa configurazione:

Utilizza il 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 gestisce le richieste in entrata.

L'altro cluster continuerà a utilizzare 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 nell'istanza.

Riceverai un avviso relativo alla perdita della coerenza lettura-scrittura, il che significa anche una perdita di elevata coerenza.

Se hai abilitato le transazioni su riga singola, riceverai anche un avviso relativo alla potenziale perdita di dati. Se invii scritture in conflitto durante il failover, perderai i dati.
Continua a monitorare l'istanza. Dovresti vedere che il secondo cluster sta gestendo le richieste in entrata.

Mantieni alta disponibilità e resilienza regionale

Supponiamo che tu abbia concentrazioni di clienti in due diverse regioni di un continente. Vuoi gestire ogni concentrazione di clienti con cluster Bigtable il più vicino possibile ai clienti. Vuoi che i tuoi dati siano ad alta disponibilità all'interno di ogni regione e potresti utilizzare un'opzione di failover se uno o più cluster non sono disponibili.

Per questo caso d'uso, puoi creare un'istanza con 2 cluster nella regione A e 2 cluster nella regione B. Questa configurazione offre alta disponibilità anche se non è possibile connettersi 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 della zona è ancora disponibile.

Per questo caso d'uso, puoi scegliere di utilizzare il routing a cluster multipli o a cluster singolo, a seconda delle esigenze della tua azienda.

Per configurare l'istanza per questo caso d'uso:

Crea un'istanza Bigtable con 4 cluster: 2 nella regione A e 2 nella regione B. I cluster nella stessa regione devono trovarsi in zone diverse.

Configurazione di esempio:
- cluster-a in zona asia-south1-a a Mumbai
- cluster-b in zona asia-south1-c a Mumbai
- cluster-c in zona asia-northeast1-a a Tokyo
- cluster-d in zona asia-northeast1-b a Tokyo
Posiziona un server applicazioni vicino a ogni regione.

Per questo caso d'uso, puoi scegliere di utilizzare il routing a cluster multipli o a cluster singolo, a seconda delle esigenze della tua azienda. Se usi il routing multi-cluster, Bigtable gestisce automaticamente i failover. Se utilizzi il routing a cluster singolo, decidi in base al tuo giudizio quando eseguire il failover su un cluster diverso.

Opzione di routing a cluster singolo

Per questo caso d'uso, puoi utilizzare il routing a cluster singolo se non vuoi che il cluster Bigtable effettui il failover automatico se una zona o una regione diventa non disponibile. Questa opzione è ideale se vuoi gestire i costi e la latenza che potrebbero verificarsi se Bigtable inizia a instradare il traffico da e verso una regione lontana oppure 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 applicazione che utilizza il routing a cluster singolo per ogni applicazione che invia richieste all'istanza. Puoi instradare 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 per l'applicazione Mumbai in modo che indirizzi gli utenti a asia-south1-a e due che lo indirizzino a asia-south1-c. Per l'applicazione Tokyo, configura tre profili di app che indirizzano a asia-northeast1-a e tre a asia-northeast1-b.

Segui i suggerimenti per l'utilizzo della CPU standard per questa configurazione.

Con questa configurazione, se uno o più cluster non sono più disponibili, puoi eseguire un failover manuale o scegliere di lasciare che i dati siano temporaneamente non disponibili in quella zona finché la zona non sarà di nuovo disponibile.

Opzione di routing a cluster multipli

Se stai implementando questo caso d'uso e vuoi che Bigtable esegua il failover automatico in una regione se la tua applicazione non può raggiungere l'altra, utilizza il routing multi-cluster.

Per implementare questa configurazione, crea un nuovo profilo di app che utilizzi il routing multi-cluster per ogni applicazione oppure aggiorna il profilo dell'app predefinito per utilizzare il routing multi-cluster.

Questa configurazione fornisce coerenza finale. Se una regione non è più disponibile, le richieste Bigtable vengono inviate automaticamente all'altra regione. In questi casi, ti viene addebitato un costo per il traffico di rete verso l'altra regione e la tua applicazione potrebbe riscontrare una latenza maggiore a causa della maggiore distanza.

Quando configuri inizialmente l'istanza, non superare il 35% di utilizzo della CPU per ogni cluster. Questo target garantisce che ogni cluster possa gestire il traffico normalmente gestito dall'altro cluster nella sua regione in caso di failover. Potrebbe essere necessario modificare questo target a seconda del traffico e dei modelli di utilizzo.

Puoi simulare il failover per questo caso d'uso per testare l'applicazione:

Esegui un carico di lavoro di test.
Utilizza la console Google Cloud per monitorare i cluster dell'istanza e verificare che tutti e quattro i cluster stiano gestendo le richieste in entrata.
Elimina uno dei cluster nella regione A per simulare un problema di connessione a una zona.

Questa modifica elimina anche la copia dei dati archiviati con il cluster.
Continua a monitorare la latenza e i tassi di errore per i cluster rimanenti.

Se i cluster hanno un volume sufficiente di risorse della CPU, dovrebbero essere in grado di stare al passo con le richieste in entrata.
Aggiungi un cluster all'istanza nella regione A e continua a monitorare l'istanza.

La replica dei dati nel nuovo cluster dovrebbe iniziare.
Elimina entrambi i cluster nella regione A per simulare un problema di connessione a un'area geografica.

Questa modifica elimina le copie dei tuoi dati presenti nei cluster.
Continua a monitorare la latenza e i tassi di errore per i cluster rimanenti.

Se i cluster hanno un volume sufficiente di risorse della CPU, dovrebbero essere in grado di stare al passo con le richieste in entrata gestite in precedenza dall'altra regione. Se i cluster non hanno risorse sufficienti, potrebbe essere necessario regolare il numero di nodi.

Archivia i dati nelle vicinanze degli utenti

Se hai utenti in tutto il mondo, puoi ridurre la latenza eseguendo la tua applicazione vicino ai tuoi utenti e posizionando i dati il più vicino possibile all'applicazione. Con Bigtable, puoi creare un'istanza che ha cluster in diverse regioni Google Cloud e i tuoi dati vengono replicati automaticamente in ogni regione.

Per questo caso d'uso, utilizza i profili di app con routing a cluster singolo. Il routing multi-cluster è sconsigliato in questo caso d'uso a causa della distanza tra i cluster. Se un cluster non è più disponibile e il relativo profilo dell'app multi-cluster reindirizza automaticamente il traffico su un'elevata distanza, l'applicazione potrebbe riscontrare una latenza inaccettabile e comportare costi di rete aggiuntivi imprevisti.