GuilleSQL :: Microsoft SQL Server, SSIS, y más !!

Cluster NLB: Modo de operación del Cluster NLB (Cluster operation mode): ¿Unicast o Multicast?

Volver a: [Instalar y Configurar Microsoft Cluster NLB (Network Load Balancing) en Windows Server 2003]


Este capítulo explica la configuración del Modo de Operación de un Cluster NLB (Cluster Operation Mode), es decir, si deseamos que nuestro Cluster NLB trabaje en modo Unicast o Multicast. Esta es una de las principales propiedades que deberemos configurar y también una de las que más dudas genera. En este capítulo se explica cuál es la recomendación de Microsoft (Unicast o Multicast) y en qué casos, que diferencia existe entre Unicast y Multicast (principalmente en la gestión de la MAC), etc. También se comenta la configuración Unicast Multicast con Hyper-V.

El modo de operación del Cluster NLB, es una propiedad del Cluster NLB (no es una propiedad de regla de puertos) que permite especificar cómo se desea que se gestione la dirección MAC de las tarjetas de red pertenecientes al Cluster NLB.

A fin de cuentas, la base del funcionamiento del Cluster NLB está en el falseo de MAC (MAC spoofing) de las respuestas ARP, es decir, en sobrescribir los paquetes salientes del Cluster NLB con la MAC Virtual y la dirección IP Virtual del Cluster NLB, y recibir los paquetes que son enviados a dicha MAC e IP.

Microsoft Network Load Balancing nos ofrece dos alternativas para el modo de operación del Cluster NLB (Cluster operation mode):

  • Unicast. Esta es la opción por defecto y es la opción recomendada. La dirección MAC del Cluster, es asignada a todas las tarjetas de red asignadas al Cluster NLB, y la dirección MAC de cada tarjeta de red NO es utilizada. Es decir, cada tarjeta de red asignada al Cluster NLB mantiene una única dirección MAC, en particular, la MAC del Cluster. Así, tanto la dirección IP del Cluster como la dirección IP propia de la tarjeta de Red, se resuelven a la dirección MAC del Cluster, ya que se sobrescribe la dirección MAC real de las tarjetas de red del Cluster NLB con la dirección MAC del Cluster.

    Esta configuración, implica que NO es posible la comunicación desde un Host del Cluster NLB a otro Host del Cluster NLB a través de la tarjeta de red utilizada en el Cluster, debido a que al compartir la dirección MAC (es decir, utilizar la misma dirección MAC en el equipo de origen y en la tarjeta de red del equipo destino), se produce una confusión, es decir, en el nivel de enlace OSI (Ethernet y direcciones MAC) no es posible diferenciar al destinatario del emisor, y por ello, la comunicación host-to-host (también conocida como intra-host) NO es posible.

    Es interesante recordar (para aquellos pocos que lo puedan utilizar) que al utilizar Application Center 2000 para configurar NLB, se especificará el modo de operación del Cluster NLB en Unicast, conforme indicar el artículo de soporte KB 278431.

  • Multicast. La dirección MAC del Cluster, es asignada a todas las tarjetas de red asignadas al Cluster NLB, pero de forma adicional, cada tarjeta de red mantiene su dirección MAC. Es decir, cada tarjeta de red asignada al Cluster NLB mantiene dos direcciones MAC, pero sólo la dirección MAC del Cluster es utilizada para la comunicación con los equipos clientes. Así, la dirección IP del Cluster se resuelve a la dirección MAC del Cluster, y la dirección IP propia de la tarjeta de Red se resuelve a la dirección MAC propia de dicha tarjeta.

    Este comportamiento implica que una tarjeta de Red de un Cluster NLB configurado en modo de operación Multicast, es capaz de manejar tanto el tráfico de los clientes (paquetes destinados a la dirección IP/MAC del Cluster) como el tráfico propio del Host (paquetes destinados a la dirección IP/MAC de la tarjeta de Red del Cluster NLB).

    En algunos casos la utilización de direcciones MAC multicast, no es soportada por la implementación ARP de algunos enrutadores (routers), como es el caso de Cisco (ni más ni menos ;-), en cuyo caso, el Cluster NLB no será visible fuera del segmento Ethernet al que pertenece. Para evitar este tipo de problemas, debe garantizarse que el enrutador (Router) acepta respuestas ARP que incluyan una dirección MAC en el payload de la trama Ethernet, pero que parecen proceder de un dispositivo con una dirección MAC distinta, conforme se muestra en la cabecera Ethernet. Si el enrutador (router) o el conmutador multi-capa (multi-layer switch) correspondiente no soporta esta funcionalidad, es posible crear una entrada ARP estática en el router como solución al problema, para que así sea capaz de resolver la dirección IP Unicast a la dirección MAC Multicast correspondiente.

    Multicast puede ofrecer un rendimiento inferior a Unicast, debido a que utiliza una única tarjeta de red tanto para el tráfico de los equipos clientes como para el tráfico host-to-host (también conocido como tráfico intra-host).

    Al utilizar Multicast es posible activar la opción IGMP Multicast. La principal razón por la que activar o desactivar la opción IGMP Multicast, es en caso de descubrir algún tipo de problema de funcionamiento, como por ejemplo, problemas de convergencia.

La recomendación de Microsoft es utilizar el modo de operación Unicast, excepto que se disponga de una única tarjeta de red (tanto para el Cluster NLB como para el resto de comunicaciones) y además sea necesaria la comunicación entre los distintos Nodos del Cluster. Como hablamos, es recomendado para evitar problemas con enrutadores (routers).

Es importante tener en cuenta, que la dirección MAC del Cluster NLB, se genera de forma automática, es decir, no podemos especificar de forma explícita que dirección MAC deseamos utilizar para utilizar como MAC del Cluster.

También es interesante recordar que, independientemente del modo de operación del Cluster NLB (es decir, sea Unicast o sea Multicast), las tarjetas de red utilizadas en un Cluster NLB dispondrán al menos de dos direcciones IP: la dirección IP propia de la tarjeta más la dirección IP del Cluster NLB.

Por último, quería comentar mi experiencia con máquinas virtuales en Hyper-V y el Modo de Operación NLB (Unicast vs Multicast). En las pruebas realizadas en mi laboratorio con máquinas virtuales, sobre las máquinas virtuales de Virtual Server 2005 R2 he conseguido configurar NLB en Unicast. Sin embargo, sobre máquinas virtuales en Hyper-V con tarjetas de red Network Adapter (synthetic NIC), sólo he conseguido hacer funcionar NLB en Modo de Operación Multicast. Es curioso, porque al configurar NLB en Unicast sobre máquinas virtuales en Hyper-V, todo parece que funciona bien (desde los propios nodos del NLB funciona todo OK, y no existen errores), pero desde un equipo cliente no se consigue comunicación con la dirección IP virtual del NLB. La solución temporal (WorkAround) que encontré fue configurar NLB en Multicast. Por otro lado, he leído en algún Foro comentarios de otras personas que les ha ocurrido y comentan que utilizando tarjetas de red Legacy Network Adapter SI es posible hacer funcionar el NLB en Unicast sobre máquinas virtuales en Hyper-V (ojo, que esto lo he leído pero no lo he probado).

Volver a: [Instalar y Configurar Microsoft Cluster NLB (Network Load Balancing) en Windows Server 2003]


[Fecha del Artículo (UTC): 13/06/2008]
[Autor: GuilleSQL]



Escribir un Comentario

Para poder escribir un comentario, debe Iniciar Sesión con un usuario.

Si no dispone de un usuario, puede Registrarse y hacerse miembro.

Si dispone de un usuario, pero no recuerda sus credenciales de acceso, puede Restablecer su Contraseña.

Miembros de
Miembros de GITCA (Global IT Community Association)

Menu de Usuario
  Iniciar Sesión
  Registrarse
  Restablecer Contraseña
  Ventajas de Registrarse

Acerca de
  Contigo desde Oct 2007
  771 usuarios registrados
  86146 pageloads/mes
  Ranking Alexa 498160

Social Networks
Sigue a Portal GuilleSQL en Linkedin !!
Sigue a Portal GuilleSQL en Twitter !!



Archivo

Marzo de 2017 (3)
Enero de 2017 (4)
Junio de 2016 (1)
Mayo de 2016 (2)
Abril de 2016 (2)
Septiembre de 2015 (2)
Agosto de 2015 (2)
Junio de 2015 (10)
Mayo de 2015 (4)
Abril de 2015 (8)
Marzo de 2015 (11)
Octubre de 2014 (3)
Septiembre de 2014 (7)
Agosto de 2014 (5)
Julio de 2014 (2)
Mayo de 2014 (4)
Abril de 2014 (4)
Marzo de 2014 (4)
Febrero de 2014 (1)
Enero de 2014 (5)
Diciembre de 2013 (8)
Noviembre de 2013 (2)
Octubre de 2013 (7)
Septiembre de 2013 (6)
Agosto de 2013 (1)
Julio de 2013 (6)
Junio de 2013 (11)
Mayo de 2013 (7)
Abril de 2013 (6)
Febrero de 2013 (5)
Enero de 2013 (7)
Diciembre de 2012 (12)
Noviembre de 2012 (13)
Octubre de 2012 (5)
Septiembre de 2012 (3)
Agosto de 2012 (6)
Julio de 2012 (4)
Junio de 2012 (1)
Mayo de 2012 (2)
Abril de 2012 (7)
Marzo de 2012 (16)
Febrero de 2012 (9)
Enero de 2012 (5)
Diciembre de 2011 (10)
Noviembre de 2011 (10)
Octubre de 2011 (4)
Septiembre de 2011 (5)
Agosto de 2011 (2)
Julio de 2011 (2)
Junio de 2011 (4)
Mayo de 2011 (2)
Abril de 2011 (6)
Marzo de 2011 (4)
Febrero de 2011 (10)
Enero de 2011 (5)
Diciembre de 2010 (6)
Noviembre de 2010 (4)
Octubre de 2010 (8)
Septiembre de 2010 (4)
Agosto de 2010 (1)
Julio de 2010 (3)
Mayo de 2010 (5)
Abril de 2010 (6)
Marzo de 2010 (8)
Febrero de 2010 (3)
Enero de 2010 (1)
Diciembre de 2009 (9)
Noviembre de 2009 (14)
Octubre de 2009 (2)
Septiembre de 2009 (8)
Agosto de 2009 (2)
Julio de 2009 (10)
Junio de 2009 (9)
Mayo de 2009 (10)
Abril de 2009 (9)
Marzo de 2009 (3)
Febrero de 2009 (2)
Enero de 2009 (3)
Noviembre de 2008 (2)
Octubre de 2008 (2)
Septiembre de 2008 (2)
Agosto de 2008 (5)
Julio de 2008 (5)
Junio de 2008 (1)
Mayo de 2008 (3)
Abril de 2008 (2)
Marzo de 2008 (2)
Febrero de 2008 (2)
Enero de 2008 (5)
Noviembre de 2007 (2)
Octubre de 2007 (2)






Esta información se proporciona "como está" sin garantías de ninguna clase, y no otorga ningún derecho.
This information is provided "AS IS" with no warranties, and confers no rights.

Copyright © 2007 GuilleSQL, todos los derechos reservados.
GuilleSQL.com y GuilleSQL.net son también parte de Portal GuilleSQL.

Visitas recibidas (Page Loads) en GuilleSQL (fuente: StatCounter):

screen resolution stats
Visitas