Sychlora Server - Serveur d'hébergement expérimental

Serveur d'Hébergement Expérimental

Auto-hébergement

Le RAID, du point de vue perte de performance

06/12/2011 15:49

Je ne vais pas vous présenter là un nouvel article sur le RAID, il en existe déjà des milliers sur le net qui se contentent d'expliquer les différences entre le RAID 0, le RAID 1, le RAID 5, le RAID 10, etc. J'ai l'intention d’éclaircir ici quelques mécanismes de transfert de données et le parcours de celles-ci sur un serveur, entre le processeur et un disque dur. Il existe beaucoup de mécanismes qui ont été implémentés au fil des années, et encore plus depuis la popularisation du RAID.

Le RAID a bien sûr d'énormes avantages du point de vue sécurité/fiabilité des données, mais il peut apporter beaucoup d'inconvénients du point de vue perte de performance. Je vais parler ici des différents choix techniques qui s'offrent à tout auto-hébergeur souhaitant mettre en place un système RAID dans le but de fiabiliser ses données en essayant de perdre le moins de performance possible.

Communication du processeur avec les disques durs

Depuis les systèmes les plus anciens, les actions du processeur ont très peu évoluées.
Le processeur envoi un ordre (lire quelques octets à tel endroit par exemple) et il attend la fin de l’exécution par le disque dur pour transférer en mémoire vive les données renvoyées. Bien évidemment, dans la plupart des cas, une seule opération n'est pas suffisante pour écrire ou lire complètement un fichier.

Dans le but de ne pas « bloquer » le processeur sur chaque action, et aussi parce qu'un processeur doit être multitâches, la DMA (ou Direct Memory Access) a été implémentée. Ce mécanisme permet de déléguer les opérations d'attente et de transfert en mémoire vive à une puce dédiée à cet usage. Cette puce renvoie une interruption au processeur lorsque l'action s'est terminée.

Les disques durs ont également reçu une mémoire cache pour stocker les ordres reçus, optimiser aussi la recherche des données, et stocker les données par avance lors d'un accès en lecture séquentielle.
Il y a eu encore d'autres optimisations, mais le but global est ici : le processeur ne doit pas attendre de manière « active » les données des disques durs. Il doit profiter de ce temps d'attente pour exécuter les autres processus en mémoire.

L'arrivée du RAID

Le RAID a été développé à l'origine à cause du coût des disques durs de grosse capacité. Celui-ci est une alternative permettant d'utiliser plusieurs disques « bon marché » dans le but de réduire le coût d'une infrastructure en « simulant » un disque de grande capacité (le concept du JBOD - Just a Bunch Of Disks sur Wikipedia).

Les disques durs les plus anciens ayant un plus gros risque de panne, les différents types de RAID que nous connaissons aujourd'hui ont été développés pour obtenir une solution à la fois fiable et performante.

Les principaux utilisés aujourd'hui sont :
- le RAID 1 (duplication des données sur 2 disques durs ou plus),
- le RAID 0 (répartition des données entre 2 disques durs ou plus),
- le RAID 5 (utilisation d'au moins 3 disques durs, chaque donnée est répartie entre 2 disques et un 3ème stocke les données de parités à tour de rôle).

Le nombre de disque par grappe RAID peut être pair ou impair dans tous les cas.
Il est aussi possible de les utiliser de manière combinée : 2 grappes RAID 0 peuvent former une grappe RAID 1 grâce à 4 disques durs (au minimum), ce que l'on appelle le RAID 1+0 ou RAID 10.

L'utilisation du RAID 5 est toutefois de plus en plus déconseillée en raison du risque qu'elle présente de nos jours. En gros, plus les disques sont gros, plus il faut de temps pour reconstruire une grappe RAID 5, et plus on y passe de temps, plus on risque de perdre un second disque et donc perdre la grappe complète. (article et calculs très intéressant sur aboutNetApp, mais malheureusement écrit en Russe ! - RAID 5 must die ! )

OK, on va faire du RAID, mais avec quoi ?

Il existe plusieurs solutions techniques pour monter un RAID sur son propre serveur :

- Configurer un RAID dans votre système d'exploitation :

Dans ce cas, c'est le système d'exploitation qui gère le RAID, ce que l'on appelle un Raid Soft ou Raid logiciel.

Pour cette solution, le système d'exploitation s'occupe de l'ensemble des échanges avec les disques durs (via la DMA). Dans le cas d'un RAID 0, tout se passe bien, le processeur écrit un coup à droite, un coup à gauche, ce qui divise donc par 2 (ou par le nombre de disque) le temps de lecture et d'écriture d'un fichier sur le disque. En revanche, d'un point de vue fiabilité, on multiplie le risque de perdre l'ensemble de ses données par le nombre de disques durs de la grappe (un seul disque dur défaillant va mettre la grappe RAID hors d'usage : aucune redondance dans ce cas).

Dans le cas d'un RAID 1, on garde l'avantage de diviser le temps de lecture d'un fichier par 2 (sur la plupart des systèmes, on alterne la lecture entre les 2 disques), mais on augmente légèrement le temps d'écriture, car oui, à chaque fois, c'est toujours le système d'exploitation qui gère l'écriture simultanée sur les 2 disques (ou plus) ce qui multiplie donc le nombre d'opérations et d'interruptions entre le processeur et la DMA. Du côté vérification des données, c'est aussi le système d'exploitation qui se charge de corriger une donnée sur un disque lorsqu'elle est fausse (une routine de plus à exécuter).

Le RAID 5 logiciel, que je déconseille encore une fois : c'est le processeur à nouveau qui se charge d'écrire sur tous les disques, ajoute la donnée de parité à chaque écriture, et doit également vérifier cette dernière à chaque lecture.

- Utilisation du contrôleur RAID intégré à la carte mère :
Facile à configurer à partir du BIOS de la carte mère, mais par contre, lors de l'installation du système d'exploitation il faut réussir à lui faire comprendre qu'il doit utiliser des pilotes spécifique à ce contrôleur RAID, sinon tous les disques apparaissent de manière transparente au système d'exploitation.

La seule différence avec la solution précédente, c'est que ce n'est plus le système d'exploitation qui gère les disques, mais les pilotes ajoutés au système d'exploitation. Autrement dit, l'ensemble des points décrits dans le RAID logiciel s'appliquent de la même manière ici.

- Utilisation d'une carte contrôleur RAID : comme pour la solution précédente, la carte contrôleur RAID a son propre BIOS où le type de RAID à utiliser doit être configuré.

On se retrouve face à 2 options : soit la carte possède un processeur et une mémoire qui lui sont propres (voire même une batterie !), soit elle n'a rien de tout ça et il s'agit en fait d'une carte Fake-RAID (autrement dit, encore un autre type RAID logiciel).

Je n'utiliserai pas le terme « semi-matérielle » car la carte Fake-RAID n'est rien de plus qu'un contrôleur de disques durs, le processeur ne lui délègue aucune opération, et il faudra intégrer des pilotes spécifiques pour être sûr de ne pas voir apparaître l'ensemble des disques de manière transparente lors de l'installation d'un système.

- Utilisation d'une vraie carte RAID : dans ce cas, aucun pilote supplémentaire à installer, le système d'exploitation ne peut pas voir les disques durs, il ne voit apparaître que les grappes RAID qui ont été configurées dans le BIOS de la carte. (Des pilotes optionnels pourront être installés plus tard pour communiquer avec la carte RAID et obtenir des informations sur l'état des disques.)

Ce type de carte possède obligatoirement un processeur et de la mémoire dédiée, mais leur prix est vraiment plus élevé que les autres solutions.

(Pas mal d'informations supplémentaires sur cet article du site Serve The Home)

Et qu'est ce que ça peut apporter de plus ?

Ce type de carte coûte au minimum 200 euros, ce qui représente une grosse partie du coût d'un serveur, surtout pour de l'auto-hébergement. Alors qu'est-ce que ça apporte de plus ?

Des nouveaux mécanismes !

Dans les vraies cartes RAID tout d'abord, il y a un processeur dédié. Ce processeur va recevoir les ordres de lecture et d'écriture et va les exécuter. Le système hôte ne gère donc plus qu'une seule interruption par la DMA à chaque écriture ou lecture terminée, peu importe le nombre de disques à l'autre bout de la chaîne.

Qui dit processeur dédié, dit fonctionnement autonome. La plupart des cartes RAID propose une option permettant de vérifier la cohérence des données lorsqu'elle n'est pas sollicitée par le système. La carte va donc automatiquement et régulièrement lire une donnée sur chaque disque et vérifier/corriger le RAID si nécessaire.

Il y a également, de la mémoire vive ! Cette mémoire va constituer un cache exagérément grand pour les données reçues par le système. L'objectif est de ne pas bloquer le système lors de l'écriture d'un fichier de taille moyenne sur la grappe RAID.
Pour chaque donnée à écrire reçue, la carte RAID renvoie immédiatement une interruption pour signaler que l'écriture est terminée. En réalité, elle va stocker les données dans sa mémoire et les écouler au fur et à mesure dans les disques durs. Ainsi, pour une carte RAID avec 128 Mo de mémoire, c'est 128 Mo (ou presque) qui pourront être écrits sans ralentir le système d'exploitation.
Cette option s'appelle généralement Write-Back (par opposition au Write-Through), ou Write-Buffer dans le BIOS des cartes RAID, et est souvent désactivée par défaut !

Avec certaines cartes est fournie une batterie. L'usage de cette batterie est directement lié au mécanisme décrit ci-dessus. Dans le cas où une coupure électrique intervient lors de l'écriture d'un fichier, la batterie sera utilisée pour maintenir les données stockées dans la mémoire vive de la carte RAID. Ainsi au redémarrage, la carte va terminer ses écritures, et éviter de laisser derrière elle un système corrompu ! (Des infos supplémentaires sur le comportement du Write-Back chez EdelweissHosting)

Toujours grâce à leur mémoire vive, certaines cartes RAID permettent d'optimiser les accès en lecture séquentielle sur les disques durs. Lors de la réception d'un ordre de lecture séquentielle, un disque dur va charger automatiquement les données suivantes pour remplir son cache (jusqu'à 64 Mo dans les plus récents). La carte RAID, va pousser un peu plus loin la lecture en demandant automatiquement la lecture des données suivantes et les accumuler elles aussi. Ainsi lors de la réception du prochain ordre, les données seront déjà sur la mémoire de la carte, ou pas très loin sur le cache du disque.

Diminuer les IO WAIT

Sous Linux (l'équivalent existe aussi sous Windows), les IO WAIT représentent le temps d'inactivité du processeur généré par les processus qui attendent un périphérique. (Par opposition au temps Idle, où le processeur est inactif car tous les processus ont déjà été exécutés.)

Sur un système non-optimisé, lors de l'écriture d'un fichier de taille moyenne sur le disque, les IO WAIT seront constamment élevées (à condition que la charge du système soit très faible, sinon d'autres processus s'exécuteront pendant ce temps d'attente, et les IO WAIT seront alors diminuées).

Ces IO WAIT ne sont pas comparables d'un système à un autre, mais elles peuvent être un bon point de référence pour mesurer l'optimisation d'un système et vérifier son fonctionnement en temps normal.

Pour diminuer ces IO WAIT avec une carte RAID, il est préférable d'utiliser les mécanismes d'optimisation de la lecture séquentielle et d'écriture décrits auparavant.

Dans tous les cas, il peut être intéressant d'identifier d'autres sources d'accès aux disques durs :

- L'utilisation du SWAP par exemple, peut générer beaucoup d'IO WAIT. C'est ce qui ralentit principalement le système lors d'une grande utilisation de la mémoire RAM. Le SWAP va permettre de réussir à exécuter l'ensemble des processus sans erreurs, mais cela au prix d'un grand ralentissement du système. Sans mémoire libre, aucun nouveau processus ne pourra être créé (voire pire, le kernel lui-même peut décider de tuer des processus de manière plus ou moins arbitraire – voir le OOM Killer sur le forum Linux.RedHat).
En fonction du système et de la disponibilité qu'on lui demande, il peut parfois être préférable de limiter la SWAP à une valeur très faible pour ne pas exagérer son utilisation lors d'un manque de mémoire vive. Mais de manière générale, être généreux sur la mémoire vive et limiter l'usage de la SWAP, permet d'éviter cette situation (plus d'info sur les réglages de la SWAP, voir à la fin de cet article de la Doc Ubuntu le réglage du Swappiness).

- Séparer, si possible, les programmes et les données. L'utilisation d'un disque (ou d'une grappe RAID) différent pour le système et les données peut aussi diminuer les IO WAIT ou les ralentissements du système. Un processus qui attend une donnée lue sur un disque ne sera ainsi pas bloquant pour un nouveau processus en cours de chargement (dont le programme est situé sur l'autre disque).

En cas de défaillance d'un disque dur

Que va-t-il se passer en cas de défaillance d'un de vos disques dur sur une grappe RAID 1 ?

Dans toutes les solutions, le serveur va continuer de fonctionner (ouf !), mais par la suite, il ne faudra pas perdre de temps pour couper le serveur, échanger le disque mort par un nouveau (de taille au moins égale à celle de l'ancien), et reconfigurer votre RAID.

Ça c'est dans la théorie, maintenant dans la pratique, il y a quelques nuances :

- Pour le RAID logiciel, si c'est le disque avec les blocs de démarrage qui a sauté, une fois le disque remplacé, il faudra recréer votre GRUB/LILO/MBR pour pouvoir redémarrer. Ensuite, monter le nouveau disque dans la grappe RAID (en lignes de commandes) devrait lancer automatiquement la reconstruction. (Plus d'informations sous Linux, le Raid Kernel Wiki)

- Pour le RAID matériel, aucune chance de perdre les blocs de démarrage puisque les disques sont copiés à l'identique, secteurs de boot et table des partitions compris. Une fois entré dans le BIOS de la carte RAID, le nouveau disque pourra être rattaché pour commencer la reconstruction.

Dans ces 2 cas, il existe un mécanisme de «  hot-spare » permettant de garder un ou plusieurs disques de secours connectés au RAID, et inactifs jusqu'à la perte d'un disque. La reconstruction est alors lancée automatiquement avec ce disque de spare.

- Le cas particulier des Fake-RAID, là, il n'y a aucune science exacte. Certaines cartes, ou certains contrôleurs intégrés à la carte-mère proposent de garder un disque en hot-spare. D'autres, moins malins, forceront à utiliser Windows pour reconstruire le RAID grâce à leurs logiciels.

La réaction en chaîne d'une simple panne

Lors qu'une panne intervient, il peut être important de vérifier l'état des autres disques durs de la grappe RAID avant de procéder à la reconstruction avec un nouveau disque (utiliser SmartMonTools pour vérifier les disques – fonctionne également au travers des cartes RAID matérielles).

Exemple de données renvoyées par SmartMonTools :

Device: WDC WD10EARS-00Y Version: 80.0
Serial number: WD-WCAV5560413
Device type: disk
Transport protocol: SAS
Local Time is: Tue Dec 6 00:49:28 2011 CET
Device supports SMART and is Enabled
Temperature Warning Disabled or Not Supported
SMART Health Status: OK

Avec un disque de plus haute gamme :

Device: SEAGATE ST3300657SS Version: 0006
Serial number: 6SJ03G7Q0000M10JHT1
Device type: disk
Transport protocol: SAS
Local Time is: Tue Dec 6 00:50:03 2011 CET
Device supports SMART and is Enabled
Temperature Warning Enabled
SMART Health Status: OK

Current Drive Temperature: 36 C
Drive Trip Temperature: 68 C
Elements in grown defect list: 0
Vendor (Seagate) cache information
Blocks sent to initiator = 3005798529
Blocks received from initiator = 2561768732
Blocks read from cache and sent to initiator = 20135200
Number of read and write commands whose size <= segment size = 80060606
Number of read and write commands whose size > segment size = 34
Vendor (Seagate/Hitachi) factory information
number of hours powered up = 9387.33
number of minutes until next internal SMART test = 12

Error counter log:
Errors Corrected by Total Correction Gigabytes Total
ECC rereads/ errors algorithm processed uncorrected
fast | delayed rewrites corrected invocations [10^9 bytes] errors
read: 41253028 0 0 41253028 41253028 457.124 0
write: 0 0 0 0 0 5730.028 0
verify: 16419028 0 0 16419028 16419028 1081.845 0

Non-medium error count: 14

Dans le cas où les autres disques aussi se trouvent dans un mauvais état, il peut être judicieux de tenter une copie complète de vos partitions vers un nouveau disque, indépendant du RAID (en utilisant donc tous les disques de la grappe comme source).

Ce qu'il risque d'arriver pendant la reconstruction, est que le seul disque survivant lâche à son tour. Le RAID, essayant de se reconstruire sur un nouveau disque, va multiplier les accès et la recherche de données sur l'ancien disque, cela peut malheureusement amplifier le problème et mettre le disque hors d'usage.

Un ensemble de disques homogènes ou hétérogènes ?

Deux disques durs d'une même série, ou d'un même modèle auront des caractéristiques très proches. Cela aura un avantage certain pour les systèmes ayant des gros accès disques, et travaillant en RAID 0 ou RAID 5 (voir le test chez Présence PC). En contrepartie, si vous perdez un disque, il y a de fortes chances d'en perdre un second dans un intervalle de temps relativement court (gamme défectueuse, durée de vie).

Avec un ensemble de disques hétérogènes, cette corrélation est simplement diminuée. Rien n'oblige l'utilisation de 2 disques identiques après tout ! Aucun problème également si leur taille est légèrement différente, mais il est toutefois judicieux d'utiliser des disques ayant les mêmes vitesses de rotation (et donc plus ou moins les même débits) et la même taille (sinon une partie de l'espace aura été achetée pour rien).

En cas de défaillance de la Carte RAID ou de la Carte-Mère

Dans le cas de l'utilisation d'une carte RAID matérielle, il est possible d'utiliser l'un ou l'autre des 2 disques du RAID en direct sur votre carte-mère, cela ne posera pas de problème dans la plupart des cas (sauf peut-être pour la numérotation des disques dans GRUB/LILO/MBR si d'autres disques sont déjà branchés sur la carte-mère).
Cela permettra d'avoir un système opérationnel en attendant le remplacement de la carte.

A partir de là, il faudra dans tous les cas reconstruire votre RAID sur le second disque, cela pourra être fait par une carte RAID de n'importe quelle autre marque (à partir du moment où votre disque est intègre et que vous réussissez à booter votre système avec un seul disque). Remarque : les fabricants de vraies cartes RAID matérielles se comptent sur les doigts d'une main.

Pour le Fake-RAID, rien n'est assuré, l'utilisation du disque directement sur la carte-mère est sûrement possible, mais la reconstruction du RAID ne l'est pas forcément. Éventuellement, elle pourra être remplacée par une carte de la même marque et de la même famille, mais rien ne dit que la carte acceptera de récupérer les 2 disques sans « initialiser » la grappe RAID (et donc tout effacer ).

Pour la carte-mère, difficile d'imaginer un redémarrage du système d'exploitation à moins de remplacer la carte-mère a l'identique ? Ça dépend !
Sous Windows, c'est déjà trop tard, il aurait fallu tout commencer avant la panne ! Sous Linux, oui, et c'est souvent possible sans trop de problèmes ! (plus d'informations sur cet article du site Scottie's Tech.info)

Dans le pire des cas, les données pourront toujours être récupérées en branchant un des disques sur un autre système (la plupart des implémentations du RAID 1 pour les RAID logiciels et matériels ne semble pas utiliser une structure exotique et maintient les disques lisibles par un système sans contrôleur/configuration RAID en particulier – voir l'article de Wikipedia en anglais sur le RAID).

Pour résumer

Lors de la conception d'un système sur lequel vous partagerez beaucoup de données en réseau, et sur lequel un certain nombre d'utilisateurs va se connecter pour regarder un film, encoder une vidéo, écouter de la musique, télécharger comme un goret, mais aussi héberger un ou plusieurs gros sites web, (voir même le tout à la fois), afin de limiter les IO WAIT, n'abusez pas de la SWAP mais soyez généreux sur la RAM (surtout si vous utilisez des machines virtuelles). Posez-vous la question de mettre en place une vraie carte RAID pour garder de bonnes performances sans compromis sur la fiabilité des données.

Pour des systèmes plus raisonnables en termes d'accès aux ressources, on peut très bien imaginer l'installation du système d'exploitation sur un disque SSD de faible capacité (ce qui est moins problématique pour la SWAP dans ce cas), et un RAID 1 logiciel sur 2 disques durs différents (afin de former une grappe hétérogène) dans le but de stocker les données uniquement. Rien ne vous empêche de garder une copie de votre partition système sur un autre disque dur afin d'éviter une réinstallation complète après une défaillance du SSD.
Si aujourd'hui je devais construire un nouveau serveur pour de l'auto-hébergement, je pense que je m'orienterais vers cette solution ! C'est un bon compromis entre la fiabilité des données, la rapidité du redémarrage du système sur le SSD, le temps de réaction, et le prix des composants.

Toujours en rapport avec l'hébergement des sites Web, la mise en place de caches à plusieurs niveaux du système (en fonctions de vos services : cache serveur web, cache base de données, et pourquoi pas un ram disk) sur votre serveur pourra aussi diminuer les accès disques.

Enjoy !

6 commentaires - Ajouter un commentaire