Documentation
Table of Contents
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.
Áú»¢¶Ä²© 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 Áú»¢¶Ä²© puede ser ¨²til para tener una capa adicional de protecci¨®n contra fallos de software/hardware del servidor Áú»¢¶Ä²© o tener menos tiempo de inactividad debido al mantenimiento.
En el modo de alta disponibilidad de Áú»¢¶Ä²©, se ejecutan varios servidores Áú»¢¶Ä²© como nodos en un cl¨²ster. Mientras un servidor Áú»¢¶Ä²© en el cl¨²ster est¨¢ activo, otros est¨¢n en espera, listos para asumir el control si fuera necesario.
Cambiar a Áú»¢¶Ä²© 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 Áú»¢¶Ä²© como nodo del cl¨²ster
Se requieren dos ±è²¹°ù¨¢³¾±ð³Ù°ù´Çs en la ³¦´Ç²Ô´Ú¾±²µ³Ü°ù²¹³¦¾±¨®²Ô del servidor para iniciar un servidor Áú»¢¶Ä²© como nodo del cl¨²ster:
- Se debe especificar el ±è²¹°ù¨¢³¾±ð³Ù°ù´Ç HANodeName para cada servidor Áú»¢¶Ä²©. 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 ³¦´Ç²Ô´Ú¾±²µ³Ü°ù²¹³¦¾±¨®²Ô del agente. y del proxy. Si no especifica HANodeName, el servidor ser¨¢ iniciado en modo independiente.
- Se debe especificar el ±è²¹°ù¨¢³¾±ð³Ù°ù´Ç NodeAddress para cada nodo.
El ±è²¹°ù¨¢³¾±ð³Ù°ù´Ç NodeAddress (direcci¨®n:puerto) ser¨¢ utilizado por la interfaz de Áú»¢¶Ä²© para conectarse al nodo del servidor activo. NodeAddress debe coincidir con la IP o el nombre FQDN del servidor Áú»¢¶Ä²© respectivo.
Reinicie todos los servidores Áú»¢¶Ä²© despu¨¦s de realizar cambios en los archivos de ³¦´Ç²Ô´Ú¾±²µ³Ü°ù²¹³¦¾±¨®²Ô. 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_statusEste comando en tiempo de ejecuci¨®n registrar¨¢ el estado actual del cl¨²ster HA en el registro del servidor Áú»¢¶Ä²© (y en la salida est¨¢ndar):
Preparando la interfaz
Aseg¨²rese de que la direcci¨®n:puerto del servidor Áú»¢¶Ä²© no est¨¦ definida en la ³¦´Ç²Ô´Ú¾±²µ³Ü°ù²¹³¦¾±¨®²Ô de la interfaz (que se encuentra en conf/zabbix.conf.php del directorio de archivos de la interfaz).
La interfaz de Áú»¢¶Ä²© detectar¨¢ autom¨¢ticamente el nodo activo leyendo la ³¦´Ç²Ô´Ú¾±²µ³Ü°ù²¹³¦¾±¨®²Ô de la tabla de nodos en la base de datos Áú»¢¶Ä²©. La direcci¨®n de nodo del nodo activo se utilizar¨¢ como la direcci¨®n del servidor Áú»¢¶Ä²©.
°ä´Ç²Ô´Ú¾±²µ³Ü°ù²¹³¦¾±¨®²Ô de proxy
Los nodos (servidores) del cl¨²ster HA deben aparecer en la ³¦´Ç²Ô´Ú¾±²µ³Ü°ù²¹³¦¾±¨®²Ô de cualquiera de los dos Proxy Áú»¢¶Ä²© pasivo o activo.
Para un proxy pasivo, los nombres de los nodos deben aparecer en el ±è²¹°ù¨¢³¾±ð³Ù°ù´Ç Server del proxy, separados por una coma.
Server=zabbix-node-01,zabbix-node-02Para un proxy activo, los nombres de los nodos deben aparecer en el ±è²¹°ù¨¢³¾±ð³Ù°ù´Ç Server del proxy, separados por un punto y coma.
Server=zabbix-node-01;zabbix-node-02°ä´Ç²Ô´Ú¾±²µ³Ü°ù²¹³¦¾±¨®²Ô del agente
Para habilitar las conexiones a varios servidores en una ³¦´Ç²Ô´Ú¾±²µ³Ü°ù²¹³¦¾±¨®²Ô de alta disponibilidad, enumerar las direcciones de los nodos HA en ServerActive ±è²¹°ù¨¢³¾±ð³Ù°ù´Ç del agente, separados por un punto y coma.
Conmutaci¨®n por error al nodo en espera
Áú»¢¶Ä²© 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=5mGesti¨®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 Áú»¢¶Ä²© (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-02Tenga 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_statusdel 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 ³¦´Ç²Ô´Ú¾±²µ³Ü°ù²¹³¦¾±¨®²Ô
- detener los nodos en espera
- eliminar el ±è²¹°ù¨¢³¾±ð³Ù°ù´Ç 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 ³¦´Ç²Ô´Ú¾±²µ³Ü°ù²¹³¦¾±¨®²Ô al modo independiente comentando HANodeName y ²¹³¦³Ù³Ü²¹±ô¾±³ú¨¢²Ô»å´Ç±ô´Ç;
- 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 Áú»¢¶Ä²© 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 Áú»¢¶Ä²©. 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 Áú»¢¶Ä²© reconoce. Los usuarios son libres de utilizar la soluci¨®n HA nativa de Áú»¢¶Ä²© 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 Áú»¢¶Ä²©.