Nivel 3 · 30 min

Gestión de Cluster

Elasticsearch es un sistema distribuido. Entender los roles de nodo, la elección de master, el health del cluster y los mecanismos de recovery es esencial para diseñar clusters resilientes y diagnosticar outages.

Roles de Nodo y Arquitectura

Cada nodo Elasticsearch puede tener uno o más roles. Los nodos master-eligible participan en la elección de master y gestionan el cluster state. Los nodos master dedicados no deben contener shards de datos: necesitan pausas de JVM estables y baja carga de CPU. Los nodos data almacenan shards y manejan búsqueda/indexación. Los nodos coordinating-only enrutan requests, mergean resultados de shards y alivian trabajo de los data nodes. Los nodos ingest ejecutan pipelines de ingest. Arquitectura hot-warm-cold: nodos hot (SSD, CPU potente) contienen datos recientes; warm (HDD, menos CPU) datos más viejos; cold usa índices frozen en object storage.

Elección de Master y Split-Brain

Elasticsearch usa un protocolo de consenso basado en Raft (desde 7.0) para la elección de master. El requisito de quórum previene el split-brain: con N nodos master-eligible, el quórum es (N/2)+1. Un cluster de 3 nodos master tolera 1 fallo (quórum = 2). Un cluster de 5 tolera 2 fallos (quórum = 3). En ES 6 y anterior, la configuración minimum_master_nodes (= N/2 + 1) era crítica: configurarla incorrectamente causaba split-brain donde dos masters existían simultáneamente. ES 7+ maneja esto automáticamente via Raft. Nunca uses un número par de nodos master-eligible.

Snapshot y Restore

Los snapshots son el mecanismo primario de backup para Elasticsearch. Son incrementales: cada snapshot almacena solo los segmentos que cambiaron desde el último. Tipos de repositorio: fs (filesystem compartido), s3, gcs, azure. SLM (Snapshot Lifecycle Management) automatiza el scheduling y las políticas de retención. Cross-cluster replication (CCR) replica índices en near-real-time a un cluster follower. Searchable snapshots montan índices directamente desde el repositorio sin restauración completa, habilitando tiers cold/frozen.

Puntos clave

Usá nodos master dedicados (3 o 5, nunca 2 o 4) para prevenir split-brain. Los master nodes nunca deben contener shards de datos: necesitan heap estable y bajas pausas de GC.
ES 7+ usa Raft para elección de master automáticamente. En ES 6, configurar mal minimum_master_nodes era la causa principal de corrupción de cluster por split-brain.
Los snapshots son incrementales. Configurá SLM para backups automatizados. Usá CCR para geo-redundancia activa-activa u offloading de tráfico de lectura.

Code example

// Check cluster health\nGET /_cluster/health\n\n// Check shard allocation\nGET /_cluster/allocation/explain\n\n// Create snapshot repository (S3)\nPUT /_snapshot/my_backup\n{"type": "s3", "settings": {"bucket": "my-es-snapshots"}'}'\n\n// Trigger manual snapshot\nPUT /_snapshot/my_backup/snapshot_1?wait_for_completion=true