Jump to content
Sign in to follow this  
fusioN

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

Recommended Posts

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 :)

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 :)

Share this post


Link to post
Share on other sites

/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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×