La Haute Disponibilité

cactiComme annoncé dans ce précédent billet. La société Cloud Consultingpartenaire des IT souhaitant étudier leur migration vers le Cloud Computing nous propose d’intervenir sur ce blog afin d’apporter son éclairage et son expertise sur le Cloud Computing, et vous présenter ses solutions techniques.

Dans ce premier article, Cloud Consulting vous propose d’aborder sa vision de la haute disponibilité et un comparatif des définitions qu’en font les fournisseurs de Cloud Computing. Mais commençons tout d’abord par définir ce qu’est la Haute Disponibilité…

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 unemaster-slave 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, PDM/PLM, 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.

Si vous souhaitez plus d’informations sur ce sujet n’hésitez pas à contacter : cloudconsulting.fr.

Posted by Alexandre (Cloud Consulting)

Sur le même thème :

4 Responses to “La Haute Disponibilité”

  1. benjamin says:

    “La probabilité de discontinuité de service est alors divisée par n”

    C’est faux me semble-t-il … cela suppose que vous avez n serveurs ou processus et que l’ensemble de la charge peut être traitée par un seul processus/serveur, ce qui est rarement le cas.

    Imaginons que vous avez 20 serveurs d’application en cluster, à une période de la journée vous avez besoin de disons 15 serveurs pour que l’application tourne correctement (sans ralentissements) ; au delà de 5 serveurs en panne vous avez une discontinuité de service.

    Bonne journée,

  2. Alexandre says:

    La discontinuité de service correspond à une panne totale : si vous avez 5 serveurs en panne dans votre exemple, votre système est dégradé mais pas en panne.
    Ma phrase souhaitait exprimer l’idée suivante : si la probabilité de discontinuité de service d’un serveur est de 0.05%, alors celle de n serveurs identiques est 0.05%^n. Car ces événements sont indépendants (la chute d’un serveur n’entraîne pas la chute d’un autre).
    Marc, peux-tu remplacer la phrase “La probabilité de discontinuité de service est alors divisée par n ” par “La probabilité de discontinuité de service est alors fortement réduite (multipliée n fois)”.
    Merci Benjamin pour votre remarque.

  3. benjamin says:

    Tout à fait d’accord avec votre réponse, j’avais néanmoins comme idée derrière la tête que dans le cas d’un cluster web (ça doit être valable dans d’autres cas) à partir d’un certain nombre de serveurs hors service (disjonction d’une baie par exemple / problème électrique …) on peut assister à un phénomène de “domino”.

    En effet les serveurs restant se trouvant à assurer une charge plus importante qu’ils ne le peuvent ils s’écroulent les uns après les autres et sont (selon le système de répartition de charge) retirés progressivement du pool de serveurs, la charge s’accentuant encore un peu plus sur les serveurs existants et ainsi de suite …

  4. Marc says:

    @Alexandre : C’est modifié
    @Benjamin : Merci pour cette remarque pertinente. Mais il est certains que dans les cas extrêmes il est impossible de maintenir le service, sauf en multipliant tous les composants, et en les distribuant sur plusieurs sites. Mais les coûts montent extrêmement vite, et comme souvent les moyens sont calculés de manière à pouvoir géré le 99,99% pour garantir le 99,999% ou plus il faut des budgets très importants (comme pour les composants militaires ou ceux de l’avionique) mais un cluster de site web n’a pas forcement besoin d’un tel niveau de sécurité.

    En tout cas ça ne serais pas forcément rentable/nécessaire.

    Merci pour les commentaires en tout cas,
    Marc.

Leave a Reply