Le raisonnement paraît solide : deux serveurs, mis en cluster, et si l'un tombe l'autre prend le relais. C'est le premier réflexe quand on cherche de la redondance sans y consacrer un budget de production.
Puis arrive le jour où un nœud tombe réellement. Et le survivant, au lieu de reprendre la charge, se fige : plus de démarrage possible, plus de modification, interface en lecture seule. Ce n'est pas un dysfonctionnement. C'est exactement ce qui était prévu.
Le quorum, et pourquoi 2 est le pire nombre
Un cluster doit à tout moment savoir qui décide. Le mécanisme est un vote : chaque nœud a une voix, et il faut la majorité stricte pour que le groupe soit considéré comme légitime.
Faites le calcul pour différentes tailles :
- 3 nœuds : majorité à 2. Un nœud peut tomber, les deux autres continuent.
- 5 nœuds : majorité à 3. Deux peuvent tomber.
- 2 nœuds : majorité à 2. Aucun ne peut tomber.
Avec deux nœuds, la perte d'un seul fait passer le survivant en minorité. Il perd le quorum, refuse d'écrire dans la configuration partagée, et se met en retrait. Un cluster à deux nœuds est donc, en pratique, moins disponible qu'un serveur seul pour les opérations d'administration.
Pourquoi le survivant ne peut pas simplement continuer
La question naturelle est : pourquoi ne pas laisser le nœud restant faire son travail ? Parce qu'il est incapable de distinguer deux situations radicalement différentes :
- l'autre nœud est réellement arrêté ;
- l'autre nœud fonctionne parfaitement, mais le lien réseau entre eux est coupé.
Vu du nœud A, ces deux cas sont rigoureusement identiques : silence sur le réseau. Or dans le second cas, le nœud B raisonne symétriquement et conclut lui aussi qu'il est le survivant.
Si les deux se mettent alors à travailler, ils démarrent chacun les mêmes machines virtuelles sur le même stockage partagé. Deux systèmes écrivent en parallèle sur les mêmes fichiers, sans coordination. C'est le split-brain, et son résultat n'est pas un conflit à résoudre : c'est une corruption du système de fichiers, généralement définitive.
La solution : une troisième voix, sans troisième serveur
Il n'est pas nécessaire d'ajouter un vrai nœud. Il suffit d'ajouter une voix.
Un témoin externe est un participant qui vote sans rien exécuter : pas de stockage partagé, pas de machines virtuelles, aucune charge. Le cluster compte alors trois voix, la majorité passe à deux, et la perte d'un nœud laisse le survivant en majorité avec le témoin. Il conserve le quorum et continue de fonctionner.
Deux conditions sur ce témoin :
- Il doit être indépendant des deux nœuds. Hébergé sur l'un d'eux, il disparaît avec son hôte et ne sert strictement à rien.
- Il doit être joignable par les deux. Un témoin placé derrière le même équipement réseau que l'un des nœuds réintroduit un point de défaillance commun.
En dehors de cela, il peut être minuscule : un micro-ordinateur, un petit conteneur sur un NAS, une machine hébergée ailleurs. Ce qu'il apporte est un arbitrage, pas de la capacité.
Le forçage manuel : utile, mais à comprendre
En dépannage, il est possible de déclarer au nœud survivant qu'une seule voix suffit. C'est parfois la seule façon de redémarrer un service critique un dimanche soir.
Mais cette opération désactive la protection contre le split-brain. Elle n'est acceptable qu'après avoir vérifié physiquement que l'autre nœud est éteint — pas « il ne répond pas au ping », mais réellement hors tension. Et elle doit être annulée dès le retour à la normale. Ce n'est jamais une configuration permanente.
Le quorum ne suffit pas si vous automatisez la reprise
Dernier étage du raisonnement, souvent sauté : avec un témoin, le survivant garde le quorum et peut redémarrer automatiquement les machines du nœud perdu. Mais il ne sait toujours pas si ce nœud est mort ou seulement isolé.
D'où l'isolation du nœud défaillant : le cluster force son arrêt — coupure d'alimentation pilotée, carte d'administration, prise commandée — avant de redémarrer ses machines ailleurs. On ne suppose plus qu'il est hors service, on s'en assure.
Pour un homelab, la question se tranche simplement :
- Administration centralisée et migration manuelle : un témoin suffit, l'isolation est superflue.
- Redémarrage automatique activé : sans isolation, vous pouvez recréer précisément le doublon que le quorum protégeait.
Ce qu'il faut retenir
Deux nœuds sans témoin, c'est un cluster qui se bloque au premier incident — l'inverse de l'objectif recherché. Ajoutez une troisième voix : c'est peu coûteux et cela transforme le comportement du jour de panne. Et n'activez la reprise automatique qu'avec un moyen de garantir que le nœud suspect est réellement hors service.
Commentaires