Changer ou ajouter un ring Corosync sur un cluster Proxmox

Le contexte : 2 nœuds OVH, ring sur le vRack

L'architecture de départ est classique chez OVH : deux serveurs Proxmox interconnectés par un vRack (réseau privé L2 entre serveurs OVH). Corosync utilise ce vRack comme ring unique (link 0), et la réplication ZFS entre les deux nœuds passe par ces mêmes IP privées. L'interface publique, elle, ne porte aucun ring : elle sert le trafic des VM, pas le cluster.

Deux fichiers, deux lecteurs : la base à comprendre

C'est le point qui fait perdre le plus de temps. Corosync sur Proxmox manipule deux fichiers distincts, lus par des composants différents :

Étape 1 — Éditer la configuration

On édite /etc/pve/corosync.conf si on est quorate, sinon /etc/corosync/corosync.conf localement (voir le mode dégradé plus bas). Principes :

• ring0_addr = lien primaire (celui que suivra la réplication).
• ring1_addr = lien secours.
• Déclarer un bloc interface par linknumber utilisé (0 et 1).
• Incrémenter config_version à chaque édition.

Avant de choisir la nouvelle version, vérifier celle réellement chargée par le daemon :

corosync-cmapctl -g totem.config_version

Dans notre cas, on passe d'un seul ring (vRack) à deux rings en ajoutant l'IP publique. Pour basculer la réplication sur le public, on met l'IP publique en ring0_addr et le vRack (encore vivant sur l'autre nœud) en secours :

Pour mémoire, voici la configuration de départ (un seul ring sur le vRack), utile pour comparer :

Étape 2 — Redémarrer Corosync

Le reload à chaud est capricieux ; on préfère un restart complet qui recharge le fichier quelle que soit la version. À faire sur les deux nœuds :

systemctl restart corosync          # sur les DEUX nœuds
corosync-cfgtool -s                 # LINK 0 = primaire, status: connected
pvecm status                        # Quorate: Yes, sans 'expected 1'

Étape 3 — Rafraîchir la nodelist pmxcfs

Indispensable après un changement de ring0_addr : sinon les outils PVE gardent l'ancienne IP en cache et la réplication continue de cibler le vRack mort.

systemctl restart pve-cluster       # sur les DEUX nœuds
cat /etc/pve/.members               # les "ip" doivent montrer le nouveau primaire

On enchaîne avec les autres services PVE pour qu'ils rechargent la topologie :

systemctl restart pvestatd pvedaemon pveproxy
# si HA active :
systemctl restart pve-ha-lrm pve-ha-crm

Étape 4 — La réplication ZFS bascule sur l'IP publique

Si les IP des nœuds ont changé, rafraîchir les empreintes SSH du cluster, puis forcer un job pour valider :

pvecm updatecerts                       # rafraîchit les ssh_known_hosts du cluster
pvesr run --id <vmid-job> --verbose     # le ssh doit cibler la nouvelle IP publique

Cas dégradé : plus de quorum du tout

Si le lien primaire est mort des deux côtés (ou si la panne a déjà fait sauter le quorum avant l'intervention),/etc/pve est en lecture seule et la propagation cluster ne fonctionne plus. Il faut pousser la conf à la main :

Vérification finale

Prérequis réseau / firewall

Ce scénario — un nœud OVH qui perd brutalement son lien vRack — est exactement le type d'incident que nous traitons en astreinte pour nos clients. Nous opérons des clusters Proxmox hébergés chez OVHcloud en infogérance : bascule de ring, réplication ZFS, suivi de la réparation matérielle avec le datacenter, retour en nominal.

Questions fréquentes

Documentation officielle

Articles connexes