1 Clúster de alta disponibilidad

Descripción general

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. El 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 clúster. Mientras un servidor Zabbix en el clúster está activo, otros están en espera, listos para asumir el control si fuera 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

Habilitando la alta disponibilidad

Iniciando el servidor Zabbix como nodo del clúster

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

• Se debe especificar el parámetro HANodeName para cada servidor Zabbix. ese será un nodo de clúster HA.

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.

• Se debe especificar el parámetro NodeAddress para cada nodo.

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):

Preparando la interfaz

Asegúrese de que la dirección:puerto del servidor Zabbix no esté definida en la configuración de la interfaz (que se encuentra en conf/zabbix.conf.php del directorio de archivos de la interfaz).

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.

Configuración de proxy

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

Configuración del agente

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.

Conmutación por error al nodo en espera

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

Gestión del clúster HA

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=destino: 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=zabbix-node-02

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; se admiten sufijos de tiempo, p.e. 10s, 1m)

El estado del nodo se puede monitorear:

• en Informes → Información del sistema
• en el widget del tablero Información del sistema
• usando la opción de control de tiempo de ejecución ha_status del servidor (ver arriba).

La métrica interna zabbix[cluster,discovery,nodes] se puede utilizar para el descubrimiento de los nodos, ya que devuelve un JSON con la información del nodo de alta disponibilidad.

Deshabilitar el clúster HA

Para deshabilitar un clúster de alta disponibilidad:

• hacer copias de seguridad de los archivos de configuración
• detener los nodos en espera
• eliminar 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 importante para los nodos HA:

• detener todos los nodos;
• crear 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 no funciona.
• seleccione un único nodo que realizará la actualización de la base de datos, cambie su configuración al modo independiente comentando HANodeName y actualizándolo;
• asegúrese de que la actualización de la base de datos esté completamente completa (La información del sistema debe mostrar que el servidor Zabbix se está ejecutando);
• reiniciar el nodo en modo HA;
• actualizar e iniciar el resto de nodos (no es necesario cambiarlos al modo independiente ya que la base de datos ya está actualizada en este punto).

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.

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 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 entorno.

La solución consta de múltiples instancias o nodos zabbix_server. Cada nodo:

• se configura por separado
• utiliza la misma base de datos
• puede tener varios modos: activo, en espera, no disponible, detenido

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 nodos 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 está por encima de los segundos de 'retraso de conmutación por error', 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.