Diseños con balanceadores

"Se revisan de modo esquemático los diseños de arquitectura de balanceadores, 
dando una pequeña descripción, así como las ventajas/inconvenientes de cada uno de ellos"

En esta entrada se describen las arquitecturas “estándar” de diseño de infraestructuras de balanceo. Para ello se parte de una topología convencional inicial como la que se muestra a continuación:

Ilustración 1 - Esquema inicial

En este esquema, los clientes se encuentran en redes externas, dándoles acceso a los servidores internos por un router perimetral. En este ejemplo los servidores tendrán configuradas IPs públicas, por lo que el router perimetral no realiza ningún tipo de NAT.

Para los siguientes ejemplos no se tienen en cuenta, por simplificar, los conceptos de HA ni en routers ni en los propios elementos balanceadores.

Para introducir el balanceo en este esquema, se pueden realizar diversos despliegues del balanceador, entre los que se pueden encontrar:

• Routed mode (modo ruteado)
• Bridged mode (modo transparente)
• ONE-ARM
• DSR

A continuación se explican cada uno de ellos, haciendo hincapié en las ventajas e inconvenientes.

Modo ruteado/encaminado (Routed mode)

En este despliegue se introduce el balanceador entre los servidores y el router perimetral, dividiendo la antigua red en dos diferentes.

La parte externa de la red, también llamada red cliente, es la que debiera conservar el direccionamiento público, ya que es a ella a la que acceden los clientes. Por el contrario, los servidores deberán modificar los parámetros de red (IP, máscara, default Gateway) y se les podría asignar un direccionamiento privado. El Default Gateway de los servidores, en este despliegue, suele ser el propio balanceador.

Dependiendo de las necesidades de los servidores, puede ser posible que estos necesiten acceder a las redes externas a través del balanceador, o que los servidores sean accedidos directamente (suponiendo que tuviesen direccionamiento público). En estos casos se debería permitir explícitamente en los balanceadores el encaminamiento de estas peticiones, ya que por norma general, los balanceadores solo reenvían los paquetes destinados a algún servicio balanceado publicado en ellos.

También se debería tener en cuenta que si los servidores con direccionamiento público necesitan acceder a servicios situados tras el balanceador, a parte de la configuración del encaminamiento mencionada antes, se deberá configurar una política de NAT/PAT en el balanceador para que cambie la IP privada del servidor por una pública.

Flujo del tráfico de servicio

1. El cliente realiza la petición a la IP pública de servicio
2. Las peticiones de los clientes llegan al router perimetral y este las encaminaría hacia el balanceador.
3. Este, a su vez, la reenvía a uno de los servidores que tenga configurados en el pool asociado a ese servicio.
4. La petición llega al servidor (conservando la IP de origen), con lo que la respuesta la envía al Default Gateway que tengan configurado, es decir, de vuelta al balanceador.
5. El balanceador modifica la IP de origen para incluir la IP de servicio (IP pública) y la envía hacia su Default Gateway (router perimetral)
6.  La respuesta llega al cliente con IP origen la IP de servicio

Ilustración 2 - Diseño en routed mode

Ventajas

• Es una de las arquitecturas más comunes entre los despliegues.
• Se tiene visibilidad completa de las transacciones balanceadas.
• El balanceador puede ejecutar otros trabajos como la securización de aplicaciones o la externalización del cifrado SSL, descargando a los servidores internos de dicho trabajo

 Inconvenientes

• El balanceador debe ser incluido en el camino de la comunicación, lo cual conlleva que el rendimiento del dispositivo balanceador tiene que ser suficiente para gestionar todo el tráfico que transcurre por él. Esto, en algunos casos, es un problema porque puede que se necesite acceder desde fuera directamente a los servidores internos o que los servidores internos necesiten comunicarse con el exterior, lo que aumenta el throughput que transcurre por los Balanceadores. Además, puede darse el caso de que ese tráfico de los servidores al exterior esté NATeado por los balanceadores, lo que supone mayor necesidad de recursos en estos dispositivos.
• Se necesita desdoblar la red, lo que implica un cambio de dirección IP en los servidores

Modo transparente (Bridge mode)

Este despliegue, al igual que en el “routed mode”, necesita incluir el balanceador entre los servidores y el router pero, a diferencia del anterior, no implica una división del direccionamiento IP de la red. No obstante, es necesario una división lógica entre la parte cliente (conectada al router) y la parte servidor, y esta se suele realizar mediante la configuración de VLANs, de tal manera que cualquier elemento de la VLAN servidor, para comunicarse con alguno de la VLAN cliente, deberá transcurrir por el balanceador.

Aunque esta topología parece sencilla, lo cierto es que para llevarla a cabo se necesitan tener en consideración muchos más factores que en el modo ruteado, ya que normalmente todos los elementos suelen estar duplicados, por exigencias de alta disponibilidad, y existe un alto riesgo de que se produzcan bucles o comportamientos indeseados asociados a conectar las dos VLANs a nivel 2.

Estas problemáticas se ven acentuadas si existe la necesidad de conectividad entre los elementos de la VLAN de servidores con los de la VLAN de clientes (siempre que no se trate del tráfico de servicio publicado en el balanceador). En estos casos, de forma similar a la que sucedía en routed mode, se hace necesario permitir este flujo de tráfico de manera explícita en la mayoría de los casos.

Flujo del tráfico de servicio

1. El cliente realiza la petición a la IP pública de servicio
2. Las peticiones de los clientes llegan al router perimetral y este la envía al balanceador, que es quien conserva la IP de servicio
3. Este, a su vez, la reenvía a uno de los servidores que tenga configurados en el pool asociado a ese servicio. 
4. La petición llega al servidor (conservando la IP de origen), con lo que la respuesta la envía al Default Gateway que tengan configurado, en este caso el router perimetral.
5. Como para alcanzar el router perimetral el tráfico tiene que transcurrir por el balanceador, este se hace cargo de modificar la IP de origen para incluir la IP de servicio, tras lo cual la reenvía al router. 
6. La respuesta llega al cliente con IP origen la IP de servicio

Ilustración 3 - Diseño en bridged mode

Ventajas:

• No necesita redireccionamiento en los servidores

 Inconvenientes

• Posibles problemas con bucles y comportamientos no deseados
• Imposibilidad de funcionalidades avanzadas de tráfico a nivles 4-7 en muchos fabricantes
• Implica que el balanceador sea capaz de manejar toda la comunicación, incluyendo la que no es específica del servicio balanceado, al igual que sucedía en el modo enrutado. Hay que tener en cuenta que el balanceador almacenará las comunicaciones entre las VLAN cliente y servidor en sus tablas de sesiones, lo cual puede implicar que se llegue a la máxima capacidad de estas aunque no exista gran tráfico de servicio.
• Los clientes no pueden estar en la misma red que los servidores

Modo ONE-ARM

Este el primero de los diseños mostrados que no necesita implementar el balanceador entre los servidores y el router de acceso. En su lugar se conectará en la red de servicios mediante un único enlace (o agregado), de ahí el nombre de "one-arm".

Debido a que el balanceado se encuentra instalado en paralelo, tan solo la comunicación balanceada transcurrirá por ellos, con lo que para el dimensionado del balanceador solo tendrá que tener en cuenta dicho throughput. Es probable que en algunos entornos se pueda cubrir un mismo servicio con un balanceador con menor capacidad si se despliega este diseño en lugar del modo ruteado o transparente.

Este esquema tiene un inconveniente que, en muchos casos, es causa de que no pueda desplegarse: no se tiene visibilidad de las IPs de cliente desde los servidores. Esto es debido a que, para garantizar que el tráfico de vuelta de los servidores (las respuestas a las peticiones de los clientes) transcurran por los balanceadores, es necesario realizar un NAT de origen de las peticiones de cliente, con lo que se "oculta" el origen de la petición.

Para solventar este problema, algunos protocolos concretos, pueden hacer uso de funcionalidades propias para no perder la visibilidad del origen de las peticiones, como por ejemplo x-forwarded-for en las peticiones HTTP o se puede configurar PBR en los routers para hacer que el flujo concreto que se quiera tratar pase siempre por el balanceador..

Esta topología es muy conveniente en los despliegues de "demo", ya que no requiere el corte de servicio necesario en los despliegues "in-path", como son el modo ruteado y modo transparente, y no afecta a cualquier comunicación que no sea la balanceada, así como no requiere modificaciones en los servidores.

También se puede hacer uso de este tipo de despliegues en entornos donde existan tráficos, alternativos a los servicios balanceados, muy sensibles a los retardos, o que, por algún motivo, presenten problemas al transcurrir por los balanceadores.

Flujo del tráfico de servicio

1. El cliente realiza la petición a la IP pública de servicio
2. Las peticiones de los clientes llegan al router perimetral y este la envía al balanceador, que es quien conserva la IP de servicio
3. Este, a su vez, la reenvía a uno de los servidores que tenga configurados en el pool asociado a ese servicio, pero modificando la IP de origen, cambiando la del cliente por la suya propia.
4. La petición llega al servidor, con la IP del balanceador como origen, con lo que la respuesta la devuelve al balanceador.
5. El balanceador recibe la respuesta del servidor y modifica la IP de origen para incluir la IP de servicio, y la IP destino, para volver a incluir la IP del cliente que realizó la petición. 
6. La respuesta llega al cliente con IP origen la IP de servicio

Ilustración 4- Diseño en one-arm

Ventajas:

• El balanceador solo gestiona el tráfico balanceado
• La arquitectura de balanceo es totalmente transparente al resto de flujos de tráfico

 Inconvenientes

• Se pierde la visibilidad de la IP de los clientes que realizan las peticiones (si no se utiliza ninguna funcionalidad añadida)

Modo Direct Server Return (DSR)

Este diseño es similar a la arquitectura one-arm, con dos diferencias fundamentales: no se realiza NAT de origen para las IPs de clientes en el balanceador, por lo que se conserva la visibilidad en los servidores, y que las respuestas de los servidores no transcurren por los balanceadores.

Para que esto sea posibles, los servidores deben adoptar como suya la IP de servicio, ya que las respuestas deben conservar la IP de servicio como IP origen. Para ello se configura la IP de servicio como una dirección de loopback y se hace que las respuestas de los servidores se realicen desde esta IP.

El que las respuestas no fluyan por el balanceador hacen que este diseño sea propicio para servicios en los que exista una gran necesidad de throughput en las respuestas en comparación con las peticiones (como FTP), de manera que se puede hacer un dimensionamiento mucho más ajustado del balanceador.

Por contra, al no tener visibilidad de todo el transcurso de la conversación entre los clientes y el servidor en el balanceador, no se pueden realizar muchas de las funcionalidades añadidas (securizaciones, aceleraciones, etc) que los balanceadores ofrecen para capas 4-7.

Flujo del tráfico de servicio

1. El cliente realiza la petición a la IP pública de servicio
2. Las peticiones de los clientes llegan al router perimetral y este la envía al balanceador, que es quien conserva la IP de servicio
3. Este, a su vez, la reenvía a uno de los servidores que tenga configurados en el pool asociado a ese servicio.
4. La petición llega al servidor, con la IP del cliente como origen, con lo que la respuesta la encamina a su Default Gateway.
5. La respuesta llega al cliente con IP origen la IP de servicio

Ilustración 5- Diseño DSR

Ventajas:

• El balanceador solo gestiona las peticiones del tráfico balanceado
• La arquitectura de balanceo es totalmente transparente al resto de flujos de tráfico

 Inconvenientes

• Requiere configuraciones en los servidores (IPs de loopback, etc)
• No permite el tratamiento avanzado de las conexiones por parte del balanceador