Proxmox « node not in cluster » : que s’est-il passé et comment rejoindre correctement

Ce que signifie réellement « node not in cluster »

Dans Proxmox VE, « node not in cluster » apparaît généralement lorsqu’un nœud pense qu’il devrait faire partie du cluster, mais qu’il ne peut pas voir (ou valider) l’état du cluster. Cet état est fourni par Corosync et stocké/distribué via pmxcfs (le système de fichiers de cluster Proxmox) monté sur /etc/pve.

Le message peut signifier l’une des réalités pratiques suivantes :

• Corosync ne tourne pas (ou ne peut pas se lier au réseau du cluster).
• Pas de quorum, donc pmxcfs devient en lecture seule ou ne se monte pas complètement, et la configuration du cluster ne peut pas être considérée comme fiable.
• L’identité du nœud est obsolète (mauvaise corosync.conf, mauvais ID de nœud, mauvaises adresses de ring, ou mauvais mappage nom d’hôte/IP).
• Split brain : le nœud a formé/maintenu une vue différente du cluster et est maintenant incompatible.
• Dérive temporelle qui casse l’authentification Corosync ou fait expirer des jetons de façon inventive.
• Vous avez changé le réseau (VLAN, MTU, bonding, firewall) et le trafic Corosync est maintenant malheureux.

Voici la partie opinionnée : traitez le message comme un fusible de sécurité. C’est Proxmox qui vous dit : « Je ne peux pas prouver l’état du cluster ; je ne vais pas faire semblant. » Votre travail est de déterminer pourquoi il ne peut pas le prouver, puis de choisir la voie de récupération la moins destructive.

Autre point : ne « corrigez » jamais cela en copiant des fichiers au hasard dans /etc/pve depuis un autre nœud à moins de comprendre exactement ce que vous faites. /etc/pve n’est pas un répertoire normal. C’est une base de données distribuée avec des opinions.

Faits et contexte qui expliquent l’étrangeté

Ce ne sont pas des trivia. Ce sont les petites mines historiques qui expliquent pourquoi Proxmox se comporte ainsi.

1. Corosync vient de l’écosystème HA Linux et hérite d’une vision « adhésion et quorum d’abord ». Si l’adhésion est incertaine, il préfère s’arrêter plutôt que deviner.
2. Proxmox stocke la plupart de la configuration de cluster dans pmxcfs, un système FUSE soutenu par une base en mémoire répliquée via Corosync. Voilà pourquoi la perte de Corosync casse souvent des tâches de configuration « simples ».
3. /etc/pve n’est pas comme /etc. Il est monté dynamiquement. S’il n’est pas monté, les services Proxmox qui s’y attendent peuvent se comporter comme si vous aviez supprimé le plan de contrôle.
4. Les règles de quorum existent pour éviter le split brain, pas pour vous ennuyer. Elles expliquent aussi pourquoi un cluster à deux nœuds est opérationnellement délicat à moins d’ajouter un troisième votant (qdevice) ou d’accepter des contraintes.
5. L’identité d’un nœud de cluster repose sur des IDs et des noms transportés dans la configuration Corosync et l’état interne ; un nom d’hôte non correspondant peut ressembler à une machine différente apparaissant dans le même uniforme.
6. Proxmox a historiquement été optimisé pour la fiabilité sur site où « un nœud a disparu » est souvent un problème de câblage ou de switch, pas un événement d’auto-scaling. L’interface et les réglages par défaut reflètent cela.
7. Le multicast réseau était autrefois important dans les clusters. Corosync moderne utilise typiquement unicast, mais la règle « le réseau de cluster doit être simple et prévisible » a survécu pour de bonnes raisons.
8. La synchronisation du temps est une dépendance du cluster parce que la messagerie authentifiée et les timeouts sont des hypothèses intégrées au protocole d’adhésion. Les problèmes NTP peuvent se faire passer pour des pannes réseau.
9. La pile HA de Proxmox suppose que le fencing est important. Sans vue d’adhésion fiable, elle évite d’effectuer des actions susceptibles de lancer la même VM deux fois.

Une idée paraphrasée qui devrait figurer sur tous les murs d’opération : espoir n’est pas une stratégie ; concevez pour que les pannes soient attendues et réparables. — Gene Kranz (idée paraphrasée)

Mode opératoire de diagnostic rapide

Voici la séquence « arrêtez de faire défiler et trouvez le goulot d’étranglement ». Vous essayez de répondre à trois questions : Avons-nous le quorum ? Corosync est-il sain ? /etc/pve est-il monté et cohérent ?

1) D’abord : vérifier si le nœud est simplement isolé

• Peut-il atteindre les autres nœuds sur les IP du ring Corosync ?
• L’interface réseau du cluster est-elle montée, avec le bon VLAN/MTU, sans filtrage de firewall ?
• Le temps est-il cohérent ?

2) Ensuite : vérifier quorum et adhésion depuis un nœud sain

• Si le cluster a le quorum ailleurs, le nœud « hors cluster » est le problème.
• Si le cluster n’a pas de quorum, ne « réintégrez » rien pour l’instant. Stabilisez d’abord le quorum.

3) Troisième étape : décider de la voie de récupération

• Voie A (meilleure) : l’identité du nœud est encore valide ; corrigez le réseau/temps/Corosync et il se réintègre automatiquement.
• Voie B (courante) : le nœud a été supprimé ou son état a divergé ; vous devez le supprimer et le rajouter via pvecm delnode puis pvecm add.
• Voie C (pire) : split brain ou états de cluster en conflit ; vous devez choisir une « source de vérité » et nettoyer l’autre côté soigneusement.

Règle opérationnelle courte : si vous avez encore des VMs en fonctionnement sur le nœud défaillant, considérez-le comme un domaine de défaillance séparé tant que vous n’avez pas confirmé l’adhésion au cluster. Évitez les actions HA qui pourraient démarrer des workloads en double.

Comment fonctionne le clustering Proxmox (les éléments importants)

Corosync : l’oracle d’adhésion

Corosync est la couche de communication du cluster. Il décide qui fait partie du groupe. Il applique aussi la politique de quorum : si moins de votes requis sont présents, le cluster devient conservateur. Le cluster peut encore exécuter des workloads existants, mais les opérations du plan de contrôle peuvent être bloquées ou passer en lecture seule.

Quand Corosync est arrêté ou ne peut pas communiquer, les services Proxmox sont forcés dans une posture « je ne peux pas vérifier l’état ». C’est là que « node not in cluster » apparaît souvent.

pmxcfs : votre configuration est un système de fichiers répliqué

pmxcfs fournit /etc/pve. C’est là que résident les configs VM, définitions de stockage, règles firewall et métadonnées de cluster. Ce n’est pas juste un répertoire que vous éditez ; c’est une machine d’état distribuée déguisée en système de fichiers.

Si /etc/pve n’est pas monté (ou est monté mais bloqué), vous verrez des symptômes étranges :

• Des fichiers de config de VM « manquants » même si les VMs existent toujours sur disque.
• Une interface montrant un état de cluster obsolète ou vide.
• Des modifications de configuration du cluster qui échouent ou reviennent en arrière.

Quorum : pourquoi deux nœuds sont un piège à moins d’avoir un plan

Dans un cluster à trois nœuds, la perte d’un nœud laisse typiquement encore le quorum. Dans un cluster à deux nœuds, la perte de l’un ou l’autre fait généralement perdre le quorum sauf si vous ajoutez un dispositif de quorum (qdevice) ou acceptez des contraintes. Ce n’est pas du dramatique Proxmox ; c’est des mathématiques.

Vérité sèchement drôle : un cluster à deux nœuds sans troisième votant est comme une réunion avec deux dirigeants et sans procès-verbal ; celui qui parle en dernier pense qu’il a raison.

Split brain : le mode de défaillance à éviter

Split brain signifie que deux parties du cluster se croient autoritaires. Si les deux côtés peuvent écrire sur un stockage partagé ou démarrer la même VM, vous obtenez de la corruption de données ou des doublons. Le comportement de quorum de Proxmox essaie fort d’empêcher cela. Votre travail n’est pas de le devancer avec des « rustines » temporaires.

Tâches pratiques : commandes, sorties, et décisions

Ci‑dessous des tâches concrètes à exécuter. Chacune inclut (1) une commande, (2) ce que la sortie plausible signifie, et (3) la décision suivante. Exécutez-les sur le nœud affecté et au moins sur un nœud sain quand c’est possible.

Task 1: Confirm what Proxmox thinks its node name is

cr0x@server:~$ hostnamectl --static
pve03

Sens : Proxmox s’attend à ce que le nom du nœud corresponde à la config du cluster. Si le cluster connaît ce nœud comme pve03 mais que votre hôte s’appelle maintenant pve3, vous avez créé une nouvelle identité.

Décision : Si le nom d’hôte a changé, remettez-le à celui connu par le cluster avant de faire quoi que ce soit d’autre.

Task 2: Validate hostname resolution (cluster traffic often uses names)

cr0x@server:~$ getent hosts pve01 pve02 pve03
10.10.10.11   pve01
10.10.10.12   pve02
10.10.10.13   pve03

Sens : Les noms résolvent vers les IP attendues du ring. Si c’est faux (anciennes IP, mauvais sous‑réseau), l’adhésion Corosync casse.

Décision : Corrigez le DNS ou la cohérence de /etc/hosts sur tous les nœuds ; ne faites pas une rustine sur un seul nœud.

Task 3: Check if /etc/pve is mounted (pmxcfs health indicator)

cr0x@server:~$ mount | grep -E 'pmxcfs|/etc/pve'
pmxcfs on /etc/pve type fuse.pmxcfs (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other)

Sens : Si vous voyez pmxcfs, le système de fichiers du cluster est monté. Sinon, Proxmox fonctionne « à l’aveugle ».

Décision : Si non monté, concentrez-vous sur Corosync et le statut du service pve-cluster ensuite.

Task 4: Check pve-cluster and Corosync services

cr0x@server:~$ systemctl status pve-cluster corosync --no-pager
● pve-cluster.service - The Proxmox VE cluster filesystem
     Loaded: loaded (/lib/systemd/system/pve-cluster.service; enabled)
     Active: active (running)
● corosync.service - Corosync Cluster Engine
     Loaded: loaded (/lib/systemd/system/corosync.service; enabled)
     Active: failed (Result: exit-code)

Sens : Corosync a échoué : pas d’adhésion, probablement pas de vue de quorum. pve-cluster peut encore tourner localement mais sans état de cluster valide.

Décision : Inspectez les logs et la config de Corosync ; ne sautez pas à « réintégrer ».

Task 5: Read Corosync logs for the real error

cr0x@server:~$ journalctl -u corosync -b --no-pager | tail -n 25
Dec 25 10:11:12 pve03 corosync[1321]: [TOTEM ] Token has not been received in 2730 ms
Dec 25 10:11:12 pve03 corosync[1321]: [TOTEM ] A processor failed, forming new configuration.
Dec 25 10:11:14 pve03 corosync[1321]: [KNET  ] link: host: 2 link: 0 is down
Dec 25 10:11:15 pve03 corosync[1321]: [MAIN  ] Corosync Cluster Engine exiting with status 1

Sens : Échec de chemin réseau (knet link down) ou perte sévère de paquets/mismatch MTU. Corosync n’aime pas les réseaux instables.

Décision : Validez l’interface réseau, le MTU, le tagging VLAN et le firewall. Ne touchez pas à l’adhésion du cluster tant que les paquets ne circulent pas.

Task 6: Confirm Corosync ring connectivity (ICMP is not enough, but it’s a start)

cr0x@server:~$ ping -c 3 10.10.10.11
PING 10.10.10.11 (10.10.10.11) 56(84) bytes of data.
64 bytes from 10.10.10.11: icmp_seq=1 ttl=64 time=0.356 ms
64 bytes from 10.10.10.11: icmp_seq=2 ttl=64 time=0.331 ms
64 bytes from 10.10.10.11: icmp_seq=3 ttl=64 time=0.342 ms

--- 10.10.10.11 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2034ms

Sens : La connectivité basique existe. Si ping échoue, le cluster ne peut pas fonctionner. Si ping réussit mais Corosync échoue, regardez le MTU, le firewall ou l’asymétrie.

Décision : Si ping est correct, testez le MTU et le comportement UDP ensuite.

Task 7: Check MTU consistency (silent killer for knet)

cr0x@server:~$ ip -br link show
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
eno1             UP             3c:ec:ef:11:22:33 <BROADCAST,MULTICAST,UP,LOWER_UP>
vmbr0            UP             3c:ec:ef:11:22:33 <BROADCAST,MULTICAST,UP,LOWER_UP>
vmbr1            UP             3c:ec:ef:11:22:33 <BROADCAST,MULTICAST,UP,LOWER_UP>

cr0x@server:~$ ip link show vmbr1 | grep -E 'mtu|state'
2: vmbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000

Sens : Si ce nœud utilise MTU 9000 mais que le switch ou les pairs sont en 1500, vous obtenez un comportement « marche parfois » que Corosync punit.

Décision : Uniformisez le MTU bout en bout. Si vous ne pouvez pas garantir les jumbo frames, restez à 1500.

Task 8: Verify time sync (Corosync auth and timeouts hate drift)

cr0x@server:~$ timedatectl
               Local time: Thu 2025-12-25 10:14:02 UTC
           Universal time: Thu 2025-12-25 10:14:02 UTC
                 RTC time: Thu 2025-12-25 10:14:01
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Sens : « synchronized: yes » est ce que vous voulez. Si c’est « no », réparez NTP avant d’accuser Corosync.

Décision : Remettez en marche NTP (chrony/systemd-timesyncd) et revérifiez l’adhésion.

Task 9: Check cluster status from a healthy node (authoritative view)

cr0x@server:~$ pvecm status
Cluster information
-------------------
Name:             prod-cluster
Config Version:   18
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Thu Dec 25 10:15:10 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.6
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   3
Highest expected: 3
Total votes:      3
Quorum:           2
Flags:            Quorate

Sens : Le cluster est sain ailleurs. Le nœud cassé est celui hors de l’adhésion.

Décision : Concentrez-vous sur la config/réseau du nœud cassé plutôt que sur une chirurgie cluster globale.

Task 10: Check membership list and whether the node is “known”

cr0x@server:~$ pvecm nodes
Membership information
----------------------
    Nodeid      Votes Name
0x00000001          1 pve01
0x00000002          1 pve02
0x00000003          1 pve03

Sens : Si le cluster liste encore le nœud, il devrait pouvoir se réintégrer sans suppression, en supposant que l’identité corresponde et que le réseau fonctionne.

Décision : Si le nœud est absent ici, vous devrez probablement utiliser pvecm add après nettoyage.

Task 11: Inspect the local Corosync config on the broken node

cr0x@server:~$ grep -E 'cluster_name|ring0_addr|nodeid|bindnetaddr' -n /etc/pve/corosync.conf
2:  cluster_name: prod-cluster
12:     bindnetaddr: 10.10.10.0
18:         ring0_addr: pve01
23:         nodeid: 1
28:         ring0_addr: pve02
33:         nodeid: 2
38:         ring0_addr: pve03
43:         nodeid: 3

Sens : Les IDs de nœud et les adresses de ring doivent correspondre à ce que le cluster attend. Si ce fichier manque ou est différent, vous ne regardez pas la même réalité de cluster.

Décision : Si le fichier diffère de celui d’un nœud sain, vous avez une dérive de config ou /etc/pve n’est pas correctement monté.

Task 12: Verify the Corosync authentication key exists and matches (only if you know you should)

cr0x@server:~$ ls -l /etc/corosync/authkey
-r-------- 1 root root 128 Dec 10 09:02 /etc/corosync/authkey

Sens : Clé d’auth manquante = impossibilité d’authentifier le trafic du cluster. Mauvaise clé = impossibilité de rejoindre.

Décision : Si le nœud a été réinstallé ou partiellement reconstruit, il peut avoir une clé différente ; vous devez le réajouter proprement plutôt que copier des clés à l’aveugle.

Task 13: See whether the node thinks it’s in a cluster at all

cr0x@server:~$ test -f /etc/pve/.members && echo "members file exists" || echo "members file missing"
members file exists

Sens : La présence suggère que des métadonnées de cluster existent, mais elles peuvent être obsolètes ou en lecture seule.

Décision : Si /etc/pve n’est pas monté mais que ce fichier existe, vous pourriez voir un ancien état local de montage ; résolvez d’abord les problèmes de service/montage.

Task 14: Check if /etc/pve is read-only (quorum loss symptom)

cr0x@server:~$ touch /etc/pve/test-write 2>&1 || true
touch: cannot touch '/etc/pve/test-write': Read-only file system

Sens : Vous n’avez pas le quorum du point de vue de ce nœud, ou pmxcfs protège l’état.

Décision : Ne forcez pas les modifications. Réparez d’abord le quorum/l’adhésion. Si c’est une situation de survie sur un seul nœud, vous pouvez temporairement ajuster les attentes de quorum (avec prudence et un plan de retour arrière).

Task 15: Confirm firewall isn’t blocking Corosync traffic

cr0x@server:~$ pve-firewall status
Status: enabled/running

cr0x@server:~$ iptables -S | grep -E 'DROP|REJECT' | head
-A INPUT -j PVEFW-INPUT
-A PVEFW-INPUT -j DROP

Sens : Si le firewall est activé et que les règles sont strictes, le trafic UDP de Corosync peut être bloqué.

Décision : Assurez-vous que le réseau du cluster est dans une zone de confiance ou autorisez explicitement Corosync. Ne désactivez pas le firewall en permanence ; corrigez les règles.

Task 16: Confirm Ceph (if used) isn’t the real incident

cr0x@server:~$ ceph -s
cluster:
  id:     7d2c1c2a-9b9c-4e5b-9a65-1f9b6c1a1b11
  health: HEALTH_WARN
          1 osds down

services:
  mon: 3 daemons, quorum a,b,c
  mgr: x(active), standbys: y
  osd: 12 osds: 11 up, 12 in

Sens : Un nœud quittant le cluster Proxmox peut coïncider avec des avertissements Ceph, mais le quorum Ceph peut rester correct. Séparez l’adhésion du plan de contrôle de la santé du plan de stockage.

Décision : Réparez d’abord l’adhésion au cluster si vous avez besoin de la gestion centralisée ; traitez la récupération des OSD Ceph en parallèle si cela affecte l’E/S.

Deuxième blague courte (vous n’en avez que deux) : si votre première impulsion est « réinstaller le nœud », félicitations — vous avez inventé la version IT de redémarrer avec un chariot élévateur.

Listes de contrôle / plan étape par étape : rejoindre correctement, selon ce qui s’est passé

Il n’existe pas une seule procédure de « réintégration ». Il y en a trois, et une seule est sûre pour votre situation. Choisissez en fonction des faits vérifiés ci‑dessus.

Plan 0 : Arrêter et protéger les workloads (toujours faire ceci en premier)

• Identifiez si des VMs/CTs tournent sur le nœud affecté et si elles utilisent un stockage partagé (Ceph, NFS, iSCSI, ZFS partagé).
• Si HA est activé, envisagez de désactiver temporairement les actions HA pour les services impactés pendant que vous stabilisez l’adhésion, afin d’éviter des démarrages en double.
• Si le nœud est isolé mais continue d’exécuter des workloads, traitez‑le comme « standalone dégradé ». N’autorisez pas un autre nœud à démarrer les mêmes workloads.

Plan A : Le nœud est toujours dans l’adhésion du cluster, juste déconnecté (meilleur cas)

À utiliser quand : le quorum du cluster est sain ailleurs ; pvecm nodes liste le nœud ; et l’identité du nœud (nom d’hôte, mappage IP, authkey) n’a pas changé.

1. Corrigez le réseau : VLAN/MTU/bonding, ports de switch, règles de firewall.
2. Corrigez la synchronisation temporelle.
3. Redémarrez Corosync puis pve-cluster sur le nœud affecté, dans cet ordre si Corosync était arrêté.

cr0x@server:~$ systemctl restart corosync
cr0x@server:~$ systemctl restart pve-cluster
cr0x@server:~$ pvecm status
Cluster information
-------------------
Name:             prod-cluster
Config Version:   18
Transport:        knet
Secure auth:      on

Quorum information
------------------
Quorate:          Yes

Sens : Si cela redevient quorate et que l’adhésion revient, vous avez terminé. Validez ensuite le stockage et l’état HA.

Décision : Si Corosync ne démarre pas ou ne peut toujours pas rejoindre, stoppez et passez au Plan B ou C selon ce que vous découvrez.

Plan B : Le nœud doit être ré‑ajouté proprement (courant après réinstallation ou dérive d’identité)

À utiliser quand : le cluster est sain ailleurs, mais l’état du nœud est obsolète, manquant ou non compatible (OS réinstallé, nouvelle authkey, hôte renommé, IP changées).

Étape 1 : Sur un nœud sain, supprimer l’entrée d’adhésion morte (si présente)

cr0x@server:~$ pvecm delnode pve03
Removed node pve03 from cluster

Sens : Cela supprime les métadonnées d’adhésion pour ce nœud. Cela n’efface pas magiquement ses disques, mais modifie l’état du cluster.

Décision : Si la suppression échoue à cause du quorum, ne forcez pas ; restaurez d’abord le quorum.

Étape 2 : Nettoyer la configuration de cluster sur le nœud que vous réintégrez (précisément)

C’est la partie que les gens font en hâte et regrettent ensuite. Vous supprimez l’ancienne identité du nœud local afin qu’il puisse rejoindre comme membre neuf.

cr0x@server:~$ systemctl stop pve-cluster corosync
cr0x@server:~$ rm -f /etc/corosync/corosync.conf
cr0x@server:~$ rm -f /etc/corosync/authkey
cr0x@server:~$ rm -rf /etc/pve/corosync.conf /etc/pve/nodes /etc/pve/.members
cr0x@server:~$ systemctl start pve-cluster

Sens : Vous effacez les fichiers d’identité de cluster locaux. Cela ne doit pas supprimer les disques VM. Cela peut orpheliner des configs VM locales si elles n’étaient présentes que dans /etc/pve et non sauvegardées ailleurs — confirmez donc où résident vos configs VM avant.

Décision : Si le nœud héberge des configs VM uniques et non répliquées dont vous avez besoin, arrêtez‑vous et sauvegardez l’état de /etc/pve avant de supprimer quoi que ce soit.

Étape 3 : Joindre le cluster depuis le nœud que vous ajoutez

cr0x@server:~$ pvecm add 10.10.10.11
Please enter superuser (root) password for '10.10.10.11':
Establishing API connection with host '10.10.10.11'
The authenticity of host '10.10.10.11' can't be established.
Fingerprint: SHA256:0mJ0QwqN7ZpVtJcXxq0b3oYzYl6s9Qx9fYqVQ4oSx2s
Are you sure you want to continue connecting (yes/no)? yes
Successfully added node 'pve03' to cluster.

Sens : Proxmox a copié la bonne config Corosync/matériel d’auth et enregistré le nœud.

Décision : Vérifiez immédiatement l’adhésion et le quorum des deux côtés.

Étape 4 : Vérifier l’état après jonction

cr0x@server:~$ pvecm status | grep -E 'Name:|Quorate:|Nodes:'
Name:             prod-cluster
Nodes:            3
Quorate:          Yes

Sens : Le plan de contrôle est de retour. Validez maintenant les montages de stockage, les configs VM et les tâches de réplication.

Plan C : Split brain ou états de cluster en conflit (la chirurgie délicate)

À utiliser quand : vous suspectez l’existence de deux états de cluster indépendants : par exemple, quelqu’un a exécuté pvecm create sur le nœud isolé, ou a restauré /etc/pve depuis une sauvegarde sur un côté sans coordination.

À quoi cela ressemble en pratique :

• Même nom de cluster, mais IDs de nœud différentes.
• Les nœuds apparaissent en double ou avec des IDs bizarres.
• Les logs Corosync mentionnent des versions de config incompatibles ou des échecs d’authentification persistants même avec le bon réseau.
• /etc/pve/corosync.conf diffère entre les nœuds alors qu’il ne devrait pas.

Approche sûre : choisissez une source de vérité (le côté ayant le quorum et l’état le plus cohérent). Traitez ensuite l’autre côté comme un nœud qui doit être ré‑ajouté (Plan B) après avoir arrêté ou isolé en toute sécurité ses workloads.

Dans les scénarios de split brain, vous devez aussi tenir compte du stockage partagé :

• Si les deux côtés peuvent écrire sur le même datastore, stoppez. Assurez-vous qu’un seul côté est actif sur le stockage partagé.
• Si vous utilisez Ceph, confirmez le quorum des MON et assurez-vous que le nœud isolé ne fait rien « créatif » comme former un second cluster Ceph.
• Si vous utilisez la réplication ZFS, confirmez les GUID des datasets et la direction de réplication avant de réactiver les tâches.

Le Plan C est l’endroit où la gestion des changements justifie son coût. Si vous pouvez planifier une fenêtre d’indisponibilité, faites‑le. Sinon, au moins exigez le silence de tout le monde sauf de la personne au clavier.

Erreurs fréquentes : symptôme → cause racine → correction

1) Symptom: “node not in cluster” after a reboot; other nodes are fine

Cause racine : Corosync n’a pas réussi à se lier à la bonne interface après un changement réseau (changement de nom de bridge, réordonancement d’un bond, VLAN non levé à temps).

Correction : Vérifiez les adresses du ring et la disponibilité des interfaces ; corrigez /etc/network/interfaces ou systemd-networkd ; redémarrez Corosync ; confirmez que les logs montrent l’adhésion.

2) Symptom: /etc/pve is mounted read-only

Cause racine : Pas de quorum (souvent un cluster à deux nœuds avec un nœud en panne) ou le nœud ne voit pas assez de pairs.

Correction : Restaurez le quorum en ramenant des nœuds ou en ajoutant un dispositif de quorum ; ne forcez pas les écritures. Si vous devez fonctionner temporairement en mode nœud unique, faites‑le avec une stratégie de quorum explicite et un plan de réversion.

3) Symptom: Corosync log shows “token has not been received” and knet link flaps

Cause racine : Perte de paquets réseau, mismatch MTU, ou filtrage du firewall UDP entre les pairs du cluster.

Correction : Rendre le MTU cohérent, corriger le switch/VLAN, autoriser le trafic Corosync, éviter de faire transiter le trafic de cluster par des firewalls « intelligents » qui modifient l’état des paquets.

4) Symptom: Node was reinstalled and now can’t join; authentication errors

Cause racine : La nouvelle installation a une authkey Corosync différente et possiblement un nom d’hôte/clé SSH différente. C’est un nœud différent, même si le matériel est le même.

Correction : Supprimez l’ancienne entrée de nœud du cluster, nettoyez l’identité du nouveau système, et rajoutez‑le avec pvecm add.

5) Symptom: Cluster shows duplicate nodes or strange IDs

Cause racine : Split brain ou copie manuelle de fichiers dans /etc/pve ; bases d’adhésion en conflit.

Correction : Choisissez un cluster source de vérité et réajoutez les autres proprement. Ne fusionnez pas à la main sauf si vous aimez l’archéologie.

6) Symptom: GUI shows cluster but CLI says not quorate (or vice versa)

Cause racine : Cache UI obsolète, montage partiel de pmxcfs, ou services redémarrés dans un mauvais ordre.

Correction : Faites confiance à la CLI (pvecm status, journalctl). Redémarrez les services dans un ordre contrôlé ; confirmez le montage et l’état lecture/écriture de /etc/pve.

7) Symptom: Everything worked until someone “optimized” the cluster network

Cause racine : Jumbo frames activés sur certains ports seulement ; modification du hashing LACP ; paramètres d’offload modifiés ; ou réseau de cluster déplacé derrière un appliance firewall.

Correction : Rendez le réseau de cluster ennuyeux : MTU cohérent, minimum d’équipements intermédiaires, latence stable. Mettez l’astuce ailleurs.

Trois mini‑histoires du monde entreprise (anonymisées, plausibles et douloureusement familières)

Mini‑histoire 1 : L’incident causé par une mauvaise hypothèse

Ils avaient un cluster Proxmox à trois nœuds dans un bureau régional, exécutant un mélange de VMs Windows et quelques appliances Linux. Un jour, un nœud est devenu muet. La régie a dit que c’était « juste un cycle d’alimentation ». L’administrateur junior a supposé que le nœud se réintégrerait après le démarrage.

Il a démarré, mais Proxmox affichait « node not in cluster ». L’admin a fait ce que beaucoup font sous pression : il a copié /etc/pve/corosync.conf depuis un nœud sain vers le nœud cassé et a redémarré les services. Ça a semblé mieux pendant environ cinq minutes. Puis Corosync a commencé à flapper.

L’hypothèse erronée était subtile : ils croyaient que /etc/pve était un système de fichiers normal. Ce n’était pas le cas. Leur copie est arrivée dans un endroit géré par pmxcfs, et l’état pmxcfs du nœud n’était pas encore sain. Ils ont en gros épinglé une configuration sur une cible en mouvement.

Ce qui a réparé la situation était ennuyeusement banal : ils ont annulé la copie manuelle, vérifié le réseau du ring, et découvert que le port du switch avait été déplacé vers un VLAN différent lors de travaux sans rapport. Une fois le VLAN corrigé et la synchronisation du temps confirmée, le nœud s’est réintégré sans chirurgie d’adhésion.

Le postmortem était clair : traitez « node not in cluster » d’abord comme un problème de connectivité et de quorum, pas comme un problème de fichiers. Un cluster est un système, pas un dossier.

Mini‑histoire 2 : L’optimisation qui a mal tourné

Une entreprise de taille moyenne a décidé que leur réseau de cluster Proxmox devait être « rapide ». Quelqu’un a activé MTU 9000 sur le VLAN de stockage et s’est dit, pourquoi ne pas le mettre aussi sur le ring Corosync. La moitié des switches supportaient les jumbo frames bout en bout, l’autre moitié « à peu près », et quelques NIC anciennes nécessitaient des ajustements de pilote.

Rien n’a explosé immédiatement. C’est comme ça que ces histoires commencent. Au bout de quelques semaines, il y a eu des changements intermittents d’adhésion au cluster. Courts. Un nœud tombait, revenait, retombait. Le HA hésitait. Les logs parlaient de tokens manquants. Tout le monde accusait « Proxmox instable ».

L’échec était que le pattern de trafic de Corosync ne se soucie pas de votre bande passante théorique ; il se soucie de la prévisibilité. L’inconsistance des jumbo frames a introduit des micro‑paquets et des drops occasionnels que le trafic applicatif ordinaire n’a pas remarqués. Corosync l’a remarqué. Bruyamment.

Ils ont résolu le problème en remettant le réseau Corosync à MTU 1500 et en laissant les jumbo frames uniquement là où ils pouvaient garantir le support bout en bout (et où cela apportait un gain mesurable). Le cluster est redevenu ennuyeux. La performance a à peine changé. La disponibilité, si.

Mini‑histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la situation

Une autre organisation exploitait un cluster Proxmox à cinq nœuds avec Ceph et un contrôle de changement strict. Chaque modification du réseau incluait une checklist pré‑vol : confirmer la résolution de noms, confirmer la synchronisation NTP, confirmer l’accessibilité du ring Corosync, confirmer pvecm status quorate, et enregistrer la version courante de corosync.conf.

Un après‑midi, un reboot de switch a causé une courte panne du réseau de cluster. Un nœud est revenu avec « node not in cluster ». L’équipe n’a pas improvisé. Ils ont sorti la checklist.

Ils ont immédiatement vu que la synchronisation temporelle du nœud affecté était cassée : NTP était bloqué car la route par défaut du nœud avait changé au boot et il ne pouvait plus atteindre les serveurs NTP. L’horloge du nœud a dérivé suffisamment pour que l’authentification Corosync et les timeouts déraillent. La correction du routage et de NTP a restauré l’adhésion proprement.

Personne n’a « réintégré » quoi que ce soit. Personne n’a supprimé l’état du cluster. Personne n’a copié des fichiers autour. La meilleure réponse à un incident est parfois de refuser la panique et d’avoir les preuves pour prouver ce qui a changé.

FAQ

1) Does “node not in cluster” mean my VMs are gone?

Non. Cela signifie que le plan de contrôle ne peut pas valider l’état du cluster. Les disques VM sont typiquement sur un stockage local, partagé ou Ceph ; ils n’évaporent pas parce que Corosync est mécontent. Mais les configs VM stockées dans /etc/pve peuvent ne pas être visibles si pmxcfs n’est pas monté.

2) Can I just run pvecm add and move on?

Seulement si vous êtes sûr que le nœud a été proprement supprimé ou qu’il s’agit d’une installation neuve que vous voulez ajouter. Si le cluster croit encore que le nœud existe, rejoindre sans nettoyage peut créer des conflits. Vérifiez avec pvecm nodes depuis un nœud sain d’abord.

3) What’s the safest first action when this happens?

Vérifiez le quorum et le statut Corosync depuis un nœud sain. Si le cluster est quorate, votre problème est localisé. Sinon, réparez le quorum avant de faire quoi que ce soit de destructeur.

4) Why does /etc/pve sometimes go read-only?

Parce que Proxmox refuse d’accepter des écritures quand l’adhésion au cluster n’est pas digne de confiance (souvent à cause d’une perte de quorum). Cela évite le split brain et la divergence de configuration.

5) How do I handle this in a two-node cluster?

Soit ajoutez un troisième votant (qdevice), soit acceptez que la perte d’un nœud entraîne probablement la perte du quorum. Les clusters à deux nœuds peuvent fonctionner, mais vous devez concevoir en tenant compte des mathématiques du quorum plutôt que de discuter pendant un incident.

6) Is it safe to copy corosync.conf from another node?

Généralement non. Si pmxcfs est sain et que le cluster est sain, la config est déjà répliquée. Si pmxcfs n’est pas sain, copier des fichiers peut aggraver la divergence. Utilisez pvecm add pour une distribution contrôlée après nettoyage si nécessaire.

7) After rejoin, why are my storages missing in the UI?

Parce que les définitions de stockage sont dans la config du cluster (/etc/pve/storage.cfg). Si pmxcfs n’est pas monté ou si vous avez rejoint de façon incorrecte, le nœud peut ne pas avoir la configuration répliquée. Vérifiez le montage de /etc/pve et comparez storage.cfg entre les nœuds.

8) Does Ceph complicate rejoining a Proxmox node?

Ceph complique le rayon d’impact, pas la mécanique de réintégration de base. L’adhésion Proxmox est un système, Ceph un autre. Vous devez vous assurer que le nœud ne provoque pas de double‑montage ou de confusion d’OSD, mais vous réparez d’abord Corosync/quorum.

9) What if the node was renamed and I want to keep the new name?

Ne renommez pas sur place en espérant que le cluster suive. Supprimez le nœud du cluster, nettoyez son état de cluster, définissez le nouveau nom d’hôte de façon cohérente partout, puis rajoutez‑le comme membre neuf. Planifiez l’impact sur les configs VM et la supervision.

10) When is reinstalling actually the right move?

Quand le système est compromis, irrémédiablement mal configuré, ou que vous ne pouvez pas faire confiance à l’état du nœud — et que vous avez un processus propre pour retirer/rajouter des nœuds. Réinstaller en premier réflexe est généralement de l’impatience déguisée en décision.

Prochaines étapes à exécuter réellement

Si vous gérez un ticket d’incident maintenant, faites ceci dans l’ordre :

1. Établir l’état du quorum depuis un nœud sain avec pvecm status. Si non quorate, réparez le quorum avant de « réintégrer ».
2. Sur le nœud cassé : confirmez le nom d’hôte, la résolution de noms, la synchronisation temporelle, et que /etc/pve est monté.
3. Lire les logs Corosync. Ils ne sont pas poétiques, mais généralement honnêtes.
4. Corriger les problèmes réseau ennuyeux : mismatch MTU, tagging VLAN, drop firewall, changements de nom d’interface.
5. Choisir le plan de récupération adéquat :
   • Plan A si l’identité est intacte et que le nœud est encore listé.
   • Plan B si l’identité est obsolète (réinstallation/renommage/nouvelle clé).
   • Plan C si split brain est suspecté — choisissez une source de vérité et ré‑ajoutez proprement.
6. Après récupération : validez le stockage, l’état HA et les tâches de réplication. Ne déclarez pas victoire tant que les vérifications ennuyeuses n’ont pas été faites.

Puis faites une faveur à votre futur vous :

• Documentez le réseau du cluster (interfaces, VLANs, MTU, zones de firewall) et rendez‑le volontairement terne.
• Si vous exploitez deux nœuds, ajoutez un dispositif de quorum ou acceptez explicitement les contraintes opérationnelles.
• Pratiquez la procédure de suppression/rajout dans un labo au préalable. Les incidents sont un mauvais moment pour découvrir ce qu’est pmxcfs.