Haute disponibilité - Définition

Introduction

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^{[réf. souhaitée]}, 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.

Techniques améliorant la disponibilité

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