El mes pasado, host1 volvió de entre los muertos. Esta semana, ha madurado.
En host1, de vuelta en el clúster conté la historia de un nodo que se congeló, volvió con una CPU distinta y reveló 319 GiB de TRIM obsoleto. Aquello fue la recuperación. Esto es la actualización: todo el clúster doméstico cruzó la línea de una versión mayor, host1 renació con un nombre nuevo y once contenedores de producción no se enteraron de nada.
Cruzando una versión mayor, en caliente
Nuestro hipervisor principal, pve1, corría Proxmox 8.3 sobre Debian Bookworm. El objetivo era Proxmox 9.2 sobre Debian Trixie: un salto mayor de sistema operativo, de los que normalmente implican una ventana de mantenimiento y cruzar los dedos. En su lugar lo hicimos por etapas. Primero una actualización menor a 8.4, luego un reinicio al nuevo kernel, después la comprobación previa oficial pve8to9 (39 aprobados, un puñado de avisos, cero bloqueos), y solo entonces el salto a 9.2.
Dos redes de seguridad respaldaban cada paso: snapshots ZFS del sistema a las que podíamos volver en segundos, y un juego completo de copias de los contenedores en nuestro Proxmox Backup Server. No necesitamos ninguna. Tras el reinicio final pve1 arrancó con el kernel 7.0, los once contenedores se iniciaron solos y el pool ZFS se reportó sano.
host1, renacido como pve2
Con pve1 en 9.2, le tocaba a host1, salvo que host1 volvió como pve2. Lo levantamos limpio sobre el mismo Proxmox 9.2 y lo unimos al clúster. Unir un nodo vacío es el caso fácil: sin invitados que colisionen, sin IDs que reconciliar. En menos de un minuto el clúster eran dos nodos, con quórum, compartiendo un único sistema de ficheros de configuración.
La trampa de los dos nodos
Dos nodos es justo donde el quórum de Proxmox se vuelve peligroso. Con un voto cada uno, el quórum pasa a ser dos, así que si cualquiera de los nodos se reinicia el superviviente pierde el quórum y se congela: no se pueden arrancar ni parar contenedores y la configuración queda en solo lectura. Con la producción viviendo en pve1, ese no era un trato que quisiéramos.
La solución es el modo de dos nodos: un único nodo superviviente mantiene el quórum, y desactivamos wait-for-all para que pve1 pueda arrancar solo tras un corte de luz sin esperar a su compañero. Lo confirmamos en el origen, donde el requisito de quórum bajó a uno, antes de fiarnos.
Las copias siguen al nuevo nodo
Una máquina que ejecuta algo pero no respalda en ningún sitio es un riesgo, así que extendimos el servidor de copias a pve2 el mismo día. En lugar de compartir credenciales, pve2 recibió su propio token de acceso y su propio namespace aislado en cada uno de los dos discos de backup, de modo que sus futuras copias nunca puedan colisionar con las de otro nodo y los dos almacenes queden limpiamente separados.
Una pequeña trampa de Proxmox 9
La comprobación previa se ganó el sueldo: señaló un rol de permisos personalizado que aún referenciaba un privilegio que Proxmox 9 había eliminado. Inofensivo, pero imprimía un aviso en cada listado de contenedores hasta que lo recortamos. Justo el tipo de arañazo que deja una actualización mayor.
Por qué nos tomamos la molestia
Este es nuestro propio laboratorio, pero la disciplina es la misma que aplicamos a las plataformas de clientes: mantenerse en versiones soportadas, tener un segundo nodo para que el mantenimiento nunca signifique caída, y asegurarse de que toda máquina que ejecuta algo tenga también dónde respaldarse. host1 ya no está. Larga vida a pve2.