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 supportare questi casi d'uso.

Questa pagina spiega anche come decidere quali impostazioni utilizzare per altri casi d'uso.

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

Prima di aggiungere cluster a un'istanza, devi conoscere le limitazioni che si applicano quando modifichi i criteri di raccolta dei rifiuti 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 i nodi di un cluster in base al carico di lavoro.

Se 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 ricevuto dalle applicazioni. Se un cluster non ha nodi sufficienti, il ritardo della replica può aumentare, il cluster può presentare problemi di prestazioni a causa dell'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 i cluster a un'istanza esistente.

Isolare i carichi di lavoro di analisi batch da altre applicazioni

Quando utilizzi un singolo cluster per eseguire un job di analisi in 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 delle 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 tue applicazioni.

Per isolare due carichi di lavoro:

  1. Crea un'istanza con due cluster.

  2. Crea due profili app, uno denominato live-traffic e un altro batch-analytics.

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

    Se necessario, puoi attivare le transazioni su riga singola nel profilo dell'app live-traffic. Non è necessario attivare le transazioni con una riga nel profilo dell'app batch-analytics, a condizione che tu intenda utilizzare questo profilo solo per le letture.

  3. Utilizza il profilo dell'app live-traffic per eseguire un carico di lavoro del traffico in tempo reale.

  4. Mentre il workload del traffico in tempo reale è in esecuzione, utilizza il profilo dell'app batch-analytics per eseguire un workload batch di sola lettura.

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

  1. Crea un'istanza con tre cluster.

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

  2. Crea i seguenti profili di app:

    • live-traffic-app-a: routing a un cluster singolo dalla tua applicazione a cluster-a
    • live-traffic-app-b: routing a un cluster singolo dalla tua applicazione a cluster-b
    • batch-analytics: routing a singolo cluster dal job di analisi batch a cluster-c

  3. Utilizza i profili delle app di traffico in tempo reale per eseguire carichi di lavoro di questo tipo.

  4. Mentre i workload relativi al traffico in tempo reale sono in esecuzione, utilizza il profilo dell'app batch-analytics per eseguire un workload batch di sola lettura.

Creare l'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à sia la disponibilità archiviando copie separate dei dati in più zone o regioni ed 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 dell'app che utilizzi il routing multi-cluster o aggiorna il profilo dell'app predefinito in modo che utilizzi il routing multi-cluster. Questa configurazione fornisce la coerenza finale. Non potrai attivare le transazioni su riga singola perché possono causare conflitti di dati quando utilizzi il routing multicluster.

Le configurazioni per migliorare la disponibilità includono quanto segue.

  • Cluster in tre o più regioni diverse (configurazione consigliata). La configurazione consigliata per l'HA è un'istanza con N+2 cluster, ognuno in una regione diversa. Ad esempio, se il numero minimo di cluster necessari per pubblicare i dati è 2, per mantenere l'HA è necessaria un'istanza con quattro cluster. Questa configurazione garantisce l'uptime anche nel raro caso in cui due regioni non siano disponibili. Ti consigliamo di distribuire i cluster su 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 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à di eseguire il failover senza generare costi di replica tra regioni e nessuna latenza aggiuntiva durante il failover. I dati in un'istanza Bigtable replicata sono disponibili a condizione che una delle zone in cui viene eseguita la replica sia disponibile.

    Configurazione di esempio:

    • cluster-a nella zona australia-southeast1-a a Sydney
    • cluster-b nella zona australia-southeast1-b a Sydney

  • Due cluster in regioni diverse. Questa configurazione multiregionale offre un'alta disponibilità come la configurazione multizona precedente, ma i dati sono disponibili anche se non riesci a connetterti a una delle regioni.

    Ti vengono addebitati i costi per la replica delle scritture tra regioni.

    Configurazione di esempio:

    • cluster-a nella zona asia-northeast1-c di Tokyo
    • cluster-b nella zona asia-east2-b di Hong Kong

  • Due cluster nella regione A e un terzo cluster nella regione B. Questa opzione consente di rendere disponibili i dati anche se non riesci a connetterti a una delle regioni e offre una capacità aggiuntiva nella regione A.

    Ti vengono addebitati i costi per la replica delle scritture tra regioni. Se scrivi nella regione A, ti viene addebitato un solo costo perché hai un solo cluster nella regione B. Se scrivi nella regione B, ti viene addebitato il costo due volte perché hai due 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 nella zona europe-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 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 in tempo quasi reale. Se il cluster di pubblicazione diventa non disponibile, puoi ridurre al minimo i tempi di inattività eseguendo manualmente il failover al 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 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 in caso di necessità di eseguire il failover. Questa disposizione è a volte nota come configurazione attiva-passiva e offre sia coerenza elevata che coerenza read-your-writes. Se necessario, puoi attivare le transazioni su riga singola nel profilo dell'app.

Per implementare questa configurazione:

  1. Utilizza un profilo dell'app con routing a cluster singolo per eseguire un workload.

  2. 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 continuerà a utilizzare le risorse della CPU per eseguire la replica e altre attività di manutenzione.

  3. Aggiorna il profilo dell'app in modo che indichi il secondo cluster della tua istanza.

    Ricevi un avviso relativo alla perdita della coerenza di lettura delle tue scritture, il che significa anche che perdi la coerenza rigorosa.

    Se hai attivato le transazioni a riga singola, riceverai anche un avviso sulla potenziale perdita di dati. Perderai i dati se invii scritture in conflitto durante il failover.

  4. Continua a monitorare l'istanza. Dovresti vedere che il secondo cluster gestisce le richieste in arrivo.

Mantieni alta disponibilità e resilienza a livello di regione

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 altamente disponibili all'interno di ogni regione e potresti volere un'opzione di failover se uno o più dei tuoi cluster non sono disponibili.

Per questo caso d'uso, puoi creare un'istanza con due cluster nella regione A e due nella regione B. Questa configurazione garantisce un'alta disponibilità anche se non puoi collegarti a una regione Google Cloud. Fornisce inoltre resilienza a livello di regione perché, anche se una zona diventa non disponibile, l'altro cluster nella regione della zona rimane disponibile.

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

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

  1. 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 zona asia-south1-a a Mumbai
    • cluster-b nella zona asia-south1-c a Mumbai
    • cluster-c nella zona asia-northeast1-a di Tokyo
    • cluster-d nella zona asia-northeast1-b di Tokyo

  2. Posiziona un server delle applicazioni vicino a ogni regione.

Per questo caso d'uso, puoi scegliere di utilizzare il routing a cluster multipli o il routing a cluster singolo, a seconda delle esigenze della tua attività. Se utilizzi 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 altro cluster.

Opzione di routing a un cluster singolo

Puoi utilizzare il routing a cluster singolo per questo caso d'uso se non vuoi che il tuo cluster Bigtable esegua il failover automaticamente 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 verso e da una regione distante 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 dell'app che utilizzi 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 dell'app per l'applicazione di Mumbai in modo che indirizzi a asia-south1-a e due che indirizzino a asia-south1-c. Per l'applicazione di Tokyo, configura tre profili dell'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 i dati temporaneamente non disponibili nella zona finché non sarà di nuovo 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 la tua applicazione non riesce a raggiungere l'altra regione, utilizza il routing multi-cluster.

Per implementare questa configurazione, crea un nuovo profilo dell'app che utilizzi il routing a cluster multipli per ogni applicazione oppure aggiorna il profilo dell'app predefinito in modo che utilizzi il routing a cluster multipli.

Questa configurazione fornisce la coerenza finale. Se una regione non è disponibile, le richieste Bigtable vengono inviate automaticamente all'altra regione. In questo caso, ti viene addebitato il traffico di rete verso l'altra regione e la tua applicazione potrebbe presentare 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 la tua applicazione vicino agli utenti e posizionando i dati il più vicino possibile all'applicazione. Con Bigtable puoi creare un'istanza con cluster in più regioni Google Cloud e i tuoi dati vengono replicati automaticamente in ogni regione.

Per questo caso d'uso, utilizza i profili dell'app con routing a cluster singolo. Il routing multi-cluster non è auspicabile per questo caso d'uso a causa della distanza tra i cluster. Se un cluster non è disponibile e il relativo profilo dell'app multi-cluster reindirizza automaticamente il traffico su una lunga distanza, la tua applicazione potrebbe registrare una latenza inaccettabile e comportare costi di rete imprevisti e aggiuntivi.

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

  1. Crea un'istanza con cluster in tre regioni geografiche distinte, ad esempio Stati Uniti, Europa e Asia.

  2. Posiziona un server delle applicazioni vicino a ogni regione.

  3. Crea profili di app simili al seguente:

    • clickstream-us: routing a un cluster singolo per il cluster negli Stati Uniti
    • clickstream-eu: Routing a un cluster singolo nel cluster in Europa
    • clickstream-asia: routing a un cluster singolo verso il 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 hai un caso d'uso non descritto in questa pagina, utilizza le seguenti domande per decidere come configurare i profili delle app:

Passaggi successivi