Le clustering, synonyme de fiabilité

au moins
deux cartes réseau par serveur, une pour communiquer avec les autres serveurs
du cluster (communication intra-cluster), l’autre pour communiquer avec les applications
externes (par exemple les browsers Web). WLBS peut s’exécuter sur des serveurs
avec une seule carte réseau, mais risque de ne pas fonctionner aussi bien en cas
de charges très lourdes.

La communication intra-cluster comporte un message sous forme de pulsation cardiaque
envoyée par chaque serveur du cluster aux autres serveurs. Cette pulsation permet
aux serveurs de savoir que les autres systèmes du cluster fonctionnent tous correctement.
Par défaut les serveurs envoient des pulsations à  une seconde d’intervalle.
Si les autres serveurs du cluster n’entendent pas la pulsation cinq fois de suite,
ils lancent automatiquement la convergence.La convergence est un processus consistant
à  reconfigurer l’état des systèmes du cluster et à  les associer en un nouveau
cluster. Une fois la convergence effectuée, les systèmes du cluster élisent comme
hôte par défaut celui qui a la priorité d’hôte la plus élevée. (Cette priorité
est définie dans les options WLBS.)

Plusieurs événements peuvent déclencher une convergence, par exemple la défaillance
d’un serveur, l’ajout d’un nouveau serveur au cluster ou l’arrêt d’un serveur.

Il faut moins de dix secondes après la découverte d’un problème pour mener à  bien
une opération de convergence.

Le journal des événements de chaque serveur du cluster génère un Event Detail
(Détail de l’événement), comme sur l’Ecran 1, qui signale la réalisation d’une
convergence.

Si les utilisateurs tentent d’accéder à  un serveur pendant la convergence, ce
dernier les route vers un autre serveur. Les utilisateurs accèderont à  cet autre
serveur pendant les 10 secondes que dure la convergence. S’ils travaillent dans
une application qui ne fait pas le suivi des utilisateurs du serveur, ils peuvent
facilement se déplacer vers un autre serveur sans interrompre leurs activités.
Si l’application stocke des informations sur le serveur, les utilisateurs détournés
doivent réaccéder à  l’application sur le nouveau serveur. Les applications qui
exigent d’abord une ouverture de session (par exemple les sites de commerce électronique)
font le suivi de l’utilisateur sur le serveur et exigent qu’il obtienne de nouveau
l’accès à  l’application.

Le support du failover est utile lorsque les ordinateurs sont arrêtés pour maintenance,
mise à  niveau ou réparation. Comme WLBS route automatiquement les utilisateurs
vers d’autres systèmes, il est possible, en cas d’arrêt ou de déconnexion d’ un
serveur, d’ajouter ou de retirer dynamiquement des systèmes à  un cluster. Il faut
toutefois faire preuve de bon sens dans ce type d’approche.
Si vous exécutez des applications tributaires des données dans votre cluster,
il ne faut pas arrêter un système lorsque les utilisateurs sont en interaction
avec la base de données (par exemple en train de saisir des commandes). Dans un
scénario de ce type, il peut être nécessaire de modifier l’application pour qu’elle
indique le moment où les utilisateurs sont en train de mettre à  jour une base
de données et à  partir de quel serveur. Assurez-vous que les utilisateurs ont
terminé leurs transactions avant d’arrêter le serveur.
Comme WLBS n’effectue pas la bascule des serveurs de bases de données, ce sont
les systèmes qui interagissent avec celles-ci (par exemple les serveurs Web) qui
posent le problème essentiel. Il reste enfin la possibilité de créer des applications
Active Server Pages (ASP) dans lesquelles ASP route automatiquement les utilisateurs
vers un autre serveur lorsqu’il faut arrêter cette application.