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

Dimensionamiento de dispositivos Big-IP de F5

Algunos de los puntos más importantes a tener en cuenta en el dimensionameinto de una solución con los dispositivos BIG-IP de F5

Normalmente los dispositivos se dimensionan por un número determinado de parámetros determinados de forma fija por el hardware, pero en el caso de las plataformas BIG-IP, al ser a su vez un cúmulo de módulos que realizan diferentes funciones (hay que recordad que el BIG-IP no solo aporta el servicio de balanceo de su módulo LTM), hay que tener en cuenta los aspectos que se exponen a continuación:

Funcionalidades requeridas

La plataforma Big-IP incluye diferentes funcionalidades que se pueden licenciar, por lo que el primer paso será definir cuáles de estos módulos mejor se adaptan a la solución global que se busca.

1.     BIG-IP Local Traffic Manager (LTM)

Este es el componente básico y más conocido de la solución. Su cometido es realizar las tareas de balanceo de carga convirtiéndose en un full-proxy TCP entre los clientes y servidores.

El balanceo se puede realizar a nivel de aplicación, aunque existe la posibilidad de adquisición de un LTM básico en el cual solo se realiza a nivel TCP.

2.     Edge Gateway

Proporciona accesos remotos mediante la creación de VPNs SSL de usuario, de forma similar a otras soluciones como pueden ser el SSL Secure Access de Juniper.

3.     BIG-IP WAN Optimization Manager (WOM)

Proporciona optimización de WAN de un modo similar a los productos SteelHead de Riverbed, enviado patrones entre los dispositivos y reduciendo las necesidades de interacciones entre los extremos (chatty protrocols) aportando, por ejemplo, grandes mejoras en los tiempos de transmisión en protocolos como CIFS.

4.     BIG-IP Access Policy Manager (APM)

Realiza las tareas de un servidor RADIUS que integre los Servicios AAA (Autenticación, Autorización y Contabilidad) muy utilizadas por despliegues Wireless y otros como puedan ser proyectos de escritorios virtuales.

5.     BIG-IP Application Security Manager (ASM)

Es el firewall de aplicación integrado en el BIG-IP. Aunque aporta una securización muy fuerte contra todo tipo de ataques que los firewall tradicionales no son capaces de interceptar, su configuración y gestión puede llegar a ser bastante costoso si los servicios protegidos son bastante dinámicos, como puedan ser páginas web en continuo desarrollo.

6.     BIG-IP WebAccelerator (WBA)

Gracias al Offload de las tareas de encriptación, el caché, o la compresión de paquetes, se consigue la aceleración de prestación de páginas WEB y un consumo menor de ancho de banda.

7.     BIG-IP Link Controller (LC)

Este módulo, que también puede conseguirse como un producto a parte, controla los flujos de tráfico hacia las diferentes líneas externas de los proveedores ISP contratados dependiendo de diversos parámetros, como puedan ser errores o velocidad de acceso.

También tiene la capacidad de realizar compresión de la transmisión para minimizar el consumo de ancho de banda.

8.     BIG-IP Global Traffic Manager (GTM)

Realiza un balanceo selectivo entre Data Centers, lo que permite disminuir las interrupciones de servicio y mejora los tiempos de respuesta del servicio.

Este balanceo es posible gracias a la gestión de las entradas DNS asociadas a los diferentes servicios alojados simultáneamente en los diversos Data Centers.

           

Virtualización

Pueden surgir dos tipos de necesidades de virtualización de la plataforma que también influirán en los modelos finalmente adoptados:

1.     Conversión del BIG-IP en una máquina virtual.

Se puede disponer del BIG-IP en forma de Virtual Appliance, bajo el nombre de Virtual Edition. Hay que tener en cuenta que la elección de este despliegue condiciona mucho tanto las funcionalidades posibles como el rendimiento que se conseguirá con él.

2.     Virtualización del hardware BIG-IP, posibilitando varias instancias en un mismo dispositivo.

Existen ocasiones e las que es necesario virtualiza un hardware y correr sobre él varias instancias del Sistema Operativo, como por ejemplo hacen los Firewalls ASA de Cisco con los denominados “Contextos”. Esa necesidad viene dada principalmente por el requisito de una división lógica de la gestión y de recursos hardware (Multitenance).

La única gama de BIG-IP que permite esto son los productos Viprion. Los Viprion permiten dos grados de virtualización:

·         Particiones: En las que se separa la gestión pero no se puede hacer reserva de recursos.

·         Instancias: También llamadas vCMP. Permiten restringir la utilización de RAM y CPU a la vez que proporcionan el aislamiento de gestión.

Compatibilidad entre módulos

Una vez determinados los módulos requeridos, es necesario comprobar que pueden integrarse todos bajo un mismo BIG-IP, ya que cada hardware soporta un número concreto de módulos y, a parte, existen incompatibilidades que hacen que no puedan coexistir ciertos módulos a la vez bajo el mismo BIG-IP

Para aclarar lo anterior se puede consultar el siguiente recurso:

http://support.f5.com/content/dam/f5/kb/global/solutions/sol10288_images.html/BIG-IP_Product_Matrix.pdf

En dicha tabla aparecen las compatibilidades de los módulos con las versiones de firmware y los modelos de hardware, así como la posibilidad de ejecutar varios de ellos a la vez.

Mediante esta tabla se puede comprobar las restricciones de funcionalidades existentes en la edición virtual comentadas en el apartado anterior.

Throughput

Siguiendo las consideraciones de los apartados anteriores se reduce a unos cuantos posibles hardware BIG-IP que cumplen los objetivos marcados. Una vez que se dispone de esa lista de candidatos se ha de comprobar cuales no cumplen los requisitos de throughput.

Los documentos en los que se pueden encontrar los límites de throughput de cada uno de los hardware son los siguientes:

·         BIG-IP: http://www.f5.com/pdf/products/big-ip-platforms-ds.pdf

·         Viprion: http://www.f5.com/pdf/products/viprion-overview-ds.pdf

En estos documentos se exponen diversos elementos para el dimensionamiento del hardware. Para saber cuál aplicar hay que conocer las peculiaridades de los servicios que se encontrarán detrás de la plataforma BIG-IP.

Puede darse el caso que sea necesario balancear una base de datos sea más restrictivo el componente de transacciones SSL por segundo que los requisitos de ancho de banda que ese servicio necesita.

Para cualquier tipo de servicio se ha de tomar como referencia el  “Throughput de tráfico”, mientras que si se requiere realizar Offload de SSL también entrará en consideración las  “Transacciones SSL por segundo (TPS)”. Por último, en el caso de que también se requiera compresión de tráfico, se ha de cumplir el mínimo de “Throughput de tráfico comprimido”

Es necesario tener en cuenta que los documentos señalados antes muestran las especificaciones generales de la gama, pero hay casos en los que dentro de una misma gama existe un producto para soportar servicios específicos que supera alguno de esos límites, como por ejemplo el dispositivo 8600S que dispone de más throughput SSL (pero menos capacidad de compresión) que el indicado en la tabla para la gama 8600.

             

Por último es de utilidad señalar que en ciertos casos en los que es necesario ajustar mucho el hardware a los requisitos marcados,  hay que tener en cuenta que ciertos módulos consumen más recursos que otros y puede que el throughput real logrado sea inferior al mostrado en las tablas. Este punto es muy difícil de definir y no puede ser consultado a título personal en ninguna documentación de F5, por lo que, en caso de duda, hay que contactar con el fabricante para aclarar este punto.

Interfaces físicas

El último punto importante que puede hacer desestimar el modelo elegido es la carencia del número o de los tipos de  interfaces físicas (velocidad, conectores, etc) necesarios para poder integrar el producto en la arquitectura de red existente. Estos datos aparecen también en las tablas que se encuentran en los enlaces del apartado anterior.