Синхронизация токенов сервиса 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);

! Configuration File for keepalived
 
global_defs {
 
   script_user root
   enable_script_security 
}

vrrp_script check_network {
    script "/etc/keepalived/check_ping.sh"
    interval 5
    weight 50
    fall 3
    rise 3
    init_fail
    user root
}

vrrp_instance VI_SWLC {
    state  MASTER
    interface <interface>
    virtual_router_id 1
    track_script {
        check_network
    }
    track_interface {
        <interface> weight 50
    }
    priority 150
    advert_int 1
    nopreempt
	# Uncomment and comment "nopreempt" if preemption needed
	#preempt_delay 180
    authentication {
        auth_type PASS
        auth_pass eltex
    }
    virtual_ipaddress {
        <virtual_ip> dev <interface> label <interface>:1
    }
 
    notify_master "/etc/keepalived/keep_notify.sh master"
    notify_backup "/etc/keepalived/keep_notify.sh backup"
    notify_fault "/etc/keepalived/keep_notify.sh fault"
 
    unicast_peer {
        <ip_адрес_другого_сервера>
    }
}

Тест-скрипт

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

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

#!/bin/bash

# host to ping
# there - default gw
HOST=<default_gw_ip>
# -q quiet
# -c nb of pings to perform
ping -c 1 -W 1 $HOST > /dev/null

# $? var keeping result of execution
# previous command
if [ $? -eq 0 ]
    then
        echo `date +"%T %F"` "OK gw reachable"
        EXIT_CODE=0
    else
        echo `date +"%T %F"` "ERROR gw unreacheble!"
        EXIT_CODE=1
fi

exit $EXIT_CODE

где <default_gw_ip> - шлюз по умолчанию для этого сервера аналогично записи (100.10.194.1);.

Конфигурация смены роли

При смене состояния сервера, выполняется скрипт keep_notify.sh, где <mysql_user> и <mysql_password> - логин и пароль от БД MySQL (по умолчанию root/root).

#!/bin/bash

MYSQL_USER="<mysql_user>"
MYSQL_PASSWORD="<mysql_password>"


if ! lockfile-create --use-pid -r 5 /tmp/keep.mode.lock; then
    echo "Unable to lock"
    echo "Unable to lock" > /tmp/keep.mode.lock.fail
    exit 0
fi

case "$1" in
    master)
    #  ems_reload_all
    echo "MASTER" > /tmp/keep.mode
  
    service eltex-ems restart
    service eltex-ngw restart
    service eltex-wifi-cab restart

  ;;
 backup)
    echo "BACKUP" > /tmp/keep.mode

    service eltex-ems stop
    service eltex-ngw stop
	service eltex-wifi-cab stop
 
 ;;
 fault)
    echo "FAULT" > /tmp/keep.mode
 ;;
 *)
    echo "Usage: $0 {master|backup|fault}"
    exit 1
esac

lockfile-remove /tmp/keep.mode.lock;

exit 0

Необходимо добавить права 

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

Основной файл конфигурации : 

[ems-conf]
path = /usr/lib/eltex-ems/conf/
use chroot = no
max connections = 2
lock file = /var/lock/rsyncd
read only = no
list = no
uid = root
auth users = backup
secrets file = /etc/rsyncd.secrets
strict modes = yes
# IP-адрес сервера, который будет иметь доступ к ресурсу, т.е. адрес второго сервера в паре
hosts allow = <ip_адрес_другого_сервера> <virtual_ip>
ignore errors = no
ignore nonreadable = yes
transfer logging = no
timeout = 60
refuse options = checksum dry-run
dont compress = *.gz *.tgz *.zip *.z *.rpm *.deb *.iso *.bz2 *.tbz
 
[ems-tftp]
path = /tftpboot
use chroot = no
max connections = 2
lock file = /var/lock/rsyncd.tftp
read only = no
list = no
uid = root
auth users = backup
secrets file = /etc/rsyncd.secrets
strict modes = yes
hosts allow = <ip_адрес_другого_сервера> <virtual_ip>
ignore errors = no
ignore nonreadable = yes
transfer logging = no
timeout = 60
refuse options = checksum dry-run
dont compress = *.gz *.tgz *.zip *.z *.rpm *.deb *.iso *.bz2 *.tbz

[ems-wp]
path = /var/ems-data/WP
use chroot = no
max connections = 2
lock file = /var/lock/rsyncd.ems-wp
read only = no
list = no
uid = root
auth users = backup
secrets file = /etc/rsyncd.secrets
strict modes = yes
hosts allow = <ip_адрес_другого_сервера> <virtual_ip>
ignore errors = no
ignore nonreadable = yes
transfer logging = no
timeout = 60
refuse options = checksum dry-run
dont compress = *.gz *.tgz *.zip *.z *.rpm *.deb *.iso *.bz2 *.tbz

[radius-nbi-certs]
path = /var/lib/eltex-radius-nbi
use chroot = no
max connections = 2
lock file = /var/lock/rsyncd.radius
read only = no
list = no
uid = root
auth users = backup
secrets file = /etc/rsyncd.secrets
strict modes = yes
hosts allow = <ip_адрес_другого_сервера> <virtual_ip>
ignore errors = no
ignore nonreadable = yes
transfer logging = no
timeout = 60
refuse options = checksum dry-run
dont compress = *.gz *.tgz *.zip *.z *.rpm *.deb *.iso *.bz2 *.tbz

[radius-certs]
path = /etc/eltex-radius/certs
use chroot = no
max connections = 2
lock file = /var/lock/rsyncd.radius
read only = no
list = no
uid = root
auth users = backup
secrets file = /etc/rsyncd.secrets
strict modes = yes
hosts allow = <ip_адрес_другого_сервера> <virtual_ip>
ignore errors = no
ignore nonreadable = yes
transfer logging = no
timeout = 60
refuse options = checksum dry-run
dont compress = *.gz *.tgz *.zip *.z *.rpm *.deb *.iso *.bz2 *.tbz

Для аутентификации, необходимо настроить пользователя 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

Способ запуска/остановки

Для запуска сервиса используется команда:

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)

#!/bin/bash

LOCKFILE="/run/lock/rsync_ems_backup"

# IP address backup server
HOST=<ip_адрес_другого_сервера>
# Check if we're root
if [ `whoami` != "root" ]
    then
	echo "This script should be run by root."
	exit 1
fi

# Check and create lock file
if ! lockfile-create --use-pid -r 0 $LOCKFILE &> /dev/null ; then
    echo "Backup is already running"
    exit 0
fi

# Check - if we're master - try to perform backup to slave
SRVMODE=`cat /tmp/keep.mode`
if [ "$SRVMODE" == "MASTER" ]
    then
	rsync -urlogtp --delete-after --password-file=/etc/rsync_client.secrets /usr/lib/eltex-ems/conf/ backup@$HOST::ems-conf > /tmp/rsync_ems_conf.log 2>&1
	echo $? >> /tmp/rsync_ems_conf_result.log
	rsync -urlogtp --delete-after --password-file=/etc/rsync_client.secrets /tftpboot/ backup@$HOST::ems-tftp > /tmp/rsync_ems_tftpboot.log 2>&1
	echo $? >> /tmp/rsync_ems_tftpboot_result.log
    rsync -urlogtp --delete-after --password-file=/etc/rsync_client.secrets /var/ems-data/WP/ backup@$HOST::ems-wp > /tmp/rsync_ems_wp.log 2>&1
    echo $? >> /tmp/rsync_ems_wp_result.log
else
	echo "Not master. No action will be performed."
fi

lockfile-remove $LOCKFILE

Конфигурация скрипта для  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.
Поэтому при переходе мастерства вторая нода не будет ничего знать о клиентских сертификатах.

Чтобы это исправить нужно:

1. выбираем ноду, которая будет владеть актуальными данными, например первую ноду

2. Добавить ip-адрес второго хоста в переменную окружения 

   echo "export SLAVE_HOST="YOUR_IP"" | sudo tee /etc/environment && source /etc/environment

3.  /usr/lib/eltex-radius-nbi/rsync_radius_cert_synchronization.sh

   #!/bin/bash
   # You mustn't change this script. After new installation it will be replaced.
   
   LOCKFILE="/run/lock/rsync_radius_cert_synchronization"
   
   # IP address server for synchronization.
   # Please before all define SLAVE_HOST for your environment.
   SLAVE_HOST=${SLAVE_HOST:-SLAVE_HOST_DEFAULT}
   # Check if we're root
   if [ `whoami` != "root" ]
       then
       echo "This script should be run by root."
       exit 1
   fi
   
   # Check and create lock file
   if ! lockfile-create --use-pid -r 0 $LOCKFILE &> /dev/null ; then
       echo "Backup is already running"
       exit 0
   fi
   
   # Check - if we're master - try to perform backup to slave
   SRVMODE=`cat /tmp/keep.mode`
   if [ "$SRVMODE" == "MASTER" ]
       then
       rsync -urlogtp --password-file=/etc/rsync_client.secrets /var/lib/eltex-radius-nbi/ backup@$SLAVE_HOST::radius-nbi-certs > /tmp/rsync_radius_nbi_certs.log 2>&1
       echo $? >> /tmp/rsync_radius_nbi_certs.log
       rsync -urlogtp --password-file=/etc/rsync_client.secrets /etc/eltex-radius/certs/ backup@$SLAVE_HOST::radius-certs > /tmp/rsync_radius_certs.log 2>&1
       echo $? >> /tmp/rsync_radius_certs.log
   else
       echo "Not master. No action will be performed."
   fi
   
   lockfile-remove $LOCKFILE

4.  Запустить команды с выбранной вами ноды в статусе "MASTER"

   rsync -rlogtp --delete-after --password-file=/etc/rsync_client.secrets /var/lib/eltex-radius-nbi/ backup@$SLAVE_HOST::radius-nbi-certs > /tmp/rsync_radius_nbi_certs.log 2>&1
   rsync -rlogtp --delete-after --password-file=/etc/rsync_client.secrets /etc/eltex-radius/certs/ backup@$SLAVE_HOST::radius-certs > /tmp/rsync_radius_certs.log 2>&1

   эти команды синхронизируют данные с вашей второстепенной нодой

5.  убедитесь, что файлы в директориях /var/lib/eltex-radius-nbi/ и /etc/eltex-radius/certs/ совпадают
6.  выполнить команду на двух нодах

   systemctl restart eltex-radius.service

Настройка 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)

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 и приводим его к виду (тестовый стенд):

#file proxysql.cfg

########################################################################################
# This config file is parsed using libconfig , and its grammar is described in:
# http://www.hyperrealm.com/libconfig/libconfig_manual.html#Configuration-File-Grammar
# Grammar is also copied at the end of this file
########################################################################################

########################################################################################
# IMPORTANT INFORMATION REGARDING THIS CONFIGURATION FILE:
########################################################################################
# On startup, ProxySQL reads its config file (if present) to determine its datadir.
# What happens next depends on if the database file (disk) is present in the defined
# datadir (i.e. "/var/lib/proxysql/proxysql.db").
#
# If the database file is found, ProxySQL initializes its in-memory configuration from
# the persisted on-disk database. So, disk configuration gets loaded into memory and
# then propagated towards the runtime configuration.
#
# If the database file is not found and a config file exists, the config file is parsed
# and its content is loaded into the in-memory database, to then be both saved on-disk
# database and loaded at runtime.
#
# IMPORTANT: If a database file is found, the config file is NOT parsed. In this case
#            ProxySQL initializes its in-memory configuration from the persisted on-disk
#            database ONLY. In other words, the configuration found in the proxysql.cnf
#            file is only used to initial the on-disk database read on the first startup.
#
# In order to FORCE a re-initialise of the on-disk database from the configuration file
# the ProxySQL service should be started with "systemctl start proxysql-initial".
#
########################################################################################

datadir="/var/lib/proxysql"
errorlog="/var/log/proxysql/proxysql.log"

admin_variables=
{
	admin_credentials="admin:admin"
#	mysql_ifaces="127.0.0.1:6032;/tmp/proxysql_admin.sock"
	mysql_ifaces="0.0.0.0:6032" # порт для подключения к БД
#	refresh_interval=2000
#	debug=true
}

mysql_variables=
{
	threads=4
	max_connections=2048
	default_query_delay=0
	default_query_timeout=36000000
	have_compress=true
	poll_timeout=2000
#	interfaces="0.0.0.0:6033;/tmp/proxysql.sock"
	interfaces="0.0.0.0:6033" #порт для взаимодействия proxysql с сервисами выставили 6033 (стандартный порт MySQL)
    default_schema="information_schema"
	stacksize=1048576
	server_version="5.5.30"
	connect_timeout_server=3000
# make sure to configure monitor username and password
# https://github.com/sysown/proxysql/wiki/Global-variables#mysql-monitor_username-mysql-monitor_password
	monitor_username="monitor"
	monitor_password="monitor"
	monitor_history=600000
	monitor_connect_interval=60000
	monitor_ping_interval=10000
	monitor_read_only_interval=1500
	monitor_read_only_timeout=500
	ping_interval_server_msec=120000
	ping_timeout_server=500
	commands_stats=true
	sessions_sort=true
	connect_retries_on_failure=10
}


# defines all the MySQL servers
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
    }
)


# defines all the MySQL users
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
	}
)



#defines MySQL Query Rules
mysql_query_rules:
(
#	{
#		rule_id=1
#		active=1
#		match_pattern="^SELECT .* FOR UPDATE$"
#		destination_hostgroup=0
#		apply=1
#	},
#	{
#		rule_id=2
#		active=1
#		match_pattern="^SELECT"
#		destination_hostgroup=1
#		apply=1
#	}
)

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"
  }
)


mysql_replication_hostgroups=
(
        {
                writer_hostgroup=1
                reader_hostgroup=2
                comment="SWLC REPLICA"
       }
)

Основные настройки.

Исправляем вывод файла логов на более обычную директорию:

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

Подключение к административной консоли (используются дефолтные настройки /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

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

• http://<ip_server1>:7070/cluster
• http://<ip_server2>:7070/cluster

{
  "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 настроить взаимодействие со всеми нодами кластера используя их реальный адрес.