[Gfoss] [OT] NAS che manda in crash un server...è possibile?

Giuseppe Naponiello beppenapo a gmail.com
Dom 12 Giu 2016 23:48:13 CEST


Grazie a tutti,
ripeto, non mi era mai successa una cosa del genere e non sono preparato a
gestirla, ora ho le idee molto più chiare!

Una curiosita':
> ma poi se fai ripartire il server debian , senza rimuovere il mounting
> della cartella remota NAS, esso ti riparte o resta bloccato in avvio ?
> Mi aspetterei che ti resti bloccato in avvio in attesa di un comando
> da console di autorizzazione alla prosecuzione oltre la partizione che
> non sta rispondendo.


Io accedo via ssh in remoto, crashato il server non riuscivo più ad
accedere. Credo abbiano riavviato la macchina virtuale, fatto questo il
servizio è riandato su tranquillamente ma il nas è scollegato...a naso
direi che hanno "smontato" il NAS prima di riavviare il server, e lo
rimonteranno una volta cambiati i dischi...sperando di non perdere dati!!!

-beppe-


Il giorno 12 giugno 2016 23:23, Andrea Peri <aperi2007 a gmail.com> ha
scritto:

> Se metti la questioni in termini assoluti la risposta non puo' essere
> altro che "si, puo' succedere".
>
> Che succeda spesso o quasi mai, e' un altra questione.
>
> Dipende da tanti fattori.
> Che tipo di mounting, che tipo di protocollo usi per il collegamento
> tra cartella remota e server debian.
>
> Ma dipende anche da quale software doveva usare tale cartella remota.
> Se su di essa era puntato qualche software di sistema (o servizio)
> direi che e' molto probabile. che qualcosa possa accadere.
>
> Aggiungo che il surriscaldamento dei dischi e' un evento che non va
> mai ignorato. E questovale anche in un RAID.
> Anche perche' il surriscaldamento e' proprio il classico evento che
> colpisce tutti i dischi al medesimo tempo e quindi espone tutti i
> dischi del RAID al medesimo rischio di rottura. . O anche di rotture
> parziali di settori , che e' altrettanto dannoso.
>
> Questo perche' un Raid salva dalla rottura di 1 disco. Ma il
> surriscaldamento mette a repentaglio tutti i dischi e quindi ti espone
> alla rottura di piu' dischi contemporaneamente cosa che se avviene
> vanifica la sicurezza del raid.
>
> Una curiosita':
> ma poi se fai ripartire il server debian , senza rimuovere il mounting
> della cartella remota NAS, esso ti riparte o resta bloccato in avvio ?
> Mi aspetterei che ti resti bloccato in avvio in attesa di un comando
> da console di autorizzazione alla prosecuzione oltre la partizione che
> non sta rispondendo.
>
> A.
>
>
> Il 12 giugno 2016 22:11,  <a.furieri a lqt.it> ha scritto:
> > On Sun, 12 Jun 2016 21:19:22 +0200, Giuseppe Naponiello wrote:
> >>
> >> Grazie Sandro,
> >> quindi tu mi stai dicendo che, in una situazione con due macchine
> >> diverse, due ip diversi (magari in due armadi diversi!), in cui una
> >> (il server) è virtualizzato, il cui unico collegamento è una riga in
> >> fstab, se una delle due subisce un danno, in questo caso all'hadware,
> >> può danneggiare anche il software dell'altra?
> >>
> >
> > Giuseppe,
> >
> > non ho certo detto questo :-)
> >
> > mi sono limitato a spiegare che un'installazione non adeguata
> > puo' facilmente causare danni hardware gravi, e che questi
> > difficilmente non avranno ripercussioni anche sul software.
> > piu' in particolare, visto che nel tuo post parli di frequenti
> > guasti ai dischi del NAS e di temperature di esercizio troppo
> > spesso elevate oltre le soglie di tolleranza ho cercato di
> > indicarti quali possono essere le cause piu' verosimili.
> >
> > l'ipotesi che un guasto hw si possa propagare da una macchina
> > all'altra, specie se ubicare in due locations diverse e'
> > decisamente peregrina.
> >
> > viceversa che l'improvvisa sparizione di un'intera partizione
> > del filesystem (la tua "singola riga in fstab") possa causare
> > il crash del sistema operativo (piu' verosimilmente un kernel
> > panic nel caso di Linux) non pare affatto ingiustificata,
> > specie se quel filesystem si e' reso improvvisamente
> > indisponibile.proprio nel bel mezzo di un'operazione di
> > lettura o di scrittura.
> >
> > ciao Sandro
> >
> >
> >
> >
> >> Scusami ma mi ritrovo in una situazione delicata ed ho bisogno di
> >> capire esattamente cos'è successo...
> >>
> >> Grazie ancora
> >>
> >>
> >> Il giorno 12 giugno 2016 20:46,  ha scritto:
> >>
> >>> On Sun, 12 Jun 2016 19:23:22 +0200, Giuseppe Naponiello wrote:
> >>>
> >>>> Salve a tutti,
> >>>> so che sono nella lista sbagliata e vi giuro che mi scoccia
> >>>> scrivere post
> >>>> OT ma, quando cerco risposte che non trovo altrove, so che qui
> >>>> qualche buon
> >>>> consiglio lo raccatto sempre!!!
> >>>> La domanda è nell'oggetto, ora vi do qualche dettaglio in più!
> >>>> Ho un NAS Qnap da 8 bay, configurato con RAID6, ho montato una
> >>>> cartella sul
> >>>> server principale (debian 8), mi serve per salvare i file che gli
> >>>> utenti
> >>>> caricano, per fare un po' di backup, ecc.
> >>>> Ad un certo punto il serve va in down e nessuno accede più al
> >>>> servizio web.
> >>>> Non ho accesso "fisicamente" all'hardware in quanto ospitati in
> >>>> un CED da
> >>>> un'altra parte...i tecnici, dopo mia segnalazione, mi dicono che
> >>>> tre dischi
> >>>> del NAS si sono rotti e questo ha mandato in crash anche il
> >>>> server, senza
> >>>> dare altre spiegazioni un po' più dettagliate!!!!
> >>>> Confesso la mia ignoranza in materia ma mi sembra un po' strano
> >>>> visto che
> >>>> già in un'altra occasione si erano rotti dei dischi del NAS e
> >>>> non era
> >>>> successo niente al server.
> >>>> Per completezza vi dico che mi erano arrivati messaggi di warning
> >>>> dal NAS
> >>>> relativi al surriscaldamento di alcuni dischi...che forse ho
> >>>> sottovalutato!
> >>>> Quindi, è possibile una situazione come quella che vi ho
> >>>> descritto?
> >>>> Se si, potete spiegarmi tecnicamente cos'è successo?
> >>>> E poi, secondo voi è normale che in nemmeno 2 anni è stato
> >>>> necessario
> >>>> cambiare 6 dischi?
> >>>> Grazie, e scusatemi ancora per l'OT ;)
> >>>
> >>>
> >>> e' praticamente impossibile che il software possa resistere
> >>> indenne ad un severo malfunzionamento hardware.
> >>> le conseguenze possono essere le più svariate ed hanno natura
> >>> intrinsecamente casuale e ben poco riproducibile, ma e'
> >>> assolutamente
> >>> certo che un componente HW gravemente malfunzionante provocherà
> >>> danni piu' o meno seri.
> >>>
> >>> strutture ridondanti come i RAID possono resistere ragionevolmente
> >>> a guasti che interessano una singola unità disco, ma franeranno
> >>> rovinosamente se il guasto colpisce direttamente l'elettronica di
> >>> controllo.
> >>> e comunque, anche gli schemi RAID più' sofisticati sono progettati
> >>> per  resistere ad un singolo malfunzionamento, che richiede
> >>> quindu sempre una immediata e tempestiva riparazione del guasto.
> >>> se arrivi ad accumulare ben tre malfunzionamenti simultanei
> >>> finisci ben al di la delle capacità di recupero di qualsiasi RAID.
> >>> ma anche un singolo chip di RAM malfunzionante puo' innescare
> >>> catene di eventi assolutamente perniciosi.
> >>>
> >>> molto spesso, guasti di questa natura sono la diretta conseguenza
> >>> dell'uso di componenti esageratamente economici e di bassa
> >>> qualità, oppure derivano da un'installazione fisica gravemente
> >>> inadeguata, con un impianto elettrico fuori norma e/o con
> >>> condizioni
> >>> termiche di costante surriscaldamento.
> >>>
> >>> condizioni peraltro abbastanza comuni e tipiche di molte
> >>> situazioni "fai da te", in cui pare assolutamente ovvio e
> >>> naturale stipare tutti assieme numerosi server e relativi
> >>> apparati di rete all'interno di un angusto sgabuzzino delle
> >>> scope del tutto privo di ventilazione e sprovvisto di
> >>> aria condizionata.
> >>>
> >>> un caso di questo genere di cui sono personalmente a
> >>> conoscenza fini' addirittura con un bell'incendio nel
> >>> cuore della notte che distrusse l'intero ufficio e che
> >>> mise seriamente a repentaglio la stessa stabilita'
> >>> strutturale dell'edificio.
> >>>
> >>> insomma, la moderna elettronica e' sicuramente molto
> >>> affidabile, ma non puo' certo reistere alle scellerate
> >>> conseguenze di un'installazione errata in un ambienete
> >>> fisico del tutto inadeguato; le sale macchine "serie"
> >>> sono attrezzate in ben altro modo.
> >>>
> >>> (oltre a qualche zilione di ulteriori possibili cause
> >>> piu' o meno improbabili ed imprevedibili che quando si
> >>> dice che la sfiga si accanisce ... vai un po' a sapere)
> >>>
> >>> ciao Sandro
> >>> _______________________________________________
> >>> Gfoss a lists.gfoss.it [1]
> >>> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss [2]
> >>> Questa e' una lista di discussione pubblica aperta a tutti.
> >>> I messaggi di questa lista non hanno relazione diretta con le
> >>> posizioni dell'Associazione GFOSS.it.
> >>> 807 iscritti al 31/03/2016
> >>
> >>
> >> --
> >>
> >> GIUSEPPE NAPONIELLO
> >>
> >> ARC-TEAM SRL
> >> piazza Navarrino, 13 - 38023Cles (TN)
> >> C.F. e P. IVA IT-01941600221
> >> cell. +393476846599
> >> mail: beppenapo a arc-team.com [4]
> >> pec: arc-team a pec.it [5]
> >>
> >> 101 | www.arc-team.com [6]
> >> 110 | http://arc-team-open-research.blogspot.it/ [7]
> >> 000 | https://independent.academia.edu/GiuseppeNaponiello [8]
> >>
> >> Links:
> >> ------
> >> [1] mailto:Gfoss a lists.gfoss.it
> >> [2] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> >> [3] mailto:a.furieri a lqt.it
> >> [4] mailto:beppenapo a arc-team.com
> >> [5] mailto:arc-team a pec.it
> >> [6] http://www.arc-team.com/
> >> [7] http://arc-team-open-research.blogspot.it/
> >> [8] https://independent.academia.edu/GiuseppeNaponiello
> >
> >
> > _______________________________________________
> > Gfoss a lists.gfoss.it
> > http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> > Questa e' una lista di discussione pubblica aperta a tutti.
> > I messaggi di questa lista non hanno relazione diretta con le posizioni
> > dell'Associazione GFOSS.it.
> > 807 iscritti al 31/03/2016
>
>
>
> --
> -----------------
> Andrea Peri
> . . . . . . . . .
> qwerty àèìòù
> -----------------
> _______________________________________________
> Gfoss a lists.gfoss.it
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> 807 iscritti al 31/03/2016
>



-- 
*Giuseppe Naponiello*

*A**rc-**T**eam srl*
piazza Navarrino, 13 - 38023Cles (TN)
C.F. e P. IVA IT-01941600221
cell. +393476846599
mail: beppenapo a arc-team.com
pec: arc-team a pec.it
101 | www.arc-team.com
110 | http://arc-team-open-research.blogspot.it/
000 | https://independent.academia.edu/GiuseppeNaponiello


Maggiori informazioni sulla lista Gfoss