Haute disponibilité

Exemple de cluster à haute disponibilité

La haute disponibilité ou high availability (HA) 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. Ces coûts se chiffrant en milliards d'euros à l'échelle d'un pays[1]. L'indisponibilité des services informatiques est particulièrement critique dans le domaine de l'industrie, notamment en cas d'arrêt d'une chaîne de production.

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

  • la mise en place d'une infrastructure matérielle spécialisé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.

Mesure du taux de disponibilité

[modifier | modifier le code]

La disponibilité se mesure souvent en pourcentage :

Disponibilité en % Indisponibilité par année Indisponibilité par mois[2] Indisponibilité par semaine
90 % (« un neuf ») 36,5 jours 72 heures 16,8 heures
95 % 18,25 jours 36 heures 8,4 heures
98 % 7,30 jours 14,4 heures 3,36 heures
99 % (« deux neuf ») 3,65 jours 7,20 heures 1,68 heure
99,5 % 1,83 jour 3,60 heures 50,4 minutes
99,8 % 17,52 heures 86,23 minutes 20,16 minutes
99,9 % (« trois neuf ») 8,76 heures 43,2 minutes 10,1 minutes
99,95 % 4,38 heures 21,56 minutes 5,04 minutes
99,99 % (« quatre neuf ») 52,56 minutes 4,32 minutes 1,01 minute
99,999 % (« cinq neuf ») 5,26 minutes 25,9 secondes 6,05 secondes
99,9999 % (« six neuf ») 31,5 secondes 2,59 secondes 0,605 seconde

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.

Techniques améliorant la disponibilité

[modifier | modifier le code]

De nombreuses techniques sont utilisées pour améliorer la 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 :

  • 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…)

Dépendance vis-à-vis des autres applications

[modifier | modifier le code]

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.

Répartition de charge et sensibilité

[modifier | modifier le code]

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 matière 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).

Redondance différentielle

[modifier | modifier le code]

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.

Redondance avec système de vote

[modifier | modifier le code]

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.

« Shadow operations »

[modifier | modifier le code]

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.

Les processus qui permettent d'améliorer la disponibilité

[modifier | modifier le code]

On peut distinguer deux rôles dans ces processus.

Les processus qui réduisent le nombre de pannes

[modifier | modifier le code]

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 affecté à 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

[modifier | modifier le code]

Les pannes finissent toujours par arriver. À 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.

Cluster haute disponibilité

[modifier | modifier le code]

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) :

L'OS Microsoft Windows Server incorpore les outils de construction d'un cluster de haute disponibilité pour les services compatibles tels que les bases de données MS SQL Server[4].

Certification

[modifier | modifier le code]

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"[5], ainsi que des critères de résilience.

Voir aussi

[modifier | modifier le code]

Articles connexes

[modifier | modifier le code]

Liens externes

[modifier | modifier le code]
Cette section est vide, insuffisamment détaillée ou incomplète. Votre aide est la bienvenue ! Comment faire ?

Notes et références

[modifier | modifier le code]
  1. ↑ « journaldunet » (consulté le )
  2. ↑ Une période de 30 jours est utilisée pour ce calcul.
  3. ↑ (en) Alteon WebSystems
  4. ↑ JasonGerend, « créer un cluster de basculement », sur learn.microsoft.com, (consulté le )
  5. ↑ http://www.uptimeinstitute.com/professional-services/professional-services-tier-certification « Copie archivée » (version du sur Internet Archive)