/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
disk, 4 GB, is entirely available;
sdc
disk, 4 GB, is also entirely available;
sdd
disk, only partition sdd2
(about 4 GB) is available;
sde
disk, still 4 GB, entirely available.
#
mdadm --create /dev/md0 --level=0 --raid-devices=2 /dev/sdb /dev/sdc
mdadm: Defaulting to version 1.2 metadata mdadm: array /dev/md0 started. #
mdadm --query /dev/md0
/dev/md0: 8.00GiB 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) Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) Stride=128 blocks, Stripe width=256 blocks 524288 inodes, 2096896 blocks 104844 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=2147483648 64 block groups 32768 blocks per group, 32768 fragments per group 8192 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632 Allocating group tables: done Writing inode tables: done Creating journal (32768 blocks): done Writing superblocks and filesystem accounting information: done #
mkdir /srv/raid-0
#
mount /dev/md0 /srv/raid-0
#
df -h /srv/raid-0
Filesystem Size Used Avail Use% Mounted on /dev/md0 7.9G 146M 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:15:32 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
disk, a sdb2
partition, 4 GB;
sdc
disk, a sdc3
partition, 3 GB;
sdd
disk, 4 GB, is fully available;
sdf
disk, a sdf1
partition, 4 GB; and a sdf2
partition, 5 GB.
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_critical /dev/sdb2 /dev/sdf1
Volume group "vg_critical" successfully created #
vgdisplay
--- Volume group --- VG Name vg_critical 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_critical 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
command, and a slightly more complex syntax:
#
lvdisplay
#
lvcreate -n lv_files -L 5G vg_critical
Logical volume "lv_files" created #
lvdisplay
--- Logical volume --- LV Path /dev/vg_critical/lv_files LV Name lv_files VG Name vg_critical 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_critical
Logical volume "lv_base" created #
lvcreate -n lv_backups -L 12G vg_normal
Logical volume "lv_backups" created #
lvdisplay -C
LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert lv_base vg_critical -wi-a--- 1.00g lv_files vg_critical -wi-a--- 5.00g lv_backups 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 Jan 17 16:52 control lrwxrwxrwx 1 root root 7 Jan 17 17:05 vg_critical-lv_base -> ../dm-1 lrwxrwxrwx 1 root root 7 Jan 17 17:05 vg_critical-lv_files -> ../dm-0 lrwxrwxrwx 1 root root 7 Jan 17 17:05 vg_normal-lv_backups -> ../dm-2 #
ls -l /dev/dm-*
brw-rw---T 1 root disk 253, 0 Jan 17 17:05 /dev/dm-0 brw-rw---T 1 root disk 253, 1 Jan 17 17:05 /dev/dm-1 brw-rw---T 1 root disk 253, 2 Jan 17 17:05 /dev/dm-2
#
ls -l /dev/vg_critical
total 0 lrwxrwxrwx 1 root root 7 Jan 17 17:05 lv_base -> ../dm-1 lrwxrwxrwx 1 root root 7 Jan 17 17:05 lv_files -> ../dm-0 #
ls -l /dev/vg_normal
total 0 lrwxrwxrwx 1 root root 7 Jan 17 17:05 lv_backups -> ../dm-2
#
mkfs.ext4 /dev/vg_normal/lv_backups
mke2fs 1.42.5 (29-Jul-2012) Filesystem label= OS type: Linux Block size=4096 (log=2) [...] Creating journal (32768 blocks): done Writing superblocks and filesystem accounting information: done #
mkdir /srv/backups
#
mount /dev/vg_normal/lv_backups /srv/backups
#
df -h /srv/backups
Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_normal-lv_backups 12G 158M 12G 2% /srv/backups #
[...]
[...] #
cat /etc/fstab
[...] /dev/vg_critical/lv_base /srv/base ext4 /dev/vg_critical/lv_files /srv/files ext4 /dev/vg_normal/lv_backups /srv/backups 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/files/
Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_critical-lv_files 5.0G 4.6G 146M 97% /srv/files #
lvdisplay -C vg_critical/lv_files
LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert lv_files vg_critical -wi-ao-- 5.00g #
vgdisplay -C vg_critical
VG #PV #LV #SN Attr VSize VFree vg_critical 2 2 0 wz--n- 8.09g 2.09g #
lvresize -L 7G vg_critical/lv_files
Extending logical volume lv_files to 7.00 GB Logical volume lv_files successfully resized #
lvdisplay -C vg_critical/lv_files
LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert lv_files vg_critical -wi-ao-- 7.00g #
resize2fs /dev/vg_critical/lv_files
resize2fs 1.42.5 (29-Jul-2012) Filesystem at /dev/vg_critical/lv_files is mounted on /srv/files; on-line resizing required old_desc_blocks = 1, new_desc_blocks = 1 Performing an on-line resize of /dev/vg_critical/lv_files to 1835008 (4k) blocks. The filesystem on /dev/vg_critical/lv_files is now 1835008 blocks long. #
df -h /srv/files/
Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_critical-lv_files 6.9G 4.6G 2.1G 70% /srv/files
#
df -h /srv/base/
Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_critical-lv_base 1008M 854M 104M 90% /srv/base #
vgdisplay -C vg_critical
VG #PV #LV #SN Attr VSize VFree vg_critical 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_critical /dev/sdb1
Volume group "vg_critical" successfully extended #
vgdisplay -C vg_critical
VG #PV #LV #SN Attr VSize VFree vg_critical 3 2 0 wz--n- 9.09g 1.09g #
[...]
[...] #
df -h /srv/base/
Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_critical-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/sda
Disk /dev/hda: 300.0 GB, 300090728448 bytes 255 heads, 63 sectors/track, 36483 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00039a9f Device Boot Start End Blocks Id System /dev/sda1 * 1 124 995998+ fd Linux raid autodetect /dev/sda2 125 248 996030 82 Linux swap / Solaris /dev/sda3 249 36483 291057637+ 5 Extended /dev/sda5 249 12697 99996561 fd Linux raid autodetect /dev/sda6 12698 25146 99996561 fd Linux raid autodetect /dev/sda7 25147 36483 91064421 8e Linux LVM
md0
. This mirror is directly used to store the root filesystem.
sda2
and sdc2
partitions are used as swap partitions, providing a total 2 GB of swap space. With 1 GB of RAM, the workstation has a comfortable amount of available memory.
sda5
and sdc5
partitions, as well as sda6
and sdc6
, are assembled into two new RAID-1 volumes of about 100 GB each, md1
and md2
. Both these mirrors are initialized as physical volumes for LVM, and assigned to the vg_raid
volume group. This VG thus contains about 200 GB of safe space.
sda7
and sdc7
, are directly used as physical volumes, and assigned to another VG called vg_bulk
, which therefore ends up with roughly 200 GB of space.
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/
.