Newsgroup: it.comp.hardware.storage
Titolo: RAID e cache ... si o no ?

Salve a tutti.
Avrei bisogno di capire se conviene o meno abilitare la cache sugli
hard disk in caso di raid1 (mirror).
Ho letto qualche post qua e la e molti consigliano di disabilitarla
per evitare possibili e frequenti ricostruzioni dell'array in caso di
problemi, per esempio, all'alimentazione e/o a crash improvvisi di
sistema.
E' vera questa cosa ?
Grazie


In qualche modo si, anche se per un RAID-1, con due dischi,
protrebbe non essere una situazione cosi` critica.
Il fatto e` che, con la cache abilitata, il controller non
puo` sapere lo stato del disco, per cui se il tutto si ferma
_prima_ che il disco venga effettivamente scritto, l'array
non e` piu` in stato consistente e neanche recuperabile.
Almeno con un RAID-1 con 2 dischi (servono almeno 3 dischi,
od un RAID-6, per avere qualche possibilita`).
D'altro canto, senza cache, si perde abbastanza in prestazioni,
per cui bisogna decidere di che morte si vuole morire...
Diciamo inoltre che "frequenti ricostruzioni" e "in
caso di problemi", sono due cose che non vanno troppo
daccordo, poiche` ne consegue "frequenti problemi".
Se il sistema va in crash frequentemente, immagino
che la questione cache diventi secondaria...
bye,
-- 
piergiorgio

Sembra che Goldrake abbia detto :

Si è vera... ma onestamente le probabilità di perdere dati
anche in caso di black out rimane comunque bassa. Per quanto
mi riguarda quando allestisco array RAID, la cache in scrittuta
l'abilito sempre.


Non mi e' chiara ancora una cosa..... :
La cache e' sia sugli hard disk che sul controller ?
Se fosse cosi', conviene disabilitare quella degli hard disk e
lasciare quella del controller ?
Se uno volesse dormire sonni tranquilli... che deve fare ... ?
Disabilitare tutte le cache (sia hd che controller) e andare a dormire
rilassato ?
:-)
Grazie

 Se uno volesse dormire sonni tranquilli... che deve fare ... ?
Spegenere tutto... :-)
bye,
-- 
piergiorgio

  :-)
Direi solo la seconda...:D

 
rotfl

 Spegenere tutto... :-)
Com'e' umano lei...... :-)
Ho capito... non dormiro' sonni tranquilli.....
Ma chi me l'ha fatto fare di scegliere 'sto lavoro... non potevo
aprire un agriturismo !!??!?!
Ciao a tutti e grazie

si puoi avere problemi.
ma se usi una sk dotata di bbu (batteria tampone che memorizza per
almeno 24/48 ore la cache) non hai problemi, ne in caso di blocco del
SO, ne in caso di black-out.
un solo problema, le schede con bbu sono di fascia elevata, e non sono
proprio molto economiche ;)
ps non confodere la bbu con l'ups. in caso di blocco del SO e
conseguente reboot, la bbu mantiene integra la cache che viene
aggiornata appena i dischi sono disponibili.
ciao 
-- 
my blog: 
www.r3lative.it


Infatti... misà che appena vedrà il costo di questi controller l'OP 
avrà ancora meno sonni tranquilli, LOL.

Lorenz wrote:

hehe
ma è anche vero che le prestazioni sono decisamente di un'altro livello
;)
-- 
my blog: 
www.r3lative.it

 proprio molto economiche ;)
Immagino, quindi, che il controller raid on-board di serie dell' HP
Proliant ML150 G5 non rientri in quella categoria... vero ?
Mediamente quanto costa un controller raid "serio" ?
Grazie

 Mediamente quanto costa un controller raid "serio" ?
devi vedere il listino hp.
io ho avuto grossi problemi con hp (sono stato sfortunato) che non mi
voleva riconoscere la garanzia di un server (problemi ai cestello dei
dischi) in quanto il controller non era hp.
quindi usa i controller hp (io per inciso ho smesso)
comuqnue il prezzo dipende da quanti canali, parti da 3/400 a salire
-- 
my blog: 
www.r3lative.it


Ricapitolando..... da quello che ho capito, nei server entry level,
conviene avere un bell'hard disk coi maroni e pianificare dei backup
frequenti del sistema, piuttosto che un raid del menga... che porta
solo problemi.
O no... ??

Goldrake wrote:

no, decisamente no. il raid è indubbiamente un sistema utile per
aumentare l'affidabilita di un server, il discorso sul controller è che
semplicemente quelli forniti di base sono appunto di base, quindi non
permettono prestazioni al top (ma in ogni caso di tutto rispetto). con
un controller al top, oltre all'affidabilita hai anche prestazioni
superiori.
poi per il backup. perché si continua a parlare di backup mentre si
parla di raid ??? sono due cose molto diverse, con scopi molto diversi.
RAID = affidabilita, prestazioni
BACKUP=salvaguardia dei dati.
quindi il backup DEVE essere fatto in ogni caso, deve essere studiato
un piano/politica valido di backup, comprensivo di n° volumi (logici,
fisici, virtuali, quello che volete, basta che siano tanti, quanti ne
servono), e non ultimo deve essere pianificato una politica di
ripristino (in ambiente di prova) per verificare la solidita del backup.
-- 
my blog: 
www.r3lative.it

 ripristino (in ambiente di prova) per verificare la solidita del backup.
Quello l'ho fatto !
:-)
Ciao e grazie

 :-)
attenzione che politica non vuol dire lo fai una volta e basta, ma che
devi programmare il ripristino ogni x tempo per verificare che i dati
sono integri e che viene salvato tutto quanto serve (sembra stupido, ma
no  lo è, e di solito ci si accorge del cosa manca solo quando è tardi).
io ad esempio consiglio sempre una politica di backup 5d, 4w, 3m, con
un ripristino su vm mensile.
ovvero 
lu-ve: backup giornaliero (5 volumi/copie)
sa : backup settimanale (4 volumi/copie)
1° del mese : backup mensile (3 volumi/copie)
e di norma verso il 15 del mese faccio un ripristino su macchina
virtuale di un backup.
-- 
my blog: 
www.r3lative.it

 no  lo č, e di solito ci si accorge del cosa manca solo quando č tardi).
Non e` affatto stupido, anzi e` una concetto
fondamentale che a volte sembra sfuggire: il
backup serve solo se e` ripristinabile.
Altrimenti anziche` nastri/CD/DVD/HD basterebbe
fare una copia di tutto su /dev/null, che avrebbe
anche il vantaggio di non riempirsi mai... ;-)
bye,
-- 
piergiorgio

 anche il vantaggio di non riempirsi mai... ;-)
attento che potrei mandardi dei geni che coglierebbero al volo il tuo
consiglio ;) salvo poi ...
ciao ;)
-- 
my blog: 
www.r3lative.it



Ok... ecco qua un genio che arriva..... :-)
Che cos'e' 'sto /dev/null ???
Grazie

 Che cos'e' 'sto /dev/null ???
E` un dispositivo bellissimo!
Tu puoi scriverci tutto quello che vuoi, quanto
vuoi e lui non batte ciglio, funziona sempre.
Un po' un "write-only memory", se vogliamo.
Scherzi a parte, e` un file speciale di Unix che, in
scrittura, legge i dati e li butta via, in lettura
restituisce, mi pare, EOF (End Of File).
Ha diverse applicazioni, per esempio benchmark,
oppure per zittire qualche programma troppo
loquace (si manda l'output su /dev/null).
bye,
-- 
piergiorgio