Общие сведения
Резервирование контроллеров SoftWLC необходимо для синхронизации критичных для работы системы файлов (настройки, файлы прошивок, выгрузки данных), баз данных MySQL, баз данных MongoDB, а также DHCP серверов. Такая схема обеспечивает доступность услуг и и актуальные данные на обоих контроллерах при выходе одного из строя, недоступности сети, проблем с электропитанием.
Настройка резервирования контроллеров SoftWLC состоит из следующих этапов:
- установка и настройка keepalived (выполняется по схеме master-slave)
- настройка rsync
- настройка репликации MySQL (осуществляется путём встречной репликации по принципу master-master)
- настройка replicaSet MongoDB (репликация осуществляется объединением 3 узлов в Replica Set)
- настройка работы Eltex-PCRF в режиме кластера
- изменение конфигурации модулей системы для работы с виртуальным IP
В примерах конфигурации в данном разделе для простоты ip-адреса будут указываться как <ip_server1>, <ip_server2> и <virtual_ip>, где:
- <ip_server1> - реальный ip-адрес первого сервера
- <ip_server2> - реальный ip-адрес второго сервера
- <virtual_ip> - виртуальный ip-адрес
Для корректной работы требуется обеспечить L2 связность между двумя удаленными серверами.
Установка и настройка keepalived
Описание пакета
Пакет keepalived - это open source программное обеспечение, предназначенное для обеспечения функций высокой надежности (high availabilitty) и балансировки нагрузки (load-balancing). За первую функцию отвечает реализация протокола VRRP, а вторая основывается на модуле ядра Linux Vitrual Server (IPVS). Keepalived не разрабатывается сотрудниками Eltex и не включает доработок, за исключением конфигурации. Keepalived используется для организации резервирования контроллеров SoftWLC, при этом используется только функционал VRRP.
Установка keepalived
Для установки пакета, необходимо загрузить его на сервер и выполнить следующую команду (установка должна производиться от имени суперпользователя root на обоих серверах):
admin@ubuntu:/# sudo apt update admin@ubuntu:/# sudo apt install keepalived
После установки, необходимо добавить демона Keepalived в автозагрузку и запустить его:
admin@ubuntu:/# sudo systemctl enable keepalived admin@ubuntu:/# 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).
Скрипт смены мастера replicaSet MongoDB.
Для того, чтобы скрипты работали корректно, необходимо назначить права на их исполнение:
admin@swlc01-server:/# sudo chmod +x /etc/keepalived/check_ping.sh admin@swlc01-server:/# sudo chmod +x /etc/keepalived/keep_notify.sh admin@swlc01-server:/# sudo chmod +x /etc/keepalived/mongo_switch.js
Выделение лога в отдельный файл
По умолчанию keepalived записывает лог в файл /var/log/syslog . Для удобства отладки, мониторинга и контроля работы keepalived, можно настроить ведение собственного, отдельного лог-файла.
Ниже приведен пример настройки rsyslog:
nano -w /etc/rsyslog.d/10-keepalived.conf if $programname contains 'Keepalived' then /var/log/keepalived.log if $programname contains 'Keepalived' then ~
Затем, нужно перезапустить rsyslog командой:
admin@swlc01-server:/#sudo service rsyslog restart
Теперь сообщения от демона keepalived попадут только в лог-файл /var/log/keepalived.log и не попадут в /var/log/syslog .
Способ запуска/остановки keepalived
Для запуска сервиса воспользуйтесь командой:
admin@master:/#sudo service keepalived start
Остановка сервиса:
admin@master:/#sudo service keepalived stop
Проверить состояние сервиса можно командой:
admin@master:/#sudo service keepalived status
На одном из серверов, при корректной настройке, должен отображаться интерфейс с виртуальным ip.
Для проверки работы сервиса keepalived, отключите сервер, у которого в интерфейсах присутствует virtual_ip. Virtual_ip должен появиться на втором сервере.
Настройка rsync
Rsync в схеме резервирования отвечает за синхронизацию служебных файлов, сервисов Eltex-EMS и Eltex-APB, а также файлов прошивок, шаблонов конфигурации, выгрузок конфигураций точек. Rsync представляет собой клиент серверное ПО. В данной схеме master-сервер выступает в роли клиента и синхронизирует каталоги slave-сервера с локальными.
Конфигурация сервера rsync
Для активации сервера rsync, необходимо на каждом сервере в файле /etc/default/rsync установить значение:
RSYNC_ENABLE=true
Создать файл /etc/rsyncd.conf. Листинг файла приведен ниже.
hosts allow = <ip_другого_сервера> <virtual ip>
Для аутентификации, необходимо настроить пользователя rsync, для этого, на каждом сервере создайте файлы /etc/rsyncd.secrets, в которых необходимо указать пароль.
backup:rspasswd
Назначить права доступа к файлам, выполнив на обоих серверах:
admin@swlc01-server:/#sudo chmod 600 /etc/rsyncd.secrets
Настройка запуска синхронизации
Создайте файлы /etc/rsync_client.secrets, в которых укажите пароль:
admin@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.
В 6 строке заменить HOST на ip-адрес другого сервера (Пример: HOST=100.111.195.201)
Cоздать задачу в cron на обоих серверах, для запуска синхронизации раз в минуту:
root@swlc01-server:/# crontab -l | { cat; echo "*/1 * * * * /usr/lib/eltex-ems/scripts/rsync_ems_backup.sh"; } | crontab
Проверяем список задач:
root@swlc01-server:/# crontab -l root@swlc01-server:/# */1 * * * * /usr/lib/eltex-ems/scripts/rsync_ems_backup.sh
Если задача не добавилась или случайно добавилась несколько раз - редактируем список вручную:
root@swlc01-server:/# 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 # выбираем в каком редакторе открыть
Способ запуска/остановки
Для запуска сервиса используется команда:
admin@swlc01-server:/# sudo service rsync start
Для остановки сервиса используется команда:
admin@swlc01-server:/# sudo service rsync stop
Для проверки — запущен ли сервис в данный момент, используется команда:
admin@swlc01-server:/# sudo service rsync status
Проверить работу rsync можно в EMS. Во вкладке "Информация"-Состояние системы резервирования-Rsync service.
На обоих серверах должна быть запись такого типа:
OK. Успешная синхронизация файлов из директории: /usr/lib/eltex-ems/conf/* OK. Успешная синхронизация файлов из директории: /tftpboot/* OK. Успешная синхронизация файлов из директории: /var/ems-data/WP/*
Настройка репликации MySQL
Резервирование данных, хранящихся СУБД MySQL, осуществляется путём встречной репликации по принципу master-master (ведущий-ведущий). То есть, каждый из серверов одновременно является и master и slave. При такой схеме работы, все изменения в БД на одном сервере записываются в специальный бинарный лог, который в реальном времени вычитывает второй сервер и применяет изменения. Второй сервер реплицирует данные с первого, а первый со второго. Это позволяет получить актуальную копию БД на двух хостах одновременно. При разрыве связи, изменения накапливаются, после восстановления происходит синхронизация.
Перенос дампа данных и перенос на второй сервер
При настройке резервирования в процессе эксплуатации (то есть если в 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 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/mysql.conf.d/mysqld.cnf произвести следующие изменения:
В файл /etc/mysql/my.cnf добавить путь к файлу /etc/mysql/mysql.conf.d/
Закомментировать либо удалить строку на обоих серверах:
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 = eltex_doors binlog-do-db = eltex_ngw
yказать базы, для которых не будут вестись логи:
binlog-ignore-db = mysql binlog-ignore-db = Syslog binlog-ignore-db = performance_schema binlog-ignore-db = information_schema
Перезапустить сервис mysql на каждом сервер и создать БД для репликации:
admin@swlc01-server:/# 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'@'%'; 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,wireless,radius,eltex_auth_service,ELTEX_PORTAL,eltex_doors,eltex_ngw Binlog_Ignore_DB: mysql,Syslog,performance_schema,information_schema 1 row in set (0.00 sec)
Запомнить параметры File и Position.
Настроить и запустить репликацию второго сервера с первого (выполнить действия на втором сервере):
STOP SLAVE; CHANGE MASTER TO MASTER_HOST='<ip_server1>', MASTER_USER='replication', MASTER_PASSWORD='password', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=107; START SLAVE;
где,
MASTER_LOG_FILE='mysql-bin.000001' – указать значение File, полученное на первом сервере;
MASTER_LOG_POS=107 – указать значение Position, полученное на первом сервере.
Проверить состояние репликации на втором сервере:
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», репликация успешно запустилась.
Запуск репликации на первом сервере
На втором сервере выполнить:
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)
Настроить и запустить репликацию первого сервера со второго (выполнять действия на первом сервере):
STOP SLAVE; 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 - логин/пароль учетной записи, для работы репликации.
Настройка MongoDB
В MongoDB репликация осуществляется объединением нескольких (в типовой конфигурации - 3) узлов в Replica Set. Replica Set состоит из одного primary узла и нескольких secondary. Для упрощения предлагаем схему:
- Primary — основной сервер mongoDB.
- Secondary — точные копии баз(ы) данных с real-time синхронизацией.
- Arbiter — сервер отвечает только за выборы преемника, сам стать преемником он не может, поэтому рекомендуется отдавать под арбитра минимальные ресурсы, SoftWLC на аrbiter устанавливать не требуется.
Минимальные характеристики для mongo-db arbiter:
- vCore: 1, 64-bit x86 CPUs
- vRAM: 2 ГБ
- vHDD: 20Гб
Примечание
Все операции по изменению данных выполняются только на primary. При этом MongoDB автоматически выполняет failover и смену primary на живой узел, если текущий primary выйдет из строя. Но это требует 3+ узлов в replica set.
Установка mongodb на arbiter
При настройке репликации, необходимо, чтобы версии MongoDB совпадали на всех хостах, при обычной установке mongo , устанавливается версия 3.6.3, в нашем случае требуется актуальный патч 4 версии mongodb.
Для установки нужной версии mongodb, выполните следующие действия:
Создайте файл /etc/apt/sources.list.d/mongodb-org-4.0.list и пропишите в него репо mongo
deb [ arch=amd64 ] http://mirror.yandex.ru/mirrors/repo.mongodb.org/apt/ubuntu bionic/mongodb-org/4.0 multiverse
Выполните на сервере команду
sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 9DA31620334BD75D9DCB49F368818C72E52529D4
Скачайте mongodb-org
sudo apt-get update sudo apt install mongodb-org
Проверьте, что на сервер установлена mongodb версии не ниже 4.0.28
mongo --version или dpkg -l | grep mongo
Выполните следующие команды:
sudo systemctl enable mongod.service sudo systemctl start mongod.service
Настройка replicaSet
В /etc/mongod.conf на всех узлах:
Добавить/раскомментировать блок:
replication: replSetName: "<replica_set_name>"
где <replica_set_name> - имя replica set, выбирается произвольно, но должно быть одинаково на всех серверах.
Разрешить внешние подключения, прописав в параметре bindIp (bind_ip в старой версии mongo) адрес 0.0.0.0 (0.0.0.0 - разрешает подключения с любых ip адресов):
bindIp: 0.0.0.0
Перезапустить MongoDB:
root@swlc01-server:/# service mongod restart
На первом узле зайти в консоль MongoDB:
root@swlc01-server:/# mongo
Создать конфигурацию replica set:
rs.initiate( { _id: "replica_set_name", version: 1, members: [ { _id: 0, host : "ip_mongo_primary:27017" }, { _id: 1, host : "ip_mongo_secondary:27017" } ] } )
Добавить в Replica Set узел Arbiter (на PRIMARY):
rs.add("<ip_server>:27017",true)
Через некоторое время, приглашение shell должно смениться на такое:
replica_set_name:PRIMARY>
Посмотреть конфигурацию Replica Set можно командой:
replica_set_name:PRIMARY> rs.config()
Для проверки состояния Replica Set, выполните в консоли MongoDB команду rs.status().
Добавление/удаление/изменение узлов в Replica Set
Настройку узлов в Replica Set можно выполнять только на PRIMARY.
Добавить в Replica Set узел Secondary (на PRIMARY):
rs.add("<ip_server>:27017")
Если MongoDB отвечает на эту команду ошибкой, возможно, нет связи со вторым узлом (или там прописан bindIp: 127.0.0.1), или там не настроен блок replication.
На втором узле приглашение консоли управления MongoDB должно смениться на:
root@swlc01-server:/# mongo replica_set_name:SECONDARY>
Добавить в Replica Set узел Arbiter:
replica_set_name:PRIMARY> rs.add("<ip_server>:27017",true)
Удалить узел из Replica Set (выполнять на PRIMARY):
replica_set_name:PRIMARY> rs.remove("<ip_server>:27017")
Для корректировки адреса сервера выполнить следующее:
replica_set_name:PRIMARY> cfg = rs.conf() replica_set_name:PRIMARY> cfg.members[<индекс>].host = "<ip_server>:27017" replica_set_name:PRIMARY> rs.reconfig(cfg)
Работа 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 командой
admin@swlc01-server:/# 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 } ], "messagesStats" : { "received" : 45157, "sent" : 45144 }, "mongo" : { "available" : false, "error" : "not running with --replSet" } }, "key" : "PcrfErrorCode.success", "message" : "Success", "code" : 0, "args" : [ ] }
Особенности настройки ESR для взаимодействия с кластером PCRF
При использовании кластера PCRF на ESR настроить взаимодействие со всеми нодами кластера используя их реальный адрес.
Настройка модулей SoftWLC
Необходимо настроить модули SoftWLC на работу с контроллером по virtual ip на обоих серверах. Изменения необходимо внести в приведенные ниже конфигурационные файлы.
Внимание! При изменении настроек подключения к БД Mysql и MongoDB следует исключительно внимательно относится к настройкам коннектов к БД - ошибки в настройке, такие как ошибки в символах между параметрами (например "?" вместо "&"), лишние символы и т. п. приведут к сложно диагностируемым ошибкам подключения к БД!
После внесения изменений в конфигурационные файлы необходимо перезапустить соответствующий сервис:
root@swlc01-server:/# service eltex-<service_name> restart
В случае использования однохостовой системы на каждом из серверов SoftWLC, в конфигурационных файлах сервисов, обращающихся к БД MySQL заменять localhost
или 127.0.0.1
на <virtual_ip>
не требуется.
- Изменить
localhost
на<virtual_ip>
в строке 24.
- Изменить
mongodb://localhost
наmongodb://ip_mongo_primary,ip_mongo_secondary
во всех строках иуказать replicaSet
, который вы настроили в /etc/mongod.conf. Таким образом строка будет выглядеть примерно следующим образом
mongodb://192.168.10.3:27017,192.168.10.4:27017/pcrf?replicaSet=Cluster&waitQueueMultiple=500&connectTimeoutMS=10000&socketTimeoutMS=0&readPreference=secondaryPreferred mongodb://192.168.10.3:27017,192.168.10.4:27017/ott?replicaSet=Cluster&waitQueueMultiple=500&connectTimeoutMS=10000&socketTimeoutMS=0&readPreference=secondaryPreferred
- Изменить
localhost
на<virtualip>
- Изменить
127.0.0.1
на<virtualip>
- Изменить
localhost
на<virtualip>
- Изменить
localhost
на<virtualip>
- Изменить
mongodb://localhost
наmongodb://ip_mongo_primary,ip_mongo_secondary
во всех строках иуказать replicaSet
, который вы настроили в /etc/mongod.conf. Таким образом строка будет выглядеть примерно следующим образом
pcrf.mongodb.uri=mongodb://192.168.10.3:27017,192.168.10.4:27017/pcrf?replicaSet=Cluster wificab.mongodb.uri=mongodb://192.168.10.3:27017,192.168.10.4:27017/wifi-customer-cab?replicaSet=Cluster sorm2.mongodb.uri=mongodb://192.168.10.3:27017,192.168.10.4:27017/sorm2?replicaSet=Cluster ott.mongodb.uri=mongodb://192.168.10.3:27017,192.168.10.4:27017/ott?replicaSet=Cluster
- Изменить
localhost
на<virtualip>
- Изменить
127.0.0.1
на<virtualip>
- Изменить
localhost
наvirtual_ip
в строке 44.
- Изменить
localhost
на<virtualip>
- Изменить
127.0.0.1
на<virtualip>
- Изменить
mongodb://localhost
наmongodb://ip_mongo_primary,ip_mongo_secondary
указать replicaSet
, который вы настроили в /etc/mongod.conf. Таким образом строка будет выглядеть примерно следующим образом:
<entry key="mongoaddress">mongodb://192.168.10.3:27017,192.168.10.4:27017/wifi-customer-cab?replicaSet=Cluster</entry>
- Изменить
localhost
на<virtualip>
Изменить localhost
на <virtualip>
в строках 4, 17, 26, 35, 48, 57, 66, 75, 84, 98.
Добавление пользователя в таблицу NAS
Для доступа в Личный кабинет необходимо добавить соответствующие записи в таблицу NAS.
Данная таблица находится в БД eltex_auth_service и содержит адреса клиентов, имеющих право отправлять запросы на проведение авторизации пользователей. Если клиент не включен в эту таблицу, то запросы авторизации будут игнорироваться.
Для этого в личном кабинете в разделе Настройки → Серверные адреса добавить :
- <ip_server_1> - IP-адрес сервера-1
- <ip_server_2> - IP-адрес сервера-2
<virtual_ip> - Виртуальный IP-адрес
Смена настроек в GUI
Также нужно настроить модули SoftWLC при помощи графического интерфейса.
Личный кабинет Wi-Fi
В разделе Настройки → Интеграция в параметрах PCRF URL, URL NGW-клиента и URL конструктора порталов изменить localhost на виртуальный ip-адрес:
Конструктор порталов
Изменить localhost на виртуальный ip-адрес в разделах настроек:
Системные настройки → Конструктор порталов
Системные настройки → Доступ к NBI
Системные настройки → Доступ к NGW
Системные настройки → Доступ к PCRF
Системные настройки → Доступ к Mercury
EMS-GUI
В графическом интерфейсе сервера EMS изменить localhost (либо 127.0.0.1) на виртуальный ip-адрес в следующих разделах:
Администрирование → Настройка сервера → Системные модули → pcrf
Администрирование → Настройка сервера → Системные модули → radius
Администрирование → Настройка сервера → Системные модули → softwlc.nbi
Администрирование → Настройка сервера → Системные модули → system
Администрирование → Настройка сервера → Системные модули → tftpserver
Администрирование → Настройка сервера → Системные модули →wifelessCommon
Данный ключ должен совпадать с файлом /etc/eltex-wifi-cab/local_secret на каждом хосте, где установлен eltex-wifi-cab .
Если вы используете модуль netconf, то там так же необходимо актуализировать информацию
Администрирование → Настройка сервера → Системные модули → netconf