Balanceamento de carga de rede do Windows no cluster ESX com pilhas Dell PowerConnect

Question

Recentemente, trocamos nosso switch de núcleo Cisco 6500 por um par de pilhas Dell PowerConnect 6248. Desde então, nosso Network Load Balanced Sharepoint, que é executado em duas máquinas virtuais em um cluster ESX, tem se comportado de maneira muito deficiente. Os sintomas são que abrir e salvar documentos armazenados no sharepoint leva um tempo muito longo. Não há erros aparecendo nos servidores Sharepoint ou SQL Server, apenas um monte de usuários irritados. Inicialmente, achei que não havia como o NLB causar isso, mas assim que identificamos os registros de DNS da intranet no endereço IP de um dos front-ends da web, os problemas desapareceram.

Suspeitamos que há um problema relacionado ao multicast nas configurações da Dell - o NLB está configurado para multicast, mas não para IGMP.

Alguém configurou algo semelhante para nós e corrigiu esse tipo de problema? Sharepoint no VMware ESX, com switches Dell PowerConnect.

    

Answer 1

Já vimos quase o mesmo problema. Estamos usando o NLB com multicast (mas não IGMP) para equilibrar a carga de 14 servidores da Web em dois servidores ESX 4 conectados a um par de Dell PowerConnect6248. O nlb estava funcionando, mas o desempenho foi terrível. Nós tentamos chnaging everying em nlb (unicast, multicast, igmp) e switch vmware (promicous, nitify switch, etc) e não poderia fazê-lo funcionar. Adicionamos o multicast MAC às tabelas dell bridge e arp, tudo sem efeito. Eventualmente, resolvemos isso desativando o roteamento da vlan no PowerConnect (ou seja, usando uma VLAN de camada 2 simples) e usando um roteador externo para rotear o tráfego. Adoraria saber como usar o roteamento na Dell para fazer esse trabalho como deveria ser suportado.

    

Answer 2

Tudo parece muito familiar. Eu tenho exatamente o mesmo problema. Com o NLB no Exchange e o Sharepoint em um conjunto de VMs do ESX, sempre que houver tráfego para o NLB, ele será interrompido. Temos trabalhado em estreita colaboração com a Dell e o problema é o Multicast. Supostamente há um White Paper da Dell sobre isso, que diz que você deve usar Unicast e não Multicast.

Agora estamos aguardando para mover nossos NLBs para o Unicast. Temos 30 ímpares desses switches, todos executando o 3.2.0.7 agora. O firmware da v3 foi uma grande melhoria, mas tenha cuidado se você estiver atualizando da v2 e tenha certeza de que leu as instruções, não é uma simples instalação e reinicialização. Além disso, algumas coisas são configuradas de maneiras diferentes, como o retransmissor DHCP. E massivamente quebrou nosso NLB para começar.

Se você não estiver convencido, tente executar ping na interface de gerenciamento (algo gráfico como o PingPlotter) enquanto monitora o tráfego para o NLB. Você verá que o tempo de ping está vinculado à quantidade de tráfego. Nós vamos de pings de 1ms a mais de 200ms, e até mesmo derrubando pacotes. A interface de gerenciamento trava quando o processador do switch está lidando com o Multicast, em vez de ser feito em hardware.

Espero que ajude, vou postar de volta quando, eventualmente, nos mudarmos.

    

Answer 3

Alguns comutadores da Dell não suportam o Multicast NLB. É por isso que você está tendo um problema de desempenho. Além disso, você verá excessivamente o uso da CPU. Você pode ver mais sobre isso neste link.

link

Outro caso sobre perda de ping na rede de gerenciamento está relacionado à revisão de firmware. Novos firmwares resolvem esse problema. Eu sugiro que você atualize seu nível de firmware.