TP Installation elasticsearch_tp
L'idée de ce TP est de constituer un véritable cluster Opensearch de manière ludique sur la plateforme cloud de GRICAD. Les stagiaires (seuls ou en binôme), vont installer et administrer chacun un noeud d'un cluster qui en comportera 10 au total, et pourront réutiliser ce cluster pour "jouer" avec une véritable implémentation (tester les perfs, faire tomber un noeud pour provoquer les mécanismes de reprise, superviser l'état du cluster, etc...)
Ce sera différent des manipulations faites au seins de containers all-in-one, plus simples à prendre en main rapidement pour utiliser les fonctionnalités "clientes", mais cela permet de mieux apréhender la partie "admin dans la vraie vie"!
La référence principale utilisée est la documentation officielle Opensearch en ligne: https://opensearch.org/docs
La partie provisionning de VM vous est épargnée! ouf! Donc nous avons préparé pour vous 10 VM déja accessibles depuis un bastion SSH. Le préfixe du nom des VM peut surprendre: il s'agit en fait de la récupération d'un travail fait pour une autre ANF nommée "UST4HPC".
Un fichier /etc/hosts est installé sur toutes les VM afin d'éviter les problèmes de DNS et de permettre un accès rapide aux machines sans spécifier le fqdn. Le nom des VM est donc ust4hpc-data0, ust4hpc-data1, ... ust4hpc-data9
15 personnes:
Les stagiaires prennent en main les VM ust4hpc-data[0-4]
en binome et ust4hpc-data[5-9]
en monome.
Le bastion est admin@ust4hpc.u-ga.fr
, accessible via un
mot de passe qui vous sera fourni oralement. Vous pourrez alors joindre
votre VM en vous connectant par rebond. (Les plus avertis d'entre vous
pourront se configurer une proxy-commande ssh, mais ce ne sera pas
indispensable).
ssh admin@ust4hpc.u-ga.fr -> sudo su - -> ssh ust4hpc-data[0-9]
A faire sur tous les noeuds, en root:
# Install des dépendances
apt-get update && sudo apt-get -y install lsb-release ca-certificates curl gnupg2
# Importation de la clé GPG
curl -o- https://artifacts.opensearch.org/publickeys/opensearch.pgp | sudo gpg --dearmor --batch --yes -o /usr/share/keyrings/opensearch-keyring
# APT repository
echo "deb [signed-by=/usr/share/keyrings/opensearch-keyring] https://artifacts.opensearch.org/releases/bundle/opensearch/2.x/apt stable main" | sudo tee /etc/apt/sources.list.d/opensearch-2.x.list
# Installation
apt-get update
apt-get install opensearch
Nous allons éditer le fichier
/etc/opensearch/opensearch.yml
. Il comporte quelques
éléments de configuration par défaut pour un fonctionnement en mode
single-node. Nous allons adapter la config pour déployer notre cluster
sur toutes nos VM.
Sur tous les noeuds, décommentez et changez la valeur de
cluster.name
: anf2023
Sur tous les noeuds, nous allons changer le nom
node.name
: y mettre le nom d'hôte, soit
ust4hpc-data0
, ust4hpc-data1
, etc... (Note: en
théorie, on peut mettre le nom que l'on souhaite, et donc utiliser des
noms explicites comme 'data1', 'data2', 'coord1',... Hors, par
expérience, en pratique, il faut au moins que les noeuds master
aient ce nom là déclaré dans le système de nommage DNS ou
/etc/hosts)
Ajoutez le rôle de votre noeud à la suite: (ne cherchez pas
l'option, node.roles
, elle n'y est pas par défaut, c'est à
vous de créer une nouvelle ligne de configuration):
node.roles: [ data, ingest ]
node.roles: [ cluster_manager ]
node.roles: []
Configuration de l'interface d'écoute:
network.host: 0.0.0.0
afin que le service écoute sur toutes
les interfaces du noeud
Configuration de la découverte du cluster: sur tous les noeuds,
il faut lister les adresses des noeuds manager. Donc:
discovery.seed_hosts: [ "ust4hpc-data5" , "ust4hpc-data6" , "ust4hpc-data7" ]
Sur les noeuds manager, il faut en plus lister les noms
des managers dans
cluster.initial_cluster_manager_nodes: ["ust4hpc-data5", "ust4hpc-data6" , "ust4hpc-data7" ]
A la fin du fichier, vous trouverez tous les paramètres de
sécurité, qui sont gérés par le plugin security
. C'est ici
que vous allez configurer vos certificats (indispensable!) lorsque vous
mettrez un cluster en production. Nous allons pour notre part désactiver
le plugin de sécurité afin d'éviter des problèmes pendant ce simple
test: Ajouter une ligne
plugins.security.disabled: true
Sauvez maintenant le fichier opensearch.yml
Configuration de la mémoire
/etc/opensearch/jvm.options
Xms
et Xmx
: mettez -Xms512m
et
-Xmx512m
.Démarrer le service sur tous les noeuds :
systemctl start opensearch.service
Vérifiez le bon démarrage du cluster dans les fichiers de logs
qui se trouvent dans
/var/log/opensearch/anf2023.log
Pré-requis: connaissance de curl
. Si vous ne connaissez
pas cet outil, manifestez-vous afin que nous l'introduisons
rapidement.
Faites une reqûete sur l'un des noeuds "coordonating". Le rôle de ces noeuds est de prendre les requetes des clients et de les transmettre au cluster:
curl http://admin:admin@ust4hpc-data8:9200/_cluster/health?pretty
Dans la vraie vie, bien sûr, il faudra installer des certificats
officiels et changer le login d'administration! La requête se fera alors
en https
et il faudra préciser à curl le certificat de
votre authorité de certification si nécessaire.
Pour cela, la doc est ici: https://opensearch.org/docs/latest/install-and-configure/install-opensearch/tar/#configure-tls
Note: désactiver le plugin de sécurité rend impossible l'utilisation
de la commande d'administration qui permet de créer des utilisateurs ou
même de changer les mots de passe (commande
/usr/share/opensearch/plugins/opensearch-security/tools/securityadmin.sh
)
Note: pour utiliser les commandes d'administration telles que
securityadmin.sh
, il peut être nécessaire de positionner
correctement la variable suivante:
export JAVA_HOME=/usr/share/opensearch/jdk
.
Mais concentrons nous sur l'utilisation de notre cluster!
La requête invoquée ci-dessus, va donner ce genre de réponse:
{
"cluster_name" : "anf2023",
"status" : "yellow",
"timed_out" : false,
"number_of_nodes" : 4,
"number_of_data_nodes" : 2,
"discovered_master" : true,
"discovered_cluster_manager" : true,
"active_primary_shards" : 6,
"active_shards" : 10,
"relocating_shards" : 0,
"initializing_shards" : 0,
"unassigned_shards" : 2,
"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" : 83.33333333333334
}
Notre cluster doit passer en status "green" si tout va bien. Cela se passe lorsque l'on a au minimum 1 noeud de management actif et si tous les shards ont bien été assignés sur les noeuds de data.
Attendez que tout le monde ai bien installé son noeud opensearch. Si vous êtes en avance et que le cluster répond, essayez de faire quelques reqûetes:
_stats
_cat
)Opensearch-dashboards est une interface web équivalente à Kibana. Elle permet de requeter un cluster Opensearch, faire des opérations sur les index, voire même administrer le cluster. Elle exploite l'API rest fournie par Opensearch.
Nous allons installer ensemble une seule instance dashboards sur notre noeud de tête ust4hpc .
Installation sous Debian:
curl -o- https://artifacts.opensearch.org/publickeys/opensearch.pgp | sudo gpg --dearmor --batch --yes -o /usr/share/keyrings/opensearch-keyring
echo "deb [signed-by=/usr/share/keyrings/opensearch-keyring] https://artifacts.opensearch.org/releases/bundle/opensearch-dashboards/2.x/apt stable main" | sudo tee /etc/apt/sources.list.d/opensearch-dashboards-2.x.list
apt-get update
apt-get install opensearch-dashboards
Configuration:
/etc/opensearch-dashboards/opensearch_dashboards.yml
server.host: 0.0.0.0
opensearch.hosts: [http://ust4hpc-data8:9200]
opensearch.username
et
opensearch.password
par admin
et
admin
server.basePath: "/anf2023"
opensearch_security*
/usr/share/opensearch-dashboards/bin/opensearch-dashboards-plugin --allow-root remove securityDashboards
Securité: ici aussi nous devrions activer https pour sécuriser notre infra. Il est également conseillé de placer l'application dashboards derrière un firewall et un reverse proxy qui vous permettera de réaliser du filtrage. C'est ce que nous avons fait pour cette instance, vous pourrez la joindre derrière notre proxy à l'URL suivante: https://eli.univ-grenoble-alpes.fr/anf2023
Utilisation de dashboards
Revenez à la console shell de votre noeud. Nous allons créer un index par binôme pour charger un peu notre cluster. Pour cela, nous allons utiliser Logstash. Sans entrer dans les détails car ce n'est pas le but ici, logstash permet de définir des inputs, des filtres et des outputs. Dans notre exemple, nous allons utiliser un fichier de données correspondant à des séquences ADN comme input. Le filtre fera la correspondance des champs à ingérer et l'output sera un index de notre cluster Opensearch.
echo "deb https://artifacts.elastic.co/packages/oss-8.x/apt stable main" | sudo tee -a /etc/apt/sources.list.d/elastic-8.x.list
apt-get update
apt-get install logstash-oss
Configuration de la Heapsize: ici aussi, il faut adapter la
taille de la zone mémoire allouée aux objects java: editez
/etc/logstash/jvm.options
et mettez -Xms640m
et -Xmx640m
Installation du plugin opensearch
/usr/share/logstash/bin/logstash-plugin install logstash-output-opensearch
cd /var/tmp
wget http://ciment-grid.univ-grenoble-alpes.fr/public/seqFreqTmrca_cat3.sample
Creation d'un fichier de config dans
/etc/logstash/conf.d/anf.conf
:
input {
file {
path => ["/var/tmp/seqFreqTmrca_cat3.sample"]
mode => "read"
exit_after_read => "false"
file_completed_action => "log"
file_completed_log_path => "/var/tmp/file_completed_log"
sincedb_path => "/var/tmp/sincedb_seqfreqtmrca"
}
}
filter {
dissect {
mapping => {
"message" => "%{seq} %{freq} %{tmrca}"
}
}
}
output {
opensearch {
hosts => ["http://ust4hpc-data8:9200"]
index => "CHOISISSEZ UN NOM POUR VOTRE INDEX"
user => "admin"
password => "admin"
}
}
ATTENTION : Dans le filtre, la chaine
%{seq} %{freq} %{tmrca}
contient des tabulations et non
des espaces. Vérifiez votre copier-coller...
curl -X PUT "http://admin:admin@ust4hpc-data8:9200/mon_index?pretty" -H 'Content-Type: application/json' -d'
{
"settings": {
"number_of_shards": 3,
"number_of_replicas": 2
},
"mappings": {
"properties": {
"seq": { "type": "keyword" },
"freq": { "type": "double" },
"tmrca": { "type": "double" }
}
}
}
'
Cela va initialiser notre index avec 3 shards et 2 réplicas. Il sera donc distribué sur 3 serveurs de data et on pourra perdre l'un de ces serveurs sans perdre les données car elles pourront être retrouvées sur les réplicas.
Important! : Comme nous allons utiliser logstash pour
ingérer un fichier, le service doit s'arreter une fois le travail
terminé. On ne souhaite pas que logstash soit automatiquement relancé
par systemd, sinon, on va charger en boucle le fichier. Donc, editez
/lib/systemd/system/logstash.service
et remplacez la ligne
Restart=always
par Restart=never
.
Maintenant, nous pouvons lancer logstash, via systemd:
systemctl daemon-reload
systemctl restart logstash
# Fichier de log:
tail -f /var/log/logstash/logstash-plain.log
Faites quelques requêtes sur l'API pour voir si votre index existe bien, et s'il est bien alimenté, par exemple:
GET /mon_index?pretty
GET /mon_index/_count?pretty
wget http://ciment-grid.univ-grenoble-alpes.fr/public/elastic_moutons_search.py
apt-get install python3-elasticsearch
python3 ./elastic_moutons_search.py
Ce code python de quelques lignes fait une recherche d'intervalles dans les fréquences d'ADN de moutons et compte le nombre d'occurences des gènes recherchés. Le fichier de fréquences original fait plusieurs milliards de lignes. L'ingestion de ce fichier sur un cluster convenablement dimensionné prend quelques heures, et le calcul de distribution que vous venez de lancer ne prend que quelques heures également. Cette méthode a permi de remplacer un autre code qui était inefficace et qui aurait mis des jours, voire des mois pour obtenir les même résultats
N'hésitez pas à jetter un oeil au code et à vous balader dans les données avec "Opensearch Dahsboards" si vous avez deviné comment on fait ;-)