diff options
Diffstat (limited to 'it_IT.ISO8859-15/books/handbook/vinum/chapter.xml')
| -rw-r--r-- | it_IT.ISO8859-15/books/handbook/vinum/chapter.xml | 1465 |
1 files changed, 1465 insertions, 0 deletions
diff --git a/it_IT.ISO8859-15/books/handbook/vinum/chapter.xml b/it_IT.ISO8859-15/books/handbook/vinum/chapter.xml new file mode 100644 index 0000000000..426a61e26a --- /dev/null +++ b/it_IT.ISO8859-15/books/handbook/vinum/chapter.xml @@ -0,0 +1,1465 @@ +<?xml version="1.0" encoding="iso-8859-15" standalone="no"?> +<!-- + The FreeBSD Italian Documentation Project + + $FreeBSD$ + Original revision: 1.37 +--> + +<chapter id="vinum-vinum"> + <chapterinfo> + <authorgroup> + <author> + <firstname>Greg</firstname> + + <surname>Lehey</surname> + + <contrib>Originariamente scritto da </contrib> + </author> + </authorgroup> + </chapterinfo> + + <title>Il Gestore di Volumi Vinum</title> + + <sect1 id="vinum-synopsis"> + <title>Sinossi</title> + + <para>Qualunque siano i dischi che hai, ci sono sempre dei problemi + potenziali:</para> + + <itemizedlist> + <listitem> + <para>Potrebbero essere troppo piccoli.</para> + </listitem> + + <listitem> + <para>Potrebbero essere troppo lenti.</para> + </listitem> + + <listitem> + <para>Potrebbero essere troppo inaffidabili.</para> + </listitem> + </itemizedlist> + + <para>Un modo in cui alcuni utenti salvaguardano sè stessi contro + questi problemi è attraverso l'uso di dischi multipli, e + talvolta ridondanti.</para> + + <para>In aggiunta a supportare diverse schede e controller per sistemi RAID + hardware, il sistema FreeBSD base include il gestore di volumi Vinum, un + driver di dispositivo a blocchi che implementa dischi virtuali.</para> + + <para>Vinum fornisce più flessibilità, prestazioni, e + affidabilità rispetto all'archiviazione su disco tradizionale e + implementa i modelli RAID-0, RAID-1, e RAID-5 sia singolarmente che in + combinazione.</para> + + <para>Questo capitolo fornisce una panoramica sui potenziali problemi + dell'archiviazione su disco tradizionale e un'introduzione al gestore + di volumi Vinum.</para> + </sect1> + + <sect1 id="vinum-intro"> + <title>Dischi Troppo Piccoli</title> + + <indexterm><primary>Vinum</primary></indexterm> + <indexterm> + <primary>RAID</primary> + <secondary>software</secondary> + </indexterm> + + <para><emphasis>Vinum</emphasis> è un <emphasis>Volume + Manager</emphasis>, ovvero un driver virtuale di disco che si occupa dei + tre problemi indicati nella sinossi. Diamo un'occhiata in dettaglio a + questi problemi, per i quali sono state proposte e implementate varie + soluzioni.</para> + + <para>I dischi stanno diventando sempre più grandi, ma questo + è vero anche per le necessità di spazio per i dati. Spesso + sentirai il bisogno di avere un file system più grande dei dischi + che possiedi. Effettivamente questo problema non è così + grave come lo era dieci anni fa, ma è sempre presente. Alcuni + sistemi risolvono la questione creando un dispositivo astratto che + ripartisce i suoi dati su vari dischi.</para> + </sect1> + + <sect1 id="vinum-access-bottlenecks"> + <title>Colli di Bottiglia nell'Accesso</title> + + <para>I moderni sistemi hanno frequentemente la necessità di + accedere ai dati in modo concorrente. Ad esempio, un grande server FTP o + HTTP può avere migliaia di sessioni concorrenti e molteplici + connessioni da 100 Mbit/s verso il mondo esterno, ben oltre il + transfer rate (velocità di trasferimento) che la maggior parte dei + dischi può sostenere.</para> + + <para>I dischi odierni possono trasferire sequenzialmente dati fino a + 70 MB/s, ma questo valore ha poca importanza in un ambiente dove + molti processi indipendenti accedono al disco, in quanto raggiungerebbero + solo una frazione di quella velocità. In questi casi è + più interessante vedere il problema dal punto di vista del + sottosistema dischi: il parametro importante è il carico che il + trasferimento pone sul sottosistema, in altre parole il tempo per cui il + trasferimento occupa i dischi necessari per lo stesso.</para> + + <para>In ogni trasferimento da disco il drive deve prima posizionare le + testine, poi aspettare che il primo settore passi sotto la testina di + lettura e solo dopo può effettuare il trasferimento. Queste azioni + possono essere considerate atomiche: non ha alcun senso + interromperle.</para> + + <para><anchor id="vinum-latency"/>Considera un tipico trasferimento di circa + 10 kB: l'attuale generazione di dischi ad alte prestazioni può + posizionare le testine in circa 3,5 ms. I dischi più veloci + ruotano a 15.000 rpm, quindi la latenza media rotazionale (mezzo + giro) è di 2 ms. A 70 MB/s, il trasferimento in + sé occupa circa 150 μs, quasi nulla in confronto al tempo + di posizionamento. In questo caso il transfer rate effettivo può + scendere fino a poco oltre 1 MB/s e questo è chiaramente molto + dipendente dalla dimensione del trasferimento.</para> + + <para>La tradizionale e ovvia soluzione a questo collo di bottiglia è + <quote>più assi</quote>: invece di usare un grande disco si usano + molti piccoli dischi con la stessa dimensione totale. Ogni disco è + capace di posizionarsi e trasferire dati indipendentemente quindi la + velocità effettiva aumenta di un fattore vicino al numero di dischi + usati.</para> + + <para>L'esatto fattore di miglioramento è, ovviamente, più + piccolo del numero di dischi: benché ogni disco sia capace di + trasferire in parallelo non c'è modo di assicurare che le richieste + siano distribuite uniformemente tra tutti i dischi. Inevitabilmente il + carico su uno dei dischi è più alto che sugli altri.</para> + + <indexterm><primary>concatenazione dei dischi</primary></indexterm> + <indexterm> + <primary>Vinum</primary> + <secondary>concatenazione</secondary> + </indexterm> + + <para>L'uniformità della distribuzione del carico sui dischi è + fortemente dipendente dal modo in cui i dati sono condivisi tra i dischi + stessi. Nella seguente discussione è conveniente pensare allo + spazio di immagazzinamento come se fosse diviso in un gran numero di + settori identificati da un indirizzo numerico, come pagine in un libro. + Il metodo più ovvio è di dividere il disco virtuale in + gruppi di settori consecutivi della dimensione dei dischi fisici e + immagazzinarli in questa maniera, come strappare un grosso libro in + piccole sezioni. Questo metodo è chiamato + <emphasis>concatenazione</emphasis> e ha il vantaggio di non avere + particolari richieste sulla dimensione degli specifici dischi. + Funziona bene quando l'accesso al + disco virtuale è ben ripartito tra tutto il suo spazio di + indirizzamento. Quando l'accesso è concentrato in una piccola area + il miglioramento è meno marcato. La <xref linkend="vinum-concat"/> + illustra la sequenza in cui le unità di immagazzinamento sono + allocate nell'organizzazione concatenata.</para> + + <para> + <figure id="vinum-concat"> + <title>Organizzazione Concatenata</title> + + <graphic fileref="vinum/vinum-concat"/> + </figure> + </para> + + <indexterm><primary>striping dei dischi</primary></indexterm> + <indexterm> + <primary>Vinum</primary> + <secondary>striping</secondary> + </indexterm> + <indexterm> + <primary>RAID</primary> + </indexterm> + <indexterm> + <primary>RAID</primary> + <secondary>livello 0</secondary> + </indexterm> + <indexterm><primary>RAID-0</primary></indexterm> + + <para>Un metodo alternativo è dividere lo spazio di indirizzamento in più + piccole componenti di egual dimensione e immagazzinarle sequenzialmente su + differenti dispositivi. Per esempio i primi 256 settori potrebbero essere + immagazzinati sul primo disco, i seguenti 256 settori sul disco seguente e + così via. Dopo aver immagazzinato i dati sull'ultimo disco il + processo si ripete finché i dischi non sono pieni. Questo + mappamento è chiamato <emphasis>striping</emphasis> (letteralmente + "a bande") o <acronym>RAID-0</acronym> + <footnote> + <para><acronym>RAID</acronym> significa <emphasis>Redundant Array of + Inexpensive Disks</emphasis> (insieme ridondante di dischi non + costosi) e offre varie forme di tolleranza ai problemi. Nel caso del + <acronym>RAID-0</acronym> il termine è leggermente fuorviante: + in effetti non dà alcuna ridondanza.</para> + </footnote>. + Lo striping richiede qualche sforzo aggiuntivo per localizzare i dati e + può causare carico di I/O aggiuntivo quando il trasferimento + è distribuito tra vari dischi, ma aiuta il carico a essere ben + distribuito tra i vari dischi. La <xref linkend="vinum-striped"/> illustra + la sequenza in cui i blocchi di dati sono allocati nell'organizzazione in + striping.</para> + + <para> + <figure id="vinum-striped"> + <title>Organizzazione in Striping</title> + + <graphic fileref="vinum/vinum-striped"/> + </figure> + </para> + </sect1> + + <sect1 id="vinum-data-integrity"> + <title>Integrità dei Dati</title> + + <para>L'ultimo problema dei dischi attuali è che sono inaffidabili. + Benché la loro affidabilità sia aumentata tremendamente + durante gli ultimi anni sono tuttora il componente di un server che ha + la maggior probabilità di rompersi. Quando succede i risultati + possono essere catastrofici: rimpiazzare un disco rotto e riempirlo dei + dati originari può richiedere giorni.</para> + + <indexterm><primary>mirroring dei dischi</primary></indexterm> + <indexterm> + <primary>Vinum</primary> + <secondary>mirroring</secondary> + </indexterm> + <indexterm> + <primary>RAID</primary> + <secondary>livello 1</secondary> + </indexterm> + <indexterm><primary>RAID-1</primary></indexterm> + + <para>Il metodo tradizionale per affrontare questo problema si chiama + <emphasis>mirroring</emphasis> (letteralmente "specchiatura") e consiste + nel tenere due copie dei dati su hardware fisici differenti. Con + l'avvento dei livelli <acronym>RAID</acronym> questa tecnica è + stata chiamata <acronym>RAID</acronym> di livello 1 o + <acronym>RAID-1</acronym>. Ogni scrittura su disco scrive in entrambe le + locazioni; una lettura può essere soddisfatta da entrambi quindi se + un disco si rompe i dati sono sempre disponibili sull'altro disco.</para> + + <para>Il mirroring ha due problemi:</para> + + <itemizedlist> + <listitem> + <para>Il prezzo. Richiede il doppio dello spazio di + immagazzinamento delle soluzioni non ridondanti.</para> + </listitem> + + <listitem> + <para>L'impatto sulle prestazioni. La scrittura deve essere + compiuta su entrambi i dischi quindi la banda occupata raddoppia. + Le letture non soffrono di problemi sulle prestazioni: possono + perfino essere più veloci.</para> + </listitem> + </itemizedlist> + + <indexterm> + <primary>Vinum</primary> + <secondary>striping con parità</secondary> + </indexterm> + <para><indexterm><primary>RAID-5</primary></indexterm> + + Una soluzione alternativa è la + <emphasis>parità</emphasis>, implementata nel + <acronym>RAID</acronym> di livello 2, 3, 4 e 5. Di questi, il + <acronym>RAID-5</acronym> è il più interessante. La sua + implementazione in Vinum è una variante dell'organizzazione in + striping che dedica un blocco di ogni banda alla parità degli + altri blocchi. Per come è implementato in Vinum, ogni blocco + <acronym>RAID-5</acronym> è simile a un blocco in striping, con + la differenza che implementa il <acronym>RAID-5</acronym> includendo un + blocco di parità per ogni banda. Come richiesto dal + <acronym>RAID-5</acronym> la locazione di questi blocchi di parità + cambia da ogni banda alla successiva. I numeri nei blocchi dati indicano + il numero dei blocchi relativi.</para> + + <para> + <figure id="vinum-raid5-org"> + <title>Organizzazione RAID-5</title> + + <graphic fileref="vinum/vinum-raid5-org"/> + </figure> + </para> + + <para>Comparandolo al mirroring, il <acronym>RAID-5</acronym> ha il + vantaggio di richiedere molto meno spazio di immagazzinamento. La + velocità di lettura è simile all'organizzazione in + striping, ma in scrittura l'accesso è significativamente più + lento, circa il 25% della performance di lettura. Se uno dei dischi si + rompe l'aggregato continua a lavorare con performance peggiorate: la + lettura da uno dei dischi rimanenti continua normalmente, ma la lettura + dal disco rotto è ricalcolata dai corrispondenti blocchi dei + dischi rimanenti.</para> + </sect1> + + <sect1 id="vinum-objects"> + <title>Oggetti Vinum</title> + + <para>Per risolvere questi problemi Vinum implementa una categoria di + oggetti a quattro livelli:</para> + + <itemizedlist> + <listitem> + <para>L'oggetto più visibile è il disco virtuale, + chiamato <emphasis>volume</emphasis>. I volumi hanno essenzialmente + le stesse proprietà di un disco &unix;, benché ci + sia qualche differenza minore. Non hanno limiti di dimensione.</para> + </listitem> + + <listitem> + <para>I volumi sono composti da <emphasis>plex</emphasis>, ognuno dei + quali rappresenta il completo spazio di indirizzamento del volume. + È quindi questo il livello della gerarchia che gestisce la + ridondanza dei dati. Pensa ai plex come a singoli dischi collegati + tra loro in mirroring, ognuno contenente gli stessi dati.</para> + </listitem> + + <listitem> + <para>Dato che Vinum vive all'interno del framework &unix; di + immagazzinamento dei dati sarebbe possibile utilizzare le partizioni + &unix; come blocchi basilari per costruire i plex multidisco, ma + questo approccio sarebbe in effetti troppo poco flessibile: i dischi + &unix; possono avere solo un limitato numero di partizioni; al + contrario Vinum suddivide le singole partizioni &unix; + (<emphasis>drive</emphasis>, ovvero dischi) in aree contigue chiamate + <emphasis>subdisks</emphasis> (sottodischi), che sono a loro volta + utilizzati come elementi per costruire i plex.</para> + </listitem> + + <listitem> + <para>I sottodischi risiedono su <emphasis>drive</emphasis> Vinum, che + attualmente sono partizioni &unix;. I drive Vinum possono + contenere qualsiasi quantità di sottodischi. Con l'eccezione + di una piccola area all'inizio del drive, che è usata per + immagazzinare informazioni sulla configurazione e sullo stato, + l'intero drive è disponibile per l'immagazzinamento + dei dati.</para> + </listitem> + </itemizedlist> + + <para>La sezione seguente descrive come gli oggetti sopra discussi possano + dare le funzionalità richieste.</para> + + <sect2> + <title>Considerazioni sulle Dimensioni dei Volumi</title> + + <para>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.</para> + </sect2> + + <sect2> + <title>Immagazzinamento Ridondante dei Dati</title> + + <para>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.</para> + + <para>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.</para> + </sect2> + + <sect2> + <title>Considerazioni sulle Prestazioni</title> + + <para>Vinum implementa sia la concatenazione che lo striping al livello di + plex:</para> + + <itemizedlist> + <listitem> + <para>Un <emphasis>plex concatenato</emphasis> usa lo spazio di + indirizzamento di ogni sottodisco a turno.</para> + </listitem> + + <listitem> + <para>Un <emphasis>plex in striping</emphasis> suddivide i dati tra + ogni sottodisco. I sottodischi devono tutti avere la stessa + dimensione e devono essere presenti almeno due sottodischi + perché esista differenza da un plex concatenato.</para> + </listitem> + </itemizedlist> + </sect2> + + <sect2> + <title>Quale Organizzazione per i Plex?</title> + + <para>La versione di Vinum distribuita con FreeBSD &rel.current; + implementa due tipi di plex:</para> + + <itemizedlist> + <listitem> + <para>I plex concatenati, che sono i più flessibili: possono + contenere qualsiasi numero di sottodischi e questi possono avere + qualsiasi dimensione. Il plex può essere esteso aggiungendo + sottodischi. Richiede meno tempo di <acronym>CPU</acronym> di un + plex in striping, benché la differenza in carico di + <acronym>CPU</acronym> non sia misurabile. D'altro canto sono + più suscettibili agli hot spot (letteralmente <quote>zona + calda</quote>): ovvero situazioni in cui un disco è molto attivo mentre + gli altri sono fermi.</para> + </listitem> + + <listitem> + <para>Il più grande vantaggio dei plex in striping + (<acronym>RAID-0</acronym>) è la loro capacità di + ridurre gli hot spot: scegliendo una dimensione di striping ottimale + (circa 256 kB) si può ridistribuire il carico sui drive. + Gli svantaggi di questo approccio sono codice più complesso e + restrizioni sui sottodischi: devono essere tutti della stessa + dimensione, inoltre estendere il plex aggiungendo sottodischi + è così complicato che attualmente Vinum non lo + implementa. Vinum aggiunge anche un'ulteriore restrizione + elementare: un plex in striping deve contenere almeno due + sottodischi, dato che sarebbe altrimenti indistinguibile da un plex + concatenato.</para> + </listitem> + </itemizedlist> + + <para>La <xref linkend="vinum-comparison"/> riassume vantaggi e svantaggi + di ogni tipo di organizzazione dei plex.</para> + + <table id="vinum-comparison" frame="none"> + <title>Organizzazione dei Plex Vinum</title> + + <tgroup cols="5"> + <thead> + <row> + <entry>Tipo di plex</entry> + + <entry>Sottodischi minimi</entry> + + <entry>Sottodischi aggiungibili</entry> + + <entry>Dimensioni forzatamente uguali</entry> + + <entry>Applicazione</entry> + </row> + </thead> + + <tbody> + <row> + <entry>concatenato</entry> + + <entry>1</entry> + + <entry>sì</entry> + + <entry>no</entry> + + <entry>Immagazzinamento di grandi moli di dati con la massima + flessibilità e prestazioni moderate</entry> + </row> + + <row> + <entry>striping</entry> + + <entry>2</entry> + + <entry>no</entry> + + <entry>sì</entry> + + <entry>Alte prestazioni in casi di accessi altamente + concorrenti</entry> + </row> + </tbody> + </tgroup> + </table> + </sect2> + </sect1> + + <sect1 id="vinum-examples"> + <title>Alcuni Esempi</title> + + <para>Vinum mantiene un <emphasis>database della configurazione</emphasis> + che descrive gli oggetti del sistema conosciuti. Inizialmente l'utente + crea il database della configurazione da uno o più file di + configurazione, con l'aiuto del programma &man.vinum.8;. Vinum + immagazzina una copia del database di configurazione in ogni slice del + disco (che Vinum chiama <emphasis>device</emphasis>, ovvero + <quote>dispositivo</quote>) sotto il suo controllo. + Questo database è aggiornato a ogni cambio + di stato in modo che un riavvio possa recuperare accuratamente lo stato di + ogni oggetto Vinum.</para> + + <sect2> + <title>Il File di Configurazione</title> + + <para>Il file di configurazione descrive singoli oggetti Vinum. La + definizione di un semplice volume potrebbe essere:</para> + + <programlisting> drive a device /dev/da3h + volume myvol + plex org concat + sd length 512m drive a</programlisting> + + <para>Questo file descrive quattro oggetti Vinum:</para> + + <itemizedlist> + <listitem> + <para>La linea <emphasis>drive</emphasis> descrive la partizione del + disco (<emphasis>drive</emphasis>) e la sua locazione relativa + all'hardware sottostante. Gli viene assegnato il nome simbolico + <emphasis>a</emphasis>. Questa separazione dei nomi simbolici dai + nomi di dispositivo permette di muovere i dischi da una locazione ad + un'altra senza confusione.</para> + </listitem> + + <listitem> + <para>La linea <emphasis>volume</emphasis> descrive un volume. + L'unico attributo richiesto è il nome, in questo caso + <emphasis>myvol</emphasis>.</para> + </listitem> + + <listitem> + <para>La linea <emphasis>plex</emphasis> definisce un plex. + L'unico parametro richiesto è il tipo di organizzazione, in + questo caso <emphasis>concat</emphasis>. Non è necessario + un nome: il sistema genera un nome automaticamente a partire dal + nome del volume, aggiungendo un suffisso + <emphasis>.p</emphasis><emphasis>x</emphasis>, dove + <emphasis>x</emphasis> indica il numero del plex nel volume. Il + plex verrà quindi chiamato + <emphasis>myvol.p0</emphasis>.</para> + </listitem> + + <listitem> + <para>La linea <emphasis>sd</emphasis> descrive un sottodisco. + Le specifiche minime sono il nome del drive su cui immagazzinarlo e + la lunghezza del sottodisco. Come per i plex non è + necessario un nome: il sistema assegna automaticamente nomi + derivati dal nome del plex, aggiungendo il suffisso + <emphasis>.s</emphasis><emphasis>x</emphasis>, dove + <emphasis>x</emphasis> indica il numero del sottodisco nel plex, + quindi Vinum darà a questo sottodisco il nome di + <emphasis>myvol.p0.s0</emphasis>.</para> + </listitem> + </itemizedlist> + + <para>Dopo aver elaborato questo file, &man.vinum.8; produce il seguente + output:</para> + + <programlisting width="97"> &prompt.root; vinum -> <userinput>create config1</userinput> + Configuration summary + Drives: 1 (4 configured) + Volumes: 1 (4 configured) + Plexes: 1 (8 configured) + Subdisks: 1 (16 configured) + + D a State: up Device /dev/da3h Avail: 2061/2573 MB (80%) + + V myvol State: up Plexes: 1 Size: 512 MB + + P myvol.p0 C State: up Subdisks: 1 Size: 512 MB + + S myvol.p0.s0 State: up PO: 0 B Size: 512 MB</programlisting> + + <para>Questo output mostra il formato di elenco breve di &man.vinum.8;, + che è rappresentato graficamente nella + <xref linkend="vinum-simple-vol"/>.</para> + + <para> + <figure id="vinum-simple-vol"> + <title>Un Semplice Volume Vinum</title> + + <graphic fileref="vinum/vinum-simple-vol"/> + </figure> + </para> + + <para>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.</para> + + <para>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.</para> + </sect2> + + <sect2> + <title>Aumentare la Resistenza alle Rotture: il Mirroring</title> + + <para>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:</para> + + <programlisting> drive b device /dev/da4h + volume mirror + plex org concat + sd length 512m drive a + plex org concat + sd length 512m drive b</programlisting> + + <para>In questo esempio non è necessario specificare nuovamente la + definizione del drive <emphasis>a</emphasis>, dato che Vinum mantiene + traccia di tutti gli oggetti nel suo database di configurazione. Dopo + aver elaborato questa definizione, la configurazione appare + così:</para> + + + <programlisting width="97"> Drives: 2 (4 configured) + Volumes: 2 (4 configured) + Plexes: 3 (8 configured) + Subdisks: 3 (16 configured) + + D a State: up Device /dev/da3h Avail: 1549/2573 MB (60%) + D b State: up Device /dev/da4h Avail: 2061/2573 MB (80%) + + V myvol State: up Plexes: 1 Size: 512 MB + V mirror State: up Plexes: 2 Size: 512 MB + + P myvol.p0 C State: up Subdisks: 1 Size: 512 MB + P mirror.p0 C State: up Subdisks: 1 Size: 512 MB + P mirror.p1 C State: initializing Subdisks: 1 Size: 512 MB + + S myvol.p0.s0 State: up PO: 0 B Size: 512 MB + S mirror.p0.s0 State: up PO: 0 B Size: 512 MB + S mirror.p1.s0 State: empty PO: 0 B Size: 512 MB</programlisting> + + <para><xref linkend="vinum-mirrored-vol"/> mostra la struttura + graficamente.</para> + + <para> + <figure id="vinum-mirrored-vol"> + <title>Un Volume Vinum in Mirroring</title> + + <graphic fileref="vinum/vinum-mirrored-vol"/> + </figure> + </para> + + <para>In questo esempio ogni plex contiene l'intero spazio di + indirizzamento di 512 MB. Come nel precedente esempio ogni plex + contiene un solo sottodisco.</para> + </sect2> + + <sect2> + <title>Ottimizzazione delle Prestazioni</title> + + <para>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:</para> + + <programlisting> drive c device /dev/da5h + drive d device /dev/da6h + volume stripe + plex org striped 512k + sd length 128m drive a + sd length 128m drive b + sd length 128m drive c + sd length 128m drive d</programlisting> + + <para>Come prima non è necessario definire i drive che Vinum + già conosce. Dopo aver elaborato queste definizioni la + configurazione appare così:</para> + + <programlisting width="92"> Drives: 4 (4 configured) + Volumes: 3 (4 configured) + Plexes: 4 (8 configured) + Subdisks: 7 (16 configured) + + D a State: up Device /dev/da3h Avail: 1421/2573 MB (55%) + D b State: up Device /dev/da4h Avail: 1933/2573 MB (75%) + D c State: up Device /dev/da5h Avail: 2445/2573 MB (95%) + D d State: up Device /dev/da6h Avail: 2445/2573 MB (95%) + + V myvol State: up Plexes: 1 Size: 512 MB + V mirror State: up Plexes: 2 Size: 512 MB + V striped State: up Plexes: 1 Size: 512 MB + + P myvol.p0 C State: up Subdisks: 1 Size: 512 MB + P mirror.p0 C State: up Subdisks: 1 Size: 512 MB + P mirror.p1 C State: initializing Subdisks: 1 Size: 512 MB + P striped.p1 State: up Subdisks: 1 Size: 512 MB + + S myvol.p0.s0 State: up PO: 0 B Size: 512 MB + S mirror.p0.s0 State: up PO: 0 B Size: 512 MB + S mirror.p1.s0 State: empty PO: 0 B Size: 512 MB + S striped.p0.s0 State: up PO: 0 B Size: 128 MB + S striped.p0.s1 State: up PO: 512 kB Size: 128 MB + S striped.p0.s2 State: up PO: 1024 kB Size: 128 MB + S striped.p0.s3 State: up PO: 1536 kB Size: 128 MB</programlisting> + + <para> + <figure id="vinum-striped-vol"> + <title>Un Volume Vinum in Striping</title> + + <graphic fileref="vinum/vinum-striped-vol"/> + </figure> + </para> + + <para>Questo volume è rappresentato nella + <xref linkend="vinum-striped-vol"/>. 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.</para> + </sect2> + + <sect2> + <title>Resistenza alle Rotture e Prestazioni</title> + + <para><anchor id="vinum-resilience"/>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:</para> + + <programlisting> volume raid10 + plex org striped 512k + sd length 102480k drive a + sd length 102480k drive b + sd length 102480k drive c + sd length 102480k drive d + sd length 102480k drive e + plex org striped 512k + sd length 102480k drive c + sd length 102480k drive d + sd length 102480k drive e + sd length 102480k drive a + sd length 102480k drive b</programlisting> + + <para>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.</para> + + <para>La <xref linkend="vinum-raid10-vol"/> rappresenta la struttura di + questo volume.</para> + + <para> + <figure id="vinum-raid10-vol"> + <title>Un Volume Vinum in Mirroring e Striping</title> + + <graphic fileref="vinum/vinum-raid10-vol"/> + </figure> + </para> + </sect2> + </sect1> + + <sect1 id="vinum-object-naming"> + <title>Nomenclatura degli Oggetti</title> + + <para>Come descritto sopra, Vinum assegna nomi di default a plex e + sottodischi, benché questi possano essere cambiati. Cambiare il + nome di default non è raccomandato: l'esperienza con il VERITAS + volume manager, che permette la nomenclatura arbitraria degli oggetti, ha + mostrato che questa flessibilità non porta vantaggi significativi e + può causare confusione.</para> + + <para>I nomi possono contenere ogni carattere non blank (i caratteri di + spazio, tabulazione, cambio riga) ma è consigliato limitarsi a + lettere, cifre e il carattere di underscore. I nomi di volumi, + plex e sottodischi possono essere + lunghi fino a 64 caratteri, i nomi di drive invece hanno un massimo di 32 + caratteri.</para> + + <indexterm><primary>/dev/vinum</primary></indexterm> + + <para>I nomi assegnati agli oggetti Vinum sono nella gerarchia + <filename>/dev/vinum</filename>. + La configurazione di Vinum mostrata sopra creerebbe i seguenti + dispositivi:</para> + + <itemizedlist> + <listitem> + <para>I dispositivi di controllo + <filename>/dev/vinum/control</filename> e + <filename>/dev/vinum/controld</filename>, utilizzati + rispettivamente da &man.vinum.8; e dal demone Vinum.</para> + </listitem> + + <listitem> + <para>Voci di dispositivi a blocchi e a caratteri per ogni volume. + Questi sono i principali dispositivi utilizzati da Vinum. I + dispositivi a blocchi hanno il nome dei relativi volumi, quelli a + caratteri, seguendo la tradizione BSD, hanno una lettera + <emphasis>r</emphasis> all'inizio del nome. Quindi la configurazione + vista sopra genererebbe i dispositivi a blocchi + <filename>/dev/vinum/myvol</filename>, + <filename>/dev/vinum/mirror</filename>, + <filename>/dev/vinum/striped</filename>, + <filename>/dev/vinum/raid5</filename> e + <filename>/dev/vinum/raid10</filename>, e i dispositivi a + caratteri <filename>/dev/vinum/rmyvol</filename>, + <filename>/dev/vinum/rmirror</filename>, + <filename>/dev/vinum/rstriped</filename>, + <filename>/dev/vinum/rraid5</filename> e + <filename>/dev/vinum/rraid10</filename>. + In questo c'è un ovvio problema: è possibile avere due + volumi chiamati <emphasis>r</emphasis> e <emphasis>rr</emphasis> che + avrebbero un conflitto nel creare il nodo + <filename>/dev/vinum/rr</filename>: sarebbe il dispositivo a + caratteri per il volume <emphasis>r</emphasis> o il dispositivo a + blocchi per il volume <emphasis>rr</emphasis>? Attualmente Vinum non + si interessa di questo conflitto: il volume definito per primo prende + il nome.</para> + </listitem> + + <listitem> + <para>Una directory <filename>/dev/vinum/drive</filename> con voci + per ogni disco. Queste voci sono in effetti dei collegamenti simbolici + ai rispettivi nodi di disco.</para> + </listitem> + + <listitem> + <para>Una directory <filename>/dev/vinum/volume</filename> con voci per + ogni volume. Contiene sottodirectory per ogni plex, che a loro volta + contengono sottodirectory per ogni sottodisco.</para> + </listitem> + + <listitem> + <para>Le directory <filename>/dev/vinum/plex</filename>, + <filename>/dev/vinum/sd</filename> e + <filename>/dev/vinum/rsd</filename> contengono i dispositivi a + blocchi per ogni plex, dispositivo a blocchi e dispositivo a caratteri + per ogni sottodisco rispettivamente.</para> + </listitem> + </itemizedlist> + + <para>Ad esempio, considera il seguente file di configurazione:</para> + + <programlisting> drive drive1 device /dev/sd1h + drive drive2 device /dev/sd2h + drive drive3 device /dev/sd3h + drive drive4 device /dev/sd4h + volume s64 setupstate + plex org striped 64k + sd length 100m drive drive1 + sd length 100m drive drive2 + sd length 100m drive drive3 + sd length 100m drive drive4</programlisting> + + <para>Dopo aver elaborato questo file, &man.vinum.8; crea la seguente + struttura in <filename>/dev/vinum</filename>:</para> + + <programlisting> brwx------ 1 root wheel 25, 0x40000001 Apr 13 16:46 Control + brwx------ 1 root wheel 25, 0x40000002 Apr 13 16:46 control + brwx------ 1 root wheel 25, 0x40000000 Apr 13 16:46 controld + drwxr-xr-x 2 root wheel 512 Apr 13 16:46 drive + drwxr-xr-x 2 root wheel 512 Apr 13 16:46 plex + crwxr-xr-- 1 root wheel 91, 2 Apr 13 16:46 rs64 + drwxr-xr-x 2 root wheel 512 Apr 13 16:46 rsd + drwxr-xr-x 2 root wheel 512 Apr 13 16:46 rvol + brwxr-xr-- 1 root wheel 25, 2 Apr 13 16:46 s64 + drwxr-xr-x 2 root wheel 512 Apr 13 16:46 sd + drwxr-xr-x 3 root wheel 512 Apr 13 16:46 vol + + /dev/vinum/drive: + total 0 + lrwxr-xr-x 1 root wheel 9 Apr 13 16:46 drive1 -> /dev/sd1h + lrwxr-xr-x 1 root wheel 9 Apr 13 16:46 drive2 -> /dev/sd2h + lrwxr-xr-x 1 root wheel 9 Apr 13 16:46 drive3 -> /dev/sd3h + lrwxr-xr-x 1 root wheel 9 Apr 13 16:46 drive4 -> /dev/sd4h + + /dev/vinum/plex: + total 0 + brwxr-xr-- 1 root wheel 25, 0x10000002 Apr 13 16:46 s64.p0 + + /dev/vinum/rsd: + total 0 + crwxr-xr-- 1 root wheel 91, 0x20000002 Apr 13 16:46 s64.p0.s0 + crwxr-xr-- 1 root wheel 91, 0x20100002 Apr 13 16:46 s64.p0.s1 + crwxr-xr-- 1 root wheel 91, 0x20200002 Apr 13 16:46 s64.p0.s2 + crwxr-xr-- 1 root wheel 91, 0x20300002 Apr 13 16:46 s64.p0.s3 + + /dev/vinum/rvol: + total 0 + crwxr-xr-- 1 root wheel 91, 2 Apr 13 16:46 s64 + + /dev/vinum/sd: + total 0 + brwxr-xr-- 1 root wheel 25, 0x20000002 Apr 13 16:46 s64.p0.s0 + brwxr-xr-- 1 root wheel 25, 0x20100002 Apr 13 16:46 s64.p0.s1 + brwxr-xr-- 1 root wheel 25, 0x20200002 Apr 13 16:46 s64.p0.s2 + brwxr-xr-- 1 root wheel 25, 0x20300002 Apr 13 16:46 s64.p0.s3 + + /dev/vinum/vol: + total 1 + brwxr-xr-- 1 root wheel 25, 2 Apr 13 16:46 s64 + drwxr-xr-x 3 root wheel 512 Apr 13 16:46 s64.plex + + /dev/vinum/vol/s64.plex: + total 1 + brwxr-xr-- 1 root wheel 25, 0x10000002 Apr 13 16:46 s64.p0 + drwxr-xr-x 2 root wheel 512 Apr 13 16:46 s64.p0.sd + + /dev/vinum/vol/s64.plex/s64.p0.sd: + total 0 + brwxr-xr-- 1 root wheel 25, 0x20000002 Apr 13 16:46 s64.p0.s0 + brwxr-xr-- 1 root wheel 25, 0x20100002 Apr 13 16:46 s64.p0.s1 + brwxr-xr-- 1 root wheel 25, 0x20200002 Apr 13 16:46 s64.p0.s2 + brwxr-xr-- 1 root wheel 25, 0x20300002 Apr 13 16:46 s64.p0.s3</programlisting> + + <para>Benché sia raccomandato non allocare nomi specifici a plex e + sottodischi, i drive di Vinum devono avere un nome. Questo permette di + spostare un disco in una differente locazione e continuare a riconoscerlo + automaticamente. I nomi di drive possono essere lunghi fino a 32 + caratteri.</para> + + <sect2> + <title>Creare i File System</title> + + <para>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 &man.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 + <filename>/dev/ad0a</filename> o <filename>/dev/da2h</filename>. + Questi nomi rappresentano la prima partizione + (<devicename>a</devicename>) del primo (0) disco IDE + (<devicename>ad</devicename>) e l'ottava partizione + (<devicename>h</devicename>) del terzo (2) disco SCSI + (<devicename>da</devicename>), rispettivamente. Al contrario un volume + Vinum potrebbe essere chiamato + <filename>/dev/vinum/concat</filename>, un nome che non ha alcuna + relazione con nomi di partizione.</para> + + <para>Normalmente &man.newfs.8; interpreta il nome del disco e si lamenta + se non riesce a comprenderlo. Per esempio:</para> + + <screen>&prompt.root; <userinput>newfs /dev/vinum/concat</userinput> +newfs: /dev/vinum/concat: can't figure out file system partition</screen> + + <note><para>Queste informazioni sono valide solo per versioni di FreeBSD + precedenti alla 5.0:</para></note> + + <para>Per poter creare un file system su questo volume usa &man.newfs.8; + con l'opzione <option>-v</option>:</para> + + <screen>&prompt.root; <userinput>newfs -v /dev/vinum/concat</userinput></screen> + </sect2> + </sect1> + + <sect1 id="vinum-config"> + <title>Configurare Vinum</title> + + <para>Il kernel <filename>GENERIC</filename> non contiene Vinum. + È possibile creare un kernel speciale che lo contenga, ma questo + non è raccomandato: il metodo standard per lanciare Vinum è + come modulo del kernel (<acronym>kld</acronym>). Non è neanche + necessario usare &man.kldload.8; per Vinum: quando lanci &man.vinum.8; il + programma controlla se il modulo è stato caricato e, in caso non + sia caricato, lo carica automaticamente.</para> + + <sect2> + <title>Avvio</title> + + <para>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:</para> + + <programlisting width="119">volume myvol state up +volume bigraid state down +plex name myvol.p0 state up org concat vol myvol +plex name myvol.p1 state up org concat vol myvol +plex name myvol.p2 state init org striped 512b vol myvol +plex name bigraid.p0 state initializing org raid5 512b vol bigraid +sd name myvol.p0.s0 drive a plex myvol.p0 state up len 1048576b driveoffset 265b plexoffset 0b +sd name myvol.p0.s1 drive b plex myvol.p0 state up len 1048576b driveoffset 265b plexoffset 1048576b +sd name myvol.p1.s0 drive c plex myvol.p1 state up len 1048576b driveoffset 265b plexoffset 0b +sd name myvol.p1.s1 drive d plex myvol.p1 state up len 1048576b driveoffset 265b plexoffset 1048576b +sd name myvol.p2.s0 drive a plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 0b +sd name myvol.p2.s1 drive b plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 524288b +sd name myvol.p2.s2 drive c plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 1048576b +sd name myvol.p2.s3 drive d plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 1572864b +sd name bigraid.p0.s0 drive a plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 0b +sd name bigraid.p0.s1 drive b plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 4194304b +sd name bigraid.p0.s2 drive c plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 8388608b +sd name bigraid.p0.s3 drive d plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 12582912b +sd name bigraid.p0.s4 drive e plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 16777216b</programlisting> + + <para>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;.</para> + + <sect3 id="vinum-rc-startup"> + <title>Avvio Automatico</title> + + <para>Per poter lanciare Vinum automaticamente all'avvio del sistema + assicuratevi che le seguenti linee siano nel vostro + <filename>/etc/rc.conf</filename>:</para> + + <programlisting>start_vinum="YES" # set to YES to start vinum</programlisting> + + <para>Se non hai un file <filename>/etc/rc.conf</filename>, creane uno + con questo contenuto. Questo ordinerà al sistema di caricare + il Vinum <acronym>kld</acronym> all'avvio, inizializzando ogni oggetto + menzionato nella configurazione. Questo viene fatto prima del mount + dei file system quindi è possibile fare automaticamente + &man.fsck.8; e mount dei file system su volumi Vinum.</para> + + <para>Quando esegui Vinum con il comando <command>vinum start</command> + Vinum legge il database di configurazione da uno dei drive Vinum. In + circostanze normali ogni drive contiene una copia identica del + database di configurazione quindi non conta da quale disco viene + letto. Dopo un crash, tuttavia, Vinum deve determinare quale drive + è stato aggiornato più recentemente e leggere la + configurazione da questo drive. Quindi aggiorna la configurazione, se + necessario, sui drive progressivamente più vecchi.</para> + </sect3> + </sect2> + </sect1> + + <sect1 id="vinum-root"> + <title>Usare Vinum nel Filesystem Root</title> + + <para>Per una macchina con filesystem completamente in mirroring con Vinum + è desiderabile mettere in mirroring anche il filesystem di root; + fare questo è meno semplice che non per un filesystem arbitrario, + dato che:</para> + + <itemizedlist> + <listitem> + <para>Il filesystem root deve essere disponibile nella parte iniziale + del processo di boot, quindi l'infrastruttura di Vinum deve essere + già disponibile in quel momento.</para> + </listitem> + + <listitem> + <para>Il volume contenente il filesystem root contiene anche il sistema + di avvio e il kernel, che devono essere letti usando le funzioni + native del sistema (ovvero il BIOS, sui PC) che spesso non conoscono i + dettagli di Vinum.</para> + </listitem> + </itemizedlist> + + <para>Nelle sezioni seguenti, il termine <quote>volume root</quote> + è usato generalmente per descrivere il volume Vinum che contiene il + filesystem root. È probabilmente una buona idea usare il nome + <literal>"root"</literal> per questo volume, ma non è necessario. + Tutti gli esempi nelle prossime sezioni usano questo nome.</para> + + <sect2> + <title>Lanciare Vinum abbastanza presto per il Filesystem Root</title> + + <para>Ci sono varie misure da prendere per fare in modo che questo + accada:</para> + + <itemizedlist> + <listitem> + <para>Vinum deve essere disponibile nel kernel già all'avvio, + quindi il metodo per lanciare Vinum automaticamente descritto + in <xref linkend="vinum-rc-startup"/> non può essere + utilizzato e il parametro <literal>start_vinum</literal> in + realtà <emphasis>non</emphasis> va impostato in questo tipo + di configurazione. La prima possibilità è di + compilare Vinum staticamente dentro al kernel, in modo che sia + sempre disponibile, ma questo non è normalmente desiderabile. + Un'altra opportunità à di fare in modo che + <filename>/boot/loader</filename> (<xref + linkend="boot-loader"/>) carichi il modulo kernel di Vinum prima di + lanciare il kernel. Questo può essere fatto utilizzando la + riga:</para> + + <programlisting>vinum_load="YES"</programlisting> + + <para>nel file <filename>/boot/loader.conf</filename>.</para> + </listitem> + + <listitem> + <para>Vinum deve essere inizializzato subito in modo da poter fornire + il volume per il filesystem root. Per default la porzione kernel di + Vinum non cerca dischi che contengano informazioni sui volumi Vinum + fino a quando un amministratore (o uno degli script di partenza) non + esegue un comando di <command>vinum start</command>.</para> + + <note> + <para>I seguenti paragrafi spiegano i passi necessari per + &os; 5.X e superiori. L'impostazione richiesta da + &os; 4.X è diversa ed è descritta dopo, in + <xref linkend="vinum-root-4x"/>.</para> + </note> + + <para>Inserendo la linea:</para> + + <programlisting>vinum.autostart="YES"</programlisting> + + <para>dentro a <filename>/boot/loader.conf</filename>, Vinum viene + istruito, alla partenza del kernel, di controllare automaticamente + tutti i dischi alla ricerca di informazioni sui volumi Vinum.</para> + + <para>Da notare il fatto che non è necessario istruire il + kernel sulla locazione del filesystem root. + <filename>/boot/loader</filename> cerca il nome del device di root + in <filename>/etc/fstab</filename> e passa l'informazione al kernel. + Quando è necessario montare il filesystem root, il kernel, + tramite il nome di device fornitogli, capisce a quale driver deve + chiedere la conversione di tale nome in ID interno di device (numero + maggiore/minore).</para> + </listitem> + </itemizedlist> + </sect2> + + <sect2> + <title>Rendere un volume di root basato su Vinum accessibile + dall'avvio</title> + + <para>Dato che il codice di avvio di FreeBSD è attualmente di soli + 7.5 KB ed è già appesantito dalla lettura di file (come + <filename>/boot/loader</filename>) 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 <literal>"a"</literal> standard contenente + il filesystem di root.</para> + + <para>Perché questo sia anche solo possibile, il volume di root + deve rispondere ai seguenti requisiti:</para> + + <itemizedlist> + <listitem> + <para>Il volume di root non deve essere in striping o in RAID-5.</para> + </listitem> + + <listitem> + <para>Il volume di root non deve contenere la concatenazione di più di + un sottodisco per ogni plex.</para> + </listitem> + </itemizedlist> + + <para>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 <literal>"a"</literal> illusoria, + affinché la periferica relativa possa essere avviabile. Non + è strettamente necessario che ognuna di queste finte partizioni + <literal>"a"</literal> 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.</para> + + <para>Per poter configurare queste partizioni <literal>"a"</literal>, + in ogni periferica contenente parte del volume di root, bisogna fare le + seguenti cose:</para> + + <procedure> + <step> + <para>La locazione (spiazzamento dall'inizio della periferica) e la + dimensione del sottodisco che è parte del volume di root deve + essere esaminato, usando il comando:</para> + + <screen>&prompt.root; <userinput>vinum l -rv root</userinput></screen> + + <para>Da notare che gli spiazzamenti e le dimensioni in Vinum sono + misurati in byte. Devono essere divisi per 512 per ottenere il + numero di blocchi necessari nel comando + <command>disklabel</command>.</para> </step> + + <step> + <para>Esegui il comando:</para> + + <screen>&prompt.root; <userinput>disklabel -e <replaceable>devname</replaceable></userinput></screen> + + <para>per ogni periferica che partecipa al volume di root. + <replaceable>devname</replaceable> deve essere o il nome della slice + (ad esempio <devicename>ad0s1</devicename>) o il nome del disco (ad + esempio <devicename>da0</devicename>) per dischi senza tabella delle + slice (ovvero i nomi che si usano anche con fdisk).</para> + + <para>Se c'è già una partizione <literal>"a"</literal> + sulla periferica (presumibilmente contenente un filesystem root + precedente all'uso di Vinum), dovrebbe essere rinominata in altro + modo, in modo da restare accessibile (non si sa mai), ma non essere + usata più per default per avviare il sistema. Da notare che + le partizioni attive (ad esempio un filesystem root attualmente + montato) non possono essere rinominati, quindi questo deve essere + eseguito o avviando da un disco <quote>Fixit</quote> o (in caso di + mirror) in un processo a due passi dove il disco non di avvio viene + modificato per primo.</para> + + <para>Infine, lo spiazzamento della partizione Vinum sulla periferica + va aggiunto allo spiazzamento del rispettivo sottodisco di root + rispetto alla periferica stessa. Il risultato sarà il valore + di <literal>"offset"</literal> (spiazzamento) per la nuova + partizione <literal>"a"</literal>. Il valore + <literal>"size"</literal> (dimensione) per questa partizione + può essere copiato pari pari dal calcolo fatto sopra. + Il valore <literal>"fstype"</literal> deve essere + <literal>4.2BSD</literal>. I valori <literal>"fsize"</literal>, + <literal>"bsize"</literal> e <literal>"cpg"</literal> devono + preferibilmente essere scelti per corrispondere al vero e proprio + filesystem, anche se in questo contesto non sono molto + importanti.</para> + + <para>In questo modo una nuova partizione <literal>"a"</literal> + sarà creata ricoprendo le partizioni Vinum su questa + periferica. Da notare che <command>disklabel</command> + permetterà questa ricopertura solo se la partizione Vinum + è stata appropriatamente marcata usando un + <literal>"fstype"</literal> pari a <literal>"vinum"</literal> + fstype.</para> </step> + + <step> + <para>È tutto! Ora una falsa partizione <literal>"a"</literal> + esiste su ogni periferica che abbia una replica del volume di root. + È altamente raccomandabile verificare nuovamente i risultati, + usando un comando come:</para> + + <screen>&prompt.root; <userinput>fsck -n /dev/<replaceable>devname</replaceable>a</userinput></screen> + </step> + </procedure> + + <para>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 + <filename>/etc/fstab</filename> e + <filename>/boot/loader.conf</filename>.</para> + + <para>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:</para> + + <screen>Mounting root from ufs:/dev/vinum/root</screen> + </sect2> + + <sect2> + <title>Esempi di configurazioni con root basata su Vinum</title> + + <para>Dopo aver creato il volume di root Vinum, + <command>vinum l -rv root</command> dovrebbe produrre qualcosa di simile + a:</para> + + <screen> +... +Subdisk root.p0.s0: + Size: 125829120 bytes (120 MB) + State: up + Plex root.p0 at offset 0 (0 B) + Drive disk0 (/dev/da0h) at offset 135680 (132 kB) + +Subdisk root.p1.s0: + Size: 125829120 bytes (120 MB) + State: up + Plex root.p1 at offset 0 (0 B) + Drive disk1 (/dev/da1h) at offset 135680 (132 kB) + </screen> + + <para>I valori su cui fare caso sono il <literal>135680</literal> dello + spiazzamento (relativo alla partizione + <filename>/dev/da0h</filename>). Questo si traduce in 265 blocchi da + 512 byte nei termini di <command>disklabel</command>. + <filename>/dev/da1h</filename>, contenente la seconda replica del + volume di root, ha una configurazione simmetrica.</para> + + <para>La <command>disklabel</command> per queste periferiche dovrebbe + essere simile a questa:</para> + + <screen> +... +8 partitions: +# size offset fstype [fsize bsize bps/cpg] + a: 245760 281 4.2BSD 2048 16384 0 # (Cyl. 0*- 15*) + c: 71771688 0 unused 0 0 # (Cyl. 0 - 4467*) + h: 71771672 16 vinum # (Cyl. 0*- 4467*) + </screen> + + <para>Si può notare che il parametro <literal>"size"</literal> per + la finta partizione <literal>"a"</literal> corrisponde al valore di cui + abbiamo parlato prima, mentre il parametro <literal>"offset"</literal> + è la somma dello spiazzamento all'interno della partizione Vinum + <literal>"h"</literal> e lo spiazzamento all'interno della periferica (o + slice). Questa è una tipica configurazione necessaria per + evitare il problema descritto in <xref linkend="vinum-root-panic"/>. + Si può anche notare che l'intera partizione + <literal>"a"</literal> è completamente contenuta dalla partizione + <literal>"h"</literal>, che contiene tutti i dati Vinum per questa + periferica.</para> + + <para>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.</para> + </sect2> + + <sect2> + <title>Risoluzione Problemi</title> + + <para>Se qualcosa va storto, serve un modo per tornare in una situazione + di normalità. Segue una lista di alcuni tipici problemi, + completi di soluzione.</para> + + <sect3> + <title>Il Codice di Avvio si Carica, ma il Sistema non si Avvia</title> + + <para>Se per qualsiasi ragione in sistema non prosegue nell'avvio, si + può interrompere il processo di avvio premendo il tasto + <keycap>spazio</keycap> all'avviso dei 10 secondi. Le variabili di + avvio potranno quindi essere esaminate usando il comando + <command>show</command> e manipolate con <command>set</command> e + <command>unset</command>.</para> + + <para>Se l'unico problema è che il modulo kernel di Vinum non + è ancora presente nella lista dei moduli da caricare + automaticamente, un semplice <command>load vinum</command> + aiuterà.</para> + + <para>Quando pronti, il processo di avvio può continuare con un + <command>boot -as</command>. Le opzioni <option>-as</option> + comunicano al kernel di montare il filesystem di root + (<option>-a</option>) e di interrompere il processo di avvio in + modalità singolo utente (<option>-s</option>), + quando il filesystem di root è montato a sola lettura. In + questo modo benché uno solo dei plex do un volume multi-plex + sia stato montato, non si rischia inconsistenza dei dati tra i vari + plex.</para> + + <para>Alla richiesta di un filesystem di root da montare, ogni + periferica che contenga un filesystem di root valido può essere + usata. Se <filename>/etc/fstab</filename> è stato impostato + correttamente, il default dovrebbe essere + <literal>ufs:/dev/vinum/root</literal> o simile. Una tipica + alternativa potrebbe essere <literal>ufs:da0d</literal>, una + ipotetica partizione contenente un filesystem root pre-Vinum. + Bisogna fare attenzione quando si sceglie una delle partizioni + <literal>"a"</literal> alias di un sottodisco della periferica root di + Vinum, perché in una configurazione in mirror questo monterebbe + solo un pezzo della root in mirror. Se questo filesystem deve poi + essere montato in lettura/scrittura è necessario rimuovere gli + altri plex del volume root di Vinum dato che conterrebbero comunque + dati non consistenti.</para> + </sect3> + + <sect3> + <title>Si Carica Solo l'Avvio Primario</title> + + <para>Se <filename>/boot/loader</filename> non si carica, ma l'avvio + primario si carica comunque (si capisce dal singolo trattino nella + colonna di sinistra dello schermo subito dopo l'inizio dell'avvio), si + può tentare di fermare l'avvio primario in questo punto, + premendo il tasto <keycap>spazio</keycap>. Questo fermerà + l'avvio nella seconda fase, vedi <xref linkend="boot-boot1"/>. Qua si + può fare un tentativo di caricare una differente partizione, ad + esempio la partizione contenente il precedente filesystem di root + <literal>"a"</literal>, prima di sostituirlo come sopra + indicato.</para> + </sect3> + + <sect3 id="vinum-root-panic"> + <title>Non si Carica Niente, l'Avvio va in Panico</title> + + <para>Questa situazione accade quando l'installazione di Vinum ha + distrutto il codice di avvio. Sfortunatamente Vinum lascia solo 4 KB + liberi all'inizio della sua partizione prima di scrivere il proprio + header. Purtroppo le due fasi dell'avvio e la disklabel compresa tra + le due attualmente occupa 8 KB, quindi se la partizione Vinum è + creata con spiazzamento 0 in una slice o disco che dovrebbe essere + avviabile, la configurazione di Vinum distruggerà il codice di + avvio.</para> + + <para>Similmente, se la situazione sopra descritta è stata + risolta avviando da un disco di <quote>Fixit</quote>, e il codice di + avvio re-installato usando <command>disklabel -B</command> come + descritto in <xref linkend="boot-boot1"/>, il codice di avvio + distruggerà l'header di Vinum, che non saprà più + trovare i propri dischi. Benché nessun dato, di configurazione + o contenuto, sia distrutto da questo processo, che risulta quindi + recuperabile reinserendo la stessa configurazione di Vinum, la + situazione è in realtà di difficile risoluzione: sarebbe + necessario spostare l'intera partizione Vinum di almeno 4 KB, in modo + da lasciare abbastanza spazio sia per il codice di avvio che per + l'header Vinum.</para> + </sect3> + </sect2> + + <sect2 id="vinum-root-4x"> + <title>Differenze per FreeBSD 4.X</title> + + <para>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 + <filename>/dev/vinum/root</filename>, quindi le cose vengono fatte + in modo un po' diverso.</para> + + <para>Bisogna dire esplicitamente a Vinum quali dischi controllare, usando + una riga di <filename>/boot/loader.conf</filename> come la + seguente:</para> + + <programlisting>vinum.drives="/dev/<replaceable>da0</replaceable> /dev/<replaceable>da1</replaceable>"</programlisting> + + <para>È importante indicare tutti i drive che possono contenere + dati Vinum. Non è un problema indicare drive <emphasis>di + troppo</emphasis>, 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.</para> + + <para>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 + <quote>classici</quote> di periferica come + <filename>/dev/ad0s1a</filename>, non riescono a capire nomi di + volumi root come <filename>/dev/vinum/root</filename>. 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 <literal>vinum.root</literal>. + La riga di <filename>/boot/loader.conf</filename> adatta per fare questo + è simile alla seguente:</para> + + <programlisting>vinum.root="root"</programlisting> + + <para>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 <emphasis>e</emphasis> 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 + <literal>"vinum"</literal>, 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.</para> + + <para>Bisogna comunque notare che anche quando <command>boot -a</command> + 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 <literal>ufs:da0d</literal> + funzionerà come previsto. Da notare che se questo fallisce non + si può più provare una stringa come + <literal>ufs:vinum/root</literal>, dato che non verrebbe + interpretata; l'unica via di uscita è riavviare e ripartire da + zero. (Alla richiesta di <quote>askroot</quote>, la parte iniziale + <filename>/dev/</filename> può sempre essere omessa.)</para> + </sect2> + </sect1> +</chapter> |