La pregunta que genera más ansiedad cuando hay que actualizar la infraestructura: ¿cuánto tiempo van a estar caídos los sistemas? En un clúster Proxmox de varios nodos bien diseñado, es posible actualizar Proxmox sin interrupciones: la respuesta correcta es ninguno.
Este artículo explica cómo se hace — tanto para actualizaciones de parches dentro de la misma versión como para el salto entre versiones mayores — y qué debe quedar documentado para que la actualización sea también evidencia — ante la Ley 21.719 — de que los sistemas se mantienen al día.
El principio que hace posible actualizar sin interrupción
Un clúster Proxmox permite migrar máquinas virtuales en vivo de un nodo a otro sin detenerlas. Eso significa que cada nodo puede vaciarse de cargas, actualizarse y reiniciarse de forma aislada mientras el resto del clúster sostiene la operación completa. La regla es simple: nunca actualizar todos los nodos al mismo tiempo.
Para actualizaciones de parches dentro de la misma versión
El proceso por nodo: migrar en vivo todas sus VMs a los demás nodos del clúster — los contenedores LXC con el reinicio correspondiente —, verificar que el nodo queda sin cargas activas, aplicar las actualizaciones, reiniciar si el kernel u otros componentes críticos lo requieren, confirmar que el nodo vuelve a integrarse correctamente al clúster, y recién entonces continuar con el siguiente.
En un clúster de tres nodos, este ciclo completo toma entre una y tres horas. En ningún momento hay servicios caídos: siempre hay al menos dos nodos operativos sosteniendo la carga mientras el tercero se actualiza.
Vale la pena avisar a las áreas de negocio antes de ejecutar la ventana aunque no haya interrupción visible. Las migraciones en vivo pueden generar latencia breve durante el movimiento de cargas intensivas. Una comunicación anticipada evita alarmas innecesarias.
Para el salto entre versiones mayores
El mismo principio de rotación nodo por nodo aplica, pero con preparación adicional antes de tocar el primer nodo.
Revisar las notas de la versión de destino con atención a cambios de compatibilidad: versión mínima requerida de la anterior, cambios en la configuración de red o almacenamiento, advertencias sobre hardware específico.
Ejecutar la herramienta de verificación pre-actualización que Proxmox distribuye para detectar incompatibilidades antes de iniciar, no a mitad de camino.
Probar el proceso completo en un entorno de laboratorio que replique la configuración del clúster de producción — clustering, almacenamiento, configuración de red — antes de ejecutarlo en el entorno real.
Respaldar todo antes de empezar: VMs y configuración del clúster, ejecutado inmediatamente antes de tocar el primer nodo.
Lo que debe quedar documentado
El registro de actualización tiene cuatro columnas: versión anterior, versión aplicada, fecha, responsable de la ejecución. Ese registro es la evidencia de que los sistemas se mantienen al día. Si ocurre un incidente relacionado con una vulnerabilidad que la actualización resolvía, el registro muestra que la actualización se aplicó antes del incidente.
Sin ese registro, demostrar que los sistemas estaban al día requiere reconstruir el historial bajo presión — que es exactamente la situación donde menos conviene estar.
¿Tu empresa tiene planificada la actualización de Proxmox antes del 1 de diciembre, con el proceso documentado?
