Общие сведения
Резервирование контроллеров SoftWLC выполняется по схеме master-slave. Синхронизируются критичные для работы системы файлы (настройки, файлы прошивок, выгрузки данных), баз данных MySQL (в режиме master-master), баз дынных MongoDB, а также работа DHCP серверов. Такая схема обеспечивает доступность услуги и актуальные данные на обоих контроллерах при выходе одного из строя, недоступности сети, проблем с электропитанием.
В примерах конфигурации в данном разделе для простоты ip-адреса будут указываться как <ip_server1>, <ip_server2> и <virtual_ip>, где:
- <ip_server1> - реальный ip-адрес первого сервер
- <ip_server2> - реальный ip-адрес второго сервера
- <virtual_ip> - виртуальный ip-адрес
Настройка резервирования контроллеров SoftWLC состоит из следующих этапов:
- установка и настройка keepalived
- настройка rsync
- настройка репликации MySQL
- настройка replicaSet MongoDB
- настройка работы Eltex-PCRF в режиме кластера
- изменение конфигурации модулей системы для работы с виртуальным IP
Установка и настройка keepalived
в отдельной доке
Основной компонент резервирования контроллеров. Определяет за переход мастерства и обнаружение проблем в работе сети. Для установки keepalived необходимо обратиться в Сервисный центр Wi-Fi за актуальным дистрибутивом.
Настройка rsync
Rsync в схеме резервирования отвечает за синхронизацию служебных служебных файлов сервисов Eltex-EMS и Eltex-APB, а также файлов прошивок, шаблонов конфигурации, выгрузок конфигураций точек. Rsync представляет собой клиент серверное ПО. В данной схеме master-сервер выступает в роли клиента и синхронизирует каталоги slave-сервера с локальными.
Способ запуска/остановки
Для активации сервера rsync необходимо в файле /etc/default/rsync
установить значение:
RSYNC_ENABLE=true
Для запуска сервиса после остановки используется команда:
root@swlc01-server:/# service rsync start
Для остановки сервиса используется команда:
root@swlc01-server:/# service rsync stop
Для проверки — запущен ли сервис в данный момент, используется команда:
root@swlc01-server:/# service rsync status
В ответ последует сообщение:
* rsync is running
в случае если сервис запущен,или
* rsync is not running
в случае если сервис не запущен.
Конфигурация сервера rsync
Основной конфигурационный файл сервера rsync расположен в /etc/rsyncd.conf Листинг файла приведен ниже.
[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_server1> <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_server1> <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 = 10.62.8.121 10.62.8.122 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
Параметры hosts allow
указаны для master сервера. Рекомендуется указать в виде
hosts allow = <ip_другого_сервера> <virtual ip>
Для аутентификации необходимо настроить пользователя rsync
на обоих серверах, для этого на каждом сервере создайте файлы /etc/rsyncd.secrets
, в которых указать логин и пароль.
backup:rspasswd
Назначить права доступа к файлам, выполнив на обоих серверах:
root@swlc01-server:/# chmod 600 /etc/rsyncd.secrets
Настройка запуска синхронизации
Создайте файлы /etc/rsync_client.secrets
, в которых укажите пароль:
root@swlc01-server:/# echo "rspasswd" > /etc/rsync_client.secrets && chmod 600 /etc/rsync_client.secrets
Операцию синхронизации файлов осуществляет задача cron, в которой выполняется скрипт /usr/lib/eltex-ems/scripts/rsync_ems_backup.sh
. Скрипт запускает rsync клиент и синхронизирует локальные директории с директориями на втором (backup) сервере. Синхронизация запускается только в случае, если сервер в состоянии master.
#!/bin/bash LOCKFILE="/run/lock/rsync_ems_backup" # IP address backup server HOST=<ip_server2> # 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
где
backup
– логин, указанный в файле /etc/rsyncd.secretsHOST -
ip-адрес другого сервера
Cоздать задачу в cron на обоих серверах для запуска синхронизации раз в минуту:
root@swlc01-server:/# crontab -l | { cat; echo "*/1 * * * * /usr/lib/eltex-ems/scripts/rsync_ems_backup.sh"; } | crontab
Настройка репликации MySQL
Резервирование данных, хранящихся СУБД MySQL, осуществляется путём встречной репликации по принципу master-master (ведущий-ведущий). То есть, каждый из серверов одновременно является и master и slave. При такой схеме работы все изменения в БД на одном сервере записываются в специальный бинарный лог, который в реальном времени вычитывает второй сервер и применяет изменения. Второй сервер реплицирует данные с первого, а первый со второго. (http://dev.mysql.com/doc/refman/5.5/en/replication.html). Это позволяет получить актуальную копию БД на двух хостах одновременно. При разрыве связи изменения накапливаются, после восстановления происходит синхронизация.
Перенос дампа данных и перенос на второй сервер
При настройке резервирования в процессе эксплуатации (то есть если в MySQL на действующем сервере уже имеются данные) необходимо перенести эти данные на второй сервер. Это можно сделать при помощи утилиты mysqldump.
Для для этого необходимо заблокировать таблицы, снять дамп, разблокировать таблицы и скопировать получившийся файл на второй сервер:
root@swlc01-server:/# mysql -uroot -proot -e "FLUSH TABLES WITH READ LOCK;" root@swlc01-server:/# mysqldump -uroot -proot --databases ELTEX_PORTAL eltex_alert eltex_auth_service eltex_ems payments radius wireless > mysqldump_master.sql root@swlc01-server:/# mysql -uroot -proot -e "UNLOCK TABLES;" root@swlc01-server:/# scp mysqldump_master.sql <username>@<ip_server2>:/home/<username>/
Затем развернуть dump на втором сервере:
root@swlc01-server:/# mysql -uroot -proot < /home/<username>/mysqldump_master.sql
Конфигурация MySQL
Конфигурация самого демона mysqld заключается в настройке параметров ведения бинарных логов. Обозначения первый сервер и второй сервер далее условны, и применяются лишь для обозначения различий в конфигурации сереров.
В секции [mysqld]
файла конфигурации /etc/mysql/my.cnf
произвести следующие изменения:
Закомментировать либо удалить строку на обоих серерах:
bind-address = 127.0.0.1
Указать server-id
. Для серверов необходимо задать уникальные идентификаторы, к примеру, для первого:
server-id = 1
для второго:
server-id = 2
Включить бинарные логи на обоих серверах:
log_bin = /var/log/mysql/mysql-bin.log
указать параметры auto_increment_increment (шаг приращения) и auto_increment_offset (стартовую точку).
Для первого сервера:
auto_increment_increment= 2 auto_increment_offset = 1
Для второго сервера:
auto_increment_increment= 2 auto_increment_offset = 2
На обоих серверах:
- указать базы, для которых будут вестись логи:
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 = payments
- yказать базы, для которых не будут вестись логи:
binlog-ignore-db = mysql binlog-ignore-db = Syslog binlog-ignore-db = performance_schema binlog-ignore-db = information_schema
Перезапустить сервис mysql
на каждом сервер и создать БД для репликации.
root@swlc01-server:/# service mysql restart
Создание учетных записей
Для работы репликации необходима служебная учетная запись на каждом из серверов. Под этой учетной записью сервер будет подключаться к master серверу и получать изменения в данных.
Создать учетную запись для репликации на первом сервере:
GRANT SELECT, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'replication'@'<ip_server2>' IDENTIFIED BY 'password'; FLUSH PRIVILEGES;
Создать учетную запись для репликации на втором сервере:
GRANT SELECT, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'replication'@'<ip_server1>' IDENTIFIED BY 'password'; FLUSH PRIVILEGES;
Включение репликации
Запуск репликации на втором сервере
На первом сервере в консоли MySQL выполнить команду show master status и проанализировать полученные значения:
mysql> show master status \G *************************** 1. row *************************** File: mysql-bin.000001 Position: 00000107 Binlog_Do_DB: eltex_alert,eltex_ems,radius,wireless,eltex_auth_service,payments,ELTEX_PORTAL Binlog_Ignore_DB: mysql,Syslog,performance_schema,information_schema 1 row in set (0.00 sec)
Запомнить параметры File и Position.
Рекомендуется устанавливать Position равным 107. Это позиция с которой начинается запись лог-файла.
Настроить и запустить репликацию второго сервера с первого (выполнить действия на втором сервере):
mysql> STOP SLAVE; mysql> CHANGE MASTER TO MASTER_HOST='<ip_server1>', MASTER_USER='replication', MASTER_PASSWORD='password', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=107; mysql> START SLAVE;
где,
- MASTER_LOG_FILE='mysql-bin.000001' – указать значение File, полученное на первом сервере.
- MASTER_LOG_POS=107 – указать значение Position, полученное в предыдущем пункте (при первичной настройке рекомендуется указать 107).
Проверить состояние репликации на втором сервере:
mysql> show slave status \G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: <ip_server1> Master_User: replication Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000001 Read_Master_Log_Pos: 107 Relay_Log_File: mysqld-relay-bin.000001 Relay_Log_Pos: 107 Relay_Master_Log_File: mysql-bin.000001 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: 107 Relay_Log_Space: 107 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: 2 1 row in set (0.00 sec)
Если параметры Slave_IO_Running
и Slave_SQL_Running
имеют значение «Yes»
, репликация успешно запустилась.
Запуск репликации на первом сервере
На втором сервере выполнить:
show master status \G mysql> show master status \G *************************** 1. row *************************** File: mysql-bin.000001 Position: 00000107 Binlog_Do_DB: eltex_alert,eltex_ems,eltex_ont,radius,wireless,eltex_auth_service,payments,ELTEX_PORTAL Binlog_Ignore_DB: mysql,Syslog,performance_schema,information_schema 1 row in set (0.00 sec)
Настроить и запустить репликацию первого сервера со второго (выполнять действия на первом сервере):
CHANGE MASTER TO MASTER_HOST='<ip_server2>', MASTER_USER='replication', MASTER_PASSWORD='password', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=107; START SLAVE;
Проверить состояние репликации на первом севере:
mysql> show slave status \G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: <ip_server2> Master_User: replication Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000001 Read_Master_Log_Pos: 107 Relay_Log_File: mysqld-relay-bin.000001 Relay_Log_Pos: 107 Relay_Master_Log_File: mysql-bin.000001 Slave_IO_Running: Yes Slave_SQL_Running: Yes ...
пример вывода сознащен ввиду того, что остальные данные не так важны
Если параметры Slave_IO_Running
и Slave_SQL_Running
имеют значение «Yes»
, значения Master_Log_File
и Read_Master_Log_Pos
репликация выполняется в обе стороны.
Проверка репликации из EMS-GUI
Состояние репликации MySQL можно контролировать из GUI EMS. Для этого необходимо отредактировать конфигурационный файл /etc/eltex-ems/check-ems-replication.conf
. Изменения необходимо внести на обоих серверах.
# Включить("Yes") / Выключить("No") проверку репликации ENABLE_REPLICATION="Yes" # Адрес первого хоста репликации HOST1=<ip_server1> # Адрес второго хоста репликации HOST2=<ip_server2> # параметры доступа к mysql серверу # mysql пользователь USER="replication" # mysql пароль PASSWORD="password"
где,
- ENABLE_REPLICATION - включена ли проверка репликации (установить в "Yes")
HOST1, HOST2
- ip-адреса серверовUSER, PASSWORD
- логин/пароль учетной записи, для работы репликации.
После сохранения изменений, состояние репликации можно отслеживать в GUI EMS в разделе Информация → Состояние системы резервирования → MySQL.
Здесь представлены результаты проверки состояния репликации на обоих серверах и краткое резюме по результатам проверки.
Настройка MongoDB
В MongoDB репликация осуществляется объединением нескольких (в типовой конфигурации - 3) узлов в Replica Set. Replica Set состоит из одного primary узла и нескольких secondary (подробнее https://docs.mongodb.com/v2.4/administration/replica-sets/).
Все операции по изменению данных выполняются только на primary. При этом MongoDB автоматически выполняет failover и смену primary на живой узел, если текущий primary выйдет из строя. Но это требует 3+ узлов в replica set.
Настройка replicaSet
В /etc/hosts на всех узлах необходимо добавить ноды по типу <IP_address> <hostname>
В /etc/mongod.conf
на всех узлах:
Добавить/раскомментировать блок
replication: replSetName: "<replica_set_name>"
где <replica_set_name>
имя replica set, выбирается произвольно, но должно быть одинаково на обоих серверах
Изменить строку
bind_ip = 0.0.0.0
Перезапустить MongoDB
root@swlc01-server:/# service mongod restart
На первом узле зайти в консоль MongoDB
root@swlc01-server:/# mongo
Создать конфигурацию replica set
> rs.initiate()
Через некоторое время, приглашение shell должно смениться на такое:
replica_set_name:PRIMARY>
Если в сети не используется DNS обязательно проверить, правильно ли добавился первый узел в конфигурацию Replica Set:
replica_set_name:PRIMARY> rs.config() { "_id" : "relica_set_name", "version" : 63243, "members" : [ { "_id" : 0, "host" : "<hostname_server1>:27017" } ] }
Для корректировки адреса сервера выполнить следующее:
replica_set_name:PRIMARY> conf = rs.conf() replica_set_name:PRIMARY> conf.members[<индекс>].host = "<ip_server1>:27017" replica_set_name:PRIMARY> rs.reconfig(conf)
И снова проверить текущую конфигурацию:
replica_set_name:PRIMARY> rs.config() { "_id" : "relica_set_name", "version" : 63243, "members" : [ { "_id" : 0, "host" : "<ip_server1>:27017" } ] }
Параметр "host"
должен содержать ip-адрес этого сервера.
Добавить в Replica Set второй узел (выполнять на первом сервере):
replica_set_name:PRIMARY> rs.add("<ip_server2>:27017") { "ok" : 1 }
Если MongoDB отвечает на эту команду ошибкой, возможно, нет связи со вторым узлом (или там прописан bind_ip = 127.0.0.1
), или там не настроен блок replication. Правильный ответ должен быть таким.
На втором узле приглашение консоли управления MongoDB должно смениться на:
root@swlc01-server:/# mongo replica_set_name:SECONDARY>
То же самое выполнить для остальных узлов.
Проверить состояние Replica Set можно выполнив в консоли MongoDB команду rs.status()
Работа 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 командой
root@swlc01-server:/# service eltex-pcrf restart
Проверка состояния кластера
{ "data" : { "enabled" : true, "state" : "ACTIVE", "members" : [ { "address" : "ip_server1", "local" : true, "active" : true }, { "address" : "ip_server2", "local" : false, "active" : true } ], "messagesStats" : { "received" : 45157, "sent" : 45144 }, "mongo" : { "available" : false, "error" : "not running with --replSet" } }, "key" : "PcrfErrorCode.success", "message" : "Success", "code" : 0, "args" : [ ] }
Настройка модулей SoftWLC
Необходимо настроить модули SoftWLC на работу с контроллером по virtual ip на обоих серверах. Изменения необходимо внести в приведенные ниже конфигурационные файлы. В целях
- Изменить
localhost
на<virtual_ip>
в строке 2.
- Изменить
localhost
на<virtualip>
Изменить localhost
на <virtualip>
в строках 9, 36.
Изменить localhost
на <virtualip>
в строке 18.
- Изменить
localhost
на<virtualip>
- Изменить
127.0.0.1
на<virtualip>
- Изменить
localhost
на<virtualip>
- Изменить
localhost
на<virtualip>
- Изменить
127.0.0.1
на<virtualip>
- Изменить
localhost
на<virtualip>
Изменить localhost
на <virtualip>
в строках 4, 17, 26, 35, 48, 57, 66, 75, 84, 98
Смена настроек в GUI
Также нужно настроить модули SoftWLC при помощи графического интерфейса.
Личный кабинет Wi-Fi
В разделе Настройки → Интеграция в параметрах PCRF URL и URL NGW-клиента изменить localhost на виртуальный ip-адрес:
Конструктор порталов
Изменить localhost на виртуальный ip-адрес в разделах настроек:
Системные настройки → Конструктор порталов
Системные настройки → Доступ к NBI
Системные настройки → Доступ к NGW
Системные настройки → БД платежей
Системные настройки → Доступ к PCRF
EMS-GUI
В графическом интерфейсе сервера EMS изменить localhost (либо 127.0.0.1) на виртуальный ip-адрес в следующих разделах:
Администрирование → Настройка сервера → Системные модули → pcrf
Администрирование → Настройка сервера → Системные модули → radius
Администрирование → Настройка сервера → Системные модули → softwlc.nbi
Администрирование → Настройка сервера → Системные модули → system
Администрирование → Настройка сервера → Системные модули → tftpserver