¿Por qué un bloqueo del servidor eliminaría a otros servidores de la red?

Tenemos un par de docenas de servidores Proxmox (Proxmox se ejecuta en Debian), y aproximadamente una vez al mes, uno de ellos tendrá un kernel panic y se bloqueará. La peor parte de estos bloqueos es que cuando se trata de un servidor que está en un conmutador separado del maestro del clúster, todos los demás servidores Proxmox en ese conmutador dejarán de responder hasta que podamos encontrar el servidor que realmente se ha bloqueado y reiniciarlo.

Cuando informamos este problema en el foro de Proxmox, se nos recomendó actualizar a Proxmox 3.1 y hemos estado en proceso de hacerlo durante los últimos meses. Desafortunadamente, uno de los servidores que migramos a Proxmox 3.1 se encerró con un kernel panic el viernes, y nuevamente todos los servidores Proxmox que estaban en ese mismo conmutador no fueron accesibles a través de la red hasta que pudimos localizar el servidor bloqueado y reiniciarlo.

Bueno, casi todos los servidores Proxmox en el conmutador ... Me pareció interesante que los servidores Proxmox en ese mismo conmutador que todavía estaban en Proxmox versión 1.9 no se vieran afectados.

Aquí hay una captura de pantalla de la consola del servidor bloqueado:

ingrese la descripción de la imagen aquí

Cuando el servidor se bloqueó, el resto de los servidores en el mismo conmutador que también ejecutaban Proxmox 3.1 se volvieron inalcanzables y arrojaban lo siguiente:

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 -una salida del servidor bloqueado:

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

Salida pveversion -v (abreviada):

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

Dos preguntas:

¿Alguna pista de lo que podría estar causando el pánico en el núcleo (ver imagen arriba)?
¿Por qué otros servidores en el mismo conmutador y versión de Proxmox serán desconectados de la red hasta que se reinicie el servidor bloqueado? (Nota: había otros servidores en el mismo conmutador que ejecutaban la versión 1.9 anterior de Proxmox que no se vieron afectados. Además, ningún otro servidor Proxmox en el mismo clúster 3.1 se vio afectado que no estaba en ese mismo conmutador).

Gracias de antemano por cualquier consejo.

— Curtis
fuente

¿Puedes dar el crashdump completo? La imagen de arriba corta las partes interesantes. Además, ¿publicaste el crashdump en lkml ? Sin embargo, viéndolo de nuevo, este es un núcleo bastante antiguo, ¿hay planes para actualizar Debian a una versión estable actual?

— ckujau

Lamentablemente, no tenemos un volcado de memoria. Lo agregué a mi lista para configurar una consola serie y / o kdump. En cuanto a que el núcleo es antiguo, Proxmox utiliza un núcleo de OpenVZ que es una rama del núcleo principal. Entonces, una vez que pueda hacer que funcionen los volcados de memoria, me pondré en contacto con los desarrolladores de OpenVZ para obtener ayuda. Gracias por tu comentario ... me ayudó a apuntar en la dirección correcta.

— Curtis

¿Qué tipo de cambio?

— ETL

El problema ha sucedido con 3 conmutadores diferentes (un dlink y 2 cisco). No tengo los números de modelo en los dos conmutadores anteriores, pero el último es un Cisco SG102-24. Dado que solo afecta a los servidores en el conmutador que ejecutan el mismo núcleo, y debido a que estoy en mi tercer conmutador, parece poco probable que el culpable sea el conmutador (aunque ese fue mi pensamiento original también).

— Curtis

Recibí una notificación por correo electrónico de que alguien publicó el siguiente comentario aquí ... "Tengo un problema similar, excepto que puedo hacer que la mina se estrelle con un par de contenedores haciendo núcleo duro ..." Desafortunadamente, se cortó allí y cuando llegué aquí, el autor había eliminado su comentario, así que no sé cuál fue el resto. Pero, agregaré que he notado que el problema parece ocurrir con mayor frecuencia cuando hay mucho tráfico de red (como cuando se ejecutan las copias de seguridad). ¿Quizás ese comentario fue "transferencias de red hardcore"?

— Curtis

Respuestas:

Estoy casi seguro de que su problema no es causado por un solo factor sino por una combinación de factores. No están seguros cuáles son esos factores individuales, pero lo más probable es que un factor sea la interfaz de red o el controlador y se encuentre otro factor en el conmutador. Por lo tanto, es muy probable que el problema solo pueda reproducirse con esta marca particular de conmutador combinada con esta marca particular de interfaz de red.

Parece que el desencadenante del problema es algo que sucede en un servidor individual que luego tiene un kernel panic que tiene efectos que de alguna manera logran propagarse a través del conmutador. Esto suena probable, pero diría que es casi tan probable, que el disparador esté en otro lugar.

Podría ser que algo esté sucediendo en el conmutador o la interfaz de red, lo que simultáneamente causa pánico en el núcleo y problemas de enlace en el conmutador. En otras palabras, incluso si el kernel no hubiera tenido pánico en el kernel, el desencadenante podría haber reducido la conectividad en el conmutador.

Uno tiene que preguntarse qué podría suceder en el servidor individual, lo que podría tener este efecto en los otros servidores. No debería ser posible, por lo que la explicación debe involucrar una falla en algún lugar del sistema.

Si fue solo el enlace entre el servidor bloqueado y el conmutador que se cayó o se volvió inestable, entonces eso no debería tener ningún efecto en el estado del enlace a los otros servidores. Si lo hace, eso contaría como un defecto en el interruptor. Y en lo que respecta al tráfico, los otros servidores deberían ver un poco menos de tráfico una vez que el servidor bloqueado pierda la conectividad, lo que no puede explicar por qué ven el problema que hacen.

Esto me lleva a creer que es probable una falla de diseño en el interruptor.

Sin embargo, un problema de enlace no es la primera explicación que se buscaría al tratar de explicar cómo un problema en un servidor podría causar problemas a otros servidores en el conmutador. Una tormenta de difusión sería una explicación más obvia. Pero, ¿podría haber un vínculo entre un servidor que tiene un kernel panic y una tormenta de difusión?

La multidifusión y los paquetes destinados a direcciones MAC desconocidas se tratan más o menos de la misma manera que las transmisiones, por lo que una tormenta de dichos paquetes también contaría. ¿Podría el servidor en pánico estar intentando enviar un crash crash a través de la red a una dirección MAC no reconocida por el switch?

Si ese es el desencadenante, entonces algo va mal en los otros servidores. Debido a que una tormenta de paquetes no debería causar este tipo de error en la interfaz de red. Reset adapter unexpectedlyno suena como una tormenta de paquetes (que solo debería causar una caída en el rendimiento pero no errores como tales), y no parece un problema de enlace (que debería haber dado como resultado mensajes sobre enlaces que se caen, pero no el error viendo).

Por lo tanto, es probable que haya algún defecto en el hardware o controlador de la interfaz de red, que se activa mediante el conmutador.

Algunas sugerencias que pueden dar pistas adicionales:

¿Puede conectar algún otro equipo al conmutador y ver qué tráfico ve en el conmutador cuando aparece el problema (predigo que se silencia o ve una inundación).
¿Sería posible reemplazar la interfaz de red en uno de los servidores con una marca diferente usando un controlador diferente para ver cómo el resultado resulta diferente?
¿Es posible reemplazar uno de los interruptores con una marca diferente? Espero que reemplazar el conmutador garantice que el problema ya no afecte a varios servidores. Lo que es más interesante saber es si también evita que ocurran los panics del kernel.

— kasperd
fuente

Gracias por su atenta respuesta. En términos de sus 3 sugerencias: 1) ¿Qué tipo de equipo / software haría eso? 2) Ojalá pudiera, pero hay muchos servidores involucrados y no sé dónde ocurrirá el problema a continuación. 3) Ya he probado 3 interruptores diferentes (3 modelos diferentes, 2 marcas diferentes). También es interesante que solo los servidores en la misma versión de Proxmox se ven afectados. Proxmox tiene un mecanismo de sincronización de clúster, por lo que sospecho que tiene algo que ver con eso. Afortunadamente, han pasado un par de meses desde que se produjo el problema ahora.

— Curtis

Para mirar el tráfico en el conmutador, estaba pensando en conectar una PC normal con tcpdump y / o wireshark. Obviamente, querrás evitar tener el software afectado instalado en esa PC. Pero parece que debe haber un error en el código que Proxmox instala en el núcleo. Si sucede tan raramente, que solo lo ve aproximadamente una vez al mes y solo en un interruptor a la vez, entonces puede llevar mucho tiempo rastrearlo. Lo pensaré un poco y comentaré si surgen más ideas.

— Kasperd

A mí me suena como un error en el controlador de Ethernet o el hardware / firmware, esto es una bandera roja:

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

Los he visto antes y puede desconectar el servidor. No recuerdo exactamente si estaba en tarjetas Intel Ethernet, pero creo que sí. Incluso podría estar relacionado con un error en las tarjetas ethernet. Recuerdo haber leído algo sobre tarjetas de Intel en particular que tienen tales problemas. Pero perdí el enlace del artículo.

Me imagino que el desencadenante de esto depende en parte del controlador (versión) que se utilice, el hecho de que una versión anterior del software funcione bien parece confirmar eso. Usted dice que el proveedor usa su propio núcleo personalizado, intente actualizar el módulo del controlador de ethernet que se está utilizando para su hardware de ethernet particular. Ya sea uno de su proveedor o uno del árbol de fuentes del núcleo oficial.

También busque vincular su hardware de ethernet, normalmente un servidor tendría dos puertos ethernet, integrados y / o agregados en la (s) tarjeta (s). De esa manera, si una tarjeta de Ethernet tiene este problema, la otra se activará. Yo uso la palabra "tarjeta" pero se aplica a cualquier hardware de Ethernet, por supuesto.

También reemplazar el hardware de Ethernet puede solucionarlo. Reemplace o agregue una nueva tarjeta Ethernet (Intel) y úsela en su lugar. Lo más probable es que si el problema está en el hardware / firmware, una tarjeta más nueva tiene una solución (¿o más antigua?).

— aseq
fuente

Todas las máquinas tienen dos puertos ethernet, sin embargo, este error ocurre en varios servidores al mismo tiempo que están en el mismo conmutador en el mismo momento en que una de las máquinas se bloquea. En el momento en que se apaga y enciende el servidor bloqueado, todos los servidores afectados vuelven a ser accesibles al instante. Esto parece indicar que el servidor bloqueado no está completamente bloqueado, pero de alguna manera está inundando el reinicio de las máquinas en el mismo conmutador. Sería interesante ver si una actualización del controlador podría ayudar, pero no creo que la activación de la otra tarjeta ethernet pueda ayudar según la evidencia.

— Curtis

Hilo antiguo, pero incluso con el modelo Intel e1000e NIC 82574L y una de las versiones más nuevas de ProxMox de 5.0-23 / af4267bf, los problemas de red aún persisten. Puedo abrir mi computadora portátil con Windows (despertarme del modo de suspensión o simplemente iniciar sesión) conectada al mismo conmutador y el servidor ProxMox se reinicia básicamente cada vez. También lo he visto reiniciar esporádicamente cuando no está conectado al conmutador. Y se reiniciará cuando lo conecte por primera vez al conmutador. El controlador actual es 3.3.5.3 y hay un 3.3.5.10, 3.3.6 y 3.4.0.2, así que probablemente intente construir y usar esos. Mi .02c.

— JGlass