La haute disponibilité est un terme souvent utilisé en informatique, à propos d'architecture de système ou d'un service pour désigner le fait que cette architecture ou ce service a un taux de disponibilité convenable.
Un cluster haute-disponibilité (par opposition à un cluster de calcul) est une grappe d'ordinateurs dont le but est d'assurer un service en évitant au maximum les indisponibilités.
Pour mesurer la disponibilité, on utilise souvent un pourcentage essentiellement composé de '9' :
De nombreuses techniques sont utilisées pour assurer la haute disponibilité :
La haute disponibilité exige le plus souvent un local adapté: alimentation stabilisée, climatisation sur plancher, avec filtre à particules, service de maintenance, service de gardiennage et de sécurité contre la malveillance et le vol. Attention aussi au risque d'incendie et de dégât des eaux. Les câbles d'alimentation et de communication doivent être multiples et enterrés. Ils ne doivent pas être saillants dans le parking souterrain de l'immeuble, ce qui est trop souvent vu dans les immeubles parisiens. Ces critères sont les premiers à entrer en compte lors du choix d'un prestataire d'hébergement (cas de la location d'un local à haute disponibilité). Pour chaque niveau de l’architecture, pour chaque composant, chaque liaison entre composants, il faut établir :
Pour une application qui sollicite d’autres applications avec des middlewares en mode synchrone (Web Services 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
Pour cette raison on privilégiera l’utilisation de middlewares asynchrones pour privilégier une bonne disponibilité quand c’est possible.
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 terme 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)
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 à
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. Il faut noter que ce procédé :
Ce procédé est utilisé généralement dans les cas suivants
Lors du dysfonctionnement d’un composant redondé et après l’avoir réparé, on peut souhaiter le réintroduire en service actif, vérifier son bon fonctionnement effectif, mais sans que les résultats soit utilisés. Dans ce cas, les entrées sont traitées par un (ou plusieurs) composants réputés fiables. Ceux-ci produisent le résultat exploité par le reste du système. Les mêmes entrées sont également traitées par le composant réintroduit qui est dit en mode " shadow ". On peut vérifier le bon fonctionnement du composant en comparant les résultats produits avec ceux des composants fiables. Ce procédé est souvent utilisé dans les systèmes à base de vote car il suffit d’exclure le composant en mode " shadow " du vote final.