Architecture distribuée Elasticsearch : rôles des nœuds, shards, répliques et allocation

1. Nœuds et rôles #

Qui fait quoi.

Rôles #

# elasticsearch.yml d'un nœud data hot
node.name: es-hot-01
node.roles: [ data_hot, data_content, ingest ]
node.attr.zone: eu-west-3a

Le nœud master élu maintient le cluster state : liste des nœuds, mappings, emplacement de chaque shard. Il faut un quorum de nœuds éligibles : avec 3 nœuds éligibles, le cluster tolère la perte d'un seul.

Erreur Courante : Deux nœuds éligibles master ne protègent de rien : la perte de l'un fait perdre le quorum. Utilisez 3 nœuds (ou 2 + un nœud voting_only).

2. Shards et répliques #

La distribution des données.

Principe #

• Un index est découpé en shards primaires (fixés à la création) ; chacun est un index Lucene.
• Chaque primaire a des répliques (modifiables à chaud) : haute disponibilité et capacité de lecture.
• Une réplique n'est jamais placée sur le même nœud que son primaire.
• Statut green : tout est alloué ; yellow : des répliques manquent ; red : des primaires manquent.

3. Allocation et pannes #

Ce qui se passe quand un nœud tombe.

Allocation #

1. Le nœud cesse de répondre : le master le retire du cluster.
2. Les répliques de ses primaires sont promues primaires : aucune donnée perdue, le cluster passe en yellow.
3. Après index.unassigned.node_left.delayed_timeout (1 minute par défaut), de nouvelles répliques sont reconstruites sur les nœuds restants.
4. Au retour du nœud, Elasticsearch rééquilibre les shards.

GET _cluster/health
GET _cat/shards?v&h=index,shard,prirep,state,node,unassigned.reason
GET _cluster/allocation/explain

# répartir les répliques entre zones de disponibilité
PUT _cluster/settings
{ "persistent": { "cluster.routing.allocation.awareness.attributes": "zone" } }

Bonne Pratique : Avec l'allocation awareness par zone, une réplique et son primaire sont toujours dans deux zones différentes : la perte d'une zone entière ne perd aucune donnée.