On me présente souvent la HA comme un bouton de sécurité : on l’active, et le cluster « se débrouille » si un serveur tombe. C’est faux, et la croyance est dangereuse. Cocher la case « HA » dans l’interface Proxmox ne crée aucune des conditions qui permettent à une VM de redémarrer ailleurs. Ça déclare une intention. Le reste se gagne avant, sur le matériel et la configuration.
Une VM qui se relance toute seule sur un autre serveur quand le premier lâche, à 3 heures du matin, sans réveiller personne : voilà ce que promet la haute disponibilité de Proxmox. La promesse est réelle. Elle repose juste sur trois prérequis que la moitié des gens découvrent trop tard.
La haute disponibilité Proxmox ne s’active pas en cochant une case : elle réclame un stockage accessible depuis plusieurs nœuds, un quorum stable et un fencing qui isole vraiment le nœud mort, faute de quoi elle ne donne qu’un faux sentiment de sécurité.
Le stockage, d’abord
Si le disque de votre VM ne vit que sur le serveur tombé, aucun autre nœud n’a de quoi la relancer : le disque gît par terre avec le reste. Il vous faut donc un stockage que plusieurs nœuds peuvent lire, type Ceph, NFS ou SAN. À défaut, une réplication ZFS recopie la VM sur un autre nœud à intervalle régulier, mais sachez ce que ça implique : ce qui a changé entre deux copies disparaît à la bascule. Réglez l’intervalle en connaissance de cause.
Le quorum, ensuite
La HA s’appuie sur le cluster, et le cluster ne décide rien sans quorum. Trois nœuds, ou deux nœuds plus un QDevice qui fait l’arbitre. Ajoutez un réseau de cluster sur sa propre carte, à l’écart du trafic des VM. J’ai dépanné un cluster de deux nœuds « en HA » sans QDevice : à la première coupure réseau, plus personne n’avait la majorité, et rien n’a basculé. Pour relancer une VM ailleurs, il faut le droit de décider. Ce droit-là n’appartenait à personne.
Le fencing, celui qu’on bâcle
C’est le prérequis qu’on traite par-dessus la jambe, et c’est le plus brutal quand il manque. Avant de relancer une VM ailleurs, le cluster doit être certain que le nœud d’origine est bien hors-jeu. S’il ne l’est pas, la même VM tourne à deux endroits, écrit dans le même stockage, et corrompt ses propres données en quelques secondes. Le fencing coupe l’alimentation du nœud suspect ou l’isole par son IPMI (l’interface de gestion matérielle qui pilote le serveur à distance, même éteint). Sans fencing fiable, il n’y a pas de HA, seulement un pari. Je ne transige pas là-dessus.
Pourquoi une HA bancale est pire que rien
Imaginez un cluster sans stockage partagé ni fencing correct, HA activée quand même. L’interface affiche du vert, tout le monde dort tranquille. Le jour de la vraie panne, deux issues, aussi mauvaises l’une que l’autre. Première possibilité : la VM ne redémarre pas, son disque étant inaccessible, et vous l’apprenez au pire moment. Seconde : faute de fencing, elle redémarre en double, et vous passez la nuit suivante à réparer une base corrompue.
Une coquille vide qui affiche du vert revient plus cher qu’une absence de HA. Sans HA, au moins, vous saviez qu’il fallait surveiller.
Ce que je débranche avant de livrer
Je ne signe pas une HA sans avoir tué un nœud pour de bon. Je débranche le câble, ou je coupe l’alim, puis je regarde : la VM bascule-t-elle, en combien de temps, et les données tiennent-elles une fois relancée ? Tant que ce test n’est pas passé, ce qui s’affiche à l’écran n’a rien prouvé. C’est un fichier de configuration qui attend sa première vraie panne.
Une réserve, pour finir, parce que tester ne fait pas tout. Mon coup de débranchement valide le scénario que j’ai imaginé : un nœud qui meurt franc. Les pannes vicieuses, elles, ne préviennent pas — une carte réseau qui ne lâche qu’à moitié, une latence de stockage qui grimpe sans coupure nette. Ces cas-là passent parfois sous le radar du fencing et du quorum, et aucune HA ne les couvre tous. Sur les défaillances claires, elle réduit le risque sans jamais le supprimer. Une supervision qui vous alerte vite reste le complément, pas l’option.