Perché un blocco del server dovrebbe eliminare altri server dalla rete?

Abbiamo un paio di dozzine di server Proxmox (Proxmox gira su Debian) e circa una volta al mese, uno di loro avrà il panico del kernel e si bloccherà. La parte peggiore di questi blocchi è che quando si tratta di un server che si trova su uno switch separato rispetto al master del cluster, tutti gli altri server Proxmox su tale switch smetteranno di rispondere fino a quando non riusciremo a trovare il server che si è effettivamente arrestato in modo anomalo e riavviarlo.

Quando abbiamo segnalato questo problema sul forum Proxmox, ci è stato consigliato di eseguire l'aggiornamento a Proxmox 3.1 e lo stiamo facendo da diversi mesi. Sfortunatamente, uno dei server che abbiamo migrato a Proxmox 3.1 si è bloccato venerdì con un panico del kernel, e di nuovo tutti i server Proxmox che si trovavano su quello stesso switch erano irraggiungibili sulla rete fino a quando non siamo riusciti a individuare il server bloccato e riavviarlo.

Bene, quasi tutti i server Proxmox sullo switch ... Ho trovato interessante che i server Proxmox su quello stesso switch che erano ancora su Proxmox versione 1.9 non fossero interessati.

Ecco una schermata della console del server in crash:

Quando il server si è bloccato, i restanti server sullo stesso switch che eseguivano anche Proxmox 3.1 sono diventati irraggiungibili e hanno emesso quanto segue:

e1000e 0000:00:19.0: eth0: Reset adapter unexpectedly
e1000e 0000:00:19.0: eth0: Reset adapter unexpectedly
e1000e 0000:00:19.0: eth0: Reset adapter unexpectedly
...etc...

uname -a output del server bloccato:

Linux ------ 2.6.32-23-pve #1 SMP Tue Aug 6 07:04:06 CEST 2013 x86_64 GNU/Linux

pveversion -v output (abbreviato):

proxmox-ve-2.6.32: 3.1-109 (running kernel: 2.6.32-23-pve)
pve-manager: 3.1-3 (running version: 3.1-3/dc0e9b0e)
pve-kernel-2.6.32-23-pve: 2.6.32-109

Due domande:

1. Qualche indizio su cosa causerebbe il panico del kernel (vedi immagine sopra)?

2. Perché altri server sullo stesso switch e versione di Proxmox dovrebbero essere eliminati dalla rete fino al riavvio del server bloccato? (Nota: c'erano altri server sullo stesso switch che eseguivano la versione 1.9 precedente di Proxmox che non erano interessati. Inoltre, nessun altro server Proxmox nello stesso cluster 3.1 era interessato che non erano sullo stesso switch.)

Grazie in anticipo per qualsiasi consiglio.

Sono quasi certo che il tuo problema non sia causato da un solo fattore, ma piuttosto da una combinazione di fattori. Quali siano questi singoli fattori non è certo, ma molto probabilmente un fattore è l'interfaccia di rete o il driver e un altro fattore si trova sullo switch stesso. Quindi è molto probabile che il problema possa essere riprodotto solo con questa particolare marca di switch combinata con questa particolare marca di interfaccia di rete.

Sembra che il trigger per il problema sia qualcosa che sta accadendo su un singolo server che ha quindi un panico del kernel che ha effetti che in qualche modo riescono a propagarsi attraverso lo switch. Sembra probabile, ma direi che è probabile che il grilletto sia da qualche altra parte.

È possibile che stia succedendo qualcosa sullo switch o sull'interfaccia di rete, il che provoca contemporaneamente il panico del kernel e collega i problemi sullo switch. In altre parole, anche se il kernel non avesse avuto un panico nel kernel, il trigger potrebbe aver abbattuto la connettività sullo switch.

Bisogna chiedersi cosa potrebbe accadere sul singolo server, che potrebbe avere questo effetto sugli altri server. Non dovrebbe essere possibile, quindi la spiegazione deve comportare un difetto da qualche parte nel sistema.

Se fosse solo il collegamento tra il server in crash e lo switch che è andato giù o è diventato instabile, allora ciò non dovrebbe avere alcun effetto sullo stato del collegamento con gli altri server. In tal caso, ciò sarebbe considerato un difetto dell'interruttore. E dal punto di vista del traffico, gli altri server dovrebbero vedere un po 'meno traffico una volta che il server in crash ha perso la connettività, il che non può spiegare perché vedono il problema.

Questo mi porta a credere che sia probabile un difetto di progettazione sull'interruttore.

Tuttavia, un problema di collegamento non è la prima spiegazione che si dovrebbe cercare quando si tenta di spiegare come un problema su un server potrebbe causare problemi ad altri server sullo switch. Una tempesta di trasmissione sarebbe una spiegazione più ovvia. Ma potrebbe esserci un collegamento tra un server con un panico nel kernel e una tempesta di trasmissione?

Multicast e pacchetti destinati a indirizzi MAC sconosciuti sono più o meno trattati allo stesso modo delle trasmissioni, quindi anche una tempesta di tali pacchetti conterebbe. È possibile che il server paniced stia tentando di inviare un crashdump attraverso la rete a un indirizzo MAC non riconosciuto dallo switch?

Se questo è il trigger, allora qualcosa va storto sugli altri server. Perché una tempesta di pacchetti non dovrebbe causare questo tipo di errore sull'interfaccia di rete. Reset adapter unexpectedlynon suona come una tempesta di pacchetti (che dovrebbe causare solo un calo delle prestazioni ma nessun errore in quanto tale) e non suona come un problema di collegamento (che avrebbe dovuto causare la caduta di messaggi sui collegamenti, ma non l'errore che si sta verificando vedendo).

Quindi è probabile che ci sia qualche difetto nell'hardware o nel driver dell'interfaccia di rete, che è attivato dallo switch.

Alcuni suggerimenti che possono fornire ulteriori indizi:

1. Riesci a collegare qualche altra apparecchiatura allo switch e guardare quale traffico vedi sullo switch quando si presenta il problema (prevedo che si stia zittendo o vedi un'inondazione).
2. Sarebbe possibile sostituire l'interfaccia di rete su uno dei server con un marchio diverso utilizzando un driver diverso per vedere come il risultato risulta diverso?
3. È possibile sostituire uno degli interruttori con una marca diversa? Mi aspetto che la sostituzione dello switch assicurerà che il problema non riguardi più server multipli. La cosa più interessante da sapere è se si ferma anche il panico del kernel.

Mi sembra un bug nel driver Ethernet o nell'hardware / firmware, essendo una bandiera rossa:

e1000e 0000:00:19.0: eth0: Reset adapter unexpectedly
e1000e 0000:00:19.0: eth0: Reset adapter unexpectedly
e1000e 0000:00:19.0: eth0: Reset adapter unexpectedly

Ho già visto questi e può mettere offline il server. Non ricordo esattamente se fosse su schede Ethernet Intel, ma credo di si. Potrebbe anche essere correlato a un bug nelle stesse schede Ethernet. Ricordo di aver letto qualcosa su particolari schede Ethernet che presentano tali problemi. Ma ho perso il link dell'articolo.

Immagino che il trigger per questo dipenda in parte dal driver (versione) in uso, il fatto che una versione precedente del software funzioni bene sembra confermarlo. Dici che il fornitore usa il proprio kernel personalizzato, prova ad aggiornare il modulo del driver ethernet che viene utilizzato per il tuo particolare hardware ethernet. Uno dal tuo fornitore o uno dall'albero dei sorgenti del kernel ufficiale.

Cerca anche di collegare il tuo hardware Ethernet, normalmente un server avrebbe due porte Ethernet, integrate e / o aggiunte su scheda. In questo modo se una scheda Ethernet presenta questo problema, l'altra prenderà. Uso la parola "scheda" ma ovviamente si applica a qualsiasi hardware Ethernet.

Anche la sostituzione dell'hardware Ethernet può risolverlo. Sostituisci o aggiungi una nuova scheda Ethernet (intel) e usala invece. È probabile che se il problema è nell'hardware / firmware, una scheda più recente ha una correzione (o più vecchia?).