Normalmente se requiere alta disponibilidad (HA) en infraestructuras críticas que prácticamente no puede permitirse ningún tiempo de inactividad. Entonces, para cualquier servicio que puede fallar, debe existir una opción de conmutación por error para asumir el control en caso de que el servicio actual falle.
Zabbix ofrece una solución nativa de alta disponibilidad que es fácil de configurar y no requiere ninguna experiencia previa en HA. HA nativo de Zabbix puede ser útil para tener una capa adicional de protección contra fallos de software/hardware del servidor Zabbix o tener menos tiempo de inactividad debido al mantenimiento.
En el modo de alta disponibilidad de Zabbix, se ejecutan varios servidores Zabbix como nodos en un cluster. Mientras un servidor Zabbix en el clúster está activo, otros están en espera, listos para asumir el control si es necesario.
Cambiar a Zabbix HA no supone ningún compromiso. Puede volver a operar de forma independiente en cualquier momento.
Ver también: Detalles de implementación
Se requieren dos parámetros en la configuración del servidor para iniciar un servidor Zabbix como nodo del clúster:
Este es un identificador de nodo único (por ejemplo, zabbix-node-01
) del servidor al que se hará referencia en la configuración del agente. y del proxy. Si no especifica HANodeName, el servidor será iniciado en modo independiente.
El parámetro NodeAddress (dirección:puerto) será utilizado por la interfaz de Zabbix para conectarse al nodo del servidor activo. NodeAddress debe coincidir con la IP o el nombre FQDN del servidor Zabbix respectivo.
Reinicie todos los servidores Zabbix después de realizar cambios en los archivos de configuración. Ahora se iniciarán como nodos del clúster. El nuevo estado de los servidores se puede ver en Informes → Información del sistema 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 registro del servidor Zabbix (y en la salida estándar):
Asegúrese de que la dirección del servidor Zabbix:puerto no esté definido en la configuración de la interfaz (que se encuentra en conf/zabbix.conf.php
del directorio de archivos del frontend).
La interfaz de Zabbix detectará automáticamente el nodo activo leyendo la configuración de la tabla de nodos en la base de datos Zabbix. La dirección de nodo del nodo activo se utilizará como la dirección del servidor Zabbix.
Los nodos (servidores) del clúster HA deben aparecer en la configuración de cualquiera de los dos Proxy Zabbix pasivo o activo.
Para un proxy pasivo, los nombres de los nodos deben aparecer 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 aparecer en el parámetro Server del proxy, separados por un punto y coma.
Server=zabbix-node-01;zabbix-node-02
Para habilitar las conexiones a varios servidores en una configuración de alta disponibilidad, enumerar las direcciones de los nodos HA en ServerActive parámetro del agente, separados por un punto y coma.
Zabbix conmutará 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 su estado, si se cambia) cada 5 segundos. Entonces:
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 o deja de estar disponible sin poder actualizarse su estado, los nodos en espera esperarán el retraso de conmutación por error + 5 segundos para tomar el control
El retraso de conmutación por error es configurable, con un rango admitido entre 10 segundos y 15 minutos (un minuto por defecto). Para cambiar el retraso de la conmutación por error, puede ejecutar:
zabbix_server -R ha_set_failover_delay=5m
El estado actual del clúster HA se puede gestionar mediante las opciones dedicadas de control en tiempo de ejecución:
ha_status
: registra el estado del clúster HA en el registro del servidor Zabbix (y en la salida estándar)ha_remove_node=target
: elimina un nodo HA identificado por su <destino> - número del nodo en la lista (el número puede ser obtenido de la salida de ejecutar ha_status), por ejemplo:zabbix_server -R ha_remove_node=2
Tenga en cuenta que los nodos activos/en espera no se pueden eliminar.
ha_set_failover_delay=delay
- establece el retraso de conmutación por error de HA (entre 10 segundos y 15 minutos; tiempo se admiten sufijos, p. 10s, 1m)El estado del nodo se puede monitorear:
ha_status
del servidor (ver arriba).El elemento interno zabbix[cluster,discovery,nodes]
se puede utilizar para el nodo descubrimiento, ya que devuelve un JSON con la información del nodo de alta disponibilidad.
Para deshabilitar un clúster de alta disponibilidad:
Para realizar una actualización de versión importante para los nodos HA:
En una actualización de versión menor, es suficiente actualizar el primer nodo, asegurarse de que esté actualizado y en ejecución, y luego comenzar la actualización en el siguiente nodo.
El clúster de alta disponibilidad (HA) es una solución opcional y es compatible con el servidor Zabbix. La solución HA nativa está diseñada para ser de uso sencillo, funcionará en todos los sitios y no tiene requisitos específicos para las bases de datos que Zabbix reconoce. Los usuarios son libres de utilizar la solución HA nativa de Zabbix o una solución HA de terceros, dependiendo de lo que mejor se adapte a los requisitos de alta disponibilidad en su ambiente.
La solución consta de múltiples instancias o nodos zabbix_server. Cada nodo:
Sólo un nodo puede estar activo (en funcionamiento) a la vez. Un nodo en espera ejecuta sólo un proceso: el administrador de HA. Un nodo en espera no recopila datos, procesamiento u otras actividades regulares del servidor; no escuchan en los puertos; Tienen conexiones mínimas a la base de datos.
Tanto los nodos activos como los en espera actualizan su última hora de acceso cada 5 segundos. Cada nodo en espera monitorea la última hora de acceso del nodo activo. Si el último tiempo de acceso del nodo activo ha terminado 'segundos tiemo de espera de retraso', el nodo en espera cambia a sí mismo para ser el nodo activo y asigna el estado "no disponible" al nodo previamente activo.
El nodo activo monitorea su propia conectividad de base de datos, si se pierde durante más de "retraso de conmutación por error-5" segundos, debe detener todo el procesamiento y cambiar al modo de espera. El nodo activo también monitorea el estado de los nodos en espera: si el último tiempo de acceso de un nodo en espera ha terminado en 'retraso de conmutación por error' segundos, al nodo en espera se le asigna el estado 'no disponible'.
Los nodos están diseñados para ser compatibles con versiones menores de Zabbix.