Haute disponibilité - Définition

Répartition de charge et sensibilité

La sensibilité est souvent gérée en redondant les éléments avec un mécanisme de répartition de charge. (un cluster websphere avec un load-balancing Alteon par exemple). Pour que ce système apporte un réel gain en termes de fiabilité, il faut vérifier que si un des éléments est défaillant, les éléments restants disposent d’une puissance suffisante pour assurer le service.

Autrement dit, dans le cas de deux serveurs actifs avec répartition de charge, la puissance d’un seul serveur doit permettre d’assurer la totalité de la charge. Avec trois serveurs, la puissance d’un seul serveur doit permettre d’assurer 50% de la charge (en supposant que la probabilité d’avoir un incident sur deux serveurs en même temps est négligeable). Pour assurer une bonne fiabilité, il est inutile de mettre en grand nombre de serveurs se secourant mutuellement. Par exemple, un élément fiable à 99% redondé une fois donne une fiabilité de 99.99% (probabilité que les deux éléments soit défaillants au même moment = 1/100x1/100 = 1/10.000)

Dépendance vis-à-vis des autres applications

Pour une application qui sollicite d’autres applications avec des middlewares en mode synchrone (service webs en http, Tuxedo, Corba, EJB) le taux de disponibilité de l’application sera fortement lié à la disponibilité des applications dont elle dépend. La sensibilité des applications dont on dépend doit donc être équivalente ou supérieure à la sensibilité de l’application elle-même.

Sinon, il faut envisager

• l’utilisation d’un middleware asynchrone : MQ Series, JMS, SonicMQ, CFT
• la mise en œuvre d’un mode dégradé quand une application dont on dépend est défaillante.

Pour cette raison on privilégiera l’utilisation de middlewares asynchrones pour privilégier une bonne disponibilité quand c’est possible.

Redondance avec système de vote

Dans ce mode, différents composants traitent les mêmes entrées et produisent donc (en principe) les mêmes sorties.

Les résultats produits par tous les composants sont collectés, puis un algorithme est mis en œuvre pour produire le résultat final. L’algorithme peut être simple (vote à la majorité) ou complexe (moyenne, moyenne pondérée, médiane…), l’objectif étant d’éliminer les résultats erronés imputables à un dysfonctionnement sur l’un des composants et/ou de fiabiliser un résultat en combinant plusieurs résultats légèrement différents.

Ce procédé :

• ne permet pas de répartition de charge
• introduit le problème de fiabilisation du composant gérant l’algorithme de vote

Ce procédé est utilisé généralement dans les cas suivants

• Des systèmes reposant sur des capteurs (exemple : capteurs de température) pour lesquels les capteurs sont redondés
• Des systèmes ou plusieurs composants différents assurant la même fonction sont utilisés (cf. redondance différentielle) et pour lesquels un meilleur résultat final peut être obtenu en combinant les résultats produits par les composants (exemple : système de reconnaissance de formes utilisant plusieurs algorithmes pour obtenir un meilleur taux de reconnaissance.

Redondance différentielle

La redondance d’un élément est généralement effectuée en choisissant de redonder avec plusieurs composants identiques. Ceci suppose, pour être efficace, qu’une défaillance d’un des composants est aléatoire et indépendante d’une défaillance d’un des autres composants. C’est par exemple le cas des pannes matérielles.

Ce n’est pas le cas de toutes les défaillances : par exemple, une faille du système d’exploitation ou une anomalie d’un composant logiciel peuvent survenir, quand les conditions sont favorables, sur l’ensemble des composants à la fois. Pour cette raison, quand l’application est extrêmement sensible, on considèrera de redonder les éléments avec des composants de natures différentes mais assurant les mêmes fonctions. Ceci peut conduire à :

• choisir des serveurs de nature différentes, avec des OS différents, des produits logiciels d’infrastructure différents,
• développer le même composant deux fois en respectant à chaque fois les contrats d’interface qui s’appliquent au composant.