Troubleshooting de clusters NLB

Olá comunidade. Neste post vamos abordar os problemas mais comuns de acesso a um Cluster NLB, bem como as possíveis soluções.

Posso começar por referir que a tecnologia NLB está bastante “madura” e aproximadamente 95% dos casos que chegam ao nosso suporte são motivados por uma das seguintes causas:

1- Utilização de software de teaming.

Em todas as configurações de NLB em que o NIC teaming é usado, podemos observar comportamentos erróneos, tais como: perda de pacotes, impossibilidade de acesso ao IP do NLB a partir da mesma subnet ou de subnets diferentes, erros ao correr os comandos de gestão do NLB (como por exemplo “wlbs.exe drain”), etc.

Basicamente, os problemas advêm da forma como o teaming gere os MAC address das placas de rede, entrando em conflito com a gestão de MAC por parte do NLB.

Oficialmente esta configuração não é suportada. Mais informações acerca deste assunto em https://support.microsoft.com/kb/278431

2- Switches Layer 3

Hoje em dia a maior parte dos Switch’s comercializados são layer 3. Isto significa que o switch é “inteligente”, aprendendo que um determinado MAC/IP está conectado numa porta física específica. O switch cria um mapeamento destas portas/ip/mac afim de prevenir flooding de todas as portas quando necessita de entregar um pacote a um host específico. Quando estamos a utilizar NLB, dependendo se estamos a usar Unicast ou Multicast, vamos substituir o MAC address original ou adicionar um novo MAC address ao existente; acontece que este novo MAC address vai ser partilhado por todos os membros do Cluster NLB. Para um switch layer 3 esta situação não é possível, uma vez que o switch vai detectar o mesmo MAC em mais que uma porta.

Os sintomas típicos nesta configuração são: dificuldade de acesso a vlans ou subnets diferentes, não haver balanceamento de carga e falhas de acesso aleatórias. Por vezes verificamos que também não há convergência entre membros do Cluster.

Possíveis soluções: Utilizar um HUB ou configurar uma VLAN específica para os membros do Cluster NLB no switch, definindo o modo de operação desta vlan como layer2.

3- NIC Drivers desactualizados.

Muitos casos que chegam ao suporte são resolvidos com uma simples actualização dos drivers das placas de rede...

4- Antivírus - filter drivers

A maioria dos antivírus actuais tem uma componente de protecção de rede e implementam um filter driver ao nível do TCP/IP. Infelizmente temos observado alguns problemas na implementação dos mesmos, pelo que no decorrer do troubleshooting é solicitado aos nossos clientes a completa remoção deste tipo de software. A nossa experiencia (através do número de casos resolvidos) mostra que este é um problema ainda muito comum e alguns dos fabricantes deste tipo de Software têm nos seus websites de suporte referencias a este assunto.

5- Acesso através de um proxy server

Neste cenário, a queixa mais comum é o facto de não haver balanceamento de carga entre os hosts NLB. Aparentemente tudo parece estar bem configurado, os pontos acima referidos estão OK, mas a carga vai toda para o mesmo host.
Normalmente este comportamento deve-se à forma como o NLB foi configurado, utilizando afinidade em modo “single”. Nesta situação, quando o acesso é feito através de um proxy, em termos de rede, os pedidos vão chegar ao NLB vindos sempre do mesmo host=proxy e, respeitando as regras de afinidade, os pedidos serão sempre redireccionados para o mesmo host NLB.

Solução: Bypass proxy para aceder ao IP do NLB ou configurar a afinidade para “nenhuma”

6- Por ultimo e apenas para os clientes que virtualizam o NLB com VMWare.

À data deste post, é necessário seguir alguns requisitos da VMWare para que esta solução funcione. Os requisitos estão detalhados na página de suporte da VMWare: https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1556

 BP

Comments

• Anonymous
  December 02, 2010
  Excelente, andava ha dias a tentar por o meu NLB a funcionar correctamente e a solução era afina tão simples. Obrigado.