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

Cluster NLB: ¿Cómo funciona el algoritmo de balanceo de Network Load Balancing (NLB)?

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


En este capítulo se explica el funcionamiento del algoritmo utilizado por el Cluster NLB de Microsoft, se introduce el concepto de Afinidad del Cluster NLB, cómo gestiona las coneciones entrantes el Cluster NLB, consideraciones de consumo de ancho de banda de red del Cluster NLB (y el switch port flooding), se introduce el concepto del proceso de convergencia del Cluster NLB, y se explican los paquetes Heartbeat intercambiados entre los distintos Nodos del Cluster NLB.

Microsoft Network Load Balancing (NLB) funciona como un controlador de dispositivo (driver) que es posible vincular y configurar sobre las tarjetas de red que se desee, y que en particular es el wlbs.exe (es un driver NDIS).

Microsoft Network Load Balancing (NLB) utiliza un algoritmo distribuido para realizar el mapeo de las conexiones entrantes (es decir, el balanceo de la carga de la red), capaz de permitir que cada Nodo del Cluster NLB pueda realizar rápida e independientemente la decisión del balanceo de carga para cada paquete entrante. Resulta especialmente eficaz cuando los clientes realizan muchas peticiones, cada una muy pequeña, como es el caso de las aplicaciones Web.

La forma de realizar el balanceo de la carga de red depende de la configuración de Afinidad, como se explica más adelante en éste Artículo. Es importante recordar, que el balanceo se realiza sólo y exclusivamente en función de la carga de red, y no en función de otros factores, como la carga de CPU o el uso de memoria. Este comportamiento, puede provocar que la efectividad de Network Load Balancing pueda variar en función de la aplicación, protocolo, y Afinidad que se esté utilizando en cada caso.

Siempre que se recibe un paquete entrante en el Cluster NLB, todos los Nodos del Cluster NLB simultáneamente examinarán dicho paquete, determinando rápidamente que Nodo del Cluster NLB debe despachar dicho paquete. La decisión de qué Nodo debe despachar el paquete, se realiza mediante un procedimiento aleatorio que toma como entrada distintas variables en función de la Afinidad utilizada (ej: dirección IP origen, puerto origen, 24 bits más significativos de la dirección IP origen, etc.). Realizado el mapeo, las sucesivas peticiones similares (dependiendo de la Afinidad) serán despachadas por el mismo Nodo, y rechazadas por el resto de Nodos del Cluster NLB. Es decir, todos los paquetes enviados al Cluster NLB son examinados por todos los Nodos del Cluster NLB, sin embargo, sólo un Nodo procesará el paquete (pasándolo por todas las capas de la pila de protocolos TCP/IP), y el resto de Nodos lo rechazarán (aunque previamente, tendrán que examinar al menos la cabecera del paquete). Este proceso de filtrado de paquetes no deseados resulta más rápido que tener que enrutar los paquetes (que implica recibirlos, examinarlos, re-escribirlos y re-enviarlos). Del mismo modo, este comportamiento implica que toda la información enviada al Cluster NLB es enviada a cada Nodo del Cluster NLB, luego en el caso habitual de redes conmutadas, se estará enviando los mismos paquetes a través de varios puertos del conmutador (switch), consumiendo ancho de banda (los paquetes se envían a todos los Nodos, y los Nodos aceptan y rechazan cada paquete durante el proceso de filtrado). Este comportamiento de enviar la misma información a través de varios puertos del conmutador, es conocido como switch port flooding o también switch flooding.

Conceptualmente podemos decir, que cada Nodo del Cluster mantiene una tabla interna de mapeos por la que sabe qué peticiones debe despachar y qué peticiones NO debe despachar (al ser despachadas por otro Nodo del Cluster NLB). Esta tabla conceptual se mantiene de forma indefinida hasta que se produce un cambio de pertenencia al Cluster NLB, en cuyo caso se produce el proceso de Convergencia.

El proceso de Convergencia implica la creación de una nueva lista de Nodos miembros del Cluster NLB, así como volver a crear la tabla conceptual de mapeos para asociar qué solicitudes de cliente son despachadas por qué Nodo del Cluster NLB. Es decir, el proceso de Convergencia permite reconstruir el estado del Cluster NLB, designando el nuevo Nodo por Defecto (Default Host) en función de la prioridad de los Nodos vivos, y reajustando la distribución del tráfico de red entrante entre los Nodos vivos. Durante el proceso de Convergencia, los Nodos vivos siguen gestionando el tráfico entrante. El proceso de Convergencia puede durar varios segundos (hasta 5 ó 10 segundos). El proceso de Convergencia puede ser iniciado tanto por un cambio en la pertenencia de Nodos al Cluster NLB, como por otros eventos como cambiar el peso de un Host del Cluster, o cambios en las reglas de puerto. Como veremos más adelante en éste Artículo, el proceso de Convergencia puede impactar al Cluster NLB, si se utiliza la Afinidad Single o la Afinidad Class C.

Para el funcionamiento del Cluster NLB, los distintos Nodos del Cluster NLB se envían paquetes de Heartbeat, con el fin de conocer el estado de los Nodos (Hosts) que pertenecen al Cluster NLB (es decir, con el fin de confirmar qué Nodos están vivos). Se supone que un Nodo está en perfecto estado, siempre y cuando se reciben sus paquetes Heartbeat. Si el resto de los Nodos de un Cluster NLB dejan de recibir los paquetes Heartbeat de un Nodo en particular, supondrán que dicho Nodo se ha caído, y se iniciará la Convergencia.

Por defecto se envía un paquete de Heartbeat cada segundo, de un tamaño de 1500 bytes. Del mismo modo, por defecto, se iniciará el proceso de Convergencia con la pérdida de 5 paquetes de Heartbeat consecutivos. Estos valores son configurables, pero por defecto ofrecen un buen comportamiento.

Los paquetes de Heartbeat son paquetes de Broadcast a nivel de Ethernet, motivo que explica porqué todos los Nodos del Cluster deben pertenecer al mismo segmento de red (o misma VLAN, que para el caso, es lo mismo ;-).

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


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)






Copyright © 2007 GuilleSQL, todos los derechos reservados.