Синхронизация токенов сервиса eltex-doors
Описание
После развертывания серверов SoftWLC, на них необходимо синхронизировать токены сервиса eltex-doors. Токены с сервера Primary копируются на потенциальный Secondary с заменой, затем перезапускаются зависящие от них сервисы и повторно генерируются записи в БД.
Удалите содержимое папки "/etc/eltex-doors/keys/" на сервере Slave (файлы private.pem и public.pem).
Скопируйте содержимое папки "/etc/eltex-doors/keys/" с сервера Master на сервер Slave (файлы private.pem и public.pem).
Перезапустите на сервере Slave следующие сервисы:
sudo service eltex-disconnect-service restart sudo service eltex-doors restart sudo service eltex-johnny restart sudo service eltex-portal restart sudo service eltex-portal-constructor restart
На обоих серверах удалите из целевой БД в MySQL записи о токенах сервиса eltex-doors командой:
mysql -ujavauser -pjavapassword -e "delete from eltex_doors.auth_token;"
Перейдите к веб-интерфейсу личного кабинета на каждом сервере, адрес "http://<ip-адрес сервера>:8080/wifi-cab", внутри личного кабинета перейдите во вкладку "Сервисы и тарифы". Редактировать ничего не требуется, при переходе в указанный раздел ЛК - записи об удаленных на шаге "3" токенах сгенерируются в БД повторно.
Установка и настройка keepalived
Описание пакета
Пакет keepalived - это open source программное обеспечение, предназначенное для обеспечения функций высокой надежности (high availabilitty) и балансировки нагрузки (load-balancing). За первую функцию отвечает реализация протокола VRRP, а вторая основывается на модуле ядра Linux Vitrual Server (IPVS). Keepalived не разрабатывается сотрудниками Eltex и не включает доработок, за исключением конфигурации. Keepalived используется для организации резервирования контроллеров SoftWLC, при этом используется только функционал VRRP.
Установка keepalived
Для установки пакета, необходимо загрузить его на сервер и выполнить следующую команду (установка должна производиться от имени суперпользователя root на обоих серверах):
sudo apt update sudo apt install keepalived
После установки необходимо добавить демона Keepalived в автозагрузку и запустить его:
sudo systemctl enable keepalived sudo systemctl start keepalived
Основной файл конфигурации
На обоих серверах в файле /etc/keepalived/keepalived.conf меняем следующие параметры:
<interface> - наименование сетевого интерфейса (свой для каждого сервера) аналогично записи (eth1);
<virtual_ip> - виртуальный ip-адрес (с указанием префикса) аналогично записи (100.111.195.202 /24);
<ip_адрес другого сервера> - ip-адрес другого сервера аналогично записи (100.111.195.200);
Тест-скрипт
Скрипт пингует шлюз по умолчанию и возвращает код результата. Таким образом, при успешном выполнении скрипта, гарантируется, что SoftWLC достижим для внешних клиентов.
В текущей реализации на обоих серверах, в качестве тестового скрипта, предлагается использовать следующий:
где <default_gw_ip> - шлюз по умолчанию для этого сервера аналогично записи (100.10.194.1);.
Конфигурация смены роли
При смене состояния сервера, выполняется скрипт keep_notify.sh, где <mysql_user> и <mysql_password> - логин и пароль от БД MySQL (по умолчанию root/root).
Необходимо добавить права
sudo chmod +x /etc/keepalived/check_ping.sh sudo chmod +x /etc/keepalived/keep_notify.sh
Выделение лога в отдельный файл
По умолчанию keepalived записывает лог в файл /var/log/syslog . Для удобства отладки, мониторинга и контроля работы keepalived, можно настроить ведение собственного, отдельного лог-файла.
Ниже приведен пример настройки rsyslog:
sudo nano -w /etc/rsyslog.d/10-keepalived.conf
Добавьте в файл 10-keepalived.conf следующее:
if $programname contains 'Keepalived' then /var/log/keepalived.log if $programname contains 'Keepalived' then ~
Затем, нужно перезапустить rsyslog командой:
sudo service rsyslog restart
Теперь сообщения от демона keepalived попадут только в лог-файл /var/log/keepalived.log и не попадут в /var/log/syslog .
Способ запуска/остановки keepalived
Для запуска сервиса воспользуйтесь командой:
sudo service keepalived start
Остановка сервиса:
sudo service keepalived stop
Проверить состояние сервиса можно командой:
sudo service keepalived status
Проверка корректной настройки keepalived
После настройки keepalived на одном из сервером среди интерфейсов должен появиться виртуальный адрес ( в данной случае eth2:1 100.112.0.5)
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 100.112.8.1 netmask 255.255.255.0 broadcast 100.112.8.255 inet6 fe80::64ff:fe70:801 prefixlen 64 scopeid 0x20<link> ether 02:00:64:70:08:01 txqueuelen 1000 (Ethernet) RX packets 35070 bytes 4468505 (4.4 MB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 116021 bytes 5036010 (5.0 MB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 eth2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 100.112.0.2 netmask 255.255.255.0 broadcast 100.112.0.255 inet6 fe80::64ff:fe70:2 prefixlen 64 scopeid 0x20<link> ether 02:00:64:70:00:02 txqueuelen 1000 (Ethernet) RX packets 5561245 bytes 957475021 (957.4 MB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 6478780 bytes 1408073987 (1.4 GB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 eth2:1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 100.112.0.5 netmask 255.255.255.255 broadcast 0.0.0.0 ether 02:00:64:70:00:02 txqueuelen 1000 (Ethernet) eth3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 100.112.7.1 netmask 255.255.255.0 broadcast 100.112.7.255 inet6 fe80::64ff:fe70:701 prefixlen 64 scopeid 0x20<link> ether 02:00:64:70:07:01 txqueuelen 1000 (Ethernet) RX packets 21885 bytes 3737224 (3.7 MB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 145 bytes 10246 (10.2 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Кроме адреса существует еще один параметр показывающий состояние ноды, статус храниться в файле /tmp/keep.mod (можно проверить выводом cat /tmp/keep.mode )
root@SWLC-master:/home/tester# cat /tmp/keep.mode MASTER
виртуальный адрес должен находиться на мастере. Проверку смены мастерства и переход виртуального адреса, можно проверять при помощи рестарта сервиса keepalived.
Настройка rsync
Rsync в схеме резервирования отвечает за синхронизацию служебных файлов, сервисов Eltex-EMS и Eltex-APB, а также файлов прошивок, шаблонов конфигурации, выгрузок конфигураций точек. Rsync представляет собой клиент серверное ПО. В данной схеме master-сервер выступает в роли клиента и синхронизирует каталоги slave-сервера с локальными.
Для активации сервера rsync, необходимо на каждом сервере в файле /etc/default/rsync установить значение:
RSYNC_ENABLE=true
Основной файл конфигурации :
Перед обновлением необходимо остановить сервер rsync:
vagrant@ubuntu:~$ systemctl stop rsync.service
Запускать rsync необходимо после обновления всех нод.
Для аутентификации, необходимо настроить пользователя rsync, для этого, на каждом сервере создайте файлы /etc/rsyncd.secrets, в которых необходимо указать пароль.
backup:rspasswd
Назначить права доступа к файлам, выполнив на обоих серверах:
sudo chmod 600 /etc/rsyncd.secrets
Настройка запуска синхронизации
Создайте файлы /etc/rsync_client.secrets, в которых укажите пароль:
echo "rspasswd" | sudo tee /etc/rsync_client.secrets && sudo chmod 600 /etc/rsync_client.secrets
Начиная с версии rsync 3.2.0 добавлена по умолчанию защита каталога /usr, /boot, /home (защиту home в дальнейшем убрали) Решением является переопределение защищающей опции rsync.
Для этого необходимо на обоих хостах:
прописать команду
systemctl edit rsync
в открывшемся файле в начале прописать:
[Service]
ProtectSystem=off
перезапустить службу
service rsync restart
Способ запуска/остановки
Для запуска сервиса используется команда:
sudo service rsync start
Для остановки сервиса используется команда:
sudo service rsync stop
Для проверки — запущен ли сервис в данный момент, используется команда:
sudo service rsync status
Операцию синхронизации файлов осуществляет задача cron, в которой выполняется скрипт /usr/lib/eltex-ems/scripts/rsync_ems_backup.sh. Скрипт запускает rsync клиент и синхронизирует локальные директории с директориями на втором (backup) сервере. Синхронизация запускается только в случае, если сервер в состоянии master.
В 6 строке заменить HOST на ip-адрес другого сервера (Пример: HOST=100.111.195.201)
Конфигурация скрипта для eltex-radius/eltex-radius-nbi
Сервис eltex-radius-nbi генерирует для каждой из нод свой собственный CA и серверный сертификат, после чего копирует их в eltex-radius:
- /var/lib/eltex-radius-nbi/wireless-ca.crt > /etc/eltex-radius/certs/ca/local.pem
- /var/lib/eltex-radius-nbi/certificates/server.crt > /etc/eltex-radius/certs/server.crt
- /var/lib/eltex-radius-nbi/certificates/server.key > /etc/eltex-radius/certs/server.key
На основании wireless-ca.crt буду генерироваться клиентские сертификаты (создаются через ЛК) в директории /var/lib/eltex-radius-nbi/certificates/
При создании сертификата пользователя через ЛК он будет сгенерирован на только ноде, на которой сейчас вы находитесь и на основании его собственного wireless-ca.crt.
Поэтому при переходе мастерства вторая нода не будет ничего знать о клиентских сертификатах.
Обязательно убедитесь, что в файле /etc/eltex-radius-nbi/radius_nbi_config.txt в переменной tomcat.host установлен ваш виртуальный ip-адрес
Чтобы это исправить нужно:
- выбираем ноду, которая будет владеть актуальными данными, например первую ноду
Добавить ip-адрес второго хоста в переменную окружения
echo "export SLAVE_HOST="YOUR_IP"" | sudo tee /etc/environment && source /etc/environment
эти команды синхронизируют данные с вашей второстепенной нодой
- убедитесь, что файлы в директориях /var/lib/eltex-radius-nbi/ и /etc/eltex-radius/certs/ совпадают
Статус можно проверить в файле /tmp/keep.mode
Настройка cron
Cоздать задачу в cron на обоих серверах, для запуска синхронизации раз в минуту:
sudo crontab -l | { cat; echo "*/1 * * * * /usr/lib/eltex-ems/scripts/rsync_ems_backup.sh"; } | sudo crontab sudo crontab -l | { cat; echo "*/1 * * * * /usr/lib/eltex-radius-nbi/rsync_radius_cert_synchronization.sh"; } | sudo crontab
Проверяем список задач:
sudo crontab -l */1 * * * * /usr/lib/eltex-ems/scripts/rsync_ems_backup.sh */1 * * * * /usr/lib/eltex-radius-nbi/rsync_radius_cert_synchronization.sh
Если задача не добавилась или случайно добавилась несколько раз - редактируем список вручную:
sudo crontab -e Select an editor. To change later, run 'select-editor'. 1. /bin/nano <---- easiest 2. /usr/bin/vim.tiny 3. /usr/bin/code 4. /bin/ed Choose 1-4 [1]: 1 # выбираем в каком редакторе открыть
Проверка корректной работы rsync
Проверить работу rsync можно в EMS. Во вкладке "Информация"-Состояние системы резервирования-Rsync service.
На обоих серверах должна быть запись такого типа:
OK. Успешная синхронизация файлов из директории: /usr/lib/eltex-ems/conf/* OK. Успешная синхронизация файлов из директории: /tftpboot/* OK. Успешная синхронизация файлов из директории: /var/ems-data/WP/*
Настройка репликации MariaDB
Резервирование данных, хранящихся СУБД MySQL, осуществляется путём встречной репликации по принципу master-master (ведущий-ведущий). То есть, каждый из серверов одновременно является и master и slave. При такой схеме работы, все изменения в БД на одном сервере записываются в специальный бинарный лог, который в реальном времени вычитывает второй сервер и применяет изменения. Второй сервер реплицирует данные с первого, а первый со второго. Это позволяет получить актуальную копию БД на двух хостах одновременно. При разрыве связи, изменения накапливаются, после восстановления происходит синхронизация.
Перенос дампа данных и перенос на второй сервер
При настройке резервирования в процессе эксплуатации (то есть если в MySQL на действующем сервере уже имеются данные), необходимо перенести эти данные на второй сервер. Это можно сделать при помощи утилиты mysqldump.
Для этого, необходимо на первом сервере заблокировать таблицы, снять дамп, разблокировать таблицы и скопировать получившийся файл на второй сервер:
1) sudo mysql -uroot -proot -e "FLUSH TABLES WITH READ LOCK;" 2) sudo mysqldump -uroot -proot --databases ELTEX_PORTAL eltex_alert eltex_auth_service eltex_bruce eltex_doors eltex_ems eltex_jobs eltex_ngw eltex_ont radius wireless eltex_pcrf eltex_wids eltex_wifi_customer_cab eltex_sorm2 eltex_ott eltex_jerry> mysqldump_master.sql 3) sudo mysql -uroot -proot -e "UNLOCK TABLES;" 4) sudo scp mysqldump_master.sql <username>@<ip_server2>:/home/<username>/
Затем, развернуть dump на втором сервере:
sudo mysql -uroot -proot < /home/<username>/mysqldump_master.sql
Настройка MariaDB
Конфигурация самого демона mysqld заключается в настройке параметров ведения бинарных логов. Обозначения первый сервер и второй сервер далее условны, и применяются лишь для обозначения различий в конфигурации серверов.
В секции [mysqld] файла конфигурации /etc/mysql/mariadb.conf.d/50-server.cnf произвести следующие изменения:
Закомментировать либо удалить строку на обоих серверах:
bind-address = 127.0.0.1
Указать server-id. Для серверов необходимо задать уникальные идентификаторы, к примеру, для первого:
server-id = 1
для второго:
server-id = 2
Включить бинарные логи на обоих серверах:
log_bin = /var/log/mysql/mysql-bin.log
Включаем GTID и обеспечиваем согласованность на обоих серверах
gtid_strict_mode=1 ssl=0
На обоих серверах: указать базы, для которых будут вестись логи:
binlog-do-db = eltex_alert binlog-do-db = eltex_ems binlog-do-db = wireless binlog-do-db = radius binlog-do-db = eltex_auth_service binlog-do-db = ELTEX_PORTAL binlog-do-db = eltex_doors binlog-do-db = eltex_ngw binlog-do-db = eltex_bruce binlog-do-db = eltex_jobs binlog-do-db = eltex_ont binlog-do-db = eltex_pcrf binlog-do-db = eltex_wids binlog-do-db = eltex_wifi_customer_cab binlog-do-db = eltex_sorm2 binlog-do-db = eltex_ott binlog-do-db = eltex_jerry
yказать базы, для которых не будут вестись логи:
binlog-ignore-db = mysql binlog-ignore-db = Syslog binlog-ignore-db = performance_schema binlog-ignore-db = information_schema
Перезапустить сервис mysql на каждом сервер и создать БД для репликации:
sudo service mysql restart
Создание учетных записей
Для работы репликации необходима служебная учетная запись на каждом из серверов. Под этой учетной записью, сервер будет подключаться к master-серверу и получать изменения в данных.
Создать в консоли MySQL учетную запись для репликации на первом сервере:
GRANT SELECT, SUPER, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'replication'@'<ip_server2>' IDENTIFIED BY 'password'; GRANT SELECT, SUPER, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'replication'@'<ip_server1>' IDENTIFIED BY 'password'; #необходимо для проверки состояния репликации из EMS FLUSH PRIVILEGES;
Создать в консоли MySQL учетную запись для репликации на втором сервере:
GRANT SELECT, SUPER, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'replication'@'<ip_server1>' IDENTIFIED BY 'password'; GRANT SELECT, SUPER, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'replication'@'<ip_server2>' IDENTIFIED BY 'password'; #необходимо для проверки состояния репликации из EMS FLUSH PRIVILEGES;
Выдача прав сервисным пользователям
Открыть /usr/lib/eltex-ems/conf/config.txt, посмотреть какие username / password используются (по умолчанию - javauser / javapassword)
Выдаем им права на внешний доступ на обоих серверах:
GRANT ALL PRIVILEGES ON *.* TO 'javauser'@'%' IDENTIFIED BY 'javapassword'; GRANT ALL PRIVILEGES ON eltex_auth_service.* TO 'javauser'@'%'; GRANT ALL PRIVILEGES ON `radius`.* TO 'javauser'@'%'; GRANT ALL PRIVILEGES ON `wireless`.* TO 'javauser'@'%'; GRANT ALL PRIVILEGES ON `Syslog`.* TO 'javauser'@'%'; GRANT ALL PRIVILEGES ON `eltex_doors`.* TO 'javauser'@'%'; GRANT ALL PRIVILEGES ON `eltex_ngw`.* TO 'javauser'@'%'; GRANT ALL PRIVILEGES ON `ELTEX_PORTAL`.* TO 'javauser'@'%'; GRANT ALL PRIVILEGES ON `eltex_ems`.* TO 'javauser'@'%'; GRANT ALL PRIVILEGES ON `eltex_alert`.* TO 'javauser'@'%'; GRANT ALL PRIVILEGES ON `eltex_auth_service`.* TO 'javauser'@'%'; GRANT ALL PRIVILEGES ON `eltex_bruce`.* TO 'javauser'@'%'; GRANT ALL PRIVILEGES ON `eltex_pcrf`.* TO 'javauser'@'%'; GRANT ALL PRIVILEGES ON `eltex_wids`.* TO 'javauser'@'%'; GRANT ALL PRIVILEGES ON `eltex_wifi_customer_cab`.* TO 'javauser'@'%'; GRANT ALL PRIVILEGES ON `eltex_jobs`.* TO 'javauser'@'%'; GRANT ALL PRIVILEGES ON `eltex_sorm2`.* TO 'javauser'@'%'; GRANT ALL PRIVILEGES ON `eltex_ott`.* TO 'javauser'@'%'; GRANT ALL PRIVILEGES ON `eltex_jerry`.* TO 'javauser'@'%'; FLUSH PRIVILEGES;
Включение репликации
Настроить и запустить репликацию второго сервера с первого (выполнить действия на втором сервере):
STOP SLAVE; CHANGE MASTER TO MASTER_HOST='<ip_server1>', MASTER_USER='replication', MASTER_PASSWORD='password', MASTER_USE_GTID=slave_pos; START SLAVE;
Проверить состояние репликации:
MariaDB [(none)]> show slave status \G; *************************** 1. row *************************** Slave_IO_State: Master_Host: 100.110.3.91 Master_User: replication Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000013 Read_Master_Log_Pos: 3332141 Relay_Log_File: localhost-relay-bin.000062 Relay_Log_Pos: 320 Relay_Master_Log_File: mysql-bin.000013 Slave_IO_Running: No Slave_SQL_Running: No Replicate_Do_DB: 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: 3332141 Relay_Log_Space: 0 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: NULL 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: 0 Master_SSL_Crl: Master_SSL_Crlpath: Using_Gtid: No Gtid_IO_Pos: Replicate_Do_Domain_Ids: Replicate_Ignore_Domain_Ids: Parallel_Mode: optimistic SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Slave_DDL_Groups: 0 Slave_Non_Transactional_Groups: 0 Slave_Transactional_Groups: 0 1 row in set (0.000 sec)
Выведем состояние параметров gtid:
MariaDB [(none)]> show global variables like '%gtid%'; +-------------------------+-----------+ | Variable_name | Value | +-------------------------+-----------+ | gtid_binlog_pos | 0-2-4217 | | gtid_binlog_state | 0-2-4217 | | gtid_cleanup_batch_size | 64 | | gtid_current_pos | 0-1-13665 | | gtid_domain_id | 0 | | gtid_ignore_duplicates | OFF | | gtid_pos_auto_engines | | | gtid_slave_pos | 0-1-13665 | | gtid_strict_mode | ON | | wsrep_gtid_domain_id | 0 | | wsrep_gtid_mode | OFF | +-------------------------+-----------+ 11 rows in set (0.001 sec)
Структура значения GTID выглядит следующим образом:
X-Y-Z:
X - номер домена кластера;
Y - server_id ноды кластера;
Z - gjpbwbz
На 1-ом сервере
STOP SLAVE; CHANGE MASTER TO MASTER_HOST='<ip_server2>', MASTER_USER='replication', MASTER_PASSWORD='password',MASTER_USE_GTID=slave_pos; START SLAVE;
Проверить состояние репликации:
MariaDB [(none)]> show slave status\G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 192.168.152.12 Master_User: replication Master_Port: 5890 Connect_Retry: 60 Master_Log_File: mysql-bin.000003 Read_Master_Log_Pos: 2682485 Relay_Log_File: mysqld-relay-bin.000002 Relay_Log_Pos: 2674921 Relay_Master_Log_File: mysql-bin.000003 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB: 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: 2682485 Relay_Log_Space: 2675231 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_SSL_Crl: Master_SSL_Crlpath: Using_Gtid: Slave_Pos Gtid_IO_Pos: 0-1-13677 Replicate_Do_Domain_Ids: Replicate_Ignore_Domain_Ids: Parallel_Mode: optimistic SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates Slave_DDL_Groups: 740 Slave_Non_Transactional_Groups: 0 Slave_Transactional_Groups: 12844 1 row in set (0.001 sec)
Проверка корректной настройки MariaDB
Проверить что реплиакация работает можно как через GUI ems перейдя на вкладку Информация >> состояние системы резервирования >> MySQL.
Еще можно проверить непосредственно перейдя в саму БД. На обоих серверах должен быть статус слейва
show slave status \G *************************** 1. row *************************** ...... Slave_IO_Running: Yes Slave_SQL_Running: Yes ......
Slave_IO_Running — состояние работы получения бинарного лога с сервера Master. Если состояние будет NO, то репликация не работает.
Slave_SQL_Running — статус выполнения команд из лога на сервере Slave. Если состояние будет NO, то репликация не работает.
Настройка ProxySQL
ProxySQL – ПО с открытым исходным кодом (GPL license) для проксирования SQL-запросов. Представляет собой высокопроизводительный инструмент, который можно применять для HA.
Поддерживает MySQL и его форки (Percona, Maria & etc).
Установка
Скачиваем файл с официального сайта: https://proxysql.com/documentation/installing-proxysql/ для Debian 10 и устанавливаем:
wget https://github.com/sysown/proxysql/releases/download/v2.5.2/proxysql_2.5.2-debian10_amd64.deb sudo dpkg -i proxysql_2.5.2-debian10_amd64.deb
В БД mariadb добавляем пользователя:
CREATE USER 'monitor'@'%' IDENTIFIED BY 'monitor'; GRANT USAGE, REPLICATION CLIENT ON *.* TO 'monitor'@'%';
Редактируем файл настроек /etc/proxysql.cnf и приводим его к виду (тестовый стенд):
Основные настройки.
Исправляем вывод файла логов на более обычную директорию:
errorlog="/var/log/proxysql/proxysql.log"
Добавляем секцию с информацией о серверах MariaDB:
mysql_servers = ( { address = "<IP MASTER>" # port = 5890 #перенастроили порт для взаимодействия с mysql hostgroup = 1 maxconnections = 500 max_replication_lag = 0 weight = 1000 }, { address = "<IP SLAVE>" port = 5890 #перенастроили порт для взаимодействия с mysql hostgroup = 2 maxconnections = 500 max_replication_lag = 0 weight = 500 } )
добавляем информацию о пользователях БД:
mysql_users: ( { username = "root" password = "root" default_hostgroup = 0 active = 1 max_connections = 500 fast_forward = 1 }, { username = "javauser" password = "javapassword" default_hostgroup = 1 active = 1 max_connections = 500 fast_forward = 1 }, { username = "radius" password = "radpass" default_hostgroup = 1 active = 1 max_connections = 500 fast_forward = 1 } )
Добавляем информацию о группах
mysql_replication_hostgroups= ( { writer_hostgroup=1 reader_hostgroup=2 comment="SWLC REPLICA" } )
Добавляем информацию о scheduler:
scheduler= ( { id=1 active=1 interval_ms=10000 filename="/var/lib/proxysql/read_only_switch.sh" arg1="NULL" arg2="NULL" arg3="NULL" arg4="NULL" arg5="NULL" comment="Script to switch read_only_status" } )
В директорию /var/lib/proxysql/ необходимо добавить следующий скрипт read_only_switch.sh:
#!/bin/bash MASTER_HOST="<ip_server_master>" SLAVE_HOST="<ip_server_slave>" MYSQL_USER="javauser" MYSQL_PASS="javapassword" # Проверяем доступность мастера if mysqladmin -h $MASTER_HOST -u $MYSQL_USER -p$MYSQL_PASS ping; then # Мастер доступен, убедимся, что он в read-write mysql -h $MASTER_HOST -u $MYSQL_USER -p$MYSQL_PASS -e "SET GLOBAL read_only = 0;" # Установить слейв в read-only, если он был временно переключен mysql -h $SLAVE_HOST -u $MYSQL_USER -p$MYSQL_PASS -e "SET GLOBAL read_only = 1;" else # Если мастер недоступен, переключаем слейв в read-write mysql -h $SLAVE_HOST -u $MYSQL_USER -p$MYSQL_PASS -e "SET GLOBAL read_only = 0;" fi
Рестартуем сервис:
systemctl restart proxysql
Здесь необходимо обратить особое внимание: если существует файл «proxysql.db» (в каталоге /var/lib/proxysql), служба ProxySQL будет читать и анализировать файл proxysql.cnf только при первом запуске; Далее файл proxysql.cnf не будет прочитан во время сеанса запуска! Если вы хотите, чтобы конфигурация в файле proxysql.cnf вступила в силу после перезапуска службы proxysql (то есть, если вы хотите, чтобы proxysql читал и анализировал файл конфигурации proxysql.cnf при перезапуске), вам необходимо удалить в директории /var/lib/ сначала файл базы данных proxysql/proxysql.db, а затем перезапустить службу proxysql. Это эквивалентно инициализации и запуску службы proxysql, снова будет создан чистый файл базы данных proxysql.db (если ранее были настроены правила маршрутизации, связанные с proxysql, и т. д., он будет удален). Официальная рекомендация — использовать метод интерфейса администратора! (То есть используйте клиент mysql для подключения к порту управления на машине proxysql)
Подключение к административной консоли (используются дефолтные настройки /etc/proxysql.cnf):
mysql -uadmin -padmin -P 6032 -h 127.0.0.1 --prompt='Admin>'
Для отображения статусов запущенных серверов mysql воспользуемся командой :
select * from runtime_mysql_servers;
Далее, необходимо изменить порт взаимодействия SoftWLC с Proxysql:
update global_variables set variable_value = '0.0.0.0:3306' where variable_name = 'mysql-interfaces'; SAVE MYSQL VARIABLES TO DISK;
В настройках mariadb НА ОБОИХ СЕРВЕРАХ /etc/mysql/mariadb.cnf необходимо в разделе [client-server] изменить port на указанный ранее, в примере - 5890
[client-server] # Port or socket location where to connect port = 5890
После этого необходимо перезагрузить ОБА СЕРВЕРА mariadb и proxysql
sudo service mariadb restart sudo service proxysql restart
Далее, необходимо перезагрузить репликацию mariadb:
# На слейве stop slave; change master to master_host='<IP MASTER>', master_port=5890, master_user='replication', master_password='password', master_use_gtid=slave_pos; start slave; # На мастере stop slave; change master to master_host='<IP SLAVE>', master_port=5890, master_user='replication', master_password='password', master_use_gtid=slave_pos; start slave;
Смена версии mysql, которую отдает proxysql
Заходим в административную консоль, изменяем переменную:
update global_variables set variable_value='5.7.19' where variable_name='mysql-server_version';
Загружаем изменения в оперативную конфигурацию proxysql:
load mysql variables to runtime;
Сохраняем изменения:
save mysql variables to disk;
Проверяем значение переменной:
show variables like 'mysql-server_version';
Добавление/удаление/отключение сервера
Чтобы добавить новый сервер, его необходимо определить, вставив новую строку в mysql_serversтаблицу.
Обратите внимание, что в таблице есть несколько столбцов со значениями по умолчанию.
Следующее добавляет новый бэкэнд со всей конфигурацией по умолчанию:
Admin> SELECT * FROM mysql_servers; Empty set (0.00 sec) Admin> INSERT INTO mysql_servers (hostname) VALUES ('172.16.0.1'); Query OK, 1 row affected (0.00 sec) Admin> SELECT * FROM mysql_servers\G *************************** 1. row *************************** hostgroup_id: 0 hostname: 172.16.0.1 port: 3306 gtid_port: 0 status: ONLINE weight: 1 compression: 0 max_connections: 1000 max_replication_lag: 0 use_ssl: 0 max_latency_ms: 0 comment: 1 row in set (0.00 sec)
Чтобы корректно отключить внутренний сервер, необходимо изменить его statusна OFFLINE_SOFT. Активные транзакции и соединения по-прежнему будут использоваться, но новый трафик на узел отправляться не будет.
Admin> SELECT hostgroup_id,hostname,status FROM mysql_servers; +--------------+------------+--------+ | hostgroup_id | hostname | status | +--------------+------------+--------+ | 0 | 172.16.0.1 | ONLINE | | 1 | 172.16.0.2 | ONLINE | | 1 | 172.16.0.3 | ONLINE | | 1 | 172.16.0.1 | ONLINE | +--------------+------------+--------+ 4 rows in set (0.00 sec) Admin> UPDATE mysql_servers SET status='OFFLINE_SOFT' WHERE hostname='172.16.0.2'; Query OK, 1 row affected (0.00 sec) Admin> SELECT hostgroup_id,hostname,status FROM mysql_servers; +--------------+------------+--------------+ | hostgroup_id | hostname | status | +--------------+------------+--------------+ | 0 | 172.16.0.1 | ONLINE | | 1 | 172.16.0.2 | OFFLINE_SOFT | | 1 | 172.16.0.3 | ONLINE | | 1 | 172.16.0.1 | ONLINE | +--------------+------------+--------------+ 4 rows in set (0.00 sec)
Можно полностью удалить внутренний сервер, удалив его из mysql_serversтаблицы.
Внутренне удаление бэкэнда или его настройка OFFLINE_HARDобрабатываются одинаково. При LOAD MYSQL SERVERS TO RUNTIMEвыполнении Hostgroup_Manager обнаружит, что внутренний сервер был удален, и пометит его как OFFLINE_HARD.
Мониторинг
SHOW TABLES FROM monitor; SELECT * FROM monitor.mysql_server_connect_log ORDER BY time_start_us DESC LIMIT 4; SELECT * FROM monitor.mysql_server_galera_log ORDER BY time_start_us DESC LIMIT 4; SELECT * FROM monitor.mysql_server_ping_log ORDER BY time_start_us DESC LIMIT 4;
Работа Eltex-PCRF в режиме кластера
Настройка кластера PCRF
Между серверами PCRF нужно открыть порты 5701 tcp, 5801 tcp
На серверах в файлах конфигурации /etc/eltex-pcrf/hazelcast-cluster-network.xml
нужно указать адреса сетевых интерфейсов (в строках 5 и 22 в примере - адрес самого сервера, строки 14-15 - список всех членов кластера)
пример, часть конфигурации:
<network> <!-- Write here public address of the node --> <!-- здесь нужно указать собственный адрес сервера --> <public-address>ip_server1</public-address> <port auto-increment="false" port-count="100">5701</port> <outbound-ports> <ports>0</ports> </outbound-ports> <join> <multicast enabled="false"/> <tcp-ip enabled="true"> <!-- Перечислить IP-адреса всех членов кластера (включая этот) --> <member>ip_server1</member> <member>ip_server2</member> </tcp-ip> <discovery-strategies> </discovery-strategies> </join> <interfaces enabled="true"> <!-- здесь нужно указать собственный адрес сервера --> <interface>ip_server1</interface> </interfaces>
В конфигурации /etc/eltex-pcrf/eltex-pcrf.json
нужно разрешить запуск кластера:
"cluster.enable" : true,
Перезапустить Eltex-PCRF командой
sudo service eltex-pcrf restart
Проверка состояния кластера
{ "data": { "enabled": true, "state": "ACTIVE", "members": [ { "address": "ip_server1", "local": true, "active": true }, { "address": "ip_server2", "local": false, "active": true } ] }, "key": "PcrfErrorCode.success", "message": "Success", "code": 0, "args": [ ] }
Особенности настройки ESR для взаимодействия с кластером PCRF
При использовании кластера PCRF на ESR настроить взаимодействие со всеми нодами кластера используя их реальный адрес.