Deux nœuds, une seule voix qui survit, et toute la prod qui passe en lecture seule : voilà ce que vous obtenez le jour où le cluster Proxmox que vous croyiez redondant perd une machine. Cette mécanique, je la vois mal comprise une fois sur deux. Elle porte un nom, le quorum, et c’est elle qui décide si votre infrastructure tient debout ou se fige quand un serveur lâche.
Un cluster vous laisse piloter plusieurs hyperviseurs comme un seul ensemble et migrer les VM de l’un à l’autre. Pour rester cohérent, il fait voter ses nœuds : chacun n’agit que s’il appartient au camp majoritaire. Cette règle existe pour empêcher le split-brain, ce scénario où deux moitiés de cluster se croient chacune seule maîtresse à bord et finissent par écrire des données contradictoires sur le même stockage. Le jour où ça arrive, vous ne réparez pas, vous arbitrez entre deux versions divergentes de vos disques.
Un cluster Proxmox veut un nombre impair de nœuds pour conserver le quorum quand l’un tombe : à deux nœuds, en perdre un fige tout en lecture seule, et la parade est un troisième nœud ou un QDevice qui arbitre.
D’où vient l’obsession du nombre impair ? Avec un nombre pair de nœuds, une coupure réseau peut couper le cluster en deux moitiés rigoureusement égales. Personne n’a la majorité, donc tout se fige des deux côtés. Trois nœuds écartent ce piège, parce qu’un camp finit toujours par l’emporter. La règle pratique tient en une ligne : trois nœuds, cinq quand l’enjeu le justifie. Et c’est précisément pour cette raison que le cluster à deux nœuds, celui par lequel presque tout le monde démarre pour des questions de budget, pose problème. Perdez-en un et l’autre se retrouve à une voix sur deux. Le voilà en minorité, basculé en lecture seule par sécurité. Votre haute disponibilité, censée vous sauver à cet instant exact, reste les bras croisés.
Deux issues se présentent alors. Ajouter un vrai troisième nœud, d’abord. Ou, moins coûteux, déployer un QDevice : un petit service d’arbitrage, le paquet corosync-qnetd, posé sur une machine tierce qui apporte la voix manquante. Un Raspberry Pi ou une VM de 512 Mo chez un autre hébergeur font l’affaire, à condition de ne jamais l’installer sur l’un des deux nœuds qu’il doit départager, sinon il tombe avec eux. Pour remettre un cluster à deux nœuds en quorum sain sans racheter de serveur, c’est ce que je conseille.
Au-delà de cet arbitrage, deux réglages font la différence sur le terrain. Le premier, je le pose systématiquement : un réseau corosync dédié, séparé du trafic des VM. Sans cette séparation, un gros transfert de migration peut saturer le lien et faire croire au cluster qu’un nœud est mort. J’ai déjà vu un cluster perdre le quorum tout seul un dimanche, simplement parce que corosync partageait le câble d’une sauvegarde nocturne de 300 Go. Le second réglage n’en est pas un, c’est une discipline : valider le cluster pour de vrai. Sur un schéma, tout fonctionne. Tant que vous n’avez pas arraché un câble pour de bon et observé si le quorum tient et si les VM rebasculent comme prévu, vous ignorez ce qui se passera le jour de l’incident. Faites le test avant la prod.
Un cas pour finir. L’an dernier, on me confie un cluster « redondant » de deux nœuds chez un client, monté par un prestataire parti depuis. Aucun QDevice, aucun réseau corosync dédié, et personne n’avait jamais débranché quoi que ce soit pour vérifier. Le jour où une carte réseau a lâché sur le premier nœud, le second s’est figé en lecture seule au lieu de prendre le relais. Trois heures d’arrêt sur une infrastructure vendue comme tolérante à la panne. La remise en état a tenu dans une après-midi : un QDevice sur une vieille machine de récupération, un VLAN corosync à part, et un arrachage de câble fait devant le client pour qu’il voie, cette fois, le failover se produire pour de vrai.