L'ordre de démarrage est un délai, pas une dépendance

L'hôte revient après une coupure de courant et la moitié de ce qui devrait tourner ne tourne pas. La machine de base de données est en route mais l'application devant elle a renoncé, ou un conteneur n'a pas pu monter un stockage qu'un autre conteneur était encore en train de démarrer. Rien n'est cassé et rien n'a consigné d'erreur digne d'être lue. Les morceaux sont simplement remontés dans le mauvais ordre.

C'est ici, et seulement ici, que la forme de votre installation, qui dépend de qui, cesse d'être un schéma dans votre tête et devient quelque chose que la machine exécute vraiment. Il vaut la peine de savoir exactement ce que fait ce mécanisme, car il est plus étroit qu'on ne le suppose.

La phrase qui explique la plupart des surprises

Le délai de démarrage est un intervalle, pas une condition.

Quand vous donnez un délai à un invité, Proxmox VE démarre cet invité, patiente le nombre de secondes indiqué, puis passe au suivant. Il ne vérifie pas si le démarrage s'est achevé à l'intérieur de l'invité. Il ne vérifie pas si un service répond. Il attend, puis continue.

L'arrangement que vous avez en tête, « l'application attend la base de données », n'est donc jamais ce qui est configuré. Ce qui est configuré, c'est « l'application démarre quatre-vingt-dix secondes après qu'on a demandé à la base de données de démarrer ». Lors d'un redémarrage de test tranquille, les deux sont indiscernables. Après une vraie coupure, quand les disques sont plus lents, qu'une vérification du système de fichiers s'exécute ou qu'un invité démarre en mode secours, ils ne le sont plus.

Quatre règles à connaître avant de poser des chiffres

Le plus petit démarre en premier et s'arrête en dernier. L'ordre d'arrêt est l'inverse de l'ordre de démarrage ; il n'y a pas de réglage séparé. Un invité d'ordre 1 est le premier levé et le dernier couché, ce qui correspond en général à ce que l'on veut pour la brique dont tout le reste dépend.

Les nombres égaux ne sont pas aléatoires. Les invités partageant le même ordre sont en plus triés par identifiant croissant. Les égalités sont donc stables et prévisibles, et vous n'avez pas besoin de donner un numéro unique à chaque invité pour obtenir un comportement reproductible.

Les invités sans ordre démarrent toujours après ceux qui en ont un. C'est plus utile qu'il n'y paraît. Vous n'avez pas à tout numéroter. Numérotez les trois ou quatre choses qui doivent réellement être tôt, et laissez le reste tranquille.

L'ordre s'applique à un hôte, pas à la grappe. Il ne peut pas exprimer « cet invité du nœud A doit monter avant celui du nœud B ». Dès que votre dépendance franchit une frontière de nœud, ce mécanisme n'a plus rien à en dire.

Le piège qui apparaît plus tard

Les invités gérés par la pile de haute disponibilité ignorent à la fois le réglage de démarrage automatique et l'ordre de démarrage. La procédure de démarrage et d'arrêt les saute entièrement, car c'est le gestionnaire de haute disponibilité qui décide quand ils tournent.

Celui-là mord tard. Un hôte unique avec un ordre soigneusement réglé fonctionne pendant un an. Puis un second nœud arrive, quelques invités passent sous haute disponibilité, et leur ordre cesse discrètement de s'appliquer. Rien ne vous prévient, car rien n'est faux ; la responsabilité a simplement changé de main.

Le délai que vous voulez vraiment est souvent un autre

Une raison fréquente de recourir aux délais par invité est une ressource externe : un stockage réseau qui doit être joignable avant que quoi que ce soit ne le monte, ou un commutateur qui a besoin d'un instant. Acheter ce temps en espaçant les invités un à un est une méthode maladroite, car cela étire toute la séquence.

Il existe un réglage distinct par nœud exactement pour cela : un délai entre la fin du démarrage de l'hôte et le premier invité à démarrage automatique. Un seul nombre, appliqué une fois, à l'endroit où l'attente a réellement sa place.

Le nombre que personne ne règle avant que ça fasse mal

Le délai d'arrêt vaut par défaut 180 secondes par invité. Proxmox VE demande à l'invité de s'arrêter, attend, et si l'invité tourne encore à l'expiration, il est arrêté de force. Un arrêt groupé de tous les invités a sa propre limite globale de trois minutes avant que la même chose ne se produise.

Pour une machine qui écrit sur disque au moment de l'arrêt, ce plafond mérite d'être vérifié exprès plutôt que découvert pendant une panne. La valeur par défaut est généreuse pour la plupart des invités et trop courte pour quelques-uns, et ces quelques-uns sont précisément ceux où un arrêt forcé vous coûte quelque chose.

Ce que l'on constate en pratique

Sur l'hôte ayant servi à vérifier le comportement décrit ici, neuf invités étaient configurés et trois réglés pour démarrer au boot. Aucun n'avait d'ordre de démarrage.

C'est l'état normal des choses, et souvent c'est très bien. Des machines qui ne dépendent pas les unes des autres n'ont pas besoin d'ordre. L'objectif de ce texte est plus étroit : si vous avez déjà dit à voix haute qu'un invité a besoin qu'un autre soit levé d'abord, alors cette phrase ne vit aujourd'hui que dans votre mémoire, et une coupure de courant ne lit pas votre mémoire.

Ce que fait Atlas

Atlas ne réordonne rien à votre place et n'invente pas un système de dépendances par-dessus celui de Proxmox VE. Ce qu'il fait, c'est rendre les relations visibles dans une seule image plutôt qu'invité par invité, pour que la question « qu'est-ce qui dépend réellement de quoi ici » puisse se poser pendant que la machine est calme, et non pendant qu'elle remonte.

Voir la forme ne la configure pas. Mais personne ne règle un ordre sensé pour une disposition qu'il n'a jamais vue dessinée.