Tabla de Contenidos
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:
- Base de datos.
- Servidor.
- 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:
- Intel(R) Core(TM) i5-8600K CPU @ 3.60GHz .
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á
yesonosegú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 Manager → Update 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 root@node1 ssh-copy-id -p22 root@node2
pandorafms# printf "\n\n\n" | ssh-keygen -t rsa -P '' ssh-copy-id -p22 root@node1 ssh-copy-id -p22 root@node2
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 root@node1:/root/ scp /usr/share/pandora_server/util/myconfig_ha_gen.sh root@node2:/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 root@node2 node1# ssh node2 node2# echo -e "\n\n\n" | ssh-keygen -t rsa node2# ssh-copy-id -p22 root@node1 node2# ssh node1 pandorafms# echo -e "\n\n\n" | ssh-keygen -t rsa pandorafms# ssh-copy-id -p22 root@node1 pandorafms# ssh-copy-id -p22 root@node2 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 root@node1:/root/ pandorafms# scp /usr/share/pandora_server/util/myconfig_ha_gen.sh root@node2:/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 mastery 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:
- Borra los backups anteriores.
- Realiza backup del
datadirdel nodo Slave. - Realiza backup del nodo Master.
- Envía backup del nodo Master a Slave.
- Inicia el recurso del nodo “slave” con los parámetros de resincronización correspondientes en el momento del backup.
- 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:
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 root@node3 node1# ssh node3
node2# ssh-copy-id -p22 root@node3 node2# ssh node3
pandorafms# ssh-copy-id -p22 root@node3 pandorafms# ssh node3
node3# echo -e "\n\n\n" | ssh-keygen -t rsa node3# ssh-copy-id -p22 root@node1 node3# ssh-copy-id -p22 root@node2 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 root@node3:/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ú Servers → Manage 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.