Esta es una traducción de la página de documentación original en español. Ayúdanos a mejorarla.

Sidebar

Zabbix 6.2
Zabbix 6.2 is out. Explore whats new!

1 Clúster de alta disponibilidad

Descripción

El modo de alta disponibilidad ofrece protección contra fallas de software/hardware para el servidor Zabbix y permite minimizar el tiempo de inactividad durante mantenimiento de software/hardware.

El clúster de alta disponibilidad (HA) es una solución opcional y compatible con el servidor Zabbix. La solución HA nativa está diseñada para ser de simple uso, funcionará en todos los sitios y no tiene requisitos para las bases de datos que reconoce Zabbix. Los usuarios son libres de usar la solución Zabbix HA nativa o una solución HA de terceros, dependiendo de lo que mejor se adapte a los requisitos de alta disponibilidad en sus entornos.

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

  • se configura por separado (archivo de configuración, scripts, cifrado, exportación de datos)
  • utiliza la misma base de datos
  • tiene varios modos: activo, en espera, no disponible, detenido

Solo un nodo puede estar activo (trabajando) a la vez. Los nodos en espera no recopilan datos, procesamiento u otras actividades regulares del servidor; ellas no escuchan en los puertos; tienen conexiones mínimas de base de datos.

Los nodos activos y en espera actualizan su última hora de acceso cada 5 segundos. Cada nodo standby monitorea la última hora de acceso del nodo activo. Si la última hora de acceso del nodo activo ha superado la "segundos de retardo por error de conmutación", 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 supervisa su propia conectividad de base de datos, si se pierde durante más de 5 segundos, debe detener todo el procesamiento y cambiar al modo de espera. El nodo activo también supervisa el estado de los nodos en espera - si el último tiempo de acceso de un nodo en espera ha terminado los segundos de 'retraso de conmutación por error', al nodo en espera se le asigna el estado 'no disponible'.

El retraso de conmutación por error es configurable, con un mínimo de 10 segundos.

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

Habilitación del clúster HA (High Availability)

Configuración del servidor

Para convertir cualquier servidor Zabbix de un servidor independiente en un nodo de clúster HA, especifique el parámetro HANodeName en el servidor configuración.

El parámetro NodeAddress (dirección:puerto), si se establece, debe ser utilizado por la interfaz para el nodo activo, anulando el valor en zabbix.conf.php.

Preparing frontend

Make sure that Zabbix server address:port is not defined in the frontend configuration.

Zabbix frontend will autodetect the active node by reading settings from the nodes table in Zabbix database. Node address of the active node will be used as the Zabbix server address.

Configuración de proxy

Para habilitar las conexiones a varios servidores en una configuración de alta disponibilidad, enumerar las direcciones de los nodos HA en el servidor parámetro del proxy, separados por un punto y coma.

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.

Failover to standby node

Zabbix will fail over to another node automatically if the active node stops. There must be at least one node in standby status for the failover to happen.

How fast will the failover be? All nodes update their last access time (and status, if it is changed) every 5 seconds. So:

  • If the active node shuts down and manages to report its status as "shut down", another node will take over within 5 seconds.

  • If the active node shuts down/becomes unavailable without being able to update its status, standby nodes will wait for the failover delay + 5 seconds to take over

The failover delay is configurable, with the supported range between 10 seconds and 15 minutes (one minute by default). To change the failover delay, you may run:

zabbix_server -R ha_set_failover_delay=5m

Gestión del clúster de alta disponibilidad (HA)

El estado actual del clúster de alta disponibilidad se puede administrar mediante las opciones de control de tiempo de ejecución:

  • ha_status: registra el estado del clúster HA en el log del servidor Zabbix;
  • ha_remove_node=target - elimina un nodo HA identificado por su <objetivo> - número del nodo en la lista (el número puede ser obtenido de la salida de la ejecución de ha_status). 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 (tiempo Se admiten sufijos, p. 10s, 1m)

El estado del nodo se puede monitorear:

  • en InformesSistema información
  • 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 sobre).

El elemento interno zabbix[cluster,discovery,nodes] se puede usar por el nodo descubrimiento, ya que devuelve un JSON con información de nodo de alta disponibilidad.

Deshabilitación del 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
  • elimine el parámetro HANodeName del servidor primario activo
  • reinicie el servidor principal (comenzará en modo independiente)

Implementation details

The high availability (HA) cluster is an opt-in solution and it is supported for Zabbix server. The native HA solution is designed to be simple in use, it will work across sites and does not have specific requirements for the databases that Zabbix recognizes. Users are free to use the native Zabbix HA solution, or a third party HA solution, depending on what best suits the high availability requirements in their environment.

The solution consists of multiple zabbix_server instances or nodes. Every node:

  • is configured separately (configuration file, scripts, encryption, data export)
  • uses the same database
  • has several modes: active, standby, unavailable, stopped

Only one node can be active (working) at a time. The standby nodes do no data collection, processing or other regular server activities; they do not listen on ports; they have minimum database connections.

Both active and standby nodes update their last access time every 5 seconds. Each standby node monitors the last access time of the active node. If the last access time of the active node is over 'failover delay' seconds, the standby node switches itself to be the active node and assigns 'unavailable' status to the previously active node.

The active node monitors its own database connectivity - if it is lost for more than failover delay-5 seconds, it must stop all processing and switch to standby mode. The active node also monitors the status of the standby nodes - if the last access time of a standby node is over 'failover delay' seconds, the standby node is assigned the 'unavailable' status.

The failover delay is configurable, with the minimum being 10 seconds.

The nodes are designed to be compatible across minor Zabbix versions.