TL; Versión DR: Resulta que este fue un error profundo de red Broadcom en Windows Server 2008 R2. Reemplazar con hardware Intel lo arregló. Ya no usamos hardware Broadcom. Siempre.
Hemos estado usando HAProxy junto con heartbeat del proyecto Linux-HA. Estamos utilizando dos instancias de Linux para proporcionar una conmutación por error. Cada servidor tiene su propia IP pública y una única IP que se comparte entre los dos mediante una interfaz virtual (eth1: 1) en IP: 69.59.196.211
La interfaz virtual (eth1: 1) IP 69.59.196.211 se configura como la puerta de enlace para los servidores de Windows detrás de ellos y usamos ip_forwarding para enrutar el tráfico.
Estamos experimentando una interrupción ocasional de la red en uno de nuestros servidores de Windows detrás de nuestras puertas de enlace de Linux. HAProxy detectará que el servidor está fuera de línea, lo que podemos verificar mediante la conexión remota al servidor fallido e intentando hacer ping a la puerta de enlace:
Pinging 69.59.196.211 con 32 bytes de datos: Respuesta del 69.59.196.220: host de destino inalcanzable.
La ejecución arp -aen este servidor fallido muestra que no hay entrada para la dirección de la puerta de enlace (69.59.196.211):
Interfaz: 69.59.196.220 --- 0xa Dirección de Internet Tipo de dirección física 69.59.196.161 00-26-88-63-c7-80 dinámico 69.59.196.210 00-15-5d-0a-3e-0e dinámico 69.59.196.212 00-21-5e-4d-45-c9 dinámico 69.59.196.213 00-15-5d-00-b2-0d dinámico 69.59.196.215 00-21-5e-4d-61-1a dinámico 69.59.196.217 00-21-5e-4d-2c-e8 dinámico 69.59.196.219 00-21-5e-4d-38-e5 dinámico 69.59.196.221 00-15-5d-00-b2-0d dinámico 69.59.196.222 00-15-5d-0a-3e-09 dinámico 69.59.196.223 ff-ff-ff-ff-ff-ff estática 224.0.0.22 01-00-5e-00-00-16 estático 224.0.0.252 01-00-5e-00-00-fc estático 225.0.0.1 01-00-5e-00-00-01 estático
En nuestras instancias de puerta de enlace de Linux arp -amuestra:
peak-colo-196-220.peak.org (69.59.196.220) en <incomplete> en eth1 stackoverflow.com (69.59.196.212) en 00: 21: 5e: 4d: 45: c9 [éter] en eth1 peak-colo-196-215.peak.org (69.59.196.215) a las 00: 21: 5e: 4d: 61: 1a [éter] en eth1 peak-colo-196-219.peak.org (69.59.196.219) a las 00: 21: 5e: 4d: 38: e5 [éter] en eth1 peak-colo-196-222.peak.org (69.59.196.222) a las 00: 15: 5d: 0a: 3e: 09 [éter] en eth1 peak-colo-196-209.peak.org (69.59.196.209) a las 00: 26: 88: 63: c7: 80 [éter] en eth1 peak-colo-196-217.peak.org (69.59.196.217) a las 00: 21: 5e: 4d: 2c: e8 [éter] en eth1
¿Por qué arp configuraría ocasionalmente la entrada para este servidor fallido como <completo>? ¿Deberíamos definir nuestras entradas arp de forma estática? Siempre he dejado solo a arp, ya que funciona el 99% del tiempo, pero en este caso parece estar fallando. ¿Hay algún paso adicional de solución de problemas que podamos tomar para ayudar a resolver este problema?
COSAS QUE HEMOS PROBADO
Agregué una entrada arp estática para probar en una de las puertas de enlace de Linux que todavía no ayudaba.
root@haproxy2:~# arp -a
peak-colo-196-215.peak.org (69.59.196.215) at 00:21:5e:4d:61:1a [ether] on eth1
peak-colo-196-221.peak.org (69.59.196.221) at 00:15:5d:00:b2:0d [ether] on eth1
stackoverflow.com (69.59.196.212) at 00:21:5e:4d:45:c9 [ether] on eth1
peak-colo-196-219.peak.org (69.59.196.219) at 00:21:5e:4d:38:e5 [ether] on eth1
peak-colo-196-209.peak.org (69.59.196.209) at 00:26:88:63:c7:80 [ether] on eth1
peak-colo-196-217.peak.org (69.59.196.217) at 00:21:5e:4d:2c:e8 [ether] on eth1
peak-colo-196-220.peak.org (69.59.196.220) at 00:21:5e:4d:30:8d [ether] PERM on eth1
root@haproxy2:~# arp -i eth1 -s 69.59.196.220 00:21:5e:4d:30:8d
root@haproxy2:~# ping 69.59.196.220
PING 69.59.196.220 (69.59.196.220) 56(84) bytes of data.
--- 69.59.196.220 ping statistics ---
7 packets transmitted, 0 received, 100% packet loss, time 6006ms
Reiniciar el servidor web de Windows resuelve este problema temporalmente sin otros cambios en la red, pero nuestra experiencia muestra que este problema volverá.
Intercambio de tarjetas de red y conmutadores
Noté que la luz de enlace en el puerto del conmutador para el servidor de Windows fallido se ejecutaba a 100 Mb en lugar de 1 Gb en la interfaz fallida. Moví el cable a varios otros puertos abiertos y el enlace indicaba 100Mb para cada puerto que probé. También cambié el cable con el mismo resultado. Intenté cambiar las propiedades de la tarjeta de red en Windows y el servidor se bloqueó y requirió un restablecimiento completo después de hacer clic en Aplicar. Este servidor de Windows tiene dos interfaces de red físicas, por lo que he cambiado los cables y la configuración de red en las dos interfaces para ver si el problema sigue a la interfaz. Si la interfaz pública vuelve a fallar, sabremos que no es un problema con la tarjeta de red.
(También probamos otro interruptor que tenemos a mano, sin cambios)
Cambio de versiones del controlador de hardware de red
Hemos tenido el mismo problema con el último controlador Broadcom, así como con el controlador incorporado que se incluye en Windows Server 2008 R2.
Sustitución de cables de red
Como último esfuerzo, recordamos que otro cambio que ocurrió fue el reemplazo de todos los cables de conexión entre nuestros servidores / conmutadores. Habíamos comprado dos juegos, uno verde de longitudes de 1 a 3 pies para las interfaces privadas y otro conjunto de cables rojos para las interfaces públicas. Intercambiamos todos los cables de conexión de interfaz pública con una marca diferente y ejecutamos nuestros servidores sin problemas durante una semana completa ... aaaaa y luego el problema se repitió.
Deshabilitar la descarga de suma de comprobación, eliminar TProxy
También intentamos deshabilitar la descarga de suma de comprobación TCP / IP en el controlador, sin cambios. Ahora estamos sacando TProxy y pasándonos a una x-forwarded-fordisposición de red más tradicional sin ninguna reescritura de direcciones IP sofisticada. Veremos si eso ayuda.
Cambiar proveedores de virtualización
En caso de que esto estuviera relacionado con Hyper-V de alguna manera (alojamos máquinas virtuales Linux en él), cambiamos a VMWare Server. Ningún cambio.
Cambiar modelo de host
Hemos llegado al final de nuestra cuerda de solución de problemas y ahora estamos involucrando formalmente el soporte de Microsoft. Recomendaron cambiar el modelo de host:
- http://en.wikipedia.org/wiki/Host_model
- http://technet.microsoft.com/en-us/magazine/2007.09.cableguy.aspx
Lo hicimos y también obtuvimos algunas revisiones de kernel no publicadas que presumiblemente se incluyeron en 2008 R2 SP1. Sin arreglo.
Sustitución del hardware de la tarjeta de red
Finalmente, el reemplazo del hardware de red Broadcom con el hardware de red Intel solucionó este problema para nosotros. ¡Entonces me inclino a pensar que los controladores Broadcom Windows Server 2008 R2 tienen la culpa!
fuente
Respuestas:
De http://linux-ip.net/html/ether-arp.html :
Parece que su caja de puerta de enlace no responde (o responde muy lentamente) a las solicitudes ARP de su caja de puerta de enlace. ¿Eso
<incomplete>finalmente cambia a<failed>? ¿Qué hardware de red tiene entre el servidor y la puerta de enlace? ¿Es posible transmitir solicitudes ARP que se están filtrando o bloqueando en algún lugar entre los dos hosts?fuente
Significa que pinchó la dirección, la IP tiene un registro PTR (de ahí el nombre) pero nada respondió de la máquina en cuestión. Cuando vemos esto, se debe más comúnmente a una máscara de subred configurada incorrectamente, o en el caso de IP vinculadas a una interfaz de bucle invertido que se vincularon accidentalmente a la interfaz eth.
¿Qué es 196.220? ¿Cuál es su relación con 196.211? Supongo que .220 es uno de los hosts proxy HA. Cuando ejecuta ifconfig -a & arp -a en él, ¿qué muestra?
fuente
Como dice Max Clark, el <incompleto> solo significa que 69.59.196.211 ha presentado una solicitud ARP para 69.59.196.220 y aún no ha recibido una respuesta. (En Windows-land, verá esto como un mapeo ARP a "00-00-00-00-00-00" ... Me parece extraño, por cierto, que no esté viendo un mapeo ARP en 69.59.196.220 para 69.59.196.211.)
Tiendo a no gustarme usar entradas ARP estáticas porque, en mi experiencia, ARP generalmente ha hecho su trabajo todo el tiempo.
Si fuera yo, olfatearía la interfaz Ethernet adecuada en la máquina Windows "defectuosa" (69.59.196.220) para observarla ARP'ing para 69.59.196.211, y para observar cómo / si responde a las solicitudes ARP de 69.59. 196.211. También consideraría rastrear en la máquina de puerta de enlace solo para ARP (
tcpdump -i interface-name arp) para ver cómo se ve el tráfico ARP desde el lado de la máquina Linux.Sé, por el blog , que tienes una red back-end y una red front-end. Durante estas interrupciones, ¿el servidor de Windows "defectuoso" (69.59.196.220) tiene problemas para comunicarse con otras máquinas en la red front-end, o simplemente tiene problemas para comunicarse con su puerta de enlace? Tengo curiosidad si vienes a la máquina que falla a través de la red front-end o back-end cuando la estás captando en el acto.
¿Qué estás haciendo para "resolver" el problema cuando ocurre?
Editar:
Veo por su actualización que está reiniciando la máquina de Windows "que falla" para resolver el problema. Antes de hacerlo la próxima vez, ¿puede verificar que la máquina Windows pueda "hablar" en su interfaz frontal? Además, tome una copia de la tabla de enrutamiento de la máquina Windows (
route print) durante una falla, también. (Estoy tratando de determinar si la NIC / controlador se está volviendo loco en la máquina Windows, básicamente).fuente
Este documento muestra los diferentes estados (tabla 2.1). Incompleto significaría que ha enviado una primera solicitud de ARP (presumiblemente después de un retraso, una sonda, una sonda) pero aún no ha recibido una respuesta.
fuente
La razón por la que el ARP estático en el nodo haproxy no ayuda es que su servidor web todavía no puede encontrar la manera de volver a la puerta de enlace.
El ARP estático en el servidor web interrumpe la capacidad de sus servidores web para cambiar puertas de enlace cuando falla uno de los nodos haproxy. Supongo que la interfaz virtual comparte la misma dirección MAC que el eth1 del nodo haproxy, por lo que tendrá que código para una de las dos puertas de enlace en cada servidor web.
¿Tiene algún tipo de software de seguridad instalado en el servidor web que falla? Pasé una larga noche con un servidor de Windows 2008 que tenía Symantec Endpoint Security: instala un código de filtrado en la pila de red que le impedía ver los paquetes ARP de la puerta de enlace. La solución para eso (según lo provisto por Microsoft) fue eliminar la entrada del registro que cargó la DLL.
La otra vez que ocurrió este problema, la eliminación de todo el adaptador de red del administrador de dispositivos y la reinstalación parecían ayudar.
fuente
Como ha configurado estáticamente su entrada arp, sus servidores saben dónde encontrar la puerta de enlace. Sin embargo, si su conmutador no sabe dónde está la puerta de enlace, no reenviará sus paquetes.
Parece que tiene un cambio malo (o confuso) entre sus HAproxy y sus servidores web. Reiniciarlo.
O eso, o sus servidores HAproxy no están de acuerdo sobre cuál está en control, y ambos responden búsquedas arp para .211.
En la misma línea, si su conmutador está sobrecargado, es posible que sus HAproxies no puedan comunicarse entre sí lo suficientemente rápido y se estén fallando.
fuente
La próxima vez que ocurra este problema, sugeriría ejecutar algunas capturas de paquetes en los dos hosts en cuestión, para determinar qué tráfico ARP está observando cada uno de ellos.
Es muy probable que su máquina HAproxy tenga algún sabor de tcpdump instalado. Para la máquina Windows, necesitará una aplicación WinPCAP , como Wireshark o Microsoft Network Monitor .
De hecho, al pensar en ello, ya que el problema parece estar específicamente relacionado con ARP, es posible que pueda registrar continuamente todo el tráfico ARP en la máquina HAproxy y la máquina Windows en cuestión, con un archivo de captura de 10 MB (por el argumento). Eso debería ser lo suficientemente grande como para que cuando detecte una falla, el archivo de captura aún contendrá el tráfico ARP de antes de la falla. (Vale la pena experimentar ejecutando la captura durante aproximadamente una hora, para ver cuántos datos genera).
Ejemplo de sintaxis de captura para tcpdump de Linux (tenga en cuenta que no tengo una caja de Linux a mano para probar esto; ¡pruebe el comportamiento de -C y -W antes de usarlo en producción!):
Con suerte, esto debería darle alguna indicación de lo que está fallando precisamente. Cuando una entrada ARP caduca (y de acuerdo con este artículo , las versiones más nuevas de Windows parecen expirar las entradas 'inactivas' muy agresivamente), esperaría que suceda lo siguiente:
Por simple que parezca, hay muchas otras cosas que pueden interferir con este proceso:
Cosas para verificar si / cuando esto vuelva a suceder:
fuente
Tuvimos un problema similar con uno de nuestros servidores de terminal 2008 R2 donde todo el tráfico en la NIC se detendría pero permanecería conectado, y los LED de la NIC mostrarían comunicaciones. Este era un problema continuo que seguía apareciendo 2-3 veces por semana, pero solo después de alrededor de 12-13 horas de tiempo de actividad (el servidor se reinicia todas las noches).
Encontré que Seriousbit Netbalancer era la causa, después de que intenté (por curiosidad) terminar el servicio NetbalancerService. Luego, el tráfico comenzó a moverse a través de la interfaz. Desde entonces desinstalé Netbalancer.
fuente
Tuve el mismo problema con Asus Mainboard lan. Se solucionó instalando un controlador más reciente del sitio web de realtek
fuente