La HA de Proxmox no evita la caída: la acorta (y a veces la provoca)

La documentación de Proxmox VE dice de su propio ha-manager algo que casi ningún folleto de virtualización se atrevería a escribir: que tiene «tiempos típicos de detección de error y failover de unos 2 minutos, así que no puedes conseguir más de un 99,999 % de disponibilidad». Está en el manual oficial, en la página que la gente se salta para llegar al botón de activar. Ese párrafo es la definición honesta de lo que compras cuando activas HA: no compras que no se caiga; compras que se levante sola.

La distancia entre esas dos frases es la que separa un proyecto que sale bien de una reunión incómoda seis meses después. Llevamos años operando clústeres de Proxmox VE en producción, y la conversación que más repetimos empieza justo después de los tres clics que la activan: qué deja de pasar y qué empieza a pasar entonces. Porque empiezan a pasar cosas.

Lo que ocurre de verdad cuando muere un nodo

Un nodo con veinte máquinas virtuales se apaga en seco: fuente muerta, kernel colgado, alguien que tropieza con un cable. El resto del clúster deja de verlo y comprueba que sigue teniendo mayoría de votos. Después toca esperar, y aquí está el detalle que ordena todo lo demás: en Proxmox al nodo perdido no lo aísla nadie desde fuera, se aísla él solo — su propio watchdog lo reinicia en cuanto deja de poder atenderlo. Pasado ese plazo, el clúster puede dar por seguro que ya nadie escribe desde el otro lado, y ahí arranca los servicios en los nodos que siguen vivos. La documentación llama a esa cadena detección de error y failover, y le pone el número que hemos citado arriba: unos dos minutos.

Conviene decir con todas las letras qué significa «mover». No es una migración en caliente. La migración en caliente copia la memoria de una máquina encendida a otro nodo y el sistema operativo huésped ni se entera; requiere que el nodo de origen esté vivo para poder copiar esa memoria. Aquí el nodo de origen no existe. Las máquinas se arrancan de cero en otro sitio, exactamente igual que si les hubieras quitado el enchufe. Y esa diferencia, que en un diagrama son dos flechas parecidas, en el reloj del lunes por la mañana es otra cosa.

Los cinco nueves salen de una resta

El «99,999 %» de la documentación suena a marketing hasta que lo pasas a minutos. Un año tiene 525.600 minutos, y de ahí sale todo lo demás:

Y hay un matiz que se cae de todas las presentaciones: ese techo es el del hipervisor, no el de tu servicio. Mide desde que el clúster detecta el problema hasta que la máquina virtual arranca. Lo que pasa dentro de la máquina virtual a partir de ese segundo no lo cuenta nadie.

Dentro de la máquina virtual ha habido un corte de luz

Nadie le ha dicho al sistema huésped que se apagara ordenadamente. Así que arranca como arranca cualquier máquina tras un apagón: el sistema de ficheros revisa su registro de transacciones, la base de datos rehace el journal y decide qué transacciones confirma y cuáles tira, los servicios se levantan en el orden que les toque —que rara vez es el orden que necesita la aplicación— y las colas que estaban a medias se quedan a medias. En un servidor de ficheros esto son segundos. En un ERP con su base de datos, su servidor de aplicaciones y tres integraciones que reintentan, esto no son segundos.

De ahí sale la única medición que de verdad importa y que casi nunca está hecha: cuánto tarda tu aplicación en estar operativa desde un arranque en frío. No cuánto tarda en encenderse la VM: cuánto tarda en que un usuario pueda facturar. Ese número, sumado a los dos minutos del hipervisor, es tu tiempo de recuperación real ante la caída de un nodo. Es la misma conversación que tuvimos al hablar de >los dos números que se firman sin haberlos calculado, aplicada a un escenario mucho más pequeño y mucho más frecuente que un desastre.

Y a veces la caída la provoca la propia HA

Esta es la parte que sorprende a quien acaba de activarla, y está descrita con una claridad admirable en el manual. Cuando un nodo pierde el quórum del clúster, «el LRM espera a que se forme un nuevo quórum. Hasta que hay quórum, el nodo no puede resetear el watchdog. Si hay servicios activos en el nodo, o si el proceso LRM o CRM no se planifica o muere, esto disparará un reinicio cuando el watchdog haya expirado (esto ocurre a los 60 segundos)».

Léelo otra vez pensando en tu red. Un nodo sano, con sus máquinas virtuales funcionando y su almacenamiento perfectamente accesible, se reinicia solo a los sesenta segundos por haber dejado de hablar con sus compañeros, con todo el hardware intacto. Y quien decide si esa conversación se mantiene es un switch, un cable o una tarjeta de red.

Por eso la documentación del clúster es tan insistente con algo que en el presupuesto parece un capricho: «la pila de clúster de Proxmox VE requiere una red fiable con latencias por debajo de 5 milisegundos (rendimiento de LAN) entre todos los nodos para funcionar de forma estable», y recomienda «una tarjeta de red física dedicada para el tráfico de clúster» porque la red de clúster, aunque mueve muy pocos datos, «es muy sensible a la latencia». Pide además, expresamente, que esa red no se use «para ningún propósito de alto tráfico, como almacenamiento en red o migración en vivo». Esa última frase es la que más veces hemos visto ignorada, y está detrás de más de un reinicio que al principio no tenía explicación: una migración en vivo de una máquina grande saturando el mismo enlace por el que corosync tiene que llegar a tiempo.

Ese reinicio brutal es la función, no el fallo

Cuesta aceptarlo la primera vez que te pasa, pero el reinicio automático es lo que hace que todo lo demás sea seguro. Se llama fencing, y su propósito es que el clúster pueda afirmar, sin ninguna duda, que el nodo desaparecido ya no escribe en el almacenamiento compartido. Sin esa certeza no se puede recuperar nada: la documentación advierte de que si se escribe desde dos nodos a la vez «se pueden destruir todos los datos de la VM».

Así que el trato es explícito y conviene firmarlo con los ojos abiertos: aceptas perder un nodo sano durante un minuto a cambio de no partir nunca un disco en dos. Nos parece un trato excelente. Pero es un trato, no un regalo, y quien no lo entienda va a vivir el primer reinicio por watchdog como una traición del producto cuando es el sistema haciendo exactamente lo que promete.

Los requisitos que se salta todo el mundo

El manual los lista sin ceremonia, en cuatro líneas, y son los cuatro sitios donde, en nuestra experiencia, se rompen los clústeres que llegan pidiendo ayuda:

Cuándo NO montamos HA

Vender alta disponibilidad es cómodo: nadie discute una propuesta que promete que no te vas a caer. Nos parece más útil decir cuándo la desaconsejamos, aunque implique un proyecto más pequeño.

Si la aplicación ya sabe agruparse sola, poner HA por debajo suele estorbar más que ayudar: dos nodos de base de datos replicados entre sí no quieren que el hipervisor reinicie uno por su cuenta a mitad de una conmutación. Pasa algo parecido con las máquinas que tienen hardware pasado directamente —una llave, una tarjeta, un autómata de planta—: no pueden arrancar en otro nodo, así que de poco sirve prometerles un sitio donde volver. Y cuando hay dos servidores y una cabina compartida, el ejercicio honesto es preguntar qué pasa si lo que se cae es la cabina: si la respuesta es «todo», la HA está protegiendo el punto que menos falla.

Y está el caso más frecuente de todos, el que casi nunca se dice en voz alta: cuando cinco minutos de corte al mes no le cuestan nada al negocio. Ahí la alta disponibilidad añade complejidad, y la complejidad es el otro nombre de las averías raras. Hay empresas a las que les hemos recomendado gastarse ese dinero en copias probadas y en un plan de restauración cronometrado, y dormir mejor. Ninguna de ellas nos ha dicho después que se arrepintiera.

Lo que sí hacemos antes de dar un clúster por bueno

La pregunta con la que empezamos

Cuando alguien nos pide alta disponibilidad, la primera pregunta no es cuántos nodos tiene ni qué almacenamiento usa. Es esta: ¿cuánto tarda tu aplicación principal en volver a funcionar después de un apagón? Si nadie lo ha medido nunca, ese es el trabajo de esta semana, y probablemente cambie el proyecto entero. Si el número es alto, la HA lo va a mejorar poco y hay que arreglar otra cosa primero. Y si el número es bajo y el negocio aguanta un par de minutos, entonces sí: dos minutos de failover automático a las cuatro de la mañana son una noche entera de sueño, que es más o menos lo que compra la alta disponibilidad cuando está bien puesta.

Fuentes: tiempos de detección y failover de unos 2 minutos, techo del 99,999 %, requisitos (tres nodos, almacenamiento compartido, redundancia de hardware, componentes de servidor), comportamiento del watchdog a los 60 segundos sin quórum, propósito del fencing y modo de mantenimiento — capítulo ha-manager de la documentación de Proxmox VE y wiki de alta disponibilidad; latencia por debajo de 5 ms, tarjeta dedicada, aviso sobre almacenamiento en red y migración en vivo, enlaces redundantes y QDevice como tercer voto — capítulo de gestión de clúster. El propio capítulo publica su tabla de disponibilidad (99,9 % → 8,76 horas; 99,99 % → 52,56 minutos; 99,999 % → 5,26 minutos al año); las conversiones a minutos y segundos son aritmética directa sobre 525.600 minutos al año. Imagen de portada: fotografía de un pulsador de parada de emergencia, CC0, vía el directorio de fotos de WordPress.