HA à 2 étages :
2 VM en cluster sur 2 hyperviseurs, les 4 pièges
C'est la meilleure architecture de haute disponibilité sur un site unique. C'est aussi la plus facile à rater — parce que les deux étages ne se parlent pas, et que là où ils s'ignorent, ils se contredisent.
Sommaire
1. Pourquoi empiler : chaque étage couvre l'angle mort de l'autre
L'architecture consiste à installer un cluster de service dans deux machines virtuelles, elles-mêmes hébergées sur des hyperviseurs en haute disponibilité. On ne l'adopte pas pour additionner deux sécurités : on l'adopte parce que chacune couvre précisément ce que l'autre laisse passer.
Le cluster de service seul
Il bascule en quelques secondes, mais après la panne il ne reste qu'un seul nœud debout. Le service fonctionne, sans aucune redondance, jusqu'à ce qu'un humain reconstruise le membre perdu. Vous avez survécu à la première panne et vous êtes désarmé devant la seconde.
L'étage hyperviseur seul
Il reconstruit tout seul, mais sa granularité est trop grossière : il faut plusieurs minutes, les sessions sont coupées, et surtout il ne voit rien d'un applicatif mort dans une machine allumée. Détaillé au niveau 1.
Les deux empilés
Le service bascule en quelques secondes — les utilisateurs voient au pire une reconnexion — puis l'étage du dessous relance la machine perdue sur un autre hyperviseur, et le cluster retrouve ses deux membres sans que personne n'intervienne.
C'est cette séquence en deux temps qui fait toute la valeur du montage : bascule immédiate, puis reconstruction automatique de la redondance. Aucun des deux étages ne sait faire les deux, et c'est pour ça qu'on ne choisit pas entre eux.
2. Piège n°1 — L'anti-affinité
Deux machines virtuelles qui forment un cluster n'apportent aucune redondance si elles tournent sur le même hyperviseur. C'est évident dit comme ça. Ça l'est beaucoup moins six mois après la mise en production.
Par défaut, rien n'empêche l'étage du dessous de les placer côte à côte. Une migration de maintenance, un redémarrage de nœud, une relance automatique après incident : à chacune de ces occasions, les deux membres peuvent se retrouver au même endroit. Il faut donc déclarer une règle qui interdit cette cohabitation, et surtout vérifier qu'elle est toujours respectée.
Le scénario silencieux
La règle existe. Une maintenance a exigé de vider un nœud, l'opérateur l'a temporairement contournée, et personne ne l'a rétablie. Le service répond parfaitement, la supervision est au vert, le cluster applicatif voit ses deux membres en bonne santé. Rien, absolument rien, n'indique que la redondance a disparu — jusqu'au jour où l'hyperviseur qui les héberge tous les deux tombe, et où l'architecture qui a coûté trois serveurs se comporte moins bien qu'une machine seule.
C'est la raison pour laquelle nous vérifions le placement effectif des membres dans notre exploitation courante, et pas seulement l'existence de la règle. Une contrainte déclarée mais contournée est plus dangereuse qu'une contrainte absente, parce qu'elle donne l'illusion d'être couvert.
3. Piège n°2 — Les deux quorums
Il y a deux mécanismes de décision empilés, et ils ne se parlent pas. Le cluster d'hyperviseurs compte ses nœuds physiques ; le cluster de service compte ses membres applicatifs. Ils n'ont ni les mêmes seuils, ni les mêmes délais, ni la même vision du réseau.
Tant que tout va bien, cette indépendance ne se voit pas. Elle se voit lors d'une partition réseau — le cas où le réseau se coupe en deux sans qu'aucune machine ne meure — et c'est là que les deux étages peuvent conclure des choses différentes du même événement.
Le scénario à dérouler
Trois hyperviseurs, deux VM en cluster réparties sur deux d'entre eux. Le lien réseau isole le troisième nœud, qui héberge l'un des deux membres.
- • Étage hyperviseur : deux nœuds sur trois se voient encore, ils ont la majorité. Ils décident que le troisième est perdu et qu'il faut relancer sa VM chez eux.
- • Étage service : à deux membres, aucun n'a la majorité tout seul. Sans arbitre, chacun peut se croire légitime — ou, plus prudemment, les deux se mettent en retrait et le service s'arrête alors qu'aucune machine n'est tombée.
- • Le nœud isolé, lui, continue de faire tourner sa VM : de son point de vue, c'est le reste du monde qui a disparu.
La conclusion pratique est nette : un cluster de service à deux membres a besoin de son propre arbitre, indépendant de celui des hyperviseurs. Un témoin léger, un troisième membre, ou un mécanisme d'isolation qui tranche par la force — mais quelque chose. Compter sur le quorum de l'étage du dessous pour protéger l'étage du dessus est une erreur d'architecture courante, et elle ne se révèle que le jour où le réseau se coupe.
4. Piège n°3 — La guerre des timeouts
Les deux étages détectent la même panne, à des vitesses différentes. Si l'ordre dans lequel ils réagissent n'a pas été décidé, c'est le hasard qui tranche — et le hasard produit des situations que personne n'a prévues.
Le cluster de service détecte en quelques secondes : c'est sa raison d'être. L'étage hyperviseur détecte en dizaines de secondes, volontairement, pour ne pas relancer des machines à chaque à-coup réseau. Quand ces deux échelles se chevauchent mal, deux scénarios apparaissent.
La double bascule
Le cluster de service a déjà basculé sur le membre survivant. L'étage hyperviseur, plus lent, relance ensuite la VM perdue. Celle-ci redémarre, rejoint le cluster, et selon la configuration peut reprendre le rôle actif — provoquant une seconde interruption, cette fois sans aucune panne pour la justifier.
Le nœud zombie
Pire : la VM exclue du cluster tourne encore quelque part, parce que l'hyperviseur qui l'héberge n'était pas mort mais seulement injoignable. Elle revient dans le réseau en croyant détenir toujours son rôle, et deux instances se disputent la même adresse ou le même disque.
La règle que nous appliquons
Le délai de détection applicatif doit être franchement inférieur à celui de l'hyperviseur — un rapport de trois à cinq, pas de vingt pour cent. L'étage rapide bascule et fixe la situation ; l'étage lent constate ensuite et se contente de reconstruire. Chacun dans son rôle, dans cet ordre, et les deux scénarios ci-dessus disparaissent.
5. Piège n°4 — Le fencing en cascade
Les deux étages disposent chacun d'un moyen d'isoler un membre douteux : le cluster de service peut couper l'accès d'une VM ou l'éteindre, l'étage hyperviseur peut couper l'alimentation d'un serveur entier. Quand les deux décident d'agir en même temps, la question devient : lequel a le dernier mot ?
Le cas problématique est facile à décrire. Le cluster de service veut éteindre la VM qu'il juge défaillante. Au même moment, l'étage hyperviseur veut redémarrer le serveur physique qui l'héberge, parce qu'il ne répond plus à ses propres sondes. Selon l'ordre, on obtient soit une VM proprement isolée puis relancée ailleurs — le résultat souhaité — soit un serveur redémarré au milieu d'une opération d'isolation, avec un cluster de service qui n'obtient jamais la confirmation qu'il attendait et qui refuse donc de basculer.
Le principe de conception
L'isolation applicative doit être plus rapide et plus fine que celle de l'hyperviseur, et ne jamais dépendre d'un composant que l'étage du dessous peut couper au même instant. En pratique cela veut dire : un mécanisme d'isolation qui agit sur la VM elle-même plutôt que sur son hôte, et une temporisation côté hyperviseur suffisante pour laisser l'étage applicatif conclure. Ce n'est pas une question d'outil, c'est une question d'ordre.
6. L'architecture de référence que nous déployons
Trois hyperviseurs, deux machines virtuelles en cluster, un témoin. C'est la configuration qui résout les quatre pièges en même temps, et c'est celle que nous proposons par défaut.
Étage bas — 3 hyperviseurs
- • Trois nœuds : la majorité existe toujours
- • Une règle d'anti-affinité sur les deux VM du cluster
- • Un stockage atteignable depuis les trois
- • Détection volontairement lente, pour ne réagir qu'aux vraies pannes
Étage haut — 2 VM + 1 témoin
- • Deux membres actifs, sur deux hyperviseurs distincts
- • Un témoin léger sur le troisième, qui ne fait qu'arbitrer
- • Détection rapide, trois à cinq fois plus que l'étage bas
- • Isolation agissant sur la VM, pas sur son hôte
Le témoin est le composant le plus rentable de l'ensemble : il ne porte aucune charge, il coûte presque rien, et il supprime à lui seul l'ambiguïté du piège n°2. C'est aussi celui qu'on oublie le plus souvent dans les architectures que nous reprenons.
Une variante fréquente quand trois nœuds applicatifs sont disponibles : au lieu d'une seule adresse partagée, on en déclare deux ou trois, réparties entre les membres et publiées ensemble dans le DNS. On obtient une répartition de charge approximative en plus de la bascule, sans ajouter le moindre composant central.
À partir de quel coût d'arrêt ce montage devient rentable ?
Chiffrez une heure d'indisponibilité, le reste du calcul en découle.
7. Coût réel et seuil de rentabilité
Trois lignes à distinguer, parce qu'elles ne se facturent pas de la même façon et qu'on les confond souvent dans les comparatifs.
| Poste | Qui le paie | Comment |
|---|---|---|
| Matériel | Le client, en direct chez l'hébergeur | Trois serveurs au lieu d'un, plus le réseau interne |
| Conception et déploiement | Prestation RDEM | Sur devis, base 150 € HT/heure |
| Exploitation | Forfait d'infogérance | À partir de 150 € HT/mois/serveur, dégressif dès le 2e nœud |
Le seuil de rentabilité ne se calcule jamais dans l'absolu : il se calcule contre le coût d'une heure d'arrêt. Une entreprise qui perd quelques centaines d'euros par heure d'indisponibilité n'a aucune raison de payer trois serveurs ; une autre qui en perd plusieurs milliers a déjà amorti l'écart au premier incident évité. C'est cette comparaison, et elle seule, qui doit décider. Voir les formules d'infogérance.
8. Quand c'est surdimensionné
Nous déconseillons régulièrement cette architecture, et il vaut mieux le dire ici que le découvrir en cours de projet. Trois signaux indiquent qu'elle est de trop.
- • Une coupure de cinq minutes ne coûte rien. Si l'activité tolère un redémarrage, le niveau 1 suffit, coûte deux serveurs de moins et se maintient bien plus facilement.
- • L'applicatif ne sait pas fonctionner à deux. Beaucoup de logiciels métier supposent une instance unique. Les mettre en cluster demande alors un travail d'adaptation qui dépasse largement le coût de l'infrastructure, quand il est possible.
- • Personne ne testera jamais la bascule. Une architecture à deux étages qu'on ne teste pas est plus fragile qu'une architecture simple, parce qu'elle a quatre mécanismes qui peuvent se dégrader silencieusement au lieu d'un.
Dans ces cas, redescendre au niveau 1 est la bonne décision. À l'inverse, si le scénario qui vous inquiète est la perte d'un site entier, ce n'est pas un étage supplémentaire qu'il faut mais une répartition entre plusieurs sites — voir les quatre architectures.
Questions fréquentes
Faut-il trois hyperviseurs pour deux VM en cluster ?
Oui, et pour deux raisons distinctes qu'on confond souvent. La première tient à l'étage hyperviseur : à trois nœuds, le cluster peut décider seul qui redémarre quoi, ce qu'il ne peut pas faire à deux. La seconde tient à la capacité : avec deux hyperviseurs et deux VM réparties, la perte d'un nœud met les deux VM sur la même machine, et vous n'avez plus de redondance réelle même si le service continue de répondre. Le troisième nœud offre une destination qui préserve la séparation.
Que se passe-t-il si les deux VM atterrissent sur le même hyperviseur ?
Le service continue de fonctionner parfaitement, et c'est exactement ce qui rend la situation dangereuse. Le cluster applicatif voit deux nœuds en bonne santé, la supervision est au vert, personne n'est alerté. Mais la redondance est devenue fictive : la panne du seul hyperviseur qui les héberge fait tomber les deux membres simultanément, et l'architecture à deux étages se comporte alors moins bien qu'un simple serveur seul, parce qu'elle a coûté trois fois plus cher pour le même résultat. C'est le rôle de la règle d'anti-affinité, et de sa vérification régulière.
Faut-il désactiver la haute disponibilité de l'hyperviseur quand on a un cluster de service ?
Non, mais il faut la subordonner. Les deux étages doivent réagir dans le bon ordre : le cluster de service, qui détecte en quelques secondes, bascule en premier ; l'hyperviseur, qui détecte en dizaines de secondes, se contente ensuite de reconstruire la redondance en relançant la VM perdue ailleurs. Désactiver l'étage hyperviseur vous priverait de cette reconstruction automatique et vous laisserait durablement sans redondance après le premier incident. Ce qu'il faut régler, ce sont les délais, pas l'existence des mécanismes.
Combien coûte une architecture de haute disponibilité à deux étages ?
Il y a trois lignes à distinguer. Le matériel, acheté en direct par le client : trois hyperviseurs plutôt qu'un, plus le réseau interne qui les relie. La conception et le déploiement, facturés sur devis à 150 € HT de l'heure, parce que le périmètre dépend entièrement de l'existant et de l'applicatif. Et l'exploitation, à partir de 150 € HT par mois et par serveur, avec un tarif dégressif dès le deuxième nœud d'un même cluster. Le seuil de rentabilité se calcule contre le coût d'une heure d'arrêt, pas dans l'absolu.
Cette architecture protège-t-elle d'une panne de datacenter ?
Non, si les trois hyperviseurs sont dans la même salle. Une architecture à deux étages couvre remarquablement bien la perte d'une machine et la perte d'un service, mais sa redondance s'arrête aux limites du site : une coupure électrique généralisée, un incident de refroidissement ou un sinistre emportent les trois nœuds ensemble. Couvrir ce scénario relève d'une autre logique, celle de la répartition entre plusieurs sites, avec les contraintes de latence et de coût qui vont avec.
Votre cluster est-il encore redondant aujourd'hui ?
Nous auditons les architectures existantes : placement effectif des membres, arbitrage, délais de détection, isolation. Souvent, la surprise n'est pas dans la conception mais dans ce qu'elle est devenue.
Demander un audit