Chapitre 11: Administrer vôtre cluster

Ce chapitre couvre

Amélioreration des paramètres de configuration par défaut
Création des templates
Monitoring de la performance
Sauvegarde et restauration d’un cluster Elasticsearch

C’est bientôt la fin. Nous avons couvert de nombreux concepts dans ce livre, et nous espérons que vous serez maintenant à l’aise avec l’utilisation de l’API d’Elasticsearch. Dans ce chapitre, vous allez l’utiliser dans le but de surveiller et d’ajuster votre cluster afin d’en améliorer les performances et d’implémenter la récupération après un crash du système.

Les développeurs et administrateurs seront éventuellement confrontés à la perspective de devoir surveiller et administrer leur cluster Elasticsearch. Que votre système soit soumis à une utilisation élevée ou modérée, il sera important pour vous de comprendre et d’identifier les goulots d’étranglement et de vous préparer en cas de défaillance du matériel ou du système.

Ce chapitre couvre les opérations d’administration de cluster Elasticsearch à l’aide de l’API REST, avec laquelle vous devriez maintenant vous sentir à l’aise. Cela vous permettra d’identifier et de résoudre les goulots d’étranglement possibles en matière de performances, grâce à une surveillance en temps réel et aux meilleures pratiques.

À cette fin, nous aborderons trois sujets principaux: l’amélioration des valeurs par défaut, la surveillance d’éventuels problèmes et l’utilisation efficace du système de sauvegarde, en partant du principe simple qu’une surveillance efficace des performances est nécessaire pour optimiser le système et que la compréhension de votre système facilitera la planification des scénarios catastrophes.

11.1. AMÉLIORATION DES CATERISTIQUES PAR DEFAUTS

Bien que la configuration prête à l’emploi d’Elasticsearch satisfasse les besoins de la plupart des utilisateurs, il est important de noter qu’il s’agit d’un système extrêmement flexible qui peut être réglé au-delà de ses paramètres par défaut pour améliorer les performances.

La plupart des utilisations d’Elasticsearch dans des environnements de production peuvent entrer dans la catégorie de la recherche occasionnelle en texte intégral, mais un nombre croissant d’installations ont tendance d’utiliser Elasticsearch en tant que source unique de données, comme agrégateurs de logs et même dans des architectures de stockage hybrides, utilisées conjointement avec d’autres types de bases de données. Ces nouvelles utilisations intéressantes ouvrent la porte à l’exploration de moyens intéressants d’optimiser les paramètres par défaut d’Elasticsearch.

11.1.1. Modèles d’index(Templates)

La création de nouveaux index et de mapping associés dans Elasticsearch est généralement une tâche simple, une fois la planification de la conception initiale terminée. Cependant, il existe certains scénarios dans lesquels des index futurs doivent être créés avec les mêmes paramètres et mapping que les précédents. Ces scénarios incluent les suivants:

Agrégation de logs – Dans cette situation, un index de log quotidien est nécessaire pour une interrogation et un stockage efficaces, un peu comme un système de rotation de logs. Un exemple courant est celui des déploiements cloud, où les systèmes distribués envoient leurs logs sur un cluster Elasticsearch central. Configurer le cluster pour gérer la création automatique de modèles(templates) de log par jour facilite l’organisation des données et facilite la recherche.
Conformité réglementaire – Dans ce cas, des blocs de données doivent être conservés ou supprimés au bout d’un certain délai pour respecter les normes de conformité, comme dans les sociétés du secteur financier où la conformité est obligatoire. Ces types de mandats exigent la tenue de registres organisés.
Multi-utilisateurs – Les systèmes qui créent de nouveaux utilisateurs de manière dynamique ont souvent besoin de compartimenter les données spécifiques aux utilisateurs. Ici l’utilisateur peut être une application, un domaine fonctionnel…etc

Les templates ont leur utilité lorsqu’un modèle éprouvé et reproductible est nécessaire pour un stockage homogène des données. La nature automatisée de la manière dont Elasticsearch applique les modèles est également une fonctionnalité attrayante.

Créer un template

Comme son nom l’indique, un modèle sera appliqué à tout nouvel index créé. Un modèle spécifique est appliqué pour les index correspondant à un pattern de dénomination prédéfini, ce qui garantit l’uniformité des paramètres d’index pour tous les index correspondants. La création d’index devra correspondre au pattern du template pour que celui ci soit appliqué. Il existe deux manières d’appliquer des templates d’index aux index nouvellement créés dans Elasticsearch:

Via l’API REST
Par un fichier de configuration

Le premier suppose un cluster en cours d’exécution; le suivant non et est souvent utilisé dans les scénarios de prédéploiement qu’un ingénieur de développement ou un administrateur système utiliserait dans un environnement de production.

Dans cette section, nous allons illustrer un template d’index simple utilisé pour l’agrégation de log. Ainsi, votre outil d’agrégation de log aura un nouvel index créé par jour. Au moment de la rédaction de ce document, Logstash était l’outil d’agrégation de log le plus populaire utilisé aux côtés d’Elasticsearch. Son intégration étant transparente, vous pouvez donc vous concentrer sur la création de modèles d’indexe via logstash.

Par défaut, Logstash effectue des appels d’API en utilisant l’horodatage quotidien ajouté au nom de l’index. par exemple, logstash-11-09-2014. En supposant que vous utilisez les paramètres par défaut d’Elasticsearch, qui autorisent la création automatique d’index, une fois que Logstash appelle votre cluster avec un nouvel événement, le nouvel index est créé avec le nom logstash-11-09-2014. Le type de document sera automatiquement mappé. Vous utiliserez d’abord la méthode de l’API REST, comme indiqué ici:

A l’aide de la commande PUT, vous demandez à Elasticsearch d’appliquer ce modèle chaque fois qu’un appel d’index correspondant au modèle logstash- * est reçu. Dans ce cas, lorsque Logstash publie un nouvel événement sur Elasticsearch et qu’un index n’existe pas sous le nom indiqué, un nouvel événement est créé à l’aide de ce template.

Ce modèle peut aller également un peu plus loin avec l’application d’un alias, vous pouvez donc regrouper tous ces index sous un mois donné. Vous devrez renommer l’index manuellement tous les mois, mais cela offre un moyen pratique de regrouper les index de log par mois.

Templates configurés sur le système de fichiers

Si vous souhaitez que les modèles soient configurés sur le système de fichiers, ce qui facilite parfois la gestion de la maintenance, cette option existe. Les fichiers de configuration doivent suivre ces règles simples:

Les configurations de templates doivent être au format JSON. Pour plus de commodité, nommez-les avec une extension .json: <FILENAME>.json.
Les définitions de templates doivent être situées à l’emplacement de configuration Elasticsearch, dans un répertoire templates. Ce chemin est défini dans le fichier de configuration du cluster (elasticsearch.yml) en tant que path.conf; Par exemple, <ES_HOME> / config / templates / *.
Les définitions de templates doivent être placées dans les répertoires des nœuds pouvant être élus comme maîtres.

En utilisant la définition de template précédente, votre fichier template.json ressemblera à ceci:

Tout comme pour la définition via l’API REST, ce modèle est appliqué à tous les index correspondant au modèle logstash- *.

Fusion de templates multiples

Elasticsearch vous permet également de configurer plusieurs modèles avec des paramètres différents. Vous pouvez ainsi configurer un template pour gérer les logs par mois et un autre qui stockera tous les logs dans un index, comme l’indique la figure suivante.

Dans l’exemple précédent, le modèle le plus haut sera responsable des logs spécifiques à novembre, car il correspond au modèle de noms d’index commençant par « logstash-09-« . Le second modèle agit comme un fourre-tout, agrégeant tous les index de logs et contenant même un mapping différent sur la date.

Une chose à noter à propos de cette configuration est l’attribut d’ordre. Cet attribut implique que le numéro d’ordre le plus bas sera appliqué en premier, le numéro d’ordre le plus élevé le remplaçant ensuite. De ce fait, les paramètres des deux modèles sont fusionnés, ce qui a pour effet que tous les logs de novembre ne disposent pas du champ date.

Récupération des templates d’index

Pour récupérer une liste de tous les templates, une API existe:

De même, vous pouvez récupérer un ou plusieurs templates individuels par leur nom:

Ou vous pouvez récupérer tous les noms de modèles correspondant à un modèle:

Suppression de templates d’index

La suppression d’un template est obtenue à l’aide de son nom. Dans la section précédente, nous avons défini un modèle en tant que tel:

Pour supprimer ce modèle, utilisez le nom du modèle dans la requête:

11.1.2. Mapping par défaut

Comme vous l’avez appris au chapitre 2, les mapping vous permettent de définir les champs spécifiques, leurs types et même la manière dont Elasticsearch les interprétera et les stockera. De plus, vous avez appris comment Elasticsearch prend en charge le mapping dynamique au chapitre 3, éliminant ainsi la nécessité de définir vos mappings au moment de la création de l’index; à la place, ces mappings sont générés dynamiquement par le contenu du document initial que vous indexez.

Nous venons de vous montrer comment utiliser les templates d’index pour gagner du temps et ajouter une uniformité à des types de données similaires. Les mappings par défaut à les mêmes effets bénéfiques et peuvent être assimilés au templating. Les mappings par défaut sont souvent utilisés lorsqu’on a plusieurs indexes avec des champs similaires. La spécification d’un mapping par défaut supprime la nécessité de devoir le spécifier de manière répétée dans tous les indexes.

La mapping n’est pas rétroactif

Notez que la spécification d’un mapping par défaut ne s’applique pas rétroactivement. Les mappings par défaut ne sont appliqués qu’aux types nouvellement créés.

Prenons l’exemple suivant, dans lequel vous souhaitez spécifier un paramètre par défaut pour le stockage de l’attribut _source pour tous vos mappings, à l’exception du type Person:

Dans ce cas, tous les nouveaux mapping stockeront par défaut l’attribut _source, mais pas pour le type Person. Notez que vous pouvez remplacer ce comportement dans les spécifications de mappings individuels.

Mappages dynamiques
Elasticsearch utilise par défaut un mappage dynamique: la possibilité de déterminer le type de données pour les nouveaux champs d’un document. Vous l’avez peut-être constaté lors de la première indexation d’un document et vous avez remarqué qu’Elasticsearch avait créé dynamiquement un mappage pour celui-ci, ainsi que le type de données de chacun des champs. Vous pouvez modifier ce comportement en demandant à Elasticsearch d’ignorer les nouveaux champs ou même de lever des exceptions sur des champs inconnus. Normalement, vous souhaiterez limiter l’ajout de nouveaux champs afin d’empêcher la pollution des données et d’aider à garder le contrôle de la définition du schéma.

Mappings dynamiques

Elasticsearch utilise par défaut un mapping dynamique: la possibilité de déterminer le type de données pour les nouveaux champs d’un document. Vous l’avez peut-être constaté lors de la première indexation d’un document et vous avez remarqué qu’Elasticsearch avait créé dynamiquement un mapping pour celui-ci, ainsi que le type de données de chacun des champs. Vous pouvez modifier ce comportement en demandant à Elasticsearch d’ignorer les nouveaux champs ou même de lever des exceptions sur des champs inconnus. Normalement, vous souhaiterez limiter l’ajout de nouveaux champs afin d’empêcher la pollution des données et d’aider à garder le contrôle de la définition du schéma.

Désactivation du mapping dynamique

Notez également que vous pouvez désactiver la création dynamique de nouveaux mappings en définissant index.mapper.dynamic sur false dans votre configuration elasticsearch.yml.

La figure suivante montre comment ajouter un mapping dynamique.

Le premier mapping limite la création de nouveaux champs dans le mapping de Person. Si vous essayez d’insérer un document avec un champ non mappé, Elasticsearch répondra par une exception sans indexer le document. Par exemple, essayez d’indexer un document avec un champ first_name:

Voici la réponse:

Mapping dynamique et création de templates

Cette section ne serait pas complète si nous ne couvrions pas la manière dont le mapping dynamique et les templates dynamiques fonctionnent ensemble, vous permettant ainsi d’appliquer différents mapping en fonction du nom du champ ou du type de données.

Nous avons déjà expliqué comment utiliser des templates d’index pour définir automatiquement les index nouvellement créés pour un ensemble uniforme d’index et de mappings. Nous pouvons développer cette idée maintenant en incorporant ce que nous avons vu sur le mapping dynamique.

L’exemple suivant résout un problème simple lorsqu’il s’agit de données comprenant des UUID. Ce sont des chaînes alphanumériques uniques contenant des séparateurs de trait d’union, telles que « b20d5470-d7b4-11e3-9fa6-25476c6788ce« . Vous ne souhaitez pas qu’Elasticsearch les analyse avec un analyseur par défaut, car il diviserait l’UUID en trait d’union lors de la création des jetons d’index. Vous voulez pouvoir rechercher par la chaîne complète UUID. Elasticsearch doit donc stocker la chaîne entière sous forme de jeton. Dans ce cas, vous devez indiquer à Elasticsearch de ne pas analyser les champs de chaîne dont le nom se termine par « _uuid« :

Dans cet exemple, le template dynamique est utilisé pour mapper de manière dynamique les champs correspondant à un certain nom et type, ce qui vous permet de mieux contrôler la manière dont vos données sont stockées et rendues consultables par Elasticsearch. En guise de remarque supplémentaire, vous pouvez utiliser le mot clé path_match ou path_unmatch, qui vous permet de faire correspondre ou non le template dynamique à l’aide de la notation par point(.), par exemple si vous souhaitez faire correspondre quelque chose comme person. *. email. En utilisant cette logique, vous pouvez voir une correspondance sur une structure de données telle que celle-ci:

Les templates dynamiques constituent une méthode pratique pour automatiser certains des aspects les plus fastidieux de la gestion Elasticsearch. Ensuite, nous explorerons la notion de l’allocation.

11.2 SENSIBILISATION À L’ALLOCATION(Allocation awareness)

Cette section met à nue la topologie de cluster afin de réduire les principaux points de défaillance et d’améliorer les performances en utilisant le concept de connaissance de l’allocation awareness. L’allocation awareness est définie comme la de définir avec précision l’endroit où placer les replicas de données. Ainsi Elasticsearch pourra distribuer intelligemment les données de réplica sur un cluster.

11.2.1. Allocation basée sur les fragments

La conscience d’allocation (allocation awareness) vous permet de configurer l’allocation de fragments à l’aide d’un paramètre défini par l’utilisateur. Il s’agit d’une pratique courante dans les déploiements Elasticsearch, car elle réduit les risques de créer un point de défaillance unique en veillant à ce que les données soient uniformément réparies dans la topologie du réseau. Vous pouvez également bénéficier d’opérations de lecture plus rapides, car les nœuds déployés sur le même rack physique auront potentiellement l’avantage de la proximité de ne pas devoir passer par le réseau.

L’activation de la conscience d’allocation est obtenue en définissant une clé de regroupement et en la définissant dans les nœuds appropriés. Par exemple, vous pouvez éditer elasticsearch.yml comme suit:

Note: Vous pouvez attribuer plus d’une valeur à l’attribut awareness.

cluster.routing.allocation.awareness.attributes: rack, groupe, zone

En utilisant la définition précédente, vous allez segmenter vos fragments à l’aide du paramètre de conscience rack. Vous modifiez le fichier elasticsearch.yml pour chacun de vos nœuds, en définissant la valeur comme vous le souhaitez pour la configuration de votre réseau. Notez que Elasticsearch vous permet de définir des métadonnées sur des nœuds. Dans ce cas, la clé de métadonnées sera votre paramètre de connaissance de l’allocation:

Une simple illustration avant-après peut aider dans ce cas. La figure 11.1 montre un cluster avec les paramètres d’allocation par défaut.

Ce cluster est affecté par le fait que les données de fragment primaires et de fragments de réplica se trouvent sur le même rack. Avec le paramètre de conscience d’allocation, vous pouvez supprimer ce risque, comme illustré à la figure 11.2.

Avec la conscience d’allocation, les fragments primaires n’ont pas été déplacés, mais les réplicas ont été déplacés vers des nœuds avec une valeur de paramètre node.rack différente. La répartition des fragments est une caractéristique pratique qui assure de ne pas avoir un seul point de défaillance central. Du coup en cas de crash, le système devient plus robuste. Une utilisation courante consiste à séparer la topologie du cluster par emplacement, par rack ou même par machine virtuelle.

Nous examinerons ensuite l’affectation forcée avec un exemple concret sur les zones AWS.

11.2.2. Conscience d’allocation forcée

La conscience d’allocation forcée est utile lorsque vous connaissez à l’avance le groupe de valeurs et que vous souhaitez limiter le nombre de réplicas pour un groupe donné. Un exemple concret d’utilisation courante de ce type d’application est l’allocation entre zones sur Amazon Web Services ou d’autres fournisseurs de cloud offrant des fonctionnalités multizones. Le cas d’utilisation est simple: limitez le nombre de réplicas dans une zone si une autre zone tombe en panne ou est inaccessible. Ce faisant, vous réduisez le risque de surchager un noeud avec les répliques d’un autre groupe.

Par exemple, dans ce cas d’utilisation, vous souhaitez appliquer l’allocation au niveau de la zone. Tout d’abord, vous spécifiez votre attribut, zone, comme vous le faisiez auparavant. Ensuite, vous ajoutez des dimensions à ce groupe: us-east et us-west. Dans votre elasticsearch.yml, vous ajoutez les éléments suivants:

Étant donné ces paramètres, imaginons ce scénario réel. Supposons que vous démarriez un ensemble de nœuds dans la région Est avec node.zone: us-east. Vous utiliserez les valeurs par défaut ici. On a ici un index avec cinq fragments primaires et un réplica. Comme il n’y a pas d’autres valeurs de zone, seules les partitions principales de vos index seront allouées.

Ce que vous faites ici consiste à limiter les répliques à être aloués uniquement sur les nœuds sans valeur. Si vous deviez démarrer votre cluster de la région Ouest avec node.zone, les répliques us-west lui seraient allouées. Aucune réplique n’existe pour les nœuds définis en tant que node.zone: us-east. Idéalement, vous feriez la même chose sur node.zone: us-west, vous assurant ainsi que les répliques n’existent jamais au même endroit. Gardez à l’esprit que si vous perdez la connectivité avec nous-ouest, aucune réplique ne sera jamais créée sur nous-est, ou inversement.

La connaissance de l’allocation nécessite une certaine planification à l’avance, mais si l’allocation ne fonctionne pas comme prévu, ces paramètres peuvent tous être modifiés au moment de l’exécution à l’aide de l’API Cluster Settings. Ils peuvent être persistants:

L’allocation de cluster permet de rendre un cluster encore plus évolutif et tolérant aux pannes.

Maintenant que nous avons exploré certains des réglages les plus précis que vous pouvez apporter aux paramètres par défaut d’Elasticsearch avec l’allocation de fragments, voyons comment monitorer l’intégrité générale de votre cluster pour détecter les problèmes de performances.

11.3. SURVEILLANCE DES BOTTLENECKS

Elasticsearch fournit une multitude d’informations via ses API: consommation de mémoire, appartenance à un nœud, distribution de fragments et performances d’E / S. Les API de cluster et de nœud vous aident à évaluer la santé et les mesures de performances globales de votre cluster. Comprendre les données de diagnostic du cluster et être en mesure d’évaluer son état général vous alertera des goulots d’étranglement liés aux performances, tels que les fragments non attribués et les nœuds manquants, afin que vous puissiez facilement les résoudre.

11.3.1. Vérification de la santé du cluster

L’API health de cluster fournit une vue à la fois pratique et grossière de la santé globale de votre cluster, de vos index et de vos fragments. C’est normalement la première étape pour être alerté et diagnostiquer un problème susceptible de se produire activement dans votre cluster. La figure suivante montre comment l’utiliser pour vérifier l’état global du cluster.

Et la réponse:

Si vous prenez la réponse montrée ici à première vue, vous pouvez en déduire beaucoup sur la santé générale et l’état du cluster, mais il ya beaucoup plus d’informations ici qu’il n’y parait au premier coup d’oeil. Examinons un peu plus en détail la signification des trois derniers indicateurs du code: relocating_shards, initializing_shards et unassigned_shards.

relocating_shards: un nombre supérieur à zéro signifie qu’Elasticsearch déplace des fragments de données sur le cluster pour améliorer l’équilibre et le basculement(faileover). Cela se produit généralement lors de l’ajout d’un nouveau nœud, du redémarrage d’un nœud défaillant ou de la suppression d’un nœud, ce qui en fait une occurrence temporaire.
initializing_shards: ce nombre sera supérieur à zéro lorsque vous venez de créer un nouvel index ou de redémarrer un nœud.
unassigned_shards – La raison la plus courante pour que cette valeur soit supérieure à zéro est le fait d’avoir des réplicas non attribués. Le problème est courant dans les environnements de développement, où un index à un seul nœud a un index défini comme ayant la valeur par défaut, cinq fragments et un réplica. Dans ce cas, il y aura cinq réplicas non attribués.

Comme vous l’avez vu à partir de la première ligne de sortie, l’état du cluster est vert. Il arrive parfois que cela ne soit pas le cas, comme dans le cas de nœuds ne pouvant pas démarrer ou s’éloignant du cluster, et bien que la valeur de statut ne donne qu’une idée générale de la santé du cluster, il est utile de comprendre signification de ces valeurs d’état pour les performances du cluster:

Vert: les fragments primaires et de répliques sont entièrement fonctionnels et distribués.
Jaune— Normalement, il s’agit d’un signe d’un fragment de réplique manquant. La valeur unassigned_ shards est probablement supérieure à zéro à ce stade, ce qui rend la nature distribuée du cluster instable. Une perte supplémentaire de fragments pourrait entraîner une perte de données critique. Recherchez les nœuds qui ne sont pas initialisés ou qui ne fonctionnent pas correctement.
Rouge— Il s’agit d’un état critique dans lequel une partition principale du cluster est introuvable, interdisant les opérations d’indexation sur cette partition et entraînant des résultats de requête incohérents. Là encore, un ou plusieurs nœuds sont probablement absents du cluster.

Forts de cette connaissance, vous pouvez maintenant examiner un cluster avec un statut jaune et tenter de localiser la source du problème:

Étant donné cet appel et cette réponse de l’API, vous voyez que le cluster est à présent en jaune et, comme vous l’avez déjà appris, le coupable est probablement la valeur unassigned_shards supérieure à 0. L’API health du cluster fournit une opération plus fine qui vous permettent de mieux diagnostiquer le problème. Dans ce cas, vous pouvez examiner plus en profondeur les index affectés par les fragments non affectés en ajoutant le paramètre level:

Le cluster à un seul nœud rencontre des problèmes car Elasticsearch tente d’allouer des fragments de répliques sur le cluster, mais ne peut pas le faire car un seul nœud est en cours d’exécution. Ceci conduit à ce que les fragments de répliques ne soient assignés nulle part et donc à un statut jaune dans le cluster, comme le montre la figure 11.3.

Comme vous pouvez le constater, une solution simple consiste à ajouter un nœud au cluster pour qu’Elasticsearch puisse ensuite affecter les fragments de réplica à cet emplacement. S’assurer que tous vos nœuds sont en cours d’exécution et accessibles est le moyen le plus simple de résoudre le problème de statut jaune.

11.3.2. CPU: logs lents, threads chauds et pools de threads

La surveillance de votre cluster Elasticsearch peut occasionnellement donner lieu à des pics d’utilisation du processeur ou à des ralentissements des performances dus à une utilisation du processeur constamment élevée ou à des threads bloqués/en attente. Cette section vous aidera à démystifier certains de ces goulots d’étranglement potentiels et vous fournira les outils nécessaires pour identifier et résoudre ces problèmes.

Logs lents

Elasticsearch fournit deux fichier de logs permettant d’isoler des opérations lentes faciles à configurer dans votre fichier de configuration du cluster: slow query log et slow index log. Par défaut, les deux fichiers de logs sont désactivés. La sortie du journal est limitée au niveau du fragment. C’est-à-dire qu’une opération peut représenter plusieurs lignes dans le fichier de log correspondant. L’avantage de la journalisation au niveau des fragments est que vous serez mieux en mesure d’identifier un fragment problématique et par conséquent un nœud avec le contenu du fichier de log, comme illustré ci-dessous. Il est important de noter à ce stade que ces paramètres peuvent également être modifiés à l’aide de l’endpoint ‘{index_name} / _ settings’:

Comme vous pouvez le constater, vous pouvez définir des seuils pour les deux phases d’une recherche: la requête et l’extraction. Les niveaux de journalisation (warn, info, debug, trace) vous permettent de contrôler plus précisément le level qui sera utilisé, ce qui est pratique lorsque vous souhaitez simplement faire un grep de votre fichier de log. Le fichier journal que vous allez générer est configuré dans votre fichier logging.yml, ainsi que d’autres fonctionnalités de journalisation, comme indiqué ci-dessous:

La sortie typique sur un fichier slow log apparaîtra comme ceci:

Slow query log

Les points importants de la requête, qui vous intéressent pour identifier les problèmes de performances, sont les temps de requête: took[## ms]. De plus, il est utile de connaître les fragments et les index impliqués, et ceux-ci sont identifiables par la notation [index] [shard_number]; dans ce cas, c’est [streamglue] [4].

Slow index log

Il est utile pour découvrir les goulots d’étranglement lors des opérations d’index. Ses seuils sont définis dans votre fichier de configuration de cluster ou via l’API de mise à jour des paramètres d’index, un peu comme le slow log précédent:

Comme auparavant, la sortie de toute opération d’index respectant les valeurs de seuil sera écrite dans votre fichier de log et vous verrez le [index][numéro_donne] ([bitbucket] [2]) et la durée (took[4.5ms]) de l’opération index:

Découvrir où se trouvent vos requêtes lentes et vos appels à l’index contribuera grandement à résoudre les problèmes de performances d’Elasticsearch. Si vous laissez les performances lentes s’exécuter trop souvent, vous risquez de provoquer une défaillance en cascade sur l’ensemble de votre cluster, ce qui entraînerait son crash complet.

API Hot_threads

Si vous avez déjà rencontré une utilisation élevée du processeur sur votre cluster, vous trouverez l’API hot_threads utile dans l’identification de processus spécifiques pouvant être bloqués et à l’origine du problème. L’API hot_threads fournit une liste des threads bloqués pour chaque nœud de votre cluster. Notez que contrairement aux autres API, hot_threads ne renvoie pas de code JSON, mais renvoie du texte mis en forme:

Voici l’exemple de sortie:

La sortie de l’API hot_threads nécessite une analyse syntaxique pour être correctement comprise. Voyons donc quelles informations elle fournit sur les performances du processeur:

La ligne du haut de la réponse comprend l’identification du nœud. Étant donné que le cluster a probablement plus d’un nœud, il s’agit de la première indication du processeur auquel les informations de thread appartiennent:

Vous pouvez voir ici que 37,5% du traitement de la CPU est consacré à un fil de recherche. C’est la clé de votre compréhension, car vous pouvez ensuite affiner vos requêtes de recherche pouvant être à l’origine de la pointe du processeur. Attendez-vous à ce que la valeur de recherche ne soit pas toujours présente. Elasticsearch peut présenter ici d’autres valeurs telles que fusion, index, etc., identifiant l’opération en cours sur ce thread. Vous savez que cela est lié au processeur en raison de l’identificateur d’utilisation du processeur. Les autres identificateurs de sortie possibles ici sont l’utilisation de bloc, qui identifie les threads bloqués, et l’attente d’utilisation pour les threads dans un état WAITING:

La dernière ligne précédant la stack trace vous indique qu’Elasticsearch a découvert que ce thread contenant la même stack trace était présent dans 10 des 10 captures prise en quelques millisecondes.

Bien entendu, il est utile de savoir comment Elasticsearch rassemble les informations de l’API hot_threads pour la présentation. Toutes les quelques millisecondes, Elasticsearch collecte des informations sur la durée d’un thread, son état (WAITING / BLOCKED) et la durée de l’attente ou du blocage pour chaque thread. Après un intervalle défini (500 ms par défaut), Elasticsearch effectue un deuxième passage de la même opération de collecte d’informations. Lors de chacune de ces passes, il prend des captures de chaque stack trace. Vous pouvez optimiser le processus de collecte d’informations en ajoutant des paramètres à l’appel de l’API hot_threads:

Type— L’un des cpu, wait ou block. Type d’état du thread.
Intervalle— Temps d’attente entre les première et deuxième vérifications. La valeur par défaut est 500 ms.
Threads— Nombre de threads «chauds» à afficher.

Pools de threads

Chaque nœud d’un cluster gère des pools de threads pour une meilleure gestion de l’utilisation du CPU et de la mémoire. Elasticsearch cherchera à gérer les pools de threads pour obtenir les meilleures performances sur un nœud donné. Dans certains cas, vous devrez configurer et remplacer manuellement la gestion des pools de threads pour éviter les scénarios d’échec en cascade. Sous une charge importante, Elasticsearch peut générer des milliers de threads pour gérer les demandes, ce qui entraîne l’échec de votre cluster. Savoir ajuster les pools de threads nécessite une connaissance approfondie de la manière dont votre application utilise les API Elasticsearch. Par exemple, une application qui utilise principalement l’API d’indexation bulk doit disposer d’un ensemble de threads plus important. Sinon, les requêtes d’indexation en masse risquent d’être surchargées et les nouvelles requêtes seront ignorées.

Vous pouvez ajuster les paramètres du pool de threads dans la configuration de votre cluster. Les pools de threads sont divisés par opération et configurés avec une valeur par défaut en fonction du type d’opération. Par souci de brièveté, nous n’en énumérons que quelques-uns:

bulk— Définit par défaut une taille fixe en fonction du nombre de processeurs disponibles pour toutes les opérations avec l’API bulk.
index: la taille par défaut est une taille fixe en fonction du nombre de processeurs disponibles pour les opérations d’index et de suppression.
search— La taille par défaut est trois fois plus grande que le nombre de processeurs disponibles pour les opérations de comptage et de recherche.

En regardant votre configuration elasticsearch.yml, vous pouvez voir que vous pouvez augmenter la taille de la file d’attente du pool d’unités d’exécution et le nombre de pools d’unités d’exécution pour toutes les opérations en bloc. Il convient également de noter ici que l’API Cluster Settings vous permet de mettre à jour ces paramètres sur un cluster en cours d’exécution:

Notez qu’il existe deux types de pool de threads, fixe et cache. Un type de pool de threads fixe contient un nombre fixe de threads pour gérer les requêtes avec une file d’attente de sauvegarde pour les requêtes en attente. Dans ce cas, le paramètre queue_size contrôle le nombre de threads et correspond par défaut à 5 fois le nombre de cœurs. Un type de pool de threads de cache est illimité, ce qui signifie qu’un nouveau thread sera créé s’il y a des requêtes en attente.

Armés de l’API Health du cluster, des fichiers de slow query, slow index et d’informations sur les threads, vous pouvez diagnostiquer plus facilement les opérations gourmandes en ressources et les goulots d’étranglement. La prochaine section traitera des informations centrées sur la mémoire, ce qui peut aider au diagnostic et au réglage des problèmes de performances Elasticsearch.

11.3.3. Mémoire: taille du tas, caches de filtres et champs

Cette section explore la gestion et le réglage efficaces de la mémoire pour les clusters Elasticsearch. De nombreuses opérations d’agrégation et de filtrage sont liées à la mémoire dans Elasticsearch. Par conséquent, savoir comment améliorer efficacement les paramètres de gestion de la mémoire par défaut dans Elasticsearch et la machine virtuelle Java sous-jacente sera un outil utile pour la mise à l’échelle de votre cluster.

Taille du tas

Elasticsearch est une application Java qui s’exécute sur la machine virtuelle Java (JVM). Elle est donc soumise à la gestion de la mémoire par le garbage collector. Le concept derrière le garbage collector est simple: il est déclenché lorsque la mémoire est insuffisante, efface les objets qui ont été déréférencés et libère de la mémoire pour que les autres applications JVM puissent l’utiliser. Ces opérations de récupération de place prennent beaucoup de temps et provoquent des pauses du système. Charger trop de données en mémoire peut également entraîner des exceptions OutOfMemory, ce qui entraîne des crash et des résultats imprévisibles – un problème que même le garbage collector ne peut pas résoudre.

Pour que Elasticsearch soit rapide, certaines opérations sont effectuées en mémoire en raison d’un meilleur accès aux données de champ. Par exemple, Elasticsearch ne charge pas uniquement les données de zone pour les documents correspondant à votre requête; il charge des valeurs pour tous les documents de votre index. Cela rend votre requête ultérieure beaucoup plus rapide grâce à un accès rapide aux données en mémoire.

Le segment de mémoire de la machine virtuelle Java représente la quantité de mémoire allouée aux applications exécutées sur la machine virtuelle Java. Pour cette raison, il est important de comprendre comment ajuster ses performances afin d’éviter les effets néfastes des pauses durant la récupération de place et des exceptions OutOfMemory. Vous définissez la taille du segment de mémoire de la machine virtuelle Java via la variable d’environnement HEAP_SIZE. Les deux règles d’or à garder à l’esprit lors de la définition de la taille de votre tas sont les suivantes:

Maximum de 50% de la mémoire vive système disponible – L’allocation d’une quantité excessive de mémoire système à la machine virtuelle Java signifie que la mémoire allouée au cache du système de fichiers sous-jacent est réduite, ce que Lucene utilise fréquemment.
Maximum de 32 Go de RAM – La JVM modifie son comportement lorsque plus de 32 Go sont alloués en n’utilisant pas de pointeur d’objet ordinaire (OOP) compressé. Cela signifie que définir une taille de segment de mémoire inférieure à 32 Go utilise environ la moitié de l’espace mémoire.

Cache de filtre et de champs

Les caches jouent un rôle important dans les performances d’Elasticsearch, permettant l’utilisation efficace des filtres, des facettes et du tri des champs d’index. Cette section explorera deux de ces caches: le cache de filtres et le cache de données de champ.

Le cache de filtres stocke les résultats des filtres et des requêtes en mémoire. Cela signifie qu’une requête initiale avec un filtre appliqué aura ses résultats stockés dans le cache de filtres. Chaque requête ultérieure avec ce filtre appliqué utilisera les données du cache et n’ira pas sur le disque pour les données. Le cache de filtre réduit efficacement l’impact sur le processeur et les E / S et accélère les résultats des requêtes filtrées.

Elasticsearch propose deux types de caches de filtres:

Cache de filtre de niveau de l’index
Cache de filtre de niveau du noeud

Le cache de filtre au niveau du nœud est le paramètre par défaut et celui que nous couvrirons. Le cache de filtre au niveau de l’index n’est pas recommandé car vous ne pouvez pas prédire l’emplacement de l’index dans le cluster et par conséquent, ne pas prévoir l’utilisation de la mémoire.

Le cache de filtre au niveau du nœud est un type de cache LRU (le moins récemment utilisé: le plus anciennement utilisé). Cela signifie que lorsque le cache est plein, les entrées de cache les moins utilisées sont d’abord détruites pour laisser la place à de nouvelles entrées. Choisissez ce type de cache en définissant index.cache.filter.type sur node, ou ne le définissez pas du tout. c’est la valeur par défaut. Vous pouvez maintenant définir la taille avec la propriété indices.cache.filter.size. Il faudra soit un pourcentage de mémoire (20%) à allouer, soit une valeur statique (1024 Mo) dans votre configuration elasticsearch.yml pour le nœud. Notez qu’une propriété de pourcentage utilise le segment de mémoire maximal du noeud comme valeur totale à partir de laquelle calculer.

Cache de données de champs

Le cache de données de champ est utilisé pour améliorer les temps d’exécution des requêtes. Elasticsearch charge les valeurs de champ en mémoire lorsque vous exécutez une requête et conserve ces valeurs dans le cache de données de champ pour les demandes ultérieures. La création de cette structure en mémoire étant une opération coûteuse, vous ne souhaitez pas qu’Elasticsearch l’exécute à chaque requête. Les gains de performances sont donc perceptibles. Par défaut, il s’agit d’un cache non lié, ce qui signifie qu’il augmentera jusqu’à déclencher le disjoncteur de données de champ(circuit breaker) (traité dans la section suivante). En spécifiant une valeur pour le cache de données de champ, vous indiquez à Elasticsearch d’expulser les données de la structure une fois la limite supérieure atteinte.

Votre configuration doit inclure une propriété index.fielddata.cache.size pouvant être définie sur une valeur en pourcentage (20%) ou statique (16 Go). Ces valeurs représentent le pourcentage ou le segment statique de l’espace de tas du noeud à utiliser pour le cache.

Pour récupérer l’état actuel du cache de données de champ, certaines API pratiques sont disponibles:

Par noeud

Par index

Par Noed et Index

Spécifier field = * renverra tous les noms et valeurs de champs. La sortie de ces API ressemble à ce qui suit:

Ces opérations vont décomposer l’état actuel du cache. Prenez note du nombre d’expulsions. Les expulsions sont une opération coûteuse et un signe que le cache de données de champ est peut-être défini sur une valeur trop petite.

Disjoncteur(Circuit breaker)

Comme indiqué dans la section précédente, le cache de données de champ peut croître au point de provoquer une exception OutOfMemory. Cela est dû au fait que la taille des données de champ est calculée une fois les données chargées. Pour éviter de tels événements, Elasticsearch fournit des disjoncteurs.

Les disjoncteurs sont des limites artificielles imposées pour aider à réduire les risques d’exception OutOfMemory. Ils effectuent une introspection des des données de champs demandés par une requête pour déterminer si le chargement des données dans le cache repoussera la taille totale au-dessus de la limite de la taille du cache. Elasticsearch propose deux disjoncteurs, ainsi qu’un disjoncteur parent qui limite la quantité totale de mémoire que tous les disjoncteurs peuvent utiliser:

indices.breaker.total.limit: 70% du tas par défaut. N’autorise pas les données de terrain et demande aux disjoncteurs de dépasser cette limite.
indices.breaker.fielddata.limit: 60% du tas par défaut. N’autorisez pas le cache de données de champ à dépasser cette limite.
indices.breaker.request.limit: la valeur par défaut est 40% du tas. Contrôle la fraction de taille du segment de mémoire allouée aux opérations telles que la création d’un compartiment d’agrégation.

La règle d’or des paramètres d’un circuit breaker doit être conservatrice dans ses valeurs, car les caches contrôlés par le disjoncteur doivent partager de l’espace mémoire avec les mémoires tampons, le cache de filtre et d’autres utilisations de la mémoire Elasticsearch.

Éviter les échanges

Les systèmes d’exploitation utilisent le processus de permutation pour écrire des pages mémoires sur un disque. Ce processus se produit lorsque la quantité de mémoire disponible n’est pas suffisante pour le système d’exploitation. Lorsque le système d’exploitation a besoin des pages permutées, elles sont chargées dans la mémoire pour pouvoir être utilisées. L’échange est une opération coûteuse et doit être évité.

Elasticsearch conserve beaucoup de données et de caches nécessaires à l’exécution, comme le montre la figure 11.4. Par conséquent, des opérations de disque coûteuses en écriture et en lecture auront un impact important sur un cluster en cours d’exécution. Pour cette raison, nous allons montrer comment désactiver le swapping pour des performances plus rapides.

La méthode la plus efficace pour désactiver le swapping Elasticsearch consiste à définir bootstrap .mlockall sur true dans le fichier elasticsearch.yml. Ensuite, vous devez vérifier que le paramètre fonctionne. En exécutant Elasticsearch, vous pouvez consulter les logs pour un avertissement ou simplement demander un statut en direct:

Exemple d’erreur dans les logs:

Requête API

Réponse

Si l’avertissement est visible dans le fichier de log ou si la vérification de l’état a pour résultat que mlockall est défini sur false, vos paramètres ne fonctionnent pas. Des droits d’accès insuffisants pour l’utilisateur exécutant Elasticsearch sont la raison la plus courante pour laquelle le nouveau paramètre n’a pas été pris en compte. Ceci est normalement résolu en exécutant ulimit -l unlimited à partir du shell en tant qu’utilisateur root. Il sera nécessaire de redémarrer Elasticsearch pour que ces nouveaux paramètres soient appliqués.

11.3.4. Caches OS

Elasticsearch et Lucene exploitent énormément le cache du système de fichiers du système d’exploitation en raison des segments immuables de Lucene. Lucene est conçu pour exploiter le cache du système de fichiers du système d’exploitation sous-jacent pour les structures de données en mémoire. Les segments de Lucene sont stockés dans des fichiers individuels immuables. Les fichiers immuables sont considérés comme compatibles avec le cache, et le système d’exploitation sous-jacent est conçu pour conserver les segments « actifs » en mémoire pour un accès plus rapide. L’effet final est que les petits index ont tendance à être entièrement mis en cache par votre système d’exploitation et deviennent rapidement sans disque.

En raison de l’utilisation intensive par Lucene du cache du système de fichiers du système d’exploitation et de la recommandation précédente de définir le segment de mémoire JVM sur la moitié de la mémoire physique, vous pouvez compter sur Lucene pour utiliser la majeure partie de la moitié restante pour la mise en cache. Pour cette simple raison, il est considéré comme la meilleure pratique de conserver les index les plus souvent utilisés sur des machines plus rapides. L’idée est que Lucene gardera en mémoire des segments de données chauds pour un accès très rapide, ce qui est plus facile à réaliser sur des machines disposant de moins de mémoire de tas alloué. Mais pour ce faire, vous devez affecter des index spécifiques à vos nœuds plus rapides en utilisant le routage.

Tout d’abord, vous devez attribuer un attribut spécifique, une balise, à tous vos nœuds. Chaque nœud a une valeur unique attribuée à la balise d’attribut; par exemple, node.tag: mynode1 ou node.tag: mynode2. En utilisant les paramètres individuels du nœud, vous pouvez créer un index qui ne se déploiera que sur les nœuds ayant des valeurs de balises spécifiques. N’oubliez pas que le but de cet exercice est de vous assurer que votre nouvel index occupé n’est créé que sur des nœuds disposant de plus de mémoire vive que Lucene peut utiliser à bon escient. Pour ce faire, votre nouvel index, myindex, sera désormais créé uniquement sur les nœuds dont les balises sont définies sur mynode1 et mynode2, à l’aide de la commande suivante:

En supposant que ces noeuds spécifiques aient une allocation de mémoire supérieure à celle des tas, Lucene mettra en cache les segments en mémoire, ce qui entraînera un temps de réponse beaucoup plus rapide pour votre index que l’alternative consistant à rechercher des segments sur le disque.

11.3.5. Limitation de magasin(Store throttling)

Apache Lucene stocke ses données dans des fichiers segmentés immuables sur le disque. Les fichiers immuables sont par définition écrits une seule fois par Lucene mais lus plusieurs fois. Les opérations de fusion fonctionnent sur ces segments car de nombreux segments sont lus simultanément lorsqu’un nouveau est écrit. Bien que ces opérations de fusion ne gênent généralement pas beaucoup le système, les systèmes à faibles E/S peuvent être affectés lorsque des opérations de fusion, d’indexation et de recherche se déroulent simultanément. Heureusement, Elasticsearch fournit des fonctionnalités de limitation permettant de contrôler la quantité d’E/S utilisée.

Vous pouvez configurer la limitation au niveau du nœud et au niveau de l’index. Au niveau du nœud, les paramètres de configuration de limitation s’appliquent à l’ensemble du nœud, mais au niveau de l’index, la configuration de limitation ne prend effet que sur les index spécifiés.

La limitation au niveau du noeud est configurée à l’aide de la propriété index.store.throre.throttle.type avec les valeurs possibles none, merge et all. La valeur de fusion indique à Elasticsearch de limiter les E/S pour la fusion des opérations sur l’ensemble du nœud, ce qui signifie chaque fragment sur ce nœud. La valeur all appliquera les limites de limitation à toutes les opérations pour tous les fragments sur le nœud. La limitation au niveau de l’index est configurée de la même manière mais utilise à la place la propriété index.store.throttle.type. De plus, il permet de définir une valeur de nœud, ce qui signifie qu’il appliquera la limitation à l’ensemble du nœud.

Que vous souhaitiez implémenter une limitation au niveau du nœud ou de l’index, Elasticsearch fournit une propriété permettant de définir le nombre maximal d’octets par seconde que les E/S utiliseront. Pour la limitation au niveau du noeud, utilisez index.store.throttle.max_bytes_per_sec, et pour la limitation au niveau de l’index, utilisez index.store.throttle.max_bytes_per_sec. Notez que les valeurs sont exprimées en mégaoctets par seconde:

Essayer de configurer les valeurs correctes pour votre système en particulier. Si la fréquence des E/S attendues sur un système est élevée ou si les performances se dégradent, la diminution de ces valeurs peut contribuer à atténuer un peu la douleur.

Bien que nous ayons exploré différentes manières de limiter un sinistre, la section suivante examinera comment sauvegarder et restaurer des données à partir « de ou vers » votre cluster, le cas échéant.

11.4. SAUVEGARDE DE VOS DONNÉES

Elasticsearch fournit une solution de sauvegarde de données complète et incrémentielle. Les API de capture instantanée et de restauration vous permettent de sauvegarder des données d’index individuelles, tous vos index et même des paramètres de cluster sur un référentiel distant ou d’autres systèmes compatibles, puis de restaurer facilement ces éléments sur le cluster existant ou sur un nouveau.

Le cas typique d’utilisation de la création de snapshots consiste bien entendu à effectuer des sauvegardes pour la reprise sur sinistre, mais vous pouvez également trouver cela utile pour la réplication de données de production dans des environnements de développement ou de test et même en tant qu’assurance avant d’exécuter un grand nombre de modifications.

11.4.1. API d’instantané(Snapshots)

En utilisant l’API d’instantané pour sauvegarder vos données pour la première fois, Elasticsearch enregistre une copie de l’état et des données de votre cluster. Tous les instantanés suivants contiendront les modifications apportées par le précédent. Le processus de capture instantanée n’étant pas bloquant, son exécution sur un système en cours d’exécution ne devrait avoir aucun effet visible sur les performances. De plus, comme chaque instantané suivant est le delta du précédent, il en résulte des instantanés plus petits et plus rapides dans le temps.

Il est important de noter que les instantanés sont stockés dans des référentiels. Un référentiel peut être défini comme un système de fichiers ou une URL.

Un référentiel de système de fichiers nécessite un système de fichiers partagé, lequel doit être monté sur chaque nœud du cluster.
Les référentiels d’URL sont en lecture seule et peuvent être utilisés comme moyen alternatif d’accéder à des instantanés.

Dans cette section, nous aborderons les types de référentiels de système de fichiers les plus courants et les plus flexibles, comment y stocker des instantanés, les restaurer et en tirant parti des plug-ins communs pour les référentiels de stockage des éditeurs de cloud.

11.4.2. Sauvegarde des données sur un système de fichiers partagé

Pour effectuer une sauvegarde de cluster, vous devez exécuter trois étapes détaillées en détail:

Définir un référentiel – Indiquez à Elasticsearch comment vous souhaitez structurer le référentiel.
Confirmez l’existence du référentiel: vous voulez vérifiez que le référentiel a été créé à l’aide de votre définition.
Exécuter la sauvegarde: votre premier instantané est exécuté via une simple commande d’API REST.

Pour activer les instantanés, vous devez définir un référentiel de système de fichiers partagé. La commande curl dans la figure suivante définit votre nouveau référentiel sur un lecteur réseau.

Une fois le référentiel défini sur votre cluster, vous pouvez confirmer son existence à l’aide d’une simple commande GET:

Notez que par défaut, vous ne devez pas spécifier le nom du référentiel, et Elasticsearch répondra avec tous les référentiels enregistrés pour le cluster:

Une fois que vous avez établi un référentiel pour votre cluster, vous pouvez créer votre instantané/sauvegarde initial:

Cette commande déclenchera une opération d’instantané et vous rendra la main immédiatement. Si vous souhaitez attendre la fin de l’instantané avant que la requête ne réponde, vous pouvez ajouter l’indicateur facultatif wait_for_completion:

Jetez maintenant un coup d’œil à l’emplacement de votre référentiel et voyez ce que votre snapshot a stockée:

Dans cette figure, vous pouvez voir un motif émerger sur ce que Elasticsearch a sauvegardé. L’instantané contient des informations pour chaque index, partition, segment et métadonnées d’accompagnement de votre cluster avec la structure de chemin de fichier suivante: /<nom_index>/<numéro_d shard>/<identificateur de segment>. Un exemple de fichier d’instantané peut ressembler au suivant, il contient des informations sur la taille, le segment de Lucene et les fichiers vers lesquels pointe chaque instantané dans la structure de répertoires:

Deuxième instantané

Les instantanés étant incrémentiels et ne stockant que le delta entre eux, une deuxième commande d’instantané créera quelques fichiers de données supplémentaires, mais ne recréera pas l’intégralité de l’instantané:

En analysant la nouvelle structure de répertoires, vous pouvez constater qu’un seul fichier a été modifié: le fichier/index existant dans le répertoire racine. Son contenu contient maintenant une liste des instantanés pris:

Instantanés par index

Dans l’exemple précédent, vous avez vu comment vous pouvez prendre des instantanés de l’ensemble du cluster et de tous les index. Il est important de noter ici que des instantanés peuvent être pris pour chaque index, en spécifiant l’index dans la commande PUT:

La récupération des informations de base sur l’état d’un instantané donné (ou de tous les instantanés) est obtenue en utilisant le même endpoint, avec une requête GET:

La réponse contient les index faisant partie de cet instantané et la durée totale de l’opération d’instantané complète:

En remplaçant le nom de l’instantané par _all, vous obtiendrez des informations sur tous les instantanés du référentiel:

Les instantanés étant incrémentiels, vous devez faire particulièrement attention lorsque vous supprimez d’anciens instantanés dont vous n’avez plus besoin. Il est toujours conseillé d’utiliser l’API d’instantané pour supprimer les anciens instantanés, car elle ne supprimera que les segments de données inutilisés:

Maintenant que vous avez une bonne compréhension des options disponibles lors de la sauvegarde de votre cluster, voyons comment restaurer les données et l’état de votre cluster à partir de ces instantanés, qu’il vous faudra comprendre en cas de sinistre.

11.4.3. Restauration à partir de sauvegardes

Les instantanés sont facilement restaurés sur n’importe quel cluster en cours d’exécution, même un cluster dont l’instantané n’a pas été créé. En utilisant l’API de capture instantanée avec l’option _restore, vous pouvez restaurer l’état complet du cluster:

Cette commande restaurera les données et l’état du cluster capturé dans les instantanés donnés: first_snapshot. Avec cette opération, vous pouvez facilement restaurer le cluster de vôtre choix à tout moment.

Semblable à ce que vous avez vu auparavant avec la capture d’instantané, l’opération de restauration autorise un indicateur wait_for_completion, qui bloque l’appel HTTP que vous passez jusqu’à ce que l’opération de restauration soit complètement terminée. Par défaut, la requête HTTP de restauration est renvoyée immédiatement et l’opération s’exécute en arrière-plan:

curl -XPOST ‘localhost:9200/_snapshot/my_repository/first_snapshot/_restore?wait_for_completion=true’;

Les opérations de restauration proposent également des options supplémentaires vous permettant de restaurer un index vers un espace d’index nommé. Ceci est utile si vous souhaitez dupliquer un index ou vérifier le contenu d’un index restauré à partir d’une sauvegarde:

Avec cette commande, vous ne restaurerez que l’index nommé logs_2014 à partir de l’instantané et ignorerez la restauration des autres index trouvés dans l’instantané. Comme le nom de l’index correspond au modèle défini en tant que rename_pattern, les données de l’instantané résident dans un nouvel index nommé a_copy_of_logs_2014.

Lors de la restauration d’un index existant, l’instance en cours de l’index doit être fermée. Une fois l’opération terminée, l’opération de restauration ouvrira les index fermés.

Maintenant que vous avez compris le fonctionnement de l’API d’instantané pour effectuer les sauvegardes dans un environnement de stockage connecté au réseau, explorons quelques-uns des nombreux plug-ins disponibles pour effectuer des sauvegardes dans un environnement de fournisseur basé sur le cloud.

11.4.4. Utilisation de plugins de référentiel

Bien que la capture instantanée et la restauration à partir d’un système de fichiers partagé soit un cas d’utilisation courant, Elasticsearch et la communauté fournissent également des plugins de référentiel pour plusieurs des principaux fournisseurs de cloud. Ces plug-ins vous permettent de définir des référentiels qui utilisent les exigences d’infrastructure et les API internes d’un fournisseur spécifique.

Amazon S3

Pour ceux qui déploient sur une infrastructure Amazon Web Services, un plugin de référentiel S3 disponible gratuitement sur GitHub et maintenu par l’équipe Elasticsearch: https://github.com/elasticsearch/elasticsearch-cloud-aws#s3-repository.

Le plug-in de référentiel Amazon S3 contient quelques variables de configuration qui diffèrent de la norme. Il est donc important de comprendre les fonctionnalités que chacune d’entre elles contrôle. Un référentiel S3 peut être créé en tant que tel:

Une fois activé, le plug-in S3 stockera vos instantanés dans le chemin du compartiment défini. Etant donné que HDFS est compatible avec Amazon S3, vous pouvez être intéressé par la section suivante, qui couvre également le plug-in du référentiel Hadoop HDFS.

Hadoop HDFS

Le système de fichiers HDFS peut être utilisé comme référentiel de capture/restauration avec ce plugin simple, construit et maintenu par l’équipe Elasticsearch faisant partie du projet plus général de plug-in Hadoop: https://github.com/elasticsearch/elasticsearch-hadoop/tree/master/ repository-hdfs.

Vous devez installer la dernière version stable de ce plugin sur votre cluster Elasticsearch. A partir du répertoire du plugin, utilisez la commande suivante pour installer la version souhaitée du plugin directement à partir de GitHub:

Une fois installé, il est temps de configurer le plugin. Les valeurs de configuration du plug-in de référentiel HDFS doivent être placées dans votre fichier de configuration elasticsearch.yml. Voici certaines des valeurs importantes:

Maintenant, avec votre plug-in de référentiel HDFS configuré, vos opérations d’instantané et de restauration s’exécuteront à l’aide de la même API d’instantané que celle décrite précédemment. La seule différence est que la méthode de capture d’instantanée et de restauration provient de votre système de fichiers Hadoop.

Dans cette section, nous avons exploré différentes manières de sauvegarder et de restaurer des données et des états de cluster à l’aide de l’API d’instantané. Les plugins de référentiel sont pratiques pour ceux qui déploient Elasticsearch avec des fournisseurs de cloud public. L’API d’instantané fournit un moyen simple et automatisé de stocker des sauvegardes dans un environnement réseau pour la récupération après sinistre.

11.5. RÉSUMÉ

Nous avons couvert de nombreuses informations dans ce chapitre, l’accent étant mis sur l’administration et l’optimisation de votre cluster Elasticsearch. Maintenant que vous comprenez bien ces concepts, récapitulons:

Les templates d’index permettent la création automatique d’index partageant des paramètres communs.
Les mappings par défaut sont pratiques pour les tâches répétitives consistant à créer des mappings similaires sur plusieurs index.
Les alias vous permettent d’interroger de nombreux index avec un seul nom, ce qui vous permet de conserver vos données segmentées si nécessaire.
L’API Health du cluster fournit un moyen simple d’évaluer la santé de votre cluster, de vos nœuds et de vos fragments.
Utilisez les fichiers de logs slow index et slow query pour diagnostiquer les opérations d’index et de requête susceptibles d’affecter les performances du cluster.
Armés d’une solide compréhension de la façon dont la machine virtuelle Java, Lucene et Elasticsearch allouent et utilisent la mémoire, vous pouvez empêcher le système d’exploitation de permuter les processus sur le disque.
L’API de capture instantanée constitue un moyen pratique de sauvegarder et de restaurer votre cluster avec un dispositif de stockage connecté au réseau. Les plug-ins de référentiel étendent cette fonctionnalité aux providers de cloud public.