Muutech seleccionada para participar en el BFFood
agosto 27, 2019
Ventajas de utilizar un sistema de monitorización SaaS en la nube
septiembre 12, 2019
Alta disponibilidad en tus servidores de monitorización
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:
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.
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:
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í:
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.
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:port2Donde:
- 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.
[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.
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 ú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.