Solución de Problemas Comunes de Escenarios de Cerebro Dividido en Clústeres de Elasticsearch

El cerebro dividido es la falla de Elasticsearch de la que la gente habla porque suena dramática, pero la pregunta útil es más práctica: ¿puede más de una parte del clúster tomar decisiones a nivel de maestro al mismo tiempo? Las versiones modernas de Elasticsearch están diseñadas para prevenir esto mediante la coordinación del clúster basada en mayoría. Los clústeres más antiguos, especialmente los anteriores a la versión 7.0 con una mala configuración de discovery.zen.minimum_master_nodes, eran más fáciles de configurar incorrectamente.

Por lo tanto, este artículo separa dos situaciones que a menudo se mezclan. Un verdadero cerebro dividido significa que particiones independientes pueden elegir o mantener un maestro cada una. Una interrupción en la elección del maestro significa que el clúster no puede elegir un maestro porque no tiene mayoría. El primero corre el riesgo de un estado de clúster conflictivo e inconsistencia de datos. El segundo es doloroso, pero suele ser el modo de falla más seguro.

Cómo se ve el cerebro dividido

En un clúster saludable, un maestro elegido gestiona el estado del clúster: creación de índices, decisiones de asignación de fragmentos, mapeos, membresía de nodos y metadatos similares. Los nodos de datos pueden manejar lecturas y escrituras, pero el clúster aún depende de una única vista del mundo del maestro.

Un escenario de cerebro dividido ocurre cuando particiones de red o configuraciones de descubrimiento incorrectas permiten que dos grupos de nodos se comporten como si cada grupo fuera el clúster real. Un lado podría aceptar escrituras en un índice mientras que el otro lado acepta escrituras diferentes. Cuando la conectividad regresa, Elasticsearch no puede simplemente fusionar dos historias conflictivas como un archivo de texto.

En Elasticsearch moderno, si una partición no tiene una mayoría de nodos elegibles para maestro, no debería elegir un maestro. Eso significa que algunos nodos pueden volverse no disponibles en lugar de formar un clúster competidor. Ese es el comportamiento que deseas.

La versión importa

Para Elasticsearch 6.x y versiones anteriores, la configuración clave era:

discovery.zen.minimum_master_nodes: 2

La regla era mayoría de nodos elegibles para maestro: (N / 2) + 1, redondeado hacia abajo para la división de enteros antes de sumar uno. Con tres nodos elegibles para maestro, configúralo en 2. Con cinco, configúralo en 3. Configurarlo en 1 en un clúster de tres nodos hacía posible el cerebro dividido.

Para Elasticsearch 7.x y posteriores, discovery.zen.minimum_master_nodes ha desaparecido. La coordinación del clúster cambió y Elasticsearch gestiona la configuración de votación. Los clústeres nuevos aún necesitan un arranque correcto con cluster.initial_master_nodes, pero esa configuración es solo para la formación inicial del clúster. Después de que el clúster se forma, elimínala de la configuración.

No "arregles" un clúster moderno agregando configuraciones antiguas de discovery.zen. Ya no son el plano de control.

Causas comunes

El desencadenante más común es una partición de red entre nodos elegibles para maestro. En términos de nube, eso podría ser un cambio en un grupo de seguridad, una tabla de enrutamiento incorrecta, una ACL de red, un problema a nivel de zona o una regla de firewall que bloquea el puerto de transporte 9300. En entornos de hardware físico, podría ser un problema de switch, VLAN, DNS, MTU o pérdida de paquetes.

Otra causa es ejecutar muy pocos nodos elegibles para maestro. Dos nodos elegibles para maestro son incómodos porque no hay una mayoría clara después de que uno falla. Un clúster de producción normalmente usa tres nodos dedicados elegibles para maestro, o tres nodos de roles mixtos en una implementación pequeña.

Una tercera causa son directorios de datos obsoletos o reutilizados. Si clonas máquinas virtuales o reutilizas discos de clústeres antiguos, los nodos pueden llevar metadatos del clúster que no pretendías. Eso puede llevar a fallos de unión confusos y, en los peores casos, a la formación accidental de un clúster separado.

Finalmente, la recuperación manual bajo presión puede empeorar el problema. Reiniciar nodos al azar, borrar rutas de datos o forzar una asignación insegura antes de saber qué partición es autoritativa puede convertir un incidente recuperable en una pérdida de datos.

Primeras comprobaciones durante un incidente

Comienza preguntando a cada nodo alcanzable qué piensa:

curl -s "http://NODO:9200/_cat/master?v"
curl -s "http://NODO:9200/_cat/nodes?v&h=ip,name,roles,master,node.role"
curl -s "http://NODO:9200/_cluster/health?pretty"

Ejecuta esos comandos contra más de un nodo si es posible. Si diferentes nodos reportan diferentes maestros o diferentes membresías de nodos, es posible que estés viendo un clúster particionado o nodos aislados.

Revisa los registros en los nodos elegibles para maestro en busca de mensajes sobre elecciones, uniones, desconexiones y fallos de publicación. Los términos de búsqueda útiles incluyen master not discovered, elected-as-master, node-left, node-join, publication, connect_transport_exception y handshake.

Luego prueba la conectividad de transporte, no solo HTTP:

nc -vz nodo-1.ejemplo.interno 9300
nc -vz nodo-2.ejemplo.interno 9300
nc -vz nodo-3.ejemplo.interno 9300

Ejecuta esas pruebas de nodo a nodo. Un balanceador de carga o bastión que llegue al puerto HTTP 9200 te dice muy poco sobre si los nodos de Elasticsearch pueden formar un clúster a través del puerto 9300.

Verifica la configuración de descubrimiento y arranque

En Elasticsearch 7.x y posteriores, inspecciona estas configuraciones:

cluster.name: mi-cluster
discovery.seed_hosts:
  - nodo-1:9300
  - nodo-2:9300
  - nodo-3:9300

Solo para un clúster nuevo:

cluster.initial_master_nodes:
  - nodo-1
  - nodo-2
  - nodo-3

Los nombres de arranque deben coincidir con node.name. Después de que el clúster se forma, elimina cluster.initial_master_nodes de todos los nodos.

En Elasticsearch 6.x y versiones anteriores, verifica:

discovery.zen.minimum_master_nodes: 2

para un clúster de tres nodos elegibles para maestro. También confirma que todos los nodos elegibles para maestro tengan hosts de descubrimiento y nombres de clúster consistentes.

Principios de recuperación

Si sospechas un verdadero cerebro dividido, deja de hacer cambios a través de la API del clúster hasta que sepas qué lado es autoritativo. La recuperación más segura generalmente sigue este orden:

1. Preserva la evidencia: recopila registros, listas de nodos, vistas de maestro y salud del índice de cada partición.
2. Restaura la conectividad de red o aísla intencionalmente el lado malo.
3. Elige la partición autoritativa basada en la mayoría, los datos válidos más recientes y el impacto en el negocio.
4. Detén Elasticsearch en los nodos que no deberían continuar como una partición independiente.
5. Vuelve a traer los nodos uno a la vez y verifica que se unan al clúster autoritativo.
6. Restaura los datos faltantes de instantáneas si alguna historia de fragmento primario se pierde o es inconsistente.

No elimines los directorios de translog como una solución rutinaria para el cerebro dividido. Ese es un consejo peligroso. Los translogs son parte de la recuperación de Elasticsearch. Eliminar archivos manualmente bajo la ruta de datos puede causar pérdida de datos y solo debe hacerse con orientación específica de la versión del soporte de Elastic o después de haber aceptado la pérdida y tener un plan de reconstrucción.

Si dos particiones aceptaron escrituras de forma independiente, puede que no haya una fusión automática perfecta. Es posible que necesites restaurar desde una instantánea, reindexar desde sistemas de origen, reproducir registros de aplicación o elegir los datos de un lado como autoritativos.

Un ejemplo realista

Imagina un clúster de tres nodos en tres subredes privadas. Un cambio de firewall bloquea accidentalmente el tráfico de transporte entre el nodo 1 y los nodos 2 y 3. Los nodos 2 y 3 aún se ven entre sí, por lo que mantienen o eligen un maestro. El nodo 1 no puede ver una mayoría. En un clúster moderno y correctamente configurado, el nodo 1 no debería formar un maestro competidor por sí solo. Los clientes que usan el nodo 1 pueden fallar, pero el clúster evita maestros conflictivos.

Ahora imagina un clúster antiguo 6.x con tres nodos elegibles para maestro y discovery.zen.minimum_master_nodes: 1. El nodo 1 puede elegirse a sí mismo, mientras que los nodos 2 y 3 eligen otro maestro. Ese es el riesgo clásico de cerebro dividido. La solución no es solo reconectar la red. También necesitas corregir la configuración del quórum y decidir cómo manejar cualquier escritura aceptada en el lado incorrecto.

Prevención

Usa tres nodos elegibles para maestro para clústeres pequeños y medianos. Para clústeres más grandes, conviértelos en nodos maestro dedicados para que la carga de búsqueda e indexación no interfiera con la coordinación del clúster.

Mantén los nodos elegibles para maestro en redes confiables con baja pérdida de paquetes. Distribuir nodos entre zonas puede ayudar a la disponibilidad, pero solo si la red entre zonas es confiable y el diseño del quórum sigue teniendo sentido.

Monitorea los cambios de maestro. Una elección de maestro durante un mantenimiento planificado es normal. Elecciones frecuentes durante el tráfico normal son una señal de advertencia.

Monitorea la conectividad de transporte y no solo el tiempo de actividad de HTTP. Un nodo puede responder en el puerto 9200 y aún así no participar correctamente en el clúster si el tráfico de transporte está bloqueado.

Realiza instantáneas regularmente y prueba las restauraciones. Las réplicas no te protegen de una eliminación incorrecta, datos corruptos o escrituras conflictivas durante un incidente grave.

Ten cuidado con las configuraciones de arranque. En clústeres modernos, cluster.initial_master_nodes no es una configuración de descubrimiento cotidiana. Úsalo para crear un nuevo clúster, luego elimínalo.

La mejor recuperación de cerebro dividido es la que nunca necesitas: elegibilidad de maestro basada en mayoría, configuraciones de descubrimiento correctas según la versión, reglas de red aburridas y un plan de instantáneas probado.

Cómo distinguir el cerebro dividido de una elección normal

Una elección de maestro no es automáticamente un cerebro dividido. Durante un reinicio progresivo, un problema de red o una falla del nodo maestro, Elasticsearch puede elegir un nuevo maestro. Si el clúster mantiene un maestro autoritativo y el antiguo maestro se retira, ese es un comportamiento normal de sistemas distribuidos.

Las señales de advertencia son vistas diferentes desde diferentes nodos. Si el nodo A se reporta a sí mismo como maestro mientras que el nodo B reporta al nodo C como maestro, detente e investiga. Si dos grupos de nodos aceptan cambios en el estado del clúster mientras están desconectados, tienes una situación mucho más grave que una breve elección.

También observa el comportamiento del cliente. Los clientes vinculados a un nodo aislado pueden ver fallos incluso mientras el lado mayoritario está saludable. Eso no significa que el clúster mayoritario esté roto. Puede significar que tu estrategia de conexión de cliente o balanceador de carga aún está enviando tráfico a un nodo que no puede participar.

Balanceadores de carga y enrutamiento de clientes

El descubrimiento de transporte de Elasticsearch no es lo mismo que el enrutamiento HTTP del cliente. No pongas el descubrimiento de maestro detrás de un balanceador de carga HTTP genérico y esperes que resuelva la membresía del clúster. Los nodos necesitan conectividad de transporte entre sí.

Para los clientes, usa múltiples puntos finales HTTP o un balanceador de carga que elimine rápidamente los nodos no saludables. Un nodo que ha perdido su maestro puede aún tener un proceso escuchando por un corto tiempo, pero no es un buen objetivo para escrituras. Las comprobaciones de salud deberían ser más significativas que "el puerto 9200 está abierto".

Una comprobación de salud HTTP práctica podría consultar la salud del clúster localmente y rechazar nodos que no tengan un maestro descubierto. El enfoque exacto depende de tu cliente e infraestructura, pero el principio es simple: no sigas enviando escrituras a nodos aislados.

Limpieza posterior al incidente

Después de que el clúster esté estable, compara la salud del índice, los recuentos de documentos y los recuentos de fuente de verdad a nivel de aplicación. Si hubo alguna posibilidad de que las escrituras llegaran a diferentes particiones, la salud de Elasticsearch por sí sola no puede probar que los datos sean semánticamente correctos.

Revisa la línea de tiempo. ¿Qué nodo perdió la conectividad primero? ¿Qué nodo era el maestro antes del evento? ¿Los clientes continuaron escribiendo? ¿Las instantáneas estaban actualizadas? ¿Se activaron alertas antes de que los usuarios notaran? Estos detalles determinan si solo necesitas una solución de red o un plan de reconciliación de datos.

Para clústeres antiguos, programa el trabajo de versión y configuración de descubrimiento. Si aún estás ejecutando una versión que depende de discovery.zen.minimum_master_nodes, asegúrate de que sea correcta hoy, luego planifica una ruta de actualización. La prevención del cerebro dividido no es un paso único de runbook; es parte de la gestión del ciclo de vida del clúster.

Cambios de configuración que debes evitar durante el pánico

No cambies cluster.name para que los nodos se unan. Eso crea un problema diferente de identidad del clúster.

No borres rutas de datos a menos que estés descartando intencionalmente las copias de fragmentos locales del nodo y hayas confirmado que el clúster tiene copias válidas en otro lugar o instantáneas disponibles.

No agregues cluster.initial_master_nodes de nuevo a un clúster moderno existente como una solución general para reinicios. Esa configuración es para el arranque inicial, no para el descubrimiento rutinario.

No reduzcas las protecciones de tipo quórum en clústeres antiguos para restaurar la disponibilidad. Hacer que una partición minoritaria sea escribible puede parecer un progreso, pero es exactamente cómo los maestros conflictivos se vuelven posibles.

Diseñando para dominios de falla incómodos

Tres nodos elegibles para maestro funcionan mejor cuando ningún evento de infraestructura único puede eliminar dos de ellos. En una región de nube de tres zonas, un nodo elegible para maestro por zona es un patrón común. En un entorno de dos zonas, la ubicación es más difícil porque una zona puede contener dos votos. Si esa zona más grande falla, el voto único restante no puede elegir un maestro de manera segura. Eso no es que Elasticsearch sea frágil; es matemática de mayoría.

No resuelvas esto agregando un número par de nodos de votación sin pensar en los modos de falla. Cuatro nodos elegibles para maestro aún requieren una mayoría, y una partición dos-dos no puede elegir un lado de manera segura. Los nodos dedicados solo de votación pueden ayudar en algunos diseños, pero el principio sigue siendo el mismo: el clúster necesita una mayoría confiable para tomar decisiones sobre el estado del clúster.

Escribe esto en las notas de arquitectura. Durante una interrupción, la gente a menudo pregunta por qué el nodo o zona sobreviviente no puede simplemente seguir sirviendo escrituras. La respuesta debe estar clara antes del incidente: aceptar escrituras sin una mayoría corre el riesgo de una historia conflictiva.