¿Cómo se hace realmente el equilibrio de carga? La tecnología cambia la vida futura

El concepto de equilibrio de carga es que las tareas o solicitudes se distribuyen en varias computadoras. Por ejemplo, si hago una solicitud HTTP estándar de un cliente para acceder a una aplicación web, se dirige a varios servidores web. Lo que básicamente sucede aquí es que la carga de trabajo de la aplicación se distribuye entre varias computadoras, lo que la hace más escalable. También ayuda a proporcionar redundancia, así que digamos que un servidor falla en un clúster, el equilibrador de carga distribuye la carga entre los servidores restantes. Sin embargo, cuando se produce un error y la solicitud se mueve de un servidor que falla a un servidor funcional, se llama “conmutación por error”.

Cluster es típicamente un conjunto de servidores que ejecutan la misma aplicación y su propósito es doble. Para distribuir la carga en diferentes servidores y proporcionar un mecanismo de redundancia / conmutación por error.

¿Cuáles son los esquemas comunes de equilibrio de carga?

Incluso el esquema de distribución de tareas

También llamado “Round Robin”, aquí las tareas se distribuyen de manera uniforme entre los servidores en un clúster. Aquí cada tarea se distribuye de manera uniforme a un servidor. Funciona básicamente cuando todos los servidores tienen la misma capacidad y todas las tareas necesitan la misma cantidad de esfuerzo. Sin embargo, el problema aquí es que esta metodología no considera que cada tarea podría tener un esfuerzo diferente para ser procesada. Entonces podría tener una situación, donde digamos que todos los servidores tienen 3 tareas: T1, T2 y T3. A primera vista, parece igual, sin embargo, T1, T2 en el servidor 1 necesita más esfuerzo para procesar, que T1, T2 en el servidor 2,3. Entonces, en efecto, el Servidor 1 soporta una carga más pesada aquí, que los Servidores 2 y 3, a pesar de una distribución uniforme.

Equilibrio de carga basado en DNS

Aquí se asegura de que el DNS esté configurado para devolver diferentes direcciones IP, cuando se solicita una dirección IP para su nombre de dominio. Es casi similar al esquema Round Robin, excepto que las computadoras aquí almacenan en caché la dirección IP, y siguen refiriéndose a ella, hasta que se realiza una nueva búsqueda. Sin embargo, no es realmente un enfoque recomendado, y es más recomendable utilizar un software de equilibrador de carga.

Esquema ponderado de distribución de tareas

Como su nombre indica, las tareas aquí se distribuyen en una proporción relativa a otros servidores. Funciona si todos los servidores en un clúster no tienen la misma capacidad. Supongamos que tenemos 3 servidores, y una de las capacidades del servidor es la mitad de los otros dos servidores. Ahora suponga que hay 10 tareas para distribuir entre los servidores. En este caso, tanto el Servidor 1 como el 2 obtendrían 10 tareas, sin embargo, dado que el Servidor 3 tiene solo la mitad de la capacidad, obtendría solo 5 tareas. Entonces, aquí la distribución de tareas se realiza según la capacidad del servidor, en relación con el otro servidor. Sin embargo, esto todavía no considera la capacidad de procesamiento de cada tarea.

Esquema de sesión fija

Hasta ahora en los esquemas de equilibrio de carga anteriores, hemos asumido que cualquier solicitud entrante es independiente de las otras solicitudes. Consideremos una aplicación web Java típica, donde una solicitud llega al servidor 1, y algunos valores se escriben en el estado de sesión. Ahora, el mismo usuario realiza otra solicitud, que se envía al Servidor 2, podría tener un escenario en el que no puede obtener los datos de la sesión, ya que se almacenan en el Servidor 1.

Escenario típico, el usuario inicia sesión, ingresa credenciales, se valida y se lleva a la página de inicio. Ahora, la primera solicitud que realiza el usuario, almacenamos el ID de usuario y la contraseña en una sesión en el Servidor 1, ya que eso sería necesario en toda la aplicación. Ahora, la siguiente solicitud del usuario, digamos para navegar desde la página de inicio a una página de registro, se envía al Servidor 2. Aquí necesitaríamos las credenciales del usuario, que sin embargo se almacenan en un Estado de sesión en el Servidor 1. Por lo tanto, terminamos con un escenario, donde la solicitud no pudo obtener los datos de la sesión.

Esto se puede resolver utilizando el equilibrio de carga de Sticky Session, donde en lugar de distribuir las tareas entre los servidores, distribuimos las sesiones. Básicamente, todas las tareas del mismo usuario en una sesión se envían al mismo servidor para evitar la pérdida de datos. Por ejemplo, si tenemos una aplicación de Carrito de compras, toda la sesión (Inicio de sesión del usuario-> Página de inicio-> Selecciona artículos-> Pagar factura) se distribuirá a un servidor por usuario. Esto a su vez podría resultar en una distribución desigual de la carga de trabajo, ya que algunas sesiones podrían tener más tareas en comparación con otras.

Esquema de distribución de cola de tareas de tamaño par

Esto es similar a la distribución de tareas ponderadas, sin embargo, en lugar de simplemente enrutar todas las tareas a un servidor a la vez, se mantienen en una cola. Entonces, suponiendo que se distribuyan 10 tareas a cada servidor, se mantienen en una cola. Estas colas contienen las tareas que el servidor está procesando o que se procesarán. Cada vez que finaliza una tarea, se elimina de la cola de ese servidor.

Aquí nos aseguramos de que cada cola del servidor tenga la misma cantidad de tareas en progreso. Los servidores con mayor capacidad finalizan las tareas más rápido, asegurando espacio para las tareas restantes. Aquí estamos teniendo en cuenta la capacidad del servidor, así como el esfuerzo necesario para procesar cada tarea. Cualquier tarea nueva se envía al servidor cuya cola tiene menos tareas alineadas. En el caso de que un servidor se sobrecargue, su tamaño de cola se vuelve más grande que las colas de tareas de otros servidores. Y este servidor sobrecargado no tiene ninguna tarea nueva asignada hasta que se borre la cola.