Capitolo 20. Il Gestore di Volumi Vinum

I plex possono contenere molteplici sottodischi distribuiti tra tutti i drive presenti nella configurazione di Vinum, questo permette alla dimensione dei plex, e quindi anche dei volumi, di non essere limitata dalla dimensione dei singoli dischi.

Vinum implementa il mirroring collegando più plex allo stesso volume, ogni plex contiene la rappresentazione di tutti i dati del volume. Un volume può contenere da uno ad otto plex.

Nonostante un plex rappresenti i dati di un volume per intero, è possibile che parti di questa rappresentazione vengano a mancare o per scelta (non definendo dei sottodischi per alcune parti del plex) o per accidente (come risultato della rottura del disco che le conteneva). Finché almeno un plex contiene i dati di tutto lo spazio d’indirizzamento del volume, il volume stesso è completamente funzionale.

Vinum implementa sia la concatenazione che lo striping al livello di plex:

La versione di Vinum distribuita con FreeBSD 12.0 implementa due tipi di plex:

La Organizzazione dei Plex Vinum riassume vantaggi e svantaggi di ogni tipo di organizzazione dei plex.

Il file di configurazione descrive singoli oggetti Vinum. La definizione di un semplice volume potrebbe essere:

Questo file descrive quattro oggetti Vinum:

Dopo aver elaborato questo file, vinum(8) produce il seguente output:

Questo output mostra il formato di elenco breve di vinum(8), che è rappresentato graficamente nella Un Semplice Volume Vinum.

Questa figura e quelle che seguono rappresentano un volume contenente dei plex che a loro volta contengono dei sottodischi. In questo semplice esempio il volume contiene un plex e il plex contiene un sottodisco.

Questo particolare volume non ha specifici vantaggi su una convenzionale partizione di disco. Contiene un singolo plex, quindi non è ridondante. Il plex contiene un solo sottodisco, quindi non c’è differenza nell’immagazzinamento dei dati. Le sezioni seguenti mostrano vari metodi di configurazione più interessanti.

Il mirroring può aumentare, in un volume, la resistenza alle rotture. Quando si definisce un volume in mirroring è importante assicurarsi che i sottodischi di ogni plex siano su dischi differenti, in modo che la rottura di un drive non blocchi entrambi i plex. La seguente configurazione mostra un volume in mirroring:

In questo esempio non è necessario specificare nuovamente la definizione del drive a, dato che Vinum mantiene traccia di tutti gli oggetti nel suo database di configurazione. Dopo aver elaborato questa definizione, la configurazione appare così:

Un Volume Vinum in Mirroring mostra la struttura graficamente.

In questo esempio ogni plex contiene l’intero spazio di indirizzamento di 512 MB. Come nel precedente esempio ogni plex contiene un solo sottodisco.

Il volume in mirroring dell’esempio precedente è più resistente alle rotture di un volume non in mirroring, ma le sue prestazioni sono inferiori: ogni scrittura sul volume richiede una scrittura su ognuno dei drive, utilizzando quindi una maggior frazione della banda passante totale dei dischi. Considerazioni sulle prestazioni portano ad un differente approccio: al posto del mirroring, i dati vengono posti sul maggior numero di dischi possibile utilizzando lo striping. La seguente configurazione mostra un volume con un plex in striping su quattro dischi:

Come prima non è necessario definire i drive che Vinum già conosce. Dopo aver elaborato queste definizioni la configurazione appare così:

Questo volume è rappresentato nella Un Volume Vinum in Striping. L’intensità del colore delle strisce indica la posizione all’interno dello spazio di indirizzamento del plex: le più chiare all’inizio, le più scure alla fine.

Con hardware a sufficenza è possibile creare volumi con miglioramenti sia nella resistenza alle rotture che nelle prestazioni, comparati alle normali partizioni UNIX®. Una tipica configurazione potrebbe essere:

I sottodischi del secondo plex sono spostati di due posti rispetto a quelli del primo plex: questo aumenta le probabilità che le scritture non utilizzino lo stesso sottodisco anche nel caso in cui un trasferimento utilizzi entrambi i drive.

La Un Volume Vinum in Mirroring e Striping rappresenta la struttura di questo volume.

I volumi appaiono al sistema identici ai dischi, con un’eccezione. Differentemente dai dischi UNIX®, Vinum non partiziona i volumi, che quindi non contengono una tabella delle partizioni. Questo ha reso necessario modificare alcuni programmi di utilità del disco, tra cui newfs(8), che precedentemente cercava di interpretare l’ultima lettera di un volume Vinum come un identificatore di partizione. Ad esempio un disco potrebbe avere un nome come /dev/ad0a o /dev/da2h. Questi nomi rappresentano la prima partizione (a) del primo (0) disco IDE (ad) e l’ottava partizione (h) del terzo (2) disco SCSI (da), rispettivamente. Al contrario un volume Vinum potrebbe essere chiamato /dev/vinum/concat, un nome che non ha alcuna relazione con nomi di partizione.

Normalmente newfs(8) interpreta il nome del disco e si lamenta se non riesce a comprenderlo. Per esempio:

Per poter creare un file system su questo volume usa newfs(8) con l’opzione -v:

Vinum immagazzina le informazioni sulla configurazione dei dischi essenzialmente nella stessa forma dei file di configurazione. Quando legge il database di configurazione Vinum riconosce un numero di parole chiave che non sono permesse nei file di configurazione, ad esempio un file di configurazione del disco potrebbe contenere il seguente testo:

Le ovvie differenze sono qua la presenza di informazioni esplicite sulle locazioni e sulla nomenclatura (entrambe permesse, ma scoraggiate, all’utente) e le informazioni sugli stati (che non sono disponibili all’utente). Vinum non immagazzina informazioni sui drive tra le informazioni della configurazione: trova i drive scandendo le partizioni dei dischi configurati alla ricerca di un’etichetta Vinum. Questo permette a Vinum di identificare i drive correttamente anche se gli è stato assegnato un differente codice identificativo di drive UNIX®.

Ci sono varie misure da prendere per fare in modo che questo accada:

Dato che il codice di avvio di FreeBSD è attualmente di soli 7.5 KB ed è già appesantito dalla lettura di file (come /boot/loader) da un filesystem UFS, è semplicemente impossibile insegnargli anche a leggere le strutture interne di Vinum in modo da fargli leggere i dati della configurazione di Vinum per ricavarne gli elementi del volume di boot stesso. Sono quindi necessari alcuni trucchi per dare al codice di avvio l’illusione di una partizione "a" standard contenente il filesystem di root.

Perché questo sia anche solo possibile, il volume di root deve rispondere ai seguenti requisiti:

Da notare che è desiderabile e possibile avere plex multipli, contenente ognuno una replica del filesystem root. Il processo di avvio, però, usa solo una di queste repliche per trovare i file necessario all’avvio, fino a quando il kernel monta il filesystem di root stesso. Ogni singolo sottodisco in questi plex avrà quindi bisogno di una propria partizione "a" illusoria, affinché la periferica relativa possa essere avviabile. Non è strettamente necessario che ognuna di queste finte partizioni "a" sia locato con lo stesso spiazzamento all’interno della propria periferica, rispetto alle periferiche contenenti gli altri plex del volume. È comunque probabilmente una buona idea creare i volumi Vinum in modo che le periferiche in mirror siano simmetriche, per evitare confusione.

Per poter configurare queste partizioni "a", in ogni periferica contenente parte del volume di root, bisogna fare le seguenti cose:

Bisogna ricordarsi che tutte le informazioni contenute nei file di controllo devono essere relative al filesystem di root nel volume Vinum che, quando si imposta un nuovo volume di root Vinum, potrebbe non coincidere con quello del filesystem root attualmente attivo. In particolare bisogna stare attenti ai file /etc/fstab e /boot/loader.conf.

Al seguente riavvio il sistema dovrebbe ricavare le informazioni di controllo appropriate dal filesystem di root Vinum e agire di consequenza. Alla fine del processo di inizializzazione del kernel, dopo che tutte le periferiche sono state annunciate, l’avvertimento principale che conferma il successo dell’avvio è un messaggio simile a questo:

Dopo aver creato il volume di root Vinum, vinum l -rv root dovrebbe produrre qualcosa di simile a:

I valori su cui fare caso sono il 135680 dello spiazzamento (relativo alla partizione /dev/da0h). Questo si traduce in 265 blocchi da 512 byte nei termini di disklabel. /dev/da1h, contenente la seconda replica del volume di root, ha una configurazione simmetrica.

La disklabel per queste periferiche dovrebbe essere simile a questa:

Si può notare che il parametro "size" per la finta partizione "a" corrisponde al valore di cui abbiamo parlato prima, mentre il parametro "offset" è la somma dello spiazzamento all’interno della partizione Vinum "h" e lo spiazzamento all’interno della periferica (o slice). Questa è una tipica configurazione necessaria per evitare il problema descritto in Non si Carica Niente, l’Avvio va in Panico. Si può anche notare che l’intera partizione "a" è completamente contenuta dalla partizione "h", che contiene tutti i dati Vinum per questa periferica.

Notate che in questo esempio l’intera periferica è dedicata a Vinum e non c’è spazio per partizioni pre-Vinum, dato che questo disco è stato configurato da nuovo per il solo scopo di far parte di una configurazione Vinum.

Se qualcosa va storto, serve un modo per tornare in una situazione di normalità. Segue una lista di alcuni tipici problemi, completi di soluzione.

In FreeBSD 4.X alcune funzioni interne necessarie a Vinum per poter trovare automaticamente tutti i dischi non sono presenti e il codice che ricava l’ID interno della periferica di root non è abbastanza intelligente da gestire automaticamente nomi come /dev/vinum/root, quindi le cose vengono fatte in modo un po' diverso.

Bisogna dire esplicitamente a Vinum quali dischi controllare, usando una riga di /boot/loader.conf come la seguente:

È importante indicare tutti i drive che possono contenere dati Vinum. Non è un problema indicare drive di troppo, non è neanche necessario aggiungere esplicitamente ogni slice e/o partizione, dato che Vinum cercherà header Vinum in tutte le slice e partizioni dei drive nominati.

Dato che le procedure utilizzate per interpretare il nome del filesystem di root e derivarne l’ID di periferica (numeri maggiore e minore) sono adatte per gestire solo nomi "classici" di periferica come /dev/ad0s1a, non riescono a capire nomi di volumi root come /dev/vinum/root. Per questo motivo Vinum ha bisogno di pre-impostare durante la propria inzializzazione il parametro kernel interno che contiene l’ID della periferica di root. Questo viene fatto indicando il nome del volume di root nella variabile di avvio vinum.root. La riga di /boot/loader.conf adatta per fare questo è simile alla seguente:

Quando l’inizializzazione del kernel cerca di trovare la periferica root da montare controlla se qualche modulo del kernel ha già pre-inizializzato il parametro kernel apposito; se questo è il caso e la periferica che dice di essere la periferica di root ha il numero maggiore e minore corrispondenti al driver come trovato dal nome della periferica di root passata (ovvero "vinum", nel nostro caso), userà l’ID di periferica pre-allocato, anziché cercar di trovarne uno da solo. In tal modo durante l’usuale avvio automatico può continuare a montare il volume di root Vinum per il filesystem di root.

Bisogna comunque notare che anche quando boot -a richiede di inserire manualmente il nome della periferica di root tale nome non può essere intepretato nel caso sia un nome riferito a un volume Vinum. Se è inserito un nome di periferica non riferito a una periferica Vinum, la non corrispondenza col numero maggiore pre-allocato del parametro di root e del driver ricavato dal nome farà sì che la procedura utilizzi il normale interprete, quindi una stringa come ufs:da0d funzionerà come previsto. Da notare che se questo fallisce non si può più provare una stringa come ufs:vinum/root, dato che non verrebbe interpretata; l’unica via di uscita è riavviare e ripartire da zero. (Alla richiesta di "askroot", la parte iniziale /dev/ può sempre essere omessa.)