Rappel de l’existant sous Windows Server 20008

Avant de voir la nouveauté de la fonctionnalité, revenons sur ce qui existe actuellement sous Windows Server 2008 (et avant sous 2003) à savoir le besoin de disposer pour chaque groupe de ressources d’une « ressource disque physique ». Le but était de contrôler l’accès du cluster sur les données de l’application afin de s’assurer qu’au maximum un seul nœud pouvait accéder aux données à un instant donné pour éviter la corruption des données sur la LUN. Sous 2008, le propriétaire d’une LUN était déterminé par le protocole SCSI SPC-3 appelé « Persistent Reservations ».

Lorsqu’un nœud possédait une LUN, cela marquait une réservation sur le volume. Si un autre nœud essayait d’accéder à ce disque, il devait en faire la demande de possession au propriétaire actuel qui soit la refusé soit s’il l’accepté procédait à un bascule de la ressource. C’est ce que l’on appel finalement le « Shared Nothing » puisque la ressource n’est au final pas partagée simultanément.  

 Etant donné qu’un seul nœud peut posséder la LUN à instant donné, cela signifie que la LUN devient la plus petite unité de basculement. Si une application tournant sur une LUN a besoin de basculer sur un autre nœud, alors toutes les applications sur cette même LUN vont également basculer. Ceci à une conséquence importante au niveau du stockage puisque les clients décident alors de créer une LUN par application (qui le plus souvent, se retrouve être une machine virtuelle). Ceci pose de nombreux problèmes de complexité de stockage avec un découpage difficile de la baie SAN qui s’accompagne généralement d’une perte de place…

Voyons maintenant comme la technologie CSV de Windows Server 2008 R2 permet

Comment fonctionne le CSV (Nœud Coordinateur)

CSV autorise les nœuds d’un même cluster à partager l’accès à une LUN ce qui signifie que l’application sur ce disque partagé peut être exécuté par n’importe quel nœud, n’importe quand. CSV casse la dépense actuelle entre la ressource applicative (dans notre cas la VM) et la ressource disque (le disk CSV) ce qui signifie que dans un environnement CSV peu importe où le disque est monté car il apparaît comme local pour tous les nœuds du cluster. Une nouvelle notion apparaît c’est le nœud coordinateur qui correspondant anciennement au propriétaire et c’est lui qui gère l’accès concurrentiel à la ressource disque en fonction de la demande.  

Le nœud coordinateur peut être n’importe quel nœud dans un cluster, et la VM sur le disque CSV peut être également sur n’importe que hôte hyper-V du cluster. Lorsque l’application tournant dans la VM a besoin d’écrire sur le disque CSV, une demande au nœud coordinateur est effectuée. En fonction de si la demande nécessite de modifier la structure du système de fichiers, le nœud coordinateur va faire deux choses :

• Directement envoyé au nœud le demandant l’adresse de block disponible en écriture dans le système de fichiers où la VM va directement pouvoir écrire.

• Ecrire lui-même les informations sur le disque
• si le besoin est de déplacer, étendre ou modifier l’attribut d’un fichier.

Si vous avez plusieurs disques CSV, vous aurez plusieurs nœuds coordinateurs. Il est d’ailleurs recommandé dans une configuration à 3 nœuds avec 3 disques CSV, par exemple, de répartir la charge ainsi que le trafic réseau pour que chaque host devienne coordinateur d’un disque CSV.