La fragmentation dans les environnements SAN

Voilà un sujet qui ouvre le débat: Quid de la fragmentation versus les stockages de type SAN ? Nous sommes tous d’accord sur le fait que les performances E/S peuvent être affectées de façon significative selon le niveau de fragmentation du système de fichiers, surtout lors d’accès séquentiels. Certains benchmarks parlent de 33% de perte de performances sur un RAID-1. Essayons d’y voir plus clair…

Le phénomène de fragmentation s’explique du fait qu’une requête I/O s’exécute sur plusieurs blocs répartis sur différentes endroits du disque, on parle de bloc non contigus. Le but de la défragmentation est de réduire le temps de « voyage » sur les plateaux du disque (positionnement, lecture, continuation de la requête). Prenons un exemple simple, vous devez chercher un dossier de 4 classeurs dans votre bureau qui comporte 10 armoires espacées l’une de l’autre de 5 mètres, la fragmentation s’expliquerait de la façon suivante, vos 4 classeurs sont répartis dans 4 armoires différentes, il va falloir du temps pour constituer l’ensemble de dossier… La défragmentation consisterait à ranger ces 4 classeurs dans une même armoire, les uns à côté des autres 😉 Le gain de temps est considérable !

La taille de la mémoire cache des baies de stockage actuelles est telle que la fragmentation impacte peu les performances. Mais il faut savoir qu’une baie de stockage gère des blocs et est incapable de distinguer quelle I/O est relatif à telle donnée, et encore moins de répartir intelligemment les fragments sur la pile RAID, car la baie de stockage travaille avec de LUNs qui n’ont pas de rapport direct avec la géométrie des disques (plateaux, têtes, secteurs, …)

Un processus de défragmentation sur un disque local alourdit considérablement le travail du disque dur, sur une baie de stockage, cela va être encore pire ! Si vous décidez de défragmenter une partition située sur un RAID-5, tous les autres serveurs accédant à cette ressource seront pénalisés également. A noter que les logiciels de défragmentation agissent uniquement sur le système de fichier du serveur sur lesquel il est installé, et n’a même pas connaissance de quel autre serveur pourrait éventuellement être connecté sur le même LUN… La dégradation est performances peut être dramatique si la taille de la fragmentation est inférieure à la taille de stripe de votre RAID, car une I/O pourrait générer deux requêtes ! Première conclusion, une défragmentation doit être exécutée en dehors des plages de production !

La communauté est perplexe sur le fait qu’une défragmentation pourrait ou non avoir des effets positifs sur les performances. Pour ma part, je suis assez mitigé sur la question, un même RAID-5 pour être découpé en plusieurs LUNs que se partageraient le serveur, comment le processus de défragmentation serait capable de répartir les fragments d’un fichier sur plusieurs disques tout en tenant compte de la taille de stripe de la pile RAID, sachant que les contrôleurs des baies de stockage agissent au niveau bloc… Qui serait en mesure de prouver qu’une défragmentation assurait à coup sûr que les fragments serait répartis de façon optimale sur l’ensemble des disques d’une pile RAID ?

De même, la défragmentation sur les Pools de stockage virtuels ou volume Thin « Provisionné » serait inutile et non recommandé. Dans le premier cas, défragmenter un volume d’un pool contenant plusieurs RAID-10 n’apporterait rien car la couche physique et logique du système disque est complétement abstraite, elle est virtualisée, aucune corrélation entre les secteurs et les blocs ! De même que défragmenter un volume Thin « Provisionné » pourrait nuire à sa fonction première du fait que le processus allouerait inutilement des nouveaux secteurs !

J’amène une autre question sur le tapis: quid de l’Auto Tiering ? Certains algorithmes sont basés au niveau fichier, d’autre au niveau bloc, quoiqu’il en soit il ne faut pas défragmenter un type de volume, car une défragmentation pourrait promouvoir ou rétrograder une donnée inutilement. En principe les algorithmes font de la ré-allocation de façon intelligente et placent la donnée promue ou rétrogradée de façon optimale sur le système de disque approprié.

De la même façon, les volumes repliqués ne doivent pas être défragmentés, car une opération sur un site entraine la même sur l’autre site en plus des opérations de production, idem pour les volume CDP, car les journaux pourraient « exploser » ainsi que pour la déduplication.

Le schéma ci-dessus nous montre plusieurs choses:

• Un fichier VHD est crée sur l’ensemble de la stripe composant la pile RAID, la fragmentation est donc faible, mais techniquement nous pourrions parler de fragmentation du fait qu’il est réparti sur plusieurs disque au lieu d’un seul, mais en environnement SAN/RAID, il est bien plus optimal de lire d’un coup un stripe dans son ensemble ! (augmentation des débits, IOPS, …)
• Par contre, défragmenter « l’intérieur » d’un fichier VHD présenterait de l’intérêt mais n’agit qu’au niveau du système de fichier de la VM
• ce que nous montre ce schéma, et montre bien qu’une défragmentation apporte peu de chose, c’est qu’une donnée fragmentée ou non au niveau du système de fichiers peut être répartie d’un point de vue physique n’importe où sur le RAID, qui dépend de taille de stripe, chunk, etc…
• Néanmoins nous sommes tous d’accord sur le fait qu’une défragmentation consomme moins de ressources…

Certaines solutions, Diskeeper, avancent que leur technologie prends en compte les fonctions avancées des SAN, j’en pas convaincu, Windows ne voit qu’un type de partition et sa taille, mais n’a aucune idée des caractéristiques physiques du disque (IDE, SCSI, RAID, SAN) ! Comment peut t’il savoir qu’un RAID-5 est découpé en plusieurs LUNs ? Est-ce que Windows, lorsqu’il lit un fichier WORD, sait qu’il se trouve sur 3 des 5 disques composants la pile RAID, NON…  C’est pourtant leur promesse…

Pour conclure…

Les contrôleurs des baies de stockage ont déjà pour mission de répartir intelligemment et de façon optimale la localisation des blocs sur le système disque. De plus, la rapidité des disques (15.000 tours, SAS, NCQ, …), la taille des mémoire caches et autres optimisations gomment/diminuent les effets néfastes de la fragmentation.

En fait nous aurions 3 niveaux de fragmentation, à l’intérieur d’une VM, au niveau du VHD, et au niveau du RAID… Une défragmentation agirait beaucoup au niveau des blocs logiques sur l’ensemble des disques composant la pile RAID sans pour autant améliorer les performances, les blocs devant être accéder fréquemment pourraient être déplacés vers des secteurs lents.

L’idéal serait une solution qui ferait la corrélation entre les fichiers (logique) et les blocs au niveau SAN (physique). NetApp propose via sa commande reallocate de ré-allouer via un schedule les blocs !

La défragmentation est clairement nécessaire pour des systèmes DAS ou NAS, sachant que certaines technologies des éditeurs de solution de défragmentation jugent à la volée la rapidité des secteurs logiques avant de faire une ré-allocation des blocs… Pour le reste, j’estime que ce n’est pas nécessaire contrairement à tous les arguments marketing de certains éditeurs, à moins de me convaincre des points évoqués ci-dessus 😉

Voici quelques éléments de réponse complémentaires concernant VMWARE, Hyper-V, et SQL.

Cédric GEORGEOT [MVP]

Je travaille actuellement en tant qu’Enterprise Architect pour le groupe CAPGEMINI. Acteur et expert communautaire reconnu depuis de nombreuses années, j’anime ce site autour des technologies Microsoft, des thématiques du Cloud, des infrastructures, … Je suis également à l’origine de nombreuses publications dans la presse IT.