Un serveur tombe. Que se passe-t-il ? Si la réponse est « le service s'arrête », vous avez un problème de haute disponibilité. Dans un monde où chaque minute d'indisponibilité coûte de l'argent et de la crédibilité, concevoir des systèmes capables de résister aux pannes n'est plus une option.
Pourquoi la haute disponibilité ?
Section intitulée « Pourquoi la haute disponibilité ? »Les pannes arrivent. Matériel défaillant, erreur humaine, attaque, pic de charge, mise à jour qui tourne mal. La question n'est pas « si » mais « quand ».
Les conséquences d'une indisponibilité :
- Financières : perte de revenus, pénalités contractuelles (SLA)
- Réputationnelles : perte de confiance des utilisateurs
- Opérationnelles : équipes mobilisées en urgence, dette technique
- Réglementaires : non-conformité (HDS, PCI-DSS exigent des SLA)
La haute disponibilité (HA) vise à minimiser le temps d'arrêt en concevant des systèmes capables de continuer à fonctionner malgré la défaillance d'un ou plusieurs composants.
Qui est concerné ?
Section intitulée « Qui est concerné ? »Ce tableau sert surtout à cadrer les attentes lors des arbitrages. Les trois premiers profils raisonnent en mécanismes (réplication, bascule, quorum) tandis que la direction raisonne en euros par minute d'arrêt. Un projet de haute disponibilité échoue rarement sur la technique ; il échoue quand personne n'a traduit un objectif de SLA en contraintes d'architecture chiffrées.
| Profil | Besoin principal |
|---|---|
| Ops / SRE | Concevoir et maintenir les architectures HA |
| Architecte | Définir les SLA, choisir les patterns de résilience |
| DBA | Réplication, failover des bases de données |
| Direction | Comprendre les coûts vs risques d'indisponibilité |
Les concepts clés
Section intitulée « Les concepts clés »Redondance
Section intitulée « Redondance »Dupliquer les composants critiques pour qu'un autre prenne le relais en cas de panne : serveurs, disques, alimentations, connexions réseau, datacenters.
Failover (basculement)
Section intitulée « Failover (basculement) »Mécanisme automatique qui bascule le trafic vers un système de secours quand le système principal tombe. Peut être local ou géographique.
Répartition de charge (load balancing)
Section intitulée « Répartition de charge (load balancing) »Distribuer les requêtes entre plusieurs instances pour éviter la surcharge d'un seul serveur et permettre la continuité si une instance tombe.
SLA et niveaux de disponibilité
Section intitulée « SLA et niveaux de disponibilité »Le SLA (Service Level Agreement) est l'engagement contractuel de disponibilité. Lisez la colonne « Indisponibilité / mois » en priorité : c'est elle qui détermine ce que votre équipe peut se permettre. À 99,9 %, vous disposez de 43 minutes par mois, de quoi absorber un redémarrage manuel. À 99,99 %, il ne reste que 4 minutes, c'est-à-dire moins que le temps d'un réveil d'astreinte : la bascule doit être entièrement automatique.
| Disponibilité | Indisponibilité / an | Indisponibilité / mois |
|---|---|---|
| 99% (deux 9) | 3,65 jours | 7,3 heures |
| 99.9% (trois 9) | 8,76 heures | 43,8 minutes |
| 99.99% (quatre 9) | 52,6 minutes | 4,4 minutes |
| 99.999% (cinq 9) | 5,26 minutes | 26 secondes |
Chaque 9 supplémentaire coûte exponentiellement plus cher à atteindre, et le saut n'est pas linéaire : passer de trois à quatre 9 divise par dix le budget d'incident annuel autorisé, ce qui impose de supprimer toute intervention manuelle du chemin de bascule. Au-delà de quatre 9, la contrainte devient organisationnelle avant d'être technique : il faut une astreinte et des déploiements progressifs.
Comment ça fonctionne ?
Section intitulée « Comment ça fonctionne ? »La haute disponibilité se construit par couches, et une seule couche non redondée annule le travail fait sur toutes les autres. Les quatre sections suivantes remontent de l'application vers le réseau ; parcourez-les dans cet ordre pour identifier votre point de rupture.
Niveau applicatif
Section intitulée « Niveau applicatif »Tout repose ici sur une propriété : l'application doit être sans état. Un serveur qui garde la session utilisateur en mémoire locale ne peut pas être remplacé sans déconnecter ses utilisateurs, quelle que soit la qualité du load balancer devant lui. C'est la raison d'être de la troisième puce, et c'est le chantier le plus long quand l'application n'a pas été conçue ainsi.
- Instances multiples derrière un load balancer
- Health checks pour détecter les instances défaillantes
- Sessions externalisées (Redis, base de données) pour permettre le failover
Niveau base de données
Section intitulée « Niveau base de données »C'est la couche la plus délicate, parce que c'est la seule où une bascule ratée détruit des données au lieu de simplement interrompre le service. Le choix entre réplication synchrone et asynchrone est un arbitrage entre perte de données acceptable (RPO) et latence d'écriture : le synchrone attend l'accusé de réception du secondaire à chaque transaction, ce qui se ressent immédiatement dès que les deux nœuds sont éloignés.
- Réplication synchrone : chaque écriture confirmée sur le secondaire (0 perte)
- Réplication asynchrone : légère latence, mais meilleure performance
- Clustering : Patroni (PostgreSQL), Galera (MySQL), MongoDB Replica Set
Niveau infrastructure
Section intitulée « Niveau infrastructure »À ce niveau, la question centrale n'est plus « comment basculer » mais « qui décide de basculer ». Un cluster Corosync/Pacemaker tranche par quorum : sans majorité de nœuds joignables, aucun ne s'autoproclame maître. C'est ce mécanisme qui empêche le split-brain, et c'est pourquoi un cluster à deux nœuds a besoin d'un arbitre supplémentaire.
- Clusters de serveurs : Corosync + Pacemaker pour orchestrer le failover
- Stockage répliqué : DRBD, Ceph, solutions SAN
- Multi-datacenter : réplication géographique pour les catastrophes majeures
Niveau réseau
Section intitulée « Niveau réseau »Regardez surtout les temps de bascule, ils diffèrent d'un facteur mille. Une IP flottante portée par Keepalived change de machine en quelques secondes parce que la décision est locale. Un basculement DNS dépend du TTL de l'enregistrement et des caches des résolveurs intermédiaires : comptez plusieurs minutes, parfois davantage si un résolveur ignore votre TTL.
- Load balancers redondants : HAProxy, Keepalived avec IP flottante
- DNS failover : basculement au niveau DNS (plus lent)
- CDN : distribution géographique pour la résilience
Scénario : cluster web haute disponibilité
Section intitulée « Scénario : cluster web haute disponibilité »Une application web critique doit garantir 99.9% de disponibilité.
Architecture mise en place :
- 2 serveurs web derrière HAProxy (actif/passif avec Keepalived)
- PostgreSQL avec réplication synchrone (Patroni)
- DRBD pour le stockage partagé
- Monitoring : alertes si un composant tombe
Test de failover : on arrête le serveur primaire.
- HAProxy détecte l'échec du health check en 3 secondes
- Le trafic bascule sur le secondaire
- Patroni promeut le réplica PostgreSQL en primaire
- Temps d'indisponibilité : < 10 secondes
Pièges courants
Section intitulée « Pièges courants »Les deux premiers pièges sont de loin les plus fréquents en production. La confusion entre HA et DR conduit à des architectures qui survivent à la perte d'un serveur mais pas à celle du datacenter, alors que le contrat promettait les deux. Et un failover jamais testé est une hypothèse, pas une garantie : c'est le jour de l'incident qu'on découvre le mot de passe expiré ou le disque secondaire plein.
- Confondre HA et DR, haute disponibilité ≠ reprise après sinistre (disaster recovery)
- Négliger les tests de failover, un failover non testé est un failover qui échoue
- Single point of failure caché, le load balancer lui-même peut tomber
- Sous-estimer le split-brain, deux nœuds qui se croient maîtres = corruption de données
- Complexité excessive, plus de composants = plus de points de défaillance potentiels
- Oublier la supervision, sans monitoring, vous découvrez la panne avec vos utilisateurs
Outils disponibles
Section intitulée « Outils disponibles »Ces deux guides couvrent les briques que vous installerez en premier sur un cluster Linux classique, et ils se complètent plutôt qu'ils ne se remplacent : Corosync et Pacemaker décident quel nœud est actif, DRBD garantit que le nœud qui prend la main dispose bien des mêmes données. Commencez par le premier, la réplication de stockage n'a d'intérêt qu'une fois la logique de bascule en place.
Outils à explorer
Section intitulée « Outils à explorer »Cette liste n'est pas un catalogue à installer intégralement : chaque entrée répond à une couche précise identifiée plus haut. HAProxy et Keepalived vont ensemble pour le réseau, Patroni traite le cas PostgreSQL, et etcd ou Consul fournissent le magasin de quorum dont Patroni a besoin pour élire un primaire sans risque de split-brain.
- HAProxy, load balancer haute performance
- Keepalived, VRRP pour IP flottante et failover
- Patroni, HA pour PostgreSQL avec failover automatique
- etcd, stockage distribué pour la coordination de cluster
- Consul, service discovery et health checking
À retenir
Section intitulée « À retenir »- Redondance à tous les niveaux, réseau, compute, stockage, données
- Testez régulièrement, chaos engineering, failover planifiés
- Monitoring proactif, détectez les problèmes avant qu'ils ne deviennent des pannes
- Définissez vos SLA, 99.9% vs 99.99% = 8h vs 52min d'indisponibilité par an
- Documentez les procédures, un runbook clair accélère la récupération
Prochaines étapes
Section intitulée « Prochaines étapes »La haute disponibilité se construit à chaque étage de la pile. Les trois pages ci-dessous prolongent celle-ci sur les couches qui portent le plus de pannes : le réseau, qui décide de ce qui reste joignable pendant un incident, l'orchestration, qui redémarre et replace les charges sans intervention, et le modèle Zero Trust, qui évite qu'une bascule ouvre involontairement un accès.