Los hosts de equilibrio de carga pueden proporcionar muchos métodos de equilibrio de carga, es decir, los métodos de programación o algoritmos que solemos mencionar:

Round Robin (turno rotatorio)
Este método asigna cíclicamente las solicitudes recibidas a cada máquina del clúster de servidores, es decir, los servidores activos. Si se utiliza este método, todos los servidores marcados para entrar en el servicio virtual deben tener capacidades de recursos similares y ejecutar aplicaciones con cargas similares. Si todos los servidores tienen el mismo rendimiento o uno similar, elegir este método hará que las cargas de los servidores sean similares. Bajo esta premisa, la programación Round Robin es una forma simple y eficaz de distribuir solicitudes. Sin embargo, para el caso de servidores heterogéneos, elegir este método significa que los servidores menos potentes también recibirán solicitudes en la siguiente ronda, incluso si ya no pueden manejar la solicitud actual. Esto puede provocar la sobrecarga de los servidores menos potentes.
Round Robin ponderado (Weighted Round Robin)
Este algoritmo resuelve las desventajas del algoritmo de programación Round Robin simple: las solicitudes entrantes se asignan secuencialmente a los servidores del clúster, pero se tienen en cuenta los pesos previamente asignados a cada servidor. El administrador simplemente define el peso de cada servidor según su capacidad de procesamiento. Por ejemplo, al servidor más potente A se le asigna un peso de 100, mientras que al servidor menos potente se le asigna un peso de 50. Esto significa que el servidor A recibirá 2 solicitudes consecutivas antes de que el servidor B reciba la primera, y así sucesivamente.
Mínimo número de conexiones (Least Connection)
Los dos métodos anteriores no consideran que el sistema no puede identificar cuántas conexiones se mantienen en un momento dado. Por lo tanto, puede ocurrir que el servidor B reciba menos conexiones que el servidor A pero ya esté sobrecargado, porque los usuarios en el servidor B mantienen sus conexiones abiertas durante más tiempo. Es decir, el número de conexiones, como carga del servidor, es acumulativo. Este problema potencial se puede evitar con el algoritmo de “mínimo número de conexiones”: las solicitudes entrantes se asignan según el número de conexiones abiertas actualmente en cada servidor. Es decir, el servidor con menos conexiones activas recibe automáticamente la siguiente solicitud entrante. Básicamente, es el mismo principio que el Round Robin simple: todos los servidores que tienen servicios virtuales deben tener capacidades de recursos similares. Vale la pena señalar que, en entornos de configuración con baja tasa de tráfico, el tráfico de cada servidor no es igual, y se prioriza el primer servidor. Esto se debe a que, si todos los servidores son iguales, el primer servidor tiene prioridad hasta que tenga tráfico activo continuo; de lo contrario, siempre se elegirá el primer servidor.
Mínimo número de conexiones con inicio lento (Least Connection Slow Start Time)
Para los métodos de programación de mínimo número de conexiones y mínimo número de conexiones ponderado, cuando un servidor acaba de incorporarse al entorno en línea, se le puede configurar un período de tiempo durante el cual el número de conexiones está limitado y aumenta lentamente. Esto proporciona al servidor un “período de transición” para garantizar que no se sobrecargue debido a un número excesivo de conexiones asignadas justo después del inicio. Este valor se establece en la interfaz de configuración de L7.
Mínimo número de conexiones ponderado (Weighted Least Connection)
Si las capacidades de recursos de los servidores son diferentes, el método de “mínimo número de conexiones ponderado” es más adecuado: el número de conexiones activas, determinado por los pesos personalizados por el administrador según las condiciones del servidor, generalmente proporciona una utilización muy equilibrada del servidor, porque combina las ventajas tanto del mínimo número de conexiones como de los pesos. Por lo general, es una forma de distribución muy justa, ya que utiliza la proporción entre el número de conexiones y el peso del servidor; el servidor con la proporción más baja en el clúster recibe automáticamente la siguiente solicitud. Sin embargo, tenga en cuenta que, al usar este método en situaciones de bajo tráfico, consulte las advertencias del método de “mínimo número de conexiones”.
Equilibrio de carga adaptativo basado en agente (Agent Based Adaptive Balancing)
Además de los métodos anteriores, el host de equilibrio de carga incluye una lógica adaptativa para monitorear periódicamente el estado de los servidores y los pesos de estos servidores. Para el potente método de “equilibrio de carga adaptativo basado en agente”, el host de equilibrio de carga detecta periódicamente la carga de todos los servidores de la siguiente manera: cada servidor debe proporcionar un archivo de inclusión que contiene un número del 0 al 99 para indicar la carga real de ese servidor (0 = vacío, 99 = sobrecargado, 101 = fallido, 102 = deshabilitado por el administrador), y el servidor obtiene este archivo mediante el método HTTP GET; al mismo tiempo, para los servidores del clúster, proporcionar su propia carga en forma de archivo binario es también una de las tareas de ese servidor; sin embargo, no hay restricción sobre cómo el servidor calcula su propia carga. Según la carga general de los servidores, se pueden elegir dos estrategias: en operaciones normales, el algoritmo de programación calcula una proporción de peso utilizando la proporción entre el valor de carga recopilado del servidor y la cantidad de conexiones asignadas a ese servidor. Por lo tanto, si un servidor está demasiado cargado, el peso se reajustará de manera transparente por el sistema. Al igual que con el método de programación Round Robin ponderado, las asignaciones incorrectas pueden registrarse para poder asignar eficazmente diferentes pesos a diferentes servidores. Sin embargo, en entornos de tráfico muy bajo, los valores de carga informados por los servidores no pueden establecer una muestra representativa; asignar carga basándose en estos valores provocaría pérdida de control y oscilaciones de instrucciones. Por lo tanto, en este caso, es más razonable calcular la asignación de carga basándose en una proporción de peso estática. Cuando la carga de todos los servidores está por debajo del límite inferior definido por el administrador, el host de equilibrio de carga cambia automáticamente al modo Round Robin ponderado para distribuir las solicitudes; si la carga es mayor que el límite inferior definido por el administrador, el host de equilibrio de carga vuelve al modo adaptativo.
Peso fijo (Fixed Weighted)
El peso más alto solo se usa cuando los valores de peso de los demás servidores son muy bajos. Sin embargo, si el servidor con el peso más alto se cae, el servidor con la siguiente prioridad más alta atenderá al cliente. En este modo, el peso de cada servidor real debe configurarse según la prioridad del servidor.
Respuesta ponderada (Weighted Response)
La programación del tráfico se realiza mediante el método Round Robin ponderado. Los pesos utilizados en el Round Robin ponderado se calculan según el tiempo de respuesta de las comprobaciones de disponibilidad del servidor. Cada comprobación de disponibilidad se cronometra para marcar cuánto tiempo tardó en responder con éxito. Sin embargo, hay que tener en cuenta que este método asume que la detección por latido del servidor se basa en la velocidad de la máquina, pero esta suposición no siempre se cumple. Se suman los tiempos de respuesta de todos los servidores en el servicio virtual, y con este valor se calcula el peso de cada servidor físico individual; este peso se calcula aproximadamente cada 15 segundos.
Hash de IP de origen (Source IP Hash)
Este método genera un valor hash de la IP de origen de la solicitud y utiliza este valor hash para encontrar el servidor real correcto. Esto significa que para un mismo host, el servidor correspondiente siempre es el mismo. Con este método, no es necesario guardar ninguna IP de origen. Sin embargo, hay que tener en cuenta que este método puede provocar un desequilibrio de carga en los servidores.
Fuente: http://www.codeceo.com/article/balanced-algorithm.html