Balanceo de carga con LVS (I)

Vamos a continuar con el desarrollo del Sistema de Alta Disponibilidad y Balanceo de Carga que venimos realizando. El último capítulo que se trató fue el de la Alta Disponibilidad con Heartbeat.

LVS (Linux Virtual Server) es un proyecto destinado a implementar balanceadores de carga en sistemas de tipo GNU/Linux. LVS viene a ser un cluster de máquinas que de cara a los clientes aparecen como un único servidor.

Por lo tanto, dentro de la arquitectura que definimos en el primer artículo, cualquiera de los dos nodos frontales (HA1 o HA2) vendrían a ser los servidores virtuales, y los dos nodos traseros (LB1 y LB2), los servidores reales, los cuales estarían bajo el control del balanceador de carga (HA1 o HA2), también conocido como director.

Siguiendo el esquema de la arquitectura desarrollada, puede observase que cuando los clientes web realicen peticiones HTTP, el nodo activo (balanceador) repartirá dichas peticiones de forma equitativa a los nodos traseros (servidores reales). Éstos a su vez procesarán la petición y devolverán nuevamente la respuesta al balanceador, siendo este elemento en última instancia el que realmente retorne las consultas a los clientes.

De esta forma cada vez que llega una conexión TCP, el balanceador escoge a un servidor real basándose en un algoritmo de scheduling. LVS dispone de diversos algoritmos que trabajan en función de distintos parámetros: número de conexiones establecidas, tráfico máximo soportado por cada uno de los servidores reales, etc. Por lo tanto, el balanceador será capaz de gestionar todas las conexiones que esté reenviando.

El balanceador va a tener conocimiento en todo momento del inicio y finalización de las conexiones TCP o UDP, así como de los puertos y direcciones IP empleadas. Pero por contra, desconoce qué es lo que se hace en las capas superiores. Aquí entra en juego uno de los mayores problemas de los sistemas de balanceo, la persistencia.

Existen varios servicios que requieren que todas las conexiones abiertas por un cliente, tengan como destino el mismo servidor real. Éste es por ejemplo el caso de los protocolos HTTPS o FTP. Esta situación se conoce como persistencia de la sesión. La sesión se puede definir como el conjunto de conexiones TCP/UDP realizadas con el objetivo de mantener la correcta prestación de un determinado servicio.

Por lo tanto, LVS identificará las conexiones de cada uno de los clientes analizando las cabeceras de los protocolos IP, TCP y UDP, y aplicará métodos de persistencia basados en direcciones IP origen, con la finalidad de asegurar el correcto funcionamiento del servicio gestionado.
Existen tres tipos de topología LVS de cara al reenvío de peticiones: LVS-NAT, LVS-DR y LVS-TUN. En el caso del cluster que estamos desarrollando, seguiremos la LVS-NAT.

LVS-NAT

Cuando un paquete llega al balanceador, éste lo examina para ver si coincide con alguno de los servicios que tiene definidos en la tabla de reglas, y en caso afirmativo, reenvía la petición hacia alguno de los servidores reales basando su elección en algún algoritmo de planificación.

Para reenviar el paquete, el balanceador reescribirá la dirección IP destino por la del servidor real al que vaya dirigido el encapsulado (10.0.0.12 o 10.0.0.13). Esta nueva conexión será añadida a una tabla de sesiones y permanecerá en ella hasta que finalice o caduque su tiempo de vida.

Cuando el paquete vuelva de regreso hacia el balanceador, éste rescribirá su dirección origen para que sea transmitido con la dirección IP virtual del director (192.168.1.20).

Las principales ventajas de este tipo de esquema son su relativa facilidad, rapidez y escasos requerimientos hardware. Por contra, se pierde en escalabilidad y rendimiento.

LVS-DR

A través de este método, cuando un paquete llegue al balanceador, éste lo reenviará al servidor real que considere oportuno. Pero a diferencia del esquema anterior, no modificará la dirección IP destino del encapsulado, simplemente cambiará la dirección MAC destino para poder reenviar el paquete al servidor real. Y a su vez, el servidor real no retornará el paquete al balanceador, directamente se lo enviará al cliente a través del router de salida.

Como puede observarse en la imagen anterior, en este tipo de esquema todas las máquinas que conforman el cluster tienen la misma dirección IP virtual, pero únicamente responde a las peticiones ARP a dicha dirección IP virtual el interfaz del balanceador, con el objetivo de que el router de entrada sólo tenga conocimiento de la dirección MAC del director, y de esta forma poder enviarle siempre los paquetes entrantes.

LVS-DR es el método con mayor rendimiento, ya que como ha podido observarse enruta a nivel de enlace, y además, el flujo de datos de los clientes atraviesa al balanceador en un único sentido.

LVS-TUN

LVS-TUN es similar a LVS-DR, con la diferencia de que se pueden establecer sistemas de balanceo estando el director y los servidores reales en redes remotas. Para ello lo que se hace es establecer túneles entre el balanceador y los servidores reales, encapsulando los paquetes transmitidos a través de los túneles mediante tramas IPIP.

Este tipo de implementación permite crear sistemas de alta disponibilidad y balanceo de carga muchos más efectivos, sin tener que depender de la ubicación física de las máquinas.

A través de esta clase de infraestructura que vamos a desarrollar se optimizan los siguientes aspectos:

• Rendimiento: tenemos una máquina que exclusivamente se encarga de repartir las peticiones, y varios servidores que atienden las peticiones que ecuánimemente les reparte el balanceador.
• Escalabilidad: a medida que el sistema lo vaya requiriendo, se podrán ir añadiendo nuevas máquinas a la granja de servidores sin ningún tipo de problema.
• Seguridad: por una parte, si se cae alguno de los nodos traseros el sistema seguirá funcionando correctamente debido a que el otro permanecerá levantado. Y por otra parte y en base al tipo de esquema empleado, puede verse que los dos nodos traseros (puntos más vulnerables para ser atacados) siempre estarán protegidos por el balanceador.