Load Balancing Deep Dive

Em um projeto recente o pessoal me perguntou sobre qual configuração de Network Load Balance (NLB) é a mais recomendada. Esse assunto envolve vários conceitos interessantes sobre o protocolo IP, MAC Address e funcionamento dos switches. Acho que esse assunto interessaria a outras pessoas e por isso, resolvi escrever este post.

Pontos importantes:

• Virtual IP Address (VIP) – É um endereço IP que não está associado a uma placa de rede física de um computador específico. Os pacotes que são enviados para esse endereço (VIP) são redirecionados para as interfaces físicas dos computadores.
• Multicast – É uma técnica de comunicação onde um computador de origem pode enviar pacotes para vários computadores destino, de forma eficiente, ou seja, sem que ocorra um elevado envio de pacotes.
• Unicast – É quando uma única origem envia um pacote para um único destino. É como ocorre em na maioria das comunicações na Internet.
• O NLB é uma técnica para distribuir a carga uniformemente entre dois ou mais computadores de forma a obter maior disponibilidade, escalabilidade e balanceamento de carga para um ou mais serviços.
  • Um NLB pode ter até 32 nós configurados.
  • O NLB é um componente do kernel.
  • O NLB não faz balanceamento baseado na carga de CPU ou utilização da aplicação.
• A coexistência entre um NLB em Windows Server 2003 e Windows Server 2008  é possível, em caso de migrações. Maiores detalhes em - Preparing to upgrade the Network Load Balancing cluster.

Distribuição do trafego do NLB do Windows

A arquitetura do NLB usa unicast ou multicast para distribuir o tráfego de entrada (incoming) para os nós do NLB.

No modo unicast o sistema operacional altera o MAC Address da placa de rede que faz parte do NLB em todos os nós para um único MAC Address virtual. Desta forma, qualquer pacote enviado para os endereços IP destes servidores são na verdade enviados para um único MAC Address. Um pacote destinado ao NLB é capturado por todos os nós do balanceamento.

A solução de NLB com unicast apresenta dois efeitos colaterais. As placas de rede que participam do balanceamento não conseguem comunicar entre si, pois têm o mesmo MAC. Para eliminar essa limitação é necessário instalar uma segunda placa de rede nos servidores que fazem parte do NLB, para que eles possam trocar mensagens novamente entre sí. O efeito colateral mais nocivo porém, é o switch flooding, que por não ser capaz de identificar onde os nós estão, uma vez que várias portas estão com o mesmo MAC, envia os pacotes de entranda (inbound) do NLB para todas as portas do switch, incluindo as portas onde os nós de NLB não estão conectados.

Há duas formas de conter o switch flooding em unicast.  A primeira é colocar um HUB para conectar os nós do NLB no switch, pois com o HUB, todos os nós se conectam em uma única porta do switch com o mesmo MAC. A segunda é configurar uma VLAN para os servidores do NLB, para conter o switch flooding apenas nas portas configuradas na VLAN.

No modo multicast o NLB adiciona um endereço MAC para a placa de rede de cada nó participante, assim cada nó NLB tem dois endereços MAC: o seu real e o do NLB no formato de MAC de multicast. O problema com o modo multicast é que o VIP não é acessível por equipamentos que estejam em outra subnet IP, pois os roteadores em geral não aceitam pacotes ARP para um endereço unicast que contêm um MAC de multicast, e como não consegue determinar qual porta estão os MAC o switch flooding ocorre exatamente como no unicast.

Para que o modo multicast funcione sem switch flooding é necessário criar entradas estáticas no switch para que ele envie os pacotes apenas para membros do NLB. Os artigos: Configuring Cisco to work with a Windows NLB Cluster e Catalyst Switches for Microsoft Network Load Balancing Configuration Example mostram essa configuração no ambiente com equipamentos da Cisco.

Como o padrão utilizado pelo NLB é o modo unicast, vou detalhar mais seu funcionamento.

Os switches em geral não gostam de MAC Address duplicados e como cada servidor participante do balanceamento se conecta com o mesmo MAC Address a solução encontrada pela Microsoft foi utilizar um mecanismo chamado de MaskSourceMAC. Esse mecanismo modifica o pacote de saída (outcome) incluíndo no source MAC Address do pacote de saída uma idenficação baseada no priority number do nó. Por exemplo, se o MAC Virtual é 00-8E-37-D5-F3-7F no pacote de saída ele ficaria 00-02-37-D5-F3-7F, sendo 02 o priority number do nó que está enviando o pacote. Caso os nós do NLB estejam conectados a um HUB a funcionalidade de MaskSourceMAC deve ser desabilitada (via registry).

Para mostrar tudo isso em funcionamento montei um laboratório em Windows Server 2008 R2. Os passos para instalar e configurar um NLB podem ser encontrados em - Network Load Balancing Step-by-Step Guide. O funcionamento do NLB em ambiente Hyper-V requer algumas pequenas configurações ou instalação de patches. Maiores detalhes podem ser encontrados no post do time de cluster - Network Load Balancing (NLB) and Virtual Machines.

Em laboratório criei dois nós NLB01 e NLB02. As telas abaixo mostram a configuração IP dos servidores e seus respectivos MAC Address antes de se instalar e configurar o NLB.

NLB01

NLB02

Notem que o MAC Address de ambos dos servidores são diferentes. No caso do laboratório como estava em ambiente virtual, o último byte. sendo 00-15-50-11-0A-1C (IP 172.17.2.11) para o NLB01 e 00-15-50-11-0A-1E (IP 172.17.2.12)para o NLB02.

Após o NLB ser configurado os MAC Address das placas são alterados para a do NLB – 02-BF-AC-11-02-0D, e o endereço IP do NLB 172.17.2.13 é adcionado em cada um dos servidores.

Servidor NLB01

Servidor NLB02

Podemos verificar que a comunicação que sai dos nós é alterada, podendo ser visualizada pela ferramenta Network Monitor. Abaixo, as duas primeiras telas mostram a conexão do NLB01 e depois do NLB02 para um servidor WEB. Perceba que o MAC Address de origem (SourceAddress) é 02-01-AC-11-02-0D para o NLB01 e 02-02-AC-11-02-0D para o NLB02. Comprovando que para as sessões iniciadas pelos nós o MAC-Address é alterado no segundo octeto com o priority number daquele nó.

A terceira tela porém, mostra o ARP Request que um nó faz para obter o MAC-Address do servidor WEB. Perceba que a resposta não é enviada para o MAC-Address alterado no segundo octeto, como mostrado acima, mas para o endereço MAC do NLB (02-BF-AC-11-02-0D). Mostrando que todo o pacote de entrada vai para o MAC do NLB e não o MAC utilizado para o envio. Achou confuso ainda? Se voce quiser se aprofundar mais de uma olhada no artigo - Network Load Balancing Technical Overview.