[gl-como] Server e RAID (?)

Pirla the.pirla@flashnet.it
Mer 8 Mar 2006 11:20:08 CET


Il giorno mar, 07/03/2006 alle 10.43 +0100, Riccardo Penco ha scritto:
> Pirla ha scritto:

> Premetto che non ho esperienze in merito.
> Da quello che avevo capito pero', raid0 quando deve salvare un file ne 
> scrive sempre una parte su ogni disco che compone il raid (il motivo per 
> cui e' tanto veloce). Se si rompe un disco io perdo parte 
> dell'informazione di qualsiasi file nel filesystem.
> Per come avevo capito, invece, LVM inizia a scrivere sul primo disco, 
> quando esaurisce lo spazio, passa al secondo e cosi' via. In questo modo 
> tutte le informazioni (i byte) di quasi tutti i file sono contenuti in 
> un singolo disco. Fanno ovviamente eccezione i file che sono a cavallo 
> di due dischi. Quando si rompe un disco io dovrei perdere solo i file 
> contenuti (completamente o in parte) nello stesso.
> [Cosa] ho capito male?
Diciamo che hai capito *molto* male un po' tutto.
Cominciamo da un presupposto di fondo.
Tu ragioni a livello di file, invece devi ragionare a livello di disco
(e quindi di blocchi del disco).

Detto questo vediamo come funzionano i principi raid, opartendo
dall'hardware e poi passando al software.

Un controller intelligente che ti permette di gestire i raid si comporta
in questo modo.
     1. Riconosce una serie di dispositivi di memorizzazione
        (presupponiamo che siano geometricamente uguali anche se non è
        importante), e ti permette (quando ancora il sistema operativo
        non è partito) di gestirli e di aggregarli in raid. Prendiamo in
        considerazione il raid 0 di 2 dischi (anche se nessuno
        praticamente lo fa) e il raid 1 di 2 dischi.
     2. A questo punto il configuratore decide di fare un raid 0. Lo
        comunica al controller ed il controller scrive alcune
        informazioni sui dischi. A questo punto presenta al PC/Server un
        disco fisico formato dall'unione dei due dischi. Questo disco
        logico avrà la dimensione data dalla somma dei due dischi
        fisici. Avrà una geometria che il controller definisce. Avrà uno
        stripe size ben definito (prendiamo per esempio 256 KB).
     3. Il bios del PC/Server fa partire un sistema operativo dicendogli
        di avere un disco che ha una certa geometria (mediata dal
        controller che tradurrà poi le informazioni provenienti dal S.O.
        verso i vari dischi fisici che compongono il disco logico).
     4. A questo punto il sistema comincia ad accedere al disco logico.
        Ogni richiesta di blocchi viene mediata dal controller che sa
        che lo stripe size è di 256KB. Quando il sistema chiede di
        leggere o scrivere un blocco allora il controller decide dove
        sta il blocco e lo passa al sistema operativo. Naturalmente le
        performance dipendono da molti fattori ma ignoriamo questo e
        pensiamo al fatto che si ha un accesso pressocchè parallelo in
        entrambi i dischi. Se un file ipotetico sta dentro un blocco che
        è più piccolo dello stripe size, è molto probabile che sia
        memorizzato su un unico disco, ma se è grande verrà spalmato su
        più dischi. Questo comporta che la mancanza di uno dei due
        dischi non ti permetterà di accedere più a nulla, proprio perché
        le info sono sparpagliate e non c'è modo di ricostruirle senza
        il disco che hai perso. Anzi, il controller proprio fallisce
        l'inizializzazione del raid e non viene presentato nessun disco
        logico al sistema.
     5. Nel caso di raid 1 invece il controller non spalma le info sui
        dischi ma le duplica, quindi ogni scrittura avviene in
        contemporanea (non sempre è vero) su entrambe le meccaniche. In
        caso di lettura, il dato viene letto dalla meccanica che ha la
        testina più vicina al blocco di disco da leggere. Se perdi un
        disco il tuo raid è ancora in grado di funzionare e il disco
        logico viene presentato lo stesso come se nulla fosse. Il tutto
        però in una situazione di precarietà perché non hai più la
        protezione.

Il raid fatto a livello software funziona (e deve funzionare)
esattamente nello stesso modo, altrimenti non sarebbe raid ma sarebbe
altro. Solo che il tutto è fatto dopo che il sistema operativo è
partito. Naturalmente le implementazioni software sono più lente, ma non
è detto che siano meno sicure. Se sono fatte bene e il sistema è stabile
non ci sono problemi.

Per ulteriori dettagli o per approfondire molto le nozioni ti consiglio
di partire da wikipedia -> raid ed andare a vedere la storia del raid.
Altre ricerche su internet sono possibili ma non le ho fatte :-)

Veniamo ad LVM.
In questo caso faccio riferimento ad lvm di linux (che è molto simile a
quello di HP) ma ce ne sono molti altri (Veritas Volume Manager, AIX LVM
di IBM, Soltice Disk Suite di Sun Solaris ecc.ecc.)

Diamo per assunti alcuni argomenti.
     1. Il S.O. riconosce dei volumi (per esempio sda ed sdb) e questi
        vogliono essere usati per generare un unico Volume Group.
     2. Il Volume Group in questione verrà diviso in 4 Logical Volumes
        uguali
     3. Su ogni Logical Volumes verrà creato un file system.

Come deve ragionare in questo caso un configuratore? Servono le seguenti
definizioni
PV (Physical Volume)
        Rappresenta un volume fisico (e quindi un disco o una partizione
        di questo disco opportunamente configurata).
VG (Volume Group)
        Insieme logico di uno o più PV
LV (Logical Volume)
        Insieme logico di entità (LE) che rappresentano il volume sul
        quale il Sistema Operativo può agire ad alto livello.
PE (Physical Extent)
        Parte di un PV. Rappresenta l'entità minima di un PV
        utilizzabile per comporre qualsiasi altra cosa
LE (Logical Extent)
        Parte logica di un LV. Rappresenta l'entità minima di un LV
        utilizzabile.
Quindi andiamo con ordine.

Si deve definire un PV. Per cui bisogna generare una partizione di tipo
LVM sul disco fisico /dev/sda1 /dev/sdb1 e poi creare il PV.
In questo modo viene marcato un identificativo sulla partizione che
individuerà univocamente il PV tra tutti.
Fatto questo il PV generato viene automaticamente diviso in PE. Ogni PE
ha una dimensione predefinita (o definita) ma tutti risiedono sullo
stesso disco fisico.
Supponiamo quindi che abbiamo i 2 dischi con 100 PE ciascuno

A questo punto dobbiamo definire il VG.
Creiamo un VG (nome a caso vg01) composto da due PV (/dev/sda1
e /dev/sdb1).
A questo punto il VG è composto da 2 PV, avrà una certa dimensione (la
somma dei due) ed avrà un certo numero di PE (200 per noi).
All'inizio saranno tutti free e nessuno allocato.
Ma cosa ha fatto il sistema fino a questo punto (o meglio il Logical
Volume Manager)?

Non ha fatto altro che marcare le due partizioni con un identificativo
univoco che servirà sempre in seguito. Poi ha creato una struttura in
una particolare directory del S.O. (ed in RAM) che permette di capire
come è formato il VG.
Senza le informazioni sul VG memorizzate da qualche parte cosa
succederebbe? Che nessuno potrebbe leggere il VG perché non saprebbe
come è mappato.
Allora per salvarsi anche da questa eventualità le info vengono scritte
su tutti i PV che compongono il VG.

Già in questa fase, se perdo un disco, non posso aprire il VG, perché il
VG è definito da un certo numero di PV ben precisi, e se non ci sono ho
un errore.
Con alcuni comandi superfighi posso aprirlo lo stesso, senza aprire i
singoli LV e poi cercare di fare qualcosa per recuperare il possibile,
ma in linea di principio, in una situazione reale questo è molto
difficile se non ho altri meccanismi di protezione.

Andiamo avanti e creiamo il primo LV. Decidiamo di allocare per lui 50
PE.
con il comando lvcreate creiamo il LV /dev/vg01/lv01 da 50 PE (o meglio
LE) perché in questa fase i PE vengono tramutati in LE.
Questa trasformazione (trasparente in questo caso è la cosa più
impotante). Normalmente infatti ogni LE è corrispondente ad un PE.
Ma mentre per il LV tutti i LE sono consecutivi, per il VG questo non è
vero. Si potrebbe quindi avere questa corrispondenza
LE	PE su sda	PE su sdb
00	00
01	01
02	02
03			01
04	03
05			02
06			03
... ecc ecc
Ecco perché viene effettuata la trasformazione.
Inoltre se il LV che creiamo è mirrorato avremo questa corrispondenza
LE	PE su sda	PE su sdb
00	00		00
01	01		05
02	02		06
03	06		01
04	03		07
05	04		02
06	05		03
... ecc. ecc.
Questo è quello che ti salva, se perdi un disco, ogni LE di un LV è
duplicato anche sull'altro. (raid 1 ma a livello di LV e non di intero
disco)
Questo permette di avere la situazione per cui hai un LV molto
importante che è mirrorato, ed un altro che è non mirrorato.

Inoltre il LV può essere stripato a livello di LE, il che vuol dire che
LE consecutivi non stiano sullo stesso PV, oppure a livello di blocco
(cosa più complicata ma anche più performante in quanto il PE size
standard è superiore a 4KB, mentre lo stripe size potrebbe essere anche
di 512Byte), ma quì andiamo troppo in la e diventa difficile spiegare il
tutto semplicemente scrivendo.

Se non è chiaro qualcosa chiedi pure.... :-)

> Questo a prescindere da marca / modello di disco o ce ne sono di piu' 
> resistenti?
Tieni conto che quando un disco ti costa almeno 750€ e forse più,
pretendi il meglio sul mercato.

So che hitachi sta presentando dischi SATA in bagno d'olio, ma
sinceramente direi che a parità di superfice, per aumentaro lo spazio
utile bisogna aumentare la densità di dati, e quindi è facile che si
abbiano errori di lettura scrittura.

-- 
Ciao
        Pirla

Per rispondere in E-mail the (punto) pirla (chiocciola) flashnet.it
*** un bacio ai pupi ***

---> Linux user since yesterday <---
--->     Linux User #389536     <---



Maggiori informazioni sulla lista gl-como