El orden de arranque es un retardo, no una dependencia

El anfitrión vuelve tras un apagón y la mitad de lo que debería estar funcionando no funciona. La máquina de base de datos está levantada pero la aplicación que va delante se ha rendido, o un contenedor no pudo montar un almacenamiento que otro contenedor todavía estaba levantando. Nada está roto y nadie registró un error que merezca leerse. Las piezas simplemente subieron en el orden equivocado.

Aquí es donde la forma de su instalación, qué invitado depende de cuál, deja de ser un esquema en su cabeza y se convierte en algo que la máquina ejecuta de verdad. Vale la pena saber con precisión qué hace ese mecanismo, porque es más estrecho de lo que casi todos suponen.

La frase que explica casi todas las sorpresas

El retardo de arranque es un intervalo, no una condición.

Cuando da un retardo a un invitado, Proxmox VE arranca ese invitado, espera los segundos indicados y pasa al siguiente. No comprueba si dentro del invitado terminó el arranque. No comprueba si un servicio responde. Espera y continúa.

Así que el arreglo que tiene en la cabeza, "la aplicación espera a la base de datos", nunca es lo que queda configurado. Lo que queda configurado es "la aplicación arranca noventa segundos después de que se le dijera a la base de datos que arrancara". En un reinicio de prueba tranquilo ambos son indistinguibles. Tras un apagón real, cuando los discos van más lentos, se ejecuta una comprobación del sistema de archivos o un invitado arranca en modo de recuperación, dejan de serlo.

Cuatro reglas que conviene conocer antes de poner números

El menor arranca primero y se apaga el último. El orden de apagado es el inverso del de arranque; no hay un ajuste aparte. Un invitado con orden 1 es el primero en subir y el último en bajar, que suele ser justo lo que se quiere para aquello de lo que depende todo lo demás.

Los números iguales no son aleatorios. Los invitados que comparten orden se ordenan además por identificador ascendente. Los empates son estables y predecibles, y no hace falta dar un número único a cada invitado para obtener un comportamiento repetible.

Los invitados sin orden arrancan siempre después de los que tienen uno. Esto es más útil de lo que parece. No hace falta numerarlo todo. Numere las tres o cuatro cosas que de verdad deben ir pronto y deje el resto en paz.

El orden se aplica a un anfitrión, no al clúster. No puede expresar "este invitado del nodo A debe subir antes que aquel del nodo B". En cuanto su dependencia cruza una frontera de nodo, este mecanismo no tiene nada que decir.

La trampa que aparece más tarde

Los invitados gestionados por la pila de alta disponibilidad ignoran tanto el arranque automático como el orden de arranque. El procedimiento de arranque y apagado los salta por completo, porque es el gestor de alta disponibilidad quien decide cuándo se ejecutan.

Esta muerde tarde. Un anfitrión único con un orden cuidadosamente ajustado funciona durante un año. Luego llega un segundo nodo, algunos invitados pasan bajo alta disponibilidad, y su orden deja de aplicarse en silencio. Nada le avisa, porque nada está mal; simplemente cambió de manos la responsabilidad.

El retardo que de verdad quiere suele ser otro

Un motivo habitual para recurrir a los retardos por invitado es un recurso externo: un almacenamiento en red que debe ser alcanzable antes de que nada lo monte, o un conmutador que necesita un momento. Comprar ese tiempo espaciando invitados uno a uno es una vía torpe, porque estira toda la secuencia.

Existe un ajuste aparte por nodo exactamente para esto: un retardo entre el final del arranque del anfitrión y el primer invitado de arranque automático. Un solo número, aplicado una vez, y en el punto donde la espera realmente corresponde.

El número que nadie ajusta hasta que duele

El tiempo de espera de apagado vale por defecto 180 segundos por invitado. Proxmox VE pide al invitado que se apague, espera, y si al vencer sigue en marcha se detiene de forma forzosa. Una parada en bloque de todos los invitados tiene su propio límite global de tres minutos antes de que ocurra lo mismo.

Para una máquina que escribe en disco al apagarse, ese techo merece revisarse a propósito y no descubrirse durante una avería. El valor por defecto es generoso para casi todos los invitados y demasiado corto para unos pocos, y esos pocos son exactamente aquellos en los que una parada forzosa le cuesta algo.

Lo que se ve en la práctica

En el anfitrión usado para comprobar el comportamiento descrito aquí había nueve invitados configurados y tres puestos a arrancar con el sistema. Ninguno tenía orden de arranque.

Ese es el estado normal de las cosas, y a menudo está bien. Las máquinas que no dependen unas de otras no necesitan orden. El propósito de este texto es más estrecho: si alguna vez ha dicho en voz alta que un invitado necesita que otro esté arriba primero, esa frase hoy vive solo en su memoria, y un apagón no lee su memoria.

Qué hace Atlas

Atlas no reordena nada por usted ni inventa un sistema de dependencias encima del que ya tiene Proxmox VE. Lo que hace es volver visibles las relaciones en una sola imagen en lugar de invitado por invitado, para que la pregunta "qué depende realmente de qué aquí" pueda hacerse mientras la máquina está tranquila y no mientras vuelve en sí.

Ver la forma no la configura. Pero nadie establece un orden sensato para una disposición que nunca ha visto dibujada.