Versión TL;DR: Resulta que se trataba de un profundo error de red de Broadcom en Windows Server 2008 R2. La sustitución por hardware Intel lo solucionó. Ya no utilizamos el hardware de Broadcom. Nunca.
Hemos estado utilizando HAProxy junto con latido del corazón 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 usando una interfaz virtual (eth1:1) en la IP: 69.59.196.211
La interfaz virtual (eth1:1) IP 69.59.196.211 está configurada como la puerta de enlace para los servidores 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 Windows detrás de nuestras pasarelas linux. HAProxy detecta que el servidor está fuera de línea, lo que podemos verificar mediante la conexión remota con el servidor que ha fallado e intentando hacer un ping a la puerta de enlace:
Pinging 69.59.196.211 with 32 bytes of data:
Reply from 69.59.196.220: Destination host unreachable.
Ejecutar arp -a
en este servidor fallido muestra que no hay ninguna entrada para la dirección de la puerta de enlace (69.59.196.211):
Interface: 69.59.196.220 --- 0xa
Internet Address Physical Address Type
69.59.196.161 00-26-88-63-c7-80 dynamic
69.59.196.210 00-15-5d-0a-3e-0e dynamic
69.59.196.212 00-21-5e-4d-45-c9 dynamic
69.59.196.213 00-15-5d-00-b2-0d dynamic
69.59.196.215 00-21-5e-4d-61-1a dynamic
69.59.196.217 00-21-5e-4d-2c-e8 dynamic
69.59.196.219 00-21-5e-4d-38-e5 dynamic
69.59.196.221 00-15-5d-00-b2-0d dynamic
69.59.196.222 00-15-5d-0a-3e-09 dynamic
69.59.196.223 ff-ff-ff-ff-ff-ff static
224.0.0.22 01-00-5e-00-00-16 static
224.0.0.252 01-00-5e-00-00-fc static
225.0.0.1 01-00-5e-00-00-01 static
En nuestras instancias de la pasarela linux arp -a
espectáculos:
peak-colo-196-220.peak.org (69.59.196.220) at <incomplete> on eth1
stackoverflow.com (69.59.196.212) at 00:21:5e:4d:45:c9 \[ether\] on eth1
peak-colo-196-215.peak.org (69.59.196.215) at 00:21:5e:4d:61:1a \[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-222.peak.org (69.59.196.222) at 00:15:5d:0a:3e:09 \[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
¿Por qué arp ocasionalmente establece la entrada para este servidor fallido como <incompleto>? ¿Deberíamos definir nuestras entradas arp de forma estática? Siempre he dejado arp solo ya que funciona el 99% de las veces, pero en este caso parece estar fallando. ¿Hay algún otro paso para solucionar este problema?
COSAS QUE HEMOS PROBADO
Añadí una entrada arp estática para probar en una de las puertas de enlace de linux que todavía no ayudó.
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 demuestra que este problema volverá a aparecer.
Intercambio de tarjetas de red y conmutadores
Me di cuenta de que la luz de enlace en el puerto del conmutador para el servidor Windows fallado estaba funcionando a 100Mb en lugar de 1Gb en la interfaz fallada. 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. Traté de cambiar las propiedades de la tarjeta de red en Windows y el servidor se bloqueó y requirió un reinicio duro después de hacer clic en aplicar. Este servidor de Windows tiene dos interfaces de red físicas, así que he intercambiado los cables y la configuración de red en las dos interfaces para ver si el problema sigue la interfaz. Si la interfaz pública se cae de nuevo, sabremos que no es un problema con la tarjeta de red.
(También probamos con otro interruptor que tenemos a mano, sin cambios)
Cambio de versiones de los controladores de hardware de red
Hemos tenido el mismo problema con el último controlador de Broadcom, así como con el controlador integrado que viene en Windows Server 2008 R2.
Sustitución de cables de red
Como último esfuerzo recordamos que otro cambio que se produjo fue la sustitución de todos los cables de conexión entre nuestros servidores / switch. Habíamos comprado dos conjuntos, uno verde de longitudes de 1 pie a 3 pies para las interfaces privadas y otro conjunto de cables rojos para las interfaces públicas. Cambiamos todos los cables de conexión de la interfaz pública por otros de otra marca y nuestros servidores funcionaron sin problemas durante toda una semana... y entonces el problema volvió a aparecer.
Desactivar la descarga de la suma de comprobación, eliminar TProxy
También hemos probado a desactivar la descarga de sumas de comprobación TCP/IP en el controlador, pero no ha habido ningún cambio. Ahora estamos retirando TProxy y pasando a un sistema más tradicional. x-forwarded-for
disposición de la red sin necesidad de reescribir las direcciones IP. Veremos si eso ayuda.
Cambiar los proveedores de virtualización
Por si acaso esto estuviera relacionado con Hyper-V de alguna manera (alojamos máquinas virtuales de Linux en él), cambiamos a VMWare Server. No hay cambios.
Modelo de host de conmutación
Hemos llegado al final de nuestra cuerda de solución de problemas y ahora estamos involucrando formalmente al soporte de Microsoft. Nos han recomendado 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 algunos hotfixes del kernel no publicados que presumiblemente se incluyeron en el SP1 de 2008 R2. No hay solución.
Sustitución del hardware de la tarjeta de red
Finalmente, la sustitución del hardware de red Broadcom por el hardware de red Intel solucionó el problema. Así que me inclino a pensar que los controladores Broadcom de Windows Server 2008 R2 son los culpables.
0 votos
También hay que tener en cuenta que utilizamos TProxy (proxy transparente) para devolver la IP real del tráfico que entra a través de HAProxy. blog.loadbalancer.org/
0 votos
LUnix... je je... hld.c64.org/poldi/lunix/lunix.html
2 votos
Nunca confíes en la configuración automática en un entorno de producción. Ajusta la velocidad a lo que debe ser, y pon un monitor para estar seguro.
3 votos
@Daniel Sobral: Tengo que discrepar de corazón contigo. En 2003 supongo que podría verlo. Con el hardware moderno, fijar la velocidad de los puertos y el dúplex es una receta para obtener desajustes de velocidad / dúplex. La autonegociación en los equipos Ethernet modernos funciona bien.
1 votos
Estoy con @Daniel Sobral, demasiadas veces he tenido fallos de red causados por malas negociaciones de velocidad en el peor momento, por lo que en los sistemas de producción voy con configuraciones estáticas. Cuando eso ocurre, ¿qué dice el estado del enlace en el switch? Está gestionado, ¿verdad? ¿Qué dice el sistema Windows? Yo apostaría por que la red falla a nivel de enlace, y eso es lo que está causando esos ARP incompletos (fallidos o en espera de recibir ARP who-has). Un mal hardware/driver podría ser la causa. Vamos a ver cómo va después de intercambiar.
0 votos
@Evan Supongo que podrías tener razón en lo que respecta al hardware más nuevo (no al de 2004, sin embargo :), pero yo he tenido problemas con la configuración automática, nunca con la configuración dura. Siempre que conecto un servidor a un switch, o conecto switches y routers, sé precisamente la configuración que deben tener. Así que, hasta que no me encuentre con el problema contrario, mantendré mi recomendación.
0 votos
Como punto de interés, el Service Pack 1 ya ha sido lanzado.
0 votos
¿No debería ponerse la respuesta como una respuesta propiamente dicha, y no como una edición de la pregunta? De este modo, la pregunta podría marcarse como "respondida".
0 votos
Pero, ¿sigues utilizando Windows Server?
0 votos
@Rudie : ¿Hubo un problema con el sistema operativo o por qué lo dices?
0 votos
@Jeff - débil, pero ¿alguna posibilidad de una copia de ese parche de MSFT? Estamos teniendo este problema exacto en los 3 nuevos Dell R610 que alojan todo el SSL para nuestro sitio :| (Tengo Intel dualport NICs en orden en el ínterin )
0 votos
@gdh no funcionan los parches del sistema operativo - esto es puramente un problema de los controladores broadcom AFAIK y si usted tiene los últimos controladores broadcom no hay nada más que hacer.
0 votos
Sabes que es gracioso que no vea ¿Cuál es su pregunta? , ¿Esta pregunta es demasiado amplia? , Esta pregunta no es productiva o ¿Por qué estás usando el servidor de Windows 2008? ? Usted sabe que la respuesta típica que se obtiene a lo largo de la terminación de la pregunta en < 1s.