Instances, clusters et nœuds

Pour utiliser Bigtable, vous créez des instances qui contiennent des clusters auxquels vos applications peuvent se connecter. Chaque cluster contient des nœuds, à savoir les unités de calcul qui gèrent vos données et effectuent des tâches de maintenance.

Cette page fournit plus d'informations sur les instances, les clusters et les nœuds Bigtable.

Avant de lire cette page, vous devez avoir lu la présentation de Bigtable.

Instances

Une instance Bigtable est un conteneur pour vos données. Les instances possèdent un ou plusieurs clusters situés dans différentes zones. Chaque cluster comporte au moins un nœud.

Une table appartient à une instance, et non à un cluster ou à un nœud. Si vous disposez d'une instance avec plusieurs clusters, vous utilisez la réplication. Cela signifie que vous ne pouvez pas attribuer une table à un cluster individuel ni créer des règles de récupération de mémoire uniques pour chaque cluster d'une instance. Vous ne pouvez pas non plus faire en sorte que chaque cluster stocke un ensemble de données différent dans la même table.

Une instance possède quelques propriétés importantes que vous devez connaître :

  • Le type de stockage (SSD ou HDD)
  • Les profils d'application, qui sont principalement destinés aux instances utilisant la réplication

Les sections suivantes décrivent ces propriétés.

Types de stockage

Lorsque vous créez une instance, vous devez choisir le type de disques durs, SSD ou HDD, à utiliser par les clusters de l'instance pour stocker les données. Le stockage SSD constitue souvent, mais pas toujours, le choix le plus efficace et le plus rentable.

Le choix entre disques durs SSD et HDD est définitif. Chaque cluster de votre instance doit utiliser le même type de stockage. Par conséquent, assurez-vous de choisir le type de stockage adapté à votre cas d'utilisation. Pour en savoir plus et pour vous aider à faire votre choix, consultez la page Choisir entre le stockage SSD et HDD.

Profils d'application

Une fois que vous avez créé une instance, Bigtable l'utilise pour stocker des profils d'application. Pour les instances qui utilisent la réplication, les profils d'application contrôlent la manière dont vos applications se connectent aux clusters de l'instance.

Si votre instance n'utilise pas la réplication, vous pouvez utiliser les profils d'application pour fournir des identifiants distincts à chacune de vos applications ou à chaque fonction d'une application. Vous pouvez ensuite afficher des graphiques distincts pour chaque profil d'application dans la console Google Cloud.

Pour en savoir plus sur les profils d'application, consultez la section Profils d'application. Pour savoir comment configurer les profils d'application de votre instance, consultez la section Configurer des profils d'application.

Clusters

Un cluster représente le service Bigtable dans un emplacement spécifique. Chaque cluster appartient à une seule instance Bigtable. Une instance peut avoir des clusters dans un maximum de huit régions. Lorsque votre application envoie des requêtes à une instance Bigtable, celles-ci sont traitées par l'un des clusters de l'instance.

Chaque cluster est situé dans une seule zone. Une instance peut comporter des clusters dans huit régions au maximum, où Bigtable est disponible. Chaque zone d'une région ne peut contenir qu'un seul cluster. Par exemple, si une instance dispose d'un cluster dans la région us-east1-b, vous pouvez ajouter un cluster dans une autre zone de la même région, telle que us-east1-c, ou dans une zone située dans une région distincte. Par exemple, europe-west2-a.

Le nombre de clusters que vous pouvez créer dans une instance dépend du nombre de zones disponibles dans les régions que vous choisissez. Par exemple, si vous créez des clusters dans huit régions comportant chacune trois zones, l'instance peut avoir 24 clusters au maximum. Pour obtenir la liste des zones et des régions dans lesquelles Bigtable est disponible, consultez Emplacements Bigtable.

Les instances Bigtable ne comportant qu'un seul cluster n'utilisent pas la réplication. Si vous ajoutez un deuxième cluster à une instance, Bigtable commence automatiquement à répliquer vos données en conservant des copies distinctes des données dans chacune des zones des clusters et en synchronisant les mises à jour entre les copies. Vous pouvez choisir le cluster auquel vos applications se connectent, ce qui permet d'isoler différents types de trafic les uns des autres. Vous pouvez également laisser Bigtable équilibre le trafic entre les clusters. Si un cluster devient indisponible, vous pouvez basculer d'un cluster à un autre. Pour découvrir comment fonctionne la réplication, consultez la présentation de la réplication.

Dans la plupart des cas, vous devez activer l'autoscaling pour pour que Bigtable ajoute et supprime des nœuds selon les besoins pour gérer les charges de travail du cluster.

Nœuds

Chaque cluster d'une instance possède un ou plusieurs nœuds, qui correspondent à des ressources de calcul permettant à Bigtable de gérer vos données.

En coulisses, Bigtable divise toutes les données d'une table en tablets distincts. Les tablets sont stockés sur le disque, séparément des nœuds mais dans la même zone que ces derniers. Un tablet est associé à un unique nœud.

Chaque nœud est responsable des éléments suivants :

  • Effectuer le suivi de tablets spécifiques sur le disque
  • Gérer les lectures et écritures entrantes pour ces tablets
  • Effectuer les tâches de maintenance sur ces tablets, telles que des compactages périodiques

Un cluster doit disposer de suffisamment de nœuds pour assimiler la charge de travail actuelle et la quantité de données qu'il stocke. Sinon, le cluster risque de ne pas pouvoir gérer les requêtes entrantes, ce qui peut entraîner une augmentation de la latence. Surveillez l'utilisation du processeur et de l'espace disque de vos clusters et ajoutez des nœuds à une instance lorsque ses métriques dépassent les recommandations de la section Planifier votre capacité.

Pour en savoir plus sur le stockage et la gestion des données par Bigtable, consultez la page Architecture Bigtable.

Nœuds pour les clusters dupliqués

Lorsque votre instance comporte plusieurs clusters, le basculement doit être pris en compte lorsque vous configurez le nombre maximal de nœuds pour l'autoscaling ou que vous allouez manuellement les nœuds.

  • Si vous utilisez le routage multicluster dans l'un de vos profils d'application, un basculement automatique peut se produire si un ou plusieurs clusters sont indisponibles.

  • Lorsque vous basculez manuellement d'un cluster à un autre, ou lorsque le cluster récepteur doit normalement disposer d'une capacité suffisante pour pour supporter la charge. Vous pouvez toujours allouer suffisamment de nœuds pour prendre en charge le basculement, ce qui peut être coûteux, ou vous pouvez vous fier à l'autoscaling pour ajouter des nœuds lorsque le trafic bascule, mais sachez qu'un impact bref sur les performances peut se produire pendant l'ajustement du cluster.

  • Si tous vos profils d'application utilisent un routage à cluster unique, chaque cluster peut avoir un nombre différent de nœuds. Redimensionnez chaque cluster en fonction de sa charge de travail.

    Comme Bigtable stocke une copie de vos données sur chaque cluster, chacun d'eux doit toujours disposer de suffisamment de nœuds pour couvrir l'espace disque utilisé et dupliquer les opérations d'écriture entre les clusters.

    Vous pouvez toujours basculer manuellement d'un cluster à un autre si nécessaire. Cependant, si un cluster a beaucoup plus de nœuds qu'un autre et que vous devez basculer vers celui comportant moins de nœuds, vous devrez peut-être commencer par ajouter des nœuds. Rien ne garantit que des nœuds supplémentaires seront disponibles au moment où vous aurez besoin d'effectuer un basculement. La seule façon de réserver des nœuds consiste à les ajouter à votre cluster.

Étape suivante