Entornos HA con Percona XtraDB Cluster

Introducción

Pandora FMS se fundamenta en una base de datos MySQL para configurar y almacenar datos. Conocemos que para escalar (crecer) “horizontalmente” existe la Metaconsola de Pandora FMS para la monitorización de todos los dispositivos necesarios. Sin embargo hay ciertos escenarios que se puedan quedar pequeños para el uso de la Metaconsola, con la dificultad que provoca en su gestión, así como pueden ser demasiado grandes como almacenar todos los datos en una única base de datos.

Para solventar esta problemática se confia en Percona XtraDB Cluster, que ofrece la posibilidad de poder usar en modo multimaster (varios servidores principales) para las tareas de lectura y escritura de dichos servidores. De esta forma se reparte la carga entre los distintos servidores donde se aloje este clúster dando más capacidad de procesamiento a la base de datos que la que puede ofrecer un nodo standalone (nodo singular). Así se puede incrementar el número de métricas a monitorizar en un solo nodo de Pandora FMS.

La representación de este esquema ofrece la posibilidad de instalar en un mismo servidor, un nodo de replicación de Percona XtraDB Cluster junto al servidor de Pandora FMS y la Consola web o bien separar la instalación de los mismos. Bastará con apuntar cada uno de los servidores o Consolas web de Pandora FMS al nodo donde se necesite que escriba o lea, pudiendo repartir la carga del entorno como sea más conveniente en cada entorno.

El número mínimo de nodos para el funcionamiento del clúster es de 3 nodos y siempre debe haber 2 de ellos activos para que la base de datos esté operativa.

Instalación Percona XtraDB Cluster

Para realizar una correcta instalación de Percona XtraDB Cluster, primero se debe instalar en todos los nodos el servidor y el cliente de Percona XtraDB Cluster.

Los datos de los nodos a usar en el ejemplo van a ser los siguientes:

NODO 1:

pandora001
192.168.80.111

NODO 2:

pandora002
192.168.80.112

NODO 3:

pandora003
192.168.80.113

Ejecución en todos los nodos

# yum install Percona-XtraDB-Cluster-server-57 Percona-XtraDB-Cluster-client-57

Una vez instalado en todos los nodos, inicie el servicio en cada uno de ellos y configure una contraseña que sea común para el usuario root, así como un usuario (en este caso sstuser) que se utilizará para la replicación entre todos los nodos. Ejecute:

# systemctl start mysqld

Obtenga una contraseña provisional para root y acceda con ella al servidor MySQL (recuerde que se debe ejecutar en todos los nodos):

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

Ahora proceda a crear al usuario sstuser:

mysql> create user sstuser@'%' identified by 'pandora';> grant all on *.* to sstuser@'%';
> flush privileges;
> quit

Detenga el servicio mysql en todos los nodos tras finalizar esta configuración:

# systemctl stop mysqld

Una vez haya detenido todos los servidores, debe iniciar uno de ellos en modo bootstrap, para que actúe como servidor principal para realizar la replicación entre los otros dos nodos.

Para ello hay que añadir una configuración específica en el nodo que elija como principal, en este caso el nodo pandora001.

Modifique el fichero /etc/my.cnf del nodo pandora001 añadiendo correctamente los parámetros indicados entre las dos líneas # Modified for PFMS:

[mysqld]
# Modified for PFMS\
server-id=1
# Modified for PFMS/

datadir=/var/lib/mysql
character-set-server=utf8
skip-character-set-client-handshake

# Add configuration for Percona XtraDB Cluster.
# Cache size depends on the server resources. Recommended 1G - 10 GB.
# Modified for PFMS\
wsrep_provider_options="gcache.size=10G; gcache.page_size=10G"
wsrep_provider=/usr/lib64/galera3/libgalera_smm.so

wsrep_cluster_name=pandora-cluster
wsrep_cluster_address=gcomm://
wsrep_node_name=pandora001
wsrep_node_address=192.168.80.111

wsrep_sst_method=xtrabackup-v2
wsrep_sst_auth=sstuser:pandora
# Modified for PFMS/

pxc_strict_mode=PERMISSIVE

# Mysql optimizations for Pandora FMS node with 4G RAM
max_allowed_packet = 64M
innodb_buffer_pool_size = 1G
innodb_lock_wait_timeout = 90
innodb_file_per_table innodb_flush_log_at_trx_commit = 0
innodb_flush_method = O_DIRECT
innodb_log_file_size = 64M
innodb_log_buffer_size = 16M
innodb_io_capacity = 100
innodb_autoinc_lock_mode=2
thread_cache_size = 8192
thread_stack = 256K
max_connections = 8192
wait_timeout = 900
key_buffer_size=4M
read_buffer_size=128K
read_rnd_buffer_size=128K
sort_buffer_size=128K
join_buffer_size=4M
query_cache_type = 0
query_cache_size = 0
sql_mode=""
binlog_format=ROW
expire_logs_days=1

Inicie con esta configuración el servicio de mysql en el nodo pandora001, en modo bootstrap:

# systemctl start mysql@bootstrap

En los nodos pandora002 y pandora003 modifique el fichero /etc/my.cnf indicando los siguientes parámetros indicados entre las dos líneas # Modified for PFMS:

Nodo pandora002:

[mysqld]
server-id=2
datadir=/var/lib/mysql
character-set-server=utf8
skip-character-set-client-handshake
# add configuration for Percona XtraDB Cluster.
# Cache size depends on the server resources. Recommended 1G - 10 GB.
# Modified for PFMS\
wsrep_provider_options="gcache.size=10G; gcache.page_size=10G"
wsrep_provider=/usr/lib64/galera3/libgalera_smm.so

wsrep_cluster_name=pandora-cluster
wsrep_cluster_address=gcomm:pandora001,pandora003

wsrep_node_name=pandora002
wsrep_node_address=192.168.80.112

wsrep_sst_method=xtrabackup-v2
wsrep_sst_auth=sstuser:pandora

pxc_strict_mode=PERMISSIVE
# Modified for PFMS/

# Mysql optimizations for Pandora FMS
max_allowed_packet = 64M
innodb_buffer_pool_size = 1G
innodb_lock_wait_timeout = 90
innodb_file_per_table
innodb_flush_log_at_trx_commit = 0
innodb_flush_method = O_DIRECT
innodb_log_file_size = 64M
innodb_log_buffer_size = 16M
innodb_io_capacity = 100
innodb_autoinc_lock_mode=2
thread_cache_size = 8192
thread_stack    = 256K
max_connections = 8192
wait_timeout = 900
key_buffer_size=4M
read_buffer_size=128K
read_rnd_buffer_size=128K
sort_buffer_size=128K
join_buffer_size=4M
query_cache_type = 0
query_cache_size = 0
sql_mode=""
binlog_format=ROW
expire_logs_days=1

Nodo pandora003:

[mysqld]
server-id=3
datadir=/var/lib/mysql
character-set-server=utf8
skip-character-set-client-handshake
# add configuration for Percona XtraDB Cluster.
# Cache size depends on the server resources. Recommended 1G - 10 GB.
# Modified for PFMS\
wsrep_provider_options="gcache.size=10G; gcache.page_size=10G"
wsrep_provider=/usr/lib64/galera3/libgalera_smm.so

wsrep_cluster_name=pandora-cluster
wsrep_cluster_address=gcomm:pandora001,pandora003

wsrep_node_name=pandora002
wsrep_node_address=192.168.80.112

wsrep_sst_method=xtrabackup-v2
wsrep_sst_auth=sstuser:pandora

pxc_strict_mode=PERMISSIVE
# Modified for PFMS/

# Mysql optimizations for Pandora FMS
max_allowed_packet = 64M
innodb_buffer_pool_size = 1G
innodb_lock_wait_timeout = 90
innodb_file_per_table
innodb_flush_log_at_trx_commit = 0
innodb_flush_method = O_DIRECT
innodb_log_file_size = 64M
innodb_log_buffer_size = 16M
innodb_io_capacity = 100
innodb_autoinc_lock_mode=2
thread_cache_size = 8192
thread_stack    = 256K
max_connections = 8192
wait_timeout = 900
key_buffer_size=4M
read_buffer_size=128K
read_rnd_buffer_size=128K
sort_buffer_size=128K
join_buffer_size=4M
query_cache_type = 0
query_cache_size = 0
sql_mode=""
binlog_format=ROW
expire_logs_days=1

Inicie en los nodos pandora002 y pandora003 el servicio mysqld para que iniciar la sincronía:

#systemctl start mysqld

En este punto puede realizar la instalación de la base de datos de Pandora FMS sobre el nodo 1 y observar cómo se replica correctamente entre los otros dos servidores.

Una vez comprobado el correcto funcionamiento de la replicación, detenga el nodo que ha iniciado en modo bootstrap (en este caso el nodo pandora001):

(NODO1) # systemctl stop mysql@bootstrap

Cambie dentro del fichero my.cnf del NODO 1 el parámetro wsrep_cluster_address para añadir los otros 2 nodos del clúster al mismo, ha de quedar de la siguiente forma:

wsrep_cluster_address=gcomm:pandora002,pandora003

Inicie de nuevo el servicio mysqld en el nodo pandora001, pero esta vez en modo normal, para que se sincronice con los otros 2 nodos ya activos.

systemctl start mysqld

Cambios al esquema de Pandora FMS para su correcto funcionamiento

Para evitar problemas con los deadlocks (bloqueos de registros) por las constantes escrituras y lecturas que se producen en paralelo es necesario modificar las siguientes tablas de Pandora FMS con las siguientes modificaciones:

alter table tagent_access add column `id_tagent_access` bigint(20) unsigned NOT NULL;
alter table tagent_access add primary key (id_tagent_access);
alter table tagent_access modify id_tagent_access bigint(20) auto_increment;
alter table tagente_datos add column `id_tagente_datos` bigint(20) unsigned NOT NULL;
alter table tagente_datos add primary key (id_tagente_datos);
alter table tagente_datos modify id_tagente_datos bigint(20) auto_increment;
alter table tagente_datos_inc add column `id_tagente_datos_inc` bigint(20) unsigned NOT NULL;
alter table tagente_datos_inc add primary key (id_tagente_datos_inc);
alter table tagente_datos_inc modify id_tagente_datos_inc bigint(20) auto_increment;
alter table tagente_datos_string add column `id_tagente_datos_string` bigint(20) unsigned NOT NULL;
alter table tagente_datos_string add primary key (id_tagente_datos_string);
alter table tagente_datos_string modify id_tagente_datos_string bigint(20) auto_increment;
alter table tagente_datos_inventory add column `id_tagente_datos_inventory` bigint(20) unsigned NOT NULL;
alter table tagente_datos_inventory add primary key (id_tagente_datos_inventory);
alter table tagente_datos_inventory modify id_tagente_datos_inventory bigint(20) auto_increment;
alter table torigen add primary key (`origen`);
alter table tusuario add primary key (`id_user`);

Para su corrrecto funcionamiento, deben aplicarse estos cambios con la base de datos sin datos, solo con el esquema.

Aplicar cambios en un entorno con datos previos

Ante este escenario, es necesario reconstruir las tablas donde se han añadido las modificaciones necesarias para evitar los deadlocks en el entorno. El proceso sería el siguiente:

1.- Hacer DUMP (exportar datos) de todas las tablas implicadas por separado, excluyendo los campos DROP y create TABLE:

#mysqldump -u root -p pandora tagent_access --skip-add-drop-table --complete-insert --no-create-info> tagent_access.sql
#mysqldump -u root -p pandora tagente_datos --skip-add-drop-table --complete-insert --no-create-info> tagente_datos.sql
#mysqldump -u root -p pandora tagente_datos_inc --skip-add-drop-table --complete-insert --no-create-info> tagente_datos_inc.sql
#mysqldump -u root -p pandora tagente_datos_string --skip-add-drop-table --complete-insert --no-create-info> tagente_datos_string.sql
#mysqldump -u root -p pandora tagente_datos_inventory --skip-add-drop-table --complete-insert --no-create-info> tagente_datos_inventory.sql

2.- Eliminar las tablas afectadas:

mysql>drop table tagent_access;
mysql>drop table tagente_datos;
mysql>drop table tagente_datos_inc;
mysql>drop table tagente_datos_string;
mysql>drop table tagente_datos_inventory;

3.- Crear de nuevo todas las tablas con todos los ALTER y con todas las nuevas columnas para que funcione el entorno sin problemas. Para crear las tablas de nuevo es necesario usar el create table del fichero /var/www/html/pandora_console/pandoradb.sql de las tablas tagent_access, tagente_datos_inc, tagente_datos_string, tagente_datos_inventory.

4.- Incorporar con source todos los datos DUMP creados en el paso 1.

#mysql -u root -p pandora
mysql> source tagent_access.sql:
mysql> source tagente_datos.sql:
mysql> source tagente_datos_inc;
mysql> source tagente_datos_string;
mysql> source tagente_datos_inventory;

Al finalizar el proceso, se habrán quedado todas las tablas con los id incrementales creados desde 0 en todas ellas.

Volver al índice de documentación de Pandora FMS

Tabla de Contenidos