Table of Contents
1 Alta disponibilidad
Descripción general
La alta disponibilidad (HA) suele ser necesaria en infraestructuras críticas que no pueden permitirse prácticamente ningún tiempo de inactividad. Por lo tanto, para cualquier servicio que pueda fallar, debe existir una opción de conmutación por error para hacerse cargo en caso de que el servicio actual falle.
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 contra fallos de software/hardware del servidor Zabbix o para reducir el tiempo de inactividad debido a tareas de mantenimiento.
En el modo de alta disponibilidad de Zabbix, se ejecutan varios servidores Zabbix como nodos en un clúster. Mientras un servidor Zabbix en el clúster está activo, los demás están en espera, listos para hacerse cargo si es necesario.
El cambio a HA de Zabbix no es vinculante. Puede volver a la operación independiente en cualquier momento.
Consulte también: Detalles de la implementación
Habilitar alta disponibilidad
Iniciar el servidor Zabbix como nodo de clúster
Se requieren dos parámetros en la configuración del servidor para iniciar un servidor Zabbix como nodo de clúster:
- El parámetro HANodeName debe especificarse para cada servidor Zabbix que será un nodo de clúster HA.
Este es un identificador único de nodo (por ejemplo, zabbix-node-01) con el que se hará referencia al servidor en las configuraciones de agente y proxy. Si no especifica HANodeName, entonces el servidor se iniciará en modo independiente.
- El parámetro NodeAddress debe especificarse para cada nodo.
El parámetro NodeAddress (dirección:puerto) será utilizado por el frontend de Zabbix para conectarse al nodo de servidor activo. NodeAddress debe coincidir con la IP o el nombre FQDN del servidor Zabbix correspondiente.
Reinicie todos los servidores Zabbix 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 servidores puede verse en Informes → Información del sistema y también ejecutando:
zabbix_server -R ha_statusEste comando en tiempo de ejecución registrará el estado actual del clúster HA en el registro del servidor Zabbix (y en stdout):
Preparando la interfaz web
Asegúrese de que la dirección:puerto del servidor Zabbix no esté definida en la configuración de la interfaz web (se encuentra en conf/zabbix.conf.php del directorio de archivos de la interfaz web).
La interfaz web 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 del servidor Zabbix.
Configuración del proxy
Los nodos del clúster HA (servidores) deben estar listados en la configuración de un proxy Zabbix pasivo o activo.
Para un proxy pasivo, los nombres de los nodos deben estar listados en el parámetro Server parameter del proxy, separados por una coma.
Server=zabbix-node-01,zabbix-node-02Para un proxy activo, los nombres de los nodos deben estar listados en el parámetro Server parameter del proxy, separados por un punto y coma.
Server=zabbix-node-01;zabbix-node-02Configuración del agente
Los nodos del clúster HA (servidores) deben estar listados en la configuración del agente Zabbix o Zabbix agent 2.
Para habilitar 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-02Para habilitar comprobaciones activas, los nombres de los nodos deben estar listados en el parámetro ServerActive parameter. Tenga en cuenta que para comprobaciones activas los nodos deben estar separados por una coma de cualquier otro servidor, mientras que los propios nodos deben estar separados por un punto y coma, por ejemplo:
ServerActive=zabbix-node-01;zabbix-node-02Conmutación por error al nodo en espera
Zabbix cambiará automáticamente a otro nodo si el nodo activo se detiene. Debe haber al menos un nodo en estado de espera para que ocurra la conmutación por error.
¿Con qué rapidez se producirá la conmutación por error? Todos los nodos actualizan su última hora de acceso (y el estado, si ha cambiado) cada 5 segundos. Así que:
Si el nodo activo se apaga y logra informar su estado como "detenido", otro nodo tomará el control en 5 segundos.
Si el nodo activo se apaga/se vuelve inaccesible sin poder actualizar su estado, los nodos en espera esperarán el retardo de conmutación por error + 5 segundos para tomar el control.
El retardo de conmutación por error es configurable, con un rango soportado entre 10 segundos y 15 minutos (un minuto por defecto). Para cambiar el retardo de conmutación por error, puede ejecutar:
zabbix_server -R ha_set_failover_delay=5mGestión del clúster HA
El estado actual del clúster HA puede gestionarse utilizando las opciones dedicadas de control en tiempo de ejecución:
ha_status- registra el estado del clúster HA en el log del servidor Zabbix (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 de la salida de ejecutar ha_status), por ejemplo:
zabbix_server -R ha_remove_node=zabbix-node-02Tenga en cuenta que los nodos activos/en espera no pueden eliminarse.
ha_set_failover_delay=delay- establece el retardo de conmutación por error de HA (entre 10 segundos y 15 minutos; se admiten sufijos de tiempo, por ejemplo, 10s, 1m)
El estado del nodo puede supervisarse:
- en Informes → Información del sistema
- en el widget Información del sistema del dashboard
- utilizando la opción de control en tiempo de ejecución
ha_statusdel servidor (ver arriba).
La métrica interna 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 el clúster de alta disponibilidad
Para deshabilitar un clúster de alta disponibilidad:
- haga copias de seguridad de los archivos de configuración
- detenga los nodos en espera
- elimine el parámetro HANodeName del servidor primario activo
- reinicie el servidor primario (se iniciará en modo independiente)
Actualización del clúster HA
Para realizar una actualización de versión principal para los nodos HA:
- detenga todos los nodos;
- cree una copia de seguridad completa de la base de datos;
- si la base de datos utiliza replicación, asegúrese de que todos los nodos estén sincronizados y no tengan problemas. No actualice si la replicación está rota.
- seleccione un único nodo que realizará la actualización de la base de datos, cambie su configuración a modo independiente comentando HANodeName y actualícelo;
- asegúrese de que la actualización de la base de datos se haya completado completamente (Información del sistema debería mostrar que el servidor Zabbix está en ejecución);
- reinicie el nodo en modo HA;
- actualice e inicie el resto de los nodos (no es necesario cambiarlos a modo independiente ya que la base de datos ya está actualizada en este punto).
En una actualización de versión menor, es suficiente con actualizar el primer nodo, asegurarse de que se haya actualizado y esté en ejecución, y luego comenzar la actualización en el siguiente nodo.
Detalles de implementación
El clúster de alta disponibilidad (HA) es una solución opcional y es compatible con el servidor Zabbix. 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 reconoce Zabbix. Los usuarios son libres de utilizar la solución nativa de HA de Zabbix o una solución de HA de terceros, dependiendo de lo que mejor se adapte a los requisitos de alta disponibilidad en su entorno.
La solución consiste en múltiples instancias o nodos de zabbix_server. Cada nodo:
- se configura por separado
- utiliza la misma base de datos
- puede tener varios modos: activo, en espera, no disponible, detenido
Solo un nodo puede estar activo (funcionando) a la vez. Un nodo en espera ejecuta solo un proceso: el gestor de HA. Un nodo en espera no realiza recopilación de datos, procesamiento ni otras actividades regulares del servidor; no escucha en puertos; tiene conexiones mínimas a la base de datos.
Tanto los nodos activos como los de espera actualizan su último tiempo de acceso cada 5 segundos. Cada nodo en espera monitoriza el último tiempo de acceso del nodo activo. Si el último tiempo de acceso del nodo activo supera los segundos de 'retardo de conmutación por error', el nodo en espera se convierte en el nodo activo y asigna el estado 'no disponible' al nodo que estaba activo previamente.
El nodo activo monitoriza su propia conectividad a la base de datos: si se pierde durante más de retardo de conmutación por error-5 segundos, debe detener todo el procesamiento y cambiar al modo de espera. El nodo activo también monitoriza el estado de los nodos en espera: si el último tiempo de acceso de un nodo en espera supera los segundos de 'retardo de conmutación por error', al nodo en espera se le asigna el estado 'no disponible'.
Los nodos están diseñados para ser compatibles entre versiones menores de Zabbix.