ADR-0002 : Cluster Proxmox sans haute disponibilité¶
- Statut : Acceptée
- Date : 2026-10-31
Dans ce document, « haute disponibilité » désigne la fonction de basculement automatique de Proxmox (Proxmox HA), à ne pas confondre avec Home Assistant.
Contexte¶
Trois hôtes Proxmox (Giada, NUC i3, NUC Celeron). Les regrouper en cluster apporte une interface d'administration unique, la migration manuelle des VMs et une configuration partagée.
Le fonctionnement d'un cluster repose sur corosync : le service qui fait communiquer les nœuds entre eux. Chaque nœud envoie plusieurs fois par seconde de petits messages aux autres pour signaler qu'il est vivant et partager sa vision du cluster. À partir de ces échanges, les nœuds calculent le quorum : une majorité de nœuds (2 sur 3) doit se voir pour que le cluster accepte des modifications. Corosync est très sensible à la latence : si ses messages arrivent en retard, un nœud peut se croire isolé.
Deux contraintes propres à cette installation : - le routeur (VM OPNsense) tourne lui-même sur un nœud du cluster ; - le Giada n'a qu'un port LAN 1G, partagé entre corosync et tout le trafic inter-VLAN. Un transfert lourd peut retarder les messages de corosync de quelques secondes.
La haute disponibilité de Proxmox redémarre automatiquement les VMs d'un nœud défaillant sur un autre nœud. Pour éviter qu'une VM tourne à deux endroits à la fois (ce qui corromprait ses données), un nœud qui perd le quorum se redémarre de force : c'est le fencing, assuré par un watchdog.
Conséquence : avec la haute disponibilité activée, quelques secondes de perturbation de corosync suffiraient à faire redémarrer le Giada, donc à couper internet pour tout le réseau.
Options envisagées¶
- Pas de cluster : trois hôtes indépendants. Simple, mais pas de gestion centralisée ni de migration.
- Cluster avec haute disponibilité : basculement automatique. Inutile ici, car aucune VM critique ne peut changer d'hôte (OPNsense dépend des ports physiques du Giada, Frigate de l'iGPU du NUC i3). Risque de redémarrage intempestif du routeur.
- Cluster sans haute disponibilité : gestion centralisée et migrations manuelles, aucun redémarrage automatique.
Décision¶
Option 3. Cluster de 3 nœuds, haute disponibilité désactivée.
| Perturbation de corosync de quelques secondes | Conséquence |
|---|---|
| Sans haute disponibilité | Perte brève du quorum, puis retour à la normale. Aucun redémarrage. |
| Avec haute disponibilité | Le Giada se croit isolé et se redémarre : coupure d'internet. |
Conséquences¶
- 3 nœuds = quorum à 2, pas de QDevice nécessaire (Proxmox le déconseille sur un nombre impair de nœuds). Il deviendra utile en v3, avec le NAS comme 4e nœud.
- Indépendance vis-à-vis du routeur : IPs statiques sur tous les nœuds, réseau de management commuté en L2 par le switch. Après une coupure de courant, les nœuds forment le quorum même si OPNsense ne démarre pas.
- Procédure de secours documentée :
pvecm expected 1sur un nœud isolé, pour retrouver la main en écriture. - Ordre de création imposé : un nœud qui rejoint le cluster ne doit héberger aucune VM. Tous les nœuds rejoignent vides, les VMs sont déployées ensuite.
- Les noms d'hôtes sont définitifs (renommer un nœud de cluster est coûteux) :
giada,nuc-i3,nuc-cel. - À revoir en v3 : un réseau dédié à corosync (port séparé ou VLAN prioritaire) rendrait la haute disponibilité envisageable pour certains services.