Comment créer un noeud figuré sans droit de vote dans un cluster Proxmox à deux serveurs

Dans un cluster Proxmox à deux nœuds, le mécanisme de quorum de Corosync peut rapidement devenir un point de blocage : si le nœud « principal » tombe, le nœud « secondaire » se retrouve seul et perd le quorum, ce qui rend le cluster inutilisable. Plus vous avez de nœuds, plus vous avez de votants et de capacités à exploiter dans votre cluster.

Ici, on souhaite disposer d’un second serveur Proxmox qui ne participe pas réellement aux décisions de quorum. Cela évite que le cluster se bloque lorsqu’un seul nœud est actif, tout en conservant la possibilité de lancer des machines virtuelles de démonstration sur le serveur secondaire. Cet article décrit comment désactiver le vote Corosync du nœud secondaire et garantir la stabilité du cluster.

J’ai eu besoin de faire ce type de cluster à deux nœuds pour mon application PVMSS, pour tester les capacités de l’application face à un cluster Proxmox. Cependant, je n’ai pas besoin de plusieurs nœuds de travail, seulement un seul sera actif.

Pour éviter le problème de “split-brain” tout en conservant le deuxième serveur uniquement comme machine de test/figuration, il faut :

Supprimer son droit de vote (weight = 0).
Indiquer à Corosync qu’il s’agit d’un cluster à deux nœuds, où le quorum doit être calculé sur un seul vote réel.

Le cœur du problème réside dans le paramètre votes. En attribuant votes: 0 au nœud secondaire, on le retire du calcul du quorum. On indique également à Corosync qu’il ne doit attendre qu’un seul vote réel (expected_votes: 1) et on active le mode spécial deux‑nœuds (two_node: 1). Cette combinaison assure que le cluster fonctionne tant que le nœud principal est en ligne, et que le second nœud ne cause aucun « split‑brain ».

Modifier le fichier corosync.conf du nœud principal#

Le fichier corosync.conf ne peut pas être modifié tant que les services qui utilisent ce fichier sont démarrés. Connectez-vous sur le nœud principal, où vous ferez les modifications. Stoppez les services corosync et pve-cluster :

systemctl stop pve-cluster
systemctl stop corosync

Maintenant, il faut utiliser la commande pmxcfs pour explorer le système de fichier de Proxmox et y apporter des modifications. Faites un pmxcfs -l, les messages suivants devraient s’afficher :

[main] notice: resolved node name '<nom_node>' to '<ip_node>' for default node IP address
[main] notice: forcing local mode (although corosync.conf exists)

Avant toute modification, il est primordial de faire une copie de sauvegarde du fichier de configuration via un simple “cp” : cp /etc/pve/corosync.conf /etc/pve/corosync.conf.bak.

Éditez le fichier /etc/pve/corosync.conf et ajoutez les modifications suivantes :

totem {
    ...
    config_version: 2 # incrémentez cette valeur avant d'enregistrer le fichier corosync.conf
    ...
}

nodelist {
    node {
        name: nom_node1
        nodeid: 1
        quorum_votes: 1          # nœud principal : droit de vote normal
        ...
    }
    node {
        name: nom_node2
        nodeid: 2
        quorum_votes: 0          # nœud secondaire : aucun droit de vote, à mettre à 0
        ...
    }
}

quorum {
    provider: corosync_votequorum
    expected_votes: 1      # Le quorum attend seulement 1 vote réel
    two_node: 1            # Active le mode « two‑node » (évite le split‑brain)
    wait_for_all: 0
}

votes: 0 retire le droit de vote du second nœud.
expected_votes: 1 indique que le quorum sera atteint dès qu’un seul vote (celui du nœud principal) est présent.
two_node: 1 active le mode spécial deux‑nœuds : si le nœud principal disparaît, le second nœud continue de fonctionner en mode « standalone » (pas de blocage du cluster), mais il ne pourra pas prendre la place du principal tant que le quorum n’est pas rétabli.
wait_for_all: 0 évite à corosync d’attendre les votes de tous les membres du cluster.

Enregistrez les modifications faites dans le fichier, quittez le mode local de la commande pmxcfs et redémarrez les services :

killall pmxcfs && systemctl restart corosync.service pve-cluster.service

Les actions seront répliquées sur le second nœud. Si ce n’est pas le cas, connectez-vous sur le second nœud, redémarrez les services pve-cluster et corosync, puis assurez-vous que le fichier /etc/pve/corosync.conf est identique au premier nœud.

Avec la commande pvecm status, vérifiez que la seconde machine du cluster n’a plus son droit de vote :

root@node1:~# pvecm status
Cluster information
-------------------
Name:             clustername
Config Version:   3
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Sat Nov  1 21:36:19 2025
Quorum provider:  corosync_votequorum
Nodes:            2
Node ID:          0x00000001
Ring ID:          1.266
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   1
Highest expected: 1
Total votes:      1
Quorum:           1
Flags:            2Node Quorate WaitForAll

Membership information
----------------------
    Nodeid      Votes Name
0x00000001          1 172.16.0.1 (local)
0x00000002          0 172.16.132.240

Résultat#

Le serveur secondaire devient un “nœud de figuration » : il reste visible dans le cluster, peut héberger des VM de test, mais n’influence jamais le processus de décision de Corosync. Le cluster reste pleinement fonctionnel même si le nœud principal tombe grâce au mode two_node.

Sources#

The Startup Behavior of a 2-Node Pacemaker ClusterThis article describes fencing considerations, quorum settings, and commands for sensible behavior in a 2-node Pacemaker with Corosync cluster Goals for a 2-node cluster: Do not go online with stale data (replication case). Do not cause a startup fencing loop. Run Pacemaker primitive services exactly once (prevent IP conflicts, data corruption, and other issues). To be allowed to start services, a node needs to be quorate, that is, the node needs to be a member of a cluster partition that has quorum.Knowledge Base