Haute disponibilité

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.

La disponibilité est aujourd'hui un enjeu important des infrastructures informatiques. On estime aujourd'hui que la non-disponibilité d'un service informatique peut avoir des coûts se chiffrant en millions, particulièrement dans le domaine de l'industrie où l'arrêt d'une chaîne de production peut avoir un effet dévastateur.

Deux moyens complémentaires sont utilisés pour améliorer la haute disponibilité :

• La mise en place d'une infrastructure matérielle dédiée, généralement en se basant sur de la redondance matérielle. Est alors créé un cluster de haute-disponibilité (par opposition à un cluster de calcul) : une grappe d'ordinateurs dont le but est d'assurer un service en évitant au maximum les indisponibilités.
• La mise en place de processus adaptés permettant de réduire les erreurs, et d'accélérer la reprise en cas d'erreur. ITIL contient de nombreux processus de ce type.

Pour mesurer la disponibilité, on utilise souvent un pourcentage essentiellement composé de '9' :

• 99% désigne le fait que le service est indisponible moins de 3,65 jours par an
• 99,9%, moins de 8,75 heures par an
• 99,99%, moins de 52 minutes par an
• 99,999%, moins de 5,2 minutes par an
• 99,9999%, moins de 54,8 secondes par an
• 99,99999%, moins de 3,1 secondes par an
• etc.

L'amalgame est souvent fait, à tort, entre la haute disponibilité et le plan de reprise d'activité. Il s'agit de deux tâches différentes, complémentaires pour atteindre la disponibilité continue.

De nombreuses techniques sont utilisées pour améliorer la disponibilité :

• la redondance des matériels et la mise en cluster ;
• la sécurisation des données : RAID, snapshots, Oracle Data Guard, BCV (Business Copy Volume), SRDF (Symmetrix Remote Data Facility), DRBD ;
• la possibilité de reconfigurer le serveur « à chaud » (c’est-à-dire lorsque celui-ci fonctionne) ;
• mode dégradé ou un mode panique ;
• plan de secours ;
• et sécurisation des sauvegardes : externalisation, centralisation sur site tiers.

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 :

• Comment détecter une panne ? Exemples : Tests de vie TCP Health Check implémenté par un boîtier Alteon, programme de test invoqué périodiquement (« heartbeat »), interface de type « diagnostic » sur les composants…
• Comment le composant est-il sécurisé, redondé, secouru… Exemples : serveur de secours, cluster système, clustering Websphere, stockage RAID, sauvegardes, double attachement SAN, mode dégradé, matériel non-utilisé libre (spare) prêt à être réinstallé..
• Comment désire-t-on enclencher la bascule en mode secours / dégradé. Manuellement après analyse ? Automatiquement ?
• Comment s’assurer que le système de secours reparte sur un état stable et connu. Exemples : on repart d’une copie de la base et on réapplique les archives logs, relancement des batchs depuis un état connu, commit à 2 phases pour les transactions mettant à jour plusieurs gisements de données…
• Comment l’application redémarre sur le mécanisme de secours. Exemples : redémarrage de l’application, redémarrage des batches interrompus, activation d’un mode dégradé, reprise de l’adresse IP du serveur défaillant par le serveur de secours…
• Comment reprendre éventuellement les transactions ou sessions en cours. Exemples : persistance de session sur le serveur applicatif, mécanisme pour assurer une réponse à un client pour une transaction qui s’est bien effectuée avant défaillance mais pour laquelle le client n’a pas eu de réponse…
• Comment revenir à la situation nominale. Exemples :
• si un mode dégradé permet en cas de défaillance d’une base de données de stocker des transactions en attente dans un fichier, comment les transactions sont-elles ré-appliquées quand la base de données redevient active.
• si un composant défaillant a été desactivé, comment s’effectue sa réintroduction en service actif (nécessité par exemple de resynchroniser des données, de retester le composant…)

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.

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)

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.

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.

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 soient 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.

On peut distinguer deux rôles dans ces processus.

Les processus qui réduisent le nombre de pannes

En se basant sur le fait que mieux vaut prévenir que guérir, mettre en place des processus de contrôle qui permettront de réduire le nombre d'incidents sur le système permet d'améliorer la disponibilité. Deux processus permettent de jouer ce rôle :

• Le processus de gestion des changements : 60% des erreurs sont liées à un changement récent. En mettant en place un processus formalisé, accompagné de tests suffisants (et réalisés dans un environnement de pré-production correct), de nombreux incidents peuvent être éliminés.
• Un processus de gestion pro-active des erreurs : les incidents peuvent bien souvent être détectés avant de survenir : les temps de réponse augmentent ... Un processus dédié à cette tâche, et muni des outils adéquats (système de mesure, de reporting ...) pourra intervenir avant même que l'incident n'arrive.

En mettant en place ces deux processus, de nombreux incidents peuvent être évités.

Les processus réduisant la durée des pannes

Les pannes finissent toujours par arriver. A ce moment-là, le processus de reprise en cas d'erreur est primordial pour que le service soit restauré au plus vite. Ce processus doit avoir un objectif : permettre à l'utilisateur d'utiliser un service le plus rapidement possible. La réparation définitive doit donc être évitée car elle prend beaucoup plus de temps. Ce processus devra donc mettre en place une solution de contournement du problème.

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.

Exemples d'application de clustering dans le monde UNIX (fonctionnant sous AIX ou Linux) :

• IBM HACMP
• Bull Application Roll-over Facility