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 <aperi2...@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.furi...@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@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: beppen...@arc-team.com [4] > >> pec: arc-t...@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@lists.gfoss.it > >> [2] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss > >> [3] mailto:a.furi...@lqt.it > >> [4] mailto:beppen...@arc-team.com > >> [5] mailto:arc-t...@pec.it > >> [6] http://www.arc-team.com/ > >> [7] http://arc-team-open-research.blogspot.it/ > >> [8] https://independent.academia.edu/GiuseppeNaponiello > > > > > > _______________________________________________ > > Gfoss@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@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: beppen...@arc-team.com pec: arc-t...@pec.it 101 | www.arc-team.com 110 | http://arc-team-open-research.blogspot.it/ 000 | https://independent.academia.edu/GiuseppeNaponiello
_______________________________________________ Gfoss@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