Difference between revisions of "Pandora: Documentation es: HA"
Dimas.pardo (talk | contribs) |
(→Instalación) |
||
| (47 intermediate revisions by 8 users not shown) | |||
| Line 1: | Line 1: | ||
[[Pandora:Documentation|Volver a Índice de Documentacion Pandora FMS]] | [[Pandora:Documentation|Volver a Índice de Documentacion Pandora FMS]] | ||
| + | |||
= Alta disponibilidad = | = Alta disponibilidad = | ||
| Line 5: | Line 6: | ||
== Introducción == | == 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 | + | 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 no se viene abajo. |
Pandora FMS ha sido diseñado para que sea muy modular, y que cualquiera de sus módulos pueda funcionar de forma independiente. 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. | Pandora FMS ha sido diseñado para que sea muy modular, y que cualquiera de sus módulos pueda funcionar de forma independiente. 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. | ||
| Line 19: | Line 20: | ||
<br> | <br> | ||
| − | Evidentemente, los agentes no son | + | 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 HA en varios escenarios: | Se puede hablar de utilizar HA en varios escenarios: | ||
| Line 123: | Line 124: | ||
| − | 1. Base de datos en HA simple, hasta 7500 agentes / 125000 módulos cada 5 minutos, datos uniformes, con datos históricos (1 año) | + | 1. Base de datos en HA simple, hasta 7500 agentes / 125000 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) | Servidores: 4 (1 servidor + consola, 2 base de datos, 1 histórico) | ||
| Line 157: | Line 158: | ||
| − | 2. Base de datos en HA completo (con quorum), hasta 7500 agentes / 125000 módulos cada 5 minutos, datos uniformes, con datos históricos (1 año) | + | 2. Base de datos en HA completo (con quorum), hasta 7500 agentes / 125000 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) | Servidores: 5 (1 servidor + consola, 3 base de datos, 1 histórico) | ||
| Line 197: | Line 198: | ||
| − | 3. Base de datos en HA simple y Pandora FMS en HA balanceado, hasta 7500 agentes / 125000 módulos cada 5 minutos, datos uniformes, con datos históricos (1 año) | + | 3. Base de datos en HA simple y Pandora FMS en HA balanceado, hasta 7500 agentes / 125000 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) | Servidores: 5 (2 servidor + consola, 2 base de datos, 1 histórico) | ||
| Line 238: | Line 239: | ||
| − | 4. Básico HA balanceado en servidor, principal y réplica de Base de datos, hasta 4000 agentes / 90000 módulos cada 5 minutos, datos uniformes, con datos históricos (1 año) | + | 4. Básico HA balanceado en servidor, principal y réplica de Base de datos, hasta 4000 agentes / 90000 módulos cada 5 minutos, datos uniformes, con datos históricos (1 año). |
Servidores: 3 (2 compartido, 1 histórico) | Servidores: 3 (2 compartido, 1 histórico) | ||
| − | Principal: (consola + servidor + base de datos nodo 1) | + | Principal: (consola + servidor + base de datos nodo 1). |
---------- | ---------- | ||
CPU: 8 cores | CPU: 8 cores | ||
| Line 248: | Line 249: | ||
Disco: 100GB | Disco: 100GB | ||
| − | Secundario: (consola + servidor + base de datos nodo 2) | + | Secundario: (consola + servidor + base de datos nodo 2). |
---------- | ---------- | ||
CPU: 8 cores | CPU: 8 cores | ||
| Line 271: | Line 272: | ||
<b>Nota:</b> Para grandes entornos, definiremos cada uno de los esquemas de configuración descritos previamente como <i>nodos de computación</i>. | <b>Nota:</b> Para grandes entornos, definiremos cada uno de los esquemas de configuración descritos previamente como <i>nodos de computación</i>. | ||
| − | |||
=== Ejemplo === | === Ejemplo === | ||
| Line 314: | Line 314: | ||
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 vamos a utilizar un balanceador externo, éste proveerá una única dirección IP a la que los agentes se conectarán para enviar sus datos. | 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 vamos 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 estamos usando un balanceador externo, y uno de los servidores falla, el mecanismo de HA | + | Si estamos 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, ú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". | 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 | + | Si se quieren utilizar dos servidores de datos y que ambos manejen políticas, colecciones, y configuraciones remotas, habrá que [[Pandora:Documentation_es:Compartir_colecciones_NFS|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/conf | ||
* /var/spool/pandora/data_in/collections | * /var/spool/pandora/data_in/collections | ||
* /var/spool/pandora/data_in/md5 | * /var/spool/pandora/data_in/md5 | ||
| + | * /var/spool/pandora/data_in/netflow | ||
| + | * /var/www/html/pandora_console/attachment | ||
<br> | <br> | ||
| Line 358: | Line 360: | ||
* '''secondary_server_path''': Ruta donde se copian los XML en el servidor secundario, habitualmente /var/spool/pandora/data_in | * '''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 22 y en ftp 21. | * '''secondary_server_port''': Puerto por el que se copiaran los XML al servidor secundario, en tentacle 41121, en ssh 22 y en ftp 21. | ||
| − | * '''secondary_transfer_mode''': | + | * '''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 password para la transferencia por FTP | * '''secondary_server_pwd''': Opción de password 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_ssl''': Se pondrá yes o no según se quiera usar ssl para transferir los datos por Tentacle. | ||
| − | * '''secondary_server_opts''': En este campo | + | * '''secondary_server_opts''': En este campo se pondrán otras opciones necesarias para la transferencia. |
{{Warning|Solo está operativa la configuración remota del agente, en el caso de estar habilitada, en el servidor principal. }} | {{Warning|Solo está operativa la configuración remota del agente, en el caso de estar habilitada, en el servidor principal. }} | ||
| Line 369: | Line 371: | ||
Necesita instalar múltiples servidores, de red. WMI, Plugin, 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). | Necesita instalar múltiples servidores, de red. WMI, Plugin, 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 | + | 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 maestros (Master). En el caso de haber más de dos servidores maestros y un tercer servidor caído con módulos pendientes de ejecutar, el primero de los servidores maestros 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. | 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 maestros (Master). En el caso de haber más de dos servidores maestros y un tercer servidor caído con módulos pendientes de ejecutar, el primero de los servidores maestros 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. | ||
| Line 381: | Line 383: | ||
<br> | <br> | ||
| − | El balanceo de carga | + | El balanceo de carga entre los distintos servidores se realiza en la parte de administración del agente en el menú "setup". |
<br> | <br> | ||
| Line 395: | Line 397: | ||
=== Configuración en los servidores === | === Configuración en los servidores === | ||
| − | Un | + | Un servidor de Pandora FMS puede estar corriendo en dos modos diferentes: |
* Modo maestro. | * Modo maestro. | ||
| Line 402: | Line 404: | ||
Si un servidor se cae, sus módulos serán ejecutados por el servidor maestro de modo que no se pierdan datos. | Si un servidor se cae, sus módulos serán ejecutados por el servidor maestro de modo que no se pierdan datos. | ||
| − | En un momento dado | + | 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] | 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 | + | 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''. |
{{warning|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.}} | {{warning|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 | + | 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 | + | Dentro de pandora_server.conf se han introducido los siguientes parámetros: |
* ha_file: Dirección del fichero binario temporal del HA. | * ha_file: Dirección del fichero binario temporal del HA. | ||
| Line 420: | Line 422: | ||
== Alta disponibilidad de la consola de Pandora FMS == | == Alta disponibilidad de la consola de Pandora FMS == | ||
| − | Sólo hay que instalar otra consola. Cualquiera de | + | Sólo hay que [https://pandorafms.com/docs/index.php?title=Pandora:Documentation_es:Instalacion#Instalaci.C3.B3n_de_Consola_y_Servidor_de_Pandora_FMS 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. Podremos usar un balanceador Web delante de las consolas en caso de necesitar un crecimiento horizontal para el balanceo 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, tanto los servidores de datos | + | 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. |
| + | {{Tip|[[Pandora:Documentation_es:Compartir_colecciones_NFS|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 afectaria negativamente el rendimiento del servidor. | ||
=== Actualización === | === Actualización === | ||
| Line 456: | Line 461: | ||
</center> | </center> | ||
| − | La herramienta de base de datos HA de Pandora FMS, ''pandora_ha'', monitoriza el cluster y se asegura de que el servidor de Pandora FMS está en continuo funcionamiento, reiniciándolo | + | La herramienta de base de datos HA de Pandora FMS, ''pandora_ha'', monitoriza el cluster 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. |
{{Warning|Se trata de una característica avanzada que requiere conocimientos en sistemas Linux.}} | {{Warning|Se trata de una característica avanzada que requiere conocimientos en sistemas Linux.}} | ||
| Line 473: | Line 478: | ||
Hay un host adicional, denominado '''pandorafms''', en el que se encuentra o se instalará Pandora FMS. | 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 ==== | ==== Requisitos previos ==== | ||
| − | Se debe instalar CentOS | + | 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 | node1# ping node2 | ||
| Line 500: | Line 507: | ||
Generamos nuevas claves de autenticación SSH para cada host y copiamos la clave pública para cada uno de los hosts: | Generamos nuevas claves de autenticación SSH para cada host y copiamos la clave pública para cada uno de los hosts: | ||
| − | {{Warning|Se pueden generar claves para un usuario que no sea root para una posterior instalación de | + | {{Warning|Se pueden generar claves para un usuario que no sea root para una posterior instalación de cluster con usuario "no root". }} |
node1# echo -e "\n\n\n" | ssh-keygen -t rsa | node1# echo -e "\n\n\n" | ssh-keygen -t rsa | ||
node1# ssh-copy-id -p22 [email protected] | node1# ssh-copy-id -p22 [email protected] | ||
| − | + | node1# ssh node2 | |
node2# echo -e "\n\n\n" | ssh-keygen -t rsa | node2# echo -e "\n\n\n" | ssh-keygen -t rsa | ||
| Line 530: | Line 537: | ||
Instalamos el paquete necesario: | Instalamos el paquete necesario: | ||
| − | all# yum install | + | all# yum install https://repo.percona.com/yum/percona-release-latest.noarch.rpm |
all# yum install -y Percona-Server-server-57 percona-xtrabackup-24 | 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, nos aseguramos de que el servicio Percona está desactivado, ya que lo gestionará el cluster: | ||
all# systemctl disable mysqld | all# systemctl disable mysqld | ||
| Line 540: | Line 549: | ||
{{Warning|Si el servicio del sistema no está desactivado, el gestor de recursos del cluster no funcionará correctamente.}} | {{Warning|Si el servicio del sistema no está desactivado, el gestor de recursos del cluster no funcionará correctamente.}} | ||
| − | + | A continuación, iniciamos el servidor Percona: | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
all# systemctl start mysqld | all# systemctl start mysqld | ||
| Line 623: | Line 561: | ||
mysql> SET PASSWORD FOR 'root'@'localhost' = PASSWORD('pandora'); | mysql> SET PASSWORD FOR 'root'@'localhost' = PASSWORD('pandora'); | ||
mysql> quit | 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. | ||
| + | |||
| + | {{Warning|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 tenemos 2 nodos de base de datos (node1 y node2) y un nodo de aplicación (Pandorafms) por lo que el paquete del servidor de pandora 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/ | ||
| + | |||
| + | Como vemos en el ejemplo, 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 password. De no hacerlo se usarán los configurados por defecto. | ||
| + | |||
| + | Para este caso ejecutaremos 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 id único. | ||
| + | |||
| + | Se escribirá el fichero de configuración de Percona en /etc/my.cnf donde estarán definidos la id del server y la configuración recomendada para la replicación de base de datos. | ||
| + | |||
| + | Reiniciar el servicio de mysqld para comprobar que la configuracion se ha aplicado correctamente. | ||
| + | |||
| + | all# systemctl restart mysqld | ||
==== Instalación de Pandora FMS ==== | ==== Instalación de Pandora FMS ==== | ||
| Line 628: | Line 614: | ||
===== Nueva instalación de Pandora FMS ===== | ===== Nueva instalación de Pandora FMS ===== | ||
| − | Instalamos Pandora FMS en la base de datos recién creada. Para más información, | + | Instalamos Pandora FMS en la base de datos recién creada. Para más información, consulte: |
https://wiki.pandorafms.com/index.php?title=Pandora:Documentation_en:Installing | https://wiki.pandorafms.com/index.php?title=Pandora:Documentation_en:Installing | ||
| Line 760: | Line 746: | ||
Instalamos los paquetes necesarios: | Instalamos los paquetes necesarios: | ||
| − | yum install -y epel-release corosync ntp pacemaker pcs | + | all# yum install -y epel-release corosync ntp pacemaker pcs |
all# systemctl enable ntpd | all# systemctl enable ntpd | ||
| Line 814: | Line 800: | ||
{{Warning|Ambos nodos deberían estar online ('''Online: [ node1 node2 ]'''). Otros valores pueden ser diferentes a los del ejemplo.}} | {{Warning|Ambos nodos deberían estar online ('''Online: [ node1 node2 ]'''). Otros valores pueden ser diferentes a los del ejemplo.}} | ||
| − | Instalamos el agente de replicación Pacemaker de Percona: | + | Instalamos el agente de replicación Pacemaker de Percona (se puede descargar manualmente desde nuestra [https://pandorafms.com/library/pacemaker-replication-agent-for-mysql/ librería]): |
all# cd /usr/lib/ocf/resource.d/ | all# cd /usr/lib/ocf/resource.d/ | ||
all# mkdir percona | all# mkdir percona | ||
all# cd percona | all# cd percona | ||
| − | all# curl -L -o | + | 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 | all# chmod u+x mysql | ||
| Line 826: | Line 813: | ||
{{Warning|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'' convenientemente.}} | {{Warning|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'' convenientemente.}} | ||
| + | |||
| + | {{Warning|Los nombres de los recursos del cluster deben ser exactamente los indicados en esta guía ("pandoraip" y "pandoradb")}} | ||
node1# export VIP=<VIRT_IP> | node1# export VIP=<VIRT_IP> | ||
| Line 874: | Line 863: | ||
==== Configuración del cluster de dos nodos con usuario "no root"==== | ==== Configuración del cluster de dos nodos con usuario "no root"==== | ||
| − | Se realizará de manera similar a la anterior. Se deberá | + | 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: | # All nodes: | ||
| Line 901: | Line 890: | ||
==== Configuración de Pandora FMS ==== | ==== Configuración de Pandora FMS ==== | ||
| − | Nos aseguramos de que ''php-pecl-ssh2'' | + | Nos aseguramos de que ''php-pecl-ssh2'' esté instalado: |
pandorafms# yum install php-pecl-ssh2 | pandorafms# yum install php-pecl-ssh2 | ||
| Line 948: | Line 937: | ||
</center> | </center> | ||
| − | Hacemos | + | Hacemos clic en ''Add new node'' y creamos una entrada para el primer nodo: |
<center> | <center> | ||
| Line 954: | Line 943: | ||
</center> | </center> | ||
| − | Después, hacemos | + | Después, hacemos clic en ''Create slave'' y añadimos una nueva entrada en el segundo nodo. Debería aparecer algo parecido a: |
<center> | <center> | ||
| Line 966: | Line 955: | ||
=== Añadir un nuevo nodo al cluster === | === Añadir un nuevo nodo al cluster === | ||
| − | Instalamos Percona ( | + | Suprimimos el banner 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 | ||
| + | |||
| + | Generamos nuevas claves de autenticación SSH para el nuevo host y copiamos la clave pública para cada uno de los hosts: | ||
| + | |||
| + | {{Warning|Se pueden generar claves para un usuario que no sea root para la instalación del cluster 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, copiamos 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. Sustituimos 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 | ||
| + | |||
| + | Instalamos 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 | ||
| + | |||
| + | Nos aseguramos de que el servicio Percona está desactivado, ya que lo gestionará el cluster: | ||
| + | |||
| + | node3# systemctl stop mysqld | ||
| + | node3# systemctl disable mysqld | ||
| + | |||
| + | {{Warning|Si el servicio del sistema no está desactivado, el gestor de recursos del cluster no funcionará correctamente.}} | ||
| + | |||
| + | Configuramos Percona, sustituyendo '''<ID>''' con un número que debe ser único para cada nodo de cluster: | ||
| + | |||
| + | {{Warning|La replicación de la base de datos no funcionará si dos nodos tienen el mismo '''SERVER_ID'''.}} | ||
| + | |||
| + | node3# export SERVER_ID=<ID> | ||
| + | node3# export POOL_SIZE=$(grep -i total /proc/meminfo | head -1 | \ | ||
| + | awk '{print $(NF-1)*0.4/1024}' | sed s/\\..*$/M/g) | ||
| + | node3# cat <<EOF > /etc/my.cnf | ||
| + | [mysqld] | ||
| + | server_id=$SERVER_ID | ||
| + | |||
| + | datadir=/var/lib/mysql | ||
| + | socket=/var/lib/mysql/mysql.sock | ||
| + | symbolic-links=0 | ||
| + | log-error=/var/log/mysqld.log | ||
| + | show_compatibility_56=on | ||
| + | |||
| + | max_allowed_packet = 64M | ||
| + | # Recommendation: not to assign a value greater than 35% of available RAM memory | ||
| + | innodb_buffer_pool_size = $POOL_SIZE | ||
| + | innodb_lock_wait_timeout = 90 | ||
| + | innodb_file_per_table | ||
| + | innodb_flush_method = O_DIRECT | ||
| + | innodb_log_file_size = 64M | ||
| + | innodb_log_buffer_size = 16M | ||
| + | thread_cache_size = 8 | ||
| + | max_connections = 200 | ||
| + | key_buffer_size=4M | ||
| + | read_buffer_size=128K | ||
| + | read_rnd_buffer_size=128K | ||
| + | sort_buffer_size=128K | ||
| + | join_buffer_size=4M | ||
| + | log-bin=mysql-bin | ||
| + | query_cache_type = 1 | ||
| + | query_cache_size = 32M | ||
| + | query_cache_limit = 8M | ||
| + | sql_mode="" | ||
| + | expire_logs_days=3 | ||
| + | |||
| + | binlog-format=ROW | ||
| + | log-slave-updates=true | ||
| + | sync-master-info=1 | ||
| + | sync_binlog=1 | ||
| + | max_binlog_size = 100M | ||
| + | replicate-do-db=pandora | ||
| + | port=3306 | ||
| + | report-port=3306 | ||
| + | report-host=master | ||
| + | gtid-mode=off | ||
| + | enforce-gtid-consistency=off | ||
| + | master-info-repository=TABLE | ||
| + | relay-log-info-repository=TABLE | ||
| + | |||
| + | sync_relay_log = 10 | ||
| + | sync_relay_log_info = 10 | ||
| + | slave_compressed_protocol = 1 | ||
| + | slave_parallel_type = LOGICAL_CLOCK | ||
| + | slave_parallel_workers = 10 | ||
| + | innodb_flush_log_at_trx_commit = 2 | ||
| + | innodb_flush_log_at_timeout = 1800 | ||
| + | |||
| + | |||
| + | [mysqld_safe] | ||
| + | log-error=/var/log/mysqld.log | ||
| + | pid-file=/var/run/mysqld/mysqld.pid | ||
| + | |||
| + | [client] | ||
| + | user=root | ||
| + | password=pandora | ||
| + | EOF | ||
| + | |||
| + | Iniciamos el servidor Percona: | ||
| + | |||
| + | node3# systemctl start mysqld | ||
| + | |||
| + | Se generará una nueva contraseña temporal conectada a /var/log/mysqld.log. Nos conectamos al servidor Percona y cambiamos 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 | ||
| + | |||
| + | Hacemos una copia de seguridad de la base de datos del nodo maestro (node1 en este ejemplo) y escribimos 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# [ -e /root/pandoradb.bak ] && rm -rf /root/pandoradb.bak | ||
| Line 973: | Line 1,093: | ||
node1# cat /root/pandoradb.bak/xtrabackup_binlog_info | node1# cat /root/pandoradb.bak/xtrabackup_binlog_info | ||
mysql-bin.000001 785 | mysql-bin.000001 785 | ||
| − | + | ||
Cargamos la base de datos en el nuevo nodo, que llamaremos node3, y la configuramos para replicar desde el node1 (configuramos MASTER_LOG_FILE y MASTER_LOG_POS a los valores del paso anterior): | Cargamos la base de datos en el nuevo nodo, que llamaremos node3, y la configuramos para replicar desde el node1 (configuramos MASTER_LOG_FILE y MASTER_LOG_POS a los valores del paso anterior): | ||
| Line 1,051: | Line 1,171: | ||
node3# systemctl stop mysqld | node3# systemctl stop mysqld | ||
| − | + | ||
{{Warning|Conviene asegurarse de que '''Slave_IO_Running''' y '''Slave_SQL_Running''' muestran '''Yes'''. Otros valores podrían ser diferentes de los del ejemplo.}} | {{Warning|Conviene asegurarse de que '''Slave_IO_Running''' y '''Slave_SQL_Running''' muestran '''Yes'''. Otros valores podrían ser diferentes de los del ejemplo.}} | ||
| + | |||
| + | Instalamos los paquetes necesarios para el cluster: | ||
| + | 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ñadimos un nuevo nodo al cluster: | Añadimos un nuevo nodo al cluster: | ||
| Line 1,060: | Line 1,190: | ||
node3# mkdir percona | node3# mkdir percona | ||
node3# cd percona | node3# cd percona | ||
| − | node3# curl -L -o | + | 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 | node3# chmod u+x mysql | ||
node1# pcs cluster auth -u hacluster -p hapass --force node3 | node1# pcs cluster auth -u hacluster -p hapass --force node3 | ||
node1# pcs cluster node add --enable --start node3 | node1# pcs cluster node add --enable --start node3 | ||
| − | + | ||
| − | Configuramos | + | Configuramos clone-max al número de nodos en nuestro cluster (3 en este ejemplo): |
node3# pcs resource update master_pandoradb meta master-max="1" \ | node3# pcs resource update master_pandoradb meta master-max="1" \ | ||
master-node-max="1" clone-max="3" clone-node-max="1" notify="true" \ | master-node-max="1" clone-max="3" clone-node-max="1" notify="true" \ | ||
globally-unique="false" target-role="Master" is-managed="true" | globally-unique="false" target-role="Master" is-managed="true" | ||
| − | + | ||
Comprobamos el estado del nodo: | Comprobamos el estado del nodo: | ||
| Line 1,098: | Line 1,229: | ||
pacemaker: active/enabled | pacemaker: active/enabled | ||
pcsd: active/enabled | pcsd: active/enabled | ||
| + | |||
| + | {{Warning|Todos los nodos deberían estar online ('''Online: [ node1 node2 node3 ]'''). Otros valores podrían ser diferentes de los del ejemplo.}} | ||
| − | + | Registramos el nodo del cluster en la consola de Pandora desde el menú "Servers -> Manage database HA". | |
=== Reparación de un nodo roto === | === Reparación de un nodo roto === | ||
| Line 1,139: | Line 1,272: | ||
node2# mv /var/lib/mysql /var/lib/mysql.bak | node2# mv /var/lib/mysql /var/lib/mysql.bak | ||
| − | Hacemos una copia de seguridad de la base de datos del nodo maestro (node1 en este ejemplo) y | + | Hacemos una copia de seguridad de la base de datos del nodo maestro (node1 en este ejemplo) y actualizamos el nombre del nodo maestro, y el nombre y la posición del archivo de log maestro en el cluster (en este ejemplo node1, mysql-bin.000001 y 785): |
node1# [ -e /root/pandoradb.bak ] && rm -rf /root/pandoradb.bak | node1# [ -e /root/pandoradb.bak ] && rm -rf /root/pandoradb.bak | ||
node1# innobackupex --no-timestamp /root/pandoradb.bak/ | node1# innobackupex --no-timestamp /root/pandoradb.bak/ | ||
node1# innobackupex --apply-log /root/pandoradb.bak/ | node1# innobackupex --apply-log /root/pandoradb.bak/ | ||
| − | node1# cat /root/pandoradb.bak/xtrabackup_binlog_info | + | 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}')" | |
| − | Cargamos la base de datos del nodo roto | + | |
| + | Cargamos la base de datos del nodo roto: | ||
node1# rsync -avpP -e ssh /root/pandoradb.bak/ node2:/var/lib/mysql/ | node1# rsync -avpP -e ssh /root/pandoradb.bak/ node2:/var/lib/mysql/ | ||
| Line 1,153: | Line 1,287: | ||
node2# chown -R mysql:mysql /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# chcon -R system_u:object_r:mysqld_db_t:s0 /var/lib/mysql | ||
| − | node2# | + | |
| + | Desactivamos el modo standby del node2: | ||
| + | |||
| + | node2# pcs node unstandby node2 | ||
| + | node2# pcs resource cleanup --node node2 | ||
| + | |||
| + | Comprobamos el estado del cluster: | ||
| + | |||
| + | 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 | ||
| + | |||
| + | {{Warning|Ambos nodos deberían estar online ('''Online: [ node1 node2 ]'''). Otros valores podrían ser diferentes de los del ejemplo.}} | ||
| + | |||
| + | Comprobamos el estado de la replicación de la base de datos: | ||
| + | |||
node2# mysql -uroot -ppandora | node2# mysql -uroot -ppandora | ||
| − | + | mysql> SHOW SLAVE STATUS \G | |
| − | |||
| − | |||
| − | |||
| − | |||
*************************** 1. row *************************** | *************************** 1. row *************************** | ||
Slave_IO_State: Waiting for master to send event | Slave_IO_State: Waiting for master to send event | ||
| Line 1,166: | Line 1,331: | ||
Master_Port: 3306 | Master_Port: 3306 | ||
Connect_Retry: 60 | Connect_Retry: 60 | ||
| − | Master_Log_File: mysql-bin. | + | Master_Log_File: mysql-bin.000001 |
Read_Master_Log_Pos: 785 | Read_Master_Log_Pos: 785 | ||
Relay_Log_File: node2-relay-bin.000003 | Relay_Log_File: node2-relay-bin.000003 | ||
Relay_Log_Pos: 998 | Relay_Log_Pos: 998 | ||
| − | Relay_Master_Log_File: mysql-bin. | + | Relay_Master_Log_File: mysql-bin.000001 |
Slave_IO_Running: Yes | Slave_IO_Running: Yes | ||
Slave_SQL_Running: Yes | Slave_SQL_Running: Yes | ||
| Line 1,219: | Line 1,384: | ||
Master_TLS_Version: | Master_TLS_Version: | ||
1 row in set (0.00 sec) | 1 row in set (0.00 sec) | ||
| − | |||
| − | |||
| − | |||
{{Warning|Conviene asegurarse de que '''Slave_IO_Running''' y '''Slave_SQL_Running''' muestran '''Yes'''. Otros valores podrían ser diferentes de los del ejemplo.}} | {{Warning|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 === | === Resolución de problemas === | ||
Latest revision as of 10:08, 4 November 2020
Volver a Índice de Documentacion Pandora FMS
Contents
- 1 Alta disponibilidad
- 1.1 Introducción
- 1.2 Dimensionamiento y diseños de arquitectura HA
- 1.3 Alta disponibilidad del Servidor de Datos
- 1.4 Alta disponibilidad en los agentes software
- 1.5 Alta disponibilidad de los servidores de Red, WMI, plugin, web, prediction y similares
- 1.6 Alta disponibilidad de la consola de Pandora FMS
- 1.7 Alta disponibilidad en la Base de datos
- 1.7.1 Instalación
- 1.7.2 Añadir un nuevo nodo al cluster
- 1.7.3 Reparación de un nodo roto
- 1.7.4 Resolución de problemas
1 Alta disponibilidad
1.1 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 no se viene abajo.
Pandora FMS ha sido diseñado para que sea muy modular, y que cualquiera de sus módulos pueda funcionar de forma independiente. 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 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 BBDD.
- Balanceo y HA de la consola de Pandora FMS.
1.2 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
Instancia t2.large de Amazon [1]
1.2.1 Dimensionamiento
Dependiendo de las necesidades:
1. Standalone (sin alta disponibilidad) hasta 2500 agentes / 50000 módulos cada 5 minutos, datos uniformes, sin datos históricos
Servidores: 1 (compartido) Principal: ---------- CPU: 6 cores RAM: 8 GB Disco: 100GB
2. Standalone (sin alta disponibilidad) hasta 2500 agentes / 50000 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: 100GB Histórico: ---------- CPU: 2 cores RAM: 4 GB Disco: 200GB
3. Standalone (sin alta disponibilidad) hasta 5000 agentes / 100000 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: 40GB Base de datos principal: ------------------------ CPU: 4 cores RAM: 8 GB Disco: 100GB Histórico: ---------- CPU: 2 cores RAM: 4 GB Disco: 200GB
1.2.2 Diseños de arquitectura HA
1. Base de datos en HA simple, hasta 7500 agentes / 125000 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: 40GB Base de datos nodo 1: --------------------- CPU: 6 cores RAM: 8 GB Disco: 100GB Base de datos nodo 2: --------------------- CPU: 6 cores RAM: 8 GB Disco: 100GB Histórico: ---------- CPU: 2 cores RAM: 4 GB Disco: 300GB
2. Base de datos en HA completo (con quorum), hasta 7500 agentes / 125000 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: 40GB Base de datos nodo 1: --------------------- CPU: 6 cores RAM: 8 GB Disco: 100GB Base de datos nodo 2: --------------------- CPU: 6 cores RAM: 8 GB Disco: 100GB Base de datos nodo 3: --------------------- CPU: 6 cores RAM: 8 GB Disco: 100GB Histórico: ---------- CPU: 2 cores RAM: 4 GB Disco: 200GB
3. Base de datos en HA simple y Pandora FMS en HA balanceado, hasta 7500 agentes / 125000 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: 40GB Servidor + consola: ------------------- CPU: 6 cores RAM: 8 GB Disco: 40GB Base de datos nodo 1: --------------------- CPU: 6 cores RAM: 8 GB Disco: 100GB Base de datos nodo 2: --------------------- CPU: 6 cores RAM: 8 GB Disco: 100GB Histórico: ---------- CPU: 2 cores RAM: 4 GB Disco: 200GB
4. Básico HA balanceado en servidor, principal y réplica de Base de datos, hasta 4000 agentes / 90000 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: 100GB Secundario: (consola + servidor + base de datos nodo 2). ---------- CPU: 8 cores RAM: 12 GB Disco: 100GB Histórico: ---------- CPU: 2 cores RAM: 4 GB Disco: 200GB
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).
Nota: Para grandes entornos, definiremos cada uno de los esquemas de configuración descritos previamente como nodos de computación.
1.2.3 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 elegimos el diseño HA#1 (1 servidor+consola, 2 nodos de base de datos en HA, y una base de datos de histórico), deberemos 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: 100GB
Total de servidores con bases de datos históricas independientes: 17
Total de servidores con bases de datos históricas combinadas: 13
Nota: 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: 1200GB
1.3 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 vamos 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 estamos 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, ú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
1.4 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 y otro de backup. En el fichero de configuración del agente 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).
- 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: 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 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 password 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, en el caso de estar habilitada, en el servidor principal. |
|
1.5 Alta disponibilidad de los servidores de Red, WMI, plugin, web, prediction y similares
Necesita instalar múltiples servidores, de red. WMI, Plugin, 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 maestros (Master). En el caso de haber más de dos servidores maestros y un tercer servidor caído con módulos pendientes de ejecutar, el primero de los servidores maestros 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 menú "setup".
En el campo "server" hay un combo donde se elige el servidor que realizará los chequeos.
1.5.1 Configuración en los servidores
Un servidor de Pandora FMS puede estar corriendo en dos modos diferentes:
- Modo maestro.
- Modo no maestro.
Si un servidor se cae, 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.
1.6 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. Podremos usar un balanceador Web delante de las consolas en caso de necesitar un crecimiento horizontal para el balanceo 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 afectaria negativamente el rendimiento del servidor.
1.6.1 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 nos 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.
1.7 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 integridad, usando la consola Linux como Root. En versiones futuras facilitaremos la configuración desde la 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 cluster de la base de datos de alta disponibilidad de Pandora FMS nos permite desplegar fácilmente una arquitectura robusta y tolerante a los fallos.
Los recursos de cluster se gestionan con Pacemaker, un gestor de recursos de cluster 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. Percona se eligió 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 esclavos (sólo lectura). Una dirección IP virtual siempre lleva al maestro actual. Si falla el nodo maestro, uno de los esclavos 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 cluster 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 trata de una característica avanzada que requiere conocimientos en sistemas Linux. |
|
1.7.1 Instalación
Configuraremos un cluster de dos nodos, con hosts node1 y node2. Cambiamos nombres de host, contraseñas, etc. según lo que necesitemos para que concuerde con nuestro entorno.
Los comandos que tengan que ejecutarse en un nodo irán precedidos por el hostname de ese nodo. Por ejemplo:
node1# <command>
Los comandos que tengan que ejecutarse en todos los nodos irán precedidos de la palabra all. Por ejemplo:
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
1.7.1.1 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 banner 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 se configura un banner para Open SSH. |
|
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 cluster 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 cluster:
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. Sustituimos 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
1.7.1.2 Instalación de Percona
Instalamos 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, nos aseguramos de que el servicio Percona está desactivado, ya que lo gestionará el cluster:
all# systemctl disable mysqld
|
|
Si el servicio del sistema no está desactivado, el gestor de recursos del cluster no funcionará correctamente. |
|
A continuación, iniciamos el servidor Percona:
all# systemctl start mysqld
Se generará una nueva contraseña temporal conectada a /var/log/mysqld.log. Nos conectamos al servidor Percona y cambiamos 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 tenemos 2 nodos de base de datos (node1 y node2) y un nodo de aplicación (Pandorafms) por lo que el paquete del servidor de pandora 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/
Como vemos en el ejemplo, 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 password. De no hacerlo se usarán los configurados por defecto.
Para este caso ejecutaremos 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 id único.
Se escribirá el fichero de configuración de Percona en /etc/my.cnf donde estarán definidos la id del server y la configuración recomendada para la replicación de base de datos.
Reiniciar el servicio de mysqld para comprobar que la configuracion se ha aplicado correctamente.
all# systemctl restart mysqld
1.7.1.3 Instalación de Pandora FMS
1.7.1.3.1 Nueva instalación de Pandora FMS
Instalamos Pandora FMS en la base de datos recién creada. Para más información, consulte:
https://wiki.pandorafms.com/index.php?title=Pandora:Documentation_en:Installing
Detenemos el servidor de Pandora FMS:
pandorafms# /etc/init.d/pandora_server stop
1.7.1.3.2 Instalación de Pandora FMS existente
Detenemos el servidor de Pandora FMS:
pandorafms# /etc/init.d/pandora_server stop
Hacemos 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/
Lo cargamos a la nueva base de datos:
node1# mysql -uroot -ppandora pandora -e source "/tmp/pandoradb.sql"
1.7.1.4 Configuración de la replicación
Otorgamos 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
Hacemos una copia de seguridad de la base de datos del primer nodo y escribimos 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
Cargamos la base de datos en el segundo nodo y la configuramos para replicar desde el primer nodo (configuramos 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
|
|
Debemos asegurarnos 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. |
|
1.7.1.5 Configuración del cluster de dos nodos
Instalamos 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
Detenemos el servidor Percona:
node1# systemctl stop mysqld
node2# systemctl stop mysqld
Autenticamos todos los nodos en el cluster:
Creamos e iniciamos el cluster:
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
Comprobamos el estado del cluster:
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. |
|
Instalamos el agente de replicación Pacemaker de Percona (se puede descargar manualmente desde nuestra librería):
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
Configuramos los recursos del cluster. Sustituimos <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 convenientemente. |
|
|
|
Los nombres de los recursos del cluster 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
Comprobamos el estado del cluster:
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. |
|
1.7.1.6 Configuración del cluster 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
1.7.1.7 Configuración de Pandora FMS
Nos aseguramos de que php-pecl-ssh2 esté instalado:
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 nuestras necesidades:
# 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
Dirigimos 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
Instalamos e iniciamos el servicio pandora_ha:
pandorafms# cat > /etc/systemd/system/pandora_ha.service <<-EOF [Unit] Description=Pandora FMS Database HA Tool [Service] Type=forking PIDFile=/var/run/pandora_ha.pid Restart=always ExecStart=/usr/bin/pandora_ha -d -p /var/run/pandora_ha.pid /etc/pandora/pandora_server.conf [Install] WantedBy=multi-user.target EOF pandorafms# systemctl enable pandora_ha pandorafms# systemctl start pandora_ha
Iniciamos sesión en la consola de Pandora FMS y navegamos hasta Servers -> Manage database HA:
Hacemos clic en Add new node y creamos una entrada para el primer nodo:
Después, hacemos clic en Create slave y añadimos una nueva entrada en el segundo nodo. Debería aparecer algo parecido a:
|
|
Será necesario comprobar que el fichero functions_HA_cluster.php posee las rutas de $ssh_user correctas para que se muestre correctamente y se permita interactuar correctamente con los iconos. |
|
|
|
Seconds behind master debería estar cerca de 0. Si sigue aumentando, la replicación no está aumentando. |
|
1.7.2 Añadir un nuevo nodo al cluster
Suprimimos el banner 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
Generamos nuevas claves de autenticación SSH para el nuevo 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 la instalación del cluster 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, copiamos 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. Sustituimos 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
Instalamos 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
Nos aseguramos de que el servicio Percona está desactivado, ya que lo gestionará el cluster:
node3# systemctl stop mysqld node3# systemctl disable mysqld
|
|
Si el servicio del sistema no está desactivado, el gestor de recursos del cluster no funcionará correctamente. |
|
Configuramos Percona, sustituyendo <ID> con un número que debe ser único para cada nodo de cluster:
|
|
La replicación de la base de datos no funcionará si dos nodos tienen el mismo SERVER_ID. |
|
node3# export SERVER_ID=<ID>
node3# export POOL_SIZE=$(grep -i total /proc/meminfo | head -1 | \
awk '{print $(NF-1)*0.4/1024}' | sed s/\\..*$/M/g)
node3# cat <<EOF > /etc/my.cnf
[mysqld]
server_id=$SERVER_ID
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
symbolic-links=0
log-error=/var/log/mysqld.log
show_compatibility_56=on
max_allowed_packet = 64M
# Recommendation: not to assign a value greater than 35% of available RAM memory
innodb_buffer_pool_size = $POOL_SIZE
innodb_lock_wait_timeout = 90
innodb_file_per_table
innodb_flush_method = O_DIRECT
innodb_log_file_size = 64M
innodb_log_buffer_size = 16M
thread_cache_size = 8
max_connections = 200
key_buffer_size=4M
read_buffer_size=128K
read_rnd_buffer_size=128K
sort_buffer_size=128K
join_buffer_size=4M
log-bin=mysql-bin
query_cache_type = 1
query_cache_size = 32M
query_cache_limit = 8M
sql_mode=""
expire_logs_days=3
binlog-format=ROW
log-slave-updates=true
sync-master-info=1
sync_binlog=1
max_binlog_size = 100M
replicate-do-db=pandora
port=3306
report-port=3306
report-host=master
gtid-mode=off
enforce-gtid-consistency=off
master-info-repository=TABLE
relay-log-info-repository=TABLE
sync_relay_log = 10
sync_relay_log_info = 10
slave_compressed_protocol = 1
slave_parallel_type = LOGICAL_CLOCK
slave_parallel_workers = 10
innodb_flush_log_at_trx_commit = 2
innodb_flush_log_at_timeout = 1800
[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
[client]
user=root
password=pandora
EOF
Iniciamos el servidor Percona:
node3# systemctl start mysqld
Se generará una nueva contraseña temporal conectada a /var/log/mysqld.log. Nos conectamos al servidor Percona y cambiamos 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
Hacemos una copia de seguridad de la base de datos del nodo maestro (node1 en este ejemplo) y escribimos 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
Cargamos la base de datos en el nuevo nodo, que llamaremos node3, y la configuramos para replicar desde el node1 (configuramos 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. |
|
Instalamos los paquetes necesarios para el cluster:
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ñadimos un nuevo nodo al cluster:
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
Configuramos clone-max al número de nodos en nuestro cluster (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"
Comprobamos 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. |
|
Registramos el nodo del cluster en la consola de Pandora desde el menú "Servers -> Manage database HA".
1.7.3 Reparación de un nodo roto
Utilizaremos node2 como ejemplo. Ponemos node2 en modo 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. |
|
Hacemos 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
Hacemos una copia de seguridad de la base de datos del nodo maestro (node1 en este ejemplo) y actualizamos el nombre del nodo maestro, y el nombre y la posición del archivo de log maestro en el cluster (en este ejemplo node1, 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# 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}')"
Cargamos 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
Desactivamos el modo standby del node2:
node2# pcs node unstandby node2 node2# pcs resource cleanup --node node2
Comprobamos el estado del cluster:
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. |
|
Comprobamos 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. |
|
1.7.4 Resolución de problemas
1.7.4.1 ¿Qué hacer si uno de los nodos del cluster 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. Ver Reparación de un nodo roto.
