Dawan Proxmox VE — TSSR

Chapitre 4 — Cluster, Ceph et haute disponibilité

7. Maintenance d'un nœud et mises à jour

Un nœud de cluster doit parfois s'arrêter : changer une pièce, appliquer une mise à jour. Tant qu'il porte des machines, l'arrêter les interromprait. Proxmox sait le vider d'abord, en migrant ses machines à chaud vers les autres nœuds.

7.1 Mode maintenance et politique d'arrêt

Un nœud qui porte des ressources HA ne s'arrête pas comme un serveur isolé : le gestionnaire doit savoir s'il s'agit d'une panne ou d'une intervention. Trois outils répondent à trois situations.

Trois outils pour intervenir sur un nœud HA : mode maintenance, politique d'arrêt, désarmement de la HA

Les trois outils de cette sous-section, avec la situation à laquelle chacun répond et son effet. Cliquez sur un outil pour la commande et ce qu'elle affiche.

Le mode maintenance vide un nœud de ses ressources HA pour une intervention qui ne se résume pas à un seul redémarrage (remplacement de matériel, tests). La commande peut être lancée depuis n'importe quel nœud : elle est mise en file d'attente et traitée par le CRM.

Dans le Shell du nœud (interface web → votre nœud → Shell) :

ha-manager crm-command node-maintenance enable pxe213   # mettre pxe213 en maintenance : ses ressources HA partent
ha-manager crm-command node-maintenance disable pxe213   # sortir pxe213 de maintenance

Sur le lab, avec la VM de test 950 sous HA sur pxe213. Après enable, le CRM migre la ressource à chaud :

pve-ha-crm[1412]: node 'pxe213': state changed from 'online' => 'maintenance'
pve-ha-crm[1412]: migrate service 'vm:950' to node 'pxe212' (running)
pve-ha-crm[1412]: service 'vm:950': state changed from 'started' to 'migrate'  (node = pxe213, target = pxe212)
pve-ha-crm[1412]: service 'vm:950': state changed from 'migrate' to 'started'  (node = pxe212)

Le LRM du nœud signale qu'il a fini de se vider en fermant son watchdog — c'est la ligne à guetter avant d'intervenir : pve-ha-lrm[1931]: watchdog closed (disabled), 30 secondes après la commande. ha-manager status affiche alors lrm pxe213 (maintenance mode, watchdog active, …). Après disable, la ressource revient d'elle-même sur son nœud d'origine :

pve-ha-crm[1412]: node 'pxe213': state changed from 'maintenance' => 'online'
pve-ha-crm[1412]: moving service 'vm:950' back to 'pxe213', node came back from maintenance.
pve-ha-crm[1412]: migrate service 'vm:950' to node 'pxe213' (running)
pve-ha-crm[1412]: service 'vm:950': state changed from 'migrate' to 'started'  (node = pxe213)

Sur le lab, le retour a pris 39 secondes après la commande disable : le LRM doit d'abord reprendre son verrou d'agent (successfully acquired lock 'ha_agent_pxe213_lock', 9 secondes après). Il faut attendre, pas relancer la commande. Le mode maintenance survit à un redémarrage du nœud : il ne disparaît que par disable.

La politique d'arrêt (shutdown_policy) dit ce que fait le gestionnaire quand on éteint ou redémarre un nœud sans mode maintenance. Elle se règle dans Datacenter → Options → HA Settings :

Valeur Comportement
conditional (défaut) Sur poweroff : les ressources sont arrêtées, puis reprises par d'autres nœuds. Sur reboot : elles sont gelées (freeze) et redémarrent sur le même nœud à son retour
migrate Le LRM se déclare indisponible et fait migrer toutes ses ressources avant de s'éteindre ; elles reviennent au retour du nœud
failover Les ressources sont arrêtées, et reprises ailleurs si le nœud ne revient pas rapidement
freeze Les ressources sont arrêtées et gelées jusqu'au retour du nœud

C'est pourquoi l'atelier de HA (§6, atelier 6) simule la panne par une coupure brutale, et non par poweroff. Un arrêt propre est traité par cette politique, pas par le mécanisme de reprise sur panne.

Désarmer la HA (Proxmox VE 9.2) sert aux interventions qui risquent de faire perdre le quorum : une reconfiguration de Corosync ou du réseau du cluster, par exemple. ha-manager crm-command disarm-ha freeze (ou ignore) relâche tous les watchdogs du cluster.

ha-manager crm-command arm-ha les réarme. Pendant ce temps, aucune panne n'est prise en charge : la fenêtre doit rester courte.

7.2 Les mises à jour en cluster

En cluster, on met à jour un nœud à la fois. On le vide de ses VM (migration, mode maintenance HA), on le met à jour, on le redémarre, puis on passe au suivant. C'est le rolling update.

Avec Ceph, on pose d'abord ceph osd set noout, pour que Ceph ne recopie pas les données d'un OSD absent quelques minutes.

Ne jamais redémarrer deux nœuds simultanément dans un cluster à 3 nœuds. Avec deux nœuds en cours de redémarrage, le troisième n'a plus le quorum (1 vote sur 3) et passe en lecture seule : toutes les VM sont figées.

À retenir : on applique les mises à jour de sécurité sans attendre. En cluster, un nœud à la fois, vidé de ses VM, mis à jour, redémarré, puis le suivant. Jamais deux nœuds redémarrés en même temps sur trois ; avec Ceph, on pose noout.