Résilience Elasticsearch : réplica + snapshot + CCR

Symptôme

Objectif : renforcer la résilience d'Elasticsearch avec des shards réplicas, des nœuds master/data dédiés, des sauvegardes par snapshot (SLM) et la réplication inter-clusters (CCR).

1. Séparez les rôles : nœuds master et data dédiés

Pour la stabilité du cluster, les nœuds master-eligible votants (de préférence 3, pour une majorité impaire) sont séparés de la charge data. Attribuez les rôles avec node.roles dans elasticsearch.yml et définissez les seed hosts pour la découverte. 3 masters évitent le split-brain.

Elasticsearch

# elasticsearch.yml on master nodes:
# node.roles: [ master ]
# on data nodes:
# node.roles: [ data, ingest ]
# discovery.seed_hosts: [ m1, m2, m3 ]
# cluster.initial_master_nodes: [ m1, m2, m3 ]

2. Définissez le nombre de réplicas de l'index

number_of_replicas est le nombre de copies conservées pour chaque shard primaire ; il doit être d'au moins 1 pour que les données restent disponibles en cas de perte d'un nœud data. Il peut être modifié dynamiquement sur un index en service ; le nombre de réplicas doit être inférieur au nombre de nœuds data.

Elasticsearch

PUT /orders/_settings
{
  "index": { "number_of_replicas": 1 }
}
# default via template (composable template; the old _template API is legacy):
# PUT _index_template/order-tpl { "index_patterns": ["order*"], "template": { "settings": { "number_of_replicas": 1 } } }

3. Définissez un dépôt de snapshots

Les sauvegardes sont effectuées dans un dépôt : un système de fichiers partagé (fs) ou les plugins S3/GCS/Azure. Pour pouvoir récupérer les données même si le cluster est supprimé, le dépôt doit se trouver sur un stockage durable externe au cluster.

Elasticsearch

PUT /_snapshot/backup_repo
{
  "type": "fs",
  "settings": { "location": "/mnt/es_backups", "compress": true }
}

4. Planifiez des snapshots automatiques avec SLM

Snapshot Lifecycle Management (SLM) prend des snapshots réguliers et applique une politique de rétention. Une expression cron définit la fréquence, les index inclus et le nombre de snapshots conservés.

Elasticsearch

PUT /_slm/policy/daily_backup
{
  "schedule": "0 30 1 * * ?",
  "name": "<daily-{now/d}>",
  "repository": "backup_repo",
  "config": { "indices": ["*"] },
  "retention": { "expire_after": "30d", "min_count": 5, "max_count": 50 }
}

5. Vérifiez le snapshot et la restauration

Déclenchez manuellement la politique SLM pour vérifier qu'elle fonctionne ; l'état du snapshot doit être SUCCESS. Effectuez régulièrement des tests de restauration, car une sauvegarde non testée n'est pas une sauvegarde.

Elasticsearch

POST /_slm/policy/daily_backup/_execute
GET /_snapshot/backup_repo/_all
# restore:
POST /_snapshot/backup_repo/<snapshot_name>/_restore

6. Mettez en place une DR distante avec Cross-Cluster Replication (CCR)

Pour la reprise après sinistre inter-régions, un second cluster (follower) suit les index du cluster primaire distant (leader). Définissez d'abord le cluster distant, puis rattachez l'index follower au leader ; les modifications du leader sont propagées automatiquement. CCR est une fonctionnalité Platinum (commerciale).

Elasticsearch

# define the remote cluster on the follower cluster:
PUT /_cluster/settings
{ "persistent": { "cluster": { "remote": { "primary": { "seeds": ["leader1:9300"] } } } } }
# create the follower index:
PUT /orders-follower/_ccr/follow
{ "remote_cluster": "primary", "leader_index": "orders" }