Les clusters de trois nœuds Proxmox VE apparaissent fréquemment quand on parle de virtualisation d’entreprise et de haute disponibilité. La raison n’est pas que trois serveurs offrent magiquement plus de performances que deux, mais quelque chose de beaucoup plus fondamental : le quorum qu’un système distribué doit atteindre pour prendre des décisions en toute sécurité lors d’une défaillance. La documentation officielle de Proxmox recommande au minimum trois nœuds pour assurer une haute disponibilité avec un quorum fiable.
Les clés des clusters Proxmox à trois nœuds en 30 secondes
- Chaque nœud fournit généralement un vote, et le cluster nécessite la majorité pour maintenir le quorum.
- Avec trois nœuds, la perte d’un nœud laisse deux votes disponibles et le cluster conserve la majorité.
- Deux nœuds sont également possibles, et Proxmox prévoit l’utilisation d’un QDevice externe comme troisième vote.
- Disposer du quorum ne signifie pas avoir la capacité suffisante pour récupérer toutes les machines virtuelles.
- Une architecture HA doit prendre en compte la CPU, la RAM N+1, le stockage, Corosync, les réseaux, le commuté, l’alimentation électrique et la sauvegarde.
Il est important de faire cette distinction car il est relativement simple d’acheter trois serveurs, d’installer Proxmox VE, de créer le cluster et d’activer les ressources de haute disponibilité (HA). Cependant, cela ne garantit pas que l’infrastructure pourra supporter la perte de l’un de ces serveurs de manière optimale.
Le problème survient lorsque le dimensionnement se fait en utilisant pratiquement 100 % de la CPU et de la mémoire disponibles. Si l’un des hôtes tombe en panne et que les deux autres sont déjà saturés, Proxmox peut disposer du quorum et détecter la panne, mais les machines virtuelles affectées ne disposeront pas des ressources nécessaires pour redémarrer.
C’est l’un des motifs pour lesquels le nombre de nœuds ne constitue qu’une partie de la conception.
Pourquoi le quorum explique la compatibilité des trois nœuds
Proxmox VE utilise Corosync pour la communication du cluster et pmxcfs, son système de fichiers distribué pour la configuration. Les nœuds fonctionnent via un système de quorum basé sur des votes. Dans une configuration conventionnelle, chaque nœud apporte un vote.
Dans un cluster constitué de trois serveurs, la situation de base est simple :
| État | Nœuds disponibles | Votes | Majorité |
|---|---|---|---|
| Fonctionnement normal | 3 | 3 sur 3 | Oui |
| Panne d’un nœud | 2 | 2 sur 3 | Oui |
| Un seul nœud restant | 1 | 1 sur 3 | Non |
L’objectif du quorum n’est pas d’augmenter la performance, mais d’empêcher différentes parties d’un cluster divisé de continuer à agir comme si chacune détenait l’autorité sur les mêmes ressources.
Ce genre de situation peut entraîner le connu split brain, particulièrement dangereux lorsque plusieurs serveurs peuvent modifier simultanément des ressources partagées.
C’est pourquoi trois nœuds offrent une majorité naturelle : si l’un disparaît, les deux autres peuvent toujours s’accorder.
Alors, un cluster de deux nœuds est-il incorrect ?
Pas nécessairement.
Proxmox autorise des configurations à deux nœuds et recommande spécifiquement l’utilisation d’un QDevice pour de petits clusters nécessitant une disponibilité accrue.
Le QDevice fournit un vote externe sans nécessiter l’ajout immédiat d’un troisième serveur de virtualisation complet. Proxmox le recommande pour des clusters à deux nœuds et déconseille généralement son ajout dans des clusters impairs en raison du comportement différent du système de votes.
Une architecture comprenant deux hôtes et un QDevice peut avoir beaucoup de sens lorsque le coût d’un troisième nœud de calcul n’est pas justifié.
Mais il faut redéfinir certains concepts : le QDevice aide à résoudre le quorum, il n’apporte pas de CPU ou de RAM pour exécuter des machines virtuelles.
Si l’un des deux serveurs tombe en panne, l’autre devra prendre en charge la charge qui doit être récupérée. Si celle-ci dépasse ses capacités, la présence du troisième vote ne résoudra pas cette limitation.
L’erreur de pousser tous les serveurs à leur pleine capacité
Voici un aspect crucial dans le dimensionnement pour la haute disponibilité.
Supposons un cluster avec trois serveurs et 512 Go de RAM par nœud :
| Nœud | RAM physique |
|---|---|
| PVE01 | 512 Go |
| PVE02 | 512 Go |
| PVE03 | 512 Go |
| Total | 1 536 Go |
La capacité totale de la plateforme est d’environ 1,5 To de mémoire, mais cela ne signifie pas que toute cette mémoire peut être allouée facilement aux machines virtuelles si l’objectif est de conserver de la capacité en cas de perte totale d’un hôte.
Si chaque serveur utilise 500 Go et que PVE01 tombe en panne, il ne reste que 24 Go disponibles sur les deux autres nœuds. Les machines utilisant les ressources de ce serveur disparu auront du mal à redémarrer dessus.
C’est pourquoi une architecture haute disponibilité est souvent conçue en tenant compte d’un N+1.
En termes simples, les ressources restantes doivent suffire pour supporter les charges à maintenir lorsqu’un nœud disparaît.
Cela ne signifie pas nécessairement garder un serveur totalement vide.
Les capacités peuvent être réparties entre tous les nœuds tout en laissant une marge supplémentaire pour le scénario de panne prévu. De plus, toutes les machines ne doivent pas avoir la même priorité.
Une organisation peut décider que les ERP, bases de données, contrôleurs de domaine ou certains services critiques doivent être récupérés en priorité, tandis que les machines de développement, laboratoires ou services secondaires peuvent rester à l’arrêt lors d’une incident.
Le dimensionnement doit se faire en fonction de la consommation et des pics réels, et non simplement en additionnant les vCPU configurées sur toutes les machines virtuelles.
La mémoire est généralement moins flexible. Une plateforme avec CPU disponible mais insuffisance de RAM continuera à rencontrer des problèmes pour récupérer ses charges.
HA ne signifie pas migration en direct
Une confusion courante consiste à croire que haute disponibilité et migration en direct sont synonymes.
Lors d’une migration en direct, la machine virtuelle continue de fonctionner sur le nœud source. Proxmox peut déplacer une VM planifiée vers un autre serveur, par exemple pour effectuer une maintenance.
Une défaillance physique est différente.
Si un hôte tombe en panne de façon inattendue, il n’y a pas de VM en fonctionnement pouvant être migrée de manière ordonnée depuis le serveur d’origine. Le système HA doit alors identifier la panne du nœud, garantir qu’il ne continue pas à utiliser ses ressources et restaurer les charges protégées sur un autre nœud.
La documentation de Proxmox explique que sa pile HA utilise des mécanismes de verrouillage et de surveillance (watchdog) pour permettre la récupération automatique des hôtes gérés par HA après la perte ou la mise en quarantaine d’un nœud.
Ainsi, la HA peut réduire et automatiser la récupération, mais ne garantit pas une interruption zéro.
Les applications nécessitant une disponibilité continue doivent également adopter leur propre architecture avec réplication, clustering de bases de données, équilibreurs de charge ou multiples instances.
Corosync, stockage et réseau font également partie de la haute disponibilité
Avoir trois hôtes avec des ressources suffisantes ne constitue pas à lui seul une architecture complète.
Corosync requiert des communications fiables entre membres du cluster. Proxmox recommande un réseau physique dédié à ce trafic et indique que Corosync privilégie principalement une faible latence et une stabilité, plutôt qu’un débit particulièrement élevé. Une interface dédiée de 1 Gbit/s peut souvent suffire.
Il supporte aussi plusieurs liens de communication. La documentation actuelle prévoit jusqu’à huit réseaux pour Corosync et conseille que la redondance repose sur des chemins physiques distincts.
Une autre question importante se pose : à quoi sert d’avoir trois serveurs redondants si tous dépendent d’un seul switch ?
Il en va de même pour le stockage.
Proxmox peut fonctionner avec différentes architectures : stockage partagé, NFS, iSCSI, Fibre Channel, Ceph, ZFS ou stockage local. Le choix influence la manière dont les migrations sont effectuées et comment une VM peut être récupérée lorsqu’un nœud disparaît.
Pour la haute disponibilité, la documentation de Proxmox recommande un stockage partagé pour les machines virtuelles et conteneurs gérés de cette façon. Il existe également des architectures basées sur un stockage distribué ou répliqué, à étudier selon le scénario.
Ceph mérite une mention particulière puisque trois nœuds apparaissent souvent comme une configuration minimale pratique pour de petites déploiements. Mais que l’on puisse construire Ceph avec trois nœuds ne signifie pas que trois sont adaptés pour toutes les charges. La capacité utile, le nombre de disques, la réplication, le réseau, l’IOPS, la latence, la récupération et le comportement en dégradation doivent être dimensionnés séparément.
Et la sauvegarde alors ?
Un cluster de trois nœuds ne remplace pas les sauvegardes.
La haute disponibilité cherche à maintenir ou restaurer des services en cas de défaillance de l’infrastructure. La sauvegarde répond à d’autres problématiques : suppression accidentelle, corruption, ransomware, erreurs administratives ou la nécessité de restaurer une version antérieure des données.
Proxmox propose Proxmox Backup Server (PBS) pour la protection des machines virtuelles et conteneurs, mais la stratégie doit définir la durée de conservation, l’objectif de point de restauration (RPO), le délai de restauration (RTO), l’emplacement des copies et des tests réguliers de restauration.
Une plateforme peut avoir une excellente HA et une stratégie de sauvegarde inadéquate, ou vice versa.
C’est pourquoi, lors de l’évaluation d’un cluster à trois nœuds, il est souvent plus utile de se demander : qu’est-ce qui doit continuer de fonctionner lorsque l’un des composants disparaît.
À partir de là, il est possible de dimensionner CPU, RAM, stockage, réseau et capacité de récupération.
Trois nœuds offrent une architecture simple pour maintenir le quorum après la perte d’un seul. Mais la haute disponibilité commence vraiment lorsqu’il faut réfléchir à ce qui se passe après ce défaillance.
Si vos charges critiques ne peuvent pas tenir sur les deux nœuds restants, si tous dépendent du même switch ou si le stockage constitue un point unique de défaillance supplémentaire, alors la simple présence de trois nœuds ne garantit pas à elle seule une plateforme hautement disponible.
Questions fréquentes
Proxmox nécessite-t-il obligatoirement trois nœuds ?
Non. Proxmox VE peut fonctionner avec un seul serveur et autorise des clusters de différentes tailles. Pour une HA avec un quorum fiable, Proxmox recommande au moins trois nœuds ; dans de petits clusters à deux nœuds, un QDevice peut être utilisé comme vote supplémentaire.
Que se passe-t-il si un nœud échoue dans un cluster Proxmox de trois serveurs ?
Les deux autres nœuds conservent la majorité des votes. Si les machines sont gérées par HA et que le stockage et les ressources sont suffisants, Proxmox peut restaurer les charges sur les hôtes disponibles.
Faut-il laisser un nœud Proxmox vide pour obtenir un N+1 ?
Pas nécessairement. Les ressources peuvent être réparties entre les trois nœuds, à condition qu’une capacité suffisante en marge soit disponible pour absorber la charge en cas de défaillance d’un nœud.
Un cluster Proxmox de trois nœuds a-t-il besoin de Ceph ?
Non. Ceph est une solution parmi d’autres, et non une nécessité absolue pour créer un cluster Proxmox. La plateforme supporte différentes options de stockage, et le choix doit répondre aux exigences de disponibilité, performance et récupération.