Haute disponibilité

La disponibilité se mesure souvent en pourcentage :

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 (en), 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[3], 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, relance 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 batchs 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é désactivé, 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 disponibilité, il est inutile de mettre un grand nombre de serveurs se secourant mutuellement. Par exemple, un élément disponible à 99 % redondé une fois donne une disponibilité de 99,99 % (probabilité que les deux éléments soit défaillants au même moment = 1/100x1/100 = 1/10000).

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.

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.

Voici une liste non exhaustive d'applications de clustering pour UNIX (fonctionnant sous AIX, HP-UX, Linux ou Solaris) :

• Evidian SafeKit (load balancing, réplication temps réel et failover)
• HP MC/ServiceGuard pour HP-UX
• IBM HACMP
• Bull Application Roll-over Facility
• Symantec Veritas Cluster Server
• Open Source Linux Pacemaker (logiciel)
• OpenSVC (Logiciels Libres Gratuits)
• Oracle Solaris Cluster (ex SUN Cluster)

Il existe des organismes de certification, comme l'Uptime Institute (appelé parfois « The Global Data Center Authority ») qui ont défini des classifications dans le domaine des Datacenters, en distinguant quatre types de "Tiers"[4], ainsi que des critères de résilience.