Haute disponibilité infogérée
De 4 h à 10 s de bascule
Quatre architectures, quatre pannes absorbées, quatre budgets. Voici ce que nous déployons et surtout ce que nous exploitons chez nos clients — avec les temps de bascule réels, pas ceux des plaquettes.
La haute disponibilité n'est pas un produit, c'est un assemblage
On n'achète pas « de la haute disponibilité » comme on achète un serveur. Les briques qui la composent — keepalived, Pacemaker, la HA d'un hyperviseur, un démon de routage — sont toutes open source et gratuites. Ce qui se paie, c'est de choisir le bon assemblage, de l'emboîter sans créer de nouveaux points de panne, et de le tenir dans la durée. Installer keepalived prend vingt minutes ; ce n'est pas ça que vous payez.
Ce que ça absorbe, et ce que ça n'absorbe pas
La haute disponibilité répond à une seule question : comment ne pas tomber quand un composant meurt ? Elle ne répond pas à comment revenir après un sinistre ? — c'est la reprise, et elle repose sur la sauvegarde. Les deux se paient séparément parce qu'elles couvrent des risques opposés : une panne matérielle d'un côté, une erreur humaine ou un ransomware de l'autre. Face au second, la haute disponibilité travaille même contre vous, en répliquant fidèlement la donnée corrompue.
Pour la partie reprise et sauvegarde, tout est détaillé sur NimbusBackup et sur notre article dédié au plan de reprise avec Proxmox. Cette page-ci ne parle que de continuité.
Ce que ça change par rapport à une GTR
Une garantie de temps de rétablissement engage un délai d'intervention humaine : quelqu'un est prévenu, se connecte, diagnostique, répare. La haute disponibilité, elle, supprime le besoin de cette intervention pour toute une classe de pannes — le service bascule seul, et l'équipe intervient ensuite à froid pour reconstruire la redondance. Les deux sont complémentaires : on garde la GTR pour tout ce que l'automatisme ne sait pas traiter, c'est-à-dire l'essentiel des incidents réels.
La question préalable : combien vous coûte une heure d'arrêt ?
C'est la seule question qui permette d'arbitrer honnêtement. Une architecture qui divise le temps de bascule par cinquante coûte plus cher qu'une architecture qui le divise par cinq — et pour beaucoup d'entreprises, passer de quatre heures à cinq minutes suffit largement, tandis que descendre à dix secondes ne se justifie pas. Tant qu'on n'a pas chiffré le coût d'une heure d'indisponibilité, on compare des architectures dans le vide.
Le calcul est rapide et il change souvent la conversation : notre calculateur de coût d'indisponibilité donne un ordre de grandeur en deux minutes, à partir de votre chiffre d'affaires et de votre effectif.
Les 4 architectures que nous déployons
Elles ne se classent pas par technologie mais par la panne qu'elles absorbent — et surtout par ce qui la détecte. C'est cette différence-là qui décide de tout le reste.
| Niveau | Ce qu'on absorbe | Ce qui le détecte | Bascule |
|---|---|---|---|
| 1 · Relance de VM | La perte d'un hyperviseur | Le cluster : un nœud devient muet | 4 h → 5 min |
| 2 · Bascule de service | La perte d'une instance — matériel, OS ou service | Le pair : le service ne répond plus | 5 min → 10 s |
| 3 · Deux étages | Les deux, et leurs angles morts mutuels | Les deux étages, à leur granularité | Quelques secondes |
| 4 · Anycast interne | La perte d'un site ou d'un VLAN | Le routage : la route disparaît | Convergence du routage |
1. Relancer la VM ailleurs
Un hyperviseur meurt, ses machines virtuelles redémarrent seules sur les nœuds survivants. Nous installons les trois prérequis qui le rendent possible : au moins trois nœuds pour que le cluster décide sans ambiguïté, un stockage partagé ou répliqué pour que la VM soit démarrable ailleurs, et un mécanisme d'isolation qui garantit qu'un nœud douteux ne redémarre pas de son côté.
Sans ce dispositif, il faut restaurer : comptez une à quatre heures, dont une bonne partie à attendre que quelqu'un s'aperçoive du problème. Avec, comptez deux à cinq minutes et personne n'a besoin de s'en apercevoir. Attention à ce que ça ne fait pas : la VM redémarre, elle ne bascule pas — les sessions en cours sont perdues, et un applicatif mort dans une VM allumée ne sera jamais détecté à ce niveau.
2. Faire basculer le service
Deux nœuds se surveillent mutuellement et se partagent une adresse IP flottante. Celui qui répond la porte ; s'il cesse de répondre, l'autre la reprend en une à trois secondes. Le client ne voit qu'une adresse, et ne sait pas qu'il y a deux machines derrière.
Contrairement à une idée répandue, ce niveau absorbe aussi la panne matérielle : deux serveurs physiques suffisent, sans aucun hyperviseur — c'est même le montage historique. Ce qui le distingue du niveau 1 n'est pas la nature de la panne mais la granularité : ici, c'est le service qui est surveillé. Disque mort, noyau figé, processus planté : la réaction est la même.
3. Empiler les deux
Un cluster de service installé dans des machines virtuelles, elles-mêmes posées sur des hyperviseurs en haute disponibilité. Chaque étage couvre l'angle mort de l'autre : le service bascule en quelques secondes, puis la redondance se reconstruit toute seule quand la machine perdue redémarre ailleurs.
C'est notre architecture de référence quand la coupure elle-même est inacceptable — et c'est aussi la plus facile à rater. Les deux étages ne se parlent pas : il faut déclarer une règle qui interdit aux deux VM d'atterrir sur le même hyperviseur, accorder les délais de détection pour qu'ils ne se contredisent pas, et décider lequel des deux a le dernier mot quand ils veulent isoler un nœud en même temps.
4. Sortir du site
Un service d'infrastructure — résolveur DNS interne, collecteur de logs, serveur RADIUS, proxy sortant — présent dans chaque site et chaque VLAN sous une seule adresse. Chaque instance annonce cette adresse au réseau ; celle qui tombe cesse simplement d'annoncer, et le routage envoie le trafic ailleurs.
Aucun besoin d'internet, de transit ni de numéro d'AS : les protocoles de routage interne suffisent. Le piège est ailleurs, et il est silencieux : la bascule est automatique, la capacité ne l'est pas. Si chaque site est dimensionné pour sa propre charge, le survivant absorbe la charge en plus de la sienne et s'écroule sans bruit.
Temps de bascule et portée, mécanisme par mécanisme
On ne choisit pas vraiment un mécanisme : on choisit une portée, et la portée impose le mécanisme, donc le temps de bascule. C'est ce qui explique l'ordre des quatre niveaux ci-dessus.
| Mécanisme | Temps de bascule | Portée |
|---|---|---|
| keepalived (VRRP) | De quelques centaines de millisecondes à quelques secondes, selon les temporisateurs configurés | Même domaine de diffusion : intra-datacenter, ou L2 étendu par VXLAN |
| Heartbeat, Corosync, CARP | Identique — c'est la même famille de mécanisme, un battement et un seuil de silence | |
| HA hyperviseur | Même détection (même couche en dessous), plus la confirmation d'isolation et le démarrage de la machine virtuelle → 2 à 5 min bout en bout — à condition que la VM démarre proprement. Une vérification de système de fichiers sur un gros volume, ou un disque chiffré qui attend une phrase de passe, font sauter cette estimation | |
| IGP (OSPF, IS-IS) | Immédiat quand c'est un port dédié qui tombe — le lien physique fait foi. Quelques secondes sinon, le temps des temporisateurs | Votre propre réseau routé : de quelques kilomètres à l'échelle nationale, selon les liens dont vous disposez — fibre noire, MPLS, liaisons opérées. Ce n'est pas le protocole qui limite, c'est la latence |
| BGP | 30 s en configuration agressive, 180 s avec les temporisateurs par défaut | Mondiale |
La contrainte qui décide vraiment : la latence, et elle se paie à chaque écriture
Élargir la portée ne coûte pas que du temps de bascule. Avec une réplication synchrone entre deux sites — un miroir de blocs type DRBD, par exemple — une écriture n'est confirmée à l'applicatif que lorsque l'autre site l'a acquittée. 15 ms de latence entre les deux sites, c'est 15 ms ajoutées à chaque écriture. Pas en moyenne : à chacune.
L'arithmétique est brutale et elle ne se négocie pas. Une transaction qui enchaîne dix écritures séquentielles paie 150 ms de réseau pur, avant même que le disque ait travaillé. Un traitement qui en fait des milliers passe d'une poignée de secondes à plusieurs minutes. Ce n'est pas une dégradation progressive qu'on absorbe en ajoutant du matériel : c'est un plancher imposé par la vitesse de la lumière et le tracé de la fibre.
Mais toutes les réplications synchrones ne paient pas au même rythme, et c'est ce qui décide de l'architecture. Un miroir de blocs paie à chaque écriture, parce qu'il ne sait rien de ce qui se passe au-dessus de lui. Une réplication synchrone applicative comme un cluster Galera comprend la notion de transaction : elle regroupe les modifications et ne se synchronise qu'au moment de la validation. La même transaction à dix écritures y coûte un aller-retour, pas dix. À latence identique, l'un devient inutilisable là où l'autre reste confortable — c'est pourquoi on remonte la réplication au niveau du moteur dès que les sites s'éloignent.
C'est donc la latence, et non le budget, qui fixe la limite de ce qui est réalisable. Elle se mesure avant de concevoir, pas après — et quand elle interdit le synchrone, la réponse n'est pas d'insister mais de passer en réplication asynchrone et d'assumer la perte de données qui va avec.
Les outils que nous utilisons
Tous open source, tous éprouvés, aucun sous licence. Nous les déployons, nous les exploitons, et pour certains nous contribuons à leur code.
| Outil | Ce qu'il fait chez nos clients | Niveau |
|---|---|---|
| HA Proxmox VE[1] | Relance une machine virtuelle sur un autre nœud. Détaillé sur notre site Proxmox. | 1 |
| Proxmox Backup Server[2] | Rend la VM restaurable ailleurs. Détaillé sur NimbusBackup. | 1 / reprise |
| keepalived[3] | Déplace une adresse IP entre deux nœuds, selon la norme VRRP[4]. Le même démon sait aussi faire de la répartition de charge en couche 4, via IPVS/LVS[5]. | 2 |
| Pacemaker & Corosync[6] | Ordonnance les ressources, arbitre le quorum et isole les nœuds défaillants, quand une simple bascule d'IP ne suffit plus. | 2 |
| Galera[7] & replication-manager[8] | Réplication synchrone et bascule orchestrée pour MariaDB. Détaillé sur notre site MariaDB. | 2 (données) |
| FRRouting[9] / BIRD[10] | Annonce un service depuis plusieurs sites du réseau interne. Nous l'utilisons aussi pour notre propre réseau, et nous contribuons à son code. | 4 |
| Monitoring & astreinte | Détecte ce que l'automatisme ne détecte pas — et vérifie que la redondance est encore réelle. | Tous |
Comment nous choisissons
PME sur un seul site
Une interruption de quelques minutes est tolérable, une demi-journée ne l'est pas. Le niveau 1 suffit presque toujours, et il a un avantage décisif : le dispositif qui permet de relancer une VM ailleurs est exactement celui qui constitue votre plan de reprise. Un seul investissement, deux bénéfices.
E-commerce, SaaS
Chaque minute d'arrêt se compte en commandes perdues, et une bascule qui coupe les sessions en cours coûte cher en paniers abandonnés. Le niveau 3 se justifie : bascule en secondes, sessions préservées quand l'applicatif le permet, et redondance reconstruite automatiquement.
Multi-site, secteur régulé
Plusieurs sites, plusieurs VLAN, des services d'infrastructure dont tout le reste dépend. Le niveau 4 devient pertinent : un résolveur ou un collecteur qui suit le réseau plutôt que la machine, et qui survit à la perte d'un site sans reconfigurer quoi que ce soit côté client.
Et quand ce n'est pas la panne, mais la charge ?
Tout ce qui précède répond à une seule question : que se passe-t-il quand un composant tombe ? C'est la haute disponibilité. Il en existe une seconde, qui se pose avec les mêmes outils mais pour une raison opposée : que se passe-t-il quand tout fonctionne, mais qu'il y en a trop ?
Les deux se recouvrent largement. Une adresse partagée qui bascule est déjà à un pas d'être une adresse partagée qui distribue ; keepalived, qui porte la VIP, sait aussi piloter le répartiteur de charge du noyau Linux. C'est d'ailleurs le piège nommé plus haut au niveau 4 : la bascule est automatique, la capacité ne l'est pas. Un survivant qui hérite de la charge des autres tombe à son tour, et aucun mécanisme de haute disponibilité ne l'en empêche.
Nous traitons ce second axe séparément, avec la même règle : on commence aussi bas que le besoin le permet, et on ne monte d'un niveau que pour ce que ce niveau apporte en propre — du DNS à plusieurs adresses jusqu'à l'annonce BGP mondiale, en passant par la couche 4 et la couche 7.
Les 5 niveaux de répartition de charge →Ce que nous exploitons ensuite — la partie que personne ne vend
Un cluster n'est pas un objet qu'on installe et qu'on oublie. Il se maintient, il se teste, et il se re-vérifie après chaque maintenance. Le scénario le plus courant que nous rencontrons chez de nouveaux clients n'est pas un cluster mal conçu : c'est un cluster correctement conçu, dont la redondance a disparu en silence des mois plus tôt.
Une migration a rapproché les deux machines virtuelles sur le même hyperviseur. Une mise à jour a désactivé le mécanisme d'isolation. Un certificat a expiré sur le lien de réplication. Rien de tout cela ne déclenche d'alerte si personne ne surveille la redondance elle-même — et pas seulement le service, qui répond parfaitement jusqu'au jour où il s'arrête.
C'est pour ça que nous facturons de l'exploitation et pas seulement du déploiement : tests de bascule réguliers, vérification que la règle d'anti-affinité est toujours appliquée, contrôle du quorum, et astreinte 24/7 pour tout ce que l'automatisme ne sait pas traiter.
Ce qui est inclus, ce qui est en supplément
Conception et déploiement
Facturés sur devis, sur la base de 150 € HT de l'heure. Le périmètre dépend entièrement de votre existant : nombre de nœuds disponibles, hébergeur et ce qu'il permet en matière de réseau privé et d'adresses déplaçables, applicatif à rendre disponible. Nous auditons avant de chiffrer.
Exploitation
À partir de 150 € HT/mois par serveur (formule Pro, 24/7, GTI 4h), avec un tarif dégressif dès le deuxième nœud d'un même cluster. Monitoring, mises à jour, astreinte et tests de bascule inclus. Voir les formules d'infogérance.
Le matériel n'est pas chez nous
Vous achetez vos serveurs en direct chez l'hébergeur de votre choix — OVHcloud, Hetzner, Scaleway ou autre — et vous en restez propriétaire. Nous facturons la conception, le déploiement et l'exploitation, jamais un forfait tout compris qui masquerait le coût réel de votre infrastructure. Le dimensionnement dépend de votre charge, et nous vous aidons à le définir avant l'achat.
Questions fréquentes sur la haute disponibilité
La haute disponibilité remplace-t-elle les sauvegardes ?
Non, et les deux répondent à des problèmes opposés. La haute disponibilité vous protège d'une panne : un composant meurt, un autre prend le relais. La sauvegarde vous protège d'une erreur : une suppression accidentelle, un ransomware, une corruption logicielle. Et dans ce dernier cas, la haute disponibilité travaille contre vous, puisqu'elle réplique fidèlement la donnée corrompue sur tous les nœuds. Une infrastructure sérieuse a les deux.
Combien de serveurs faut-il au minimum pour de la haute disponibilité ?
Cela dépend de ce que le cluster porte. Pour un service sans état — proxy, résolveur DNS, NTP, relais — deux nœuds suffisent très bien : le pire cas d'une coupure réseau est une adresse portée en double quelques secondes, gênant mais non destructeur. Dès qu'il y a des données, il faut un troisième point de vue pour éviter que deux instances écrivent en parallèle et divergent en silence — un témoin léger, un mécanisme d'isolation, ou un troisième nœud complet. Côté hyperviseurs, trois nœuds restent la règle.
La haute disponibilité protège-t-elle d'une erreur humaine ou d'un ransomware ?
Non. Une commande de suppression, un script de purge ou un chiffrement par ransomware sont des opérations valides du point de vue de l'infrastructure : elles sont répliquées, propagées et rendues hautement disponibles avec la même efficacité que le reste. La seule réponse à ces scénarios est la sauvegarde, avec une rétention et une isolation adaptées — c'est le métier de NimbusBackup. La haute disponibilité couvre la panne, pas l'erreur.
Peut-on faire de la haute disponibilité avec un seul serveur dédié ?
Non. Un serveur unique reste un point de panne unique, quel que soit son niveau de redondance interne : deux alimentations, un RAID et de la mémoire ECC réduisent la probabilité d'une panne, ils ne suppriment pas le scénario où la machine s'arrête. Ce qu'on peut faire avec un seul serveur, c'est réduire le temps de reprise en gardant une sauvegarde restaurable ailleurs. C'est utile, et c'est souvent la bonne première étape — mais ce n'est pas de la haute disponibilité.
Faut-il de la haute disponibilité quand on a déjà une GTR 4h ?
Les deux sont complémentaires et ne couvrent pas la même chose. Une GTR engage un délai de rétablissement par une intervention humaine : quelqu'un est prévenu, se connecte, diagnostique et répare. La haute disponibilité supprime le besoin de cette intervention pour toute une classe de pannes : le service bascule seul, en secondes, et l'équipe intervient ensuite à froid pour reconstruire la redondance. On garde la GTR pour tout ce que l'automatisme ne sait pas traiter — c'est-à-dire l'essentiel des incidents réels.
Déployez-vous de la haute disponibilité sur une infrastructure que nous possédons déjà ?
Oui, c'est même le cas le plus fréquent. Nous partons de l'existant : le nombre de serveurs disponibles, l'hébergeur et ce qu'il permet en matière de réseau privé et d'adresses IP déplaçables, et l'applicatif à rendre disponible. Ces trois éléments déterminent l'architecture atteignable, et parfois nous concluons qu'il faut d'abord ajouter un nœud ou activer une option chez l'hébergeur. Le client achète son infrastructure en direct, nous facturons la conception, le déploiement et l'exploitation.