Общие сведения
Резервирование контроллеров 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 это open source программное обеспечение, предназначенное для обеспечения функций высокой надежности (high availabilitty) и балансировки нагрузки (load-balancing). За первую функцию отвечает реализация протокола VRRP, а вторая основывается на модуле ядра Linux Vitrual Server (IPVS). Keepalived не разрабатывается сотрудниками Eltex и не включает доработок, за исключением конфигурации. Keepalived используется для организации резервирования контроллеров SoftWLC, при этом используется только функционал VRRP.
Установка keepalived
Для установки пакета необходимо загрузить его на сервер и выполнить следующую команду (установка должна производиться от имени суперпользователя root):
root@master:/# apt update root@master:/# apt install keepalived
После установки необходимо добавить демона Keepalived в автозагрузку и запустить его:
root@master:/# systemctl enable keepalived root@master:/# systemctl start keepalived
Конфигурация keepalived
Конфигурация keepalived состоит из следующих файлов:
Файл | Описание |
---|---|
/etc/keepalived/keepalived.conf | главный файл конфигурации сервиса |
/etc/keepalived/check_ping.sh | скрипт проверки состояния службы EMS |
/etc/keepalived/keep_notify.sh | скрипт, который выполняется при смене состояния (при переходе в MASTER, BACKUP, FAULT) |
/etc/keepalived/mongo_switch.js | скрипт перевода члена replicaSet MongoDB в состояние, соответствующее состоянию VRRP |
Основной файл конфигурации
Листинг основного файла конфигурации по умолчанию
где
- <interface> - наименование сетевого интерфейса;
- <virtual_ip> - виртуальный ip-адрес (с указанием префикса);
- <ip_server1> - ip-адрес другого сервера;
Тест-скрипт
В текущей реализации в качестве тестового скрипта предлагается использовать следующий:
где <default_gw_ip> - шлюз по умолчанию для этого сервера.
Скрипт пингует шлюз по умолчанию и возвращает код результата. Таким образом, при успешном выполнении скрипта гарантируется, что SoftWLC достижим для внешних клиентов.
Конфигурация смены роли
При смене состояния сервера выполняется скрипт keep_notify.sh
где <mysql_user> и <mysql_password> - логин и пароль от БД MySQL.
Скрипт смены мастера replicaSet MongoDB.
Для того, чтобы скрипты работали корректно, необходимо назначить права на их исполнение:
root@swlc01-server:/# chmod +x /etc/keepalived/check_ping.sh root@swlc01-server:/# chmod +x /etc/keepalived/keep_notify.sh root@swlc01-server:/# 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 командой:
root@swlc01-server:/# service rsyslog restart
Теперь сообщения от демона keepalived попадут только в лог-файл /var/log/keepalived.log
и не попадут в /var/log/syslog
.
Способ запуска/остановки keepalived
Для запуска сервиса воспользуйтесь командой:
service keepalived start
Ответ об успешном запуске будет такой:
keepalived start/running, process 2471
Остановка сервиса:
root@master:/# service keepalived stop
Ответ системы:
keepalived stop/waiting
Проверить состояние сервиса можно командой:
root@master:/# service keepalived status
Ответ:
keepalived start/running, process 2809
Настройка rsync
Rsync в схеме резервирования отвечает за синхронизацию служебных служебных файлов сервисов Eltex-EMS и Eltex-APB, а также файлов прошивок, шаблонов конфигурации, выгрузок конфигураций точек. Rsync представляет собой клиент серверное ПО. В данной схеме master-сервер выступает в роли клиента и синхронизирует каталоги slave-сервера с локальными.
Конфигурация сервера rsync
Для активации сервера rsync необходимо в файле /etc/default/rsync
установить значение:
RSYNC_ENABLE=true
В /etc/ нужно создать конфигурационный файл rsyncd.conf
Листинг файла приведен ниже.
Параметры 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.
где
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
Проверяем список задач
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 # выбираем в каком редакторе открыть
Способ запуска/остановки
Для запуска сервиса используется команда:
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
в случае если сервис не запущен.
Настройка репликации MySQL
Резервирование данных, хранящихся СУБД MySQL, осуществляется путём встречной репликации по принципу master-master (ведущий-ведущий). То есть, каждый из серверов одновременно является и master и slave. При такой схеме работы все изменения в БД на одном сервере записываются в специальный бинарный лог, который в реальном времени вычитывает второй сервер и применяет изменения. Второй сервер реплицирует данные с первого, а первый со второго. (https://dev.mysql.com/doc/refman/5.7/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 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 произвести следующие изменения:
Закомментировать либо удалить строку на обоих серверах:
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
на каждом сервер и создать БД для репликации.
root@swlc01-server:/# 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 'username'@'%' 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,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.
Рекомендуется устанавливать Position равным 107. Это позиция с которой начинается запись лог-файла.
Настроить и запустить репликацию второго сервера с первого (выполнить действия на втором сервере):
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, полученное в предыдущем пункте (при первичной настройке рекомендуется указать 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)
Настроить и запустить репликацию первого сервера со второго (выполнять действия на первом сервере):
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
- логин/пароль учетной записи, для работы репликации.
После сохранения изменений, состояние репликации можно отслеживать в GUI EMS в разделе Информация → Состояние системы резервирования → MySQL.
Здесь представлены результаты проверки состояния репликации на обоих серверах и краткое резюме по результатам проверки.
Настройка MongoDB
В MongoDB репликация осуществляется объединением нескольких (в типовой конфигурации - 3) узлов в Replica Set. Replica Set состоит из одного primary узла и нескольких secondary (подробнее https://docs.mongodb.com/v4.0/administration/replica-set-deployment/). Для упрощения предлагаем схему:
Primary — основной сервер mongoDB.
Secondary — точные копии баз(ы) данных с real-time синхронизацией.
Arbiter — сервер отвечает только за выборы преемника, сам стать преемником он не может, поэтому рекомендуется отдавать под арбитра минимальные ресурсы.
Минимальные характеристики для mongo-db arbiter:
vCore: 1, 64-bit x86 CPUs
vRAM: 2 ГБ
vHDD: 20Гб
Примечание
Все операции по изменению данных выполняются только на primary. При этом MongoDB автоматически выполняет failover и смену primary на живой узел, если текущий primary выйдет из строя. Но это требует 3+ узлов в replica set.
Настройка 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:
replica_set_name:PRIMARY> rs.add("<ip_server>:27017",true) { "ok" : 1 }
Через некоторое время, приглашение 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:
replica_set_name:PRIMARY> rs.add("<ip_server>:27017") { "ok" : 1 }
Если 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) { "ok" : 1 }
Удалить узел из Replica Set (выполнять на PRIMARY):
replica_set_name:PRIMARY> rs.remove("<ip_server>:27017") { "ok" : 1 }
Для корректировки адреса сервера выполнить следующее:
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 - список всех членов кластера)
:
1 |
|
В конфигурации /etc/eltex-pcrf/eltex-pcrf.json
нужно разрешить запуск кластера:
|
Перезапустить Eltex-PCRF командой
|
Проверка состояния кластера
|
Особенности настройки 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 и содержит адреса клиентов, имеющих право отправлять запросы на проведение авторизации пользователей. Если клиент не включен в эту таблицу, то запросы авторизации будут игнорироваться.
Для этого следующие команды из консоли MySQL на любом из серверов:
INSERT INTO eltex_auth_service.nas (nasname, shortname, secret, description) VALUES ('<ip_server_1>', 'Server-1', 'eltex', 'Server-1'); INSERT INTO eltex_auth_service.nas (nasname, shortname, secret, description) VALUES ('<ip_server_2>', 'Server-2', 'eltex', 'Server-2'); INSERT INTO eltex_auth_service.nas (nasname, shortname, secret, description) VALUES ('<virtual_ip>', 'Virtual IP', 'eltex', 'Virtual IP');
где:
- <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