Soy administrador de sistemas en una biblioteca en Holanda. Nuestro personal utiliza clientes ligeros que realizan una sesión de escritorio remoto a nuestros servidores de sesión. Disponemos de dos servidores de sesión (Windows 2008 R2) configurados en un cluster NLB. Ambos servidores están virtualizados. Uno enHiper-V (RDS01)el otro enVMware ESX (RDS03).
El clúster NLB está configurado para funcionar en modo de unidifusión. Ambos servidores del clúster NLB tienen dos adaptadores de red. Uno para el clúster NLB y el otro para la comunicación entre pares.
El problema que estamos teniendo es que realizar una sesión de escritorio remoto a nuestro cluster NLB muchas vecesfalla(el mismo error que intentar conectarse a una IP o nombre de host que no existe). Después de investigar un poco, descubrí que cuando intento ver el clúster en el administrador NLB en RDS03, a menudo no logro "descubrir" RDS01. Al revés funciona bien (de RDS01 a RDS03).
La imagen 1 a continuación muestra el NLB Manager en RDS01 (ÉXITO).
La imagen 2 a continuación muestra el NLB Manager en RDS03 (FALLAR).
Como puede ver en la primera imagen, desactivé el RDS03 en el clúster NLB. Sólo RDS01 es el servidor activo en el clúster NLB. Esteresuelveel problema de conexión al clúster NLB por ahora (así que supongo que el problema radica en el RDS03).
Aprendí que NLB Manager usa ICMP para "descubrir" otros hosts en el clúster. Entonces decidí usar un rastreador de paquetes (Microsoft Network Monitoring) para inspeccionar los paquetes que envía el NLB Manager. Y noté en el paquete enviado por el RDS01 que usa la dirección IP del adaptador Peer-to-Peer en el RDS03. Además de eso, el RDS03a vecesutiliza la dirección IP del clúster NLB de RDS01.
Debajo de los detalles del paquete capturados en el RDS01.
Frame: Number = 2812, Captured Frame Length = 74, MediaType = ETHERNET
+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-15-5D-63-97-23],SourceAddress:[00-15-5D-63-96-2B]
+ Ipv4: Src = 10.81.129.159, Dest = 10.81.129.161, Next Protocol = ICMP, Packet ID = 8406, Total IP Length = 60
+ Icmp: Echo Request Message, From 10.81.129.159 To 10.81.129.161
A continuación, los detalles del paquete capturados en el RDS03. Cuando los administradores de NLB envían este paquete, el descubrimiento falla.
Frame: Number = 211, Captured Frame Length = 74, MediaType = ETHERNET
+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[02-BF-0A-51-81-A5],SourceAddress:[00-15-5D-63-97-23]
+ Ipv4: Src = 10.81.129.161, Dest = 10.81.129.167, Next Protocol = ICMP, Packet ID = 11326, Total IP Length = 60
+ Icmp: Echo Request Message, From 10.81.129.161 To 10.81.129.167
Como último, los detalles del paquete capturados en el RDS03. Cuando el NLB Manager envía este paquete, el descubrimiento es exitoso.
Frame: Number = 2095, Captured Frame Length = 74, MediaType = ETHERNET
+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-15-5D-63-96-2B],SourceAddress:[00-15-5D-63-97-23]
+ Ipv4: Src = 10.81.129.161, Dest = 10.81.129.159, Next Protocol = ICMP, Packet ID = 21180, Total IP Length = 60
+ Icmp: Echo Request Message, From 10.81.129.161 To 10.81.129.159
Debajo de la configuración de IP para el clúster NLB y sus servidores.
10.81.129.165...IP del clúster NLB
10.81.129.167...IP NLB para RDS01
10.81.129.169...IP NLB para RDS03
10.81.129.159...IP RDS01 (segunda NIC para Peer-to-peer)
10.81.129.161...IP RDS03 (segunda NIC para Peer-to-peer)
¿Por qué el RDS03 utiliza la IP del clúster NLB del RDS01? ¿Y por qué también utiliza la IP peer-to-peer de RDS01? ¿Qué está causando este comportamiento inconsistente?
Respuesta1
Para responder a mi propia pregunta, el problema estaba en la búsqueda de DNS. Después de borrar el caché de DNS en el RDS03 (donde ocurrió el comportamiento inconsistente).
ipconfig /flushdns
Hice una actualización del clúster en RDS03 NLB Manager y noté que realizaba una búsqueda de DNS para RDS01. Ahora estaba seguro de que el administrador de NLB estaba usando nombres de host para comunicarse. El servidor DNS respondió con las dos direcciones IP siguientes:
10.81.129.159 ...IP RDS01(segunda NIC para peer-to-peer)
10.81.129.167...IP NLB para RDS01
Cada vez que fallaba el descubrimiento de RDS01,NLB IP de RDS01fue la primera IP de la respuesta de búsqueda de DNS. Y cada vez que el descubrimiento tuvo éxitoIP RDS01fue primero.
Después de quitar elNLB IP de RDS01Registro DNS del servidor DNS, el problema se resolvió. Ahora sólo tenía que asegurarme de que las direcciones IP de NLB ya no se registraran solas en el servidor DNS. Esta era una configuración en el protocolo TCP/IP de la NIC NLB. Vea la imagen a continuación.
