Los sistemas de monitorización son parte fundamental de cualquier empresa tecnológica hoy en día. Por tanto, es muy necesario que éstos estén disponibles en todo momento para ser consultados. De no conseguirse, cualquier problema con el servicio puede resultar en un fallo catastrófico para nuestra empresa.

La manera tradicional de solucionar esto sería detectar la caída del sistema y lanzar nosotros a mano un nuevo servidor, con la configuración que ello conlleva. En Muutech nos propusimos automatizar este proceso. Debido a las características de Zabbix, no es posible tener varios servidores activos al mismo tiempo. Por lo que tenemos que buscar una solución que valga para servidores que trabajen en activo-pasivo, es decir, que mientras un servidor tiene el servicio listo y lanzado, el otro está preparado para lanzarse en cuanto sea requerido.

El objetivo principal es crear una red para que el servicio Zabbix no sufra problemas de disponibilidad. Para ello el primer paso es ver los posibles problemas a solucionar:

• Caída de un servidor completo.
• Caída de red del servidor en el que se ejecuta Zabbix.
• Caídas del servicio ofrecido debido a un error en su ejecución.

Cada uno de estos fallos se debe tratar de manera diferenciada desde cada uno de los nodos que estén en la red. Y, por supuesto, de manera completamente transparente al usuario. Para conseguir estos objetivos es necesario diseñar una arquitectura capaz de responder de manera rápida y efectiva a estos errores, además de preparar las diferentes máquinas para los mismos.

Esta solución es efectiva para una red que vaya desde tres nodos a varios cientos de ellos, por lo que es completamente escalable. Pero para simplificar la explicación, vamos a exponer el ejemplo más sencillo, que sería con tres nodos, aunque luego explicaremos como funcionaría con más.

Solución simple

Para conseguir la alta disponibilidad, optamos por usar la tecnología de Zookeeper, subproceso de Hadoop. Es una tecnología ampliamente probada y contrastada, utilizada por varias grandes empresas (Youtube, eBay, Yahoo, entre otras) y software (PTC ThingWorx, Patroni, etc.). Ésto nos da una idea de que puede llegar a ser muy efectiva.

Antes de nada, necesitamos instalar Zookeeper en los tres nodos de nuestra red. Y configurarlos de tal manera que se repliquen la información entre ellos, para evitar pérdidas de datos. Necesitamos mínimo tres nodos en la red para conseguir un quorum mediante un cluster saludable.

Un quorum es el conjunto de nodos que están replicados dentro de un mismo cluster y una misma aplicación. Todos estos nodos tienen la misma copia del fichero de configuración (explicado más adelante), ya que deben estar perfectamente sincronizados entre ellos.

Un clúster saludable se consigue cuando existen tres o más servidores dentro de un quorum, ya que de esta manera, de perder la conexión con un nodo, se puede mantener una “mayoría” de nodos con los datos sincronizados. Para verlo más claramente exponemos el siguiente ejemplo: tenemos dos nodos, si se perdiese la conexión entre ellos, cuando volviesen a conectarse, ambos tendrían diferentes datos. En ese caso, ¿cuáles serían los datos correctos a sincronizar? No hay manera sencilla de solucionar este supuesto, por este motivo, se considera que el número mínimo de nodos para tener un clúster saludable son tres.

Esto último se consigue con los siguientes pasos:

1. Escribimos lo siguiente en los ficheros de configuración:

tickTime=2000
initLimit=10
syncLimit=5
dataDir=/opt/zookeeper/data
clientPort=2181
server.1=zoo1ip:port1:port2
server.2=zoo2ip:port1:port2
server.3=zoo3ip:port1:port2

Donde:

• tickTime: Es el tiempo que se tarda en enviar cada ping.
• initLimit: Es el número de ping que tiene la primera fase de sincronización.
• syncLimit: Es el número máximo de pings que pueden pasar entre un ping y su repuesta, si se sobrepasa, la conexión se considera perdida.
• dataDir: Donde se almacena la información de los nodos de Zookeeper.
• clientPort: Puerto a través del cual se van a conectar los clientes.

Los servidores se describen en cada nodo, incluido él mismo. A mayores de ésto, necesitamos un fichero llamado “myid” en la carpeta indicada en “dataDir”. Este fichero contendrá un número único dentro del cluster Zookeeper (normalmente se suele poner el que le corresponde en server.X). 2. Ahora procederemos a ejecutar los servidores, ya sea de manera manual o a través de un servicio. La descripción del servicio la ofrecemos a continuación:

[Unit]
Description=Zookeeper Service

[Service]
Type=simple
WorkingDirectory=$ZOOKEEPER_PATH_OF_INSTALLATION
PIDFile=$ZOOKEEPER_PATH_OF_INSTALLATION/data/zookeeper_server.pid
SyslogIdentifier=zookeeper
User=zookeeper
Group=zookeeper
ExecStart=$ZOOKEEPER_PATH_OF_INSTALLATION/bin/zkServer.sh start
ExecStop=$ZOOKEEPER_PATH_OF_INSTALLATION/bin/zkServer.sh stop
Restart=always
TimeoutSec=20
SuccessExitStatus=130 143
Restart=on-failure

[Install]
WantedBy=

Con este servicio ya se lanzaría Zookeeper de manera automática.

3. Ahora, en los servidores donde esté instalado el servicio de Zabbix, instalamos nuestro cliente, que, con una pequeña configuración, ya se encarga de mantener la sincronización con los servidores de Zookeeper.

La arquitectura resultante en un caso sería algo así:

En ella vemos como nuestro cliente Zookeeper se encargaría de mantener la conexión con los servidores. De esta manera, el servidor pasivo sabría el estado del servidor activo en todo momento, por si fuese necesario que se activarse.

Ahora vamos a ver como actuaríamos en cada uno de los casos de fallo mencionados anteriormente:

En el caso de caída del servicio ofrecido debido a un error en su ejecución, veríamos que el sistema de servicios de Linux (systemd) intenta relanzarlo, si no lo consiguiese, nuestro cliente pararía el servicio, informaría al servidor de Zookeeper y este a su vez, informaría al servidor pasivo que tiene que activarse.

En el caso de caída de un servidor completo, el servidor de Zookeeper detectaría una pérdida de conexión desde el servidor activo, por lo cual considera que el servicio está caído. Debido a ello, informaría al servidor pasivo que tiene que activarse.

En el último caso, una caída de red del servidor en el que se ejecuta Zabbix, nuestro cliente comprueba contra otro servidor si tiene caídas sus interfaces de red. Si es así, para su servicio para que, al volver a tener red, no estén ambos servidores activos. El servidor de Zookeeper y el servidor pasivo funcionarán exactamente igual que en el caso anterior, por lo cual existe un servidor activo.

En el caso de que existiesen más de un servidor pasivo, todos ellos se pondrían en cola para esperar su “turno”. Por ello, si cayese el servidor activo, uno de los pasivos pasaría a ocupar su lugar mientras tendría otros pasivos pendientes de su estado.

Conclusión

Como se puede comprobar de manera fácil, esta solución resulta en una mejora total de la disponibilidad de la plataforma de monitorización, ya que el sistema es capaz de reaccionar de manera automática (failover) ante diversos problemas: perdida de red, caídas de servidores o servicios, etc.