Resiliencia de Elasticsearch: réplica + snapshot + CCR

Síntoma

Objetivo: dotar de resiliencia a Elasticsearch con replica shards, nodos master/data dedicados, snapshots de backup (SLM) y replicación entre clústeres (CCR).

1. Separar roles: nodos master y data dedicados

Para la estabilidad del clúster, los nodos master-eligible con voto (preferiblemente 3, una mayoría impar) se separan de la carga de datos. Asigne los roles con node.roles en elasticsearch.yml y defina los seed hosts para discovery. 3 masters evitan el 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. Definir el número de réplicas del índice

number_of_replicas es el número de copias que se mantienen de cada primary shard; debe ser al menos 1 para que los datos sigan disponibles si se pierde un nodo data. Puede cambiarse dinámicamente en un índice en uso; el número de réplicas debe ser menor que el número de nodos 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. Definir un repositorio de snapshots

Los backups se toman en un repositorio: un sistema de archivos compartido (fs) o los plugins de S3/GCS/Azure. Para poder recuperar los datos incluso si se elimina el clúster, el repositorio debe estar en almacenamiento duradero fuera del clúster.

Elasticsearch

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

4. Programar snapshots automáticos con SLM

Snapshot Lifecycle Management (SLM) toma snapshots periódicos y aplica una política de retención. Una expresión cron define la frecuencia; también se definen los índices incluidos y cuántos snapshots se conservan.

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. Verificar el snapshot y la restauración

Ejecute manualmente la política SLM para verificar que funciona; el estado del snapshot debe ser SUCCESS. Realice pruebas de restauración con regularidad, porque un backup no probado no es un backup.

Elasticsearch

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

6. Configurar DR remoto con Cross-Cluster Replication (CCR)

Para la recuperación ante desastres entre regiones, un segundo clúster (follower) sigue los índices del clúster primario remoto (leader). Primero defina el clúster remoto y luego vincule el índice follower al leader; los cambios en el leader se propagan automáticamente. CCR es una funcionalidad Platinum (comercial).

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" }