Haute disponibilité
Mise à jour :
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é ?
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é ?
| 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
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)
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)
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é
| 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.
Comment ça fonctionne ?
Niveau applicatif
- 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
- 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
- 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
- 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é
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
- 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
Outils à explorer
- 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
- 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