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/sdc2) exceeds size (4189184K) 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 : 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:08:09 2022
State : clean, resync
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Consistency Policy : resync
Rebuild Status : 13% complete
Name : debian:1 (local to host debian)
UUID : 2dfb7fd5:e09e0527:0b5a905a:8334adb8
Events : 17
Number Major Minor RaidDevice State
0 8 34 0 active sync /dev/sdd2
1 8 48 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ó
Most of the meta-data concerning RAID volumes are saved directly on the disks that make up these arrays, so that the kernel can detect the arrays and their components and assemble them automatically when the system starts up. However, backing up this configuration is encouraged, because this detection isn't fail-proof, and it is only expected that it will fail precisely in sensitive circumstances. In our example, if the 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. In reality this leads to the RAID starting from the individual disks alternately - distributing the data also alternately, depending on which disk started the RAID in degraded mode 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.
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 matter, since LVM allows adding physical volumes to existing volume groups. For instance, maybe we've noticed that the sdb3 partition, which was so far used outside of LVM, only contained archives that could be moved to lv_backups. We can now recycle it and integrate it to the volume group, and thereby reclaim some available space. This is the purpose of the vgextend command. Of course, the partition must be prepared as a physical volume beforehand. Once the VG has been extended, we can use similar commands as previously to grow the logical volume then the filesystem:
# 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ó.
Let's take a concrete example: the public relations department at Falcot Corp needs a workstation for video editing, but the department's budget doesn't allow investing in high-end hardware from the bottom up. A decision is made to favor the hardware that is specific to the graphic nature of the work (monitor and video card), and to stay with generic hardware for storage. However, as is widely known, digital video does have some particular requirements for its storage: the amount of data to store is large, and the throughput rate for reading and writing this data is important for the overall system performance (more than typical access time, for instance). These constraints need to be fulfilled with generic hardware, in this case two 300 GB SATA hard disk drives; the system data must also be made resistant to hardware failure, as well as some of the user data. Edited video clips must indeed be safe, but video rushes pending editing are less critical, since they're still on the videotapes.
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
The first partitions of both disks are BIOS boot partitions.
The next two partitions sda2 and sdc2 (about 48 GB) are assembled into a RAID-1 volume, md0. This mirror is directly used to store the root filesystem.
The sda3 and sdc3 partitions are assembled into a RAID-0 volume, md1, and used as swap partition, providing a total 32 GB of swap space. Modern systems can provide plenty of RAM and our system won't need hibernation. So with this amount added, our system will unlikely run out of memory.
The sda4 and sdc4 partitions, as well as sda5 and sdc5, are assembled into two new RAID-1 volumes of about 300 GB each, md2 and md3. Both these mirrors are initialized as physical volumes for LVM, and assigned to the vg_raid volume group. This VG thus contains about 600 GB of safe space.
The remaining partitions, sda6 and sdc6, are directly used as physical volumes, and assigned to another VG called vg_bulk, which therefore ends up with roughly 460 GB of space.
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.
