Rester en ligne quand une machine tombe.
La haute disponibilité (HA) est l'ensemble des techniques qui garantissent qu'un service reste accessible malgré la panne d'un composant. Le principe est toujours le même : identifier les points de panne uniques et les redonder.
Le vocabulaire de la HA
Six notions suffisent à comprendre toute architecture haute disponibilité.
SPOF (point de panne unique)
Tout composant dont la panne suffit à mettre le service à terre : un unique serveur web, une seule base de données, un seul disque, un seul lien réseau. La HA consiste à identifier puis éliminer les SPOF.
Redondance N+1
Prévoir au moins un composant de plus que le strict nécessaire. Si deux frontaux suffisent à absorber la charge, on en déploie trois : la panne de l'un ne dégrade pas le service.
Failover (bascule)
Le mécanisme qui redirige automatiquement le trafic ou le rôle actif vers un composant sain quand le composant en service tombe. Le failover peut être automatique (idéal) ou manuel.
RTO / RPO
RTO (Recovery Time Objective) : durée d'interruption tolérée avant retour du service. RPO (Recovery Point Objective) : quantité de données que l'on accepte de perdre (fenêtre entre deux points de cohérence). La HA vise un RTO proche de zéro.
Health check
Sonde qui vérifie en continu qu'un composant répond correctement (pas seulement qu'il est allumé). Un frontal qui renvoie des erreurs 500 doit être sorti de la rotation même s'il « répond ».
Quorum & split-brain
Dans un cluster, le quorum (majorité) évite que deux moitiés isolées se croient chacune seule maître (split-brain), ce qui corromprait les données. D'où les clusters en nombre impair.
Les « neuf » de disponibilité
La disponibilité s'exprime en pourcentage de temps de fonctionnement. Chaque neuf supplémentaire divise le temps d'indisponibilité toléré — et augmente fortement le coût.
| Disponibilité | Indispo. / an | Indispo. / mois | Indispo. / semaine |
|---|---|---|---|
| 99 % | 3,65 jours | 7,2 h | 1,68 h |
| 99,9 % (« trois neuf ») | 8,77 h | 43,8 min | 10,1 min |
| 99,99 % (« quatre neuf ») | 52,6 min | 4,4 min | 1,01 min |
| 99,999 % (« cinq neuf ») | 5,26 min | 26 s | 6 s |
Le bon objectif n'est pas « le maximum » mais « le juste niveau » : pour une boutique, passer de 99 % à 99,9 % évite ~3 jours de panne par an et se rentabilise vite ; viser 99,999 % relève d'une autre échelle d'investissement.
Le coût d'une indisponibilité
Avant de chiffrer une architecture HA, on estime ce que coûte une heure de panne : chiffre d'affaires perdu, coût de gestion de crise, atteinte à la réputation, pénalités contractuelles (SLA). Cette valeur détermine le niveau de HA rationnel.
Ce que génère une heure d'activité en ligne
Heures de panne évitées par an
Budget HA justifiable
Une architecture HA complète
Chaque couche est redondée et dispose de son propre mécanisme de bascule. Aucune machine seule ne peut mettre le service à terre.
Redonder couche par couche
On rend chaque couche indépendamment tolérante à la panne. Trois pages détaillent les mécanismes.
HA des frontaux web
Load balancing, health checks, VIP flottante et frontaux sans état pour absorber la charge et survivre à la perte d'un serveur.
Voir le détailHA des base de données
Réplication, failover automatique, cluster Galera et read/write split : la couche la plus délicate, car elle porte l'état.
Voir le détailHA des stockage & données
Stockage partagé/répliqué, objet S3, sauvegardes 3-2-1 : garantir que les fichiers survivent et restent cohérents.
Voir le détailQuestions fréquentes
Haute disponibilité et sauvegarde, c'est pareil ? +
Non, et c'est une confusion coûteuse. La sauvegarde protège contre la perte de données (on restaure une copie après un incident) : le service est interrompu pendant la restauration. La haute disponibilité protège contre l'interruption de service (un composant tombe, un autre prend le relais immédiatement). Les deux sont nécessaires et complémentaires : la HA ne remplace jamais une sauvegarde.
La HA garantit-elle 100 % de disponibilité ? +
Non. Aucune architecture n'atteint 100 %. On raisonne en « neuf » : 99,9 % autorise 8,77 h d'indisponibilité par an, 99,99 % environ 52 minutes, 99,999 % environ 5 minutes. Chaque neuf supplémentaire coûte nettement plus cher. L'objectif est de trouver le bon niveau pour votre activité, pas le maximum théorique.
Faut-il tout redonder d'un coup ? +
Non. On commence généralement par le point de panne unique le plus risqué. Souvent la base de données (état non répliqué) ou le stockage des fichiers. On peut redonder couche par couche : frontaux web, puis base de données, puis stockage.
Combien de serveurs faut-il pour de la HA ? +
Au minimum deux par couche que l'on veut rendre redondante, plus un mécanisme de bascule. Pour un cluster à quorum (Galera, etcd), on préconise un nombre impair (3, 5) afin d'éviter les situations de split-brain où deux moitiés se croient seules.
Évaluons votre besoin de redondance
On analyse votre architecture actuelle, on identifie les points de panne uniques et on propose un plan de redondance chiffré.
Étudier ma redondanceExplorer le pôle infogérance & haute disponibilité
Infogérance de serveur
Supervision, mises à jour, sauvegardes testées, durcissement et réponse à incident.
Exploitation & supervisionReprise d’infogérance
Vous changez d’infogéreur ? On reprend l’existant, même sans documentation ni accès complets.
Depuis un autre prestataireHA des frontaux web
Répartition de charge, health checks, VIP flottante, frontaux stateless.
Load balancing & failoverHA de la base de données
Réplication, failover automatique, cluster Galera, read/write split.
Réplication & basculeHA du stockage
Stockage partagé/répliqué, objet S3, sauvegardes 3-2-1, redondance géo.
Fichiers & données répliqués