SERI problemi con un dedicato, datemi una mano per favore. :)

[fusioN]

PREMETTO: THREAD LUNGHISSIMO!!!

Ciao a tutti,

Mi trovo in una situazione quantomeno ridicola con un hosting provider presso il quale ho un server dedicato. Per correttezza non ho intenzione di fare nomi, almeno per ora.
Il server in questione ha debian [stable], un controller 3ware 8000 e directadmin (ehsì, per una volta mi sono affidato a un pannello)

Mi sono affidato a directadmin proprio per evitare di rompermi le palle con versioni di software, configurazioni, incompatibilità eccetera (in quanto è un server di produzione)

Puntualmente, circa 1 volta al mese, si PIANTA. Rimonta il filesystem in read-only [i dischi sono da 160 SATA in RAID 1] e lì resta.
Controllando da tw_cli [l'interfaccia CLI per l'hardware treeware] il risultato è il seguente

[root@lexotan][/var/log]# tw_cli
//lexotan> /c0 show

Unit  UnitType  Status         %Cmpl  Stripe  Size(GB)  Cache  AVerify  IgnECC
------------------------------------------------------------------------------
u0    RAID-1    DEGRADED       -      -       189.922   ON     -        -

Port   Status           Unit   Size        Blocks        Serial
---------------------------------------------------------------
p0     OK               u0     189.92 GB   398297088     V40DEMZG
p1     DEGRADED         u0     189.92 GB   398297088     V40B16WG

//lexotan>

Ora.
Il mio hoster dice che non è un suo problema in quanto i lserver è unmanaged.
E che il problema è di tipo SISTEMISTICO.
Io non ho di certo 20 anni di esperienza con linux ma CAZZO, un array che mi viene segnalato come DEGRADED e che si monta in read only, può davvero trattarsi di un problema sistemistico?!

Il kernel è quello di default di debian, che è stato installato insieme alla macchina. Non ho toccato una virgola.

Per quella che è la mia esperienza, considero che un problema del genere possa essere O a livello hardware oppure a livello basso [vedi kernel o modulo 3w_xxxx]

secondo voi?

La prima volta che si è presentato questo problema, la risposta è stata "si è trattato di un attacco SSH, il server è stato riavviato, verifichi i log di sistema"
Poteva anche starci.. l'avevo tirato su da poco ed effettivamente non avevo ancora cambiato la porta di default di SSH (mea culpa)
Ovviamente dopo il riavvio ho verificato i log ma nulla, il server sembrava morto tutto ad un tratto (e non c'era NESSUN tentativo di bruteforce su SSH)

Al secondo ticket aperto presso l'hoster, abbiamo avuto questo scambio di risposte:

Hoster:

Salve, ha un account di tipo unamanged, per tale ragione non possiamo controllare quale problema a livello sistemistico può avere. In caso chieda un intervento sistemistico ci autorizzi aggiornando il ticket autorizzando anche un intervento soggetto a tariffazione al costo di eur40+iva/ora.
Cordiali Saluti

Io:

Da quand'è che un device che si rimonta read-only si tratta di un problema sistemistico?

Hoster:

Salve, qualsiasi richiesta che richieda un intervento al suo server ad eccezione dei riavvii e di sostituzioni hardware è da considerarsi soggetta a tariffazione. Cordiali Saluti

Io:

allora è sufficiente un riavvio, per il resto ci darò un occhio io. grazie

Hoster:

Salve, in caso il riavvio non dovesse mandare up il server deve autorizzarci all' intervento a tariffazione per il ripristino dello stesso. Attendiamo tale autorizzazione e procederemo prima al riavvio (compreso nell' account). Cordiali Saluti

A questo punto decido che la soluzione migliore e la più sicura è quella di autorizzare questo fantomatico "intervento sistemistico" per risolvere il problema (?)

Mi viene richiesta la password di root (che puntualmente ho dato) ma non viene effettuato nessun intervento sistemistico (o quantomeno a me non è giunta nessuna fattura), ma ricevo questa risposta dall'hoster:

Salve, sembrava esserci un errore nella gestione del controller 3ware usato per il raid. è sicuro che il modulo che ha caricato di debian non crei conflitti? Per sicurezza ho comunque sostituito uno dei due hard disk (il primario) e il controller raid mettendone uno nuovo. In server è tornato operativo alle 17.52 ed ha quasi terminato il rebuild completo dell' array (operazione fa comunque a caldo). Nessun costo per l' operazione le verrà addebitato in quanto (non ne sono certo) ma si sospetta un guasto hardware. Cordiali Saluti

Già qui la situazione è paradossale, prima si parla di errore nella gestione del controller 3ware, e poi si parla di guasto hardware.
Io ovviamente, ripeto per la 23148312 esima volta, non ho (e NON avrei mai) cambiato/modificato/riconfigurato kernel e/o moduli, il server l'ho lasciato come mi è stato consegnato (sarei scemo a mettermi a smanettare sui moduli di un server in produzione).

Passa circa un mese, e lo stesso problema si ripresenta. Nuovo scambio di ticket:

Io:

.. siamo sicuri non si tratti di un problema di driver? mi sembra strano che si sia scassato DI NUOVO un disco, tra l'altro è proprio quello sostituito la volta scorsa (se non erro) ho provato a rilanciare un rebuild manuale ma non me lo lascia fare. Mi sa che in questa situazione si può solo da BIOS

Hoster:

salve, può consegnarci la password di accesso dell' utente root? nella giornata di domani un nostro sistemista effettuerà le opportune modifiche. Cordiali Saluti

Hoster nuovamente, dopo aver ricevuto la psw:

Salve, ho verificato l' hardware (smartd degli hdd) e un check al controller stesso, ma non han segnato errori. Ho ntato però beh "basta" togliere e rimettere la corrente affinchè il sistema operativo ricominci a vedere i due dischi (da bios del controller li vede entrambi). Presumo quindi sia un qualche errore nei driver del sistema operativo. Cordiali Saluti

E qui già stiamo cadendo sul ridicolo, secondo me.

Io:

Grazie dei test ma.. quindi? nel senso, ce lo teniamo così?

Hoster:

ora li vede Intanto cerco se trovo qualcosa in giro. Purtroppo non posso cambiarle scheda raid altrimenti perderebbe tutti i dati. Per lo più se ricapita ci avverte e facciamo un semplice reboot (con stacco della corrente notturno) nel frattempo che si studia una soluzione. Saluti

Io:

grazie.. vedrò di fare altrettanto nei limiti di ciò che mi è possibile saluti

Hoster:

OK, comunque consideri che ora non è scoperto, nel senso che il raid sta funzionando correttamente. Il disagio diciamo che sarebbe quel riavvio notturno una volta al mese se proprio non si trova una soluzione. Ma essendo una scheda raid (3ware 8000) molto utilizzata penso che il problema se non è già fixato venga corretto presto.

Qui la discussione finisce. Il servere lavora ottimamente per ancora un mese, e poi si ripresenta il problema.

Stufo di questa situazione contatto telefonicamente l'hoster, rispiegando il tutto.
E qui torniamo alla situazione riportata all'inizio del post... insomma: è colpa MIA.
Allora richiedo un intervento sistemistico per risolvere il problema, mi viene detto che non si può fare perchè il server non è managed, neanche a pagamento. ???? Ma qualche ticket fa non si discuteva di interventi sistemistici???

La soluzione proposta dall'hoster è ovviamente quella di passare al servizio Managed senza accesso root, chiaramente, e con un costo di quasi 50€ in più al mese se non erro.. cosa che di per se non è un grosso problema, ma non è ciò che si era preventivato.

Permettetemi il termine, mi sento preso per il culo.
Vorrei avere una vostra opinione.

P.S.
Probabilmente ci vuole poco a capire di chi sto parlando, vuoi perchè l'ho scritto magari su altri post, vuoi perchè basta un traceroute, vuoi perchè...
Gradirei però non si facesse nessun nome o domanda in merito almeno per ora.., piuttosto datemi una mano a risolvere o a capire

[daniele_dll]

Ciao,

beh innanzi tutto e a dir poco paradossale la situazione, ma magari ci sono delle incomprensioni o comunque l'hoster alza gli scudi (giustamente) perché gli sarà capitato di casini fatti dai clienti ... il problema come sempre è passare attraverso questi scudi

Allora, il problema mi sembra abbastanza "evidente", ovvero non è un problema software, nel senso che se il raid lo gestisce la scheda raid via hardware (ovvero tramite il software che sta sulla scheda del controller scsi) il sistema non può in nessun modo andare ad intaccare il suo funzionamento "da solo", ci dovrebberò essere dei bug paradossali e quindi la cosa è da mettere da parte

Ora, la cosa invece strana è la continuità temporale con il continuarsi ripetere dell'evento a fine mese!

Mi sapresti dire i giorni esatti con i relativi orari? Potrebbe essere uno script su cron del driver a fare questi casini (se ripeto è mensile fissa la cosa)

Magari non c'entra assolutamente nulla, però se c'è questa "prosecuzio" temporale mi sa che potrebbe essere un check da fare

[fusioN]

Ciao daniele,

Intanto ti ringrazio per la risposta e soprattutto tiro un respiro di sollievo: non mi sembri di certo un "niubbo qualunque" e quindi mi sento un pelo rassicurato.
Comunque.. le date dei down PRECISE non le so, purtroppo.
In cambio però, ho le date dei ticket:

2006-08-11
2006-08-16
2006-09-11
2006-10-26

Non mi sembrano proprio a tempi fissati
Riguardo al fatto degli scudi e dell'hoster: lo so benissimo che è così.. e capisco che contrattualmente può essere perfettamente "in regola", in quanto non c'è modo di dimostrare di chi è effettivamente il problema.
Per il resto.. non è questione di incomprensioni, lato mio la disponibilità è totale a discutere e parlare, ma l'hoster sembra non sentir ragioni.. in nessun modo.

Non so veramente cosa fare. Tristemente, mi vedrò quasi obbligato ad accettare la proposta per il managed. Devo tenere su un dominio importante e non posso permettermi dei downtime del genere.
Mi rendo conto di aver veramente sbagliato hoster, comunque.

[daniele_dll]

Beh direi che l'importante è iniziare a scartare i vari possibili problemi per arrivare a capire cosa può essere

Avendo le date dei ticket è possibile definire un range di un periodo nel quale potrebbe essersi verificato il problema, quindi se ora ti vuoi divertire devi andare a recuperare i log di quel periodo li:
- /var/log/messages
- (se c'è) /var/log/syslog
- (se c'è ed è pieno) /var/log/bootlog
- (e per finire) /var/log/dmesg

Dei primi 3 dovresti andare a recuperare dai non gli ultimi bensì quelli backuppati da logrotate. Considera che (almeno sulla redhat) il cron esegue il logrotate dentro cron.daily che di solito parte intorno alle 4 di notte, ma questo lo puoi verificare sul crontab

Per dire se sai che c'è stato il problema "prima" il 2006-10-26 e il quando è accaduto non si distanzia di più di uno due giorni da quella data (magari avevi effettuato dei controlli) allora recuperi quel periodo dei log

Ovviamente se li hai backuppati per settimana il problema non sussiste, basta che recuperi le ultime due settimane, credo dovrebberò bastare, poi eventualmente si procede a ritroso

Ovviamente fai un bel tar bizzippone in modo che vediamo se ci sono errori strani da parte del modulo del controller o se comnque quando si degrada il disco si vede dai log, cosi già iniziamo a farci un'idea di quello che può essere

[fusioN]

/var/log/messages

[...]
Oct 18 18:58:51 lexotan -- MARK --
Oct 18 19:18:51 lexotan -- MARK --
Oct 18 19:27:05 lexotan kernel: 3w-xxxx: scsi0: AEN: ERROR: Drive error: Port #1.
Oct 18 19:27:05 lexotan kernel: 3w-xxxx: scsi0: AEN: ERROR: Unit degraded: Unit #0.
Oct 18 19:38:51 lexotan -- MARK --
Oct 18 19:58:51 lexotan -- MARK --
[...]

Intorno alla precisa data del ticket, c'è solo un reboot (come richiesto) ma nessuna altra info
Purtroppo, non ho altri log. Il logrotate era configurato a 4 weeks (e ho cambiato immediatamente, ma ormai è tardi...) mea culpa.

Il dmesg è qui

[Ste]

fusion, il provider quale sarebbe? sinceramente capisco non sia bello da dire, ma non mi sembrano il massimo della professionalità da quel che dici sia successo

[Luca]

da quello che so ha 2 server

1 su server24
l'altro su seflow...

[fusioN]

Considerato che i tedeschi non scrivono in italiano..
Si tratta di Seflow, comunque.

Ciò che voglio sia chiaro è molto semplice
non voglio, non mi interessa, e non me ne frega proprio un cazzo (permettete il termine) di buttare fango su SeFlow.

io voglio risolvere il problema. E' questo che a me interessa, non altro.
E no.. il managed, non mi sembra una soluzione, ma un workaround. A me i workaround non vanno granchè a genio.

[giovanni81]

Fusion, qual è l'esatta versione del tuo kernel e che filesystem stai usando?

[SeFlow]

Per evitare di sollevare un' altro polverone (visto che c'è gente hce aspetta solo quello, spiego perchè secondo noi non è un guasto hardware.

Alla prima segnalazione di questo problema (considerando che è hardware standard che usiamo per centinaia di altri server), abbiamo eseguito una completa sotituzione hardware dei dischi e del controller raid. Quegli stessi dischi e controller stanno ora funzionando senza il minimo problema in un nostro server...

Può succedere di "beccare" due componenti con lo stesso problema sulla stessa macchina, però il dubbio viene sfatato con il fatto che il precedente hardware al momento è utilizzato su un' altra piattaforma senza nessun problema.

Ora noi non possiamo sapere se ha installato altro o no sul server che possa creare incompatibilità o qualsiasi altra cosa, ma ci siamo offerti di passare al servizio managed per tipo 2 mesi e risolvere in maniera definitiva il problema. Mi sembra un modo di "esserci messi in gioco" anche noi, convinti della nostra tesi, se poi, il problema si ripresenterà sarà nostra cura scusarci nei modi in cui il cliente potrà ritenersi soddisfatti, ma al momento siamo quasi certi che il problema non sia di natura hardware.

[daniele_dll]

Il fatto è che a livello software le uniche cose che possono influire sono:
- Il software di gestione della scheda
- I moduli 3w-xxxx che gestiscono la scheda

Anche se comunque il raid è gestito via hardware dalla scheda.

Ora credo che in entrambi i casi non sia possibile "causare" via questi software dei problemi di questo tipo:

Oct 18 19:27:05 lexotan kernel: 3w-xxxx: scsi0: AEN: ERROR: Drive error: Port #1.
Oct 18 19:27:05 lexotan kernel: 3w-xxxx: scsi0: AEN: ERROR: Unit degraded: Unit #0.

Che credo siano molto strani dato che prima dice errore sul disco 1 e poi dice che l'unità 0 si è degradata.

Ammetto comunque la mia ignoranza con quest'hardware e software di gestione, quindi la certezza al 100% non la potrò mai avere e mai la avrò, però mi sembra un po surreale che sia dovuto al modulo, che non va a intaccare direttamente il lavoro del controller raid dato che a fare fisicamente la copia se ne occupa in HW la scheda, o al software di gestione perché credo, e spero, che non permetta di modificare il raid sul quale il sistema sta girando (il software può sapere istantaneamente su quale sistema sta girando il tutto per evitare quindi l'auto distruzione del raid) che comunque, come detto tra le parentesi, al massimo può distruggere il raid in toto non fare perdere la sincronizzazione al primo disco dopo aver ricevuto un'errore del secondo

Per altro purtroppo ci sono solo quelle righe di log dato che le altre purtroppo sono state eliminate dal sistema :\

Ho citato su solo quelle due opzioni per il semplice motivo che sono gli unici software che, tramite delle apposite ioctl da parte del software di gestione al device /dev/sda o al modulo del kernel, quera direttamente il controller e quindi non ci può essere nient'altro che influisca sul funzionamento.

Ovviamente, ci sono tanti strati che teoricamente posso influenzare e potrebbe anche essere un mix di questi a far causare un problema, però è anche vero che alla fin fine cambiarli di nuovo può portare via qualche ora e fine che, anche se mi rendo conto che sono costi per voi, potrebberò anche risolvere il problema o togliere il dubbio mettendo un punto ad una situazione che potrebbe divenire sgradevole

--- nota ---
questo ovviamente è il mio parere come persona e non come commerciale o co-socio di una ditta che ha le sue responsabilità e deve farsi i conti in tasca, però alla fin fine siccome 2 serie di componenti non possono essere rotti facendo la prova si sta sicuri al 100% che non ci sono problemi su quei componenti

Lo so che è stupido è quasi sicuramente lo avete pure fatto, ma perché non provate a cambiare pure i cavi scsi e quelli di alimentazione? a me è capitato più volte in situazioni diverse che i cavi erano difettosi e facevano contatto male ... anche questa è un'ipotesi remota ma siccome richiede 30 secondi, se si cambiano i dischi, può aiutare a scartare possibili opzioni

[SeFlow]

Un problema ai cavi dati lo escludo, una cosa che non è stata cambiata sono i cavi dell' alimentatore, ma capiscimi che sarebbe un problema più unico che raro.

Livello software non possiamo fare verifiche approfondite in quanto il servizio è unmanaged, per poter intervenire dobbiamo necessariamente che il cliente passi ad un account managed, effettuato quello, se il problema risultasse hardware o comunque indipendente da loro e di nostra competenza sicuramente (come già detto) eiceveranno segni di scuse non solo a parole

Quello che possiamo fare l' abbiamo fatto

[TheVice]

scusate la mia partecipazione da "niubbo" ma da quel che vedo su quel controller esistono tante "magiche" combinazioni da rispettare ...

http://www.accs.com/p_and_p/3WareRev.html

poi se ho letto bene qui:
http://www.3ware.com/download/Escala..._Notes_Web.pdf

ci possono essere delle altre magiche combinazioni in funzione del chipset montato sulla mainboard e del sistema operativo usato (ho visto post di problemi su CentOS anche se con errori diversi da quello riscontrato)

[Luca]

https://twiki.cern.ch/twiki/bin/view/FIOgroup/DiskPrbTw

forse è una boiata...

[daniele_dll]

Un problema ai cavi dati lo escludo, una cosa che non è stata cambiata sono i cavi dell' alimentatore, ma capiscimi che sarebbe un problema più unico che raro.

Livello software non possiamo fare verifiche approfondite in quanto il servizio è unmanaged, per poter intervenire dobbiamo necessariamente che il cliente passi ad un account managed, effettuato quello, se il problema risultasse hardware o comunque indipendente da loro e di nostra competenza sicuramente (come già detto) eiceveranno segni di scuse non solo a parole

Quello che possiamo fare l' abbiamo fatto

Beh, si è no nel senso che si avete fatto delle prove ma di certo una prova non toglie i dubbi, o per lo meno io per togliermi tutti i dobbi ne eseguo sempre di più

ovviamente, ripeto, mi rendo conto che voi siete una società e se doveste impiegare il triplo del tempo i costi salirebberò in maniera vertiginosa, ma ...