soit
parce que c’est elle-même qui a un problème, soit parce que
c’est le noeud qui l’héberge qui a un problème, l’application
peut, automatiquement ou à  la demande d’un administrateur,
être déplacée vers un noeud disponible.
Il est évidemment plus rapide de basculer une application
de cette façon que de restaurer un serveur depuis une
ou plusieurs bandes de sauvegarde.
Pour qu’une application soit « Cluster
aware », elle doit avoir été conçue
spécifiquement dans ce but, et notamment
implémenter un ensemble de
fonction particulier que l’on inclus
dans une « Resource DLL ».

Cette « Resource DLL » est une interface
entre l’application et Cluster
Server.
L’interface doit implémenter 2
fonctions, LooksAlive() et IsAlive().

LooksAlive :
il s’agit d’une fonction exécutant
un test simple sur l’application et qui
indique au Cluster que tout semble
être correct. Pour SQL Server, l’exemple
d’une fonction LooksAlive est de
tenter une connexion à  la base de données

IsAlive() :
Il s’agit d’une fonction plus évoluée
qui exécute un test plus complexe
que LooksAlive et qui assure le véritable
fonctionnement complet de l’application.
Dans le cas de SQL Server, à 
titre de comparaison, IsAlive() va exécuter
une requête SQL et vérifier le résultat
avant d’indiquer au Cluster que
tout va bien

En fonction de certains paramètres
de temps de réponse et de non réponse
fourni par l’administrateur, il
sera donc possible de connaître une indisponibilité
de l’application et de
prendre les mesures qui s’imposent
pour la transférer sur un noeud différent
dans l’éventualité ou un problème
surviendrait.