enchufado
   RSS
#
Balanceo de carga y HA con Zen Load Balancer (GNU/Linux) 2012-12-08 21:29:06

Siguiendo un poco con la serie de los balanceadores de carga (1, 2), mi actual responsable nos pidió que echáramos un vistazo a Zen Load Balancer, un balanceador de carga Open Source de propósito tanto general (balanceo de protocolos TCP/UDP) como particular (HTTS/HTTPS) que incluye la posibilidad de creación de un clúster para HA (con nodos activo/activo y activo/pasivo) y la gestión gráfica vía web.

Como en el caso de todos los balanceadores, éste siempre acaba atacando contra unos backends y es el que se encarga de redirigir las peticiones. Esta tarea la lleva a cabo -por debajo- principalmente con el antiguo y poco conocido pen.

Voy a ir al grano y seré escueto dado que su documentación ya detalla suficientemente cada cosa. Además, también está disponible una Quick Start Guide para tener un overview de cómo va el tema. Para terminar esta breve intro, solamente queda aclarar un par de conceptos de su jerga:

  • Farm es un grupo de backends con una configuración determinada que sirven a un mismo propósito.P.ej. podemos tener un farm que tenga un número determinado de nodos que se encargue de servir peticiones web.
  • Real Servers son los backends propiamente. P.ej. los servidores web finales con Apache mismo.
  • Cluster es un conjunto de 2 o más nodos de balanceo/frontends (Zen Load Balancers, para entendernos).

Instalación de un sólo nodo de balanceo

  1. Instalación, bien en base a iso/imagen virtual, bien en base a paquete, de Zen Load Balancer. En el caso de Debian basta con añadir los siguientes repositorios y lanzar un apt-get update && apt-get install zenloadbalancer para tenerlo andando (se puede gestionar a nivel de servicio).
  2. deb http://zenloadbalancer.sourceforge.net/apt/x86 v2/
  3. Acceso a la interfaz de gestión: https://<ip>:444, donde <ip> es la dirección ip que le hemos asignado al host. Las credenciales por defecto son admin:admin.
  4. Creación y configuración de una ip virtual (Settings > Interfaces > Add virtual network interface).
  5. Creación y configuración de un farm (usando la recién creada ip virtual): Manage > Farms > Add farm, especificando el profile (protocolo) a usar y otros settings.
  6. Asignación de backends/real servers. Dentro de la configuración del farm está la opción Add real server, que usaremos para añadir cada backend. Destacar que en este punto debemos tener los hosts y el servicio a balancear (p.ej. web) instalados y debidamente configurados en cada backend.
  7. Comprobación de funcionamiento. Sólo queda comprobar que atacando a la ip definida en el farm esten sirviendo los distintos real servers. Comentar que si no hemos definido persistencia, podemos ver la alternancia del uso de backends.

Instalación de un par de nodos de balanceo (clúster)

Llegados a este punto, añadir la capacidad de clúster son sólo unos pocos pasos más:

  1. Instalación de un segundo Zen Load Balancer siguiendo el anterior primer paso.
  2. El Zen Load Balancer que ya teniamos instalado (no el del paso previo) será el nodo primario del Clúster. Crearemos el cluster en Settings > Cluster y usamos la ip virtual. A continuación añadimos los datos del segundo Zen Load Balancer (Remote hostname), puesto que el principal -que es en el que estamos- ya figura. Guardamos (Save).
  3. Ahora establecemos la contraseña del segundo Zen Load Balancer (Remote host root password) para que el primero pueda sincronizarse a fin y efecto de crear el cluster, sincronizar datos y, en definitiva, operar con el mismo. Nos aseguramos de establecer correctamente la RSA connection between nodes.
  4. Finalmente definimos un Cluster type, que puede estar en Disabled (sin cluster), Master/Failback ó Both masters. La diferencia entre los 2 últimos tipos es que en el caso del Master/Failback, el nodo secundario del clúster sólo entra en funcionamiento temporalmente mientras el primario no esté disponible (y cuando lo está, cada uno recupera su rol). En el segudo caso (Both masters), el nodo secundario del clúster se convertirá en primario de modo permanemte (o hasta que forcemos manualmente lo contrario) mientras el primario no esté disponible.
  5. Si todos los anteriores pasos han terminado satisfactoriamente, veremos (en cada Zen Load Balancer, bien en la cabecera al lado del usuario admin, bien en la sección Cluster) la indicación de que existe una configuración de clúster y su rol en cada caso (master o failback/backup).
  6. Comprobación de funcionamiento. Podemos apagar el que esté actuando como nodo primario del clúster Zen Load Balancer y ver que el secundario rescata los requests (levantando la ip virtual) y los redirige a los real servers de igual modo que hacía el primario. Y cuando el primario vuelva a levantarse, podemos ver si recupera o no su rol en función del tipo de cluster elegido.

Notas/Troubleshooting

  • Asegúrate siempre de operar (Farms y Clusters) con la ip virtual.
  • Si quieres acceder a cada nodo por separado, recuerda que cada uno sigue teniendo su ip "física" disponible por la url de gestión. Esto es interesante si uno de ellos está deshabilitado/caído o si simplemente quieres ver rasgos particulares de cada uno (rol dentro del cluster, logs...).
  • Antes de crear un Cluster, asegúrate de tener un nodo secundario limpio: será el nodo primario el que se encargará de replicarlo todo en él.
  • Para las pruebas, puedes instalar un servidor web en cada realserver con una web estática que muestre el nombre del nodo. Así verás la alternancia (o stickyness) dependiento de la configuración de persistencia elegida.

Comentarios (9)


Volver al indice

login, admin, form, register