Software RAID nel nuovo kernel Linux 2.4, Parte 21. Impostare RAID-1 in un ambiente di produzione Nell'articolo precedente, sono state introdotte ai lettori alle funzionalità del RAID software di Linux 2.4, mostrando come impostare volumi lineari, RAID-0 e RAID-1. In questo articolo, verrà analizzato cosa serve sapere per poter usare RAID-1 in modo da incrementare la disponibilità dei dati in ambiente di produzione. Ciò richiede maggiore comprensione e conoscenza rispetto alla semplice creazione di un RAID-1 su un server di test o nel proprio pc casalingo; più precisamente, bisogna sapere esattamente da quali cause esterne il RAID-1 dovrà proteggere i dati, e come mantenere attivo e funzionante il proprio volume RAID nel caso si guasti un disco. In questo articolo verranno coperti questi aspetti, iniziando con una panoramica su cosa possono fare o non fare RAID-1, 4 e 5, e terminando con una completa simulazione di test della sostituzione di un disco in RAID-1 guasto (qualcosa che si dovrebbe effettivamente fare, seguendo questo articolo come guida, in base alle proprie possibilità). Dopo aver effettuato la simulazione, si avrà acquisito tutta l'esperienza necessaria per gestire i guasti di un RAID-1 in un ambiente reale. Le caratteristiche di tolleranza ai guasti di RAID sono progettate per proteggere i dati dell'utente dagli effetti negativi di uno spontaneo guasto completo del disco, e questa è una buona cosa. Ma RAID non è una soluzione perfetta per ogni tipo di problema riguardante l'affidabilità. Prima di implementare una forma di RAID (1,4,5) tollerante ai guasti in un ambiente di produzione, è estremamente importante conoscere esattamente cosa NON potrà fare RAID per i dati dell'utente. Quando si è in una situazione nella quale l'operatività dipende da RAID, non si vuole fare nessuna falsa affermazione riguardo alle sue funzionalità. Cominciamo sfatando alcuni miti comuni riguardo a RAID 1, 4 e 5. Molte persone pensano che posizionare tutti i propri dati importanti su un volume RAID 1/4/5 li esimi dall'eseguire backup regolari. Questa cosa è completamente falsa, ed il perchè è presto detto. RAID 1/4/5 aiutano a proteggere i dati da interruzioni non pianificate causate da guasti casuali dei dischi. Tuttavia, non offrono protezioni contro corruzioni dei dati casuali o intenzionali. Se viene digitato cd /; rm -rf * come root su un volume RAID, si perderanno un sacco di dati molto importanti nel giro di qualche secondo, ed il fatto di avere una configurazione RAID-5 su 10 dischi sarà ininfluente. Inoltre, RAID non sarà d'aiuto se il server viene fisicamente rubato o se c'è un incendio nell'edificio. E ovviamente, se non viene implementata una strategia di backup, non si avrà un archivio dei dati passati: se qualcuno nel proprio ufficio cancella alcuni dati importanti, non si riuscirà a recuperarli. Solamente questo dovrebbe essere sufficiente a convincere che, nella maggior parte dei casi, bisogna pianificare ed implementare una strategia di backup prima di pensare di affrontare l'implementazione di un potenziale RAID-1, 4 o 5. Un altro errore è l'implementazione di un RAID software su un sistema composto da hardware di bassa qualità. Se si sta assemblando un server che dovrà svolgere qualcosa di importante, ha senso acquistare l'hardware migliore nel limite delle proprie disponibilità economiche. Se il proprio sistema è instabile o non adeguatamente raffreddato, si incorrerà in problemi che RAID non potrà risolvere. Un'altro esempio simile è l'impossibilità di RAID nel fornire continuità aggiuntiva al servizio in caso di mancanza di alimentazione. Se il proprio server è adibito a svolgere un qualsiasi compito relativamente importante, assicurarsi che sia equipaggiato con un gruppo di continuità (UPS). Inoltre è importante focalizzarsi sulle problematiche inerenti ai filesystem. Il filesystem esiste "al di sopra" del proprio volume RAID software. Ciò significa che usare un RAID software non permette di evitare i problemi dovuti al filesystem, per esempio a lunghi e potenzialmente problematici fsck se capita di non utilizzare un filesystem non journaled o con la tendenza a rovinarsi. Pertanto, il RAID software non rende il filesystem ext2 più affidabile; ecco perché è così importante che la comunità Linux abbia a disposizione ReiserFS, come anche JFS e XFS. RAID software e filesystem journaled affidabili sono una combinazione efficace. RAID - implementazione intelligente Speriamo che la sezione precedente abbia sfatato qualunque mito riguardo a RAID eventualmente a conoscenza del lettore. Quando si implementa RAID-1, 4 o 5, è molto importante vedere la tecnologia come qualcosa che migliora l'uptime (periodo di tempo nel quale la macchina è attiva e funzionante, N.d.T.). Quando viene implementato uno di questi livelli RAID, si verrà protetti da una situazione molto specifica, ovvero un completo guasto spontaneo (singolo o multiplo) dei dischi. Se si sperimenta questa situazione, il RAID software permetterà al sistema di continuare a funzionare, così come dare l'opportunità all'utente di eseguire le operazioni necessarie per sostituire il disco guasto con uno nuovo. In altre parole, se si implementa RAID 1,4, o 5, verrà ridotto il rischio di avere una lunga interruzione di servizio non pianificata, solamente il tempo necessario alla sostituzione del disco fuori uso. Ovviamente, questo significa che se non è una priorità avere un sistema altamente disponibile non sarà necessario implementare un RAID software, a meno che non si stia progettando di usarlo principalmente come un modo per incrementare le prestazioni di I/O su file. Un amministratore di sistema intelligente usa il RAID software per uno scopo preciso, ovvero migliorare l'affidabilità di un server già molto affidabile. Se si è dei bravi amministratori di sistema, si avranno già affrontati gli aspetti basilari. La propria organizzazione sarà protetta dalle catastrofi grazie all'implementazione di un piano regolare di backup. Il proprio server sarà alimentato da un UPS, e ci sarà in funzione un software di monitoraggio dell'UPS in modo che il proprio server venga spento in caso di un prolungamento di mancanza di corrente. Forse si starà utilizzando un filesystem journaled come ReiserFS in modo da ridurre i tempi di esecuzione di fsck e incrementare le prestazioni e l'affidabilità dello stesso. E si spera che il proprio server sia adeguatamente raffreddato e sia composto da hardware di alta qualità, e si abbia fatto grande attenzione ai problemi di sicurezza. Ora, e solo ora, si dovrebbe considerare l'implementazione di un RAID-1, 4 o 5 software; facendolo, si aggiungerà potenzialmente qualche punto percentuale di uptime al proprio server difendendolo da un guasto completo dei dischi. Il RAID software aggiunge uno strato di protezione che rende ancora migliore un server già robusto di per sé. 2. Spiegazione dettagliata per RAID-1 Ora che si è a conoscenza di cosa RAID può fare e non fare, chi scrive spera che il lettore abbia aspirazioni ragionevoli ed un giusto atteggiamento nei confronti dell'argomento. In questa sezione, si verrà accompagnati attraverso il processo di simulazione di guasto di un disco, ed il riavvio del proprio volume RAID in modalità degradata. Se si possiede l'abilità di impostare un volume RAID-1 su una macchina di test e seguire i vari passaggi, è caldamente consigliato farlo. Questo tipo di simulazione può risultare divertente. E divertirsi un po' proprio adesso può aiutare ad assicurare che quando un disco si guasterà veramente, si sarà calmi e padroni di sé, sapendo esattamente cosa fare.
Il primo passo è impostare un volume RAID-1: fare riferimento all'articolo precedente se si ha bisogno di rinfrescarsi la memoria a riguardo. Una volta impostato il volume, il comando cat /proc/mdstat visualizzerà qualcosa di simile a questo:
Notare che chi scrive sta utilizzando devfs, che è anche il motivo per cui si vedono dei nomi di dispositivo estremamente lunghi nel codice appena esposto. L'autore in verità sta utilizzando /dev/hda5 e /dev/hde1 come dischi RAID-1. In questo momento, il codice del software RAID nel kernel sta sincronizzando i dischi in modo che ciascuno sia l'esatta copia dell'altro. Se il proprio volume RAID-1 è arrivato a questo punto, si può proseguire e creare un filesystem sul volume, e montarlo da qualche parte. Copiarci dentro qualche file ed impostare il proprio /etc/fstab in modo che il volume (/dev/md0) venga montato all'avvio del sistema. Questa è la linea che l'autore del documento ha aggiunto al proprio fstab; quella dell'utente potrebbe differire leggermente:
Si è quasi pronti per simulare un guasto del disco, ma manca ancora una cosa. Primo, eseguire nuovamente cat /proc/mdstat, ed attendere fino a che tutti i volumi dei dischi saranno sincronizzati. Dopodiché, il proprio /proc/mdstat dovrebbe apparire così:
Ora che la risincronizzazione è completata, si è pronti per la simulazione. Proseguire spegnendo completamente la propria macchina. Successivamente aprirla e scollegare uno dei dischi fissi che compongono l'array RAID-1. Ovviamente, non bisognerà scollegare il disco che contiene la propria partizione root di Linux, in quanto si avrà bisogno di avviare nuovamente Linux! Ora che il disco fisso è scollegato, riaccendere la macchina. Una volta effettuato il login, si potrà constatare che /dev/md0 è montato e che si potrà ancora usare il volume. Eseguendo cat /proc/mdstat si potrà vedere il cambiamento importante:
È possibile vedere che il volume /dev/md0 è in esecuzione in modalità degradata. Il disco /dev/hde è scollegato, in tal modo /dev/hde1 non viene trovato durante la fase di boot del kernel e l'avvio automatico dell'array. Fortunatamente, il kernel ha trovato /dev/hda5, e /dev/md0 è riuscito comunque ad avviarsi in modalità degradata. Com'è possibile vedere, la partizione /dev/hde1 non viene elencata in /proc/mdstat, e uno dei dischi RAID è marcato come "fuori uso" ([U_] invece di [UU]). Ma siccome /dev/md0 sta comunque funzionando, il RAID-1 software sta facendo quello che per cui è progettato: mantenere i propri dati disponibili. In questo momento si sta sperimentando un guasto simulato di un disco. Se il disco che attualmente non è alimentato si guasta realmente mentre il sistema è in esecuzione, è il tipo di situazione che si sta vivendo. Il proprio volume RAID-1 verrà eseguito in modalità degradata, in altre parole esso sarà ancora disponibile ma senza alcuna ridondanza. Al momento opportuno si dovrà spegnere il sistema, sostituire il disco guasto, e riavviare nuovamente il sistema. A questo punto il proprio volume RAID-1 partirà ancora in modalità degradata. Una volta che il nuovo disco è nella macchina, creare una partizione RAID autodetect (FD) di dimensioni adeguate sul nuovo disco. Un riavvio addizionale potrebbe essere necessario in modo che Linux possa rileggere la tabella delle partizioni del disco. Una volta che la nuova partizione è visibile al sistema, si è pronti per ripristinare il proprio array RAID-1, ottenendo nuovamente un po' di ridondanza. Ovviamente, quella che si sta eseguendo è solamente una simulazione. Per fare pratica nel riaggiungere una partizione nel proprio array RAID, è possibile fare due cose, in base al tipo di scenario che si preferisce affrontare. Si può o spegnere la macchina, collegare il disco, avviare il sistema, e aggiungere nuovamente la vecchia partizione nell'array, o spegnere la macchina, collegare il disco, avviare, cancellare il disco, creare una nuova partizione RAID autodetect (FD) da aggiungere all'array (della dimensione corretta, ovviamente, grande almeno quanto la partizione che si sta ripristinando), dopodiché aggiungere questa partizione nuova di zecca all'array. La seconda scelta probabilmente si avvicina di più a quello che potrebbe avvenire nel caso un guasto reale del disco, mentre la prima simula qualcosa come situazione di guasto al controller dei dischi o di un cavo danneggiato, dove uno dei dischi del mirror è temporaneamente non disponibile, causando l'esecuzione in modalità degradata di /dev/md0, e richiedendo la successiva aggiunta di una delle partizioni dopo aver rimediato al problema. Qualsiasi simulazione si scelga, la "correzione" è la medesima: dopo che la partizione è pronta, bisogna reinserirla nel volume /dev/md0. Prima di reinserire la partizione nel proprio array, è buona cosa dare un'occhiata ai messaggi di boot del proprio kernel. Digitando dmesg | more sarà possibile visualizzarli. Si dovrebbe vedere una porzione di testo simile al seguente:
Ora è consigliabile prendere un po' di tempo e leggere attentamente questi messaggi, perché aiuteranno a capire il processo usato dal kernel per avviare automaticamente /dev/md0, fornendo un altro visione preziosa dei funzionamenti interni del software RAID di Linux. Se l'output del kernel elencato sopra è stato letto, si vedrà che il kernel ha individuato /dev/hda5 e /dev/hde1, ma hde1 non è aggiornato rispetto a hda5. Pertanto il kernel avvia /dev/md0 in modalità degradata, usando /dev/hda5 e non toccando assolutamente /dev/hde1. A questo punto è il momento di aggiungere la propria partizione originale (o creata ex-novo) al volume. Ecco come. Per prima cosa, se la partizione sostitutiva ha un nuovo nome di dispositivo, aggiornare /etc/raidtab in modo che rispecchi le nuove informazioni. Successivamente aggiungere la nuova partizione al volume usando il seguente comando, sostituendo /dev/hde1 con il nome del dispositivo della partizione che si andrà ad aggiungere:
Le luci del proprio disco fisso dovrebbero cominciare a lampeggiare in quanto comincerà la ricostruzione. Proseguire ed eseguire cat /proc/mdstat per verificare lo stato di ricostruzione del RAID-1 che ora sarà in corso:
Nel giro di qualche minuto, il proprio volume RAID-1 tornerà ad uno stato normale:
Voila! È stata appena effettuato un ripristino da un guasto di un disco simulato, e si è pronti per usare RAID-1 in un ambiente di produzione. Ora sarà possibile attaccare l'adesivo fatto in casa "certificato RAID-1" sulla propria fronte ed iniziare a sbattere le braccia correndo in giro per l'ufficio per il diletto dei propri colleghi. Ovviamente, forse non è una grande idea. Ci si vede nel prossimo articolo.
|
|
