Microsoft Cluster Services (MSCS)

MSCS, le logiciel connecte jusqu’à 
quatre ordinateurs physiques tournant sur un réseau à  grande vitesse. Normalement,
les ordinateurs mis en cluster partagent un sous-système de stockage commun et
fonctionnent en mode  » actif-actif « , ce qui signifie que tous les ordinateurs
du cluster (les noeuds) travaillent activement pour se répartir la charge, mais
peuvent aussi prendre en charge le surplus, en cas de défaillance de l’un des
noeuds. La Figure 1 montre un cluster MSCS à  quatre noeuds.

La raison d’être de MSCS consiste principalement à  accroître la disponibilité
des applications grâce à  ses capacités de bascule en cas d’incident. La bascule
est une fonction qui permet à  un cluster de déplacer le traitement d’une application
défaillante (pour différentes raisons relevant aussi bien d’un problème matériel
que de bugs de logiciels) du noeud où elle se trouve vers un autre noeud du cluster
en bon état de fonctionnement. Une fois l’application défaillante restaurée, le
cluster devra la basculer à  nouveau sur le noeud original. MSCS gère la bascule
dans les deux sens des applications tournant sur un cluster, sans perdre les données
associées à  une application défaillante et maintient l’état des utilisateurs et
des applications pendant tout le déroulement des opérations de bascule. Au contraire,
avec NLB, CLB, et AppCenter le clustering est sans état et s’accompagne de l’équilibrage
dynamique des charges (dont je parlerai en détail plus loin), tout en assurant
la disponibilité.

MSCS est un bon choix pour exécuter des applications cruciales comme les serveurs
de messagerie ou les applications de bases de données. Supposons que vous décidiez
d’exécuter Microsoft Exchange 2000 Server sur un cluster MSCS à  4 noeuds. Après
avoir installé le logiciel MSCS et la version d’Exchange 2000 reconnaissant les
clusters, vous pouvez configurer le cluster de façon à  ce qu’Exchange 2000 bascule
vers un noeud de sauvegarde, en cas de problème sur le noeud primaire. Les utilisateurs
auront immanquablement des sessions ouvertes sur le serveur principal, lorsqu’il
aura une défaillance, mais MSCS effectue la bascule rapidement et automatiquement,
sans perdre de données. Le noeud de sauvegarde prend à  son compte la charge de
travail et les données du noeud défaillant et la prise en charge des utilisateurs
se poursuit.

MSCS permet aussi aux utilisateurs de continuer à  travailler pendant la mise à 
jour d’une application. Au lieu d’être obligé d’arrêter une application lors de
sa mise à  jour, vous pouvez l’effectuer par roulements (c’est-à -dire sur un noeud
du cluster à  la fois, pendant qu’elle continue à  être disponible sur les autres
noeuds). Par exemple, supposons que vous ayez un cluster à  2 noeuds. Le noeud 1 exécute
Exchange 2000 et le noeud 2 Microsoft SQL Server, et votre cluster est configuré
de sorte qu’Exchange 2000 et SQL Server basculeront sur l’autre noeud lorsque cela
sera nécessaire. Le moment venu de mettre à  jour SQL Server, vous pouvez utiliser
MSCS Cluster Administrator pour lancer une bascule de SQL Server sur le noeud 2.
Le noeud 1 prend alors en charge l’exécution de SQL Server (en même temps qu’Exchange
2000), permettant ainsi la mise à  niveau du logiciel SQL Server sur le noeud 2.
L’opération terminée, SQL Server peut de nouveau être basculé du noeud 1 sur le
noeud 2 et le processus peut être répété pour le logiciel SQL Server du noeud 1.
Au final, la mise à  jour du logiciel SQL Server aura pu être effectuée sans provoquer
de temps d’arrêt pour les utilisateurs.

La raison d’être de MSCS consiste principalement à  accroître la disponibilité
des applications grâce à  ses capacités de bascule en cas d’incident

Normalement, MSCS ne s’utilise pas pour faire évoluer une application pour qu’elle
supporte davantage d’utilisateurs, comme c’est le cas avec les trois autres solutions
de clustering de Microsoft. Un cluster MSCS n’assure pas l’équilibrage dynamique
des charges, ni n’effectue une distribution sans état, share-nothing, des applications
entre ses noeuds, comme c’est le cas de NLB, CLB et AppCenter. En fait, le seul
moyen réel d’atteindre la capacité de montée en charge des applications avec MSCS
est de diviser manuellement une application entre les ressources du cluster pendant
l’installation. Par exemple, pour prendre en charge 5000 utilisateurs sur Exchange
2000, il est possible d’utiliser un cluster actif-actif de 2 noeuds avec 2500 utilisateurs
sur chaque noeud. Cette méthode permet de bénéficier de deux serveurs pour supporter
les utilisateurs, et, en plus, de la capacité de supporter le trafic de l’autre
serveur en cas de défaillance. Toutefois, en cas de bascule lors d’un incident,
le noeud restant doit pouvoir assumer la charge les 5000 utilisateurs jusqu’à  la
restauration du noeud défaillant.