Istanze, cluster e nodi

Per utilizzare Bigtable, devi creare 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, dovresti avere familiarità con 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 un nodo. Se hai un'istanza con più cluster, stai utilizzando la replica. Ciò significa che non puoi assegnare una tabella a un singolo cluster o creare criteri di garbage collection univoci per ogni cluster in un'istanza. Inoltre, non puoi consentire a ogni cluster di archiviare 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 applicazione, 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 devono archiviare i dati su unità a stato solido (SSD) o su disco rigido (HDD). L'SSD è spesso, ma non sempre, la scelta più efficiente ed economica.

La scelta tra SSD e HDD è definitiva e tutti i cluster nella tua istanza devono utilizzare lo stesso tipo di archiviazione, quindi assicurati di scegliere il tipo di archiviazione adatto al tuo caso d'uso. Consulta Scelta tra archiviazione SSD e HDD per ulteriori informazioni che ti aiuteranno a decidere.

Profili di applicazione

Dopo aver creato un'istanza, Bigtable utilizza l'istanza per archiviare i profili di applicazione o i profili di app. Per le istanze che utilizzano la replica, i profili app controllano il modo in cui le applicazioni si connettono ai cluster dell'istanza.

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

Per scoprire di più sui profili delle app, consulta l'articolo sui profili di applicazioni. Per scoprire come configurare i profili delle app dell'istanza, consulta Configurare i profili delle app.

Cluster

Un cluster rappresenta il servizio Bigtable in una località specifica. Ogni cluster appartiene a una singola istanza Bigtable e un'istanza può avere cluster in un massimo di 8 regioni. Quando la tua applicazione invia richieste a un'istanza Bigtable, queste vengono gestite da uno dei cluster nell'istanza.

Ogni cluster si trova in una zona singola. 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 una zona diversa della stessa regione, come us-east1-c, oppure una zona in un'area geografica separata, come europe-west2-a.

Il numero di cluster che puoi creare in un'istanza dipende dal numero di zone disponibili nelle regioni scelte. Ad esempio, se crei cluster in 8 regioni con 3 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, vedi Località di Bigtable.

Le istanze Bigtable con un solo cluster non utilizzano la replica. Se aggiungi un secondo cluster a un'istanza, Bigtable inizia automaticamente a replicare i tuoi dati conservando copie separate dei dati in ciascuna zona del cluster e sincronizzando gli aggiornamenti tra le copie. Puoi scegliere a quale cluster connettere le tue applicazioni, in modo da isolare diversi tipi di 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 un cluster all'altro. Per scoprire di più su come funziona la replica, consulta la panoramica della replica.

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

Nodi

Ogni cluster in un'istanza ha 1 o più nodi, che sono risorse di calcolo utilizzate da Bigtable per gestire i tuoi dati.

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

Ciascun nodo è responsabile di:

  • Monitoraggio di tablet specifici su disco.
  • Gestione delle letture e delle scritture in entrata per i tablet.
  • L'esecuzione di attività di manutenzione sui suoi tablet, come comparazioni 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 cluster e aggiungi nodi a un'istanza quando le relative metriche superano i suggerimenti descritti in Pianificare la capacità.

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

Nodi per cluster replicati

Se l'istanza ha più di un cluster, viene preso in considerazione il failover quando configuri il numero massimo di nodi per la scalabilità automatica o assegni manualmente i nodi.

  • Se utilizzi il routing multi-cluster in uno dei profili delle tue app, può verificarsi il Failover automatico nel caso in cui uno o più cluster non siano disponibili.

  • Quando si esegue il failover manuale da un cluster all'altro o in caso di failover automatico, il cluster di ricezione dovrebbe idealmente avere una capacità sufficiente per supportare il carico. Puoi allocare sempre un numero di nodi sufficiente a supportare il failover, il che può essere costoso, oppure puoi affidarti alla scalabilità automatica per aggiungere nodi in caso di failover del traffico, ma tieni presente che potrebbe esserci un breve impatto sulle prestazioni mentre il cluster fa lo scale up.

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

    Poiché Bigtable archivia una copia separata dei tuoi dati in ciascun cluster, ogni cluster deve avere sempre un numero di nodi sufficiente per supportare l'utilizzo del disco e per replicare le scritture tra i cluster.

    È comunque possibile eseguire il failover manuale da un cluster all'altro, se necessario. Tuttavia, se un cluster ha molti più nodi di un altro e hai bisogno di eseguire il failover su un cluster con meno nodi, potrebbe essere necessario aggiungere nodi prima. Non vi è alcuna garanzia che saranno disponibili nodi aggiuntivi in caso di failover: l'unico modo per prenotare i nodi in anticipo è aggiungerli al cluster.

Passaggi successivi