Sou administrador de sistemas em uma biblioteca na Holanda. Nossa equipe usa thin clients que estão fazendo uma sessão de área de trabalho remota para nossos servidores de sessão. Temos dois servidores de sessão (Windows 2008 R2) configurados em um cluster NLB. Ambos os servidores são virtualizados. Uma em Hyper-V (RDS01) a outra em VMWare ESX (RDS03) .
O cluster NLB é configurado para funcionar no modo unicast. Ambos os servidores no cluster NLB têm dois adaptadores de rede. Um para o cluster NLB e outro para usar para comunicação ponto a ponto.
O problema que estamos tendo é que fazer uma sessão de área de trabalho remota em nosso cluster NLB geralmente falha (mesmo erro ao tentar se conectar a um IP ou nome de host não existente). Depois de algumas escavações, descobri que, ao tentar visualizar o cluster no gerenciador de NLB no RDS03, ele muitas vezes falha ao "descobrir" RDS01. O contrário funciona bem (de RDS01 a RDS03).
A Figura 1 abaixo mostra o Gerenciador do NLB no RDS01 ( SUCCESS ).
AFigura2abaixomostraoGerenciadorNLBnoRDS03(FAIL).
Como você pode ver na primeira imagem, desativei o RDS03 no cluster NLB. Apenas RDS01 é o servidor ativo no cluster NLB. Isso resolve o problema de conexão para o cluster NLB por enquanto (então eu assumo que o problema está em torno do RDS03).
Aprendi que o Gerenciador NLB usa o ICMP para "descobrir" outros hosts no cluster. Então, decidi usar um sniffer de pacote (Microsoft Network Monitoring) para inspecionar os pacotes que estão sendo enviados pelo Gerenciador do NLB. E notei no pacote sendo enviado pelo RDS01 que ele usa o endereço IP do adaptador Peer-to-Peer no RDS03. Além disso, o RDS03 às vezes usa o endereço IP do cluster NLB de RDS01.
Abaixo os detalhes do pacote capturados no 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
Em seguida, os detalhes do pacote capturados no RDS03. Quando os gerentes do NLB enviam esse pacote, a descoberta falha.
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 os detalhes do pacote capturados no RDS03. Quando o Gerenciador NLB envia este pacote, a descoberta é bem-sucedida.
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
Abaixo da configuração IP do cluster NLB e de seus servidores.
10.81.129.165 ... IP do cluster do NLB
10.81.129.167 ... IP do 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 que o RDS03 está usando o IP de cluster do NLB do RDS01? E por que ele também usa o IP peer-to-peer do RDS01? O que está causando esse comportamento inconsistente?
