Chapitre 22. Le gestionnaire de volume Vinum

Peu importe les disques dont vous disposez, ils seront toujours limités:

Vinum est un gestionnaire de volume, un pilote de disque virtuel qui permet de résoudre ces trois problèmes. Regardons-les plus en détails. De nombreuses solutions à ces problèmes ont été proposées et implémentées:

Les disques deviennent de plus en plus gros, mais tout comme les besoins en stockage. Vous vous apercevrez souvent que vous avez besoin d’un système de fichiers plus grand que les disques que vous avez à votre disposition. Bien évidemment, ce problème n’est plus aussi aigu qu’il l’était il y a de cela dix ans, mais il existe toujours. Certains systèmes l’ont résolu en créant un périphérique abstrait qui stocke ses données sur plusieurs disques.

Les systèmes modernes ont fréquemment besoin d’accéder aux données d’une manière hautement concourante. Par exemple, d’importants serveurs FTP ou HTTP peuvent supporter des milliers de sessions concourantes et avoir de multiple connexions à 100 Mbit/s vers le monde extérieur, et cela bien au-delà du taux de transfert soutenu de la plupart des disques.

Les disques actuels peuvent effectuer des transfert séquentiels de données jusqu’à une vitesse de 70 MO/s, mais ce chiffre a peu d’importance dans un environnement où plusieurs processus indépendants accèdent à un disque, où l’on pourra n’atteindre qu’une fraction de cette valeur. Dans de tels cas il est plus intéressant de voir le problème du point de vue du sous-système des disques: le paramètre important est la charge que provoque un transfert sur le sous-système, en d’autres termes le temps d’occupation du disque impliqué dans le transfert.

Dans n’importe quel transfert, le disque doit tout d’abord positionner les têtes de lecture, attendre le passage du premier secteur sous la tête de lecture, puis effectuer le transfert. Ces actions peuvent être considérées comme étant atomiques: cela n’a aucun sens de les interrompre.

Considérons un transfert typique d’environ 10 KO: la génération actuelle de disques hautes performances peuvent positionner leurs têtes en environ 3.5 ms. Les disques les plus véloces tournent à 15000 tr/minute, donc le temps de latence moyen de rotation (un demi-tour) est de 2 ms. A 70 MO/s, le transfert en lui-même prend environ 150 μs, presque rien comparé au temps de positionnement. Dans un tel cas, le taux de transfert effectif tombe à un peu plus de 1 MO/s et est clairement hautement dépendant de la taille du transfert.

La solution classique et évidente à ce goulot d’étranglement est "plus de cylindres": plutôt que d’utiliser un gros disque, on utilise plusieurs disques plus petits avec le même espace de stockage. Chaque disque est en mesure d’effectuer un transfert indépendamment des autres, aussi le taux de sortie augmente d’un facteur proche du nombre de disques utilisés.

L’amélioration du taux réel de sortie est, naturellement, inférieure au nombre de disques impliqués: bien que chaque disque soit capable de transférer en parallèle, il n’y a aucun moyen de s’assurer que les requêtes sont distribuées équitablement entre les disques. Inévitablement la charge d’un disque sera plus importante que celle d’un autre.

La répartition de la charge sur les disques dépend fortement de la manière dont les données sont partagées entre les disques. Dans la discussion suivant, il sera pratique de penser au stockage disque en tant qu’un grand nombre de secteurs qui sont adressables par l’intermédiaire d’un nombre, plutôt que comme les pages d’un livre. La méthode la plus évidente est de diviser le disque virtuel en groupes de secteurs consécutifs de taille égale aux disques physiques individuels et de les stocker de cette manière, plutôt que de les prendre comme un gros livre et de le déchirer en petites sections. Cette méthode est appelée concaténation et a pour avantage que les disques n’ont pas besoin d’avoir de rapport spécifique au niveau de leur taille respective. Cela fonctionne bien quand l’accès au disque virtuel est réparti de façon identique sur son espace d’adressage. Quand l’accès est limité à une petite zone, l’amélioration est moins marquée. Organisation par concaténation décrit la séquence dans laquelle les unités sont assignées dans une organisation par concaténation.

Une organisation alternative est de diviser l’espace adressable en composants plus petits, de même taille et de les stocker séquentiellement sur différents périphériques. Par exemple, les 256 premiers secteurs peuvent être stockés sur le premier disque, les 256 secteurs suivants sur le disque suivant et ainsi de suite. Après avoir atteint le dernier disque, le processus se répète jusqu’à ce que les disques soient pleins. Cette organisation est appelée striping (découpage en bande ou segmentation) ou RAID-0.

La segmentation exige légèrement plus d’effort pour localiser les données, et peut causer une charge additionnelle d’E/S quand un transfert est réparti sur de multiples disques, mais il peut également fournir une charge plus constante sur les disques. Organisation segmentée illustre l’ordre dans lequel les unités de stockage sont assignées dans une organisation segmentée.

Le dernier problème avec les disques actuels est qu’ils ne sont pas fiables. Bien que la fiabilité des disques s’est énormément améliorée depuis quelques années, ils sont toujours le composant principal d’un serveur le plus susceptible de tomber en panne. Et quand cela arrive, les résultats peuvent être catastrophiques: remplacer un disque en panne et restaurer les données peut prendre plusieurs jours.

La méthode originelle d’approche de ce problème fut le mode miroir, en conservant deux copies des données sur un matériel différent. Depuis l’avènement de la technologie RAID, cette technique est également nommée RAID niveau 1 ou RAID-1. Toute opération d’écriture sur le volume écrit sur les deux unités; une lecture peut être acquittée par l’une ou l’autre, aussi si l’un des disque tombe en panne, les données sont toujours accessibles sur l’autre disque.

Le mode miroir présente deux problèmes:

Une alternative est l’utilisation de la parité, implémentée sous les niveaux RAID 2, 3, 4 et 5. De ces niveaux RAID-5 est le plus intéressant. Comme implémenté dans Vinum, c’est une variante de l’organisation segmentée qui dédie un bloc de chaque segment à la parité des autres blocs. Comme implémenté dans Vinum, un volume RAID-5 est identique à un volume segmenté, sauf qu’il implémente RAID-5 en incluant un bloc de parité dans chaque unité. Comme l’exige RAID-5, l’emplacement de ce bloc de parité varie d’une unité à l’autre. Le nombre de blocs de données indique le nombre relatif de blocs.

Comparé au mode miroir, RAID-5 a pour avantage de demander un espace de stockage significativement plus faible. L’accès en lecture est semblable à celui de l’organisation segmentée, mais l’accès en écriture est bien plus lent, approximativement 25% des performances en lecture. Si un disque tombe en panne, l’ensemble peut continuer à fonctionner dans un mode dégradé: une lecture sur un disque restant accessible se poursuit normalement, mais une lecture du disque perdu est recalculée à partir du bloc correspondant sur l’ensemble des disques restants.

Afin de résoudre ces problèmes, Vinum implémente une hiérarchie d’objets à quatre niveaux:

Les sections suivantes décrivent la façon dont ces objets fournissent les fonctionnalités requises pour Vinum.

Vinum maintient une base de données de configuration qui décrit les objets connus pour un système individuel. Initialement, l’utilisateur créé la base de données de configuration à partir d’un ou plusieurs fichiers de configuration avec l’aide de l’utilitaire vinum(8). Vinum conserve une copie de sa base de données de configuration sur chaque tranche (que Vinum nomme device) sous son contrôle. Cette base données est mise à jour à chaque changement d’état, aussi un redémarrage reconstitue exactement l’état de chaque objet Vinum.

Comme décrit précédemment, Vinum assigne des noms par défaut aux plexes et aux sous-disques, bien qu’ils peuvent être imposés. Ne pas conserver les noms par défaut n’est pas recommandé: une expérience avec le gestionnaire de volume VERITAS, qui autorise les noms arbitraires pour les objets, a montré que cette flexibilité n’apporte pas d’avantage significatif, et peut être à l’origine de confusion.

Les noms pourront contenir tout caractère non vide, mais il est recommandé de se cantonner aux lettres, chiffres ou le caractère souligné. Les noms de volumes, plexes et sous-disques peuvent contenir jusqu’à 64 caractères, et le nom des disques 32 caractères.

On assigne à chaque objet Vinum un fichier spécial de périphérique dans la hiérarchie /dev/vinum. La configuration présentée plus haut aurait fait à Vinum créer les fichiers spéciaux de périphérique suivants:

Par exemple, considérons le fichier de configuration suivant:

Après traitement de ce fichier, vinum(8) crée la structure suivante dans /dev/vinum:

Bien qu’il soit recommandé de ne pas donner de nom spécifique aux plexes et sous-disques, les disques Vinum doivent avoir un nom. Cela rend possible de déplacer un disque à un emplacement différent et qu’il soit toujours reconnu automatiquement. Les noms de disques peuvent avoir jusqu’à 32 caractères.

Le noyau GENERIC ne contient pas le support Vinum. Il est possible de compiler un noyau spécial qui inclut vinum, mais cela n’est pas recommandé. La méthode standard de lancement de Vinum est d’utiliser un module du noyau (kld). Vous n’avez même pas besoin d’utiliser kldload(8) pour Vinum: quand vous lancez vinum(8), il contrôle si le module a été chargé ou non, si ce n’est pas le cas, il le charge automatiquement.