RAID e cache ... si o no ?
Goldrake
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
Piergiorgio Sartor
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
Lorenz
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.
Goldrake
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
Piergiorgio Sartor
> Se uno volesse dormire sonni tranquilli... che deve fare ... ?
Spegenere tutto... :-)
bye,
--
piergiorgio
Lorenz
> On 4 Mar, 23:30, Lorenz <lor...@alientech.it> wrote:
>> Sembra che Goldrake abbia detto :
>>
>>> 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 ?
>>
>> 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 ?
Dipende dal controller... se non ha a bordo una sua cache allora
ci si riferisce a quella degli HD.
>
> 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 ?
> :-)
Direi solo la seconda...:D
tony pedi
> Goldrake wrote:
>
>> Se uno volesse dormire sonni tranquilli... che deve fare ... ?
>
> Spegenere tutto... :-)
>
> bye,
>
rotfl
Goldrake
<piergiorgio.sartor.this.should.not.be.u...@nexgo.REMOVETHIS.de>
wrote:
> Goldrake wrote:
> > Se uno volesse dormire sonni tranquilli... che deve fare ... ?
>
> 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
r3lative
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
Lorenz
> 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 ;)
>
Infatti... misà che appena vedrà il costo di questi controller l'OP
avrà ancora meno sonni tranquilli, LOL.
r3lative
hehe
ma è anche vero che le prestazioni sono decisamente di un'altro livello
;)
--
my blog: www.r3lative.it
Goldrake
> 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 ;)
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
r3lative
> On 6 Mar, 00:35, "r3lative" <r3lat...@gmail.com> wrote:
> > 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 ;)
>
> Immagino, quindi, che il controller raid on-board di serie dell' HP
> Proliant ML150 G5 non rientri in quella categoria... vero ?
dipende dalla configurazione, ma in genere no ;)
> 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
Goldrake
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... ??
r3lative
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
Goldrake
> > 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... ??
>
> 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.
Piu' chiaro di cosi, si muore ! :-)
> 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),
Non mi e' chiaro questo discorso sui volumi logici.
Io, normalmente, utilizzo un hard disk dedicato per fare i backup
integrali del server con software specifici quali, per esempio,
Symantec Backup Exec System Recovery, con pianificazioni ogni 12 ore
incrementali.
Poi, su dei supporti removibili (tipicamente Iomega Rev) faccio anche
il backup di archivi specifici (documenti, profili utenti, Exchange,
Sql, etc..) .
> e non ultimo deve essere pianificato una politica di
> ripristino (in ambiente di prova) per verificare la solidita del backup.
Quello l'ho fatto !
:-)
Ciao e grazie
r3lative
>
> > 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),
>
> Non mi e' chiaro questo discorso sui volumi logici.
dipende dal dispositivo di backup, si va dai supporti fisici (nastri,
rev, ecc), ai logici/virtuali, che sono partizioni o comunque "parti"
di altri dispositivi tipo nas, tape library, ecc...
> Io, normalmente, utilizzo un hard disk dedicato per fare i backup
> integrali del server con software specifici quali, per esempio,
> Symantec Backup Exec System Recovery, con pianificazioni ogni 12 ore
> incrementali.
personalmente preferisco un piccolo nas che mi permette di archiviare
n° copie (sia copia fisica del sistema, che copie dati).
ma dipende dalla mole di dati.
ti ricordo che il backup dovrebbe essere mantenuto in un luogo diverso
da quello del server.
> > e non ultimo deve essere pianificato una politica di
> > ripristino (in ambiente di prova) per verificare la solidita del
> > backup.
>
> Quello l'ho fatto !
> :-)
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
Piergiorgio Sartor
> 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).
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
r3lative
> r3lative wrote:
>
> > 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).
>
> Non e` affatto stupido, anzi e` una concetto
> fondamentale che a volte sembra sfuggire: il
> backup serve solo se e` ripristinabile.
infatti dicevo "sembra", proprio perchè IMHO è una parte fondamentale
della procedura di backup dei dati. solo che spesso è sottovalutato o
ignorato ...
poi quando serve, son guai :(
> Altrimenti anziche` nastri/CD/DVD/HD basterebbe
> fare una copia di tutto su /dev/null, che avrebbe
> 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
Goldrake
Ok... ecco qua un genio che arriva..... :-)
Che cos'e' 'sto /dev/null ???
Grazie
Piergiorgio Sartor
> 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