Calcul de disponibilité et SLA

La haute disponibilité (HA, de l'anglais high availability) est l'ensemble des choix d'architecture et d'organisation qui permettent à un service de rester accessible malgré la panne d'un de ses composants. Elle se mesure par un taux de disponibilité, le pourcentage du temps où le service fonctionne, et elle se promet dans un engagement de service, le SLA. Ce chapitre pose le vocabulaire, montre comment calculer une disponibilité et la convertir en minutes d'arrêt, et présente le fil rouge du cours.

Le fil rouge : l'intranet de Ravelle Conseil

Ravelle Conseil est un cabinet d'expertise comptable fictif de 45 salariés. Son siège compte trois VLAN (utilisateurs, serveurs, administration) derrière un pare-feu pfSense, un commutateur de cœur Cisco, deux contrôleurs de domaine Windows Server qui portent l'annuaire, le DNS et le DHCP, un serveur de fichiers et un intranet documentaire. L'intranet tourne sur deux serveurs web Nginx (WEB1 et WEB2) placés derrière un répartiteur HAProxy (SRV-LB), et son application range ses données dans une base MariaDB, sur SRV-DB. Toutes les machines virtuelles tournent sur un seul hyperviseur.

Au dernier trimestre, l'intranet est tombé trois fois : une mise à jour ratée du répartiteur, un disque plein sur WEB1, une coupure de courant qui a éteint l'hyperviseur. Les collaborateurs ont découvert les pannes avant le service informatique, et la directrice demande « un intranet qui ne tombe plus ». Ta mission tout au long du cours : transformer cette demande floue en un engagement chiffré, trouver ce qui peut tomber, et le doubler intelligemment.

Réseau	VLAN	Adresse	Passerelle	Machines utiles au cours
Utilisateurs	10	10.10.10.0/24	10.10.10.254	Postes en DHCP (étendue .50 à .200)
Serveurs	20	10.10.20.0/24	10.10.20.254	SRV-AD1 .10, SRV-AD2 .11, SRV-FIC .20, SRV-LB .30, WEB1 .31, WEB2 .32, SRV-DB .35, SRV-BAK .40
Administration	30	10.10.30.0/24	10.10.30.254	SW-CORE .2, ZABBIX .20, GLPI .21

Disponibilité, tolérance de panne, continuité : les mots justes

Ces mots se ressemblent, et les confondre coûte des points à l'oral. Retiens ce que chacun promet.

Terme	Ce qu'il désigne	Exemple chez Ravelle Conseil
Disponibilité	Le pourcentage du temps où le service fonctionne comme prévu, sur une période et une plage horaire convenues	L'intranet a fonctionné 99,14 % des heures ouvrées de mars
Haute disponibilité	Une architecture qui réduit l'indisponibilité à quelques minutes ou secondes par panne, grâce à la redondance et au basculement automatique	Deux répartiteurs qui se partagent une adresse virtuelle
Tolérance de panne	La capacité à continuer sans aucune interruption visible malgré une panne	Un RAID 1 : un disque meurt, le serveur ne s'en aperçoit même pas
Redondance	La présence d'un composant en double (ou plus) pour remplacer celui qui tombe	Deux alimentations dans le serveur, deux liens vers le commutateur
Basculement (failover)	Le passage du service du composant en panne vers son remplaçant, automatique ou manuel	Le répartiteur de secours reprend l'adresse virtuelle en 3 secondes
Retour (failback)	Le retour du service sur le composant principal une fois réparé	Le répartiteur principal redevient actif après sa réparation
Mode dégradé	Le fonctionnement avec une partie des composants seulement : le service rend l'essentiel, avec moins de performance ou sans redondance	Un seul serveur web sur deux : l'intranet répond, plus lentement, et la prochaine panne le coupera
Continuité d'activité (PCA)	L'organisation qui permet à l'activité de continuer pendant un sinistre, sans interruption ou presque	La haute disponibilité est l'un de ses moyens techniques
Reprise d'activité (PRA)	La procédure qui permet de redémarrer après un arrêt, en acceptant une coupure et une perte de données bornées	Restaurer les serveurs depuis les sauvegardes sur un nouvel hyperviseur

La disponibilité est aussi le « D » des critères DICP (disponibilité, intégrité, confidentialité, preuve) qui servent à exprimer les besoins de sécurité d'un système d'information : le cours analyse de risques montre comment on l'évalue. Une attaque peut viser la disponibilité (un déni de service, un rançongiciel qui chiffre les serveurs) : la haute disponibilité protège contre les pannes, pas contre tout.

Calculer un taux de disponibilité

Le taux de disponibilité se calcule sur une période et une plage horaire convenues à l'avance :

disponibilité (%) = (durée de service prévue − durée d'indisponibilité) ÷ durée de service prévue × 100

L'indisponibilité est le complément : 100 % moins la disponibilité. Pour la convertir en temps, multiplie-la par la durée de la période.

Exemple. L'intranet de Ravelle Conseil doit fonctionner du lundi au vendredi, de 8 h à 19 h, soit 11 heures par jour. En mars, il y a eu 22 jours ouvrés et deux pannes pendant ces heures : 45 minutes, puis 1 h 20. Une troisième coupure, un samedi, ne compte pas, puisqu'elle est hors de la plage de service.

Durée de service prévue : 22 × 11 = 242 heures, soit 14 520 minutes.
Indisponibilité : 45 + 80 = 125 minutes.
Disponibilité : (14 520 − 125) ÷ 14 520 × 100 ≈ 99,14 %.

Si l'engagement était de 99,5 %, l'intranet avait droit à 0,5 % de 14 520 minutes, soit 72,6 minutes (1 h 12 min 36 s) d'arrêt dans le mois. Avec 125 minutes, l'engagement n'est pas tenu.

Le tableau des « neuf »

On parle de « trois neuf » pour 99,9 %, de « cinq neuf » pour 99,999 %. Chaque neuf supplémentaire divise par dix l'arrêt toléré, et multiplie le coût de l'architecture. Sur un service ouvert 24 heures sur 24 :

Disponibilité	Nom courant	Arrêt toléré par an (365 jours)	Par mois (30 jours)	Par semaine
99 %	« deux neuf »	3 j 15 h 36 min	7 h 12 min	1 h 40 min 48 s
99,5 %		1 j 19 h 48 min	3 h 36 min	50 min 24 s
99,9 %	« trois neuf »	8 h 45 min 36 s	43 min 12 s	10 min 5 s
99,95 %		4 h 22 min 48 s	21 min 36 s	5 min 2 s
99,99 %	« quatre neuf »	52 min 34 s	4 min 19 s	1 min
99,999 %	« cinq neuf »	5 min 15 s	26 s	6 s

Ce tableau dit quelque chose de concret sur l'architecture :

99 % : un seul serveur bien entretenu, avec des sauvegardes, y arrive. Une panne matérielle d'une journée par an reste dans l'enveloppe.
99,9 % : une réparation de plusieurs heures suffit à sortir de l'engagement annuel. Il faut de la redondance sur les éléments fragiles (disques, alimentations) et une supervision qui détecte vite.
99,99 % : moins d'une heure par an. Aucun humain ne peut intervenir à temps : seul un basculement automatique tient cet objectif, et chaque mise à jour doit se faire sans coupure.
99,999 % : cinq minutes par an. C'est l'objectif des opérateurs télécoms, des systèmes de paiement et des grands hébergeurs, avec plusieurs centres de données. La documentation de Proxmox VE rappelle que sa détection et son basculement prennent environ deux minutes, ce qui plafonne la disponibilité d'un cluster de VM à 99,999 % : trois pannes dans l'année (3 × 2 minutes) dépassent déjà l'enveloppe, et deux suffisent si l'on compte le temps de démarrage des VM.

Plage horaire et maintenance. Le même pourcentage n'a pas du tout la même valeur sur une plage réduite. Pour Ravelle Conseil, 99,5 % mesurés sur les heures ouvrées d'un mois de 21 jours (21 × 11 = 231 heures) tolèrent 1 h 09 min 18 s d'arrêt, contre 3 h 36 min sur un mois complet en continu. Et si les maintenances annoncées à l'avance sont exclues du calcul, une coupure planifiée un samedi matin ne coûte rien à l'engagement.

SLA, SLO et SLI

Un SLA (Service Level Agreement, accord de niveau de service) est l'engagement écrit d'un fournisseur envers son client sur la qualité d'un service : disponibilité, délais de prise en charge et de rétablissement, horaires. Le cours ITIL et support détaille ses rubriques, les accords internes (OLA) et les garanties de temps d'intervention et de rétablissement (GTI et GTR). Ici, on s'intéresse à sa clause de disponibilité, et à deux sigles venus des équipes d'exploitation :

Sigle	Sens	Exemple pour l'intranet
SLA	L'engagement envers le client, avec ses conséquences s'il n'est pas tenu	« Disponibilité de 99,5 % par mois sur les heures ouvrées »
SLO (Service Level Objective)	L'objectif interne, plus exigeant que le SLA pour garder une marge	« Nous visons 99,8 % »
SLI (Service Level Indicator)	La mesure réelle, telle que l'outil de supervision la calcule	« 99,87 % en avril, mesurés par une sonde toutes les minutes »

Une clause de disponibilité utilisable précise toujours :

La période de mesure : le mois ou l'année. Un engagement annuel autorise une grosse panne en janvier, un engagement mensuel non.
La plage horaire : 24 heures sur 24, ou les heures ouvrées.
Ce qui compte comme indisponible : le service ne répond plus ? répond en plus de 5 secondes ? répond avec une erreur ?
Les exclusions : les maintenances annoncées (avec quel préavis), les pannes causées par le client ou par un cas de force majeure.
La méthode de mesure : une sonde qui teste le service depuis l'extérieur à intervalle régulier, et pas le ressenti des utilisateurs.
Les conséquences : pénalités ou crédits de service quand le fournisseur est externe, plan d'amélioration quand c'est la DSI interne.

La clause écrite pour Ravelle Conseil. « L'intranet est disponible à 99,5 % par mois, mesurés du lundi au vendredi de 8 h à 19 h hors jours fériés. Le service est considéré comme indisponible quand la page d'accueil ne répond pas en HTTPS avec le code 200 en moins de 5 secondes, selon la sonde de supervision qui la teste chaque minute depuis le VLAN utilisateurs. Les maintenances annoncées au moins 48 heures à l'avance et réalisées hors des heures de service sont exclues. En cas de panne, le service est rétabli en moins de 4 heures, et au plus une journée de documents peut être perdue. »

MTBF et MTTR : d'où vient l'indisponibilité

Deux indicateurs expliquent pourquoi un composant est indisponible :

le MTBF (Mean Time Between Failures, temps moyen entre pannes) dit combien de temps il fonctionne en moyenne avant de tomber en panne ;
le MTTR (Mean Time To Repair, temps moyen de réparation) dit combien de temps il reste en panne : détecter, diagnostiquer, réparer ou remplacer, remettre en service.

On en déduit sa disponibilité :

disponibilité = MTBF ÷ (MTBF + MTTR)

Exemple. Un serveur tombe en panne en moyenne toutes les 4 000 heures de fonctionnement. Avec un MTTR de 8 heures (le temps de commander une pièce et de la changer), sa disponibilité vaut 4 000 ÷ 4 008 ≈ 99,80 %. Si un disque et une alimentation de rechange attendent sur une étagère, le MTTR tombe à 2 heures : 4 000 ÷ 4 002 ≈ 99,95 %. Si la pièce met deux jours à arriver (MTTR de 48 heures) : 4 000 ÷ 4 048 ≈ 98,81 %.

L'exemple montre les deux leviers de la disponibilité :

Levier	Moyens	Effet
Espacer les pannes (MTBF ↑)	Matériel de gamme serveur, environnement climatisé, onduleur, mises à jour testées, supervision des disques	Moins de pannes
Raccourcir les réparations (MTTR ↓)	Supervision qui alerte en une minute, pièces de rechange, contrat de maintenance avec intervention en 4 heures, procédures écrites, basculement automatique	Des pannes plus courtes

La haute disponibilité agit surtout sur le second levier : le composant tombe toujours en panne, mais le service, lui, bascule en quelques secondes. Le MTTR du service devient le temps de basculement, pendant que le composant est réparé sans urgence.

RTO et RPO : combien de temps, combien de données

Deux autres objectifs complètent la disponibilité. Ils viennent du plan de reprise, mais ils guident aussi le choix d'une solution de haute disponibilité :

le RTO (Recovery Time Objective, durée maximale d'interruption admissible) : combien de temps le service peut rester arrêté après un incident ;
le RPO (Recovery Point Objective, perte de données maximale admissible) : jusqu'à quel point dans le passé on accepte de perdre des données.

Solution	RTO typique	RPO typique
Restauration depuis la sauvegarde de la nuit	Plusieurs heures	Jusqu'à 24 heures
VM répliquée toutes les 15 minutes sur un second hôte, démarrée à la main	15 à 30 minutes	15 minutes
Cluster de VM avec redémarrage automatique sur stockage partagé	2 à 3 minutes	Aucune donnée validée perdue
Deux serveurs actifs derrière un répartiteur, données répliquées de façon synchrone	Quelques secondes, voire aucune coupure visible	Aucune

Plus le RTO et le RPO sont courts, plus la solution coûte cher. La bonne solution est la moins chère qui respecte l'engagement : si une heure d'arrêt de l'intranet coûte 200 € en temps perdu, et qu'une redondance coûte 3 000 € par an (une VM, du temps d'administration, une licence), elle est rentable dès qu'elle évite 15 heures d'arrêt par an. Cet argument chiffré est exactement ce qu'attend un dossier de choix : coût, délai, qualité.

Les niveaux de redondance : N, N+1, 2N

Pour dire combien de composants on installe, on note N le nombre strictement nécessaire pour assurer le service à pleine charge.

Notation	Principe	Exemple
N	Juste ce qu'il faut, aucune marge	Deux serveurs web suffisent à la charge : on en installe deux. Si l'un tombe, l'autre sature
N+1	Un composant de plus que nécessaire	Trois serveurs web pour une charge qui en demande deux. Les alimentations « 1+1 » d'un serveur
2N	Tout est doublé, chaque moitié peut porter toute la charge seule	Deux salles, deux arrivées électriques, deux jeux complets de serveurs
2N+1	Tout est doublé, plus un composant de réserve	Les centres de données les plus exigeants

Une redondance N+1 suppose que le composant restant tienne la charge : deux serveurs chargés chacun à 80 % ne sont pas redondants, puisque le survivant devrait absorber 160 %. On y revient au chapitre 8 pour la mémoire d'un cluster de VM.