Высокая степень доступности (HA)

Вернуться в оглавление Документации Pandora FMS

Pandora FMS - очень стабильное приложение (благодаря тестам и улучшениям, вносимым в каждую версию, а также исправлению некоторых ошибок, обнаруженных пользователями), тем не менее, в критических средах и/или при большой нагрузке может возникнуть необходимость распределить нагрузку на несколько машин и быть уверенным, что при отказе любого компонента Pandora FMS система не рухнет.

Pandora FMS была разработана по модульному принципу, и любой из ее модулей может работать независимо. Но он также предназначен для совместной работы с другими компонентами и способен принять на себя нагрузку от тех компонентов, которые упали.

Стандартно Pandora FMS может выглядеть так, как показано на рисунке ниже.

Очевидно, что агенты не являются избыточными. Если агент выходит из строя, нет смысла запускать другого, поскольку единственной причиной выхода агента из строя является невозможность получения данных из-за сбоя в работе какого-либо модуля, который не может быть устранен другим агентом, работающим параллельно, или из-за отсутствия связи или сбоя системы. Очевидным решением является резервирование критических систем независимо от того, работают ли в них агенты Pandora FMS или нет, и, таким образом, резервирование мониторинга этих систем.

Использование HA может обсуждаться в различных сценариях:

• Балансировка и HA серверов данных.
• Балансировка и HA сетевых серверов, WMI, plugin, web, prediction, recon и подобные.
• Балансировка и HA в базах данных.
• Балансировка и HA консоли Pandora FMS.

Наиболее важными компонентами Pandora FMS являются:

1. База данных
2. Сервер
3. Консоль

Каждый из компонентов может быть реплицирован для защиты системы мониторинга от любых проблем.

Чтобы определить количество узлов, необходимых для балансировки нагрузки, мы рассмотрим количество целей для мониторинга, а также объем, тип и частоту захвата метрик для сбора.

В зависимости от потребностей мониторинга, мы определим различные архитектуры.

Примечание: Испытания, проведенные для определения архитектур, были выполнены с использованием различного оборудования:

Intel(R) Core(TM) i5-8600K CPU @ 3.60GHz

Экземпляр t2.large от Amazon ¹⁾

В зависимости от потребностей:

1. Автономно (без высокой доступности) до 2500 агентов / 50000 модулей каждые 5 минут, однородные данные, без исторических данных

 Серверы: 1 (общий)

 Главный:
 ----------
 CPU: 6 cores
 RAM: 8 ГБ
 Диск: 100 ГБ

2. Автономно (без высокой доступности) до 2500 агентов / 50000 модулей каждые 5 минут, однородные данные, с историческими данными (1 год)

 Серверы: 2 (1 общий, 1 история)

 Главный:
 ----------
 CPU: 6 cores
 RAM: 8 ГБ
 Диск: 100 ГБ

 История:
 ----------
 CPU: 2 cores
 RAM: 4 ГБ
 Диск: 200 ГБ

3. Автономно (без высокой доступности) до 5000 агентов / 100000 модулей каждые 5 минут, однородные данные, с историческими данными (1 год)

 Серверы: 3 (1 сервер + консоль, 1 основная база данных, 1 история)

 Сервер + консоль:
 -------------------
 CPU: 6 cores
 RAM: 8 ГБ
 Диск: 40 ГБ

 Главная база данных:
 ------------------------
 CPU: 4 cores
 RAM: 8 ГБ
 Диск: 100 ГБ

 История:
 ----------
 CPU: 2 cores
 RAM: 4 ГБ
 Диск: 200 ГБ

1. Простая база данных HA, до 7500 агентов / 125000 модулей каждые 5 минут, однородные данные, с историческими данными (1 год).

 Серверы: 4 (1 сервер + консоль, 2 базы данных, 1 история)

 Сервер + консоль:
 -------------------
 CPU: 6 cores
 RAM: 8 ГБ
 Диск: 40 ГБ

 База данных узел 1:
 ---------------------
 CPU: 6 cores
 RAM: 8 ГБ
 Диск: 100 ГБ

 База данных узел 2:
 ---------------------
 CPU: 6 cores
 RAM: 8 ГБ
 Диск: 100 ГБ

 История:
 ----------
 CPU: 2 cores
 RAM: 4 ГБ
 Диск: 300 ГБ

2. База данных с полной HA (с кворумом), до 7500 агентов / 125000 модулей каждые 5 минут, однородные данные, с историческими данными (1 год).

 Серверы: 5 (1 сервер + консоль, 3 базы данных, 1 история)

 Сервер + консоль:
 -------------------
 CPU: 6 cores
 RAM: 8 ГБ
 Диск: 40 ГБ

 База данных узел 1:
 ---------------------
 CPU: 6 cores
 RAM: 8 ГБ
 Диск: 100 ГБ

 База данных узел 2:
 ---------------------
 CPU: 6 cores
 RAM: 8 ГБ
 Диск: 100 ГБ

 База данных узел 3:
 ---------------------
 CPU: 6 cores
 RAM: 8 ГБ
 Диск: 100 ГБ

 История:
 ----------
 CPU: 2 cores
 RAM: 4 ГБ
 Диск: 200 ГБ

3. База данных в простой HA и Pandora FMS в сбалансированной HA, до 7500 агентов / 125000 модулей каждые 5 минут, однородные данные, с историческими данными (1 год).

 Серверы: 5 (2 сервера + консоль, 2 базы данных, 1 история)

 Сервер + консоль:
 -------------------
 CPU: 6 cores
 RAM: 8 ГБ
 Диск: 40 ГБ

 Сервер + консоль:
 -------------------
 CPU: 6 cores
 RAM: 8 ГБ
 Диск: 40 ГБ

 База данных узел 1:
 ---------------------
 CPU: 6 cores
 RAM: 8 ГБ
 Диск: 100 ГБ

 База данных узел 2:
 ---------------------
 CPU: 6 cores
 RAM: 8 ГБ
 Диск: 100 ГБ

 История:
 ----------
 CPU: 2 cores
 RAM: 4 ГБ
 Диск: 200 ГБ

4. Базовая HA сбалансирована на сервере, основной и базовой базе данных, до 4000 агентов / 90000 модулей каждые 5 минут, однородные данные, с историческими данными (1 год).

 Серверы: 3 (2 общих, 1 история)

 Главный: (консоль + сервер + узел базы данных 1).
 ----------
 CPU: 8 cores
 RAM: 12 ГБ
 Диск: 100 ГБ

 Вторичный: (консоль + сервер + узел базы данных 2).
 ----------
 CPU: 8 cores
 RAM: 12 ГБ
 Диск: 100 ГБ

 История:
 ----------
 CPU: 2 cores
 RAM: 4 ГБ
 Диск: 200 ГБ

В этой схеме узлы базы данных Pandora FMS настроены на каждом из двух доступных серверов (основном и вторичном).

Примечание: Для больших сред мы определим каждую из ранее описанных схем конфигурации как вычислительные узлы.

Если вам нужно контролировать 30 000 агентов с 500 000 модулей, вы должны настроить столько узлов, сколько необходимо для выполнения этих требований. Следуя примеру:

Если мы выберем дизайн HA#1 (1 сервер+консоль, 2 узла базы данных в HA и база данных истории), нам придется настроить 30 000 / 7500 = 4 узла.

Для управления всей средой необходимо установить метаконсоль, откуда можно настроить всю инфраструктуру мониторинга.

Метаконсоль потребует:

 Серверы: 1 (общий)

 Главный:
 ----------
 CPU: 8 cores
 RAM: 12 ГБ
 Диск: 100 ГБ

Общее количество серверов с независимыми историческими базами данных: 17

Общее количество серверов с объединенными историческими базами данных: 13

Примечание> Чтобы объединить все исторические базы данных (4) в одной машине, вам придется изменить размер их функций, чтобы машина смогла принять на себя дополнительную нагрузку:

 Объединенная история:
 --------------------
 CPU: 8 cores
 RAM: 12 ГБ
 Диск: 1200 ГБ

Самый простой способ - использовать HA, реализованный в агентах (который позволяет связаться с альтернативным сервером, если основной сервер не отвечает). Однако, поскольку сервер данных обслуживает через порт 41121 и это стандартный TCP-порт, можно использовать любое коммерческое решение, позволяющее балансировать или кластеризовать обычный TCP-сервис.

Для сервера данных Pandora FMS необходимо установить две машины с настроенным сервером данных Pandora FMS (и разными именами хоста и сервера). На каждой из них нужно будет установить сервер Tentacle. Каждая машина будет иметь свой IP-адрес. Если мы собираемся использовать внешний балансировщик, он предоставит один IP-адрес, к которому агенты будут подключаться для отправки своих данных.

Если мы используем внешний балансировщик нагрузки, и один из серверов выходит из строя, механизм HA включает один из доступных активных серверов, и агенты Pandora FMS будут продолжать подключаться с тем же адресом, что и раньше, не замечая изменений, но в этом случае балансировщик нагрузки будет отправлять данные не на сервер, который вышел из строя, а на другой активный сервер. Нет необходимости менять что-либо в каждом сервере данных Pandora FMS, даже каждый сервер может сохранять свое собственное имя, полезное для того, чтобы знать, если какой-либо из них не работает, в при просмотре состояния сервера. Модули данных Pandora FMS могут обрабатываться любым сервером без необходимости предварительного распределения. Он разработан таким образом, что HA может быть реализован более удобным для пользователя способом..

В случае использования механизма HA агентов, будет наблюдаться небольшая задержка в отправке данных, так как при каждом выполнении агента, он будет пытаться соединиться с первичным сервером, и если тот не ответит, он сделает это со вторичным (если он был настроен таким образом). Это описано ниже как «Балансировка на программных агентах».

Если вы хотите использовать два сервера данных и оба должны обрабатывать удаленные политики, коллекции и конфигурации, вы должны совместно использовать ключевые каталоги чтобы все экземпляры сервера данных могли читать и записывать в эти каталоги. Консоли также должны иметь доступ к этим общим каталогам.

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

С помощью программных агентов можно выполнять балансировку серверов данных, поскольку можно настроить основной сервер данных и резервный сервер. В файле конфигурации агента pandora_agent.conf должна быть настроена и не комментированной следующая часть файла конфигурации агента:

 # 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

Доступны следующие опции (для получения дополнительной информации см. главу о конфигурации агента).

• secondary_mode: Режим, в котором должен находиться вторичный сервер. Он может иметь два значения:
  • on_error: Он будет отправлять данные на вторичный сервер только в том случае, если не может отправить их на первичный сервер.
  • always: Он всегда отправляет данные на вторичный сервер, независимо от того, может ли он связаться с первичным сервером или нет.
• secondary_server_ip: IP-адрес вторичного сервера.
• secondary_server_path: Путь, по которому XML копируется на вторичный сервер, обычно /var/spool/pandora/data_in
• secondary_server_port: Порт, через который XML будет скопирован на вторичный сервер, в tentacle 41121, в ssh 22 и в ftp 21.
• secondary_transfer_mode: Режим передачи, который будет использоваться для копирования XML на вторичный сервер, Tentacle, ssh, ftp, …
• secondary_server_pwd: Параметр пароля для передачи данных по FTP
• secondary_server_ssl: Установите значение yes или no в зависимости от того, хотите ли вы использовать ssl для передачи данных через Tentacle.
• secondary_server_opts: Другие параметры, необходимые для трансфера, будут помещены в это поле.

Вам необходимо установить несколько сетевых серверов. WMI, Plugin, Web или prediction, на нескольких машинах в сети (все с одинаковой видимостью в отношении систем, подлежащих мониторингу) и все в одном сегменте (чтобы данные о сетевой задержке были согласованными).

Серверы могут быть помечены как основные. Эти серверы будут автоматически собирать данные со всех модулей, назначенных на сервер, который помечен как «неработающий». В самих серверах Pandora FMS реализован механизм, позволяющий обнаружить, что один из них вышел из строя, путем проверки даты последнего контакта. (server threshold x 2). Достаточно, чтобы был активен только один сервер Pandora FMS, чтобы он смог обнаружить падение остальных. Если все серверы Pandora FMS не работают, нет возможности обнаружить или реализовать HA.

Очевидным способом реализации HA и балансировки нагрузки в двухузловой системе является назначение 50% модулей на каждый сервер и маркировка обоих серверов как ведущих. В случае более чем двух главных серверов и третьего упавшего сервера с большим количеством модулей, ожидающих выполнения, первый из главных серверов, выполняющий модуль, «самоназначается» модулем упавшего сервера. В случае восстановления одного из вышедших из строя серверов, модули, которые были назначены основному серверу, автоматически переназначаются.

Балансировка нагрузки между различными серверами осуществляется в административной части агента в меню «setup».

В поле «server» есть комбинированное поле, где вы выбираете сервер, который будет выполнять проверки.

Сервер Pandora FMS может работать в двух различных режимах:

• Главный режим.
• Не главный режим.

Если сервер выходит из строя, его модули будут выполняться главным сервером, так что данные не будут потеряны.

В любой момент времени может быть только один главный сервер, который выбирается среди серверов, имеющих параметр конфигурации master в /etc/pandora/pandora_server.conf со значением больше 0:

master [1..7]

Если текущий главный сервер выходит из строя, выбирается новый главный сервер. Если кандидатов несколько, выбирается кандидат с наибольшим значением master.

Например, если у вас есть три сервера Pandora FMS в статусе master, установленным на 1, один главный сервер будет выбран случайным образом, а два других будут работать во второстепенном режиме. Если главный сервер выходит из строя, новый главный сервер выбирается случайным образом.

В pandora_server.conf были введены следующие параметры:

• ha_file: Адрес временного двоичного файла HA.
• ha_pid_file: Текущий процесс HA.
• pandora_service_cmd: Контроль состояния службы Pandora FMS.

Только нужно установить другую консоль указывающую на базу данных. Любая из консолей может использоваться одновременно из разных мест разными пользователями. Мы сможем использовать веб-балансировщик для консолей, если нам понадобится горизонтальный рост для балансировки нагрузки на консоли. Управление системой сессий осуществляется с помощью файлов cookie, которые хранятся в браузере.

В случае использования удаленной конфигурации и для управления ею со всех консолей, оба сервера данных и консоли должны совместно использовать каталог входных данных (по умолчанию: /var/spool/pandora/data_in) для удаленной конфигурации агентов, коллекций и других каталогов.

Важно предоставлять общий доступ только к подкаталогам внутри data_in, а не к самим data_in, так как это негативно скажется на производительности сервера.

При обновлении консоли Pandora FMS в среде высокой доступности важно учитывать следующие соображения при обновлении через OUM посредством Update Manager → Update Manager offline.

Пользователи версии Enterprise могут загрузить пакет OUM с сайта поддержки Pandora FMS.

В сбалансированной среде с общей базой данных при обновлении первой консоли к базе данных применяются соответствующие изменения. Это приводит к тому, что при обновлении второй консоли Pandora FMS выдает ошибку при поиске информации, уже вставленной в базу данных. Однако обновление консоли будет осуществляться тем же способом.

Pandora FMS основана на базе данных MySQL для конфигурирования и хранения данных. Сбой базы данных может на мгновение парализовать работу инструмента мониторинга. Кластер базы данных высокой доступности Pandora FMS позволяет нам легко развернуть надежную и отказоустойчивую архитектуру.

Управление ресурсами кластера осуществляется с помощью Pacemaker, усовершенствованного и масштабируемого менеджера ресурсов кластера высокой доступности. Corosync предоставляет модель связи закрытой группы процессов для создания реплицированных машин состояний. Percona была выбрана в качестве РСУБД по умолчанию благодаря своей масштабируемости, доступности, безопасности и функциям резервного копирования.

Активная/пассивнаярепликация осуществляется с одного ведущего узла (с разрешением на запись) на любое количество ведомых узлов (только для чтения). Виртуальный IP-адрес всегда ведет к текущему главному узлу. Если ведущий узел выходит из строя, один из ведомых узлов становится ведущим, а виртуальный IP-адрес обновляется соответствующим образом.

Инструмент базы данных Pandora FMS HA, pandora_ha, осуществляет мониторинг кластера и следит за тем, чтобы сервер Pandora FMS непрерывно работал, перезапуская его при необходимости. pandora_ha в свою очередь контролируется systemd.

В этом примере будет настроен cluster из двух узлов, с hosts: node1 и node2.

Измените имена hosts, пароли и т.д. по мере необходимости в соответствии с развертываемой средой.

Команды, которые должны быть выполнены на любом узле, будут иметь следующий синтаксис (пример для node1):

node1#
<command>
<command>
<command>

Команды, которые должны быть выполнены на всех узлах, будут предваряться словом all:

all#
<command>
<command>
<command>

Существует также дополнительный host под названием pandorafms, на котором будет установлен Pandora FMS. Когда ссылаются на all, это относится только к узлам базы данных, дополнительный узел Pandora FMS всегда будет упоминаться как pandorafms и не является частью all.

RHEL версии 8 или Rocky Linux версии 8 должны быть установлены на всех hosts, и должны иметь возможность разрешать hostnames других hosts.

На каждом host должен быть установлен и запущен сервер OpenSSH. Подавление предупреждения, которое отображает OpenSSH:

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

Сгенерируйте новые ключи аутентификации SSH для каждого host и скопируйте открытый ключ для каждого из hosts.

all#
printf "\n\n\n" | ssh-keygen -t rsa -P ''
ssh-copy-id -p22 root@node1
ssh-copy-id -p22 root@node2

pandorafms#
printf "\n\n\n" | ssh-keygen -t rsa -P ''
ssh-copy-id -p22 root@node1
ssh-copy-id -p22 root@node2

На узле Pandora FMS скопируйте пару ключей в следующие каталоги httpd , ssh. Консоль Pandora FMS (httpd) должна получить статус cluster:

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

Вы должны заменить 22 на номер порта, который вы используете:

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

Вы должны протестировать аутентификацию без пароля от каждого узла к другим:

all#
ssh node1
ssh node2

pandorafms#
ssh node1
ssh node2

Установите необходимый пакет:

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

dnf module disable -y mysql

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

Для получения дополнительной информации о процессе установки Percona вы можете обратиться к официальной документации по продукту:

После установки пакетов убедитесь, что служба Percona отключена, так как ею будет управлять cluster:

all#
systemctl disable mysqld

Затем запустите сервер Percona:

all#
systemctl start mysqld

Будет сгенерирован новый временный пароль для подключения к /var/log/mysqld.log. Подключитесь к серверу Percona и измените пароль для root:

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

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

При выполнении настройки MySQL это можно сделать с помощью следующего автогенератора, который уже включен в установочный пакет сервера Pandora FMS Enterprise по умолчанию.

После установки server, вы найдете построитель конфигурации для репликации базы данных по пути:

/usr/share/pandora_server/util/myconfig_ha_gen.sh

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

В текущем случае, когда базы данных не находятся на том же сервере, что и приложение, необходимо будет скопировать script в стандартных средах некоторые необязательные параметры для пользовательских сред.

pandorafms#
scp /usr/share/pandora_server/util/myconfig_ha_gen.sh root@node1:/root/
scp /usr/share/pandora_server/util/myconfig_ha_gen.sh root@node2:/root/

Необходимо будет только передать параметр serverid (обязательный) в стандартных средах и некоторые необязательные параметры для пользовательских сред.

Если заданный по умолчанию или заданный пользователь не подключается к базе данных, сценарий завершится с ошибкой подключения.

У вас также есть возможность передать имя базы данных, пользователя и пароль в качестве аргументов. В противном случае будут использоваться настройки по умолчанию.

В этом случае он выполнит сценарий на обоих узлах, передав server id только в том случае, если он имеет учетные данные по умолчанию, в противном случае он должен определить необходимые параметры.

node1#
/root/myconfig_ha_gen.sh -i 1

node2#
/root/myconfig_ha_gen.sh -i 2

Файл конфигурации Percona будет записан в /etc/my.cnf , где будут определены идентификатор сервера и рекомендуемая конфигурация для репликации базы данных. Вы должны перезапустить службу mysqld, чтобы убедиться, что конфигурация применена правильно.

all#
systemctl restart mysqld

Вы можете либо выполнить полностью новую установку, либо перенести имеющиеся данные из существующего экземпляра.

Установите Pandora FMS на вновь созданную базу данных. Остановите сервер Pandora FMS:

pandorafms#
/etc/init.d/pandora_server stop

Начиная с версии NG 754 у вас появились дополнительные возможности по ручному запуску и остановке сред высокой доступности (HA).

Остановите сервер Pandora FMS:

pandorafms#
/etc/init.d/pandora_server stop

Создайте резервную копию базы данных Pandora FMS и перенесите ее на узел 1:

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

Теперь загрузите информацию в новую базу данных на узле (если вы не используете учетные данные и имя базы данных по умолчанию, измените их в следующей команде):

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

Предоставьте необходимые привилегии для репликации, чтобы она работала на всех базах данных:

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

Остановите базу данных node2:

node2#
systemctl stop mysqld

Сделайте резервную копию базы данных первого узла (node1) и запишите имя и позицию главного log файла (в данном примере mysql-bin.000001 и 785):

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

Загрузите базу данных на второй узел (node2) и настройте ее на репликацию с первого узла (необходимо установить MASTER_LOG_FILE и MASTER_LOG_POS на значения из предыдущего шага):

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

systemctl start mysqld

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

Вы получите результат, похожий на:

Если все в порядке, выйдите из интерфейса базы данных:

#node2
mysql> QUIT

Установите необходимые пакеты: Для Rocky Linux™ достаточно выполнить следующую команду.

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

В случае RedHat перед установкой необходимо включить репозиторий rhel-8-for-x86_64-highavailability-rpms из subscription manager.

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

Теперь определите конфигурационный файл и включите службы corosync, pscd и chrony (замена старого ntpd).

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

systemctl enable chronyd --now

systemctl enable pcsd --now

systemctl enable corosync --now

Остановите сервер Percona:

all#
systemctl stop mysqld

Определите пароль пользователя hacluster:

all#
echo hapass | passwd hacluster --stdin

Создайте и запустите cluster, эти шаги будут необходимы только для того, чтобы сделать это в node1:

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

pcs cluster setup pandorafms node1 node2 --force

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

pcs property set stonith-enabled=false

pcs property set no-quorum-policy=ignore

Проверьте состояние cluster:

node1#
pcs status

Вы увидите результат, аналогичный следующему:

Кардиостимулятор можно загрузить вручную из библиотеки PFMS.

Если у вас есть доступ в Интернет, вы можете установить его, запустив:

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

Настройте ресурсы cluster.

Замените <VIRT_IP> на предпочитаемый виртуальный IP-адрес:

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

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

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

pcs constraint colocation add master pandoradb-clone with pandoraip

pcs constraint order promote pandoradb-clone then start pandoraip

sleep 5 ; pcs resource cleanup

Проверка состояния cluster:

node1#
pcs status

Вы увидите результат, аналогичный следующему:

Он будет проводиться аналогично предыдущему.

Учетные данные пользователя должны быть скопированы, как уже объяснялось ранее, и необходимо выполнить следующие действия:

# 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

Мы создадим двухузловой кластер с хостами node1 и node2. Мы меняем имена хостов, пароли и т.д. в зависимости от того, что нам нужно для соответствия нашей среде.

Командам, которые должны быть выполнены на узле, предшествует имя хоста этого узла. Например:

node1# <command>

Перед командами, которые должны быть выполнены на всех узлах, должно стоять слово all. Например:

all# <command>

Существует дополнительный хост, называемый pandorafms, на котором находится или установлен Pandora FMS.

CentOS версии 7 должна быть установлена на всех хостах и должна иметь возможность разрешать имена других хостов.

 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.

На каждом хосте должен быть установлен и запущен сервер Open SSH. Уберите баннер с надписью 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

Мы генерируем новые ключи аутентификации SSH для каждого узла и копируем открытый ключ для каждого узла:

node1# echo -e "\n\n\n" | ssh-keygen -t rsa
node1# ssh-copy-id -p22 root@node2
node1# ssh node2

node2# echo -e "\n\n\n" | ssh-keygen -t rsa
node2# ssh-copy-id -p22 root@node1
node2# ssh node1

pandorafms# echo -e "\n\n\n" | ssh-keygen -t rsa
pandorafms# ssh-copy-id -p22 root@node1
pandorafms# ssh-copy-id -p22 root@node2
pandorafms# ssh node1
pandorafms# ssh node2

На узле Pandora FMS скопируйте пару ключей в /usr/share/httpd/.ssh /. Консоль Pandora FMS должна восстановить состояние кластера:

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

Следующие шаги необходимы только в том случае, если узлы используют SSH на нестандартном порту. Заменим 22 на правильный номер порта:

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

Установите необходимый пакет:

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

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

Для получения дополнительной информации о процессе установки Percona, пожалуйста, обратитесь к официальной документации продукта: https://www.percona.com/doc/percona-server/5.7/installation/yum_repo.html

После установки пакетов мы убеждаемся, что служба Percona деактивирована, поскольку она управляется кластером:

all# systemctl disable mysqld

Далее мы запускаем сервер Percona:

all# systemctl start mysqld

Будет сгенерирован новый временный пароль, подключенный к /var/log/mysqld.log. Мы подключаемся к серверу Percona и меняем пароль 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

Переустановите с помощью опции ha.

pandorafms# ./pandora_server_installer --install --ha

После установки сервера с включенными инструментами HA вы найдете генератор конфигурации для репликации базы данных по пути: /usr/share/pandora_server/util/myconfig_ha_gen.sh.

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

В текущем случае, когда базы данных не находятся на том же сервере, что и приложение, необходимо скопировать сценарий на узлы для локального выполнения.

pandorafms# scp /usr/share/pandora_server/util/myconfig_ha_gen.sh root@node1:/root/
pandorafms# scp /usr/share/pandora_server/util/myconfig_ha_gen.sh root@node2:/root/

Как мы видим в примере, необходимо передать только параметр serverid (обязательный) в стандартных средах и некоторые необязательные параметры для пользовательских сред.

Если пользователь по умолчанию или определенный пользователь не подключится к базе данных, сценарий завершится с ошибкой подключения.

Также можно передать базу данных, пользователя и пароль в качестве аргументов. В противном случае будут использоваться настройки по умолчанию.

Для этого случая мы запустим скрипт на обоих узлах, передав только id сервера, если у нас есть учетные данные по умолчанию, в противном случае определим необходимые параметры.

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

ВАЖНО: Каждый узел должен иметь уникальный идентификатор.

Конфигурационный файл Percona записывается в /etc/my.cnf, где определяется идентификатор сервера и рекомендуемая конфигурация для репликации базы данных.

Перезапуск службы mysqld, чтобы убедиться, что конфигурация была применена правильно.

all# systemctl restart mysqld

Мы устанавливаем Pandora FMS во вновь созданную базу данных. Для получения дополнительной информации:

https://wiki.pandorafms.com/es:documentation:02_installation:01_installing

Остановите сервер Pandora FMS:

pandorafms# /etc/init.d/pandora_server stop

Остановите сервер Pandora FMS:

pandorafms# /etc/init.d/pandora_server stop

Мы создаем резервную копию базы данных Pandora FMS:

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

Мы загружаем ее в новую базу данных:

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

Мы предоставляем необходимые привилегии для репликации, чтобы она работала на всех базах данных:

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

Мы создаем резервную копию базы данных первого узла и записываем имя и позицию главного файла журнала (в примере mysql-bin.000001 и 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

Мы загружаем базу данных на второй узел и настраиваем ее на репликацию с первого узла (мы устанавливаем MASTER_LOG_FILE и MASTER_LOG_POS в значения предыдущего шага):

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

Нужно установить необходимые пакеты:

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

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

 all# systemctl start ntpd
 all# systemctl start corosync
 all# systemctl start pcsd

Мы останавливаем сервер Percona:

node1# systemctl stop mysqld

node2# systemctl stop mysqld

Создаем и запускаем кластер:

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

Мы проверяем состояние кластера:

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

вы можете загрузить его вручную с нашего сайта librería PFMS.

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

Настроим ресурсы кластера. Заменяем <VIRT_IP> на предпочитаемый виртуальный IP-адрес:

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

Мы проверяем состояние кластера:

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

Она будет проводиться аналогично предыдущей. Вы должны скопировать учетные данные пользователя, о чем говорилось ранее, и выполнить следующие шаги:

# All nodes:

 useradd <user>
 passwd <user>
 usermod -a -G haclient <user>

# 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 <user> <rol>

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

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

Убедитесь, что php-pecl-ssh2 установлен в соответствии с установленной ОС и версией:

RHEL 8

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

Rocky Linux 8

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

CentOS 7

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

В /etc/pandora/pandora_server.conf есть два параметра, которые управляют поведением инструмента HA базы данных Pandora FMS. Они могут быть изменены в соответствии с нашими потребностями:

# 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

Мы направляем Pandora FMS на главный виртуальный IP-адрес (заменяя <IP> на виртуальный IP-адрес):

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

Запускаем сессию в консоли Pandora FMS и переходим в Servers → Manage database HA:

Нажмите Add new node и создайте запись для первого узла:

Затем нажмите Create slave и добавьте новую запись во второй узел. Это должно выглядеть примерно так:

Сценарий.

Оба сервера являются основными, или, в режиме просмотра консоли HA, оба выглядят основными, но виртуальный IP находится только на одном узле (том, который фактически выступает в качестве основного).

В этот момент, если параметр token splitbrain_autofix установлен в 1, начнется процесс восстановления узла в splitbrain.

Для правильной работы этой функциональности необходимо правильно настроить следующие компоненты:

• Ключи корневого пользователя SSH, общие для сервера pandora_ha master и всех серверов баз данных.
• Пользователь Replicator, настроенный в настройке с правами от сервера, на котором размещен сервер pandora_ha master.

• Свободное место для резервного копирования базы данных на обоих серверах, где размещены 2 базы данных (первичный и вторичный Master/Slave).

В случае, если каталог данных и путь ( datadir, path),на котором будет создан раздел, находятся в одном разделе, необходимо, чтобы свободное пространство составляло не менее 50%.

Если все вышеперечисленные пункты настроены правильно, процесс восстановления происходит следующим образом:

1. Удалите предыдущие резервные копии.
2. Создайте резервную копию datadir вторичного узла.
3. Резервное копирование основного узла.
4. Отправляет резервную копию основного узла на вторичный узел (Master → Slave).
5. Запускает ресурс «вторичного» узла с соответствующими параметрами ресинхронизации на момент резервного копирования.
6. Проверяет, что ресурс активен и корректен. Для этого он должен использовать конфигурацию, указанную в параметрах ha_max_resync_wait_retries и ha_resync_sleep.

В случае сбоя в любой точке процесса, он должен повторить процесс столько раз, сколько указано параметром ha_max_splitbrain_retries.

После завершения процесса в представлении событий появится событие, указывающее на успешное завершение процесса.

Если среда по-прежнему не восстанавливается автоматически, то вторичный узел переходит в режим ожидания, а в представлении событий появляется событие, указывающее, что восстановление должно быть выполнено вручную.

Уберите баннер с надписью Open SSH:

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

Создадим новые ключи аутентификации SSH для нового узла и копируем открытый ключ для каждого узла:

 node1# ssh-copy-id -p22 root@node3
 node1# ssh node3

 node2# ssh-copy-id -p22 root@node3
 node2# ssh node3

 pandorafms# ssh-copy-id -p22 root@node3
 pandorafms# ssh node3

 node3# echo -e "\n\n\n" | ssh-keygen -t rsa
 node3# ssh-copy-id -p22 root@node1
 node3# ssh-copy-id -p22 root@node2
 node3# ssh node1
 node3# ssh node2

В узле Pandora FMS скопируйте файл «known_hosts» для пользователя apache:

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

Следующие шаги необходимы только в том случае, если узлы используют SSH на нестандартном порту. Замените 22 на правильный номер порта:

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

Нужно установить необходимые пакеты:

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

Мы убедимся, что служба Percona деактивирована, поскольку она управляется кластером:

 node3# systemctl stop mysqld
 node3# systemctl disable mysqld

Мы настраиваем Percona, заменяя <ID> на номер, который должен быть уникальным для каждого узла кластера:

После установки server вы найдете в пути генератор конфигурации для репликации базы данных:

/usr/share/pandora_server/util/myconfig_ha_gen.sh

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

В текущем случае, когда базы данных находятся не на том же сервере, что и приложение, необходимо скопировать script на узлы для локального выполнения.

pandorafms#
scp /usr/share/pandora_server/util/myconfig_ha_gen.sh root@node3:/root/

Необходимо будет только передать параметр serverid (обязательный) в стандартных средах некоторые необязательные параметры для пользовательских сред.

Если заданный по умолчанию или заданный пользователь не подключается к базе данных, сценарий завершится с ошибкой подключения.

У вас также есть возможность передать имя базы данных, пользователя и пароль в качестве аргументов. В противном случае будут использоваться настройки по умолчанию.

В этом случае он выполнит сценарий на обоих узлах, передав server id только в том случае, если он имеет учетные данные по умолчанию, в противном случае он должен определить необходимые параметры.

node3#
/root/myconfig_ha_gen.sh -i 3

Запустим сервер Percona:

node3# systemctl start mysqld

Будет сгенерирован новый временный пароль, подключенный к /var/log/mysqld.log. Мы подключаемся к серверу Percona и меняем пароль root:

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

Мы делаем резервную копию базы данных главного узла (в данном примере - node1) и записываем имя и позицию главного файла журнала (в примере - mysql-bin.000001 и 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

Загрузим базу данных в новый узел, который назовем узел3, и настроим его на репликацию с узла1 (мы установим MASTER_LOG_FILE и MASTER_LOG_POS на значения из предыдущего шага):

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

Мы устанавливаем необходимые пакеты для кластера:

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

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

 node3# systemctl start ntpd

Мы добавляем новый узел в кластер:

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

 node1# pcs cluster auth -u hacluster -p hapass --force node3
 node1# pcs cluster node add --enable --start node3

Установим clone-max на количество узлов в нашем кластере (3 в данном примере):

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"

Мы проверяем состояние узла:

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

Регистрируем узел кластера в консоли Pandora из меню «Servers → Manage database HA».

В качестве примера мы будем использовать node2. Мы переводим node2 в режим ожидания:

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

Мы создаем резервную копию каталога данных в 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

Создаем резервную копию базы данных главного узла (в данном примере node1) и обновляем имя главного узла, а также имя и положение главного файла журнала в кластере (в данном примере node1, mysql-bin.000001 и 785):

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

Мы загружаем базу данных сломанного узла:

 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

Мы деактивируем режим ожидания узла2:

 node2# pcs node unstandby node2
 node2# pcs resource cleanup --node 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: 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

Мы проверяем состояние репликации базы данных:

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

Служба не будет затронута до тех пор, пока главный узел работает. Если главный узел падает, вторичный узел автоматически становится главным. Смотрите: Восстановление сломанного узла.

Вернуться в оглавление Документации Pandora FMS