"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"
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
- El cliente realiza la petición a la IP pública de servicio
- Las peticiones de los clientes llegan al router perimetral y este las encaminaría hacia el balanceador.
- Este, a su vez, la reenvía a uno de los servidores que tenga configurados en el pool asociado a ese servicio.
- 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.
- 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)
- 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
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
- El cliente realiza la petición a la IP pública de servicio
- Las peticiones de los clientes llegan al router perimetral y este la envía al balanceador, que es quien conserva la IP de servicio
- Este, a su vez, la reenvía a uno de los servidores que tenga configurados en el pool asociado a ese servicio.
- 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.
- 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.
- 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
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
- El cliente realiza la petición a la IP pública de servicio
- Las peticiones de los clientes llegan al router perimetral y este la envía al balanceador, que es quien conserva la IP de servicio
- 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.
- La petición llega al servidor, con la IP del balanceador como origen, con lo que la respuesta la devuelve al balanceador.
- 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.
- 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
- El cliente realiza la petición a la IP pública de servicio
- Las peticiones de los clientes llegan al router perimetral y este la envía al balanceador, que es quien conserva la IP de servicio
- Este, a su vez, la reenvía a uno de los servidores que tenga configurados en el pool asociado a ese servicio.
- La petición llega al servidor, con la IP del cliente como origen, con lo que la respuesta la encamina a su Default Gateway.
- 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
