9.3. Descripción general de la planificación LVS

Una de las ventajas de usar un LVS cluster es su habilidad para realizar balanceo de cargas flexible y a nivel de IP, en el pool de servidores reales. Esta flexibilidad es debida a la variedad de algoritmos de planificación desde los cuales un administrador puede escoger cuando configura un cluster. El balanceo de cargas LVS es mucho mejor que los métodos menos flexibles tales como Round-Robin DNS donde la naturaleza jerárquica del DNS y el almacenamiento en memoria inmediata (caché) de las máquinas cliente puede llevar a desequilibrios de cargas. También, el filtrado de bajo nivel empleado por el enrutador LVS tiene ventajas sobre el reenvío de las peticiones a nivel de aplicaciones, debido a que el balanceo de cargas a nivel de paquetes de red causa una sobrecarga computacional mínima permitiendo mayor escalabilidad.

Mediante el uso de planificación, el enrutador activo puede tomar en consideración la actividad de los servidores reales y, opcionalmente, un factor de peso asignado por el administrador, cuando se enruten las peticiones de servicios. El uso de pesos asignados otorga prioridad arbitraria a máquinas individuales. Usando esta forma de planificación, es posible crear un grupo de servidores reales usando una variedad de combinaciones de hardware y software y el enrutador activo puede cargar cada servidor real equitativamente.

Los mecanismos de planificación para un LVS cluster son proporcionados por una colección de correcciones del kernel también llamados Servidores Virtuales IP o módulos IPVS. Estos módulos activan la conmutación de la capa 4 (L4) de transporte, el cual está diseñado para funcionar bien con múltiples servidores en una dirección IP única.

Para seguir y enrutar los paquetes a los servidores reales eficientemente, IPVS construye una tabla IPVS en el kernel. Esta tabla es usada por el enrutador LVS activo para redirigir las peticiones desde una dirección virtual de servidor a los servidores reales en el pool. La tabla IPVS es actualizada constantemente por un demonio llamado ipvsadm — agregando y removiendo miembros cluster dependiendo de su disponibilidad.

9.3.1. Algoritmos de planificación

La estructura que la tabla IPVS toma, depende del algoritmo de planificación que el administrador seleccione para cualquier servidor virtual dado. Para permitir la mayor flexibilidad en los tipos de servicios que se pueden colocar en cluster y en como estos servicios son planificados, Red Hat Enterprise Linuxproporciona los siguientes algoritmos de planificación que se listan más abajo. Para instrucciones sobre cómo asignar algoritmos de planificación consulte la Sección 12.6.1.

Planificación Round-Robin

Distribuye cada petición secuencialmente alrededor del pool de servidores reales. Usando este algoritmo, todos los servidores reales son tratados como iguales sin importar su capacidad o carga. Este modelo de planificación se asemeja a round-robin DNS pero es más granular debido al hecho de que está basado en la conexión de la red y no en host. La planificación LVS round-robin tampoco sufre de los desequilibrios causados por los queries DNS.

Planificación de Round-Robin con pesos

Distribuye cada petición secuencialmente alrededor del pool de servidores reales pero otorga más trabajos a servidores con mayor capacidad. La capacidad está indicada por un factor de peso asignado por un usuario, la cual es luego ajustada hacia arriba o abajo usando la información de carga dinámica. Vea la Sección 9.3.2 para más información relacionada a las cargas de servidores reales.

La planificación round-robin con pesos es una mejor opción si hay diferencias significativas en la capacidad de ciertos servidores reales en el pool. Sin embargo, si la carga solicitada varía dramáticamente, el servidor con más peso puede tener que responder más de lo que le corresponde.

Menos conexiones

Distribuye más peticiones a servidores reales con menos conexiones activas. Puesto que sigue la pista de las conexiones vivas a los servidores reales a través de la tabla IPVS, el tipo de algoritmo de menos conexiones es un algoritmo dinámico, haciéndolo una mejor opción si hay un alto grado de variación en la carga de peticiones. Funciona mejor para un conjunto de servidores reales donde cada nodo miembro tiene, en líneas generales, la misma capacidad. Si un grupo de servidores tiene diferentes capacidades, el tipo de planificación de Menos conexiones con pesos, es una mejor opción.

Menos conexiones con pesos (por defecto)

Distribuye más peticiones a servidores con menos conexiones activas relativas a sus capacidades. La capacidad es indicada por un peso asignado por el usuario, el cual es luego ajustado hacia arriba o abajo, a partir de la información de carga dinámica. La adición de pesos hace a este algoritmo ideal cuando el grupo de servidores reales contiene hardware de diferentes capacidades. Consulte la Sección 9.3.2 para más información sobre la asignación de pesos en servidores reales.

Planificación basada en la ubicación de menos conexiones

Distribuye más peticiones a servidores con menos conexiones activas relativo a sus IPs destino. Este algoritmo es diseñado para usarse en un servidor cluster proxy-cache. Enruta los paquetes de una dirección IP al servidor para esa dirección a menos que ese servidor esté por encima de su capacidad y tenga un servidor a la mitad de la carga, en cuyo caso asignará la dirección IP al servidor real con menos cargas.

Planificación de menos conexiones basada en la ubicación con replicación de planificación

Distribuye más peticiones a los servidores con menos conexiones relativas a su destinación IP. Este algoritmo es también diseñado para ser usado en un servidor cluster proxy-cache. Se diferencia de la planificación basada en la ubicación de menos conexiones, porque hace un mapping de las direcciones IP objetivo a un subconjunto de nodos de servidores reales. Las peticiones son luego enrutadas al servidor en este subconjunto con el menor número de conexiones. Si todos los nodos para la IP destino están por encima de sus capacidades, replica un nuevo servidor para esa dirección agregando el servidor real con menos conexiones de todo el pool de servidores al subconjunto de servidores reales para esa IP de destino. El nodo más cargado es luego sacado del subconjunto de servidores reales para prevenir sobre-replicación.

Planificación destino Hash

Distribuye peticiones al pool de servidores reales buscando la IP destino en una tabla hash estática. Este algoritmo está diseñado para usarse en un servidor cluster proxy-cache.

Planificación de fuente Hash

Distribuye las peticiones al pool de servidores reales buscando por la dirección IP fuente en una tabla hash estática. Este algoritmo está diseñado para enrutadores LVS con múltiples cortafuegos (firewalls).

9.3.2. Carga y planificación del servidor

El administrador de un LVS cluster puede asignar un peso a cada nodo en el pool de servidores reales. Este peso es un valor entero el cual es factorizado en cualquier algoritmo de planificación sensitivo a pesos (tal como menos conexiones con pesos) y ayuda al enrutador LVS a cargar hardware con diferentes capacidades de manera más uniforme.

Los pesos funcionan como una relación de transformación relativa uno al otro. Por ejemplo, si un servidor real tiene un peso de 1 y otro tiene un peso de 5, luego el servidor con un peso de 5 obtendrá 5 conexiones por cada 1 conexión que el otro servidor obtenga. El valor por defecto para el peso de un servidor real es 1.

Aunque al agregar pesos a diferentes configuraciones de hardware en un pool de servidores reales puede ayudar a balancear las cargas del cluster más eficientemente, también puede causar un desequilibrio temporal cuando un servidor real es introducido en el pool de servidores reales y el servidor virtual es planificado usando menos conexiones con pesos. Para ilustrar, digamos que hay tres servidores en el pool de servidores reales. Los Servidores A y B son pesados a 1 y el tercero, Servidor C, es pesado a 2. Si el servidor C se cae por alguna razón, los servidores A y B equitativamente se distribuyen la carga abandonada. Sin embargo, una vez que el servidor C vuelva a estar en línea, el enrutador LVS lo verá como un servidor de cero conexiones e intentará inundarlo con todas las peticiones entrantes hasta que esté a la par con los servidores A y B.

Para prevenir este fenómeno, el administrador puede hacer el servidor virtual un servidor quiesce — en cualquier momento que un servidor real entre en línea, la tabla de menos conexiones es reseteada a cero para que así el enrutador LVS enrute las peticiones como si todos los servidores reales estuviesen recientemente añadidos al cluster.