Présentation des Cluster Shared Volume pour Hyper-V 2.0

Présentation de la mise en cluster du rôle Hyper-V

Pour les facilités d’administration, de déploiement, les économies en énergie et en logistique, la virtualisation continue de se développer de manière importante même dans les scénarii les plus critiques.

Nécessitant des besoins en haute disponibilité de plus en plus importants, Hyper-V ne déroge pas à la règle et la mise en cluster de machine virtuelle sera l’axe d’évolution le plus important de la prochaine version de Hyper-V intégré au nouveau Windows Server, Windows Server 2008 R2 (aussi connu sous le nom de Windows 7 Server).

Cette version, attendue pour 2010, a pour objectif de permettre à Microsoft de rattraper son retard dans ce domaine face à son concurrent VMware et son produit VMotion en proposant des solutions de basculement de machine virtuelle d’un nœud à un autre en quelques secondes au maximum.

Actuellement, Windows Server 2008 permet déjà une mise en cluster des machines avec une bascule rapide grâce à la technologie Quick Migration mais son principe de fonctionnement implique une indisponibilité longue des services. Ainsi, le cluster est obligé de :

1. Sauvegarder la mémoire vive de la machine virtuelle sur un espace de stockage partagé
2. Déplacer le contrôle de l’espace de stockage qui contient le disque durs virtuel pour rendre accessible la machine virtuelle sur le second nœud (server) du cluster.
3. Recharger la mémoire vive de la machine virtuelle à partir de l’espace de stockage partagé sur le second nœud du cluster.
4. Lancer la machine virtuelle.

Ce processus est très long car il nécessite des étapes d’accès aux stockages pendant lesquels la machine n’est plus disponible (Sauvegarde et chargement de la mémoire vive, déplacement du média de stockage).

Sous Windows Server 2008 R2, le rôle Hyper-V va bénéficier d’une nouvelle technique de basculement bien plus performante appelé Live Migration. L’objectif étant de basculer une machine virtuelle en quelques secondes et ainsi avoir une indisponibilité très faible en cas de dysfonctionnement. Son principe est simple :

1. La mémoire vive de la machine virtuelle est copiée et pré-chargée directement sur le serveur de destination.
2. Pendant cette copie, les clients continuent d’accéder à la machine virtuelle sur le premier serveur et les emplacements mémoire modifiés sont repérés pour être ensuite copiés à leur tour de manière incrémentielle (donc uniquement les changements) sur le serveur de destination. Il y aura moins de données à copier (uniquement ce qui a été modifié) et la copie sera beaucoup plus rapide.
3. La machine virtuelle est alors mise en pause sur le premier serveur et redémarrée sur le second serveur.
4. Des requêtes ARP redirigent les clients sur le nouveau serveur et dans la mesure où l’état de session est maintenu, aucune reconnexion n’est nécessaire pour le client.

Dans ce processus, pour obtenir un temps d’indisponibilité très court, il est nécessaire de porter une attention toute particulière au temps de basculement de l’espace de stockage qui est chronophage.

Ce basculement n'est habituellement pas un problème car comme dans la technologie Quick migration, un cluster n’a souvent qu’un nœud actif accédant aux données. Si l'application doit se déplacer vers un autre nœud, la ressource de stockage physique est démontée puis remontée vers le nouveau nœud actif, ce qui signifie un arrêt de quelques secondes pendant que l’espace de stockage est indisponible.

Ce besoin de quelques secondes pour le déplacement n'est pas acceptable dans le cadre de la virtualisation ou l’on souhaite minimiser au maximum l'arrêt lors du déplacement d'une machine virtuelle entre les nœuds. La solution étant que plusieurs nœuds puissent accéder simultanément au VHD (disque virtuel) sur un espace de stockage.

Présentation des Cluster Shared Volume

Pour accompagner Live migration, Windows Server 2008 R2 met à disposition une nouvelle fonctionnalité avec son rôle Failover Clustering afin de rendre le système de fichiers NTFS clusterisé. Les disques de stockage sont ainsi visibles par tous les nœuds du cluster simultanément.

Les volumes de cluster partagés (cluster shared volume) apparaissent comme des sous-dossiers d'un répertoire. Chaque espace de stockage est appelé volume (par exemple, C:\ ClusterStorage\ Volume1 et C:\ ClusterStorage\ Volume2) et va accueillir sa propre machine virtuelle.

La particularité est que tous les nœuds du cluster peuvent accéder au contenu d'un fichier simultanément, ce qui signifie qu'il n'y a pas de délai si un autre nœud doit commencer à accéder à un VHD.

Principe de fonctionnement

NTFS traite deux types d’informations, les données qui sont le contenu des fichiers en eux même (le contenu de mon document Word par exemple) et les métadonnées qui sont les informations qui permettent d’organiser l’espace de stockage NTFS (l’emplacement où mon contenu se trouve physiquement sur le plateau de mon disque durs par exemple).

Le principe de fonctionnement du CSV est le suivant :

Pour permettre l’accès simultané, il va falloir coordonner les écritures des métadonnées pour éviter de nuire à l’intégrité des informations d’organisation de stockage du système NTFS.

Pour cela, on va définir l’un des nœuds du clustered shared volume comme coordinateur et il aura pour charge de réaliser les écritures des métadonnées pour les autres nœuds. Donc tous les nœuds qui souhaitent écrire sur l’espace de stockage vont envoyer leur requête d’écriture de métadonnées au coordinateur par l’intermédiaire du réseau.

Par contre lorsqu’il va s’agir d’écrire le contenu des données sur le volume, chaque nœud va pouvoir le faire directement. Ce travail consistant la majeur partie de la tâche d’écriture, il n’y aura pas ou très peu de goulot d’étranglement lors des accès classique à un CSV.

CSV est mis en œuvre par le biais du filtre csvfilter.sys qui est chargé de l'interception des demandes de métadonnées NTFS et de tous les I/O dans le cas où un nœud perd la communication avec le volume cible. Un nœud peut alors demander au coordonnateur de s'acquitter de toutes ses I/O si elle ne peut plus communiquer avec le volume cible.

Chaque machine virtuelle étant placée dans son propre sous-dossier, vous n'avez plus besoin d’espace de stockage multiple pour obtenir des capacités de basculement granulaire. Les machines virtuelles vont pouvoir être déplacées de façon indépendante entre les nœuds du cluster.et un seul volume partagé clusterisé suffira (CSV).

Ceci permet de réduire la complexité de l’infrastructure et de minimiser l'espace perdu lorsque l’on gère des centaines de petits LUN.

Conclusion

En résumé, ce système dédié dans un premier temps aux machines virtuelles et donc à Hyper-V permet de garantir un basculement planifié dans les meilleurs délais (scénarios de maintenance exclusivement) et ne pourra pas vraiment être utilisé et bénéfique dans le cadre d'une tolérance de panne.