On retire un noeud d'un cluster Proxmox VE pour trois raisons : le remplacer par du matériel neuf, le réinstaller à la suite d'une dérive de configuration, ou réduire la plateforme. Dans les trois cas la commande finale est la même, et dans les trois cas ce n'est pas elle qui pose problème. Les incidents viennent de ce qui référençait encore le noeud au moment du retrait : une tâche de réplication, une règle de haute disponibilité, un moniteur Ceph, une entrée de stockage.
Cette procédure couvre le cas complet, retrait puis réintégration après réinstallation. Elle suppose un cluster en bon état et un noeud joignable. Le cas du noeud mort est traité à la fin.
Renseignez les noms de vos noeuds : toute la page s'adapte, blocs de commande compris. Les valeurs restent dans votre navigateur et ne nous sont jamais transmises.
01La règle qui rend l'opération sûre
Un noeud retiré du cluster ne doit jamais être rallumé sur le réseau du cluster avec son ancienne installation. Il possède encore la configuration corosync, les certificats et les clés du cluster. En redémarrant, il tente de reprendre sa place, et peut corrompre la configuration partagée des noeuds restants. Un noeud retiré est un noeud à réinstaller depuis l'ISO, sans exception.
Trois corollaires pratiques en découlent.
- Le noeud doit être éteint au moment où l'on lance la commande de retrait, et le rester jusqu'à sa réinstallation.
- Si vous comptez réutiliser le même nom et la même adresse, le retrait doit être complet, répertoire de configuration compris, avant la réinstallation.
- Il n'existe pas de retour arrière une fois la commande passée. La préparation remplace le plan de repli.
02Vérifier la marge de quorum
Retirer un noeud réduit le nombre de voix. Proxmox VE ajuste le nombre de voix attendues au moment du retrait, mais pendant toute la durée de l'opération, réinstallation comprise, le cluster tourne avec un noeud de moins. C'est le moment où une panne supplémentaire fait mal.
pvecm status pvecm nodes corosync-cfgtool -s
| Cluster avant | Pendant l'opération | Tolérance restante | Recommandation |
|---|---|---|---|
| 3 noeuds | 2 noeuds, quorum à 2 | Aucune | Fenêtre courte, ou QDevice temporaire |
| 4 noeuds | 3 noeuds, quorum à 2 | 1 noeud | Confortable |
| 5 noeuds | 4 noeuds, quorum à 3 | 1 noeud | Confortable |
| 2 noeuds | 1 noeud | Aucune | QDevice indispensable |
Passer à deux noeuds supprime toute tolérance : la perte d'un des deux survivants fige la plateforme en lecture seule. Si la réinstallation s'étale sur plusieurs jours, ajoutez un QDevice le temps de l'opération. Une machine légère hébergée ailleurs suffit, et elle se retire aussi facilement qu'elle s'ajoute.
# sur la machine tierce apt install corosync-qnetd # sur chaque noeud restant apt install corosync-qdevice # depuis un noeud, une seule fois pvecm qdevice setup 10.10.0.250 # retrait une fois l'operation terminee pvecm qdevice remove
03Vider le noeud
Le noeud doit ne plus rien porter, ni machine, ni responsabilité. Quatre inventaires à faire, dans cet ordre.
Les machines et conteneurs
# ce que porte le noeud, depuis n'importe quel noeud du cluster pvesh get /nodes/pve-03/qemu --output-format json-pretty pvesh get /nodes/pve-03/lxc --output-format json-pretty # stockage partage : migration a chaud immediate qm migrate 101 pve-01 --online # stockage local ZFS : les disques suivent la machine qm migrate 101 pve-01 --online --with-local-disks # un conteneur ne migre pas a chaud, --restart le redemarre sur la cible pct migrate 201 pve-01 --restart
Sur du ZFS local, --with-local-disks copie le contenu des disques pendant la
migration. Comptez le temps correspondant au volume et au débit du réseau de migration, et
surveillez l'espace disponible sur le noeud cible. Si le cluster utilise la réplication ZFS,
une machine déjà répliquée vers la cible migre beaucoup plus vite : seul le delta est
transféré.
La haute disponibilité
ha-manager status # Proxmox VE 9 : regles d'affinite ha-manager rules config ha-manager rules set node-affinity prod-critique --nodes "pve-01:2,pve-02:1" # Proxmox VE 8 : anciens groupes ha-manager groupset prod-critique --nodes "pve-01:2,pve-02:1"
Une règle d'affinité stricte qui désigne encore le noeud retiré devient impossible à satisfaire. La ressource concernée ne redémarre alors nulle part, et l'erreur n'apparaît qu'au prochain incident, des semaines plus tard. Passez en revue toutes les règles, pas seulement celles des machines que le noeud hébergeait.
Les tâches de réplication
Ce point est le plus souvent oublié sur les clusters ZFS. Une tâche dont la source ou la cible disparaît tombe en erreur à chaque exécution, et laisse des jeux de données orphelins derrière elle.
# toutes les taches, source et cible confondues pvesr list # suppression d'une tache qui concerne le noeud retire pvesr delete 101-0 # les instantanes de replication restes sur les noeuds survivants zfs list -t snapshot -r rpool/data | grep __replicate__ # les jeux de donnees orphelins, a supprimer apres verification zfs list -r rpool/data
Un jeu de données laissé en place empêchera plus tard la recréation d'une réplication portant le même nom, avec un message peu explicite sur un volume déjà existant. Le nettoyage prend deux minutes maintenant, et un quart d'heure de recherche dans six mois.
Les sauvegardes et la supervision
- Travaux de sauvegarde qui ciblent explicitement le noeud, dans les tâches planifiées du centre de données.
- Agent de métriques installé sur le noeud, et tableaux de bord qui le nomment.
- Alertes et seuils qui référencent le nom du noeud, sous peine d'alertes fantômes.
- Inventaire, documentation et plan d'adressage, à mettre à jour en fin d'opération.
04Détacher le stockage
Entrées de stockage restreintes au noeud
pvesm status cat /etc/pve/storage.cfg # mettre a jour la liste des noeuds autorises pvesm set local-zfs --nodes pve-01,pve-02
Si le noeud participe à Ceph
Cette section ne concerne pas les clusters en ZFS local. Sur une plateforme Ceph, le noeud porte des OSD, et souvent un moniteur et un gestionnaire : ils doivent être retirés avant le retrait du noeud, et un par un.
# sortir un OSD, attendre le retour a HEALTH_OK avant le suivant ceph osd out osd.5 watch ceph -s # verifier qu'il peut etre detruit sans perte ceph osd safe-to-destroy osd.5 pveceph osd destroy 5 # puis les services, une fois tous les OSD du noeud detruits pveceph mds destroy pve-03 pveceph mgr destroy pve-03 pveceph mon destroy pve-03 # retirer l'hote de la carte CRUSH ceph osd crush remove pve-03 ceph osd tree
Ceph a besoin d'une majorité de moniteurs. Détruire l'un des trois laisse deux moniteurs, donc aucune tolérance côté Ceph pendant toute l'opération. Si la réinstallation doit durer, créez d'abord un moniteur sur un autre noeud, puis détruisez celui du noeud sortant. Le compte reste impair, et la marge est préservée.
05Le retrait proprement dit
Le noeud est vide, plus rien ne le référence. On peut l'éteindre définitivement, puis lancer le retrait depuis un autre noeud.
# le repertoire contient encore les definitions des machines du noeud ls -la /etc/pve/nodes/pve-03/qemu-server/ /etc/pve/nodes/pve-03/lxc/ # copie hors de /etc/pve, qui est un systeme de fichiers partage cp -a /etc/pve/nodes/pve-03 /root/config-pve-03-$(date +%F)
pvecm delnode pve-03 # controles immediats pvecm status pvecm nodes corosync-cfgtool -s
Le nombre de voix attendues doit avoir diminué d'une unité, et le noeud ne doit plus apparaître dans la liste. Les deux liens corosync doivent rester connectés sur les noeuds survivants.
# le repertoire de configuration survit au retrait, il faut l'enlever ls /etc/pve/nodes/ rm -rf /etc/pve/nodes/pve-03 # empreintes SSH obsoletes, sinon erreur de verification au retour ssh-keygen -f /root/.ssh/known_hosts -R pve-03 ssh-keygen -f /root/.ssh/known_hosts -R 10.10.0.13 pvecm updatecerts -f
Ce répertoire contient les fichiers de configuration des machines qui vivaient sur le noeud.
Si une machine a été migrée correctement, sa configuration est déjà passée sur le noeud cible
et il n'y a rien à perdre. Si quelque chose y traîne encore, c'est qu'une migration a été
oubliée. Vérifiez qu'il est vide de qemu-server et de lxc avant de
supprimer, et gardez la copie faite plus haut.
06Réinstaller le noeud
La réinstallation suit le chapitre d'installation du guide cluster. Quatre points demandent une attention particulière dans ce contexte précis.
- Le nom du pool ZFS. Les entrées de
storage.cfgdésignent un pool par son nom. Si le noeud réinstallé crée un pool nommé différemment, le stockage reste invisible pour lui. Reprenez exactement les noms d'origine,rpoolcompris. - Le nom d'hôte et l'adresse. Les réutiliser est parfaitement possible, à condition que le retrait ait été complet, répertoire de configuration supprimé inclus. C'est le choix le plus simple : rien d'autre à mettre à jour ailleurs.
- La configuration réseau. Les mêmes interfaces, les mêmes VLAN, les mêmes liens corosync qu'avant. Un noeud qui rejoint avec un plan d'adressage différent du reste du cluster rejoint, puis pose problème.
- Les dépôts, l'horloge et la résolution de noms à aligner sur les autres noeuds avant la réintégration, pas après.
# le pool porte le bon nom zpool status zfs list # chaque noeud du cluster est resolu, par /etc/hosts ping -c1 pve-01 && ping -c1 pve-02 # horloge synchronisee sur les memes sources chronyc sources chronyc tracking # meme version de paquets que les autres noeuds pveversion -v | head -3
07Le réintégrer au cluster
Un noeud qui rejoint un cluster voit sa configuration locale de machines virtuelles remplacée par celle du cluster. Sur un noeud fraîchement réinstallé il n'y a rien à perdre, mais ne créez aucune machine avant d'avoir rejoint : elle disparaîtrait de la configuration.
# les liens correspondent aux reseaux corosync, comme a la creation pvecm add 10.10.1.11 \ --link0 10.10.1.13 \ --link1 10.10.2.13 # verifications, depuis n'importe quel noeud pvecm status corosync-cfgtool -s pvesm status
Si l'adhésion échoue sur une erreur de vérification d'empreinte SSH, c'est qu'une ancienne
clé subsiste. Relancez pvecm updatecerts -f sur les noeuds existants et retirez
l'entrée obsolète de leurs fichiers d'empreintes, puis réessayez.
Remettre en place ce qui avait été retiré
La réintégration n'est pas terminée quand le noeud apparaît dans l'interface. Reprenez la liste du retrait, à l'envers.
# stockages : rendre le noeud a nouveau eligible pvesm set local-zfs --nodes pve-01,pve-02,pve-03 # Ceph, le cas echeant : paquets, moniteur, gestionnaire, OSD pveceph install --repository no-subscription pveceph mon create pveceph osd create /dev/nvme0n1 # replication : recreer les taches dans les deux sens pvesr create-local-job 101-0 pve-03 --schedule "*/15" --rate 100 # haute disponibilite : remettre le noeud dans les regles ha-manager rules set node-affinity prod-critique --nodes "pve-01:2,pve-02:1,pve-03:1" # renvoyer des machines sur le noeud et verifier la migration a chaud qm migrate 101 pve-03 --online
Une migration à chaud aller-retour vers le noeud réintégré prouve que le cluster, le stockage et le réseau de migration fonctionnent ensemble. Tant qu'elle n'a pas été faite, le noeud est présent mais pas validé. Ajoutez une sauvegarde réussie d'une machine hébergée sur ce noeud, et l'opération peut être considérée comme terminée.
08Cas d'un noeud mort ou injoignable
Si le noeud ne redémarrera plus, la procédure est la même, amputée de tout ce qui se fait depuis lui. Les machines qu'il hébergeait sont restaurées depuis les sauvegardes ou récupérées depuis les réplicas, jamais migrées.
# si le quorum est perdu, abaisser temporairement les voix attendues pvecm expected 2 # puis retirer normalement pvecm delnode pve-03 pvecm status
Abaisser le nombre de voix attendues lève la protection qui empêche deux parties d'un cluster coupé en deux d'écrire chacune de leur côté. Ne l'utilisez que si vous avez la certitude que le noeud absent est réellement arrêté, et pas simplement isolé par une panne réseau. Le réglage est temporaire et disparaît au redémarrage de corosync.
Une machine dont le noeud propriétaire a disparu garde sa configuration dans
/etc/pve/nodes/pve-03/. Pour la relancer ailleurs, il suffit de déplacer son fichier
de configuration vers le répertoire du noeud cible, à condition que ses disques soient
accessibles, sur un stockage partagé ou via un réplica ZFS.
Ne déplacez une configuration que si vous êtes certain que la machine ne tourne nulle part ailleurs. Deux instances de la même machine écrivant sur les mêmes disques détruisent le système de fichiers en quelques secondes. C'est précisément ce que la haute disponibilité et son watchdog évitent en fonctionnement normal.
09Liste de contrôle
| Étape | Action | Vérification |
|---|---|---|
| Avant | Marge de quorum évaluée, QDevice si besoin | pvecm status |
| Avant | Sauvegarde récente et vérifiée des machines du noeud | Tâche de vérification PBS réussie |
| Vidage | Machines et conteneurs migrés | Aucun résultat sur les listes du noeud |
| Vidage | Règles de HA mises à jour | ha-manager rules config |
| Vidage | Tâches de réplication supprimées | pvesr list |
| Vidage | Jeux de données orphelins nettoyés | zfs list -r |
| Vidage | Sauvegardes et supervision débranchées | Plus d'alerte sur le nom du noeud |
| Stockage | Entrées de stockage mises à jour | pvesm status |
| Stockage | Ceph : OSD, MDS, MGR, MON détruits, CRUSH nettoyée | ceph -s en HEALTH_OK |
| Retrait | Configurations copiées hors de /etc/pve | Copie présente sur un autre noeud |
| Retrait | Noeud éteint, puis pvecm delnode | Voix attendues diminuées de 1 |
| Retrait | Répertoire et empreintes SSH nettoyés | ls /etc/pve/nodes/ |
| Retour | Réinstallation, pool ZFS au bon nom | zpool status |
| Retour | Adhésion avec les deux liens corosync | corosync-cfgtool -s |
| Retour | Stockage, Ceph, réplication et HA rétablis | Chaque commande du paragraphe 07 |
| Retour | Migration à chaud aller-retour réussie | Machine en service sur le noeud |
Faites de cette liste un document d'exploitation interne, rempli à chaque opération avec la date, le nom du noeud et l'opérateur. Sur une plateforme qui vit plusieurs années, c'est la seule trace qui permet de répondre à la question posée six mois plus tard : qu'est-ce qui a changé sur ce cluster.
Une plateforme Proxmox a exploiter sereinement
Nous exploitons des clusters Proxmox VE et Ceph en production pour des PME, des structures reglementees et des collectivites. Remplacement de noeud, montee de version, reprise d'une plateforme existante : nous intervenons au forfait comme en astreinte.