We are in the process of migrating this forum. A new space will be available soon. We are sorry for the inconvenience.

Blocchi, freeze di server e diagnostico


boanergos
14.11.2014, 09.53
Ciao Roberto.

Dopo il blocco del 22 di Ottobre, hanno analizzato il server che si è freezato con schermo nero e hanno deciso per la sostituzione dell'alimentatore.

Adesso ho l'alimentatore sostituito e vediamo che cosa succede.

Buon fine settimana.

Marco

boanergos
04.11.2014, 14.32
Ciao Roberto.

Come vedi anche le mie risposte non sono velocissime!

Il mistero si fa sempre più fitto.

Il server che è crashato il 22 di Ottobre ha già i driver cambiati:

scsi-megaraid-sas 6.603.55.00-1OEM.500.0.0.472560 LSI VMwareCertified 2014-08-09
scsi-megaraid-mbox 2.20.5.1-6vmw.550.0.0.1331820 VMware VMwareCertified 2014-08-09
scsi-megaraid2 2.00.4-9vmw.550.0.0.1331820 VMware VMwareCertified 2014-08-09

in occasione della sua messa in produzione.

Nonostante questo è la seconda volta che va in crash.

La prima è stata come ti dicevo la notte/mattina dell'11 di Agosto mentre c'era in atto il cambiamento dei sistemi di raffreddamento.
(vedi messaggio del 22 di Agosto di questo thread).
Ancora a oggi, chiamando adesso il servizio clienti a loro continua a NON risultare che la macchina è andata in crash ed è stata riavviata anche il 10/11 di Agosto.
Adesso spedirò loro gli SMS che ho ricevuto, insieme all'informazione che, quando mi sono ricollegato all'istanza VMWare tutte le macchine erano spente (non c'era ancora il riavvio automatico, configurato sull'altro server).

Adesso c'è da capire queste cose:
1) Il server che è crashato ha ancora dei problemi con il sistema di raffreddamento che ne hanno causato ancora il freeze il 22 di Ottobre?
2) Perché a loro NON risulta il crash di Agosto che è stato motivato da loro, con tempi differenti, in due modi diversi? (il primo: è un guasto o hardware o software / il secondo a oggi: forse abbiamo fatto manutenzione il 10/11 di Agosto)

A parte tutto gradirei avere solo una situazione più stabile, solida e controllabile, anche perché la complessità delle applicazioni installate non è altissima (server LAMP e qualche VPN net-to-net). Dover soffrire per questa instabilità è veramente una cosa che non mi aspettavo dopo anni di lavoro con le infrastrutture virtuali.

Grazie ancora per il tuo supporto, sperando di trovare una situazione stabile!

Ciao,
Marco

patch
28.10.2014, 10.26
Citazione Originariamente Scritto da boanergos
Aggiornamento

E' crashato anche il server P2 che avevo preso a settembre. OVH non mi sa dire esattamente se su questo server è stato effettuato il cambio di sistema di raffreddamento.

Lo metterò in rescue mode e vediamo che cosa mi dice il sistema.

Per Roberto (patch): a te è ancora successo? Come hai risolto definitivamente?

Grazie di tutto,

Marco
Ciao Marco
i miei ritardi nel rispondere diventano sempre più cronici
Il server per fortuna non ha dato più problemi ma, come già detto, credo che nel mio caso ciò che ha risolto sia stato l'aggiornamento del driver. Dopo di allora, infatti, non ho più avuto i crash che si verificavano mediamente una volta a settimana. L'intervento di Agosto per migliorare il raffreddamento è stato comunque utile, dal momento che le temperature medie segnalatemi nel momento in cui ti scrivo viaggiano dai 37 ai 42 gradi, con un picco di 45. Considera che la macchina è in produzione ed al momento vi sono circa 50 utenti che stanno utilizzando 8 VM via web o RDP.
Sinceramente la temperatura del controller che hai citato nel tuo messaggio del 22/8, anche se come tu indichi rientra nei parametri di funzionamento, mi sembra un po' altina per una macchina che si trova in una Webfarm dove le temperature ambientali dovrebbero essere decisamente basse. Per darti un parametro di confronto dovrei verificare sulla mia, ma al momento non posso farlo: potrò provarci verso la metà del mese, quando il carico di lavoro è più basso e posso metterla in standby senza tirarmi addosso le "ire funeste" dei clienti.

Saluti
Roberto

boanergos
24.10.2014, 10.26
Aggiornamento

E' crashato anche il server P2 che avevo preso a settembre. OVH non mi sa dire esattamente se su questo server è stato effettuato il cambio di sistema di raffreddamento.

Lo metterò in rescue mode e vediamo che cosa mi dice il sistema.

Per Roberto (patch): a te è ancora successo? Come hai risolto definitivamente?

Grazie di tutto,

Marco

boanergos
22.08.2014, 11.00
Ciao Roberto!
Grazie della risposta!

A me il mistero non si è ancora risolto e sto un po' perdendo la pazienza, data la mia esperienza passata e molto positiva con VMWare.

La mia situazione è al momento la seguente:

Hanno fatto l'intervento sul server "colpevole" (lo chiamerò P1) tra il 10 e l'11 Agosto.
Mi sono appoggiato per evitare danni possibili a un altro server (acquisito pochi giorni prima - lo chiamerò P2), spostando tutta la produzione su un altro EG-128 con una build di VMWare più aggiornata (ESXi 5.5 1892794).

Qui arriva l'assurdo.
Nella notte tra il 10 e 11 agosto ho un KO per macchina:

1) il primo sul server P1 in cui doveva essere effettuata la manutenzione, che era assolutamente previsto.

2) Intorno alle 5.45 non si blocca per due minuti anche il server P2? A me onestamente è sembrata una cosa molto strana, anche perché il blocco rilevato dall'SMS che mi arriva risulta essere di due minuti (arrivo SMS del down e arrivo SMS di UP). Inizialmente ho immaginato che avessero spento la macchina, pensando di dover intervenire anche su quella e poi, accortisi dell'errore, l'hanno subito riaccesa.
Chiamando il supporto tecnico invece mi dicono che la macchina si è bloccata.
Per email mi avevano assicurato che la macchina nuova NON avrebbe avuto i problemi di raffreddamento della precedente e quindi...che cosa è successo?

I driver sono questi:
~ # esxcli software vib list | grep -i mega
scsi-megaraid-sas 6.603.55.00-1OEM.500.0.0.472560 LSI VMwareCertified 2014-08-09
scsi-megaraid-mbox 2.20.5.1-6vmw.550.0.0.1331820 VMware VMwareCertified 2014-08-09
scsi-megaraid2 2.00.4-9vmw.550.0.0.1331820 VMware VMwareCertified 2014-08-09

in linea con quella che dovrebbe essere la situazione stabile.

Apro allora il ticket incidente sul nuovo server P2; mi dicono che vedono dei messaggi strani sul syslog:

2014-08-20T13:17:44Z sfcb-hhrc[35334]: Associators
lsi/LSIMR13:LSIESG_MegaRAIDHBA.CreationClassName="LSIE SG_M
egaRAIDHBA",Name="500605B006D91C80" (assocClass:
CIM_SystemDevice, resultClass: CIM_DiskDrive) failed,
status: rc -2, msg NULL
2014-08-20T13:17:44Z sfcb-hhrc[35334]: Associators
lsi/LSIMR13:LSIESG_IntegratedRAIDController.CreationCl assN
ame="LSIESG_IntegratedRAIDController",Name="500304 80156c6a
00" (assocClass: CIM_SystemDevice, resultClass:
CIM_Battery) failed, status: rc -2, msg NULL

Controllo anche su P1 e, non potendo spostare la produzione immediatamente da P2, faccio fare il controllo su P1, in quanto nel syslog ci sono i medesimi errori (li hai anche tu?)

Metto in rescue mode P1 e su P1 notano che la temperatura del controller MegaRaid LSI, nonostante l'intervento del 10 Agosto, è di 87 gradi centigradi con l'attività del disco che è a zero (nessuna macchina virtuale attivata).
Adesso hanno sostituito la ventola un'altra volta e la temperatura sembra sia stabile sui 72 gradi (per me sempre un po' troppo alta, anche se ancora rimane nelle specifiche da documento).

Tutti questi blocchi rimangono veramente un mistero, anche perché su ciascun server non ho fatto chissà che cosa, se non installare l'immagine di VMWare ESXi 5.5 fornita da OVH e mettere delle macchine virtuali con delle applicazioni LAMP. Nulla che sia particolarmente complesso.

In attesa che il mistero si chiarisca, ti chiedo questo: quale comando utilizzi per vedere la temperatura del controller LSI? Devi per forza mettere la macchina in rescue mode? C'è qualche comando diretto da shell di VMWARE ESXi 5.5? Ho provato a vedere la documentazione, ma non trovo nulla.

Grazie per le informazioni!

Buona giornata.

Marco

patch
11.08.2014, 07.03
Ciao Marco
scusa per il ritardo nella risposta.
L'intervento da te citato è stato realizzato questa mattina sul mio server ed ha richiesto il fermo macchina; successivamente, almeno nel mio caso, hanno provveduto loro al riavvio.
Ho controllato l'impatto dell'intervento sulle temperature e c'è stata una diminuzione di circa 2 gradi centigradi. In base ai test che avevo però effettuato in precedenza, non credo fosse questa l'origine del problema, dal momento che le temperature precedenti erano comunque accettabili e nè il test della CPU nè quello della RAM, che sovraccaricano abbastanza la macchina, avevano dato problemi.
Credo invece che l'aggiornamento del driver del controller fosse la giusta soluzione (anche in base a quanto veniva riportato sulla console al momento del freeze): da quando l'ho realizzato, non ho avuto più alcun blocco.

Saluti
Roberto



Citazione Originariamente Scritto da boanergos
Ho un aggiornamento sul server di produzione.

OVH mi ha mandato una segnalazione per cui nella prossima settimana miglioreranno il sistema di raffreddamento dei server che hanno come scheda madre la Supermicro X9SRH-7TF,
Nella mia analisi del server di produzione non avevo notato alcuna anomalia software e devo effettuare in questi giorni il diagnostico.
Con un ticket come questo viene da pensare che il freeze capitato al server, sia dovuto proprio al sistema di raffreddamento che non fa il suo dovere.

Ecco la segnalazione:
"Faults have been detected on several servers equipped with a SuperMicro X9SRH-7TF motherboard.

To increase server reliability, we will intervene in approximately ten minutes on the affected machines, with the aim of improving the cooling system.

We will carry out interventions over 2 days:

- From 00:00 on Sunday, August 10th 2014 until 07:00 on Monday, August 11th 2014
- From 22:00 on Monday, August 11th 2014 until 07:00 on August 12th

Affected customers will be contacted during the week via an incident ticket."

Quello che vorrei capire è a che ora esattamente i nostri server saranno sotto manutenzione evitando di dover stare sveglio tutta la notte.

Un'altra cosa "particolare" è il testo:
"It is suggested that you make a backup of all important data as a safety precaution."

Vedremo.

Per Roberto: la tua modifica dei driver al server ha sortito gli effetti desiderati? Grazie di tutto ancora!

Marco

boanergos
04.08.2014, 10.20
Ho un aggiornamento sul server di produzione.

OVH mi ha mandato una segnalazione per cui nella prossima settimana miglioreranno il sistema di raffreddamento dei server che hanno come scheda madre la Supermicro X9SRH-7TF,
Nella mia analisi del server di produzione non avevo notato alcuna anomalia software e devo effettuare in questi giorni il diagnostico.
Con un ticket come questo viene da pensare che il freeze capitato al server, sia dovuto proprio al sistema di raffreddamento che non fa il suo dovere.

Ecco la segnalazione:
"Faults have been detected on several servers equipped with a SuperMicro X9SRH-7TF motherboard.

To increase server reliability, we will intervene in approximately ten minutes on the affected machines, with the aim of improving the cooling system.

We will carry out interventions over 2 days:

- From 00:00 on Sunday, August 10th 2014 until 07:00 on Monday, August 11th 2014
- From 22:00 on Monday, August 11th 2014 until 07:00 on August 12th

Affected customers will be contacted during the week via an incident ticket."

Quello che vorrei capire è a che ora esattamente i nostri server saranno sotto manutenzione evitando di dover stare sveglio tutta la notte.

Un'altra cosa "particolare" è il testo:
"It is suggested that you make a backup of all important data as a safety precaution."

Vedremo.

Per Roberto: la tua modifica dei driver al server ha sortito gli effetti desiderati? Grazie di tutto ancora!

Marco

boanergos
22.07.2014, 12.17
Update: sul secondo server, quello di test, ho in effetti la versione precedente che aggiornerò al più presto.

~ # esxcli software vib list | grep -i mega
vmware-esx-MegaCli-8.07.07 8.07.07-01 LSI PartnerSupported 2014-04-10
scsi-megaraid-mbox 2.20.5.1-6vmw.550.0.0.1331820 VMware VMwareCertified 2014-04-10
scsi-megaraid-sas 5.34-9vmw.550.0.0.1331820 VMware VMwareCertified 2014-04-10
scsi-megaraid2 2.00.4-9vmw.550.0.0.1331820 VMware VMwareCertified 2014-04-10


Grazie!

Marco

boanergos
22.07.2014, 12.11
Ciao Roberto.

Il risultato della lista del megaraid è:

~ # esxcli software vib list|grep -i mega
scsi-megaraid-sas 6.603.55.00-1OEM.500.0.0.472560 LSI VMwareCertified 2014-05-28
scsi-megaraid-mbox 2.20.5.1-6vmw.550.0.0.1331820 VMware VMwareCertified 2014-05-28
scsi-megaraid2 2.00.4-9vmw.550.0.0.1331820 VMware VMwareCertified 2014-05-28

La versione del megaraid-sas è superiore.
Proverò ancora a controllare riga per riga il log del purple screen.

Grazie ancora e in anticipo per tutte le notizie!

Ci teniamo aggiornati.

Marco

boanergos
22.07.2014, 11.53
Grazie Roberto, verifico subito e ti terrò aggiornato.

Non so se mi puoi mandare un messaggio in privato con questo sistema (dobbiamo verificare)...così ci scambiamo l'email e ci teniamo aggiornati.

Ciao,
Marco


Citazione Originariamente Scritto da patch
Ciao Marco
ho un problema simile al tuo con un EG128 + opzione Raid HARD LSI 9271-4i Cachevault 1 GB (+€15.00/mese), con il quale sto combattendo da circa 15 giorni.
Ho effettuato tutti i test diagnostici senza alcun errore (la durata del test della RAM dipende dalla sua dimensione ed alla fine ti viene rilasciato un log, per il mio 128 GB ci ha messo circa 5 o 6 ore, quello della CPU lo devi far andare almeno per 30 minuti o più: se il server non si blocca allora è tutto ok).
Ipotizzando un bug presente nella release 5.5 con VM che utilizzano schede Ethernet E1000 e non VMXNET3, ho anche effettuato un downgrade alla 5.1, senza alcun risultato.
Stamattina si è verificato l'ennesimo blocco e per fortuna sono riuscito ad intervenire prima che il Servizio Tecnico riavviasse la macchina.
Ho lanciato il Remote KVM e, come mi aspettavo, sulla console ho trovato il classico Purple Screen con una serie di errori. Uno in particolare "forse" mi ha messo sulla buona strada (dico forse perchè ho applicato le correzioni solo da un paio di ore e quindi non posso essere ancora certo di aver risolto).

http://i.share.pho.to/6e7a61d5_c.jpeg

Da quanto ho letto in giro, l'errore potrebbe essere dovuto allo scsi-megaraid-sas driver: se la sua versione è inferiore alla 6.506.51.00.1vmw si possono verificare questi blocchi e deve essere quindi aggiornato. Puoi verificare la tua da una sessione SSH con il comando esxcli software vib list | grep -i mega. La mia versione, quella installata dalla iso OVH, era la 5.34-4vmw

http://i.share.pho.to/b4f2d586_c.jpeg

Ho scaricato i nuovi driver da questo link
https://my.vmware.com/web/vmware/det...&productId=229
e li ho installati sul server ESXi: dopo il riavvio, il driver risultava aggiornato alla versione 6.506.51.00.1vmw

Ho rimesso il server in produzione ed ora sto effettuando un test di carico sui dischi, sperando che il problema non si verifichi più.

Spero di esserti stato utile: fammi gentilmente sapere se sei riuscito a risolvere.
Ciao

Roberto

patch
22.07.2014, 10.22
Ciao Marco
ho un problema simile al tuo con un EG128 + opzione Raid HARD LSI 9271-4i Cachevault 1 GB (+€15.00/mese), con il quale sto combattendo da circa 15 giorni.
Ho effettuato tutti i test diagnostici senza alcun errore (la durata del test della RAM dipende dalla sua dimensione ed alla fine ti viene rilasciato un log, per il mio 128 GB ci ha messo circa 5 o 6 ore, quello della CPU lo devi far andare almeno per 30 minuti o più: se il server non si blocca allora è tutto ok).
Ipotizzando un bug presente nella release 5.5 con VM che utilizzano schede Ethernet E1000 e non VMXNET3, ho anche effettuato un downgrade alla 5.1, senza alcun risultato.
Stamattina si è verificato l'ennesimo blocco e per fortuna sono riuscito ad intervenire prima che il Servizio Tecnico riavviasse la macchina.
Ho lanciato il Remote KVM e, come mi aspettavo, sulla console ho trovato il classico Purple Screen con una serie di errori. Uno in particolare "forse" mi ha messo sulla buona strada (dico forse perchè ho applicato le correzioni solo da un paio di ore e quindi non posso essere ancora certo di aver risolto).

http://i.share.pho.to/6e7a61d5_c.jpeg

Da quanto ho letto in giro, l'errore potrebbe essere dovuto allo scsi-megaraid-sas driver: se la sua versione è inferiore alla 6.506.51.00.1vmw si possono verificare questi blocchi e deve essere quindi aggiornato. Puoi verificare la tua da una sessione SSH con il comando esxcli software vib list | grep -i mega. La mia versione, quella installata dalla iso OVH, era la 5.34-4vmw

http://i.share.pho.to/b4f2d586_c.jpeg

Ho scaricato i nuovi driver da questo link
https://my.vmware.com/web/vmware/det...&productId=229
e li ho installati sul server ESXi: dopo il riavvio, il driver risultava aggiornato alla versione 6.506.51.00.1vmw

Ho rimesso il server in produzione ed ora sto effettuando un test di carico sui dischi, sperando che il problema non si verifichi più.

Spero di esserti stato utile: fammi gentilmente sapere se sei riuscito a risolvere.
Ciao

Roberto

boanergos
19.07.2014, 07.36
Buongiorno a tutti.

Volevo capire un vostro parere.

Dopo aver lavorato per anni con infrastrutture interne e VMWare, mi trovo a utilizzare i server dedicati di OVH.

Ho acquisito due server (EG-32, EG-128). Installato VMWare ESXi 5.5 per sfruttare al massimo la memoria e per richieste economiche dell'azienda per cui lavoro, mi sono trovato ad avere:

n.1 macchina spenta il 10 Luglio, che si riaccende senza alcun intervento dei tecnici OVH (secondo il ticket dell'incidente) dopo 25 minuti in modo autonomo (35 giorni di UPTIME)
n.1 macchina freezata nella giornata di ieri che è stata riavviata dai tecnici di OVH. (44 giorni di UPTIME)

Volevo chiedere:
1) quanto impiega il diagnostico a terminare tutte le operazioni di analisi e fornire i report da mandare a OVH?

2) è così comune avere questi blocchi macchina con "server dedicato" e VRack abilitato come nel mio caso? In 6 anni di gestione di infrastruttura interna VMWare, gli unici spegnimenti di nodi che ho avuto sono stati effettuati manualmente e dovuti a manutenzione elettrica o operazioni simili. Mi stupisce che con una immagine preparata "ad hoc" sull'hardware ci siano questi blocchi a fronte di una installazione mia che poco ha fatto, se non quello di installare un numero minimo di macchine virtuali.

Buona giornata.

Marco