El día en que un clúster de tres nodos se negó a confiar en sí mismo
Cuando la "alta disponibilidad" de repente parece frágil
Tener un clúster de virtualización de tres nodos suele dar una reconfortante sensación de redundancia. Reinicias un nodo y los otros dos lo mantienen todo en marcha, mientras el modo de mantenimiento migra las máquinas virtuales sin problemas. Las cargas de trabajo se deslizan entre hosts como en una coreografía bien ensayada mientras los administradores toman café y miran los paneles.
Entonces alguien prueba algo que parece perfectamente razonable: reiniciar dos nodos a la vez después de migrar todas las VMs al tercer host. De repente, el clúster se comporta como si estuviera sufriendo una crisis existencial.
El último nodo entra en pánico. Los servicios se reinician y a veces el host incluso se reinicia entero. En lugar de ejecutar con calma todas las cargas de trabajo del clúster, la última máquina se niega a fiarse de la situación. Para el administrador que lo mira desde la consola parece absurdo, porque el hardware es lo bastante potente para ejecutarlo todo, las VMs ya están migradas y técnicamente nada está sobrecargado.
Entonces, ¿por qué se rebela el clúster en cuanto desaparecen dos nodos?
La regla invisible: siempre gana la mayoría
Una explicación viene de gente que lleva años viviendo dentro de sistemas distribuidos. Señalan una regla que está debajo de la mayoría de los clústeres de alta disponibilidad: la regla de la mayoría.
En un montaje de tres nodos, el clúster espera que al menos dos nodos estén de acuerdo sobre la realidad. Ese acuerdo se llama quórum, y en cuanto se pierde el quórum, el sistema deja de fiarse de su propio estado.
Un ingeniero lo explicó sin rodeos: cuando desaparecen dos nodos, el nodo que queda da por hecho que el problema podría ser él mismo. Desde su punto de vista, puede que las otras máquinas no hayan desaparecido en absoluto y que simplemente él esté aislado.
Suena paranoico, pero esa paranoia tiene su razón de ser. Los sistemas distribuidos tratan el aislamiento como algo peligroso porque puede llevar a algo peor que el tiempo de inactividad: el split brain.
El escenario de pesadilla que temen los ingenieros
Imagina que el clúster se comporta como los administradores esperan al principio. Dos nodos se desconectan y el último sigue ejecutando todas las VMs sin quejarse.
Ahora imagina otra situación. En lugar de un reinicio planificado, falla el enlace de red entre los nodos y el clúster se divide en dos grupos que no se ven entre sí. Si los dos lados creen que son el clúster legítimo, pueden empezar a ejecutar las mismas máquinas virtuales a la vez.
Así es como acabas con bases de datos duplicadas escribiendo en el mismo almacenamiento, dos copias de una VM procesando transacciones y sistemas de archivos corrompidos sin arreglo posible. Un administrador describió el resultado de forma pintoresca: de repente tienes dos de cada VM en marcha, y el día se va cuesta abajo muy rápido.
Para evitar esa pesadilla, el software de clúster sigue una regla estricta. Si un nodo no puede confirmar que forma parte de la mayoría, se niega a ejecutar cargas de trabajo, aunque eso suponga apagar servicios que estaban perfectamente sanos unos segundos antes. Desde el punto de vista del sistema, pararlo todo es la opción más segura.
Por qué el modo de mantenimiento no lo resuelve
Muchos administradores dan por hecho que el modo de mantenimiento debería cambiar la ecuación. Al fin y al cabo, poner nodos en modo de mantenimiento migra las cargas de trabajo y le indica al clúster que esas máquinas se apartan a propósito. Si el clúster sabe que dos nodos están desconectados de forma deliberada, dice el razonamiento, el host que queda debería seguir ejecutando las VMs.
El clúster no lo ve así. El modo de mantenimiento se ocupa de la migración de las cargas de trabajo y de las decisiones de programación, y no cambia las reglas de quórum que rigen la seguridad del clúster. En cuanto dos nodos dejan de comunicarse, el nodo restante pierde igualmente el acuerdo de la mayoría.
Desde el punto de vista del software, no hay ninguna prueba fiable de que los otros hosts estén realmente apagados y no simplemente inalcanzables. Los sistemas distribuidos funcionan con una suposición muy dura: las redes mienten todo el tiempo.
La comparación con VMware que siempre aparece
Cada vez que este comportamiento sorprende a alguien, aparecen casi al instante las comparaciones con otras plataformas de virtualización.
En algunos entornos, los administradores están acostumbrados a mecanismos como el heartbeat de datastores o los bloqueos de almacenamiento. Esos sistemas permiten a los hosts comprobar si otra máquina sigue siendo dueña de una VM o ha perdido el acceso al almacenamiento compartido.
Ese enfoque crea otro estilo de detección de fallos. En lugar de depender sobre todo del quórum del clúster, el sistema mira las señales del almacenamiento compartido para determinar si una VM sigue viva en otro sitio.
Algunos ingenieros prefieren este modelo, y otros lo ven como cambiar un conjunto de riesgos por otro. Como señaló un comentarista, cada plataforma toma decisiones de diseño distintas sobre de dónde sale la confianza, ya sea el consenso de red, los bloqueos de almacenamiento o alguna combinación híbrida, y ninguna es perfecta.
La sencillez sin rodeos de la filosofía de Proxmox
La filosofía de diseño detrás de muchos clústeres de código abierto es de una sencillez casi testaruda. Si un nodo no puede confirmar que forma parte de la mayoría, da por hecho que puede estar pasando algo peligroso y lo apaga todo, sin conjeturas ingeniosas ni suposiciones optimistas.
Este enfoque antepone la consistencia y la seguridad de los datos a la comodidad, así que los administradores tienen que seguir unos patrones operativos estrictos. Reinicia los nodos de uno en uno, mantén el quórum y evita las situaciones en las que el clúster pierde su mayoría de votos.
A algunas personas les resulta frustrante, porque el sistema parece ignorar intenciones obvias durante las ventanas de mantenimiento. Desde la perspectiva de los sistemas distribuidos, sin embargo, el clúster se comporta exactamente como se diseñó y protege los datos de escenarios que los humanos a menudo subestiman.
El coste oculto de los clústeres pequeños
Esta situación también muestra un límite de los clústeres pequeños que es fácil olvidar. Un clúster de tres nodos solo puede tolerar un fallo a la vez, y en cuanto desaparecen dos nodos, el quórum se esfuma.
Esa limitación lleva al consejo que inevitablemente aparece en conversaciones como esta: si quieres que el clúster sobreviva a la pérdida de dos nodos, necesitas más nodos. Suena casi a desplante, pero matemáticamente es correcto. Los clústeres más grandes aumentan el número de fallos que pueden ocurrir sin romper el consenso de la mayoría. Un clúster de cinco nodos puede perder dos y mantener el quórum, y uno de siete nodos puede perder tres. Con tres nodos, sencillamente no hay margen.
El momento en que el diseño por fin tiene sentido
Para los administradores que se encuentran con este comportamiento por primera vez, el sistema parece demasiado prudente. Saben exactamente lo que están haciendo, pusieron los nodos en modo de mantenimiento a propósito y el escenario está controlado.
Pero los sistemas distribuidos no se basan en la certeza humana. Se basan en reglas que sobreviven a condiciones caóticas como switches rotos, particiones de red, hosts caídos y memoria corrupta. Esas reglas suelen parecer testarudas durante el mantenimiento rutinario, y existen porque alguien, en algún lugar, perdió una vez un clúster entero por un split brain.
Así que la próxima vez que un clúster de tres nodos se niegue a seguir funcionando después de que desaparezcan dos nodos, lo que parece pánico es el clúster negándose a hacer conjeturas sobre un estado que no puede confirmar.