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:
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.
fuente
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:
fuente
A mí me suena como un error en el controlador de Ethernet o el hardware / firmware, esto es una bandera roja:
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?).
fuente