Software-RAID HOWTO: Considerazioni sul setup e sull'installazione

Avanti Indietro Indice

3. Considerazioni sul setup e sull'installazione

D: Quale è il modo migliore di configurare Software RAID?
R: Continuamente riscopro il fatto che la pianificazione del file-system è uno dei lavori più difficili sotto Unix. Per rispondere alla domanda, posso descrivere cosa si può fare. Supponiamo il setup che segue:
- 2 dischi EIDE, da 2.1 Gb ciascuno.
  disco partizione montata su dimensione dispositivo 1 1 / 300M /dev/hda1 1 2 swap 64M /dev/hda2 1 3 /home 800M /dev/hda3 1 4 /var 900M /dev/hda4 2 1 /root 300M /dev/hdc1 2 2 swap 64M /dev/hdc2 2 3 /home 800M /dev/hdc3 2 4 /var 900M /dev/hdc4
- Ogni disco è su un controller (e cavo) separato. La mia teoria è che un guasto al controller o al cavo non manderà in tilt tutti e due i dischi. Questo permette un miglioramento delle performance rispetto alla gestione di operazioni parallele
- Installare Linux su (/) della partizione /dev/hda1. Marcare questa partizione come avviabile.
- /dev/hdc1 conterrà una copia ``fredda'' di /dev/hda1. Questa non è una copia RAID, è proprio una semplice copia. Serve solamente nel caso che il primo disco si rompa; si può usare un disco, di recupero, marcare /dev/hdc1 come avviabile, e usare questa partizione per continuare a lavorare senza dover reinstallare il sistema. Può anche essere utile mettere una copia del kernel di /dev/hdc1 su LILO per semplificare il boot in caso di malfunzionamento. Qui si suppone che nel caso di un grave malfunzionamento si possa ancora far partire il sistema senza preoccupazioni riguardanti la corruzione dei superblock raid o di altri errori del raid che non si capiscono.
- /dev/hda3 e /dev/hdc3 saranno il mirror /dev/md0.
- /dev/hda4 e /dev/hdc4 saranno il mirror /dev/md1.
- abbiamo scelto/var e /home per essere mirrorate in partizioni separate, seguendo questa logica
  - / (la partizione root) conterrà dati relativamente statici, non soggetti a cambiamenti. Ad ogni effetto sarà si sola lettura anche se non sarà impostata e montata veramente in sola lettura
  - /home conterrà i dati che cambiano "lentamente".
  - /var conterrà i dati che cambiano rapidamente, inclusi i mail spool, i database ed i log del web server.
  L'idea che sta dietro all'uso di più partizioni separate è che se, per qualche bizzarra, ragione che sia un errore umano, un calo di tensione, o altro il sistema operativo impazzisce, il danno è limitato ad una sola partizione. In un caso tipico vi è un calo di tensione mentre il sistema sta scrivendo sul disco. Questo lascerà sicuramente il file system in uno stato di inutilizzabilità, a cui sarà posto rimedio da fsck nel boot seguente. Anche se fsck farà del suo meglio per rimettere a posto la situazione evitando di fare ulteriori danni, è confortante sapere che ogni danno è stato limitato ad una sola partizione. In un altro caso tipico l'amministratore di sistema fa un errore durante le operazioni di recupero del file system, cosa che porta alla cancellazione o alla distruzione dei dati. L'uso delle partizioni può aiutare a contenere le ripercussioni degli errori dell'operatore.
- Un'altra scelta ragionevole per la disposizione delle partizioni potrebbe essere quella di /usr o di /opt. In effetti, /opt e /home sono una buona scelta come partizioni RAID-5, se si hanno più hard disk. Una parola sulla prudenza da utilizzare: NON mettere /usr in una partizione RAID-5. Se si avesse un grave malfunzionamento si potrebbe scoprire che non si può montare /usr, e che si ha bisogno di qualche strumento che vi risiede (ad es. i programmi per la rete, o il compilatore.) Con RAID-1, se si ha un malfunzionamento e RAID smette di funzionare, si può almeno montare uno dei due mirror. La stessa cosa non si può fare con ogni altro livello RAID (RAID-5, striping, linear RAID).
Così, per rispondere alla domanda:
- installare il S.O. sul disco 1, partizione 1. NON montare altre partizioni.
- installare RAID seguendo le istruzioni.
- configurare md0 e md1.
- convincersi del fatto che si sa che cosa fare in caso di malfunzionamento del disco! Si scoprano gli errori dell'amministratore di sistema adesso, non non durante una vera crisi! Sperimentate! (noi abbiamo tolto corrente durante l'attività del disco, poco ortodosso ma fa imparare molto).
- effettuate una successione di mount/copy/unmount/rename/reboot per muovere /var su /dev/md1. Fatelo attentamente, non è pericoloso.
- godetevi il tutto!
D: Quale è la differenza tra i comandi mdadd, mdrun, etc. e quelli raidadd, raidrun?
R: I nomi dei tool sono stati cambiati dalla versione 0.5 del pacchetto raidtools. La convenzione che voleva che i comandi iniziassero per md era usata nella versione 0.43 e precedenti, mentre quella nuova che fa iniziare i comandi per raid viene usata nella versione 0.5 e successive.
D: Vorrei utilizzare RAID-Linear/RAID-0 presente nel kernel 2.0.34. Vorrei non applicare la patch raid, poiché non sono richieste per RAID-0/Linear. Dove posso procurarmi i tool RAID per gestire il sistema?
R: Questa è una bella domanda, poiché i più nuovi tool raid abbisognano che le patch RAID-1,4,5 siano state applicate al kernel per compilarsi. Non conosco versioni binarie, precompilate dei tool raid disponibili in questo momento. Comunque sia, esperimenti hanno dimostrato che i file binari dei tool raid, compilati su un kernel 2.1.100, sembrano funzionare abbastanza bene nella creazione di una partizione RAID-0/linear sotto 2.0.34. Un'anima impavida me li ha chiesti ed io ho temporaneamente reso disponibili i binari di mdadd, mdcreate, ecc, su http://linas.org/linux/Software-RAID/ Avrete bisogno delle pagine di manuale, ecc. che si trovano nel pacchetto standard dei raid-tools.
D: Posso mettere in strip/mirror la partizione di root (/)? Perché non posso far partire Linux direttamente dai dischi md?
R: Sia LILO che Loadlin hanno bisogno di una partizione che non sia in strip/mirror per potervi leggere l'immagine del kernel. Se volete mettere in strip/mirror la partizione di root (/), avrete bisogno di creare una partizione che non sia in strip/mirror dove poter mettere il kernel. Tipicamente questa partizione viene chiamata /boot. Fatto questo si può quindi usare o il supporto per il ramdisk iniziale (initrd) o le patch di Harald Hoyer < HarryH@Royal.Net> che consentono ad una partizione in strip/mirror di essere usata come root. (Adesso queste patch sono una parte standard dei recenti kernel 2.1.x)
Si possono usare approcci diversi. Uno è documentato dettagliatamente nel Bootable RAID mini-HOWTO: ftp://ftp.bizsystems.com/pub/raid/bootable-raid.

In alternativa, si può usare mkinitrd per costruire un'immagine per il ramdisk, vedere di seguito.

Edward Welbon < welbon@bga.com> ha scritto:
- ... tutto quello che serve è uno script che gestisca il setup di boot. Per montare un file system md come root, la cosa principale da fare è costruire un'immagine iniziale del file system che abbia i moduli e i tool md necessari per far partire md. Io ho un semplice script che fa tutto ciò.
- Come supporto per il boot utilizzo un piccolo ed economico disco SCSI (170MB lo ho preso usato per $20). Il disco è collegato ad un AHA1452, ma avrebbe potuto essere un disco IDE a buon prezzo sull'interfaccia nativa IDE. Non c'è bisogno che sia un disco molto veloce poiché serve solamente per il boot.
- Questo disco contiene un piccolo file system dove trova posto il kernel e l'immagine del file system per initrd. L'immagine iniziale del file system contiene abbastanza roba da permettermi di caricare il modulo driver per il dispositivo raid SCSI e poter accedere alla partizione che diverrà root. Poi eseguo un
  echo 0x900 > /proc/sys/kernel/real-root-dev
  (0x900 è per /dev/md0) e esco da linuxrc. Il boot procede normalmente da qui in poi.
- Ho compilato molti driver come moduli eccetto quello per l'AHA1452 che serve per il file system initrd. Il kernel che uso è così molto piccolo. Il metodo è perfettamente affidabile, lo sto usando sin da prima della versione 2.1.26 e non ho mai avuto un problema che non sia riuscito a risolvere facilmente. Il file system è addirittura sopravvissuto a diversi crash dei kernel 2.1.4[45] senza reali difficoltà.
- Una volta avevo partizionato i dischi raid in maniera tale che i cilindri iniziali del primo disco raid contenevano il kernel e i cilindri iniziali del secondo disco raid contenevano l'immagine iniziale del file system, adesso invece ho messo la swap nei primi cilindri dei dischi raid poiché questi sono i più veloci (perché sprecarli nel boot?).
- La cosa bella dell'avere un dispositivo che costa poco dedicato al boot è che è facile effettuarne il boot e che risulta utile come disco di recupero se necessario. Se siete interessati, potete dare un'occhiata allo script che genera l'immagine iniziale per il ram disk e che quindi fa partire LILO.
  http://www.realtime.net/~welbon/initrd.md.tar.gz
  Per adesso è abbastanza per fare quello che serve. Non è specificamente bello e potrebbe sicuramente costruire un'immagine del file system molto più piccola per il ram disk iniziale. Dovrebbe essere facile renderlo più efficiente. Ma del resto usa LILO così com'è. Se gli apportate dei miglioramenti vi prego di mandarmene una copia. 8-)
D: Ho sentito dire che si può usare il mirroring sullo striping RAID. È vero? Posso usare il mirroring sul dispositivo di loopback?
R: Si, ma non il contrario. Si può mettere una striscia su più dischi e poi effettuarne il mirroring. Comunque sia lo striping non può essere messo al di sopra del mirroring.
Per darne una breve spiegazione tecnica si può dire che le personality linear e stripe usano la routine ll_rw_blk per gli accessi. La routine ll_rw_blk mappa dispositivi di dischi e settori, non blocchi. I dispositivi a blocchi possono essere stratificati uno sull'altro; ma i dispositivi che effettuano un accesso al disco diretto, a basso livello, come fa ll_rw_blk non possono essere sovrapposti.

In questo momento (Novembre 1997) RAID non può funzionare sui dispositivi di loopback, anche se questo dovrebbe essere possibile a breve.
D: Ho due piccoli dischi e tre dischi più grandi. Posso concatenare i due dischi piccoli con RAID-0 e quindi creare una partizione RAID-5 con questi e quelli più grandi?
R: In questo momento (Novembre 1997), non si può creare una partizione RAID-5 in questa maniera. Si può farlo solo con RAID-1 al di sopra della concatenazione dei drive.
D: Quale è la differenza tra RAID-1 e RAID-5 per una configurazione che prevede due dischi (cioè la differenza tra una serie di due dischi RAID-1 e una serie di due dischi RAID-5)?
R: Non c'è differenza nella capacità di immagazzinamento. Non si possono aggiungere dischi a nessuno dei due sottosistemi per aumentarne la capacità (vedi la domanda qui di seguito per i dettagli).
RAID-1 offre un vantaggio nella prestazione in lettura: il driver RAID-1 usa la tecnologia distributed-read (lettura distribuita. ndt) per leggere contemporaneamente due settori, uno da ogni disco, raddoppiando la performance in lettura.
Il driver RAID-5, anche se fortemente ottimizzato, attualmente (Settembre 1997) non considera il fatto che il disco di parità è una copia del disco dati. Quindi le letture avvengono in maniera seriale.
D: Come posso proteggermi dal malfunzionamento di due dischi?
A: Qualcuno degli algoritmi RAID protegge da un malfunzionamento multiplo dei dischi, ma nessuno di questi algoritmi è attualmente implementato da Linux. Detto ciò il Software RAID per Linux può essere utilizzato per proteggersi da un malfunzionamento di più dischi stratificando serie su serie di dischi. Per esempio, nove dischi possono essere utilizzati per creare tre serie raid-5. Quindi queste tre serie possono a loro volta essere legate assieme in una singola serie di dischi RAID-5. In effetti questo tipo di configurazione arriva a proteggere da un malfunzionamento di tre dischi. Va notato il fatto che una grande quantità di spazio disco va ''persa'' per la ridondanza delle informazioni.
Per una serie di NxN dischi raid-5 N=3, 5 dischi su 9 sono usati per la parità (=55%) N=4, 7 dischi su 16 N=5, 9 dischi su 25 ... N=9, 17 dischi su 81 (=~20%)
In generale, una serie di MxN dischi userà MxN-1 dischi per la parità. Lo spazio "perso" è minimo quando M=N.
Un'altra alternativa è quella di creare una serie RAID-1 con tre dischi. Va notato il fatto che poiché tutti e tre i dischi contengono dati identici, 2/3 dello spazio vanno ``sprecati''.
D: Mi piacerebbe capire come è possibile che ci sia un programma tipo fsck: se la partizione non è stata smontata in maniera ortodossa, fsck interviene e riaggiusta il filesystem da solo in più del 90% dei casi. Poiché la macchina è capace di porsi rimedio da sola con ckraid --fix, perché non farlo diventare automatico?
R: Si può ottenere ciò aggiungendo linee come le seguenti a /etc/rc.d/rc.sysinit:
```
    mdadd /dev/md0 /dev/hda1 /dev/hdc1 || {
        ckraid --fix /etc/raid.usr.conf
        mdadd /dev/md0 /dev/hda1 /dev/hdc1
    }
            
```
o
```
    mdrun -p1 /dev/md0
    if [ $? -gt 0 ] ; then
            ckraid --fix /etc/raid1.conf
            mdrun -p1 /dev/md0
    fi
            
```
Prima di presentare uno script più completo e affidabile, rivediamo la teoria delle operazioni. Gadi Oxman ha scritto: In uno shutdown sporco, Linux può rimanere in uno degli stati seguenti:
- Il dischi RAID erano stati aggiornati con i dati contenuti nella memoria cache a loro destinata quando è avvenuto lo shutdown; non sono andati persi dati.
- La memoria cache dei dischi RAID conteneva informazioni non scritte sui dischi quando è avvenuto il blocco del sistema; questo ha portato ad un filesystem danneggiato e potenzialmente alla perdita di dati. Quest'ultimo stato può essere ulteriormente suddiviso in altri due stati:
  - Linux era in fase di scrittura dati quando si è avuto lo shutdown.
  - Linux non era in fase di scrittura dati quando si è verificato il blocco.
Supponiamo che stavamo usando una serie di dischi RAID-1. Nel caso (2a) potrebbe accadere che, prima del blocco, un piccolo numero di blocchi dati sia stato scritto con successo su solo alcuni dei dischi di mirror e al prossimo boot i mirror non conterranno più` gli stessi dati. Se si ignorassero le differenze dei mirror, il codice di bilanciamento della lettura dei raidtools-0.36.3 potrebbe scegliere di leggere i suddetti dati da uno qualsiasi dei dischi di mirror, cosa che porterebbe ad un comportamento incoerente (per esempio, l`output di e2fsck -n /dev/md0 potrebbe essere differente di volta in volta).
Poiché RAID non protegge dagli shutdown sporchi, usualmente non c`e` un modo ''sicuramente corretto'' di correggere le differenze nei dischi di mirror e il danneggiamento del filesystem.
Per esempio il comportamento predefinito di ckraid --fix sarà quello di scegliere il primo disco di mirror operativo e aggiornare gli altri dischi di mirror con il suo contenuto. Tuttavia, a seconda della situazione dei dischi al momento del blocco, i dati negli altri dischi di mirror potrebbero essere più recenti e si potrebbe scegliere di copiare i dati da quei dischi o forse di usare un metodo differente per riparare le cose.
Lo script che segue definisce una delle più robuste sequenze di boot. In particolare si cautela dalle lunghe ripetizioni dell`esecuzione di ckraid quando si ha a che fare con dischi, controller o driver dei controller che non cooperano. Lo si modifichi in modo da adeguarlo alla propria configurazione, e lo si copi su rc.raid.init. Quindi si esegua rc.raid.init dopo che la partizione di root è stata controllata da fsck e montata in lettura/scrittura ma prima che le rimanenti partizioni siano controllate da fsck. Assicurarsi che la directory attuale sia nel percorso di ricerca.
```
    mdadd /dev/md0 /dev/hda1 /dev/hdc1 || {
        rm -f /fastboot             # forza l`esecuzione di fsck  
        ckraid --fix /etc/raid.usr.conf
        mdadd /dev/md0 /dev/hda1 /dev/hdc1
    }
    # se il sistema si bloccasse più avanti durante questo processo di boot
    # vorremmo che almeno questo dispositivo md non ne risentisse. 
     /sbin/mdstop /dev/md0

    mdadd /dev/md1 /dev/hda2 /dev/hdc2 || {
        rm -f /fastboot             # forza l`esecuzione di fsck
        ckraid --fix /etc/raid.home.conf
        mdadd /dev/md1 /dev/hda2 /dev/hdc2
    }
    # se il sistema si bloccasse più avanti durante questo processo di boot
    # vorremmo che almeno questo dispositivo md non ne risentisse. 
    /sbin/mdstop /dev/md1

    mdadd /dev/md0 /dev/hda1 /dev/hdc1
    mdrun -p1 /dev/md0
    if [ $? -gt 0 ] ; then
        rm -f /fastboot             #  forza l`esecuzione di fsck 
        ckraid --fix /etc/raid.usr.conf
        mdrun -p1 /dev/md0
    fi
    # se il sistema si bloccasse più avanti durante questo processo di boot
    # vorremmo che almeno questo dispositivo md non ne risentisse. 
    /sbin/mdstop /dev/md0

    mdadd /dev/md1 /dev/hda2 /dev/hdc2
    mdrun -p1 /dev/md1
    if [ $? -gt 0 ] ; then
        rm -f /fastboot             #   forza l`esecuzione di fsck
        ckraid --fix /etc/raid.home.conf
        mdrun -p1 /dev/md1
    fi
    # se il sistema si bloccasse più avanti durante questo processo di boot
    # vorremmo che almeno questo dispositivo md non ne risentisse. 
    /sbin/mdstop /dev/md1

    # OK, adesso con i soli comandi md. Se ci fossero stati errori
    # i controlli precedenti dovrebbero aver rimesso tutto a posto.
    /sbin/mdadd /dev/md0 /dev/hda1 /dev/hdc1
    /sbin/mdrun -p1 /dev/md0
    
    /sbin/mdadd /dev/md12 /dev/hda2 /dev/hdc2
    /sbin/mdrun -p1 /dev/md1

            
```
In aggiunta a questo si dovrà creare un file rc.raid.halt che dovrebbe apparire come questo:
```
    /sbin/mdstop /dev/md0
    /sbin/mdstop /dev/md1
            
```
Assicuratevi di aver modificato sia rc.sysinit che init.d/halt per far eseguire questa procedura da qualsiasi parte il filesystem venga smontato prima di un halt/reboot. (Si noti che rc.sysinit smonta ed effettua un reboot se fsck termina l`esecuzione con un errore.)
D: Posso configurare metà di un mirror RAID-1 con il solo disco che ho adesso e poi dopo aggiungervi semplicemente un altro disco?
R: Con gli strumenti di adesso no, almeno non in maniera semplice. In particolare non si può solamente copiare il contenuto di un disco su un altro e poi appaiarli. Questo a causa del fatto che i driver RAID usano un poco di spazio alla fine della partizione per memorizzare i superblock. Questo diminuisce leggermente lo spazio disponibile per il filesystem; ma se si provasse a forzare una partizione RAID-1 su una partizione con un filesystem preesistente, i superblock sovrascriverebbero una parte del filesystem confondendo i dati. Poiché il filesystem ext2fs distribuisce i file in maniera casuale su una partizione (per evitarne la frammentazione), con grossa probabilità qualche file risiederà alla fine della partizione anche se il disco non è pieno.
Se siete abili, suppongo che possiate calcolarvi quanto spazio il superblock RAID occuperà e quindi rendere il filesystem leggermente più piccolo, in modo da lasciare lo spazio di cui la memorizzazione del superblock RAID avrà bisogno in seguito. Ma, se siete così abili, sarete quindi abbastanza bravi da modificare i tool in modo tale che lo facciano automaticamente (i tool non sono terribilmente complessi).

Nota: il lettore attento avrà pensato che il trucco seguente potrebbe funzionare; non l'ho provato né verificato: Eseguite mkraid con /dev/null come uno dei dispositivi. Quindi eseguite mdadd -r sul solo vero disco (non eseguite mdadd /dev/null). Il comando mkraid dovrebbe aver configurato con successo il sistema raid, e il comando mdadd serve solo a forzare il funzionamento del sistema in modalità "degradata" (in inglese "degraded mode". ndt), come se uno dei due dischi fosse rotto.

Avanti Indietro Indice