Lors de la création d'un cluster Alibaba Cloud Elasticsearch, vous devez configurer les spécifications et le stockage pour les différents types de nœuds afin de répondre aux exigences de votre activité. Un cluster Elasticsearch se compose de nœuds de données, de nœuds Kibana, de nœuds maîtres dédiés, de nœuds warm, de nœuds frozen et de nœuds coordinators, chacun ayant des responsabilités distinctes.
Nœud de données
Les nœuds de données stockent les données d'index et exécutent les opérations d'indexation, de recherche et d'agrégation. Ces nœuds présentent des exigences élevées en matière de CPU, de mémoire et d'I/O. Si les ressources sont insuffisantes, nous vous recommandons d'ajouter de nouveaux nœuds de données à votre cluster.
Si un cluster dispose de nœuds maîtres dédiés, les nœuds de données fonctionnent uniquement en tant que nœuds de données.
Si un cluster ne dispose pas de nœuds maîtres dédiés, les nœuds de données servent à la fois de nœuds de données et de nœuds maîtres dédiés.
Les clusters Alibaba Cloud Elasticsearch utilisent l'une des deux architectures de plan de contrôle suivantes : un plan de contrôle basique (v2) ou un plan de contrôle cloud-native (v3). Dans l'architecture v2, la mise à l'échelle verticale d'un cluster dépourvu de nœuds maîtres dédiés déclenche un redémarrage du cluster. Si la charge globale du cluster est faible et que vos index possèdent des shards répliqués, le cluster peut rester disponible pendant le redémarrage. Toutefois, dans certains scénarios, tels que des charges d'écriture et de requête élevées, des délais d'expiration d'accès peuvent survenir lors du redémarrage. Par conséquent, nous vous recommandons d'effectuer ces opérations pendant les heures creuses.
|
Paramètre |
Description |
|
Spécifications des nœuds de données |
Nous vous recommandons d'utiliser des nœuds de données avec 2 vCPU et 4 Go de mémoire dans les environnements de test, et des nœuds de données avec des spécifications supérieures dans les environnements de production. |
|
Type de disque des nœuds de données |
Remarque
|
|
Niveau de performance ESSD |
Si vous définissez le paramètre Type de disque des nœuds de données sur ESSD, vous devez configurer ce paramètre. |
|
Chiffrement du disque des nœuds de données |
|
|
Espace de stockage par nœud de données |
L'espace de stockage de chaque nœud de données dépend du type de disque. Unité : Go.
Remarque
Lorsque vous redimensionnez un Ultra Disk dont l'espace de stockage est supérieur à 2 560 Go, seule une mise à jour blue-green peut être effectuée pour le disque, car celui-ci est conçu pour fonctionner dans des baies de disques ou en RAID 0. |
|
Nombre de nœuds de données |
Le nombre de nœuds que vous achetez doit être un multiple du nombre de zones. Important
Un cluster contenant seulement deux nœuds de données présente des risques élevés de split-brain et offre une stabilité faible. Si un cluster d'une version antérieure, telle que V6.X ou V5.X, contient seulement deux nœuds de données, un nœud maître dédié peut ne pas être sélectionné si un redémarrage de nœud est nécessaire, et le cluster peut cesser de fournir des services. Par conséquent, vous devez configurer ce paramètre en fonction des besoins de votre activité. |
Nœud Kibana
La valeur du paramètre Nœud Kibana ne peut être que Oui.
Un nœud Kibana doté de 1 vCPU et de 2 Go de mémoire est gratuit. Toutefois, nous vous recommandons d'utiliser le nœud Kibana avec 1 vCPU et 2 Go de mémoire uniquement à des fins de test.
En raison de l'impact sur les performances et la stabilité du cluster, nous vous recommandons d'acheter un nœud Kibana disposant d'au moins 2 vCPU et 4 Go de mémoire, ou de spécifications supérieures.
Nœud maître dédié
Vous pouvez utiliser des nœuds maîtres dédiés pour effectuer des opérations sur les clusters, telles que la création d'index, la suppression d'index, le suivi des nœuds et l'allocation des shards. La stabilité des nœuds maîtres dédiés est cruciale pour la santé des clusters. Par défaut, chaque nœud d'un cluster peut être utilisé comme nœud maître dédié. Les opérations telles que l'indexation des données, les recherches et les requêtes nécessitent un grand nombre de ressources CPU, mémoire et I/O. Afin de garantir la stabilité d'un cluster, nous vous recommandons d'acheter des nœuds maîtres dédiés pour séparer les nœuds maîtres dédiés des nœuds de données.
Si les nœuds maîtres dédiés de votre cluster sont gratuits, vous serez facturé pour ces nœuds après la mise à niveau de la configuration du cluster.
Si vous effectuez un changement blue-green pour un cluster qui ne contient pas de nœuds maîtres dédiés et qui est déployé dans l'ancienne architecture (V2), les nœuds de données seront redémarrés la prochaine fois que vous effectuerez une modification sur le cluster. Par conséquent, nous vous recommandons d'acheter des nœuds maîtres dédiés.
|
Paramètre |
Description |
|
Nœud maître dédié |
Remarque
|
|
Spécifications des nœuds maîtres dédiés |
Vous pouvez consulter les spécifications prises en charge sur la page d'achat. |
|
Type de disque des nœuds maîtres dédiés |
Vous pouvez consulter les types de disques pris en charge sur la page d'achat. |
|
Espace de stockage des nœuds maîtres dédiés |
La valeur de ce paramètre ne peut être que 20 Go. |
|
Nombre de nœuds maîtres dédiés |
La valeur de ce paramètre ne peut être que 3. |
Nœud warm
Si votre charge de travail implique les deux types de données suivants, nous vous recommandons d'utiliser une architecture hot-warm, combinant des nœuds hot hautes performances avec des nœuds warm de grande capacité :
Données hot : Index fréquemment interrogés, soumis à des charges d'écriture élevées et sensibles à la latence.
Données warm : Index rarement interrogés, principalement en lecture seule ou faisant l'objet d'écritures minimes. Il s'agit généralement de données historiques.
En déployant les données hot et warm sur différents types de nœuds, vous évitez que la contention des ressources causée par les données warm n'affecte les performances des données hot, réduisez considérablement les coûts de stockage et améliorez l'efficacité et la stabilité globales du cluster.
Pour plus d'informations, consultez Architecture « Hot-Warm » dans Elasticsearch 5.x (https://www.elastic.co/cn/blog/hot-warm-architecture-in-elasticsearch-5-x).
Si des nœuds maîtres dédiés sont achetés, les nœuds warm sont utilisés uniquement en tant que nœuds warm.
Si aucun nœud maître dédié n'est acheté, les nœuds warm servent également de nœuds maîtres dédiés.
|
Paramètre |
Description |
|
Nœud warm |
Vous pouvez désactiver les nœuds warm achetés. Si le cluster se bloque lors de la désactivation d'un nœud warm, consultez Que faire si un cluster se bloque après la désactivation d'un nœud warm ? |
|
Spécifications des nœuds warm |
Pour obtenir des informations sur les spécifications prises en charge, consultez la page d'achat. Pour les scénarios nécessitant des I/O élevés et un grand espace de stockage, vous pouvez également utiliser des types d'instance à disque local économiques, tels que le type d'instance
Remarque
|
|
Type de disque des nœuds warm |
Ultra Disk et ESSD sont pris en charge. |
|
Chiffrement du disque des nœuds warm |
Remarque
|
|
Espace de stockage des nœuds warm |
La valeur minimale de ce paramètre est 500. Unité : Go. |
|
Nombre de nœuds warm |
Le nombre de nœuds que vous achetez doit être un multiple du nombre de zones. |
Après l'achat de nœuds warm, le système ajoute le paramètre -Enode.attr.box_type aux paramètres de démarrage du nœud, comme indiqué dans le tableau suivant.
|
Type de nœud |
Paramètre de démarrage |
|
Nœud de données |
-Enode.attr.box_type=hot |
|
Nœud warm |
-Enode.attr.box_type=warm |
Nœuds frozen
Un nœud frozen constitue la couche de calcul pour la fonctionnalité Searchable Snapshot. Il conserve les métadonnées d'index, gère un cache partagé local et extrait les blocs de données requis depuis Object Storage Service (OSS) à la demande pour les requêtes. En stockant les données historiques sous forme de snapshots dans Alibaba Cloud OSS, les nœuds frozen permettent de réduire les coûts de stockage jusqu'à 90 % tout en conservant les capacités de recherche.
Les nœuds frozen sont pris en charge uniquement pour les instances V8.17.0 et versions ultérieures. Une fois les nœuds frozen activés, vous ne pouvez pas les désactiver. Pour les désactiver, contactez le support technique.
Les nœuds frozen ne nécessitent pas de disques locaux de grande capacité, car les données sont stockées dans OSS. Nous vous recommandons de configurer une mémoire suffisante pour améliorer le taux de succès du cache.
Pour des exemples détaillés, consultez Searchable Snapshot.
|
Paramètre |
Description |
|
Nœud frozen |
Lors de l'achat d'une nouvelle instance V8.17.0, vous pouvez cocher la case dans la section des spécifications de l'instance pour activer cette fonctionnalité. |
|
Spécifications des nœuds frozen |
Nous vous recommandons un type d'instance disposant d'au moins 4 vCPU et 16 Go de mémoire. La mémoire d'un nœud frozen conserve les métadonnées d'index et gère le cache partagé. Une mémoire suffisante permet d'améliorer le taux de succès du cache. Pour obtenir des informations sur les spécifications prises en charge, consultez la page d'achat. |
|
Type de disque des nœuds frozen |
Ultra Disk et ESSD sont pris en charge. Les disques locaux servent uniquement de cache partagé, et les données sont persistées dans OSS. |
|
Espace de stockage des nœuds frozen |
Nous vous recommandons 500 Go ou plus. L'espace disque local sert de cache partagé. Le cache utilise 90 % de l'espace disque total d'un nœud ou l'espace total moins 100 Go, selon la valeur la plus faible. Une politique LRU (Least Recently Used) évince les blocs de données froids. Plus l'espace disque est important, plus le taux de succès du cache est élevé. |
|
Nombre de nœuds frozen |
Le nombre de nœuds que vous achetez doit être un multiple du nombre de zones de disponibilité. |
Après l'achat de nœuds frozen, le système ajoute le paramètre -Enode.attr.box_type aux paramètres de démarrage du nœud, comme indiqué dans le tableau suivant.
|
Type de nœud |
Paramètre de démarrage |
|
nœud de données |
-Enode.attr.box_type=hot |
|
nœud warm |
-Enode.attr.box_type=warm |
|
nœud frozen |
-Enode.attr.box_type=frozen |
Nœud client
Vous pouvez acheter des nœuds clients pour partager la charge CPU des nœuds de données. Cela améliore les performances de traitement et la stabilité des services d'un cluster. Pour les services gourmands en CPU, tels que ceux nécessitant un grand nombre de requêtes d'agrégation, nous vous recommandons d'acheter des nœuds clients.
|
Paramètre |
Description |
|
Nœud coordinator |
Vous ne pouvez pas libérer les nœuds clients que vous avez achetés pour un cluster déployé dans l'architecture de contrôle cloud-native (un cluster V7.16 ou ultérieur). Vous pouvez vérifier sur la page d'achat si vous pouvez libérer les nœuds clients de votre cluster. |
|
Spécifications des nœuds coordinators |
Vous pouvez consulter les spécifications prises en charge sur la page d'achat. |
|
Type de disque des nœuds coordinators |
La valeur de ce paramètre ne peut être que Ultra Disk. |
|
Espace de stockage des nœuds coordinators |
La valeur de ce paramètre ne peut être que 20 Go. |
|
Nombre de nœuds coordinators |
Le nombre de nœuds que vous achetez doit être un multiple du nombre de zones. |
Références
Pour plus d'informations sur l'achat d'un cluster Elasticsearch, consultez Créer un cluster Alibaba Cloud Elasticsearch.
Pour plus d'informations sur les nœuds, consultez Node | Elasticsearch Guide.
Pour plus d'informations sur la tarification des spécifications des nœuds, consultez Tarification.
FAQ
Cluster bloqué après la désactivation d'un nœud warm
1. Vérifiez les règles d'allocation des nœuds box_type
-
Interrogez le paramètre
index.routing.allocation.require.box_typepour tous les index existants.GET */_settings/index.routing.allocation.require.box_typeSi la sortie est
{"index.routing.allocation.require.box_type": "warm"}, l'index doit être alloué aux nœuds oùbox_type=warm. -
Vérifiez si une règle d'allocation
box_typeest configurée dans l'un des modèles d'index.Interrogez tous les modèles d'index pour vérifier si une règle d'allocation
box_typeest configurée. Si un modèle renvoie"index.routing.allocation.require.box_type": "warm", tous les nouveaux indices sont alloués par défaut aux nœuds warm.Lorsqu'un nouvel index est créé, il hérite de la configuration du modèle. Si cette valeur est définie dans le modèle, tous les indices suivants appliquent automatiquement cette règle.
-
GET _ilm/policy?filter_path=*.policy.phases.warm.actions.allocate.require.box_typeInterroge la configuration d'allocation des nœuds pour la phase warm de toutes les politiques Index Lifecycle Management (ILM).
Si un index est alloué à un nœud warm, l'arrêt des nœuds de données cold en effectuant une opération de réduction d'échelle entraînera le blocage de la modification du cluster avec le statut Change is blocked :
2. Solution
-
Supprimez la configuration
box_typede la politique# First, stop ILM. POST _ilm/stop # View the specific ILM policy. GET _ilm/policy/your_policy_name # Update the ILM policy and remove the box_type configuration from the warm phase. PUT _ilm/policy/your_policy_name { "policy": { "phases": { "warm": { "actions": { "allocate": { "require": { "box_type": null # Remove this configuration. } } } }, "hot": { "actions": { "allocate": { "require": { "box_type": null # If present, remove this as well. } } } } } } } # If the require field under allocate is empty, delete the entire allocate action. # Alternatively, retain only other necessary allocation rules, such as the number of replicas. -
Supprimez la configuration
box_typedu modèle d'index# View the specific template name. GET _template/?filter_path=*.settings.index.routing.allocation.require.box_type # Update the template and remove the box_type configuration. PUT _template/your_template_name { "settings": { "index.routing.allocation.require.box_type": null } } # Alternatively, resubmit the complete template definition without the box_type field. -
Supprimez la configuration
box_typede l'index# Remove the box_type configuration for a specific index. PUT /your_index_name/_settings { "index.routing.allocation.require.box_type": null } # Remove the configuration for all indexes in a batch. { "index.routing.allocation.require.box_type": null }