ReFS est-il prêt à héberger des VHDX de production sur des clusters Hyper-V 2012 r2?

L'une des nouvelles fonctionnalités que je n'ai pas vues répertoriées dans tous les articles "Windows Server 2012 r2" est que le clustering prend désormais en charge les fichiers CSV formatés avec ReFS. Donc, naturellement, je voudrais changer les CSV où je stocke les fichiers VHDX pour être ReFS. Mais les fichiers VHDX sont utilisés pour stocker des fichiers de base de données dans des machines virtuelles exécutant Sql Server 2012.

L'idée est que j'aurais alors un RAID au niveau matériel, protégeant contre une panne instantanée. Au-dessus de cela, le véritable système d'exploitation (Hyper-V Server 2012 r2) les conserverait en tant que volumes ReFS, ce qui protégerait les données de ces disques contre Bitrot. Enfin, les VHDX sont des lecteurs NTFS, ce qui signifie que les applications prises en charge continuent à utiliser le système de fichiers sur lequel elles reposent.

Jusqu'à présent, le mieux que je puisse trouver est que cela est techniquement pris en charge --- car Hyper-V signale que vous devez désactiver le paramètre "intégrité des données" dans le fichier VHDX (applet de commande Set-FileIntegrity) lorsque vous essayez de l'utiliser à partir de le volume ReFS. Mais je ne trouve pas d'informations plus solides que cela. Est-il vraiment prêt pour les heures de grande écoute, ou est-ce en fait juste un aperçu technique pour le clustering?

Modifier: 2014-01-22

J'ai trouvé que ReFS ne détecte que le bitrot par lui-même. Pour que ReFS détecte et répare automatiquement, vous devez également utiliser des espaces de stockage pour créer un volume RAID-1 à l'aide de plusieurs disques ReFS. Il semble donc que ma solution évolue pour que le RAID matériel présente ses disques en tant que JBOD, puis Windows s'occuperait de la partie RAID-1. Je testerai s'il s'agit d'une configuration viable en production au cours du mois prochain.

La réponse est un "non" très clair .

ReFS ne détecte la pourriture des bits dans les données utilisateur que si le fichier en question a activé "Integrity Streams" (Sources: documents officiels TechNet , article de blog préféré de tout le monde et autre endroit ). Oh, et vous perdez également COW (Copy-On-Write) lorsque les flux d'intégrité sont désactivés. Étant donné que vous ne pouvez pas utiliser un VHDX résidant sur un volume ReFS à moins que Integrity Streams ne soit désactivé, vous ne pouvez pas protéger un VHDX contre la pourriture des bits. Jeu terminé.

C'est comme la même personne qui pensait qu'un pool d'espace de stockage en cluster devrait nécessiter au moins 3 disques était également celui qui a pris la décision de faire la meilleure chose sur ReFS quelque chose que vous pourriez désactiver, puis a demandé aux personnes Hyper-V de l'exiger être désactivé. Il est difficile d'imaginer cette quantité de "stupides" répartis à ce jour entre les équipes de base comme ça.

Auxiliaire

En faisant quelques tests, j'ai trouvé ce qui suit qui peut être utile aux personnes qui souhaitent encore avancer:

• Vous pouvez uniquement SLM (Storage Live Migrate) un VHDX en cours d'utilisation vers un volume miroir ReFS si votre destination est un dossier où les flux d'intégrité ont été désactivés.
  • Si vous essayez de faire SLM sur un miroir ReFS où Integrity Streams est activé , vous obtiendrez une erreur avec ceci: "La destination '...' n'est pas valide car elle est configurée avec l'attribut de flux d'intégrité. Sélectionnez une destination qui n'a pas l'attribut de flux d'intégrité pour continuer. ". Vous obtenez la même erreur lors d'une tentative via PowerShell.
• La copie / le déplacement d'un fichier sur un miroir ReFS entraînera le fichier ayant son "bit d'intégrité" défini pour correspondre au paramètre du dossier de destination.
• Vous ne pouvez pas obtenir / définir le bit d'intégrité d'un VHDX en cours d'utilisation.
• Sinon, les performances d'un volume miroir ReFS semblent être assez bonnes (à mon avis, bien sûr) pour la production. Mon test de «différences» est là si quelqu'un s'en soucie.

ReFS est pris en charge, avec l'intégrité des données désactivée, comme vous l'avez découvert. Cela signifie que votre VHD n'est pas "protégé contre le bitrot" comme vous le dites ci-dessus. Le système de fichiers lui-même le serait, mais pas le VHD lui-même. Si cette mesure de protection vous intéresse, allez-y et utilisez ReFS.