Aller au contenu

Ajouter, retirer, réinstaller un nœud

Day 2 · ExploiterNiveau 3 · MaîtriserRunbookRédigé · à valider en lab

Ajouter un nœud à un cluster existant, retirer définitivement un nœud avec pvecm delnode, ou réinstaller un nœud défaillant sous le même nom, sans casser Corosync ni Ceph. Ces opérations touchent Corosync : elles sont exécutées par le MSP (contrats N2 et N3) ; en N1, le client les réalise avec un ticket ouvert et le MSP en appui.

Avant de toucher la prod

  • Cluster quorate, Ceph HEALTH_OK, aucune réplication en échec.
  • Impact sur le quorum calculé (Quorum et votes) : passer de 3 à 2 nœuds impose un QDevice ; de 3 à 4 en recommande un.
  • Ceph : capacité restante suffisante sans le nœud retiré, size/min_size toujours respectables, MON restant en nombre impair.
  • Nouveau nœud installé dans la même version que le cluster, vide (aucun invité), même plan réseau.
  • QDevice présent : prévoir pvecm qdevice remove avant, et pvecm qdevice setup après.
  • Sauvegardes à jour sur pbs-local.

A. Ajouter un nœud (pve04)

  1. Installer pve04 (Installer PVE), mettre à jour au même niveau que le cluster.
  2. Si un QDevice existe : pvecm qdevice remove sur un nœud du cluster.

  3. Joindre le cluster.

    Sur pve01 : Datacenter → Cluster → Join Information → Copy Information. Sur pve04 : Datacenter → Cluster → Join Cluster, coller, saisir le mot de passe root, choisir les adresses Link 0 et Link 1.

    pvecm add 10.10.10.1 --link0 10.10.10.4 --link1 192.168.1.14

  4. Reconfigurer le QDevice si le nombre de nœuds est pair : pvecm qdevice setup 192.168.1.50.

  5. Ceph HCI : installer Ceph sur pve04, créer les OSD (Installer Ceph) ; restreindre les stockages locaux (Datacenter → Storage → Nodes) si besoin.

B. Retirer définitivement un nœud (pve03)

  1. Migrer toutes les VM et CT hors de pve03 ; sauvegarder ses données locales.
  2. Supprimer ses jobs de réplication (Datacenter → Replication) : après le retrait, ils ne pourraient plus être supprimés.
  3. Retirer pve03 de toutes les règles HA (Datacenter → HA → Affinity Rules).
  4. Ceph : sortir et détruire ses OSD un par un en attendant active+clean (RB-03), détruire MON, MGR et MDS de ce nœud, puis ceph osd crush remove pve03.
  5. Éteindre pve03 et s'assurer qu'il ne redémarrera pas sur le réseau du cluster avec sa configuration (débrancher, effacer les disques boot).

  6. Sur un nœud restant :

    pvecm nodes
pvecm delnode pve03          # "cs_err_not_exist" peut être ignoré
pvecm nodes                  # pve03 n'apparaît plus

  7. Nettoyage : récupérer ce qui est utile puis supprimer /etc/pve/nodes/pve03, retirer ses clés dans /etc/pve/priv/authorized_keys, retirer le nœud des listes de nœuds des stockages.

C. Réinstaller un nœud défaillant (même nom, même IP)

  1. Appliquer B intégralement (le nœud est déjà éteint s'il est en panne).
  2. Réinstaller sur des disques boot vierges, même nom et même IP.
  3. Appliquer A, puis sur le nœud réintégré : pvecm updatecerts en cas d'erreur SSH ou de certificat.
  4. Recréer les OSD, les jobs de réplication et les règles HA.

Vérifications

pvecm status
# Quorate: Yes ; Expected votes = nombre de nœuds (+1 si QDevice)
corosync-cfgtool -s          # tous les liens "connected"
ls /etc/pve/nodes/           # liste exacte des nœuds attendus
ceph -s                      # HEALTH_OK, nombre d'OSD et de MON attendu
ha-manager status            # aucun service sur un nœud absent

Rollback

Un ajout réussi se défait par la procédure B. Un delnode ne se défait pas : le nœud retiré doit être réinstallé avant de rejoindre. Si delnode fait perdre le quorum (cluster de 2 nœuds restants sans QDevice), le MSP utilise pvecm expected sous contrôle, jamais sur deux partitions à la fois.

Pièges vus en support

  • Nœud retiré puis rallumé tel quel sur le réseau : il tente de rejoindre Corosync avec l'ancienne configuration et perturbe tout le cluster.
  • Jobs de réplication oubliés : entrées fantômes impossibles à supprimer depuis la GUI.
  • OSD détruits sur le nœud retiré avant le retour à active+clean : PG dégradés, voire inactifs.
  • Réutiliser le nom d'un nœud sans delnode préalable : conflits de certificats et de clés SSH.
  • Ajouter un nœud avec un QDevice actif sans le retirer d'abord : votes incohérents.
  • Séparer un nœud sans réinstaller (procédure pmxcfs -l) : déconseillée par Proxmox, réservée au MSP.

Quand ouvrir un ticket iTop

Ajout ou retrait planifié : P4, deux semaines à l'avance. Nœud en panne matérielle à réinstaller : P2 (P1 si le quorum est menacé). Joindre pvecm status, pvecm nodes, ceph -s, ceph osd tree et le plan d'adressage du nœud.

Ouvrir un ticket iTop

Pour aller plus loin