View Full Version : Controllare l'integrità di dischi SCSI su server HP Proliant
Oggi dovrei avere fra le mani un server Proliant DL380 G3 con un controller SCSI Smart Array 5i.
Mi servirebbe un metodo pratico per controllare l'integrità dei 7 dischi SCSI che sono stati presi per questo server (2 di riserva).
I dischi sono originali HP (3 da 36 GB e 4 da 72 GB) ed andranno a formare un RAID 1 per il SO (2x36 GB) e un RAID 5 per i dati (3 x 72 GB).
Grazie
Tasslehoff
05-08-2010, 01:31
Se hai già un os installato puoi usare l'Array Configuration Utility (ACU) o l'Array Diagnostic Utility (ADU) che dovresti poter scaricare direttamente dal sito HP tra il software disponibile per quella macchina.
Non sono il massimo (anzi francamente a me sembrano la peggiori utility del genere, Dell OpenManage o IBM ServeRAID Manager sono eoni avanti...) ma quantomeno ti possono verificare lo stato delle unità e fornire un report dettagliato sul controller, gli array, le unità logiche e le unità fisiche.
Mi pare che ci sia anche una iso con una serie di tool diagnostici da far girare al boot, nel caso tu non abbia ancora installato l'OS.
Riguardo alla topologia dello storage, i due dischi che avanzano li useresti come hot-spare?
Perchè in questo caso io consiglierei di risparmiarne uno, e di usare un solo disco da 74GB come hot-spare condiviso.
Nel caso si guastasse uno dei dischi da 36GB risulterebbe sprecato, ma quello che serve è che possa garantire la continuità operativa; poi con tutta calma potrai farti mandare un disco da 36GB, togliere l'hot-spare da 74GB e inserire il nuovo da 36GB e attendere l'avvio della rebuild e poi reinserire il 74GB hot-spare.
Ancora il sistema operativo non c'è, così alla fine ho optato per il CD HP SmartStart.
Buona l'idea dell'hot spare condiviso. Grazie.
Purtroppo proprio un disco da 73 GB è riportato come near to failure :muro: :muro: :rolleyes:
La cosa strana è che i counter degli errori di lettura sono a zero, l'hard disk passa tutti i test (compreso il self test esteso), mentre è diverso da zero lo status dello SMART.
Ora mi sa che lo devo montare sul mio controller 19160 per poter leggere in modo più preciso tutti i contatori SMART.
E davvero da buttare ?
OUTATIME
06-08-2010, 09:55
Nel caso si guastasse uno dei dischi da 36GB risulterebbe sprecato, ma quello che serve è che possa garantire la continuità operativa; poi con tutta calma potrai farti mandare un disco da 36GB, togliere l'hot-spare da 74GB e inserire il nuovo da 36GB e attendere l'avvio della rebuild e poi reinserire il 74GB hot-spare.
Quindi tu dici di forzare la rebuild estraendo un disco buono? Cioè:
- Mi si rompe un disco da 36
- Parte l'hot spare da 72
- Rebuild completata, tolgo il disco da 36 guasto e ne inserisco uno nuovo da 36
- Tolgo il disco di hot-spare da 72 in modo da forzare una rebuild sul nuovo da 36
- Reinserisco il disco da 72 che cosi torna a essere hot spare....
Totale 2 rebuild.... tu saresti disposto a correre un rischio simile?
Vero, un bel problema. Allora opterò per mettere solo l'hot spare solo per il Raid 5, anche se ora devo cercare un altro disco.
Oggi dovrei avere fra le mani un server Proliant DL380 G3 con un controller SCSI Smart Array 5i.
Mi servirebbe un metodo pratico per controllare l'integrità dei 7 dischi SCSI che sono stati presi per questo server (2 di riserva).
I dischi sono originali HP (3 da 36 GB e 4 da 72 GB) ed andranno a formare un RAID 1 per il SO (2x36 GB) e un RAID 5 per i dati (3 x 72 GB).
Grazie
ma perche non fare un raid 5 per il SO con i tre dischi da 36 (36*2=76 GB) ed un raid 5 per i dati con i 4 dischi da 72? (72*3=217 GB)
Tanto se e per un uso standard che te ne fai di un hotspare, hai gia la ridondanza nel raid
pro:
piu spazio per l'OS 72 GB anziche 36
Piu spazio per i dati, 217 anziche 146
costo per GB inferiore perche sfrutti tutto il disponibile
contro
Il raid 5 sara un pelo piu lento del raid 5, ma sara solo l'avvio
ha dimenticavo, il predictive failure che ti segnala il tool, non controlla solo i bad blocks, controlla anche svariati altri parametri tra i quali, il tempo di accesso, se si allunga, ti da un warning
Tasslehoff
19-08-2010, 13:43
Quindi tu dici di forzare la rebuild estraendo un disco buono? Cioè:
- Mi si rompe un disco da 36
- Parte l'hot spare da 72
- Rebuild completata, tolgo il disco da 36 guasto e ne inserisco uno nuovo da 36
- Tolgo il disco di hot-spare da 72 in modo da forzare una rebuild sul nuovo da 36
- Reinserisco il disco da 72 che cosi torna a essere hot spare....
Totale 2 rebuild.... tu saresti disposto a correre un rischio simile?Beh naturalmente un bel ghost ci starebbe bene, però è una cosa che si può fare.
A me è capitata in passato visto che l'assistenza HP mi aveva procurato un disco da 10k rpm anzichè 15k rpm, piuttosto che rimanere con l'array degradato e con il rischio di disastro ho preferito subire una rebuild in più.
Alla fine il problema non è la rebuild, il problema è rimanere scoperti di parità.
Tutto sommato poi non stiamo parlando di TB e TB, si tratta al massimo di qualche centinaio di GB, la rebuild dovrebbe richiedere più o meno mezz'ora.
Previo ghost (magari a caldo tramite drive snapshot se si tratta di macchina Windows) imho è una cosa fattibilissima.
Tasslehoff
19-08-2010, 13:51
ma perche non fare un raid 5 per il SO con i tre dischi da 36 (36*2=76 GB) ed un raid 5 per i dati con i 4 dischi da 72? (72*3=217 GB)
Tanto se e per un uso standard che te ne fai di un hotspare, hai gia la ridondanza nel raid
pro:
piu spazio per l'OS 72 GB anziche 36
Piu spazio per i dati, 217 anziche 146
costo per GB inferiore perche sfrutti tutto il disponibile
contro
Il raid 5 sara un pelo piu lento del raid 5, ma sara solo l'avvioSi ok la parità dell'array raid5, ma se ti salta quella poi sei subito di corsa a cercare un disco o a chiamare il supporto con severità urgente (= fregarsi la serata o il week end) perchè se salta un altro disco hai perso l'unità logica...
Valuta tu in base alla necessità di storage che hai, però io preferirei avere un hot-spare, anche considerando che il software di monitoraggio HP fa abbastanza pena e non invia nemmeno una misera mail di notifica in caso di problemi allo storage :muro:
ha dimenticavo, il predictive failure che ti segnala il tool, non controlla solo i bad blocks, controlla anche svariati altri parametri tra i quali, il tempo di accesso, se si allunga, ti da un warningDimenticavo un dettaglio, se dovessi riavviare non ti sorprendere se magicamente il disco dovesse tornare online. Nel caso sostituiscilo cmq eh.
Io con i server HP ho visto comportamenti bizzarri simili più volte... cose che con Dell e IBM invece non capitano mai :stordita:
Si ok la parità dell'array raid5, ma se ti salta quella poi sei subito di corsa a cercare un disco o a chiamare il supporto con severità urgente (= fregarsi la serata o il week end) perchè se salta un altro disco hai perso l'unità logica...
Valuta tu in base alla necessità di storage che hai, però io preferirei avere un hot-spare, anche considerando che il software di monitoraggio HP fa abbastanza pena e non invia nemmeno una misera mail di notifica in caso di problemi allo storage :muro:
Dimenticavo un dettaglio, se dovessi riavviare non ti sorprendere se magicamente il disco dovesse tornare online. Nel caso sostituiscilo cmq eh.
Io con i server HP ho visto comportamenti bizzarri simili più volte... cose che con Dell e IBM invece non capitano mai :stordita:
:D si capisce che non ti piaciono i prodotti HP. eppure basta lavorare un po con quei prodotti per averne di nuovo piena fiducia.
Non e perche uno ha avuto una brutta esperienza con un singolo prodotto che si deve sempre affossarlo. Per esempio, ci sono anche con hp tutti i tools per il monitoraggio del prodotto, incluse trap snmp, emails, insight agents con insight manager (gratis), remote access e control via la ILO, and anche la tirata di una campanellellina se lo vuoi :sofico:
Comunque tornando alla tua citazione, quante volte ti e successo che un disco si guasti subito dopo un altro? ( e intendo dopo, non contemporaneamente perche allora ripristini tutto facilmente) sara una su 10.000? a me in tanti anni di supporto su questi prodotti, non mi e mai successo, il piu delle volte si tratta di un disco che blocca la catena scsi, e per cio tutto sembra bloccato.
ovviamente dipende se il server e usato in un ambiente mission critical, o simili, ma a questo punto non penso ci si possa rivolgersi ad un forum per una consulenza :D
Tasslehoff
19-08-2010, 14:47
:D si capisce che non ti piaciono i prodotti HP. eppure basta lavorare un po con quei prodotti per averne di nuovo piena fiducia.
Non e perche uno ha avuto una brutta esperienza con un singolo prodotto che si deve sempre affossarlo. Per esempio, ci sono anche con hp tutti i tools per il monitoraggio del prodotto, incluse trap snmp, emails, insight agents con insight manager (gratis), remote access e control via la ILO, and anche la tirata di una campanellellina se lo vuoi :sofico: Beh aspetta, io ho citato anche in altri thread i casi che sono capitati a me, però più che il caso specifico di guasto (e ti parlo anche di 4 unità che vanno in fail una dietro l'altra con successiva sostituzione anche del controller SmartArray P400 che non faceva partire la rebuild degli array, case documentato dal supporto HP) che statisticamente potrebbe essere irrilevante, ho criticato apertamente HP per molte altre cose oggettive.
Ok Insight manager (anche IBM offre gratuitamente Director Express e Dell OpenManage) ma si tratta di un software che richiede una sua infrastruttura, una macchina su cui installarlo etc etc...
Se uno ha pochi server HP e vuole qualcosa di indipendente e poco invasivo usa ACU o ADU, che nel migliore dei casi loggano nell'event log di Windows e non mandano uno straccio di email (cosa che invece OpenManage standalone fa, IBM ServeRaid Manager e Storage Manager standalone fanno).
Poi per carità, uno può anche fare in modo di usare l'SMTP di IIS o Exchange (brrrrr...) per inviare ogni singolo record dell'event log via mail, ma francamente in oltre 10 anni di consulenze non ho ancora visto una persona che l'abbia fatto... passerebbe la giornata intera e spazzolarsi mail... :rolleyes:
Citi ILO, benissimo ma quanti hanno acquistato il server con quel componente opzionale? Anche i competitor hanno la loro controparte (IBM Remote Supervisor II), anche decisamente migliore (Dell DRAC5).
Comunque tornando alla tua citazione, quante volte ti e successo che un disco si guasti subito dopo un altro? ( e intendo dopo, non contemporaneamente perche allora ripristini tutto facilmente) sara una su 10.000? a me in tanti anni di supporto su questi prodotti, non mi e mai successo, il piu delle volte si tratta di un disco che blocca la catena scsi, e per cio tutto sembra bloccato.
ovviamente dipende se il server e usato in un ambiente mission critical, o simili, ma a questo punto non penso ci si possa rivolgersi ad un forum per una consulenza :DEh sarò sfigato ma a me è capitato, e per fortuna che dopo il primo disco in fail (array raid5 senza hot-spare) ho fatto un ghost con true image echo.
Dopo il riavvio per il ghost il disco è tornato magicamente online, poi dopo un altro riavvio è tornato offline insieme ad un altro... insomma dopo 3 gg di interventi alla fine abbiamo cambiato 4 dischi su 6 + controller, ovviamente con tutti gli update di firmware del caso.
Alla fine di tutte queste sostituzioni ho ripristinato il ghost e non abbiamo perso un bit, però più che i guasti in se, quello che mi ha insospettito e mal disposto nei confronti di queste macchine (si trattava di un DL380 G5) è stato il comportamento randomico.
Disco in fail --> reboot --> disco online... ma da quando? ma mai su nessuna macchina IBM ho visto fare questi numeri, se un disco è in fail, tale resta anche dopo 10.000 reboot :stordita:
Il bello è che il tecnico stesso uscito per le varie sostituzioni mi disse che era stata una cattiva idea rebootare per fare il ghost, che era normale che il disco che era in fail fosse tornato online con il reboot a causa dei contatori che si erano resettati con lo shutdown.
Per carità, come giustamente facevi notare, dietro a un led di fail ci sono innumerevoli fattori, però non esiste che questi contatori (che certamente ci sono) si cancellino per un reboot e quindi rendano totalmente inaffidabile il monitoraggio.
Il bello è che il tecnico stesso uscito per le varie sostituzioni mi disse che era stata una cattiva idea rebootare per fare il ghost, che era normale che il disco che era in fail fosse tornato online con il reboot a causa dei contatori che si erano resettati con lo shutdown.
Per carità, come giustamente facevi notare, dietro a un led di fail ci sono innumerevoli fattori, però non esiste che questi contatori (che certamente ci sono) si cancellino per un reboot e quindi rendano totalmente inaffidabile il monitoraggio.
diciamo che qui la situazione e un po piu complessa, un disco con il flag di failed non torna di nuovo online se non fai alcune azzioni a mano, poi dipende del array controller e del fw.
Penso questo caso sia uno di quelli in cui un disco blocca tutto, percio non c'e piu communicazione tra controller e array, l'array segna tutto in fail, pero se ritiri il disco che ha bloccato tutto o se seguito ad un reboot quel disco sblocca la catena (attenzione, questo non significa che quel disco riparte, ma che sblocca la catena scsi. quel disco rimane failed) succede che l'array controller vede che i dischi che riappaiono sono tutti in status good (anche se lui prima nella sua memoria li avaiva in failded due to non accessible) e decide che tu poi ritornare a lavorare, magari senza parita, oppure aggiungendo l'hot spare.
Direi che questa e una feature . Al tempo delle Netraid (vecchi array controllers) l'operazione e la scelta era lasciata tutta al tecnico (o al supporto remoto) percui ci perdevi le ore a capire come era configurato, e quali dischi forzare online per recuperate i dati, adello il fw dei nuovi controller lo fanno in automatico se possono.
Meglio questo, aver di nuovo i dati, piutosto che avere tutto down e ripristinare da Tape.
eh si, perche il ghost puo essere un workaround, ma in un enterprise level si usa il backup, magari su virtual library, magari con OBDR or Bare Metal Data Recovery
devo anche dire che ACU e ADU sono configuration tool e diagnostic tool, non un monitoring tool
af e poi le ILO sono integrate di default in tutti i server
out of that, riconosco che i guasti ci sono, ma ci sono per tutte le company
ciao
vBulletin® v3.6.4, Copyright ©2000-2026, Jelsoft Enterprises Ltd.