Este documento descreve a implementação do modo de Balanceamento de Carga de Rede (NLB - Network Load Balancing) da Microsoft no Cisco Unified Computing System-B (UCS-B) Series com Interconexão de Estrutura (FI - Fabric Interconnect) no modo de Host Final. Há também vários requisitos nos dispositivos upstream para facilitar o encaminhamento correto do tráfego NLB que estão descritos neste documento. O exemplo de configuração concentra-se no modo IGMP (Internet Group Management Protocol) multicast.
A Cisco recomenda que você tenha conhecimento destes tópicos:
Este documento não se restringe a versões de software e hardware específicas.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
O Microsoft NLB funciona em três modos operacionais diferentes: unicast, multicast e multicast IGMP. Um grupo de nós NLB é conhecido coletivamente como um cluster NLB. Um cluster NLB atende um ou mais endereços IP virtuais (VIP). Os nós no cluster NLB usam seu algoritmo de balanceamento de carga para concordar em qual nó individual servirá o fluxo de tráfego específico destinado ao VIP do NLB.
Este documento não faz recomendações de implantação específicas para o Microsoft NLB no UCS. Conforme descrito neste documento, o NLB se baseia em métodos não convencionais para a entrega de tráfego vinculado ao cluster. Foi observado que os modos IGMP multicast e multicast parecem ter uma operação estável e consistente em servidores UCS-B Series. Embora as diretrizes de dimensionamento de NLB estejam além do escopo deste documento, é uma solução geralmente recomendada para implantações menores.
A configuração padrão do NLB é o modo unicast. No modo unicast, o NLB substitui o endereço MAC real de cada servidor no cluster em um endereço MAC NLB comum. Normalmente, algo no intervalo 02bf:xxxx:xxxx. Todos os nós no cluster NLB entendem o que são o NLB VIP e o endereço MAC. O tráfego, que inclui respostas ARP (Address Resolution Protocol) de nós NLB, nunca é originado do endereço MAC ou IP do NLB. Em vez disso, os nós NLB usam um endereço MAC atribuído com base na ID do host do membro. O endereço MAC geralmente está no intervalo 0201:xxxx:xxxx, 0202, 0203 e assim por diante, um para cada nó no cluster. Esse é o endereço de origem no cabeçalho da Camada 2 (L2) quando uma solicitação ARP é respondida. No entanto, as informações do cabeçalho ARP contêm o endereço MAC NLB. Assim, os hosts que desejam corresponder ao endereço VIP do NLB enviam tráfego para o endereço MAC do NLB.
Os switches compatíveis com IEEE (dispositivos L2) criam sua tabela de endereços MAC com base no cabeçalho de origem L2 e não nas informações contidas no payload ARP. Isso significa que o tráfego encaminhado ao cluster NLB é enviado ao endereço MAC NLB, que nunca é a origem do tráfego. Portanto, o tráfego destinado ao endereço MAC NLB é inundado como unicast desconhecido.
O modo multicast atribui o endereço IP virtual unicast do cluster a um endereço MAC multicast não-Internet Assigned Numbers Authority (IANA) (03xx.xxxx.xxxx). O rastreamento IGMP não registra dinamicamente esse endereço, o que resulta na inundação do tráfego NLB na VLAN como multicast desconhecido.
O modo IGMP multicast atribui o endereço IP virtual do cluster e um endereço MAC multicast dentro do intervalo IANA (01:00:5E:XX:XX:XX). Os nós em cluster enviam relatórios de associação IGMP para o grupo multicast configurado e, portanto, o FI preenche dinamicamente sua tabela de rastreamento IGMP para apontar para os servidores em cluster.
Há uma pequena vantagem operacional para o uso do modo IGMP de multicast, pois as informações de estado (através de relatórios de associação IGMP e rastreamento IGMP) sobre as portas L2 interessadas podem ser mantidas upstream e downstream. Sem a otimização da espionagem de IGMP, o NLB depende de inundação de multicast desconhecida na VLAN NLB para entrega ao cluster através do receptor de broadcast/multicast designado pelo UCS. Em versões posteriores ao UCS Versão 2.0, o receptor de broadcast/multicast designado é escolhido por VLAN.
Um resumo das etapas necessárias para suportar NLB no modo IGMP de multicast é mostrado aqui:
Uma configuração básica do NLB, os nós podem ser máquinas virtuais (VMs) ou instalação bare-metal do SO Windows Server, é mostrada neste diagrama.
NLB VLAN 10 com sub-rede IP 10.1.1.0 /24. O endereço MAC é truncado para ser breve.
NLB VIP (MAC = 01, IP = 10.1.1.1)
NODE-A (MAC = AA, IP = 10.1.1.10)
NODE-B (MAC = BB, IP = 10.1.1.11)
NODE-C (MAC = CC, IP = 10.1.1.12)
A entrada ARP estática no switch upstream SVI aponta para o endereço VIP 10.1.1.1 para MAC 01.
Os nós NLB da Microsoft enviam o relatório de associação IGMP. Observe que a tabela de rastreamento IGMP pode levar de 30 a 60 segundos para ser preenchida.
Com o rastreamento IGMP e o verificador de VLAN, a tabela de rastreamento é preenchida com o endereço MAC NLB e os grupos que apontam para as portas L2 corretas.
Consulte estes documentos para obter mais informações:
O Nexus 1000v suporta apenas o modo NLB Microsoft unicast. Assim, em implantações do Nexus 1000v com UCS, o modo IGMP multicast só funcionará depois que você desabilitar a espionagem no Nexus 1000v. Quando isso é feito, os pacotes NLB da Microsoft nessa VLAN são inundados como multicast desconhecido.
Para minimizar o impacto das inundações:
Os procedimentos de verificação para os exemplos de configuração descritos neste documento são fornecidos nas respectivas seções.
Atualmente, não existem informações disponíveis específicas sobre Troubleshooting para esta configuração.
Revisão | Data de publicação | Comentários |
---|---|---|
1.0 |
14-Aug-2014 |
Versão inicial |