Comprendiendo la Elección del Nodo Maestro y los Requisitos de Cuórum en Elasticsearch

El cuórum del nodo maestro de Elasticsearch determina si tu clúster puede elegir de manera segura un líder, publicar cambios en el estado del clúster y evitar que dos lados desconectados del mismo clúster tomen decisiones diferentes.

El maestro elegido no acelera las búsquedas por sí mismo. Coordina el clúster. Cuando las elecciones son inestables, los síntomas pueden parecer dispersos: la creación de índices se congela, la asignación de fragmentos se detiene, Kibana reporta estados de salud cambiantes y los registros repiten mensajes sobre un maestro que no se descubre.

El Papel Crítico del Nodo Maestro

Mientras que los nodos de datos se encargan del trabajo pesado de indexar, buscar y almacenar datos, el nodo maestro es responsable de gestionar la estructura y los metadatos de todo el clúster. Normalmente no participa en operaciones de consulta o indexación a menos que también esté configurado como nodo de datos.

Responsabilidades del Nodo Maestro

1. Gestión del Estado del Clúster: El maestro mantiene y publica el estado del clúster—un plano de la configuración actual del clúster, incluyendo qué índices existen, las asignaciones y configuraciones de esos índices, y la ubicación de cada fragmento.
2. Gestión de Nodos: Manejar la unión y salida de nodos, actualizando el estado del clúster en consecuencia.
3. Gestión de Índices: Crear, eliminar o actualizar índices.
4. Asignación de Fragmentos: Decidir dónde deben residir los fragmentos primarios y réplica (asignación inicial y rebalanceo después de una falla de nodo).

Si el maestro elegido falla, el clúster pausa el trabajo exclusivo del maestro hasta que se elija otro. Las búsquedas existentes pueden continuar para los fragmentos disponibles, pero la creación de índices, las actualizaciones de asignaciones y las decisiones de asignación dependen de una coordinación estable del maestro.

Comprendiendo la Elección del Maestro y la Votación

En un sistema distribuido, se requiere un proceso de elección cada vez que el nodo maestro actual falla o se vuelve inalcanzable. Desde Elasticsearch 7.0, el mecanismo de elección se ha simplificado y endurecido significativamente, principalmente mediante la eliminación del complejo ajuste discovery.zen.minimum_master_nodes y la introducción de Configuraciones de Votación autogestionadas.

El Proceso de Elección (Elasticsearch 7.x+)

La elección del maestro ahora se maneja automáticamente por los nodos elegibles para maestro, que se definen en la configuración usando node.roles: [master, data], o simplemente node.roles: [master] para maestros dedicados.

1. Descubrimiento de Candidatos: Los nodos elegibles para maestro se comunican para determinar el conjunto de miembros votantes activos.
2. Verificación de Cuórum: Los nodos verifican si pueden alcanzar un cuórum—una mayoría de los nodos votantes conocidos—para asegurar el consenso.
3. Selección del Líder: Si se establece un cuórum, el subsistema de coordinación de Elasticsearch selecciona un maestro de acuerdo con sus reglas internas de elección.
4. Votación y Compromiso: La propuesta se vota, y si es aceptada por la mayoría, el nuevo maestro toma el control y publica el nuevo estado del clúster.

Arranque Inicial del Clúster

Al iniciar un clúster nuevo por primera vez, Elasticsearch necesita saber qué nodos deben participar en la configuración de votación inicial. Esto se maneja usando el ajuste cluster.initial_master_nodes. Este ajuste solo debe usarse una vez durante el inicio inicial del clúster.

# fragmento de elasticsearch.yml para configuración inicial
cluster.name: my-production-cluster
node.name: node-1
node.roles: [master, data]

# Lista los nombres de todos los nodos elegibles para maestro usados para el arranque inicial
cluster.initial_master_nodes: [node-1, node-2, node-3]

Consejo: Una vez que el clúster se haya formado, elimina cluster.initial_master_nodes de cada nodo. Dejarlo puede ser peligroso durante reinicios posteriores porque este ajuste solo está destinado para el primer arranque de un clúster nuevo.

Requisitos de Cuórum y Prevención de División de Cerebro

La razón fundamental de los requisitos de cuórum es garantizar que solo un líder pueda ser elegido en cualquier momento, evitando así el problema de división de cerebro.

¿Qué es la División de Cerebro?

La división de cerebro ocurre cuando una partición de red divide el clúster en segmentos aislados, y más de un segmento cree que tiene el maestro autoritario. Si eso sucede, diferentes lados pueden aceptar cambios conflictivos en el estado del clúster, que es exactamente lo que el cuórum está diseñado para prevenir.

La Regla del Cuórum (Consenso Mayoritario)

Para prevenir la división de cerebro, Elasticsearch aplica una regla de consenso mayoritario, requiriendo un número mínimo de nodos votantes para acordar cualquier cambio en el estado del clúster. Este mínimo es el cuórum, calculado como:

$$\text{Cuórum} = \lfloor (\text{Número de Nodos Votantes} / 2) \rfloor + 1$$

Al requerir una mayoría estricta, si la red se particiona, solo el lado más grande (que tiene la mayoría) puede alcanzar el cuórum y continuar operando. El lado más pequeño, incapaz de elegir un maestro, se detendrá y esperará a que se restaure la conectividad de red, evitando así escrituras de datos en el segmento particionado.

Número de Nodos Maestros Votantes (N)	Cuórum Requerido (N/2 + 1)
3	2
5	3
7	4

Advertencia de Mejores Prácticas: Siempre despliega un número impar de nodos elegibles para maestro (por ejemplo, tres o cinco). Desplegar un número par (por ejemplo, cuatro) ofrece la misma tolerancia a fallos que el número impar anterior (tres), pero requiere más recursos. Por ejemplo, un clúster de votación de 4 nodos requiere 3 votos (N/2+1), lo que significa que solo puede tolerar una falla, igual que un clúster de 3 nodos, pero usa un servidor extra.

Configurando Nodos Maestros Dedicados

Para entornos de producción, tres nodos elegibles para maestro dedicados son la línea base común. Esto separa la carga de búsqueda e indexación del trabajo de coordinación. Los clústeres de desarrollo pequeños pueden ejecutar roles mixtos, pero un clúster que importa no debería permitir que una agregación pesada o un pico de ingesta prive al maestro elegido.

Ejemplo de Configuración de Nodo (Maestro Dedicado)

Para configurar un nodo como elegible para maestro pero no almacenar datos o ejecutar pipelines de ingesta, usa los siguientes roles en elasticsearch.yml:

# Nodo 1: Maestro Dedicado
node.name: es-master-01
node.roles: [master]

# Vincula el transporte a una red privada y restringe el acceso con firewalls/grupos de seguridad.
# network.host: 10.0.0.1

Ejemplo de Configuración de Nodo (Nodo de Datos Dedicado)

Por el contrario, un nodo de datos dedicado debe evitar participar en el proceso de elección del maestro:

# Nodo 4: Nodo de Datos Dedicado
node.name: es-data-04
node.roles: [data]

# Si no se especifican roles, Elasticsearch asigna el conjunto de roles predeterminado para esa versión.

Configuraciones de Descubrimiento del Clúster

Todos los nodos deben configurarse para encontrar el mismo conjunto de nodos elegibles para maestro usando el ajuste discovery.seed_hosts. Este ajuste lista las direcciones de red donde Elasticsearch puede intentar contactar a otros nodos para unirse al clúster.

# Configuración común para todos los nodos en el clúster
discovery.seed_hosts: ["10.0.0.1:9300", "10.0.0.2:9300", "10.0.0.3:9300"]

Esta lista debe contener las direcciones de los nodos elegibles para maestro (es-master-01, es-master-02, es-master-03, etc.).

Solución de Problemas de Elección

Si el clúster no logra elegir un maestro, típicamente entra en un estado 'rojo' o 'amarillo' y registra errores persistentes. Las causas comunes incluyen:

Problema	Descripción y Solución
Problemas de Red	Los nodos no pueden comunicarse debido a reglas de firewall, problemas de enrutamiento, problemas de DNS o alta latencia. El puerto de transporte, comúnmente 9300, debe ser accesible entre nodos. HTTP, comúnmente 9200, es para acceso de cliente/API y no es el canal de elección.
Discrepancia de Configuración	cluster.name es incorrecto o discovery.seed_hosts no apunta a los nodos elegibles para maestro correctos. Verifica que todos los nodos usen configuraciones idénticas.
Pérdida de Cuórum	Demasiados nodos votantes han fallado a la vez, como dos fallas en una configuración de tres maestros. Si los nodos faltantes se han ido permanentemente, usa la API de exclusiones de configuración de votación con cuidado y solo después de confirmar el modo de falla.
E/S de Disco	La E/S de disco del nodo maestro está saturada, impidiéndole publicar el estado del clúster rápidamente, lo que lleva a tiempos de espera y elecciones repetidas.

Verificando la Configuración de Votación

Puedes inspeccionar la configuración de votación actual usando la API del Clúster:

GET /_cluster/state?filter_path=metadata.cluster_coordination

Esta salida confirma qué nodos se cuentan actualmente para el cuórum, asegurando que tu configuración coincida con tus objetivos de tolerancia a fallos.

El patrón de producción más seguro es aburrido: tres nodos elegibles para maestro dedicados en dominios de falla separados, redes de transporte estables, hosts semilla correctos y cluster.initial_master_nodes usado solo una vez. Cuando las elecciones fallan, resiste la tentación de reiniciar todos los nodos a la vez. Lee los registros, confirma qué nodos elegibles para maestro pueden verse entre sí y haz un cambio controlado a la vez.