/dev/cciss/c0d0
; le noyau de Wheezy l'a changé en quelque chose de plus naturel, à savoir /dev/sda
. Toutefois, d'autres contrôleurs RAID peuvent encore avoir des noms différents.
sdb
, de 4 Go, est entièrement disponible ;
sdc
, de 4 Go, est également entièrement disponible ;
sdd
, seule la partition sdd2
d'environ 4 Go est disponible ;
sde
, toujours de 4 Go, est entièrement disponible.
#
mdadm --create /dev/md0 --level=0 --raid-devices=2 /dev/sda /dev/sde
mdadm: Defaulting to version 1.2 metadata mdadm: array /dev/md0 started. #
mdadm --query /dev/md0
/dev/md0: 7.100GiB raid0 2 devices, 0 spares. Use mdadm --detail for more detail. #
mdadm --detail /dev/md0
/dev/md0: Version : 1.2 Creation Time : Thu Jan 17 15:56:55 2013 Raid Level : raid0 Array Size : 8387584 (8.00 GiB 8.59 GB) Raid Devices : 2 Total Devices : 2 Persistence : Superblock is persistent Update Time : Thu Jan 17 15:56:55 2013 State : clean Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Chunk Size : 512K Name : mirwiz:0 (local to host mirwiz) UUID : bb085b35:28e821bd:20d697c9:650152bb Events : 0 Number Major Minor RaidDevice State 0 8 16 0 active sync /dev/sdb 1 8 32 1 active sync /dev/sdc #
mkfs.ext4 /dev/md0
mke2fs 1.42.5 (29-Jul-2012) Étiquette de système de fichiers= Type de système d'exploitation : Linux Taille de bloc=4096 (log=2) Taille de fragment=4096 (log=2) « Stride » = 128 blocs, « Stripe width » = 256 blocs 1048576 i-noeuds, 2096896 blocs 104856 blocs (5.00%) réservés pour le super utilisateur Premier bloc de données=0 Nombre maximum de blocs du système de fichiers=2147483648 64 groupes de blocs 32768 blocs par groupe, 32768 fragments par groupe 8192 i-noeuds par groupe Superblocs de secours stockés sur les blocs : 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632 Allocation des tables de groupe : complété Écriture des tables d'i-noeuds : complété Création du journal (32768 blocs) : complété Écriture des superblocs et de l'information de comptabilité du système de fichiers : complété #
mkdir /srv/raid-0
#
mount /dev/md0 /srv/raid-0
#
df -h /srv/raid-0
Sys. de fichiers Tail. Uti. Disp. Uti% Monté sur /dev/md0 7,9G 147M 7,4G 2% /srv/raid-0
mdadm --create
requiert en arguments le nom du volume à créer (/dev/md*
, MD signifiant Multiple Device), le niveau de RAID, le nombre de disques (qui prend tout son sens à partir du RAID-1 mais qui est systématiquement obligatoire) et les périphériques à utiliser. Une fois le périphérique créé, nous pouvons l'utiliser comme une partition normale, y créer un système de fichiers, le monter, etc. On notera que le fait que nous ayons créé un volume RAID-0 sur md0
est une pure coïncidence et que le numéro d'un ensemble n'a pas à être corrélé avec le modèle de redondance (ou non) choisi. Il est également possible de créer des volumes RAID nommés, en indiquant à mdadm
des noms de volume comme /dev/md/lineaire
au lieu de /dev/md0
.
#
mdadm --create /dev/md1 --level=1 --raid-devices=2 /dev/sdd2 /dev/sde
mdadm: Note: this array has metadata at the start and may not be suitable as a boot device. If you plan to store '/boot' on this device please ensure that your boot-loader understands md/v1.x metadata, or use --metadata=0.90 mdadm: largest drive (/dev/sdd2) exceeds size (4192192K) by more than 1% Continue creating array?
y
mdadm: Defaulting to version 1.2 metadata mdadm: array /dev/md1 started. #
mdadm --query /dev/md1
/dev/md1: 4.00GiB raid1 2 devices, 0 spares. Use mdadm --detail for more detail. #
mdadm --detail /dev/md1
/dev/md1: Version : 1.2 Creation Time : Thu Jan 17 16:13:04 2013 Raid Level : raid1 Array Size : 4192192 (4.00 GiB 4.29 GB) Used Dev Size : 4192192 (4.00 GiB 4.29 GB) Raid Devices : 2 Total Devices : 2 Persistence : Superblock is persistent Update Time : Thu Jan 17 16:13:04 2013 State : clean, resyncing (PENDING) Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Name : mirwiz:1 (local to host mirwiz) UUID : 6ec558ca:0c2c04a0:19bca283:95f67464 Events : 0 Number Major Minor RaidDevice State 0 8 50 0 active sync /dev/sdd2 1 8 64 1 active sync /dev/sde #
mdadm --detail /dev/md1
/dev/md1: [...] State : clean [...]
mdadm
constate que les deux éléments physiques n'ont pas la même taille ; comme cela implique que de l'espace sera perdu sur le plus gros des deux éléments, une confirmation est nécessaire.
/dev/md1
est utilisable (pour créer le système de fichiers et commencer à copier des données, éventuellement).
mdadm
permet de simuler cette défaillance, grâce à son option --fail
:
#
mdadm /dev/md1 --fail /dev/sde
mdadm: set /dev/sde faulty in /dev/md1 #
mdadm --detail /dev/md1
/dev/md1: [...] Update Time : Thu Jan 17 16:14:09 2013 State : active, degraded Active Devices : 1 Working Devices : 1 Failed Devices : 1 Spare Devices : 0 Name : mirwiz:1 (local to host mirwiz) UUID : 6ec558ca:0c2c04a0:19bca283:95f67464 Events : 19 Number Major Minor RaidDevice State 0 8 50 0 active sync /dev/sdd2 1 0 0 1 removed 1 8 64 - faulty spare /dev/sde
sdd
venait à tomber en panne, les données seraient perdues. Pour éviter ce risque, nous allons remplacer ce disque par un neuf, sdf
:
#
mdadm /dev/md1 --add /dev/sdf
mdadm: added /dev/sdf #
mdadm --detail /dev/md1
/dev/md1: [...] Raid Devices : 2 Total Devices : 3 Persistence : Superblock is persistent Update Time : Thu Jan 17 16:16:36 2013 State : clean, degraded, recovering Active Devices : 1 Working Devices : 2 Failed Devices : 1 Spare Devices : 1 Rebuild Status : 28% complete Name : mirwiz:1 (local to host mirwiz) UUID : 6ec558ca:0c2c04a0:19bca283:95f67464 Events : 26 Number Major Minor RaidDevice State 0 8 50 0 active sync /dev/sdd2 2 8 80 1 spare rebuilding /dev/sdf 1 8 64 - faulty spare /dev/sde #
[...]
[...] #
mdadm --detail /dev/md1
/dev/md1: [...] Update Time : Thu Jan 17 16:16:36 2013 State : clean Active Devices : 2 Working Devices : 2 Failed Devices : 1 Spare Devices : 0 Name : mirwiz:1 (local to host mirwiz) UUID : 6ec558ca:0c2c04a0:19bca283:95f67464 Events : 41 Number Major Minor RaidDevice State 0 8 50 0 active sync /dev/sdd2 2 8 80 1 active sync /dev/sdf 1 8 64 - faulty spare /dev/sde
sde
de l'ensemble, pour se retrouver avec un miroir classique sur deux disques :
#
mdadm /dev/md1 --remove /dev/sde
mdadm: hot removed /dev/sde from /dev/md1 #
mdadm --detail /dev/md1
/dev/md1: [...] Number Major Minor RaidDevice State 0 8 50 0 active sync /dev/sdd2 2 8 80 1 active sync /dev/sdf
sde
était réelle, et si on redémarrait le système sans le retirer, ce disque pourrait, à la faveur du redémarrage, « retomber en marche ». Le noyau aurait alors trois éléments physiques, chacun prétendant représenter la moitié du même volume RAID. Une autre source de confusion peut subvenir si l'on consolide des volumes RAID de deux serveurs sur un seul. Si ces ensembles étaient en fonctionnement normal avant le déplacement des disques, le noyau saura reconstituer les paires correctement. Mais pour peu que les disques déplacés soient agrégés en un /dev/md1
et qu'il existe également un md1
sur le serveur consolidé, l'un des miroirs sera contraint de changer de nom.
/etc/mdadm/mdadm.conf
, dont un exemple est donné ci-dessous.
Exemple 12.1. Fichier de configuration de mdadm
# mdadm.conf # # Please refer to mdadm.conf(5) for information about this file. # # by default (built-in), scan all partitions (/proc/partitions) and all # containers for MD superblocks. alternatively, specify devices to scan, using # wildcards if desired. DEVICE /dev/sd* # auto-create devices with Debian standard permissions CREATE owner=root group=disk mode=0660 auto=yes # automatically tag new arrays as belonging to the local system HOMEHOST <system> # instruct the monitoring daemon where to send mail alerts MAILADDR root # definitions of existing MD arrays ARRAY /dev/md0 metadata=1.2 name=mirwiz:0 UUID=bb085b35:28e821bd:20d697c9:650152bb ARRAY /dev/md1 metadata=1.2 name=mirwiz:1 UUID=6ec558ca:0c2c04a0:19bca283:95f67464 # This configuration was auto-generated on Thu, 17 Jan 2013 16:21:01 +0100 # by mkconf 3.2.5-3
DEVICE
, qui spécifie l'ensemble des périphériques sur lesquels le système va chercher automatiquement des composants de volumes RAID au démarrage. Nous avons ici remplacé la valeur implicite, partitions containers
, par une liste explicite de fichiers de périphérique ; nous avons en effet choisi d'utiliser des disques entiers, et non simplement des partitions, pour certains volumes.
/dev/md*
correspondant).
#
mdadm --misc --detail --brief /dev/md?
ARRAY /dev/md0 metadata=1.2 name=mirwiz:0 UUID=bb085b35:28e821bd:20d697c9:650152bb ARRAY /dev/md1 metadata=1.2 name=mirwiz:1 UUID=6ec558ca:0c2c04a0:19bca283:95f67464
/dev/
, aucun risque donc de les utiliser directement.
sdb
, une partition sdb2
de 4 Go ;
sdc
, une partition sdc3
de 3 Go ;
sdd
, de 4 Go, est entièrement disponible ;
sdf
, une partition sdf1
de 4 Go et une sdf2
de 5 Go.
sdb
et sdf
ont de meilleures performances que les deux autres.
pvcreate
:
#
pvdisplay
#
pvcreate /dev/sdb2
Writing physical volume data to disk "/dev/sdb2" Physical volume "/dev/sdb2" successfully created #
pvdisplay
"/dev/sdb2" is a new physical volume of "4,00 GiB" --- NEW Physical volume --- PV Name /dev/sdb2 VG Name PV Size 4,00 GiB Allocatable NO PE Size 0 Total PE 0 Free PE 0 Allocated PE 0 PV UUID 0zuiQQ-j1Oe-P593-4tsN-9FGy-TY0d-Quz31I #
for i in sdc3 sdd sdf1 sdf2 ; do pvcreate /dev/$i ; done
Writing physical volume data to disk "/dev/sdc3" Physical volume "/dev/sdc3" successfully created Writing physical volume data to disk "/dev/sdd" Physical volume "/dev/sdd" successfully created Writing physical volume data to disk "/dev/sdf1" Physical volume "/dev/sdf1" successfully created Writing physical volume data to disk "/dev/sdf2" Physical volume "/dev/sdf2" successfully created #
pvdisplay -C
PV VG Fmt Attr PSize PFree /dev/sdb2 lvm2 a-- 4,00g 4,00g /dev/sdc3 lvm2 a-- 3,09g 3,09g /dev/sdd lvm2 a-- 4,00g 4,00g /dev/sdf1 lvm2 a-- 4,10g 4,10g /dev/sdf2 lvm2 a-- 5,22g 5,22g
pvdisplay
est capable de lister les PV déjà établis, sous deux formes.
vgcreate
. Nous allons placer dans le VG vg_critique
uniquement des PV appartenant à des disques rapides ; le deuxième VG, vg_normal
, contiendra des éléments physiques plus lents.
#
vgdisplay
No volume groups found#
vgcreate vg_critique /dev/sdb2 /dev/sdf1
Volume group "vg_critique" successfully created #
vgdisplay
--- Volume group --- VG Name vg_critique System ID Format lvm2 Metadata Areas 2 Metadata Sequence No 1 VG Access read/write VG Status resizable MAX LV 0 Cur LV 0 Open LV 0 Max PV 0 Cur PV 2 Act PV 2 VG Size 8,09 GiB PE Size 4,00 MiB Total PE 2071 Alloc PE / Size 0 / 0 Free PE / Size 2071 / 8,09 GiB VG UUID bpq7zO-PzPD-R7HW-V8eN-c10c-S32h-f6rKqp #
vgcreate vg_normal /dev/sdc3 /dev/sdd /dev/sdf2
Volume group "vg_normal" successfully created #
vgdisplay -C
VG #PV #LV #SN Attr VSize VFree vg_critique 2 0 0 wz--n- 8,09g 8,09g vg_normal 3 0 0 wz--n- 12,30g 12,30g
vgdisplay
présente deux formats de sortie). Notons que rien n'empêche de placer deux partitions d'un même disque physique dans deux VG différents ; le préfixe vg_
utilisé ici est une convention, mais n'est pas obligatoire.
lvcreate
, dont la syntaxe est un peu plus complexe :
#
lvdisplay
#
lvcreate -n lv_fichiers -L 5G vg_critique
Logical volume "lv_fichiers" created #
lvdisplay
--- Logical volume --- LV Path /dev/vg_critique/lv_fichiers LV Name lv_fichiers VG Name vg_critique LV UUID J3V0oE-cBYO-KyDe-5e0m-3f70-nv0S-kCWbpT LV Write Access read/write LV Creation host, time mirwiz, 2013-01-17 17:05:13 +0100 LV Status available # open 0 LV Size 5,00 GiB Current LE 1280 Segments 2 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:0 #
lvcreate -n lv_base -L 1G vg_critique
Logical volume "lv_base" created #
lvcreate -n lv_sauvegardes -L 12G vg_normal
Logical volume "lv_sauvegardes" created #
lvdisplay -C
LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert lv_base vg_critique -wi-a--- 1,00g lv_fichiers vg_critique -wi-a--- 5,00g lv_sauvegardes vg_normal -wi-a--- 12,00g
lvcreate
. Le nom du LV à créer est spécifié par l'option -n
et sa taille est en général spécifiée par -L
. Évidemment, il faut également expliciter à l'intérieur de quel groupe de volumes on souhaite créer le LV, d'où le dernier paramètre de la ligne de commande.
/dev/mapper/
:
#
ls -l /dev/mapper
total 0 crw------T 1 root root 10, 236 17 janv. 16:52 control lrwxrwxrwx 1 root root 7 17 janv. 17:05 vg_critique-lv_base -> ../dm-1 lrwxrwxrwx 1 root root 7 17 janv. 17:05 vg_critique-lv_fichiers -> ../dm-0 lrwxrwxrwx 1 root root 7 17 janv. 17:05 vg_normal-lv_sauvegardes -> ../dm-2 #
ls -l /dev/dm-*
brw-rw---T 1 root disk 253, 0 17 janv. 17:05 /dev/dm-0 brw-rw---T 1 root disk 253, 1 17 janv. 17:05 /dev/dm-1 brw-rw---T 1 root disk 253, 2 17 janv. 17:05 /dev/dm-2
#
ls -l /dev/vg_critique
total 0 lrwxrwxrwx 1 root root 7 17 janv. 17:05 lv_base -> ../dm-1 lrwxrwxrwx 1 root root 7 17 janv. 17:05 lv_fichiers -> ../dm-0 #
ls -l /dev/vg_normal
total 0 lrwxrwxrwx 1 root root 7 17 janv. 17:05 lv_sauvegardes -> ../dm-2
#
mkfs.ext4 /dev/vg_normal/lv_sauvegardes
mke2fs 1.42.5 (29-Jul-2012) Étiquette de système de fichiers= Type de système d'exploitation : Linux Taille de bloc=4096 (log=2) [...] Création du journal (32768 blocs) : complété Écriture des superblocs et de l'information de comptabilité du système de fichiers : complété #
mkdir /srv/sauvegardes
#
mount /dev/vg_normal/lv_sauvegardes /srv/sauvegardes
#
df -h /srv/sauvegardes
Sys. de fichiers Tail. Uti. Disp. Uti% Monté sur /dev/mapper/vg_normal-lv_sauvegardes 12G 158M 12G 2% /srv/sauvegardes #
[...]
[...] #
cat /etc/fstab
[...] /dev/vg_critique/lv_base /srv/base ext4 /dev/vg_critique/lv_fichiers /srv/fichiers ext4 /dev/vg_normal/lv_sauvegardes /srv/sauvegardes ext4
vg_critique
, nous pouvons étendre lv_fichiers
. Nous allons pour cela utiliser la commande lvresize
pour étendre le LV, puis resize2fs
pour ajuster le système de fichiers en conséquence :
#
df -h /srv/fichiers/
Sys. de fichiers Tail. Uti. Disp. Uti% Monté sur /dev/mapper/vg_critique-lv_fichiers 5,0G 4,6G 146M 97% /srv/fichiers #
lvdisplay -C vg_critique/lv_fichiers
LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert lv_fichiers vg_critique -wi-ao-- 5,00G #
vgdisplay -C vg_critique
VG #PV #LV #SN Attr VSize VFree vg_critique 2 2 0 wz--n- 8,14G 2,14G #
lvresize -L 7G vg_critique/lv_fichiers
Extending logical volume lv_fichiers to 7,00 GB Logical volume lv_fichiers successfully resized #
lvdisplay -C vg_critique/lv_fichiers
LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert lv_fichiers vg_critique -wi-ao-- 7,00G #
resize2fs /dev/vg_critique/lv_fichiers
resize2fs 1.42.5 (29-Jul-2012) Le système de fichiers de /dev/vg_critique/lv_fichiers est monté sur /srv/fichiers ; le changement de taille doit être effectué en ligne old_desc_blocks = 1, new_desc_blocks = 1 En train d'effectuer un changement de taille en ligne de /dev/vg_critique/lv_fichiers vers 1835008 (4k) blocs. Le système de fichiers /dev/vg_critique/lv_fichiers a maintenant une taille de 1835008 blocs. #
df -h /srv/fichiers/
Sys. de fich. Tail. Uti. Disp. Uti% Monté sur /dev/mapper/vg_critique-lv_fichiers 6,9G 4,6G 2,1G 70% /srv/fichiers
#
df -h /srv/base/
Sys. de fichiers Tail. Uti. Disp. Uti% Monté sur /dev/mapper/vg_critique-lv_base 1008M 854M 104M 90% /srv/base #
vgdisplay -C vg_critique
VG #PV #LV #SN Attr VSize VFree vg_critique 2 2 0 wz--n- 8,09g 92,00m
sdb1
, qui jusqu'à présent était utilisée en dehors de LVM, contenait uniquement des archives qui ont pu être déplacées dans lv_sauvegardes
. On peut donc l'intégrer au groupe de volumes pour récupérer l'espace disponible. Ceci passe par la commande vgextend
. Il faut bien entendu préparer la partition comme un volume physique au préalable. Une fois le VG étendu, on peut suivre le même cheminement que précédemment pour étendre le système de fichiers.
#
pvcreate /dev/sdb1
Writing physical volume data to disk "/dev/sdb1" Physical volume "/dev/sdb1" successfully created #
vgextend vg_critique /dev/sdb1
Volume group "vg_critique" successfully extended #
vgdisplay -C vg_critique
VG #PV #LV #SN Attr VSize VFree vg_critique 3 2 0 wz--n- 9,09G 1,09G #
[...]
[...] #
df -h /srv/base/
Sys. de fichiers Tail. Uti. Disp. Uti% Monté sur /dev/mapper/vg_critique-lv_base 2,0G 854M 1,1G 45% /srv/base
hda
et hdc
. Le schéma de partitionnement, identique sur les deux disques, sera le suivant :
#
fdisk -l /dev/hda
Disque /dev/hda: 300.0 Go, 300090728448 octets 255 têtes, 63 secteurs/piste, 36483 cylindres Unités = cylindres de 16065 * 512 = 8225280 octets Périphér. Amorce Début Fin Blocs Id Système /dev/hda1 * 1 124 995998+ fd Linux raid autodetect /dev/hda2 125 248 996030 82 Linux swap /dev/hda3 249 36483 291057637+ 5 Extended /dev/hda5 249 12697 99996561 fd Linux raid autodetect /dev/hda6 12698 25146 99996561 fd Linux raid autodetect /dev/hda7 25147 36483 91064421 8e Linux LVM
md0
. Ce miroir est utilisé directement pour stocker le système de fichiers racine.
hda2
et hdc2
sont utilisées comme partitions d'échange, pour fournir un total de 2 Go de mémoire d'échange. Avec 1 Go de mémoire vive, la station de travail dispose ainsi d'une quantité confortable de mémoire.
hda5
et hdc5
d'une part, hda6
et hdc6
d'autre part sont utilisées pour monter deux nouveaux volumes RAID-1 de 100 Go chacun, md1
et md2
. Ces deux miroirs sont initialisés comme des volumes physiques LVM et affectés au groupe de volumes vg_raid
. Ce groupe de volumes dispose ainsi d'environ 200 Go d'espace sécurisé.
hda7
et hdc7
, sont directement initialisées comme des volumes physiques et affectées à un autre VG, vg_vrac
, qui pourra contenir presque 200 Go de données.
vg_raid
seront préservés même en cas de panne d'un des deux disques, à l'opposé des LV pris sur vg_vrac
; en revanche, ces derniers seront alloués en parallèle sur les deux disques, ce qui permettra des débits élevés lors de la lecture ou de l'écriture de gros fichiers.
lv_usr
, lv_var
, lv_home
sur vg_raid
, pour y accueillir les systèmes de fichiers correspondants ; on y créera également un lv_films
, d'une taille conséquente, pour accueillir les films déjà montés. L'autre VG sera quant à lui utilisé pour un gros lv_rushes
, qui accueillera les données directement sorties des caméras numériques, et un lv_tmp
, pour les fichiers temporaires. Pour l'espace de travail, la question peut se poser : certes, il est important qu'il offre de bonnes performances, mais doit-on pour autant courir le risque de perdre le travail effectué si un disque défaille alors qu'un montage n'est pas fini ? C'est un choix à faire ; en fonction de ce choix, on créera le LV dans l'un ou l'autre VG.
/usr/
.