Chapitre 9. Mise à l’échelle (Scaling out)

Ce chapitre couvre

Ajout de nœuds à votre cluster Elasticsearch
Choix du noeud master dans votre cluster Elasticsearch
Retrait et mise hors service des nœuds
Utilisation de l’API _cat pour comprendre votre cluster
Stratégies de planification et de mise à l’échelle (Scaling out)
Alias et routage personnalisé

Maintenant que vous avez une bonne idée de ce dont Elasticsearch est capable, vous êtes prêt à entendre parler de la prochaine fonctionnalité phare d’Elasticsearch: la possibilité de redimensionner (scaler), c’est-à-dire de pouvoir gérer davantage d’indexation et de recherche au fur et à mesure que la charge augmente. De nos jours, la mise à l’échelle est un facteur important lorsqu’il s’agit de millions ou de milliards de documents. Vous ne pourrez pas toujours supporter la quantité de trafic que vous souhaitez sur une seule instance en cours d’exécution d’Elasticsearch, sans mise à l’échelle sous une forme ou une autre. Heureusement, Elasticsearch est facilement adaptable. Dans ce chapitre, nous examinerons les capacités de dimensionnement dont dispose Elasticsearch et comment vous pouvez les utiliser pour améliorer les performances et obtenir plus de fiabilité.

Après avoir déjà vu comment Elasticsearch traite les données de rencontre que nous avons présentées aux chapitres 2 et 3, nous sommes maintenant prêts à discuter de la façon d’adapter votre système de recherche à la gestion de tout le trafic que vous pouvez lui envoyer. Imaginez que vous êtes assis dans votre bureau et que votre patron annonce que votre site a été présenté dans le magazine Wired comme le nouveau site à la mode que tout le monde devrait utiliser pour réserver des rencontres sociales. Votre travail: assurez-vous qu’Elasticsearch puisse gerer l’afflux de nouveaux groupes et événements, ainsi que toutes les nouvelles recherches attendues sur le site une fois l’article de Wired publié! Vous avez 24 heures. Comment allez-vous étendre votre serveur Elasticsearch pour gérer ce trafic dans cette période? Heureusement, Elasticsearch facilite la mise à l’échelle en ajoutant des nœuds à votre cluster Elasticsearch existant.

9.1. AJOUT DE NŒUDS À VOTRE CLUSTER ÉLASTICSEARCH

Même si vous ne vous retrouvez pas dans une situation de travail semblable à celle que nous venons de décrire, au cours de votre expérimentation avec Elasticsearch, vous arriverez tôt ou tard au point où vous aurez besoin d’augmenter la puissance de traitement de votre cluster Elasticsearch.

Vous devez pouvoir rechercher et indexer les données dans vos index plus rapidement, avec plus de parallélisation; votre ordinateur manque d’espace disque ou le nœud Elasticsearch manque peut-être de mémoire lorsqu’il effectue des requêtes sur vos données. Dans ces cas, le moyen le plus simple d’améliorer les performances de votre nœud Elasticsearch consiste généralement à le transformer en un cluster Elasticsearch en ajoutant plusieurs nœuds, ce que vous avez appris à connaître au chapitre 2. Elasticsearch facilite la mise à l’échelle horizontale en ajoutant des nœuds à votre cluster. afin qu’ils puissent partager la charge de travail d’indexation et de recherche. En ajoutant des nœuds à votre cluster Elasticsearch, vous pourrez bientôt gérer l’indexation et la recherche parmi des millions de groupes et d’événements.

9.1.1. Ajout de nœuds à votre cluster

La première étape de la création d’un cluster Elasticsearch consiste à ajouter un autre nœud (ou nœuds) au nœud unique pour en faire un cluster de 2 nœuds. L’ajout d’un noeud à votre environnement de développement local est aussi simple que d’extraire la distribution Elasticsearch dans un répertoire distinct, de le saisir et d’exécuter la commande bin / elasticsearch, comme le montre l’extrait de code suivant. Elasticsearch choisira automatiquement le prochain port disponible (dans ce cas, 9201) et rejoindra automatiquement le nœud existant comme par magie! Si vous voulez aller plus loin, il n’est même pas nécessaire d’extraire la distribution d’Elasticsearch; Plusieurs instances d’Elasticsearch peuvent être exécutées à partir du même répertoire sans interférer les unes avec les autres:

Maintenant que vous avez ajouté un deuxième nœud Elasticsearch au cluster, vous pouvez exécuter la commande health à partir de l’endroit précédent et voir comment l’état du cluster a changé, comme indiqué dans la figure suivante.

Il n’y a maintenant plus de fragments non attribués dans ce cluster, comme vous pouvez le constater avec le compte unassigned_shards qui est zéro. Comment exactement les fragments se sont-ils retrouvés sur l’autre noeud? Examinez la figure 9.1 et voyez ce qu’il advient de l’index de test avant et après l’ajout d’un nœud au cluster. Sur le côté gauche, les fragments primaires pour l’index de test ont tous été affectés à Node1, tandis que les fragments de réplica ne sont pas attribués. Dans cet état, le cluster est jaune car tous les fragments primaires ont une maison, mais pas les répliques. Une fois qu’un deuxième nœud est ajouté, les fragments de répliques non attribués sont affectés au nouveau nœud Node2, ce qui entraîne le passage du cluster à l’état vert.

Lorsqu’un autre nœud est ajouté, Elasticsearch essaiera automatiquement d’équilibrer les fragments entre tous les nœuds. La figure 9.2 montre comment les mêmes fragments sont répartis sur trois nœuds Elasticsearch dans le même cluster. Notez qu’il n’existe aucune interdiction d’avoir des fragments primaires et de répliques sur le même noeud tant que les fragments primaires et de répliques d’un même numéro ne sont pas sur le même noeud.

Si un nombre encore plus grand de noeuds sont ajoutés à ce cluster, Elasticsearch tentera d’équilibrer le nombre de fragments entre eux de manière uniforme, car chaque noeud ajouté de cette manière partage la charge en prenant une partie des données (sous forme de fragments). Félicitations, vous venez de mettre à l’échelle horizontalement votre cluster Elasticsearch!

L’ajout de nœuds à votre cluster Elasticsearch apporte des avantages substantiels, le principal étant la haute disponibilité et des performances accrues. Lorsque les répliques sont activées (ce qui est le cas par défaut), Elasticsearch promeut automatiquement un fragment de réplique en fragment principal si le fragment principal ne peut pas être localisé. Ainsi, même si vous perdez le noeud où se trouvent les fragments principaux de votre index, vous pourrez toujours accéder aux données de vos index. Cette répartition des données entre les nœuds augmente également les performances, car les requêtes de recherche et d’extraction peuvent être traitées à la fois par des fragments primaires et des fragments de répliques, comme vous le rappellerez à la figure 2.9. Cette mise à l’échelle ajoute également plus de mémoire au cluster dans son ensemble. Ainsi, si les recherches et les agrégations gourmandes en mémoire prennent trop de temps ou entraînent un manque de mémoire, l’ajout de nœuds supplémentaires est presque toujours un moyen facile de gérer davantage de opérations complexes.

Maintenant que vous avez transformé votre nœud Elasticsearch en un véritable cluster en ajoutant un nœud, vous vous demandez peut-être comment chaque nœud a pu découvrir et communiquer avec le ou les autres nœuds. Dans la section suivante, nous parlerons des méthodes de découverte de nœuds d’Elasticsearch.

9.2. DÉCOUVERTE D’AUTRES NŒUDS ELASTICSEARCH

Vous vous demandez peut-être exactement comment le deuxième nœud que vous avez ajouté à votre cluster a découvert le premier nœud et a automatiquement rejoint le cluster. Les noeuds Elasticsearch peuvent utiliser deux méthodes différentes pour se découvrir: multidiffusion ou monodiffusion. Elasticsearch peut utiliser les deux à la fois, mais est configuré par défaut pour n’utiliser que la multidiffusion, car la monodiffusion nécessite une liste de noeuds connus auxquels se connecter.

9.2.1. Découverte multicast

Lorsque Elasticsearch démarre, il envoie un ping multicast à l’adresse 224.2.2.4 sur le port 54328, auquel répondent d’autres nœuds Elasticsearch portant le même nom de cluster. Par conséquent, si vous remarquez que la copie locale d’Elasticsearch exécutée par votre collègue et rejoignant votre cluster, veillez à modifier le paramètre cluster.name dans votre fichier de configuration elasticsearch.yml, du nom par défaut elasticsearch à un nom plus spécifique. La découverte en multidiffusion comporte quelques options que vous pouvez modifier ou désactiver entièrement en définissant les options suivantes dans elasticsearch.yml, affichées avec leurs valeurs par défaut:

En règle générale, la découverte par multidiffusion est une option décente lorsque vous utilisez des clusters très flexibles sur le même réseau, où l’adresse IP des nœuds ajoutés est fréquemment modifiée. Pensez à la découverte par multidiffusion comme si vous criiez«Hé, y at-il d’autres noeuds exécutant un cluster Elasticsearch nommé« xyz »?» Et attendant une réponse. La figure 9.3 montre à quoi ressemble la découverte par multidiffusion.

Bien que la découverte par multidiffusion soit idéale pour le développement local et pour un test rapide de validation du concept, lors du développement d’un cluster de production, Elasticsearch découvre de manière plus stable les autres nœuds en utilisant tout ou une partie des nœuds comme «routeurs de commérages» afin d’obtenir plus d’informations sur le cluster. Cela peut éviter que des nœuds ne se connectent accidentellement à un cluster lorsqu’un autre ordinateur portable est connecté au même réseau. Unicast permet de lutter contre cela en n’envoyant pas de message à tous les ordinateurs du réseau, mais uniquement à une liste spécifique de nœuds.

9.2.2. Découverte unicast

La découverte par monodiffusion utilise une liste d’hôtes sur laquelle Elasticsearch se connecte et tente de trouver plus d’informations sur le cluster. Ceci est idéal pour les cas où l’adresse IP du noeud ne change pas fréquemment ou pour les systèmes Elasticsearch de production où seuls certains noeuds sont autorisés à communiqués avec et non avec tout le réseau entier. Unicast est utilisé en indiquant à Elasticsearch l’adresse IP et, éventuellement, le port ou la plage de ports des autres nœuds du cluster. Un exemple de configuration unicast serait de définir discovery.zen.ping.unicast.hosts: [« 10.0.0.3 », « 10.0.0.4:9300 », « 10.0.0.5 [9300-9400] »] dans elasticsearch.yml pour les nœuds Elasticsearch sur votre réseau. Il n’est pas nécessaire que tous les nœuds Elasticsearch du cluster soient présents dans la liste unicast pour détecter tous les nœuds, mais vous devez configurer un nombre suffisant d’adresses pour que chaque nœud connaisse un nœud de « commérage » (gossip) disponible. Par exemple, si le premier nœud de la liste unicast connaît environ trois nœuds sur sept dans un cluster et que le second nœud de la liste unicast connaît les quatre autres nœuds, le nœud effectuant la découverte sera toujours en mesure de pouvoir trouver les sept nœuds du cluster. La figure 9.4 présente une représentation graphique de la découverte unicast.

Il n’est pas nécessaire de désactiver la découverte unicast. Si vous souhaitez utiliser uniquement la découverte par multidiffusion pour rechercher d’autres noeuds Elasticsearch, laissez la liste non définie (ou vide) dans le fichier de configuration. Après avoir découvert d’autres noeuds faisant partie du cluster, les noeuds Elasticsearch organiseront une élection du noeud master.

9.2.3. Choix d’un noeud master et détection de fautes

Une fois que les nœuds de votre cluster se sont découverts, ils négocient qui devient le maître. Le nœud maître est responsable de la gestion de l’état du cluster, c’est-à-dire des paramètres actuels et de l’état des fragments, des index et des nœuds du cluster. Une fois le nœud maître élu, il configure un système de pings internes pour s’assurer que chaque nœud reste en vie et en bonne santé dans le cluster. C’est ce qu’on appelle la détection des pannes, dont nous parlerons plus en détail à la fin de cette section. Elasticsearch considère que tous les nœuds sont susceptibles de devenir le nœud maître, sauf si le paramètre node.master est défini sur false. Dans ce chapitre, nous allons parler davantage de la raison pour laquelle vous pouvez définir le paramètre node.master, ainsi que des différents types de nœuds Elasticsearch, lorsque nous expliquerons comment accélérer les recherches. Si votre cluster ne comporte qu’un seul nœud, ce nœud se désignera lui-même comme maître après un certain délai s’il ne détecte aucun autre nœud dans le cluster.

Pour les clusters de production comportant plusieurs nœuds, il est judicieux de définir le nombre minimal de nœuds maîtres. Bien que ce paramètre puisse donner l’impression qu’Elasticsearch puisse avoir plusieurs noeuds maîtres, il indique à Elasticsearch combien de noeuds d’un cluster doivent être éligibles pour devenir maîtres avant que le cluster ne soit en bon état. Définir le nombre minimum de nœuds maîtres éligibles peut être utile pour vous assurer que votre cluster n’essaye pas d’exécuter des opérations potentiellement dangereuses sans avoir au préalable une vue complète de l’état de votre cluster. Vous pouvez définir le nombre minimal correspondant au nombre total de nœuds de votre cluster si le nombre de nœuds ne change pas dans le temps ou le définir selon une règle commune, à savoir le nombre de nœuds de votre cluster divisé par 2, plus. 1. Définir le paramètre minimum_master_nodes sur un nombre supérieur à 1 peut aider à prévenir ce que l’on appelle un cerveau divisé dans le cluster. En suivant la règle habituelle pour un cluster à trois nœuds, définissez minimum_master_nodes sur 2 ou pour un cluster à 14 nœuds, définissez la valeur sur 8. Pour modifier ce paramètre, modifiez discovery.zen.minimum_master_nodes dans elasticsearch. yml au nombre qui correspond à votre cluster.

Qu’est-ce qu’un cerveau divisé?

Le terme cerveau divisé décrit un scénario dans lequel (généralement sous une charge importante ou des problèmes de réseau) un ou plusieurs des nœuds de votre cluster Elasticsearch perd la communication avec le nœud maître, élit un nouveau maître et continue à traiter les demandes. À ce stade, vous pouvez avoir deux clusters Elasticsearch différents fonctionnant indépendamment l’un de l’autre. D’où le terme cerveau divisé, car un seul cluster s’est scindé en deux parties distinctes, similaires aux hémisphères d’un cerveau. Pour éviter cela, définissez discovery.zen.minimum_master_nodes en fonction du nombre de nœuds dans votre cluster. Si le nombre de nœuds ne change pas, définissez-le sur le nombre total de nœuds du cluster. sinon, le nombre de nœuds divisé par 2 plus 1 est un bon paramètre, car cela signifie que si un ou deux nœuds perdent la communication avec les autres nœuds, ils ne pourront pas élire un nouveau maître et former un nouveau cluster car ils ne ne répond pas au nombre requis de nœuds éligibles au maître.

Une fois que vos nœuds sont en place et se sont découverts, vous pouvez voir quel nœud votre cluster a choisi comme maître en utilisant la commande curl indiquée dans la figure suivante.

9.2.4. Détection de fautes

Maintenant que votre cluster contient deux noeuds, ainsi qu’un noeud principal élu, il doit communiquer avec tous les noeuds du cluster pour s’assurer que tout va bien dans le cluster. C’est le processus de détection de défaut. Le nœud maître envoie une requête ping à tous les autres nœuds du cluster et chaque nœud envoie une commande ping au maître afin de s’assurer qu’une nouvelle élection n’est pas necéssaire, comme illustré dans la figure 9.5.

Comme le montre la figure, chaque nœud envoie un ping tous les discovery.zen.fd.ping_interval (1 par défaut), attend Discovery.zen.fd.ping_timeout (30 par défaut) et tente un nombre maximal de discovery.zen.fd.ping_retries fois (par défaut à 3) avant de déclarer un nœud déconnecté et de router des fragments ou de choisir un nouveau noeud master si nécessaire. Veillez à modifier ces valeurs si la latence de votre environnement est plus élevée, par exemple lorsque vous travaillez avec des nœuds ec2 qui ne se trouvent peut-être pas dans la même zone Amazon AWS.

Inévitablement, l’un des noeuds de votre cluster tombera en panne. Dans la section suivante, nous allons donc parler de ce qui se passe lorsque des noeuds sont supprimés du cluster et comment supprimer des noeuds sans causer de perte de données dans un système distribué.

9.3. SUPPRESSION DE NOEUDS D’UN CLUSTER

L’ajout de nœuds est un excellent moyen de « scaler » notre système, mais que se passe-t-il lorsqu’un nœud quitte le cluster Elasticsearch ou si vous l’arrêtez? Utilisez l’exemple de cluster à trois nœuds que vous avez créé à la figure 9.2 et contenant l’index de test avec cinq fragments primaires et un réplica répartis sur les trois nœuds.

Disons que Joe, l’administrateur système, trébuche accidentellement sur le cordon d’alimentation pour Node1; qu’advient-il des trois fragments actuellement sur Node1? Elasticsearch commence par transformer automatiquement les fragments de répliques test0 et test3 se trouvant sur Node2 en fragments principaux, comme le montre la figure 9.6. Cela s’explique par le fait que l’indexation concerne d’abord les fragments primaires. Elasticsearch s’efforce donc de s’assurer que tous les fragments primaires soient toujours attribuées pour un index.

Elasticsearch peut choisir n’importe laquelle des répliques à transformer en fragment primaire. Il se trouve que dans cet exemple il n’ya qu’une réplique pour chaque fragment principal parmi lequel choisir: les répliques sur Node2.

Une fois que Elasticsearch a transformé les répliques des fragments primaires manquants en primaires, le cluster ressemble à la figure 9.6.

Après avoir transformé les fragments de réplica en primaires, le cluster est maintenant dans un état jaune, ce qui signifie que certains fragments de réplica ne sont pas alloués à un nœud. Elasticsearch doit ensuite créer davantage de fragments de réplica pour maintenir la configuration de haute disponibilité de l’index de test. Comme toutes les primaires sont disponibles, les données des fragments primaires test0 et test3 sur Node2 seront répliquées dans des répliques sur Node3 et les données du fragment primaire test1 sur Node3 seront répliquées sur Node2, comme illustré à la figure 9.7.

Une fois que les fragments de réplique ont été recréés pour compenser la perte du nœud 1, le cluster revient à l’état vert avec tous les fragments primaires et de réplica attribués à un nœud. N’oubliez pas que pendant tout ce temps, l’ensemble du cluster sera disponible pour la recherche et l’indexation car aucune donnée n’a été réellement perdue. Si plusieurs nœuds sont perdus ou si un fragment sans réplique est perdu, le cluster sera rouge, ce qui signifie qu’une certaine quantité de données a été perdue de manière permanente. Vous devez alors reconnecter le nœud qui contient les données au cluster ou réindexer les données manquantes.

Il est important de comprendre le risque que de perdre des données suite à la disparition d’un noeud est directement lié au nombre de replica que vous avez. Avoir un seul réplica signifie qu’un seul nœud peut disparaître du cluster sans perte de données. Si vous utilisez deux réplicas, vous pouvez perdre deux nœuds sans perte de données, etc., assurez-vous donc de choisir le nombre de réplicas approprié à votre utilisation. C’est également toujours une bonne idée de sauvegarder vos index, un sujet que nous aborderons au chapitre 11 lorsque nous parlerons de l’administration de votre cluster.

Vous avez vu à quoi ressemble l’ajout et la suppression d’un nœud, mais qu’en est-il de fermer un nœud sans que le cluster ne passe à l’état jaune? Dans la section suivante, nous parlerons de la mise hors service des nœuds afin qu’ils puissent être supprimés du cluster sans interruption pour les utilisateurs du cluster.

9.3.1. Mise hors service de noeuds

Faire en sorte qu’Elasticsearch crée automatiquement de nouvelles répliques lorsqu’un nœud tombe en panne est une excellente chose, mais lors de la maintenance d’un cluster, vous souhaiterez éventuellement arrêter un nœud contenant des données sans que le cluster ne passe à l’état jaune. Le matériel est peut-être dégradé ou vous ne recevez pas le même nombre de requêtes qu’auparavant, la charge ayant diminué, vous n’avez plus besoin de garder le nœud. Vous pouvez toujours arrêter le nœud en supprimant directement le processus Java. Elasticsearch restaurera les données sur les autres nœuds, mais qu’en sera-t-il lorsque vous aurez zéro réplicas pour un index? Cela signifie que vous pourriez perdre des données si vous arrêtez un nœud sans d’abord transférer les données!

Heureusement, Elasticsearch peut désaffecter un nœud en indiquant au cluster de ne pas allouer de fragments à un nœud ou à un ensemble de nœuds. Dans notre exemple à trois nœuds, supposons que Node1, Node2 et Node3 possèdent les adresses IP 192.168.1.10, 192.168.1.11 et 192.168.1.12, respectivement. Si vous souhaitez fermer Node1 tout en conservant le cluster dans un état vert, vous pouvez d’abord le mettre hors service, ce qui déplacerait tous les fragments sur le nœud vers les autres nœuds du cluster. Vous désactivez un nœud en modifiant temporairement les paramètres du cluster, comme indiqué dans la figure suivante.

Une fois cette commande exécutée, Elasticsearch commencera à déplacer tous les fragments du nœud mis hors service vers les autres nœuds du cluster. Vous pouvez vérifier où se trouvent les fragments dans le cluster en déterminant d’abord l’ID des noeuds du cluster avec le endpoint _nodes, puis en consultant l’état du cluster pour voir où chaque fragment du cluster est actuellement alloué. Voir la figure suivante pour un exemple de resultat de ces commandes.

C’est un résultat long et pas très jolie! Ne vous inquiétez pas. Plus tard dans ce chapitre, nous parlerons d’une version plus lisible de cette API, appelée API _cat.

Vous pouvez voir ici qu’il n’ya pas de fragments sur le nœud lFd3ANXiQlug-0eJztvaeA, c’est-à-dire le nœud 192.168.1.10 qui a été mis hors service, il est donc prudent d’arrêter Elascticsearu sur ce nœud sans que le cluster ne passe à l’état du vert au jaune. Ce processus peut être répété noeud par noeud pour mettre hors service chaque noeud que vous souhaitez arrêter. Vous pouvez également utiliser une liste d’adresses IP séparées par des virgules au lieu de 192.168.1.10 pour mettre hors service plusieurs noeuds à la fois. Cependant, gardez à l’esprit que les autres nœuds du cluster doivent être capables de gérer l’allocation des fragments en termes d’utilisation du disque et de la mémoire. Planifiez en conséquence afin de vous assurer que vous disposez de suffisamment de marge avant le décommissionnement de vos nœuds!

Combien de données un index Elasticsearch peut-il gérer?

Bonne question! Malheureusement, les limitations d’un seul index dépendent du type de machine utilisée pour stocker l’index, de ce que vous envisagez de faire avec les données et du nombre de fragments dans lesquels l’index est sauvegardé. En règle générale, un index Lucene (également appelé fragment Elasticsearch) ne peut pas contenir plus de 2,1 milliards de documents ou plus de 274 milliards de termes distincts (voir https://lucene.apache.org/core/4_9_0/core/org/apache). /lucene/codecs/lucene49/package-summary.html#Limitations), mais votre espace disque peut être limité avant ce point. Le meilleur moyen de savoir si vous pourrez stocker vos données dans un seul index est de faire des tests de votre système, en ajustant les paramètres nécessaires pour obtenir les caractéristiques de performance souhaitées. Vous ne pouvez pas modifier le nombre de fragments primaires une fois qu’un index a été créé; vous ne pouvez changer que le nombre de fragments de réplica, agissez en conséquence.

Maintenant que vous avez vu comment les nœuds sont ajoutés et supprimés du cluster, voyons comment mettre à niveau les nœuds Elasticsearch.

9.4. MISE A JOUR DE NOEUDS ELASTICSEARCH

Chaque installation d’Elasticsearch arrive à un moment où il est temps de passer à la dernière version. Nous vous recommandons de toujours exécuter la dernière version d’Elasticsearch, car de nouvelles fonctionnalités sont toujours ajoutées, de même que des bogues corrigés. Cela dit, en fonction des contraintes de votre environnement, la mise à niveau peut être plus ou moins complexe.

Mise en garde des mises à jour

Avant de passer aux instructions de mise à niveau, il est important de comprendre que la mise à niveau des instances Elasticsearch est soumise à certaines limitations. Une fois que vous avez mis à niveau un serveur Elasticsearch, vous ne pouvez plus rétrograder le serveur si de nouveaux documents ont été écrits. Lorsque vous effectuez des mises à niveau vers une instance de production, vous devez toujours sauvegarder vos données avant d’effectuer une mise à niveau. Nous parlerons davantage de la sauvegarde de vos données au chapitre 11.

Une autre chose importante à considérer est que, bien qu’Elasticsearch puisse gérer facilement un environnement de version mixte, il est parfois arrivé que différentes versions de JVM sérialisent les informations différemment. Nous vous recommandons donc de ne pas mélanger différentes versions de JVM au sein du même cluster Elasticsearch.

Le moyen le plus simple de mettre à niveau un cluster Elasticsearch consiste à fermer tous les noeuds, puis à mettre à niveau chaque installation Elasticsearch avec la méthode utilisée à l’origine, par exemple, extraire la distribution si vous avez utilisé la distribution .tar.gz ou installer le package .deb à l’aide de dpkg. si vous utilisez un système basé sur Debian. Une fois que chaque nœud a été mis à niveau, vous pouvez redémarrer l’ensemble du cluster et attendre qu’Elasticsearch atteigne l’état vert. Voilà, la mise à jour est terminée!

Cela peut ne pas toujours être le cas, cependant; Dans de nombreuses situations, les temps d’arrêt ne peuvent être tolérés, même pendant les heures creuses. Heureusement, vous pouvez effectuer un redémarrage progressif pour mettre à niveau votre cluster Elasticsearch tout en continuant de répondre aux demandes d’indexation et de recherche.

9.4.1. Effectuer un redémarrage progressif

Un redémarrage progressif est un autre moyen de redémarrer votre cluster pour mettre à niveau un nœud ou effectuer une modification de configuration non dynamique sans sacrifier la disponibilité de vos données. Cela peut être particulièrement utile pour les déploiements de production d’Elasticsearch. Au lieu de fermer tout le cluster en même temps, vous fermez les nœuds un à un. Ce processus est légèrement plus complexe qu’un redémarrage complet en raison des multiples étapes requises.

La première étape consiste à décider si vous voulez qu’Elasticsearch rééquilibre automatiquement les fragments lorsque chaque noeud individuel est arreté. La plupart des utilisateurs ne souhaitent pas qu’Elasticsearch démarre sa récupération automatique si un nœud quitte le cluster pour une mise à niveau, car cela signifie qu’ils rééquilibreront chaque nœud. Or en réalité, les données sont toujours là; le nœud doit simplement être redémarré et rejoindre le cluster pour qu’il soit disponible.

Pour la plupart des gens, il est logique de ne pas déplacer les données du cluster lors de la mise à niveau. Pour ce faire, définissez le paramètre cluster.routing.allocation.enable sur none lors de la mise à niveau. Pour clarifier, le processus entier ressemble à ceci:

1. Désactivez l’allocation pour le cluster.

2. Arrêtez le nœud qui sera mis à niveau.

3. Mettez à niveau le nœud.

4. Démarrez le nœud mis à niveau.

5. Attendez que le nœud mis à niveau ait rejoint le cluster.

6. Activez l’allocation pour le cluster.

7. Attendez que le cluster revienne à l’état vert.

Répétez cette procédure pour chaque nœud à mettre à niveau. Pour désactiver l’allocation pour le cluster, vous pouvez utiliser l’API _cluster avec les paramètres suivants:

Une fois cette commande exécutée, Elasticsearch ne rééquilibrera plus les fragments autour du cluster. Par exemple, si un fragment primaire est perdu pour un index parce que le nœud sur lequel il résidait est arrêté, Elasticsearch transformera toujours le fragment de réplique en un nouveau fragment primaire, mais aucun nouveau réplica ne sera créé. Dans cet état, vous pouvez arrêter en toute sécurité le nœud Elasticsearch et effectuer la mise à niveau.

Après la mise à niveau du nœud, assurez-vous de réactiver l’allocation pour le cluster. Sinon, vous vous demanderez pourquoi Elasticsearch ne répliquera pas automatiquement vos données à l’avenir! Vous pouvez réactiver l’allocation en définissant le paramètre cluster.routing.allocation.enable sur all au lieu de none, comme ceci:

Vous devez exécuter ces deux étapes, désactivation et activation de l’allocation, pour chaque nœud du cluster en cours de mise à niveau. Si vous ne les exécutiez qu’une fois au début et une fois à la fin, Elasticsearch n’allourait pas les fragments présents sur le nœud chaque fois que vous l’auriez mis à niveau, et votre cluster serait rouge une fois que vous auriez mis à niveau plusieurs nœuds. En réactivant l’allocation et en attendant que le cluster revienne à l’état vert après la mise à niveau de chaque nœud, vos données sont allouées et disponibles lorsque vous passez au nœud suivant devant être mis à niveau. Répétez ces étapes pour chaque nœud à mettre à niveau jusqu’à ce que vous disposiez d’un cluster entièrement mis à niveau.

Il y a encore une chose à mentionner dans cette section: les index qui n’ont pas de répliques. Les exemples précédents prennent tous en compte les données ayant au moins un seul réplica afin qu’un nœud en panne ne supprime pas l’accès aux données. Si vous avez un index qui n’a pas de réplicas, vous pouvez utiliser les étapes de désaffectation décrites dans la section 9.3.1 pour désaffecter le noeud en déplaçant toutes les données de celui-ci avant de le fermer pour effectuer la mise à niveau.

9.4.2. Minimiser le temps de récupération après un redémarrage

Vous remarquerez peut-être que même avec les étapes de désactivation et d’activation, le cluster peut prendre un certain temps pour revenir à l’état vert lors de la mise à niveau d’un seul nœud. Malheureusement, cela est dû au fait que la réplication utilisée par Elasticsearch s’applique à chaque segment de fragment, plutôt qu’au niveau du document. Cela signifie que le nœud Elasticsearch qui envoie les données à répliquer dit «Avez-vous des segments_1?». S’il ne contient pas le fichier ou si le fichier n’est pas identique, le fichier de segment entier est copié. Une plus grande quantité de données peut être copiée dans le cas où les documents sont identiques. Jusqu’à ce qu’Elasticsearch dispose d’un moyen de vérifier le dernier document écrit dans un fichier de segment, il doit copier tous les fichiers différents lors de la réplication de données entre le fragment principal et le réplica.

Il existe deux manières différentes de rendre des fichiers de segment identiques sur les fragments primaires et de répliques. La première consiste à utiliser l’API d’optimisation dont nous parlerons au chapitre 10 pour créer un seul segment volumineux pour le réplica et le primaire. La seconde consiste à basculer le nombre de répliques à 0, puis à revenir à un nombre plus élevé; Cela garantit que toutes les copies de réplicas ont les mêmes fichiers de segment que le fragment principal. Cela signifie que pendant une courte période, vous ne disposerez que d’une seule copie des données, alors méfiez-vous de le faire dans un environnement de production!

Enfin, afin de minimiser le temps de récupération, vous pouvez également arrêter l’indexation des données dans le cluster lors de la mise à niveau du nœud.

Maintenant que nous avons couvert la mise à niveau d’un nœud, nous allons aborder une API utile pour extraire des informations du cluster de manière plus conviviale: l’API _cat.

9.5 UTILISER L’API _CAT

Utiliser les commandes curl des sections 9.1, 9.2 et 9.3 est un excellent moyen de voir ce qui se passe dans votre cluster, mais il est parfois utile de voir le résultat dans un format plus lisible (si vous ne nous croyez pas, essayez la requête suivante: http://localhost: 9200/ _cluster/state sur un grand cluster et voir combien d’informations sont renvoyées!). C’est ici qu’intervient l’API _cat pratique. L’API _cat fournit des outils de diagnostic et de débogage utiles qui permettent d’imprimer les données de manière plus lisible par l’homme, plutôt que d’essayer de feuilleter une réponse JSON géante. La figure suivante montre deux de ses commandes pour les instructions cURL health et nodes que nous avons déjà traitées.

En plus des endpoints nodes et _health, l’API _cat possède de nombreuses autres fonctionnalités, qui sont toutes utiles pour le débogage de différentes choses pour votre cluster. Vous pouvez voir la liste complète des endpoints de l’API _cat prises en charge en exécutant curl ‘localhost:9200 / _cat’.

API _cat

Au moment d’écrire ces lignes, voici quelques-unes des API _cat les plus utiles et ce qu’elles font. Prenez tout de même le temps de découvrir les autres!

allocation: affiche le nombre de fragments attribués à chaque nœud.
count: compte le nombre de documents dans l’ensemble du cluster ou de l’index.
health: affiche la santé du cluster.
indices: affiche des informations sur les index existants
master: indique quel noeud est actuellement élu maître.
nodes: affiche diverses informations sur tous les nœuds du cluster.
recovery: affiche l’état des fragments en cours de restauration dans le cluster.
shards– Affiche le nombre, la taille et les noms des fragments du cluster.
plugins – Affiche des informations sur les plugins installés

Bien que nous envisagions d’ajouter des nœuds à un cluster, pourquoi ne pas voir comment les fragments sont répartis sur chaque nœud à l’aide de l’API _cat dans la figure de code suivante. C’est un moyen beaucoup plus facile de voir comment les fragments sont alloués dans votre cluster, par opposition à la commande curl de la figrue 9.2.

L’utilisation des API _cat/allocation et _cat/shards constitue également un excellent moyen de déterminer quand un nœud peut être arrêté en toute sécurité après la mise hors service décrite à la section 9.3.1. Comparez le résultat de la commande curl de la figure 9.2 à la sortie des commandes de la figure 9.6; il est beaucoup plus facile de lire la sortie de l’API _cat!

Maintenant que vous pouvez voir où se trouvent les fragments dans votre cluster, nous devrions passer plus de temps à discuter de la planification de votre cluster Elasticsearch afin de tirer le meilleur parti de vos nœuds et de vos données.

9.6. STRATÉGIES DE MISE A L’ÉCHELLE

Il peut sembler assez facile d’ajouter des nœuds à un cluster pour améliorer les performances, mais c’est en réalité le moment où une petite planification permet de tirer le meilleur parti des performances de votre cluster.

Chaque utilisation d’Elasticsearch étant différente, vous devez choisir les meilleures options pour votre cluster en fonction de la façon dont vous indexez les données et de la recherche. En règle générale, vous devez toutefois prendre en compte au moins trois éléments lors de la mise en place d’un cluster Elasticsearch de production: découpage excessif, fractionnement des données entre index et fragments, et optimisation du débit.

9.6.1. Découpage excessif (Over-sharding)

Commençons par parler du surdécoupage. Le sur-partage est le processus par lequel vous créez intentionnellement un plus grand nombre de fragments pour un index afin de pouvoir ajouter des nœuds et de croître à l’avenir. ceci est mieux illustré par un diagramme, regardez donc la figure 9.8.

Dans la figure 9.8, vous avez créé votre index de rencontre avec un seul fragment, sans répliques. Mais que se passe-t-il lorsque vous ajoutez un autre noeud?

Oups! L’ajout de nœuds dans ce cluster ne sert à rien. Car toute la charge d’indexation et de requête sera toujours gérée par le nœud contenant le seul fragment. Comme un fragment est la plus petite chose qu’Elasticsearch puisse déplacer, c’est une bonne idée de toujours vous assurer que vous avez au moins autant de fragments primaires dans votre cluster que vous prévoyez d’avoir des noeuds; Si vous avez actuellement un cluster à 5 nœuds avec 11 fragments principaux, vous avez la possibilité de vous développer lorsque vous devez ajouter plus de nœuds pour traiter des demandes supplémentaires. En utilisant le même exemple, si vous avez soudainement besoin de plus de 11 nœuds, vous ne pourrez pas répartir les fragments primaires sur plusieurs nœuds, car vous aurez plus de nœuds que de fragments.

C’est facile à corriger me direz-vous. Vous pourriez vous dire: «Je vais juste créer un index avec 100 fragments primaires!» Cela peut sembler une bonne idée au départ, mais chaque fragment doit supporter un coût caché à gérer. Comme chaque fragment est un index complet de Lucene, comme vous l’avez appris au chapitre 1, chaque fragment nécessite un certain nombre de descripteurs de fichier pour chaque segment de l’index, ainsi qu’une surcharge de mémoire. En créant un nombre trop important de fragments pour un index, vous utilisez peut-être une mémoire qui pourrait être mieux utilisée pour améliorer les performances, ou vous risquez de heurter le descripteur de fichier ou les limites de la RAM de la machine. De plus, lors de la compression de vos données, vous diviserez les données en 100 éléments différents, ce qui réduira le taux de compression que vous auriez obtenu si vous aviez choisi une taille plus raisonnable.

Il convient de noter qu’il n’existe pas de rapport fragmentaire / index parfait pour tous les cas d’utilisation; Elasticsearch choisit une valeur par défaut de cinq fragments pour le cas général, mais il est toujours important de réfléchir à la manière dont vous prévoyez de croître (ou de diminuer) à l’avenir en fonction du nombre de fragments que vous créez et indexez. N’oubliez pas: une fois qu’un index a été créé avec un nombre de fragments, le nombre de fragments primaires ne peut plus être modifié pour cet index! Vous ne voulez pas avoir à réindexer une grande partie de vos données six mois plus tard, faute de planification insuffisante. Nous en reparlerons également dans le chapitre suivant lorsque nous aborderons l’indexation en profondeur.

Dans le même ordre d’idées que lorsque vous choisissez le nombre de fragments pour créer un index, vous devez également décider de la répartition exacte de vos données entre les index dans Elasticsearch.

9.6.2. Fractionnement des données entre index et fragments

Malheureusement, pour l’instant, il n’ya aucun moyen d’augmenter ou de réduire le nombre de fragments primaires dans un index, mais vous pouvez toujours planifier vos données de manière à couvrir plusieurs index. C’est un autre moyen parfaitement valide de fractionner des données. Dans notre exemple de site de rencontre, rien ne vous empêche de créer un index pour chaque ville dans laquelle se produit un événement. Par exemple, si vous prévoyez d’organiser un plus grand nombre d’événements à New York que Sacramento, vous pouvez créer un index sacramento avec deux fragments primaires et un index newyork avec quatre fragments primaires; vous pouvez également segmenter les données par date, en créant un indexe pour chaque année au cours de laquelle un événement se produit ou est créé: 2014, 2015, 2016, etc. La segmentation des données de cette manière peut également être utile lors de la recherche, car la segmentation est gérée en plaçant les bonnes données au bon endroit. Si le client souhaite rechercher uniquement des événements ou des groupes de l’année 2014 ou 2015, vous devez rechercher uniquement ces index plutôt que l’intégralité de l’index de rendez-vous.

Une autre façon de planifier en utilisant des index est d’utiliser des alias. Un alias agit comme un pointeur sur un index ou un ensemble d’index. Un alias vous permet également de modifier les index qu’il pointe à tout moment. Ceci est incroyablement utile pour segmenter vos données de manière sémantique. vous pouvez créer un alias appelé last-year qui pointe vers 2019; ensuite, lorsque le 1 er janvier 2020 arrive, vous pourrez modifier le pseudonyme pour qu’il pointe vers l’index 2020. Cette technique est couramment utilisée lors de l’indexation d’informations basées sur la date (telles que les fichiers logs) afin que les données puissent être segmentées par date sur une base mensuelle/hebdomadaire/journalière et qu’un alias nommé current puisse être utilisé pour toujours pointer sur les données à rechercher. sans avoir à changer le nom de l’index recherché chaque fois que le segment est remplacé. Encore une fois, les alias permettent un niveau incroyable de flexibilité et ne génèrent quasiment pas de frais généraux. Nous vous encourageons donc à les utiliser. Nous parlerons plus en détail des alias plus tard dans ce chapitre.

Lors de la création d’index, n’oubliez pas que, chaque index contient ses propres fragments. Veillez donc à ne pas créer trop de fragments en créant trop d’index et en utilisant des ressources qui auraient pu servir à la gestion des requêtes. Une fois que vous savez comment vos données seront disposées dans le cluster, vous pouvez peaufiner la configuration du nœud pour optimiser votre débit.

9.6.3. Maximiser le débit

Maximiser le débit est l’un de ces termes flous et vagues pouvant signifier énormément de choses. Essayez-vous de maximiser le débit d’indexation? Faire des recherches plus rapidement? Effectuer plus de recherches à la fois? Il existe différentes façons de modifier Elasticsearch pour accomplir chaque tâche. Par exemple, si vous receviez des milliers de nouveaux groupes et événements, comment procéderiez-vous pour les indexer le plus rapidement possible? Un moyen d’accélérer l’indexation consiste à réduire temporairement le nombre de fragments de réplica dans votre cluster. Lors de l’indexation des données, par défaut, la demande ne sera pas complétée tant que les données ne figureront pas sur le fragment principal, ainsi que sur toutes les répliques. Il peut donc être avantageux de réduire le nombre de répliques à un (ou à zéro si le risque vous convient. ) pendant l’indexation, puis augmentez le nombre à un ou plusieurs une fois la période d’indexation lourde terminée.

Qu’en est-il des recherches? Les recherches peuvent être effectuées plus rapidement en ajoutant plus de répliques, car un fragment principal ou un fragment de réplique peut être utilisé pour effectuer une recherche. Pour illustrer cela, consultez la figure 9.9, qui montre un cluster à trois nœuds où le dernier nœud ne peut pas aider les requêtes de recherche tant qu’il n’a pas une copie des données.

Mais n’oubliez pas que la création de plus de fragments dans un cluster Elasticsearch s’accompagne d’une légère surcharge en descripteurs de fichiers et en mémoire. Si le volume de recherches devient trop important pour que les nœuds du cluster puissent suivre, envisagez d’ajouter des nœuds avec node.data et node.master définis sur false. Ces nœuds peuvent ensuite être utilisés pour gérer les demandes entrantes, les distribuer aux nœuds de données et collecter les résultats pour les réponses. De cette manière, les nœuds recherchant les partitions ne doivent pas gérer les connexions des clients de recherche; ils ont seulement besoin de rechercher des fragments. Nous parlerons davantage des différentes manières d’accélérer l’indexation et la recherche dans le chapitre suivant.

9.7. ALIASES

Parlons maintenant de l’une des fonctionnalités les plus simples et potentiellement les plus utiles d’Elasticsearch: les alias. Les aliases sont exactement ce à quoi ils ressemblent; il s’agit d’un pointeur ou d’un nom que vous pouvez utiliser et qui correspond à un ou plusieurs indices concrets. Cela s’avère très utile en raison de la flexibilité qu’il offre lors de la mise à l’échelle de votre cluster et de la gestion de la disposition des données dans vos index. Même si vous utilisez un cluster Elasticsearch avec un seul index, utilisez un alias. Vous nous remercierez plus tard pour la flexibilité que cela vous apportera.

9.7.1. Qu’est-ce qu’un alias, vraiment?

Vous vous demandez peut-être ce qu’est exactement un alias et quelle est la surcharge, qu’est ce que ça coûte à votre système d’en créer un. Un alias passe sa vie dans l’état du cluster, géré par le nœud maître; Cela signifie que si vous avez un alias appelé idaho qui pointe vers un index nommé pommes de terre, la surcharge est une clé supplémentaire dans la map gérant l’état du cluster, qui associera le nom idaho à l’index pommes de terre . Cela signifie que, par rapport aux indices supplémentaires, les alias sont beaucoup plus légers; des milliers d’entre eux peuvent être gérés sans impact négatif sur votre cluster. Cela dit, nous vous déconseillons de créer des centaines de milliers, voire des millions, d’alias, car même le surcoût minimal d’une seule entrée dans la map peut entraîner la croissance de l’état du cluster. Cela signifie que les opérations modifiant l’ état du cluster prendront plus de temps car tout l’état du cluster est envoyé à chaque nœud à chaque fois qu’il change.

Pourquoi les alias sont-ils utiles?

Nous recommandons à tous les utilisateurs d’utiliser un alias pour leurs index Elasticsearch, car cela leur donnera beaucoup plus de flexibilité à l’avenir en matière de réindexation. Supposons que vous commenciez par créer un index avec un seul fragment primaire, puis que vous décidiez par la suite que vous avez besoin de plus de capacité sur votre index. Si vous utilisiez un alias pour l’index d’origine, vous pouvez maintenant modifier cet alias pour qu’il pointe vers un index créé en plus sans avoir à changer le nom de l’index que vous recherchez (en supposant que vous utilisiez un alias pour effectuer une recherche depuis le début). ).

Une autre fonctionnalité utile peut être la création de fenêtres dans différents index. Par exemple, si vous créez des index quotidiens pour vos données, vous souhaiterez peut-être une fenêtre glissante des données de la semaine dernière en créant un alias appelé last-7-days; Ensuite, chaque jour, lorsque vous créez un nouvel index quotidien, vous pouvez l’ajouter à l’alias tout en supprimant simultanément l’index de huit jours.

Gestion des alias

Les alias sont créés à l’API aliases et d’une liste d’actions. Chaque action est une map avec une action d’ajout ou de suppression, suivie de l’index et de l’alias sur lesquels appliquer l’opération. Cela sera beaucoup plus clair avec l’exemple présenté dans la figure suivante.

Dans cette figure, l’index get-together est ajouté à un alias nommé gt-alias et l’index inventé old-get-together est supprimé de l’alias gt-alias. Le fait d’ajouter un index à un alias le crée et le fait de supprimer tous les index pointés par un alias supprime celui-ci; il n’existe pas de création ou de suppression manuelle d’alias. Mais les opérations sur les alias échoueront si l’index n’existe pas, gardez cela à l’esprit. Vous pouvez spécifier autant d’actions d’ajout et de suppression que vous le souhaitez. Il est important de reconnaître que toutes ces actions se produiront de manière atomique, ce qui signifie que, dans l’exemple précédent, l’alias gt-alias à aucun moment ne pointera à la fois sur les index get-together et old-get-together. Bien que l’appel à l’API Alias de façon composé que nous venons de décrire puisse répondre à vos besoins, il est important de noter que des actions individuelles peuvent également être effectuées sur l’API Alias, à l’aide des méthodes HTTP courantes normalisées par Elasticsearch. Par exemple, la série d’appels suivante aurait le même effet que l’appel d’actions composées présenté précédemment:

Bien que nous explorions des méthodes d’API à appel unique, cette section ne serait pas complète sans une description plus détaillée de l’API, en particulier des endpoints pouvant être utiles pour la création et l’énumération des opérations.

9.7.2. Création d’alias

Lors de la création d’alias, de nombreuses options sont disponibles via l’endpoint _alias. Par exemple, vous pouvez créer des alias sur un index spécifique, de nombreux index ou un modèle correspondant aux noms d’index:

La suppression d’alias accepte le même format de paramètre au niveau de l’url:

Vous pouvez récupérer tous les alias vers lesquels un index concret pointe en émettant une demande GET sur un index avec _alias, ou vous pouvez extraire tous les index et les alias qui pointent sur eux en omettant le nom de l’index. La récupération des alias pour un index est indiquée dans la figure suivante.

En plus de l’endpoint _alias sur un index, vous pouvez extraire les informations sur les aliases d’un index de différentes manières:

Les alias ont également d’autres caractéristiques intéressantes; ils peuvent être utilisés pour appliquer automatiquement un filtre aux requêtes exécutées. Par exemple, avec vos données de rencontre, il peut être utile de disposer d’un alias pointant uniquement sur les groupes contenant la balise elasticsearch. Vous pouvez ainsi créer un alias filtrant automatiquement, comme indiqué dans la figure suivante.

Ici, vous pouvez voir que l’alias es-groups ne contient que deux groupes au lieu de cinq. En effet, il applique automatiquement le filtre de terme aux groupes contenant le tag elasticsearch. Cela a beaucoup d’applications; Si vous indexez des données sensibles, par exemple, vous pouvez créer un alias filtré pour vous assurer que quiconque l’utilisera ne pourra pas voir les données qu’il n’est pas censé voir.

Les alias peuvent fournir une fonctionnalité supplémentaire, le routage, mais avant de parler de l’utiliser avec un alias, nous parlerons de son utilisation en général.

9.8. ROUTING

Au chapitre 8, nous avons expliqué comment les documents se retrouvent dans un fragment particulier. Ce processus est le routing d’un document. Pour faire un petit rappel, le routing d’un document a lieu lorsque Elasticsearch a haché l’ID du document, spécifié par vous ou généré par Elasticsearch, afin de déterminer le fragment dans lequel un document doit être indexé. Elasticsearch vous permet également de spécifier manuellement le routing d’un document lors de l’indexation, comme vous le faites lorsque vous utilisez des relations parent-enfant car le document enfant doit se trouver dans le même fragment que le document parent.

Le routing peut également utiliser une valeur personnalisée pour le hachage, au lieu de l’ID du document. En spécifiant le paramètre de requête de routage sur l’URL, cette valeur sera hachée et utilisée à la place de l’ID:

Dans cet exemple, denver est la valeur hachée pour déterminer le fragment dans lequel le document se termine, au lieu de 9, l’ID du document. Le routage peut être utile pour les strategies de mise à l’échelle (scaling). C’est pourquoi nous en parlerons en détail dans ce chapitre.

9.8.1. Pourquoi utiliser le routage?

Si vous n’utilisez pas du tout le routage, Elasticsearch veillera à ce que vos documents soient distribués de manière uniforme sur tous les fragments, pourquoi voudriez-vous utiliser le routage? Le routage personnalisé vous permet de collecter plusieurs documents partageant une valeur de routage dans un même fragment. Une fois que ces documents figurent dans le même index, il vous permet de router certaines requêtes afin qu’elles soient exécutées sur un sous-ensemble des fragments d’un index. Cela semble déroutant? Nous y reviendrons plus en détail pour clarifier ce que nous voulons dire.

9.8.2. Stratégies de routage

Le routage est une stratégie qui demande des efforts dans deux domaines: vous devez choisir de bonnes valeurs de routage lors de l’indexation des documents et vous devez les réutiliser lorsque vous exécutez des requêtes. Avec notre exemple get-together, vous devez d’abord choisir un bon moyen de séparer chaque document. Dans ce cas, choisissez la ville associée à un groupe de rencontre ou alors un événement, comme valeur de routage. C’est un bon choix pour une valeur de routage car les villes varient suffisamment pour que vous ayez plusieurs valeurs à choisir et chaque événement et groupe étant déjà associés à une ville, il est donc facile de les extraire d’un document avant l’indexation. Si vous choisissez quelque chose qui n’a que quelques valeurs différentes, vous pouvez facilement vous retrouver avec des fragments non équilibrés pour l’index. S’il n’y a que trois valeurs de routage possibles pour tous les documents, tous les documents seront acheminés entre trois fragments au maximum. Il est important de choisir une valeur qui aura suffisamment de cardinalité pour répartir les données entre les fragments dans un index.

Maintenant que vous avez sélectionné ce que vous voulez utiliser pour la valeur de routage, vous devez spécifier cette valeur de routage lors de l’indexation des documents, comme indiqué dans la figure ci-dessous.

Dans cet exemple, vous utilisez trois valeurs de routage différentes, denver, boulder et amsterdam, pour trois documents différents. Cela signifie qu’au lieu de hacher les ID 10, 11 et 12 pour déterminer le fragment dans lequel placer le document, vous utilisez plutôt les valeurs de routage. Du côté de l’index, cela ne vous aide pas beaucoup; Le véritable avantage réside dans la combinaison du routage du côté de la requête, comme l’indique la figure suivante. Du côté de la requête, vous pouvez combiner plusieurs valeurs de routage avec une virgule.

Intéressant! Au lieu de renvoyer les trois groupes, seuls deux ont été renvoyés. Alors qu’est-ce qui s’est réellement passé? En interne, lorsque Elasticsearch a reçu la demande, il a haché les valeurs des deux valeurs de routage fournies, denver et amsterdam, puis a exécuté la requête sur tous les fragments auxquels ils ont été hachés. Dans ce cas, Denver et Amsterdam utilisent tous deux le même fragment du fait de leurs hash et boulder est sur fragment différent.

Extrapolez cela à des centaines de milliers de groupes, dans des centaines de villes, en spécifiant le routage de chaque groupe lors de l’indexation et de l’interrogation. Vous pouvez ainsi limiter la portée de l’exécution d’une requête de recherche. Cela peut constituer une grande amélioration au niveau de la scalabilité pour un index pouvant contenir jusqu’à 100 fragments; au lieu d’exécuter la requête sur les 100 fragments, elle peut être limitée et donc exécutée plus rapidement avec un impact moindre sur votre cluster Elasticsearch.

Dans l’exemple précédent, denver et amsterdam arrivent à se diriger vers le même fragment, mais ils auraient tout aussi bien pu être hachés différemment, donc vers des fragments différents. Comment savoir sur quel fragment une requête sera exécutée? Heureusement, Elasticsearch a une API qui peut vous montrer les nœuds et les fragments sur lesquels une requête de recherche sera effectuée.

9.8.3. Utilisation de l’API _search_shards pour déterminer les fragments concernés par une recherche

Prenons l’exemple précédent et utilisons l’API search shards pour voir sur quels fragments la demande sera exécutée, avec et sans les valeurs de routage, comme indiqué dans la figure suivante.

Vous pouvez voir que, même s’il y a deux fragments dans l’index, lorsque la valeur de routage denver est spécifiée, seul le fragment 1 sera recherché. Vous avez effectivement réduit de moitié la quantité de données que la recherche doit traiter!

Le routage peut être utile lorsque vous utilisez des index comportant un grand nombre de fragments, mais il n’est certainement pas nécessaire pour une utilisation régulière d’Elasticsearch. Considérez-le comme un moyen de scaler plus efficacement dans certains cas et assurez-vous de le tester avant de le mettre en production.

9.8.4. Configuration du routage

Il peut également être utile de dire à Elasticsearch que vous souhaitez utiliser le routage personnalisé pour tous les documents et de vous refuser de vous permettre d’indexer un document sans valeur de routage personnalisée. Vous pouvez le configurer via le mapping. Par exemple, pour créer un index appelé event et où le routage sera requis pour chaque événement, vous pouvez utiliser le code de la figure suivante.

Il existe un autre moyen d’utiliser le routage, qui consiste à associer une valeur de routage à un alias.

9.8.5. Combinaison de routage avec des alias

Comme vous l’avez vu dans la section précédente, les alias sont une abstraction puissante et flexible au-dessus des index. Ils peuvent également être utilisés avec le routage pour appliquer automatiquement les valeurs de routage lors d’une requête ou lors de l’indexation, en supposant que l’alias pointe vers un seul index. Si vous essayez d’indexer dans un alias qui pointe sur plus d’un index, Elasticsearch renvoie une erreur car il ne sait pas dans quel index concret le document doit être indexé.

En reprenant l’exemple précédent, vous pouvez créer un alias appelé denver-events qui filtre automatiquement les événements avec le nom « denver » dans le nom et ajoute « denver » au routage lors de la recherche et de l’indexation afin de limiter le lieu d’exécution des requêtes, comme indiqué dans la figure suivante.

Vous pouvez également utiliser l’alias que vous venez de créer pour l’indexation. Lors de l’indexation avec l’alias denver-events, c’est la même chose que si les documents étaient indexés avec le paramètre de requête routing = denver. Les alias étant légers, vous pouvez en créer autant que vous le souhaitez lorsque vous utilisez un routage personnalisé afin de mieux évoluer.

9.9. RÉSUMÉ

Vous devriez maintenant mieux comprendre la façon dont les clusters Elasticsearch sont formés et comment ils se composent de plusieurs noeuds, chacun contenant un certain nombre d’index, eux-mêmes constitués de plusieurs fragments. Voici quelques-unes des choses dont nous avons parlé dans ce chapitre:

Que se passe-t-il lorsque des nœuds sont ajoutés à un cluster Elasticsearch?
Comment les nœuds master sont élus
Retrait et mise hors service des nœuds
Utilisation de l’API _cat pour connaître l’état votre cluster
Partage en excessif en fragment et son application pour anticiper la croissance future d’un cluster
Comment utiliser les alias et le routage pour la flexibilité et la mise à l’échelle d’un cluster

Au chapitre 10, nous continuerons à parler de dimensionnement dans l’optique d’améliorer les performances de votre cluster Elasticsearch.