El balanceo de carga, que realiza un balanceador, es un mecanismo que permite repartir el consumo de recursos de cpu, red, almacenamiento, … para poder atender un servicio determinado sin las limitaciones que ofrecería un único dispositivo. Un ejemplo típico, es el tráfico web que recibe una determinada URL, y que puede llegar a saturar los recursos disponibles en una sola máquina. Si en lugar de ofrecer ese servicio web desde una sola máquina, lo hacemos repartiendo el tráfico y la carga entre varios servidores, seguro que la capacidad de ese servicio puede crecer hasta límites mucho mayores. En eso consiste el balancear la carga, repartir el tráfico o el procesamiento entre varios servidores para poder atender más peticiones, reducir los tiempos de respuesta, …

Por tanto, balancear la carga nos permite ofrecer un servicio con una mejor disponibilidad y permite crecer atendiendo una mayor demanda de peticiones.

Tipos de balanceo de carga

Pero, antes de entrar en detalle, vamos a clasificar distintos tipos de balanceos de carga en base a su función determinada:

  • Balanceo de tráfico web: es uno de los casos más habituales, basado en el ejemplo anterior, donde recibimos una determinada cantidad de tráfico (por ejemplo tráfico web), y que repartimos entre varios servidores web (basado en Apache o Nginx por ejemplo) para poder atender muchas más visitas de las que podría soportar un único servidor, aunque pudiéramos aumentarle los recursos al máximo. Esto último se conoce como escalado vertical, es decir aumentar al máximo los recursos de una máquina por ejemplo en CPU y RAM, a diferencia del escalado horizontal donde se añaden nuevos servidores cuando se necesita crecer ese sistema para atender más peticiones HTTP.
  • Balanceo de bases de datos: a nivel de bases de datos, también hay soluciones que permiten balancear las peticiones entre varios servidores diferentes. En MySQL, hay varias soluciones dependiendo de si se necesita un entorno multi-master o con varios nodos de solo lectura, por ejemplo Galera Clúster o MySQL Clúster son varias de las opciones más recomendables. En SQLServer se puede hacer uso de AlwaysOn para repartir peticiones de lectura desde las versiones 2014/2016. En Oracle database también se puede conseguir un balanceo de la carga utilizando Oracle RAC.
  • Balancear comunicaciones: hay situaciones donde tenemos por ejemplo, varias líneas de comunicaciones que nos permiten tener conectividad hacia un determinado destino, que puede ser Internet o puede ser conectividad por ejemplo hacia otra sede o hacia una plataforma de Cloud (GCP, Azure, …). Al tener varios canales de comunicaciones, necesitamos un dispositivo que se encargue de repartir este tráfico entre esos enlaces, de forma activa/activa repartiendo la carga en base a algún patrón predefinido (% del tráfico, por IPs destino, por tipo de tráfico, …) o también se puede utilizar como solución activa/pasiva para proporcionar alta disponibilidad en caso de caída del enlace principal. Esto puede ser realizado mediante el balanceo de carga en Linux que proporciona el propio sistema operativo.
Esquema de balanceo de carga en varios frontales.

Tipo de balanceadores de carga

En cada uno de los distintos escenarios de balanceo de carga que hemos descrito anteriormente, necesitamos un dispositivo que realice esta función, habitualmente distribuyendo sesiones TCP entre los distintos servidores disponibles. Hay distintos equipos, hardware o software, que pueden realizar la tarea de distribuir la carga cuando se requiere un servicio de balanceo, estos son algunos de ellos:

  • Dispositivo específico de balanceo: existen varios fabricantes de dispositivos cuya funcionalidad principal es realizar balanceo de tráfico en base a la configuración definida. Hasta hace unos años estos equipos solían ser siempre físicos, pero en los últimos años se ha extendido cada vez más el formato virtual que puede ser desplegado en entornos de virtualización OnPremise como VMWare o HyperV, o en entornos de Cloud públicos como Google Cloud, AWS o Azure. Entre estos equipos podríamos destacar a fabricantes como F5 con sus equipos Big-IP o Radware Alteon.
  • Dispositivos de red con funcionalidad extra de balanceo: también existen dispositivos de red cuya funcionalidad principal no es el balanceo, como un Firewall, un router, o similares pero que incluyen funcionalidad para hacer balanceo de carga. Evidentemente no ofrecen las prestaciones que un dispositivo dedicado, pero en muchas situaciones puede ser suficiente. Como ejemplo muy extendido, destacan los Firewall Fortigate que tienen un módulo de balanceo entre muchas otras funcionalidades, o también pequeños routers como los Mikrotik.
  • Balanceo por software en Linux: dependiendo del tipo de balanceo que se necesite, hay varias opciones para balancear tráfico o peticiones con Linux. Una de ellas es mediante Linux Advanced Routing and Traffic Control con el que puedes balancear tráfico por diferentes enlaces físicos en Linux. Si lo que se requiere es balancear peticiones TCP sobre varios servidores, una de las opciones principales es LVS que ofrece funcionalidad similar a un dispositivos específico de balanceo, mediante su implementación a nivel de kernel.
  • Balanceo por software en Windows: estos sistemas no tienen sistemas tan específicos y funcionales para temas de red en general, pero tienen una implementación de balanceo por software mediante NLB: Network Load Balancing.
TE PUEDE INTERESAR:

Configuración de balanceo de carga

Balanceo de carga

¿En qué consiste la configuración de un balanceo de carga? Hay varios aspectos que hay que tener en cuenta a la hora de realizar la configuración de un balanceador clásico para balancear conexiones TCP o UDP:

  • Creación de la VIP de servicio: habitualmente, se define una dirección IP que es la que ofrece el servicio balanceado. Esta IP es a la que se conectarán los clientes, y cuyas conexiones se balancearán posteriormente sobre cada uno de los frontales disponibles. Hay que definir el puerto o los puertos sobre los que esta VIP ofrecerá este servicio, habitualmente se utilizará el puerto 80 (HTTP) o el 443 (HTTPS) para servicios tradicionales, aunque por supuesto se puede utilizar cualquier otro puerto.
  • Creación de los frontales donde balancear el servicio: hay que configurar cuáles son los servidores donde se balancearán las peticiones, también llamados real. Y en cada uno de ellos definir en qué puerto ofrecen este servicio, que puede ser el mismo que en la VIP o puede ser uno distinto porque ya estén en uso. Esta definición de frontales en un servicio balanceado, puede ser estático o dinámico, es decir que los frontales que ofrecen servicio pueden crecer o disminuir en base a sistemas de autoescalado como ofrecen los Cloud públicos.
  • Método de balanceo: hay distintos métodos de balanceo que definen cómo se reparten las sesiones entre cada uno de los frontales. Podemos destacar los siguientes como los más habituales:
    • Robin Round: las peticiones se reparten entre los frontales disponibles de una en una desde el primero hasta el último, de forma circular. De esta forma, todos los frontales recibirán exactamente el mismo número de peticiones, para lo bueno y para lo malo. Si tienes frontales con recursos no homogéneos, es decir que tienen diferente capacidad de CPU o recursos, este método no será el más adecuado, y la consecuencia será unos frontales mucho más cargados que el resto.
    • Weighted Robin Round: igual que el anterior, pero cada servidor tiene un determinado peso en el reparto que indica qué porcentaje de las peticiones se entregarán a cada servidor. Con esto se intenta identificar previamente qué servidores podrán procesar más carga bien porque dispongan de más recursos o estén mejor optimizados para procesar estas peticiones. Lo malo de esta opción es que el reparto que se hace es estático, se define previamente, y no tiene en cuenta el estado del sistema en cada momento.
    • Least Connections: cada petición se balancea al servidor con el menor número de conexiones establecidas en ese preciso momento. De esta forma se intenta que el frontal menos cargado atienda las nuevas peticiones pero solamente en base al número de peticiones, y esto no siempre implica que un frontal esté menos cargado, porque puede haber conexiones que exijan mayor capacidad de procesamiento, memoria u otros recursos que otras similares.
    • IP-Hash: la primera conexión que llega de una determinada dirección IP se balancea al frontal que corresponda (habitualmente por robin round), y se apunta en una tabla esa asignación. Desde ese momento, todas las nuevas conexiones de esa misma IP se balanceará a ese mismo frontal, manteniendo la persistencia por IP origen.
    • Response Time: esto significa repartir las nuevas conexiones entre el o los servidores que menor tiempo de respuesta ofrezcan en cada momento, o sea que es totalmente dinámico y se adapta al estado del entorno. El tiempo de respuesta se suele basar en el puerto que escucha cada uno de los frontales.
  • Persistencia de Sesión: como ya se ha descrito en el apartado anterior, hay algún algoritmo de balanceo que ya incluye persistencia de sesión, es decir, que el destino de unas determinadas sesiones será siempre el mismo frontal. Esto es necesario en algunos aplicativos para su correcto funcionamiento, por ejemplo para procesos de compra donde los frontales a nivel aplicativo no comparten el carrito de la compra o los datos del comprador, y cambiarle de frontal implica perder todo lo realizado hasta ese momento por el usuario. Por tanto, mantener la persistencia, es imprescindible para algunos aplicativos, y esta persistencia puede ser implementada de distintas formas:
  • Detección de servidores inaccesibles: una parte importante de un servicio balanceado es la detección de servidores que dejan de responder en un momento determinado, bien porque tienen una carga excesiva o porque han sufrido algún problema y han caído, por ejemplo. En este caso, el balanceador debe detectar esta situación para no distribuir más peticiones al frontal afectado, y de esta forma permitir la caída de algún frontal sin que el servicio se vea afectado.

Por Byte

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.