Alta disponibilidad (HA)

Introducción

Pandora FMS es una aplicación muy estable gracias a las pruebas y mejoras introducidas en cada versión y a la corrección de algunos fallos descubiertos por los usuarios. No obstante, en entornos críticos y/o con mucha carga, es posible que sea necesario repartir la carga en varias máquinas y tener la seguridad de que si algún componente de Pandora FMS falla, el sistema se mantiene en línea.

Pandora FMS ha sido diseñado para que sea modular pero también esta diseñado para trabajar en colaboración con otros componentes y ser capaz de asumir la carga de aquellos componentes que han caído.

Un diseño estándar de Pandora FMS podría ser el que se ve en la siguiente ilustración.

Evidentemente, los agentes no son redundantes. Si un agente cae, no tiene sentido ejecutar otro, ya que la única causa de que un agente caiga es que no se puedan obtener datos porque algún modulo está fallando su ejecución —lo que no se podría subsanar con otro agente corriendo en paralelo— o porque el sistema está incomunicado o se ha colgado. La solución obvia es redundar los sistemas críticos —independientemente de que tengan corriendo agentes de Pandora FMS o no— y así redundar la monitorización de dichos sistemas.

Se puede hablar de utilizar la Alta disponibilidad ( High Availability o HA ) en varios escenarios:

  • Balanceo y HA del Servidor de datos.
  • Balanceo y HA de los servidores de Red, WMI, plugin, web, prediction, recon, y similares.
  • Balanceo y HA en la base de datos (BBDD).
  • Balanceo y HA de la consola de Pandora FMS.

Dimensionamiento y diseños de arquitectura HA

Los componentes más importantes de Pandora FMS son:

  1. Base de datos.
  2. Servidor.
  3. Consola.

Cada uno de los componentes puede replicarse para proteger el sistema de monitorización de cualquier catástrofe.

Para designar el número de nodos necesarios para equilibrar la carga estudiaremos el número de objetivos a monitorizar y la cantidad, tipo y frecuencia de captura de las métricas a recolectar.

En función de las necesidades de monitorización definiremos las diferentes arquitecturas.

Nota: Las pruebas realizadas para definir las arquitecturas se han realizado utilizando equipos diferentes:

Dimensionamiento

Dependiendo de las necesidades:

1. Standalone (sin alta disponibilidad) hasta 2500 agentes / 50 000 módulos cada 5 minutos, datos uniformes, sin datos históricos.

 Servidores: 1 (compartido)

 Principal:
 ----------
 CPU: 6 cores
 RAM: 8 GB
 Disco: 100 GB

2. Standalone (sin alta disponibilidad) hasta 2500 agentes / 50 000 módulos cada 5 minutos, datos uniformes, con datos históricos (1 año).

 Servidores: 2 (1 compartido, 1 histórico)

 Principal:
 ----------
 CPU: 6 cores
 RAM: 8 GB
 Disco: 100 GB

 Histórico:
 ----------
 CPU: 2 cores
 RAM: 4 GB
 Disco: 200 GB

3. Standalone (sin alta disponibilidad) hasta 5000 agentes / 100 000 módulos cada 5 minutos, datos uniformes, con datos históricos (1 año).

 Servidores: 3 (1 servidor + consola, 1 base de datos principal, 1 histórico)

 Servidor + consola:
 -------------------
 CPU: 6 cores
 RAM: 8 GB
 Disco: 40 GB

 Base de datos principal:
 ------------------------
 CPU: 4 cores
 RAM: 8 GB
 Disco: 100 GB

 Histórico:
 ----------
 CPU: 2 cores
 RAM: 4 GB
 Disco: 200 GB

Diseños de arquitectura HA

1. Base de datos en HA simple, hasta 7500 agentes / 12 5000 módulos cada 5 minutos, datos uniformes, con datos históricos (1 año).

 Servidores: 4 (1 servidor + consola, 2 base de datos, 1 histórico)

 Servidor + consola:
 -------------------
 CPU: 6 cores
 RAM: 8 GB
 Disco: 40 GB

 Base de datos nodo 1:
 ---------------------
 CPU: 6 cores
 RAM: 8 GB
 Disco: 100 GB

 Base de datos nodo 2:
 ---------------------
 CPU: 6 cores
 RAM: 8 GB
 Disco: 100 GB

 Histórico:
 ----------
 CPU: 2 cores
 RAM: 4 GB
 Disco: 300 GB

2. Base de datos en HA completo (con quorum), hasta 7500 agentes / 125 000 módulos cada 5 minutos, datos uniformes, con datos históricos (1 año).

 Servidores: 5 (1 servidor + consola, 3 base de datos, 1 histórico)

 Servidor + consola:
 -------------------
 CPU: 6 cores
 RAM: 8 GB
 Disco: 40 GB

 Base de datos nodo 1:
 ---------------------
 CPU: 6 cores
 RAM: 8 GB
 Disco: 100 GB

 Base de datos nodo 2:
 ---------------------
 CPU: 6 cores
 RAM: 8 GB
 Disco: 100G B

 Base de datos nodo 3:
 ---------------------
 CPU: 6 cores
 RAM: 8 GB
 Disco: 100 GB

 Histórico:
 ----------
 CPU: 2 cores
 RAM: 4 GB
 Disco: 200 GB

3. Base de datos en HA simple y Pandora FMS en HA balanceado, hasta 7500 agentes / 125 000 módulos cada 5 minutos, datos uniformes, con datos históricos (1 año).

 Servidores: 5 (2 servidor + consola, 2 base de datos, 1 histórico)

 Servidor + consola:
 -------------------
 CPU: 6 cores
 RAM: 8 GB
 Disco: 40 GB

 Servidor + consola:
 -------------------
 CPU: 6 cores
 RAM: 8 GB
 Disco: 40 GB

 Base de datos nodo 1:
 ---------------------
 CPU: 6 cores
 RAM: 8 GB
 Disco: 100 GB

 Base de datos nodo 2:
 ---------------------
 CPU: 6 cores
 RAM: 8 GB
 Disco: 100 GB

 Histórico:
 ----------
 CPU: 2 cores
 RAM: 4 GB
 Disco: 200 GB

4. Básico HA balanceado en servidor, principal y réplica de Base de datos, hasta 4000 agentes / 90 000 módulos cada 5 minutos, datos uniformes, con datos históricos (1 año).

 Servidores: 3 (2 compartido, 1 histórico)

 Principal: (consola + servidor + base de datos nodo 1).
 ----------
 CPU: 8 cores
 RAM: 12 GB
 Disco: 100 GB

 Secundario: (consola + servidor + base de datos nodo 2).
 ----------
 CPU: 8 cores
 RAM: 12 GB
 Disco: 100 GB

 Histórico:
 ----------
 CPU: 2 cores
 RAM: 4 GB
 Disco: 200 GB

En este esquema se configuran los nodos de la base de datos de Pandora FMS en cada uno de los dos servidores disponibles (principal y secundario).

Para grandes entornos, definiremos cada uno de los esquemas de configuración descritos previamente como nodos de computación.

Ejemplo

Si se necesitan monitorizar 30 000 agentes con 500 000 módulos deberá configurarse tantos nodos como sea necesario para cubrir estos requisitos. Siguiendo el ejemplo:

Si elige el diseño HA Nº. 1 (1 servidor+consola, 2 nodos de base de datos en HA, y una base de datos de histórico), se debe configurar 30 000 / 7500 = 4 nodos.

Para administrar todo el entorno, se necesitará disponer de una Metaconsola instalada, desde donde configurar toda la infraestructura de monitorización.

La Metaconsola requerirá:

 Servidores: 1 (compartido)

 Principal:
 ----------
 CPU: 8 cores
 RAM: 12 GB
 Disco: 100 GB

Total de servidores con bases de datos históricas independientes: 17.

Total de servidores con bases de datos históricas combinadas: 13.

Para combinar todas las bases de datos históricas (4) en un solo equipo, deberá redimensionar sus características para asumir la carga extra:

 Histórico combinado:
 --------------------
 CPU: 8 cores
 RAM: 12 GB
 Disco: 1200 GB

Alta disponibilidad del Servidor de Datos

Lo más sencillo es utilizar la propia HA implementada en los agentes (que permiten contactar con un servidor alternativo si el principal no contesta). Sin embargo, dado que el servidor de datos atiende por el puerto 41121 y es un puerto TCP estándar, es posible usar cualquier solución comercial que permita balancear o clusterizar un servicio TCP ordinario.

Para el servidor de datos de Pandora FMS necesitará montar dos máquinas con un Pandora FMS data server configurado (y diferente hostname y nombre del servidor). Habrá que configurar un servidor Tentacle en cada uno de ellos. Cada máquina tendrá una dirección IP diferente. Si va a utilizar un balanceador externo, éste proveerá una única dirección IP a la que los agentes se conectarán para enviar sus datos.

Si está usando un balanceador externo, y uno de los servidores falla, el mecanismo de HA habilita uno de los servidores activos disponibles y los agentes de Pandora FMS seguirán conectándose con la misma dirección que hacían antes, sin notar el cambio, pero en este caso, el balanceador de carga ya no enviará los datos al servidor que ha fallado, sino a otro servidor activo.

No hay necesidad de cambiar nada en cada servidor de datos de Pandora FMS, incluso cada servidor puede mantener su propio nombre: esto es útil para saber si se ha caído alguno en la vista de estado de servidores. Los módulos de datos de Pandora FMS pueden ser procesados por cualquier servidor sin que sea necesaria una preasignación. Está diseñado precisamente así para poder implementar HA de una forma más fácil.

En el caso de usar el mecanismo de HA de los agentes, existirá un pequeño retardo en el envío de datos, ya que a cada ejecución del agente, este intentará conectar con el servidor primario, y si no contesta, lo hará contra el secundario (si se ha configurado así). Esto se describe a continuación como “Balanceo en los agentes Software”.

Si se quieren utilizar dos servidores de datos y que ambos manejen políticas, colecciones, y configuraciones remotas, habrá que compartir los directorios clave para que todas las instancias del data server puedan leer y escribir sobre dichos directorios. Las consolas también deberán tener acceso a dichos directorios compartidos.

  • /var/spool/pandora/data_in/conf
  • /var/spool/pandora/data_in/collections
  • /var/spool/pandora/data_in/md5
  • /var/spool/pandora/data_in/netflow
  • /var/www/html/pandora_console/attachment

Alta disponibilidad en los Agentes Software

Desde los Agentes Software es posible realizar un balanceo de servidores de datos ya que es posible configurar un servidor de datos master (principal) y otro de backup (respaldo operativo). En el fichero de configuración del Agente Software pandora_agent.conf se debe configurar y descomentar la siguiente parte del archivo de configuración del agente:

 # Secondary server configuration
 # ==============================
 # If secondary_mode is set to on_error, data files are copied to the secondary
 # server only if the primary server fails. If set to always, data files are
 # always copied to the secondary server
 secondary_mode on_error
 secondary_server_ip localhost
 secondary_server_path /var/spool/pandora/data_in
 secondary_server_port 41121
 secondary_transfer_mode tentacle
 secondary_server_pwd mypassword
 secondary_server_ssl no
 secondary_server_opts

Existen las siguientes opciones (para más información, consultar el capítulo de configuración de los Agentes Software).

  • secondary_mode: Modo en el que debe estar el servidor secundario. Puede tener dos valores:
    • on_error: Envía datos al servidor secundario solo si no puede enviarlas al primario.
    • always: Siempre envía datos al servidor secundario, independientemente si puede contactar o no con el servidor principal.
  • secondary_server_ip: Dirección IP del servidor secundario.
  • secondary_server_path: Ruta donde se copian los XML en el servidor secundario, habitualmente /var/spool/pandora/data_in .
  • secondary_server_port: Puerto por el que se copiaran los XML al servidor secundario, en Tentacle 41121, en SSH el puerto 22 y en FTP 21.
  • secondary_transfer_mode: Modo de transferencia que se usará para copiar los XML al servidor secundario, Tentacle, SSH, FTP.
  • secondary_server_pwd: Opción de contraseña para la transferencia por FTP.
  • secondary_server_ssl: Se pondrá yes o no según se quiera usar SSL para transferir los datos por Tentacle.
  • secondary_server_opts: En este campo se pondrán otras opciones necesarias para la transferencia.

Solo está operativa la configuración remota del Agente Software, en el caso de estar habilitada, en el servidor principal.

Alta disponibilidad de los servidores de Red, WMI, plugin, web, prediction y similares

Necesita instalar múltiples servidores: servidor de red, servidor WMI, servidor de Plugin, servidor Web o prediction, en varias máquinas de la red (todas con la misma visibilidad de cara hacia los sistemas que se quieran monitorizar) y que todas estén en el mismo segmento (para que los datos de latencia de la red sean coherentes).

Los servidores se pueden marcar como primarios. Esos servidores automáticamente recogerán los datos de todos los módulos asignados a un servidor que esté marcado como “caído”. Los propios servidores de Pandora FMS implementan un mecanismo para detectar que uno de ellos se ha caído a través de una verificación de su última fecha de contacto (server threshold x 2). Basta que exista un solo servidor de Pandora FMS activo para que pueda detectar la caída del resto. Si se “caen” todos los servidores de Pandora FMS, no existe forma de detectar o implementar HA.

La forma evidente de implementar HA y un balanceo de carga, en un sistema de dos nodos es asignar el 50% de los módulos a cada servidor y marcar ambos servidores como principales (Master). En el caso de haber más de dos servidores principales y un tercer servidor caído con módulos pendientes de ejecutar, el primero de los servidores principales que ejecute el módulo se “autoasigna” el módulo del servidor caído. En caso de recuperación de uno de los servidores caídos, se vuelven a asignar automáticamente los módulos que se habían asignado al servidor primario.

El balanceo de carga entre los distintos servidores se realiza en la parte de administración del agente, en el icono Setup.

En el campo Server hay un combo donde se elige el servidor que realizará los chequeos.

Configuración en los servidores

Un servidor de Pandora FMS puede estar corriendo en dos modos diferentes:

  • Modo maestro (modo principal o modo MASTER).
  • Modo no maestro.

Si un servidor se “cae” (está fuera de línea), sus módulos serán ejecutados por el servidor maestro de modo que no se pierdan datos.

En un momento dado solo puede haber un servidor maestro que se elige entre los servidores que tengan la opción de configuración master en /etc/pandora/pandora_server.conf con un valor mayor que 0:

master [1..7]

Si el servidor maestro actual se cae, se elige un nuevo maestro. Si hay más de un candidato, se elige aquel que tenga un valor mas alto en master.

Tenga cuidado al deshabilitar servidores. Si un servidor con módulos de red se cae y el Servidor de Red del servidor maestro está deshabilitado, esos módulos no se ejecutarán.

Por ejemplo, si tiene tres servidores de Pandora FMS con master a 1, se elegirá un servidor maestro de forma aleatoria y los otros dos se ejecutarán en modo no maestro. Si el servidor maestro se cae, se elegirá un nuevo maestro de forma aleatoria.

Dentro de pandora_server.conf se han introducido los siguientes parámetros:

  • ha_file: Dirección del fichero binario temporal del HA.
  • ha_pid_file: Proceso actual del HA.
  • pandora_service_cmd: Control de estado del servicio de Pandora FMS.

Alta disponibilidad de la consola de Pandora FMS

Sólo hay que instalar otra consola apuntando a la base de datos. Cualquiera de las consolas podrá usarse de forma simultánea desde diferentes ubicaciones por diferentes usuarios. Se puede usar un balanceador de carga web delante de las consolas en caso de necesitar un crecimiento horizontal para el reparto de carga en la consola. El sistema de sesiones se gestiona mediante cookies y estas quedan almacenada en el navegador.

En el caso de estar utilizando configuración remota y para gestionarlo desde todas las consolas, tanto los servidores de datos como las consolas deben compartir el directorio de datos de entrada (por defecto: /var/spool/pandora/data_in) para la configuración remota de los agentes, las colecciones y otros directorios.

En esta guía se indica cómo compartir estos directorios con NFS y con GlusterFS.

Es importante solo compartir los subdirectorios dentro de data_in y no el propio data_in ya que afectaría negativamente el rendimiento del servidor.

Actualización

A la hora de actualizar la consola de Pandora FMS en un entorno de Alta Disponibilidad es importante tener en cuenta las siguientes consideraciones al actualizar mediante OUM a través de Update ManagerUpdate Manager offline .

Los usuarios de la versión Enterprise podrán descargar el paquete OUM desde la web de soporte de Pandora FMS.

Al estar en un entorno balanceado con una base de datos compartida, la actualización de la primera consola aplica los cambios correspondientes en la base de datos. Esto provoca que al actualizar la segunda consola, Pandora FMS muestre un error al encontrar la información ya insertada en la base de datos. No obstante, la actualización de la consola quedará realizada de igual forma.

Alta disponibilidad en la Base de datos

El objetivo de este apartado es ofrecer una solución completa para HA en entornos de Pandora FMS. Éste es el único modelo HA con soporte oficial para Pandora FMS. Esta solución se proporciona -preinstalada- desde OUM 724. Este sistema reemplaza DRBD y otros sistemas HA recomendados en el pasado.

Esta es la primera implementación de DB HA de Pandora FMS y el proceso de instalación es manual casi en su totalidad, usando la consola GNU/Linux como root. En versiones futuras facilitaremos la configuración desde la interfaz gráfica ( GUI ).

Pandora FMS se fundamenta en una base de datos MySQL para configurar y almacenar datos. Un fallo en la base de datos puede paralizar momentáneamente la herramienta de monitorización. El clúster de la base de datos de alta disponibilidad de Pandora FMS permite desplegar fácilmente una arquitectura robusta y tolerante a los fallos.

Se trata de una característica avanzada que requiere conocimientos en sistemas GNU/Linux.

Los recursos de clúster se gestionan con Pacemaker, un gestor de recursos de clúster de alta disponibilidad avanzado y escalable. Corosync proporciona un modelo de comunicación de grupo de proceso cerrado para crear máquinas de estado replicadas. Se eligió a Percona como RDBMS por defecto por su escalabilidad, disponibilidad, seguridad y características de backup.

El replication activo/pasivo se desarrolla desde un nodo maestro único (con permiso de escritura) a cualquier número de secundarios (sólo lectura). Una dirección IP virtual siempre lleva al maestro actual. Si falla el nodo maestro, uno de los secundarios asciende a maestro y se actualiza la dirección IP virtual en consecuencia.

La herramienta de base de datos HA de Pandora FMS, pandora_ha, monitoriza el clúster y se asegura de que el servidor de Pandora FMS está en continuo funcionamiento, reiniciándolo en caso necesario. pandora_ha se monitoriza a su vez con systemd.

Se recomienda mantener 15 días de datos y eventos como máximo, para guardar durante más tiempo se debe configurar una base de datos histórico. Consulte, además, el tema “Gestión y administración de los servidores PFMS”.

Instalación para RHEL 8 y Rocky Linux 8

Version 760 o posterior.

En este ejemplo se configurará un clúster de dos nodos, con los hosts: node1 y node2.

Cambie los nombres de host, contraseñas, etcétera según necesite para que concuerde con el entorno a implementar.

Los comandos que tengan que ejecutarse en un nodo cualquiera tendrá la siguiente sintaxis (ejemplo para node1):

node1#
<command>
<command>
<command>

Los comandos que tengan que ejecutarse en todos los nodos irán precedidos de la palabra all:

all#
<command>
<command>
<command>

Además hay un host adicional denominado pandorafms en el que se se instalará Pandora FMS. Cuando se referencie all solo se refiere a los nodos de base de datos, el nodo adicional Pandora FMS siempre se referenciará como pandorafms y no forma parte de all.

Requisitos previos

Se debe instalar RHEL versión 8 o Rocky Linux versión 8 en todos los hosts, y deben poder resolver los hostnames de los demás hosts.

Se debe instalar y ejecutar un servidor OpenSSH en cada host. Suprima el aviso que muestra OpenSSH:

all#
[ -f /etc/cron.hourly/motd_rebuild ] && rm -f
/etc/cron.hourly/motd_rebuild sed -i -e 's/^Banner.*//g' /etc/ssh/sshd_config
systemctl restart sshd


La herramienta de base de datos HA de Pandora FMS no funcionará correctamente si OpenSSH tiene un aviso configurado.

Genere nuevas claves de autenticación SSH para cada host y copie la clave pública para cada uno de los hosts.


Se pueden generar claves para un usuario que no sea root para una posterior instalación de clúster con usuario “no root”.

all#
printf "\n\n\n" | ssh-keygen -t rsa -P ''
ssh-copy-id -p22 [email protected]
ssh-copy-id -p22 [email protected]
pandorafms#
printf "\n\n\n" | ssh-keygen -t rsa -P ''
ssh-copy-id -p22 [email protected]
ssh-copy-id -p22 [email protected]

En el nodo de Pandora FMS, copie el par de claves a los directorios httpd y ssh. La consola de Pandora FMS (httpd) necesita recuperar el estado del clúster:

pandorafms#
cp -r /root/.ssh/ /usr/share/httpd/
chown -R apache:apache /usr/share/httpd/.ssh/


Los siguientes pasos son necesarios solo si los nodos ejecutan SSH en un puerto no estándar.

Debe sustituir 22 con el número de puerto que usted utilice:

all#
echo -e "Host node1\n Port 22">> /root/.ssh/config
echo -e "Host node2\n Port 22">> /root/.ssh/config

Se debe probar la autenticaccion sin contraseña desde cada nodo hacia los demás:

all#
ssh node1
ssh node2
pandorafms#
ssh node1
ssh node2

Instalación de Percona

Instale el paquete necesario:

all#
dnf install dnf-utils \
 https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm \
 https://repo.percona.com/yum/percona-release-latest.noarch.rpm"

dnf module disable -y mysql

dnf install -y Percona-Server-server-57 percona-xtrabackup-24

Para más información respecto al proceso de instalación de Percona puede consultar la documentación oficial del producto:


Una vez instalados los paquetes, asegúrese de que el servicio Percona está desactivado, ya que lo gestionará el clúster:

all#
systemctl disable mysqld


Si el servicio del sistema no está desactivado, el gestor de recursos del clúster no funcionará correctamente.


A continuación, inicie el servidor Percona:

all#
systemctl start mysqld

Se generará una nueva contraseña temporal conectada a /var/log/mysqld.log. Conéctese al servidor Percona y cambie la contraseña de root:

all#
export MYSQL_PWD=$(grep "temporary password" /var/log/mysqld.log | rev | cut -d' ' -f1 | rev)

echo """
  SET PASSWORD FOR 'root'@'localhost' = PASSWORD('Pandor4!');
  UNINSTALL PLUGIN validate_password;
  SET PASSWORD FOR 'root'@'localhost' = PASSWORD('pandora');
  """ | mysql --connect-expired-password -uroot

A la hora de llevar a cabo la configuración de MySQL se podrá realizar mediante el siguiente autogenerador, que ya está incluido en el paquete de instalación del server Enterprise de Pandora FMS y la ISO de Pandora FMS por defecto.

Una vez instalado el server, encontrará el generador de configuración para la replicación de base de datos en la ruta:

/usr/share/pandora_server/util/myconfig_ha_gen.sh
Example: ./myconfig_ha_gen.sh -i serverid [-l file_location] [-d database] [-b binlog] [-u dbuser] [-p dbpass] [-s poolsize] [-h help]
Mandatory parameters:
    -i --serverid Set the server id for the database (Mandatory)
Optional parameters:
    -l --location Set my.cnf custom location including filename. [ default value: /etc/my.cnf ] (optional)
    -d --database Set the database to be replicated. [ default value: pandora ] (optional)
    -b --binlog Set binlog file. [ default value: mysql-bin ] (optional)
    -u --dbuser Set dbuser for mysql connection and backups. [ default value: root ] (optional)
    -p --dbpass Set dbpassword for mysql connection and backups. [ default value: pandora ] (optional)
    -s --poolsize Set innodb_buffer_pool_size static size in M (Megabytes) or G (Gigabytes). [ default value: autocalculated ] (optional)
    -h --help Print help.

En el caso actual en que las bases de datos no están en el mismo servidor que la aplicación, será necesario copiar el script a los nodos para ser ejecutados localmente.

pandorafms#
scp /usr/share/pandora_server/util/myconfig_ha_gen.sh [email protected]:/root/
scp /usr/share/pandora_server/util/myconfig_ha_gen.sh [email protected]:/root/

Solo será necesario pasar el parámetro serverid (obligatorio) en entornos estándar o desplegados con la ISO y algunos parámetros opcionales para entornos personalizados.

Si el usuario por defecto o el definido no conecta a la base de datos, el script finalizará dando un error de conexión.

También se tiene la posibilidad de pasar como argumentos nombre de la base de datos, el usuario y la contraseña. De no hacerlo se usarán los configurados por defecto.

Para este caso ejecutará en ambos nodos el script únicamente pasando el server id si tiene las credenciales por defecto, en caso contrario deberá definir los parámetros necesarios.

node1#
/root/myconfig_ha_gen.sh -i 1
node2#
/root/myconfig_ha_gen.sh -i 2


Cada nodo debe tener un identificador único.


Se escribirá el fichero de configuración de Percona en /etc/my.cnf donde estarán definidos el identificador del server y la configuración recomendada para la replicación de base de datos. Debe reiniciar el servicio de mysqld para comprobar que la configuracion se ha aplicado correctamente.

all#
systemctl restart mysqld

Instalación de Pandora FMS

Bien puede realizar una instalación completamente nueva o migrar los datos que tenga de una instancia existente.

Nueva instalación de Pandora FMS

Instale Pandora FMS en la base de datos recién creada. Detenga el servidor de Pandora FMS:

pandorafms#
/etc/init.d/pandora_server stop

A partir de la versión NG 754 dispone de opciones adicionales en el arranque y parada manual de Entornos de Alta Disponibilidad (HA).

Instalación de Pandora FMS existente

Detenga el servidor de Pandora FMS:

pandorafms#
/etc/init.d/pandora_server stop

Haga una copia de seguridad de la base de datos de Pandora FMS y transfiérala al nodo 1:

pandorafms# mysqldump -uroot -ppandora --databases pandora> /tmp/pandoradb.sql scp /tmp/pandoradb.sql node1:/tmp/

Ahora cargue la información a la nueva base de datos en el nodo (en caso de no usar las credenciales ni nombre de base de datos por defecto, cámbielo en el siguiente comando):

node1# mysql -uroot -ppandora pandora -e source "/tmp/pandoradb.sql"

Configuración de la replicación

Otorgue los privilegios necesarios para la replicación con el fin de trabajar en todas las bases de datos:

all#
mysql -uroot -ppandora
  GRANT ALL ON pandora.* TO 'root'@'%' IDENTIFIED BY 'pandora';
  GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'root'@'%' IDENTIFIED BY 'pandora';
  GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'pandora'@'%' IDENTIFIED BY 'pandora';
  GRANT REPLICATION CLIENT, REPLICATION SLAVE, SUPER, PROCESS, RELOAD ON *.* TO 'root'@'localhost' IDENTIFIED BY 'pandora';
  GRANT select ON mysql.user TO 'root'@'%' IDENTIFIED BY 'pandora'; FLUSH PRIVILEGES; quit;

Si la instalación de los nodos de base de datos se realizó desde una ISO de PandoraFMS será necesario borrar la base de datos original del node2. Sólo se necesitará la base de datos del node1, que será la que almacenará la información de ambas máquinas. De esta forma se realizará el balanceo correctamente.


Detenga la base de datos del node2:

node2#
systemctl stop mysqld

Haga una copia de seguridad de la base de datos del primer nodo (node1) y escriba el nombre y la posición del archivo del log maestro (en este ejemplo, mysql-bin.000001 y 785):

node1#
[ -e /root/pandoradb.bak ] && rm -rf /root/pandoradb.bak
innobackupex --no-timestamp /root/pandoradb.bak/
innobackupex --apply-log /root/pandoradb.bak/
rsync -avpP -e ssh /root/pandoradb.bak/ node2:/var/lib/mysql/
cat /root/pandoradb.bak/xtrabackup_binlog_info

Cargue la base de datos en el segundo nodo (node2) y configure para replicar desde el primer nodo (debe configurar MASTER_LOG_FILE y MASTER_LOG_POS a los valores del paso anterior):

node2#
chown -R mysql:mysql /var/lib/mysql
chcon -R system_u:object_r:mysqld_db_t:s0 /var/lib/mysql

systemctl start mysqld

mysql -uroot -ppandora
  CHANGE MASTER TO MASTER_HOST='node1',
  MASTER_USER='root', MASTER_PASSWORD='pandora',
  MASTER_LOG_FILE ='mysql-bin.000001', MASTER_LOG_POS =785;
  START SLAVE;
  SHOW SLAVE STATUS \G

Obtendrá una salida similar a:


Debe asegurarse de que Slave_IO_Running y Slave_SQL_Running muestran Yes. Otros valores pueden ser diferentes a los del ejemplo.

Si todo ha sido correcto salga de la interfaz de base de datos:

#node2
mysql> QUIT

Configuración del clúster de dos nodos

Instale los paquetes necesarios: Para el caso de Rocky Linux™ solo sera necesario ejecutar el siguiente comando.

all#
dnf install -y --enablerepo='ha' chrony epel-release corosync pacemaker pcs

En el caso de RedHat sera necesario habilitar el repositorio rhel-8-for-x86_64-highavailability-rpms desde el subscription manager antes de instalar.

all#
subscription-manager repos --enable=rhel-8-for-x86_64-highavailability-rpms
dnf install -y --enablerepo='rhel-8-for-x86_64-highavailability-rpms' chrony epel-release corosync pacemaker pcs

Ahora defina el fichero de configuración y habilite los servicios de corosync, pscd y chrony (substituto del antiguo ntpd).

all#
cp /etc/corosync/corosync.conf.example /etc/corosync/corosync.conf

systemctl enable chronyd --now

systemctl enable pcsd --now

systemctl enable corosync --now


Es posible que vea un mensaje de error al intentar iniciar el servicio de corosync: eso es porque aún no está configurado, ignore y continúe los siguientes pasos.


Detenga el servidor Percona:

all#
systemctl stop mysqld

Autenticación de todos los nodos en el clúster

Defina la contraseña del usuario hacluster:

all#
echo hapass | passwd hacluster --stdin

Cree e inicie el clúster, estos pasos solo serán necesarios hacerlo en node1:

node1#
pcs host auth node1 node2 -u hacluster -p hapass

pcs cluster setup pandorafms node1 node2 --force

pcs cluster start --all
pcs cluster enable --all

pcs property set stonith-enabled=false

pcs property set no-quorum-policy=ignore

Comprobación del estado del clúster:

node1#
pcs status

Verá una salida similar a:


Ambos nodos deberían estar en línea

( Online: [ node1 node2 ] ).

Otros valores pueden ser diferentes a los del ejemplo.

Instalación del agente de replicación Pacemaker de Percona

Pacemaker se puede descargar manualmente desde la librería PFMS.

En caso de tener acceso a internet se puede instalar ejecutando:

all#
cd /usr/lib/ocf/resource.d/
mkdir percona
cd percona
curl -L -o pacemaker_mysql_replication.zip
https://pandorafms.com/library/wp-content/uploads/2019/12/pacemaker_mysq
l_replication.zip
unzip pacemaker_mysql_replication.zip
rm -f pacemaker_mysql_replication.zip
chmod u+x mysql
cd

Configure los recursos del clúster.

Si se ha modificado la contraseña por defecto utilizada en esta guía para el usuario root de la base de datos, conviene actualizar replication_passwd y test_passwd respectivamente. Los nombres de los recursos del clúster deben ser exactamente los indicados en esta guía ( pandoraip y pandoradb)

Sustituir <VIRT_IP> por la dirección IP virtual de preferencia:

#node1
export VIP='<VIRT_IP>'

pcs resource create pandoradb ocf:percona:mysql config="/etc/my.cnf" \
pid="/var/run/mysqld/mysqld.pid" socket="/var/lib/mysql/mysql.sock" \
replication_user="root" replication_passwd="pandora" max_slave_lag="60" \
evict_outdated_slaves="false" binary="/usr/sbin/mysqld" datadir="/var/lib/mysql" \
test_user="root" test_passwd="pandora" op start interval="0" timeout="60s" \
op stop interval="0" timeout="60s" op promote timeout="120" op demote timeout="120" \
op monitor role="Master" timeout="30" interval="5" on-fail="restart" op monitor role="Slave" \
timeout="30" interval="10"

pcs resource create pandoraip ocf:heartbeat:IPaddr2 ip=$VIP cidr_netmask=24 \
op monitor interval=20s

pcs resource promotable pandoradb meta master-max="1" master-node-max="1" clone-max="2" clone-node-max="1" notify="true" \
globally-unique=" false" target-role="Master" is-managed="true"

pcs constraint colocation add master pandoradb-clone with pandoraip

pcs constraint order promote pandoradb-clone then start pandoraip

sleep 5 ; pcs resource cleanup

Comprobación el estado del clúster:

node1#
pcs status

Verá una salida similar a:


Ambos nodos deberían estar en línea

( Online: [ node1 node2 ] ).

Otros valores pueden ser diferentes a los del ejemplo.

Configuración del clúster de dos nodos con usuario "no root"

Se realizará de manera similar a la anterior.

Se deberá haber copiado las credenciales del usuario, previamente explicado, y se deberán realizar los siguientes pasos:

# All nodes:
useradd <usuario>
passwd <usuario>
usermod -a -G haclient <usuario>

# Enable PCS ACL system
pcs property set enable-acl=true --force

# Create role
pcs acl role create <rol> description="RW role" write xpath /cib

# Create PCS user - Local user
pcs acl user create <usuario> <rol>

# Login into PCS from ALL nodes
su - <usuario>
pcs status
Username: <usuario>
Password: *****

# Wait for 'Authorized' message, ignore output. Wait a second and retry 'pcs status' command

Instalación para RedHat 7 y CentOS 7

Versión 759 o anterior.

En este ejemplo se configurará un clúster de dos nodos, con hosts node1 y node2. Se cambiarán los nombres de host, contraseñas, etc. según lo que necesite para que concuerde con el entorno a implementar.

Los comandos que tengan que ejecutarse en un nodo irán precedidos por el hostname de ese nodo:

node1# <command>

Los comandos que tengan que ejecutarse en todos los nodos irán precedidos de la palabra all:

all# <command>

Hay un host adicional, denominado pandorafms en el que se encuentra o se instalará Pandora FMS.

Cuando se referencie all solo se refiere a los nodos de Base de datos, el nodo adicional Pandora FMS siempre se referenciara como pandorafms y no es parte de all.

Requisitos previos

Se debe instalar CentOS versión 7 en todos los hosts, y deben poder resolver los hostnames de los demás hosts.

 node1# ping node2
 PING node2 (192.168.0.2) 56(84) bytes of data.

 node2# ping node1
 PING node1 (192.168.0.1) 56(84) bytes of data.

 pandorafms# ping node1
 PING node1 (192.168.0.1) 56(84) bytes of data.

 pandorafms# ping node2
 PING node2 (192.168.0.2) 56(84) bytes of data.

Se debe instalar y ejecutar un servidor Open SSH en cada host. Suprimimos el aviso que muestra Open SSH:

all# [ -f /etc/cron.hourly/motd_rebuild ] && rm -f /etc/cron.hourly/motd_rebuild
all# sed -i -e 's/^Banner.*//g' /etc/ssh/sshd_config
all# systemctl restart sshd

La herramienta de base de datos HA de Pandora FMS no funcionará correctamente si Open SSH tiene un aviso configurado.

Generamos nuevas claves de autenticación SSH para cada host y copiamos la clave pública para cada uno de los hosts:

Se pueden generar claves para un usuario que no sea root para una posterior instalación de clúster con usuario “no root”.

node1# echo -e "\n\n\n" | ssh-keygen -t rsa
node1# ssh-copy-id -p22 [email protected]
node1# ssh node2

node2# echo -e "\n\n\n" | ssh-keygen -t rsa
node2# ssh-copy-id -p22 [email protected]
node2# ssh node1

pandorafms# echo -e "\n\n\n" | ssh-keygen -t rsa
pandorafms# ssh-copy-id -p22 [email protected]
pandorafms# ssh-copy-id -p22 [email protected]
pandorafms# ssh node1
pandorafms# ssh node2

En el nodo de Pandora FMS, copiamos el par de claves a /usr/share/httpd/.ssh/. La consola de Pandora FMS necesita recuperar el estado del clúster:

 pandorafms# cp -r /root/.ssh/ /usr/share/httpd/
 pandorafms# chown -R apache:apache /usr/share/httpd/.ssh/

Los siguientes pasos son necesarios solo si los nodos ejecutan SSH en un puerto no estándar. Debe sustituir 22 con el número de puerto correcto:

 all# echo -e "Host node1\n    Port 22">> /root/.ssh/config
 all# echo -e "Host node2\n    Port 22">> /root/.ssh/config

Instalación de Percona

Instale el paquete necesario:

 all# yum install https://repo.percona.com/yum/percona-release-latest.noarch.rpm

 all# yum install -y Percona-Server-server-57 percona-xtrabackup-24

Para más información respecto al proceso de instalación de Percona puede consultar la documentación oficial del producto: https://www.percona.com/doc/percona-server/5.7/installation/yum_repo.html

Una vez instalados los paquetes, asegúrese de que el servicio Percona está desactivado, ya que lo gestionará el clúster:

all# systemctl disable mysqld

Si el servicio del sistema no está desactivado, el gestor de recursos del clúster no funcionará correctamente.

A continuación, inicie el servidor Percona:

all# systemctl start mysqld

Se generará una nueva contraseña temporal conectada a /var/log/mysqld.log. Conéctese al servidor Percona y cambie la contraseña de root:

all# mysql -uroot -p$(grep "temporary password" /var/log/mysqld.log | \
rev | cut -d' ' -f1 | rev)
mysql> SET PASSWORD FOR 'root'@'localhost' = PASSWORD('Pandor4!');
mysql> UNINSTALL PLUGIN validate_password;
mysql> SET PASSWORD FOR 'root'@'localhost' = PASSWORD('pandora');
mysql> quit

A la hora de llevar a cabo la configuración de MySQL se podrá realizar mediante el siguiente autogenerador, que ya está incluido en el paquete de instalación del server Enterprise de Pandora FMS si se instala con el modificador –ha y la ISO de Pandora FMS por defecto.

Recuerde que si se ha instalado el paquete del servidor manualmente, en lugar de usar la ISO, se debe pasar el parámetro –ha para tener acceso a las herramientas del server HA.

En caso de no haberlo hecho solo debe reinstalar el paquete del servidor con el parámetro –ha : En el entorno de ejemplo hay 2 nodos de base de datos (node1 y node2) y un nodo de aplicación (pandorafms), por ello el paquete del servidor de Pandora FMS solo debe instalarse en el nodo de aplicación. Si el nodo de aplicación es instalado con una ISO de Pandora (opción recomendable) este paso no es necesario, de lo contrario debe reinstalarse el paquete del servidor con el flag –ha.

pandorafms# ./pandora_server_installer --install --ha

Una vez instalado el server con las herramientas HA habilitadas, encontrará el generador de configuración para la replicación de base de datos en la ruta: /usr/share/pandora_server/util/myconfig_ha_gen.sh

Example: ./myconfig_ha_gen.sh -i serverid [-l file_location] [-d database] [-b binlog] [-u dbuser] [-p dbpass] [-s poolsize] [-h help]
Mandatory parameters:
       -i --serverid   Set the server id for the database (Mandatory)
Optional parameters:
       -l --location   Set my.cnf custom location including filename. [ default value: /etc/my.cnf ] (optional)
       -d --database   Set the database to be replicated. [ default value: pandora ] (optional)
       -b --binlog     Set binlog file. [ default value: mysql-bin ] (optional)
       -u --dbuser     Set dbuser for mysql connection and backups. [ default value: root ] (optional)
       -p --dbpass     Set dbpassword for mysql connection and backups. [ default value: pandora ] (optional)
       -s --poolsize   Set innodb_buffer_pool_size static size in M (Megabytes) or G (Gigabytes). [ default value: autocalculated ] (optional)
       -h --help       Print help.

En el caso actual en que las bases de datos no están en el mismo servidor que la aplicación, será necesario copiar el script a los nodos para ser ejecutados localmente.

pandorafms# scp /usr/share/pandora_server/util/myconfig_ha_gen.sh [email protected]:/root/
pandorafms# scp /usr/share/pandora_server/util/myconfig_ha_gen.sh [email protected]:/root/

Solo será necesario pasar el parámetro serverid (obligatorio) en entornos estándar o desplegados con la ISO y algunos parámetros opcionales para entornos personalizados.

Si el usuario por defecto o el definido no conecta a la base de datos, el script finalizará dando un error de conexión.

También se tiene la posibilidad de pasar como argumentos la base de datos, el usuario y la contraseña. De no hacerlo se usarán los configurados por defecto.

Para este caso ejecutará en ambos nodos el script solo pasando el server id si tenemos las credenciales por defecto, en caso contrario definir los parámetros necesarios.

 node1# /root/myconfig_ha_gen.sh -i 1
 node2# /root/myconfig_ha_gen.sh -i 2

Importante: Cada nodo debe tener un identificador único

Se escribirá el fichero de configuración de Percona en /etc/my.cnf donde estarán definidos el identificador del server y la configuración recomendada para la replicación de base de datos.

Debe reiniciar el servicio de mysqld para comprobar que la configuracion se ha aplicado correctamente.

all# systemctl restart mysqld

Instalación de Pandora FMS

Nueva instalación de Pandora FMS

Instale Pandora FMS en la base de datos recién creada. Detenga el servidor de Pandora FMS:

pandorafms# /etc/init.d/pandora_server stop


A partir de la versión NG 754 dispone de opciones adicionales en el arranque y parada manual de Entornos de Alta Disponibilidad (HA).

Instalación de Pandora FMS existente

Detenga el servidor de Pandora FMS:

pandorafms# /etc/init.d/pandora_server stop

Haga una copia de seguridad de la base de datos de Pandora FMS:

 pandorafms# mysqldump -uroot -ppandora --databases pandora> /tmp/pandoradb.sql
 pandorafms# scp /tmp/pandoradb.sql node1:/tmp/

Ahora cargue la información a la nueva base de datos:

node1# mysql -uroot -ppandora pandora -e source "/tmp/pandoradb.sql"

Configuración de la replicación

Otorgue los privilegios necesarios para la replicación con el fin de trabajar en todas las bases de datos:

all# mysql -uroot -ppandora
mysql> GRANT ALL ON pandora.* TO 'root'@'%' IDENTIFIED BY 'pandora';
mysql> GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.*
TO 'root'@'%' IDENTIFIED BY 'pandora';
mysql> GRANT REPLICATION CLIENT, REPLICATION SLAVE, SUPER, PROCESS, RELOAD ON *.*
TO 'root'@'localhost' IDENTIFIED BY 'pandora';
mysql> GRANT select ON mysql.user TO 'root'@'%' IDENTIFIED BY 'pandora';
mysql> FLUSH PRIVILEGES;
mysql> quit

Haga una copia de seguridad de la base de datos del primer nodo y escriba el nombre y la posición del archivo del log maestro (en el ejemplo,
mysql-bin.000001 y 785):

node1# [ -e /root/pandoradb.bak ] && rm -rf /root/pandoradb.bak
node1# innobackupex --no-timestamp /root/pandoradb.bak/
node1# innobackupex --apply-log /root/pandoradb.bak/
node1# cat /root/pandoradb.bak/xtrabackup_binlog_info
mysql-bin.000001        785

Cargue la base de datos en el segundo nodo y configure para replicar desde el primer nodo (debe configurar MASTER_LOG_FILE y MASTER_LOG_POS a los valores del paso anterior):

Si la instalación de Pandora FMS se realizó desde una ISO será necesario borrar la base de datos original del nodo 2. Sólo se necesitará la base de datos del nodo 1, que será la que almacenará la información de ambas máquinas. De esta forma se realizará el balanceo correctamente.

node2# systemctl stop mysqld

node1# rsync -avpP -e ssh /root/pandoradb.bak/ node2:/var/lib/mysql/

node2# chown -R mysql:mysql /var/lib/mysql
node2# chcon -R system_u:object_r:mysqld_db_t:s0 /var/lib/mysql
node2# systemctl start mysqld
node2# mysql -uroot -ppandora
mysql> CHANGE MASTER TO MASTER_HOST='node1',
MASTER_USER='root', MASTER_PASSWORD='pandora',
MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=785;
mysql> START SLAVE;
mysql> SHOW SLAVE STATUS \G
   *************************** 1. row ***************************
                  Slave_IO_State: Waiting for master to send event
                     Master_Host: node1
                     Master_User: root
                     Master_Port: 3306
                   Connect_Retry: 60
                 Master_Log_File: mysql-bin.000002
             Read_Master_Log_Pos: 785
                  Relay_Log_File: node2-relay-bin.000003
                   Relay_Log_Pos: 998
           Relay_Master_Log_File: mysql-bin.000002
                Slave_IO_Running: Yes
               Slave_SQL_Running: Yes
                 Replicate_Do_DB: pandora
             Replicate_Ignore_DB:
              Replicate_Do_Table:
          Replicate_Ignore_Table:
         Replicate_Wild_Do_Table:
     Replicate_Wild_Ignore_Table:
                      Last_Errno: 0
                      Last_Error:
                    Skip_Counter: 0
             Exec_Master_Log_Pos: 785
                 Relay_Log_Space: 1252
                 Until_Condition: None
                  Until_Log_File:
                   Until_Log_Pos: 0
              Master_SSL_Allowed: No
              Master_SSL_CA_File:
              Master_SSL_CA_Path:
                 Master_SSL_Cert:
               Master_SSL_Cipher:
                  Master_SSL_Key:
           Seconds_Behind_Master: 0
   Master_SSL_Verify_Server_Cert: No
                   Last_IO_Errno: 0
                   Last_IO_Error:
                  Last_SQL_Errno: 0
                  Last_SQL_Error:
     Replicate_Ignore_Server_Ids:
                Master_Server_Id: 1
                     Master_UUID: 580d8bb0-6991-11e8-9a22-16efadb2f150
                Master_Info_File: mysql.slave_master_info
                       SQL_Delay: 0
             SQL_Remaining_Delay: NULL
         Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
              Master_Retry_Count: 86400
                     Master_Bind:
         Last_IO_Error_Timestamp:
        Last_SQL_Error_Timestamp:
                  Master_SSL_Crl:
              Master_SSL_Crlpath:
              Retrieved_Gtid_Set:
               Executed_Gtid_Set:
                   Auto_Position: 0
            Replicate_Rewrite_DB:
                    Channel_Name:
              Master_TLS_Version:
   1 row in set (0.00 sec)
mysql> QUIT

Debe asegurarse de que Slave_IO_Running y Slave_SQL_Running muestran Yes. Otros valores pueden ser diferentes a los del ejemplo.

Se recomienda no utilizar usuario root para la realización de este proceso. Es aconsejable dar permisos a otro usuario encargado de gestionar la base de datos para evitar posibles conflictos.

Configuración del clúster de dos nodos

Instale los paquetes necesarios:

 all# yum install -y epel-release corosync ntp pacemaker pcs

 all# systemctl enable ntpd
 all# systemctl enable corosync
 all# systemctl enable pcsd
 all# cp /etc/corosync/corosync.conf.example /etc/corosync/corosync.conf
 all# systemctl start ntpd
 all# systemctl start corosync
 all# systemctl start pcsd

Detenga el servidor Percona:

node1# systemctl stop mysqld
node2# systemctl stop mysqld
Autenticación de todos los nodos en el clúster

Crear e iniciar el clúster:

all# echo hapass | passwd hacluster --stdin
node1# pcs cluster auth -u hacluster -p hapass --force node1 node2
node1# pcs cluster setup --force --name pandoraha node1 node2
node1# pcs cluster start --all
node1# pcs cluster enable --all
node1# pcs property set stonith-enabled=false
node1# pcs property set no-quorum-policy=ignore

Comprobación el estado del clúster:

node#1 pcs status
   Cluster name: pandoraha
   Stack: corosync
   Current DC: node1 (version 1.1.18-11.el7_5.2-2b07d5c5a9) - partition with quorum
   Last updated: Fri Jun  8 12:53:49 2018
   Last change: Fri Jun  8 12:53:47 2018 by root via cibadmin on node1

   2 nodes configured
   0 resources configured

   Online: [ node1 node2 ]

   No resources

   Daemon Status:
     corosync: active/disabled
     pacemaker: active/disabled
     pcsd: active/enabled

Ambos nodos deberían estar online
( Online: [ node1 node2 ] ).
Otros valores pueden ser diferentes a los del ejemplo.

Instalación del agente de replicación Pacemaker de Percona

Se puede descargar manualmente desde nuestra librería PFMS.

all# cd /usr/lib/ocf/resource.d/
all# mkdir percona
all# cd percona
all# curl -L -o pacemaker_mysql_replication.zip https://pandorafms.com/library/wp-content/uploads/2019/12/pacemaker_mysql_replication.zip
all# unzip pacemaker_mysql_replication.zip
all# rm -f pacemaker_mysql_replication.zip
all# chmod u+x mysql

Configure los recursos del clúster. Sustituir <VIRT_IP> por la dirección IP virtual de preferencia:

Si se ha modificado la contraseña por defecto utilizada en esta guía para el usuario root de la base de datos, conviene actualizar replication_passwd y test_passwd respectivamente.

Los nombres de los recursos del clúster deben ser exactamente los indicados en esta guía ( pandoraip y pandoradb)

node1# export VIP='<VIRT_IP>'

node1# pcs resource create pandoradb ocf:percona:mysql config="/etc/my.cnf" \
pid="/var/run/mysqld/mysqld.pid" socket="/var/lib/mysql/mysql.sock" \
replication_user="root" replication_passwd="pandora" max_slave_lag="60" \
evict_outdated_slaves="false" binary="/usr/sbin/mysqld" datadir="/var/lib/mysql" \
test_user="root" test_passwd="pandora" op start interval="0" timeout="60s" \
op stop interval="0" timeout="60s" op promote timeout="120" op demote timeout="120" \
op monitor role="Master" timeout="30" interval="5" on-fail="restart" op monitor role="Slave" \
timeout="30" interval="10"
node1# pcs resource create pandoraip ocf:heartbeat:IPaddr2 ip=$VIP cidr_netmask=24 \
op monitor interval=20s
node1# pcs resource master master_pandoradb pandoradb meta master-max="1" \
master-node-max="1" clone-max="2" clone-node-max="1" notify="true" \
globally-unique="false" target-role="Master" is-managed="true"
node1# pcs constraint colocation add master master_pandoradb with pandoraip
node1# pcs constraint order promote master_pandoradb then start pandoraip

Comprobación el estado del clúster:

node1# pcs status
   Cluster name: pandoraha
   Stack: corosync
   Current DC: node1 (version 1.1.18-11.el7_5.2-2b07d5c5a9) - partition with quorum
   Last updated: Fri Jun  8 13:02:21 2018
   Last change: Fri Jun  8 13:02:11 2018 by root via cibadmin on node1

   2 nodes configured
   3 resources configured

   Online: [ node1 node2 ]

   Full list of resources:

    Master/Slave Set: master_pandoradb [pandoradb]
        Masters: [ node1 ]
        Slaves: [ node2 ]
    pandoraip      (ocf::heartbeat:IPaddr2):       Started node1

   Daemon Status:
     corosync: active/disabled
     pacemaker: active/disabled
     pcsd: active/enabled

Ambos nodos deberían estar online
( Online: [ node1 node2 ] ).
Otros valores pueden ser diferentes a los del ejemplo.

Configuración del clúster de dos nodos con usuario "no root"

Se realizará de manera similar a la anterior. Se deberá haber copiado las credenciales del usuario, previamente explicado, y se deberán realizar los siguientes pasos:

# All nodes:
 useradd <usuario>
 passwd <usuario>
 usermod -a -G haclient <usuario>
# Enable PCS ACL system
pcs property set enable-acl=true --force
# Create role
pcs acl role create <rol> description="RW role"  write xpath /cib
 # Create PCS user - Local user
 pcs acl user create <usuario> <rol>
 # Login into PCS from ALL nodes
 su - <usuario>
 pcs status
 Username: <usuario>
 Password: *****
# Wait for 'Authorized' message, ignore output. Wait a second and retry 'pcs status' command

Configuración de Pandora FMS

Asegúrese de que php-pecl-ssh2 esté instalado según el SO y versión que tenga instalado:

RHEL 8

 pandorafms# dnf install --disablerepo=rhel-8-for-x86_64-appstream-rpms php-pecl-ssh2
 pandorafms# systemctl restart php-fpm
 pandorafms# systemctl restart httpd

Rocky Linux 8

 pandorafms# dnf install php-pecl-ssh2
 pandorafms# systemctl restart php-fpm
 pandorafms# systemctl restart httpd

CentOS 7

 pandorafms# yum install php-pecl-ssh2
 pandorafms# systemctl restart httpd

Hay dos parámetros en /etc/pandora/pandora_server.conf que controlan el comportamiento de la herramienta HA de la base de datos de Pandora FMS. Se pueden modificar para adaptarlos a las necesidades de cada caso:

# Pandora FMS Database HA Tool execution interval in seconds (PANDORA FMS ENTERPRISE ONLY).
ha_interval 30

# Pandora FMS Database HA Tool monitoring interval in seconds. Must be a multiple of ha_interval (PANDORA FMS ENTERPRISE ONLY).
ha_monitoring_interval 60

Direccionar Pandora FMS a la dirección IP virtual del maestro (sustituyendo <IP> por la dirección IP virtual):

pandorafms# export VIRT_IP=<IP>
pandorafms# sed -i -e "s/^dbhost .*/dbhost $VIRT_IP/" \
/etc/pandora/pandora_server.conf
pandorafms# sed -i -e "s/\$config\[\"dbhost\"\]=\".*\";/\$config[\"dbhost\"]=\"$VIRT_IP\";/" \
/var/www/html/pandora_console/include/config.php

Inicie sesión en la consola de Pandora FMS, navegue hasta Servers → Manage database HA:

Haga clic en Add new node y cree una entrada para el primer nodo:

Después, haga clic en Register y añada una nueva entrada en el segundo nodo. Debería aparecer algo parecido a:

Seconds_Behind_Master debería estar cerca de cero 0. Si sigue aumentando, la replicación se realiza con velocidad inadecuada o simplemente está detenida. Si desea conocer más información (en general) sobre réplicas de bases de datos, consulte nuestro blog.“

Recuperación automática de nodos en Splitbrain

Escenario inicial.

Ambos servidores están como principales o master, en la vista HA de la consola aparecen como Master ambos pero la IP Virtual solo se encuentra en un nodo ( el que realmente está actuando como master).

En este momento, si está habilitado el token splitbrain_autofix a 1 se inciará el proceso de recuperación del nodo en splitbrain.

Para el correcto funcionamiento de esta funcionalidad deben encontrarse los siguientes componentes correctamente configurados:

  • Claves SSH de usuario root compartidas entre el servidor pandora_ha master y todos los servidores de bases de datos.
  • Usuario replicador configurado en el setup de Pandora HA con derechos o grants desde el servidor donde de aloje el servidor pandora_ha master .

  • Espacio disponible para realizar el respaldo o backup de la base de datos en ambos servidores donde se encuentren alojadas las 2 bases de datos ( principal y secundario o Master y Slave ).

En el caso de que el datadir y el path donde se debe realizar la partición estén en la misma partición es necesario que el espacio libre sea al menos del 50%.

Si todos los puntos anteriores se encuentran correctamente configurados, el proceso que realiza para su recuperación es el siguiente:

  1. Borra los backups anteriores.
  2. Realiza backup del datadir del nodo Slave.
  3. Realiza backup del nodo Master.
  4. Envía backup del nodo Master a Slave.
  5. Inicia el recurso del nodo “slave” con los parámetros de resincronización correspondientes en el momento del backup.
  6. Realiza la comprobación de que el recurso está activo y es correcto. Para ello hará uso de la configuración indicada en los parámetros ha_max_resync_wait_retries y ha_resync_sleep .

En el caso de que falle algún punto en el proceso volverá a repetirlo las veces indicadas mediante el parámetro ha_max_splitbrain_retries.

Una vez finalizado el proceso aparecerá un evento indicando que el proceso se ha completado correctamente tanto en la vista de eventos.

Si pese a ello no se recupera automáticamente el entorno, dejará el nodo Slave en Standby y aparecerá un evento indicando que debe realizarse manualmente la recuperación en la vista de eventos.

Añadir un nuevo nodo al clúster

Repita los pasos realizados para instalar node1 y node2, dependiendo de la versión que va a utilizar en el nuevo nodo:

RHEL 8 o Rocky Linux 8 (PFMS versión 760 o posterior).

RedHat 7 o CentOS 7 (PFMS versión 759 o anterior).

Suprima el banner o aviso que muestra Open SSH:

node3# [ -f /etc/cron.hourly/motd_rebuild ] && rm -f /etc/cron.hourly/motd_rebuild
node3# sed -i -e 's/^Banner.*//g' /etc/ssh/sshd_config
node3# systemctl restart sshd

Genere nuevas claves de autenticación SSH para el nuevo host y copie la clave pública para cada uno de los hosts:

Se pueden generar claves para un usuario que no sea root para la instalación del clúster con usuario “no root”.

 node1# ssh-copy-id -p22 [email protected]
 node1# ssh node3
 node2# ssh-copy-id -p22 [email protected]
 node2# ssh node3
 pandorafms# ssh-copy-id -p22 [email protected]
 pandorafms# ssh node3
 node3# echo -e "\n\n\n" | ssh-keygen -t rsa
 node3# ssh-copy-id -p22 [email protected]
 node3# ssh-copy-id -p22 [email protected]
 node3# ssh node1
 node3# ssh node2

En el nodo de Pandora FMS, copie el fichero known_hosts para el usuario apache:

pandorafms# yes | cp /root/.ssh/known_hosts /usr/share/httpd/.ssh/

Los siguientes pasos son necesarios solo si los nodos ejecutan SSH en un puerto no estándar. Sustituya 22 con el número de puerto correcto:

 all# echo -e "Host node1\n    Port 22">> /root/.ssh/config
 all# echo -e "Host node2\n    Port 22">> /root/.ssh/config
 all# echo -e "Host node3\n    Port 22">> /root/.ssh/config

Instale los paquetes necesarios:

node3# yum install -y http://www.percona.com/downloads/percona-release/redhat/0.1-4/percona-release-0.1-4.noarch.rpm
node3# yum install -y Percona-Server-server-57 percona-xtrabackup-24

Asegúrese de que el servicio Percona está desactivado, ya que lo gestionará el clúster:

 node3# systemctl stop mysqld
 node3# systemctl disable mysqld

Si el servicio del sistema no está desactivado, el gestor de recursos del clúster no funcionará correctamente.

Configure Percona, sustituyendo <ID> con un número que debe ser único para cada nodo de clúster:

La replicación de la base de datos no funcionará si dos nodos tienen el mismo SERVER_ID.

Una vez instalado el server, encontrará el generador de configuración para la replicación de base de datos en la ruta:

/usr/share/pandora_server/util/myconfig_ha_gen.sh
Example: ./myconfig_ha_gen.sh -i serverid [-l file_location] [-d database] [-b binlog] [-u dbuser] [-p dbpass] [-s poolsize] [-h help]
Mandatory parameters:
    -i --serverid Set the server id for the database (Mandatory)
Optional parameters:
    -l --location Set my.cnf custom location including filename. [ default value: /etc/my.cnf ] (optional)
    -d --database Set the database to be replicated. [ default value: pandora ] (optional)
    -b --binlog Set binlog file. [ default value: mysql-bin ] (optional)
    -u --dbuser Set dbuser for mysql connection and backups. [ default value: root ] (optional)
    -p --dbpass Set dbpassword for mysql connection and backups. [ default value: pandora ] (optional)
    -s --poolsize Set innodb_buffer_pool_size static size in M (Megabytes) or G (Gigabytes). [ default value: autocalculated ] (optional)
    -h --help Print help.

En el caso actual en que las bases de datos no están en el mismo servidor que la aplicación, será necesario copiar el script a los nodos para ser ejecutados localmente.

pandorafms#
scp /usr/share/pandora_server/util/myconfig_ha_gen.sh [email protected]:/root/

Solo será necesario pasar el parámetro serverid (obligatorio) en entornos estándar o desplegados con la ISO y algunos parámetros opcionales para entornos personalizados.

Si el usuario por defecto o el definido no conecta a la base de datos, el script finalizará dando un error de conexión.

También se tiene la posibilidad de pasar como argumentos nombre de la base de datos, el usuario y la contraseña. De no hacerlo se usarán los configurados por defecto.

Para este caso ejecutará en ambos nodos el script únicamente pasando el server id si tiene las credenciales por defecto, en caso contrario deberá definir los parámetros necesarios.

node3#
/root/myconfig_ha_gen.sh -i 3

Inicie el servidor Percona:

node3# systemctl start mysqld

Se generará una nueva contraseña temporal conectada a /var/log/mysqld.log. conéctese al servidor Percona y cambie la contraseña de root:

node3# mysql -uroot -p$(grep "temporary password" /var/log/mysqld.log | \
rev | cut -d' ' -f1 | rev)
mysql> SET PASSWORD FOR 'root'@'localhost' = PASSWORD('Pandor4!');
mysql> UNINSTALL PLUGIN validate_password;
mysql> SET PASSWORD FOR 'root'@'localhost' = PASSWORD('pandora');
mysql> quit

Haga una copia de seguridad de la base de datos del nodo maestro (node1 en este ejemplo) y escriba el nombre y la posición del archivo de log maestro (en el ejemplo, mysql-bin.000001 y 785):

node1# [ -e /root/pandoradb.bak ] && rm -rf /root/pandoradb.bak
node1# innobackupex --no-timestamp /root/pandoradb.bak/
node1# innobackupex --apply-log /root/pandoradb.bak/
node1# cat /root/pandoradb.bak/xtrabackup_binlog_info
mysql-bin.000001        785

Cargue la base de datos en el nuevo nodo, que llamaremos node3, y configure para replicar desde el node1 (configure MASTER_LOG_FILE y MASTER_LOG_POS a los valores del paso anterior):

node3# systemctl stop mysqld

node1# rsync -avpP -e ssh /root/pandoradb.bak/ node3:/var/lib/mysql/

node3# chown -R mysql:mysql /var/lib/mysql
node3# chcon -R system_u:object_r:mysqld_db_t:s0 /var/lib/mysql
node3# systemctl start mysqld
node3# mysql -uroot -ppandora
mysql> CHANGE MASTER TO MASTER_HOST='node1',
MASTER_USER='root', MASTER_PASSWORD='pandora',
MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=785;
mysql> START SLAVE;
mysql> SHOW SLAVE STATUS \G
   *************************** 1. row ***************************
                  Slave_IO_State: Waiting for master to send event
                     Master_Host: node1
                     Master_User: root
                     Master_Port: 3306
                   Connect_Retry: 60
                 Master_Log_File: mysql-bin.000002
             Read_Master_Log_Pos: 785
                  Relay_Log_File: node3-relay-bin.000003
                   Relay_Log_Pos: 998
           Relay_Master_Log_File: mysql-bin.000002
                Slave_IO_Running: Yes
               Slave_SQL_Running: Yes
                 Replicate_Do_DB: pandora
             Replicate_Ignore_DB:
              Replicate_Do_Table:
          Replicate_Ignore_Table:
         Replicate_Wild_Do_Table:
     Replicate_Wild_Ignore_Table:
                      Last_Errno: 0
                      Last_Error:
                    Skip_Counter: 0
             Exec_Master_Log_Pos: 785
                 Relay_Log_Space: 1252
                 Until_Condition: None
                  Until_Log_File:
                   Until_Log_Pos: 0
              Master_SSL_Allowed: No
              Master_SSL_CA_File:
              Master_SSL_CA_Path:
                 Master_SSL_Cert:
               Master_SSL_Cipher:
                  Master_SSL_Key:
           Seconds_Behind_Master: 0
   Master_SSL_Verify_Server_Cert: No
                   Last_IO_Errno: 0
                   Last_IO_Error:
                  Last_SQL_Errno: 0
                  Last_SQL_Error:
     Replicate_Ignore_Server_Ids:
                Master_Server_Id: 1
                     Master_UUID: 580d8bb0-6991-11e8-9a22-16efadb2f150
                Master_Info_File: mysql.slave_master_info
                       SQL_Delay: 0
             SQL_Remaining_Delay: NULL
         Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
              Master_Retry_Count: 86400
                     Master_Bind:
         Last_IO_Error_Timestamp:
        Last_SQL_Error_Timestamp:
                  Master_SSL_Crl:
              Master_SSL_Crlpath:
              Retrieved_Gtid_Set:
               Executed_Gtid_Set:
                   Auto_Position: 0
            Replicate_Rewrite_DB:
                    Channel_Name:
              Master_TLS_Version:
   1 row in set (0.00 sec)
mysql> QUIT

node3# systemctl stop mysqld

Conviene asegurarse de que Slave_IO_Running y Slave_SQL_Running muestran Yes. Otros valores podrían ser diferentes de los del ejemplo.

Instale los paquetes necesarios para el clúster:

 node3# yum install -y epel-release corosync ntp pacemaker pcs

 node3# systemctl enable ntpd
 node3# systemctl enable corosync
 node3# systemctl enable pcsd

 node3# systemctl start ntpd

Añada un nuevo nodo al clúster:

node3# echo -n hapass | passwd hacluster --stdin
node3# cd /usr/lib/ocf/resource.d/
node3# mkdir percona
node3# cd percona
node3# curl -L -o pacemaker_mysql_replication.zip https://pandorafms.com/library/wp-content/uploads/2019/12/pacemaker_mysql_replication.zip
node3# unzip pacemaker_mysql_replication.zip
node3# rm -f pacemaker_mysql_replication.zip
node3# chmod u+x mysql
 node1# pcs cluster auth -u hacluster -p hapass --force node3
 node1# pcs cluster node add --enable --start node3

Configure clone-max al número de nodos del clúster (3 en este ejemplo):

node3# pcs resource update master_pandoradb meta master-max="1" \
master-node-max="1" clone-max="3" clone-node-max="1" notify="true" \
globally-unique="false" target-role="Master" is-managed="true"

Compruebe el estado del nodo:

node3# pcs status
Cluster name: pandoraha
Stack: corosync
Current DC: node1 (version 1.1.18-11.el7_5.2-2b07d5c5a9) - partition with quorum
Last updated: Fri Jun  1 10:55:47 2018
Last change: Fri Jun  1 10:55:09 2018 by root via crm_attribute on node3

3 nodes configured
3 resources configured

Online: [ node1 node2 node3 ]

Full list of resources:

pandoraip      (ocf::heartbeat:IPaddr2):       Started node1
Master/Slave Set: master_pandoradb [pandoradb]
    Masters: [ node1 ]
    Slaves: [ node2 node3 ]

Daemon Status:
 corosync: active/enabled
 pacemaker: active/enabled
 pcsd: active/enabled

Todos los nodos deberían estar online
(Online: [ node1 node2 node3 ]).
Otros valores podrían ser diferentes de los del ejemplo.

Registre el nodo del clúster en la consola de Pandora FMS desde el menú ServersManage database HA.

Reparación de un nodo roto

El node2 funciona como ejemplo. Ponga node2 en modo de espera o standby:

node2# pcs node standby node2
node2# pcs status
    Cluster name: pandoraha
    Stack: corosync
    Current DC: node1 (version 1.1.18-11.el7_5.2-2b07d5c5a9) - partition with quorum
    Last updated: Tue Jun 12 08:20:49 2018
    Last change: Tue Jun 12 08:20:34 2018 by root via cibadmin on node2

    2 nodes configured
    3 resources configured

    Node node2: standby
    Online: [ node1 ]

    Full list of resources:

     Master/Slave Set: master_pandoradb [pandoradb]
         Masters: [ node1 ]
         Stopped: [ node2 ]
     pandoraip      (ocf::heartbeat:IPaddr2):       Started node1

    Daemon Status:
      corosync: active/enabled
      pacemaker: active/enabled
      pcsd: active/enabled

node2 debería estar en standby
(Node node2: standby).
Otros valores podrían ser diferentes de los del ejemplo.

Haga una copia de seguridad del directorio de datos de Percona:

node2# systemctl stop mysqld
node2# [ -e /var/lib/mysql.bak ] && rm -rf /var/lib/mysql.bak
node2# mv /var/lib/mysql /var/lib/mysql.bak

Haga una copia de seguridad de la base de datos del nodo maestro (node1 en este ejemplo) y actualice el nombre del nodo maestro, y el nombre y la posición del archivo de log maestro en el clúster (en este ejemplo node1, mysql-bin.000001 y 785 respectivamente):

node1# [ -e /root/pandoradb.bak ] && rm -rf /root/pandoradb.bak
node1# innobackupex --no-timestamp /root/pandoradb.bak/
node1# innobackupex --apply-log /root/pandoradb.bak/
node1# binlog_info=$(cat /root/pandoradb.bak/xtrabackup_binlog_info)
node1# crm_attribute --type crm_config --name pandoradb_REPL_INFO -s mysql_replication \
-v "node1|$(echo $binlog_info | awk '{print $1}')|$(echo $binlog_info | awk '{print $2}')"

Cargue la base de datos del nodo roto:

 node1# rsync -avpP -e ssh /root/pandoradb.bak/ node2:/var/lib/mysql/

 node2# chown -R mysql:mysql /var/lib/mysql
 node2# chcon -R system_u:object_r:mysqld_db_t:s0 /var/lib/mysql

Desactive el modo standby del node2:

 node2# pcs node unstandby node2
 node2# pcs resource cleanup --node node2

Compruebe el estado del clúster:

node2# pcs status
Cluster name: pandoraha
Stack: corosync
Current DC: node1 (version 1.1.18-11.el7_5.2-2b07d5c5a9) - partition with quorum
Last updated: Fri Jun  1 10:55:47 2018
Last change: Fri Jun  1 10:55:09 2018 by root via crm_attribute on node3

2 nodes configured
3 resources configured

Online: [ node1 node2 ]

Full list of resources:

pandoraip      (ocf::heartbeat:IPaddr2):       Started node1
Master/Slave Set: master_pandoradb [pandoradb]
    Masters: [ node1 ]
    Slaves: [ node2 ]

Daemon Status:
 corosync: active/enabled
 pacemaker: active/enabled
 pcsd: active/enabled

Ambos nodos deberían estar online
(Online: [ node1 node2 ]).
Otros valores podrían ser diferentes de los del ejemplo.

Compruebe el estado de la replicación de la base de datos:

node2# mysql -uroot -ppandora
 mysql> SHOW SLAVE STATUS \G
   *************************** 1. row ***************************
                  Slave_IO_State: Waiting for master to send event
                     Master_Host: node1
                     Master_User: root
                     Master_Port: 3306
                   Connect_Retry: 60
                 Master_Log_File: mysql-bin.000001
             Read_Master_Log_Pos: 785
                  Relay_Log_File: node2-relay-bin.000003
                   Relay_Log_Pos: 998
           Relay_Master_Log_File: mysql-bin.000001
                Slave_IO_Running: Yes
               Slave_SQL_Running: Yes
                 Replicate_Do_DB: pandora
             Replicate_Ignore_DB:
              Replicate_Do_Table:
          Replicate_Ignore_Table:
         Replicate_Wild_Do_Table:
     Replicate_Wild_Ignore_Table:
                      Last_Errno: 0
                      Last_Error:
                    Skip_Counter: 0
             Exec_Master_Log_Pos: 785
                 Relay_Log_Space: 1252
                 Until_Condition: None
                  Until_Log_File:
                   Until_Log_Pos: 0
              Master_SSL_Allowed: No
              Master_SSL_CA_File:
              Master_SSL_CA_Path:
                 Master_SSL_Cert:
               Master_SSL_Cipher:
                  Master_SSL_Key:
           Seconds_Behind_Master: 0
   Master_SSL_Verify_Server_Cert: No
                   Last_IO_Errno: 0
                   Last_IO_Error:
                  Last_SQL_Errno: 0
                  Last_SQL_Error:
     Replicate_Ignore_Server_Ids:
                Master_Server_Id: 1
                     Master_UUID: 580d8bb0-6991-11e8-9a22-16efadb2f150
                Master_Info_File: mysql.slave_master_info
                       SQL_Delay: 0
             SQL_Remaining_Delay: NULL
         Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
              Master_Retry_Count: 86400
                     Master_Bind:
         Last_IO_Error_Timestamp:
        Last_SQL_Error_Timestamp:
                  Master_SSL_Crl:
              Master_SSL_Crlpath:
              Retrieved_Gtid_Set:
               Executed_Gtid_Set:
                   Auto_Position: 0
            Replicate_Rewrite_DB:
                    Channel_Name:
              Master_TLS_Version:
   1 row in set (0.00 sec)

Conviene asegurarse de que Slave_IO_Running y Slave_SQL_Running muestran Yes. Otros valores podrían ser diferentes de los del ejemplo.

Resolución de problemas

¿Qué hacer si uno de los nodos del clúster no funciona?

El servicio no se verá afectado siempre y cuando el nodo maestro esté en funcionamiento. Si el nodo maestro falla, un nodo esclavo ascenderá a maestro automáticamente. Vea Reparación de un nodo roto.

Volver al Índice de Documentación Pandora FMS