HAProxy y conceptos de balanceo de carga: lo básico

Introducción

Proxy de alta disponibilidad (HAProxy), es una solución popular de código abierto de proxy y TCP/HTTP balanceador de carga capaz de ejecutarse en Solaris, FreeBSD, y Linux. Se utiliza más comúnmente para mejorar la confiabilidad y el rendimiento de un entorno de servidores al proporcionar una distribución equilibrada de la carga de trabajo entre múltiples servidores. Este tipo de herramienta se utiliza en muchos entornos de alto perfil como Instagram, GitHub, Twitter e Imgur.

Esta guía le presentará HAProxy, lo familiarizará con la terminología de balanceo de carga y le proporcionará ejemplos de cómo se puede aprovechar para mejorar tanto el rendimiento como la confiabilidad de los entornos de servidores.

Términos esenciales de HAProxy

Antes de entrar en los detalles del balanceo de carga y del proxying, hay algunos términos y conceptos importantes con los que debe familiarizarse. Comenzaremos revisando estos conceptos en las siguientes secciones.

ACL (Lista de Control de Acceso)

Cuando se trata de balanceo de carga, las ACL se utilizan para probar una condición particular y realizar una acción basada en el resultado. Esto ofrece la capacidad de redirigir el tráfico de manera óptima en función de factores como las conexiones de backend y la coincidencia de patrones, entre muchos otros. Aquí hay un ejemplo de ACL en uso:

En este caso, la ACL coincide si la ruta solicitada por el usuario comienza con /blog. Por ejemplo, esta solicitud de coincidencia apuntaría a http://yourdomain.com/blog/blog-entry-1. El Manual de configuración de HAProxy contiene una guía detallada sobre el uso de ACL.

El Backend

Las solicitudes redirigidas son recibidas por un conjunto de servidores denominados backend. Las solicitudes se definen en la sección backend de la configuración de HAProxy. En los términos más básicos, un backend se puede definir por qué algoritmos de balanceo de carga utilizar y una lista de puertos y servidores. Un backend puede consistir en un solo servidor o en múltiples servidores. A medida que se agregan más servidores al backend, aumenta la capacidad de carga potencial, distribuyendo el procesamiento entre múltiples servidores. Si algunos de los servidores backend se desconectan, los demás servirán como respaldo para encargarse del procesamiento de las solicitudes.

Veamos un ejemplo de configuración de dos backends. En este caso, son un blog-backend y un web-backend. Cada uno tiene dos servidores web, escuchando en el puerto 80:

La línea balance roundrobin está destinada a especificar el algoritmo de balanceo de carga. Los detalles se pueden encontrar en la próxima sección Algoritmos para balanceo de carga, mientras que mode http configura el uso de proxy de capa 7. Explicaremos esto en la sección Tipos de balanceo de carga. Además, la opción check después de la directiva de los servidores indica que se activarán comprobaciones de estado en esos servidores backend en particular.

El Frontend

La definición de cómo se redirigen las solicitudes al backend se denomina frontend. Las solicitudes se definen en la sección frontend de la configuración de HAProxy. Están compuestas por ACL, un puerto, un conjunto de direcciones IP y una regla que define qué backends usar según las condiciones de ACL que se cumplan, llamada regla use_backend. Además, también existe una regla default_backend para contemplar cualquier otro caso. La siguiente sección explicará cómo se puede configurar un frontend para varios tipos de tráfico de red.

Tipos de balanceo de carga

Establecidos los componentes básicos utilizados para el balanceo de carga, ahora podemos pasar a los tipos básicos de balanceo de carga.

Sin balanceo de carga

En su forma más rudimentaria, la falta de balanceo de carga se puede ilustrar de la siguiente manera:

En este escenario, un usuario se conecta directamente al servidor web, en yourdomain.com. No hay balanceo de carga. Como solo hay un servidor de base de datos, si este se desconecta, el acceso a la información que contiene queda completamente cortado. Si muchos usuarios intentan conectarse a un único servidor web simultáneamente y este no puede manejar la carga que eso ejerce, todas las conexiones se ralentizarán o fallarán por completo al intentar conectarse.

Balanceo de carga (capa 4)

Una de las formas más sencillas y pragmáticas de balancear el tráfico de red hacia múltiples servidores es mediante el uso de métodos de balanceo de capa de transporte o capa 4. Esta forma de balanceo de carga dirige a cualquier usuario que se conecte en función del rango de IP en el que se encuentra su dirección IP y el puerto. En otras palabras, si http://yourdomain.com/anything es de donde proviene la solicitud, el backend que está definido para manejar estas solicitudes será el que finalmente las maneje. Reenviará esas solicitudes para yourdomain.com en el puerto 80.

La formación básica del balanceo de carga de capa 4 se ve así:

A medida que el usuario obtiene acceso al balanceador de carga, sus solicitudes se reenvían al grupo de servidores web-backend. El servidor backend configurado responderá directamente a la solicitud del usuario. Para evitar que el usuario encuentre datos inconsistentes, todos los servidores web-backend deben ofrecer contenido idéntico. Según el diagrama anterior, ambos servidores web se vinculan en última instancia al mismo servidor de base de datos.

Balanceo de carga (Capa 7)

Existe otro método más complejo para balancear la carga del tráfico de red. Consiste en utilizar el balanceo de carga de nivel 7, o capa de aplicación. Este enfoque permite que las solicitudes de los usuarios se reenvíen a diferentes servidores backend según el contenido de las solicitudes de los usuarios. Este método permite que el balanceo de carga ocurra a través de múltiples servidores de aplicaciones web mediante el mismo puerto y dominio. Para obtener más detalles sobre esta capa, eche un vistazo a la subsección HTTP de nuestro Los detalles de las redes: aprenda sobre terminología, interfaces y protocolos tutorial.

El siguiente diagrama ilustra el balanceo de carga de capa 7:

En este caso, un usuario solicita yourdomain.com/blog, y su solicitud se reenvía al backend del blog. Este es un conjunto de servidores backend asignado específicamente para ejecutar la aplicación del blog. Mientras tanto, otras solicitudes se reenviarán al web-backend. Sin embargo, ambos backends resultan en el acceso al mismo servidor de base de datos.

Un ejemplo de una pequeña parte de la configuración del frontend para el balanceo de carga de capa 7 se vería como los siguientes comandos. Configuran el frontend http para manejar el tráfico entrante a través del puerto 80:

Si la ruta de la solicitud del usuario comienza con /blog, el acl url_blog path_beg /blog coincidirá con la solicitud.

use_backend blog backend if url_blog redirige el tráfico a blog-backend utilizando ACL.

defaut_backen web_backend dirige todos los demás reenvíos de tráfico a web-backend.

Algoritmos para el balanceo de carga

Cuando se realiza el balanceo de carga, es el algoritmo de balanceo de carga el que define qué servidor backend se seleccionará para este propósito. Hay varias opciones de algoritmos ofrecidas por HAProxy. Adicionalmente, es posible asignar un parámetro de peso (weight) a los servidores para manipular con qué frecuencia se selecciona un servidor en contraste con los demás. Simplemente hay demasiados algoritmos disponibles para describirlos todos. Por lo tanto, esta guía solo se centrará en los más comunes. Puede consultar el HAProxy Documentation Converter para ver la lista completa. Los más utilizados incluyen:

• roundrobin: El algoritmo predeterminado que selecciona los servidores por turnos.
• leastconn: El servidor con menos conexiones activas se selecciona automáticamente. Sin embargo, esos servidores dentro del mismo backend deben rotarse de manera round-robin.
• source: El algoritmo elige el servidor basándose en la dirección IP de origen de la solicitud del usuario. Es un método para garantizar que el usuario siempre se conectará al mismo servidor.

Sticky Sessions

Para algunas aplicaciones, es un requisito que los usuarios que se conecten lo hagan vinculándose siempre al mismo servidor. A través de las 'sticky sessions' y utilizando el parámetro appsession en el backend que lo requiera, se puede lograr dicha persistencia.

Procesamiento de verificaciones de estado

HAProxy necesita un método mediante el cual pueda determinar la capacidad de un servidor backend para procesar solicitudes. Esto reemplaza la eliminación de un servidor del backend si se desconecta. Hay una ejecución de 'verificación de estado' predeterminada que intenta establecer una conexión TCP. Lo hace escuchando en la dirección IP y el puerto configurados.

Si la verificación de estado del servidor no se supera, el servidor no puede procesar las solicitudes enviadas. En ese momento, el servidor se deshabilita automáticamente en el backend, y el tráfico ya no se le reenvía hasta que vuelva a estar activo y en funcionamiento (sano). Sin embargo, en ciertos casos, determinar el estado del servidor a través de la verificación de estado predeterminada resulta insuficiente.

Soluciones alternativas

HAProxy podría resultar demasiado sofisticado para sus necesidades particulares. En ese caso, existen un par de buenas alternativas que podrían resultar más eficientes:

• Nginx: Este es un servidor web rápido y confiable que se puede aprovechar para fines de balanceo de carga y proxy. De hecho, Nginx se usa comúnmente en conjunto con HAProxy, el cual utiliza sus capacidades de compresión y almacenamiento en caché.
• Linux Virtual Servers (LVS): Este es un balanceador de carga simple de capa 4 que se incluye en muchos sistemas Linux.

Alta disponibilidad

Hasta ahora, hemos hablado del balanceo de carga de capa 4 y capa 7. Ambos utilizan un balanceador de carga para determinar cuál de los muchos servidores backend se encargará de responder a la solicitud del usuario. Pero es importante tener en cuenta las limitaciones de un balanceador de carga. A saber, que es un punto único de fallo. Esto significa que si se cayera o se sobrecargara con las solicitudes de los usuarios, provocaría un tiempo de inactividad o latencia en el procesamiento de las solicitudes, respectivamente. Sin embargo, una configuración de HA (alta disponibilidad) presenta una infraestructura que carece de un único punto de fallo. Esto evita que se experimenten eventos de inactividad debido a fallos del servidor al introducir redundancia en cada nivel de la arquitectura del sistema. Si bien el balanceador de carga ayudará a facilitar la redundancia del backend, los balanceadores de carga también deben ejercer redundancia.

El siguiente diagrama muestra una forma básica de una configuración de alta disponibilidad:

Esta infraestructura tiene varios balanceadores de carga (uno activo, el resto pasivos) vinculados a una dirección IP estática. Esta dirección IP se puede reasignar a un servidor diferente si la situación lo requiere. La solicitud del usuario viaja a través de la dirección IP externa al balanceador de carga actualmente activo. Si el balanceador de carga está fuera de línea en ese momento, el mecanismo de seguridad detectará su estado, reasignando la dirección IP al servidor o servidores pasivos.

Conclusión

La comprensión fundamental del balanceo de carga y el conocimiento de algunas de las formas en que HAProxy puede satisfacer las necesidades de balanceo de carga de su sistema deberían brindarle una base sólida para comenzar a optimizar la confiabilidad y el rendimiento de sus entornos de servidores actuales. También puede consultar nuestro tutorial Proxy HTTP de Nginx, balanceo de carga, almacenamiento en búfer y almacenamiento en caché: una descripción general para obtener más información sobre las propiedades de balanceo de carga de Nginx.

¡Feliz informática!