Equilibrio de carga 101: componentes básicos

En el dinámico mercado actual, centrado en las aplicaciones, las organizaciones están sometidas a una presión cada vez mayor para ofrecer la información, los servicios y las experiencias que esperan sus clientes, y además de forma rápida, fiable y segura. Las funciones clave de la red y de las aplicaciones, como el equilibrio de carga, la encriptación, la aceleración y la seguridad, pueden proporcionarse a través de los controladores de entrega de aplicaciones (ADC), que son dispositivos físicos o virtuales que funcionan como proxies para los servidores físicos. Con la explosión de las aplicaciones, así como las exigencias impuestas a las organizaciones por el riguroso ciclo de Integración continua y Entrega continua (CI/CD), no es de extrañar que se prevea que el mercado de los ADC alcance los 2900 millones de dólares anuales en 2020.¹

Pero antes de adentrarnos en el futuro, vamos a ver cómo hemos llegado hasta aquí. El equilibrio de carga basado en la red es la base fundamental sobre la que funcionan los ADC. A mediados de la década de 1990, los primeros dispositivos de hardware de equilibrio de carga comenzaron a ayudar a las organizaciones a escalar sus aplicaciones distribuyendo las cargas de trabajo entre los servidores y las redes. Estos primeros dispositivos eran neutrales con respecto a las aplicaciones y estaban ubicados fuera de los propios servidores de aplicaciones, lo que significaba que podían equilibrar la carga utilizando técnicas de red sencillas. Básicamente, estos dispositivos presentaban una «dirección IP virtual» al mundo exterior, y cuando los usuarios intentaban conectarse, reenviaban la conexión al servidor real más apropiado realizando una traducción bidireccional de direcciones de red (NAT).

Sin embargo, con la llegada de la virtualización y la informática en la nube, una nueva iteración de ADC de equilibrio de carga llegó como ediciones virtuales suministradas por software y destinadas a ejecutarse en hipervisores. En la actualidad, los dispositivos virtuales pueden ofrecer servicios de aplicaciones con la misma amplitud de funciones que los que se ejecutan en hardware específico. Además, estas ediciones virtuales eliminan gran parte de la complejidad que supone trasladar los servicios de aplicaciones entre entornos virtuales, de nube e híbridos, lo que permite a las organizaciones poner en marcha de forma rápida y sencilla servicios de aplicaciones en entornos de nube privada o pública.

La última tendencia que ha llegado al centro de datos es la contenedorización, que es un método de virtualización de aplicaciones que ayuda a implementar y ejecutar aplicaciones distribuidas. El proceso aísla las aplicaciones y las contiene en espacios de memoria claramente delimitados en un sistema operativo compartido, lo que no solo hace que el desarrollo y la implementación de una aplicación sean más fáciles que la construcción de un dispositivo virtual, sino que también hace que sean más rápidos. Gracias a las espectaculares mejoras en la portabilidad y el rendimiento, la contenedorización podría proporcionar a las empresas una mayor escalabilidad y agilidad. En el futuro, las arquitecturas de contenedores también podrían ayudar a las organizaciones a aprovechar mejor los diferentes entornos de la nube.

Los ADC actuales evolucionaron desde los primeros equilibradores de carga mediante el proceso de virtualización de servicios. Y ahora, con las ediciones virtuales únicamente por software, los ADC no solo pueden mejorar la disponibilidad, sino también ayudar a las organizaciones a ofrecer las aplicaciones escalables, de alto rendimiento y seguras que su negocio requiere. Al final, sin embargo, todos estos servicios de aplicaciones virtualizados, implementaciones de infraestructura compartida y capacidades de enrutamiento inteligente no serían posibles sin la sólida base de la tecnología de equilibrio de carga.

Para entender cómo pueden las empresas afrontar mejor los complejos retos que presenta este mercado de evolución dinámica, vamos a ver en detalle los fundamentos de la entrega de aplicaciones: Equilibrio de carga 101.

Antes de empezar, repasemos la terminología básica del equilibrio de carga. Sería más sencillo si todo el mundo utilizara el mismo léxico; por desgracia, cada proveedor de dispositivos de equilibrio de carga (y, a su vez, de ADC) parece utilizar una terminología diferente. No obstante, con unas pocas explicaciones, se puede evitar la confusión.

La mayoría de los ADC de equilibrio de carga utilizan los conceptos de nodo, host, miembro o servidor; algunos utilizan los cuatro, pero significan cosas diferentes. Hay dos conceptos básicos que todos estos términos tratan de expresar. Un concepto (normalmente llamado nodo o servidor) es el de la idea del propio servidor físico o virtual que recibirá el tráfico del ADC. Es sinónimo de la dirección IP del servidor físico y, en ausencia de un equilibrador de carga, sería la dirección IP a la que se convertiría el nombre del servidor (por ejemplo, www.example.com). A partir de ahora en este documento, nos referiremos a este concepto como el host.

El segundo concepto se expresa con el término «miembro» (lamentablemente también llamado nodo por algunos fabricantes). Un miembro suele estar un poco más definido que un host, ya que incluye el puerto TCP de la aplicación real que recibirá el tráfico. Por ejemplo, un host llamado www.example.com puede convertirse en una dirección de 172.16.1.10, que representa el host, y puede tener una aplicación (un servidor web) que se ejecuta en el puerto TCP 80, haciendo que la dirección del miembro sea 172.16.1.10:80. En pocas palabras, el miembro incluye la definición del puerto de la aplicación así como la dirección IP del servidor físico/virtual. A partir de ahora en este documento, nos referiremos a esto como el servicio.

¿Por qué toda esta complejidad? Porque la distinción entre un servidor y los servicios de aplicación que se ejecutan en él permite que el equilibrador de carga interactúe individualmente con las aplicaciones y no con el hardware o el hipervisor subyacente, en un centro de datos o en la nube. Un host (172.16.1.10) puede tener más de un servicio disponible (HTTP, FTP, DNS, etc.). Al definir cada aplicación de forma única (172.16.1.10:80, 172.16.1.10:21 y 172.16.1.10:53, por ejemplo), el ADC puede aplicar un equilibrio de carga y una supervisión del estado únicos (un concepto del que hablaremos más adelante) basados en los servicios en lugar del host.

Recuerde que la mayoría de la tecnología basada en el equilibrio de carga utiliza un término para representar el host, o servidor físico, y otro para representar los servicios disponibles en él; en este caso, simplemente host y servicios.

El equilibrio de carga permite a las organizaciones distribuir el tráfico entrante de las aplicaciones a través de múltiples destinos de back-end, incluyendo implementaciones en nubes públicas o privadas. Por lo tanto, es necesario disponer del concepto de una colección de destinos de back-end. Los clústeres, como los denominaremos (también se conocen como grupos o granjas), son colecciones de servicios similares disponibles en cualquier número de hosts. Por ejemplo, todos los servicios que ofrecen la página web de la empresa se reunirían en un clúster llamado «página web de la empresa» y todos los servicios que ofrecen servicios de comercio electrónico se reunirían en un clúster llamado «comercio electrónico».

Un servidor virtual es un proxy del servidor real (físico, virtual o contenedor). Combinado con una dirección IP virtual, es el punto final de la aplicación que se presenta al mundo exterior.

Entendiendo estos términos, se conocen los fundamentos del equilibrio de carga. El ADC de equilibrio de carga presenta servidores virtuales al mundo exterior. Cada servidor virtual apunta a un clúster de servicios que residen en uno o más hosts físicos.

Aunque la Figura 2 puede no ser representativa de ninguna implementación del mundo real, proporciona la estructura elemental para continuar con el tema sobre el proceso de equilibrio de carga y la entrega de aplicaciones.

Una vez establecido este vocabulario común, examinemos la transacción sencilla de entrega de la aplicación al cliente. Como se ha descrito, el ADC de equilibrio de carga normalmente se situará en línea entre el cliente y los hosts que proporcionan los servicios que el cliente quiere utilizar. Como con la mayoría de las cosas en la entrega de aplicaciones, este posicionamiento no es una regla, sino más bien una práctica recomendada en cualquier tipo de implementación. Supongamos también que el ADC ya está configurado con un servidor virtual que apunta a un clúster formado por dos puntos de servicio. En este escenario de implementación, es común que los hosts tengan una ruta de retorno que apunte de nuevo al equilibrador de carga para que el tráfico de retorno se procese a través de él en su camino de vuelta al cliente.

La operación básica de entrega de aplicaciones es la siguiente:

• El cliente trata de conectarse con el servicio.
• El ADC acepta la conexión y, después de decidir qué host debe recibir la conexión, cambia la IP de destino (y posiblemente el puerto) para que coincida con el servicio del host seleccionado (tenga en cuenta que la IP de origen del cliente permanece inalterada).
• El host acepta la conexión y responde a la fuente original, el cliente, a través de la ruta predeterminada, el ADC.
• El ADC intercepta el paquete de retorno del host y ahora cambia la IP de origen (y el posible puerto) para que coincida con la IP y el puerto del servidor virtual, y reenvía el paquete de vuelta al cliente.
• El cliente recibe el paquete de retorno, creyendo que proviene del servidor virtual, y continúa el proceso.

Este ejemplo tan básico es relativamente sencillo, pero hay un par de elementos clave a tener en cuenta. En primer lugar, por lo que el cliente sabe, envía paquetes al servidor virtual y el servidor virtual responde, así de simple. En segundo lugar, existe la NAT. Aquí es donde el ADC sustituye la IP de destino enviada por el cliente (del servidor virtual) por la IP de destino del host al que ha elegido equilibrar la carga de la solicitud. La tercera parte de este proceso es la que hace que la NAT sea «bidireccional». La IP de origen del paquete de retorno del host será la IP del host; si esta dirección no se cambiara y el paquete fuera simplemente reenviado al cliente, éste estaría recibiendo un paquete de alguien a quien no solicitó nada y, simplemente, lo descartaría. En cambio, el equilibrador de carga, al recordar la conexión, reescribe el paquete para que la IP de origen sea la del servidor virtual, resolviendo así este problema.

Normalmente, en este punto surgen dos preguntas: ¿Cómo decide el ADC de equilibrio de carga a qué host enviar la conexión? y ¿Qué ocurre si el host seleccionado no funciona?

Vamos a discutir primero la segunda pregunta. ¿Qué ocurre si el host seleccionado no funciona? La respuesta más sencilla es que no responde a la solicitud del cliente y el intento de conexión acaba por agotarse y fallar. Obviamente, este no es el caso ideal, ya que no garantiza una alta disponibilidad. Por eso la mayoría de la tecnología de equilibrio de carga incluye algún nivel de supervisión de estado para determinar si un host está realmente disponible antes de intentar enviarle conexiones.

Existen varios niveles de supervisión del estado, cada uno con mayor granularidad y enfoque. Un supervisor básico simplemente haría un ping al propio host. Si el host no responde al ping, es de suponer que cualquier servicio determinado en el host esté probablemente caído y debería ser eliminado del grupo de servicios disponibles. Desafortunadamente, incluso aunque el host responda al ping, esto no significa necesariamente que el servicio en sí se encuentre funcionando. Por lo tanto, la mayoría de los dispositivos pueden hacer «pings de servicio» de algún tipo, que van desde simples conexiones TCP hasta la interacción con la aplicación a través de un script o una interacción inteligente. Estos supervisores de estado de alto nivel no solo proporcionan una mayor confianza en la disponibilidad de los servicios reales (en contraposición al host), sino que también permiten al equilibrador de carga diferenciar entre múltiples servicios en un único host. El equilibrador de carga entiende que mientras un servicio puede no estar disponible, otros servicios del mismo host pueden estar funcionando correctamente y deben seguir siendo considerados como destinos válidos para el tráfico de usuarios.

Esto nos lleva a la primera pregunta: ¿Cómo decide el ADC a qué host enviar una solicitud de conexión? Cada servidor virtual tiene un grupo específico de servicios (con una lista de hosts que ofrecen ese servicio) que conforma la lista de posibilidades. Además, la supervisión del estado modifica esa lista creando una lista de hosts «actualmente disponibles» que proporcionan el servicio indicado. Es de esta lista modificada de donde el ADC selecciona el host que recibirá una nueva conexión. La decisión sobre el host concreto depende del algoritmo de equilibrio de carga asociado a ese clúster en particular. Algunos de estos algoritmos incluyen el de menos conexiones, el de proporción dinámica y un simple round robin en el que el equilibrador de carga básicamente va bajando por la lista empezando por la parte de arriba y asigna cada nueva conexión al siguiente host; cuando llega al final de la lista, vuelve a empezar de nuevo por el principio. Aunque esto es muy simple y predecible, asume que todas las conexiones tendrán una carga y duración similares en el host de back-end, lo que no siempre es cierto. Los algoritmos más avanzados utilizan cosas como el recuento de conexiones actuales, la utilización del host e incluso los tiempos de respuesta del mundo real para el tráfico existente en el host con el fin de elegir el host más apropiado de los servicios de clúster disponibles.

Los sistemas de entrega de aplicaciones suficientemente avanzados también podrán sintetizar la información de supervisión del estado con los algoritmos de equilibrio de carga para incluir el conocimiento de la dependencia de los servicios. Esto resulta útil sobre todo en los casos en los que un único host tiene múltiples servicios, todos ellos necesarios para completar la solicitud del usuario. En este caso, no es necesario que el usuario vaya al host que tenga un servicio operativo pero no el otro. En otras palabras, si un servicio falla en el host, también es deseable que el otro servicio del host sea eliminado de la lista de servicios disponibles del clúster. Esta funcionalidad es cada vez más importante a medida que los servicios se diferencian más con HTML y scripts.

La parte del equilibrio de carga que implica la elección de un servicio disponible cuando un cliente inicia una solicitud de transacción representa únicamente la mitad de la solución. Una vez establecida la conexión, el ADC debe hacer un seguimiento para ver si el siguiente tráfico de ese usuario necesita equilibrio de carga. En general, existen dos problemas específicos en la gestión del tráfico una vez que se ha equilibrado la carga: el mantenimiento de la conexión y la persistencia.

Si el usuario está intentando utilizar una conexión TCP de larga duración (Puerto 21: FTP, Puerto 23: Telnet, u otro) que no se cierra inmediatamente, el equilibrador de carga debe asegurarse de que no se realice el equilibrio de carga para los múltiples paquetes de datos transportados a través de esa conexión a otros hosts de servicio disponibles. Este es el mantenimiento de la conexión y requiere dos capacidades clave. La primera es la capacidad de mantener un seguimiento de las conexiones abiertas y del servicio de host al que pertenecen. En segundo lugar, el equilibrador de carga debe ser capaz de continuar con la supervisión de esa conexión para que la tabla de conexiones pueda actualizarse cuando la conexión se cierre. Esto es algo bastante estándar para la mayoría de los ADC.

Sin embargo, cada vez es más común que el cliente utilice múltiples conexiones TCP de corta duración (por ejemplo, el puerto 80: HTTP) para realizar una sola tarea. En algunos casos, como la navegación web estándar, no importa y cada nueva solicitud puede ir a cualquiera de los hosts de servicios back-end; sin embargo, hay muchos casos (XML, comercio electrónico, etc.) en los que es extremadamente importante que múltiples conexiones del mismo usuario vayan al mismo host de servicios back-end y no se equilibren las cargas. Este concepto se llama persistencia o afinidad de servidores.

Existen varias maneras de abordar esto, dependiendo del protocolo y de los resultados que se deseen conseguir. Por ejemplo, en las transacciones HTTP modernas, el servidor puede especificar una conexión «keep-alive», que convierte esas múltiples conexiones de corta duración en una única conexión de larga duración, que se puede gestionar igual que el resto de conexiones de larga duración. Sin embargo, esto solo proporciona un poco de alivio, sobre todo porque, a medida que aumenta el uso de los servicios web y móviles, mantener todas las conexiones abiertas más tiempo del necesario sobrecarga los recursos de todo el sistema. Por eso, hoy en día (en aras de la escalabilidad y la portabilidad) muchas organizaciones se están orientando hacia la creación de aplicaciones sin estado que dependen de las API. Esto significa, básicamente, que el servidor se olvida de toda la información de la sesión para reducir la carga de los recursos y, en estos casos, el estado se mantiene mediante ID de sesión, así como mediante el concepto de persistencia.

Una de las formas más básicas de persistencia es la afinidad de dirección de origen, que implica simplemente registrar la dirección IP de origen de las solicitudes entrantes y el host de servicio al que fueron equilibradas, y hacer que todas las transacciones futuras vayan al mismo host. Dos formas de conseguirlo son el uso de ID de sesión SSL y las cookies. La persistencia SSL rastrea la sesión SSL utilizando los ID de sesión SSL, lo que significa que incluso cuando la dirección IP del cliente cambia, el equilibrador de carga reconoce que la sesión es persistente basándose en el ID de sesión. La persistencia basada en cookies ofrece la opción de insertar una cookie en el ordenador del cliente para identificar de forma exclusiva una sesión y, a continuación, hacer referencia a esa cookie en las solicitudes, de forma que la conexión vaya al servidor correcto.

Hoy en día, la inteligencia de los ADC permite a las organizaciones abrir los paquetes de datos y crear tablas de persistencia en ellos para prácticamente cualquier cosa. Esto les permite utilizar información única, como el nombre de usuario, para mantener la persistencia. Sin embargo, las organizaciones deben asegurarse de que esta información identificable del cliente esté presente en todas las solicitudes que se realicen, ya que cualquier paquete que no la tenga no contará con persistencia y se volverá a equilibrar la carga, probablemente rompiendo la aplicación.

Al principio, el equilibrio de carga se centraba en distribuir las cargas de trabajo por la red y garantizar la disponibilidad de las aplicaciones y los servicios. Sin embargo, a medida que la tecnología ha ido evolucionando, los equilibradores de carga se han convertido en plataformas para la entrega de aplicaciones, asegurando que las aplicaciones críticas de una organización estén altamente disponibles y seguras. Aunque el equilibrio de carga básico sigue siendo la esencia de la entrega de aplicaciones, los ADC modernos ofrecen una funcionalidad mucho mejor.

Las empresas se dan cuenta de que el simple hecho de poder acceder a una aplicación no la hace utilizable, y las aplicaciones inutilizables suponen una pérdida de tiempo y dinero para la organización que las implementa. Ahí es donde entra en juego el ADC moderno, que permite a las organizaciones consolidar los servicios basados en la red, como la descarga de SSL/TLS, el almacenamiento en caché, la compresión, la conformación de la velocidad, la detección de intrusiones, los cortafuegos de aplicaciones e incluso el acceso remoto, en un único punto estratégico que puede compartirse y reutilizarse en todos los servicios de aplicaciones y todos los hosts para crear una red de entrega de aplicaciones virtualizada. Esto permite a los equipos de redes, aplicaciones y operaciones responder mejor a las demandas del negocio para acortar los plazos de entrega y aumentar la escalabilidad, sin sacrificar en ningún momento la necesidad de seguridad.

Si desea saber más sobre el funcionamiento de la entrega avanzada de aplicaciones y el futuro de los ADC, lea La evolución de los controladores de entrega de aplicaciones y No se quede en el viejo y sencillo equilibrio de carga.