Questa pagina è stata tradotta dall'API Cloud Translation.

Esempi di impostazioni della replica

In questa pagina vengono descritti alcuni casi d'uso comuni per abilitare la replica di Cloud Bigtable, quindi vengono presentate le impostazioni che puoi utilizzare a supporto di questi casi d'uso.

Isolare i carichi di lavoro di analisi batch da altre applicazioni
Crea disponibilità elevata
Fornisci backup quasi in tempo reale
Mantieni alta disponibilità e resilienza a livello di area geografica
Archivia i dati vicini agli utenti

Questa pagina spiega anche come decidere le impostazioni da utilizzare se il tuo caso d'uso non è elencato qui.

Prima di leggere questa pagina, dovresti conoscere la panoramica della replica Bigtable.

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

Indipendentemente dal tuo caso d'uso, esegui sempre 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, i problemi di prestazioni del cluster possono verificarsi a causa dell'accumulo di memoria e le scritture ad altri cluster nell'istanza potrebbero essere rifiutate.

Isolare i carichi di lavoro di analisi batch da altre applicazioni

Quando utilizzi un unico 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 i profili di app con 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 sugli utenti delle tue 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 consigli standard per l'utilizzo della CPU per questa configurazione.
Crea 2 profili di app, uno denominato live-traffic e un altro chiamato batch-analytics.

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

Puoi abilitare le transazioni per riga singola nel profilo dell'app live-traffic, se necessario. Non è necessario attivare le transazioni su riga singola nel profilo dell'app batch-analytics, supponendo che utilizzerai questo profilo app solo per la lettura.
Utilizza il profilo 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 app batch-analytics per eseguire un carico di lavoro batch di sola lettura.
Monitorare l'utilizzo della CPU per i cluster dell'istanza e, se necessario, aggiungere 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 sue metriche lato client.

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

Crea una nuova istanza con 3 cluster o aggiungi cluster a un'istanza esistente finché non ne avrà 3.

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

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

Utilizza lo stesso numero di nodi in cluster-a e in cluster-b se usano la stessa applicazione. Utilizza un numero maggiore di nodi in cluster-c per supportare il carico di lavoro di dimensioni maggiori.
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
Usa i profili delle app per il traffico in tempo reale per eseguire i carichi di lavoro relativi al traffico in tempo reale.
Mentre i carichi di lavoro di traffico in esecuzione sono in esecuzione, utilizza il profilo app batch-analytics per eseguire un carico di lavoro batch di sola lettura.
Monitorare l'utilizzo della CPU per i cluster dell'istanza e, se necessario, aggiungere 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 sue metriche lato client.

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à archiviando copie separate dei tuoi dati in più zone o regioni e eseguendo il failover automatico tra i cluster, se necessario.

Per configurare l'istanza per un caso d'uso ad alta disponibilità (HA), crea un nuovo profilo app che utilizzi il routing multi-cluster oppure aggiorna il profilo app predefinito per utilizzare il routing multi-cluster. Questa configurazione fornisce coerenza finale. Non puoi attivare le transazioni su riga singola perché questo tipo di transazioni può causare conflitti di dati quando utilizzi il routing a cluster multipli.

Per saperne di più su come Bigtable aiuta a ottenere un'alta disponibilità, vedi Creare una presenza di dati globale con Cloud Bigtable.

Le configurazioni per migliorare la disponibilità includono quanto segue.

Cluster in tre o più regioni diverse (configurazione consigliata). La configurazione consigliata per l'alta disponibilità è un'istanza con cluster N+2 che si trovano ciascuno in un'altra area geografica. Ad esempio, se il numero minimo di cluster di cui hai bisogno per gestire i dati è 2, hai bisogno di un'istanza di 4 cluster per mantenere l'alta disponibilità. Questa configurazione fornisce il tempo di attività anche nel raro caso in cui due aree geografiche non siano più disponibili. Ti consigliamo di distribuire i cluster in più continenti.

Configurazione di esempio:
- cluster-a nella zona us-central1-a in Iowa
- cluster-b nella zona europe-west1-d in Belgio
- cluster-c nella zona asia-east1-b di Taiwan
Per questa configurazione, esegui il provisioning di nodi sufficienti a mantenere un target del 23% di utilizzo della CPU per un'istanza a 3 cluster a 3 aree geografiche e del 35% a livello di CPU per un'istanza a 4 cluster a 4 aree geografiche. Questo garantisce che, anche se due regioni non sono disponibili, il cluster o i cluster rimanenti possono gestire tutto il traffico.
Due cluster nella stessa area geografica, ma in zone diverse. Questa opzione offre disponibilità elevata all'interno della regione, possibilità di failover senza generare costi di replica tra regioni e nessuna latenza nel failover. I tuoi dati in un'istanza Bigtable replicata sono disponibili finché una qualsiasi delle zone in cui è replicata è disponibile.

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

Viene addebitato un costo per la replica delle scritture tra le aree geografiche.

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

Viene addebitato un costo per la replica delle scritture tra le aree geografiche. Se scrivi nella regione A, l'addebito viene effettuato una volta perché hai un solo cluster nella regione B. Se scrivi nella regione B, l'addebito avviene due volte perché hai 2 cluster nell'area geografica A.

Configurazione di esempio:
- cluster-a nella zona europe-west1-b in Belgio
- cluster-b nella zona europe-west1-d in Belgio
- cluster-c nella zona europe-north1-c in Finlandia
Inizia con un target di utilizzo della CPU del 35% nell'area geografica con 2 cluster e 70% nell'altra area geografica. Monitora i cluster dell'istanza e regola il numero di nodi 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:

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

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

Fornisci backup quasi in tempo reale

In alcuni casi, ad esempio, se non puoi permetterti di leggere i dati inattivi, dovrai sempre indirizzare le richieste a un unico 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 pubblicazione diventa non disponibile, puoi ridurre al minimo i tempi di inattività eseguendo il failover manuale del cluster di backup.

Per configurare l'istanza per questo caso d'uso, crea un profilo per l'app che utilizzi il routing a cluster singolo o aggiorna il profilo per app predefinito per utilizzare il routing a cluster singolo. Il cluster specificato nel profilo dell'app gestisce le richieste in entrata. L'altro cluster funge da backup in caso di failover. Questo disposizione a volte è nota come configurazione attiva-passiva e fornisce sia elevata coerenza che coerenza nella lettura per le scritture. Puoi abilitare le transazioni per riga singola nel profilo dell'app, se necessario.

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

Per implementare questa configurazione:

Usa il profilo app con routing a cluster singolo per eseguire un carico di lavoro.
Utilizza la console Google Cloud per monitorare i cluster dell'istanza e confermare che solo un cluster sta gestendo 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 rimandi al secondo cluster dell'istanza.

Riceverai un avviso relativo alla perdita di coerenza delle operazioni di lettura, che indica anche la perdita di elevata coerenza.

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

Mantenere un'alta disponibilità e la resilienza a livello di area geografica

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ù vicino possibile ai clienti. Vuoi che i tuoi dati siano ad alta disponibilità all'interno di ogni regione e consigliamo un'opzione di failover se uno o più cluster non sono disponibili.

Per questo caso d'uso, puoi creare un'istanza con 2 cluster nell'area geografica A e 2 cluster nell'area geografica B. Questa configurazione offre disponibilità elevata anche se non puoi connetterti a una regione di Google Cloud. Fornisce inoltre la resilienza regionale perché, anche se una zona non è più disponibile, l'altro cluster nella regione di quella zona è ancora disponibile.

Puoi scegliere di utilizzare il routing multi-cluster o un cluster singolo per questo caso d'uso, 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 nella zona asia-south1-a di Mumbai
- cluster-b nella zona asia-south1-c di Mumbai
- cluster-c nella zona asia-northeast1-a di Tokyo
- cluster-d nella zona asia-northeast1-b di Tokyo
Posiziona un server di applicazioni vicino a ogni regione.

Puoi scegliere di utilizzare il routing multi-cluster o un cluster singolo per questo caso d'uso, a seconda delle esigenze della tua azienda. Se utilizzi il routing multi-cluster, Bigtable gestisce i failover automaticamente. Se utilizzi il routing a cluster singolo, decidi autonomamente quando eseguire il failover su un cluster diverso.

Opzione di routing per cluster singolo

Puoi utilizzare il routing a cluster singolo per questo caso d'uso se non vuoi che il cluster Bigtable venga eseguito automaticamente se una zona o un'area geografica non è più disponibile. Questa opzione è una buona scelta se vuoi gestire i costi e la latenza che potrebbero verificarsi se Bigtable inizia a eseguire il routing del 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 app che utilizzi il routing a cluster singolo per ogni applicazione che invia richieste all'istanza. Puoi instradare i profili delle 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 in modo che l'applicazione sia instradata a asia-south1-a e due che indirizzano a asia-south1-c. Per l'applicazione Tokyo, configura tre profili di app indirizzati a asia-northeast1-a e tre che indirizzano a asia-northeast1-b.

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

Con questa configurazione, se uno o più cluster diventano non disponibili, puoi eseguire un failover manuale o scegliere di rendere i dati temporaneamente non disponibili nella zona finché la zona non sarà di nuovo disponibile.

Opzione di routing multi-cluster

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

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

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

Quando hai configurato inizialmente l'istanza, non superare il 35% dell'utilizzo della CPU per ogni cluster. Questo target garantisce che ogni cluster sia in grado di gestire il traffico normalmente gestito dall'altro cluster nella sua regione in caso di failover. Potresti dover 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:

Eseguire un carico di lavoro di prova.
Utilizza la console Google Cloud per monitorare i cluster dell'istanza e confermare che tutti e 4 i cluster stanno 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 tuoi dati archiviati nel cluster.
Continua a monitorare la latenza e i tassi di errore per i cluster rimanenti.

Se i cluster hanno risorse CPU sufficienti, 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 dovrebbe iniziare nel nuovo cluster.
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 in tali cluster.
Continua a monitorare la latenza e i tassi di errore per i cluster rimanenti.

Se i cluster hanno risorse CPU sufficienti, devono essere in grado di stare al passo con le richieste in entrata gestite in precedenza dall'altra regione. Se i cluster non dispongono di risorse sufficienti, potrebbe essere necessario modificare il numero di nodi.

Archivia i dati vicini agli utenti

Se hai utenti in tutto il mondo, puoi ridurre la latenza eseguendo l'applicazione vicino agli utenti e inserendo i dati più vicini possibile alla tua applicazione. Con Bigtable puoi creare un'istanza che ha cluster in diverse regioni di 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. La routing a cluster multipli non è appropriata 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 reindirizza automaticamente il traffico su una vasta distanza, l'applicazione potrebbe riscontrare una latenza inaccettabile e comportare costi di rete aggiuntivi imprevisti.