No more maintained.
Now just a test in a lab.
Gestione avanzata dei filesystem Linux
Utilizzo avanzato dei file system: RAID, LVM.
LVM commands and brief reference
Tipo Infobox: DESCRIPTION - Skill: 5- SENIOR
Common commands for using LVM and some references. Some are harmless some are harmful: know what you type.
LVM basics
LVM usage requires few different steps:
Creation of physical volumes (PV) (it just tags a device or partition to be used as PV):
pvcreate /dev/sda1 /dev/sdb2
Volume Group (VG) creation (it uses one or more PV to create a VG. Consider a VG as a virtual device that can grow with more PV at any time and has to be splitted in different partitions (Logical Volumes)). Here is named mygroup:
vgcreate mygroup /dev/sda1 /dev/sdb2
Creation of a Logical Volume (LV) named myvolume inside the previously created VG mygroup of 25 Gb (consider Logical Volumes as virtual partitions, that can be formatted and mounted as normal partitions and can be extended or reduced with LV commands) :
lvcreate -L 25G -n myvolume mygroup
Show LVM information
To show info about local Physical Volumes:
pvdisplay
pvscan
pvs
To show info about Volume Groups:
vgdisplay
vgscan
vgs
To show info about Logical Volumes
lvdisplay
lvscan
lvs
Growing and reducing
To add a PV to an existing Volume Group ("make the virtual disk bigger") use the command vgextend, here the new PV /dev/hdb1 is added to existing VG mygroup: vgextend mygroup /dev/hdb1
To extend a LV with no data:
lvextend -L +1G /dev/mygroup/myvolume
To extend a LV formatted in ext2 or ext3 and with data (first enlarge LV then enlarge FS) - Here myvolume is extended by 1 Gb:
umount /mnt
lvextend -L +1G /dev/mygroup/myvolume
resize2fs /dev/mygroup/myvolume mount /mnt
Alternatively instead of using resize2fs you can use ext2online for enlarging a mounted file systems. So the previous example becomes:
lvextend -L +1G /dev/mygroup/myvolume
ext2online /dev/mygroup/myvolume
To reduce a LV formatted in ext2 or ext3 and with data (first reduce FS then reduce LV) - Here myvolume has size set to 5 Gb:
umount /mnt
resize2fs /dev/mygroup/myvolume 5G
lvreduce -L 5G /dev/mygroup/myvolume
mount /mnt
Some internals
Cache file with filters for device names:
/etc/lvm/.cache
Directory of automatic backup of last VG metadata:
/etc/lvm/backup/
Directory ot automatic archive of VG metadata:
/etc/lvm/archive/
Show lvm configuration:
lvm dumpconfig
Scans local devices to look for Logical Volumes:
lvmdiskscan
To use a device ( ex: /dev/sda as PV instead of a partition (ex: /dev/sda1) remember to wipe out it's boot sector otherwise unexpected behaviours may occur:
dd if=/dev/zero of=/dev/sda bs=512 count=1
To use a device or a partition as PV it's suggested (not required) to tag it with the proper type. You can use fdisk and then tag the partition or device ID with type LVM (82):
fdisk /dev/sda - type t - enter 8e
Clustered Logical Volume Manager (CLVM)
CLVM is an extension to LVM2 for managing LV information in a cluster.
A clustered Volume Group should be used on storage used by different nodes of a RedHat Cluster.
In /etc/lvm/lvm.conf a clustered locking type must be defined:
locking_type = 3
locking_library = /lib/liblvm2clusterlock.so
or
locking_type = 2
Alternatively type:
lvmconf --enable-cluster
To create a clustered volume group (here share01, using PV /dev/sdc1):
vgcreate share01 -c y /dev/sdc1
rdev
Tipo Infobox: COMMANDS - Skill: 3- INTERMEDIATE
Visualizza o setta informazioni relative all'immagine di boot del kernel come root device, la dimensione dei RAM disk ed il video mode.
Alcune funzionalità di rdev possono richimate direttamente tramite alcuni link simbolici, di seguito è riportato la sintassi del comando rdev e dei relativi link sinbolici.
rdev [ -rvh ] [ -o offset ] [ image [ value [ offset ] ] ]
rdev [ -o offset ] [ image [ root_device [ offset ] ] ]
ramsize [ -o offset ] [ image [ size [ offset ] ] ]
vidmode [ -o offset ] [ image [ mode [ offset ] ] ]
rootflags [ -o offset ] [ image [ flags [ offset ] ] ]
-r Equivale a utilizzare ramsize
-R Equivale a utlizzare rootflags
-v Equivale a utilizzare vidmode
-h Visualizza un help
Esempi.
Visulizzazione del root device:
[root@nefertiti root]# rdev
/dev/sda2 /
Settaggio RAM disk, la dimensione è sempre espressa in kb:
[root@nefertiti root]# rdev -r /dev/fd0 627
RAM disk
Tipo Infobox: DESCRIPTION - Skill: 3- INTERMEDIATE
In molti sistemi operativi, compreso Linux, è possibile utilizzare una fetta della memoria volatile RAM come un filesystem, tale risultato viene definito RAM disk.
L'utilizzo dei RAM disk è tipicamente giustificato per incrementare le prestazioni di un sistema ove il limite fisico è dato dalla bassa velocità dell'accesso dati.
L'esempio più calzante potrebbe essere un Server Web con una connessione in fibra o con giga ethernet che non potrà mai utilizzare a pieno la banda disponibile poichè il proprio controller ide/scsi/raid sarà troppo lento per accedere ai dati sul proprio filesystem.
Occorre verificare se il kernel Linux abbia abilitato il supporto per i ramdisk, semplicemente verificando l'esistenza dei device /dev/ram(x)
Nel caso del kernel di default di RedHat è già attivato e non occorre la ricompilazione.
[root@nefertiti root]# ls -l /dev/ram*
lrwxrwxrwx 1 root root 4 Apr 2 2003 /dev/ram -> ram1
brw-rw---- 1 root disk 1, 0 Jan 30 2003 /dev/ram0
brw-rw---- 1 root disk 1, 1 Jan 30 2003 /dev/ram1
brw-rw---- 1 root disk 1, 10 Jan 30 2003 /dev/ram10
brw-rw---- 1 root disk 1, 11 Jan 30 2003 /dev/ram11
brw-rw---- 1 root disk 1, 12 Jan 30 2003 /dev/ram12
brw-rw---- 1 root disk 1, 13 Jan 30 2003 /dev/ram13
brw-rw---- 1 root disk 1, 14 Jan 30 2003 /dev/ram14
brw-rw---- 1 root disk 1, 15 Jan 30 2003 /dev/ram15
brw-rw---- 1 root disk 1, 16 Jan 30 2003 /dev/ram16
brw-rw---- 1 root disk 1, 17 Jan 30 2003 /dev/ram17
brw-rw---- 1 root disk 1, 18 Jan 30 2003 /dev/ram18
brw-rw---- 1 root disk 1, 19 Jan 30 2003 /dev/ram19
brw-rw---- 1 root disk 1, 2 Jan 30 2003 /dev/ram2
brw-rw---- 1 root disk 1, 3 Jan 30 2003 /dev/ram3
brw-rw---- 1 root disk 1, 4 Jan 30 2003 /dev/ram4
brw-rw---- 1 root disk 1, 5 Jan 30 2003 /dev/ram5
brw-rw---- 1 root disk 1, 6 Jan 30 2003 /dev/ram6
brw-rw---- 1 root disk 1, 7 Jan 30 2003 /dev/ram7
brw-rw---- 1 root disk 1, 8 Jan 30 2003 /dev/ram8
brw-rw---- 1 root disk 1, 9 Jan 30 2003 /dev/ram9
lrwxrwxrwx 1 root root 4 Apr 2 2003 /dev/ramdisk -> ram0
La dimensione di default è di ca 4Mb relativamente poco se si considera che i sistemi odierni superano senza difficoltà 1Gb di memoria RAM, questa dimensione è modificabile sia in run-time mode con il comando rdev o ramsize oppure tramite una configurazione permanente aggiungendo il seguente parametro al boot del kernel ramdisk_size=xxx ove xxx è la dimensione del ramdisk in Kb.
Esempio di configurazione del boot loader grub:
[root@nefertiti root]# cat /etc/grub.conf
[...]
kernel /vmlinuz-2.4.20-18.9 ro root=LABEL=/ ramdisk_size=500000
[...]
Come tutti i supporti occorre formattarlo per poterlo utilizzare come filesystem, esempio:
[root@nefertiti root]# mkfs.ext3 /dev/ram0
mke2fs 1.32 (09-Nov-2002)
warning: 287 blocks unused.
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
125416 inodes, 499713 blocks
25000 blocks (5.00%) reserved for the super user
First data block=1
61 block groups
8192 blocks per group, 8192 fragments per group
2056 inodes per group
Superblock backups stored on blocks:
8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409
Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 20 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
Per rendere disponibile il nuovo filesystem occorre montarlo, e spostare il contenuto che deve essere caricato in memoria all'interno del nuovo file system, esempio:
[root@nefertiti root]# mount /dev/ram0 /home/ramdisk
[root@nefertiti root]# df -k
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda2 15380592 9617788 4981508 66% /
/dev/sda1 100692 9501 85992 10% /boot
none 515456 0 515456 0% /dev/shm
/dev/ram0 483886 8239 450647 2% /home/ramdisk
[root@nefertiti root]# mv /usr/local/apache/htdocs /home/ramdisk/
[root@nefertiti root]#df -k
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda2 15380592 9613048 4986248 66% /
/dev/sda1 100692 9501 85992 10% /boot
none 515456 0 515456 0% /dev/shm
/dev/ram0 483886 12496 446390 3% /home/ramdisk
Anche se il filesystem è vuoto sono risorse allocate che il sistema non può utilizzare, quindi è bene calibrare il filesystem per le singole esigenze, inoltre essendo un filesystem basato su memoria volatile il suo contenuto va perso ad ogni riavvio.
Maggiori informazioni ed esempi di creazione di RAM disk si possono trovare nella documentazione all'interno dei sorgenti del kernel linux/Documentation/ramdisk.txt
Migrazione di un file system esistente verso LVM
Tipo Infobox: STDOUT - Skill: 4- ADVANCED
Il modo migliore per vedere come funziona LVM è metterlo in pratica, possibilmente su un computer di prova che può essere sacrificato per i nostri esperimenti.
Vediamo qui la procedura adottata per migrare su un sistema RedHat Linux 8 la directory /home da una normale partizione fisica ad una partizione basata su LVM.
Quanto riportato può essere utile, oltre che per avere un'idea dei pochi comandi necessari, per tutti i casi in cui non si è usato LVM durante l'installazione e si decide di implementarlo in tempi successivi.
[root@89 /]# cat /proc/partitions
Visualizziamo innanzitutto quali partizioni sono presenti sui dischi collegati al sistema. Si nota hda variamente partizionato e hdc e hdd senza partizioni
major minor #blocks name rio rmerge rsect ruse wio wmerge wsect wuse running use aveq
22 0 3528000 hdc 6 6 24 30 1 3 8 0 0 30 30
22 64 2481696 hdd 1 3 8 10 0 0 0 0 0 10 10
3 0 4224150 hda 14048 39349 183186 149870 4952 10187 82764 480080 0 119420 639100
3 1 104391 hda1 31 80 222 580 17 8 50 4460 0 3180 5040
3 2 2072385 hda2 6159 3376 75626 60190 1231 3020 34880 188820 0 69350 257130
3 3 522112 hda3 7193 32990 80366 46130 1525 5005 13210 220250 0 53150 267410
3 4 1 hda4 0 0 0 0 0 0 0 0 0 0 0
3 5 755023 hda5 23 97 306 290 11 5 104 2910 0 3200 3200
3 6 570276 hda6 629 2769 26530 42520 2168 2149 34520 63640 0 22540 106160
3 7 192748 hda7 9 25 104 100 0 0 0 0 0 100 100
[root@89 /]# mount
Di fatto tutto il sistema è montato su partizioni di hda
/dev/hda3 on / type ext3 (rw)
none on /proc type proc (rw)
/dev/hda1 on /boot type ext3 (rw)
none on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/hda5 on /home type ext3 (rw)
none on /dev/shm type tmpfs (rw)
/dev/hda2 on /usr type ext3 (rw)
/dev/hda6 on /var type ext3 (rw)
A questo punto decidiamo di creare dei fisical device usando hdc e hdd
[root@89 /]# pvcreate /dev/hdc
pvcreate -- physical volume "/dev/hdc" successfully created
[root@89 /]# pvcreate /dev/hdd
pvcreate -- physical volume "/dev/hdd" successfully created
[root@89 /]# pvscan
Il comando pvscan è utile per visualizzare lo stato dei PV
pvscan -- reading all physical volumes (this may take a while...)
pvscan -- inactive PV "/dev/hdc" is in no VG [3.36 GB]
pvscan -- inactive PV "/dev/hdd" is in no VG [2.37 GB]
pvscan -- total: 2 [5.73 GB] / in use: 0 [0] / in no VG: 2 [5.73 GB]
Possiamo creare un Volume Group, utilizzando i PV appena creati. Notare che avremmo potuto usare un unico comando (vgcreate /dev/hdc /dev/hdd) ma abbiamo preferito provare ad estendere il gruppo (chiamato "grumo") appena creato con il comando vgextend
[root@89 /]# vgcreate grumo /dev/hdc
vgcreate -- INFO: using default physical extent size 4 MB
vgcreate -- INFO: maximum logical volume size is 255.99 Gigabyte
vgcreate -- doing automatic backup of volume group "grumo"
vgcreate -- volume group "grumo" successfully created and activated
[root@89 /]# vgdisplay
Comando utile per visualizzare lo stato di un Volume Group, notare come cambia l'output dopo aver aggiunto il PD hdd
--- Volume group ---
VG Name grumo
VG Access read/write
VG Status available/resizable
VG # 0
MAX LV 256
Cur LV 0
Open LV 0
MAX LV Size 255.99 GB
Max PV 256
Cur PV 1
Act PV 1
VG Size 3.36 GB
PE Size 4 MB
Total PE 860
Alloc PE / Size 0 / 0
Free PE / Size 860 / 3.36 GB
VG UUID 49Urj3-lrwC-3S3k-pF7p-NZ71-1bGg-44QOeF
[root@89 /]# vgextend grumo /dev/hdd
vgextend -- INFO: maximum logical volume size is 255.99 Gigabyte
vgextend -- doing automatic backup of volume group "grumo"
vgextend -- volume group "grumo" successfully extended
[root@89 /]# vgdisplay
--- Volume group ---
VG Name grumo
VG Access read/write
VG Status available/resizable
VG # 0
MAX LV 256
Cur LV 0
Open LV 0
MAX LV Size 255.99 GB
Max PV 256
Cur PV 2
Act PV 2
VG Size 5.72 GB
PE Size 4 MB
Total PE 1464
Alloc PE / Size 0 / 0
Free PE / Size 1464 / 5.72 GB
VG UUID 49Urj3-lrwC-3S3k-pF7p-NZ71-1bGg-44QOeF
A questo punto possiamo creare un Logical Volume. Decidiamo di farlo grande 1 Gigabyte (-L 1G) e di chiamarlo "casa". Con il comando lvdisplay se ne visualizzano le informazioni di base.
Notare che con il comando lvcreate è obbligatorio speficicare il Volume Group in cui crearlo e la dimensione del Logcial Volume (tramite i flag -l o -L).
[root@89 /]# lvcreate -L 1G -n casa grumo
[root@89 /]# lvdisplay /dev/grumo/casa
--- Logical volume ---
LV Name /dev/grumo/casa
VG Name grumo
LV Write Access read/write
LV Status available
LV # 1
# open 0
LV Size 1 GB
Current LE 256
Allocated LE 256
Allocation next free
Read ahead sectors 1024
Block device 58:0
Il nostro Logical Volume /dev/grumo/casa è a tutti gli effetti un device a blocchi che possiamo formattare e montare su una directory del nostro filesystem
[root@89 /]# mkfs.ext3 /dev/grumo/casa
[...]
[root@89 /]# mkdir /mnt/casa
[root@89 /]# mount -t ext3 /dev/grumo/casa /mnt/casa/
[root@89 /]# mount
[...]
/dev/hda6 on /var type ext3 (rw)
/dev/grumo/casa on /mnt/casa type ext3 (rw)
Ne approfittiamo per vedere come appare il modulo LVM
[root@89 /]# lsmod
Module Size Used by Not tainted
loop 11224 0 (autoclean)
lvm-mod 61792 3
autofs 12228 0 (autoclean) (unused)
ne2k-pci 6752 1
8390 7884 0 [ne2k-pci]
ipt_REJECT 3448 6 (autoclean)
iptable_filter 2316 1 (autoclean)
ip_tables 14456 2 [ipt_REJECT iptable_filter]
ext3 64160 6
jbd 48180 6 [ext3]
A questo punto copiamo tutto il contenuto della /home attuale sul LV appena creato e montato temporaneamente su /mnt/casa
[root@89 /]# cp -Ra /home/* /mnt/casa/
Per montare stabilmente la nostra home sul LV dobbiamo modificare /etc/fstab
[root@89 /]# cat /etc/fstab
LABEL=/ / ext3 defaults 1 1
LABEL=/boot /boot ext3 defaults 1 2
none /dev/pts devpts gid=5,mode=620 0 0
LABEL=/home /home ext3 defaults 1 2
none /proc proc defaults 0 0
none /dev/shm tmpfs defaults 0 0
LABEL=/usr /usr ext3 defaults 1 2
LABEL=/var /var ext3 defaults 1 2
/dev/hda7 swap swap defaults 0 0
/dev/cdrom /mnt/cdrom iso9660 noauto,owner,kudzu,ro 0 0
/dev/fd0 /mnt/floppy auto noauto,owner,kudzu 0 0
In particolare modifichiamo il device da montare su /home:
/dev/grumo/casa /home ext3 defaults 1 2
A questo punto possiamo smontare la vecchia home, la directory temporanea /mnt/casa e rimontare home con il nuovo /etc/fstab modificato
[root@89 /]# umount /mnt/casa/
[root@89 /]# umount /home/
[root@89 /]# mount /home/
Tutto fin'ora è filato liscio, le operazione di creazione e gestione di LVM sono state piuttosto facili, la migrazione della home è stata rapida perchè coinvolgeva pochi file, in produzione, con maggiori quantità di dati da spostare, ci sarebbero stati sicuramente tempi e complicazioni maggiori (avremmo fatto una prima copia di tutti i file e poi una rapida sincronizzazione con rsync appena prima di smontare e rimontare il tutto. L'operazione sarebbe stata comunque resa più difficoltosa se ci fossero stati vari utenti locali a lavorare su /home e avrebbe potuto comportare un disservizio forzato di alcuni minuti)
Tutto a posto?
Non esattamente. Abbiamo eseguito il reboot del sistema (sempre consigliabile farlo subito, quando si fanno simili cambiamenti radicali, per essere sicuri che tutto si ripristini senza problemi) e inesorabilmente si è tutto bloccato lasciandoci in mantenance mode:
- Il kernel ha dato un messaggio di errore tipo "kmod: failed to exec /sbin/modprobe -s -k block-major-8, errno = 2
- Al momento di eseguito il mount dei file system, il sistema si è bloccato, non riuscendo a trovare il mount point per /home (di fatto non trovando il nostro Logical Volume /dev/grumo/casa)
L'HowTo e la logica ci hanno fatto capire che il problema stava nel mancato caricamento automatico del modulo LVM (non ci sarebbero stati problemi se avessimo avuto un kernel con il supporto LVM direttamente compilato nel core). Abbiamo provato inizialmente a modificare /etc/modules.conf aggiungendo la riga:
alias block-major 8 lvm-mod ma senza risultati.
Allora senza ulteriori indugi, e in modo non particolarmente elegante, ma comunque efficace, abbiamo aggiunto all'INIZIO di /etc/rc.d/rc.sysinit (il primo script che viene eseguito da init sui sistemi Redhat) il caricamente manuale del modulo:
/sbin/insmod lvm-mod
e il tutto ha finalmente funzionato.
Notare che se non ci fossimo presi la briga di provare subito un reboot, avremmo avuto maggiori problemi al prossimo avvio, senza magari ricordare gli interventi fatti o avere la possibilità di intervenire immediatamente.
Introduzione a Logical Volume Manager (LVM)
Tipo Infobox: DESCRIPTION - Skill: 3- INTERMEDIATE
Un Logical Volume Manager permette ad un sistema operativo di utilizzare dei dispositivi logici virtuali per l'accesso al disco che mascherano la natura dei dispositivi fisici (hard disk) su cui risiedono i dati.
In pratica è possibile utilizzare un device virtuale di cui possono fare parte diversi hard disk fisici, anche di natura, velocità e dimensioni diverse.
I vantaggi di un simile approccio alla gestione del file systems sono maggiore scalabilità, alta disponibilità del servizio, ridondanza e in alcuni casi migliori prestazioni.
L'implementazione LVM su Linux (dalla version 2.4 è presente nel thread ufficiale del kernel) è stata sviluppata dalla software house Sistina e mette a disposizioni features quali:
- Possibilità di modificare i volumi logici online, senza interruzione del servizio (utile, ad esempio, per ampliare una partizione virtuale);
- Gestione di molteplici gruppi di volumi logici;
- Funzionalità di mirroring, striping o concatening;
- Possibilità di eseguire snapshot in tempo reale senza smontare la partizione (fondamentale per operazioni di backup);
- Strumenti di gestione in command line semplici da usare;
- Supporto per software di High availability.
I vantaggi di usare un sistema LVM esistono sia su sistemi piccoli che grandi:
- su sistemi di piccole dimensioni (workstation o server con pochi hard disk) LVM permette di gestire più agilmente lo spazio su disco: ridimensionare una partizione fisica troppo piena di dati è problematico e pericoloso, mentre è semplice ed immediato cambiare le dimensioni di un volume logico.
- su sistemi di grandi dimensioni, con numerosi dischi fissi da gestire, è possibile ottimizzare meglio lo storage, modificarne le dimensioni o sostituire dischi guasti senza interrompere il servizio.
Le componenti basilari di LVM sono:
- Volume Group (VG) I gruppi di volume, sono il livello di astrazione più alta, contengono volumi fisici e logici.
- Physical Volume (PV) Di fatto sono i singoli hard disk o le loro partizioni, ogni HD o partizione è un PV (ma anche un /dev/md0 lo può essere, in quanto si presenta come device autonomo e singolo)
- Logical Volume (LV) Si presenta come un device a blocchi standard, è paragonabile ad una partizione di un hard disk ed è quello che viene referenziato come mount device per una data directory e che va formattato con il filesystem che si desidera.
- Physical Extent (PE) Ogni volume fisico viene diviso in blocchi di dati di dimensione fisse, chiamati "physical extent". Questi sono associati (1 a 1) con i:
- Logical Extent (LE) I blocchi di dati, della stessa dimensione, con cui è diviso un volume logico. Diversi volumi logici possono avere LE di dimensioni diverse, ma sempre uguali all'interno dello stesso volume.
In termini pratici, per mettere in piedi un sistema basato su LVM:
- Si creano dei volumi fisici, definendoli sulla base di hard disk o partizioni esistenti con il comando pvcreate
- Si crea un volume group, con due o più volumi fisici, con il comando vgcreate. Se in tempi successivi si devono aggiungere nuovi volumi fisici al gruppo si può usare il comando vgextend
- In un volume group esistente si possono creare i volumi logici veri e propri, con il comando lvcreate
- Il volume logico creato si presenta come un device a blocchi con nome tipo /dev/nome_vg/nome_lv, che può essere normalmente formattato con il filesystem che si desidera (ext2, ext3, reiserfs...) e montato nella directory che si desidera (/home, /var ...) come una normale partizione.
In un Volume Group possono esistere svariati Logical Volume che possono essere facilmente ridimensionati, rimossi, creati, rinominati. Facendo un paragone con un normale hard disk e la logica con cui viene usato su un sistema Unix, i LV è come se fossero delle partizioni "flessibili" di un disco fisso (il VG) a "capienza variabile", in quanto composto da un numero modificabile di dischi fisici.
La mappatura fra Psysical Extent e Logical Extend, le unità di storage minime, può essere impostata in due diversi modi:
- Linear. I LE di un LV vengono mappati sequenzialmente ai PE di uno o più PV. In pratica un volume logico composto da due volumi fisici, avrà, ad esempio, i LE da 1 a 100 che coincidono con i PE da 1 a 100 (sempre di uguali dimensioni) sul primo volume fisico e i LE da 101 a 200 che coincidono con i PE da 1 a 100 sul secondo volume fisico.
- Striped. Analogamente ad un Raid 1, i LE verranno mappati alternativamente su PE di diversi volumi fisici. In questo modo le performance potrebbero migliorare (in particolare se si usano volumi fisici su bus diversi) ma una volta impostati inizialmente, con questo metodo non è più possibile aggiungere volumi fisici ad un volume logico.
Molte distribuzioni presentano LVM come un modulo del kernel: lvm-mod (Per caricarlo, nel caso non avvenga automaticamente: modprobe lvm.mod) e provvedono all'avvio, nel caso in cui sia configurato un volume group, ad eseguire gli script di setup:
vgscan Esegue uno scan di tutti i dischi in cerca di volume groups e crea i database con le impostazioni di base per tutti gli altri comandi lvm: /etc/lvmtab e directroy /etc/lvmtab.d/
vgchange -ay Attiva i volume group conosciuti dal sistema.
Allo shutdown del sistema è opportuno dare il comando (già previsto nelle distribuzioni che supportano nativamente LVM):
vgchange -an Disattiva i volume group conosciuti dal sistema.
Per diagnosticare cosa succede è utile la directory /proc/lvm/ con i suoi contenuti che a loro volta forniscono dati simili a quelli che si possono ottenere con comandi come lvdisplay, vgdisplay e pvdisplay.
Raid performance su Linux
Tipo Infobox: TIPS - Skill: 2- JUNIOR
Questo testo si basa su ricerche in rete e conoscenza generale degli argomenti correlati, come molta documentazione, ormai, si basa su quanto detto o sentito da altri e non su benchmark o esaustive esperienze dirette.
Nonostante questo riteniamo utile fornire informazioni di massima su come scegliere e dimensionare un sistema raid (software) su Linux.
Definizione degli obiettivi
Come sempre, non esiste una soluzione definitiva ad una necessità informatica: dipende da cosa si vuole ottenere, dalle disponibilità di tempo, risorse e conoscenze, dal carico, dimensionamento e la natura dei sistemi su cui si intende configurare un software raid:
- Che funzioni avrà il nostro sistema?
A seconda delle sue funzioni cambiano parametri quali il tipo di accesso al disco, le dimensioni medie dei file, la quantità degli accessi, il carico generale di I/O e sulla CPU.
In genere un server web avrà frequente accesso a vari (alcuni più spesso di altri) piccoli file, con un carico di I/O relativamente basso e bassa occupazione di disco (quantomeno per i dati, log esclusi).
Un database gestirà file di grosse dimensioni, generalmente in posizioni fisse, con carichi di I/O maggiori.
Un file o print server avrà accessi frequenti a vari file di dimensioni variabili, con alti carici di I/O e grosse quantità di dati da avere in storage.
- Quali compromessi fra ridondanza dei dati e performance possiamo valutare?
La natura dei dati stessi e la necessità di mantenerne l'integrità e la disponibilità influisce sulla scelta di tipo di Raid. Il mirroring è la forma che garantisce probabilmente la migliore protezione dei dati, a scapito di un maggiore utilizzo di spazio su disco e di tempi di scrittura più lenti.
Scelta e disposizione degli hard disk
In termini di performance è fondamentale disporre gli hard disk che fanno parte di un raid array su bus diversi, in modo da ottimizzare il più possibile il throughput dei dati e riduerre i colli di bottiglia.
Su canali (E)IDE, in particolare, si riscontrano notevoli rallentamenti nell'accesso al disco se entrambi gli hard disk appartengono alla stesso canale. Se si fa mirroring, per esempio, è meglio abbinare un primary master (hda) o slave ad un secondary master (hdc) o slave (hdd), ed è assolutamente da evitare un sistema raid 1 composto, ad esempio, da primary master e un primary slave.
Su SCSI il problema è minore, ma se si hanno a disposizione due diversi canali, è meglio usarli alternati per sfruttare al meglio il thoughput del bus.
Benchmarking utility
Chi ha necessità di eseguire test di performance sui dischi ha a disposizione alcuni strumenti liberamente utilizzabili:
Iozone - http://www.iozone.org/
E' un tool che produce grafici diversi, in stile MS Office, sulla base dei risultati di una varietà di test di accesso al disco. Disponibile per vari sistemi operativi (tra cui Linux e Windows).
Bonnie ++ - http://www.coker.com.au/bonnie++/
E' una suite che comprende test di lettura e scrittura di dati su disco, simula diverse condizioni, riconducibile alle attività di server comuni. Serve per ogni tipo di tuning delle performance su disco e risulta particolarmente utile per valutare diverse soluzioni di raid.
Deriva da Bonnie, a suo tempo piuttosto usato e ancora valido.
Tiobench - http://tiobench.sourceforge.net/
Dedicata espressamente ad analisi di sistemi raid, produce statistiche interessanti e dettagliate.
PostMark -http://www.netapp.com/tech_library/3022.html
Tool di disk benchmarking della NetWork Appliance. Presenta una propria command line da cui è possibile configurare, impostare e visualizzare i risultati dei test.
Un elenco completo di tool per il benchmark del disco per diverse piattaforme è disponibile su http://www.acnc.com/benchmarks.html
Linear mode - Append
Modalità: I dati vengono scritti sul primo disco fino a quando non è completo, poi sul secondo ecc.
Dischi necessari: 2 o più
Prestazioni Lettura: Uguale a quella di un sistema senza raid. Può migliorare nei rari casi in cui si scrive contemporaneamente su diversi dischi fisici.
Prestazioni Scrittura:
Ridondanza: Nessuna
Recupero dati in caso di guasto: Difficile. Ma il fatto di avere i dati scritti sequenzialmente potrebbe permettere il recupero parziale dei dati scritti sul disco integro.
Chunk size generalmente consigliato: 32KB
Spare Disks: Non supportati.
Raid 0 - Stripe mode
Modalità: I dati vengono letti e scritti contemporaneamente, in parallelo, sui diversi dischi fisici.
Dischi necessari: 2 o più
Prestazioni Lettura: Decisamente migliori, se i BUS non rappresentano un collo di bottiglia, si avvicinano a N*P Mb/sec (Numero di HD * Prestazioni HD).
Prestazioni Scrittura: Desisamente migliori. Come per la lettura, tutte le operazioni di scrittura vengono svolte in parallelo sui diversi dischi fissi.
Ridondanza: Nessuna
Recupero dati in caso di guasto: Praticamente impossibile: ogni file fisicamente viene distribuito su dischi diversi: se un disco si rompe, ogni file risulta danneggiato.
Chunk size generalmente consigliato: 32KB
Spare Disks: Non supportati.
Raid 1 - Mirroring
Modalità: I dati vengono letti e scritti contempraneamente, in parallelo, sui diversi dischi fisici.
Dischi necessari: 2 o più, meglio se di uguale geometria.
Prestazioni Lettura: Migliorate. Vengono fatte in parallelo con meccanismi che minimizzano i tempi di seek di un file sul disco.
Prestazioni Scrittura: Peggiorate. Tutte le operazioni di scrittura vengono fatte due volte.
Ridondanza: Completa. Tutti i dati sono scritti due volte su due diversi dischi. Se esistono dischi spare questi vengono automaticamente ricreati. Se si ha a disposizione una copia del mirror, questa può essere usata autonomamente.
Chunk size generalmente consigliato: 32KB
Spare Disks: Uno o più.
Raid 4 -
Modalità: I dati vengono scritti, in modalità di striping su più dischi e viene mantenuto un disco autonomo per le info di parità.
Dischi necessari: 3 o più
Prestazioni Lettura: Migliorate.
Prestazioni Scrittura: Rallentate dalla necessità di gestire le parity info su disco autonomo.
Ridondanza: Se un disco si rompe, le informazioni di parità permettono la ricostruzione dei suoi dati.
Chunk size generalmente consigliato: 32KB
Spare Disks: Uno o più.
Raid 5 -
Modalità: Sia i dati che le informazioni di parità vengono scritti in modalità di striping su più dischi.
Dischi necessari: 3 o più
Prestazioni Lettura: Migliorate. Simili a Raid 0.
Prestazioni Scrittura: Paragonabili a quelle di Raid 1.
Ridondanza: Se un disco si rompe, le informazioni di parità permettono la ricostruzione dei suoi dati.
Chunk size generalmente consigliato: 128KB
Spare Disks: Uno o più.
/etc/raidtab
Tipo Infobox: PATH - Skill: 3- INTERMEDIATE
In questo file Linux mantiene tutte le informazioni relative ai metadevice (md) con cui gestisce il raid software.
Il fiel è diviso in sezioni, una per ogni md device, identificate dalla parola raiddev. L'ordine con cui sono inserite le sezioni e le relative opzioni è importante. Nel file sono specificate informazioni quali:
- Nome del metadevice (raiddev device)
- Livello di raid: linear, 0, 1, 4, 5 (raid-level )
- Numero dei dischi che fanno parte del md (nr-raid-disks #). Il limite attuale è di 12 dischi.
- Il numero di dischi da lasciare spare ed utilizzare in caso di guasto dei dischi di raid (nr-spare-disks #).
- La quantità minima di dati che può essere usata per le operazioni di I/O (dimensione delle stripe) in Kbytes (chunk-size #) Il valore può essere 2, 4, 8, 16, 32, 64 ... e di default può raggiungere un massimo di 4096. Valori tipici vanno da 4 a 128).
- I device da aggiungere al sistema raid. (device path). Questa opzione va sempre seguita da una che ne definisce l'utilizzo e l'ordine:
raid-disk 0|1|2|3... - Indica che il device definito nella riga precedente va inserito nella posizione indicata (a partire da 0, non è possibile avere due device nella stessa posizione) del raid array.
spare-disk 0|1|2|3... - Indica che il device definito nella riga precedente va inserito nella posizione indicata (a partire da 0, non è possibile avere due device nella stessa posizione) dell'array dei dischi spare (di riserva).
parity-disk 0|1|2|3 - Indica che il device definito nella riga precedente va dedicato alla parity check, dovrebbe avere come indice il numero più alto.
failed-disk 0|1|2|3 - Indica che il device definito nella riga precedente è guasto. Questo può servire anche pr inizializzare il raid su un sistema esistente. Inserire questa voce dopo le altre e quindi dopo aver definito l'array raid.
- La possibilità di inserire le informazioni relative al raid in un'area riservata di ogni device che ne fa parte. E' indispensabile se si vuole l'autodetection del raid da parte del kernel (persistent-superblock 0|1)
- L'algoritmo di parità da usare con Raid 5 (parity-algorithm left-symmetric|right-symmetric|left-asymmetric|right-asymmetric)
Vediamo un esempio di un improbabile (ma valido ed applicabile nelle parti che interessano) /etc/raidtab contenente vari tipi di device md con diversi livelli di Raid:
raiddev /dev/md0
Si definisce il primo device md, notare che il numero parte da 0
raid-level linear
Qui si usa la modalità linear, che in pratica accorpa in un unico device logico (md0) i due device fisici hda1 e hdb1, scrivendo sul primo fino a quando questo viene riempito e poi passando al secondo (in raid 0 i due device vengono usati in parallelo)
nr-raid-disks 2
Due saranno i device che faranno parte di md0, vengono sotto definiti
chunk-size 32
Tutte le operazione di accesso a md0 vengono fatte con sbostamenti di blocchi di dati di 32 Kb
persistent-superblock 1
Questo device md0, se il kernel è configurato per supportare l'automounter e le singole partizioni impostate con type automatico (0xFD su fdisk) , potrà essere utilizzato automaticamente e riconosciuto al boot
device /dev/hda1
raid-disk 0
Si definisce il primo device che fa parte di md0 e si indica il suo indice (a partire da 0)
device /dev/hdc2
raid-disk 1
Si definisce il secondo device, hdb2, con indice 1. Notare che se si volesse aggiungere un terzo device al raid array si dovrebbero scrivere le due righe di definizione (device e indice del raid-disk) e di dovrebbe cambiare a 3 il valore del'opzione nr-raid-disk qualche riga sopra)
raiddev /dev/md1
Si definisce un secondo device md, le opzioni che seguono riguardano questo device, quelle precedenti sono riferite soltanto al device md0)
raid-level 0
Su md1 si usa Raid 0 (i dati vengono scritti, senza ridondanza, in parallelo sui device che compongono il raid array. Le opzioni che seguono sono analoghe a quelle già viste, notare che:
- due device fisici non possono far parte di due diversi device virtuali md
- il chunk-size è riferito ad un dato md device e può cambiare su device diversi
- gli indici dei device fisici all'interno del device virtuale "ripartono" da zero e si riferiscono unicamente al loro md
nr-raid-disks 2
persistent-superblock 1
chunk-size 4
device /dev/hdb1
raid-disk 0
device /dev/hdc1
raid-disk 1
raiddev /dev/md2
raid-level 1
Terzo device in questo delirante /etc/fstab. Su questo viene fatto mirroring (raid 1) fra 2 dischi, lasciandone un terzo spare in caso di problemi di uno dei due. Ricordarsi sempre che per non degradare le prestazioni è meglio usare dischi su bus diversi, soprattutto se sono bus IDE (quindi uno sul primario e uno sul secondario)
nr-raid-disks 2
nr-spare-disks 1
Il numero di dischi spare, oltre ai due sopra inseiriti nel raid array. Vanno sotto definiti
chunk-size 4
persistent-superblock 1
device /dev/hda2
raid-disk 0
device /dev/hdd1
raid-disk 1
device /dev/hdb2
spare-disk 0
Qui si definisce lo spare disk sopra anticipato. Notare che il suo indice riparte da 0 in quanto indipendente dal raid-array
raiddev /dev/md3
raid-level 5
Il nostro quarto array è in Raid 5, utilizza ben 7 dischi (3 è il minimo) SCSI più uno spare. Notare che si tratta sempre di raid software, se il nostro controller SCSI supportasse raid hardware, andrebbe configurato direttamente, apparirebbe come device autonomo e non andrebbe tracce di configurazione in /etc/raidtab.
nr-raid-disks 7
nr-spare-disks 1
persistent-superblock 1
parity-algorithm left-symmetric
Con Raid 5 va specificato l'algoritmo di parità. Left-symmetric è generalmente il più performante ed utilizzato.
chunk-size 32
Il valore di 32 Kb è generalmente consigliato su Raid 5
device /dev/sda3
raid-disk 0
device /dev/sdb1
raid-disk 1
device /dev/sdc1
raid-disk 2
device /dev/sdd1
raid-disk 3
device /dev/sde1
raid-disk 4
device /dev/sdf1
raid-disk 5
device /dev/sdg1
raid-disk 6
device /dev/sdh1
spare-disk 0
Notare: Gli indici crescenti da 0 a 6 per i 7 raid disk e l'indice 0 per lo spare disk
A questo punto dovremmo averne abbastanza di metadevice raid, ma possiamo andare oltre, facendo l'esempio di una configurazione in raid 10 con 4 hard disk EIDE (soluzione invero abbastanza dissennata, visto che comunque prevede operazioni di I/O contemporanee su hard disk sullo stesso canale IDE).
Quanto segue, visto che i nomi dei device si ripetono, va preso come file autonomo dall'esempio di /etc/raidtab di cui sopra:
Primo device: Raid 1 (mirroring) fra due harddisk IDE su bus separati
raiddev /dev/md0
raid-level 1
nr-raid-disks 2
nr-spare-disks 0
chunk-size 4
persistent-superblock 1
device /dev/hda1
raid-disk 0
device /dev/hdc1
raid-disk 1
Secondo device: Raid 1 (mirroring) fra altri due harddisk IDE su bus separati
raiddev /dev/md1
raid-level 1
nr-raid-disks 2
nr-spare-disks 0
chunk-size 4
persistent-superblock 1
device /dev/hdb1
raid-disk 0
device /dev/hdd1
raid-disk 1
Terzo device: Un sistema Rad 10 si ottiene facendo striping (Raid 0) fra due md device in mirror mode (Raid 1)
raiddev /dev/md2
raid-level 0
nr-raid-disks 2
nr-spare-disks 0
chunk-size 4
persistent-superblock 1
device /dev/md0
raid-disk 0
device /dev/md1
raid-disk 1
Software Raid su Linux
Tipo Infobox: DESCRIPTION - Skill: 3- INTERMEDIATE
Il kernel di Linux garantisce sia la possibilità di fare raid software (su dischi IDE o SCSI) che il supporto di un gran numero di controller SCSI che permettono la gestione di raid hardware.
Il supporto RAID software del Kernel vale per Raid 0, Raid 1, Raid 4, Raid 5 e il semplice linear mode anche se varie distribuzioni come RedHat non utilizzano Raid 4 (per'altro poco usato in genere).
Nel kernel 2.4 e successivi è stato riscritto il codice e gli strumenti in userland (raidtools) per la gestione del Raid software. Tutto quello che viene riferito qui si riferisce alla nuova versione, per informazioni sulla vecchia implementazione, ancora usata su kernel 2.0 e 2.2 non patchati fare riferimento al relativo HowTo. I vecchi comandi come mdrun, mdadd, mdstop e ckraid non vengono più utilizzati.
La configurazione di RAID a livello software viene fatta tramite i metadevice /dev/md# (# è un numero progressivo, a partire da zero) che possono normalmente essere montati su delle directory del filesystem:
mount -t ext3 /dev/md0 /usr.
Il metadevice md viene trattato come un normale filesystem, che va formattato, montato e utilizzato in modo trasparente, a prescindere dai dispositivi fisici che questo utilizza.
Il file dove si configurano gli md è /etc/raidtab. Qui si definisce il nome dei metadevice virtuali che si vogliono utilizzare (/dev/md0, /dev/md1 ecc) e come questi sono composti: le partizioni fisiche che ne fanno parte (es: /dev/hda1, /dev/sda4), il tipo di Raid che va utilizzato (linear, 0, 1, 4, 5), la presenza di eventuali dischi spare di standy, che possono automaticamente essere utilizzati in caso di guasti sui dischi che fanno parte del metadevice, la dimensione delle unità "atomiche" di dati (chunk) per ogni operazione di I/O.
Possono far parte di un metadevice sia partizioni di dischi SCSI che partizioni di dischi IDE e, curiosamente, anche altri metadevice. In questo modo, per esempio, è possibile fare Raid 10 facendo un raid 1 di un device già in raid 0.
Per creare un metadevice con il livello di raid scelto su un sistema esistente con le seguenti procedure:
- Creazione di un file /etc/raidtab opportunamente e correttamente configurato
- Creazione del metadevice con il comando mkraid (Ad esempio mkraid /dev/md0 crea /dev/md0 sulla base di quanto definito in /etc/raidtab).
- Formattazione del nuovo device (mkfs.ext3 -b 4096 -R stride=8 /dev/md0) Notare che le partizioni fisiche facenti parte di md0 (specificate in /etc/raidtab) vengono cancellate, per cui non devono contenere dati utili. I parametri aggiuntivi forniti servono per specificare la dimensione dei blocchi (qui 4Kb) e il numero di blocchi per chunk (qui 8). Con questi parametri ci si aspetta un chunk-size 32 (Kb) nel file /etc/raidtab.
- Mount del device sul filesystem (es: mount -t ext3 /dev/mdo /opt)
- E' possibile verificare informazioni sul raid con cat /proc/mdstat. Consultando questo file è possibile visualizzare anche informazioni come lo stato di avanzamento di un rebuilding dei device e di fatto rimane la fonte di informazioni più diretta e chiara. Se il file manca, il proprio kernel non supporta Raid software.
RAID riferimenti teorici
Tipo Infobox: DESCRIPTION - Skill: 2- JUNIOR
In ambito server l'utilizzo dei RAID (Rendundant Array of Inexpensive Disk) è tipicamente utilizzato per avere una certa rindondanza dati e per migliorare le prestazioni di lettura e scrittura dati.
Il RAID può essere gestito tramite software oppure tramite hardware (tipicamente controller RAID SCSI), naturalmente la seconda soluzione risulta essere la migliore in termini di performance ma onerosa in termini economici.
Di seguito verranno presentati i livelli RAID più utilizzati con i relativi vantaggi e svantaggi:
RAID 0
Il disco simulato dal RAID viene suddiviso in fette (strip), sulle quali verranno scritte i dati in modo consecutivo e in modalità round-robin.
Nel caso di più hard-disk, il metodo con cui vengono distribuiti i dati viene chiamata striping.
Il Raid a livello zero è migliore (in termini di performance) nel caso in cui il passaggio dati in I/0 è elevato, poichè il controller RAID dividerà la richiesta di lettura o scrittura per tutti gli hard-disk e in seguito riassemblerà tutte le informazioni ricevute.
Le note negative si hanno quando si utilizza questo tipo di RAID con i OS che normalmente richiedono la lettura o scrittura di un settore alla volta, perdendo così il vantaggio della parallelizzazione, inoltre l'affidabilità di tale livello risulta essere molto bassa poichè basta la rottura di un solo disco per perdere tutti i dati.
Questo modello di Raid viene anche chiamato "striping without parity".
RAID 1
Raid 1 viene utilizzato proprio per la sua funzionalità di duplicazione, ovvero esso duplica tutti i dati (in caso di due hard-disk, ne avremo uno master e il secondo utilizzato per il backup).
In fase di scrittura, ogni dato (o meglio fetta) viene scritto due volte: una volta sull'hard-disk master e la seconda sull'hard-disk di backup, mentre in fase di lettura il dato può essere letto da entrambi, distribuendo anche il carico. In termini di performance si hanno vantaggi solo in lettura, mentre le operazione di scrittura, dovendo avvenire in duplice copia, sono più lente.
Questa configurazione garantisce la ridonzanda dei dati: se si rompe un hard disk, tutti i dati saranno comunque disponibili sull'altro. Viene anche definita "disk mirroring".
RAID 3
A differenza dei livelli precedenti, la suddivisione dei dati non avviene più per settore ma per byte, ovvero ogni byte viene suddiviso in bit ai quali ne viene aggiunto uno, come bit di parità, per ogni "parola" dati scritta. Poichè il byte dovrà essere scritto per i vari dischi disponibili viene richiesta la sincronizzazione del movimento fra i vari hard-disk.
Un solo bit di parità non permette la correzzione di errori nei dati ma può solo rilevarlo mentre in caso di crash di un hard-disk completo la correzzione dell'errore è completa poichè il bit di parità permette di svelare la posizione del bit corrotto.
Il numero di richieste che si possono gestire al secondo sono identiche a quelle di un singolo hard-disk.
RAID 4
Richiede tre o più dischi, come con il RAID 0, le operazioni in lettura e scrittura sono eseguite in parallelo, ma in questo caso un disco, che può diventare un collo di bottiglia, mantiene le informazioni di parità per ricostruire i dati in caso di guasto sugli altri dischi. RAID 4 viene considerato un "disk striping with parity".
RAID 5
Il vantaggio di questo livello di RAID sta nel fatto che la sincronizzazione dei vari componenti del RAID non è richiesta e la suddivisione dati fra questi componenti non avviene più per bit ma per fette (strip) come nel caso del RAID 1 con in aggiunta i bit di parità che vengono distribuiti su tutti gli hard-disk in modalità round-robin.
Questo garantisce ridondanza in caso di guasto di uno qualsiasi dei dischi, anche se la ricostruzione dei dati risulta essere un'operazione piuttosto complessa.
E' una delle varianti più utilizzate, insieme a RAID 1, perchè garantisce buone prestazione (parallelismo in lettura e scrittura), integrità dei dati (i parity check vengono distribuiti su tutti i dischi) e "spreco" relativamente limitato di spazio su disco per la ridondanza. Anche questo tipo è un "disk striping with parity".