par Sagar Borikar (Copyright © 2011) sagar POINT borikar CHEZ gmail POINT com
et par Rajesh Palani (Copyright © 2011) raj POINT Palani CHEZ emc POINT com
traduction par Alain Boulé (tous droits réservés) alain POINT boule CHEZ free POINT fr
Les systèmes NAS (Unité de Stockage en Réseau - Network attached Storage) couvrent des besoins allant des systèmes de base pour les TPE (entreprises individuelles) possèdant de 2 à 10 serveurs et nécessitant de 1 à 10 TB d'espace de stockage aux systèmes de haut de gamme destinés au marché des PME (Petites et Moyennes Entreprises). Les clients exigent des fonctionalités évoluées à des coûts très bas, étant données les solutions relativement bon marché en termes de disques, en comparaison des solutions qui étaient disponibles il y a 5 ans. Les facteurs clés pour le choix des NAS pour le marché des entreprises individuelles sont les performances réseau et les capacités de stockage. Du fait de prix extrèmement compétitifs, beaucoup de fabricants de NAS s'efforcent de réduire les coûts de fabrication. L'un des défis est de concilier des ressources matérielles minimales et les performances. Le présent article décrit les optimisations (optimisations de code, ajustement des paramètres, etc.) nécessaires pour satisfaire les exigences de performance des systèmes NAS pour PME à ressources restreintes fonctionnant sous Linux.
Un système NAS typique pour PME comporte les composants suivants:
1. Processeur RISC à 500 MHz
2. RAM 256 Mo
3. Contrôleur Ethernet Gigabit intégré
4. PCI 2.0
5. Contrôleur PCI-série ATA hôte
Nous visons principalement les aspects réseau et stockage du noyau pour améliorer les performances. En ce qui concerne l'aspect réseau, nous examinons les optimisations au niveau du périphérique, du gestionnaire et de la pile, dans cet ordre et par ordre décroissant de priorité. Avant de démarrer l'optimisation, on commence par mesurer les performances des accès CIFS, NFS et FTP. Nous pouvons utiliser les outils IOzone, NetBench ou bonnie++ pour caractériser les boitiers NAS en ce qui concerne les performances réseau et stockage. Les goulots d'étranglement de niveau système peuvent être identifiés à l'aide d'outils tels que Sysstat, LTTng ou SystemTap qui emploient des techniques d'instrumentation moins intrusives. L'outil OProfile peut également être utile pour comprendre les goulots d'étranglement de niveau fonctionnel.
Beaucoup de fabricants de matériel incorporent de nombreuses options d'accélération de fonctions spécifiques. Nous décrivons, ci-dessous, les principales qui ont un impact sur les performances système des NAS.
La plupart des périphériques Ethernet Gigabit permettent la fusion des interruptions, ce qui, en commun avec NAPI, améliore les performances. (Référez-vous aux optimisations de niveau gestionnaire ci-dessous). Le choix de la valeur de fusion pour des performances optimales se fait selon une méthode purement itérative et est très dépendant de l'application visée. Pour les systèmes utilisés pour des charges réseau importantes, en particulier les trames jumbo, ou pour les applications à fortes exigences en UC ou pour les UC à faible fréquence, la valeur joue un rôle important pour réduire la fréquence des interruptions de l'UC. Bien qu'il n'existe pas de règle générale pour fixer la valeur de fusion, les aspects ci-dessous sont utiles à la réduction du nombre d'interruptions.
L'activation du filtrage MAC au niveau du périphérique déchargera significativement l'UC du traitement des paquets indésirables et permettra d'éliminer les paquets au niveau du périphérique.
La plupart des périphérique peuvent calculer les sommes de contrôle au niveau du matériel. En choisissant l'option CHECKSUM_HW, on décharge significativement l'UC du calcul des sommes de contrôle et du rejet des paquets en cas d'erreur. Il faut remarquer qu'il s'agit des CRC de niveau physique et non de niveau réseau.
Le contrôleur DMA garde la trace des adresses des buffers et des bits d'appartenance pour les descripteurs en émission et en réception. En fonction de la disponibilité de buffers en mémoire système, le contrôleur DMA va transférer les paquets de ou vers la mémoire. C'est le comportement standard de tout périphérique Ethernet. Les performances peuvent être améliorées en transférant les descripteurs dans la SRAM du composant si elle est disponible sur le processeur. En cas d'augmentation de la fréquence des accès aux descripteurs en réception et en émission, leur transfert en SRAM accélérera l'accès aux buffers.
Le champ de cette optimisation est vaste; elle requiert un traitement lié aux besoins de l'application. Le traitement sera différent selon qu'on optimise seulement la performance du transfert des paquets ou la performance au niveau TCP. Il varie également en fonction de la configuration système et des ressources, c'est à dire qu'il faut tenir compte de l'utilisation des ressources par d'autres applications importantes, les ressources étant les canaux DMA, la mémoire système et le type de rattachement du périphérique, par le bus CPI ou directement sur le composant en Soc par le bus système. Pour le DUT le périphérique Ethernet était rattaché directement au bus système par l'intermédiaire du bridge, aussi nous ne nous intéressons pas directement au cas du bus PCI pour l'optimisation des performances, notez cependant que, dans une certaine mesure, ces optimisations peuvent s'appliquer au cas du bus PCI. La plupart des systèmes NAS sont soumis à un stress important lorsqu'ils fonctionnent pendant plusieurs jours et qu'un nombre important de transferts a lieu pendant ce temps. En particulier pour les systèmes NAS fonctionnant sous Linux, le nombre de buffers libres tend à se réduire au cours du temps et comme l'algorithme pdflush n'est pas optimisé au niveau du noyau pour cette utilisation et etant donné que le mécanisme de vidage du cache est géré individuellement par chaque système de fichier, tout dépend de l'efficacité de l'algorithme de vidage du système de fichier. L'optimisation dépend aussi de l'efficacité du matériel utilisé, en particulier, le contrôleur SATA, les disques, etc. On doit tenir compte des facteurs suivants lorsqu'on optimise au niveau du gestionnaire Ethernet :
On peut masquer les interruptions en émission et ainsi éviter la gigue des interruptions qui se produit en cas d'émission de paquets. Si l'émission se bloque, cela n'aura pas beaucoup d'impact sur l'ensemble du processus réseau, car ce qui compte principalement, ce sont les interruptions en réception.
Désactivez les interruptions sur erreur au niveau du périphérique sauf si vous voulez vraiment réagir aux erreurs et remonter le statut au niveau de l'application pour lui indiquer un problème de niveau périphérique.
Bien que cela conduise à des espaces mémoire inutilisés lors du remplissage des descripteurs, il est toujours mieux d'avoir un alignement efficace des descripteurs en fonction de la largeur du cache et de la largeur du bus.
Il faut faire un compromis pour l'allocation de la mémoire pour la réception, il faut choisir entre la pré-allocation de l'ensemble des buffers, de préférence de taille fixe, en nombre fixe et une utilisation récursive ou alors de faire de l'allocation dynamique des buffers en fonction des besoins. Chaque méthode a ses avantages et ses inconvénients. Dans le premier cas, on consomme de la mémoire et les applications du système ne pourront pas l'utiliser. Cela peut conduire à une fragmentation interne des buffers et à l'incertitude quant à la taille des paquets à recevoir. Mais cela réduira considérablement le nombre d'allocations et de désallocations dans la chaine de réception. Comme on se sert des routines d'allocation et de désallocation de mémoire noyau, il se peut qu'on soit en état de famine de buffers ou en boucle d'attente de libération dans le contexte de la réception et si la mémoire requise n'est pas disponible cela peut conduire à une erreur d'allocation de page. L'allocation dynamique de la mémoire économisera de la mémoire pour les systèmes à mémoire restreinte. Cela permettra aux autres applications de continuer à fonctionner normalement même si le système est soumis à un flux d'E/S important. Il vous faudra cependant payer le prix en temps d'allocation et de libération des buffers au cours du fonctionnement.
Les buffers socket (SKB) sont alloués et libérés par le gestionnaire à l'arrivée des paquets dans les gestionnaires Ethernet standard. En implémentant le recyclage SKB, les sockets sont pré-allouées et sont mises à disposition du gestionnaire à la demande et sont remises dans la file de recyclage lorqu'ils sont libérés par l'implémentation de kfree.
La cohérence de cache n'est en général pas implémentée par la plupart des systèmes matériels ceci pour réduire les coûts, mais si au contraire, elle l'est cela rend le système très performant puisque le logiciel n'a plus besoin d'invalider la ligne de cache et de vider le cache. Surtout en cas de fort stress E/S cela peut avoit un grand impact sur les peformances réseau, ce qui se propagera à la pile de stockage elle-même.
Si l'UC sous-jacente supporte le préchargement, cela augmentera considérablement les performances du système en cas de fort stress. Cela augmente en particulier les performances dans ce cas car cela évite les échecs du cache. Il faut noter que le cache doit être invalidé si cela n'est pas implémenté au niveau du matériel sinon cela nuira grandement aux performances.
Les verrous spin et les verrouillages d'interruptions sont pénalisant en comparaison des verrous légers de type RCU (Read COpy Update ou Lecture Copie Mise à jour). Les mécanismes de verrouillage et de déverrouilage RCU sont bien plus légers que les verrous spin et améliorent beaucoup les performances.
Les paramètres de la pile TCP/IP sont définis en tenant compte de tous les protocoles supportés par le système. En tenant compte de la priorité de l'accès choisi, on peut choisir les paramètres en fonction de ses besoins. Ainsi, NAS utilise CIFS et les protocoles NFS principalement pour le transfert des données.
On pourrait choisir les paramètres suivants :
net.core.rmem_max = 64K net.core.rmem_default = 109568
Alors que cela fournira un espace largement suffisant pour l'enregistrement des paquets TCP en mémoire et de meilleures performances, cela consomme de la mémoire système, il faut alors tenir compte de la mémoire requise par les autres applications pour un fonctionnement normal. Dans les systèmes avec peu de mémoire, les options ci-dessous peuvent être essayées pour vérifier le gain en performance. Il faut insister sur le fait que ces modifications dépendent fortement des applications et ne conduiront pas forcément à un gain de performance tel que celui que nous avons observé dans notre DUT.
Ce paramètre détermine l'instant où le programme pdflush commencera à vider le cache noyau dans le disque. En choisissant une valeur élevée, on augmentera la fréquence d'apparition des threads pdflush pour vider les données vers le disque. Cela permettra de libérer les buffers pour les autres applications lorsque le système est soumis à un stress important. L'inconvénient est que cela peut conduire le système à boucler et à consommer des cycles UC afin de vider les buffers fréquemment et ainsi de louper des paquets.
Le nombre de threads dans le système est de 2 par défaut. En portant ce nombre à 4, on améliore les performances de NFS. Cela permettra de vider les données rapidement et de ne pas rester bloqué en attente longtemps et ainsi d'augmenter le nombre de buffers disponibles pour d'autres applications.
L'optimisation du stockage dépend fortement du système de fichiers utilisé ainsi que des caractéristiques du matériel utilisé pour le stockage, c'est à dire du type d'interface, à savoir un contrôleur SATA intégré ou le bus PCI. Elle dépend aussi du type de contrôleur RAID : matériel ou logiciel. Un contrôleur matériel augmente considérablement le coût du matériel. Ainsi pour les solutions de type individuel (TPE) le contrôleur logiciel "mdam" est employé. En plus du support matériel de la fonctionnalité RAID, la performance dépend du chemin d'E/S logiciel qui comprend le gestionnaire de blocs, le gestionnaire de périphérique et le système de fichier. Les NAS utilisent en général les systèmes de fichier journalisés tels que ext3 ou XFS. XFS est plus couramment utilisé pour des accès séquentiels en écriture ou en lecture du fait de son architecture basée sur la notion de contiguïté, alors que ext3 est bien adapté pour des lectures ou écritures de secteurs qui accèdent à des blocs de 512 octets et non à de grands blocs. Nous avons utilisé XFS pour notre système. L'inconvénient de XFS est la fragmentation dont nous allons parler dans la prochaine section. Les aspects suivants ont été modifiés en vue de l'amélioration des performance au niveau du stockage :
Il y a deux paramètres cruciaux dont dépend la performance du gestionnaire RAID.
On doit fixer la taille des blocs à 64Ko ce qui améliorera les performances des applications de redondance de disque, soit RAID1 ou RAID10.
Le facteur d'entrelacement du cache détermine le facteur d'entrelacement par disque. Le facteur d'entrelacement doit être soigneusement choisi puisqu'il détreminera les données à écrire sur chaque disque du contrôleur RAID. Dans le cas des systèmes de fichier journalisés, il y aura une duplication du disque et cela ralentira les E/S si la taille des blocs et Le facteur d'entrelacement par disque sont élevés.
Du fait de son architecture, XFS requiert de la mémoire en multiples d'étendues. Ceci conduit à une grande fragmentation interne si les blocs sont de petites tailles. XFS demande de la mémoire en multiples de 4 Ko et si l'allocateur de type buddy n'a pas suffisamment de place dans le hachage d'ordre 2 ou 3, alors le système peut se mettre à ralentir jusqu'à ce que les applications libèrent de la mémoire et que le noyau peut la réassembler dans l'allocateur de type buddy. Cela s'observera particulièrement dans les cas de stress important quand le système aura fonctionné pendant plusieurs jours. Cela peut être amélioré en jouant sur le paramètre xfs syncd centisecs (voir ci-dessous) pour vider les données modifiées vers les disques à une fréquence plus élevée.
Le journal (ou le log) joue un rôle important pour les performances de XFS. Chaque sytème de fichier journalisé n'écrit pas directement les données dans les secteurs finaux, mais met à jour une copie dans le journal et écrit plus tard dans les secteurs. Pour obtenir une meilleure performance, XFS écrit le journal au centre du disque alors que les données sont stockées sur les pistes situées à la périphérie du disque. Ceci permet d'éviter au bras du disque un excès de mouvements de rotation, ce qui augmente les performances. Si nous supprimons la contrainte d'avoir le journal et les données sur le même disque, cela améliore considérablement les performances. Une mémoire flash NAND de 64 Mo pour stocker le journal permettrait certainement de réduire les mouvements de rotation du bras.
Lors du montage du système de fichier, on peut choisir les options de montage suivantes : logsize=64M,noatime,nodiratime. L'élimination du temps d'accès pour les fichiers et les répertoires libérera l'UC qui n'aura plus besoin de vérifier constamment les inodes des fichiers et des répertoires.
C'est la fréquence à laquelle XFS vide les données sur le disque. Il videra le contenu du journal et nettoiera les inodes non liés. En fixant ce paramètre à une valeur de 500 on augmentera la fréquence de vidage des données. Cela sera requis si les performances matérielles sont limitées. En particulier lorsque le système est soumis à des écritures constantes, cela est d'un grand bénéfice.
Il s'agit de la fréquence à laquelle XFS nettoie les métadonnées. En la fixant à une valeur basse on aura des nettoyages fréquents des métadonnées pour les étendues qui sont marquées comme modifiés.
Il s'agit de la fréquence à laquelle xfsbufd vide les métadonnées modifiées vers le disque. En la fixant à 500 on obtiendra de fréquents vidages des métadonnées modifiées.
Les paramètres listés en b,c, et d, ci-dessus permettront d'obtenir des améliorations significatives des performances lorsque le journal est contenu dans un disque ou une mémoire flash distincts, au lieu de le stocker sur le même disque que les données.
Des accès en écriture simultanés à des secteurs non contigus conduisent à de nombreux mouvement de rotation du bras, ce qui dégrade de façon inhérente les performances et a un impact sur le débit général du système. Bien qu'on ne puisse pratiquement rien faire pour éviter les accès en écriture aléatoires, nous pouvons contrôler la fragmentation.
Tout système de fichier journalisé aura ce problème lorsque le système fonctionne sur une longue période et est soumis à un stress important. XFS fournit un utilitaire nommé xfs_fsr qui peut être exécuté périodiquement pour réduire la fragmentation sur le disque, bien qu'il ne touche qu'aux étendues modifiées qui ne sont pas utilisées. En réalité les accès E/S aléatoires et les problèmes de fragmentation se conjuguent. Plus la fragmentation sera élevée plus nombreux seront les accès E/S aléatoires et moindre sera le débit. Il est d'une importance vitale de contrôler la fragmentation pour réduire les accès E/S aléatoires.
Nous pouvons facilement nous rendre compte que lorsque le système est soumis à un stress important, le temps passé par le noyau pour le traitement des paquets est plus important que le temps consenti à l'espace utilisateur pour le traitement de bout en bout, c'est à dire en allant du périphérique Ethernet au disque dur.
Après avoir implémenté les fonctionalités ci-dessus, nous avons capturé les données de performance sur le même DUT.
Pour la création RAID, fixer '--chunk=1024'; pour RAID5, fixer
echo 8192 > /sys/block/md0/md/stripe_cache_size
Une dégradation des performance de 37% a été observée après une fragmentation de 99% du système de fichier, par rapport à la situation ou la fragmentation du système de fichiers était de 5%. On peut noter que ces données ont été capturées à l'aide de l'outil bonnie++.
2.7.2 Un journal externe donne une amélioration des performances de 28% par rapport à la situation où il est situé sur le même disque que les données, pour un système avec 99% de fragmentation.
2.7.3 L'exécution de l'utilitaire de défragmentation sfs_fsr sur un système fragmenté à 99% améliore les performances de 37%.
2.7.4 La performance des accès en écriture CIFS pour un fichier de 1 Go sur un système soumis pendant 7 jours à des accès en écritures continus a été amélioré de 133% après l'implémentation des optimisations. Il faut noter que cela concerne les performances de bout en bout y compris les traitements réseau et stockage.
2.7.5. La performance des accès en écriture de NFS a été mesurée à l'aide de IOzone. La performance de NFS en écriture pour un fichier de 1 Go sur un système soumis à des accès continus en écriture pendant 7 jours a été améliorée de 180% après implémentation des optimisations. Il faut noter à nouveau que cela concerne les performances de bout en bout y compris les traitements réseau et stockage.
Alors que les système NAS commerciaux pour PME s'offrent le luxe d'employer du matériel puissant pour satisfaire les exigences de performances, les systèmes NAS pour TPE doivent se contenter de plateformes matérielles à ressources réduites pour satisfaire les exigences en termes de coût. Bien que Linux soit un système d'exploitation généraliste qui doit exécuter beaucoup de code et une grande diversité d'applications et n'est pas nécessairement conçu pour des applications de serveurs NAS embarqués, il est possible de configurer et de régler le système afin d'obtenir de bonnes performances pour ce type d'applications. Le défi est de déterminer le bon ensemble de boutons à manoeuvrer. A l'aide de divers outils de profilage et de mesure de performances, les points chauds en terme de performance et les optimisations afférentes pour un serveur NAS ont été identifiés et documentés.
Mon premier contact avec Linux a eu lieu à partir du célèbre débat Tanenbaum vs. Torvalds. Jusque là, tout ce que j'avais entendu, c'était que Linux n'était rien d'autre qu'un système d'exploitation Unix-like de plus. Mais l'énorme confiance d'un jeune diplômé qui contredisait le célèbre professeur, auteur de Minix, et spécialiste des systèmes d'exploitation pour réseaux, m'a incité à en apprendre plus. A partir de ce jour, je n'ai pas pu délaisser Linux et je ne le pourrai pas non plus à l'avenir. J'ai commencé par comprendre les aspects internes et plus je m'y suis plongé et plus j'ai découvert de joyaux dans cet océan de connaissances. Le développent en Open Source vous incite vraiment à apprendre et à aider les autres à apprendre.
Actuellement, je m'occupe activement de travailler sur le noyau 2.6 et particulièrement sur l'architecture MIPS. J'ai voulu apporter ma modeste contribution à la communauté - quelque soit ce que j'ai pu obtenir lors de la compréhension et du travail avec cette plateforme. J'espère que mes articles seront utiles aux lecteurs de la Gazette Linux.
Raj Palani travaille comme chef de projet sénior en ingéniérie logicielle à EMC Il a conçu et développé du logiciel embarqué depuis 1993. Sa participation au développement de Linux couvre plus d'une décennie.
Adaptation française de la Gazette Linux
L'adaptation française de ce document a été réalisée dans le cadre du Projet de traduction de la Gazette Linux
Cet article est publié selon les termes de la Open Publication License. La Linux Gazette n'est ni produite, ni sponsorisée, ni avalisée par notre hébergeur principal, SSC, Inc.
Vous pourrez lire d'autres articles traduits et en apprendre plus sur ce projet en visitant notre site http://www.traduc.org/Gazette_Linux
Si vous souhaitez apporter votre contribution, n'hésitez pas à nous rejoindre, nous serons heureux de vous accueillir.