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 toujours utiliser des 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 disposant que d'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.

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 et limites répertoriées ci-dessous.

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

Usage du processeur

Bigtable enregistre les métriques d'utilisation du processeur suivantes :

Métrique Description
Utilisation moyenne du processeur

Utilisation moyenne du processeur sur tous les nœuds du cluster. Inclut l'activité des flux de modifications si un flux de modifications est activé pour une table de l'instance.

Les valeurs maximales recommandées fournissent une marge pour de brefs pics d'utilisation.

Si un cluster dépasse la valeur maximale recommandée pour votre configuration pendant plus de quelques minutes, ajoutez des nœuds au cluster.

Utilisation du processeur du nœud le plus sollicité

Utilisation du processeur pour le nœud le plus actif dans le cluster. Cette métrique continue d'être fournie pour la continuité, mais dans la plupart des cas, vous devez utiliser la métrique plus précise utilisation précise du processeur du nœud le plus sollicité.

Utilisation précise du processeur du nœud le plus sollicité

Mesure précise de l'utilisation du processeur pour le nœud le plus actif dans le cluster. Nous vous recommandons d'utiliser cette métrique plutôt que l'utilisation du processeur du nœud le plus sollicité, car elle est plus précise.

Le nœud le plus sollicité n'est pas nécessairement le même nœud au fil du temps et peut changer rapidement, en particulier lors des tâches par lot volumineuses ou des analyses de table.

Si le nœud le plus sollicité est souvent au-dessus de la valeur recommandée, même si l'utilisation moyenne du processeur est raisonnable, il se peut que vous accédiez à une petite partie de vos données plus souvent qu'au reste de vos données.

  • Utilisez l'outil Key Visualizer pour identifier les points d'accès de votre table susceptibles de causer des pics d'utilisation du processeur.
  • Vérifiez la conception du schéma pour vous assurer qu'il accepte la répartition uniforme des opérations de lecture et d'écriture sur chaque table.
Utilisation du processeur dans les flux de modifications

Utilisation moyenne du processeur due à l'activité des flux de modification sur tous les nœuds du cluster.

Utilisation du processeur par profil d'application, méthode et table

Utilisation du processeur par profil d'application, méthode et table.

Si vous observez une utilisation du processeur plus élevée que prévu pour un cluster, utilisez cette métrique pour déterminer si l'utilisation du processeur par un profil d'application, une méthode API ou une table spécifique est à l'origine de la charge du processeur.

Les valeurs de ces métriques ne doivent pas dépasser les valeurs suivantes:

Configuration Valeurs maximales recommandées1
  1. Les valeurs maximales recommandées s'appliquent à l'ensemble d'un cluster. Il n'existe aucune valeur maximale recommandée pour l'utilisation du processeur par profil d'application, méthode ou table. Utilisez cette métrique plus précise pour observer les causes possibles de l'utilisation élevée du processeur par un cluster.
  2. Les valeurs maximales recommandées garantissent qu'une instance dispose d'une capacité suffisante pour continuer à être diffusée avec une faible latence en cas de basculement. Par exemple, dans une instance composée de deux clusters, chaque cluster doit pouvoir gérer tout le trafic à 70% au cas où l'autre cluster deviendrait indisponible.
Routage à cluster unique, quel que soit le nombre de clusters

70% de l'utilisation moyenne du processeur
90% de l'utilisation du processeur pour le nœud le plus sollicité

Routage multicluster, autoscaling activé, 2 clusters ou plus

70% de l'utilisation moyenne du processeur
90% de l'utilisation du processeur pour le nœud le plus sollicité

Routage multicluster, autoscaling non activé, 2 clusters

35% de l'utilisation moyenne du processeur2
45% de l'utilisation du processeur pour le nœud le plus sollicité2

Routage multicluster, autoscaling non activé, 3 clusters ou plus

Dépend de votre configuration. Consultez la page Exemples de paramètres de réplication pour découvrir les cas d'utilisation courants.

Espace disque utilisé

Bigtable enregistre les métriques d'utilisation du disque suivantes :

Métrique Description
Utilisation du stockage (octets)

Quantité de données stockées dans le cluster. L'utilisation du flux modifié n'est pas incluse pour cette métrique.

Cette valeur affecte les coûts. En outre, comme décrit ci-dessous, vous aurez peut-être à ajouter des nœuds à chaque cluster au fur et à mesure de l'augmentation de la quantité de données.

Utilisation du stockage (% max.)

Pourcentage de la capacité de stockage du cluster qui est utilisée. La capacité est basée sur le nombre de nœuds présents dans le cluster. L'utilisation du flux modifié n'est pas incluse pour cette métrique.

En général, faites en sorte de ne pas utiliser plus de 70 % de la limite stricte de stockage total. Il restera ainsi de la place pour ajouter des données. Si vous ne prévoyez pas d'ajouter de grandes quantités de données à l'instance, vous pouvez utiliser jusqu'à 100 % de la limite stricte.

Si vous dépassez le pourcentage recommandé de la limite de stockage, ajoutez des nœuds au cluster. Vous pouvez également supprimer des données existantes, mais les données supprimées occupent non pas moins mais plus d'espace, jusqu'à ce qu'un compactage se produise.

Pour savoir comment cette valeur est calculée, consultez Utilisation du stockage par nœud.

Flux de modifications de l'utilisation du stockage (octets)

Quantité de stockage consommée par les enregistrements de flux de modifications pour les tables de l'instance. Celui-ci n'est pas pris en compte dans l'utilisation totale du stockage. Le stockage des flux de modifications vous est facturé, mais il n'est pas inclus dans le calcul de l'utilisation du stockage (% max.).

Charge du disque

Pourcentage de bande passante utilisé par votre cluster pour les lectures HDD par rapport à la bande passante maximale possible. Disponible uniquement pour les clusters HDD.

Si cette valeur est souvent égale à 100 %, vous risquez de rencontrer des taux de latence plus élevés. Ajoutez des nœuds au cluster pour réduire le pourcentage de charge du disque.

Nœuds pour les clusters dupliqués

Dans une instance qui utilise la réplication, assurez-vous que chaque cluster dispose de suffisamment de nœuds pour prendre en charge votre cas d'utilisation :

  • Si vous utilisez la réplication pour assurer une haute disponibilité ou si vous utilisez le routage multicluster dans l'un de vos profils d'application, chaque cluster doit avoir le même nombre de nœuds. En outre, comme indiqué ci-dessus dans la section Utilisation du processeur, l'utilisation recommandée du processeur est réduite de moitié.

    Cette configuration permet de s'assurer que si un basculement automatique est nécessaire, la capacité du cluster réactif est suffisante pour gérer tout votre trafic.

  • 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.

Étapes suivantes