---
title: "Microsoft NLB Alternativa para VMware: Problemas de multicast e unicast resolvidos"
canonical: "https://safekit.eviden.com/pt-br/best-practises/microsoft-nlb-vmware-multicast-unicast-alternative/"
description: "Com dificuldades para configurar o balanceamento de carga multicast ou unicast do Microsoft no VMware? SafeKit propõe um cluster farm sem SAN como uma alternativa simples. Obtenha balanceamento de carga e failover automáticos no Windows e Linux sem entradas ARP estáticas, falsificação de MAC ou configuração de rede especializada."
category: "best-practises"
lang: "pt-br"
topics: "Microsoft Modo multicast NLB, Microsoft Modo unicast NLB, Alternativa com SafeKit, Como o cluster SafeKit em modo farm funciona com Windows ?"
---

# Microsoft Alternativa NLB da VMware: Problemas de multicast e unicast resolvidos {#microsoft-nlb-vmware-alternative-multicast-and-unicast-issues-solved}

## Microsoft Modo multicast NLB {#microsoft-nlb-multicast-mode}

Conforme explicado na base de conhecimento [ da VMware sobre a configuração do modo multicast do balanceamento de carga de rede (NLB) ](<https://knowledge.broadcom.com/external/article?articleNumber=414968>) , é necessário configurar manualmente a resolução ARP estática no switch ou roteador para cada porta conectada ao cluster. A implementação do modo multicast do NLB Microsoft em um ambiente de rede desconhecido pode ser uma tarefa complexa e árdua.

## Microsoft Modo unicast NLB {#microsoft-nlb-unicast-mode}

Com o modo unicast Microsoft do NLB, você deve configurar o host ESXi/ESX para não enviar pacotes RARP quando qualquer uma de suas máquinas virtuais estiver ligada. É por isso que o NLB [ Microsoft não funciona corretamente no modo unicast com o VMware ](<https://knowledge.broadcom.com/external/article/344421/microsoft-nlb-not-working-properly-in-un.html>) .

## Alternativa com SafeKit {#alternative-with-safekit}

A configuração de endereço IP virtual [ SafeKit ](<https://safekit.eviden.com/pt-br/best-practises/how-a-virtual-ip-address-works/>) não requer nenhuma configuração de rede especial e o balanceamento de carga de rede pode ser executado em qualquer ambiente. Uma característica importante quando a solução precisa ser implantada em uma infraestrutura desconhecida: switches ou roteadores desconhecidos, servidores físicos ou virtuais.

## Como o cluster SafeKit em modo <span class="notranslate farm-term" translate="no">farm</span> funciona com Windows ? {#safekit-farm-cluster}

### Endereço IP virtual em um cluster em modo de <span class="notranslate farm-term" translate="no">farm</span> {#virtual-ip-address-farm}

![Como o cluster SafeKit implementa o balanceamento de carga e o failover da rede Windows](https://safekit.eviden.com/wp-content/uploads/2023/02/safekit-up-up-up-300.png "w:300")

Na figura anterior, o aplicativo Windows está sendo executado nos 3 servidores (3 é um exemplo, pode ser 2 ou mais). Os usuários estão conectados a um endereço IP virtual.

O [endereço IP virtual](https://safekit.eviden.com/pt-br/best-practises/how-a-virtual-ip-address-works/) é configurado localmente em cada servidor no cluster em modo <span class="notranslate farm-term" translate="no">farm</span>.  
O tráfego de entrada para o endereço IP virtual é recebido por todos os servidores e dividido entre eles por um filtro de rede dentro do kernel de cada servidor.

SafeKit detecta falhas de hardware e software, reconfigura os filtros de rede em caso de falha e oferece verificadores de aplicativos configuráveis e scripts de recuperação.

### Balanceamento de carga em um filtro de rede {#network-load-balancing}

O algoritmo de balanceamento de carga da rede dentro do filtro de rede é baseado na identidade dos pacotes do cliente (endereço IP do cliente, porta TCP do cliente). Dependendo da identidade da entrada do pacote do cliente, apenas um filtro em um servidor aceita o pacote; os outros filtros em outros servidores o rejeitam.

Uma vez que um pacote é aceito pelo filtro em um servidor, apenas a CPU e a memória desse servidor são usadas pelo Windows que responde à solicitação do cliente. As mensagens de saída são enviadas diretamente do servidor de aplicativos para o cliente.

Se um servidor falhar, o protocolo de pulsação <span class="notranslate farm-term" translate="no">farm</span> reconfigura os filtros no cluster de balanceamento de carga da rede para reequilibrar o tráfego nos servidores disponíveis restantes.

### Aplicações com ou sem estado {#stateful-stateless}

Com um Windows estado, há afinidade de sessão. O mesmo cliente deve estar conectado ao mesmo servidor em várias sessões TCP para recuperar seu contexto no servidor. Nesse caso, a regra de balanceamento de carga SafeKit é configurada no endereço IP do cliente. Assim, o mesmo cliente está sempre conectado ao mesmo servidor em várias sessões TCP. E diferentes clientes são distribuídos entre diferentes servidores no <span class="notranslate farm-term" translate="no">farm</span>.

Com um aplicativo Windows sem estado, não há afinidade de sessão. O mesmo cliente pode estar conectado a diferentes servidores no <span class="notranslate farm-term" translate="no">farm</span> em várias sessões TCP. Não há contexto armazenado localmente em um servidor de uma sessão para outra. Nesse caso, a regra de balanceamento de carga SafeKit é configurada na identidade da sessão do cliente TCP. Essa configuração é a melhor para distribuir sessões entre servidores, mas requer um serviço TCP sem afinidade de sessão.

### Como configurar um cluster SafeKit no modo <span class="notranslate farm-term" translate="no">farm</span> para Windows ? {#safekit-farm-cluster-configuration}

![Console Web SafeKit: configuração de cluster para balanceamento de carga de rede Windows e gerenciamento de IP virtual.](https://safekit.eviden.com/wp-content/uploads/2026/01/safekit-farm-cluster-config.png "w:966")

O **cluster SafeKit no modo <span class="notranslate farm-term" translate="no">farm</span>** foi projetado para alta disponibilidade e escalabilidade de serviços. A configuração se concentra em distribuir o tráfego de entrada em ambos os nós simultaneamente:

  * **Serviços com balanceamento de carga (guia Macros):** defina os serviços de aplicativos específicos (por exemplo, Apache, IIS, Nginx) a serem mantidos ativos em todos os nós.
  * **Rede(s) de pulsações:** Caminho(s) de comunicação usado(s) para detectar se um nó saiu da <span class="notranslate farm-term" translate="no">farm</span>, acionando uma redistribuição imediata da carga.
  * **IP Virtual (VIP <span class="notranslate farm-term" translate="no">Farm</span>):** Ao contrário de um cluster mirror, o VIP <span class="notranslate farm-term" translate="no">Farm</span> é compartilhado entre os nós usando um algoritmo de filtragem do kernel para distribuir o tráfego de rede.
  * **Regras de balanceamento de carga:** defina a política de distribuição de tráfego com base no endereço IP de origem ou na porta.
  * **Verificadores:** Monitore a integridade do aplicativo e acione a reinicialização automática se for detectada uma falha no processo.

### Como monitorar um cluster SafeKit em modo <span class="notranslate farm-term" translate="no">farm</span> para Windows ? {#safekit-farm-cluster-monitoring}

![Console SafeKit: Monitoramento de um cluster em modo farm de 2 nós, mostrando ambos os nós Windows no estado UP com balanceamento de carga ativo.](https://safekit.eviden.com/wp-content/uploads/2026/01/safekit-farm-cluster-monitor.png "w:473")

O monitoramento de um cluster no modo <span class="notranslate farm-term" translate="no">farm</span> fornece visibilidade sobre a natureza **Ativo-Ativo** da infraestrutura, onde todos os nós contribuem para o desempenho do aplicativo (mostrando 2 nós neste exemplo):

  * **Estado UP (50% em 2 nós):** Em uma <span class="notranslate farm-term" translate="no">farm</span> íntegra, ambos os nós estão no estado " UP " (50%), o que significa que ambos estão recebendo e processando ativamente as solicitações do cliente por meio do IP virtual compartilhado.
  * **Rebalanceamento automático:** se um nó falhar, o console mostra visualmente o nó restante recebendo 100% do tráfego. Não há atraso de "failover", pois o nó sobrevivente já está ativo (além de um tempo de detecção de alguns segundos).
  * **Inserção de nó:** quando um nó reparado é reiniciado, ele transita de " STOP " para " UP " e começa automaticamente a receber sua parte da carga sem intervenção do administrador.
  * **Sem sincronização de dados:** observe que, em um cluster no modo <span class="notranslate farm-term" translate="no">farm</span>, não há estado de resincronização "Laranja", pois espera-se que os nós sejam sem estado ou compartilhem um banco de dados de backend (que pode ser protegido separadamente em um cluster mirror).

Além de simples ícones de status, a interface fornece gerenciamento de nó com um clique, permitindo que você pare ou inicie manualmente um nó para manutenção planejada, enquanto o IP virtual compartilhado redistribui automaticamente o tráfego sem interromper a atividade do usuário.