drive a device /dev/da3h volume myvol plex org concat sd length 512m drive a
Chapitre 22. Le gestionnaire de volume Vinum
This translation may be out of date. To help with the translations please access the FreeBSD translations instance.
Sommaire
22.1. Synopsis
Peu importe les disques dont vous disposez, ils seront toujours limités:
Ils pourront être trop petits.
Ils pourront être trop lents.
Ils pourront être peu fiables.
22.2. Les disques sont trop petits
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.
22.3. Les goulots d’étranglement d’accès aux données
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.
22.4. Intégrité des données
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:
Le prix. Il demande au moins deux fois autant d’espace disque qu’une solution non-redondante.
L’impact sur la performance. Les écritures doivent être effectuées sur les deux disques, elles prennent donc deux fois plus de bande passante que sur un volume sans miroir. Les lectures de souffrent pas de baisse de performance: elles semblent même plus rapides.
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.
22.5. Objets Vinum
Afin de résoudre ces problèmes, Vinum implémente une hiérarchie d’objets à quatre niveaux:
L’objet le plus visible est le disque virtuel, appelé volume. Les volumes ont essentiellement les mêmes propriétés qu’un disque UNIX™, bien qu’il y ait quelques différences mineures. Ils n’ont aucune limitation de taille.
Les volumes sont composés de plexes, chacune d’entre elles représente l’ensemble de l’espace d’adressable d’un volume. Ce niveau dans la hiérarchie permet ainsi la redondance. Pensez aux plexes comme différents disques dans un ensemble miroir, chacun contenant les mêmes données.
Comme Vinum existe dans le système de stockage disque d’UNIX™, il serait possible d’utiliser les partitions UNIX™ pour construire des blocs pour des plexes à disques multiples, mais en fait cela ne serait pas suffisamment flexible: les disques UNIX™ ne peuvent avoir qu’un nombre limités de partitions. Au lieu de cela Vinum subdivise une simple partition UNIX™ (le disque) en zones contiguës appelées sous-disques, qui sont utilisés comme bloc pour construire les plexes.
Les sous-disques résident sur le disque Vinum, en fait les partitions UNIX™. Les disques Vinum peuvent contenir un nombre quelconque de sous-disque. A l’exception d’une petite zone au début du disque, qui est utilisée pour stocker les informations de configuration et d’état, l’intégralité du disque est disponible pour le stockage des données.
Les sections suivantes décrivent la façon dont ces objets fournissent les fonctionnalités requises pour Vinum.
22.5.1. Considérations sur la taille des volumes
Les plexes peuvent comprendre de multiple sous-disques répartis sur tous les disques dans la configuration Vinum. Par conséquent, la taille d’un disque ne limite pas la taille d’une plex, et donc d’un volume.
22.5.2. Stockage de données redondant
Vinum implémente le mode miroir en attachant de multiples plexes à un volume. Un volume peut contenir entre une et huit plexes.
Bien qu’une plex représente les données complètes d’un volume, il est possible que des parties de la représentation soient physiquement manquantes, soit en raison de la mise en place (en définissant un sous-disque comme ne faisant pas partie de la plex) ou par accident (en raison de la panne d’un disque). Tant qu’au moins une plex peut fournir les données de l’intégralité de la plage d’adresse d’un volume, le volume est totalement fonctionnel.
22.5.3. Problèmes de performance
Vinum implémente la concaténation et la segmentation au niveau de la plex:
Une plex concaténée utilise alternativement l’espace d’adresse de chaque sous-disque.
Une plex segmentée segmente les données sur chaque sous-disque. Les sous-disques doivent avoir la même taille, et il doit y avoir au moins deux sous-disques pour distinguer la plex d’une plex concaténée.
22.5.4. Quelle organisation de plex?
La version de Vinum fournie avec FreeBSD 12.0 implémente deux type de plexes:
Les plexes concaténées sont les plus flexibles: elles peuvent contenir un nombre quelconque de de sous-disques, et les sous-disques peuvent être de taille différentes. La plex peut être étendue en ajoutant des sous-disques supplémentaires. Elles demandent moins de temps CPU que les plexes segmentées, bien que la différence en charge CPU ne soit pas mesurable. D’autre part, elles sont plus susceptibles d’échauffement, là où un disque est très actif et les autres sont au repos.
Le plus grand avantage des plexes segmentées (RAID-0) est qu’elles réduisent les problèmes d’échauffement: en choisissant tailles de segments optimales (environ 256 KO), vous pouvez également réduire la charge des disques. Les inconvénients de cette approche sont un code (infimement) plus complexe et des restrictions sur les sous-disques: ils doivent être de la même taille, et agrandir une plex en ajoutant de nouveaux sous-disques est si complexe que Vinum ne l’implémente pas actuellement. Vinum impose une restriction triviale supplémentaire: une plex segmentée doit avoir au moins deux sous-disques, puisque sinon elle ne serait distinguable d’une plex concaténée.
Organisations de plex Vinum résume les avantages et inconvénients de chaque type d’organisation de plex.
Type de plex | Nombre minimal de sous-disques | Possibilité d’ajout de sous-disques | Doivent être de même taille | Application |
---|---|---|---|---|
concaténée | 1 | oui | non | Stockage de grandes quantités de données avec le maximum de flexibilité en terme de placement et des performances modérées |
segmentée | 2 | non | oui | Haute performance combinée avec un accès hautement concourant |
22.6. Quelques exemples
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.
22.6.1. Le fichier de configuration
Le fichier de configuration décrit les objets Vinum. La définition d’un simple volume pourrait être:
Ce fichier décrit quatre objets Vinum:
La ligne drive une partition disque (drive) et son emplacement relatif par rapport au matériel sous-jacent. On lui donne le nom symbolique a. Cette séparation entre le nom symbolique et le nom du périphérique permet aux disques d’être déplacés d’un emplacement à un autre sans confusion possible.
La ligne volume décrit un volume. Le seul attribut nécessaire est le nom, dans notre cas myvol.
La ligne plex définit une plex. Le seul paramètre requit est l’organisation, dans ce cas concat. Aucun nom n’est nécessaire: le système génère automatiquement un nom à partir du nom de volume en ajoutant le suffixe .px, où x est le nombre de plexes dans le volume. Donc cette plex sera appelée myvol.p0.
La ligne sd décrit un sous-disque. Les spécifications minimales sont le nom du disque sur lequel le stocker et la taille du sous-disque. Comme pour les plexes, aucun nom n’est nécessaire: le système assignera automatiquement des noms dérivés du nom de la plex en ajoutant le suffixe .sx, où x est le nombre de sous-disques dans la plex. Donc Vinum donnera le nom myvol.p0.s0 à ce sous-disque.
Après avoir traité ce fichier vinum(8) affiche ce qui suit:
# vinum - create config1 Configuration summary Drives: 1 (4 configured) Volumes: 1 (4 configured) Plexes: 1 (8 configured) Subdisks: 1 (16 configured) D a State: up Device /dev/da3h Avail: 2061/2573 MB (80%) V myvol State: up Plexes: 1 Size: 512 MB P myvol.p0 C State: up Subdisks: 1 Size: 512 MB S myvol.p0.s0 State: up PO: 0 B Size: 512 MB
Cette sortie affiche une brève liste du format vinum(8). Elle est représentée graphiquement dans Un simple volume Vinum.
Cette figure, et celles qui suivent, représentent un volume qui contient les plexes, qui à leur tour contiennent les sous-disques. Dans cet exemple trivial, le volume contient une plex, et la plex contient un sous-disque.
Ce volume particulier ne présente aucun avantage spécifique par rapport à une partition de disque conventionnelle. Il contient une seule plex, donc il n’est pas redondant. La plex contient un seul sous-disque, il n’y a donc pas de différence dans l’organisation du stockage des données par rapport à une partition de disque conventionnelle. Les sections suivantes présenteront diverses méthodes de configuration plus intéressantes.
22.6.2. Robustesse accrue: le mode miroir
La robustesse d’un volume peut être augmentée par le mode miroir. Quand on implémente un volume en mode miroir, il est important de s’assurer que les sous-disques de chaque plex sont sur des disques différents, de sorte qu’une panne disque ne mette hors service les deux plexes. La configuration suivante place en mode miroir un volume:
drive b device /dev/da4h volume mirror plex org concat sd length 512m drive a plex org concat sd length 512m drive b
Dans cet exemple, il n’était pas nécessaire de spécifier une définition de disque a à nouveau, puisque Vinum garde trace de tous les objets dans sa base de données de configuration. Après le traitement de cette définition, la configuration ressemble à:
Drives: 2 (4 configured) Volumes: 2 (4 configured) Plexes: 3 (8 configured) Subdisks: 3 (16 configured) D a State: up Device /dev/da3h Avail: 1549/2573 MB (60%) D b State: up Device /dev/da4h Avail: 2061/2573 MB (80%) V myvol State: up Plexes: 1 Size: 512 MB V mirror State: up Plexes: 2 Size: 512 MB P myvol.p0 C State: up Subdisks: 1 Size: 512 MB P mirror.p0 C State: up Subdisks: 1 Size: 512 MB P mirror.p1 C State: initializing Subdisks: 1 Size: 512 MB S myvol.p0.s0 State: up PO: 0 B Size: 512 MB S mirror.p0.s0 State: up PO: 0 B Size: 512 MB S mirror.p1.s0 State: empty PO: 0 B Size: 512 MB
Un volume Vinum en mode miroir présente la structure sous forme graphique.
Dans cet exemple, chaque plex contient un espace d’adressage de 512 MO. Comme dans l’exemple précédent, chaque plex contient seulement un seul sous-disque.
22.6.3. Optimiser les performances
Le volume en mode miroir de l’exemple précédent est plus résistant aux pannes qu’un volume sans miroir, mais ses performances sont moindres: chaque écriture sur le volume demande d’écrire sur les deux disques, utilisant alors une plus grande proportion de la bande passante disque totale. Des considérations sur les performances demandent une approche différente: à la place d’un miroir, les données sont segmentées sur autant de disques que possible. La configuration suivante montre un volume avec une plex segmentée sur quatre disques:
drive c device /dev/da5h drive d device /dev/da6h volume stripe plex org striped 512k sd length 128m drive a sd length 128m drive b sd length 128m drive c sd length 128m drive d
Comme précédemment, il n’est pas nécessaire de définir les disques qui sont déjà connus de Vinum. Après traitement de cette définition, la configuration ressemble à:
Drives: 4 (4 configured) Volumes: 3 (4 configured) Plexes: 4 (8 configured) Subdisks: 7 (16 configured) D a State: up Device /dev/da3h Avail: 1421/2573 MB (55%) D b State: up Device /dev/da4h Avail: 1933/2573 MB (75%) D c State: up Device /dev/da5h Avail: 2445/2573 MB (95%) D d State: up Device /dev/da6h Avail: 2445/2573 MB (95%) V myvol State: up Plexes: 1 Size: 512 MB V mirror State: up Plexes: 2 Size: 512 MB V striped State: up Plexes: 1 Size: 512 MB P myvol.p0 C State: up Subdisks: 1 Size: 512 MB P mirror.p0 C State: up Subdisks: 1 Size: 512 MB P mirror.p1 C State: initializing Subdisks: 1 Size: 512 MB P striped.p1 State: up Subdisks: 1 Size: 512 MB S myvol.p0.s0 State: up PO: 0 B Size: 512 MB S mirror.p0.s0 State: up PO: 0 B Size: 512 MB S mirror.p1.s0 State: empty PO: 0 B Size: 512 MB S striped.p0.s0 State: up PO: 0 B Size: 128 MB S striped.p0.s1 State: up PO: 512 kB Size: 128 MB S striped.p0.s2 State: up PO: 1024 kB Size: 128 MB S striped.p0.s3 State: up PO: 1536 kB Size: 128 MB
Ce volume est représenté sur Un volume Vinum segmenté. La couleur des segments indique leur position dans l’espace d’adresses de la plex: le segment le plus clair vient en premier, le plus sombre en dernier.
22.6.4. Robustesse et performances
Avec suffisamment de matériel, il est possible de créer des volumes qui présenteront une robustesse et des performances accrues comparés aux partitions UNIX™ standards. Un fichier de configuration pourrait être:
volume raid10 plex org striped 512k sd length 102480k drive a sd length 102480k drive b sd length 102480k drive c sd length 102480k drive d sd length 102480k drive e plex org striped 512k sd length 102480k drive c sd length 102480k drive d sd length 102480k drive e sd length 102480k drive a sd length 102480k drive b
Les sous-disques de la seconde plex sont décalés de deux disques par rapport à ceux de la première plex: cela aide à s’assurer que les écritures ne vont pas sur les même sous-disques même si un transfert s’effectue sur les deux disques.
Un volume Vinum en mode miroir segmenté représente la structure de ce volume.
22.7. Appellation des objets
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:
Les périphériques de contrôle /dev/vinum/control et /dev/vinum/controld, qui sont respectivement utilisés par vinum(8)et le "daemon" Vinum.
Les entrées des périphériques en mode bloc et caractères par chaque volume. Ce sont les périphériques principaux utilisés par Vinum. Les noms de périphériques en mode bloc sont le nom du volume, alors que les noms de périphériques en mode caractère suivent la tradition BSD de faire précéder le nom de la lettre r. Donc la configuration précédent inclurait les périphériques en mode bloc /dev/vinum/myvol, /dev/vinum/mirror, /dev/vinum/striped, /dev/vinum/raid5 et /dev/vinum/raid10, et les périphériques en mode caractères /dev/vinum/rmyvol, /dev/vinum/rmirror, /dev/vinum/rstriped, /dev/vinum/rraid5 et /dev/vinum/rraid10. Un problème évident apparaît ici: il est possible d’avoir deux volumes appelés r et rr, mais il y aurait un conflit lors de la création du fichier spécial de périphérique /dev/vinum/rr: c’est le périphérique en mode caractère du volume r ou le périphérique en mode bloc du volume rr? Actuellement Vinum ne résout pas ce conflit: le premier volume défini obtiendra le nom.
Un répertoire /dev/vinum/drive avec des entrées pour chaque disque. Ces entrées sont en fait des liens symboliques vers les fichiers spéciaux de périphérique de disque correspondants.
Un répertoire /dev/vinum/volume avec des entrées pour chaque volume. Il contient des sous-répertoires pour chaque plex, qui à leur tour contiennent des sous-répertoires pour leurs sous-disques.
Les répertoires /dev/vinum/plex, /dev/vinum/sd, et /dev/vinum/rsd, qui contiennent les fichiers spéciaux de périphérique en mode bloc pour chaque plex et les fichiers spéciaux de périphérique en mode bloc et caractère pour chaque sous-disque.
Par exemple, considérons le fichier de configuration suivant:
drive drive1 device /dev/sd1h drive drive2 device /dev/sd2h drive drive3 device /dev/sd3h drive drive4 device /dev/sd4h volume s64 setupstate plex org striped 64k sd length 100m drive drive1 sd length 100m drive drive2 sd length 100m drive drive3 sd length 100m drive drive4
Après traitement de ce fichier, vinum(8) crée la structure suivante dans /dev/vinum:
brwx------ 1 root wheel 25, 0x40000001 Apr 13 16:46 Control brwx------ 1 root wheel 25, 0x40000002 Apr 13 16:46 control brwx------ 1 root wheel 25, 0x40000000 Apr 13 16:46 controld drwxr-xr-x 2 root wheel 512 Apr 13 16:46 drive drwxr-xr-x 2 root wheel 512 Apr 13 16:46 plex crwxr-xr-- 1 root wheel 91, 2 Apr 13 16:46 rs64 drwxr-xr-x 2 root wheel 512 Apr 13 16:46 rsd drwxr-xr-x 2 root wheel 512 Apr 13 16:46 rvol brwxr-xr-- 1 root wheel 25, 2 Apr 13 16:46 s64 drwxr-xr-x 2 root wheel 512 Apr 13 16:46 sd drwxr-xr-x 3 root wheel 512 Apr 13 16:46 vol /dev/vinum/drive: total 0 lrwxr-xr-x 1 root wheel 9 Apr 13 16:46 drive1 - /dev/sd1h lrwxr-xr-x 1 root wheel 9 Apr 13 16:46 drive2 - /dev/sd2h lrwxr-xr-x 1 root wheel 9 Apr 13 16:46 drive3 - /dev/sd3h lrwxr-xr-x 1 root wheel 9 Apr 13 16:46 drive4 - /dev/sd4h /dev/vinum/plex: total 0 brwxr-xr-- 1 root wheel 25, 0x10000002 Apr 13 16:46 s64.p0 /dev/vinum/rsd: total 0 crwxr-xr-- 1 root wheel 91, 0x20000002 Apr 13 16:46 s64.p0.s0 crwxr-xr-- 1 root wheel 91, 0x20100002 Apr 13 16:46 s64.p0.s1 crwxr-xr-- 1 root wheel 91, 0x20200002 Apr 13 16:46 s64.p0.s2 crwxr-xr-- 1 root wheel 91, 0x20300002 Apr 13 16:46 s64.p0.s3 /dev/vinum/rvol: total 0 crwxr-xr-- 1 root wheel 91, 2 Apr 13 16:46 s64 /dev/vinum/sd: total 0 brwxr-xr-- 1 root wheel 25, 0x20000002 Apr 13 16:46 s64.p0.s0 brwxr-xr-- 1 root wheel 25, 0x20100002 Apr 13 16:46 s64.p0.s1 brwxr-xr-- 1 root wheel 25, 0x20200002 Apr 13 16:46 s64.p0.s2 brwxr-xr-- 1 root wheel 25, 0x20300002 Apr 13 16:46 s64.p0.s3 /dev/vinum/vol: total 1 brwxr-xr-- 1 root wheel 25, 2 Apr 13 16:46 s64 drwxr-xr-x 3 root wheel 512 Apr 13 16:46 s64.plex /dev/vinum/vol/s64.plex: total 1 brwxr-xr-- 1 root wheel 25, 0x10000002 Apr 13 16:46 s64.p0 drwxr-xr-x 2 root wheel 512 Apr 13 16:46 s64.p0.sd /dev/vinum/vol/s64.plex/s64.p0.sd: total 0 brwxr-xr-- 1 root wheel 25, 0x20000002 Apr 13 16:46 s64.p0.s0 brwxr-xr-- 1 root wheel 25, 0x20100002 Apr 13 16:46 s64.p0.s1 brwxr-xr-- 1 root wheel 25, 0x20200002 Apr 13 16:46 s64.p0.s2 brwxr-xr-- 1 root wheel 25, 0x20300002 Apr 13 16:46 s64.p0.s3
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.
22.7.1. Création de systèmes de fichiers
Les volumes apparaissent pour le système comme des disques, avec une seule exception. Contrairement aux disques UNIX™, Vinum ne partitionne pas les volumes, qui ne contiennent donc pas de table de partitionnement. Cela a demandé de modifier certains utilitaires disque, en particulier newfs(8), qui auparavant tentait d’interpréter la dernière lettre du nom de volume Vinum comme un identifiant de partition. Par exemple, un disque peut avoir un nom comme /dev/ad0a$ ou /dev/da2h. Ces noms représentent respectivement la première partition (a) sur le premier (0) disque IDE (ad) la la huitième partition (h) sur le troisième (2) disque SCSI (da). En revanche, un volume Vinum pourra être appelé /dev/vinum/concat, un nom qui n’a pas de relation avec un nom de partition.
Normalement, newfs(8) interprète le nom du disque et se plaint s’il ne peut le comprendre. Par exemple:
# newfs /dev/vinum/concat
newfs: /dev/vinum/concat: can't figure out file system partition
Afin de créer un système de fichiers sur ce volume, utilisez l’option -v
de newfs(8):
# newfs -v /dev/vinum/concat
22.8. Configuration de Vinum
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.
22.8.1. Démarrage
Vinum stocke l’information de configuration sur les tranches des disques sous la même forme que dans les fichiers de configuration. En lisant à partir de la base de données de configuration, Vinum reconnaît un certain nombre de mots clés qui ne sont pas autorisés dans les fichiers de configuration. Par exemple, une configuration de disque pourrait contenir le texte suivant:
volume myvol state up volume bigraid state down plex name myvol.p0 state up org concat vol myvol plex name myvol.p1 state up org concat vol myvol plex name myvol.p2 state init org striped 512b vol myvol plex name bigraid.p0 state initializing org raid5 512b vol bigraid sd name myvol.p0.s0 drive a plex myvol.p0 state up len 1048576b driveoffset 265b plexoffset 0b sd name myvol.p0.s1 drive b plex myvol.p0 state up len 1048576b driveoffset 265b plexoffset 1048576b sd name myvol.p1.s0 drive c plex myvol.p1 state up len 1048576b driveoffset 265b plexoffset 0b sd name myvol.p1.s1 drive d plex myvol.p1 state up len 1048576b driveoffset 265b plexoffset 1048576b sd name myvol.p2.s0 drive a plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 0b sd name myvol.p2.s1 drive b plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 524288b sd name myvol.p2.s2 drive c plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 1048576b sd name myvol.p2.s3 drive d plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 1572864b sd name bigraid.p0.s0 drive a plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 0b sd name bigraid.p0.s1 drive b plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 4194304b sd name bigraid.p0.s2 drive c plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 8388608b sd name bigraid.p0.s3 drive d plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 12582912b sd name bigraid.p0.s4 drive e plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 16777216b
Ici les différences évidentes sont la présence d’une information explicite sur l’emplacement et le nom (les deux sont également autorisés, mais leur utilisation est déconseillée à l’utilisateur) et de l’information sur les états (qui ne sont pas disponibles à l’utilisateur). Vinum ne stocke pas d’informations au sujet des disques dans la configuration: il localise les disques en recherchant les disques configurés pour les partitions dans le label Vinum. Cela permet à Vinum d’identifier correctement les disques même s’ils ont un identifiant de disque UNIX™ différent.
22.8.1.1. Démarrage automatique
Afin de lancer automatiquement Vinum au démarrage du système, assurez-vous d’avoir la ligne suivante dans votre fichier /etc/rc.conf:
start_vinum="YES" # set to YES to start vinum
Si vous n’avez pas de fichier /etc/rc.conf, créez en un avec cette ligne. Cela provoquera le chargement du module Vinum au démarrage du système, et le lancement de tout objet mentionné dans la configuration. Cela est fait avant de monter les systèmes de fichiers, il est donc possible d’utiliser automatiquement fsck(8) sur des systèmes de fichiers puis de les monter sur des volumes Vinum.
quand vous démarrez avec la commande vinum start
, Vinum lit la base de données de configuration à partir d’un des disques Vinum. Dans des circonstances normales, chaque disque contient une copie identique de la base de données de configuration, il importe donc peu quel disque est lu. Après un crash, Vinum doit déterminer quel disque a été mis à jour le plus récemment et lire la configuration à partir de ce disque. Il met ensuite à jour la configuration si nécessaire à partir de disques progressivement de plus en plus anciens.
Last modified on: 9 mars 2024 by Danilo G. Baio