Comme on a pu le voir dans les chapitres précédents, ElasticSearch est vraiment adapté à la recherche d'information dans des documents. La question qui vient juste après, c'est celle du passage à l'échelle :
Comment indexer des quantités de documents arbitrairement grandes ?
Comment répliquer les données pour assurer la résistance aux pannes ?
Ce sont les deux questions qu'on pose au sujet de n'importe quelle solution NoSQL, et chacune y répond de manière différente. Dans le cas d'ElasticSearch, le passage à l'échelle se fait de manière horizontale et en assurant la disponibilité des données, au détriment de la cohérence. Ce dernier point implique qu'un cluster ElasticSearch répondra toujours aux requêtes des utilisateurs avec un délai maximal garanti, et ce même en cas de partition du réseau. Par contre, il n'est pas garanti que la réponse contienne la version la plus récente des données. Il s'agit donc d'une différence importante, par exemple par rapport à MongoDb : en effet, MongoDb assure la cohérence mais pas la disponibilité des données. Pour ElasticSearch, ce choix technique est une conséquence des besoins liés à un moteur de recherche : on s'attend à ce qu'un moteur de recherche réponde avec une latence maximum garantie, mais pas forcément que les résultats soient mis à jour très rapidement.
Modèle de sharding
Voyons un peu comment les données sont distribuées sur un cluster ElasticSearch. Le modèle employé est celui du sharding : comme on l'a vu plus tôt, cela consiste à distribuer les données par bloc (shard) entre les différents nœuds du cluster. Un index est donc décomposé en shards, qui contiennent eux-mêmes les documents :
Un index contient un ou plusieurs shards (5 par défaut).
À chaque shard correspond un shard primaire et zéro ou plus replica shards (1 par défaut), tous stockés sur des nœuds différents.
Chaque shard primaire contient les mêmes documents que ses replica shards.
Alors quel est l'intérêt de répartir les données sur plusieurs shards ? Comme on l'a vu dans la première partie, cela permet de répartir la charge sur plusieurs serveurs. Par exemple, considérons qu'on dispose d'un cluster de cinq nœuds sur lequel sont répartis les cinq shards primaires d'un index contenant des pages web. Si l'on cherche toutes les pages web contenant un certain mot clé, chacun des nœud du cluster ne va avoir à chercher que parmi un cinquième des données. Le temps de réponse devrait donc être divisé par cinq par rapport à un cluster composé d'un seul nœud. Les replica shards sont utilisés exactement de la même manière que les shards primaires : ils contribuent également à la répartition de la charge sur un cluster.
Elasticité
Attention ! À première vue, on pourrait s'attendre à ce que le temps de calcul continue de baisser en ajoutant des nœuds au cluster, mais cela ne va pas être vrai. Si le nombre de nœuds dépasse le nombre de shards primaires, le temps nécessaire pour réaliser une requête ne va pas baisser. Par contre, en ajoutant des replicas sur ces nœuds supplémentaires, le cluster répond à plus de requêtes en même temps sans affecter le délai de réponse. La taille optimale d'un cluster va donc dépendre du scénario envisagé :
Pas de requêtes concurrentes (1 seul utilisateur) :
Multiples requêtes concurrentes (nombreux utilisateurs) :
SHAAAAAAAARDEZ!
Mais trêve de bavardages ! Passons à l'action et faisons grossir notre cluster. Vous allez voir, c'est presque décevant tellement c'est simple. On va juste lancer un nouveau nœud, de la même manière qu'on a fait jusqu'ici. Il y a une unique subtilité si on lance le second nœud sur la même machine : il faut permettre à ElasticSearch de stocker les données de plusieurs nœuds dans le même répertoire. Pour cela, on ajoute la ligne suivante au fichier de configurationconfig/elasticsearch.yml:
node.max_local_storage_nodes: 2Évidemment, remplacez "2" par le nombre de nœuds que vous comptez lancer sur votre machine. Vous pouvez alors lancer un nœud supplémentaire avec la commande habituelle :
$ ./bin/elasticsearchEt voilà le travail ! Vous avez désormais deux nœuds qui cohabitent sur la même machine.
Administration du cluster
Maintenant qu'on a un cluster fonctionnel, voyons quelques commandes permettant de visualiser l'état du cluster, et éventuellement de diagnostiquer des problème.
cluster/_health
On commence par une commande dont vous allez vous servir très souvent. La commandecluster/_healthpermet de visualiser l'état de santé du cluster. Par exemple, dans notre cluster composé de deux nœuds et contenant cinq shards répliqués une fois, on obtient :
$ curl localhost:9200/_cluster/health?pretty
{
"cluster_name" : "elasticsearch",
"status" : "green",
"timed_out" : false,
"number_of_nodes" : 2,
"number_of_data_nodes" : 2,
"active_primary_shards" : 5,
"active_shards" : 10,
"relocating_shards" : 0,
"initializing_shards" : 0,
"unassigned_shards" : 0,
"delayed_unassigned_shards" : 0,
"number_of_pending_tasks" : 0,
"number_of_in_flight_fetch" : 0,
"task_max_waiting_in_queue_millis" : 0,
"active_shards_percent_as_number" : 100.0
}Ici, l'état du cluster est vert. Cela signifie que tous les shards primaires et les replicas sont disponibles. Si certains replicas ne sont pas disponibles, le cluster va passer en état jaune. Par exemple, vous pouvez arrêter le second nœud que vous avez lancé et exécuter la commande à nouveau :
$ curl localhost:9200/_cluster/health?pretty
{
"cluster_name" : "elasticsearch",
"status" : "yellow",
"timed_out" : false,
"number_of_nodes" : 1,
"number_of_data_nodes" : 1,
"active_primary_shards" : 5,
"active_shards" : 5,
"relocating_shards" : 0,
"initializing_shards" : 0,
"unassigned_shards" : 5,
"delayed_unassigned_shards" : 5,
"number_of_pending_tasks" : 0,
"number_of_in_flight_fetch" : 0,
"task_max_waiting_in_queue_millis" : 0,
"active_shards_percent_as_number" : 50.0
}Inversement, si vous rallumez le nœud que vous venez d'éteindre, le cluster va brièvement rester dans un état jaune, le temps que les shards soient ré-alloués. Vous aurez alors un nombre derelocating_shardsnon nul :
$ curl localhost:9200/_cluster/health?pretty
{
"cluster_name" : "elasticsearch",
"status" : "yellow",
...
"relocating_shards" : 2,
...
}Un état jaune n'est pas problématique : il signale que le cluster est en bon état de marche, mais que certains shards ne sont pas alloués comme prévu. Par contre, lorsque certains shards (primaire et replicas) deviennent complètement indisponible, le cluster passe en état rouge. Il est alors dans un état problématique qu'il est urgent de résoudre.
_cat/shards
Si votre cluster est dans un état jaune ou rouge, votre premier réflexe devra être de voir quels shards sont indisponibles. Pour cela, vous utiliserez la commande_cat/shardsqui permet d'afficher l'état de tous les shards. Par exemple, sur notre indexmovies:
$ curl localhost:9200/_cat/shards
movies 4 p STARTED 1020 1.5mb 127.0.0.1 7PdQQLi
movies 4 r STARTED 1020 1.5mb 127.0.0.1 ibuo3Se
movies 3 p STARTED 966 1.4mb 127.0.0.1 7PdQQLi
movies 3 r STARTED 966 1.4mb 127.0.0.1 ibuo3Se
movies 1 p STARTED 944 1.4mb 127.0.0.1 7PdQQLi
movies 1 r STARTED 944 1.4mb 127.0.0.1 ibuo3Se
movies 2 p STARTED 981 1.5mb 127.0.0.1 7PdQQLi
movies 2 r STARTED 981 1.5mb 127.0.0.1 ibuo3Se
movies 0 p STARTED 942 1.4mb 127.0.0.1 7PdQQLi
movies 0 r STARTED 942 1.4mb 127.0.0.1 ibuo3SeEt lorsqu'un nœud est éteint, certains shards passent dans l'état "unassigned" :
$ curl localhost:9200/_cat/shards
movies 4 p STARTED 1020 1.5mb 127.0.0.1 7PdQQLi
movies 4 r UNASSIGNED
movies 3 p STARTED 966 1.4mb 127.0.0.1 7PdQQLi
movies 3 r UNASSIGNED
movies 1 p STARTED 944 1.4mb 127.0.0.1 7PdQQLi
movies 1 r UNASSIGNED
movies 2 p STARTED 981 1.5mb 127.0.0.1 7PdQQLi
movies 2 r UNASSIGNED
movies 0 p STARTED 942 1.4mb 127.0.0.1 7PdQQLi
movies 0 r UNASSIGNEDLes différentes colonnes sont, respectivement :
le nom de l'index
le numéro du shard, numéroté à partir de 0 : comme on peut le voir, l'index
moviespossède bien cinq shards.une lettre (
pour) qui indique s'il s'agit d'un shard primaire ou d'un replica.un statut (
STARTEDouUNASSIGNED) faisant référence à la disponibilité du shard.le nombre de documents dans le shard.
la taille du shard.
l'adresse IP du nœud contenant le shard.
le nom du nœud contenant le shard.
_nodes/process
Comme vous pouvez le voir, le nom des nœuds obtenu grâce à la commande précédente est une chaîne de caractères générée aléatoirement, ce qui est peu commode. Pour en apprendre plus sur les nœuds, exécutez :
$ curl localhost:9201/_nodes/process?pretty
{
"_nodes" : {
"total" : 2,
"successful" : 2,
"failed" : 0
},
"cluster_name" : "elasticsearch",
"nodes" : {
"ibuo3SebR8-DScQALMNKRA" : {
"name" : "ibuo3Se",
"transport_address" : "127.0.0.1:9301",
"host" : "127.0.0.1",
"ip" : "127.0.0.1",
"version" : "5.5.2",
"build_hash" : "b2f0c09",
"roles" : [
"master",
"data",
"ingest"
],
"process" : {
"refresh_interval_in_millis" : 1000,
"id" : 7408,
"mlockall" : false
}
},
"7PdQQLilTnyMBLyWAT5IHQ" : {
"name" : "7PdQQLi",
"transport_address" : "127.0.0.1:9300",
"host" : "127.0.0.1",
"ip" : "127.0.0.1",
"version" : "5.5.2",
"build_hash" : "b2f0c09",
"roles" : [
"master",
"data",
"ingest"
],
"process" : {
"refresh_interval_in_millis" : 1000,
"id" : 6730,
"mlockall" : false
}
}
}
}Configuration du cluster
Mal nommer les choses, c'est ajouter au malheur du monde
En fait, le nom des nœuds est un paramètre qu'on peut modifier. Il s'agit d'un des nombreux paramètres qu'on retrouve dans le fichier de configurationconfig/elasticsearch.yml. Comme vous pouvez le voir en ouvrant ce fichier, la plupart des paramètres sont commentés :
# Use a descriptive name for the node:
#
#node.name: node-1Décommentez cette ligne pour affecter explicitement un nom à votre nœud. Cela vous permettra d'avoir des nœuds qui gardent le même nom d'un redémarrage sur l'autre. Attention cependant : vous ne pourrez plus utiliser le même fichier de configuration pour plusieurs nœuds, puisque deux nœuds différents d'un même cluster doivent avoir des noms différents.
Il n'est pas indispensable de modifier le nom des nœuds ; par contre, le nom de votre cluster est assez important. Oui, car votre cluster a un nom ! Il est défini par le paramètrecluster.name. Par défaut, le nom du cluster estelasticsearch, comme vous pouvez le voir dans le résultat de la commande_cluster/health. Et ce nom de cluster est important pour que les nœuds se retrouvent entre eux...
Restons zen
Est-ce que vous vous êtes demandés comment les différents nœuds allumés sur le même réseau local se trouvent et se connectent entre eux pour former un cluster ? Pour effectuer cette découverte, ElasticSearch utilise le module "Zen discovery" : au démarrage, un nœud va chercher ses congénères parmi certaines adresses définies dans le paramètrediscovery.zen.ping.unicast.hosts. S'il y a bien un nœud ElasticSearch à l'adresse indiquée, et que ce nœud a le même nom, alors le nouveau nœud rejoint le cluster.
Évitez le split brain
Vous allez avoir de plus en plus de données à gérer (du moins on vous le souhaite). En conséquence, vous allez probablement ajouter des nœuds à votre cluster. Il y a un problème qu'on rencontre fréquemment quand on fait grossir un cluster : en cas de partition du réseau, on risque de se retrouver avec deux voire trois clusters au lieu d'un seul ! C'est le phénomène de "split brain". C'est une situation catastrophique puisqu'elle peut générer des corruptions de données. Pour l'éviter, définissez le paramètrediscovery.zen.minimum_master_nodes: un nœud ne pourra alors pas rejoindre un cluster s'il voit moins de nœuds que cette valeur. SiNest votre nombre total de nœuds dans le cluster, définissez ce paramètre àN/2 + 1(arrondi à l'inférieur) et vous serez assurés de ne pas avoir de partition de votre cluster.
Modifiez le nombre de shards
Jusqu'à présent, on a utilisé notre index avec le nombre par défaut de shards primaires (5) et de replicas (1). À un moment, vous allez probablement vouloir modifier ces nombres. Il est possible de modifier le nombre de replica shards. Pour cela, il faut modifier les paramètres de notre index. Par exemple, avec la commande suivante on assigne 2 replicas à chaque shard primaire :
$ curl -X PUT localhost:9201/movies/_settings?pretty -d '{
"index": {
"number_of_replicas" : 2
}
}'Notre cluster va donc passer à 15 shards et à un état jaune, puisqu'il ne contient que deux nœuds : tous les replicas ne pourront donc être assignés.
Quid des shards primaires ? Il se trouve qu'il n'est pas possible de modifier le nombre de shards primaires d'un index existant. Par contre il est possible de définir ce nombre lors de la création de l'index :
curl -X PUT localhost:9201/movies -d '{
"settings": {
"index": {
"number_of_shards" : 6
}
}
}'