Sou administrador de sistema em uma biblioteca na Holanda. Nosso pessoal usa thin clients que fazem 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. Um emHiper-V (RDS01)o outro emVMWare ESX (RDS03).
O cluster NLB está configurado para funcionar no modo unicast. Ambos os servidores no cluster NLB possuem dois adaptadores de rede. Um para o cluster NLB e outro para uso na comunicação ponto a ponto.
O problema que estamos enfrentando é que muitas vezes criamos uma sessão de área de trabalho remota em nosso cluster NLBfalhar(mesmo erro ao tentar conectar-se a um IP ou nome de host inexistente). Depois de algumas pesquisas, descobri que, quando tento visualizar o cluster no gerenciador NLB no RDS03, muitas vezes não consigo "descobrir" o RDS01. O contrário funciona perfeitamente (de RDS01 a RDS03).
A Figura 1 abaixo mostra o NLB Manager no RDS01 (SUCESSO).
A Figura 2 abaixo mostra o NLB Manager no RDS03 (FALHAR).
Como você pode ver na primeira foto desabilitei o RDS03 no cluster NLB. Somente RDS01 é o servidor ativo no cluster NLB. Esseresolveo problema de conexão com o cluster NLB por enquanto (então presumo que o problema esteja no RDS03).
Aprendi que o NLB Manager usa ICMP para "descobrir" outros hosts no cluster. Então decidi usar um sniffer de pacotes (Microsoft Network Monitoring) para inspecionar os pacotes enviados pelo NLB Manager. E notei no pacote enviado pelo RDS01 que ele usa o endereço IP do adaptador ponto a ponto no RDS03. Além disso, o RDS03às vezesusa o endereço IP do cluster NLB de RDS01.
Abaixo os detalhes do pacote capturado 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
A seguir, os detalhes do pacote capturado no RDS03. Quando os gerentes do NLB enviam este 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
Por último, os detalhes do pacote capturado no RDS03. Quando o NLB Manager 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 a configuração de IP do cluster NLB e seus servidores.
10.81.129.165...IP do cluster 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 ponto a ponto)
10.81.129.161...IP RDS03 (segunda NIC para ponto a ponto)
Por que o RDS03 está usando o IP do cluster NLB do RDS01? E por que ele também usa o IP ponto a ponto do RDS01? O que está causando esse comportamento inconsistente?
Responder1
Para responder à minha pergunta, o problema estava na pesquisa de DNS. Depois de limpar o cache DNS no RDS03 (onde ocorreu o comportamento inconsistente).
ipconfig /flushdns
Fiz uma atualização de cluster no RDS03 NLB Manager e percebi que ele fez uma pesquisa de DNS para RDS01. Agora eu tinha certeza de que o NLB Manager estava usando nomes de host para se comunicar. O servidor DNS respondeu com os dois seguintes endereços IP:
10.81.129.159...IP RDS01(segunda NIC para ponto a ponto)
10.81.129.167 ...IP NLB para RDS01
Toda vez que a descoberta do RDS01 falhou, oIP NLB de RDS01foi o primeiro IP da resposta de pesquisa de DNS. E sempre que a descoberta sucedia oIP RDS01foi primeiro.
Depois de remover oIP NLB de RDS01Registro DNS do servidor DNS o problema foi resolvido. Agora eu só precisava ter certeza de que os endereços IP do NLB não se registrariam mais no servidor DNS. Essa era uma configuração no protocolo TCP/IP da NIC NLB. Veja a imagem abaixo.
