/dev/sda2 e
/dev/sda3. Il dispositivo è molto più lento
di una singola partizione. Ma allora md è un ammasso di
robaccia?
R: Per usufruire di un dispositivo RAID-0 che funzioni alla massima velocità, si devono utilizzare partizioni di dischi differenti. Oltretutto, mettendo le due metà di un mirror su di un solo disco non ci si cautela da nessun tipo di malfunzionamento del disco.
R: Il fatto che RAID-0 abbia sempre una performance migliore non è cosa ovvia; in effetti, in qualche caso, le cose potrebbero andare peggio. Il filesystem ext2fs distribuisce i file su tutta la partizione, e cerca di mantenere contigui tutti i blocchi di un file, nel tentativo di impedirne la frammentazione. Quindi ext2fs si comporta "come se" ci fosse una striscia (di dimensioni variabili) per ogni file. Se diversi dischi vengono concatenati in un dispositivo RAID-linear, statisticamente i file verranno distribuiti su ogni disco. Quindi, almeno per ext2fs, RAID-linear si comporta in maniera molto simile a un RAID-0 con delle ampie strisce. Al contrario RAID-0 con strisce piccole può causare un'eccessiva attività del disco che può portare ad un forte degrado delle prestazioni se si accede contemporaneamente a diversi grandi file.In molti casi RAID-0 può risultare facile vincitore. Si immagini, per esempio un grande file di database. Poiché ext2fs cerca di raggruppare insieme tutti i blocchi di un file, vi sono buone possibilità che esso finisca in un solo disco se si utilizza RAID-linear o finisca diviso in molteplici strisce se si usa RAID-0. Si immaginino adesso un certo numero di thread (del kernel) che stanno tentando di accedere al database in maniera casuale. Sotto RAID-linear tutti gli accessi finirebbero con il dover essere soddisfatti da un solo disco che finirebbe con l'essere inefficiente se paragonato alla possibilità di accessi multipli paralleli che RAID-0 consente.
R: Per comprendere meglio aiutiamoci con un esempio che coinvolge tre partizioni; una da 50Mb, una da 90Mb e una da 125Mb. Chiamiamo D0 il disco da 50Mb, D1 il disco da 90Mb e D2 quello da 125Mb. Quando si fa partire il dispositivo, il driver calcola le 'strip zones' (letteralmente "zone di striscia". ndt). In questo caso vengono individuate 3 zone, così definite:Z0 : (D0/D1/D2) 3 x 50 = 150MB totali in questa zona Z1 : (D1/D2) 2 x 40 = 80MB totali in questa zona Z2 : (D2) 125-50-40 = 35MB totali in questa zona.Si può notare come la dimensione totale delle zone sia la dimensione del dispositivo virtuale, ma la distribuzione delle strisce varia in funzione della zona. Z2 è inefficiente, poiché contenuta in un solo disco. Poichéext2fse molti altri filesystem di Unix distribuiscono i file su tutto il disco, si ha il 35/265 = 13% di probabilità che i dati finiscano su Z2, e quindi non beneficino dello striping. (DOS cerca di riempire un disco partendo dall'inizio e andando verso la fine e quindi i file più vecchi finirebbero in Z0. Questo tipo di approccio porta però ad una pesante frammentazione, e questo è il perché nessun altro oltre a DOS gestisce il disco in questa maniera).
md.
Ma il throughput aumenta sensibilmente?
Le prestazioni sono notevolmente migliori?
R: La risposta dipende dalla configurazione che si usa.
- Prestazioni di Linux MD RAID-0 e RAID-linear:
Se il sistema deve sopperire ad un alto numero di richieste di I/O, statisticamente qualcuna andrà su un disco e qualcun'altra su un altro. Quindi le prestazioni migliorano rispetto ad un singolo disco. Ma il miglioramento effettivo dipende molto dai dati, dalla dimensione delle strisce e da altri fattori. In un sistema con basso carico di I/O le prestazioni sono uguali a quelle di un singolo disco.
- Prestazioni in lettura di Linux MD RAID-1(mirroring):
MD implementa il bilanciamento in lettura. Quindi il codice RAID-1 distribuirà il carico su ognuno dei dischi nel mirror (due o più), effettuando operazioni alternate di lettura da ognuno di essi. In una situazione con basso carico di I/O questo non influisce per niente sulle prestazioni: dovrete aspettare che un disco abbia finito di leggere. Ma con due dischi in una situazioni di alto carico di I/O la performance in lettura può raddoppiare visto che le letture possono essere effettuate in parallelo da ciascuno dei due dischi. Per N dischi nel mirror, la prestazione può essere N volte migliore.
- Prestazioni in scrittura di Linux MD RAID-1 (mirroring):
Si deve attendere che la scrittura sia stata effettuata su tutti i dischi del mirror. Questo a causa del fatto che una copia dei dati deve essere scritta su ogni disco del mirror. Quindi le prestazioni saranno quasi uguali a quelle di un singolo disco in scrittura.
- Prestazioni in lettura di Linux MD RAID-4/5:
Statisticamente un dato blocco può trovarsi in un qualsiasi disco di una serie, e quindi le prestazioni in lettura di RAID-4/5 somigliano molto a quelle di RAID-0. Esse variano in funzione dei dati, della dimensione delle strisce e del tipo di utilizzo. Le prestazioni in lettura non saranno buone quanto quelle di una serie di dischi in mirror.
- Prestazioni in scrittura di Linux MD RAID-4/5:
Questo sistema è in genere considerevolmente più lento di un disco singolo. Questo a causa del fatto che la parità dovrà essere scritta su un disco e i dati su un altro. E per poter calcolare la nuova parità quella vecchia e i vecchi dati devono prima essere letti. Viene quindi effettuato un XOR fra i vecchi dati, i nuovi dati e la vecchia parità: questo richiede numerosi cicli di CPU e diversi accessi al disco.
R: Interessa più massimizzare il throughput o diminuire la latenza? Non vi è una facile risposta dato il grande numero di fattori che influenzano la performance:
- sistema operativo - l'accesso al disco è effettuato da un solo processo o da più thread?
- applicazioni - accedono ai dati in maniera sequenziale o in maniera casuale?
- file system - raggruppa i file o li distribuisce (ext2fs raggruppa insieme i blocchi di un file e distribuisce i file)
- driver del disco - numero di blocchi di read ahead (è un parametro impostabile)
- hardware CEC - un drive controller o più?
- hd controller - gestisce la coda di richieste multiple? Ha una cache?
- hard drive - dimensioni del buffer della memoria cache -- è abbastanza ampia da gestire la quantità e la velocità degli accessi in scrittura di cui si ha bisogno?
- caratteristiche fisiche del disco - blocchi per cilindro -- accedere a blocchi su differenti cilindri porta il disco ad effettuare molte operazioni di seek.
R: Poiché RAID-5 genera un carico di I/O che è uniformemente distribuito su diversi dischi, le prestazioni migliori si otterranno quando il set RAID viene bilanciato usando drive identici, controller identici e lo stesso (basso) numero di drive su ciascun controller. Si noti comunque che l'uso di componenti identici alzerà la probabilità di malfunzionamenti multipli e simultanei dovuti, per esempio a degli sbalzi repentini, al surriscaldamento o a problemi di alimentazione durante un temporale. Questo tipo di rischio può essere ridotto utilizzando dispositivi di marca e modello differenti.
R: Nell'uso dell'implementazione attuale (Novembre 1997) di RAID-4/5 è fortemente raccomandato che il filesystem venga creato conmke2fs -b 4096al posto della dimensione predefinita del blocco che è di 1024 byte.Questo perché l'attuale implementazione di RAID-5 alloca una pagina di memoria di 4K per ogni blocco del disco; se un blocco del disco fosse grande solo 1K il 75% della memoria allocata da RAID-5 per l'I/O non verrebbe usata. Se la grandezza del blocco del disco è uguale a quella della pagina di memoria il driver può (potenzialmente) usare tutta la pagina. Quindi, su un filesystem con dei blocchi da 4096 invece che da 1024, il driver RAID potrà potenzialmente gestire una coda di richieste di I/O quattro volte più grande senza usare memoria aggiuntiva.
Nota: le considerazioni precedenti non si applicano ai driver Software RAID-0/1/linear.
Nota: le considerazioni sulla pagina di memoria da 4K sono da applicare all'architettura Intel x86. Le dimensioni della pagina di memoria su Alpha, Sparc e altre CPU sono differenti; credo che siano 8k su Alpha/Sparc (????). Aggiustate le asserzioni precedenti in maniera da tenerne conto.
Nota: se il vostro filesystem contiene un grande numero di piccoli file (file più piccoli di 10KBytes), una frazione considerevole di spazio disco andrà perduta. Questo a causa del fatto che la dimensione dello spazio disco allocata dal filesystem è un multiplo della dimensione del blocco. Allocare dei blocchi di grosse dimensioni per dei piccoli file porta chiaramente ad uno spreco di spazio disco; quindi si potrebbe voler continuare ad utilizzare blocchi di piccole dimensioni, avere una una capacità di immagazzinamento maggiore e non preoccuparsi della memoria "persa" a causa del fato che le dimensioni della pagina e del blocco non combaciano.
Nota: molti sistemi ''tipici'' non contengono così tanti piccoli file. Comunque, anche se ci fossero centinaia di piccoli file, questo potrebbe portare alla perdita di 10 - 100 MB di spazio disco, che probabilmente è un compromesso accettabile per avere buone prestazioni se si usano hard disk multi-gigabyte.
Nel caso dei news server, ci potrebbero essere decine o centinaia di migliaia di piccoli file. In questi casi i blocchi di dimensioni minori, e quindi una maggiore capacità di immagazzinamento, potrebbero essere più importanti dell'efficienza dello scheduling di I/O.
Nota: esiste un filesystem sperimentale per Linux che memorizza piccoli file e pezzi di file in un solo blocco. Apparentemente questo influisce in maniera positiva sulla performance quando la dimensione media dei file è molto più piccola della dimensione del blocco.
Nota: Le prossime versioni potrebbero implementare dei dispositivi che renderanno obsolete queste discussioni. Comunque sia la loro implementazione è difficoltosa a causa del fatto che la allocazione dinamica a tempo di esecuzione può portare a dei blocchi; l'implementazione attuale effettua una pre-allocazione statica.
R: La grandezza del chunk è la quantità di dati contigui nel dispositivo virtuale che sono contigui anche nel dispositivo fisico. In questo HOWTO "chunk" e "striscia" sono la stessa cosa: quella che è comunemente chiamata "striscia" in altre documentazioni su RAID, nelle pagine del manuale di MD è chiamata "chunk". Si parla di strisce o chunk solo per RAID 0, 4 e 5 poiché le strisce non vengono utilizzate nel mirroring (RAID-1) e nella semplice concatenazione (RAID-linear). Le dimensioni della striscia influenzano il tempo di latenza (ritardo) nella lettura e nella scrittura, il throughput (larghezza di banda) e la gestione di operazioni indipendenti (l'abilità di provvedere a richieste di I/O simultanee che si accavallano)Posto che si usino il filesystem ext2fs e le impostazioni attuali del kernel che regolano il read-ahead, le strisce di grosse dimensioni risultano quasi sempre essere una scelta migliore rispetto a quelle di piccole dimensioni, e strisce di dimensioni confrontabili con la grandezza di un quarto di cilindro del disco potrebbero essere ancora migliori. Per capire questa affermazione, consideriamo gli effetti delle strisce grandi su file piccoli, e delle strisce piccole sui file grandi. La dimensione delle strisce non influenza le prestazioni durante la lettura di piccoli file: per una serie di N dischi il file ha 1/N probabilità di essere interamente contenuto in una striscia in uno dei dischi. Quindi sia la larghezza di banda che la latenza in lettura sono comparabili a quelle di un singolo disco. Ipotizzando il fatto che i file piccoli siano distribuiti in maniera statisticamente uniforme nel filesystem (e, se si usa il filesystem ext2fs, questo dovrebbe essere vero) il numero delle letture simultanee sovrapposte può essere circa N volte maggiore, senza collisioni significanti. Al contrario, se vengono utilizzate strisce di dimensioni molto ridotte e un file grande viene letto sequenzialmente, vi sarà un accesso in lettura da ogni disco del sottosistema. Nella lettura di un singolo file di grandi dimensioni, la latenza sarà almeno raddoppiata, e la probabilità che un blocco si trovi molto distaccato dagli altri aumenterà. Si noti comunque ciò che si ottiene: la larghezza di banda può aumentare di al più N volte nella lettura di un singolo file di grandi dimensioni, poiché N dischi lo leggono simultaneamente (se viene usato il read-ahead per mantenere attivi tutti i dischi). Ma vi è anche un effetto secondario controproducente: se tutti i drive sono occupati nella lettura di un singolo, grande file, il tentativo di leggere un secondo, un terzo file allo stesso tempo causerà un grave contenzioso, e degraderà le prestazioni a causa del fatto che gli algoritmi del disco lo porteranno ad effettuare numerosi seek. Quindi, strisce di grosse dimensioni danno quasi sempre i risultati migliori. L'unica eccezione è costituita dalla situazione nella quale si accede ad un singolo file di grandi dimensioni e si richiede la maggiore larghezza di banda possibile e si usa anche un buon algoritmo di read-ahead, in questo caso sarebbero desiderabili strisce di piccole dimensioni.
Si noti che in precedenza questo HOWTO ha raccomandato strisce di piccole dimensioni per i news spool o per altri sistemi con un gran numero di piccoli file. Questo è stato un cattivo consiglio, ed ecco perché: i news spool contengono non solo molti piccoli file ma anche file sommario di grandi dimensioni e grandi directory. Se il file sommario è più grande della striscia, la sua lettura comporterà un accesso su più dischi, rallentando il tutto come se ogni disco effettuasse un seek. Similmente, l'attuale filesystem ext2fs ricerca nelle directory in maniera lineare e sequenziale. Quindi, per trovare un dato file o inode, in media metà della directory verrà letta. Se la directory è distribuita su più strisce (su più dischi), la lettura della directory (per es. a causa del comando ls) potrebbe rallentare notevolmente. Un grazie a Steven A. Reisman < sar@pressenter.com> per questa correzione. Steve ha anche aggiunto:
Ho scoperto che l'uso di una striscia da 256k dà performance molto migliori. Sospetto che la dimensione ottimale sia quella di un cilindro del disco (o forse la dimensione della cache dei settori del disco). Comunque sia, oggi i dischi hanno zone di memorizzazione con un numero di settori variabile (e le cache dei settori variano anche fra differenti modelli). Non c'è un metodo per assicurarsi che le strisce non oltrepassino i confini del cilindro.I tool accettano le dimensioni delle strisce in KBytes. Conviene specificare un multiplo della dimensione della pagina per la CPU che si usa (4KB su x86).
mke2fs:
mke2fs -b 4096 -R stride=nnn ...
Cosa devo mettere al posto di nnn?
R: L'opzione-R strideviene usata per comunicare al filesystem le dimensioni delle strisce RAID. Poiché solo RAID-0,4 e 5 usano le strisce, e RAID-1 (mirroring) e RAID-linear non le usano, questa opzione ha senso solo per RAID-0,4,5. La conoscenza delle dimensioni delle strisce consente amke2fsdi dimensionare i blocchi e i bitmap degli inode in modo tale che non vengano a trovarsi tutti sullo stesso dispositivo fisico. Uno sconosciuto ha contribuito alla discussione scrivendo:L'ultima primavera ho notato che in una coppia di dischi uno aveva sempre un I/O maggiore e ho attribuito la cosa a questi blocchi di meta-dati. Ted ha aggiunto l'opzionePer un filesystem con blocchi da 4Kb e strisce da 256Kb, si potrebbe usare-R stride=in risposta alle mie spiegazioni e alla richiesta di una soluzione.-R stride=64.Se non volete affidarvi all'opzione
-R, potete ottenere un effetto simile in modo differente. Steven A. Reisman < sar@pressenter.com> scrive:Un'altra questione è l'uso del filesystem su un dispositivo RAID-0. Il filesystem ext2 alloca 8192 blocchi per ogni gruppo. Ogni gruppo ha il proprio set di inode. Se ci sono 2, 4, o 8 dischi questi blocchi si accumulano nel primo disco. Ho distribuito gli inode su tutti i drive impostando mke2fs in modo da allocare solo 7932 blocchi per gruppo.Qualche pagina di mke2fs non descrive l'opzione[-g blocks-per-group]usata in questa operazione
md negli script di avvio,
in modo tale che tutto parta automaticamente al boot?
R: Rod Wilkens < rwilkens@border.net> scrive:Quello che ho fatto è stato mettere ``Nel caso si usi raid-5 si dovrà fare attenzione al codice di uscita dimdadd -ar'' nel ``/etc/rc.d/rc.sysinit'' subito dopo il punto nel quale il kernel carica i moduli, e prima del controllo dischi di ``fsck''. In questa maniera si può mettere il dispositivo ``/dev/md?'' in ``/etc/fstab''. Quindi ho messo il comando ``mdstop -a'' subito dopo il comando ``umount -a'' nel file ``/etc/rc.d/init.d/halt''.mdadde, nel caso indichi un errore, eseguireper riparare i danni.ckraid --fix /etc/raid5.conf
md0? Questo per un news server, e io
ho 9 dischi... Non c'è bisogno che dica che ne servono molti più
di due. È possibile?
A: Si. (descrivere come)
R: Normalmente il RAID hardware è considerato superiore al RAID Software, poiché i controller hardware dispongono spesso di una capiente cache e possono effettuare una programmazione migliore delle operazioni in parallelo. Comunque il software RAID integrato può (e lo fa) avvantaggiarsi della sua integrazione con il sistema operativo.Per esempio, ... ummm. Oscura descrizione del caching dei blocchi ricostruiti nella cache del buffer tralasciata ...
È stato riferito che, su un sistema SMP con doppio PPro, software RAID supera le prestazioni di un hardware RAID di ben nota marca di un fattore variabile da 2 a 5.
Software RAID è anche un'opzione molto interessante per sistemi server ridondanti ad altro gradi di affidabilità. In questa configurazione due CPU sono collegate ad un set di dischi SCSI. Se un server si blocca o non risponde più l'altro server può eseguire
mdadd,mdrunemountper montare la serie di dischi RAID, e continuare le operazioni. Questo tipo di operazione a doppio controllo non è sempre possibile con molti controller RAID, a causa del fatto che il controller hardware mantiene la stessa configurazione.
R: No, a meno che non cambi il numero primario di versione. Una versione di MD x.y.z consiste di tre sottoversioni:x: Versione primaria. y: Versione secondaria. z: Livello di patch.La versione x1.y1.z1 del driver RAID supporta un sistema RAID con versione x2.y2.z2 nel caso (x1 == x2) e (y1 >= y2). Le versioni che differiscono per il solo livello di patch (z) sono concepite in modo da essere compatibili.Il numero di versione secondario viene incrementato quando la struttura del sistema RAID viene modificata in modo tale da renderla incompatibile con le vecchie versioni del driver. Le nuove versioni del driver manterranno la compatibilità con i vecchi sistemi RAID.
Il numero primario di versione viene incrementato quando non vi sono più ragioni per continuare a supportare i vecchi sistemi RAID nel nuovo codice del kernel.
Per quanto riguarda RAID-1, è improbabile che la struttura del disco o dei superblock venga alterata entro breve termine. Le ottimizzazioni e le nuove funzioni (ricostruzione, tool che implementino il multithread, hot-plug ecc.) non vanno a modificare la struttura fisica.
mdstop /dev/md0 dice che il dispositivo è occupato.
R: C'è un processo che ha un file aperto su/dev/md0o/dev/md0è ancora montato. Chiudere il processo o eseguireumount /dev/md0.
R: Vi è anche un nuovo programma di utilità chiamatoiotracenella directorylinux/iotrace. Esso legge/proc/io-tracee analizza/riporta il suo output. Se credete che le prestazioni dei vostri dispositivi a blocchi siano poco convincenti, date un'occhiata all'output di iotrace.
SPEED_LIMIT
impostato a 1024K/sec. Che significa? Questo rallenta le prestazioni?
R:SPEED_LIMITviene usato per regolare la ricostruzione RAID quando essa avviene in automatico. Semplificando, la ricostruzione automatica permette di effettuaree2fsckemountsubito dopo uno shutdown sporco, senza prima dover eseguireckraid. La ricostruzione automatica viene usata anche dopo la sostituzione di un disco rotto.Per evitare un sovraccarico del sistema mentre la ricostruzione è in corso, il processo di ricostruzione controlla la velocità alla quale essa avviene e la rallenta se è troppo veloce. Il limite di 1M/sec è stato scelto arbitrariamente come ragionevole velocità che consente alla ricostruzione di finire in un tempo accettabile, con solo un leggero carico del sistema, in modo tale che gli altri processi non vengano disturbati.
R: La sincronizzazione dei dischi viene usata per far girare più hard disk esattamente alla stessa velocità, in modo tale che le loro superfici siano sempre perfettamente allineate. Questo metodo viene usato da qualche controller hardware per migliorare l'organizzazione degli accessi in scrittura. Tuttavia, per quanto riguarda Software RAID, questa informazione non viene usata e la sincronizzazione dei dischi può addirittura influire negativamente sulle prestazioni.
R: Leonard N. Zubkoff risponde: È veramente veloce, ma non c'è necessità di usare MD per mettere in strip le aree di swap. Il kernel usa automaticamente le strisce su diverse aree di swap a priorità uguale. Per esempio, la seguente configurazione di/etc/fstabmette in stripe le aree di swap su cinque drive suddivisi in tre gruppi:/dev/sdg1 swap swap pri=3 /dev/sdk1 swap swap pri=3 /dev/sdd1 swap swap pri=3 /dev/sdh1 swap swap pri=3 /dev/sdl1 swap swap pri=3 /dev/sdg2 swap swap pri=2 /dev/sdk2 swap swap pri=2 /dev/sdd2 swap swap pri=2 /dev/sdh2 swap swap pri=2 /dev/sdl2 swap swap pri=2 /dev/sdg3 swap swap pri=1 /dev/sdk3 swap swap pri=1 /dev/sdd3 swap swap pri=1 /dev/sdh3 swap swap pri=1 /dev/sdl3 swap swap pri=1
R: In molti casi la risposta è si. L'uso di controller multipli per accedere in parallelo al disco consentirà un incremento delle prestazioni. Ovviamente il miglioramento effettivo dipenderà dalla vostra particolare configurazione. Per esempio è stato riferito (Vaughan Pratt, gennaio 98) che un singolo Cheetah da 4.3Gb collegato ad un Adaptec 2940UW può arrivare ad un trasferimento di 14Mb/sec (senza l'uso di RAID). Installando due dischi su un controller e usando una configurazione RAID-0 si arriva ad una prestazione di 27Mb/sec.Si noti che il controller 2940UW è un controller SCSI "Ultra-Wide", capace di un trasferimento teorico di 40Mb/sec. quindi la velocità di trasferimento misurata non sorprende. Tuttavia un controller più lento collegato a due dischi veloci potrebbe fare da collo di bottiglia. Si noti anche che molte periferiche SCSI out-board (ad es. i tipi con le connessioni utilizzabili "a caldo") non possono arrivare a 40Mb/sec a causa del rumore elettrico e di quello dovuto al cablaggio.
Se state progettando un sistema a controller multipli tenete a mente il fatto che molti dischi e molti controller funzionano normalmente al 70-85% della loro velocità massima.
Si noti anche che l'uso di un controller per disco può ridurre la probabilità che il sistema si blocchi a causa di un malfunzionamento dei cavi o del controller (Teoricamente -- questo accade solo nel caso in cui il driver del controller riesca a gestire ordinatamente un controller rotto. Non tutti i device driver SCSI sembrano riuscire a gestire una simile situazione senza andare in panico o bloccarsi in altra maniera).