Comprensión de la elección del nodo maestro de Elasticsearch y los requisitos de Quórum
Elasticsearch es un sistema distribuido que se basa en la coordinación entre nodos para mantener una vista consistente del estado del clúster. En el centro de esta coordinación se encuentra el Nodo Maestro. El nodo maestro es la única fuente de verdad para los metadatos del clúster, y garantizar su estabilidad y una elección adecuada es primordial para la salud, escalabilidad y resiliencia del clúster.
Este artículo detalla las responsabilidades críticas del nodo maestro, explica el proceso de elección moderno utilizado en las versiones recientes de Elasticsearch (7.x+), y aclara el concepto esencial de quórum—el mecanismo necesario para prevenir el devastador escenario conocido como el problema de split-brain.
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
- 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, los mapeos y ajustes para esos índices, y la ubicación de cada shard.
- Gestión de nodos: Maneja la unión y salida de nodos, actualizando el estado del clúster en consecuencia.
- Gestión de índices: Creación, eliminación o actualización de índices.
- Asignación de shards: Decide dónde deben residir los shards primarios y de réplica (asignación inicial y reequilibrio después de un fallo de nodo).
Si el nodo maestro falla, el clúster no puede realizar tareas administrativas ni reasignar shards hasta que se elija un nuevo maestro con éxito.
Comprensión de la elección y votación del maestro
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 ha sido simplificado y fortalecido significativamente, principalmente a través de la eliminación de la compleja configuración 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 es manejada automáticamente por los nodos elegibles para maestro, que se definen en la configuración utilizando node.roles: [master, data], o simplemente node.roles: [master] para maestros dedicados.
- Descubrimiento de candidatos: Los nodos elegibles para maestro se comunican para determinar el conjunto de miembros votantes activos.
- Verificación de quórum: Los nodos verifican si pueden alcanzar un quórum—una mayoría de los nodos votantes conocidos—para asegurar el consenso.
- Selección de líder: Si se establece un quórum, el candidato de mayor rango (basado en un mecanismo de desempate como el ID de estado del clúster) es propuesto como el nuevo maestro.
- Votación y compromiso: La propuesta es votada, 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 completamente nuevo por primera vez, Elasticsearch necesita saber qué nodos deben participar en la configuración de votación inicial. Esto se maneja utilizando la configuración cluster.initial_master_nodes. Esta configuración solo debe usarse una vez durante el arranque inicial del clúster.
# fragmento elasticsearch.yml para la 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 utilizados para el arranque inicial
cluster.initial_master_nodes: [node-1, node-2, node-3]
Consejo: Una vez que el clúster esté funcionando y estable, debe eliminar o comentar la configuración
cluster.initial_master_nodesde los archivos de configuración de todos los nodos para evitar posibles problemas si los nodos se reinician más tarde en un estado mixto.
Requisitos de quórum y prevención de split-brain
La razón fundamental de los requisitos de quórum es garantizar que solo un líder pueda ser elegido en cualquier momento, evitando así el problema de split-brain.
¿Qué es split-brain?
El split-brain ocurre cuando una partición de red divide el clúster en dos o más segmentos aislados, y cada segmento cree que es el maestro autoritativo. Si esto sucede, los nodos en diferentes segmentos pueden aceptar solicitudes de indexación y asignar shards de forma independiente, lo que lleva a inconsistencia y corrupción de datos cuando la red se recupera.
La regla del quórum (consenso de la mayoría)
Para prevenir el split-brain, Elasticsearch impone una regla de consenso de la mayoría, que requiere que un número mínimo de nodos votantes estén de acuerdo con cualquier cambio de estado del clúster. Este mínimo es el quórum, calculado como:
$$\text{Quó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 quórum y continuar operando. El lado más pequeño, incapaz de elegir un maestro, se detendrá y esperará a que se restablezca la conectividad de la red, evitando así escrituras de datos en el segmento particionado.
| Número de Nodos Maestros Votantes (N) | Quórum Requerido (N/2 + 1) |
|---|---|
| 3 | 2 |
| 5 | 3 |
| 7 | 4 |
Advertencia de buenas prácticas: Siempre despliegue 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 precedente (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 un fallo, lo mismo que un clúster de 3 nodos, pero utiliza un servidor adicional.
Configuración de nodos maestros dedicados
Para entornos de producción, especialmente clústeres grandes (más de 20 nodos de datos), es altamente recomendable utilizar nodos maestros dedicados. Esto separa las tareas que consumen muchos recursos de búsqueda/indexación de las cruciales funciones administrativas del maestro.
Ejemplo de configuración de nodo (maestro dedicado)
Para configurar un nodo como elegible para maestro pero que no almacene datos ni ejecute pipelines de ingesta, use los siguientes roles en elasticsearch.yml:
# Nodo 1: Maestro Dedicado
node.name: es-master-01
node.roles: [master]
# Deshabilitar tráfico HTTP/Transport para maestros puros (opcional, pero buena práctica de seguridad)
# http.enabled: false
# transport.bind_host: [ip_privada_del_maestro]
Ejemplo de configuración de nodo (nodo de datos dedicado)
Por el contrario, un nodo de datos dedicado debe impedirse que participe en el proceso de elección del maestro:
# Nodo 4: Nodo de Datos Dedicado
node.name: es-data-04
node.roles: [data]
# Nota: Si no se especifican roles, Elasticsearch por defecto usa [master, data, ingest] (valor predeterminado antes de 8.0)
Configuraciones de descubrimiento de clúster
Todos los nodos deben configurarse para encontrar el mismo conjunto de nodos elegibles para maestro utilizando la configuración discovery.seed_hosts. Esta configuración enumera 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 del 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.).
Resolució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 entre sí debido a reglas de firewall, problemas de enrutamiento o alta latencia. Asegúrese de que los puertos 9200 (HTTP) y 9300 (Transport) estén abiertos entre los nodos. |
| Incompatibilidad de configuración | cluster.name es incorrecto o discovery.seed_hosts no apunta a los nodos elegibles para maestro correctos. Verifique que todos los nodos utilicen configuraciones idénticas. |
| Pérdida de quórum | Demasiados nodos elegibles para maestro han fallado simultáneamente (por ejemplo, dos fallos en una configuración de maestro de 3 nodos). Puede ser necesaria una intervención manual (por ejemplo, usando la API api/cluster/decommission/voting_config_exclusions) para eliminar forzosamente los nodos fallidos de la lista de votación. |
| E/S de disco | La E/S de disco del nodo maestro está saturada, impidiendo que publique el estado del clúster rápidamente, lo que lleva a tiempos de espera y elecciones repetidas. |
Verificación de la configuración de votación
Puede inspeccionar la configuración de votación actual utilizando la API del clúster:
GET /_cluster/state?filter_path=metadata.cluster_coordination.voting_config_excluding_deferred
Esta salida confirma qué nodos se cuentan actualmente para el quórum, asegurando que su configuración coincida con sus objetivos de tolerancia a fallos.
Resumen
El proceso de elección del nodo maestro es la columna vertebral de la resiliencia de un clúster de Elasticsearch. Al comprender las responsabilidades del maestro e implementar correctamente la regla de quórum (utilizando un número impar de nodos elegibles para maestro y asegurando un cluster.initial_master_nodes correcto durante el arranque), los administradores pueden prevenir de manera confiable los escenarios de split-brain y mantener un sistema distribuido de alta disponibilidad. Siempre use nodos maestros dedicados en producción para aislar las tareas administrativas y asegurar una publicación confiable del estado del clúster.