/dev/cciss/c0d0
; the kernel in Wheezy changed this name to the more natural /dev/sda
, but other RAID controllers may still behave differently.
mdadm
, che permette di creare e manipolare array RAID, oltre che script e strumenti per integrarlo al resto del sistema, compreso il sistema di monitoraggio.
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
command requires several parameters: the name of the volume to create (/dev/md*
, with MD standing for Multiple Device), the RAID level, the number of disks (which is compulsory despite being mostly meaningful only with RAID-1 and above), and the physical drives to use. Once the device is created, we can use it like we'd use a normal partition, create a filesystem on it, mount that filesystem, and so on. Note that our creation of a RAID-0 volume on md0
is nothing but coincidence, and the numbering of the array doesn't need to be correlated to the chosen amount of redundancy. It's also possible to create named RAID arrays, by giving mdadm
parameters such as /dev/md/linear
instead of /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
si accorge che gli elementi fisici hanno dimensioni diverse; poiché ciò implica che verrà perso dello spazio sull'elemento più grande, è richiesta una conferma.
/dev/md1
è usabile e vi si può creare sopra un file system, oltre a copiarvi sopra dei dati.
mdadm
, in particolare la sua opzione --fail
, permette di simulare uno guasto:
#
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
disk fail in turn, the data would be lost. We want to avoid that risk, so we'll replace the failed disk with a new one, 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
disk is about to be removed from the array, so as to end up with a classical RAID mirror on two disks:
#
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
disk failure had been real (instead of simulated) and the system had been restarted without removing this sde
disk, this disk could start working again due to having been probed during the reboot. The kernel would then have three physical elements, each claiming to contain half of the same RAID volume. Another source of confusion can come when RAID volumes from two servers are consolidated onto one server only. If these arrays were running normally before the disks were moved, the kernel would be able to detect and reassemble the pairs properly; but if the moved disks had been aggregated into an md1
on the old server, and the new server already has an md1
, one of the mirrors would be renamed.
/etc/mdadm/mdadm.conf
, un esempio del quale è mostrato qui:
Esempio 12.1. File di configurazione di 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
option, which lists the devices where the system will automatically look for components of RAID volumes at start-up time. In our example, we replaced the default value, partitions containers
, with an explicit list of device files, since we chose to use entire disks and not only partitions, for some volumes.
/dev/md*
).
#
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
, quindi non c'è rischio di usarli direttamente.
/dev
, and it can be used as any other physical partition can be (most commonly, to host a filesystem or swap space).
sdb
, una partizione sdb2
, 4 GB;
sdc
, una partizione sdc3
, 3 GB;
sdd
disk, 4 GB, is fully available;
sdf
, una partizione sdf1
, 4 GB e una partizione sdf2
, 5 GB.
sdb
e sdf
siano più veloci degli altri due.
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
elenca le PV esistenti, con due possibili formati di output.
vgcreate
. Solo le PV dei dischi più veloci saranno riunite in un VG vg_critical
; l'altro VG, vg_normal
, includerà anche gli elementi più lenti.
#
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
proposes two output formats). Note that it is quite possible to use two partitions of the same physical disk into two different VGs. Note also that we used a vg_
prefix to name our VGs, but it is nothing more than a convention.
lvcreate
e una sintassi leggermente più complessa:
#
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
. Il nome dei LV da creare viene specificato con l'opzione -n
e la sua dimensione viene generalmente data usando l'opzione -L
. Ovviamente bisogna anche dire al comando su quale VG operare, da cui l'ultimo parametro sulla riga di comando.
/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_critical
, si può espandere lv_files
. A questo scopo, si usa il comando lvresize
, quindi resize2fs
per adattare il file system di conseguenza:
#
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
, che finora era stata usata al di fuori di LVM, conteneva solo archivi che potrebbero essere spostati su lv_backups
. La si può quindi riciclare e integrare nel gruppo di volume, liberando così dello spazio utilizzabile. Questo è lo scopo del comando vgextend
. Ovviamente la partizione deve essere preparata in precedenza come volume fisico. Una volta che il VG è stato esteso, possiamo usare comandi simili ai precedenti per espandere il volume logico e poi il file system:
#
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
sda
e sdc
. Vengono partizionati in modo identico secondo il seguente schema:
#
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
. Questo mirror è usato direttamente per contenere il file system di root.
sda2
e sdc2
sono usate come partizioni di swap, dando un totale di 2 GB di spazio di swap. Con 1 GB di RAM, la postazione di lavoro ha una quantità sufficiente di memoria disponibile.
sda5
e sdc5
, così come sda6
e sdc6
, sono assemblate in due nuovi volumi RAID-1 di circa 100 GB l'uno, md1
e md2
. Entrambi questi mirror sono inizializzati come volumi fisici per LVM e assegnati al gruppo di volume vg_raid
. Questo VG contiene circa 200 GB di spazio sicuro.
sda7
e sdc7
, sono usate direttamente come volumi fisici e assegnate a un altro VG chiamato vg_bulk
, che quindi ha all'incirca 200 GB di spazio.
vg_raid
saranno preservati anche in caso di guasto di uno dei dischi, cosa che non succede per i LV creati in vg_bulk
; d'altro canto, quest'ultimo sarà allocato in parallelo su entrambi i dischi, il che consente velocità di lettura o scrittura maggiori per file grandi.
lv_usr
, lv_var
e lv_home
su vg_raid
, per ospitare i corrispondenti file system; un altro grande LV, lv_movies
, verrà usato per ospitare le versioni definitive dei filmati dopo l'elaborazione. L'altro VG verrà suddiviso in un grande lv_rushes
, per ospitare i dati che provengono direttamente dalle videocamere digitali e un lv_tmp
per i file temporanei. La posizione dell'area di lavoro è meno ovvia: pur essendo necessarie delle buone prestazioni per quel volume, vale la pena rischiare di perdere il lavoro se un disco si guasta durante una sessione di elaborazione? A seconda della risposta a quella domanda, il relativo LV sarà creato su uno dei due VG.
/usr/
può essere allargato senza fatica.