Switch Catalyst e Cluster Microsoft NLB em Modo Multicast

Olá Pessoal.

É comum as empresas agruparem seus servidores físicos Microsoft através da solução Network Load Balancer (NLB) para criar um cluster lógico equivalente à soma dos nós. Ao configurar o cluster deve ser informado um IP Virtual (Virtual IP Address) correspondente ao agrupamento lógico. 

O objetivo desse artigo é explicar a configuração do Switch Cisco Catalyst para suportar o encaminhamento otimizado de pacotes destinados ao cluster através de comunicação multicast, por isso não entrarei em detalhes do modus operandi da solução MS-NLB. No entanto, para acompanhar esse artigo é importante conhecer os possíveis modos de configuração do MS-NLB, que são:

• Unicast: É o modo padrão de operação do cluster NLB onde os endereços físicos (MAC) dos servidores são sobrescritos com um único endereço "falso" gerado pelo cluster e que é igual para todos os nós. Por causa disso é necessário um segundo adaptador de rede para a comunicação interna entre os nós do cluster;

• Multicast: É o modo de operação mais recomendado porque instrui o NLB a adicionar um endereço físico (MAC) de multicast nos adaptadores de rede de todos os hosts do cluster. Dessa forma o MAC original de cada host não é alterado e os hosts podem se comunicar normalmente entre si. Esse modo também oferece a opção de habilitar o protocolo IGMP, o que faz com que os hosts do cluster enviem uma mensagem igmp-join para o switch manifestando que são parte do mesmo grupo multicast.

A menos que os servidores físicos estejam isolados em sua própria VLAN (e sub-rede), o problema do modo unicast é que o switch faz o flood (inundação) dos pacotes/quadros destinados ao MAC do cluster MS-NLB, o que implica na propagação de todo tráfego destinado aos nós do cluster como broadcast. Isso é muito ruim para o desempenho da rede e pode causar problemas desastrosos no ambiente corporativo se os servidores físicos estiverem conectados no switch principal da rede (core) que é responsável por agregar todos os demais switches de acesso. Na figura abaixo o leitor pode visualizar esse efeito negativo comparado com aquilo que seria o ideal (clique p/ ampliar).

Caso os servidores estejam no mesmo domínio de broadcast que as demais máquinas da rede, uma prática não recomendada, então é necessário configurar o switch em que os servidores do cluster estão diretamente conectados para que haja ciência da existência dos grupos multicast. Caso haja outros switches de acesso conectados ao principal, eles também devem ser configurados para encaminhar os quadros multicast somente para a(s) interface(s) de uplink. Essa configuração pode ser feita manualmente com mapeamentos estáticos que associam o endereço MAC do cluster com as respectivas interfaces do switch que estão conectadas aos servidores.

O IGMP (Internet Group Management Protocol) é um protocolo de comunicação utilizado no IPv4 para que hosts comuns possam estabelecer um grupo lógico multicast. É comumente utilizado por aplicações de streaming de vídeo e clusters, entre outras, quando há necessidade de comunicação de "um para muitos" (grupo). Se o cluster MS-NLB foi implementado para operar no modo "IGMP Multicast", então os servidores utilizam o protocolo IGMP para que o switch aprenda dinamicamente quais portas estão conectadas aos servidores e, portanto, pertencem ao mesmo grupo multicast.

Então vamos considerar o cenário abaixo para exemplificar como o switch deve ser configurado para otimizar o desempenho da rede através de ambos os métodos dinâmico (via IGMP) e estático. Em relação à figura, é importante ficar atento aos endereços dos servidores, principalmente os endereços do cluster lógico que estão destacados em vermelho. O cluster foi configurado para operar em modo "Multicast (sem IGMP)", de modo que o MAC gerado pela solução da Microsoft fica sendo 03:bf:XX:XX:XX:XX, sendo os 32 bits X equivalentes ao endereço virtual do cluster em hexadecimal.

Em relação ao suporte do IGMP para associação dinâmica, a "boa" notícia é que não seria necessário fazer nenhuma configuração adicional no switch. Por padrão o IGMP vem ativado no equipamento e, portanto, bastaria configurar o cluster para propagar as mensagens join-igmp que, assim, o switch aprenderia em quais portas existe um grupo multicast! ;-) A má notícia é que nem todos os modelos de switches apresentam esse comportamento e há inúmeros relatos de comportamento estranho dessa funcionalidade. Por exemplo, os novos modelos Catalyst 2960-X e 3750-X, amplamente utilizados nas empresas, constroem sua lógica de encaminhamento partindo do princípio que o IP de destino pertence à faixa reservada para multicast (224. até 239.), o que conflita com a lógica do MS-NLB que opera com um endereço de destino unicast (associado a um MAC multicast do tipo 0100.5e). Muitas vezes a melhor opção acaba sendo a configuração manual, então vamos a ela...

Quanto à configuração manual, uma primeira informação importante é conhecer o endereço MAC multicast gerado pelo cluster NLB, o que pode ser visualizado na própria configuração do cluster, através do cache da tabela ARP presente em algum computador da rede (via comando "arp -a") ou mesmo através da análise dos cabeçalhos via captura de tráfego com algum software sniffer. Em posse dessa informação, basta utilizar o seguinte comando associando o endereço físico do cluster com as respectivas interfaces do switch em que os servidores estão conectados e que, portanto, têm interesse em receber tráfego destinado ao grupo multicast.

SW(config)# mac-address-table static 03bf.ca08.6464 vlan 1 interface g0/1 g0/2 g0/3

Caso os servidores sejam acessados remotamente, então o(s) roteador(es) de borda que têm acesso externo também precisam ser configurados com o mapeamento estático do ARP, responsável pela associação dos endereços IP e MAC do cluster. Embora o ARP faça essa associação automaticamente nos diversos sistemas operacionais, os roteadores Cisco não completam as requisições ARP ao NLB porque associar um endereço IP unicast com um endereço MAC multicast é contrário aos princípios da RFC. Essa configuração é simples:

Router(config)# arp 192.168.100.100 03bf.ca08.6464 ARPA

Com isso o desempenho da rede é otimizado porque seu montante de tráfego é estabilizado através da implementação de comunicação multicast com os servidores que compõem o cluster, eliminando a propagação dos broadcasts nos switches.

Abraço.

Samuel.