La caída había durado cuatro horas. El equipo del cliente estaba decidido a que no volviera a ocurrir. La solución que tenían en mente era un clúster Proxmox con alta disponibilidad. Cuando llegaron a la conversación con Aleph Server, ya habían investigado, ya tenían una idea de los costos, y estaban listos para avanzar.
Nuestra respuesta fue frenar y hacer primero las preguntas que todavía no se habían hecho.
El análisis del incidente real
La caída había afectado un servidor que alojaba dos sistemas: un sistema de reportes interno usado principalmente los lunes por el equipo de gerencia, y un servidor de archivos compartido con acceso ocasional durante la semana.
El incidente ocurrió un martes al mediodía. Las cuatro horas de inactividad fueron incómodas. No interrumpieron ningún proceso de producción crítico, no afectaron a clientes externos, y no generaron un costo operacional medible más allá del tiempo del equipo técnico dedicado a la recuperación.
Eso no minimiza el incidente: cuatro horas es un tiempo de recuperación mejorable. Pero cambia completamente la respuesta técnica correcta.
Por qué HA no era la respuesta en ese contexto
Primera razón: el hardware disponible eran dos servidores. Un clúster Proxmox con alta disponibilidad funcional requiere un mínimo de tres nodos para que el sistema de quorum pueda resolver de forma autónoma la caída de un nodo. Con dos nodos, si uno cae, el sistema no puede determinar de forma autónoma si el problema es el nodo caído o la pérdida de conectividad entre los dos. El resultado es que el clúster se suspende para evitar el riesgo de split-brain. Proxmox permite configurar un QDevice externo basado en Corosync qdevice para resolver esto con dos nodos, pero requiere un tercer host árbitro, lo que en la práctica equivale a tener tres dispositivos físicos con una complejidad adicional de gestión.
Segunda razón: el equipo técnico del cliente tenía un administrador con experiencia en virtualización básica y gestión de VMs individuales, sin experiencia en gestión de clústeres, Corosync, o procedimientos de reintegración de nodos. Implementar HA en ese contexto habría creado un entorno cuya operación en situación de incidente real nadie en el equipo dominaba. La alta disponibilidad habría generado una falsa sensación de seguridad, no seguridad real.
Tercera razón: el costo de agregar un tercer servidor para tener HA funcional, más el tiempo de implementación y la curva de aprendizaje del equipo, no estaba justificado para sistemas cuya inactividad no tiene costo operacional crítico. El análisis de retorno no cerraba.
Lo que sí tenía sentido implementar
El objetivo real del cliente era reducir el tiempo de recuperación ante un fallo similar. Eso se podía lograr con tres medidas de complejidad significativamente menor:
Backup diario verificado con Proxmox Backup Server, con prueba de restauración mensual documentada. No un backup que se asume que funciona: uno que se prueba regularmente y cuyo resultado queda registrado. La diferencia entre ambos es la diferencia entre creer que se puede recuperar y saber que se puede recuperar.
Procedimiento de recuperación documentado paso a paso, escrito para que cualquier técnico con acceso al documento pudiera ejecutarlo sin depender del administrador principal. Ese documento es el seguro real contra la dependencia de personas clave en situaciones de incidente.
Sistema de monitoreo con alerta que notificara al equipo dentro de los primeros diez minutos de una caída. El incidente que duró cuatro horas empezó siendo detectado tarde. Con detección temprana, la ventana de recuperación se reduce de forma inmediata.
El resultado
Con esas tres medidas, el tiempo de recuperación estimado ante un fallo similar bajaba a menos de cuarenta y cinco minutos. Sin agregar un tercer servidor, sin implementar Corosync, sin capacitar al equipo en gestión de clústeres.
El cliente implementó el esquema recomendado. Meses después tuvo un incidente menor —un disco con errores que requirió restauración desde backup. El procedimiento documentado funcionó. El tiempo de recuperación fue de treinta y cinco minutos. El equipo lo resolvió de forma autónoma.
La distinción que importa
El cliente quería alta disponibilidad porque quería seguridad. Lo que realmente necesitaba era reducir el tiempo de recuperación a un nivel aceptable para su operación. Esas son dos cosas distintas, y confundirlas tiene consecuencias concretas: implementaciones que agregan complejidad sin el beneficio esperado, y equipos que operan entornos que no comprenden completamente.
Un clúster con HA bien implementado, probado y operado por un equipo capacitado es la respuesta correcta cuando el contexto lo justifica. Cuando no lo justifica, es una forma cara de tener una falsa sensación de seguridad.
La postura de Aleph Server
Parte del trabajo de un partner TI es hacer el análisis que lleva a recomendar la solución correcta para el contexto real, no la solución más sofisticada ni la que genera más ingresos en el corto plazo. Eso implica, a veces, decirle a un cliente que lo que quiere implementar no es lo que necesita todavía.
No siempre es la conversación más cómoda. Siempre es la más honesta.
