====== Высокая степень доступности (HA) ====== {{indexmenu_n>6}} [[:ru:documentation:start|Вернуться в оглавление Документации Pandora FMS]] ===== Введение ===== Pandora FMS - очень стабильное приложение (благодаря тестам и улучшениям, вносимым в каждую версию, а также исправлению некоторых ошибок, обнаруженных пользователями), тем не менее, в критических средах и/или при большой нагрузке может возникнуть необходимость распределить нагрузку на несколько машин и быть уверенным, что при отказе любого компонента Pandora FMS система не рухнет. Pandora FMS была разработана по модульному принципу, и любой из ее модулей может работать независимо. Но он также предназначен для совместной работы с другими компонентами и способен принять на себя нагрузку от тех компонентов, которые упали. Стандартно Pandora FMS может выглядеть так, как показано на рисунке ниже. {{ :wiki:ha1.png }} Очевидно, что агенты не являются избыточными. Если агент выходит из строя, нет смысла запускать другого, поскольку единственной причиной выхода агента из строя является невозможность получения данных из-за сбоя в работе какого-либо модуля, который не может быть устранен другим агентом, работающим параллельно, или из-за отсутствия связи или сбоя системы. Очевидным решением является резервирование критических систем независимо от того, работают ли в них агенты Pandora FMS или нет, и, таким образом, резервирование мониторинга этих систем. Использование HA может обсуждаться в различных сценариях: * Балансировка и HA серверов данных. * Балансировка и HA сетевых серверов, WMI, plugin, web, prediction, recon и подобные. * Балансировка и HA в базах данных. * Балансировка и HA консоли Pandora FMS. ===== Архитектурное проектирование HA и определение размеров ===== Наиболее важными компонентами Pandora FMS являются: - База данных - Сервер - Консоль Каждый из компонентов может быть реплицирован для защиты системы мониторинга от любых проблем. Чтобы определить количество узлов, необходимых для балансировки нагрузки, мы рассмотрим количество целей для мониторинга, а также объем, тип и частоту захвата метрик для сбора. В зависимости от потребностей мониторинга, мы определим различные архитектуры. **Примечание:** Испытания, проведенные для определения архитектур, были выполнены с использованием различного оборудования: Intel(R) Core(TM) i5-8600K CPU @ 3.60GHz Экземпляр //t2.large// от Amazon (([[https://aws.amazon.com/ru/ec2/instance-types/t2/?nc1=h_ls|https://aws.amazon.com/ru/ec2/instance-types/t2/?nc1=h_ls]])) ==== Определение размеров ==== В зависимости от потребностей: 1. Автономно (без высокой доступности) до 2500 агентов / 50000 модулей каждые 5 минут, однородные данные, без исторических данных Серверы: 1 (общий) Главный: ---------- CPU: 6 cores RAM: 8 ГБ Диск: 100 ГБ {{ :wiki:dim_std1.png }} 2. Автономно (без высокой доступности) до 2500 агентов / 50000 модулей каждые 5 минут, однородные данные, с историческими данными (1 год) Серверы: 2 (1 общий, 1 история) Главный: ---------- CPU: 6 cores RAM: 8 ГБ Диск: 100 ГБ История: ---------- CPU: 2 cores RAM: 4 ГБ Диск: 200 ГБ {{ :wiki:dim_std2.png }} 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 ГБ {{ :wiki:dim_std3.png }} ==== Создание архитектуры HA ==== 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 ГБ {{ :wiki:dim_ha1.png }} 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 ГБ {{ :wiki:dim_ha2.png }} 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 ГБ {{ :wiki:dim_ha3.png }} 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 настроены на каждом из двух доступных серверов (основном и вторичном). {{ :wiki:dim_ha4.png }} **Примечание:** Для больших сред мы определим каждую из ранее описанных схем конфигурации как //вычислительные узлы//. ==== Пример ==== Если вам нужно контролировать 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 агентов, будет наблюдаться небольшая задержка в отправке данных, так как при каждом выполнении агента, он будет пытаться соединиться с первичным сервером, и если тот не ответит, он сделает это со вторичным (если он был настроен таким образом). Это описано ниже как "Балансировка на программных агентах". Если вы хотите использовать два сервера данных и оба должны обрабатывать удаленные политики, коллекции и конфигурации, вы должны [[:en:documentation:07_technical_annexes:10_share_var_spool_directory_between_several_pandora_servers|совместно использовать ключевые каталоги]] чтобы все экземпляры сервера данных могли читать и записывать в эти каталоги. Консоли также должны иметь доступ к этим общим каталогам. * /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 {{ :wiki:ha2.png }} ===== Высокая доступность программных агентов ===== С помощью программных агентов можно выполнять балансировку серверов данных, поскольку можно настроить основной сервер данных и резервный сервер. В файле конфигурации агента //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, плагинов, web, prediction и т.п. ===== Вам необходимо установить несколько сетевых серверов. WMI, Plugin, Web или prediction, на нескольких машинах в сети (все с одинаковой видимостью в отношении систем, подлежащих мониторингу) и все в одном сегменте (чтобы данные о сетевой задержке были согласованными). Серверы могут быть помечены как основные. Эти серверы будут автоматически собирать данные со всех модулей, назначенных на сервер, который помечен как "неработающий". В самих серверах Pandora FMS реализован механизм, позволяющий обнаружить, что один из них вышел из строя, путем проверки даты последнего контакта. (server threshold x 2). Достаточно, чтобы был активен только один сервер Pandora FMS, чтобы он смог обнаружить падение остальных. Если все серверы Pandora FMS не работают, нет возможности обнаружить или реализовать HA. Очевидным способом реализации HA и балансировки нагрузки в двухузловой системе является назначение 50% модулей на каждый сервер и маркировка обоих серверов как ведущих. В случае более чем двух главных серверов и третьего упавшего сервера с большим количеством модулей, ожидающих выполнения, первый из главных серверов, выполняющий модуль, "самоназначается" модулем упавшего сервера. В случае восстановления одного из вышедших из строя серверов, модули, которые были назначены основному серверу, автоматически переназначаются. {{ :wiki:ha3.png }} Балансировка нагрузки между различными серверами осуществляется в административной части агента в меню "setup". {{ :wiki:ha4.png }} В поле "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. ===== Высокая доступность консоли Pandora FMS ===== Только нужно [[:en:documentation:06_metaconsole:03_installation|установить другую консоль]] указывающую на базу данных. Любая из консолей может использоваться одновременно из разных мест разными пользователями. Мы сможем использовать веб-балансировщик для консолей, если нам понадобится горизонтальный рост для балансировки нагрузки на консоли. Управление системой сессий осуществляется с помощью файлов cookie, которые хранятся в браузере. В случае использования удаленной конфигурации и для управления ею со всех консолей, оба сервера данных и консоли должны совместно использовать каталог входных данных (по умолчанию: /var/spool/pandora/data_in) для удаленной конфигурации агентов, коллекций и других каталогов. [[:en:documentation:07_technical_annexes:10_share_var_spool_directory_between_several_pandora_servers|В этом руководстве]] показано, как предоставлять общий доступ к этим каталогам с помощью NFS и GlusterFS. Важно предоставлять общий доступ только к подкаталогам внутри data_in, а не к самим data_in, так как это негативно скажется на производительности сервера. ==== Обновление ==== При обновлении консоли Pandora FMS в среде высокой доступности важно учитывать следующие соображения при обновлении через OUM посредством Update Manager → [[:ru:documentation:02_installation:02_anexo_upgrade#обновления_оффлайн|Update Manager offline]]. Пользователи версии Enterprise могут загрузить пакет OUM с сайта поддержки Pandora FMS. В сбалансированной среде с общей базой данных при обновлении первой консоли к базе данных применяются соответствующие изменения. Это приводит к тому, что при обновлении второй консоли Pandora FMS выдает ошибку при поиске информации, уже вставленной в базу данных. Однако обновление консоли будет осуществляться тем же способом. {{ :wiki:pfms-update_manager-offline-oum_1.png }} {{ :wiki:pfms-update_manager-offline-oum_2.png }} ===== Высокая доступность в базе данных ===== Цель данного раздела - предложить комплексное решение для HA в среде Pandora FMS. Это единственная модель HA с официальной поддержкой Pandora FMS. Это решение поставляется - предварительно установленным - из OUM 724. Эта система заменяет DRBD и другие системы HA, рекомендованные в прошлом. Это первое применение базы данных HA в Pandora FMS, и процесс установки почти полностью ручной, с использованием консоли GNU/Linux в качестве **root**. В будущих версиях мы облегчим настройку из графического интерфейса. Pandora FMS основана на базе данных MySQL для конфигурирования и хранения данных. Сбой базы данных может на мгновение парализовать работу инструмента мониторинга. Кластер базы данных высокой доступности Pandora FMS позволяет нам легко развернуть надежную и отказоустойчивую архитектуру. Это продвинутая функция, требующая знания систем GNU/Linux. Управление ресурсами кластера осуществляется с помощью [[https://github.com/ClusterLabs/pacemaker|Pacemaker]], усовершенствованного и масштабируемого менеджера ресурсов кластера высокой доступности. [[http://corosync.github.io/corosync/|Corosync]] предоставляет модель связи закрытой группы процессов для создания реплицированных машин состояний. [[https://www.percona.com/|Percona]] была выбрана в качестве РСУБД по умолчанию благодаря своей масштабируемости, доступности, безопасности и функциям резервного копирования. Активная/пассивная[[https://dev.mysql.com/doc/refman/5.7/en/replication.html|репликация]] осуществляется с одного ведущего узла (с разрешением на запись) на любое количество ведомых узлов (только для чтения). Виртуальный IP-адрес всегда ведет к текущему главному узлу. Если ведущий узел выходит из строя, один из ведомых узлов становится ведущим, а виртуальный IP-адрес обновляется соответствующим образом. {{ :wiki:ha_cluster_diagram.png }} Инструмент базы данных Pandora FMS HA, //pandora_ha//, осуществляет мониторинг кластера и следит за тем, чтобы сервер Pandora FMS непрерывно работал, перезапуская его при необходимости. //pandora_ha// в свою очередь контролируется systemd. Рекомендуется хранить максимум 15 дней данных и событий, для более длительного хранения [[:ru:documentation:05_big_environments:09_pandorafms_engineering#историческая_база_данных#уплотнение_данных|следует создать историческую базу данных]]. См. также тему "[[:ru:documentation:05_big_environments:07_server_management#историческая_база_данных|Управление и администрирование серверов PFMS]]". ==== Установка для RHEL 8 и Rocky Linux 8 ==== Версия 760 или более поздняя В этом примере будет настроен //cluster// из двух узлов, с //hosts//: **node1** и **node2**. Измените имена //hosts//, пароли и т.д. по мере необходимости в соответствии с развертываемой средой. Команды, которые должны быть выполнены на любом узле, будут иметь следующий синтаксис (пример для **node1**): node1# Команды, которые **должны быть выполнены на всех узлах**, будут предваряться словом **all**: all# Существует также дополнительный //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 \\ Инструмент базы данных Pandora FMS HA **не** будет работать должным образом, если в OpenSSH настроено предупреждение. \\ Сгенерируйте новые ключи аутентификации SSH для каждого //host// и скопируйте открытый ключ для каждого из //hosts//. \\ Вы можете сгенерировать ключи для пользователя, отличного от //root//, для последующей установки кластера с пользователем "//non-root//". \\ all# printf "\n\n\n" | ssh-keygen -t rsa -P '' ssh-copy-id -p22 root@node1 ssh-copy-id -p22 root@node2 pandorafms# printf "\n\n\n" | ssh-keygen -t rsa -P '' ssh-copy-id -p22 root@node1 ssh-copy-id -p22 root@node2 На узле Pandora FMS скопируйте пару ключей в следующие каталоги **httpd** , **ssh**. Консоль Pandora FMS (**httpd**) должна получить статус //cluster//: pandorafms# cp -r /root/.ssh/ /usr/share/httpd/ chown -R apache:apache /usr/share/httpd/.ssh/ \\ Следующие шаги необходимы только в том случае, если узлы используют 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 === Установка Percona === Установите необходимый пакет: 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 вы можете обратиться к официальной документации по продукту: \\ [[https://www.percona.com/doc/percona-server/5.7/installation/yum_repo.html|https://www.percona.com/doc/percona-server/5.7/installation/yum_repo.html]]\\ \\ После установки пакетов убедитесь, что служба Percona отключена, так как ею будет управлять //cluster//: all# systemctl disable mysqld \\ Если системная служба не отключена, диспетчер ресурсов //cluster// **не** будет работать правильно.\\ Затем запустите сервер 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 == [[:ru:documentation:02_installation:01_installing#установка|Установите Pandora FMS]] на вновь созданную базу данных. Остановите сервер Pandora FMS: pandorafms# /etc/init.d/pandora_server stop Начиная с версии NG 754 у вас [[:ru:documentation:05_big_environments:07_server_management#ручные_запуск_и_остановка_серверов_pandora_fms|появились дополнительные возможности по ручному запуску и остановке]] сред высокой доступности (HA). == Существующая установка Pandora FMS == Остановите сервер 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 Вы получите результат, похожий на: {{ :wiki:pfms-big_environments-ha-replication_configuration.png }} \\ Вы должны убедиться, что ''Slave_IO_Running'' и ''Slave_SQL_Running'' показывают **Yes**. //Другие значения могут отличаться от приведенных в примере.// \\ Если все в порядке, выйдите из интерфейса базы данных: #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 \\ При попытке запустить службу **corosync**: вы можете увидеть сообщение об ошибке: это связано с тем, что она еще не настроена, проигнорируйте его и продолжите следующие шаги. \\ \\ Остановите сервер 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 Вы увидите результат, аналогичный следующему: {{ :wiki:pfms-big_environments-ha-pcs_status.png }} \\ Оба узла должны быть в режиме онлайн ( ''Online: [ node1 node2 ]'' ). //Другие значения могут отличаться от приведенных в примере.// \\ === Установка агента репликации Pacemaker от Percona === Кардиостимулятор можно загрузить вручную из [[https://pandorafms.com/library/pacemaker-replication-agent-for-mysql/|библиотеки 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//. Если пароль по умолчанию, используемый в данном руководстве для пользователя базы данных //root//, был изменен, рекомендуется обновить ''replication_passwd'' и ''test_passwd'' соответственно. Имена ресурсов //cluster// должны быть точно такими, как указано в данном руководстве (**pandoraip** и **pandoradb**). Замените **** на предпочитаемый виртуальный IP-адрес: #node1 export VIP='' 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 Вы увидите результат, аналогичный следующему: {{ :wiki:pfms-big_environments-ha-pacemaker_status.png }} \\ Оба узла должны быть в режиме онлайн ( ''Online: [ node1 node2 ]'' ). //Другие значения могут отличаться от приведенных в примере.// \\ === Конфигурация двухузлового кластера с пользователем "не root" === Он будет [[:ru:documentation:05_big_environments:06_ha#конфигурация_кластера_с_двумя_узлами|проводиться аналогично предыдущему]]. Учетные данные пользователя должны быть скопированы, как уже объяснялось ранее, и необходимо выполнить следующие действия: # All nodes: useradd passwd usermod -a -G haclient # Enable PCS ACL system pcs property set enable-acl=true --force # Create role pcs acl role create description="RW role" write xpath /cib # Create PCS user - Local user pcs acl user create # Login into PCS from ALL nodes su - pcs status Username: Password: ***** # Wait for 'Authorized' message, ignore output. Wait a second and retry 'pcs status' command ==== Установка для RedHat 7 и CentOS 7 ==== Версия 759 или более ранняя Мы создадим двухузловой кластер с хостами //node1// и //node2//. Мы меняем имена хостов, пароли и т.д. в зависимости от того, что нам нужно для соответствия нашей среде. Командам, которые должны быть выполнены на узле, предшествует имя хоста этого узла. Например: node1# Перед командами, которые должны быть выполнены на всех узлах, должно стоять слово **all**. Например: all# Существует дополнительный хост, называемый **pandorafms**, на котором находится или установлен Pandora FMS. Когда **all** относится только к узлам Базы данных, дополнительный узел Pandora FMS всегда будет упоминаться как **pandorafms** и не является частью **all**. === Предварительные требования === 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 Инструмент базы данных Pandora FMS HA не будет работать правильно, если баннер настроен на Open SSH. Мы генерируем новые ключи аутентификации SSH для каждого узла и копируем открытый ключ для каждого узла: Ключи могут быть созданы для пользователя NO root, для последующей установки кластера с пользователем "no root". node1# echo -e "\n\n\n" | ssh-keygen -t rsa node1# ssh-copy-id -p22 root@node2 node1# ssh node2 node2# echo -e "\n\n\n" | ssh-keygen -t rsa node2# ssh-copy-id -p22 root@node1 node2# ssh node1 pandorafms# echo -e "\n\n\n" | ssh-keygen -t rsa pandorafms# ssh-copy-id -p22 root@node1 pandorafms# ssh-copy-id -p22 root@node2 pandorafms# ssh node1 pandorafms# ssh node2 На узле 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 === Установка Percona === Установите необходимый пакет: 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|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 == == Новая установка Pandora FMS == Мы устанавливаем Pandora FMS во вновь созданную базу данных. Для получения дополнительной информации: [[:ru:documentation:02_installation:01_installing|https://wiki.pandorafms.com/es:documentation:02_installation:01_installing]] Остановите сервер Pandora FMS: pandorafms# /etc/init.d/pandora_server stop \\ Начиная с версии NG 754 и выше, доступны [[:ru:documentation:05_big_environments:07_server_management|дополнительные опции по ручному запуску и выключению]] сред высокой доступности (HA). \\ == Существующая установка Pandora FMS == Остановите сервер 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 Мы должны убедиться, что **Slave_IO_Running** и **Slave_SQL_Running** показывают **Yes**. Другие значения могут отличаться от приведенных в примере. Рекомендуется **не** использовать пользователя **root** для выполнения этого процесса. Рекомендуется предоставить права другому пользователю, отвечающему за управление базой данных, чтобы избежать возможных конфликтов. === Конфигурация кластера с двумя узлами === Нужно установить необходимые пакеты: 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 Оба узла должны быть в режиме онлайн (''Online: [ node1 node2 ] '' ). Другие значения могут отличаться от приведенных в примере. == Установите агент репликации Pacemaker от Percona == вы можете загрузить его вручную с нашего сайта [[https://pandorafms.com/library/pacemaker-replication-agent-for-mysql/|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 Настроим ресурсы кластера. Заменяем **** на предпочитаемый виртуальный IP-адрес: Если пароль по умолчанию, используемый в данном руководстве для пользователя root базы данных, был изменен, необходимо соответствующим образом обновить //replication_passwd// и //test_passwd//. Имена ресурсов кластера должны быть точно такими, как указано в данном руководстве ("pandoraip" и "pandoradb") node1# export VIP='' 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 Оба узла должны быть в режиме онлайн (''Online: [ node1 node2 ] ''). Другие значения могут отличаться от приведенных в примере. === Настройка кластера из двух узлов с пользователем "no root" === Она будет проводиться аналогично предыдущей. Вы должны скопировать учетные данные пользователя, о чем говорилось ранее, и выполнить следующие шаги: # All nodes: useradd passwd usermod -a -G haclient # Enable PCS ACL system pcs property set enable-acl=true --force # Create role pcs acl role create description="RW role" write xpath /cib # Create PCS user - Local user pcs acl user create # Login into PCS from ALL nodes su - pcs status Username: Password: ***** # Wait for 'Authorized' message, ignore output. Wait a second and retry 'pcs status' command ==== Конфигурация Pandora FMS ==== Убедитесь, что **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-адрес): pandorafms# export VIRT_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//: {{ :wiki:hanuevo1.jpg |hanuevo1.jpg}} Нажмите //Add new node// и создайте запись для первого узла: {{ :wiki:manage_ha_add_node.png }} Затем нажмите //Create slave// и добавьте новую запись во второй узел. Это должно выглядеть примерно так: {{ :wiki:manage_ha_view.png }} //Seconds behind master// должен быть около 0. Если он продолжает расти, репликация не увеличивается. ==== Автоматическое восстановление узлов в Splitbrain ==== **Сценарий.** Оба сервера являются основными, или, в режиме просмотра консоли HA, оба выглядят основными, но виртуальный IP находится только на одном узле (том, который фактически выступает в качестве основного). {{ :wiki:pfms-ha-view_nodes.png }} В этот момент, если параметр //token// [[:ru:documentation:02_installation:04_configuration#splitbrain_autofix|splitbrain_autofix]] установлен в 1, начнется процесс восстановления узла в //splitbrain//. Для правильной работы этой функциональности необходимо правильно настроить следующие компоненты: * Ключи корневого пользователя SSH, общие для сервера ''pandora_ha master'' и всех серверов баз данных. * Пользователь Replicator, настроенный в настройке с правами от сервера, на котором размещен сервер ''pandora_ha master''. {{ :wiki:pfms-servers-manage_database_ha-setup_values.png }} * Свободное место для резервного копирования базы данных на обоих серверах, где размещены 2 базы данных (первичный и вторичный Master/Slave). В случае, если каталог данных и путь ( ''datadir'', ''path''),на котором будет создан раздел, находятся в одном разделе, необходимо, чтобы свободное пространство составляло не менее 50%. Если все вышеперечисленные пункты настроены правильно,** процесс восстановления происходит следующим образом**: - Удалите предыдущие резервные копии. - Создайте резервную копию ''datadir'' вторичного узла. - Резервное копирование основного узла. - Отправляет резервную копию основного узла на вторичный узел (//Master// → //Slave)//. - Запускает ресурс "вторичного" узла с соответствующими параметрами ресинхронизации на момент резервного копирования. - Проверяет, что ресурс активен и корректен. Для этого он должен использовать конфигурацию, указанную в параметрах [[:ru:documentation:02_installation:04_configuration#ha_max_resync_wait_retries|ha_max_resync_wait_retries]] и [[:ru:documentation:02_installation:04_configuration#ha_resync_sleep|ha_resync_sleep]]. В случае сбоя в любой точке процесса, он должен повторить процесс столько раз, сколько указано параметром [[:ru:documentation:02_installation:04_configuration#ha_max_splitbrain_retries|ha_max_splitbrain_retries]]. После завершения процесса в представлении событий появится событие, указывающее на успешное завершение процесса. Если среда по-прежнему не восстанавливается автоматически, то вторичный узел переходит в режим ожидания, **а в представлении событий появляется событие, указывающее, что восстановление должно быть выполнено вручную.** ==== Добавление нового узла в кластер ==== Повторите описанные выше шаги для установки **node1** и **node2**, в зависимости от версии, которая будет использоваться на новом узле: [[:ru:documentation:05_big_environments:06_ha#установка_для_rhel_8_и_rocky_linux_8|RHEL 8 o Rocky Linux 8 (PFMS Версия 760 или более поздняя)]]. [[:ru:documentation:05_big_environments:06_ha#установка_для_redhat_7_и_centos_7|RedHat 7 o CentOS 7 (PFMS Версия 759 или более ранняя)]]. Уберите баннер с надписью 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 для нового узла и копируем открытый ключ для каждого узла: Ключи могут быть сгенерированы для пользователя, не являющегося пользователем root, для установки кластера с пользователем "no root". node1# ssh-copy-id -p22 root@node3 node1# ssh node3 node2# ssh-copy-id -p22 root@node3 node2# ssh node3 pandorafms# ssh-copy-id -p22 root@node3 pandorafms# ssh node3 node3# echo -e "\n\n\n" | ssh-keygen -t rsa node3# ssh-copy-id -p22 root@node1 node3# ssh-copy-id -p22 root@node2 node3# ssh node1 node3# ssh node2 В узле 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, заменяя **** на номер, который должен быть уникальным для каждого узла кластера: Репликация базы данных не будет работать, если два узла имеют одинаковый **SERVER_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 Важно обеспечить, чтобы **Slave_IO_Running** и **Slave_SQL_Running** показывали **Yes**. Другие значения могут отличаться от приведенного примера. Мы устанавливаем необходимые пакеты для кластера: 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 Все узлы должны быть в режиме онлайн. (''Online: [ node1 node2 node3 ]''). Другие значения могут отличаться от приведенного примера. Регистрируем узел кластера в консоли 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 node2 должен находиться в режиме ожидания (''Node node2: standby''). Другие значения могут отличаться от приведенного примера. Мы создаем резервную копию каталога данных в 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 Оба узла должны быть в режиме онлайн. (''Online: [ node1 node2 ]''). Другие значения могут отличаться от приведенного примера. Мы проверяем состояние репликации базы данных: 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) Важно обеспечить, чтобы **Slave_IO_Running** и **Slave_SQL_Running** показывали **Yes**. Другие значения могут отличаться от приведенного примера. ==== Решение проблем ==== === Что делать, если один из узлов кластера не работает? === {{ :wiki:manage_ha_failed.png }} Служба не будет затронута до тех пор, пока главный узел работает. Если главный узел падает, вторичный узел автоматически становится главным. Смотрите: [[:ru:documentation:05_big_environments:06_ha#восстановление_сломанного_узла|Восстановление сломанного узла]]. [[:ru:documentation:start|Вернуться в оглавление Документации Pandora FMS]]