Centre de Recherche sur les Matériaux à Haute Température

- Home - News - Conseils - SécuritéMise à jour  -  Liens  -  Accès  -

Centre de Recherche sur les Matériaux à Haute Température
News 2000 Numéro 42 -  Avril 2002 La lettre d'information technique d'Amosdec

- Un RAID a t-il besoin d'un défragmenteur ?
Par Michael Materie, Systems Engineer, MCSE, CCNA, A+, I-NET+ and Howard Butler, Senior Systems Engineer

La fragmentation des RAID est un sujet complexe. Parce que le but du RAID est de permettre la  redondance - améliorant ainsi les performances des disques en répartissant la charge des entrées/sorties - on considère habituellement, mais à tort, que la fragmentation n’a pas d’impact négatif.

Pourtant, les systèmes RAID souffrent de la fragmentation de la même façon qu’un simple disque physique. Cela peut être attribué à la différence entre l’affectation logique des fichiers par rapport à leur localisation physique. Le système de fichiers contrôle l’affectation logique (ce que voit l’OS), dans ce cas, nous faisons référence à ntfs.sys. L’écriture est ensuite passée au gestionnaire de tolérance de pannes (périphérique logiciel ou matériel, cela ne fait aucune différence), qui après, selon les procédures établies, permet le placement du fichier et  génère la parité des informations. Après quoi l’information peut être stockée sur le disque.

Nous considèrerons dans cet article que vous être familiarisé avec les différents types de RAID, qui ne seront donc pas détaillés.

Les volumes agrégés par bandes sont utilisés en partie pour des raisons de performances. L’accès aux données stockées sur un volume agrégé par bandes est en général plus rapide  que  l’accès aux données sur un  simple disque, car les entrées/sorties sont réparties sur plusieurs disques. Ainsi Windows NT/2000 peut effectuer des accès concurrents sur plusieurs disques, autorisant ainsi des opérations de lectures et d’écritures simultanées.

Les volumes agrégés par bandes fonctionnent bien dans les environnements suivants :

  • 1. Quand les utilisateurs ont besoin d’accès rapide à de grandes bases de données ou à d’autres structures de données.
  • 2. Pour le stockage et le chargement rapide de programmes, images, DLL, ou bibliothèques d’exécution
  • 3. Pour des applications utilisant des E/S asynchrones multi-threaded.


Les volumes agrégés par bandes ne sont pas adaptés dans les cas suivants :

  • 1. Quand les programmes effectuent des requêtes pour des quantités limitées de données séquentielles. Par exemple, si un programme réclame 8 Ko à la fois, cela sollicitera jusqu’à 8 E/S pour lire et écrire toutes les données d’une bande de 64 Ko, ce qui n’est pas la meilleure façon d’utiliser ce type de stockage.
  • 2. Quand les programmes effectuent des requêtes synchrones et aléatoires de quantités limitées de données. Cela provoque des goulots d’étranglement d’entrées/sorties car chaque requête nécessite un accès distinct. Les programmes 16 bits single-threaded sont particulièrement concernés par ce problème.

Il est bien connu que les systèmes RAID peuvent exploiter une application bien écrite qui tire avantage des techniques d’E/S asynchrones multi-threaded. Les membres physiques d’un environnement RAID ne sont pas lus ou écrits directement par une application. Même le système de fichiers de Windows NT/2000 le voit comme un seul et unique disque virtuel. Ce disque virtuel dispose de clusters logiques comme n’importe quelle partition supportée par Windows NT/2000. Lorsqu’une application lit et écrit sur cet environnement virtuel (en créant de nouveaux fichiers, en agrandissant ceux qui existent déjà, ou en les supprimant), les fichiers se fragmentent. 
La fragmentation du disque virtuel a un  impact négatif important sur les performances. Lorsqu’une requête est effectuée par le système de fichiers, un grand nombre d’attributs doivent être vérifiés ; cela représente un coût significatif en temps système. Si  une application doit effectuer de multiples requêtes E/S inutiles, comme dans le cas de la fragmentation, ce n’est pas seulement le processeur qui est sollicité plus que de besoin, mais une fois les requêtes effectuées, le RAID (matériel/logiciel) doit déterminer vers quelle unité physique diriger cette requête. Un nombre important d’entrées/sorties provoque de multiples mouvements des têtes des disques physiques. En fait, la fragmentation contrecarre tous les bénéfices apportés par le RAID puisque la bande passante est consommée par ces entrées/sorties inutiles qui le rendent de moins en moins efficace.

La question est maintenant de savoir de quelle façon le défragmenteur peut agir sur ce problème ? Le défragmenteur voit le RAID de la même façon que le système de fichiers. Diskeeper va donc défragmenter le disque virtuel.  Il améliore la vitesse et les performances du RAID en éliminant le gaspillage dû à ces multiples entrées/sorties inutiles demandées par le système de fichiers. Celui-ci, en effet, va  voir  que l’espace libre et les fichiers sont davantage contigus. Le système de fichiers passera donc moins de temps en recherche, ce qui libère du temps processeur pour les applications et l’utilisateur. 

Maintenant, voyons un exemple concret.

Comme nous l’avons vu, si un fichier donné est fragmenté, les requêtes effectuées sur ce fichier demandent à l’OS d’utiliser plus d’E/S sur chaque fragment séparé. Ces requêtes sont transmises au disque physique.

Prenons l’exemple d’un fichier Excel  fragmenté en 100 morceaux. Un simple disque physique aura à faire 100 E/S pour le reconstituer (plus quelques autres pour le lire, l’enregistrer, etc.). Maintenant, que se passe-il si ce disque physique est constitué d’un agrégat par bandes de 5 disques ? Le contrôleur RAID reçoit les E/S et les répartit en quantité égale sur chaque disque (1/5ème de fichier sur chaque disque). Mais si on était sur un RAID 5, un des disques sur chaque bande serait réservé aux informations de parité. Dans ce cas, chaque disque physique doit réaliser 20 E/S pour reconstituer le fichier. Ce n’est pas autant que les 100 du simple disque physique, mais cela fait tout de même 20 accès.

Faisons rentrer Diskeeper en scène. Revenons tout d’abord au disque physique. Diskeeper a défragmenté le fichier logique pour en faire un seul fragment. Accéder à ce fichier ne demandera donc plus qu’une seule E/S. Passons maintenant au RAID 5. Le contrôleur RAID intercepte la requête et la répartit entre les disques. Chaque disque physique doit donc restituer 1/5ème du fichier mais n’effectue qu’une seule E/S au lieu de 20 !

Un défragmenteur (du moins s’il utilise les API) n’est pas concerné par l’architecture physique du stockage en elle même, ni même par le système de fichiers. Ce sont les contrôleurs RAID et les disques qui en sont chargés. Que vous utilisiez des agrégats par bandes, des solutions de miroirs ou des RAID, cela  ne fait aucune différence. Diskeeper ne gère pas lui même la localisation physique des fichiers. 

Page Up Updated 24 septembre, 2003 Hervé Chaudret
C.N.R.S.

-   Home   -  News   -   Conseils   -   Sécurité   -   Mise à jour   -   Liens   -   Accès   -

C.N.R.S.