J’ai activé la haute disponibilité et la machine s’est quand même arrêtée : ce que la HA promet vraiment

Vous avez activé la haute disponibilité. Un nœud est tombé et votre machine est bien remontée sur l’autre nœud. Mais entre les deux elle n’a rien servi pendant quelques minutes, et vous pensiez qu’il n’y aurait pas d’interruption.

Le malentendu est là : la haute disponibilité ne promet pas un fonctionnement sans interruption, elle promet un redémarrage automatique.

Deux choses différentes

Le déplacement en marche est un travail planifié. Vous le lancez, la machine passe sur l’autre nœud avec sa mémoire et ne s’arrête presque pas. C’est l’outil des nuits de maintenance.

La haute disponibilité est faite pour une panne non planifiée. Quand un nœud s’effondre, tout ce qui était dans sa mémoire est parti avec lui ; il ne reste rien à copier. La seule chose possible est de démarrer la machine depuis zéro sur un autre nœud. Elle remonte donc comme votre serveur remonte après une coupure de courant.

C’est pourquoi la mesure de la HA ne devrait pas être « y a-t-il eu une interruption » mais « combien de temps l’interruption a-t-elle duré ».

Trois choses fixent la durée

La détection. Le cluster ne décide pas tout de suite qu’un nœud est vraiment mort. Prendre une fluctuation du réseau pour une mort et déplacer les machines est pire que ne pas détecter la mort. Il y a donc une attente.

La mise au silence de l’ancien nœud. Cette étape est la plus mal comprise et c’est le cœur de cet article : avant que la machine remonte sur le nouveau nœud, il faut être certain que l’ancien est bien arrêté. Si cela ne peut pas être établi, le cluster redémarre ce nœud de force.

Cela paraît brutal, mais l’alternative est une catastrophe : si l’ancien nœud est en réalité debout et que seul son réseau est coupé, la même machine tourne à deux endroits et écrit sur le même disque des deux côtés. Les données sont abîmées sans retour. C’est pourquoi le cluster préfère éteindre un nœud dont il n’est pas sûr.

Le démarrage. La machine démarre depuis le début sur le nouveau nœud. Le système d’exploitation se lance, les services montent, une base de données s’il y en a une se rétablit. Ce temps est le temps de démarrage normal de votre machine ; le cluster n’a aucun moyen de le raccourcir.

Le total, dans la plupart des installations, se compte en minutes. Ce n’est pas zéro, et ce ne le sera pas.

Trois conditions pour que la HA fonctionne

Une majorité. La HA dépend de la capacité du cluster à décider. Sans majorité, rien ne bouge. Activer la HA dans un cluster à deux nœuds revient à monter un filet de sécurité qui lâche au moment précis où vous en avez le plus besoin.

La visibilité du disque depuis l’autre nœud. Si la machine doit remonter sur le nouveau nœud, elle doit atteindre son disque. Une machine qui ne réside que sur du stockage local ne peut aller nulle part.

La capacité. Les nœuds restants doivent pouvoir porter aussi la charge du nœud tombé. Si les deux nœuds sont remplis à quatre-vingts pour cent, la HA ne vous sauvera pas, elle fera tomber le second aussi.

N’activez pas la HA sur chaque machine

Toute machine avec la HA activée devient une chose que le cluster surveille en permanence et qu’il démarre ou arrête de sa propre décision quand il le juge bon. Ce n’est pas toujours ce que vous voulez.

Le test est simple : si cette machine remontait toute seule sur un autre nœud à trois heures du matin, l’apprendre au réveil me rassurerait-il ou m’inquiéterait-il ? Si cela rassure, activez la HA. Si cela inquiète, ne l’activez pas ; prenez vous-même les décisions de cette machine.

Ce que fait Atlas

Atlas signale à part les machines laissées à la gestion de haute disponibilité. C’est pour la maintenance que cela sert le plus : quand les machines d’un nœud sont listées avant une mise à jour, on voit séparément lesquelles dépendent de votre décision et lesquelles de celle du cluster. Déplacer à la main et laisser à la gestion sont deux choses différentes, et les confondre coûte cher.

Un comportement petit mais significatif : si la haute disponibilité n’a jamais été configurée sur l’installation, Atlas voit que les fichiers de configuration correspondants sont absents et ne pose pas du tout cette question, il renvoie une réponse vide. Sur une installation qui n’utilise pas la HA, le produit n’occupe donc ni vous ni le système à chercher quelque chose qui n’existe pas.

Et une limite mérite d’être dite clairement : Atlas ne prend ni ne modifie la décision de HA du cluster. Qu’une machine soit laissée à la HA relève de vous et de Proxmox ; Atlas la rend visible, il ne décide pas à votre place.