Prérequis
- Deux nœuds Proxmox VE à jour
- Le nœud qui rejoint le cluster n’héberge encore aucune VM ni conteneur
- Heures synchronisées (NTP)
- Une petite machine tierce pour le QDevice
01Ce que demande Corosync
Le cluster repose sur Corosync. Les nœuds doivent se joindre en UDP sur les ports 5405 à 5412, avec moins de 5 ms de latence, des horloges synchronisées et SSH (TCP 22) entre eux. Un réseau dédié au cluster est l’idéal : une carte 1 Gbit/s suffit dans la plupart des cas.
Entre deux sites distants, surveillez la latence de près : au-delà de quelques millisecondes, le cluster devient instable.
02Créer le cluster
# Sur le premier nœud
pvecm create lab
# Sur le second, en pointant le premier
pvecm add 192.168.10.11
# Vérifier
pvecm status
pvecm nodes03Le problème des deux nœuds
Un cluster ne prend de décision qu’avec la majorité des votes : le quorum. À deux nœuds, chacun a une voix ; si l’un tombe, l’autre n’a plus que la moitié des votes, et le cluster se fige par prudence. La documentation recommande trois nœuds pour un quorum fiable.
Sans troisième serveur complet, un QDevice apporte ce troisième vote.
04Ajouter le QDevice
Le QDevice ne fait tourner aucune VM : il départage. Il utilise l’algorithme ffsplit, qui accorde son vote à une seule des deux moitiés en cas de coupure entre les nœuds.
# Sur la machine tierce
apt install corosync-qnetd
# Sur chacun des deux nœuds
apt install corosync-qdevice
# Puis, depuis un nœud
pvecm qdevice setup 192.168.10.5005En dernier recours
Si un nœud est définitivement perdu et qu’aucun QDevice ne répond, abaisser le nombre de votes attendus rend la main. À réserver aux urgences : deux nœuds isolés qui se croient chacun seul maître, c’est la corruption assurée.
pvecm expected 1À retenir
- Corosync : UDP 5405-5412, moins de 5 ms, heure synchronisée.
- Deux nœuds : pas de majorité si l’un tombe.
- Le QDevice apporte le troisième vote, sans faire tourner de VM.
- pvecm status avant toute opération.