Istanze, cluster e nodi

Per utilizzare Bigtable, crea istanze che contengono cluster che a cui possono connettersi le tue applicazioni. Ogni cluster contiene nodi, la rete 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, dovresti conoscere le panoramica di Bigtable.

Istanze

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

Una tabella appartiene a un'istanza, non a un cluster o 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). SSD è spesso, ma non sempre, il più efficiente a convenienza economica.

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 utilizza sull'istanza per archiviare profili di applicazioni o profili di 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 fornisci identificatori separati per ogni tua applicazione o 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 l'articolo sui profili di applicazioni. A scopri come configurare i profili di app dell'istanza, consulta Configurazione dell'app profili.

Cluster

Un cluster rappresenta il servizio Bigtable in una località specifica. Ogni cluster appartiene a una singola istanza Bigtable può avere cluster in un massimo di 8 regioni. Quando la tua applicazione invia richieste a un'istanza Bigtable, e richieste 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 Bigtable è disponibile. 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 delle 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 di zone e regioni in cui Bigtable è disponibile, consulta Posizioni 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 tuoi dati conservando copie separate dei dati in ciascuno dei cluster zone e e sincronizzare 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 in un'istanza ha 1 o più nodi, ovvero le risorse di calcolo utilizzate da Bigtable per gestire i tuoi dati.

Dietro le quinte, Bigtable suddivide tutti i dati in un in tablet separati. I tablet sono archiviati su disco separate dai nodi, ma che si trovano nella stessa zona dei nodi. Un tablet è associati 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 tablet, ad esempio attività periodiche compazioni.

Un cluster deve avere un numero di nodi sufficiente per supportare il carico di lavoro attuale e la quantità dei dati che archivia. In caso contrario, il cluster potrebbe non essere in grado di gestire la gestione richieste e la latenza potrebbe aumentare. Monitora i cluster e utilizzo del disco e aggiungi nodi a un'istanza quando le metriche superano i suggerimenti Pianifica la capacità.

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

Nodi per cluster replicati

Quando l'istanza ha più di un cluster, il failover diventa una considerazione quando configuri il numero massimo di nodi per la scalabilità automatica o manualmente e allocare i nodi.

  • 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 allocare sempre un numero di nodi sufficiente di failover, che può essere costoso, oppure puoi fare affidamento sulla scalabilità automatica per aggiungere in caso di failover del traffico, ma tieni presente che il problema potrebbe risentirne brevemente mentre il cluster fa lo scale up.

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

    Poiché 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.

    Puoi comunque eseguire il failover manuale da un cluster a un'altra, se necessario. Tuttavia, se un cluster ha molti più nodi ed è necessario eseguire il failover su un cluster con meno nodi, potrebbero 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