Shards et répliques Elasticsearch : Un guide pratique

Vous débutez avec Elasticsearch ? Participez à notre webinaire Premiers pas avec Elasticsearch. Vous pouvez aussi démarrer un essai gratuit sur le cloud ou tester Elastic dès maintenant sur votre machine.

Elasticsearch renforce la puissance de Lucene en construisant un système distribué au-dessus de celui-ci, qui répond aux problèmes d'évolutivité et de tolérance aux pannes. Il expose également une API REST basée sur JSON, ce qui rend l'interopérabilité avec d'autres systèmes très simple.

Les systèmes distribués comme Elasticsearch peuvent être très complexes, avec de nombreux facteurs qui peuvent affecter leurs performances et leur stabilité. Les Shards font partie des concepts les plus fondamentaux d'Elasticsearch, et la compréhension de leur fonctionnement vous permettra de gérer efficacement un cluster Elasticsearch.

Cet article explique ce qu'est un serveur primaire et un serveur réplique, leur impact sur un cluster Elasticsearch et les outils qui permettent de les adapter à des besoins différents.

Comprendre les tessons

Les données contenues dans un index Elasticsearch peuvent prendre des proportions considérables. Afin de rester gérable, chaque donnée est conservée dans un index, et les index sont un index divisé en un certain nombre de morceaux. Chaque tesson Elasticsearch est un index Apache Lucene, chaque index Lucene individuel contenant un sous-ensemble des documents de l'index Elasticsearch. Le fractionnement des indices de cette manière permet de contrôler l'utilisation des ressources. Un index Apache Lucene a une limite de 2 147 483 519 (2³¹ - 129) documents.

Parfois, les indices doivent être déplacés d'un nœud à l'autre à des fins de rééquilibrage. Étant donné que ce processus peut être à la fois long et coûteux en ressources, les indices ne doivent pas devenir trop volumineux, ce qui permet de maintenir le temps de récupération à un niveau raisonnable. En outre, comme les indices sont composés de segments Lucene qui doivent être constamment fusionnés, il est important que les segments ne deviennent pas trop grands. Pour ces raisons, Elasticsearch divise les données d'index en morceaux plus petits et plus faciles à gérer, appelés shards primaires, qui peuvent être plus facilement distribués sur un certain nombre de machines. Les shards répliqués sont simplement une copie exacte d'un shard primaire correspondant et nous verrons leur fonction plus loin dans cet article.

Il est important de disposer d'un nombre adéquat de fragments pour garantir les performances. Il est donc judicieux de planifier à l'avance. Lorsque les requêtes sont exécutées en parallèle sur différents nuages, elles s'exécutent plus rapidement qu'un index composé d'un seul nuage, mais uniquement si chaque nuage est situé sur un nœud différent et s'il y a suffisamment de nœuds dans la grappe. En même temps, cependant, les ensembles consomment de la mémoire et de l'espace disque, à la fois en termes de données indexées et de métadonnées de grappe. Le fait d'avoir un trop grand nombre de shards (également appelé oversharding) peut ralentir les requêtes, les demandes d'indexation et les opérations de gestion, c'est pourquoi il est essentiel de maintenir un bon équilibre.

Le nombre de groupes primaires est défini au moment de la création de l'index pour cette instance d'index spécifique. Si vous avez besoin ultérieurement d'un nombre différent d'unités primaires, vous pouvez utiliser les API de redimensionnement :division(plus d'unitésprimaires), réduction (moins d'unités primaires) ou clonage (le même nombre d'unités primaires avec de nouveaux paramètres pour les réplicas). Ces opérations copient des segments Lucene et évitent une réindexation complète de tous les documents. Lors de la création d'un index, vous pouvez définir le nombre de shards primaires et de shards répliqués comme paramètres de l'index :

(Si vous ne spécifiez pas le nombre de shards ou de répliques, la valeur par défaut est 1, à partir d'Elasticsearch 7.0). Le nombre idéal d'unités de stockage doit être déterminé en fonction de la quantité de données contenues dans un index. En règle générale, un fonds optimal doit contenir de 10 à 50 Go de données, avec moins de 200 millions de documents par fonds. Par exemple, si vous prévoyez d'accumuler environ 300 Go de journaux d'application par jour, il serait raisonnable d'avoir environ 10 fichiers dans cet index, à condition que vous disposiez d'un nombre suffisant de nœuds pour les héberger.

Au cours de leur vie, les tessons peuvent passer par un certain nombre d'états, notamment

• Initialisation : Un état initial avant que le tesson puisse être utilisé.
• Démarré : État dans lequel le groupe de stockage est actif et peut recevoir des demandes.
• Relocalisation : Un état qui se produit lorsque les shards sont en train d'être déplacés vers un autre nœud. Cela peut s'avérer nécessaire dans certaines conditions, par exemple lorsque le nœud sur lequel ils se trouvent manque d'espace disque.
• Non assigné : État d'un tesson qui n'a pas été affecté. Une raison est fournie lorsque cela se produit, par exemple, si le nœud hébergeant le dépôt n'est plus dans le cluster (NODE_LEFT) ou en raison d'une restauration dans un index fermé (EXISTING_INDEX_RESTORED).

Pour afficher tous les shards, leur état et d'autres métadonnées, vous pouvez utiliser la requête suivante :

Pour visualiser les dépôts d'un index spécifique, vous pouvez ajouter le nom de l'index à l'URL, par exemple, sensor :

Cette commande produit une sortie, comme dans l'exemple suivant. Par défaut, les colonnes affichées comprennent le nom de l'index, le nom (i.e. ) du dépôt, s'il s'agit d'un dépôt primaire ou d'une réplique, son état, le nombre de documents, la taille sur le disque, ainsi que l'adresse IP et l'ID du nœud où se trouve le dépôt.

Comprendre les répliques

Alors que chaque nuage contient une seule copie des données, un index peut contenir plusieurs copies du nuage. Il y a donc deux types de tessons, le tesson primaire et une copie, ou réplique. Chaque réplique d'un groupe de données primaire est toujours située sur un nœud différent, ce qui garantit la haute disponibilité de vos données en cas de défaillance d'un nœud. Outre la redondance et leur rôle dans la prévention des pertes de données et des temps d'arrêt, les répliques peuvent également contribuer à améliorer les performances de recherche en permettant aux requêtes d'être traitées en parallèle avec le shard principal, et donc plus rapidement.

Il existe des différences importantes dans la manière dont se comportent les disques primaires et les disques répliques. Bien qu'ils soient tous deux capables de traiter les requêtes, les demandes d'indexation (c.-à-d. les demandes d'accès à la base de données) ne sont pas traitées. l'ajout de données à l'index) doivent d'abord passer par les disques primaires avant d'être répliqués dans les disques répliques. Comme nous l'avons vu plus haut, si un shard primaire devient indisponible, par exemple en raison d'une déconnexion de nœud ou d'une défaillance matérielle, un réplica est promu pour reprendre son rôle.

Si les répliques peuvent être utiles en cas de défaillance d'un nœud, il est important de ne pas en avoir trop, car elles consomment de la mémoire, de l'espace disque et de la puissance de calcul lors de l'indexation. Une autre différence entre les shards primaires et les réplicas est que le nombre de shards primaires ne peut pas être modifié après la création de l'index, alors que le nombre de réplicas peut être modifié dynamiquement à tout moment en mettant à jour les paramètres de l'index.

Un autre facteur à prendre en compte pour les répliques est le nombre de nœuds disponibles. Les répliques sont toujours placées sur des nœuds différents de ceux du groupe principal, car deux copies des mêmes données sur le même nœud n'offriraient aucune protection en cas de défaillance de ce nœud. Par conséquent, pour qu'un système prenne en charge n répliques, il doit y avoir au moins n + 1 nœuds dans la grappe. Par exemple, s'il y a deux nœuds dans un cluster et qu'un index est configuré avec six répliques, une seule réplique sera allouée. En revanche, un système à sept nœuds est parfaitement capable de gérer un shard primaire et six répliques.

Optimisation des grappes et des répliques

Même après la création d'un index avec le bon équilibre entre les unités primaires et les unités répliquées, celles-ci doivent être surveillées, car la dynamique autour d'un index évolue au fil du temps. Par exemple, lorsqu'il s'agit de séries chronologiques, les indices contenant des données récentes sont généralement plus actifs que les indices plus anciens. Sans réglage de ces indices, ils consommeraient tous la même quantité de ressources, malgré leurs exigences très différentes.

L'API de l'indice de reconduction peut être utilisée pour séparer les indices les plus récents des plus anciens. Il peut être configuré pour créer automatiquement un nouvel index lorsqu'un certain seuil - taille d'un index sur le disque, nombre de documents ou âge - est atteint. Cette API est également utile pour contrôler la taille des fichiers. Étant donné que le nombre de groupes ne peut pas être facilement modifié après la création de l'index, les groupes continueront d'accumuler des données si aucune condition de transfert n'est remplie. Pour les index plus anciens qui ne nécessitent que des accès peu fréquents, le rétrécissement et la fusion forcée d'un index sont deux moyens différents de réduire leur empreinte mémoire et disque. La première permet de réduire le nombre d'unités dans un index, tandis que la seconde réduit le nombre de segments Lucene et libère l'espace utilisé par les documents qui ont été supprimés.

Shards primaires et répliques comme base d'Elasticsearch

Elasticsearch s'est forgé une solide réputation en tant que plateforme distribuée de stockage, de recherche et d'analyse pour d'énormes volumes de données. Toutefois, à une telle échelle, des problèmes se posent inévitablement. C'est pourquoi il est si important et fondamental pour Elasticsearch de comprendre le fonctionnement des shards primaires et répliqués, car cela permet d'optimiser la fiabilité et les performances de la plateforme.

Il est essentiel de savoir comment ils fonctionnent et comment les optimiser pour obtenir un cluster Elasticsearch plus robuste et plus performant. Si vous rencontrez régulièrement des réponses lentes aux requêtes ou des pannes, ces connaissances peuvent être la clé pour surmonter ces obstacles.

Suivez la documentation officielle d'Elasticsearch pour en savoir plus sur les clusters, les nœuds et les shards, sur la taille des shards, sur l 'allocation des shards et sur la récupération.

Ce sujet est également disponible sous forme de cours d'introduction sur la chaîne YouTube de la communauté Elastic.

Enfin, si vous ne voulez pas vous préoccuper des nœuds, des unités de stockage ou des répliques, vous pouvez essayer Elastic Cloud Serverless. Cette offre Elastic Cloud est entièrement gérée par Elastic et automatisée pour évoluer avec votre charge de travail. Un essai gratuit peut vous aider à vous familiariser avec d'autres avantages de l'approche sans serveur.