Aller au contenu

Changer l'IP d'un nœud de cluster sans casser Corosync

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

Changer l'adresse d'un nœud déjà membre d'un cluster demande de modifier, dans le bon ordre, trois fichiers : /etc/network/interfaces, /etc/hosts et /etc/pve/corosync.conf (en incrémentant config_version). Une erreur d'ordre ou de syntaxe fait perdre le quorum au nœud, voire au cluster, et peut déclencher le fencing HA. Cette opération est à confier au MSP quel que soit le contrat. Ce runbook vous permet de la comprendre, de la préparer et de la vérifier avec lui.

Exemple : le nœud pve02 passe sur le lien Corosync link0 de 10.10.20.12 à 10.10.21.12. Le cluster a deux liens : link0 dédié et link1 sur le management (10.10.10.12, inchangé).

Avant de toucher la prod

  • Ticket iTop ouvert, intervention planifiée avec le MSP, accès console hors bande (IPMI, iDRAC, iLO) à pve02 testé.
  • Cluster quorate et tous les liens Corosync connectés : pvecm status, corosync-cfgtool -s.
  • Au moins deux liens Corosync : on ne modifie qu'un lien à la fois, l'autre garde le nœud dans le cluster. Avec un seul lien, la procédure est plus risquée et réalisée exclusivement par le MSP.
  • Toutes les VM et conteneurs migrés hors de pve02, nœud en maintenance HA.
  • L'adresse modifiée n'est pas une adresse Ceph (moniteur, réseau public ou cluster) : ce cas suit une procédure Ceph distincte, MSP uniquement.
  • Sauvegardes PBS récentes des VM critiques, et copies des fichiers modifiés.

Étapes

1. Vider le nœud et sauvegarder la configuration

ha-manager crm-command node-maintenance enable pve02   # les ressources HA quittent pve02
qm list ; pct list                                       # sur pve02 : plus rien en cours
cp /etc/pve/corosync.conf /root/corosync.conf.$(date +%F)
cp /etc/network/interfaces /root/interfaces.$(date +%F)
cp /etc/hosts /root/hosts.$(date +%F)

2. Modifier corosync.conf (une seule fois, depuis un nœud quorate)

/etc/pve/corosync.conf est répliqué : le modifier sur pve01 suffit. Ne l'éditez jamais en place, travaillez sur une copie.

cp /etc/pve/corosync.conf /etc/pve/corosync.conf.new
nano /etc/pve/corosync.conf.new

Dans la section nodelist, changez seulement ring0_addr de pve02, puis incrémentez config_version dans la section totem :

  node {
    name: pve02
    nodeid: 2
    quorum_votes: 1
    ring0_addr: 10.10.21.12     # était 10.10.20.12
    ring1_addr: 10.10.10.12
  }
...
totem {
  cluster_name: cluster-client
  config_version: 5             # était 4

mv /etc/pve/corosync.conf.new /etc/pve/corosync.conf
corosync-cfgtool -s        # link0 vers pve02 : déconnecté ; link1 : connecté
pvecm status               # Quorate: Yes, 3 nœuds

3. Changer l'adresse sur pve02

  1. pve02 → System → Network → sélectionnez l'interface de link0 (par exemple eno3) → Edit → IPv4/CIDR 10.10.21.12/24 → OK.
  2. Vérifiez le diff affiché, puis Apply Configuration.
  3. pve02 → System → Hosts : mettez à jour les lignes concernées si elles référencent l'ancienne adresse.
nano /etc/network/interfaces      # iface eno3 : address 10.10.21.12/24
ifreload -a
ip -br addr show eno3
nano /etc/hosts                   # sur chaque nœud qui référence l'ancienne IP

Si c'est l'adresse de management qui change, /etc/hosts de pve02 doit résoudre son propre nom vers la nouvelle adresse (10.10.10.x pve02.client.local pve02), et les autres nœuds doivent être mis à jour aussi.

4. Vérifier la reprise du lien et finaliser

corosync-cfgtool -s
journalctl -b -u corosync --since "-10min"
# si le lien ne remonte pas après la modification : systemctl restart corosync (sur pve02)
pvecm updatecerts                   # met à jour certificats et known_hosts SSH du cluster
ha-manager crm-command node-maintenance disable pve02

Mettez ensuite à jour les références à l'ancienne adresse : réseau de migration (/etc/pve/datacenter.cfg), IPSet et règles du pare-feu (/etc/pve/firewall/cluster.fw), ACL des exports NFS ou des cibles iSCSI, QDevice, supervision, DNS, pare-feu externe vers pbs-local.

Vérifications

# corosync-cfgtool -s
LINK ID 0 udp
        addr    = 10.10.20.11
        status:
                nodeid:   1:    localhost
                nodeid:   2:    connected
                nodeid:   3:    connected
# pvecm status | grep -E "Quorate|Total votes"
Quorate:          Yes
Total votes:      3
Le même config_version apparaît dans /etc/corosync/corosync.conf sur les trois nœuds. Les trois nœuds sont verts dans la GUI. Une migration à chaud de test vers pve02 aboutit.

Rollback

Tant que link1 est actif : restaurez l'ancienne adresse sur pve02 (cp /root/interfaces.<date> /etc/network/interfaces && ifreload -a), puis réécrivez corosync.conf avec l'ancienne ring0_addr et un config_version encore incrémenté (6, jamais revenir à 4). Si pve02 a perdu le quorum, /etc/pve y est en lecture seule : la correction passe par /etc/corosync/corosync.conf local, intervention MSP.

Pièges vus en support

  • config_version non incrémenté : la modification n'est pas prise en compte, ou les nœuds divergent.
  • Édition directe de /etc/pve/corosync.conf avec un éditeur qui écrit des fichiers temporaires : une version incomplète est propagée à tout le cluster.
  • Les deux liens modifiés en même temps : le nœud sort du cluster, le fencing HA redémarre le nœud s'il portait des ressources HA.
  • Un nom d'hôte à la place d'une IP dans ring0_addr : la résolution peut changer sans prévenir. Proxmox recommande des adresses IP.
  • Nœud avec un seul lien Corosync sans maintenance HA : redémarrage par le watchdog au moment du changement.
  • Adresse Ceph modifiée par cette procédure : moniteurs injoignables. Procédure distincte, MSP.

Quand ouvrir un ticket iTop

Toujours, avant l'intervention : demande P4 de planification, avec le plan d'adressage cible et la sortie de pvecm status et corosync-cfgtool -s. Pendant l'intervention, perte de quorum ou nœud gris : P1, suivez RB-09 en parallèle. Joindre /etc/pve/corosync.conf, journalctl -u corosync -u pve-cluster --since "-1h".

Ouvrir un ticket iTop

Pour aller plus loin