1 Clúster de alta disponibilidad

Resumen

La alta disponibilidad (HA) suele ser necesaria en infraestructuras críticas que no pueden permitirse prácticamente ningún tiempo de inactividad. Por ello, para cualquier servicio que pueda fallar debe existir una opción de conmutación por error que asuma el control si el servicio actual falla.

Zabbix ofrece una solución de alta disponibilidad nativa que es fácil de configurar y no requiere experiencia previa en HA. La HA nativa de Zabbix puede ser útil como una capa adicional de protección frente a fallos de software o hardware del server de Zabbix, o para reducir el tiempo de inactividad debido al mantenimiento.

En el modo de alta disponibilidad de Zabbix, varios servers de Zabbix se ejecutan como nodos en un clúster. Mientras un server de Zabbix del clúster está activo, los demás permanecen en espera, listos para asumir el control si es necesario.

Cambiar a Zabbix HA no implica compromiso. Puede volver al funcionamiento independiente en cualquier momento.

Véase también: Detalles de implementación

Habilitando la alta disponibilidad

Iniciando Zabbix server como nodo de clúster

Se requieren dos parámetros en la configuración del server para iniciar un Zabbix server como nodo de clúster:

  • El parámetro HANodeName debe especificarse para cada Zabbix server que será un nodo del clúster HA.

Este es un identificador único del nodo (por ejemplo, zabbix-node-01) con el que se hará referencia al server en las configuraciones de agent y proxy. Si no especifica HANodeName, el server se iniciará en modo independiente.

  • El parámetro NodeAddress debe especificarse para cada nodo.

El parámetro NodeAddress (address:port) será utilizado por el frontend de Zabbix para conectarse al nodo activo del server. NodeAddress debe coincidir con la IP o el nombre FQDN del Zabbix server correspondiente.

Reinicie todos los Zabbix servers después de realizar cambios en los archivos de configuración. Ahora se iniciarán como nodos de clúster. El nuevo estado de los servers puede verse en Reports > System information y también ejecutando:

zabbix_server -R ha_status

Este comando en tiempo de ejecución registrará el estado actual del clúster HA en el log del Zabbix server (y en stdout):

Preparando el frontend

Asegúrese de que address:port de Zabbix server no esté definido en la configuración del frontend (se encuentra en conf/zabbix.conf.php del directorio de archivos del frontend).

El frontend de Zabbix detectará automáticamente el nodo activo leyendo la configuración de la tabla de nodos en la base de datos de Zabbix. La dirección del nodo activo se utilizará como la dirección de Zabbix server.

Configuración del proxy

Los nodos del clúster HA (servers) deben estar enumerados en la configuración de un proxy Zabbix pasivo o activo.

Para un proxy pasivo, los nombres de los nodos deben estar enumerados en el parámetro Server del proxy, separados por una coma.

Server=zabbix-node-01,zabbix-node-02

Para un proxy activo, los nombres de los nodos deben estar enumerados en el parámetro Server del proxy, separados por un punto y coma.

Server=zabbix-node-01;zabbix-node-02
Configuración del agent

Los nodos del clúster HA (servers) deben estar listados en la configuración de Zabbix agent o Zabbix agent 2.

Para habilitar las comprobaciones pasivas, los nombres de los nodos deben estar listados en el parámetro Server parameter, separados por una coma.

Server=zabbix-node-01,zabbix-node-02

Para habilitar las comprobaciones activas, los nombres de los nodos deben estar listados en el parámetro ServerActive parameter. Tenga en cuenta que, para las comprobaciones activas, los nodos deben separarse de cualquier otro servidor mediante una coma, mientras que los propios nodos deben separarse mediante un punto y coma, por ejemplo:

ServerActive=zabbix-node-01;zabbix-node-02

Conmutación por error al nodo en espera

Zabbix realizará la conmutación por error a otro nodo automáticamente si el nodo activo se detiene. Debe haber al menos un nodo en estado de espera para que se produzca la conmutación por error.

¿Qué tan rápida será la conmutación por error? Todos los nodos actualizan su última hora de acceso (y el estado, si cambia) cada 5 segundos. Por lo tanto:

  • Si el nodo activo se apaga y logra informar su estado como "stopped", otro nodo asumirá el control en un plazo de 5 segundos.
  • Si el nodo activo se apaga o deja de estar disponible sin poder actualizar su estado, los nodos en espera esperarán el retardo de conmutación por error + 5 segundos para asumir el control.

El retardo de conmutación por error es configurable, con un rango admitido entre 10 segundos y 15 minutos (un minuto de forma predeterminada). Para cambiar el retardo de conmutación por error, puede ejecutar:

zabbix_server -R ha_set_failover_delay=5m

Gestión del clúster HA

El estado actual del clúster HA puede gestionarse mediante las opciones dedicadas de runtime control:

  • ha_status - registra el estado del clúster HA en el log del Zabbix server (y en stdout);
  • ha_remove_node=target - elimina un nodo HA identificado por su <target> - nombre o ID del nodo (el nombre/ID puede obtenerse a partir de la salida de ejecutar ha_status), por ejemplo:
zabbix_server -R ha_remove_node=zabbix-node-02

Tenga en cuenta que los nodos activos/en espera no se pueden eliminar.

  • ha_set_failover_delay=delay - establece el retardo de failover de HA (entre 10 segundos y 15 minutos; se admiten sufijos de tiempo, por ejemplo 10s, 1m).

El estado del nodo puede supervisarse:

  • En Reports > System information.
  • En el widget del panel System information.
  • Usando la opción de runtime control ha_status del server (véase arriba).

El item interno zabbix[cluster,discovery,nodes] puede utilizarse para el descubrimiento de nodos, ya que devuelve un JSON con la información de los nodos de alta disponibilidad.

Deshabilitar un clúster HA

Para deshabilitar un clúster de alta disponibilidad:

  1. Haga copias de seguridad de los archivos de configuración2.
  2. Detenga los nodos en espera.
  3. Elimine el parámetro HANodeName del server primario activo.
  4. Reinicie el server primario (se iniciará en modo independiente).

Actualización del clúster HA

Para realizar una actualización de versión principal de los nodos HA:

  1. Detenga todos los nodos.
  2. Cree una copia de seguridad completa de la base de datos.
  3. Si la base de datos usa replicación, asegúrese de que todos los nodos estén sincronizados y no tengan problemas. No actualice si la replicación está rota.
  4. Seleccione un único nodo que realizará la actualización de la base de datos, cambie su configuración al modo independiente comentando HANodeName y actualícelo.
  5. Asegúrese de que la actualización de la base de datos se haya completado por completo (System information debe mostrar que Zabbix server se está ejecutando).
  6. Reinicie el nodo en modo HA.
  7. Actualice e inicie el resto de los nodos (no es necesario cambiarlos al modo independiente, ya que en este punto la base de datos ya está actualizada).

En una actualización de versión menor, basta con actualizar el primer nodo, asegurarse de que se haya actualizado y esté en ejecución, y luego iniciar la actualización del siguiente nodo.

Detalles de implementación

El clúster de alta disponibilidad (HA) es una solución opcional y es compatible con Zabbix server. La solución nativa de HA está diseñada para ser sencilla de usar, funcionará entre sitios y no tiene requisitos específicos para las bases de datos que Zabbix reconoce. Los usuarios pueden usar la solución nativa de HA de Zabbix o una solución de HA de terceros, según lo que mejor se adapte a los requisitos de alta disponibilidad de su entorno.

La solución consta de varias instancias o nodos de zabbix_server. Cada nodo:

  • Se configura por separado.
  • Usa la misma base de datos.
  • Puede tener varios modos: activo, en espera, no disponible, detenido.

Solo un nodo puede estar activo (en funcionamiento) a la vez. Un nodo en espera ejecuta solo un proceso: el administrador de HA. Un nodo en espera no realiza recopilación de datos, procesamiento ni otras actividades habituales del server; no escucha en puertos; tiene un mínimo de conexiones a la base de datos.

Tanto los nodos activos como los nodos en espera actualizan su última hora de acceso cada 5 segundos. Cada nodo en espera supervisa la última hora de acceso del nodo activo. Si la última hora de acceso del nodo activo supera los segundos de 'failover delay', el nodo en espera se convierte en el nodo activo y asigna el estado unavailable al nodo que estaba activo anteriormente.

El nodo activo supervisa su propia conectividad con la base de datos: si se pierde durante más de failover delay-5 segundos, debe detener todo el procesamiento y cambiar al modo en espera. El nodo activo también supervisa el estado de los nodos en espera: si la última hora de acceso de un nodo en espera supera los segundos de 'failover delay', al nodo en espera se le asigna el estado unavailable.

Los nodos están diseñados para ser compatibles entre versiones menores de Zabbix.