la
réponse sur l’aspect technique, quoiqu’il ne diffère pas fondamentalement
dans le résultat de celui énoncé
ci-dessus.
Nous avons vu dans la section précédente
quel était le défaut du cluster
dans Windows NT4 et Windows 2000.
Ce qui change dans Windows 2003
c’est la gestion de l’incident à  plusieurs
niveaux.
Tout comme auparavant, un composant,
le Resource Monitor, est toujours
responsable d’interroger les
Resource DLL des applications compatibles
pour s’assurer de leur bon fonctionnement.
Le Cluster Service interroge maintenant
régulièrement le Resource
Monitor pour qu’il indique son propre
état. Si ce Resource Monitor ne répond
pas, le Cluster Service l’interrompt et
le redémarre. Après un nombre de redémarrage
paramétrable, le Cluster
Service estime qu’il y a problème et demande
le transfert sur un noeud alternatif
du cluster.
Le Cluster Service lui-même peut
devenir inopérant, rendant par là 
même ce nouveau test inutile. La solution
c’est donc que le driver Cluster
Network (ClustNet) figurant en mode
Kernel (voir Figure 1) soit aussi responsable
de l’interrogation régulière
du Cluster Service.
Si ce service devient indisponible,
ClustNet tente un déplacement sur un
noeud alternatif. S’il n’y parvient pas, il
initie alors un redémarrage du serveur
local.
Voir Figure 3 : fonctionnement du
cluster en environnement Windows
2003
Le test Heartbeat a lieu toutes les 3
secondes, par défaut, et il faut trois
occurrences manquées pour déclencher
une action, soit 9 secondes.