---
title: "Alternativa a VMware NLB Microsoft : Solución a problemas de multidifusión y unidifusión"
canonical: "https://safekit.eviden.com/es/best-practises/microsoft-nlb-vmware-multicast-unicast-alternative/"
description: "¿Problemas con el balanceo de carga de red (NLB) multicast o unicast en Microsoft en VMware? SafeKit propone un clúster farm sin SAN como una alternativa sencilla. Obtenga balanceo de carga y conmutación por error automáticos en Windows y Linux sin entradas ARP estáticas, suplantación de MAC ni configuración de red especializada."
category: "best-practises"
lang: "es"
topics: "Microsoft Modo multidifusión NLB, Microsoft Modo unidifusión NLB, Alternativa con SafeKit, ¿Cómo funciona el clúster SafeKit en modo farm con Windows ?"
---

# Alternativa a VMware NLB Microsoft : Problemas de multidifusión y unidifusión resueltos {#microsoft-nlb-vmware-alternative-multicast-and-unicast-issues-solved}

## Microsoft Modo multidifusión NLB {#microsoft-nlb-multicast-mode}

Como se explica en la base de conocimientos de [ sobre la configuración del modo multidifusión de balanceo de carga de red (NLB) ](<https://knowledge.broadcom.com/external/article?articleNumber=414968>) , es necesario configurar manualmente la resolución ARP estática en el conmutador o enrutador para cada puerto conectado al clúster. La implementación del modo multidifusión NLB Microsoft en un entorno de red desconocido puede resultar una tarea compleja y laboriosa.

## Microsoft Modo unidifusión NLB {#microsoft-nlb-unicast-mode}

Con el modo unicast de Microsoft NLB, debe configurar el host ESXi/ESX para que no envíe paquetes RARP cuando cualquiera de sus máquinas virtuales esté encendida. Por eso, [ Microsoft NLB no funciona correctamente en modo unicast con VMware ](<https://knowledge.broadcom.com/external/article/344421/microsoft-nlb-not-working-properly-in-un.html>) .

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

La configuración de la dirección IP virtual [ SafeKit ](<https://safekit.eviden.com/es/best-practises/how-a-virtual-ip-address-works/>) no requiere ninguna configuración de red especial y el balanceo de carga de red puede ejecutarse en cualquier entorno. Una característica importante cuando la solución debe implementarse en una infraestructura desconocida: conmutadores o enrutadores desconocidos, servidores físicos o virtuales.

## ¿Cómo funciona el clúster SafeKit en modo <span class="notranslate farm-term" translate="no">farm</span> con Windows ? {#safekit-farm-cluster}

### Dirección IP virtual en un clúster en modo <span class="notranslate farm-term" translate="no">farm</span> {#virtual-ip-address-farm}

![Cómo el clúster SafeKit implementa el balanceo de carga y la conmutación por error de la red Windows](https://safekit.eviden.com/wp-content/uploads/2023/02/safekit-up-up-up-300.png "w:300")

En la figura anterior, la aplicación Windows se está ejecutando en los 3 servidores (3 es un ejemplo, pueden ser 2 o más). Los usuarios están conectados a una dirección IP virtual.

La [dirección IP virtual](https://safekit.eviden.com/es/best-practises/how-a-virtual-ip-address-works/) se configura localmente en cada servidor del clúster en modo <span class="notranslate farm-term" translate="no">farm</span>.  
El tráfico de entrada a la dirección IP virtual es recibido por todos los servidores y dividido entre ellos por un filtro de red dentro del núcleo de cada servidor.

SafeKit detecta fallos de hardware y software, reconfigura los filtros de red en caso de fallo y ofrece verificadores de aplicaciones y scripts de recuperación configurables.

### Equilibrio de carga en un filtro de red {#network-load-balancing}

El algoritmo de equilibrio de carga de la red dentro del filtro de red se basa en la identidad de los paquetes del cliente (dirección IP del cliente, puerto TCP del cliente). Dependiendo de la identidad de la entrada del paquete del cliente, solo un filtro en un servidor acepta el paquete; los otros filtros en otros servidores lo rechazan.

Una vez que un paquete es aceptado por el filtro en un servidor, solo la CPU y la memoria de este servidor son utilizadas por la Windows que responde a la solicitud del cliente. Los mensajes de salida se envían directamente desde el servidor de aplicaciones al cliente.

Si un servidor falla, el protocolo de latido <span class="notranslate farm-term" translate="no">farm</span> reconfigura los filtros en el clúster de equilibrio de carga de red para reequilibrar el tráfico en los servidores disponibles restantes.

### Aplicaciones con o sin estado {#stateful-stateless}

Con una aplicación Windows con estado, existe afinidad de sesión. El mismo cliente debe estar conectado al mismo servidor en múltiples sesiones TCP para recuperar su contexto en el servidor. En este caso, la regla de equilibrio de carga SafeKit se configura en la dirección IP del cliente. Por lo tanto, el mismo cliente siempre está conectado al mismo servidor en múltiples sesiones TCP. Y los diferentes clientes se distribuyen entre diferentes servidores en el <span class="notranslate farm-term" translate="no">farm</span>.

Con una Windows sin estado, no hay afinidad de sesión. El mismo cliente puede conectarse a diferentes servidores en la <span class="notranslate farm-term" translate="no">farm</span> en múltiples sesiones TCP. No hay ningún contexto almacenado localmente en un servidor de una sesión a otra. En este caso, la regla de equilibrio de carga SafeKit se configura en la identidad de la sesión del cliente TCP. Esta configuración es la mejor para distribuir sesiones entre servidores, pero requiere un servicio TCP sin afinidad de sesión.

### ¿Cómo configurar un clúster SafeKit en modo <span class="notranslate farm-term" translate="no">farm</span> para Windows ? {#safekit-farm-cluster-configuration}

![Consola web SafeKit: configuración del clúster para el equilibrio de carga de la red Windows y la gestión de la IP virtual.](https://safekit.eviden.com/wp-content/uploads/2026/01/safekit-farm-cluster-config.png "w:966")

El **clúster SafeKit en modo <span class="notranslate farm-term" translate="no">farm</span>** está diseñado para ofrecer alta disponibilidad y escalabilidad de los servicios. La configuración se centra en distribuir el tráfico entrante entre ambos nodos simultáneamente:

  * **Servicios con balanceo de carga (pestaña Macros):** Defina los servicios de aplicación específicos (por ejemplo, Apache, IIS, Nginx) que se mantendrán activos en todos los nodos.
  * **Red(es) de latidos:** ruta(s) de comunicación utilizada(s) para detectar si un nodo ha abandonado la <span class="notranslate farm-term" translate="no">farm</span>, lo que desencadena una redistribución inmediata de la carga.
  * **IP virtual (VIP <span class="notranslate farm-term" translate="no">Farm</span>):** a diferencia de un clúster mirror, el VIP <span class="notranslate farm-term" translate="no">Farm</span> se comparte entre los nodos mediante un algoritmo de filtrado del kernel para distribuir el tráfico de red.
  * **Reglas de equilibrio de carga:** defina la política de distribución del tráfico en función de la dirección IP o el puerto de origen.
  * **Checkers:** supervise el estado de la aplicación y active el reinicio automático si se detecta un error en un proceso.

### ¿Cómo supervisar un clúster SafeKit en modo <span class="notranslate farm-term" translate="no">farm</span> para Windows ? {#safekit-farm-cluster-monitoring}

![Consola SafeKit: Supervisión de un clúster en modo granja de dos nodos que muestra ambos nodos Windows en estado UP con equilibrio de carga activo.](https://safekit.eviden.com/wp-content/uploads/2026/01/safekit-farm-cluster-monitor.png "w:473")

La supervisión de un clúster en modo <span class="notranslate farm-term" translate="no">farm</span> proporciona visibilidad sobre la naturaleza **activa-activa** de la infraestructura, donde todos los nodos contribuyen al rendimiento de la aplicación (mostrando 2 nodos en este ejemplo):

  * **Estado UP (50 % en 2 nodos):** en una <span class="notranslate farm-term" translate="no">farm</span> saludable, ambos nodos están en estado " UP " (50 %), lo que significa que ambos están recibiendo y procesando activamente las solicitudes de los clientes a través de la IP virtual compartida.
  * **Reequilibrio automático:** si un nodo falla, la consola muestra visualmente que el nodo restante toma el 100 % del tráfico. No hay retraso de "conmutación por error", ya que el nodo superviviente ya está activo (aparte de un tiempo de detección de unos pocos segundos).
  * **Inserción de nodo:** cuando se reinicia un nodo reparado, pasa de " STOP " a " UP " y comienza automáticamente a recibir su parte de la carga sin intervención del administrador.
  * **Sin sincronización de datos:** Tenga en cuenta que en un clúster en modo <span class="notranslate farm-term" translate="no">farm</span>, no existe el estado de resincronización "Naranja", ya que se espera que los nodos no tengan estado o compartan una base de datos de backend (que puede protegerse por separado en un clúster mirror).

Más allá de los simples iconos de estado, la interfaz proporciona la gestión de nodos con un solo clic, lo que le permite detener o iniciar manualmente un nodo para el mantenimiento planificado, mientras que la IP virtual compartida redistribuye automáticamente el tráfico sin interrumpir la actividad del usuario.