Balanceadores de Carga

Cada vez existen más servicios en Internet y la demanda de estos por parte de todos nosotros continúa creciendo. La disponibilidad y la rapidez en la respuesta de un determinado servicio depende de muchos factores, sin embargo uno de ellos es la capacidad y disponibilidad de los servidores finales encargados de procesar la petición y responder con la mayor brevedad posible. Para garantizar la fiabilidad de los servicios a veces es necesario formar cluster de servidores que permitan balancear la carga del servicio utilizando balanceadores de carga dedicados para tal fin. De esta manera por ejemplo ayudaríamos a prevenir el colapso de nuestros servicios ante una gran demanda de solicitudes, evitando titulares como que la web porno de Marc Dorcel se colapsó en 45 segundos.

Aunque ya tenía experiencia en balanceadores F5 y Radware AppDirector, en estos últimos meses he tenido la oportunidad de conocer y profundizar los balanceadores de carga FortiADC y Radware Alteon. El estudio de estos últimos ha sido hasta tal punto que he obtenido la certificación “Radware Certified Application Specialist on Alteon (RCAS-AL)”, acreditando que tengo los conocimientos para instalar y mantener equipos Radware Alteon utilizando la CLI así como la interfaz de usuario GUI, además de conocer los mecanismos de balanceo de protocolos de capa 4 a capa 7, realizar instalaciones y mantener equipos en standalone o en alta disponibilidad mediante VRRP, crear escenarios de SSL Offloading instalando y actualizando certificados SSL, además de poseer los conocimientos para realizar debbuging en los equipos.

Aparte de aprender a utilizar los equipos Alteon desde la CLI y la GUI, creo que lo más interesante que he aprendido es a reforzar mis conocimientos sobre los distintos tipos de diseño de despliegue de equipos balanceadores, independientemente del fabricante que sea. En un breve resumen podemos destacar los siguientes diseños:

Modo Route: Es el escenario más común, para ello la red debe ser segmentada en capa 3 diferenciando el segmento clientes de servidores. El balanceador puede hacer funciones de proxy inverso para securizar las aplicaciones, descargar a los servidores reales del cifrado/descifrado de datos, etc. Para su correcto funcionamiento es indispensable que la puerta de enlace de los servidores reales sea el propio balanceador.

Modo Transparente: En este escenario la red debe ser segmentada en capa 2 diferenciando el segmento de clientes y servidores. Aunque todas la comunicación (ida y vuelta) pase por el balanceador, éste no puede actuar como proxy inverso, sin embargo este diseño no requiere cambiar la puerta de enlace de los servidores, es decir, se puede mantener como puerta de enlace el router.

Modo One-arm: Es un escenario adecuado en entornos de demo ya que no requiere ningún cambio en el diseño de la red original. Para ello el balanceador realiza la función de Proxy IP cambiando la IP origen de las peticiones por la suya propia, es decir NAT en origen, de esta manera los servidores reales le contestan al balanceador sin tener que cambiarles la puerta de enlace. Como inconveniente perdemos la IP origen de las peticiones, aunque se puede subsanar incorporando el atributo x-forwarded-for en la cabecera HTTP.

Modo Direct Server Return (DSR): Es un escenario adecuado en redes de altas exigencias, ya que la respuesta de la petición balanceada no pasa por el balanceador, descargando al balanceador de dicha tarea. No es necesario segmentar la red y el balanceador perderá las funcionalidades de Proxy, ya que no tiene la posibilidad de analizar la comunicación completa entre el cliente y los servidores reales. A continuación podemos ver un ejemplo del despliegue DSR:

 

Además de lo comentado anteriormente, he podido probar en el laboratorio los distintos algoritmos de balanceo (roundrobin, leastconns, response time, bandwidth, etc), persistencia de sesiones (cookie, sslid), balanceo de carga basado en el contenido de la petición (URL, tipo de navegador, etc), además de otros aspectos como técnicas de ofuscación o DoS para proteger los servidores, vDirect para levantar máquinas virtuales bajo demanda, ADC-VX para gestionar balanceadores virtuales o GSLB para balancear servicios basándose en la proximidad del cliente o para balancear servicios entre distintos CPDs.

Y eso es todo amigos.