Balanceador de Tráfico F5. Principio de la Granja
Introducción a IPv6
8 mayo, 2019
Seguramente ha escuchado sobre grandes compañías que tienen bastas granjas de servidores, para soportar la carga de todos los clientes –por ejemplo web- que realizan consultas. ¿Se ha preguntado por qué muchas veces consultamos una sola dirección IP a pesar de ser muchos servidores? Por ejemplo, Facebook.com responde a la dirección IP 157.240.0.35 pero ¿se imagina la cantidad de servidores que requiere Facebook para atender el total de la demanda?
Una manera de lograr esto es utilizando un balanceador de tráfico; hay quienes consideran esto un servidor, otros lo consideran un equipo de comunicaciones, la verdad es que es un equipo con tantas funciones que depende de las políticas de quienes llevan su administración. Lo importante es que este equipo se antepone a una o varias granjas de servidores, recibe todas las solicitudes de los clientes que desean consultar la granja y decide a cuál host de la granja reenviar la solicitud. Al Cliente A lo envía al Servidor 1, mientras que al Cliente B lo envía al Servidor 2..
Existen varios fabricantes de Balanceadores de Tráfico en el Mercado, y para Octubre de 2015 F5 Networks es el líder de mercado según el Diagrama de Gartner.
Ahora, entendamos mejor los conceptos involucrados en un sistema de Balanceador, empezando desde la Red Interna hacia afuera.
Lo primero que se observa son los Nodos, no son más que el host o la dirección IP donde está alojado uno o más servicios. Mientras que el Pool Member es un valor compuesto por el Nodo –como una dirección IP- más el puerto de capa de transporte por el que escucha uno de los servicios. Un conjunto de Pool Members se asocia a un Pool, y así se define lo que comúnmente llamamos la granja de servidores.
Como se plantea al inicio, el cliente no hace solicitudes a un Pool Member directamente o de manera aleatoria; realiza solicitudes al Balanceador, esta dirección a la que se realizan las solicitudes es una dirección IP en la red externa del equipo, con un puerto igualmente configurado por el administrador para escuchar ese servicio y es eso a lo que se llama Virtual Server. El Virtual Server se asocia a un Pool para formar el sistema completo.
Así todo esto se puede modelar como un árbol en donde, para alcanzar por ejemplo un servicio en los Nodos 10.X.X.198 o 10.X.X.217 que escuchan por los puertos del 16001 al 16003, el cliente sólo debe hacer una solicitud al Virtual Server con IP 10.Y.Y.179 por el puerto 16000, y el F5 se encargará de balancear el tráfico de todos los clientes.
Además podemos configurar el balanceador para monitorear el servicio, y dependiendo de su estado, seguir o no enviándole transacciones; a esto se le llama Health Monitor, y es de gran importancia a la hora de tener falla en alguno de los servidores o de realizar una ventana mantenimiento programada. Los miembros en negro están administrativamente deshabilitados, en rojo están fallando, y en verde están operativos y participando en el balanceo.
¿Bajo qué criterio balancea el tráfico hacia los Miembros? Aquí se introduce la Persistencia y el Método de Balanceo. Si realizas una solicitud de DNS a un servidor esto normalmente es una operación UDP muy simple de una solicitud y una respuesta; más si te encuentras comprando entradas para el teatro esto quizá es una transacción más complicada, requiere autenticación, solicitas una función, reservas asientos, debes pagar la transacción, el recibo de la compra, etc, y evidentemente es indeseable que cada una de las partes de la transacción se balancee a un servidor distinto, lo ideal es que cada cliente sea balanceado pero una vez iniciada la transacción realizar todo el proceso de compra en el mismo servidor.
De esto se encarga la Persistencia, mantiene cada sesión contra el servidor donde fue iniciada dependiendo del algoritmo que deseamos utilizar para nuestra aplicación. Por ejemplo ya que los clientes son muchos y variados, podría ser en función de la dirección IP de Origen, o para el caso de la compra de entradas, podría ser manteniendo la sesión SSL del cliente.
El Método de Balanceo va a determinar cómo se distribuyen las distintas sesiones a los miembros de la granja. El algoritmo para esto lo podemos seleccionar por ahora con un poco de sentido común y existen muchos tipos, para el ejemplo de la transacción de DNS podríamos usar el Round-Robin donde cada transacción se va alternando entre todos los servidores disponibles uno por uno; y para el ejemplo de la compra electrónica podríamos usar el servidor que tenga menos conexiones (Least Connections), ya que no todos los clientes se toman el mismo tiempo para ejecutar sus transacciones.
Esta es la idea general de construir una granja usando un balanceador de tráfico. Son equipos muy poderosos con muchas funciones, y por supuesto hay mucho más de qué hablar en otra oportunidad.
