Définition

Elasticsearch est un moteur de recherche et d'analyse distribué et RESTful, capable de répondre à un nombre croissant de cas d'utilisation. À la base, il s'agit d'une base de données NoSQL, mais contrairement aux bases de données traditionnelles conçues pour le stockage et la récupération simple, Elasticsearch est optimisé pour la vitesse et la pertinence.

Architecture & Capacity Planning

Ce diagramme illustre une architecture typique de cluster de production, montrant la séparation des tâches entre les nœuds maîtres dédiés (dedicated master nodes), les nœuds de données étagés (tiered data nodes - hot/warm) et les nœuds de coordination (coordinating nodes).

1. Node Roles

A. Rôles de base obligatoires

1. Master-eligible node (`master`)

Fonction : Responsable des actions à l'échelle du cluster, telles que la création ou la suppression d'index, le suivi des nœuds faisant partie du cluster et l'allocation des shards aux nœuds.
Pourquoi c'est obligatoire : Sans maître, le cluster ne peut pas être formé et aucun changement au niveau du cluster ne peut être suivi.
Conseil de production : Vous avez généralement besoin de 3 nœuds maîtres dédiés pour la Haute Disponibilité (High Availability) afin d'éviter le "split-brain".

2. Data node (`data`)

Fonction : Contient les shards qui hébergent vos documents indexés. Ces nœuds effectuent des opérations liées aux données comme le CRUD, la recherche et les agrégations.
Pourquoi c'est obligatoire : Sans nœuds de données, vous ne pouvez stocker aucune donnée.
Sous-rôles (Tiered Architecture) :
- data_content : Pour les données à usage général qui ne correspondent pas à un cycle de vie de séries temporelles (time-series).
- data_hot : Pour les données time-series strictes (ex : logs) qui sont activement écrites et interrogées.
- data_warm : Pour les données plus anciennes qui sont en lecture seule (read-only) mais encore fréquemment interrogées.
- data_cold : Pour les données consultées peu fréquemment (optimisé pour le stockage).
- data_frozen : Pour les données stockées dans le stockage objet (S3) et rarement interrogées (Searchable Snapshots).

B. Core Utility Roles (Hautement recommandés)

Bien qu'ils ne soient pas strictement "obligatoires" pour le démarrage du cluster, ils sont standard dans presque tous les environnements de production.

1. Ingest node (`ingest`)

Fonction : Exécute des "ingest pipelines" pour prétraiter les documents avant l'indexation. Cela agit comme un Logstash léger à l'intérieur d'Elasticsearch (ex : parsing JSON, suppression de champs, renommage de champs).
Comportement par défaut : Chaque nœud est un ingest node par défaut, sauf configuration contraire.

2. Coordinating-only node (Aucun rôle spécifique défini)

Fonction : Ces nœuds ont une liste de rôles vide (node.roles: []). Ils agissent comme des "Smart Load Balancers". Ils acceptent les requêtes de recherche, les distribuent aux nœuds de données spécifiques détenant les données, rassemblent les résultats, effectuent la réduction finale (tri/agrégation) et envoient la réponse au client.
Cas d'utilisation : Grands clusters avec un trafic de recherche important pour éviter que les data nodes ne soient submergés par des tâches d'agrégation gourmandes en CPU.

C. Specialized Roles (Optionnels)

Ceux-ci sont spécifiques à certaines fonctionnalités de la Suite Elastic.

1. Machine Learning node (`ml`)

Fonction : Exécute les tâches natives de Machine Learning (détection d'anomalies, prévisions).
Exigence : Ces tâches sont gourmandes en CPU et en RAM. Si vous utilisez des fonctionnalités ML, vous devez avoir au moins un nœud ML.

2. Remote Cluster Client (`remote_cluster_client`)

Fonction : Permet au cluster de se connecter à d'autres clusters (Cross-Cluster Search ou Cross-Cluster Replication).
Défaut : Activé par défaut sur tous les nœuds.

3. Transform node (`transform`)

Fonction : Exécute des tâches de transformation qui pivotent ou résument les données dans de nouveaux index (similaire aux "Materialized Views" en SQL).

4. Voting-only node (`voting_only`)

Fonction : Un nœud master-eligible qui peut participer aux élections du maître (voting) mais ne peut pas devenir le maître élu.
Cas d'utilisation : Rarement utilisé ; principalement pour départager les votes (tie-breaking) dans les clusters à nombre pair.

2. Hardware Requirements

Ces chiffres sont basés sur les contraintes de la JVM (Java Virtual Machine) et les meilleures pratiques opérationnelles pour la récupération et la stabilité.

A. RAM (Mémoire)

C'est la ressource la plus critique. Elle est divisée entre la JVM Heap (pour l'application) et l'OS Filesystem Cache (pour les fichiers de segments Lucene).

Minimum : 8 GB - 16 GB
- Exécuter un nœud de production avec moins de 8GB est risqué. Vous avez besoin de suffisamment de marge (headroom) pour que l'OS puisse mettre en cache les segments d'index fréquemment consultés.
Le "Sweet Spot" : 64 GB
- C'est la spécification standard pour un nœud haute performance. Cela vous permet d'allouer environ 30GB à la Heap et de laisser environ 34GB pour le cache de l'OS.
Maximum (Effectif) : 64 GB (RAM Physique)

⚠️ La limite "Compressed Oops" Vous devez strictement éviter d'allouer plus de 31GB-32GB à la JVM Heap. Si la Heap dépasse ~32GB, la JVM cesse d'utiliser les "Compressed Object Pointers" (les pointeurs gonflent de 32-bit à 64-bit). Cela réduit considérablement l'efficacité de la mémoire, réduisant effectivement votre mémoire disponible de moitié.

B. Disk (Stockage)

La vitesse du disque dicte le débit d'indexation, et la taille du disque dicte la durée de la récupération (rééquilibrage des shards).

Exigence de type : SSD / NVMe
- Les disques durs rotatifs (Spinning HDDs) ne sont acceptables que pour les tiers "Cold" ou "Frozen".
Capacité minimale : 200 GB
- Les petits clusters ont besoin d'assez d'espace pour les logs, l'OS et une marge pour le shard merging.

Capacité maximale (Par nœud) :

Hot Nodes (High IO) : Limite de 2 TB - 4 TB.
- Raisonnement : Si un nœud contient 10TB de données "hot" et tombe en panne, répliquer ces 10TB sur un nouveau nœud via le réseau prend des heures ou des jours, laissant le cluster dans un état "Yellow" (à risque).
Warm/Cold Nodes : 10 TB - 16 TB.
- Raisonnement : Puisque ces nœuds sont query-heavy (lecture) mais low-write (écriture), vous pouvez les remplir avec un stockage dense, à condition d'accepter des temps de récupération plus lents.

C. Network

Elasticsearch est un système distribué ; le réseau en est le bus.

Minimum : 1 Gbps (Gigabit Ethernet)
- Acceptable uniquement pour les petits clusters avec des taux d'indexation faibles.
- Risque : Lors d'une "peer recovery" (quand un nœud revient en ligne), un lien de 1 Gbps sera saturé à 100%, provoquant une augmentation de la latence de recherche.
Recommandé / Maximum : 10 Gbps - 25 Gbps
- 10 Gbps est la norme pour les clusters de production modernes afin de garantir que la récupération n'impacte pas le trafic live.
Latence : Doit être de quelques millisecondes (intra-datacenter).
- Avertissement : Étendre un cluster unique sur des régions géographiques distinctes (ex : US-East vers EU-West) est généralement non supporté et causera une instabilité due aux erreurs de timeout.

3. Sizing & Sharding

Ce diagramme fournit une visualisation claire de la façon dont un index unique est divisé en shards primaires (P) et comment chaque shard primaire a un shard réplica correspondant (R) distribué sur différents nœuds pour la haute disponibilité.

A. Shard Strategy

Le sharding est le mécanisme qui permet à Elasticsearch de s'étendre au-delà des limites matérielles d'un seul serveur. Cependant, c'est la source la plus courante de problèmes de performance en production.

1. Le Concept

Un index Elasticsearch est en réalité un regroupement logique de Shards. Chaque shard est une instance autonome d'Apache Lucene, qui est un moteur de recherche entièrement fonctionnel à part entière. Lorsque vous exécutez une recherche sur un index, Elasticsearch interroge tous les shards pertinents en parallèle et fusionne les résultats.

2. Le piège de l'Oversharding"

Les nouveaux utilisateurs pensent souvent : "Si les shards offrent du parallélisme, plus de shards signifie plus de vitesse." C'est une fausse idée connue sous le nom d'oversharding.

La surcharge des métadonnées : Chaque shard consomme des ressources. Le Cluster State (le "cerveau" du cluster) doit suivre l'emplacement, le statut et la taille de chaque shard. Si vous avez 100 000 petits shards, le Cluster State devient énorme et les mises à jour (comme la création d'un nouvel index) deviennent incroyablement lentes.
La taxe "Map-Reduce" : Lorsque vous recherchez dans un index avec 50 shards, le nœud de coordination doit envoyer la requête à 50 endroits, attendre 50 réponses et fusionner 50 résultats. Si ces shards sont minuscules (ex : 50MB), la surcharge de gestion de la requête dépasse le bénéfice du traitement parallèle.
Coût en mémoire : Chaque shard a une empreinte mémoire de base dans la JVM Heap pour conserver les informations de segment Lucene. Trop de petits shards épuiseront votre mémoire Heap même si le cluster est inactif.

✅ La Règle d'Or : 10GB – 50GB Pour la recherche à usage général (ex : produits, utilisateurs), visez une taille de shard comprise entre 10GB et 50GB.

Pourquoi > 10GB ? Pour minimiser la surcharge par shard et maximiser une compression efficace.
Pourquoi < 50GB ? Pour s'assurer que la récupération est rapide. Si un nœud tombe en panne, déplacer un shard de 50GB vers un nouveau nœud via le réseau est gérable. Déplacer un shard de 500GB prend tellement de temps que votre cluster reste dans un état vulnérable (santé "Yellow") pendant des heures.

B. Replicas

La réplication sert deux objectifs distincts dans un cluster : la High Availability (HA) et le Read Throughput (débit de lecture).

1. Failover (Haute Disponibilité)

Un Replica Shard est une copie précise d'un Primary Shard.

Le Mécanisme : Si le nœud tenant un Primary Shard plante, le nœud maître "promeut" instantanément le Replica Shard (vivant sur un nœud différent) pour être le nouveau Primary.
Standard de Production : Vous devez définir number_of_replicas: 1 (au minimum). Cela garantit que si un seul nœud tombe en panne, aucune donnée n'est perdue et le cluster reste pleinement opérationnel.
Le Compromis : Les réplicas doublent vos besoins de stockage. 100GB de données avec 1 replica nécessite 200GB d'espace disque physique.

2. Read Throughput (Scaling Search)

Contrairement aux Primary shards, qui gèrent à la fois les lectures et les écritures, les Replicas sont généralement utilisés pour les lectures.

Load Balancing : Lorsqu'une requête de recherche arrive, le nœud de coordination la route intelligemment. Elle peut aller vers le Primary ou l'un de ses Replicas.
Scaling Up : Si votre application est "Read Heavy" (ex : un site e-commerce où les utilisateurs cherchent souvent mais les produits changent rarement), vous pouvez augmenter les performances en ajoutant plus de replicas.
- Exemple : Un index avec 1 Primary et 5 Replicas permet à 6 nœuds de répondre aux requêtes de recherche simultanément pour ces données spécifiques.

Distinction Clé :

Primary Shards sont fixés à la création de l'index (les changer nécessite une réindexation).

Replica Shards peuvent être changés dynamiquement. Vous pouvez passer de 1 replica à 5 replicas instantanément si vous prévoyez un pic de trafic (comme le Black Friday), et revenir en arrière ensuite.

Environment Preparation (OS Tuning)

Elasticsearch est sensible aux configurations du Système d'Exploitation. Ne pas les optimiser empêchera souvent le cluster de démarrer (Bootstrap Checks).

1. Disable Swapping (Le "Tueur de Performance")

Le Concept : Dans un serveur standard, si la RAM physique est pleine, l'OS déplace les pages mémoire inactives vers le disque dur (swap space). Pour Elasticsearch, c'est catastrophique. Le Java Garbage Collector (GC) a besoin de scanner la mémoire pour récupérer de l'espace. Si cette mémoire est sur le disque (qui est 100 000x plus lent que la RAM), un cycle GC qui prend habituellement des millisecondes prendra des secondes ou des minutes.

Le Résultat : Le nœud devient non réactif (pause "Stop-the-world"), le cluster pense que le nœud est mort, l'éjecte et déclenche un rééquilibrage massif des données.

Comment le configurer

Vous avez deux méthodes principales. La meilleure pratique est de faire les deux.

OS Level (Permanent) : Disable swap completely.
```
 sudo swapoff -a
```
Application Level (Memory Lock) : Force Elasticsearch à verrouiller son espace d'adressage mémoire dans la RAM pour que l'OS ne puisse pas le swapper.
- Dans elasticsearch.yml :
```
  bootstrap.memory_lock: true
```
- Note : Vous devrez peut-être éditer le fichier de service systemd (systemctl edit elasticsearch) pour autoriser cette limite :
```
  [Service]
  LimitMEMLOCK=infinity
```

2. File Descriptors (La "Limite de Capacité")

Le Concept : Elasticsearch (via Lucene) décompose vos données en fichiers immuables fortement compressés appelés "segments". Un seul nœud peut facilement garder des milliers de ces petits fichiers ouverts simultanément. La limite par défaut de Linux pour les fichiers ouverts par utilisateur est souvent de 1024. C'est beaucoup trop bas. Si Elasticsearch atteint cette limite, il peut perdre silencieusement des données ou planter car il ne peut pas écrire dans de nouveaux fichiers.

Comment le configurer

Vous devez augmenter la limite à au moins 65 536.

Vérifier la limite actuelle : ulimit -n
Correctif permanent : Éditer /etc/security/limits.conf :
```
  elasticsearch - nofile 65536
```
(Si vous installez via un paquet RPM/Deb, cela est souvent fait automatiquement, mais vous devez le vérifier).

3. Virtual Memory (L'exigence `mmap`)

Le Concept : C'est spécifique à la façon dont Lucene lit les données. Il utilise un appel système appelé mmap (memory map) pour mapper les fichiers sur le disque directement dans l'espace d'adressage de la mémoire virtuelle. C'est incroyablement rapide car cela laisse le noyau gérer la mise en cache des fichiers. Cependant, la limite par défaut du système d'exploitation sur le nombre de "maps mémoire" qu'un processus peut posséder est généralement de 65 530. Elasticsearch en nécessite beaucoup plus.

Comment le configurer

C'est la raison la plus courante des échecs de démarrage.

Commande (Live) :
```
  sysctl -w vm.max_map_count=262144
```
Correctif permanent : Ajoutez cette ligne à /etc/sysctl.conf :
```
  vm.max_map_count=262144
```

4. JVM Heap Size (Le jeu d'équilibre)

C'est le paramètre le plus mal compris. Vous configurez la mémoire de la Machine Virtuelle Java (JVM).

A. `Xms` et `Xmx` (Min vs. Max)

Le Problème : Par défaut, Java démarre avec une petite heap (Xms) et l'agrandit selon les besoins jusqu'au max (Xmx). Ce processus de redimensionnement met en pause l'exécution.
La Solution : Définissez-les à la même valeur. Cela alloue toute la mémoire immédiatement au démarrage, empêchant les pauses de redimensionnement.
```
  # /etc/elasticsearch/jvm.options
  -Xms4g
  -Xmx4g
```

B. La règle des 50% (Pourquoi pas 100% ?)

Si vous avez une machine de 64GB, pourquoi donner seulement 30GB à Elasticsearch ? Pourquoi pas 60GB ?

La Raison : Elasticsearch repose sur deux types de mémoire :
1. JVM Heap : Pour les objets de requête, les agrégations et le Cluster State.
2. OS Filesystem Cache : C'est là que vivent les données réelles (segments Lucene).
Si vous donnez toute la RAM à la Heap, l'OS n'a plus de place pour mettre les fichiers en cache. Le disque sera sollicité à l'excès (thrashed), et les performances s'effondreront.
Règle : 50% à la Heap, 50% laissés libres pour l'OS.

C. La limite de 32GB (Compressed Oops)

Vous ne devez jamais définir la Heap au-dessus de ~32GB (le seuil exact varie, généralement 30GB-31GB est sûr).

La Science : En dessous de 32GB, Java utilise des "Compressed Ordinary Object Pointers" (Compressed Oops). Il utilise des pointeurs de 32-bit pour référencer la mémoire.
Le Piège : Une fois que vous franchissez le seuil (ex : 32.1GB), Java bascule vers des pointeurs 64-bit. Ils sont plus grands.
Le Résultat : Une Heap de 35GB stocke en réalité moins de données qu'une Heap de 31GB car les pointeurs eux-mêmes prennent beaucoup plus de place. De plus, cela consomme plus de bande passante CPU.

Security (La couche "Must-Have")

Cette section piège souvent les nouveaux administrateurs car elle implique des certificats et des mots de passe, ce qui peut être fastidieux. Cependant, dans les versions modernes d'Elasticsearch (version 8.x+), la sécurité est activée par défaut. Vous ne pouvez pas exécuter un cluster de production sans elle.

1. TLS/SSL Encryption (Le "Tunnel Chiffré")

Le chiffrement empêche les attaques de type "Man-in-the-Middle". Dans Elasticsearch, nous implémentons cela en deux couches distinctes. Si vous manquez la première, votre cluster ne démarrera même pas.

A. Transport Layer (Node-to-Node)

Ce que c'est : Le canal de communication interne sur le port 9300 où les nœuds se parlent (élection des maîtres, déplacement des shards, réplication des données).
Pourquoi c'est obligatoire : Elasticsearch nécessite une confiance mutuelle. Le Nœud A doit prouver au Nœud B qu'il est une partie légitime du cluster, et non un serveur malveillant essayant de voler des données.
Le Mécanisme :
1. Vous générez une Certificate Authority (CA).
2. Vous signez un certificat pour chaque nœud en utilisant cette CA.
Note Cruciale : Si vous n'activez pas le Transport SSL, Elasticsearch refusera de se lier à une adresse IP non-loopback (c'est-à-dire qu'il reste en "Development Mode").
Outil clé : bin/elasticsearch-certutil (Cet outil intégré simplifie la création de ces certificats).

B. HTTP Layer (Client-to-Cluster)

Ce que c'est : L'API externe sur le port 9200 où Kibana, votre application (Java/Python/Node.js) et les utilisateurs se connectent.
Pourquoi c'est critique : Sans cela, les identifiants Basic Auth (username/password) sont envoyés en texte clair. N'importe qui sur le réseau peut intercepter le mot de passe admin.
Configuration : Vous utilisez généralement la même CA pour signer ces certificats, ou vous pouvez utiliser une CA publique (Let's Encrypt, Verisign) si votre cluster est public-facing.

2. Authentication & RBAC (Le "Gatekeeper")

Une fois la connexion sécurisée, vous devez contrôler qui se connecte et ce qu'ils peuvent toucher. C'est le Role-Based Access Control (RBAC).

A. Les utilisateurs intégrés

Lorsque vous démarrez le cluster pour la première fois, vous exécutez bin/elasticsearch-reset-password. Cela configure les comptes réservés qui sont vitaux pour la stack :

elastic: Le "Superuser" (Root). Il a le contrôle total.

Danger : N'utilisez pas ce compte dans le code de votre application ! Si ces identifiants fuitent, tout votre cluster est compromis.
kibana_system: Un service account utilisé uniquement par le serveur Kibana pour parler à Elasticsearch. Il ne peut pas être utilisé pour se connecter au tableau de bord.

B. Le Principe du Moindre Privilège

Vous devriez créer des rôles personnalisés pour chaque cas d'usage spécifique.

Le Rôle "Developer" : Peut lire et surveiller les index mais ne peut pas supprimer de données ou changer les paramètres du cluster.
Le Rôle "App" : Peut écrire dans l'index logs-* mais ne peut pas lire l'index salary-data.
Document Level Security (DLS) : Vous pouvez même restreindre l'accès au sein d'un seul index.
- Exemple : "L'utilisateur A peut chercher dans l'index employees, mais seulement les documents où department: 'marketing'."

3. Audit Logging (La "Boîte Noire")

Si des données disparaissent ou fuitent, comment savez-vous ce qui s'est passé ?

Ce qu'il suit : Vous pouvez le configurer pour journaliser des événements spécifiques : "Authentication Failed," "Index Deleted," ou même "L'utilisateur X a cherché la requête Y."
Conformité : C'est obligatoire pour des normes comme le RGPD, HIPAA et PCI-DSS.
Avertissement de performance : L'Audit logging est intensif en I/O.
Mauvaise pratique : Journaliser chaque opération de "read". Cela remplira votre disque de logs et ralentira les performances de recherche.
Meilleure pratique : Journaliser uniquement les opérations d'écriture/suppression" et les "authentication failures" pour détecter les attaques par force brute.

Deployment Methods

L'Introduction : Une taille unique ne convient pas à tous

Elasticsearch est agnostique en matière d'infrastructure. Il s'exécute partout où Java s'exécute. Le choix de la méthode de déploiement dépend généralement de trois facteurs :

Infrastructure existante : Êtes-vous déjà "all-in" sur Kubernetes ? Avez-vous des racks de serveurs physiques ?
Expertise de l'équipe : Vos opérationnels sont-ils à l'aise avec le Linux kernel tuning, ou préfèrent-ils écrire des manifestes YAML ?
Besoins d'évolutivité : Avez-vous besoin d'ajouter 10 nœuds en 5 minutes pendant le Black Friday, ou votre cluster est-il relativement statique ?

1. Bare Metal / Virtual Machines (L'approche "Classique")

C'est la manière traditionnelle de déployer des logiciels. Vous traitez Elasticsearch comme n'importe quelle autre base de données (PostgreSQL, MySQL).

Comment ça marche :

Vous provisionnez des serveurs Linux (matériel physique ou VMs comme EC2/Azure VMs), installez Java (si vous utilisez d'anciennes versions d'ES), configurez les prérequis de l'OS (comme discuté dans la section OS Tuning), ajoutez le dépôt Elastic et installez via les gestionnaires de paquets :

# Exemple Ubuntu/Debian
wget -qO - [https://artifacts.elastic.co/GPG-KEY-elasticsearch](https://artifacts.elastic.co/GPG-KEY-elasticsearch) | sudo gpg --dearmor -o /usr/share/keyrings/elasticsearch-keyring.gpg
sudo apt-get install elasticsearch

Avantages :

Performance Maximale : Vous avez un accès direct aux ressources matérielles sans aucune couche d'abstraction de conteneurisation. C'est idéal pour les cas d'utilisation ultra-performants.
Dépannage plus simple : Si vous devez déboguer la latence réseau ou les I/O disque, vous utilisez les outils Linux standard (iostat, tcpdump) directement sur l'hôte.
La persistance est facile : Les données sont écrites directement sur les disques attachés. Vous n'avez pas à vous soucier des Container Storage Interfaces (CSI) complexes.

Inconvénients :

Surcharge de maintenance : Monter en charge signifie provisionner manuellement un nouveau serveur et le configurer. Les mises à jour nécessitent des "rolling restarts" manuels et prudents.
Configuration Drift : Sans outils de gestion de configuration solides (Ansible, Chef, Puppet), les serveurs peuvent lentement diverger dans leurs configurations au fil du temps, menant à des problèmes du type "ça marche sur le nœud 1 mais pas sur le nœud 2".
Idéal pour : Les environnements IT traditionnels, les clusters stables de longue durée et les équipes ayant de solides compétences en administration Linux.

2. Docker / Containers (L'approche "Prototypage Rapide")

Docker a tout changé en permettant aux développeurs de lancer des stacks complexes localement en quelques secondes.

Comment ça marche : Elastic fournit des images Docker officielles et pré-renforcées. Vous exécutez rarement des commandes docker run simples. Au lieu de cela, vous utilisez Docker Compose pour définir un cluster multi-nœuds dans un seul fichier YAML.

Avantages :

Vitesse : Vous pouvez passer de zéro à un cluster fonctionnel de 3 nœuds sur votre ordinateur portable en moins de 60 secondes.
Cohérence : L'environnement est identique entre le développement, les tests et la pré-production. "Ça marche sur ma machine" signifie réellement quelque chose.
Isolation : Les dépendances sont empaquetées avec le conteneur.

Inconvénients :

Pas un Orchestrateur de Production : Docker Compose n'est généralement pas recommandé pour les environnements de production multi-hôtes. Il manque de fonctionnalités avancées de failover, de scaling et de networking nécessaires pour la haute disponibilité.
State Management : Vous devez être très prudent avec le volume mapping pour vous assurer que les données persistent si un conteneur redémarre.

Idéal pour : Le développement local, les pipelines de tests CI/CD et les très petits déploiements de production sur un seul hôte.

3. Kubernetes & ECK (Le Standard "Cloud-Native")

Si votre organisation a adopté Kubernetes (K8s), c'est presque certainement ainsi que vous devriez déployer Elasticsearch. Mais il y a un avertissement massif.

Le Piège du "Helm Chart" Les nouveaux utilisateurs de K8s essaient souvent de déployer Elasticsearch en utilisant des graphiques Helm génériques standard. Évitez cela. Elasticsearch est un système distribué complexe et stateful. Un déploiement K8s standard ne comprend pas que vous ne pouvez pas simplement tuer 3 nœuds maîtres simultanément pendant une mise à jour sans détruire le cluster.

La Solution : Elastic Cloud sur Kubernetes (ECK) Elastic a développé son propre Kubernetes Operator appelé ECK.

Qu'est-ce qu'un Operator ? Pensez-y comme un robot logiciel qui s'exécute à l'intérieur de votre cluster K8s et possède une connaissance opérationnelle humaine sur Elasticsearch. Il sait exactement dans quel ordre redémarrer les nœuds pour que le cluster ne tombe jamais en panne.

Comment ça marche : Au lieu de gérer directement les pods et les statefulsets, vous installez l'opérateur ECK, puis vous soumettez un simple YAML de ressource personnalisée à K8s disant "Je veux un cluster Elasticsearch".

L'Opérateur voit le YAML et crée automatiquement les Services, StatefulSets, PersistentVolumeClaims et génère les certificats TLS.

Avantages :

Day 2 Operations Automatisées : L'Opérateur gère automatiquement le scaling, les rolling upgrades, la configuration sécurisée et les backups.
Écosystème Elastic : Il rend le déploiement de Kibana, APM Server et Beats aux côtés d'Elasticsearch incroyablement facile.

Inconvénients :

Haute Complexité : Vous avez besoin d'une expertise Kubernetes significative avant d'ajouter la complexité d'exécuter une base de données stateful par-dessus.

Idéal pour : Les organisations modernes, cloud-native, nécessitant une infrastructure hautement dynamique et évolutive.

Configuration Best Practices

Le Guide Critique de Configuration `elasticsearch.yml`

Le fichier elasticsearch.yml est le centre de contrôle de votre nœud. Bien qu'il existe des centaines de paramètres, se tromper sur ces quelques-uns est la cause la plus fréquente de pannes de production ou de perte de données.

1. Identité : Noms de Cluster & de Nœud

Dans le vide, les noms ne semblent pas techniques. Dans un système distribué, ils sont vitaux pour l'observabilité et l'isolation.

A. `cluster.name`

Le Défaut : elasticsearch
Le Risque : Si vous laissez cela par défaut, un développeur malveillant ou imprudent démarrant une instance locale sur le même réseau (Wi-Fi ou VPN) pourrait accidentellement découvrir et rejoindre votre cluster de production.
Meilleure Pratique : Soyez descriptif et spécifique à l'environnement.

cluster.name: prod-search-cluster-v1

B. `node.name`

Le Défaut : Le nom d'hôte du serveur.
Le Risque : Des noms d'hôtes comme ip-10-0-0-5 sont difficiles à lire dans les logs ou les tableaux de bord Kibana.
Meilleure Pratique : Utilisez une convention de nommage qui indique le rôle et le numéro du nœud. Cela rend le débogage beaucoup plus rapide ("Oh, prod-master-02 est en panne" est plus actionnable que "Le Serveur X est en panne").

node.name: prod-data-hot-01

2. Discovery (Prévenir le "Split-Brain")

"Discovery" est le processus par lequel les nœuds se trouvent et élisent un leader (Master). Si cela est mal configuré, les nœuds formeront des clusters séparés et concurrents, menant à une incohérence des données (Split-Brain).

A. `discovery.seed_hosts` (L'annuaire téléphonique)

Ce paramètre dit au nœud : "Quand tu te réveilles, appelle ces gens pour demander où est le cluster."

Configuration : Vous n'avez pas besoin de lister chaque nœud. Listez simplement les adresses IP ou les noms d'hôtes de vos nœuds éligibles maîtres.

discovery.seed_hosts: ["192.168.1.10", "192.168.1.11", "192.168.1.12"]

Note : Si vous utilisez le Cloud/AWS, vous pourriez utiliser un plugin (comme discovery-ec2) pour les détecter automatiquement, mais coder les IP en dur est plus sûr pour le bare metal.

B. `cluster.initial_master_nodes` (Le Bootstrapper)

C'est le paramètre le plus déroutant pour les débutants. Il n'est utilisé qu'une seule fois dans toute la vie du cluster : la toute première fois que vous l'allumez.

Le Problème : Quand vous démarrez 3 nœuds vides, ils pensent tous "Je devrais être le Roi". Sans ce paramètre, ils pourraient former 3 clusters séparés de 1 nœud chacun.
La Solution : Ce paramètre les force à former un quorum. Il dit : "Ne démarre pas le cluster tant que tu ne vois pas un vote de ces nœuds spécifiques."
Configuration : DOIT correspondre exactement au node.name de vos nœuds maîtres.

cluster.initial_master_nodes: ["prod-master-01", "prod-master-02", "prod-master-03"]

Avertissement Critique : Une fois que le cluster est formé pour la première fois, supprimez ce paramètre (ou commentez-le) de votre gestion de configuration. Si vous le laissez, et que plus tard vous essayez de redémarrer un nœud pour rejoindre un cluster existant, il pourrait essayer d'amorcer un nouveau cluster au lieu de rejoindre l'ancien.

3. Path Settings (Sauver votre OS)

Par défaut, Elasticsearch écrit les données dans /var/lib/elasticsearch et les logs dans /var/log/elasticsearch. C'est dangereux.

A. Le risque de la "Partition Racine"

Sur Linux, /var fait généralement partie de la partition racine (/). Si vos utilisateurs inondent le cluster de données (remplissant path.data) ou si le cluster envoie des boucles d'erreurs massives (remplissant path.logs), vous remplirez le disque racine à 100%.

La Conséquence : Quand / est plein, Linux plante. Vous ne pouvez pas vous connecter en SSH pour réparer. Vous devez redémarrer physiquement en mode secours.

B. `path.data`

Meilleure Pratique : Montez un grand disque physique séparé (NVMe/SSD) sur un chemin comme /mnt/data et pointez Elasticsearch dessus. Si ce disque se remplit, Elasticsearch cesse de fonctionner, mais l'OS reste en vie, vous permettant de résoudre le problème.

path.data: /mnt/data/elasticsearch

Astuce Pro (Striping) : Vous pouvez fournir plusieurs chemins. Elasticsearch agira comme un RAID 0 logiciel, répartissant (striping) les données entre eux.

path.data:
  - /mnt/disk1
  - /mnt/disk2

C. `path.logs`

Meilleure Pratique : Idéalement, expédiez les logs vers un système distant (en utilisant Filebeat). Si vous les stockez localement, gardez-les sur une partition séparée de path.data pour qu'un pic de logs massif ne consomme pas votre espace de stockage de données.

Operations & Maintenance: From Hobby to Production

Cette section définit la différence entre un cluster "hobby" et un cluster de "production". Le déploiement est un événement unique ; les opérations sont éternelles.

1. Monitoring: Vous ne pouvez pas gérer ce que vous ne voyez pas

Une erreur courante est d'attendre que les utilisateurs se plaignent que "La recherche est lente" avant de vérifier le cluster. Vous avez besoin d'une visibilité proactive.

A. Les Outils

1. Elastic Stack Monitoring (La Voie Native)

Comment ça marche : Vous activez xpack.monitoring. Le cluster envoie des métriques à lui-même (ou de préférence, à un "Monitoring Cluster" séparé pour éviter d'ajouter de la charge au système de production).
Avantages : Profondément intégré ; l'interface Kibana est pré-construite et excellente.

2. Prometheus & Grafana (La Voie Cloud-Native)

Comment ça marche : Vous exécutez un conteneur sidecar elasticsearch-exporter. Prometheus le scrape, et Grafana le visualise.
Avantages : Standard de l'industrie ; vous permet de corréler les métriques Elasticsearch avec les métriques Linux/Network sur le même tableau de bord.

B. Les "Big 4" Métriques à surveiller

JVM Heap Usage
- Sain : Un motif en "dents de scie" (la mémoire se remplit, le Garbage Collection la nettoie, répéter).
- Danger : Une ligne plate près de 75-90%. Cela signifie que le nœud est affamé de mémoire et va bientôt planter avec une OutOfMemoryError.
Garbage Collection (GC) Count & Time
- Danger : Si le temps de GC "Old Gen" grimpe, votre nœud met en pause l'exécution (Stop-the-World) pour nettoyer la mémoire. Les requêtes de recherche seront suspendues pendant ces pauses.
CPU Usage
- Un CPU élevé est normal pendant l'indexation lourde, mais s'il reste à 100% en continu, vos nœuds sont sous-dimensionnés ou vos requêtes sont trop complexes (ex : wildcards commençant par *).
Thread Pool Rejections
- C'est la métrique d'erreur la plus critique. Cela signifie que le nœud dit : "Je suis trop occupé ; je ne peux pas accepter cette requête." Si les rejets de recherche ou d'écriture sont > 0, vous avez un problème de capacité.

2. Backups: Replicas ≠ Backups

C'est la leçon la plus importante en matière de sécurité des données.

Le Mythe

"J'ai 2 réplicas, donc j'ai 3 copies de mes données. Je n'ai pas besoin de backups."

La Réalité

Les réplicas protègent contre les Hardware Failure (crash de disque). Ils ne protègent pas contre l'Erreur Humaine.

Scénario : Vous exécutez accidentellement DELETE /users.
Résultat : Elasticsearch supprime le Primary shard immédiatement, et propage instantanément cette instruction de suppression à tous les Replica shards. Vos données ont disparu des 3 copies en quelques millisecondes.

La Solution : Snapshots & SLM

Vous devez prendre des Snapshots (instantanés), qui sont des backups incrémentiels envoyés vers un stockage de référentiel externe (S3, Google Cloud Storage, Azure Blob, ou un lecteur NFS partagé).

Incrémentiel : Le premier snapshot copie tout. Le second snapshot copie seulement les segments qui ont changé. C'est léger et rapide.
SLM (Snapshot Lifecycle Management) : N'écrivez pas de scripts manuels. Utilisez la fonctionnalité intégrée SLM pour définir une politique.
Exemple de Politique : "Prendre un snapshot chaque nuit à 2h du matin. Garder les 30 derniers snapshots. Supprimer les plus anciens automatiquement."

3. Updates: La stratégie de "Rolling Restart"

Mettre à jour une base de données signifiait autrefois "Scheduled Downtime" (Temps d'arrêt planifié) un dimanche soir. Avec Elasticsearch, vous pouvez mettre à jour sans temps d'arrêt si vous suivez la procédure de "Rolling Restart".

La Logique

Vous n'éteignez jamais tout le cluster. Vous éteignez un nœud, le mettez à jour, le rallumez et passez au suivant.

L'Étape Critique : Désactiver l'Allocation

Avant d'arrêter un nœud, vous devez dire au cluster : "J'éteins ce nœud exprès. Ne panique pas et ne commence pas à reconstruire ses données ailleurs."

Le Workflow

1. Stop Allocation (Cela fige la disposition du cluster pour que les shards ne bougent pas).

PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.enable": "primaries"
  }
}

2. Stop the Node Exécutez systemctl stop elasticsearch.

3. Upgrade Mettez à jour le paquet ou remplacez l'image Docker.

4. Start the Node Exécutez systemctl start elasticsearch.

5. Wait for Green Surveillez les logs ou _cat/nodes jusqu'à ce que le nœud rejoigne le cluster.

6. Re-enable Allocation

PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.enable": null
  }
}

7. Repeat Passez au nœud suivant.

Common Pitfalls: The Difference Between Novices and Experts

Cette section sépare les novices des experts. Ce sont les problèmes qui n'apparaissent pas dans un tutoriel "Hello World" ; ils n'apparaissent que lorsque vous êtes en production, sous charge, et généralement à 3 heures du matin.

1. Split Brain (Le problème des "Deux Capitaines")

Ce diagramme fournit une représentation visuelle du scénario de "split-brain", où une partition réseau conduit à la formation de deux clusters séparés, chacun avec son propre maître, risquant l'incohérence des données.

C'est le scénario cauchemardesque pour les systèmes distribués.

Le Scénario

Imaginez que vous avez un cluster de 3 nœuds (A, B, C) dans une seule pièce. Un switch réseau tombe en panne, coupant la pièce en deux. Les nœuds A et B peuvent se parler, mais le nœud C est isolé.

Le Glitch

Les nœuds A+B réalisent que C a disparu. Ils élisent le Nœud A comme Master.
Le nœud C pense que A et B sont morts. Il s'élit lui-même comme Master.

Le Résultat (Split Brain)

Vous avez maintenant deux maîtres actifs dans le même cluster.

L'Application 1 écrit des données sur le Nœud A.
L'Application 2 écrit des données sur le Nœud C.

La Catastrophe

Quand le réseau revient, vous avez deux versions différentes de l'historique. Elasticsearch ne peut pas "fusionner" ces chronologies. Vous perdrez probablement les données écrites du côté le plus petit de la partition.

Le Fix (Quorum)

Dans les anciennes versions (6.x et moins) : Vous deviez définir manuellement discovery.zen.minimum_master_nodes à (N/2) + 1.
Dans les versions modernes (7.x+) : Elasticsearch utilise automatiquement un système de Voting Configuration. Cependant, vous devez vous assurer d'avoir 3 nœuds éligibles maîtres (un nombre impair) pour qu'il y ait toujours un gagnant majoritaire lors d'un vote. Ne faites jamais tourner un cluster de production avec exactement 2 nœuds maîtres.

2. Mapping Explosion (La "Mort par Champs")

Elasticsearch est sans schéma par défaut (Dynamic Mapping), ce qui semble génial jusqu'à ce que cela plante votre cluster.

Le Scénario

Vous journalisez les cookies utilisateurs ou les en-têtes HTTP. Un développeur décide d'envoyer un document JSON où les clés sont des UUID uniques ou des horodatages.

{
  "2024-01-30_12:00": "error",
  "2024-01-30_12:01": "info"
}

Le Bug

Le dynamic mapping voit un nouveau champ ("2024-01-30_12:00") et l'ajoute au Cluster State (le registre global de tous les paramètres).

Le Résultat

Chaque clé unique devient un nouveau champ. Si vous envoyez 10 000 documents avec des clés uniques, vous créez 10 000 champs.

Le Cluster State devient massif (des centaines de Mo).
Cet état doit être synchronisé avec chaque nœud. Le mettre à jour prend des secondes. Le cluster devient non réactif.

Le Correctif

Désactiver le Dynamic Mapping : Définissez dynamic: false ou strict dans vos modèles de production.
Utiliser le Type de Données flattened : Si vous devez stocker du JSON non structuré avec des clés inconnues, mappez ce champ spécifique comme type: "flattened". Elasticsearch traitera l'objet JSON entier comme un seul champ mot-clé, empêchant l'explosion.
Limiter les Champs : La limite par défaut est de 1 000 champs par index (index.mapping.total_fields.limit). Ne l'augmentez pas. Si vous l'atteignez, votre modèle de données est mauvais.

3. Deep Pagination (La "Requête Tueuse")

Vos utilisateurs veulent sauter à la "Page 50 000" des résultats de recherche. Vous devez leur dire "Non".

Le Scénario

Un utilisateur exécute une requête avec from: 50000, size: 10.

Le Bug (Distributed Sorting Cost)

Pour trouver le "top 10" des résultats commençant à 50 000, Elasticsearch ne peut pas simplement sauter les 50 000 premiers enregistrements.

Chaque shard impliqué dans la recherche doit récupérer ses propres 50 010 meilleurs résultats et les garder en mémoire.
Si vous avez 10 shards, le nœud de coordination reçoit 50 010 * 10 = 500 100 documents.
Il doit trier ce demi-million d'enregistrements en RAM, rejeter les 500 000 premiers et renvoyer les 10 derniers.

Le Résultat

Pics massifs de CPU et boucles de Garbage Collection (GC). Si plusieurs utilisateurs font cela simultanément, le nœud manque de mémoire (OOM) et plante.

Le Correctif

Limite stricte : Elasticsearch définit par défaut index.max_result_window à 10 000. Ne l'augmentez pas à moins de savoir exactement ce que vous faites.
Pour les Utilisateurs (search_after) : C'est la manière efficace de paginer. Cela dit à Elasticsearch : "Donne-moi les 10 résultats suivants après cette valeur de tri spécifique du dernier résultat." Cela ne nécessite pas de scan profond.
Pour les Scripts (Scroll API / PIT) : Si vous devez exporter l'ensemble des données, utilisez le Point-in-Time (PIT) ou l'API Scroll, qui est conçue pour le traitement par lots.

Command Palette

Définition

Architecture & Capacity Planning

1. Node Roles

A. Rôles de base obligatoires

1. Master-eligible node (master)

2. Data node (data)

B. Core Utility Roles (Hautement recommandés)

1. Ingest node (ingest)

2. Coordinating-only node (Aucun rôle spécifique défini)

C. Specialized Roles (Optionnels)

1. Machine Learning node (ml)

2. Remote Cluster Client (remote_cluster_client)

3. Transform node (transform)

4. Voting-only node (voting_only)

2. Hardware Requirements

A. RAM (Mémoire)

B. Disk (Stockage)

C. Network

3. Sizing & Sharding

A. Shard Strategy

1. Le Concept

2. Le piège de l'Oversharding"

B. Replicas

1. Failover (Haute Disponibilité)

2. Read Throughput (Scaling Search)

Environment Preparation (OS Tuning)

1. Disable Swapping (Le "Tueur de Performance")

Comment le configurer

2. File Descriptors (La "Limite de Capacité")

Comment le configurer

3. Virtual Memory (L'exigence mmap)

Comment le configurer

4. JVM Heap Size (Le jeu d'équilibre)

A. Xms et Xmx (Min vs. Max)

B. La règle des 50% (Pourquoi pas 100% ?)

C. La limite de 32GB (Compressed Oops)

Security (La couche "Must-Have")

1. TLS/SSL Encryption (Le "Tunnel Chiffré")

A. Transport Layer (Node-to-Node)

B. HTTP Layer (Client-to-Cluster)

2. Authentication & RBAC (Le "Gatekeeper")

A. Les utilisateurs intégrés

B. Le Principe du Moindre Privilège

3. Audit Logging (La "Boîte Noire")

Deployment Methods

L'Introduction : Une taille unique ne convient pas à tous

1. Bare Metal / Virtual Machines (L'approche "Classique")

Comment ça marche :

2. Docker / Containers (L'approche "Prototypage Rapide")

3. Kubernetes & ECK (Le Standard "Cloud-Native")

Configuration Best Practices

Le Guide Critique de Configuration elasticsearch.yml

1. Identité : Noms de Cluster & de Nœud

A. cluster.name

B. node.name

2. Discovery (Prévenir le "Split-Brain")

A. discovery.seed_hosts (L'annuaire téléphonique)

B. cluster.initial_master_nodes (Le Bootstrapper)

3. Path Settings (Sauver votre OS)

A. Le risque de la "Partition Racine"

B. path.data

C. path.logs

Operations & Maintenance: From Hobby to Production

1. Monitoring: Vous ne pouvez pas gérer ce que vous ne voyez pas

A. Les Outils

B. Les "Big 4" Métriques à surveiller

2. Backups: Replicas ≠ Backups

Le Mythe

La Réalité

La Solution : Snapshots & SLM

3. Updates: La stratégie de "Rolling Restart"

La Logique

L'Étape Critique : Désactiver l'Allocation

Le Workflow

Common Pitfalls: The Difference Between Novices and Experts

1. Split Brain (Le problème des "Deux Capitaines")

Le Scénario

Le Glitch

Le Résultat (Split Brain)

1. Master-eligible node (`master`)

2. Data node (`data`)

1. Ingest node (`ingest`)

1. Machine Learning node (`ml`)

2. Remote Cluster Client (`remote_cluster_client`)

3. Transform node (`transform`)

4. Voting-only node (`voting_only`)

3. Virtual Memory (L'exigence `mmap`)

A. `Xms` et `Xmx` (Min vs. Max)

Le Guide Critique de Configuration `elasticsearch.yml`

A. `cluster.name`

B. `node.name`

A. `discovery.seed_hosts` (L'annuaire téléphonique)

B. `cluster.initial_master_nodes` (Le Bootstrapper)

B. `path.data`

C. `path.logs`