Istanze, cluster e nodi

Per utilizzare Bigtable, crei istanze che contengono cluster a cui le tue applicazioni possono connettersi. Ogni cluster contiene nodi, ovvero le unità di calcolo che gestiscono i dati ed eseguono attività di manutenzione.

Questa pagina fornisce ulteriori informazioni sulle istanze Bigtable, cluster e nodi.

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

Istanze

Un'istanza Bigtable è un container per i tuoi dati. Le istanze hanno uno o più cluster, situati in zone diverse. Ogni cluster ha almeno 1 nodo.

Una tabella appartiene a un'istanza, non a un cluster o a un nodo. Se hai un'istanza con più di un cluster, stai utilizzando la replica. Ciò significa che non puoi assegnare una tabella a un singolo cluster o creare una garbage collection univoca per ogni cluster in un'istanza. Inoltre, non puoi fare in modo che ogni cluster archivi per un set di dati diverso nella stessa tabella.

Un'istanza ha alcune proprietà importanti che devi conoscere:

  • Il tipo di archiviazione (SSD o HDD)
  • I profili di applicazioni, principalmente per istanze che utilizzano replica

Nelle sezioni seguenti vengono descritte queste proprietà.

Tipi di archiviazione

Quando crei un'istanza, devi scegliere se i cluster dell'istanza archivieranno i dati su unità a stato solido (SSD) o su disco rigido (HDD). Spesso, ma non sempre, le unità SSD sono la scelta più efficiente e conveniente.

La scelta tra SSD e HDD è definitiva e ogni cluster nella tua istanza devono utilizzare lo stesso tipo di archiviazione, quindi assicurati di scegliere quello giusto per il tuo caso d'uso. Consulta Scegliere tra l'archiviazione SSD e HDD per ulteriori informazioni che ti aiuteranno a decidere.

Profili di applicazione

Dopo aver creato un'istanza, Bigtable la utilizza per archiviare i profili delle applicazioni, o profili app. Per che utilizzano la replica, i profili delle app controllano il modo in cui le connettersi ai cluster dell'istanza.

Se la tua istanza non utilizza la replica, puoi comunque utilizzare i profili dell'app per fornire identificatori separati per ciascuna delle tue applicazioni o per ogni funzione all'interno di un'applicazione. In seguito, puoi visualizzare grafici separati per ogni profilo di app nella console Google Cloud.

Per scoprire di più sui profili delle app, consulta la sezione Profili delle app. A scopri come configurare i profili di app dell'istanza, consulta Configurazione dell'app profili.

Cluster

Un cluster rappresenta il servizio Bigtable in una posizione specifica. Ogni cluster appartiene a un'unica istanza Bigtable e un'istanza può avere cluster in un massimo di 8 regioni. Quando l'applicazione invia richieste a un'istanza Bigtable, queste richieste vengono gestite da uno dei cluster dell'istanza.

Ogni cluster si trova in un'unica zona. Un'istanza può avere cluster in un massimo di 8 regioni in cui è disponibile Bigtable. Ogni zona di una regione può contenere un solo cluster. Ad esempio, se un'istanza ha un cluster in us-east1-b, puoi aggiungerne uno in una zona diversa della stessa regione, ad esempio us-east1-c, oppure una zona in un regione, ad esempio europe-west2-a.

Il numero di cluster che puoi creare in un'istanza dipende dal numero di zone disponibili nelle regioni che scegli. Ad esempio, se crei cluster in 8 regioni con tre zone ciascuna, il numero massimo di cluster che l'istanza può avere è 24. Per un elenco delle zone e delle regioni in cui è disponibile Bigtable, consulta Località di Bigtable.

Le istanze Bigtable con un solo cluster non utilizzano la replica dei dati. Se aggiungi un secondo cluster a un'istanza, Bigtable avvia automaticamente la replica dei dati mantenendo copie separate dei dati in ciascuna delle zone dei cluster e sincronizzando gli aggiornamenti tra le copie. Puoi scegliere quale cluster per la connessione delle applicazioni, consentendo di isolare diversi tipi di il traffico l'uno dall'altro. Puoi anche consentire a Bigtable di bilanciare il traffico tra i cluster. Se un cluster non è più disponibile, puoi eseguire il failover da uno da un cluster a un altro. Per saperne di più su come funziona la replica, consulta panoramica della replica.

Nella maggior parte dei casi, devi abilitare la scalabilità automatica per in modo che Bigtable aggiunga e rimuova i nodi in base alle esigenze per gestire i carichi di lavoro del cluster.

Nodi

Ogni cluster di un'istanza ha uno o più nodi, ovvero risorse di calcolo utilizzate da Bigtable per gestire i dati.

Dietro le quinte, Bigtable suddivide tutti i dati di una tabella in tablet distinti. I tablet sono archiviati su disco, separati dai nodi, ma nella stessa zona. Un tablet è associati a un singolo nodo.

Ogni nodo è responsabile di:

  • Monitoraggio di tablet specifici sul disco.
  • Gestione delle letture e delle scritture in entrata per i tablet.
  • Eseguire attività di manutenzione sui tablet, ad esempio compazioni periodiche.

Un cluster deve avere un numero di nodi sufficiente per supportare il carico di lavoro attuale e la quantità di dati archiviati. In caso contrario, il cluster potrebbe non essere in grado di gestire le richieste in entrata e la latenza potrebbe aumentare. Monitora l'utilizzo della CPU e del disco dei tuoi cluster e aggiungi nodi a un'istanza quando le relative metriche superano i consigli riportati in Pianifica la tua capacità.

Per ulteriori dettagli su come Bigtable archivia e gestisce i dati, consulta Architettura di Bigtable.

Nodi per i cluster replicati

Quando l'istanza ha più di un cluster, il failover diventa un fattore da prendere in considerazione quando configuri il numero massimo di nodi per la scalabilità automatica o li assegni manualmente.

  • Se utilizzi il routing multi-cluster in uno dei profili delle tue app, il failover automatico può avvenire nel caso in cui uno o non sono disponibili altri cluster.

  • Quando viene eseguito manualmente il failover da un cluster all'altro o quando esegui il failover automatico un failover, il cluster ricevente dovrebbe avere idealmente una capacità sufficiente per supportare il carico. Puoi sempre allocare un numero sufficiente di nodi per supportare il failover, il che può essere costoso, oppure puoi fare affidamento sulla scalabilità automatica per aggiungere nodi quando il traffico viene eseguito in failover, ma tieni presente che potrebbe esserci un breve impatto sul rendimento durante l'aumento di dimensioni del cluster.

  • Se tutti i tuoi profili dell'app utilizzano il routing a cluster singolo, ogni cluster può avere un numero diverso di nodi. Ridimensiona ogni cluster in base alle tue esigenze in base al carico di lavoro del cluster.

    Dato che Bigtable archivia una copia separata dei tuoi dati con ogni cluster, ogni cluster deve avere sempre nodi sufficienti per supportare l'utilizzo del disco e la replica delle scritture tra i cluster.

    Se necessario, puoi comunque eseguire il failover manualmente da un cluster all'altro. Tuttavia, se un cluster ha molti più nodi di un altro e devi eseguire il failover al cluster con meno nodi, potresti dover prima aggiungere nodi. Non sono presenti garantire la disponibilità di nodi aggiuntivi in caso di errore l'unico modo per prenotare i nodi in anticipo è aggiungerli in un cluster Kubernetes.

Passaggi successivi