Difference between revisions of "Pandora: Documentation es: HA"

From Pandora FMS Wiki
Jump to: navigation, search
(Alta disponibilidad en los agentes software)
 
(40 intermediate revisions by 8 users not shown)
Line 1: Line 1:
[[Pandora:Documentation|Volver a Indice de Documentacion Pandora FMS]]
+
[[Pandora:Documentation|Volver a Índice de Documentacion Pandora FMS]]
  
 
= Alta disponibilidad =
 
= Alta disponibilidad =
Line 5: Line 5:
 
== 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 los cientos de fallos abiertos por los usuarios y que han sido corregidos), 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 es una aplicación muy estable (gracias a las pruebas y mejoras introducidas en cada versión y a la corrección de cientos de 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 19:
 
<br>
 
<br>
  
Evidentemente, los agentes no son redundables. 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.  
+
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 27: Line 27:
 
* Balanceo y HA en la BBDD.
 
* Balanceo y HA en la BBDD.
 
* Balanceo y HA de la consola de Pandora FMS.
 
* Balanceo y HA de la consola de Pandora FMS.
 +
 +
== Dimensionamiento y diseños de arquitectura HA ==
 +
 +
 +
Los componentes más importantes de Pandora FMS son:
 +
 +
# Base de datos
 +
# Servidor
 +
# Consola
 +
 +
 +
Cada uno de los componentes puede replicarse para proteger el sistema de monitorización de cualquier catástrofe.
 +
 +
Para designar el número de nodos necesarios para equilibrar la carga estudiaremos el número de objetivos a monitorizar y la cantidad, tipo y frecuencia de captura de las métricas a recolectar.
 +
 +
En función de las necesidades de monitorización definiremos las diferentes arquitecturas.
 +
 +
 +
<b>Nota:</b> Las pruebas realizadas para definir las arquitecturas se han realizado utilizando equipos diferentes:
 +
 +
Intel(R) Core(TM) i5-8600K CPU @ 3.60GHz
 +
 +
Instancia <i>t2.large</i> de Amazon [https://aws.amazon.com/es/ec2/instance-types/t2/]
 +
 +
 +
=== 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
 +
 +
<center>
 +
[[image:dim_std1.png|500px]]
 +
</center>
 +
 +
 +
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
 +
 +
<center>
 +
[[image:dim_std2.png|700px]]
 +
</center>
 +
 +
 +
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
 +
 +
<center>
 +
[[image:dim_std3.png|700px]]
 +
</center>
 +
 +
 +
 +
=== 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
 +
 +
<center>
 +
[[image:dim_ha1.png|700px]]
 +
</center>
 +
 +
 +
 +
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
 +
 +
 +
<center>
 +
[[image:dim_ha2.png|700px]]
 +
</center>
 +
 +
 +
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
 +
 +
 +
<center>
 +
[[image:dim_ha3.png|700px]]
 +
</center>
 +
 +
 +
 +
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).
 +
 +
 +
<center>
 +
[[image:dim_ha4.png|700px]]
 +
</center>
 +
 +
 +
 +
<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 ===
 +
 +
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
 +
 +
 +
<b>Nota</b>: 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
  
 
== Alta disponibilidad del Servidor de Datos ==
 
== 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.
+
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.  
 
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 «promueven» 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.  
+
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 envio 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 descibe 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 por NFS los siguientes directorios 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 por NFS.
 
Si se quieren utilizar dos servidores de datos y que ambos manejen políticas, colecciones, y configuraciones remotas, habrá que compartir por NFS los siguientes directorios 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 por NFS.
Line 54: Line 334:
 
== Alta disponibilidad en los agentes software ==
 
== 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:
+
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
 
  # Secondary server configuration
Line 78: Line 358:
 
* '''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''': modo de transferencia que se usará para copiar los XML al servidor secundario, tentacle, ssh, ftp, ...
+
* '''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 pondra 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  se pondrán otras opciones necesarias para la transferencia.
 
* '''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. }}
 
 
== Alta disponibilidad en la BBDD ==
 
 
 
La BBDD es el componente más crítico de Pandora, y por ello, el tema es más complejo. Actualmente proponemos una solución software basada en DRBD que permite clusterizar MySQL via software , y Pandora FMS también puede trabajar con diferentes soluciones hardware o virtualizadas, que permiten clusterizar cualquier aplicación standard como MySQL.
 
 
 
Estamos trabajando para ofrecer una solución integrada en Pandora FMS que permita implementar una herramienta nativa de HA en Pandora, basada en MySQL.
 
 
 
Puede consultar la documentación disponible sobre DRBD y MySQL: [https://wiki.pandorafms.com/index.php?title=Pandora:Documentation_es:DRBD]
 
  
 
== Alta disponibilidad de los servidores de Red, WMI, plugin, web, prediction y similares ==
 
== Alta disponibilidad de los servidores de Red, WMI, plugin, web, prediction y similares ==
Line 97: Line 369:
 
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 sólo 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.  
+
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 sólo 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.
  
 
<br>
 
<br>
Line 109: Line 381:
 
<br>
 
<br>
  
El balanceo de carga entere los distintos servidores se realiza en la parte de administración del agente en el menú “setup”.
+
El balanceo de carga entere los distintos servidores se realiza en la parte de administración del agente en el menú "setup".
  
 
<br>
 
<br>
Line 119: Line 391:
 
<br>
 
<br>
  
En el campo “server” hay un combo donde se elige el servidor que realizará los chequeos.
+
En el campo "server" hay un combo donde se elige el servidor que realizará los chequeos.
  
 
=== Configuración en los servidores  ===
 
=== Configuración en los servidores  ===
Line 139: Line 411:
  
 
Por ejemplo, si tiene tres servidores de Pandora FMS Servers con ''maestro'' 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.
 
Por ejemplo, si tiene tres servidores de Pandora FMS Servers con ''maestro'' 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 parametros:
 +
 +
* ha_file: Dirección del fichero binario temporal del HA.
 +
* ha_pid_file: Proceso actual del HA.
 +
* pandora_service_cmd: Control de estado del servicio de Pandora FMS.
  
 
== Alta disponibilidad de la consola de Pandora FMS ==
 
== Alta disponibilidad de la consola de Pandora FMS ==
  
 
Sólo hay que instalar otra consola. Cualquiera de ellas podrá usarse de forma simultánea desde diferentes ubicaciones por diferentes usuarios. Utilizando un balanceador Web delante de las consolas, se podrá acceder a las mismas sin saber realmente a cuál se está accediendo ya que el sistema de sesiones se gestiona mediante ''cookies'' y ésta queda almacenada en el navegador.  
 
Sólo hay que instalar otra consola. Cualquiera de ellas podrá usarse de forma simultánea desde diferentes ubicaciones por diferentes usuarios. Utilizando un balanceador Web delante de las consolas, se podrá acceder a las mismas sin saber realmente a cuál se está accediendo ya que el sistema de sesiones se gestiona mediante ''cookies'' y ésta queda almacenada en el navegador.  
 +
 
En el caso de estar utilizando configuración remota, tanto los servidores de datos, como las consolas deben compartir (NFS) el directorio de datos de entrada (/var/spool/pandora/data_in) para la configuración remota de los agentes, las colecciones y otros directorios.
 
En el caso de estar utilizando configuración remota, tanto los servidores de datos, como las consolas deben compartir (NFS) el directorio de datos de entrada (/var/spool/pandora/data_in) para la configuración remota de los agentes, las colecciones y otros directorios.
  
== Pandora FMS HA Database Cluster ==
+
=== Actualización ===
  
{{Tip|This solution is provided to offer a fully-featured solution for HA in Pandora FMS environments. This is the only officially-supported HA model for Pandora FMS. This solution is provided -preinstalled- since OUM 724. This system replaces DRBD and other HA systems we recommended in the past.}}
+
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 -> [https://pandorafms.com/docs/index.php?title=Pandora:Documentation_es:Actualizacion#Actualizaciones_.22offline.22/ Update Manager offline].  
  
{{Warning|This is the first Pandora DB HA implementation, and the install process is almost manual, by using linux console as Root. In future versions we will easy the setup and configuration from the GUI}}
+
Los usuarios de la versión Enterprise podrán descargar el paquete OUM desde la web de soporte de Pandora FMS.  
  
Pandora FMS relies on a MySQL database for configuration and data storage. A database failure can temporarily bring your monitoring solution to a halt.
+
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.
  
The Pandora FMS high-availability database cluster allows you to easily deploy a fault-tolerant robust architecture. This model is a PASSIVE/ACTIVE with a realtime replication from MASTER node to the SLAVE (or slaves) nodes. It uses MySQL replication to provide redundancy, and a mechanism based on Corosync and Pacemaker to maintain the Virtual IP address.
+
<center>
 +
[[image:OUM1.JPG]]
 +
</center>
  
A special component of Pandora FMS will keep control of any problem, do the the switchover and of course, '''will monitor everything''' related with the HA.
+
<center>
 +
[[image:OUM2.JPG]]
 +
</center>
 +
 
 +
== Alta disponibilidad en la Base de datos==
 +
 
 +
{{Tip|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.}}
 +
 
 +
{{Warning|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 [https://github.com/ClusterLabs/pacemaker Pacemaker], un gestor de recursos de cluster de alta disponibilidad avanzado y escalable. [http://corosync.github.io/corosync/ Corosync] proporciona un modelo de comunicación de grupo de proceso cerrado para crear máquinas de estado replicadas. [https://www.percona.com/ Percona] se eligió como RDBMS por defecto por su escalabilidad, disponibilidad, seguridad y características de backup.
 +
 
 +
El [https://dev.mysql.com/doc/refman/5.7/en/replication.html 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.
 +
 
 +
<center>
 +
[[image:ha_cluster_diagram.png]]
 +
</center>
  
{{Warning|This is a very advanced feature of Pandora FMS and requires linux skills and also know very well Pandora FMS internals.}}
+
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 cuando en caso necesario. ''pandora_ha'' se monitoriza a su vez con [https://www.freedesktop.org/wiki/Software/systemd/systemd systemd].
  
=== Preamble ===
+
{{Warning|Se trata de una característica avanzada que requiere conocimientos en sistemas Linux.}}
  
We will configure a two node cluster, with hosts ''node1'' and ''node2''. Change hostnames, passwords, etc. as needed to match your environment.
+
=== Instalación ===
  
<diagrama>
+
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.
  
Commands that should be run on one node will be preceded by that node's hostname. For example:
+
Los comandos que tengan que ejecutarse en un nodo irán precedidos por el hostname de ese nodo. Por ejemplo:
  
 
  node1# <command>
 
  node1# <command>
  
Commands that should be run on all nodes will be preceded by the word '''all'''. For example:
+
Los comandos que tengan que ejecutarse en todos los nodos irán precedidos de la palabra '''all'''. Por ejemplo:
  
 
  all# <command>
 
  all# <command>
  
There is an additional host, which will be referred to as '''pandorafms''', where Pandora FMS is or will be installed.
+
Hay un host adicional, denominado '''pandorafms''', en el que se encuentra o se instalará Pandora FMS.
  
=== Prerequisites ===
+
==== Requisitos previos ====
  
CentOS version 7 must be installed on all hosts, and they must be able to resolve each other's hostnames.
+
Se debe instalar CentOS version 7 en todos los hosts, y deben poder resolver los hostnames de los demás hosts.
  
 
  node1# ping node2
 
  node1# ping node2
Line 191: Line 490:
 
  PING node2 (192.168.0.2) 56(84) bytes of data.
 
  PING node2 (192.168.0.2) 56(84) bytes of data.
  
An Open SSH server must be installed and running on every host. Remove the banner displayed by Open SSH:
+
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# [ -f /etc/cron.hourly/motd_rebuild ] && rm -f /etc/cron.hourly/motd_rebuild
Line 197: Line 496:
 
  all# systemctl restart sshd
 
  all# systemctl restart sshd
  
{{Warning|The Pandora FMS Database HA Tool will not work properly if a banner is configured for Open SSH. }}
+
{{Warning|La herramienta de base de datos HA de Pandora FMS no funcionará correctamente si se configura un banner para Open SSH. }}
  
Generate new SSH authentication keys for each host and copy the public key to each of the other hosts (replaces the example keys with the actual ones):
+
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 clusted 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# cat $HOME/.ssh/id_rsa.pub
+
  node1# ssh-copy-id -p22 [email protected]
  ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA0xoEf2A+in/uReenQzJniYLrSxcFOjNUOpwDJi2jIGGoUrEd8c8gn8ut1p57H73SWlI5+YQAhfSF0BaM158XD5bIZC94M05ZVFs8UCjjuATrgNJ38hboF3CNrfWYhA5m1JraKsT2EAMNCSz55OI+GrCxmeM6o4DMoQu2W6WZu6YX8F7axCh5uOBLh1W06sgMcudn6x/lwzYhPUWm9OiS58n6pd9SkC2LoDYoRetZE2GW/1M9t+8UliSwdCpPpGIW3R5avEPfXii3XVIyO43YTpPR2cqHLwGAJN1DVp61lYMXnLSvJma9LG6gnzl0MB865YysB66o9w2v8C28asYSew== [email protected]
+
  node2# ssh node2
 
   
 
   
 
  node2# echo -e "\n\n\n" | ssh-keygen -t rsa
 
  node2# echo -e "\n\n\n" | ssh-keygen -t rsa
  node2# cat $HOME/.ssh/id_rsa.pub
+
  node2# ssh-copy-id -p22 [email protected]node1
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA3PCvWkX4kDm1fD5FWsvAN/dl9VEZV7k7cOGLmOKcDLHUE3OkS6+7/4b9J65mssZ1yc/ocQe/dvFQNJlkxk117PK+NP5PB8s7+UI5LBZHunmLAuajnLbFYwyTDIF2qHRCxsRJfU4HXHY/DIZNoL90Enrk3Al+pTSdYr6mK5QJ4LZ3DX3mN3DpeMW8duWgWP3VMY/QhDJ+pGCJ/dOW3zYMdAQwSVqzHzgUR+hhMCmgOn8ACkeEMa2rUyzlblnGMApTbK1rim82SRupiNoaPfHjSiK/GJ5l+DpBCLp26Fj+AMO2kgRkWSAmWdJh/40T7TFj4uhTJgrnPsvrvkjpp0vppw== [email protected]
+
node2# ssh node1
 
   
 
   
 
  pandorafms# echo -e "\n\n\n" | ssh-keygen -t rsa
 
  pandorafms# echo -e "\n\n\n" | ssh-keygen -t rsa
  pandorafms# cat $HOME/.ssh/id_rsa.pub
+
  pandorafms# ssh-copy-id -p22 [email protected]
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAx6eRCGw86qDcjzSENlPQ1/7ukOcD0xxi9jG/Kgf1syT1ZYz4trJHSxVG05iCpVF0YRZa1YcoWltcCNCOu3rD2jwbHl98CHmKXpq+kGnSEf02NtEiCP9366/tq9V8zknBVOJE3oND0GuhAvDUo1OqxlI35gR7bO6zXTAxXAv3o736lHqzCjmsn8wA3XfZy+CHBtTpsovCqr1SG9geIcmXRYSJpb5SmE2iIuekybYM0yWfK6c0KY0zPl4v21wX1GU6O2KE7+Q8tSDxEr/3NBeLOFZpP/0A8sYlL1U4+Xcfbi45YGZ2x7oZZ1ZMtp4OwL3v2w8fILakCsfpHcpONBZmHw== [email protected]
+
  pandorafms# ssh-copy-id -p22 [email protected]
 
node1# echo 'ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA3PCvWkX4kDm1fD5FWsvAN/dl9VEZV7k7cOGLmOKcDLHUE3OkS6+7/4b9J65mssZ1yc/ocQe/dvFQNJlkxk117PK+NP5PB8s7+UI5LBZHunmLAuajnLbFYwyTDIF2qHRCxsRJfU4HXHY/DIZNoL90Enrk3Al+pTSdYr6mK5QJ4LZ3DX3mN3DpeMW8duWgWP3VMY/QhDJ+pGCJ/dOW3zYMdAQwSVqzHzgUR+hhMCmgOn8ACkeEMa2rUyzlblnGMApTbK1rim82SRupiNoaPfHjSiK/GJ5l+DpBCLp26Fj+AMO2kgRkWSAmWdJh/40T7TFj4uhTJgrnPsvrvkjpp0vppw== [email protected]' >> $HOME/.ssh/authorized_keys
 
node1# echo 'ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAx6eRCGw86qDcjzSENlPQ1/7ukOcD0xxi9jG/Kgf1syT1ZYz4trJHSxVG05iCpVF0YRZa1YcoWltcCNCOu3rD2jwbHl98CHmKXpq+kGnSEf02NtEiCP9366/tq9V8zknBVOJE3oND0GuhAvDUo1OqxlI35gR7bO6zXTAxXAv3o736lHqzCjmsn8wA3XfZy+CHBtTpsovCqr1SG9geIcmXRYSJpb5SmE2iIuekybYM0yWfK6c0KY0zPl4v21wX1GU6O2KE7+Q8tSDxEr/3NBeLOFZpP/0A8sYlL1U4+Xcfbi45YGZ2x7oZZ1ZMtp4OwL3v2w8fILakCsfpHcpONBZmHw== [email protected]' >> $HOME/.ssh/authorized_keys
 
 
node2# echo 'ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA0xoEf2A+in/uReenQzJniYLrSxcFOjNUOpwDJi2jIGGoUrEd8c8gn8ut1p57H73SWlI5+YQAhfSF0BaM158XD5bIZC94M05ZVFs8UCjjuATrgNJ38hboF3CNrfWYhA5m1JraKsT2EAMNCSz55OI+GrCxmeM6o4DMoQu2W6WZu6YX8F7axCh5uOBLh1W06sgMcudn6x/lwzYhPUWm9OiS58n6pd9SkC2LoDYoRetZE2GW/1M9t+8UliSwdCpPpGIW3R5avEPfXii3XVIyO43YTpPR2cqHLwGAJN1DVp61lYMXnLSvJma9LG6gnzl0MB865YysB66o9w2v8C28asYSew== [email protected]' >> $HOME/.ssh/authorized_keys
 
  node2# echo 'ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAx6eRCGw86qDcjzSENlPQ1/7ukOcD0xxi9jG/Kgf1syT1ZYz4trJHSxVG05iCpVF0YRZa1YcoWltcCNCOu3rD2jwbHl98CHmKXpq+kGnSEf02NtEiCP9366/tq9V8zknBVOJE3oND0GuhAvDUo1OqxlI35gR7bO6zXTAxXAv3o736lHqzCjmsn8wA3XfZy+CHBtTpsovCqr1SG9geIcmXRYSJpb5SmE2iIuekybYM0yWfK6c0KY0zPl4v21wX1GU6O2KE7+Q8tSDxEr/3NBeLOFZpP/0A8sYlL1U4+Xcfbi45YGZ2x7oZZ1ZMtp4OwL3v2w8fILakCsfpHcpONBZmHw== [email protected]' >> $HOME/.ssh/authorized_keys
 
 
pandorafms# echo 'ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA0xoEf2A+in/uReenQzJniYLrSxcFOjNUOpwDJi2jIGGoUrEd8c8gn8ut1p57H73SWlI5+YQAhfSF0BaM158XD5bIZC94M05ZVFs8UCjjuATrgNJ38hboF3CNrfWYhA5m1JraKsT2EAMNCSz55OI+GrCxmeM6o4DMoQu2W6WZu6YX8F7axCh5uOBLh1W06sgMcudn6x/lwzYhPUWm9OiS58n6pd9SkC2LoDYoRetZE2GW/1M9t+8UliSwdCpPpGIW3R5avEPfXii3XVIyO43YTpPR2cqHLwGAJN1DVp61lYMXnLSvJma9LG6gnzl0MB865YysB66o9w2v8C28asYSew== [email protected]' >> $HOME/.ssh/authorized_keys
 
pandorafms# echo 'ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA3PCvWkX4kDm1fD5FWsvAN/dl9VEZV7k7cOGLmOKcDLHUE3OkS6+7/4b9J65mssZ1yc/ocQe/dvFQNJlkxk117PK+NP5PB8s7+UI5LBZHunmLAuajnLbFYwyTDIF2qHRCxsRJfU4HXHY/DIZNoL90Enrk3Al+pTSdYr6mK5QJ4LZ3DX3mN3DpeMW8duWgWP3VMY/QhDJ+pGCJ/dOW3zYMdAQwSVqzHzgUR+hhMCmgOn8ACkeEMa2rUyzlblnGMApTbK1rim82SRupiNoaPfHjSiK/GJ5l+DpBCLp26Fj+AMO2kgRkWSAmWdJh/40T7TFj4uhTJgrnPsvrvkjpp0vppw==  [email protected]' >> $HOME/.ssh/authorized_keys
 
 
node1# ssh node2
 
 
node2# ssh node1
 
 
 
  pandorafms# ssh node1
 
  pandorafms# ssh node1
 
  pandorafms# ssh node2
 
  pandorafms# ssh node2
  
On the Pandora FMS node, copy the key pair to ''/usr/share/httpd/.ssh/'':
+
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# cp -r /root/.ssh/ /usr/share/httpd/
 
  pandorafms# chown -R apache:apache /usr/share/httpd/.ssh/
 
  pandorafms# chown -R apache:apache /usr/share/httpd/.ssh/
  
The following steps are only necessary if the nodes are running SSH on a non-standard port. Replace ''22'' with the right port number:
+
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 node1\n    Port 22" >> /root/.ssh/config
 
  all# echo -e "Host node2\n    Port 22" >> /root/.ssh/config
 
  all# echo -e "Host node2\n    Port 22" >> /root/.ssh/config
  
=== Installation ===
+
==== Instalación de Percona ====
  
==== Installing Percona ====
+
Instalamos el paquete necesario:
 
 
Install the required packages:
 
  
 
  all# yum install -y http://www.percona.com/downloads/percona-release/redhat/0.1-4/percona-release-0.1-4.noarch.rpm
 
  all# yum install -y http://www.percona.com/downloads/percona-release/redhat/0.1-4/percona-release-0.1-4.noarch.rpm
 +
 
  all# yum install -y Percona-Server-server-57 percona-xtrabackup-24
 
  all# yum install -y Percona-Server-server-57 percona-xtrabackup-24
  
Make sure the Percona service is disabled, since it will be managed by the cluster:
+
Nos aseguramos de que el servicio Percona está desactivado, ya que lo gestionará el cluster:
  
 
  all# systemctl disable mysqld
 
  all# systemctl disable mysqld
  
Configure Percona, replacing '''<ID>''' with a number that must be unique for each cluster node:
+
{{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|Replication will not work if two nodes have the same '''SERVER_ID'''. }}
+
{{Warning|La replicación de la base de datos no funcionará si dos nodos tienen el mismo '''SERVER_ID'''. }}
  
 
  all# export SERVER_ID=<ID>
 
  all# export SERVER_ID=<ID>
 +
all# export POOL_SIZE=$(grep -i total /proc/meminfo | head -1 | \
 +
awk '{print $(NF-1)*0.4/1024}' | sed s/\\..*$/M/g)
 
  all# cat <<EOF > /etc/my.cnf
 
  all# cat <<EOF > /etc/my.cnf
    [mysqld]
+
[mysqld]
    server_id=$SERVER_ID
+
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
 
      
 
      
    datadir=/var/lib/mysql
+
binlog-format=ROW
    socket=/var/lib/mysql/mysql.sock
+
log-slave-updates=true
    symbolic-links=0
+
sync-master-info=1
    log-error=/var/log/mysqld.log
+
sync_binlog=1
    show_compatibility_56=on
+
max_binlog_size = 100M
   
+
replicate-do-db=pandora
    max_allowed_packet = 64M
+
port=3306  
    innodb_buffer_pool_size = 256M
+
report-port=3306
    innodb_lock_wait_timeout = 90
+
report-host=master
    innodb_file_per_table
+
gtid-mode=off
    innodb_flush_method = O_DIRECT
+
enforce-gtid-consistency=off
    innodb_log_file_size = 64M
+
master-info-repository=TABLE
    innodb_log_buffer_size = 16M
+
relay-log-info-repository=TABLE
    thread_cache_size = 8
+
    max_connections = 100
+
sync_relay_log = 10
    innodb_flush_log_at_trx_commit=1
+
sync_relay_log_info = 10
    key_buffer_size=4M
+
slave_compressed_protocol = 1
    read_buffer_size=128K
+
slave_parallel_type = LOGICAL_CLOCK
    read_rnd_buffer_size=128K
+
slave_parallel_workers = 10
    sort_buffer_size=128K
+
innodb_flush_log_at_trx_commit = 2
    join_buffer_size=4M
+
innodb_flush_log_at_timeout = 1800
    log-bin=mysql-bin
+
    query_cache_type = 1
+
    query_cache_size = 4M
+
[mysqld_safe]
    query_cache_limit = 8M
+
log-error=/var/log/mysqld.log
    sql_mode=""
+
pid-file=/var/run/mysqld/mysqld.pid
    expire_logs_days=3
+
   
+
[client]
    binlog-format=ROW
+
user=root
    log-slave-updates=true
+
password=pandora
    sync-master-info=1
+
EOF
    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
 
   
 
    [mysqld_safe]
 
    log-error=/var/log/mysqld.log
 
    pid-file=/var/run/mysqld/mysqld.pid
 
   
 
    [client]
 
    user=root
 
    password=pandora
 
    EOF
 
  
Start the Percona server:
+
Iniciamos el servidor Percona:
  
 
  all# systemctl start mysqld
 
  all# systemctl start mysqld
  
A new temporary password will be generated and logged to /var/log/mysqld.log. Connect to the Percona server and change the root password:
+
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)
+
  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> SET PASSWORD FOR 'root'@'localhost' = PASSWORD('Pandor4!');
 
  mysql> UNINSTALL PLUGIN validate_password;
 
  mysql> UNINSTALL PLUGIN validate_password;
 
  mysql> SET PASSWORD FOR 'root'@'localhost' = PASSWORD('pandora');
 
  mysql> SET PASSWORD FOR 'root'@'localhost' = PASSWORD('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
 
  mysql> quit
  
==== Installing Pandora FMS ====
+
==== Instalación de Pandora FMS ====
  
===== New Pandora FMS installation =====
+
===== Nueva instalación de Pandora FMS =====
  
Install Pandora FMS on the newly created database. For more information see:
+
Instalamos Pandora FMS en la base de datos recién creada. Para más información, consulta:
  
 
  https://wiki.pandorafms.com/index.php?title=Pandora:Documentation_en:Installing
 
  https://wiki.pandorafms.com/index.php?title=Pandora:Documentation_en:Installing
  
Stop the Pandora FMS server:
+
Detenemos el servidor de Pandora FMS:
  
  newpandorafms# /etc/init.d/pandora_server stop
+
  pandorafms# /etc/init.d/pandora_server stop
  
===== Existing Pandora FMS installation =====
+
===== Instalación de Pandora FMS existente =====
  
Stop your Pandora FMS Server:
+
Detenemos el servidor de Pandora FMS:
  
 
  pandorafms# /etc/init.d/pandora_server stop
 
  pandorafms# /etc/init.d/pandora_server stop
  
Backup the Pandora FMS database:
+
Hacemos una copia de seguridad de la base de datos de Pandora FMS:
  
 
  pandorafms# mysqldump -uroot -ppandora --databases pandora > /tmp/pandoradb.sql
 
  pandorafms# mysqldump -uroot -ppandora --databases pandora > /tmp/pandoradb.sql
  pandorafms# scp /tmp/pandorafms.sql node1:/tmp/
+
  pandorafms# scp /tmp/pandoradb.sql node1:/tmp/
  
Load it into the new database:
+
Lo cargamos a la nueva base de datos:
  
  node1# mysql -uroot -ppandora < /tmp/pandoradb.sql
+
  node1# mysql -uroot -ppandora pandora -e source "/tmp/pandoradb.sql"
node1# systemctl stop mysqld
 
  
==== Setting up replication ====
+
==== Configuración de la replicación ====
  
Grant the required privileges on all databases:
+
Otorgamos los privilegios necesarios para la replicación con el fin de trabajar en todas las bases de datos:
  
 
  all# mysql -uroot -ppandora
 
  all# mysql -uroot -ppandora
 
  mysql> GRANT ALL ON pandora.* TO 'root'@'%' IDENTIFIED BY 'pandora';
 
  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 ON *.*
  mysql> GRANT REPLICATION CLIENT, REPLICATION SLAVE, SUPER, PROCESS, RELOAD ON *.* TO 'root'@'localhost' IDENTIFIED BY 'pandora';
+
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> GRANT select ON mysql.user TO 'root'@'%' IDENTIFIED BY 'pandora';
 
  mysql> FLUSH PRIVILEGES;
 
  mysql> FLUSH PRIVILEGES;
 
  mysql> quit
 
  mysql> quit
  
Backup the database of the first node and write down the master log file name and position (in the example, mysql-bin.000001 and 785):
+
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 --no-timestamp /root/pandoradb.bak/
 
  node1# innobackupex --apply-log /root/pandoradb.bak/
 
  node1# innobackupex --apply-log /root/pandoradb.bak/
Line 375: Line 673:
 
  mysql-bin.000001        785
 
  mysql-bin.000001        785
  
Load the database on the second node and configure it to replicate from the first node (set MASTER_LOG_FILE and MASTER_LOG_FILE to the values found in the previous step):
+
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):
 +
 
 +
{{Warning|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
 
  node2# systemctl stop mysqld
Line 385: Line 685:
 
  node2# systemctl start mysqld
 
  node2# systemctl start mysqld
 
  node2# mysql -uroot -ppandora
 
  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> 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> START SLAVE;
 
  mysql> SHOW SLAVE STATUS \G
 
  mysql> SHOW SLAVE STATUS \G
Line 449: Line 751:
 
  mysql> QUIT
 
  mysql> QUIT
 
   
 
   
all# systemctl stop mysqld
 
  
==== Configuring the two node cluster ====
+
{{Warning|Debemos asegurarnos de que '''Slave_IO_Running''' y '''Slave_SQL_Running''' muestran '''Yes'''. Otros valores pueden ser diferentes a los del ejemplo.}}
 +
 
 +
{{Warning|Se recomienda <b>no</b> utilizar usuario <b>root</b> para la realización de este proceso. Es aconsejable dar permisos a otro usuario encargado de gestionar la base de datos para evitar posibles conflictos.}}
 +
 
 +
==== Configuración del cluster de dos nodos ====
  
Install the required packages:
+
Instalamos los paquetes necesarios:
  
 
  yum install -y epel-release corosync ntp pacemaker pcs
 
  yum install -y epel-release corosync ntp pacemaker pcs
Line 460: Line 765:
 
  all# systemctl enable corosync
 
  all# systemctl enable corosync
 
  all# systemctl enable pcsd
 
  all# systemctl enable pcsd
   
+
  all# cp /etc/corosync/corosync.conf.example /etc/corosync/corosync.conf
 +
 
 
  all# systemctl start ntpd
 
  all# systemctl start ntpd
 
  all# systemctl start corosync
 
  all# systemctl start corosync
 
  all# systemctl start pcsd
 
  all# systemctl start pcsd
  
Stop the Percona server:
+
Detenemos el servidor Percona:
  
 
  node1# systemctl stop mysqld
 
  node1# systemctl stop mysqld
  
Authenticate all the nodes in the cluster:
+
node2# systemctl stop mysqld
 +
 
 +
Autenticamos todos los nodos en el cluster:
  
Create and start the cluster:
+
Creamos e iniciamos el cluster:
  
 
  all# echo hapass | passwd hacluster --stdin
 
  all# echo hapass | passwd hacluster --stdin
all# cp /etc/corosync/corosync.conf.example /etc/corosync/corosync.conf
+
 
 
 
  node1# pcs cluster auth -u hacluster -p hapass --force node1 node2
 
  node1# pcs cluster auth -u hacluster -p hapass --force node1 node2
 
  node1# pcs cluster setup --force --name pandoraha node1 node2
 
  node1# pcs cluster setup --force --name pandoraha node1 node2
Line 483: Line 790:
 
  node1# pcs property set no-quorum-policy=ignore
 
  node1# pcs property set no-quorum-policy=ignore
  
Check the status of the cluster:
+
Comprobamos el estado del cluster:
  
 
  node#1 pcs status
 
  node#1 pcs status
Line 505: Line 812:
 
       pcsd: active/enabled
 
       pcsd: active/enabled
  
Install the Percona pacemaker replication agent:
+
{{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:
  
 
  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 mysql https://github.com/Percona-Lab/pacemaker-replication-agents/raw/1.0.0-stable/agents/mysql_prm
+
  all# curl -L -o mysql https://github.com/Percona-Lab/\
 +
pacemaker-replication-agents/raw/1.0.0-stable/agents/mysql_prm
 
  all# chmod u+x mysql
 
  all# chmod u+x mysql
  
Configure the cluster resources. Replace VIRT_IP with the virtual IP address of your choice:
+
Configuramos los recursos del cluster. Sustituimos '''<VIRT_IP>''' por la dirección IP virtual de preferencia:
 +
 
 +
{{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.}}
  
  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" 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" op monitor role="Slave" timeout="30" interval="10"
+
node1# export VIP=<VIRT_IP>
  node1# pcs resource create pandoraip ocf:heartbeat:IPaddr2 ip=VIRT_IP cidr_netmask=24 op monitor interval=20s
+
  node1# pcs resource create pandoradb ocf:percona:mysql config="/etc/my.cnf" \
  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"
+
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 colocation add master master_pandoradb with pandoraip
 
  node1# pcs constraint order promote master_pandoradb then start pandoraip
 
  node1# pcs constraint order promote master_pandoradb then start pandoraip
  
Check the status of the cluster:
+
Comprobamos el estado del cluster:
  
 
  node1# pcs status
 
  node1# pcs status
Line 547: Line 870:
 
       pcsd: active/enabled
 
       pcsd: active/enabled
  
==== Configuring Pandora FMS ====
+
{{Warning|Ambos nodos deberían estar online ('''Online: [ node1 node2 ]'''). Otros valores pueden ser diferentes a los del ejemplo.}}
 +
 
 +
==== Configuración del cluster de dos nodos con usuario "no root"====
 +
 
 +
Se realizará de manera similar a la anterior. Se deberá de 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
  
Make sure ''php-pecl-ssh2'' is installed:
+
# Create PCS user - Local user
 +
pcs acl user create <usuario> <rol>
 +
 
 +
# Login into PCS from ALL nodes
 +
su - <usuario>
 +
pcs status
 +
Username: <usuario>
 +
Password: *****
 +
 
 +
# Wait for 'Authorized' message, ignore output. Wait a second and retry 'pcs status' command
 +
 
 +
==== Configuración de Pandora FMS ====
 +
 
 +
Nos aseguramos de que ''php-pecl-ssh2'' está instalado:
  
 
  pandorafms# yum install php-pecl-ssh2
 
  pandorafms# yum install php-pecl-ssh2
 
  pandorafms# systemctl restart httpd
 
  pandorafms# systemctl restart httpd
  
There are two parameters in ''/etc/pandora/pandora_server.conf'' that control the behavior of the Pandora FMS Database HA Tool. Adjust them to suit your needs:
+
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).                                                                                                                                               
 
  # Pandora FMS Database HA Tool execution interval in seconds (PANDORA FMS ENTERPRISE ONLY).                                                                                                                                               
Line 562: Line 914:
 
  ha_monitoring_interval 60
 
  ha_monitoring_interval 60
  
Point your Pandora FMS to the virtual IP address you chose in the previous section:
+
Dirigimos Pandora FMS a la dirección IP virtual del maestro (sustituyendo '''<IP>''' por la dirección IP virtual):
  
  pandorafms# sed -i -e 's/^dbhost .*/dbhost <virtual IP>/' /etc/pandora/pandora_server.conf
+
pandorafms# export VIRT_IP=<IP>
  pandorafms# sed -i -e 's/\$config\["dbhost"\]=".*";/$config["dbhost"]="<virtual IP>";/' /var/www/html/pandora_console/include/config.php
+
  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
  
Install and start the pandora_ha service:
+
Instalamos e iniciamos el servicio pandora_ha:
  
 
  pandorafms# cat > /etc/systemd/system/pandora_ha.service <<-EOF
 
  pandorafms# cat > /etc/systemd/system/pandora_ha.service <<-EOF
Line 587: Line 942:
 
  pandorafms# systemctl start pandora_ha
 
  pandorafms# systemctl start pandora_ha
  
Create database entries for the two nodes:  
+
Iniciamos sesión en la consola de Pandora FMS y navegamos hasta ''Servers -> Manage database HA'':
  
pandorafms# mysql -uroot -ppandora
+
<center>
mysql> INSERT INTO pandora.tdatabase (host, os_user) VALUES ('node1', 'root'), ('node2', 'root');
+
[[image:HAnuevo1.JPG]]
 +
</center>
  
Log-in to your Pandora FMS Console and navigate to ''Servers -> Manage database HA'':
+
Hacemos click ''Add new node'' y creamos una entrada para el primer nodo:  
  
 
<center>
 
<center>
[[image:Manage_ha_menu.png]]
+
[[image:Manage_ha_add_node.png]]
 
</center>
 
</center>
  
You should see something similar to this:
+
Después, hacemos click en ''Create slave'' y añadimos una nueva entrada en el segundo nodo. Debería aparecer algo parecido a:
  
 
<center>
 
<center>
Line 604: Line 960:
 
</center>
 
</center>
  
{{Warning|''Seconds behind master'' should be close to 0. If it keeps increasing, replication is nor working.}}
+
{{Warning|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.}}
  
=== Adding a new node to the cluster ===
+
{{Warning|''Seconds behind master'' debería estar cerca de 0. Si sigue aumentando, la replicación no está aumentando.}}
  
Install Percona (see ''Installing Percona''). Backup the database of the master node (node1 in this example) and write down the master log file name and position (in the example, mysql-bin.000001 and 785):
+
=== Añadir un nuevo nodo al cluster ===
  
 +
Instalamos Percona (ver ''Instalación de Percona''). 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 --no-timestamp /root/pandoradb.bak/
 
  node1# innobackupex --apply-log /root/pandoradb.bak/
 
  node1# innobackupex --apply-log /root/pandoradb.bak/
Line 615: Line 974:
 
  mysql-bin.000001        785
 
  mysql-bin.000001        785
  
Load the database on the new node, which we will call node3, and configure it to replicate from node1 (set MASTER_LOG_FILE and MASTER_LOG_FILE to the values found in the previous step):
+
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
 
  node3# systemctl stop mysqld
Line 625: Line 984:
 
  node3# systemctl start mysqld
 
  node3# systemctl start mysqld
 
  node3# mysql -uroot -ppandora
 
  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> 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> START SLAVE;
 
  mysql> SHOW SLAVE STATUS \G
 
  mysql> SHOW SLAVE STATUS \G
Line 691: Line 1,052:
 
  node3# systemctl stop mysqld
 
  node3# systemctl stop mysqld
  
Add the new node to the cluster:
+
{{Warning|Conviene asegurarse de que '''Slave_IO_Running''' y '''Slave_SQL_Running''' muestran '''Yes'''. Otros valores podrían ser diferentes de los del ejemplo.}}
 +
 
 +
Añadimos un nuevo nodo al cluster:
  
 
  node3# echo -n hapass | passwd hacluster --stdin
 
  node3# echo -n hapass | passwd hacluster --stdin
Line 697: Line 1,060:
 
  node3# mkdir percona
 
  node3# mkdir percona
 
  node3# cd percona
 
  node3# cd percona
  node3# curl -L -o mysql https://github.com/Percona-Lab/pacemaker-replication-agents/raw/master/agents/mysql_prm
+
  node3# curl -L -o mysql https://github.com/Percona-Lab/\
 +
pacemaker-replication-agents/raw/master/agents/mysql_prm
 
  node3# chmod u+x mysql
 
  node3# chmod u+x mysql
node3# pcs cluster auth -u hacluster -p hapass --force node3
 
node3# pcs cluster node add --enable --start node3
 
  
'''clone-max''' must be equal to the number of nodes in your cluster:
+
node1# pcs cluster auth -u hacluster -p hapass --force node3
 +
node1# pcs cluster node add --enable --start node3
  
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"
+
Configuramos '''clone-max''' al número de nodos en nuestro cluster (3 en este ejemplo):
  
Check the status of the cluster:
+
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
 
  node3# pcs status
Line 732: Line 1,099:
 
   pcsd: active/enabled
 
   pcsd: active/enabled
  
=== Fixing a broken node ===
+
{{Warning|Todos los nodos deberían estar online ('''Online: [ node1 node2 node3 ]'''). Otros valores podrían ser diferentes de los del ejemplo.}}
  
We will use node2 as an example. Put node2 into standby mode:
+
=== Reparación de un nodo roto ===
 +
 
 +
Utilizaremos node2 como ejemplo. Ponemos node2 en modo standby:
  
 
  node2# pcs node standby node2
 
  node2# pcs node standby node2
Line 762: Line 1,131:
 
       pcsd: active/enabled
 
       pcsd: active/enabled
  
Backup Percona's data directory:
+
{{Warning|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# systemctl stop mysqld
 +
node2# [ -e /var/lib/mysql.bak ] && rm -rf /var/lib/mysql.bak
 
  node2# mv /var/lib/mysql /var/lib/mysql.bak
 
  node2# mv /var/lib/mysql /var/lib/mysql.bak
  
Backup the database of the master node (node1 in this example) and write down the master log file name and position (in the example, mysql-bin.000001 and 785):
+
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 este 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 --no-timestamp /root/pandoradb.bak/
 
  node1# innobackupex --apply-log /root/pandoradb.bak/
 
  node1# innobackupex --apply-log /root/pandoradb.bak/
Line 774: Line 1,147:
 
  mysql-bin.000001        785
 
  mysql-bin.000001        785
  
Load the database on the broken node and configure it to replicate from node1 (set MASTER_LOG_FILE and MASTER_LOG_FILE to the values found in the previous step):
+
Cargamos la base de datos del nodo roto y lo configuramos para replicar desde el node1 (configuramos MASTER_LOG_FILE y MASTER_LOG_POS a los valores del paso anterior):
  
 
  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 782: Line 1,155:
 
  node2# systemctl start mysqld
 
  node2# systemctl start mysqld
 
  node2# mysql -uroot -ppandora
 
  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> 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> START SLAVE;
 
  mysql> SHOW SLAVE STATUS \G
 
  mysql> SHOW SLAVE STATUS \G
Line 848: Line 1,223:
 
  node2# systemctl stop mysqld
 
  node2# systemctl stop mysqld
  
Remove node2 from standby mode:
+
{{Warning|Conviene asegurarse de que '''Slave_IO_Running''' y '''Slave_SQL_Running''' muestran '''Yes'''. Otros valores podrían ser diferentes de los del ejemplo.}}
 +
 
 +
Desactivamos el modo standby del node2:
  
 
  node2# pcs node unstandby node2
 
  node2# pcs node unstandby node2
 
  node2# pcs resource cleanup --node node2
 
  node2# pcs resource cleanup --node node2
  
Check the status of the cluster:
+
Comprobamos el estado del cluster:
  
 
  node3# pcs status
 
  node3# pcs status
Line 879: Line 1,256:
 
   pcsd: active/enabled
 
   pcsd: active/enabled
  
=== Troubleshooting ===
+
{{Warning|Ambos nodos deberían estar online ('''Online: [ node1 node2 ]'''). Otros valores podrían ser diferentes de los del ejemplo.}}
 +
 
 +
=== Resolución de problemas ===
  
==== What do I do if one of the cluster nodes is not working? ====
+
==== ¿Qué hacer si uno de los nodos del cluster no funciona? ====
  
 
<center>
 
<center>
Line 887: Line 1,266:
 
</center>
 
</center>
  
The service will not be affected as long as the master node is running. If the master node fails, a slave node will be automatically promoted to master. See [[Pandora:Documentation_en:HA_Cluster#Fixing_a_broken_node|Fixing a broken node]].
+
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 [[Pandora:Documentation_es:HA#Reparaci.C3.B3n_de_un_nodo_roto|Reparación de un nodo roto]].
  
  

Latest revision as of 01:33, 30 September 2019

Volver a Índice de Documentacion Pandora FMS

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 cientos de 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.



Ha1.png



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:

  1. Base de datos
  2. Servidor
  3. Consola


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

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

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


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

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

Dim std1.png


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

Dim std2.png


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

Dim std3.png


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

Dim ha1.png


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


Dim ha2.png


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


Dim ha3.png


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).


Dim ha4.png


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 por NFS los siguientes directorios 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 por NFS.

  • /var/spool/pandora/data_in/conf
  • /var/spool/pandora/data_in/collections
  • /var/spool/pandora/data_in/md5



Ha2.png



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.

Template warning.png

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 sólo 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.



Ha3.png



El balanceo de carga entere los distintos servidores se realiza en la parte de administración del agente en el menú "setup".



Ha4.png



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 sólo 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 tengan un valor mas alto en master.

Template warning.png

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 Servers con maestro 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 parametros:

  • 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. Cualquiera de ellas podrá usarse de forma simultánea desde diferentes ubicaciones por diferentes usuarios. Utilizando un balanceador Web delante de las consolas, se podrá acceder a las mismas sin saber realmente a cuál se está accediendo ya que el sistema de sesiones se gestiona mediante cookies y ésta queda almacenada en el navegador.

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

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.

OUM1.JPG

OUM2.JPG

1.7 Alta disponibilidad en la Base de datos

Info.png

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.

 


Template warning.png

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.

Ha cluster diagram.png

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 cuando en caso necesario. pandora_ha se monitoriza a su vez con systemd.

Template warning.png

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.

1.7.1.1 Requisitos previos

Se debe instalar CentOS version 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

Template warning.png

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:

Template warning.png

Se pueden generar claves para un usuario que no sea root para una posterior instalación de clusted con usuario "no root".

 


node1# echo -e "\n\n\n" | ssh-keygen -t rsa
node1# ssh-copy-id -p22 [email protected]
node2# 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 -y http://www.percona.com/downloads/percona-release/redhat/0.1-4/percona-release-0.1-4.noarch.rpm

all# 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:

all# systemctl disable mysqld

Template warning.png

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:

Template warning.png

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

 


all# export SERVER_ID=<ID>
all# export POOL_SIZE=$(grep -i total /proc/meminfo | head -1 | \
awk '{print $(NF-1)*0.4/1024}' | sed s/\\..*$/M/g)
all# 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:

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

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, consulta:

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):

Template warning.png

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

Template warning.png

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

 


Template warning.png

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:

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

Template warning.png

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:

all# cd /usr/lib/ocf/resource.d/
all# mkdir percona
all# cd percona
all# curl -L -o mysql https://github.com/Percona-Lab/\
pacemaker-replication-agents/raw/1.0.0-stable/agents/mysql_prm
all# chmod u+x mysql

Configuramos los recursos del cluster. Sustituimos <VIRT_IP> por la dirección IP virtual de preferencia:

Template warning.png

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.

 


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

Template warning.png

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á de 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:

HAnuevo1.JPG

Hacemos click Add new node y creamos una entrada para el primer nodo:

Manage ha add node.png

Después, hacemos click en Create slave y añadimos una nueva entrada en el segundo nodo. Debería aparecer algo parecido a:

Manage ha view.png

Template warning.png

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.

 


Template warning.png

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

Instalamos Percona (ver Instalación de Percona). 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

Template warning.png

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

 


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 mysql https://github.com/Percona-Lab/\
pacemaker-replication-agents/raw/master/agents/mysql_prm
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

Template warning.png

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

 


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

Template warning.png

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 escribimos el nombre y la posición del archivo de log maestro (en este 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 del nodo roto y lo configuramos para replicar desde el node1 (configuramos MASTER_LOG_FILE y MASTER_LOG_POS a los valores del paso anterior):

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

node2# systemctl stop mysqld

Template warning.png

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

 


Desactivamos el modo standby del node2:

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

Comprobamos el estado del cluster:

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

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

Template warning.png

Ambos nodos deberían estar online (Online: [ node1 node2 ]). 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?

Manage ha failed.png

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.



Go back to Pandora FMS documentation index