Proxmox « Impossible de supprimer le nœud » : suppression sûre d’un nœud d’un cluster

Le modèle mental : ce que signifie vraiment « supprimer un nœud »

Dans Proxmox VE, « supprimer un nœud » n’est pas une seule action. C’est au moins quatre choses différentes qui partagent une même étiquette :
l’adhésion au cluster, l’état du système de fichiers du cluster, les attentes au niveau des services (gestion HA, ordonnancement, plugins de stockage),
et les charges de travail qui étaient liées à ce nœud (VMs, conteneurs, démons de stockage).

Le cœur, c’est l’adhésion Corosync plus la base de données de configuration du cluster de Proxmox (pmxcfs) distribuée sous
/etc/pve. Quand vous exécutez pvecm delnode, vous dites au cluster restant :
« Arrêtez d’attendre que ce nœud participe aux décisions de quorum, et supprimez sa présence de configuration de l’état partagé. »
Si vous n’avez pas le quorum, ou si les nœuds restants ne sont pas d’accord sur l’état partagé, vous n’obtenez pas une suppression propre — parce que
les clusters sont allergiques aux modifications unilatérales. Et ce, pour de bonnes raisons.

La règle est simple mais agaçante : les changements d’adhésion exigent un cluster sain.
Quand le cluster n’est pas sain, arrêtez d’être malin et faites de la chirurgie contrôlée :
stabilisez le quorum, figez les modifications, puis supprimez le nœud. Si vous ne stabilisez pas d’abord, vous pouvez fabriquer un split brain
qui semble correct dans l’UI jusqu’à ce qu’il ne le soit plus. Et « jusqu’à ce qu’il ne le soit plus » survient généralement lors d’un reboot d’hôte.

Il y a aussi une différence entre « le nœud est hors ligne » et « le nœud est parti ». Hors ligne signifie qu’il pourrait revenir avec d’anciennes configurations.
Parti signifie que vous devez supposer qu’il ne revient jamais, et vous devez empêcher tout retour inattendu. C’est pourquoi la suppression sûre
inclut : le couper complètement, effacer les configs de cluster dessus, ou au minimum l’isoler du réseau.

Guide de diagnostic rapide

Quand « impossible de supprimer le nœud » arrive, le temps perdu n’est pas à taper des commandes. C’est à deviner quel sous-système vous bloque.
Voici la voie rapide vers le goulot d’étranglement.

1) Quorum et adhésion d’abord (toujours)

• Vérifiez pvecm status. Si vous n’avez pas de quorum, vous ne supprimez rien proprement.
• Consultez journalctl -u corosync pour les variations d’adhésion, timeouts de token, ou « not in quorum ».
• Vérifiez si le nœud que vous voulez retirer apparaît encore dans les « Expected votes » du cluster.

2) Système de fichiers du cluster (pmxcfs) ensuite

• Confirmez que pve-cluster est sain sur les nœuds restants.
• Vérifiez si /etc/pve répond ; des montages FUSE bloqués rendent chaque commande de gestion hantée.
• Recherchez des fichiers de verrou obsolètes (rare) ou un nœud bloqué avec des versions de config dépassées.

3) Charges de travail et HA ensuite

• Si HA est activé, confirmez que le nœud n’est plus référencé par des groupes ou ressources HA.
• Confirmez qu’aucune config VM/CT ne référence encore le stockage local du nœud comme emplacement principal.
• Si Ceph existe, assurez-vous de ne pas confondre « retirer un nœud Proxmox » avec « retirer un hôte Ceph ». Ils sont liés, pas identiques.

4) Puis effectuez la suppression

• Exécutez pvecm delnode depuis un nœud restant sain.
• Validez que corosync.conf et la liste des nœuds sont répliqués sous /etc/pve.
• Ce n’est qu’après cela que vous nettoyez le nœud supprimé pour éviter qu’il ne rejoigne accidentellement.

Faits et contexte intéressants (pourquoi Proxmox se comporte ainsi)

• Corosync vient du monde Linux HA, conçu pour coordonner l’adhésion dans des clusters où la correction prime sur la commodité.
• Le quorum est une fonction de sécurité, pas de performance : il évite d’avoir « deux clusters en un » (split brain) qui effectuent des changements concomitants.
• Proxmox stocke la configuration du cluster dans un système de fichiers distribué (pmxcfs) monté sur /etc/pve, d’où l’impact global des modifications.
• Historiquement, les incidents de split brain ont façonné les outils de cluster : de nombreux comportements stricts sont des cicatrices d’anciennes piles HA où le « best effort » corrompait l’état.
• Les clusters à deux nœuds sont intrinsèquement gênants car la majorité est fragile ; il faut généralement un bris d’égalité (qdevice) ou accepter le risque d’indisponibilité.
• Les votes comptent : le quorum Corosync se base sur les votes ; des « expected votes » incluant des nœuds morts peuvent laisser un cluster sans quorum.
• Le gestionnaire HA de Proxmox est tranché : il préférera isoler ou arrêter des charges de travail plutôt que d’autoriser un état incertain, énervant jusqu’au moment où cela vous sauve.
• L’adhésion Ceph est distincte de l’adhésion Proxmox : retirer un nœud Proxmox ne supprime pas automatiquement les OSDs/moniteurs Ceph, et mélanger ces étapes à l’aveugle est une recette classique de panne.
• Les changements de cluster sont sérialisés via le quorum : si vous ne pouvez pas obtenir de consensus, Proxmox préfère refuser l’opération plutôt que de deviner.

Avant d’y toucher : règles de sécurité

Définir le type de suppression : planifiée vs non planifiée

Suppression planifiée : le nœud est joignable, vous pouvez migrer les charges, vous pouvez arrêter les services de cluster proprement.
Suppression non planifiée : le nœud est mort, le disque est HS, ou il est en boucle de redémarrage et vous avez fini de négocier.
Les étapes se recoupent, mais les décisions diffèrent : la suppression planifiée optimise la migration propre ; la suppression non planifiée optimise la restauration du quorum
et l’empêchement du retour du cadavre dans la conversation.

Assurez-vous de ne pas supprimer votre seule copie de quoi que ce soit

Le stockage local est le piège. Si vous avez utilisé ZFS local, LVM-Thin local, ou un stockage de répertoire et jamais répliqué, alors « supprimer le nœud »
peut signifier « supprimer le seul endroit où ces disques existaient ». L’adhésion au cluster est facile. Les données, c’est difficile.

Règles opérationnelles (écrivez-les sur un post-it)

• Une personne pilote. Tout le monde observe. Les changements d’adhésion au cluster ne sont pas un exercice collaboratif de saisie.
• Geler les autres modifications : pas de mises à jour, pas de refonte réseau, pas de déplacements de stockage pendant l’opération.
• Maintenez le nœud supprimé hors tension (ou isolé) jusqu’à nettoyage. « Oups il est revenu » n’est pas un type d’incident agréable.
• Connaissez la taille de votre cluster : les modes de défaillance diffèrent pour 2 et 3 nœuds.

Une citation que les opérationnels apprennent à la dure :
« L’espoir n’est pas une stratégie. » — Gen. Gordon R. Sullivan

Blague n°1 : Un cluster, c’est comme un groupe de discussion — retirer quelqu’un est facile jusqu’à ce que vous réalisiez qu’il était le seul à connaître le mot de passe.

Tâches pratiques (commandes, sorties, décisions)

Voici les vérifications et actions qui font vraiment avancer le travail. Chaque tâche inclut une commande exécutable, ce que la sortie signifie,
et la décision à prendre. Les commandes supposent que vous êtes root ou utilisez sudo ; l’invite ci-dessous est un exemple.

Task 1 — Confirmer le quorum du cluster et les expected votes

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

Quorum information
------------------
Date:             Fri Dec 26 13:10:43 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.2f
Quorate:          Yes

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

Signification : « Quorate: Yes » signifie que les changements de cluster sont autorisés. « Expected votes » doit correspondre au nombre de nœuds que vous comptez avoir.
Décision : Si non quorate, arrêtez ici et réparez le quorum (voir Tâches 2–4). Si quorate, continuez avec les étapes de suppression planifiée.

Task 2 — Lister les nœuds connus du cluster

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

Signification : C’est l’adhésion au cluster telle que vue par Corosync.
Décision : Si le nœud mort apparaît encore et que vous voulez le supprimer, vous le retirerez avec pvecm delnode <name> depuis un nœud sain.

Task 3 — Vérifier la santé du service Corosync sur les nœuds restants

cr0x@server:~$ systemctl status corosync --no-pager
● corosync.service - Corosync Cluster Engine
     Loaded: loaded (/lib/systemd/system/corosync.service; enabled; preset: enabled)
     Active: active (running) since Fri 2025-12-26 10:02:11 UTC; 3h 8min ago
       Docs: man:corosync
   Main PID: 1320 (corosync)
      Tasks: 11
     Memory: 38.4M
        CPU: 2.112s
     CGroup: /system.slice/corosync.service
             └─1320 /usr/sbin/corosync -f

Signification : Corosync est en cours d’exécution. S’il oscille, vous avez un problème d’adhésion, pas un problème « supprimer le nœud ».
Décision : Si non actif, corrigez le réseau/les timeouts/le pare-feu hôte avant d’essayer la suppression.

Task 4 — Lire les logs Corosync pour perte de quorum ou problèmes d’anneau

cr0x@server:~$ journalctl -u corosync -n 50 --no-pager
Dec 26 13:02:18 pve01 corosync[1320]:   [KNET  ] link: host: 2 link: 0 is up
Dec 26 13:02:19 pve01 corosync[1320]:   [QUORUM] Members[2]: 1 2
Dec 26 13:02:19 pve01 corosync[1320]:   [QUORUM] This node is within the primary component and will provide service.
Dec 26 13:05:31 pve01 corosync[1320]:   [TOTEM ] Token has not been received in 3000 ms
Dec 26 13:05:31 pve01 corosync[1320]:   [TOTEM ] A processor failed, forming new configuration.
Dec 26 13:05:33 pve01 corosync[1320]:   [QUORUM] Members[3]: 1 2 3

Signification : « Token has not been received » indique du jitter réseau, un MTU inadapté, ou un hôte surchargé.
Décision : Si vous voyez des reconfigurations fréquentes, reportez la suppression et stabilisez d’abord le réseau du cluster. Supprimer un nœud pendant des oscillations, c’est se garantir du travail le week-end.

Task 5 — Confirmer que pmxcfs (/etc/pve) répond

cr0x@server:~$ pvesh get /cluster/status
[
  {
    "id":"cluster",
    "name":"prod-pve",
    "quorate":1,
    "version":27
  },
  {
    "id":"node/pve01",
    "ip":"10.10.10.11",
    "local":1,
    "name":"pve01",
    "online":1,
    "type":"node"
  },
  {
    "id":"node/pve02",
    "ip":"10.10.10.12",
    "local":0,
    "name":"pve02",
    "online":1,
    "type":"node"
  }
]

Signification : L’API lit le statut du cluster rapidement ; pmxcfs est probablement OK.
Décision : Si cette commande bloque ou renvoie une erreur, vous avez possiblement un problème pmxcfs ; adressez le service pve-cluster et le quorum avant toute autre action.

Task 6 — Vérifier les références HA au nœud

cr0x@server:~$ ha-manager status
quorum OK
master pve01 (active, Fri Dec 26 13:12:19 2025)
lrm pve01 (active, Fri Dec 26 13:12:19 2025)
lrm pve02 (active, Fri Dec 26 13:12:17 2025)
service vm:101 (started)
service vm:203 (started)

Signification : HA est activé ; il y a des LRMs (local resource managers) pour chaque nœud.
Décision : Si le nœud supprimé est toujours listé comme LRM et qu’il est mort, la suppression devrait le nettoyer. Si des services sont épinglés sur ce nœud, migrez-les ou désactivez HA pour ces ressources d’abord.

Task 7 — Trouver les VMs/CT encore configurés sur le nœud à supprimer

cr0x@server:~$ pvesh get /nodes/pve03/qemu --output-format yaml
- vmid: 310
  name: build-runner-03
  status: stopped
- vmid: 311
  name: legacy-db-test
  status: running

Signification : Le nœud cible a encore des VMs définies. Même si elles sont sur un stockage partagé, leur association de configuration compte.
Décision : Migrez ou déplacez ces invités. Si le nœud est mort, vérifiez où résident leurs disques avant de « supprimer le nœud » en supposant qu’ils apparaîtront ailleurs magiquement.

Task 8 — Vérifier les dépendances de stockage (quelque chose est-il node-local ?)

cr0x@server:~$ pvesm status
Name             Type     Status           Total        Used       Avail
local            dir      active        19632040     3921040    14750212
local-zfs        zfspool  active        247463936   90218496   157245440
ceph-rbd         rbd      active       104857600    52428800    52428800
nfs-backup       nfs      active       209715200    73400320   136314880

Signification : « local-zfs » est local au nœud sauf si vous avez mis en place quelque chose de partagé (rare). « ceph-rbd » et NFS sont partagés.
Décision : Si des charges dépendent d’un stockage local, répliquez ou déplacez les disques avant la suppression. Si le nœud est déjà mort et que les disques étaient locaux, votre tâche devient « restaurer depuis les sauvegardes ».

Task 9 — Vérifier les jobs de réplication (si vous utilisez la réplication ZFS)

cr0x@server:~$ pvesh get /cluster/replication
[
  {
    "id":"101-0",
    "source":"pve03",
    "target":"pve01",
    "schedule":"*/15",
    "last_sync":1735218600,
    "duration":42,
    "comment":"critical VM replication"
  }
]

Signification : Il existe une réplication avec un timestamp de dernier sync.
Décision : Si le nœud est joignable, forcez une dernière synchronisation avant le décommissionnement. S’il est injoignable, confirmez que la cible a une réplique récente et que vous connaissez les étapes de promotion.

Task 10 — Suppression planifiée : migrer les invités hors du nœud

cr0x@server:~$ qm migrate 311 pve01 --online
migration started
migration status: active
migration status: completed

Signification : La VM a été déplacée avec succès.
Décision : Répétez jusqu’à ce que le nœud n’héberge plus d’invités en cours d’exécution. Si les migrations échouent à cause du stockage, faites une pause et corrigez cela — n’improvisez pas avec des disques à moitié migrés.

Task 11 — Retirer le nœud du cluster (la suppression réelle)

cr0x@server:~$ pvecm delnode pve03
Removing node 'pve03' from the cluster
Stopping pve-cluster on removed node if reachable...
Updating corosync config
Waiting for quorum...

Signification : Le cluster met à jour l’adhésion et synchronise la configuration.
Décision : Si cela se termine, validez les Tâches 12–13. Si cela échoue avec des plaintes de quorum, vous devez restaurer le quorum d’abord — ne persistez pas à réessayer comme si c’était un téléchargement instable.

Task 12 — Confirmer que le nœud a disparu de l’adhésion et que les expected votes sont mis à jour

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

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

Votequorum information
----------------------
Expected votes:   2
Total votes:      2
Quorum:           2
Flags:            Quorate

Signification : Le cluster attend maintenant 2 votes. C’est correct pour un cluster à 2 nœuds, mais c’est aussi un signal d’alerte.
Décision : Si vous vous retrouvez avec 2 nœuds, décidez immédiatement si vous ajoutez un troisième nœud ou un qdevice. Deux nœuds sans bris d’égalité sont un pari sur la fiabilité.

Task 13 — Confirmer qu’aucun répertoire de nœud obsolète ne reste dans /etc/pve/nodes

cr0x@server:~$ ls -1 /etc/pve/nodes
pve01
pve02

Signification : La configuration partagée ne suit plus le nœud supprimé.
Décision : Si le répertoire du nœud supprimé persiste, pmxcfs peut être bloqué ou le quorum n’a jamais été réel. Revérifiez les Tâches 1–5 et évitez la suppression manuelle sauf si vous êtes en récupération contrôlée.

Task 14 — Confirmer que le nœud supprimé n’apparaît plus dans corosync.conf (depuis un nœud restant)

cr0x@server:~$ grep -R "pve03" -n /etc/pve/corosync.conf || echo "no references"
no references

Signification : La configuration Corosync est propre.
Décision : Si des références subsistent, vous ne l’avez pas réellement supprimé, ou vous avez des problèmes de propagation de config. Corrigez pmxcfs/quorum, puis réessayez.

Task 15 — Nettoyage sur le nœud supprimé (s’il est encore joignable)

cr0x@server:~$ systemctl stop pve-cluster corosync
cr0x@server:~$ rm -f /etc/pve/corosync.conf
cr0x@server:~$ rm -f /etc/corosync/authkey
cr0x@server:~$ rm -f /var/lib/corosync/*
cr0x@server:~$ systemctl disable corosync pve-cluster
Removed "/etc/systemd/system/multi-user.target.wants/corosync.service".
Removed "/etc/systemd/system/multi-user.target.wants/pve-cluster.service".

Signification : Le nœud ne rejoindra pas le cluster par accident avec des identifiants obsolètes.
Décision : Faites cela avant de réaffecter l’hôte. Si vous l’ignorez, le nœud peut revenir plus tard et embrouiller le cluster comme un ancien employé dont le badge fonctionne encore.

Task 16 — Si la suppression échoue pour cause de « not quorate » : identifier les nœuds restants qui sont d’accord

cr0x@server:~$ corosync-quorumtool -s
Quorum information
------------------
Date:             Fri Dec 26 13:18:22 2025
Quorum provider:  corosync_votequorum
Nodes:            2
Node ID:          0x00000001
Ring ID:          1.30
Quorate:          No

Votequorum information
----------------------
Expected votes:   3
Total votes:      2
Quorum:           2

Signification : Vous avez deux nœuds en ligne, mais expected votes est toujours 3, donc vous n’êtes pas quorate.
Décision : Votre correction immédiate est de restaurer le quorum (ramener le troisième, ou utiliser un qdevice si c’était votre conception). Seulement en cas d’urgence, vous pouvez ajuster temporairement les expected votes pour retrouver le quorum en vue d’opérations de récupération — voir la section étape par étape pour les garde-fous.

Blague n°2 : La façon la plus rapide d’apprendre l’arithmétique du quorum est de la casser une fois, de préférence en laboratoire et pas pendant la paie.

Listes de contrôle / plan étape par étape

Plan A : Décommission planifié (le nœud est joignable)

1. Annoncer une fenêtre de changement. Gardez-la courte, mais ne faites pas cela pendant une maintenance réseau sur les mêmes commutateurs.
2. Vérifier la santé du cluster et le quorum depuis un nœud restant.
   Utilisez les Tâches 1–5. Si quelque chose oscille, arrêtez et corrigez la stabilité d’abord.
3. Drainer le nœud.
   • Migrer ou arrêter les VMs/CTs (Tâche 10, plus l’équivalent CT pct migrate si besoin).
   • Désactiver les attentes d’ordonnancement : si vous avez HA, confirmez que les ressources ne sont pas épinglées au nœud (Tâche 6).
4. Vérifier les dépendances de stockage.
   Utilisez la Tâche 8. Si du stockage local est impliqué, répliquez ou déplacez les disques d’abord (Tâche 9).
5. Lancer la suppression depuis un nœud restant sain : Tâche 11.
6. Valider la suppression : Tâches 12–14.
7. Nettoyer le nœud supprimé : Tâche 15.
8. Rééquilibrer et durcir.
   Si vous êtes réduit à deux nœuds, décidez : ajoutez un troisième ou ajoutez un qdevice. Ne « laissez pas pour plus tard » sauf si le plus tard est déjà planifié.

Plan B : Perte non planifiée (nœud mort ou injoignable)

1. Isoler physiquement ou logiquement le nœud mort.
   S’il oscille sur le réseau, il peut perturber Corosync. Coupez sa NIC, désactivez le port de commutateur, ou gardez-le hors tension.
2. Stabiliser le quorum sur les nœuds survivants.
   Utilisez la Tâche 1 et la Tâche 4. Si non quorate, votre priorité est la restauration du quorum, pas l’esthétique du nettoyage.
3. Confirmer les charges et l’emplacement des données du nœud mort.
   Utilisez les Tâches 7 et 8 depuis les nœuds survivants. Décidez :
   • Si les disques sont sur stockage partagé (Ceph/NFS/iSCSI), vous pouvez redémarrer les invités ailleurs.
   • Si les disques étaient uniquement locaux, passez en mode restauration : sauvegardes, répliques, ou reconstruction.
4. Ne supprimer le nœud que lorsque vous êtes quorate.
   Tâche 11. Si le cluster refuse à cause du quorum, n’effectuez pas d’éditions aléatoires dans /etc/pve sauf si vous entrez délibérément en récupération.
5. Après suppression, confirmer l’adhésion et l’état de config propres.
   Tâches 12–14.

Plan C : Récupération d’urgence quand le quorum est impossible (à utiliser avec parcimonie)

Parfois vous avez un cluster à 3 nœuds, vous en perdez 2, et la direction veut « que le dernier nœud up » serve les charges.
Ce n’est pas le mode cluster. C’est le mode survie. Vous pouvez le faire, mais traitez-le comme une alimentation d’urgence : bruyant, malodorant, temporaire.

Le conseil sûr : restaurer suffisamment de nœuds pour retrouver le quorum ou utiliser un dispositif de quorum approprié si votre environnement le permet.
Si vous devez absolument procéder avec un seul nœud restant, vous choisissez d’outrepasser le mécanisme de sécurité qui empêche le split brain.
Faites ce choix explicitement, notez-le, et planifiez un nettoyage pour revenir à un état supporté.

Si vous devez temporairement forcer les expected votes pour des opérations de récupération (pas pour des « opérations normales »), faites-le en connaissance de cause :

cr0x@server:~$ pvecm expected 1
Setting expected votes to 1
WARNING: forcing expected votes can lead to split-brain if other nodes are active

Signification : Vous indiquez à Corosync d’accepter un seul nœud comme quorate.
Décision : Ne le faites que lorsque vous êtes certain que les autres nœuds ne font pas simultanément des modifications (mettez-les hors tension / isolez-les). Une fois que vous récupérez des nœuds, revenez aux expected votes normaux en laissant l’adhésion se normaliser (ou faites réintégrer proprement les nœuds).

Trois mini-récits d’entreprise du terrain

Incident causé par une mauvaise hypothèse : « hors ligne veut dire sûr à supprimer »

Une entreprise de taille moyenne exécutait un cluster Proxmox à trois nœuds pour des services internes. Un nœud a commencé à afficher des erreurs ECC.
Il était encore joignable, mais redémarrait de façon imprévisible. L’ingénieur d’astreinte a fait une hypothèse raisonnable :
« S’il est hors ligne dans l’UI, le supprimer n’est qu’un nettoyage. »

Ils ont lancé pvecm delnode alors que Corosync connaissait déjà des timeouts de token intermittents.
Le cluster était techniquement quorate au moment de la commande. Dix minutes plus tard, le nœud instable est revenu,
a rejoint brièvement avec un état ancien, puis est retombé. Les nœuds restants se sont retrouvés en désaccord sur l’adhésion suffisamment longtemps pour que pmxcfs
commence à prendre du retard, et une opération de démarrage de VM routinière a stagné.

Le mode de défaillance n’était pas spectaculaire. Il était pire : une lente dégradation. L’UI a commencé à expirer, puis les appels API ont bloqué, et finalement
l’équipe a dû planifier une maintenance d’urgence pour stabiliser Corosync. Le retour du nœud supprimé n’a pas ressuscité les charges ; il a seulement créé un
désaccord sur qui était autorisé à modifier la configuration partagée.

La correction post-incident était ennuyeuse : isoler le nœud d’abord (port de commutateur désactivé), puis refaire la suppression pendant que le cluster était stable.
Ils ont aussi adopté une politique : « Si un nœud est instable, traitez-le comme malveillant jusqu’à quarantaine complète. »

Optimisation qui s’est retournée contre eux : « On va faire un cluster à 2 nœuds un moment »

Une autre organisation subissait des contraintes budgétaires et un manque d’espace en baie. Ils ont décidé de retirer temporairement un nœud Proxmox,
faire tourner le cluster à deux nœuds pendant un trimestre, puis ajouter de la capacité plus tard. Sur le papier, tout semblait correct :
la plupart du stockage était sur iSCSI partagé, et les VMs étaient légères.

Ils ont retiré le nœud proprement. Le quorum affichait encore « Yes », car les expected votes correspondaient aux deux nœuds.
Et au quotidien ça fonctionnait — jusqu’au premier incident réseau réel.
Un commutateur top-of-rack a rebooté et les deux nœuds ont perdu la connectivité Corosync assez longtemps pour que chacun
se considère en difficulté. HA est devenu conservateur. Certains services ont basculé, d’autres ont arrêté, et quelques-uns sont restés « unknown ».

Le problème n’était pas que les clusters à deux nœuds ne fonctionnent jamais. C’est qu’ils fonctionnent jusqu’au moment où ils ne fonctionnent plus, et là
vous découvrez que vous avez basé votre modèle de fiabilité sur un pile ou face. Sans un troisième vote (qdevice ou troisième nœud),
une partition peut transformer la gestion en arrêt complet.

L’« optimisation » a été annulée : ils ont ajouté un dispositif de quorum léger sur un domaine de défaillance séparé.
Après cela, la maintenance de routine des nœuds n’a plus été un projet dramatique. La leçon n’était pas « ne jamais exécuter deux nœuds ».
C’était « ne prétendez pas que deux nœuds se comportent comme trois ».

Pratique ennuyeuse mais correcte qui a sauvé la mise : « runbook de décommission + nettoyage »

Une équipe en lien avec les finances (c’est-à-dire : tout est audité et personne n’a le droit de s’amuser) avait une checklist stricte de décommissionnement.
Chaque suppression de nœud exigeait : drainage des charges, vérification des dépendances de stockage, mise en quarantaine explicite, et étape de nettoyage sur le nœud supprimé.
C’était lent. Les gens se plaignaient. Bien sûr qu’ils le faisaient.

Puis un nœud retiré a été réutilisé par un autre groupe. Ils ont réinstallé l’OS, l’ont reconnecté au même réseau de gestion,
et l’ont mis sous tension. Cela aurait été un incident classique de « nœud zombie réapparaît » — sauf que les identifiants de cluster et
l’état Corosync avaient été effacés pendant le décommissionnement initial.

Le nœud est revenu comme un hôte Debian ordinaire sans identité de cluster. Rien n’a tenté de rejoindre. Aucun vote n’a changé.
Le cluster n’a même pas remarqué. Le bruit le plus fort a été quelqu’un réalisant que la checklist avait une raison d’être.

Le salut n’était pas une ingénierie brillante. C’était l’habitude opérationnelle la plus peu sexy : nettoyer après soi pour que le futur-vous
n’ait pas à rétroconcevoir votre intention à partir d’une machine à moitié configurée.

Erreurs courantes : symptôme → cause → correction

1) Symptom: pvecm delnode échoue avec « cluster not ready » ou « not quorate »

Cause racine : Pas de quorum (expected votes inclut toujours le nœud manquant, ou instabilité de l’anneau Corosync).

Correction : Restaurer le quorum (ramener les nœuds, stabiliser le réseau). Si urgence seulement, forcer temporairement les expected votes (Plan C),
mais isolez tous les autres nœuds d’abord pour éviter le split brain.

2) Symptom: Le nœud disparaît de pvecm nodes mais apparaît toujours dans l’UI / /etc/pve/nodes

Cause racine : Délai de réplication pmxcfs, pve-cluster bloqué, ou un nœud qui n’est pas réellement quorate.

Correction : Vérifiez le service pve-cluster, confirmez la réactivité de l’API (Tâche 5), confirmez le quorum (Tâche 1),
puis relancez la suppression. Évitez la suppression manuelle dans /etc/pve sauf si vous êtes en récupération contrôlée.

3) Symptom: Après suppression, le cluster devient fragile et les actions de gestion bloquent lors de petits incidents réseau

Cause racine : Vous avez maintenant un cluster à 2 nœuds sans bris d’égalité, ou un design réseau qui ne tolère pas les partitions.

Correction : Ajoutez un troisième nœud ou configurez un dispositif de quorum. N’acceptez pas le « ça marche la plupart du temps » pour le quorum.

4) Symptom: HA continue d’essayer de récupérer des ressources « sur le nœud supprimé »

Cause racine : La config HA référence encore le nœud/groupes ; contraintes de placement obsolètes.

Correction : Vérifiez le statut ha-manager, mettez à jour les groupes HA, désactivez/supprimez les ressources qui référencent le nœud, puis revérifiez.

5) Symptom: Les invités ne démarrent pas ailleurs après la perte d’un nœud

Cause racine : Les disques étaient sur un stockage local au nœud ; « cluster » ne veut pas dire stockage partagé.

Correction : Restaurer depuis les sauvegardes, promouvoir des répliques, ou reconstruire le stockage. Pour l’avenir : répliquez les datasets ZFS ou utilisez du stockage partagé (Ceph/NFS/iSCSI) pour les charges critiques.

6) Symptom: Le nœud supprimé revient plus tard et « se réintègre » ou cause une confusion d’adhésion

Cause racine : Vous l’avez retiré du cluster mais n’avez pas nettoyé les identifiants/états de cluster sur l’hôte ; il a conservé /etc/corosync/authkey et d’anciennes configs.

Correction : Effectuez le nettoyage (Tâche 15) ou réinstallez. Isolez aussi les nœuds retirés jusqu’à les effacer.

7) Symptom: Les opérations sur /etc/pve sont lentes/bloquent pendant les tentatives de suppression

Cause racine : pmxcfs est bloqué à cause d’une perte de quorum ou d’une instabilité corosync ; le montage FUSE dépend de la santé du cluster.

Correction : Stabilisez Corosync d’abord. Ne traitez pas cela comme un bug de système de fichiers ; c’est généralement une protection de l’état du cluster.

FAQ

1) Pourquoi Proxmox refuse-t-il de supprimer un nœud quand il est hors ligne ?

Parce que « hors ligne » n’égale pas « consensus ». Supprimer un nœud met à jour l’état partagé du cluster. Sans quorum, Proxmox ne peut pas prouver de manière sûre
que les nœuds restants sont d’accord sur le changement, donc il bloque pour éviter le split brain.

2) Puis-je simplement supprimer le répertoire du nœud sous /etc/pve/nodes ?

Ne le faites pas, sauf si vous êtes en procédure de récupération et comprenez les conséquences.
/etc/pve n’est pas un système de fichiers normal ; c’est un état géré par le cluster. Les modifications manuelles peuvent désynchroniser les nœuds ou masquer le vrai problème (quorum).

3) Quel est l’ordre le plus sûr : migrer les charges d’abord ou supprimer le nœud d’abord ?

Migrez d’abord, supprimez ensuite, nettoyez l’hôte en dernier. Si le nœud est mort, vous ne pouvez pas migrer, donc vérifiez l’emplacement des disques et restaurez/promouvez ailleurs avant la suppression.

4) J’ai supprimé un nœud et maintenant j’ai un cluster à 2 nœuds. Est-ce « supporté » ?

Ça peut tourner, mais c’est fragile opérationnellement. Ajoutez un troisième vote (troisième nœud ou dispositif de quorum) si vous tenez à un comportement prévisible lors de partitions et maintenances.

5) Comment savoir si les disques de ma VM sont sur un stockage partagé ou local ?

Vérifiez les définitions de stockage (pvesm status) et la config VM (qm config <vmid>) pour voir les backends de disque.
Si c’est indiqué local-zfs ou local, supposez que c’est local au nœud à moins que vous ayez construit quelque chose d’exotique volontairement.

6) Supprimer un nœud Proxmox le retire-t-il aussi de Ceph ?

Non. Ceph est son propre cluster. Vous devez retirer séparément les OSDs, moniteurs et entrées CRUSH si l’hôte participait à Ceph.
Coordonnez la séquence pour ne pas laisser les données orphelines ou perdre le quorum dans Ceph pendant que vous réparez le quorum dans Proxmox.

7) Que m’indique « Expected votes » ?

C’est le nombre de votes que Corosync pense devoir exister. Si expected votes inclut des nœuds partis, vous pouvez perdre le quorum même si suffisamment de nœuds sont en ligne.
Réparez les expected votes en restaurant correctement l’adhésion (meilleur) ou en les forçant temporairement pour la récupération (pire, mais parfois nécessaire).

8) Et si le nom du nœud est réutilisé plus tard pour un nouvel hôte ?

Ne réutilisez pas le nom tant que l’ancien nœud n’est pas complètement supprimé et nettoyé. Les outils du cluster se basent souvent sur les noms de nœuds dans les chemins de config.
Si vous devez réutiliser, assurez-vous que l’ancienne adhésion est partie et que le nouvel hôte rejoint proprement avec des clés fraîches.

9) Pourquoi l’UI affiche-t-elle parfois encore le nœud supprimé pendant un certain temps ?

L’état de l’UI peut être en retard par rapport à l’état du cluster, surtout si pmxcfs ou l’API a eu des problèmes lors du changement.
Validez avec pvecm nodes et /etc/pve/nodes ; ne faites pas confiance à l’interface graphique comme source de vérité lors d’un incident de cluster.

10) Quelle est la raison la plus courante pour laquelle la suppression d’un nœud tourne mal ?

La réaliser alors que le cluster est instable : liens Corosync oscillants, partitions partielles, ou quorum dégradé.
Les gens blâment la commande. La commande est correcte. Le cluster se dispute.

Conclusion : prochaines étapes qui ne vous hanteront pas

La suppression sûre d’un nœud dans Proxmox ne tient pas à la commande de suppression. Elle tient à la séquence et à la certitude :
quorum, placement des charges, réalité du stockage, puis changement d’adhésion, puis nettoyage pour que l’ancien nœud ne puisse pas revenir.

Si vous ne faites qu’une chose après avoir lu ceci : standardisez un runbook de décommissionnement qui inclut (1) la vérification du quorum,
(2) les vérifications de dépendances de stockage, et (3) le nettoyage sur l’hôte retiré. C’est la pratique ennuyeuse qui empêche que « impossible de supprimer le nœud »
se transforme en « impossible de gérer le cluster ».

Prochaines étapes pratiques :

• Exécutez les Tâches 1–5 sur votre cluster maintenant et enregistrez ce à quoi ressemble un état « sain » pour votre environnement.
• Si vous exploitez un cluster à deux nœuds, décidez d’une stratégie pour un troisième vote et planifiez-la.
• Auditez quelles charges dépendent encore du stockage local et répliquez-les ou acceptez explicitement la douleur de la restauration.
• Rendez « isoler les nœuds retirés » non négociable : hors tension, port désactivé, ou effacement. Idéalement les trois.