Cluster NLB: ¿Cómo funciona el algoritmo de balanceo de Network Load Balancing (NLB)?
|
|
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 ;-).
[Fecha artículo: 13/06/2008]
[Estado artículo: Abierto]
[Autor: GuilleSQL]
|
