Quiz — chapitre 4

Corosync est le daemon de communication cluster qui gère le heartbeat entre nœuds et calcule le quorum. pvedaemon gère l'API Proxmox locale, pveproxy sert l'interface web, pmxcfs est le système de fichiers cluster partagé (/etc/pve) — un rôle distinct de Corosync bien que les deux collaborent.

Le quorum exige une majorité stricte des votes. Avec 2 nœuds, une coupure réseau entre eux donnerait 1 voix de chaque côté — aucune majorité, donc aucune décision sûre possible (split-brain). Avec 3 nœuds, une partition 2 contre 1 laisse toujours un côté majoritaire (2 > 1.5) capable de continuer à opérer en toute sécurité.

pvecm add <IP-du-nœud-existant>, lancé depuis le **nouveau** nœud, l'ajoute au cluster déjà formé. pvecm create sert uniquement à créer un cluster depuis zéro (premier nœud). pvecm join et corosync-cfgtool --join ne sont pas des commandes valides.

La migration à chaud transfère la mémoire et l'état d'exécution d'une VM active vers un autre nœud sans interruption — cela suppose que le disque de la VM soit déjà accessible depuis les deux nœuds via un stockage partagé (Ceph RBD, NFS, iSCSI). Sans stockage partagé, le disque devrait aussi être copié, ce qui n'est possible qu'à froid (VM éteinte) ou via une migration avec transfert de stockage, plus lente. C'est la condition d'une migration à chaud rapide : sans stockage partagé, l'option --with-local-disks permet aussi de migrer à chaud, mais Proxmox recopie alors les disques pendant la migration.

Comme pour le quorum du cluster Proxmox, les MON Ceph élisent un leader par consensus majoritaire — un nombre impair (3, 5...) évite toute égalité de vote. 3 MON est le minimum recommandé en production pour tolérer la perte d'un nœud sans perdre le quorum Ceph.

OSD (Object Storage Daemon) est le processus qui gère un disque physique et y stocke réellement les données répliquées. Le quorum/la carte du cluster est géré par les MON, l'API/dashboard par les MGR, les métadonnées CephFS par les MDS (un composant distinct, non couvert par cet atelier).

ceph status est la commande native Ceph (indépendante de Proxmox) qui affiche la santé globale (HEALTH_OK/WARN/ERR), le quorum des MON, l'état des OSD et l'utilisation du stockage. pvecm status concerne le cluster Proxmox lui-même (Corosync), pvesm status liste les stockages Proxmox — pveceph gère l'installation/configuration, pas l'état runtime.

Après la perte du heartbeat d'un nœud, le HA Manager déclenche d'abord le fencing (isolation du nœud en panne, pour garantir qu'il ne peut plus écrire sur le disque partagé), puis la recovery (relance de la ressource sur un nœud sain), puis la VM repasse à l'état started une fois redémarrée avec succès. Cette séquence protège contre le risque de deux copies actives simultanées de la même VM sur des nœuds différents.

Sur le lab, la réponse du gestionnaire est explicite : service 'vm:950' in error state, must be disabled and fixed first. En error, le CRM ne touche plus la ressource ; on la désactive, on corrige (ici un bridge absent des nœuds), puis on la rend au gestionnaire. Arrêter pve-ha-crm à la main est à proscrire : ces démons tiennent le watchdog.

C'est le fencing : un nœud coupé du cluster mais encore vivant écrirait toujours sur le stockage partagé ; relancer ses VM ailleurs donnerait deux instances sur le même disque. Le watchdog (softdog par défaut) garantit l'arrêt du nœud isolé, d'où le délai d'environ 2 minutes annoncé par la documentation. Ce n'est pas une migration : la VM redémarre à froid.

Sur le lab (atelier 4) : OSD arrêté, 2 up, 3 in, PG en active+undersized+degraded — le cluster sert toujours, avec une copie de moins, sans rien recopier. Sans noout, l'OSD serait marqué out au bout de 600 s et ses données reconstruites ailleurs, pour rien. On retire noout une fois le nœud revenu.