Windows Server 2012 R2 : des technologies de stockage pour améliorer la résilience

Surveillance renforcée de la santé du CSV

Par défaut, Windows Server 2012 R2 utilise une instance unique du service Serveur pour gérer les opérations client/serveur SMB (Server Message Block). Une seconde instance est dédiée aux accès internoeuds du cluster au volume CSV. Cela permet d’améliorer la résilience car si un problème apparaît sur l’une des instances serveur, la seconde reste fonctionnelle.

Microsoft a aussi renforcé la surveillance de la santé du CSV. Dans les cluster failover Windows, un nœud joue le rôle de nœud de coordination. Ce nœud est dans la pratique celui qui contrôle le Cluster Shared Volume et gère les requêtes d’entrées/sorties en provenance des autres nœuds. Dans Windows Server 2012 R2.

Un processus est dédié à la surveillance de la santé de ce nœud de coordination. Si l’état de ce dernier se dégrade, qu’il cesse de répondre, et que les communications au sein du Cluster Shared Volume sont impactées, le nœud libère automatiquement son contrôle sur le CSV et le contrôle est transmis à un autre nœud du cluster.

Une autre amélioration est le support de certaines fonctions de stockage qui n’étaient pas supportées par les CSV dans la version initiale de Windows Server 2012. Dans Windows Server 2012 R2, par exemple, les CSV supportent le Resilient File System ( en plus de NTFS), la déduplication, les parity storage spaces, le tiering de données ainsi que le cache en mode write back des Storage Spaces. Autant de fonctions qui permettent de maximiser les performances ainsi que l’usage des capacités des CSV et qui peuvent s’avérer précieuses dans certains scénarios comme le VDI, par exemple.

Des fonctions de réplication sensiblement améliorées

L’arrivée de Windows Server 2012 R2 s’est aussi accompagnée d’améliorations aux fonctions de réplication d’Hyper-V (Hyper-V replica) qui permettent de répliquer les fichiers de VM entre plusieurs nœuds. L’une des principales nouveautés est le support de répliques multiples qui permet par exemple de disposer une copie locale d’une VM originale et d’une seconde copie sur un datacenter distant.

La mise en œuvre de ce mécanisme de double réplique nécessite toutefois d’être prudent dans la gestion de la bande passante, ne serait-ce que parce que la transmission de la première réplique est gourmande en bande passante, puisque toutes les données de la VM initiale doivent être répliquées (ensuite seuls les deltas sont transmis). Il est parfois plus efficace, notamment si l’on dispose d’une bande passante limitée d’effectuer une copie initiale des VM via un support physique entre les deux datacenters afin de limiter les trafics de données initiaux qu’engendre une réplication initiale. 

Un autre paramètre à surveiller est la fréquence de réplication. Cette dernière peut-être définie entre 30 secondes et 15 minutes. Pour une réplication distante, il est prudent de ne pas utiliser le paramètre le plus court sous peine de multiplier les erreurs de réplications (ce qui après un certain nombre d’échecs requiert l’intervention manuelle d’un administrateur). Sur un lien WAN, un intervalle de réplication de 15 mn n’est pas déraisonnable…