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 su istanze, cluster e nodi Bigtable.

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

Istanze

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

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

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

  • Il tipo di archiviazione (SSD o HDD)
  • I profili di applicazione, destinati principalmente alle istanze che utilizzano la replica

Le sezioni seguenti descrivono queste proprietà.

Tipi di archiviazione

Quando crei un'istanza, devi scegliere se i cluster dell'istanza devono archiviare i dati su unità a stato solido (SSD) o unità 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 dell'istanza deve utilizzare lo stesso tipo di archiviazione, quindi assicurati di scegliere il tipo di archiviazione corretto per il tuo caso d'uso. Per ulteriori informazioni che ti aiuteranno a decidere, consulta Scelta tra spazio di archiviazione SSD e HDD.

Profili di applicazione

Dopo aver creato un'istanza, Bigtable la utilizza per archiviare i profili delle applicazioni o i profili delle app. Per le istanze che utilizzano la replica, i profili delle app controllano il modo in cui le applicazioni si connettono 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. Puoi quindi visualizzare grafici separati per ogni profilo dell'app nella console Google Cloud.

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

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 aggiungere un cluster in un'altra zona della stessa regione, ad esempio us-east1-c, o in una zona di un'altra 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. 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 a quale cluster si connettono le tue applicazioni, il che consente di isolare tra loro diversi tipi di traffico. Puoi anche consentire a Bigtable di bilanciare il traffico tra i cluster. Se un cluster non è disponibile, puoi eseguire il failover da un cluster all'altro. Per scoprire di più sul funzionamento della replica, consulta la panoramica della replica.

Nella maggior parte dei casi, devi attivare la scalabilità automatica per un cluster, in modo che Bigtable aggiunga e rimuova i nodi in base alle esigenze per gestire i workload 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 è associato a un singolo nodo.

Ogni nodo è responsabile di:

  • Monitoraggio di tablet specifici sul disco.
  • Gestire le letture e le scritture in arrivo per i suoi 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 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 tuoi profili dell'app, il failover automatico può verificarsi nel caso in cui uno o più cluster non siano disponibili.

  • Quando esegui il failover manuale da un cluster a un altro o quando si verifica il failover automatico, il cluster di destinazione dovrebbe avere 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 esigenze in base al carico di lavoro del cluster.

    Poiché Bigtable memorizza una copia separata dei tuoi dati in ogni cluster, ogni cluster deve sempre avere un numero sufficiente di nodi per supportare il tuo utilizzo del disco e per replicare le 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 c'è alcuna garanzia che saranno disponibili nodi aggiuntivi quando dovrai eseguire il passaggio al cluster di riserva. L'unico modo per prenotare i nodi in anticipo è aggiungerli al cluster.

Passaggi successivi