Newsgroup: it.comp.os.linux.sys
Titolo: raid si o raid no?

Ho due macchine IBM Xseries sulla quali in una devo installare un server
proxy per permettere la navigazione in internet ai client dell'azienda,
mentre nell'altro devo installare un server mail pubblico.
Entrambe le macchine sono dotate di raid 5 hardware.
Mi chiedevo se e' opportuno lasciare o no il raid.
Grazie.


Decisamente si per il server mail, vorrai mica perdere tutte  le email a 
causa di un disco rotto? E poi perdere ore per ripristinare tutto da un 
backup...
Per il proxy il discorso è leggermente diverso, non essendovi dati da 
salvare ma solo le configurazioni potresti anche pensare di non usare il 
raid. In ogni caso di consiglio di usarlo sempre per evitare di dover 
reinstallare tutto a causa di un solo disco rotto.

bla wrote:

La reistallazione del proxy non e' un grosso problema, io pensavo che, per
quest'ultimo, sarebbe stato meglio togliere il raid per guadagnare
qualcosina a livello di prestazioni del disco, se non sbaglio il raid 5,
sebbene negli IBM Xseries si controllato a livello hardware, rallenta
leggermente le operazioni di scrittura su disco.

 leggermente le operazioni di scrittura su disco.
Da quel che so il raid (escluso lo stripe) perde sempre un pò di
prestazioni ... ma guadagni in affidabilità, e secondo me è un buon
compromesso!
-- 
------------------------------------------
Togliere aldruz- per rispondermi via e-mail
------------------------------------------

 compromesso!
Appunto, per un proxy la cosa migliore sarebbe il massimo delle prestazioni
dei dischi se poi si verifica qualche problema non succede niente se si
perde la cache del proxy. 

 prestazioni
Sbagliato. In lettura qualsiasi RAID aumenta le prestazioni. In scrittura,
alla peggio, vai come un solo disco.
Ciao,
-- 
Daniele Orlandi

try wrote:

Lo scopo di proxy è di fornire velocemente dei dati in cache quindi il raid
va bene. La lentezza in scrittura non dovrebbe essere un problema dato che
lo scopo di una cache è di esssere scritta una volta e letta molte volte.
Comunque se vuoi il massimo delle prestazioni passa ad un raid 0, massima
velocità con qualche rischio in più.
-- 
Nat



Se un disco si rompe quando tu non ci sei o quando sei impegnato?
Secondo me non vale mai la pena lasciare gli utenti senza un servizio
solamente per guadagnare qualche byte in piu' di storage.
ciao,
luigi


Pero` potrebbe valere la pena per aumentare le prestazioni della cache 
del proxy (o forse no) configurandola in RAID0 (solo la cache, mentre in 
RAID1 il resto - ti bastano 2 dischi per fare tutto cio`).
Oppure meglio del RAID5, per quanto riguarda le prestazioni in lettura, 
potrebbe essere il RAID1, anche se hai bisogno di piu` spazio disco.
L'ideale potrebbe essere il RAID 10 che ha le stesse esigenze di spazio 
del RAID1, ma prestazioni migliori, in ogni caso hai bisogno di piu` 
spazio disco che col RAID5.
Andrea

 leggermente le operazioni di scrittura su disco.
facendo 2 conti sulla banda ti conviene solo se hai una connessione
mostruosa.....
lascia il raid 5.
-- 
Quelli che istruiscono bene i figli devono essere onorati piu' dei
genitori: questi danno solamente la vita, quelli l'arte di vivere
meglio.
                -- Aristotele

 alla peggio, vai come un solo disco.
Sulla lettura siamo d'accordo.
Sulla scrittura no.
Ad esempio con tre dischi in raid, se non sbaglio hai questa situazione:
Disco 1:   Dato A
Disco 2:   Dato B
Disco 3:   Parita' tra dato A e dato B
Prima di scrivere il dato B sul disco 2 e quindi la parita' sul disco 3
occorre leggere il dato A sul disco 1.
Quindi la scrittura deve essere preceduta da una lettura e di conseguenza le
prestazioni in scrittura peggiorano.
P.S.
Agli esperti le correzioni del caso.
-- 
Stefano L.

Stefano L. ha scritto:

Il dato A, essendo già in memoria, non deve essere riletto dal disco, 
quindi:
- scrive il dato A sul disco 1
- scrive il dato B sul disco 2
- scrive la parità sul disco 3
Se hai SCSI/SATA le scritture sono parallele e hai la massima banda 
passante, se hai ide le scritture sono seriali e hai un decadimento 
delle prestazioni.
Idem in lettura, SCSI/SATA ti permettono ua banda passate pari alla 
somma della banda passante per ogni disco.
Se poi hai un controller dedicato al RAID, risparmi anche 
sull'occupazione della CPU.

 - scrive la parità sul disco 3
E come fa' il dato A a essere in memoria se non e' stato prima letto dal
disco ?
L'unico dato che io devo scrivere e' il dato B, il dato A e' sul disco a
seguito di elaborazioni svolte in precedenza e ormai non e' piu' nelle
cache.
-- 
Stefano L.

 
Mi hai fatto venire un dubbio.
Io pensavo che il RAID 5 scomponesse il dato+parità nei dischi 
dell'array, invece la gestione è la stssa dello striping + parità 
distribuita su dischi diversi.
Quindi avevi ragione tu: sei io cambio B devo rileggere A per calcolare 
la parità, idem se cambio A devl rileggere B per ricalcolare la parità.

 occorre leggere il dato A sul disco 1.
Hai ragione, però si tratta di operazioni che vengono eseguite da dischi
diversi, quindi possono essere rese parallele. Diciamo che il calcolo non è
banale come quello in lettura.
Ciao,
-- 
Daniele Orlandi

Daniele Orlandi scrisse

Parallele sino a un certo punto...
Prima legge A.
Poi calcola la parita'
Poi scrive B e parita'
Se il Raid e' hardware fa tutto il controller e di certo lo fa alla svelta,
ma non puo' scrivere prima di aver letto.
E' la classica legge detta "Botte piena o Moglie ubriaca"
Raid 1 = Massime prestazioni ma grande spreco di spazio disco (50%)
Raid 5 = Minore spreco di spazio disco ma minori prestazioni in scrittura.
 
-- 
Stefano L.

 svelta, ma non puo' scrivere prima di aver letto.
Già... ma non hai solo un'operazione alla volta. Di certo la latenza di ogni
singola richiesta aumenta ma il throughput non è necessariamente
compromesso.
Ciao,
-- 
Daniele Orlandi

 Gli smartarray di compaq sono bellissimi...
Ed e' proprio Compaq (o Hp che dir si voglia) che a pagina 7 di questo
documento sugli smart array:
http://h200005.www2.hp.com/bc/docs/support/SupportManual/c00257511/c00257511.pdf
espone una tabella in cui dice che le prestazioni in scrittura del raid 5
sono inferiori.
-- 
Stefano L.

 sono inferiori.
Io leggo solo che sono inferiori a RAID 0 e 1, e vorrei ben vedere che non
sia così.
Quello che ho detto è che la scrittura, nel caso peggiore di RAID (il 5),
non è peggiore di un singolo disco. Mi sono sbagliato, nel senso che
quantomeno la latenza aumenta, ma complessivamente non è tanto inferiore a
quella di un singolo disco.
Ciao,
-- 
Daniele Orlandi

quella di un singolo disco.
Mi permetto di intervenire. La discussione sulle performance dei
controller SMART (e assimilati) e' pura accademia, a meno che non
stiamo considerando controller precedenti la gia' vetusta SMART 3200.
Ho appena fatto un'installazione con una SMART 6400 collegata a 6
dischi da 300 Gb in ADG, Advanced Data Guard, un RAID distributed data
guard con 2 "dischi di parita'" (lo so che la parita' non e' su un
disco, ma e' per farmi capire). Visto che ci ho potuto "giocare"
alcuni giorni con il serverino, ho provato a fare varie installazioni
con i 6 dischi da 300 e non ho notato differenze sostanziali nemmeno
tra un 1+0 e un ADG.
La bottom line del discorso e' che questi discorsi di performance
hanno un senso su server _veramente_ heavy duty, in tutte le altre
condizioni (
p.es
. file server o server di servizi Internet) le
differenze non si vedono per nulla e, comunque, e' un tradeoff piu'
che accettabile per la continuita' del servizio.
ciao,
luigi

 tra un 1+0 e un ADG.
Questo è l'effetto della (o delle, se più di una in cascata) cache dei 
controller. Se fai stress test, devi portare il controller nella 
condizione di lavorare con buffer sempre pieno, altrimenti ti ritrovi a 
misurare non la velocità dell'array ma quella della cache, che 
ovviamente è la stessa indipendentemente dall'array che ha sotto.
In quel caso, la cache si riempie sempre alla stessa velocità; a 
cambiare con il tipo di array è la rapiditià con cui si *svuota*...	
-- 
Здрасти!
cat: .signature: No such file or directory

cambiare con il tipo di array è la rapiditià con cui si *svuota*...	
Se c'e' una cache non vedo perche' non dovrei usarla. Quello che mi
interessa non e' un benchmark di laboratorio con condizioni irreali,
ma un test sul campo in condizioni di "vita normale" della macchina.
Se la cache raggiunge raramente il "full", tanto meglio, vuol dire che
le performance ne trarranno beneficio.
Quello che voglio dire e' che va bene la teoria, ma poi alla fine i
server devono essere connessi al mondo reale, un mondo in cui il
ritardo dovuto alla scrittura ridondante su un array non e' percepito,
ma e' percepito un server che va fuori servizio.
Lo stress test va bene come dato di laboratorio, ma se nel corso della
sua vita reale il server non raggiunge mai le condizioni dello stress
test, il test non e' consistente con le condizioni d'uso del server e
non puo' essere usato come campione per l'uso quotidiano.
ciao,
luigi

 non puo' essere usato come campione per l'uso quotidiano.
Vero, ma allora stai diniegando il senso di qualsiasi bench... :-D
Non che ti dia torto, ma quei bench si fanno per avere una idea di cosa 
conviene usare per tenersi più lontano possibile dai limiti operativi 
dell'oggetto che usi.
Ha senso, quindi, vedere quale sia il limite superiore delle varie 
soluzioni. Non lo tocchi? Meglio, ma non ha nulla a che fare con 
l'esistenza e il "posizionamento" di tale limite.
Se devo scriverci sopra la mailbox della nonna, un disco ATA 33 ha le 
stesse prestazioni di un DAS con 10 dischi in raid 1+0 e 512MB di cache 
sul controller...
Il che non vuol affatto dire che siano soluzioni equivalenti.
Il fatto di andare a vedere quale soluzione scala più alto non è puro 
diletto per i numeri.
Immagina di avere un DAS come quello sopra.
512MB di cache su controller ti permettono di scrivere, appunto, 512 MB 
alla velocità consentita dal BUS. E poi? Poi la cache impiegherà, a 
svuotarsi, un tempo che dipende direttamente dalla velocità alla quale i 
dischi scrivono.
Quando arriverà la prossima pacca di 512 MB la cache avrà già avuto il 
tempo di terminare il suo lavoro e svuotarsi?
Dipende, appunto, dai dischi, e dalla frequenza alla quale attendi dati 
nella tua realtà. Se la cache è ancora piena, la macchina inizia 
lentamente a rallentare, fino al momento in cui la cache sarà sempre 
piena, la velocità diverrà solamente quella consentita dai dischi e il 
sistema inizierà a faticare.
Probabilmente, quello che va bene per te non va altrettanto bene per me.
Non tutti abbiamo le stesse esigenze...


nella tua realtà.
...e dal sistema operativo+applicativo che gira sopra: devi
considerare anche l'altra parte del mondo. Spesso per risolvere un
problema del genere e' sufficiente aggiungere RAM al sistema perche' i
dati spesso nei server non arrivano ad infinitum.
ciao,
luigi

 dati spesso nei server non arrivano ad infinitum.
No. Aumenti solamente la durata del periodo "buono", ma non il risultato 
finale. Se i dati continuano ad arrivare più velocemente di quanto la 
macchina riesca a scriverli, prima o poi le risorse saturano. 
Indipendentemente da quali sono le risorse.
Dipende, appunto, dal tipo di utilizzo che fai del sistema, e pertanto 
non puoi dare una regola fissa.


 occorre leggere il dato A sul disco 1.
Tiro ad indovinare (non conosco con precisione gli algoritmi del raid):
raid con 5 dischi (e' piu' interessante)
Situazione iniziale:
Disco 1: dato A
Disco 2: dato B
Disco 3: dato C
Disco 4: dato D
Disco 5: parita' A+B+C+D
Devo scrivere E sul secondo disco
Procedura:
- leggo B dal secondo disco e la relativa parita' sul quinto disco
- "sottraggo" B dalla parita' e ricalcolo la parita' con E
- scrivo E sul secondo disco e la nuova parita' sul quinto disco
In questo modo potrei avere l'array di N dischi e le operazioni sarebbero
sempre due letture e due scritture...
Il caso piu' semplice sarebbe la riscrittura di A,B,C,D, per cui calcolo
direttamente la parita' e faccio solo 5 scritture...
Adesso devo correre a brevettarlo prima che lo faccia qualcun altro... :-)
ciao
Michele

 che accettabile per la continuita' del servizio.
thread troppo lunghi si perde sempre il filo del ragionamento iniziale.
la bottom line e' che la domanda era stata posti per un proxy, non per il
file server.
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/