---
title: "Microsoft NLB Alternativa para VMware: Problemas de multicast e unicast resolvidos"
canonical: "https://safekit.eviden.com/pt-pt/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-pt"
topics: "Microsoft Modo multicast NLB, Microsoft Modo unicast NLB, Alternativa com SafeKit, Como funciona o cluster SafeKit em modo farm 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-pt/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 funciona o cluster SafeKit em modo <span class="notranslate farm-term" translate="no">farm</span> com Windows ? {#safekit-farm-cluster}

### Endereço IP virtual num 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 a redundância da rede Windows](https://safekit.eviden.com/wp-content/uploads/2023/02/safekit-up-up-up-300.png "w:300")

Na figura anterior, a aplicação Windows está a ser executada em 3 servidores (3 é um exemplo, podem ser 2 ou mais). Os utilizadores estão ligados a um endereço IP virtual.

O [endereço IP virtual](https://safekit.eviden.com/pt-pt/best-practises/how-a-virtual-ip-address-works/) é configurado localmente em cada servidor do cluster em modo de <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 distribuído entre eles por um filtro de rede dentro do kernel de cada servidor.

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

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

O algoritmo de balanceamento de carga da rede, dentro do filtro de rede, baseia-se 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 num servidor aceita o pacote; os outros filtros noutros servidores rejeitam-no.

Uma vez que um pacote é aceite pelo filtro num servidor, apenas a CPU e a memória desse servidor são utilizadas pela Windows que responde ao pedido do cliente. As mensagens de saída são enviadas diretamente do servidor de aplicações para o cliente.

Se um servidor falhar, o protocolo de pulsações <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 uma aplicação Windows persistente, existe afinidade de sessão. O mesmo cliente deve estar ligado ao mesmo servidor em várias sessões TCP para recuperar o seu contexto no servidor. Neste caso, a regra de balanceamento de carga SafeKit é configurada no endereço IP do cliente. Assim, o mesmo cliente está sempre ligado ao mesmo servidor em várias sessões TCP. E diferentes clientes são distribuídos por diferentes servidores no <span class="notranslate farm-term" translate="no">farm</span>.

Com uma Windows stateless, não existe afinidade de sessão. O mesmo cliente pode estar ligado a diferentes servidores no <span class="notranslate farm-term" translate="no">farm</span> em múltiplas sessões TCP. Não existe contexto armazenado localmente num servidor de uma sessão para outra. Neste caso, a regra de balanceamento de carga SafeKit é configurada na identidade da sessão do cliente TCP. Esta configuração é a que melhor distribui as sessões entre os servidores, mas requer um serviço TCP sem afinidade de sessão.

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

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

O **cluster SafeKit em modo <span class="notranslate farm-term" translate="no">farm</span>** foi concebido para alta disponibilidade e escalabilidade de serviços. A configuração foca-se na distribuição do tráfego de entrada por ambos os nós em simultâneo:

  * **Serviços com Balanceamento de Carga (separador Macros):** Defina os serviços de aplicação 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 utilizado(s) para detetar 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> é partilhado entre os nós, utilizando 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:** Monitorize o estado da aplicação e acione o reinício automático se for detetado um erro de processo.

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

![Consola SafeKit: Monitorização 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")

A monitorização de um cluster em modo <span class="notranslate farm-term" translate="no">farm</span> proporciona visibilidade sobre a natureza **Ativo-Ativo** da infraestrutura, onde todos os nós contribuem para o desempenho da aplicação (mostrando 2 nós neste exemplo):

  * **Estado UP (50% em 2 nós):** Numa <span class="notranslate farm-term" translate="no">farm</span> saudável, ambos os nós estão no estado " UP " (50%), o que significa que estão ambos a receber e a processar ativamente pedidos de clientes através do IP Virtual partilhado.
  * **Reequilíbrio Automático:** Se um nó falhar, a consola mostra visualmente o nó restante a receber 100% do tráfego. Não há atraso de "failover", pois o nó sobrevivente já está ativo (além de um tempo de deteçã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 a sua parte da carga sem intervenção do administrador.
  * **Sem Sincronização de Dados:** Tenha em atenção que, num cluster em modo de <span class="notranslate farm-term" translate="no">farm</span>, não existe o estado de resincronização "Laranja", uma vez que os nós são esperados como sem estado ou partilhando uma base de dados de backend (que pode ser protegida separadamente num cluster mirror).

Além de simples ícones de estado, a interface oferece gestão de nós com um clique, permitindo-lhe parar ou iniciar manualmente um nó para manutenção planeada, enquanto o IP Virtual partilhado redistribui automaticamente o tráfego sem interromper a atividade do utilizador.