Capitolo 12. Amministrazione avanzata

Questo capitolo rivede alcuni aspetti già descritti in precedenza, ma da una diversa prospettiva: invece di installare una singola macchina, si studiano sistemi di allestimento più vasti; invece di creare volumi RAID o LVM durante l'installazione, si descrive la procedura per farlo a mano in modo da poter rivedere in seguito le scelte iniziali. Infine, si discutono strumenti di monitoraggio e tecniche di virtualizzazione. Di conseguenza, questo capitolo è più orientato agli amministratori professionisti e meno ai singoli individui responsabili della rete di casa propria.

12.1. RAID e LVM

Capitolo 4, Installazione ha presentato queste tecnologie dal punto di vista dell'installatore, e di come questi li integrava per rendere il loro allestimento facile fin dall'inizio. Dopo l'installazione iniziale, un amministratore deve poter far fronte alle mutevoli necessità di spazio disco senza dover ricorrere a una reinstallazione costosa. Deve pertanto padroneggiare gli strumenti richiesti per manipolare volumi RAID e LVM.

RAID e LVM sono entrambi tecniche per astrarre i volumi montati dalle loro controparti fisiche (gli effettivi dischi fissi o le loro partizioni); il primo rende sicuri i dati contro guasti hardware introducendo una ridondanza, l'ultimo rende la gestione dei dati più flessibile e indipendente dall'effettiva dimensione dei dischi sottostanti. In entrambi i casi, il sistema acquisisce nuovi dispositivi a blocchi, che possono essere usati per creare filesystem o spazio di swap, senza necessariamente essere mappati su un unico disco fisico. RAID e LVM vengono da storie molto diverse, ma le loro funzionalità spesso si possono sovrapporre, che è il motivo per cui spesso vengono menzionati insieme.

PROSPETTIVA Btrfs combina LVM and RAID

Mentre LVM e RAID sono due sottosistemi distinti del kernel che si interpongono fra i dispositivi disco a blocchi e i loro file system, btrfs è un nuovo file system, sviluppato inizialmente da Oracle, che si propone di combinare le funzionalità di LVM e RAID e molto altro. È quasi del tutto funzionante, ed anche se è ancora etichettato come "sperimentale" perché il suo sviluppo è incompleto (alcune funzionalità non sono ancora state implementate), ha già visto alcuni ambienti di produzione.

→ http://btrfs.wiki.kernel.org/

Fra le funzionalità degne di nota vi sono la capacità di fare un'istantanea di un file system in ogni momento. Questa copia istantanea all'inizio non occupa spazio su disco, in quanto i dati vengono duplicati solo quando una delle copie viene modificata. Il file system inoltre gestisce la compressione trasparente dei file e dei codici di controllo assicurano l'integrità di tutti i dati memorizzati.

Sia nel RAID che nell'LVM, il kernel fornisce un file di device a blocchi, simile a quelli corrispondenti a un disco fisso o a una partizione. Quando un'applicazione o un'altra parte del kernel richiede l'accesso a un blocco di questo device, il sottosistema appropriato dirige il blocco allo strato fisico di competenza. A seconda della configurazione, questo blocco può essere memorizzato su uno o più dischi fisici e la sua posizione fisica potrebbe non essere direttamente correlata alla posizione del blocco nel device logico.

12.1.1. RAID software

RAID significa Redundant Array of Independent Disks (array ridondante di dischi indipendenti). Lo scopo di questo sistema è di impedire la perdita di dati in caso di guasto di un disco fisso. Il principio generale è molto semplice: i dati sono memorizzati su diversi dischi fisici piuttosto che su uno solo, con un livello di ridondanza configurabile. A seconda della quantità di ridondanza e anche in caso di guasto inatteso di un disco, i dati possono essere ricostruiti dai dischi rimanenti, senza alcuna perdita.

Il RAID può essere implementato sia tramite hardware dedicato (moduli RAID integrati in schede con controllori SCSI o SATA) sia tramite astrazione software (il kernel). Che sia hardware o software, un sistema RAID con sufficiente ridondanza può rimanere operativo in modo trasparente quando un disco si guasta; gli strati superiori della pila (applicazioni) possono perfino continuare ad accedere ai dati nonostante il guasto. Ovviamente questa «modalità degradata» può avere un impatto sulle prestazioni e inoltre viene ridotta la ridondanza, quindi un ulteriore guasto di un disco può provocare perdita di dati. In pratica, perciò, si cerca di rimanere in questa modalità degradata solo per il tempo necessario a sostituire il disco guasto. Una volta che il nuovo disco è al suo posto, il sistema RAID può ricostruire i dati richiesti e così tornare in modalità sicura. Le applicazioni non si accorgeranno di alcunché, a parte per la velocità di accesso potenzialmente ridotta, mentre l'array è in modalità degradata o durante la fase di ricostruzione.

Quando il RAID è implementato via hardware, la sua configurazione avviene generalmente all'interno dello strumento di configurazione del BIOS, ed il kernel considererà l'array RAID come un disco singolo, che funzionerà come un tradizionale disco singolo, anche il nome del dispositivo potrebbe essere differente (a seconda del driver).

In questo libro ci focalizzeremo sul RAID software.

12.1.1.1. Diversi livelli di RAID

Il RAID non è effettivamente un singolo sistema, ma una serie di sistemi identificati dai rispettivi livelli; che si distinguono per la loro disposizione e la quantità di ridondanza che forniscono. Più è ridondante, più è a prova di guasti, dal momento che il sistema sarà in grado di continuare a funzionare con più dischi rotti. Il rovescio della medaglia è che lo spazio utilizzabile diminuisce per un dato insieme di dischi; visto in un altro modo, servono più dischi per memorizzare la stessa quantità di dati.

RAID lineare: Anche se il sottosistema del kernel permette di creare un «RAID lineare», questo non è un RAID vero e proprio, poiché questa configurazione non prevede alcuna ridondanza. Il kernel semplicemente aggrega diversi dischi in fila e mette a disposizione il volume aggregato che ne risulta come un unico disco virtuale (un unico device a blocchi). Questa è praticamente la sua unica funzione. Questa configurazione è raramente usata da sola (vedere più avanti per le eccezioni), soprattutto in quanto la mancanza di ridondanza implica che basta un guasto a un singolo disco per rendere l'intero aggregato, e dunque tutti i dati, indisponibile.
RAID-0: Anche questo livello non fornisce alcuna ridondanza, ma i dischi non sono semplicemente messi in fila uno dietro l'altro: sono divisi in strisce e i blocchi sul device virtuale sono memorizzati su strisce su dischi fisici alternati. In un'impostazione RAID-0 a due dischi, per esempio, i blocchi di numero pari del device virtuale saranno memorizzati sul primo disco fisico, mentre i blocchi di numero dispari finiranno sul secondo disco fisico.
Questo sistema non mira ad aumentare l'affidabilità, in quanto (come nel caso lineare) la disponibilità di tutti i dati è a rischio non appena un disco si guasta, ma ad aumentare le prestazioni: durante l'accesso sequenziale a grandi quantità di dati contigui, il kernel potrà leggere da entrambi i dischi (o scrivere su di essi) in parallelo, il che aumenta la velocità di trasferimento dei dati. Tuttavia l'uso del RAID-0 sta diminuendo, in quanto LVM sta prendendo il suo posto (vedere più avanti).
RAID-1: Questo livello, noto anche come «RAID mirroring», è la configurazione più semplice e più usata. Nella sua forma standard, usa due dischi fisici della stessa grandezza e fornisce un volume logico anch'esso della stessa grandezza. I dati sono memorizzati in modo identico su entrambi i dischi, da cui il soprannome «mirror». Quando un disco si guasta, i dati sono ancora disponibili sull'altro. Per dati veramente critici, il RAID-1 può ovviamente essere impostato su più di due dischi, il che ha delle conseguenze sul rapporto fra costo dell'hardware e spazio disponibile.
NOTA Dischi e grandezze dei cluster
Se due dischi di dimensioni diverse vengono usati in mirror, il più grande non sarà usato completamente, in quanto conterrà gli stessi dati del più piccolo e nulla più. Lo spazio utile disponibile fornito da un volume RAID-1 perciò coincide con la dimensione del disco più piccolo nell'array. Ciò vale anche per volumi RAID con un diverso livello di RAID, anche se la ridondanza viene memorizzata diversamente.
È quindi importante, quando si configurano gli array RAID (eccetto il RAID-0 e il «RAID lineare»), assemblare solo dischi di dimensioni identiche, o molto vicine fra loro, per evitare di sprecare risorse.
NOTA Dischi di riserva
I livelli RAID che includono la ridondanza permettono di assegnare più dischi del necessario a un array. I dischi in più sono usati come riserva quando uno dei dischi principali si guasta. Per esempio, in un mirror di due dischi più una riserva, se uno dei primi due dischi si guasta, il kernel ricostruirà automaticamente (e immediatamente) il mirror usando il disco di riserva, cosicché la ridondanza resta assicurata dopo il tempo necessario alla ricostruzione. Ciò può essere usato come un'altra forma di salvaguardia per dati critici.
Ci si può legittimamente chiedere perché questo sarebbe meglio di un semplice mirror su tre dischi. Il vantaggio della configurazione col disco di riserva è che il disco di riserva può essere condiviso fra più volumi RAID. Ad esempio, si possono avere tre volumi in mirror, con ridondanza assicurata anche in caso di guasto di un disco, con soli sette dischi (tre coppie più una riserva condivisa) invece dei nove dischi che servirebbero per formare tre terne.
Questo livello di RAID, sebbene costoso (dal momento che al massimo è disponibile metà dello spazio fisico dei dischi), è ampiamente usato in pratica. È semplice da capire e permette di fare dei backup in modo molto semplice: dal momento che entrambi i dischi hanno gli stessi contenuti, uno di essi può essere temporaneamente estratto senza conseguenze sul sistema in funzione. Inoltre, spesso le prestazioni in lettura aumentano in quanto il kernel può leggere metà dati da ciascun disco in parallelo, mentre le prestazioni in scrittura non ne risentono troppo. Nel caso di un array RAID-1 di N dischi, i dati restano disponibili anche in caso si guastino N-1 dischi.
RAID-4: Questo livello di RAID, non molto usato, usa N dischi per memorizzare dati utili e un disco in più per memorizzare le informazioni di ridondanza. Se quel disco si guasta, il sistema può ricostruire i suoi contenuti a partire dagli altri N. Se uno degli N dischi con i dati si guasta, i rimanenti N-1 insieme al disco di «parità» contengono abbastanza informazioni per ricostruire i dati richiesti.
Il RAID-4 non è eccessivamente costoso, dal momento che richiede un aumento dei costi di appena uno-su-N e non ha un impatto notevole sulle prestazioni in lettura, ma le scritture ne risultano rallentate. Inoltre, dal momento che la scrittura su uno qualunque degli N dischi richiede anche una scrittura sul disco di parità, quest'ultimo riceve molte più scritture del primo e di conseguenza la sua vita può ridursi notevolmente. I dati su un array RAID-4 sono sicuri solo fino alla rottura di un solo disco (degli N+1).
RAID-5: Il RAID-5 risolve il problema di asimmetria del RAID-4: i blocchi di parità sono distribuiti su tutti gli N+1 dischi, senza che un unico disco abbia un ruolo particolare.
Le prestazioni in lettura e scrittura sono identiche al RAID-4. Anche qui il sistema rimane in funzione fino al guasto di un unico disco (degli N+1).
RAID-6: Il RAID-6 si può considerare un'estensione del RAID-5, in cui ciascuna serie di N blocchi richiede due blocchi di ridondanza e ciascuna di queste serie di N+2 blocchi viene distribuita su N+2 dischi.
Questo livello di RAID è leggermente più costoso dei due precedenti, ma fornisce un po' di sicurezza in più, dal momento che possono guastarsi fino a due dischi (degli N+2) senza compromettere la disponibilità dei dati. Il difetto è che le operazioni di scrittura ora richiedono la scrittura di un blocco di dati e due blocchi di ridondanza, il che le rende ancora più lente.
RAID-1+0: Strettamente parlando, questo non è un livello di RAID, ma un modo di impilare due gruppi di RAID. Partendo da 2×n dischi, prima si impostano a coppie in N volumi RAID-1; questi N volumi vengono quindi aggregati in uno solo, tramite «RAID lineare» o (sempre più spesso) tramite LVM. In quest'ultimo caso si va oltre il semplice RAID, ma questo non è un problema.
Il RAID-1+0 può sopravvivere al guasto di più dischi: fino a N nell'array 2×n descritto sopra, a condizione che almeno un disco continui a funzionare in ciascuna coppia RAID-1.
APPROFONDIMENTI RAID-10
Il RAID-10 viene generalmente considerato un sinonimo di RAID-1+0, ma una particolarità di Linux lo rende in realtà una generalizzazione. Questa configurazione permette di avere un sistema in cui ogni blocco è memorizzato su due dischi diversi, anche con un numero dispari di dischi; le copie vengono poi distribuite secondo un modello configurabile.
Le prestazioni varieranno a seconda del modello di ripartizione e dal livello di ridondanza scelti e dal carico di lavoro del volume logico.

Ovviamente, il livello di RAID verrà scelto a seconda dei vincoli e dei requisiti di ciascuna applicazione. Notare che un solo computer può avere diversi array RAID distinti con diverse configurazioni.

12.1.1.2. Impostazione di un RAID

L'impostazione di volumi RAID richiede il pacchetto mdadm; esso fornisce il comando mdadm, che permette di creare e manipolare array RAID, oltre che script e strumenti per integrarlo al resto del sistema, compreso il sistema di monitoraggio.

Questo esempio mostrerà un server con un certo numero di dischi, alcuni dei quali sono già usati e i rimanenti sono disponibili per impostare il RAID. All'inizio si hanno i seguenti dischi e partizioni:

il disco sdb, 4 GB, è interamente disponibile;
il disco sdc, 4 GB, è anch'esso interamente disponibile;
sul disco sdd, solo la partizione sdd2 (circa 4 GB) è disponibile;
infine, un disco sde, di nuovo di 4 GB, interamente disponibile.

Questi elementi fisici verranno usati per costruire due volumi, un RAID-0 e un mirror (RAID-1). Si inizia col volume 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: 8.00GiB raid0 2 devices, 0 spares. Use mdadm --detail for more detail.
# mdadm --detail /dev/md0
/dev/md0:
        Version : 1.2
  Creation Time : Wed May  6 09:24:34 2015
     Raid Level : raid0
     Array Size : 8387584 (8.00 GiB 8.59 GB)
   Raid Devices : 2
  Total Devices : 2
    Persistence : Superblock is persistent

    Update Time : Wed May  6 09:24:34 2015
          State : clean 
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

     Chunk Size : 512K

           Name : mirwiz:0  (local to host mirwiz)
           UUID : bb085b35:28e821bd:20d697c9:650152bb
         Events : 0

    Number   Major   Minor   RaidDevice State
       0       8       16        0      active sync   /dev/sdb
       1       8       32        1      active sync   /dev/sdc
# mkfs.ext4 /dev/md0
mke2fs 1.42.12 (29-Aug-2014)
Creating filesystem with 2095104 4k blocks and 524288 inodes
Filesystem UUID: fff08295-bede-41a9-9c6a-8c7580e520a6
Superblock backups stored on blocks: 
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done 
# mkdir /srv/raid-0
# mount /dev/md0 /srv/raid-0
# df -h /srv/raid-0
Filesystem      Size  Used Avail Use% Mounted on
/dev/md0        7.9G   18M  7.4G   1% /srv/raid-0

Il comando mdadm --create richiede diversi parametri: il nome del volume da creare (/dev/md*, dove MD sta per Multiple Device), il livello di RAID, il numero di dischi (obbligatorio nonostante abbia significato perlopiù solo con RAID-1 e superiori), ed i dischi fisici da usare. Una volta che il dispositivo è creato, può essere usato come una normale partizione, ci si crea sopra un file system, lo si monta, e così via. Notare che la creazione di un volume RAID-0 su md0 è solo una coincidenza, non è necessario che la numerazione dell'array sia legata alla quantità di ridondanza scelta. E' anche possibile creare un array RAID con nome, passando a mdadm parametri come /dev/md/linear invece di /dev/md0.

La creazione di un RAID-1 segue un percorso simile, la differenza si nota solo dopo la creazione:

# 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 : Wed May  6 09:30:19 2015
     Raid Level : raid1
     Array Size : 4192192 (4.00 GiB 4.29 GB)
  Used Dev Size : 4192192 (4.00 GiB 4.29 GB)
   Raid Devices : 2
  Total Devices : 2
    Persistence : Superblock is persistent

    Update Time : Wed May  6 09:30:40 2015
          State : clean, resyncing (PENDING) 
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

           Name : mirwiz:1  (local to host mirwiz)
           UUID : 6ec558ca:0c2c04a0:19bca283:95f67464
         Events : 0

    Number   Major   Minor   RaidDevice State
       0       8       50        0      active sync   /dev/sdd2
       1       8       64        1      active sync   /dev/sde
# mdadm --detail /dev/md1
/dev/md1:
[...]
          State : clean
[...]

Bisogna fare alcune osservazioni. Prima di tutto, mdadm si accorge che gli elementi fisici hanno dimensioni diverse; poiché ciò implica che verrà perso dello spazio sull'elemento più grande, è richiesta una conferma.

Cosa ancora più importante, notare lo stato del mirror. Lo stato normale di un mirror RAID è che entrambi i dischi abbiano esattamente gli stessi contenuti. Tuttavia, nulla garantisce che ciò sia vero quando il volume viene creato. Il sottosistema RAID perciò fornirà esso stesso questa garanzia, e appena dopo la creazione del device RAID ci sarà una fase di sincronizzazione. Dopo un certo tempo (l'esatta durata dipenderà dall'effettiva dimensione dei dischi…), l'array RAID passa allo stato "attivo" o "pulito". Notare che durante questa fase di ricostruzione, il mirror è in modalità degradata, e la ridondanza non è assicurata. Il guasto di un disco durante questa fase potrebbe comportare la perdita di tutti i dati. Ad ogni modo, è raro che grandi quantità di dati critici vengano memorizzati su un array RAID appena creato prima della sincronizzazione iniziale. Notare che anche in modalità degradata, /dev/md1 è usabile, e vi si può creare sopra un file system, oltre a copiarvi sopra dei dati.

SUGGERIMENTO Avviare un mirror in modalità degradata

A volte non si hanno subito a disposizione due dischi quando si vuole avviare un mirror RAID-1, per esempio perché uno dei dischi che si vogliono includere è già usato per memorizzare i dati che si vogliono spostare nell'array. In questi casi è possibile creare volontariamente un array RAID-1 degradato passando missing invece di un file di device come uno degli argomenti a mdadm. Una volta che i dati sono stati copiati sul «mirror», il vecchio disco può essere aggiunto all'array. A quel punto avrà luogo una sincronizzazione, che darà la ridondanza voluta all'inizio.

SUGGERIMENTO Impostare un mirror senza sincronizzazione

I volumi RAID-1 sono spesso creati per essere usati come nuovo disco, spesso considerato vuoto. L'effettivo contenuto iniziale del disco quindi non è molto importante, visto che basta sapere che i dati scritti dopo la creazione del volume, in particolare il file system, possono essere letti in seguito.

Ci si può quindi chiedere il senso di sincronizzare entrambi i dischi al momento della creazione. Perché preoccuparsi del fatto che i contenuti siano identici in zone del volume di cui si sa che verranno lette solo dopo che sono state scritte?

Per fortuna, questa fase di sincronizzazione può essere evitata passando l'opzione --assume-clean a mdadm. Tuttavia, questa opzione può portare a delle sorprese in casi in cui i dati iniziali saranno letti (per esempio se sui dischi fisici è già presente un file system), che è il motivo per cui non è abilitata in modo predefinito.

Ora si mostrerà cosa succede quando uno degli elementi dell'array RAID 1 si guasta. mdadm, in particolare la sua opzione --fail, permette di simulare uno guasto:

# mdadm /dev/md1 --fail /dev/sde
mdadm: set /dev/sde faulty in /dev/md1
# mdadm --detail /dev/md1
/dev/md1:
[...]
    Update Time : Wed May  6 09:39:39 2015
          State : clean, degraded 
 Active Devices : 1
Working Devices : 1
 Failed Devices : 1
  Spare Devices : 0

           Name : mirwiz:1  (local to host mirwiz)
           UUID : 6ec558ca:0c2c04a0:19bca283:95f67464
         Events : 19

    Number   Major   Minor   RaidDevice State
       0       8       50        0      active sync   /dev/sdd2
       2       0        0        2      removed

       1       8       64        -      faulty   /dev/sde

I contenuti del volume sono ancora accessibili (e, se montato, le applicazioni non si accorgono di nulla), ma la sicurezza dei dati non è più assicurata: se il disco sdd dovesse a sua volta guastarsi, i dati andrebbero persi. Poiché è meglio evitare questo rischio, si va a sostituire il disco guasto con uno nuovo, sdf:

# mdadm /dev/md1 --add /dev/sdf
mdadm: added /dev/sdf
# mdadm --detail /dev/md1
/dev/md1:
[...]
   Raid Devices : 2
  Total Devices : 3
    Persistence : Superblock is persistent

    Update Time : Wed May  6 09:48:49 2015
          State : clean, degraded, recovering 
 Active Devices : 1
Working Devices : 2
 Failed Devices : 1
  Spare Devices : 1

 Rebuild Status : 28% complete

           Name : mirwiz:1  (local to host mirwiz)
           UUID : 6ec558ca:0c2c04a0:19bca283:95f67464
         Events : 26

    Number   Major   Minor   RaidDevice State
       0       8       50        0      active sync   /dev/sdd2
       2       8       80        1      spare rebuilding   /dev/sdf

       1       8       64        -      faulty   /dev/sde
# [...]
[...]
# mdadm --detail /dev/md1
/dev/md1:
[...]
    Update Time : Wed May  6 09:49:08 2015
          State : clean 
 Active Devices : 2
Working Devices : 2
 Failed Devices : 1
  Spare Devices : 0

           Name : mirwiz:1  (local to host mirwiz)
           UUID : 6ec558ca:0c2c04a0:19bca283:95f67464
         Events : 41

    Number   Major   Minor   RaidDevice State
       0       8       50        0      active sync   /dev/sdd2
       2       8       80        1      active sync   /dev/sdf

       1       8       64        -      faulty   /dev/sde

Anche qui, il kernel attiva automaticamente una fase di ricostruzione durante la quale il volume, sebbene ancora accessibile, è in modalità degradata. Una volta finita la ricostruzione, l'array RAID torna a uno stato normale. A questo punto si può dire al sistema che il disco sde sta per essere rimosso dall'array, così da arrivare a un classico mirror RAID su due dischi:

# mdadm /dev/md1 --remove /dev/sde
mdadm: hot removed /dev/sde from /dev/md1
# mdadm --detail /dev/md1
/dev/md1:
[...]
    Number   Major   Minor   RaidDevice State
       0       8       50        0      active sync   /dev/sdd2
       2       8       80        1      active sync   /dev/sdf

Da questo punto il drive può essere rimosso fisicamente al prossimo spegnimento del server, o anche rimosso a caldo quando la configurazione hardware permette l'hot-swap. Tali configurazioni includono alcuni controller SCSI, la maggior parte dei dischi SATA e i dischi esterni che operano su USB o Firewire.

12.1.1.3. Fare il backup della configurazione

La maggior parte dei meta-dati riguardanti i volumi RAID sono salvati direttamente sui dischi che compongono questi array, cosicché il kernel può rilevare gli array e i loro componenti e assemblarli automaticamente all'avvio del sistema. Tuttavia, è consigliabile fare copie di riserva di questa configurazione, perché questo rilevamento non è infallibile, ed è ovvio che fallisca proprio in circostanze delicate. Nell'esempio in questione, se il guasto al disco sdh fosse stato reale (invece di essere solo una simulazione) e il sistema si fosse riavviato senza rimuovere questo disco sdh, questo disco si sarebbe attivato di nuovo, essendo stato riconosciuto durante il riavvio. A quel punto il kernel avrebbe tre elementi fisici, ciascuno dei quali direbbe di contenere metà dello stesso volume RAID. Un'altra fonte di confusione può sorgere quando volumi RAID di due server vengono consolidati su un solo server. Se questi array stavano funzionando normalmente prima che i dischi fossero spostati, il kernel potrebbe rilevare e riassemblare le coppie correttamente; ma se i dischi spostati sono stati aggregati in un md1 sul vecchio server e il nuovo server ha già un md1, uno dei mirror verrebbe rinominato.

È quindi importante fare il backup della configurazione, se non altro per avere un riferimento. Il modo standard di farlo è modificare il file /etc/mdadm/mdadm.conf, un esempio del quale è mostrato qui:

Esempio 12.1. File di configurazione di mdadm

# mdadm.conf
#
# Please refer to mdadm.conf(5) for information about this file.
#

# by default (built-in), scan all partitions (/proc/partitions) and all
# containers for MD superblocks. alternatively, specify devices to scan, using
# wildcards if desired.
DEVICE /dev/sd*

# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes

# automatically tag new arrays as belonging to the local system
HOMEHOST <system>

# instruct the monitoring daemon where to send mail alerts
MAILADDR root

# definitions of existing MD arrays
ARRAY /dev/md0 metadata=1.2 name=mirwiz:0 UUID=bb085b35:28e821bd:20d697c9:650152bb
ARRAY /dev/md1 metadata=1.2 name=mirwiz:1 UUID=6ec558ca:0c2c04a0:19bca283:95f67464

# This configuration was auto-generated on Thu, 17 Jan 2013 16:21:01 +0100
# by mkconf 3.2.5-3

Uno dei dettagli più utili è l'opzione DEVICE, che elenca i dispositi in cui il sistema cercherà automaticamente le componenti dei volumi RAID all'avvio. Nell'esempio in questione, abbiamo sostituito il valore predefinito, partitions containers, con una lista esplicita dei file di dispositi, poiché si è scelto di usare dei dischi interi e non solo delle partizioni, per alcuni volumi.

Le ultime due righe nell'esempio sono quelle che permettono al kernel di scegliere in sicurezza quale numero di volume assegnare a ciascun array. I metadati memorizzati sui dischi stessi sono sufficienti a riassemblare i volumi ma non a determinare i numeri di volume (e il corrispondente nome di device /dev/md*).

Per fortuna, queste righe si possono generare automaticamente:

# mdadm --misc --detail --brief /dev/md?
ARRAY /dev/md0 metadata=1.2 name=mirwiz:0 UUID=bb085b35:28e821bd:20d697c9:650152bb
ARRAY /dev/md1 metadata=1.2 name=mirwiz:1 UUID=6ec558ca:0c2c04a0:19bca283:95f67464

I contenuti di queste ultime due righe non dipendono dall'elenco dei dischi inclusi nel volume. Pertanto non è necessario rigenerare queste righe quando si sostituisce un disco guasto con uno nuovo. D'altro canto, bisogna avere cura di aggiornare il file quando si crea o si elimina un array RAID.

12.1.2. LVM

LVM, il Logical Volume Manager (Gestore Volume Logico) , è un altro approccio per astrarre volumi logici dai loro supporti fisici, che si concentra più sull'aumento della flessibilità che sull'aumento dell'affidabilità. LVM permette la modifica di un volume logico in modo trasparente dal punto di vista delle applicazioni; per esempio, è possibile aggiungere nuovi dischi, migrare i dati ad esso, e rimuovere i vecchi dischi, senza smontare il volume.

12.1.2.1. Concetti relativi a LVM

Questa flessibilità si raggiunge tramite un livello di astrazione che riguarda tre concetti.

Primo, il PV (Physical Volume, volume fisico) è l'entità più vicina all'hardware: i volumi fisici possono essere partizioni di un disco, o un disco completo, o anche qualunque altro dispositivo a blocchi (incluso, ad esempio, un array RAID). Notare che quando un elemento fisico viene configurato come PV per LVM, vi si deve accedere solo via LVM, altrimenti il sistema si confonderà.

Un certo numero di PV può essere raggruppato in un VG (Volume Group, gruppo di volume), che è paragonabile a dei dischi che siano sia virtuali che estendibili. I VG sono astratti e non compaiono in un file di device nella gerarchia /dev, quindi non c'è rischio di usarli direttamente.

Il terzo tipo di oggetto è il LV (Logical Volume, volume logico), che è una parte di un VG; proseguendo con l'analogia fra VG e dischi, il LV è simile a una partizione. Il LV appare come un dispositivo a blocchi con una voce in /dev, e può essere usato come ogni altra partizione fisica (più di frequente, per ospitare un filesystem o spazio di swap).

La cosa importante è che la divisione di un VG in LV è completamente indipendente dai suoi componenti fisici (i PV). Un VG con un solo componente fisico (per esempio un disco) può essere diviso in una dozzina di volumi logici; allo stesso modo, un VG può usare diversi dischi fisici e apparire come un unico grande volume logico. L'unico vincolo, ovviamente, è che la dimensione totale allocata ai LV non può superare la capacità totale dei PV nel gruppo di volume.

Spesso comunque ha un senso avere una certa omogeneità fra le componenti fisiche di un VG, e suddividere i VG in volumi logici che avranno modelli d'uso simili. Per esempio, se l'hardware disponibile include dischi rapidi e dischi più lenti, quelli rapidi possono essere raggruppati in un VG e quelli più lenti in un altro; blocchi del primo possono quindi essere assegnati ad applicazioni che richiedono un accesso rapido ai dati, mentre il secondo sarà tenuto per compiti meno impegnativi.

In ogni caso, è bene tenere a mente che un LV non è particolarmente legato a un singolo PV. È possibile indicare dove sono fisicamente memorizzati i dati di un LV, ma questa possibilità non è richiesta per un uso quotidiano. Al contrario: quando l'insieme dei componenti fisici di un VG evolve, il luogo fisico di stoccaggio che corrisponde a un particolare LV può essere migrato da un disco a un altro (ovviamente rimanendo all'interno dei PV assegnati ai VG).

12.1.2.2. Impostazione di un LVM

Si seguirà ora, passo per passo, il processo di impostazione di un LVM per un tipico caso d'uso: semplificare una situazione complessa di memorizzazione dati. Una tale situazione di solito si ha dopo una lunga e intricata storia fatta di misure temporanee accumulatesi nel tempo. A scopo illustrativo, si considererà un server in cui le necessità di memorizzazione sono cambiate nel tempo, arrivando ad avere alla fine un labirinto di partizioni disponibili sparse fra diversi dischi usati parzialmente. In termini più concreti, sono disponibili le seguenti partizioni:

sul disco sdb, una partizione sdb2, 4 GB;
sul disco sdc, una partizione sdc3, 3 GB;
il disco sdd, 4 GB, è completamente disponibile;
sul disco sdf, una partizione sdf1, 4 GB e una partizione sdf2, 5 GB.

Inoltre, si suppone che i dischi sdb e sdf siano più veloci degli altri due.

Lo scopo è di impostare tre volumi logici per tre diverse applicazioni: un file server che richiede 5 GB di spazio disco, un database (1 GB) e un po' di spazio per i backup (12 GB). I primi due hanno bisogno di buone prestazioni, ma i backup sono meno critici in termini di velocità di accesso. Tutti questi vincoli impediscono di usare le partizioni così come sono; l'uso di LVM permette di astrarre dalla dimensione fisica dei dispositivi, cosicché l'unico limite è lo spazio totale disponibile.

Gli strumenti richiesti sono nel pacchetto lvm2 e nelle sue dipendenze. Una volta installati, impostare un LVM richiede tre passi, che corrispondono ai tre livelli di concetti.

Prima di tutto si preparano i volumi fisici usando pvcreate:

# pvdisplay
# 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               0zuiQQ-j1Oe-P593-4tsN-9FGy-TY0d-Quz31I

# 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.09g 3.09g
  /dev/sdd        lvm2 ---  4.00g 4.00g
  /dev/sdf1       lvm2 ---  4.10g 4.10g
  /dev/sdf2       lvm2 ---  5.22g 5.22g

Finora tutto bene: notare che un PV può essere impostato su tutto un disco così come su singole partizioni. Come mostrato sopra, il comando pvdisplay elenca le PV esistenti, con due possibili formati di output.

Ora si assemblano questi elementi fisici in VG usando vgcreate. Solo le PV dei dischi più veloci saranno riunite in un VG vg_critical; l'altro VG, vg_normal, includerà anche gli elementi più lenti.

# vgdisplay
  No volume groups found
# vgcreate vg_critical /dev/sdb2 /dev/sdf1
  Volume group "vg_critical" successfully created
# vgdisplay
  --- Volume group ---
  VG Name               vg_critical
  System ID             
  Format                lvm2
  Metadata Areas        2
  Metadata Sequence No  1
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                0
  Open LV               0
  Max PV                0
  Cur PV                2
  Act PV                2
  VG Size               8.09 GiB
  PE Size               4.00 MiB
  Total PE              2071
  Alloc PE / Size       0 / 0   
  Free  PE / Size       2071 / 8.09 GiB
  VG UUID               bpq7zO-PzPD-R7HW-V8eN-c10c-S32h-f6rKqp

# vgcreate vg_normal /dev/sdc3 /dev/sdd /dev/sdf2
  Volume group "vg_normal" successfully created
# vgdisplay -C
  VG          #PV #LV #SN Attr   VSize  VFree 
  vg_critical   2   0   0 wz--n-  8.09g  8.09g
  vg_normal     3   0   0 wz--n- 12.30g 12.30g

Anche qui, i comandi sono piuttosto semplici (e vgdisplay propone due formati di output). Notare che è possibile usare due partizioni dello stesso disco fisico in due diversi VG. Notare inoltre che si è usato un prefisso vg_ per nominare i VG, ma non è altro che una convenzione.

Adesso ci sono due «dischi virtuali», della dimensione di circa 8 GB e 12 GB rispettivamente. Ora vengono modellati in «partizioni virtuali» (LV). Ciò richiede l'uso del comando lvcreate e una sintassi leggermente più complessa:

# lvdisplay
# lvcreate -n lv_files -L 5G vg_critical
  Logical volume "lv_files" created
# lvdisplay
  --- Logical volume ---
  LV Path                /dev/vg_critical/lv_files
  LV Name                lv_files
  VG Name                vg_critical
  LV UUID                J3V0oE-cBYO-KyDe-5e0m-3f70-nv0S-kCWbpT
  LV Write Access        read/write
  LV Creation host, time mirwiz, 2015-06-10 06:10:50 -0400
  LV Status              available
  # open                 0
  LV Size                5.00 GiB
  Current LE             1280
  Segments               2
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:0

# lvcreate -n lv_base -L 1G vg_critical
  Logical volume "lv_base" created
# lvcreate -n lv_backups -L 12G vg_normal
  Logical volume "lv_backups" created
# lvdisplay -C
  LV         VG          Attr     LSize  Pool Origin Data%  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--- 12.00g

La creazione di volumi logici richiede due parametri che devono essere passati come opzioni al comando lvcreate. Il nome dei LV da creare viene specificato con l'opzione -n e la sua dimensione viene generalmente data usando l'opzione -L. Ovviamente bisogna anche dire al comando su quale VG operare, da cui l'ultimo parametro sulla riga di comando.

APPROFONDIMENTI Opzioni di lvcreate

Il comando lvcreate ha diverse opzioni per poter specificare i dettagli della creazione del LV.

Prima si descrive l'opzione -l, con cui si può specificare la dimensione del LV come numero di blocchi (invece delle unità «umane» usate sopra). Questi blocchi (chiamati PE, physical extents, estensioni fisiche, in termini LVM) sono unità contigue di spazio di memorizzazione e non possono essere divisi fra più LV. Quando si vuol definire lo spazio di memorizzazione con una certa precisione¸per esempio per usare tutto lo spazio disponibile, probabilmente è meglio usare l'opzione -l piuttosto che -L.

È inoltre possibile suggerire la posizione fisica di un LV, cosicché le sue estensioni siano memorizzate su un particolare PV (ovviamente rimanendo all'interno di quelli assegnati al VG). Poiché sdb è più veloce di sdf, è meglio memorizzare lì lv_base se si vuol dare un vantaggio al server di database rispetto al file server. La riga di comando diventa: lvcreate -n lv_base -L 1G vg_critical /dev/sdb2. Notare che questo comando può fallire se il PV non ha abbastanza estensioni libere. Nell'esempio, per evitare questa situazione, probabilmente si deve creare lv_base prima di lv_files o liberare spazio su sdb2 con il comando pvmove.

Una volta creati, i volumi logici si trovano come file di device a blocchi in /dev/mapper/:

# ls -l /dev/mapper
total 0
crw------- 1 root root 10, 236 Jun 10 16:52 control
lrwxrwxrwx 1 root root       7 Jun 10 17:05 vg_critical-lv_base -> ../dm-1
lrwxrwxrwx 1 root root       7 Jun 10 17:05 vg_critical-lv_files -> ../dm-0
lrwxrwxrwx 1 root root       7 Jun 10 17:05 vg_normal-lv_backups -> ../dm-2
# ls -l /dev/dm-*
brw-rw---T 1 root disk 253, 0 Jun 10 17:05 /dev/dm-0
brw-rw---- 1 root disk 253, 1 Jun 10 17:05 /dev/dm-1
brw-rw---- 1 root disk 253, 2 Jun 10 17:05 /dev/dm-2

NOTA Rilevamento automatico di volumi LVM

All'avvio del computer, l'unità di servizio di systemd lvm2-activation esegue vgchange -aay per "attivare" i gruppi di volumi: passa in rassegna i device disponibili; quelli che sono stati inizializzati come volumi fisici per LVM sono registrati nel sottosistema LVM, quelli che appartengono a gruppi di volume vengono assemblati e i relativi volumi logici vengono avviati e resi disponibili. Non c'è quindi bisogno di modificare file di configurazione quando si creano o si modificano volumi LVM.

Notare, tuttavia, che la disposizione degli elementi LVM (volumi fisici e logici e gruppi di volume) viene replicata in /etc/lvm/backup, che può essere utile in caso di problemi (o solo per dare un'occhiata a cosa succede).

Per facilitare le cose, vengono inoltre creati dei comodi collegamenti simbolici in directory corrispondenti ai VG:

# ls -l /dev/vg_critical
total 0
lrwxrwxrwx 1 root root 7 Jun 10 17:05 lv_base -> ../dm-1
lrwxrwxrwx 1 root root 7 Jun 10 17:05 lv_files -> ../dm-0
# ls -l /dev/vg_normal
total 0
lrwxrwxrwx 1 root root 7 Jun 10 17:05 lv_backups -> ../dm-2

I LV possono quindi essere usati esattamente come normali partizioni:

# mkfs.ext4 /dev/vg_normal/lv_backups
mke2fs 1.42.12 (29-Aug-2014)
Creating filesystem with 3145728 4k blocks and 786432 inodes
Filesystem UUID: b5236976-e0e2-462e-81f5-0ae835ddab1d
[...]
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done 
# mkdir /srv/backups
# mount /dev/vg_normal/lv_backups /srv/backups
# df -h /srv/backups
Filesystem                        Size  Used Avail Use% Mounted on
/dev/mapper/vg_normal-lv_backups   12G   30M   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

Dal punto di vista delle applicazioni, la miriade di piccole partizioni è stata ora astratta in un grande volume di 12 GB con un nome più familiare.

12.1.2.3. LVM nel tempo

Anche se la capacità di aggregare partizioni o dischi fisici è comoda, questo non è il vantaggio principale di LVM. La sua flessibilità si nota soprattutto col passare del tempo, quando le necessità evolvono. Nell'esempio, si supponga di dover memorizzare dei nuovi grandi file e che il LV dedicato al file server sia troppo piccolo per contenerli. Poiché non si è usato tutto lo spazio disponibile in vg_critical, si può espandere lv_files. A questo scopo, si usa il comando lvresize, quindi resize2fs per adattare il file system di conseguenza:

# df -h /srv/files/
Filesystem                        Size  Used Avail Use% Mounted on
/dev/mapper/vg_critical-lv_files  5.0G  4.6G  146M  97% /srv/files
# lvdisplay -C vg_critical/lv_files
  LV       VG          Attr     LSize Pool Origin Data%  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- 8.09g 2.09g
# lvresize -L 7G vg_critical/lv_files
  Size of logical volume vg_critical/lv_files changed from 5.00 GiB (1280 extents) to 7.00 GiB (1792 extents).
  Logical volume 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-- 7.00g
# resize2fs /dev/vg_critical/lv_files
resize2fs 1.42.12 (29-Aug-2014)
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 1835008 (4k) blocks long.

# df -h /srv/files/
Filesystem                        Size  Used Avail Use% Mounted on
/dev/mapper/vg_critical-lv_files  6.9G  4.6G  2.1G  70% /srv/files

ATTENZIONE Ridimensionare i file system

Non tutti i file system si possono ridimensionare a caldo; per ridimensionare un volume può quindi essere necessario smontare il file system e rimontarlo in seguito. Ovviamente, se si vuole restringere lo spazio allocato a un LV, bisogna prima restringere il file system; l'ordine è invertito quando il ridimensionamento è al contrario: il volume logico deve essere allargato prima del file system che c'è sopra. È piuttosto semplice, dal momento che la dimensione del file system non deve mai essere superiore a quella del dispositivo a blocchi dove risiede (che quel dispositivo sia una partizione fisica o un volume logico).

I file system ext3, ext4 e xfs possono essere allargati a caldo, senza smontarli; per restringerli vanno invece smontati. Il file system reiserfs permette il ridimensionamento a caldo in entrambe le direzioni. Il buon vecchio ext2 non permette alcuna delle due cose e richiede sempre di essere smontato.

Si potrebbe procedere in modo simile per estendere il volume che ospita il database, ma è stato raggiunto il limite di spazio disponibile del VG:

# df -h /srv/base/
Filesystem                       Size  Used Avail Use% Mounted on
/dev/mapper/vg_critical-lv_base 1008M  854M  104M  90% /srv/base
# vgdisplay -C vg_critical
  VG          #PV #LV #SN Attr   VSize VFree 
  vg_critical   2   2   0 wz--n- 8.09g 92.00m

Questo non è un problema, dal momento che LVM permette di aggiungere volumi fisici a gruppi di volume esistenti. Per esempio, si può notare che la partizione sdb1, che finora era stata usata al di fuori di LVM, conteneva solo archivi che potrebbero essere spostati su lv_backups. La si può quindi riciclare e integrare nel gruppo di volume, liberando così dello spazio utilizzabile. Questo è lo scopo del comando vgextend. Ovviamente la partizione deve essere preparata in precedenza come volume fisico. Una volta che il VG è stato esteso, possiamo usare comandi simili ai precedenti per espandere il volume logico e poi il file system:

# pvcreate /dev/sdb1
  Physical volume "/dev/sdb1" successfully created
# vgextend vg_critical /dev/sdb1
  Volume group "vg_critical" successfully extended
# vgdisplay -C vg_critical
  VG          #PV #LV #SN Attr   VSize VFree
  vg_critical   3   2   0 wz--n- 9.09g 1.09g
# [...]
[...]
# df -h /srv/base/
Filesystem                       Size  Used Avail Use% Mounted on
/dev/mapper/vg_critical-lv_base  2.0G  854M  1.1G  45% /srv/base

APPROFONDIMENTI LVM avanzato

LVM soddisfa anche necessità più avanzate, dove molti dettagli si possono specificare a mano. Per esempio, un amministratore può regolare la dimensione dei blocchi che compongono i volumi fisici e logici, oltre alla loro disposizione fisica. È anche possibile spostare i blocchi fra i vari PV, per esempio per affinare le prestazioni o, in modo più banale, per liberare un PV quando si deve estrarre il corrispondente disco fisico dal VG (per spostarlo su un altro VG o per rimuoverlo del tutto dal LVM). Le pagine di manuale che descrivono i comandi sono di solito chiare e dettagliate. Un buon punto di partenza è la pagina di manuale lvm(8).

12.1.3. RAID o LVM?

RAID e LVM portano entrambi indiscutibili vantaggi quando si abbandona il caso semplice di un computer desktop con un solo disco fisso in cui il modello d'uso non cambia nel tempo. Tuttavia, RAID e LVM vanno in due direzioni differenti, con scopi distinti ed è giusto chiedersi quale dei due adottare. La risposta più appropriata ovviamente dipenderà dai requisiti attuali e da quelli prevedibili in futuro.

Ci sono alcuni casi semplici in cui il problema non si pone. Se il requisito è di salvaguardare i dati da guasti hardware, allora ovviamente si configurerà RAID su un array ridondante di dischi, in quanto LVM non risolve questo problema. Se, d'altro canto, c'è bisogno di uno schema flessibile per memorizzare dati dove i volumi siano indipendenti dalla disposizione fisica dei dischi, il RAID non è molto d'aiuto e LVM è la scelta naturale.

NOTA Se importanto le performance…

Se la velocità di input/output è essenziale, soprattutto in termini di tempi di accesso, l'utilizzo di LVM e/o RAID in uno delle tante combinazioni può avere un certo impatto sulle prestazioni, e questo può influenzare le decisioni su quale per scegliere. Tuttavia, queste differenze di prestazioni sono molto minori, e saranno misurabili solo in pochi casi di utilizzo. Se si cercano maggiori performance, il miglior modo per ottenerle sarebbe quello di utilizzare supporti di memorizzazione non-rotanti (solid-state drives o SSDs); il costo per megabyte è superiore a quello degli hard disk standard, e la loro capacità è di solito più piccola, ma forniscono prestazioni eccellenti per accessi casuali. Se il modello di utilizzo include molte operazioni di input/output sparse in tutto il filesystem, ad esempio per i database in cui sono regolarmente in esecuzione query complesse, allora il vantaggio di una loro esecuzione su un SSD supera di gran lunga qualunque cosa si potrebbe avere scegliendo LVM su RAID o il contrario. In queste situazioni, la scelta dovrebbe essere determinata da altre considerazioni più che dalla velocità pura, dal momento che l'aspetto delle prestazioni è più facilmente gestitibile utilizzando gli SSD.

Il terzo importante caso d'uso è quando si vuole semplicemente aggregare due dischi in un unico volume, per motivi di prestazioni o per avere un unico file system più grande di qualunque disco disponibile. Questo caso può essere affrontato sia utilizzando un RAID-0 (o addirittura un linear-RAID) sia tramite un volume LVM. In questa situazione, senza considerare ulteriori vincoli (per esempio, mantenere la coerenza con altre macchine se queste usano solo RAID), la configurazione preferita di solito sarà LVM. L'impostazione iniziale è appena più complessa, ma questo leggero aumento di complessità è più che compensato dall'aumentata flessibilità di LVM nel caso i requisiti cambiassero o si dovessero aggiungere nuovi dischi.

Poi, ovviamente, c'è il caso d'uso veramente interessante, in cui il sistema di memorizzazione deve essere reso sia resistente ai guasti hardware sia flessibile in termini di allocazione di volumi. Né RAID né LVM possono di per sé soddisfare entrambi i requisiti; ciò non è un problema, perché qui si possono usare entrambi contemporaneamente, o piuttosto, uno sopra l'altro. Lo schema che è diventato lo standard da quando RAID e LVM hanno raggiunto la maturità è di assicurare prima di tutto la ridondanza dei dati raggruppando i dischi in un piccolo numero di array RAID e usare questi array RAID come volumi fisici LVM; a questo punto si creano i file system tramite partizioni logiche all'interno di questi LV. Il punto di forza di questa impostazione è che quando un disco si guasta si deve ricostruire solo un piccolo numero di array RAID, limitando così il tempo speso dall'amministratore per il ripristino.

Si faccia un esempio concreto: il dipartimento di pubbliche relazioni alla Falcot Corp ha bisogno di una postazione di lavoro per l'editing video, ma il bilancio del dipartimento non permette di investire in hardware di fascia alta per tutti i componenti. Si prende la decisione di favorire l'hardware specifico per la natura grafica del lavoro (monitor e scheda video) e di rimanere con hardware generico per quanto riguarda la memorizzazione dei dati. Tuttavia, come è ben noto, il video digitale ha dei requisiti particolari per la memorizzazione dei suoi dati: la quantità di dati da memorizzare è grande e il tasso di throughput per leggere e scrivere questi dati è importante per le prestazioni globali del sistema (più del tipico tempo di accesso, per esempio). Questi vincoli devono essere soddisfatti con hardware generico, in questo caso due dischi SATA da 300 GB; i dati del sistema devono inoltre essere resi resistenti ai guasti hardware, così come parte dei dati degli utenti. I video elaborati devono infatti essere al sicuro, ma i provini durante le modifiche sono meno critici, in quanto sono ancora sui nastri.

RAID-1 e LVM vengono combinati per soddisfare questi vincoli. I dischi sono collegati a due controller SATA diversi per ottimizzare l'accesso in parallelo e ridurre i rischi di guasto simultaneo e quindi appaiono come sda e sdc. Vengono partizionati in modo identico secondo il seguente schema:

# fdisk -l /dev/sda

Disk /dev/sda: 300 GB, 300090728448 bytes, 586114704 sectors
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: dos
Disk identifier: 0x00039a9f

Device    Boot     Start       End   Sectors Size Id Type
/dev/sda1 *         2048   1992060   1990012 1.0G fd Linux raid autodetect
/dev/sda2        1992061   3984120   1992059 1.0G 82 Linux swap / Solaris
/dev/sda3        4000185 586099395 582099210 298G 5  Extended
/dev/sda5        4000185 203977305 199977120 102G fd Linux raid autodetect
/dev/sda6      203977306 403970490 199993184 102G fd Linux raid autodetect
/dev/sda7      403970491 586099395 182128904  93G 8e Linux LVM

Le prime partizioni di entrambi i dischi (circa 1 GB) sono assemblate in un volume RAID-1, md0. Questo mirror è usato direttamente per contenere il file system di root.
Le partizioni sda2 e sdc2 sono usate come partizioni di swap, dando un totale di 2 GB di spazio di swap. Con 1 GB di RAM, la postazione di lavoro ha una quantità sufficiente di memoria disponibile.
Le partizioni sda5 e sdc5, così come sda6 e sdc6, sono assemblate in due nuovi volumi RAID-1 di circa 100 GB l'uno, md1 e md2. Entrambi questi mirror sono inizializzati come volumi fisici per LVM e assegnati al gruppo di volume vg_raid. Questo VG contiene circa 200 GB di spazio sicuro.
Le rimanenti partizioni, sda7 e sdc7, sono usate direttamente come volumi fisici e assegnate a un altro VG chiamato vg_bulk, che quindi ha all'incirca 200 GB di spazio.

Una volta creati i VG, possono essere partizionati in modo molto flessibile. Bisogna ricordarsi che i LV creati in vg_raid saranno preservati anche in caso di guasto di uno dei dischi, cosa che non succede per i LV creati in vg_bulk; d'altro canto, quest'ultimo sarà allocato in parallelo su entrambi i dischi, il che consente velocità di lettura o scrittura maggiori per file grandi.

Si creeranno quindi i LV lv_usr, lv_var e lv_home su vg_raid, per ospitare i filesystem corrispondenti; un altro grande LV, lv_movies, verrà usato per ospitare le versioni definitive dei filmati dopo l'elaborazione. L'altro VG verrà suddiviso in un grande lv_rushes, per ospitare i dati che provengono direttamente dalle videocamere digitali e un lv_tmp per i file temporanei. La posizione dell'area di lavoro è meno ovvia: pur essendo necessarie delle buone prestazioni per quel volume, vale la pena rischiare di perdere il lavoro se un disco si guasta durante una sessione di elaborazione? A seconda della risposta a questa domanda, il relativo LV sarà creato su uno dei due VG.

Adesso è presente un certo livello di ridondanza per i dati importanti e molta flessibilità su come viene diviso lo spazio disponibile fra le applicazioni. Se in seguito si dovesse installare nuovo software (ad esempio per elaborare degli spezzoni audio), il LV che ospita /usr/ può essere allargato senza fatica.

NOTA Perché tre volumi RAID-1?

Si sarebbe potuto impostare un unico volume RAID-1 come volume fisico per vg_raid. Perché dunque crearne tre?

Il motivo della prima suddivisione (md0 separato dagli altri) è la sicurezza dei dati: i dati scritti su entrambi gli elementi di un mirror RAID-1 sono esattamente gli stessi ed è quindi possibile aggirare il livello RAID e montare uno dei dischi direttamente. In caso di un bug nel kernel, per esempio, o se i metadati LVM si rovinano, è comunque possibile avviare un sistema minimale per avere accesso ai dati critici come la struttura dei dischi nei volumi RAID e LVM; i metadati possono poi essere ricostruiti e i file resi di nuovo accessibili, cosicché il sistema può essere riportato al suo stato normale.

Il motivo della seconda suddivisione (md1 separato da md2) è meno evidente e più collegato all'accettazione del fatto che il futuro è incerto. Quando la postazione di lavoro viene assemblata all'inizio, i requisiti di spazio su disco non sono necessariamente noti con precisione assoluta; inoltre questi possono evolvere nel tempo. In questo caso, non si può conoscere in anticipo gli effettivi requisiti di spazio per gli spezzoni di video ed i video completi. Se un particolare video necessita di una grande quantità di spezzoni e il VG dedicato ai dati ridondanti è pieno per meno della metà, si può riutilizzare parte del suo spazio non usato. Si può rimuovere uno dei volumi fisici, ad esempio md2, da vg_raid e assegnarlo direttamente a vg_bulk (se la durata attesa dell'operazione è abbastanza breve da poter convivere con il temporaneo calo di prestazioni) o disfare l'impostazione RAID su md2 e integrare le sue componenti sda6 e sdc6 nel VG grande (che cresce di 200 GB invece di 100 GB); il volume logico lv_rushes può quindi essere allargato secondo necessità.