Problemas al unir un nodo al cluster entre sitios? Problema Resuelto!!

Volvemos nuevamente con una nota interesante, basada en casos que hemos recibido recientemente, donde se experimenta una falla de comunicación entre 2 nodos de Failover Clúster.

Este comportamiento se evidencia principalmente al unir nodos a un Failover clúster en un ambiente en el que existen equipos de terceros realizando tareas de inspección y reenvío de paquetes, mediando las comunicaciones entre los nodos.

Ambiente

El ambiente está compuesto de la siguiente manera:

• Nodo A, ubicado en el Sitio A (Con dirección IP 192.168.0.100)
• Enlace WAN con equipamiento realizando tareas de inspección y reenvío de paquetes
• Nodo B, Ubicado en el Sitio B (Con dirección IP 192.168.1.100)

–       Hay otros nodos en ambos sitios que están unidos y no presentan la falla.

Síntomas

Cuando se intenta unir el Nodo B al clúster, y se toma una traza del componente NetFT utilizando el siguiente comando:

netsh trace start capture=yes overwrite=yes maxsize=4096 tracefile=c:base_cluster.etl provider={7E66368D-B895-45F2-811F-FB37940421A6} keywords=0xffffffffffffffff level=0xff

Se pueden observar los siguientes eventos a lo largo de la traza:

[26] 0000.0000::12/15/16-12:38:00.2645164 [rm] rmadp_c797 RmHeartbeatTimerDpc() – Monitor FFFFE0007B4522A0 (192.168.0.100:3343 –  192.168.1.100:3343) sending RCP request FFFFE0007B4C7570 (sequence 7). Ticks=5969997, last=5969741, delay=256.

[26] 0000.0000::12/15/16-12:38:00.2645404 [rm] rmadp_c844 RmHeartbeatTimerDpc() – Monitor FFFFE0007B4522A0 (192.168.0.100:3343 –  192.168.1.100:3343) missed HB response, gap=6

[8] 0000.0000::12/15/16-12:38:00.2645566 [rm] rmadp_c1035 RmSendComplete() – Monitor FFFFE0007B4522A0 (192.168.0.100:3343 –  192.168.1.100:3343) completed RCP message FFFFE0007B4C7570 with 0.

[12] 0000.0000::12/15/16-12:38:00.2734304 [rm] rmsup_c1412 RmFilterRcpMessage() – Validation of RCP packet failed – Route monitor (192.168.0.100:3343 –  192.168.1.100:13429) FT IPs (fe80::d5e4:bf14:708f:b3db –  fe80::ec3f:16be:f9a4:3cf3) not found.

[12] 0000.0000::12/15/16-12:38:00.2734317 [ta] tnsup_c113 TaFilterPacket() – Dropping received RCP messages from 192.168.1.100:13429.

Lo que se debe observar aquí es el puerto de origen y destino de los paquetes.

Tal como lo indica la siguiente nota, el puerto de origen y destino del Heartbeat de Failover Clúster es el puerto UDP 3343. Cuando este puerto es cambiado ya sea en origen o destino, por defecto, el clúster va a descartar los paquetes, dando fallas a la comunicación.

Si tomamos una captura de red al momento de reproducir el inconveniente, vamos a ver el siguiente comportamiento en los paquetes del Heartbeat:

Si abrimos los paquetes, vamos a ver en el detalle que, en el paquete de origen (es decir el que sale del servidor que está enviando el Heartbeat) los puertos coinciden tanto en origen como en destino, tal como es el estándar o la configuración por defecto del Clúster (Puerto origen y destino UDP 3343):

   Frame: Number = 78, Captured Frame Length = 146, MediaType = ETHERNET

+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[10-8C-CF-56-3C-C0],SourceAddress:[5C-B9-01-C8-70-E0]

+ Ipv4: Src = 192.168.0.100, Dest = 192.168.1.100, Next Protocol = UDP, Packet ID = 11776, Total IP Length = 132

– Udp: SrcPort = 3343, DstPort = 3343, Length = 112

    SrcPort: 3343

    DstPort: 3343

TotalLength: 112 (0x70)

    Checksum: 27094 (0x69D6)

  + UDPPayload: SourcePort = 3343, DestinationPort = 3343

Ahora bien, si miramos el paquete en destino, vamos a notar un ligero cambio en el paquete, que a simple vista puede parecer inofensivo, pero es lo que realmente nos está causando todos los dolores de cabeza:

   Frame: Number = 79, Captured Frame Length = 146, MediaType = ETHERNET

+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[5C-B9-01-C8-70-E0],SourceAddress:[10-8C-CF-56-3C-C0]

+ Ipv4: Src = 192.168.1.100, Dest = 192.168.0.100, Next Protocol = UDP, Packet ID = 11261, Total IP Length = 132

– Udp: SrcPort = 13429, DstPort = 3343, Length = 112

    SrcPort: 13429

    DstPort: 3343

TotalLength: 112 (0x70)

Checksum: 52191 (0xCBDF)

  + UDPPayload: SourcePort = 13429, DestinationPort = 3343

Como pueden observar, el puerto de origen del paquete, al pasar a través del enlace WAN, llega modificado al destino. Esto mismo se puede notar en las capturas de ambos nodos, donde los paquetes salen de manera correcta, pero llegan del nodo contrario con puerto de origen cambiado.

Solución

Debido a que desde Windows el comportamiento en el envío de paquetes desde ambos nodos es el esperado (es decir, ambos nodos envían los paquetes con puerto origen y destino UDP 3343) y que, al atravesar el enlace entre los sitios el puerto de origen queda cambiado, recomendamos verificar las siguientes acciones:

• Evaluar la infraestructura de red para poder detectar:

o  Cuantos saltos hay entre cada nodo

o  Qué función cumple cada uno de esos saltos

o  Evaluar la presencia de dispositivos que hagan inspección y reenvíos de paquetes

• Tomar trazas de red en cada uno de los saltos, para poder identificar cuál de ellos es el que está realizando el cambio de puerto de origen
• Ponerse en contacto con el fabricante de su equipamiento de red para realizar las correcciones necesarias

En caso que entre la comunicación de los nodos exista algún dispositivo del fabricante F5, les recomendamos seguir la siguiente nota para una correcta configuración de los Virtual Servers.

Como se describe allí, para los Clusters, la siguiente opción es la más adecuada para el correcto funcionamiento:

Como se puede observar, la opción recomendada, incluso por F5, es que el Virtual server utilice la opción “Source Port” como “Preserve Strict”. Por defecto, al configurarse el Virtual Server, la opción de “Source Port” utiliza la opción “Preserve”, en la cual, si el puerto de origen ya se encuentra en uso por algún otro equipo, va a utilizar un nuevo puerto, causando los problemas que hemos notado mas arriba.

Asimismo, cabe la recomendación de ponerse en contacto con personal de F5 para poder evaluar estas configuraciones de manera adecuada, debido a que nosotros no brindamos soporte sobre equipamiento F5, y simplemente acercamos esta documentación a modo de referencia para acelerar la solución del inconveniente.

Espero que esta nota haya servido para aclarar dudas en cuanto a este comportamiento y que haya servido de ayuda.

Quiero agradecer a mis colegas Felicio Da Silva (Technical Advisor – Core / Platforms), Danilo Gonçalves (Support Escalation Engineer – Core / Platforms) y Nicolas Rojas (Support Engineer – Core / Platforms) por su ayuda en obtener gran parte de la información para esta nota (y poder aprender un poco mas de cómo funcionan las redes en los clusters) y a Martin Kirtchayan (Technical Advisor – Networking / Identity) por su ayuda con la revisión y correcciones de esta nota.

Como siempre, les agradecemos por habernos acompañado hasta aquí, así como también por seguir confiando en Microsoft.

Feliz 2017 para todos!!