Le problème

fonctionne en interne.
Microsoft Cluster Server est composé
de deux parties, l’une fonctionnant
en mode utilisateur (le service
Microsoft Cluster Service) et une autre
partie fonctionnant en mode Kernel
(Cluster Network Resource).
Le service est chargé, au travers
d’un composant nommé le Resource
Monitor, d’interroger périodiquement
les Resources DLL des applications installées,
et d’appeler leurs fonctions
LooksAlive et IsAlive afin de s’assurer
que les applications répondent aux besoins
et fournissent le service attendu
aux utilisateurs. Le test en lui-même
est nommé « heartbeat » (littéralement
battement de coeur).
La figure 1 décrit ce fonctionnement.
Voir Fig 1 : description générale
du fonctionnement du cluster
Et le problème justement vient de
ce test. Il s’est avéré que, dans certaines
circonstances, le Resource
Monitor pouvait rester dans un état
indéterminé, empêchant par là  même
le service Cluster de se rendre compte
qu’il y avait un problème au niveau
d’une application.
Les évènements s’enchaînent
alors, pas de reporting au niveau du
cluster que l’application est défaillante,
pas d’action entreprise par les administrateurs
pour corriger, et appel des utilisateurs
pour indiquer que le service
ne répond plus.
Ceci est vrai pour Windows NT4 et
pour Windows 2000.
Voir Figure 2 : Resource Monitor
bloqué par une application défectueuse