La discontinuité (également appelée interruption) de service dure généralement plusieurs heures et affecte la disponibilité de l’application, disponibilité qui peut se mesurer en pourcentage par an. Par exemple, une application disponible à 99% (un chiffre qui peut paraître élevé) souffre déjà d’environ 4 jours d’indisponibilité par an ! C’est un résultat souvent critique pour la bonne marche de l’entreprise (imaginez l’impact sur une société d’e-business privé de son site marchand pendant 4 jours…).
Il n’y a pas de seuil normé à partir duquel on peut considérer une application comme étant hautement disponible. En électronique militaire par exemple, les logiciels embarqués sont souvent développés et testés pour atteindre les « 5 neuf » : 99,999% de disponibilité, soit moins de 5 minutes d’indisponibilité par an ! A contrario, dans les systèmes d’information (moins critiques que le logiciel embarqué ou temps réel), les chiffres sont plus modestes, avec 2 chiffres maximum après la virgule.

On estime la disponibilité attendue du service (ESA) suivant la formule suivante :

ESA = MTBF / (MTBF + MTTR)

Où :

• Le MTBF (mean time between failure) est la mesure du temps estimé (ou moyen) entre deux défaillances d’un système donné. Ceci reflète la fréquence de défaillance du système considéré.
• Le MTTR (mean time to repair) est la mesure du temps estimé (ou moyen) pour réparer le système suite à une défaillance.

Le temps attendu de récupération du service est alors :

ESRT = (deadtime/2) + EFT + ESST

Où :

• Le deadtime, comme mentionné précédemment, est le délai spécifié avant de considérer qu’une application ne répond plus. S’il est réglé trop court, des faux positifs seront détectés (l’application sera déclarée défaillante alors qu’elle ne l’est pas). S’il est réglé trop long, un temps trop important sera nécessaire avant de détecter la défaillance d’une application.
• L’EFT (expected fencing time) est le temps estimé pour détruire (proprement ou non) l’application crashée.
• L’ESST (expected service start time) est le temps estimé pour redémarrer l’application.

Comme on le voit, établir un plan de HA prenant en compte tous ces paramètres peut être fastidieux ; le Cloud Computing fait de la HA un de ses fers de lance.