La haute disponibilité (abrégée HA pour « high availability ») consiste à détecter les points de défaillance (Single Points of Failure) de votre système et à les réduire par la mise en place de techniques de redondance et/ou de réplication.

Sans la HA, les clients (internes ou externes) de vos applications souffrent d’une discontinuité de service à chaque panne logicielle (software crash) ou panne matérielle (hardware crash). Dans l’approche classique, un administrateur IT intervient pour rechercher la cause et prendre les mesures appropriées :

• soit redémarrer les processus crashés, en restaurant tant bien que mal l’état du logiciel,
• soit s’adresser au support du logiciel incriminé, s’il s’agit d’un bug ou d’une limitation manifeste et reproductible,
• soit reconnecter les machines ou remplacer les pièces matérielles défectueuses.

Souvent, une RCA (root cause analysis) sera consolidée et des actions correctives seront entreprises. Mais à l’inverse, l’établissement d’un plan de HA des applications correspond à une action préventive. Comme mentionné dans la définition, ce plan correspond suivant les applications à la mise en place de :

• réplication, dans les approches Maître/Esclave, où une application Maître réplique régulièrement son état dans une application Esclave.
  • En cas d’interruption du Maître, l’Esclave le détecte après un certain délai (le « deadtime ») et est promu nouveau Maître. Les modalités techniques de détection seront présentées dans un prochain article. Le service reprend après cette période de downtime et un nouvel Esclave est initialisé.
  • La probabilité de discontinuité de service est divisée par 2, ce qui est généralement suffisant, car la HA cherche à éliminer tous les SPOF, sans chercher à résoudre le problème de points simultanés de défaillance (auquel cas le temps de réparation sera allongé puisqu’une récupération automatique n’est pas possible).
  • Exemples typiques de réplication : bases de données, reverse proxies, load balancers, mais également serveurs mail, collaboration, ERP, SCM etc.
• redondance, dans les approches Actif/Actif, où une application est démarrée n fois à l’identique, et ces n instances sont capables de traiter indifféremment les requêtes de tel ou tel client (aux cas « stateful » près – nous y reviendrons dans un prochain article).
  • Ces applications doivent avoir été conçues en suivant cette hypothèse.
  • La probabilité de discontinuité de service est alors fortement réduite (multipliée n fois) (et le nombre de clients qui peuvent être servis est alors presque multiplié par n). Cette approche contribue donc à la scalabilité du système, une notion sur laquelle nous reviendrons également dans un prochain article.
  • Exemples typiques de redondance : serveurs Web et serveurs d’application.