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

[Giuseppe Naponiello]

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 ;)
--
*Giuseppe Naponiello*

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

_______________________________________________
[hidden email]
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

[a.furieri]

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
_______________________________________________
[hidden email]
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

[a.furieri]

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
>> _______________________________________________
>> [hidden email] [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. [phone]
> mail: [hidden email] [4]
> pec: [hidden email] [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:[hidden email]
> [2] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> [3] mailto:[hidden email]
> [4] mailto:[hidden email]
> [5] mailto:[hidden email]
> [6] http://www.arc-team.com/
> [7] http://arc-team-open-research.blogspot.it/
> [8] https://independent.academia.edu/GiuseppeNaponiello

_______________________________________________
[hidden email]
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]

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,  <[hidden email]> 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
>>> _______________________________________________
>>> [hidden email] [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. [phone]
>> mail: [hidden email] [4]
>> pec: [hidden email] [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:[hidden email]
>> [2] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
>> [3] mailto:[hidden email]
>> [4] mailto:[hidden email]
>> [5] mailto:[hidden email]
>> [6] http://www.arc-team.com/
>> [7] http://arc-team-open-research.blogspot.it/
>> [8] https://independent.academia.edu/GiuseppeNaponiello
>
>
> _______________________________________________
> [hidden email]
> 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 àèìòù
-----------------
_______________________________________________
[hidden email]
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]

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 <[hidden email]> 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,  <[hidden email]> 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
> >>> _______________________________________________
> >>> [hidden email] [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. [phone]
> >> mail: [hidden email] [4]
> >> pec: [hidden email] [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:[hidden email]
> >> [2] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> >> [3] mailto:[hidden email]
> >> [4] mailto:[hidden email]
> >> [5] mailto:[hidden email]
> >> [6] http://www.arc-team.com/
> >> [7] http://arc-team-open-research.blogspot.it/
> >> [8] https://independent.academia.edu/GiuseppeNaponiello
> >
> >
> > _______________________________________________
> > [hidden email]
> > 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 àèìòù
> -----------------
> _______________________________________________
> [hidden email]
> 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. [phone]
mail: [hidden email]
pec: [hidden email]
101 | www.arc-team.com
110 | http://arc-team-open-research.blogspot.it/
000 | https://independent.academia.edu/GiuseppeNaponiello

_______________________________________________
[hidden email]
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