Network Load Balancing en Windows Server 2003 (NLB)

Este es un pequeño manual para crear un Load Balancing (frontal y 2 backends sirviendo con un IIS) con un Windows 2003 Data Center Edition.

Primero vamos a definir la infraestructura.

Front-Win001 (192.168.1.41)
Back-Server01 (192.168.1.39)
Back-Server02 (192.168.1.42)
Balanced-Server01 (192.168.1.40)

La maquina Balanced-Server01 en realidad es el servicio Load Balancing que dependiendo del estado de los backend (o de la configuración del Load Balancing) servirá la web desde un servidor o desde otro.

Los los Backends tienen un IIS en este caso sin ninguna configuración en especial (pero lo ideal seria tener un sistema de archivos centralizado para estar sirviendo la misma web, pero para hacer las pruebas y ver que funciona, vamos a mostrar webs distintas dependiendo del backend que esta funcionando)

La maquina Front es la maquina “fisica” que tiene corriendo el servicio de Load Balancing.

Primer tenemos que tener instalado el servicio IIS en los backends.

Instalar IIS
Instalar IIS

Cuando ya tenemos los backend funcionando con el IIS vamos a ir al servicio de Network Load Balancing del Frontal (en este caso Front-Win001 (192.168.1.41)) para configurar los dos backends.

Le damos a crear un cluster y poner la IP (en este caso Balanced-Server01 (192.168.1.40)) que vamos a publicar de la web.

Configuración IP Balanceado
Configuración IP Balanceado

Es importante describir ciertos campos de este apartado:

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.

Nota: Información de aqui

Una vez tenemos esto seguimos con definiendo los puertos del balanceador. Microsoft por defecto nos habilita todo los puertos.

Puerto
Puerto

Por defecto dejaremos solo el 80.

Por defecto dejamos el 80
Por defecto dejamos el 80

En la siguiente opción, al ser un servicio, podemos indicarle como queremos que se inicie. En este caso, al conseiderarlo critico lo dejaremos como inicio por defecto Iniciado.

Inicio por defecto
Inicio por defecto

Una vez finalizada la configuración ya tenemos el primer nodo del cluster. Mientras configurabamos este nodo, teniamos la posibilidad de agregar mas nodos y configurarlos todos a la vez, pero siempre va bien hacer uno por uno.

Ahora es tan facil como boton derecho, agregar nodo y poner la ip de dicho nodo, en este caso Back-Server02 (192.168.1.42) y ya lo tendremos. Las dos maquinas y el frontal.

Frontal y 2 Backends
Agregar maquina
Frontal y 2 Backends
Frontal y 2 Backends

Pero ahora tocan las prubas. La mas facil es;

Conectarse al balanceador (192.168.1.40) y ver que web muestra:

Primera conexión
Primera conexión

Desactivamos la tarjeta de red del servidor 1 (192.168.1.39) y nos volvemos a conectar al frontal (192.168.1.40) con otro navegador (por temas de cache)

Segunda conexión
Segunda conexión

Y vemos que nos muestra otra web, conectandonos a la misma ip. Ya tenemos nuestro balanceador funcionando. 🙂

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s