I.2 LINUX ET LA
HAUTE DISPONIBILITE
Les supports de Haute Disponibilité existe depuis
déjà quelques années sous Linux et même si le niveau
de maturité n'est pas encore celui d'autres environnements
propriétaires de type Unix, il est déjà largement
suffisant dans la plupart des cas.
Une bonne part des techniques disponibles reposes sur la
multiplication des ressources critique (physiques ou logicielles) constituant
un serveur. En multipliant les ressources, on supprime du même coup leurs
caractères critiques. Le service pourra donc être assuré
même en cas de panne d'un composant. Cela permet notamment d'utiliser des
composants moins chers puisque la fiabilité du composant ne devient plus
le critère principal.
Une seconde approche considère que l'on peut assez
facilement mettre en place une solution où ce n'est plus la ressource
que l'on va chercher à dupliquer, mais directement le serveur.
L'utilisation de grappes de machines (cluster en anglais) est un bon moyen de
répondre à cette problématique. Si l'on parvient à
disposer d'au moins deux machines sur lesquelles le service est
exécuté de façon unique (sur l'un ou l'autre des noeuds),
la continuité du service sera garantie moyennant le temps de basculement
d'une machine à l'autre (On parle en anglais de FailOver Services, FOS).
La principale difficulté consiste à maintenir
une copie des données entre les noeuds (dans ce type de cluster dit de
Haute Disponibilité, une machine s'appelle un noeud) pour que le service
puisse être indifféremment lancé sur l'un ou l'autre des
serveurs. Pour accomplir cela, il existe différentes techniques
basées soit sur la réplication plus ou moins en temps réel
des données entre les noeuds, soit sur le partage d'une ressource unique
en utilisant notamment un système de fichiers distribués ou
partagés. Dans ce type de configuration, il est important de faire en
sorte que le temps de rétablissement du service soit le plus faible
possible pour réduire le gène occasionné aux utilisateurs.
Le basculement du service dans le cluster ne doit pas être (trop)
perceptible et ne doit surtout pas occasionner une modification du
paramétrage côté client : Afin de rendre transparente cette
étape, on utilise la notion d'alias IP pour associer une adresse IP dite
flottante sur le noeud hébergeant le service. La continuité
apparente du service coté client est donc assurée.
Une dernière technique moins connue permet de
répartir la charge sur un ensemble de noeuds physiques sur lesquels un
service de type réseau est exécuté en parallèle et
en concurrence. Un noeud maître se charge de répartir les
requêtes sur le noeud le moins chargé du cluster. Si un noeud
tombe en panne, il sera détecté par le maître qui pourra
facilement le retirer de sa liste des noeuds actifs.
La plus grande partie des architectures misent en oeuvre pour
garantir la disponibilité d'un service dérivant plus ou moins
directement de ces trois approches.
| 
