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.
Deux moyens complémentaires sont utilisés pour
améliorer la haute 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.
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)
;
· Un mode dégradé ou un mode panique ;
· Un plan de secours ;
· La 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 certains immeubles.
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 Alteon4, 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 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...)
