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 -a
en 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 -a
muestra:
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-for
disposició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!