NTFS vs. ReFS – Comment Décider Lequel Utiliser

Maintenant, vous avez probablement entendu parler du système de fichiers relativement récent de Microsoft « ReFS ». Introduit avec Windows Server 2012, il cherche à dépasser NTFS en termes de stabilité et d’évolutivité. Étant donné que nous stockons généralement les VHDX pour plusieurs machines virtuelles dans le même volume, il semble qu’il s’associe bien aux ReFS. Malheureusement, ce n’était pas le cas… au début. Microsoft a continué d’améliorer les ReFS dans les années qui ont suivi. Il a acquis plusieurs fonctionnalités qui l’ont éloigné de NTFS. Avec sa maturation, devriez-vous commencer à l’utiliser pour Hyper-V? Vous avez beaucoup à considérer avant de prendre cette décision.

Qu’est-ce que ReFS ?

Le surnom « ReFS » signifie « système de fichiers résilient ». Il comprend des fonctionnalités intégrées pour lutter contre la corruption des données. Le site docs de Microsoft fournit une explication détaillée des REFS et de ses fonctionnalités. Un bref récapitulatif:

• Flux d’intégrité: ReFS utilise des sommes de contrôle pour vérifier la corruption de fichiers.
• Réparation automatique : Lorsque ReFS détecte des problèmes dans un fichier, il prend automatiquement des mesures correctives.
• Améliorations des performances: Dans quelques conditions particulières, ReFS offre des avantages de performance par rapport à NTFS.
• Très grand volume et prise en charge des fichiers: Les limites supérieures des REFS dépassent celles de NTFS sans subir les mêmes performances.
• Parité accélérée par miroir: La parité accélérée par miroir utilise beaucoup d’espace de stockage brut, mais elle est très rapide et très résistante.
• Intégration avec des espaces de stockage: De nombreuses fonctionnalités de ReFS ne fonctionnent pleinement qu’en conjonction avec des espaces de stockage.

Avant de vous enthousiasmer pour certains des points précédents, je dois souligner une chose: à l’exception des limites de capacité, ReFS nécessite des espaces de stockage afin de faire son meilleur travail.

Avantages de ReFS pour Hyper-V

ReFS possède des fonctionnalités qui accélèrent certaines activités de machine virtuelle.

• Clonage de blocs: D’après ma lecture, le clonage de blocs est essentiellement une forme de déduplication. Mais, il ne fonctionne pas comme un filtre de système de fichiers ou un scanner. Il n’attend pas passivement les écritures de données arbitraires ni n’analyse périodiquement le système de fichiers à la recherche de doublons. Quelque chose doit l’invoquer activement contre un fichier spécifique. Microsoft indique spécifiquement qu’il peut accélérer considérablement les fusions de points de contrôle.
• VDL clairsemé (longueur de données valide) : Tous les systèmes de fichiers enregistrent la quantité d’espace allouée à un fichier. ReFS utilise VDL pour indiquer la quantité de données de ce fichier. Ainsi, lorsque vous demandez à Hyper-V de créer un nouveau VHDX fixe sur les RÉFÉRENCES, il peut créer le fichier entier en à peu près le même temps que la création d’un VHDX à expansion dynamique. Cela profitera également aux opérations d’extension sur les VHDX à expansion dynamique.

Prenez un peu de temps pour passer en revue ces fonctionnalités. Réfléchissez à leurs applications totales.

ReFS vs NTFS pour Hyper-V: Comparaison technique

Avec l’explication générale à l’écart, vous pouvez maintenant mieux évaluer les différences. Tout d’abord, consultez les tableaux de comparaison sur la page de présentation des ReFS de Microsoft. Pour les déploiements Hyper-V typiques, la plupart des différences signifient très peu. Par exemple, vous n’avez probablement pas besoin de quotas sur vos emplacements de stockage Hyper-V. Faisons notre propre table, mieux adaptée à Hyper-V:

• ReFS gagne : Emplacements de stockage très grands et VHDX très grands
• ReFS gagne : Environnements avec des incidences excessivement élevées de VHDX créés, contrôlés ou fusionnés
• ReFS gagne : Espace de stockage et espaces de stockage Déploiements directs
• NTFS gagne : déploiements à volume unique
• NTFS wins (potentiellement): Déploiements mixtes

Je pense que la plupart de ces choses parlent d’elles-mêmes. Les deux derniers ont probablement besoin d’un peu plus d’explications.

Les déploiements à volume unique Nécessitent NTFS

Dans ce contexte, j’entends par « déploiement à volume unique » les installations où vous avez Hyper-V (y compris son système d’exploitation de gestion) et toutes les machines virtuelles sur le même volume. Vous ne pouvez pas formater un volume de démarrage avec ReFS, ni placer un fichier de page sur ReFS. Une telle installation ne permet pas non plus d’Espaces de stockage ou d’Espaces de stockage Directs, elle manquerait donc de toute façon la plupart des capacités de ReFS.

Les déploiements mixtes peuvent nécessiter NTFS

Certains d’entre nous ont la chance de ne déployer que des machines virtuelles sur des emplacements de stockage dédiés. Tout le monde n’a pas ça. Si votre volume de stockage Hyper-V héberge également des fichiers à d’autres fins, vous devrez peut-être continuer avec NTFS. Passez en revue le dernier tableau en bas de la page de présentation. Il montre les propriétés que vous ne pouvez trouver que dans NTFS. Pour les scénarios de partage de fichiers standard, vous perdez des quotas. Vous pouvez avoir des applications héritées qui nécessitent les propriétés étendues de NTFS ou des noms courts. Dans ces situations, seul NTFS fera l’affaire.

Remarque : Si vous avez une alternative, n’utilisez pas le même hôte pour exécuter des rôles non Hyper-V aux côtés d’Hyper-V. Microsoft ne prend pas en charge le mixage. De même, séparez les machines virtuelles Hyper-V sur les volumes en dehors des volumes contenant d’autres types de fichiers.

Comportement inattendu des arbitres

Le contenu officiel décrit les avantages des flux d’intégrité des ARBITRES. Il utilise des sommes de contrôle pour détecter la corruption de fichiers. S’il trouve des problèmes, il prend des mesures correctives. Sur un volume d’espaces de stockage qui utilise des schémas de protection, il a la possibilité de résoudre le problème. Il le fait avec le volume en ligne, offrant une expérience transparente. Mais que se passe-t-il lorsque les arbitres ne peuvent pas corriger le problème? C’est là que vous devez faire vraiment attention.

Sur la page d’aperçu, la documentation utilise une formulation exceptionnellement vague: « ReFS supprime les données corrompues de l’espace de noms ». La page integrity streams fait pire: « Si la tentative échoue, ReFS renverra une erreur. »En faisant des recherches sur cet article, on m’a parlé d’une activité plus troublante: ReFS supprime les fichiers qu’il juge irréfixables. La section des commentaires au bas de cette page comprend un rapport corroborant. Si vous suivez ce fil de commentaires, vous trouverez une entrée d’un gestionnaire de programmes Microsoft qui indique:

ReFS supprime les fichiers dans deux scénarios:

1. ReFS détecte la corruption des métadonnées ET il n’y a aucun moyen de la corriger. Ce qui signifie que ReFS n’est pas sur un volume redondant d’espaces de stockage où il peut réparer la copie corrompue.
2. ReFS détecte la corruption des données ET le flux d’intégrité est activé ET il n’y a aucun moyen de le réparer. Cela signifie que si le flux d’intégrité n’est pas activé, le fichier sera accessible, que les données soient corrompues ou non. Si ReFS s’exécute sur un volume en miroir à l’aide d’espaces de stockage, la copie corrompue sera automatiquement corrigée.

Le résultat: Si ReFS décide qu’un VHDX a subi des dégâts irrécupérables, il le supprimera. Cela ne vous demandera rien et ne vous donnera aucune occasion d’essayer de récupérer ce que vous pouvez. Si ReFS n’est pas soutenu par la redondance des espaces de stockage, il n’a aucun moyen d’effectuer une réparation. Donc, d’un point de vue, cela fait que les RÉFÉRENCES sur des espaces non stockés ressemblent à une approche à très haut risque. MaisMind

Attention à vos Sauvegardes!

Vous ne devez pas négliger la gravité de la section précédente. Cependant, vous ne devriez pas le laisser vous effrayer non plus. Je comprends certainement que vous pourriez préférer un VHDX partiellement lisible à un VHDX supprimé. À cette fin, vous pouvez simplement désactiver les flux d’intégrité sur les fichiers de vos machines virtuelles. J’ai aussi une autre suggestion.

Ne négligez pas vos sauvegardes ! Si ReFS supprime un fichier, récupérez-le de la sauvegarde. Si un VHDX est corrompu sur NTFS, récupérez-le à partir de la sauvegarde. Avec les arbitres, au moins vous savez que vous avez un problème. Avec NTFS, les problèmes peuvent se cacher beaucoup plus longtemps. Quelle que soit votre configuration, la seule chose sur laquelle vous pouvez compter pour protéger vos données est une solution de sauvegarde solide.

Quand choisir NTFS pour Hyper-V

Vous avez maintenant suffisamment d’informations pour prendre une décision éclairée. Ces conditions indiquent une bonne condition pour NTFS:

• Configurations qui n’utilisent pas d’espaces de stockage, telles que le disque unique ou le RAID du fabricant. Cela seul ne fait pas un point étanche à l’air; veuillez lire la rubrique  » Attention à vos sauvegardes ! » section ci-dessus.
• Systèmes à volume unique (votre hôte n’a qu’un volume C:)
• Systèmes polyvalents (veuillez reconfigurer pour séparer les rôles)
• Stockage sur des hôtes plus anciens que 2016 — Les références n’étaient pas aussi matures sur les versions précédentes. Cela seul n’est pas un point étanche à l’air.
• Votre fournisseur d’applications de sauvegarde ne prend pas en charge les ReFS
• Si vous n’êtes pas sûr des ReFS

Au fil du temps, NTFS perdra sa favorabilité par rapport aux ReFS dans les déploiements Hyper-V. Mais, cela ne signifie pas que NTFS a atteint sa fin. ReFS a des limites incroyablement plus élevées, mais très peu de systèmes utilisent plus d’une fraction de ce que NTFS peut offrir. ReFS possède des fonctionnalités de résilience impressionnantes, mais NTFS possède également des pouvoirs d’auto-guérison et vous avez accès aux technologies RAID pour vous défendre contre la corruption des données.

Microsoft continuera à développer des REFS. Ils pourraient éventuellement le positionner comme le successeur de NTFS. À ce jour, ils ne l’ont pas fait. On dirait qu’ils ne le feront pas demain non plus. Ne vous sentez pas obligé de passer aux ReFS avant votre niveau de confort.

Quand choisir ReFS pour Hyper-V

Certaines situations font des ReFS le choix évident pour stocker des données Hyper-V:

• Espaces de stockage (et Espaces de stockage Directs) environnements
• Volumes extrêmement importants
• VHDX extrêmement volumineux

Vous pouvez créer un argument supplémentaire basé sur les performances pour les REFS dans un environnement avec un taux de désabonnement très élevé de fichiers VHDX. Cependant, ne surestimez pas l’impact de ces améliorations de performance. La différence la plus frappante apparaît lorsque vous créez des VHDX fixes. Pour toutes les autres opérations, vous devez mettre à niveau votre matériel pour obtenir une amélioration significative.

Cependant, je ne veux pas passer sous silence l’avantage des REFS pour de très gros volumes. Si vous avez un volume de stockage de quelques téraoctets et des VHDX de quelques centaines de gigaoctets, les REFS battront rarement NTFS de manière significative. Lorsque vous commencez à penser en termes de centaines de téraoctets, NTFS montrera probablement des goulots d’étranglement. Si vous devez pousser plus haut, ReFS devient votre seul choix.

ReFS brille vraiment lorsque vous le combinez directement avec des espaces de stockage. Sa capacité à effectuer automatiquement une réparation en ligne sans perturbation est vraiment impressionnante. D’une part, les risques de corruption perturbatrice des données sur les systèmes modernes constituent une anomalie statistique. De l’autre, personne qui a souffert d’un tel événement ne se soucie vraiment de son improbabilité.

ReFS vs NTFS sur les systèmes de fichiers invités Hyper-V

Tout ce qui précède ne concerne que le stockage des machines virtuelles Hyper-V. Qu’en est-il des REFS dans les systèmes d’exploitation invités ?

Pour répondre à cette question, nous devons revenir aux points forts de ReFS. Jusqu’à présent, nous n’y avons pensé qu’en termes d’Hyper-V. Les clients ont leurs propres conditions et besoins. Commençons par examiner l’aperçu des références de Microsoft. Plus précisément, les éléments suivants:

 » Microsoft a développé NTFS spécifiquement pour une utilisation générale avec un large éventail de configurations et de charges de travail, mais pour les clients nécessitant spécialement la disponibilité, la résilience et / ou l’échelle fournies par ReFS, Microsoft prend en charge les REFS pour une utilisation dans les configurations et scénarios suivants… »

J’ai mis l’accent sur la partie que je veux que vous considériez. La phrase elle-même vous fait penser qu’ils vont énumérer certaines utilisations, mais ils n’en énumèrent qu’une: « cible de sauvegarde ». Les autres éléments de leur liste ne parlent que de la configuration du stockage. Nous devons donc creuser dans la phrase et extraire ces trois descripteurs pour nous aider à décider: « disponibilité », « résilience » et « échelle ». Vous pouvez jeter les deux premiers immédiatement — vous ne devez pas vous concentrer sur la disponibilité et la résilience du stockage dans une machine virtuelle. Cela nous laisse avec « échelle ». Donc, de très gros volumes et de très gros fichiers. Rappelez-vous, cela signifie des centaines de téraoctets et plus.

Pour une décision plus précise, lisez les comparaisons de fonctionnalités. Si une application que vous souhaitez utiliser dans un invité a besoin de fonctionnalités uniquement disponibles sur NTFS, utilisez NTFS. Personnellement, j’utilise toujours des NTFS à l’intérieur des invités presque exclusivement. ReFS a besoin d’espaces de stockage pour faire son meilleur travail, et Storage Spaces fait son meilleur travail au niveau de la couche physique.

Combinaison de REFS avec NTFS sur l’hôte et les invités Hyper-V

Gardez à l’esprit que le système de fichiers à l’intérieur d’un invité n’a aucune incidence sur le système de fichiers de l’hôte, et vice versa. Pour autant qu’Hyper-V le sache, les VHDX attachés aux machines virtuelles ne sont rien d’autre qu’un ensemble de blocs de données. Vous pouvez utiliser n’importe quelle combinaison qui fonctionne.