Construire un cluster Proxmox HA : architecture et pièges

Une des confusions les plus fréquentes chez les équipes qui découvrent Proxmox : la haute disponibilité n'est pas une option qu'on active dans l'interface. C'est un système qui repose sur plusieurs mécanismes indépendants, chacun avec ses propres conditions et ses propres points de défaillance.

On peut activer "HA" et avoir un cluster qui ne bascule pas en cas d'incident réel. Voilà ce qu'il faut comprendre avant de s'en apercevoir en production.

Corosync et le quorum : la base qu'on sous-estime

Corosync est le composant de communication du cluster. C'est lui qui maintient la cohérence de l'état entre les nœuds, et c'est sur lui que repose la décision de bascule.

Le quorum définit combien de nœuds doivent être en communication pour que le cluster soit "sain" et autorisé à prendre des décisions. Par défaut, un cluster à 3 nœuds tolère la perte d'un nœud (2 sur 3 forment le quorum). Un cluster à 2 nœuds a un problème fondamental : en cas de perte d'un nœud, le second ne peut pas savoir s'il est le seul survivant ou s'il y a eu une partition réseau.

Pour les petits environnements qui ne veulent pas un troisième nœud complet, Proxmox propose un QDevice (serveur de quorum léger sur une VM ou un Raspberry Pi). C'est une solution valide, mais elle doit être documentée et intégrée dans les procédures de maintenance — si le QDevice est indisponible, les opérations de cluster sont bloquées.

Le fencing : mal compris, souvent mal configuré

Le fencing est le mécanisme qui permet à un nœud survivant de "tuer" un nœud défaillant avant de migrer ses VMs. Sans fencing, le cluster risque de démarrer des VMs sur un nouveau nœud alors qu'elles tournent encore sur le nœud défaillant — entraînant une corruption de données.

En production enterprise, le fencing doit être matériel : IPMI, iDRAC, iLO, ou autre interface de gestion out-of-band. Ces interfaces permettent d'envoyer une commande de coupure physique au nœud défaillant.

Le fencing watchdog (basé sur le kernel Linux) est une alternative pour les environnements sans IPMI, mais il a ses propres contraintes et ne doit pas être retenu comme solution principale en production critique.

Ce qu'il faut valider avant de déclarer HA fonctionnel :

1. Tester la commande fence manuellement depuis chaque nœud vers chaque autre nœud
2. Couper physiquement l'alimentation d'un nœud et vérifier que le fencing s'exécute
3. Vérifier que les VMs HA redémarrent bien sur les nœuds survivants avec le bon délai

Le stockage partagé : le composant le plus critique

Le HA Proxmox fonctionne uniquement si les VMs sont sur un stockage accessible depuis tous les nœuds du cluster. Un disque local ne peut pas accueillir une VM HA — si le nœud hébergeant ce disque tombe, la VM ne peut pas migrer.

Options courantes :

• Ceph : distribué, natif dans Proxmox, sans SPOF si bien configuré
• NFS/iSCSI partagé : dépend d'un serveur externe (potentiel SPOF)
• Réplication Proxmox : réplication par snapshot entre nœuds, mais pas du stockage partagé vrai — la bascule HA n'est pas instantanée

Ceph sur Proxmox HA : ce qu'on ne dit pas assez

Ceph est excellent quand il est bien dimensionné. Il peut être douloureux quand il ne l'est pas.

Les points de vigilance en déploiement enterprise :

Nombre minimum de replicas : par défaut, Ceph réplique les données sur 3 nœuds (size=3). En dessous de 3 OSD en état "up", le pool passe en mode "degraded" ou "down". Trop de gens déploient un cluster à 3 nœuds avec 1 OSD par nœud et découvrent que perdre un nœud pendant la maintenance du second rend le stockage indisponible.

Le réseau est critique : Ceph utilise deux réseaux distincts — public (pour les clients) et cluster (pour la réplication interne). Les mélanger ou utiliser le même switch que le trafic VM peut générer des problèmes de performance et de stabilité difficiles à diagnostiquer.

Le rebuild après défaillance : quand un OSD tombe, Ceph lance une procédure de réplication pour restaurer le niveau de tolérance. Sur de gros volumes, ce processus peut durer plusieurs heures et dégrader les performances. En production, ça se prépare.

Les stretched clusters : là où ça se complique franchement

Un stretched cluster Proxmox — deux sites avec des nœuds de chaque côté — est techniquement faisable mais architecturalement complexe.

Les problèmes à résoudre :

• Latence réseau inter-sites : Corosync est sensible à la latence. Au-delà de quelques millisecondes entre les nœuds, la stabilité du cluster peut se dégrader.
• Split-brain : si le lien inter-sites est coupé, chaque site voit l'autre comme "mort". Sans tiebreaker sur un troisième site, les deux partitions peuvent essayer de devenir "master" simultanément.
• Ceph en stretched : possible mais avec des configurations spécifiques (stretch mode, zones de défaillance, rack awareness). Ce n'est pas une configuration standard et ça demande une maîtrise approfondie.

Pour la plupart des besoins de DR multi-sites, la réplication Proxmox (snapshot-based) combinée avec des procédures de bascule manuelles est plus robuste qu'un stretched cluster géré par le HA automatique.

Ce qu'il faut tester avant de déclarer HA production-ready

Liste minimale de tests pour un cluster HA production :

1. Panne nœud propre (reboot normal) → vérifier la migration automatique des VMs HA
2. Panne nœud brutale (coupure alimentation) → vérifier que le fencing s'exécute et que les VMs redémarrent
3. Perte réseau cluster → vérifier le comportement en partition
4. Panne d'un OSD Ceph → vérifier que le stockage reste opérationnel et que le rebuild démarre correctement
5. Restauration depuis PBS → vérifier le RTO réel d'une restauration complète
6. Bascule et retour → vérifier que les VMs repassent sur leur nœud préféré après récupération

Ces tests ne se font pas uniquement au démarrage. Ils doivent être répétés après chaque mise à jour majeure et intégrés dans un calendrier de validation trimestriel.

La différence entre un cluster HA et un cluster qui fait illusion

La haute disponibilité en production enterprise n'est pas un état binaire. C'est un continuum entre "le cluster redémarre éventuellement" et "le RTO est mesuré, documenté, et tenu".

La différence est dans les détails : le réseau de fencing est-il sur le même switch que le réseau de production ? Les VMs HA ont-elles été testées individuellement ? Le processus de décision de bascule manuelle est-il documenté et connu de l'équipe de nuit ?

Ce sont ces détails qui font la différence à 2h du matin.