3. Questioni hardware

Questo paragrafo tratta alcune delle questioni hardware implicate durante il lavoro di un software RAID.

3.1 Configurazione IDE

E' davvero possibile far lavorare un RAID su dei dischi IDE. Si possono realizzare anche eccellenti prestazioni. Infatti, il prezzo attuale dei dischi e dei controller IDE, rende l'IDE degno di considerazione, quando si costruisce un nuovo sistema RAID.

• Stabilità "fisica": I dischi IDE sono tradizionalmente stati sempre di peggiore qualità meccanica rispetto agli SCSI. Anche oggi, la garanzia sui dischi IDE è tipicamente di un anno , mentre è spesso da tre a cinque anni sui dischi SCSI. Sebbene non sia facile dire che i dischi IDE sono per definizione costruiti in modo peggiore, occorre stare attenti perché i dischi IDE di alcune marche possono guastarsi più spesso dei dischi SCSI simili. Comunque altre marche usano esattamente la stessa meccanica sia per i dischi SCSI sia per quelli IDE. Tutto questo ci porta alla conclusione che: Tutti i dischi si guastano prima o poi, quindi occorre essere preparati a questa evenienza.
• Integrità dei dati:All'inizio, l'IDE non poteva in alcun modo assicurare che i dati inviati sul bus IDE sarebbero stati gli stessi dati scritti sul disco. Questo era dovuto alla totale mancanza di parità, controllo (checksum), ecc. Con lo standard Ultra-DMA, i dischi IDE ora compiono un controllo (checksum) sui dati che ricevono e quindi diventa molto più difficile avere dei dati corrotti .
• Prestazioni: Non ho intenzione scrivere delle prestazioni dell'IDE. La vera storia in breve è:
  • I dischi IDE sono veloci (12 MB/s and oltre)
  • L'IDE carica la Cpu più dello SCSI (ma chi se ne importa?)
  • Usare soloun disco IDE per IDE bus, i dischi slave deteriorano le prestazioni
• Sopravvivenza ai Guasti: I driver IDE in genere sopravvivono al guasto di un dispositivo IDE. Il RAID layer marcherà il disco come guasto e se si sta lavorando su un sistema RAID livello 1 o superiore, la macchina dovrebbe lavorare ancora bene finché non viene arrestata per la manutenzione.

E' molto importante, che venga usato un solo disco IDE per IDE bus. Non solo due dischi rovinano le prestazioni, ma il guasto di un disco spesso comporta il blocco del bus, e quindi il blocco di tutti i dischi su quel bus. In un sistema RAID a prova di guasto (fault-tolerant) (livelli RAID 1,4,5), il guasto di un disco può essere gestito, ma il danneggiamento di due dischi (i due dischi sullo stesso bus che si bloccano a causa del guasto di uno dei due) renderà l'array inutilizzabile. Inoltre, quando il disco master su un bus si guasta, lo slave o il controller IDE possono risultare tragicamente confusi.

Esistono degli economici PCI IDE controller sul mercato. E' possibile acquistare due o quattro bus per circa 80$. Considerando il prezzo più basso dei dischi IDE rispetto agli SCSI, direi che un array di dischi IDE potrebbe essere veramente un'interessante soluzione se vi potete accontentare di avere a disposizione un numero relativamente basso (circa 8 probabilmente) di dischi da collegare al sistema (a meno che non abbiate molti slot PCI per collegare degli IDE controller).

L'IDE ha maggiori problemi di cablatura quando si creano grandi array. Anche se avete a disposizione abbastanza slot PCI, è difficile che possiate sistemare più di 8 dischi in un sistema continuando a mantenerlo funzionante senza corruzione dei dati (causato dalla lunghezza eccessiva dei cavi IDE).

3.2 Sostituzione di dischi "al volo" (Hot Swap)

Questa è stata una delle questioni maggiormente trattate sulla linux-kernel list per un po' di tempo. Sebbene la sostituzione "al volo" dei dischi sia supportata a qualche livello, non è ancora qualcosa che possa essere fatta facilmente.

Sostituzione "al volo" (Hot-swapping) dei dischi IDE

NO ! L'IDE non gestisce assolutamente la sostituzione "al volo". Di sicuro, può funzionare, se il driver IDE è compilato come modulo (possibile solo con i kernel della serie 2.2), e se lo ricaricate dopo avere sostituito il disco. Ma potreste anche finire con un controller IDE "fritto" e avere un tempo di fermo macchina molto maggiore che se aveste sostituito il drive con il sistema arrestato.

Il problema principale, eccetto le questioni elettriche che possono distruggere il vostro hardware, è che il bus IDE deve essere riesaminato dopo che i dischi sono stati sostituiti. Il driver IDE non può al momento farlo. Se il nuovo disco è al 100% uguale al vecchio (geometria, ecc.), potrebbe funzionare anche senza riesame del bus, ma in verità questo vuol dire camminare sulla lama del rasoio.

Sostituzione "al volo" (Hot-swapping) di dischi SCSI

Nemmeno il normale hardware SCSI offre la sostituzione "al volo". Potrebbe però funzionare comunque. Se il vostro SCSI driver supporta il riesame del bus e il collegamento e la rimozione di dispositivi, potreste essere in grado di sostituire al volo i dischi. Comunque, in un normale bus SCSI non si dovrebbero probabilmente scollegare i dispositivi mentre il sistema è ancora alimentato. Ma, di nuovo, potrebbe funzionare (e potreste anche finire con dell'hardware "fritto").

Lo SCSI layer dovrebbe sopravvivere se un disco cessa di funzionare, ma non tutti gli SCSI driver sono ancora in grado di gestire questo. Se il vostro driver SCSI si blocca quando un disco si guasta, il sistema crollerà con esso, tutto sommato il collegamento "al volo" non è poi così interessante.

Sostituzione "al volo" (Hot-swapping) con SCA

Con lo SCA, dovrebbe essere possibile collegare i dispositivi "al volo". Comunque, io non posseggo l'hardware necessario a provare questa funzione, non sono a conoscenza di nessuno che ci abbia provato, così non posso dare nessuna "ricetta" su come farlo.

Se volete "giocare" con questo, dovreste comunque conoscere abbastanza del funzionamento dello SCSI e del RAID. Così non scriverò qui qualcosa che non posso essere sicuro che funzioni, posso invece darvi alcuni indizi:

• Fate un grep per cercare remove-single-device in linux/drivers/scsi/scsi.c
• Date un occhiata araidhotremove e raidhotadd

Non tutti i driver SCSI supportano il collegamento e la rimozione dei dispositivi. Nella serie dei kernel 2.2, almeno l'Adaptec 2940 ed il Symbios NCR53c8xx sembrano supportarlo, gli altri potrebbero e non potrebbero. Apprezzerei molto se qualcuno avesse ulteriori fatti da riportare sull'argomento...

Hosting by: hurra.com
Generated: 2007-01-26 17:56:22