| Historique des versions | ||
|---|---|---|
| Version 1.0 | Juillet 2001 | |
| Article sous licence GNU FDL | ||
Il s'agit d'un ensemble de techniques de configuration et d'utilisation de disques dur destinés à travailler simultanément afin d'obtenir divers niveaux de disponibilité, de performance, et de coût. Toutes les implémentations RAID ont en commun une caractéristique essentielle : chaque groupe de disques, quel que soit le nombre de disques physiques qui le constituent, peut apparaître à l'utilisateur comme un seul ou plusieurs disques de plus grande capacité. Un disque RAID est utilisé comme un disque ordinaire. Aucune modification du code des applications n'est requise pour permettre à ces applications de bénéficier des fonctionnalités des solutions RAID. Tout ce qui apparaît à l'utilisateur est un niveau amélioré de performances, de disponibilité, ou des deux.
Le RAID (Redundant Array of Independent Disks) a été conçu à l'Université de Californie à Berkeley en 1987. Les chercheurs tentaient alors de réaliser avec des composants en provenance du marché du PC, une alternative aux grandes solutions de stockage proposées par les constructeurs de machines type mainframe. Le résultat de ces recherches et de ces efforts de développement fut le RAID. De la phase expérimentale de recherche et développement à la phase industrielle de mise en production, et en fonction des évolutions technologiques sur les disques, les domaines d'utilisation du RAID ont notablement évolué. En 1987, les disques de grande capacité, destinés aux grandes machines étaient notablement plus chers que les disques de faible capacité destinés aux solutions naissantes d'informatique personnelle, et présentaient des exigences importantes en termes d'alimentation, de climatisation, d'espace au sol, et de coût. L'auteur se souvient d'unités mordernes de l'époque mesurant environ 1m x 0,80m x 0,50m, pesant approximativement 150 Kg, absorbant quelques 4 ou 5 Kw, et d'une remarquable capacité de 300 Mo. Aujourd'hui, ces grandes unités de disques ont disparu, au profit de disques au format standard, et le RAID est devenu un outil permettant de démultiplier les possibilités offertes par ces nouvelles solutions, et non plus de les remplacer.
La réponse est simple, comme la plupart des bonnes réponses : RAID est un concept permettant de contrôler les trois axes majeurs de votre solution de stockage, à savoir la disponibilité, la performance, et le coût. Associé à d'autres technologies de stockage, RAID peut vous aider à optimiser votre solution de stockage en fonction des contraintes applicatives et des contraintes métier, en améliorant de façon globale le coût total de possession de votre système d'information. RAID n'est pas un seul et unique produit, mais se décline en plusieurs variétés, ou niveaux. Chaque niveau RAID met distinctement l'emphase sur les axes disponibilité, performance et coût. Les différents niveaux de RAID sont numérotés de 0 à 6; on parle alors de RAID 0, RAID 1, ou encore de RAID 0+1. Cette numérotation représente une simple dénomination permettant une identification des différents niveaux, et ne constitue absolument pas une classification en terme de performances. Le meilleur niveau de RAID sera donc celui qui offrira la meilleure adéquation entre les contraintes applicatives et les besoins induits par votre activité. Ensuite, le choix de l'implémentation RAID, laquelle peut être logicielle ou matérielle, aura également une grande importance.
"good, fast and cheap : choose two"
RAID vous donne la possibilité d'optimiser votre système de stockage sur les axes de performance, de disponibilité, et de coût. Formidable, mais ... où est le mais ? Le mais se situe dans le fait qu'il n'est réellement possible d'optimiser simultanément que deux de ces axes. S'il était possible d'optimiser simultanément les trois axes, aucune autre solution n'existerait alors ! Une solution de stockage d'entreprise comprend, outre les composants internes aux systèmes de calcul, tels la mémoire et les différents types de caches, divers types de disques durs (Hard Disk Drives), peut-être des disques électroniques (Solid State Disks), des moyens de stockage de masse (divers types de bandes et de cartouches), de possibles périphériques optiques et magnéto-optiques, ainsi que des équipements de stockage en réseau disponibles à distance pour un ensemble de systèmes de calcul.
Il est donc capital de comprendre les besoins et les contraintes de votre environnement avant d'engager le moindre investissement, RAID n'étant qu'une technologie permettant d'atteindre certains objectifs, et non une solution miracle à tous les problèmes d'entrées-sorties.
La charge en entrées-sorties comporte quatre éléments de base : taux de requête, taux de transfert, pourcentage de lecture, localisation de référence. Une bonne compréhension de chacun de ces paramètres est indispensable pour faire un choix pertinent de votre solution RAID, chaque solution offrant des niveaux de performance variables en fonction de la charge.
Dans la plupart des cas, le taux de requête est le facteur limitatif en entrées-sorties. Les environnements Web, les bases de données, et autres serveurs applicatifs, tendent à constituer des environnements présentant un taux de requêtes élevé, avec par ailleurs de faibles volumes de transferts unitaires (de 8 à 32 Ko par requête). D'autres applications stressent plus notablement les matériels en termes de taux de transfert, comme les applications de CAD, les serveurs de streaming et les environnements graphiques. Les taux de requêtes pour ces environnements sont souvent faibles, mais la taille moyenne des requêtes est souvent importante (64 Ko et au-delà), et le taux de transfert peut aisément excéder les capacités d'un seul axe (c'est-à-dire d'un seul disque physique).
La prise en considération du pourcentage de lecture est important lors de l'étude préalable à la mise en oeuvre d'une solution RAID, en raison de différences significatives entre les performances en lecture et les performances en écriture d'une solution RAID par rapport à une autre.
Le striping améliore les performances en effectuant une répartition des données sur plusieurs disques physiques. Les données sont divisées en segments, couramment appelés "chunks".
Si l'on prend le cas d'un "stripe set" composé de quatre disques physiques, dont nous nommerons les membres A, B, C et D respectivement, le premier chunk est placé sur le disque physique A, le second sur B, le troisième sur C, le quatrième sur D. Le cinquième chunk sera placé sur A, le sixième sur B, et ainsi de suite jusqu'à stockage complet des données. Le stripping est identifié dans les niveaux RAID comme étant le RAID 0.
La relation entre la taille du chunk et la taille moyenne d'une requête détermine si l'utilisation du RAID 0 optimise les performances sur les axes du taux de requête ou du taux de transfert. L'administrateur définit la taille du chunk en fonction des besoins applicatifs.
Si la taille du chunk choisie est importante par rapport à la taille moyenne des requêtes, tous les disques physiques peuvent être capables d'exécuter des requêtes différentes simultanément. Cette répartition de charge, ou load balancing, est particulièrement profitable à la performance des applications présentant un nombre important de requêtes.
Si la taille du chunk est inférieure à la taille moyenne des requêtes, alors plusieurs disques physiques peuvent coopérer à l'exécution d'une même requête, améliorant par conséquent le taux de transfert. Ceci est particulièrement appréciable dans le cas d'applications induisant des transferts de taille importante, étant donné que le temps de transferts représente un pourcentage très élevé du temps total de mise à disposition des données.
La répartition de charge est directement induite par le RAID 0. Hors de l'utilisation du RAID 0, les données se trouvent focalisées sur un seul disque physique (localisation de référence), et cet axe unique devient par conséquent un point de contention, ou "bottleneck".
Lorsque le RAID 0 répartit les données sur plusieurs axes, la charge en entrées-sorties est répartie sur l'ensemble des axes, et la performance globale du système s'en trouve améliorée. La répartition de charge est la manifestation la plus symptomatique du gain de performance obtenu au travers de la mise en oeuvre des solutions RAID 0.
Il existe un autre point d'achoppement sur les performances : la performance lecture au regard de la performance en écriture. La répartition des opérations de lecture dans une charge totale est un facteur déterminant dans le choix d'une solution RAID. Ceci est dû au fait que certains niveaux RAID, notamment les niveaux 1, 5 et 6, offrent des performances en lecture bien supérieures aux performances en écriture. Donc, le pourcentage d'opérations de lecture conditionne directement le temps de réponse de l'application. Ce taux étant propre à chaque application, le meilleur niveau RAID peut différer d'une application à une autre.
Certains systèmes d'exploitation offrent des stratégies de planification des entrées-sorties et de gestion des caches qui peuvent réduire le pourcentage d'opérations de lecture. Ainsi, les opérations de lecture peuvent s'effectuer dans un cache (un buffer, ou tampon), à la latence beaucoup plus faible qu'un disque physique, au lieu d'être effectuées à chaque fois directement sur le disque. La conséquence est un très important pourcentage d'opérations d'écriture (typiquement supérieur à 80%). Il est donc capital de maîtriser les caractéristiques des entrées-sorties tant au niveau applicatif qu'au niveau du système d'exploitation.
Le RAID n'est cependant pas la solution miracle à tous les problèmes d'entrées-sorties. Alors, quelle est la meilleure solution ?
La solution est donc de savoir comment les disques seront utilisés, et non quels disques utiliser.
La haute disponibilité peut être un des bénéfices les plus appréciables des systèmes RAID. Dans ce contexte, la disponibilité est la capacité du système à continuer à permettre l'accès aux données en dépit de la défaillance de l'un des éléments.
Les fournisseurs de solutions parlent le plus souvent de disponibilité en termes manichéens, comme si la disponibilité ne pouvait qu'être ou ne pas être. En réalité, la disponibilité est plutôt une valeur discrète. Il y a beaucoup de niveaux de disponibilité, et de nombreux moyens de l'obtenir, de la sauvegarde hebdomadaire (voire mensuelle) à la mise en place d'une solution résistante au désastre, avec des systèmes redondants. Pour le RAID, la redondance est la principale caractéristique permettant de proposer une amélioration de la disponibilité.
Le shadowing est la méthode la plus simple d'assurer la redondance des données. Pour chaque disque physique, il existe un autre disque aux caractéristiques identiques, contenant les mêmes données. Les données sont écrites sur les deux disques physiques simultanément, et chacun des membres du shadow set contient des données identiques au bit près. Par conséquent, si un disque devient indisponible pour quelque raison que ce soit, le disque miroir offre immédiatement un clone parfait de l'élément manquant. Le taux de disponibilité des données stockées sur un shadow set est excellent, mais à un coût. Ce coût est celui que représente l'investissement de l'exact doublement de la capacité requise pour les opérations du système d'information. Le shadowing est appelé RAID 1.
Il existe une autre solution permettant l'implémentation de la redondance. Cette solution est basée sur des techniques complexes de codage, qui permettent de calculer une parité à partir des données et de stocker cette parité, de telle sorte qu'il soit possible de recalculer les données perdues à partir de cette parité si l'un des éléments devient indisponible. Au sein de la matrice RAID, il devient donc possible de perdre un disque sans que les données qu'il abrite ne soient, elles, perdues. Contrairement au RAID 1, le calcul de parité réduit le coût induit par la redondance à la diminution des capacités et des performances de la matrice RAID si un de ses éléments devient indisponible. La parité autorise la reconstruction des données, mais la vitesse de reconstruction dépend de la charge du système et de la complexité de l'algorithme de reconstruction employé.
Le taux de requête maximum se verra diminué de façon significative pendant la période de reconstruction, laquelle peut être fort longue (quelques heures), en fonction du volume de données à reconstruire.
Il existe deux implémentations de la redondance par calcul de parité au sein des solutions RAID. L'une, le RAID 3, demande qu'un disque dédié à l'écriture des codes de parité calculés soit ajouté au stripe set. L'autre, le RAID 5, effectue une répartition des blocs de parité sur l'ensemble des disques, impactant de façon globale et répartie le volume de stockage utile de la configuration.
Le premier objectif du RAID est de prévenir la perte des données au niveau de la potentialité de perte d'un des disques physiques. Mais la perte de données peut être causée par d'autres phénomènes que la perte d'un disque. Des pannes d'alimentation, des indisponibilités du système de calcul, des aléas de câblage peuvent rendre les données inaccessibles. Si la disponibilité est votre préoccupation, alors le système RAID doit se voir gréé d'alimentations redondantes et de doubles chemins d'accès, ainsi que de contrôleurs doublés. Une stratégie de sauvegarde / restauration efficace doit également être pensée. Gardez présent à l'esprit que, par exemple, la restauration complète d'une configuration RAID, si elle doit être effectuée rapidement, requiert la mise en oeuvre d'unités de bandes rapides.
Par ailleurs, RAID ne protège pas vos données des erreurs commises par les utilisateurs, ou des bogues applicatifs, pas plus que des accidents ou des catastrophes naturelles. Les données sur solutions RAID demandent donc des sauvegardes comme toutes les données.
Si l'on considère un disque avec un MTBF (Mean Time Between Failure = Temps Moyen Entre Panne) de 250 000 heures, cela représente un délai de 28 ans et demi, au cours duquel la probabilité de voir une panne survenir est quasi nulle. Cependant, le MTBF est une mesure statistique, et non absolue. La façon la plus pragmatique d'aborder le MTBF est de raisonner en termes d'AFR (Annual Failure Rate = taux de panne annuel). La détermination de l'AFR pour un disque s'effectue en divisant le MTBF par 8760 (nombre d'heures dans une année) et en multipliant le résultat par 100. Dans notre exemple précédent, 8760 / 250000 * 100 = 3.5%. D'où, si l'on possède une configuration de 100 disques, on peut s'attendre à une perte moyenne de 3 à 4 disques par an. Si, pour certaines applications, comme par exemple les applications de calcul et de simulation, cette perte de fiabilité n'est pas cruciale, elle peut représenter un problème sérieux pour d'autres, comme par exemple les serveurs Web, réseau, données ? La redondance de données RAID est la bonne réponse à ce type de problème.
Les implémentations de solutions RAID peuvent être matérielles ou logicielles. Une implémentation matérielle embarque sur une carte placée sur l'un des bus I/O de votre machine, un processeur et le microcode codant les algorithmes de gestion de la configuration RAID.
Une implémentation logicielle introduit ces algorithmes, généralement au niveau d'un driver, dans le code du système d'exploitation et confie l'exécution des algorithmes au processeur. Chacune de ces solutions présente son lot d'avantages et d'inconvénients : il n'existe pas de règle absolue. Ainsi, pour des budgets réduits, une solution logicielle permet de conserver l'ensemble du matériel existant et de ne pas causer d'investissement important. En revanche, une solution matérielle sera garante de performances supérieures et plus régulières, et offrira généralement une administration plus aisée.
RAID matériel
Pas de surcharge CPU
Gestion et administration simplifiée
RAID logiciel
Surcoût amoindri
Facile à étendre
Le plus grand avantage du RAID réside dans l'amélioration de la disponibilité. Les divers niveaux de RAID présentent des taux différents pour cet axe d'amélioration. Il faut cependant garder présent à l'esprit que les solutions RAID ne protègent que le stockage des données sur les disques. Afin d'obtenir une authentique haute disponibilité, les solutions RAID doivent offrir de bout en bout des caractéristiques de haute disponibilité, avec tous les éléments redondants, une absence de point critique, et offrir des possibilités de dépannage à la volée (hot swap).
Intrinsèquement, le RAID n'induit pas la performance. Les divers niveaux de RAID présentent des niveaux de performance différents, et ce en fonction des axes de performance qui importent pour toute solution donnée. Les différences existent entre les taux de requêtes et les taux de transfert, et également entre les opérations de lecture et les opérations d'écriture. Afin de tirer parti de façon optimale des solutions RAID, il faut connaître les caractéristiques de chacun des niveaux, et par ailleurs maîtriser le profil entrées-sorties de l'environnement applicatif.
Les solutions RAID présentent également la possibilité d'induire des variations de performance au niveau du système d'entrées-sorties. Par exemple, une solution RAID 3 se voyant tout à coup chargée de faire face à une multitude de petites requêtes induira une perte de performance importante, et par conséquent ralentira l'ensemble du système. En conséquence, les solutions RAID ne doivent être mises en oeuvre que lorsque l'environnement est compris, maîtrisé, et stable.
La plupart des niveaux de RAID offrent cependant des performances supérieures aux performances nominales des unités de disques, mais un choix non approprié peut gréver cette performance. Il faut donc penser à comparer les performances attendues des divers niveaux de RAID avec un même nombre de disques, et de même modèle.
RAID offre aussi la possibilité d'améliorer les performances en lecture. Les configurations présentant une part importante d'opérations d'écriture peuvent se trouver pénalisées par la mise en oeuvre d'une solution RAID. Même si cet impact peut être minimisé par l'utilisation de caches, le problème reste entier.
Si la problématique est d'améliorer les performances plutôt que la disponibilité, d'autres solutions peuvent être plus efficaces que les solutions RAID. Ces solutions comprennent les disques électroniques, les outils de défragmentation, et les disques mémoire. Si on considère que 20% des données font l'objet de 80% des requêtes d'entrées-sorties, il peut être plus simple et plus économique de placer ces 20% sur un périphérique offrant de meilleures performances.
Les solutions RAID sont plus coûteuses que les disques classiques de capacité équivalente, et certains niveaux de RAID sont plus coûteux que d'autres. Ne commettez pas l'erreur de supposer que la haute disponibilité des données sur RAID permettent par ailleurs d'économiser sur les sauvegardes. Les sauvegardes restent indispensables, même avec des solutions RAID. Aussi, gardez présent à l'esprit que la capacité totale d'une solution RAID induit des temps de sauvegarde et de restauration plus importants pour les données qui résident sur un seul axe.
C'est le striping traditionnel. Les données sont partitionnées en segments qui sont répartis régulièrement sur l'ensemble des éléments du stripe set. Aucune redondance n'est offerte. En fonction de la taille des segments, le RAID 0 peut améliorer de façon significative les taux de requête ou de transfert. Les taux de transfert se voient améliorés en réduisant la taille des segments par rapport à la taille moyenne des transferts, ce qui a pour conséquence de faire participer l'ensemble des disques de la configuration à une même opération. Par ailleurs, si la taille des segments est définie comme supérieure à la taille moyenne des transferts, une requête se verra dirigée vers un seul disque, et le taux de requête se verra augmenté.
La perte de tout membre appartenant à l'ensemble causera la perte intégrale des données résidant sur ce membre. En raison de l'absence de redondance, il n'y a pas de coût associé au RAID 0.
C'est le shadowing, ou mirroring. Le RAID 1 offre au moins une duplication intégrale de l'ensemble des données, et la duplication de chaque membre garantit la disponibilité de la totalité de données si l'un des membres devient indisponible.
Le RAID 1 peut également offrir de notables améliorations dans les performances des opérations de lecture, car le contrôleur peut sélectionner le disque qui accédera les données le plus rapidement.
En cas d'indisponibilité d'un des disques, l'impact sur les performances est faible, et les conséquences sur la disponibilité sont nulles.
Lors de la remise en service de la configuration, les performances sont impactées pendant toute la durée de reconstruction du shadow set. Le coût d'une solution RAID 1 est de 100%, en raison de l'exact doublement du nombre de disques requis.
C'est la combinaison des deux solutions précédentes, obtenue en réalisant un stripset de shadowsets. Le RAID 0+1 offre les meilleures performances de toutes les solutions RAID en combinant les avantages des deux solutions de base. Le coût de la solution est celle de la solution de base la plus coûteuse, RAID 1.
Les données utilisateur sont réparties à travers un ensemble de disques. Un disque dédié à la parité est ajouté. Les données de parité sont calculées dynamiquement et automatiquement, et stockées simultanément à l'écriture des données utilisateur sur les autres disques.
La taille des segments est petite par rapport à la taille moyenne des transferts. La performance en termes de taux de requête de cette solution est celle d'un disque unitaire, tandis que la performance en termes de taux de transfert se voit améliorée. Le coût de la solution est d'un seul disque supplémentaire.
Utilise des segments de taille importante et avec une répartition de l'écriture des données de parité sur l'ensemble des disques de la configuration. La taille des segments limite généralement le travail à un disque par requête et améliore ainsi le taux de transfert.
En raison de la taille importante des segments, les données provenant des transferts ne sont pas suffisantes pour permettre le calcul des données de parité. Il faut donc prendre en compte que, pour toute opération d'écriture, le contrôleur RAID doit effectuer une opération de lecture, puis d'écriture sur deux disques distincts, ce qui explique que les performances soient inférieures à celles des autres niveaux de RAID.
Les performances du RAID 5 sont notablement plus faibles que celles du RAID 3 en cas de perte d'un seul disque. En cas de perte de deux disques, l'ensemble des données est rendu impossible jusqu'à la remise en état initial de l'ensemble.
Le RAID 6 offre une extrême disponibilité, en réservant deux disques à l'écriture des données de parité, avec en plus des codes de correction d'erreur plus élaborés, ce qui permet de conserver l'accessibilité des données même en cas de perte de deux disques.
Les performances en écriture sont inférieures à celles d'une solution RAID 5, car pour toute opération, l'accès à trois disques distincts (au lieu de deux) est requis. Le coût d'une solution RAID 6 est de deux disques supplémentaires.
Les performances en écriture sont les plus faibles de tous les niveaux de RAID, tandis que la disponibilité est la meilleure. Les taux de requêtes admissibles sont élevés.
Tableau 1. Comparatif des niveaux de RAID
| Niveau RAID | Description | Disponibilité | Taux de requête | Taux de transfert | Facteur de coût | Type d'applications |
|---|---|---|---|---|---|---|
| 0 | Striping | > 1 disque, inversement proportionnelle au nombre de disques | Grands segments : excellent | Petits segments : excellent | 1 | Hautes performances, données non critiques |
| 1 | Shadowing | Très bonne | Bon | Moyen | 2 | Données critiques, disque système |
| 0+1 | Striping-shadowing | Très bonne | Excellent | Bon | 2 | Temps de réponse critique |
| 3 | Striping données, parités dédiée | Très bonne | Faible | Excellent | 1,25 | Grandes entrées-sorties |
| 5 | Striping données + parité | Très bonne | Excellent | Moyen | 1,25 | Lecture intensive |
| 6 | Striping données + parité (2) | Meilleure | Excellent | Bon | 1,5 | Lecture intensive |
| Non RAID | - | Proportionnelle au nombre de disques | Identique à celle d'un disque | Identique à celle d'un disque | 1 | - |
Nous allons nous intéresser principalement à l'implémentation logicielle réalisée à travers le MD (Multiple Devices) driver.
Les implémentations matérielles, quant à elles, sont rendues effectives à travers le support de diverses cartes par la mise à disposition de pilotes. L'ensemble des fonctionnalités étant alors embarqué sur les cartes en question, les opérations de construction et de maintenance des RAIDsets s'effectuent en entrant directement dans le BIOS de la carte, au démarrage de la machine. Ces cartes RAID se comportent vis-à-vis du système d'exploitation comme des contrôleurs SCSI, et se chargent de gérer les dialogues entre les disques physiques et la répartition des données. Seuls les RAIDsets sont visibles depuis le système d'exploitation, les disques physiques restent alors absolument hors de la sphère de l'OS.
Bien évidemment, ces cartes sont supportées sous d'autres environnements (Windows, Unix ou autres systèmes propriétaires) et bénéficient, sous ces autres environnements, de programmes de gestion permettant à l'administrateur d'accéder aux fonctionnalités internes de ces cartes directement à partir du système d'exploitation.
Hélas, trois fois hélas, ces environnements n'ont pas été développés sous Linux et notre système favori se trouve sur ce point assez défavorisé, tout changement de configuration demandant alors, sans alternative possible, un shutdown / reboot.
Il existe plusieurs cartes, de diverses provenances, et on peut citer, de façon non exhaustive, les Mylex (DAC960, Disk Array Controller), les Hewlett-Packard NetRAID et les Compaq Smart Array.
Aujourd'hui disponible dans la plupart des distributions, et présent depuis fort longtemps et gréé d'une interface fort intuitive dans les distributions Red Hat, notamment, le MD driver permet de créer sans peine des RAIDsets lors de l'installation même du système, ce qui permet d'obtenir en quelques clics un système présentant une bonne tolérance aux pannes disque.
Outre l'implémentation de certains des niveaux de RAID qui ont été présentés au début de cet article, MD driver implémente un mode nommé le mode linéaire (linear mode), similaire au RAID 0 dans la mesure où il présente à l'utilisateur ou à l'application un volume virtuel global dont la taille est la somme des tailles des volumes intégrés dans le linear set, mais dans lequel les segments ne sont pas écrits simultanément sur l'ensemble des disques, mais de façon séquentielle. C'est-à-dire que le disque n du linear set ne commencera à être écrit que lorsque le volume n-1 aura été rempli.
Les niveaux de RAID conventionnels implémentés par ailleurs sont les niveaux 0, 1 et 5. Les caractéristiques les plus remarquables de l'implémentation RAID sous Linux sont :
La création d'un RAIDset peut se faire lors de l'installation, ou plus tard dans la vie de la configuration, avec les outils Disk Druid ou encore fdisk. La première étape consistera, comme toujours, à créer des partitions, mais qui n'auront pas le type 83 (Linux Native), mais le type fd (Linux RAID).
Ces partitions seront crées sur les disques préalablement sélectionnés, et ne pourront pas être associées à un point de montage : il faut en effet préalablement créer le périphérique RAID (RAID device), qui sera le seul périphérique visible du niveau utilisateur, et qui possédera quand à lui le point de montage.
Lors de la création du périphérique RAID, on spécifiera donc le point de montage, le niveau de RAID souhaité (0, 1 ou 5), le nom de périphérique RAID (8 au maximum), de md0 à md7, et le type de partition : Linux Native (83). Pour une partition / ou /boot, le seul niveau de RAID possible sera le niveau 1, et il sera obligatoire d'utiliser un des deux premiers disques (premiers au sens de leur identification dans la configuration matérielle).
Une fois ces étapes franchies, le périphérique virtuel mdn ainsi créé sera manipulable comme tout autre périphérique, sans aucune différence, l'ensemble des opérations de gestion s'effectuant de façon transparente pour l'utilisateur.
Si le RAID offre des possibilités intéressantes, il reste cependant un certain nombre de limitations en suspens, la plus embarrassante du point de vue de l'administrateur est peut-être de ne pas avoir la possibilité de changer la taille d'une partition une fois que celle-ci a été créée, en tout cas pas de façon simple et raisonnablement sûre. Développé par l'Open Software Foundation, LVM est devenu un standard de facto, et est à la base des implémentations LVM de True64 Unix (Alpha) et HP-UX (PA-RISC).
LVM sous Linux est très similaire à l'implémentation de Hewlett-Packard sous HP-UX. LVM étend la notion de disque logique sous Linux, et définit de multiples niveaux logiques à partir desquels le stockage peut être géré. Cette adjonction de niveaux logiques permet de définir des groupes au sein desquels il est possible d'effectuer des opérations indépendamment des disques logiques définis.
Une configuration LVM est structurée en Volume Groups, lesquels, constitués de Physical Volumes, abritent des Logical Volumes, qui forment un espace d'allocation globalisé. Note : un Physical Volume peut être tant un disque physique tout entier, un HDD, qu'une partition définie sur un HDD. Cette dénomination, trompeuse, ne doit pas vous induire en erreur.
La taille d'un Logical Volume est définie par le nombre et la taille des Extents qui le composent. Une fois créé, ce Logical Volume peut être utilisé comme une partition ordinaire, en y créant un système de fichiers ou en faisant une zone de swap.
Un Volume Group peut être formé avec un ou plusieurs disques, et il peut y avoir plus d'un Volume Group par système. Dès sa création, le Volume Group devient l'unité de base d'allocation d'espace, en lieu et place du disque physique.
Le très grand avantage de LVM réside dans les possibilités étendues d'administration qu'il offre, ces possibilités étant par ailleurs rendues très accessibles avec un environnement d'administration fort efficace. De plus, LVM permet de combiner ses propres avantages à ceux des solutions RAID hardware que nous avons vues plus avant dans cet article.
LVM peut profiter à toutes les configurations, des plus modestes aux plus étendues. Ainsi, si l'on considère une machine avec un seul disque - pourquoi pas un portable ? - avec trois points de montage distincts, sur trois partitions définies lors de l'installation, /, /usr, /home; on peut facilement envisager la situation suivante : le besoin de nouveaux logiciels induit une saturation de /usr, ou une utilisation intensive de la machine cause une saturation de /home.
Les partitions étant fixes, aucune adaptation n'est possible, et seule une réinstallation peut vous sortir d'affaire. Avec LVM, il aurait suffit de créer sur le disque une seule partition, et de créer un seul Volume Group dans lequel trois Logical Volumes (quatre avec la swap) auraient été définis. Avec les commandes lvreduce ou lvextend, il aurait alors été possible d'adapter, au fur et à mesure des besoins, la taille des partitions à leur utilisation.
L'ajout d'un second disque pourrait dans ce cas permettre de l'intégrer au Volume Group, et de permettre ainsi l'expansion "à la demande" de tout système de fichiers, ou encore envisager la création d'autres Logical Volumes.
Des configurations plus puissantes que celle envisagée ci-dessus peuvent également bénéficier de la puissance de LVM. Prenons l'exemple d'un serveur qui doit assurer plusieurs services, différents, indépendants, aux contraintes diamétralement opposées sur divers plans, comme la sécurité et les caractéristiques entrées-sorties. Comme nous l'avons vu précédemment, les performances d'entrées-sorties sont liées au type d'application.
Dans le cas que l'on vient d'envisager, il est donc difficile de concevoir un système de stockage commun aux applications. Avec LVM, la solution se trouve encore à portée de main : il faut créer un Volume Group par application, dans lequel il sera possible de créer autant de Logical Volumes que requiert l'application qui y est assignée.
Ainsi, à la facilité d'administration, il sera possible de joindre la sécurité et l'isolation entre des applications qui doivent rester séparées : clients différents, environnements de test et de production, etc.
Remplacer un disque défaillant ou aux caractéristiques insuffisantes peut s'avérer problématique. Là encore, LVM, avec la commande pmove, rend la tâche beaucoup moins complexe. Les données présentes sur le disque sont déplacées sur d'autres disques au sein d'un même Volume Group, le changement du disque, à chaud ou à froid, en fonction des caractéristiques hardware est alors possible, et la restitution des données par le même biais, aura permis cette intervention sans altérer la disponibilité du Volume Group.
Cette solution n'est toutefois pas envisageable si les Logical Volumes sont "strippés", l'opération pmove, laquelle peut prendre un temps certain, ne permet pas d'envisager d'arrêt inopiné de la machine.
Les snapshots sont des images instantanées des LV qui permettent ensuite d'effectuer des restitutions. Une commande permet de lancer la génération du snapshot, opération qui s'effectue simultanément à l'utilisation du système, mais avec la sauvegarde des informations existantes au moment où la requête a été initiée.
Bien que les snapshots soient considérablement plus petits que les LV qu'ils sauvegardent, il est néanmoins nécessaire de disposer d'un minimum d'espace libre dans le VG, afin d'y créer un nouveau LV contenant le snapshot du LV sauvegardé.
La problématique autour des snapshots se situe au niveau de la garantie quant à la cohérence des données ainsi sauvegardées. Un snapshot pris à la volée donne pour résultat une image qui possède les caractéristiques d'un système de fichiers (non journalisé) après un crash. Il est donc nécessaire de garantir que la cible du snapshot soit dans un état cohérent, tant au niveau du système qu'au niveau des applications avant de lancer l'opération.
La méthode la plus simple consiste à programmer de brèves pauses applicatives servant à lancer les snapshots. Une autre méthode, cette fois orientée système, implémente des points d'arrêt (hooks) au sein même du kernel, afin de permettre de prendre une image pendant un instant d'inactivité garantie.
Ces exemples sont des "vrais faux" : l'auteur, éloigné de sa machine au moment du bouclage de cet article, n'a pu capturer de session réelle. Les commandes présentées dans cette session artificielle montrent très succintement le type de manipulation possible.
Création de deux physical groups, sur deux partitions différentes = marquage des partitions :
[root@ecrehous /root]# pvcreate /dev/sdb1 [root@ecrehous /root]# pvcreate /dev/sdc1
Création d'un volume group, volgroup, réunissant les deux physical groups précédents :
[root@ecrehous /root]# vgcreate volgroup /dev/sdb1 /dev/sdc1
Et création d'un logical volume de 256 Mo, nommé lvol, appartenant au groupe volgroup :
[root@ecrehous /root]# lvcreate -L256 -nlvol volgroup
Il est possible de permettre au groupe de s'étendre en lui intégrant une nouvelle partition :
[root@ecrehous /root]# vgextend volgroup /dev/sdd1
Puis il est possible d'augmenter la capacité du logical volume, de 256 Mo dans cet exemple :
[root@ecrehous /root]# lvextend -L+256 /dev/volgroup/lvol
| Sistina |
| http://www.sistina.com |
| Logical Volume Manager HOWTO |
| http://www.linuxdoc.org/HOWTO/LVM-HOWTO.html |
| The Software-RAID HOWTO |
| http://www.linuxdoc.org/HOWTO/Software-RAID-HOWTO.html |
| Linux DPT Hardware RAID mini-HOWTO |
| http://www.linuxdoc.org/HOWTO/mini/DPT-Hardware-RAID.html |
| Bonnie++ |
| http://www.coker.com.au/bonnie++/ |