RAID i LVM són dues tècniques per abstraure els volums muntats dels dispositius físics (unitats de disc dur o particions); el primer assegura la seguretat i la disponibilitat de les dades en cas d'una fallada del maquinari mitjançant la introducció de redundància, mentre que el segon fa que la gestió del volum sigui més flexible i independent de la mida real dels discs subjacents. En tots dos casos, el sistema acaba amb nous dispositius de blocs, que es poden utilitzar per crear sistemes de fitxers o espai d'intercanvi, sense necessàriament tenir-los mapejats a un disc físic. RAID i LVM provenen d'orígens diferents, però la seva funcionalitat pot solapar-se una mica, i per això sovint s'esmenten junts.
En els casos de RAID i LVM, el nucli proporciona un fitxer de dispositiu de blocs, similar als que corresponen a un disc dur o una partició. Quan una aplicació, o una altra part del nucli, requereix accés a un bloc d'aquest dispositiu, el subsistema apropiat dirigeix el bloc a la capa física pertinent. Depenent de la configuració, aquest bloc es pot emmagatzemar en un o diversos discos físics, i la seva ubicació física pot no estar directament relacionada amb la ubicació del bloc en el dispositiu lògic.
12.1.1. RAID per software
RAID vol dir «Redundant Array of Independent Disks» o “conjunt redundant de discos independents”. L'objectiu d'aquest sistema és prevenir la pèrdua de dades i assegurar la disponibilitat en cas d'una fallada en un disc dur. El principi general és bastant simple: les dades s'emmagatzemen en diversos discs físics en lloc de només en un, amb un nivell de redundància configurable. Depenent d'aquesta quantitat de redundància, i fins i tot en cas d'una fallada inesperada del disc, les dades es poden reconstruir sense pèrdues a partir dels discos restants.
El RAID es pot implementar amb maquinari dedicat (mòduls RAID integrats en targetes de controlador SCSI o SATA) o amb abstracció de programari (el nucli). Ja sigui via maquinari o via programari, un sistema RAID amb prou redundància pot romandre operatiu quan un disc falla; les capes superiors de la pila (les aplicacions) poden fins i tot seguir accedint a les dades malgrat la fallada. Per descomptat, aquest “mode degradat” pot tenir un impacte en el rendiment, i la redundància es redueix, de manera que una altra fallada en el disc pot provocar la pèrdua de dades. A la pràctica, per tant, hom hauria d'esforçar-se per mantenir-se només en aquest mode degradat el que es trigui a substituir el disc espatllat. Un cop el nou disc és a lloc, el sistema RAID pot reconstruir les dades necessàries per tornar a un mode segur. Les aplicacions no notaran res, a part d'una potencial reducció de la velocitat d'accés, mentre el sistema està en mode degradat o durant la fase de reconstrucció.
Quan el RAID és implementat per maquinari, la seva configuració generalment es dóna dins de l'eina de configuració a la BIOS, i el nucli considerarà un conjunt RAID com un sol disc, que funcionarà com un disc físic estàndard, encara que el nom del dispositiu pot ser diferent (depenent del controlador).
Només ens centrarem en el RAID de programari en aquest llibre.
12.1.1.1. Diferents nivells de RAID
El RAID no és en realitat un sol sistema, sinó una sèrie de sistemes identificats pels seus nivells; els nivells difereixen pel seu disseny i la quantitat de redundància que proporcionen. Com més redundància, més a prova de fallades serà, ja que el sistema podrà continuar treballant amb més discs espatllats. La contrapartida és que, per a un conjunt donat de discos, l'espai utilitzable es redueix; vist a l'inrevés, es necessitaran més discos per emmagatzemar una quantitat donada de dades.
- RAID lineal
Tot i que el subsistema RAID del nucli permet crear un “RAID lineal”, això no és un RAID adequat, ja que aquesta configuració no implica cap redundància. El nucli simplement agrega diversos discs d'extrem a extrem i proporciona el volum agregat resultant com un disc virtual (un dispositiu de bloc). Aquesta és la seva única funció. Aquesta configuració és rarament utilitzada per si mateixa (vegeu més endavant les excepcions), especialment perquè la manca de redundància significa que un disc que falli fa que tot el conjunt, i per tant totes les dades, quedi fora de servei.
- RAID-0
Aquest nivell tampoc proporciona cap redundància, però els discs no estan simplement un darrere l'altre: estan dividits en tires, i els blocs del dispositiu virtual s'emmagatzemen en tires en discs físics alterns. En una configuració RAID-0 de dos discso, per exemple, els blocs parells del dispositiu virtual s'emmagatzemaran en el primer disc físic, mentre que els blocs senars acabaran en el segon disc físic.
Aquest sistema no té com a objectiu augmentar la fiabilitat, ja que (com en el cas lineal) la disponibilitat de totes les dades es posa en perill tan aviat com un disc falla, sinó en un rendiment millorat: durant l'accés seqüencial a grans quantitats de dades contigües, el nucli podrà llegir des dels dos discos (o escriure-hi) en paral·lel, la qual cosa augmenta la taxa de transferència de dades. Els discs són utilitzats íntegrament pel dispositiu RAID, de manera que haurien de tenir la mateixa mida per no perdre el rendiment.
L'ús de RAID-0 s'està reduint, i el seu nínxol és ocupat per LVM (vegeu més endavant).
- RAID-1
Aquest nivell, també conegut com a “RAID en mirall” (o «RAID mirroring») és tant la configuració més simple com la més utilitzada. En la seva forma estàndard, utilitza dos discos físics de la mateixa mida, i proporciona un volum lògic d'aquesta mateixa mida. Les dades s'emmagatzemen idènticament en ambdós discs, d'aquí el sobrenom de “mirall” (o «mirror» en anglès). Quan un disc falla, les dades encara estan disponibles a l'altre. Per a dades realment crítiques, el RAID-1 es pot configurar en més de dos discos, amb un impacte directe en la relació cost de maquinari enfront de l'espai de dades disponible.
Aquest nivell RAID, encara que car (com a màxim, només la meitat de l'espai d'emmagatzematge físic és usable), s'utilitza àmpliament a la pràctica. És fàcil d'entendre, i permet còpies de seguretat molt simples: ja que tots dos discs tenen continguts idèntics, un d'ells pot ser extret temporalment sense cap impacte en el sistema de treball. El rendiment de lectura sovint s'incrementa, ja que el nucli pot llegir la meitat de les dades de cada disc en paral·lel, mentre que el rendiment d'escriptura no es degrada massa. En cas d'una matriu RAID-1 de N discos, les dades es mantenen disponibles fins i tot amb la fallada d'N-1 discos.
- RAID-4
Aquest nivell RAID, no gaire utilitzat, utilitza N discos per emmagatzemar dades útils, i un disc extra per emmagatzemar informació de redundància. Si aquest disc falla, el sistema pot reconstruir el seu contingut a partir dels altres N. Si un dels N discos de dades falla, els N-1 restants combinats amb el disc de “paritat” conté prou informació per reconstruir les dades necessàries.
RAID-4 no és massa costós, ja que només implica un augment d'un sobre N en els costos i no té cap impacte notable en el rendiment de lectura, però les escriptures s'alenteixen. A més, ja que una escriptura a qualsevol dels N discs també implica una escriptura al disc de paritat, aquest últim veu moltes més escriptures que l'anterior, i la seva vida útil pot escurçar-se dramàticament com a conseqüència. Les dades d'un conjunt RAID-4 són segures només fins a un sol disc espatllat (dels N+1).
- RAID-5
RAID-5 resol el problema de l'asimetria de RAID-4: els blocs de paritat s'escampen en tots els N+1 discos, sense que cap disc tingui un paper particular.
El rendiment de lectura i escriptura és idèntic a RAID-4. Aquí de nou, el sistema roman funcional amb fins a un sol disc espatllat (dels N+1), però no més.
- RAID-6
RAID-6 es pot considerar una extensió de RAID-5, on cada sèrie d'N blocs implica dos blocs de redundància, i cada sèrie d'N+2 blocs es distribueix per N+2 discos.
Aquest nivell RAID és lleugerament més car que els dos anteriors, però aporta una mica de seguretat addicional, ja que fins a dues unitats (de les N+2) poden fallar sense comprometre la disponibilitat de dades. La contrapartida és que les operacions d'escriptura ara impliquen escriure un bloc de dades i dos blocs de redundància, la qual cosa els fa encara més lents.
- RAID-1+0
Això no és, estrictament parlant, un nivell RAID, sinó una combinació de dos grups RAID. A partir de 2xN discos, hom primer els estableix per parells en N volums RAID-1; aquests N volums s'agregaran en un, ja sigui amb RAID lineal o (cada cop més) amb LVM. Aquest últim cas va més enllà del RAID estricte, però no hi ha cap problema amb això.
RAID-1+0 pot sobreviure a múltiples fallades de disc: fins a N en la matriu 2xN descrita anteriorment, sempre que almenys un disc continuï funcional en cadascun dels parells RAID-1.
Òbviament, el nivell RAID es triarà d'acord amb les restriccions i requisits de cada aplicació. Tingueu en compte que un sol ordinador pot tenir diversos conjunts RAID amb diferents configuracions.
12.1.1.2. Configuració del RAID
La configuració de volums RAID requereix el paquet mdadm; aquest proporciona la comanda mdadm, que permet crear i manipular conjunts RAID, així com scripts i eines que els integren a la resta del sistema, inclòs el sistema de monitorització.
El nostre exemple serà un servidor amb una sèrie de discos, alguns dels quals ja s'utilitzen, i la resta estarà disponible per configurar el RAID. Inicialment tenim els següents discos i particions:
el disc sdb, de 4 GB, està tot disponible;
el disc sdc, de 4 GB, està també disponible completament;
al disc sdd només hi ha disponible la partició sdd2 (al voltant de 4 GB);
finalment, un disc sde, també de 4 GB, completament disponible.
Farem servir aquests elements físics per construir dos volums, un RAID-0 i un mirall (RAID-1). Comencem amb el volum RAID-0:
# 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: 7.99GiB raid0 2 devices, 0 spares. Use mdadm --detail for more detail.
# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Mon Feb 28 01:54:24 2022
Raid Level : raid0
Array Size : 8378368 (7.99 GiB 8.58 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent
Update Time : Mon Feb 28 01:54:24 2022
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Layout : -unknown-
Chunk Size : 512K
Consistency Policy : none
Name : debian:0 (local to host debian)
UUID : a75ac628:b384c441:157137ac:c04cd98c
Events : 0
Number Major Minor RaidDevice State
0 8 0 0 active sync /dev/sdb
1 8 16 1 active sync /dev/sdc
# mkfs.ext4 /dev/md0
mke2fs 1.46.2 (28-Feb-2021)
Discarding device blocks: done
Creating filesystem with 2094592 4k blocks and 524288 inodes
Filesystem UUID: ef077204-c477-4430-bf01-52288237bea0
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632
Allocating group tables: done
Writing inode tables: done
Creating journal (16384 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.8G 24K 7.4G 1% /srv/raid-0
La comanda mdadm --create requereix diversos paràmetres: el nom del volum a crear (/dev/md*, amb MD representant «Multiple Device» o “dispositiu múltiple”), el nivell RAID, el nombre de discos (que és obligatori tot i ser sobretot significatiu només amb RAID-1 i superiors), i les unitats físiques a utilitzar. Una vegada creat el dispositiu, es pot utilitzar com es fa servir una partició normal, crear-hi un sistema de fitxers, muntar aquest sistema de fitxers, etc. Tingueu en compte que la creació d'un volum RAID-0 a md0 no és més que una coincidència, i la numeració de conjunt no necessita estar correlacionada amb la quantitat de redundància triada. També és possible crear conjunts RAID amb nom, proporcionant a mdadm paràmetres com ara /dev/md/linear en lloc de /dev/md0.
La creació d'un RAID-1 segueix un estil similar, les diferències només es poden observar després de la creació:
# 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 : Tue Jun 25 10:21:22 2019
Raid Level : raid1
Array Size : 4189184 (4.00 GiB 4.29 GB)
Used Dev Size : 4189184 (4.00 GiB 4.29 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent
Update Time : Tue Jun 25 10:22:03 2019
State : clean, resyncing
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Consistency Policy : resync
Resync Status : 93% complete
Name : mirwiz:1 (local to host debian)
UUID : 7d123734:9677b7d6:72194f7d:9050771c
Events : 16
Number Major Minor RaidDevice State
0 8 64 0 active sync /dev/sdd2
1 8 80 1 active sync /dev/sde
# mdadm --detail /dev/md1
/dev/md1:
[...]
State : clean
[...]
Hi ha algunes observacions a fer. En primer lloc, mdadm observa que els elements físics tenen mides diferents; ja que això implica que algun espai es perdrà en l'element més gran, es requereix una confirmació.
I cosa que és més important, noteu l'estat del mirall. L'estat normal d'un mirall RAID és que ambdós discos tinguin exactament el mateix contingut. No obstant això, res garanteix que sigui així quan es crea el volum per primera vegada. El subsistema RAID, per tant, proporcionarà aquesta garantia per si mateix i hi haurà una fase de sincronització tan aviat com es creï el dispositiu RAID. Després d'un cert temps (la quantitat exacta dependrà de la mida real dels discos...), la matriu RAID canviarà a l'estat «active» (actiu) o «clean» (net). Tingueu en compte que durant aquesta fase de reconstrucció el mirall està en mode degradat, i la redundància no està assegurat. Un disc que falli durant aquesta finestra de risc podria provocar la pèrdua de totes les dades. Grans quantitats de dades crítiques, però, rarament s'emmagatzemen en una matriu RAID creada just abans de la seva sincronització inicial. Tingueu en compte que fins i tot en mode degradat /dev/md1 és utilitzable, s'hi pot crear un sistema de fitxers, i així com també copiar-hi dades.
Ara vegem què passa quan un dels elements del conjunt RAID-1 falla. mdadm, en particular la seva opció --fail, permet simular un error de disc d'aquest tipus:
# mdadm /dev/md1 --fail /dev/sde
mdadm: set /dev/sde faulty in /dev/md1
# mdadm --detail /dev/md1
/dev/md1:
Version : 1.2
Creation Time : Mon Feb 28 02:07:48 2022
Raid Level : raid1
Array Size : 4189184 (4.00 GiB 4.29 GB)
Used Dev Size : 4189184 (4.00 GiB 4.29 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent
Update Time : Mon Feb 28 02:15:34 2022
State : clean, degraded
Active Devices : 1
Working Devices : 1
Failed Devices : 1
Spare Devices : 0
Consistency Policy : resync
Name : debian:1 (local to host debian)
UUID : 2dfb7fd5:e09e0527:0b5a905a:8334adb8
Events : 19
Number Major Minor RaidDevice State
0 8 34 0 active sync /dev/sdd2
- 0 0 1 removed
1 8 48 - faulty /dev/sde
El contingut del volum encara és accessible (i, si està muntat, les aplicacions no se n'adonen de res), però la seguretat de les dades ja no està assegurada: si el disc sdd falla, les dades es perdrien. Volem evitar aquest risc, així que substituirem el disc espatllat per un nou, sdf:
# mdadm /dev/md1 --add /dev/sdf
mdadm: added /dev/sdf
# mdadm --detail /dev/md1
/dev/md1:
Version : 1.2
Creation Time : Mon Feb 28 02:07:48 2022
Raid Level : raid1
Array Size : 4189184 (4.00 GiB 4.29 GB)
Used Dev Size : 4189184 (4.00 GiB 4.29 GB)
Raid Devices : 2
Total Devices : 3
Persistence : Superblock is persistent
Update Time : Mon Feb 28 02:25:34 2022
State : clean, degraded, recovering
Active Devices : 1
Working Devices : 2
Failed Devices : 1
Spare Devices : 1
Consistency Policy : resync
Rebuild Status : 47% complete
Name : debian:1 (local to host debian)
UUID : 2dfb7fd5:e09e0527:0b5a905a:8334adb8
Events : 39
Number Major Minor RaidDevice State
0 8 34 0 active sync /dev/sdd2
2 8 64 1 spare rebuilding /dev/sdf
1 8 48 - faulty /dev/sde
# [...]
[...]
# mdadm --detail /dev/md1
/dev/md1:
Version : 1.2
Creation Time : Mon Feb 28 02:07:48 2022
Raid Level : raid1
Array Size : 4189184 (4.00 GiB 4.29 GB)
Used Dev Size : 4189184 (4.00 GiB 4.29 GB)
Raid Devices : 2
Total Devices : 3
Persistence : Superblock is persistent
Update Time : Mon Feb 28 02:25:34 2022
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 1
Spare Devices : 0
Consistency Policy : resync
Name : debian:1 (local to host debian)
UUID : 2dfb7fd5:e09e0527:0b5a905a:8334adb8
Events : 41
Number Major Minor RaidDevice State
0 8 34 0 active sync /dev/sdd2
2 8 64 1 active sync /dev/sdf
1 8 48 - faulty /dev/sde
Aquí de nou, el nucli desencadena automàticament una fase de reconstrucció durant la qual el volum, encara que encara és accessible, es troba en mode degradat. Una vegada que la reconstrucció ha acabat, el conjunt RAID torna a un estat normal. Llavors es pot dir al sistema que el disc sde està a punt de ser eliminat del conjunt, per tal d'acabar amb un mirall RAID clàssic en dos discos:
# 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 34 0 active sync /dev/sdd2
2 8 64 1 active sync /dev/sdf
A partir d'aleshores, la unitat es pot retirar físicament quan el servidor s'apagui, o fins i tot es pot retirar en calent si la configuració del maquinari permet la desconnexió en calent. Aquestes configuracions inclouen alguns controladors SCSI, la majoria de discos SATA i unitats externes que operen amb USB o Firewire.
12.1.1.3. Fent còpies de seguretat de la configuració
La majoria de les metadades relatives als volums RAID es guarden directament en els discos que componen aquestes volums, de manera que el nucli pot detectar els volums i els seus components i muntar-los automàticament quan el sistema s'inicia. No obstant això, es recomana la còpia de seguretat d'aquesta configuració, perquè aquesta detecció no és a prova de fallades, i només s'espera que falli precisament en circumstàncies sensibles. En el nostre exemple, si la fallada del disc sde hagués estat real (en lloc de simulada) i el sistema s'hagués reiniciat sense eliminar aquest disc sde, aquest disc podria començar a funcionar de nou a causa d'haver estat detectat durant el reinici. El nucli tindria llavors tres elements físics, cadascun reclamant contenir la meitat del mateix volum RAID. En realitat, això porta al RAID a engegar alternativament dels discos individualment - distribuint també les dades alternativament, depenent de quin disc inicia el RAID en mode degradat. Una altra font de confusió pot arribar quan els volums RAID de dos servidors es consoliden en un sol servidor. Si aquests volums s'executessin normalment abans que els discos es moguessin, el nucli podria detectar i tornar a muntar les parelles correctament; però si els discs moguts s'haguessin agregat en un md1 en el servidor antic, i el nou servidor ja té un md1, un dels miralls seria reanomenat.
Per tant, és important fer una còpia de seguretat de la configuració, encara que només sigui com a referència. La forma estàndard de fer-ho és editant el fitxer /etc/mdadm/mdadm.conf, un exemple del qual es mostra aquí:
Exemple 12.1. Fitxer de configuració de mdadm
# mdadm.conf
#
# !NB! Run update-initramfs -u after updating this file.
# !NB! This will ensure that initramfs has an uptodate copy.
#
# 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*
# 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/md/0 metadata=1.2 UUID=a75ac628:b384c441:157137ac:c04cd98c name=debian:0
ARRAY /dev/md/1 metadata=1.2 UUID=2dfb7fd5:e09e0527:0b5a905a:8334adb8 name=debian:1
# This configuration was auto-generated on Mon, 28 Feb 2022 01:53:48 +0100 by mkconf
Un dels detalls més útils és l'opció DEVICE, que llista els dispositius on el sistema buscarà automàticament els components dels volums RAID en el moment d'inici. En el nostre exemple, substituïm el valor per defecte, partitions containers, amb una llista explícita de fitxers de dispositius, ja que es va optar per utilitzar discos sencers i no només particions, per a alguns volums.
Les dues últimes línies en el nostre exemple són aquelles que permeten al nucli triar amb seguretat quin número de volum assignar a quina matriu. Les metadades emmagatzemades en els discos són suficients per tornar a muntar els volums, però no per determinar el número de volum (i el corresponent nom de dispositiu /dev/md*).
Afortunadament, aquestes línies es poden generar automàticament:
# mdadm --misc --detail --brief /dev/md?
ARRAY /dev/md/0 metadata=1.2 UUID=a75ac628:b384c441:157137ac:c04cd98c name=debian:0
ARRAY /dev/md/1 metadata=1.2 UUID=2dfb7fd5:e09e0527:0b5a905a:8334adb8 name=debian:1
El contingut d'aquestes dues últimes línies no depèn de la llista de discs inclosos al volum. Per tant, no és necessari regenerar aquestes línies quan se substitueix un disc fallit per un de nou. D'altra banda, s'ha de tenir cura d'actualitzar l'arxiu quan es crea o se suprimeix un conjunt RAID.
LVM, el «Logical Volume Manager» o “Gestor de volums lògics”, és un altre enfocament de l'abstracció de volums lògics respecte dels seus suports físics, que se centra en augmentar la flexibilitat en lloc d'augmentar la fiabilitat. LVM permet canviar un volum lògic de manera transparent pel que fa a les aplicacions; per exemple, és possible afegir nous discs, migrar-hi les dades, i eliminar els discos antics, sense desmuntar el volum.
12.1.2.1. Conceptes d'LVM
Aquesta flexibilitat s'aconsegueix mitjançant un nivell d'abstracció que implica tres conceptes.
En primer lloc, el PV («Physical Volum» o “Volum físic”) és l'entitat més propera al maquinari: poden ser particions en un disc, o un disc complet, o fins i tot qualsevol altre dispositiu de blocs (incloent, per exemple, un volum RAID). Cal tenir en compte que quan un element físic està configurat per ser un PV d'LVM, només s'hi ha d'accedir a través de LVM, en cas contrari el sistema es confondrà.
Un nombre de PVs es poden agrupar en un VG («Volum Group» o “Grup de volums”), que es pot comparar amb discs virtuals i extensibles. Els VG són abstractes, i no apareixen en un fitxer de dispositiu en la jerarquia de /dev, així que no hi ha risc d'usar-los directament.
El tercer tipus d'objecte és l'LV («Logical Volume» o “volum lògic”), que és un tros d'un VG; si mantenim l'analogia de “VG-com-a-disc”, l'LV es compara amb una partició. L'LV apareix com un dispositiu de blocs amb una entrada a /dev, i es pot utilitzar com qualsevol altra partició física (habitualment per albergar un sistema de fitxers o espai d'intercanvi).
L'important és que la divisió d'un VG en LVs és totalment independent dels seus components físics (els PV). Un VG amb un únic component físic (un disc per exemple) es pot dividir en una dotzena de volums lògics; de manera similar, un VG pot utilitzar diversos discos físics i aparèixer com un únic i gran volum lògic. L'única restricció, òbviament, és que la grandària total assignada als LV no pot ser més gran que la capacitat total dels PV del grup de volums.
No obstant això, sovint té sentit tenir algun tipus d'homogeneïtat entre els components físics d'un VG, i dividir el VG en volums lògics que tindran patrons d'ús similars. Per exemple, si el maquinari disponible inclou discos ràpids i discos més lents, els ràpids es podrien agrupar en un VG i els més lents en un altre; els trossos del primer es poden assignar a aplicacions que requereixin accés ràpid de dades, mentre que el segon es mantindria per a tasques menys exigents.
En qualsevol cas, tingueu en compte que un LV no està particularment vinculat a cap PV. És possible influir on les dades d'un LV s'emmagatzemen físicament, però aquesta possibilitat no és necessària per a l'ús diari. Al contrari: quan el conjunt de components físics d'un VG evoluciona, les localitzacions d'emmagatzematge físic corresponents a un LV particular es poden migrar entre discos (sempre romanent dins dels PV assignats al VG, per descomptat).
12.1.2.2. Configuració d'LVM
Seguim ara, pas a pas, el procés de creació d'un LVM per a un cas típic d'ús: volem simplificar una complexa situació d'emmagatzematge. Aquesta situació sol produir-se després d'una llarga i complicada història de mesures temporals acumulades. A tall il·lustratiu, considerarem un servidor on les necessitats d'emmagatzematge han canviat amb el temps, acabant en un laberint de particions disponibles dividides en diversos discs parcialment utilitzats. En termes més concrets, estan disponibles les següents particions:
al disc sdb, una partición sdb2 de 4Gb;
al disco sdc, una partició sdc3 de 3 GB;
el disc sdd, de 4 GB, completament disponible;
al disc sdf, una partición sdf1 de 4 GB i una partició sdf2 de 5GB.
A més, suposem que els discos sdb i sdf són més ràpids que els altres dos.
El nostre objectiu és establir tres volums lògics per a tres aplicacions diferents: un servidor d'arxius que requereix 5 GB d'espai d'emmagatzematge, una base de dades (1 GB) i una mica d'espai per a còpies de seguretat (12 GB). Les dues primeres necessiten un bon rendiment, però les còpies de seguretat són menys crítiques en termes de velocitat d'accés. Totes aquestes restriccions eviten l'ús de particions per si soles; l'ús de LVM pot absteure la mida física dels dispositius, de manera que l'únic límit és l'espai total disponible.
Les eines necessàries són en el paquet lvm2 i les seves dependències. Quan estan instal·lats, la instal·lació de l'LVM consisteix en tres passos, corresponents als tres nivells dels conceptes.
Primer, preparem els volums físics utilitzant pvcreate:
# pvcreate /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 yK0K6K-clbc-wt6e-qk9o-aUh9-oQqC-k1T71B
# for i in sdc3 sdd sdf1 sdf2 ; do pvcreate /dev/$i ; done
Physical volume "/dev/sdc3" successfully created.
Physical volume "/dev/sdd" successfully created.
Physical volume "/dev/sdf1" successfully created.
Physical volume "/dev/sdf2" successfully created.
# pvdisplay -C
PV VG Fmt Attr PSize PFree
/dev/sdb2 lvm2 --- 4.00g 4.00g
/dev/sdc3 lvm2 --- 3.00g 3.00g
/dev/sdd lvm2 --- 4.00g 4.00g
/dev/sdf1 lvm2 --- 4.00g 4.00g
/dev/sdf2 lvm2 --- 5.00g 5.00g
Fins aquí tot bé; tingueu en compte que un PV es pot configurar en un disc complet així com en particions individuals d'ell. Com es mostra a dalt, l'ordre pvdisplay llista els PV existents, amb dos formats de sortida possibles.
Ara ajuntem aquests elements físics en VG utilitzant vgcreate. Només agafarem els PV dels discos ràpids en un VG vg_critical; l'altre VG, vg_normal, també inclourà elements més lents.
# 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 7.99 GiB
PE Size 4.00 MiB
Total PE 2046
Alloc PE / Size 0 / 0
Free PE / Size 2046 / 7.99 GiB
VG UUID JgFWU3-emKg-9QA1-stPj-FkGX-mGFb-4kzy1G
# 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- 7.99g 7.99g
vg_normal 3 0 0 wz--n- <11.99g <11.99g
Aquí, de nou, les ordres són bastant senzilles (i vgdisplay proposa dos formats de sortida). Tingueu en compte que és possible utilitzar dues particions del mateix disc físic en dos VG diferents. Tingueu en compte també que hem utilitzat un prefix vg_ per anomenar els nostres VG, però no és més que una convenció.
Ara tenim dos “discos virtuals”, de mides aproximadament 8 GB i 12 GB respectivament. Ara els hem de dividir en “particions virtuals” (LV). Això involucra l'ordre lvcreate, i una sintaxi lleugerament més complexa:
# 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 Nr62xe-Zu7d-0u3z-Yyyp-7Cj1-Ej2t-gw04Xd
LV Write Access read/write
LV Creation host, time debian, 2022-03-01 00:17:46 +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 11.98G vg_normal
Rounding up size to full physical extent 11.98 GiB
Rounding up size to full physical extent 11.98 GiB
Logical volume "lv_backups" created.
# lvdisplay -C
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
lv_base vg_critical -wi-a----- 1.00g
lv_files vg_critical -wi-a----- 5.00g
lv_backups vg_normal -wi-a----- 11.98g
Es requereixen dos paràmetres al crear volums lògics; s'han de passar a lvcreate com a opcions. El nom de l'LV a crear s'especifica amb l'opció -n, i la seva mida es dona generalment utilitzant l'opció -L. També hem de dir-li a l'ordre en quin VG ha d'operar, per descomptat; d'aquí l'últim paràmetre de la línia d'ordres.
Els volums lògics, un cop creats, esdevenen fitxers de dispositius de blocs a /dev/mapper/:
# ls -l /dev/mapper
total 0
crw------- 1 root root 10, 236 Mar 1 00:17 control
lrwxrwxrwx 1 root root 7 Mar 1 00:19 vg_critical-lv_base -> ../dm-1
lrwxrwxrwx 1 root root 7 Mar 1 00:17 vg_critical-lv_files -> ../dm-0
lrwxrwxrwx 1 root root 7 Mar 1 00:19 vg_normal-lv_backups -> ../dm-2
# ls -l /dev/dm-*
brw-rw---- 1 root disk 253, 0 Mar 1 00:17 /dev/dm-0
brw-rw---- 1 root disk 253, 1 Mar 1 00:19 /dev/dm-1
brw-rw---- 1 root disk 253, 2 Mar 1 00:19 /dev/dm-2
Per facilitar les coses, també es creen enllaços simbòlics de conveniència als directoris que coincideixen amb els VG:
# ls -l /dev/vg_critical
total 0
lrwxrwxrwx 1 root root 7 Mar 1 00:19 lv_base -> ../dm-1
lrwxrwxrwx 1 root root 7 Mar 1 00:17 lv_files -> ../dm-0
# ls -l /dev/vg_normal
total 0
lrwxrwxrwx 1 root root 7 Mar 1 00:19 lv_backups -> ../dm-2
Els LV es poden utilitzar exactament com a particions estàndard:
# mkfs.ext4 /dev/vg_normal/lv_backups
mke2fs 1.46.2 (28-Feb-2021)
Discarding device blocks: done
Creating filesystem with 3140608 4k blocks and 786432 inodes
Filesystem UUID: 7eaf0340-b740-421e-96b2-942cdbf29cb3
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208
Allocating group tables: done
Writing inode tables: done
Creating journal (16384 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 24K 12G 1% /srv/backups
# [...]
[...]
# cat /etc/fstab
[...]
/dev/vg_critical/lv_base /srv/base ext4 defaults 0 2
/dev/vg_critical/lv_files /srv/files ext4 defaults 0 2
/dev/vg_normal/lv_backups /srv/backups ext4 defaults 0 2
Des del punt de vista de les aplicacions, l'escampall de petites particions s'han abstret en un volum gran de 12 GB, i amb un nom més amistós.
12.1.2.3. LVM amb el temps
Tot i que la capacitat d'afegir particions o discos físics és convenient, aquest no és el principal avantatge aportat per l'LVM. La flexibilitat que aporta es percep especialment a mesura que passa el temps, quan les necessitats evolucionen. En el nostre exemple, suposem que s'han d'emmagatzemar nous fitxers grans, i que el LV dedicat al servidor de fitxers és massa petit per contenir-los. Com que no hem utilitzat tot l'espai disponible de vg_critical, podem fer créixer lv_files. Per a aquest propòsit, utilitzarem la comanda lvresize, i després reize2fs per adaptar el sistema de fitxers en conseqüència:
# df -h /srv/files/
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_critical-lv_files 4.9G 4.2G 485M 90% /srv/files
# lvdisplay -C vg_critical/lv_files
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync 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- 7.99g 1.99g
# lvresize -L 6G vg_critical/lv_files
Size of logical volume vg_critical/lv_files changed from 5.00 GiB (1280 extents) to 6.00 GiB (1536 extents).
Logical volume vg_critical/lv_files successfully resized.
# lvdisplay -C vg_critical/lv_files
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
lv_files vg_critical -wi-ao---- 6.00g
# resize2fs /dev/vg_critical/lv_files
resize2fs 1.46.2 (28-Feb-2021)
Filesystem at /dev/vg_critical/lv_files is mounted on /srv/files; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 1
The filesystem on /dev/vg_critical/lv_files is now 1572864 (4k) blocks long.
# df -h /srv/files/
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_critical-lv_files 5.9G 4.2G 1.5G 75% /srv/files
Podríem procedir de manera similar per ampliar el volum que alberga la base de dades, només hem arribat al límit d'espai disponible del VG:
# df -h /srv/base/
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_critical-lv_base 974M 883M 25M 98% /srv/base
# vgdisplay -C vg_critical
VG #PV #LV #SN Attr VSize VFree
vg_critical 2 2 0 wz--n- 7.99g 1016.00m
No importa, ja que l'LVM permet afegir volums físics als grups de volums existents. Per exemple, potser ens hem adonat que la partició sdb3, que fins ara s'utilitzava fora de l'LVM, només contenia arxius que es podien moure a lv_backups. Ara podem reciclar-la i integrar-la en el grup de volums, i així recuperar un cert espai disponible. Aquest és el propòsit de l'ordre vgextend. Per descomptat, la partició s'ha de preparar com un volum físic per endavant. Una vegada que el VG s'ha ampliat, podem utilitzar ordres similars com abans per a augmentar el volum lògic i després el sistema de fitxers:
# pvcreate /dev/sdb3
Physical volume "/dev/sdb3" successfully created.
# vgextend vg_critical /dev/sdb3
Volume group "vg_critical" successfully extended
# vgdisplay -C vg_critical
VG #PV #LV #SN Attr VSize VFree
vg_critical 3 2 0 wz--n- <12.99g <5.99g
# lvresize -L 2G vg_critical/lv_base
[...]
# resize2fs /dev/vg_critical/lv_base
[...]
# df -h /srv/base/
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_critical-lv_base 2.0G 886M 991M 48% /srv/base
RAID i LVM aporten avantatges indiscutibles tan aviat com es deixa enrere el cas senzill d'un ordinador d'escriptori amb un sol disc dur on el patró d'ús no canvia amb el temps. No obstant això, el RAID i el LVM avancen en dues direccions diferents, amb objectius divergents, i és legítim preguntar-se quin s'ha d'adoptar. La resposta més apropiada dependrà, per descomptat, dels requisits actuals i dels previstos.
Hi ha alguns casos senzills en els quals la pregunta no realment no sorgeix. Si el requisit és salvaguardar les dades contra les fallades del maquinari, llavors és obvi que s'instal·larà un RAID en un conjunt redundant de discos, ja que l'LVM no s'ocupa realment d'aquest problema. Si, d'altra banda, la necessitat és un esquema d'emmagatzematge flexible on els volums es fan independents de la disposició física dels discs, RAID no hi ajuda molt i LVM serà l'elecció natural.
El tercer cas d'ús notable és quan només es vol agrupar dos discos en un volum, ja sigui per motius de rendiment o per tenir un sistema de fitxers únic que sigui més gran que qualsevol dels discos disponibles. Aquest cas es pot abordar tant per un RAID-0 (o fins i tot per un RAID lineal) com per un volum LVM. En aquesta situació, i sense restriccions addicionals (per exemple, mantenint-se en consonància amb la resta dels ordinadors si aquests només utilitzen RAID), la configuració escollida sovint serà LVM. La instal·lació inicial és poc més complexa, i aquest lleuger augment de la complexitat és més que el que compensa la flexibilitat addicional que aporta l'LVM si els requisits canvien o si cal afegir nous discos.
Després està, per descomptat, el cas d'ús realment interessant, en el qual el sistema d'emmagatzematge ha de ser resistent a fallades del maquinari i flexible pel que fa a l'assignació de volums. Ni RAID ni LVM poden abordar els dos requisits pel seu compte; tant se val, aquí és on els utilitzem tots dos alhora, o més aviat, un sobre l'altre. L'esquema que s'ha convertit en un estàndard des que RAID i LVM han arribat a la maduresa és assegurar la redundància de dades primer agrupant els discos en un petit nombre de grans conjunts RAID, i utilitzar aquests conjunts RAID com a volums físics LVM; les particions lògiques es treuran d'aquests LV per a sistemes de fitxers. El punt fort d'aquesta configuració és que quan un disc falla, només un petit nombre de conjunts RAID hauran de ser reconstruïts, limitant així el temps que l'administrador dedica a la recuperació.
Prenguem un exemple concret: el departament de relacions públiques de Falcot Corp necessita una estació de treball per a l'edició de vídeo, però el pressupost del departament no permet invertir en maquinari de gamma alta de cop. Es pren la decisió d'afavorir el maquinari que és específic de la naturalesa gràfica de la feina (monitor i targeta de vídeo), i d'estalviar amb maquinari genèric per a l'emmagatzematge. No obstant això, com és àmpliament conegut, el vídeo digital té alguns requisits particulars per al seu emmagatzematge: la quantitat de dades a emmagatzemar és gran, i la taxa de rendiment per llegir i escriure aquestes dades és important per al rendiment general del sistema (més que el temps d'accés típic, per exemple). Aquestes restriccions s'han de complir amb maquinari genèric, en aquest cas dues unitats de disc dur SATA de 300 GB; les dades del sistema també s'han de fer resistents a fallades de maquinari, així com algunes de les dades de l'usuari. Els videoclips editats han de ser segurs, però els vídeos pendents d'edició són menys crítics, ja que encara estan en cintes de vídeo.
RAID-1 i LVM es combinen per satisfer aquestes restriccions. Els discos es connecten a dos controladors SATA diferents per optimitzar l'accés paral·lel i reduir el risc d'una fallada simultània, i per tant apareixen com sda i sdc. Es particionen de manera idèntica seguint el següent esquema:
# sfdisk -l /dev/sda
Disk /dev/sda: 894.25 GiB, 960197124096 bytes, 1875385008 sectors
Disk model: SAMSUNG MZ7LM960
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: BB14C130-9E9A-9A44-9462-6226349CA012
Device Start End Sectors Size Type
/dev/sda1 2048 4095 2048 1M BIOS boot
/dev/sda2 4096 100667391 100663296 48G Linux RAID
/dev/sda3 100667392 134221823 33554432 16G Linux RAID
/dev/sda4 134221824 763367423 629145600 300G Linux RAID
/dev/sda5 763367424 1392513023 629145600 300G Linux RAID
/dev/sda6 1392513024 1875384974 482871951 230.3G Linux LVM
Les primeres particions d'ambdós discos són particions d'arrencada BIOS.
Les següents dues particions sda2 i sdc2 (al voltant de 48 GB) s'uneixen en un volum RAID-1, md0. Aquest mirall s'utilitza directament per emmagatzemar el sistema de fitxers arrel.
Les particions sda3 i sdc3 s'uneixen per formar un volum RAID-0, md1, que s'usa com a partició d'intercanvi oferint u total de 32 GB d'espai. Els sistemes moderns poden disposar de molta RAM i el nostre sistema no necessitarà la hibernació. Així que amb aquesta quantitat afegida, el nostre sistema probablement no farà curt de memòria.
Les particions sda4 i sdc4, així com sda5 i sdc5, s'uneixen en dos nous volums RAID-1 d'uns 300 GB cadascun, md2 i md3 . Aquests dos miralls s'inicialitzen com a volums físics per l'LVM, i s'assignen al grup de volums vg_raid. Aquest VG conté aproximadament 600 GB d'espai segur.
Les particions restants, sda6 i sdc6, s'utilitzen directament com a volums físics, i s'assignen a un altre VG anomenat vg_bulk, que per tant acaba amb aproximadament 460 GB d'espai.
Una vegada que es creen els VG, es poden particionar d'una manera molt flexible. Cal tenir en compte que els LV creats a vg_raid es conservaran fins i tot si falla un dels discos, que no serà el cas dels LV creats a vg_bulk; d'altra banda, aquest últim s'assignarà en paral·lel en ambdós discos, fet que permet una major velocitat de lectura o escriptura per a fitxers grans.
Per tant, crearem els LV lv_var i lv_home a vg_raid per acollir els sistemes de fitxers corresponents; un altre LV gran, lv_movies, s'utilitzarà per allotjar les versions definitives de les pel·lícules després de l'edició. L'altre VG es dividirà en un gran lv_rushes per a dades acabades d'obtenir de les càmeres de vídeo digital, i un lv_tmp per a fitxers temporals. La ubicació de l'àrea de treball és una opció menys senzilla de decidir: encara que es necessita un bon rendiment per a aquest volum, val la pena arriscar-se a perdre el treball si un disc falla durant una sessió d'edició? Depenent de la resposta a aquesta pregunta, el LV rellevant es crearà en un VG o l'altre.
Ara tenim una certa redundància per a les dades importants i molta flexibilitat en la forma en què es divideix l'espai disponible entre les aplicacions.
