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 acquisire 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 un nodo.

Una tabella appartiene a un'istanza, non a un cluster o nodo. Se hai un'istanza con più di un cluster, stai utilizzando la replica. Questo 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 fare in modo che ogni cluster archivi 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 le istanze che utilizzano la replica

Le seguenti sezioni descrivono 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 disco rigido (HDD). L'SSD è spesso, ma non sempre, la soluzione più efficiente ed economica.

La scelta tra SSD e HDD è definitiva e ogni cluster nell'istanza deve 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 la utilizza per archiviare i profili di applicazione o di app. Per le istanze che utilizzano la replica, i profili di app controllano il modo in cui le tue applicazioni si connettono ai cluster dell'istanza.

Se la tua istanza non utilizza la replica, puoi comunque usare i profili delle 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 di app nella console Google Cloud.

Per scoprire di più sui profili di app, consulta la pagina relativa ai profili di applicazione. Per scoprire come configurare i profili delle app della tua istanza, consulta Configurazione dei 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 l'applicazione invia richieste a un'istanza Bigtable, queste vengono gestite da uno dei cluster nell'istanza.

Ogni cluster si trova in una singola zona. Un'istanza può avere cluster in un massimo di otto 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 nella stessa regione, come us-east1-c, o in una zona in una regione separata, 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 otto 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 inizia automaticamente a replicare i tuoi dati mantenendo copie separate dei dati nelle zone di ogni cluster e sincronizzando gli aggiornamenti tra le copie. Puoi scegliere a quale cluster connettersi 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, è possibile eseguire il failover da un cluster all'altro. Per saperne di più sul funzionamento della replica, consulta la panoramica della replica.

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 separati. I tablet sono archiviati su disco, separati dai nodi ma nella stessa zona dei nodi. Un tablet è associato a un singolo nodo.

Ogni nodo è responsabile di:

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

Un cluster deve avere un numero sufficiente di nodi 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 metriche superano i suggerimenti e i limiti elencati di seguito.

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

Utilizzo CPU

Bigtable segnala le seguenti metriche per l'utilizzo della CPU:

Metrica Descrizione
Utilizzo CPU medio

L'utilizzo medio della CPU su tutti i nodi nel cluster. Include l'attività di modifiche in tempo reale se è abilitato un flusso di modifiche per una tabella nell'istanza.

Nei grafici del profilo dell'app, <system> indica le attività in background del sistema, come la replica e la compattazione. Le attività in background del sistema non sono basate sul client.

I valori massimi consigliati offrono margine per brevi picchi di utilizzo.

Se un cluster supera il valore massimo consigliato per la configurazione per più di alcuni minuti, aggiungi nodi al cluster.

Utilizzo della CPU del nodo più attivo

Utilizzo della CPU per il nodo con il traffico maggiore nel cluster. Questa metrica continua a essere fornita per la continuità, ma nella maggior parte dei casi ti consigliamo di utilizzare la metrica più accurata Utilizzo della CPU ad alta granularità del nodo più caldo.

Utilizzo della CPU ad alta granularità del nodo più attivo

Una misurazione granulare dell'utilizzo della CPU per il nodo più trafficato nel cluster. Ti consigliamo di utilizzare questa metrica invece di Utilizzo della CPU del nodo più attivo, poiché questa metrica è più precisa.

Il nodo più caldo non corrisponde necessariamente allo stesso nodo nel tempo e può cambiare rapidamente, soprattutto durante job batch o analisi delle tabelle di grandi dimensioni.

Se il nodo più attivo è spesso superiore al valore consigliato, anche quando l'utilizzo medio della CPU è ragionevole, potresti accedere a una piccola parte dei tuoi dati con maggiore frequenza rispetto al resto dei dati.

  • Utilizza lo strumento Key Visualizer per identificare gli hotspot nella tabella che potrebbero causare picchi di utilizzo della CPU.
  • Controlla la progettazione dello schema per assicurarti che supporti una distribuzione uniforme delle letture e delle scritture in ogni tabella.
Utilizzo CPU per modifiche in tempo reale

L'utilizzo medio della CPU causato dall'attività di modifiche in tempo reale su tutti i nodi nel cluster.

Utilizzo della CPU per profilo app, metodo e tabella

Utilizzo della CPU per profilo app, metodo e tabella.

Se noti un utilizzo della CPU superiore al previsto per un cluster, utilizza questa metrica per determinare se l'utilizzo della CPU di un profilo di app, un metodo API o una tabella specifici determina il carico della CPU.

I valori per queste metriche non devono superare i seguenti valori:

Configurazione Valori massimi consigliati1
  1. I valori massimi consigliati si riferiscono a un intero cluster. Non esistono valori massimi consigliati per l'utilizzo della CPU in base a profilo, metodo o tabella dell'app. Utilizza questa metrica più granulare per l'osservabilità sulle possibili cause dell'utilizzo elevato della CPU da parte di un cluster.
  2. I valori massimi consigliati assicurano che l'istanza abbia capacità sufficiente per continuare a funzionare a bassa latenza in caso di failover. Ad esempio, in un'istanza con due cluster, ognuno deve essere in grado di gestire tutto il traffico al 70% nel caso in cui l'altro cluster diventi non disponibile.
Routing a cluster singolo, qualsiasi numero di cluster

70% di utilizzo medio della CPU
90% di utilizzo della CPU del nodo più attivo

Routing multi-cluster, scalabilità automatica abilitata, due o più cluster

70% di utilizzo medio della CPU
90% di utilizzo della CPU del nodo più attivo

Routing multi-cluster, scalabilità automatica non abilitata, 2 cluster

Utilizzo medio della CPU del 35% 2
Utilizzo della CPU del 45% del nodo più attivo2

Routing multi-cluster, scalabilità automatica non abilitata, 3 o più cluster

Dipende dalla configurazione. Consulta gli esempi di impostazioni di replica per i casi d'uso comuni.

Utilizzo disco

Bigtable registra le seguenti metriche per l'utilizzo del disco:

Metrica Descrizione
Utilizzo spazio di archiviazione (byte)

La quantità di dati archiviati nel cluster. L'utilizzo delle modifiche in tempo reale non è incluso per questa metrica.

Questo valore influisce sui costi. Inoltre, come descritto di seguito, potresti dover aggiungere nodi a ogni cluster man mano che la quantità di dati aumenta.

Utilizzo spazio di archiviazione (% max)

La percentuale di capacità di archiviazione del cluster in uso. La capacità si basa sul numero di nodi nel cluster. L'utilizzo delle modifiche in tempo reale non è incluso per questa metrica.

In generale, non utilizzare più del 70% del limite rigido sullo spazio di archiviazione totale, in modo da avere spazio per aggiungere altri dati. Se non prevedi di aggiungere quantità significative di dati all'istanza, puoi utilizzare fino al 100% del limite rigido.

Se utilizzi una percentuale superiore al limite di archiviazione consigliato, aggiungi nodi al cluster. Puoi anche eliminare i dati esistenti, ma i dati eliminati occupano più spazio, non meno, fino a quando non avviene una compattazione.

Per maggiori dettagli su come viene calcolato questo valore, vedi Utilizzo dello spazio di archiviazione per nodo.

Utilizzo dello spazio di archiviazione per le modifiche in tempo reale (byte)

La quantità di spazio di archiviazione utilizzato dai record di modifiche in tempo reale per le tabelle nell'istanza. Questo spazio di archiviazione non viene conteggiato nel calcolo dell'utilizzo totale dello spazio di archiviazione. Ti viene addebitato l'archiviazione in modifiche in tempo reale, ma non è inclusa nel calcolo dell'utilizzo dello spazio di archiviazione (% max).

Carico su disco

La percentuale della larghezza di banda massima possibile per le letture HDD da parte del cluster. Disponibile solo per i cluster HDD.

Se questo valore è spesso al 100%, potresti riscontrare un aumento della latenza. Aggiungi nodi al cluster per ridurre la percentuale di carico del disco.

Nodi per cluster replicati

In un'istanza che utilizza la replica, assicurati che ogni cluster abbia un numero sufficiente di nodi per supportare il tuo caso d'uso:

  • Se utilizzi la replica per garantire l'alta disponibilità o se utilizzi il routing multi-cluster in uno qualsiasi dei profili dell'app, ogni cluster deve avere lo stesso numero di nodi. Inoltre, come mostrato sopra in Utilizzo CPU, l'utilizzo consigliato della CPU si è ridotto della metà.

    Questa configurazione aiuta a garantire che, qualora sia necessario un failover automatico, il cluster reattivo abbia una capacità sufficiente per gestire tutto il traffico.

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

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

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

Passaggi successivi