Начиная с версии 1.1.512 система WNAM позволяет создавать отказоустойчивые конфигурации путём объединение двух или более серверов в кластер. Это требуется, если требуется обеспечить полную непрерывность предоставления услуги авторизации беспроводного доступа путём дублирования управляющих серверов и БД. В случае выхода из строя одного из серверов кластера, нарушения сетевой связности, отказа жёсткого диска и БД система WNAM с точки зрения пользователей продолжит работу, и данные не будут потеряны. Время переключения серверов составляет порядка 10 секунд. Следует учитывать, что использование этого механизма не отменяет необходимости производить периодический бэкап (дамп) базы.

Сценарий использования кластеризации предполагает работу всех серверов системы WNAM и БД MongoDB в одном ЦОД (рядом). Если требуется распределенная конфигурация, то следует использовать распределенный кластер Kafka (брокер Kafka).

Для корректной работы механизма кластеризации требуется БД MongoDB версии 3.0 и выше и утилиты модуля ядра Linux - ucarp либо keepalived, позволяющие настроить "плавающий" IP-адрес.

Механизм работы кластера высокой доступности является лицензируемым. Потребуется по одной базовой лицензии системы WNAM на каждый сервер и одна лицензия на кластер.

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

  • настроить репликацию БД MongoDB;
  • настроить приложению WNAM для использования реплицированной базы;
  • настроить кластерный IP-адрес серверов.
Работа кластеризации системы WNAM основана на том, что все сведения об объектах, статистику, настройки и т.п. сервер системы WNAM хранит в БД, а не в оперативной памяти процесса. Таким образом, в случае переключения между серверами системы WNAM никакие данные не потеряются, за исключением текущих неподтвержденных телефонов (в случае, если СМС-сообщение отправлено, но абонент ещё не ввёл код подтверждения ).

Репликация БД MongoDB

Механизм обеспечения отказоустойчивости БД путём репликации её на несколько серверов встроен в БД MongoDB и очень подробно описан в документации на СУБД (официальная документация). Он основан на использовании набора репликации (replica set), функционирующем на основном (primary) и одном (или более) резервных (secondary) серверов, возможно, с использованием арбитра (arbiter). Можно перенастроить уже работающую БД MongoDB для работы в кластере без потери данных.

Минимальный набор серверов для включения в кластер состоит из основного сервера, резервного сервера и арбитра. Арбитр не хранит данные, а является лишь посредником при проведении голосования по выбору мастера. Возможно запустить службу арбитра на одном из двух серверов с базами на нестандартных портах. Допустим, если требуется создать кластер из трёх серверов (физических или виртуальных машин). Описание кластеров приведено в таблице.

№ИмяIP-адресРольПриоритет
1wnam-srv1.domain.net1.2.3.89PRIMARY2
2wnam-srv2.domain.net1.2.3.90SECONDARY1
3wnam-arbiter.domain.net1.2.3.92ARBITER0
-wnam.domain.net1.2.3.91Кластерный адрес системы WNAMНе участвует в БД MongoDB

На каждом из серверов в файлах /etc/hosts необходимо сделать записи вида "127.0.0.1 localhost wnam-srv1.domain.net", иначе кластер не соберется. В конфигурационных файлах /etc/mongod.conf на каждом из серверов следует добавить:

replication:
  replSetName: rs0

Далее следует перезапустить сервис БД MongoDB и на сервере, который предполагается сделать основным, выполнить:

  mongo
  rs.initiate()
  rs.add("wnam-srv2.domain.net")
  rs.addArb("wnam-arbiter.domain.net")

и настроить приоритеты:

  cfg = rs.conf()
  cfg.members[0].priority = 2 
  cfg.members[1].priority = 1 
  cfg.members[2].priority = 0 
  rs.reconfig(cfg)

Затем необходимо проверить конфигурацию:

 rs.conf()

и проверить статус репликации:

 rs.status()

При корректно настроенной репликации вывод вышеприведённой команды будет сходен с таким:

rs0:PRIMARY> rs.status();
{
 "set" : "rs0",
 "date" : ISODate("2015-12-13T15:56:18.191Z"),
 "myState" : 1,
 "members" : [
 {
 "_id" : 0,
 "name" : "wnam-srv1.domain.net:27017",
 "health" : 1,
 "state" : 1,
 "stateStr" : "PRIMARY",
 "uptime" : 16387,
 "optime" : Timestamp(1450020906, 3),
 "optimeDate" : ISODate("2015-12-13T15:35:06Z"),
 "electionTime" : Timestamp(1450020295, 1),
 "electionDate" : ISODate("2015-12-13T15:24:55Z"),
 "configVersion" : 6,
 "self" : true
 },
 {
 "_id" : 1,
 "name" : "wnam-srv2.domain.net:27017",
 "health" : 1,
 "state" : 2,
 "stateStr" : "SECONDARY",
 "uptime" : 1886,
 "optime" : Timestamp(1450020906, 3),
 "optimeDate" : ISODate("2015-12-13T15:35:06Z"),
 "lastHeartbeat" : ISODate("2015-12-13T15:56:16.803Z"),
 "lastHeartbeatRecv" : ISODate("2015-12-13T15:56:17.362Z"),
 "pingMs" : 0,
 "syncingTo" : "wnam-srv1.domain.net:27017",
 "configVersion" : 6
 },
 {
 "_id" : 2,
 "name" : "wnam-arbiter.domain.net:27017",
 "health" : 1,
 "state" : 7,
 "stateStr" : "ARBITER",
 "uptime" : 1886,
 "lastHeartbeat" : ISODate("2015-12-13T15:56:17.004Z"),
 "lastHeartbeatRecv" : ISODate("2015-12-13T15:56:17.361Z"),
 "pingMs" : 0,
 "configVersion" : 6
 }
 ],
 "ok" : 1
}

На этом настройка БД MongoDB завершена. Если необходимо перевести в реплицированный режим имеющуюся базу, то появится файл с базой на втором (secondary) сервере (/var/lib/mongodb/). 

Настройка системы WNAM

На обоих серверах (primary и secondary) необходимо установить систему WNAM совершенно одинаково (версия, пакеты, скрипты). Через интерфейс администратора необходимо настроить систему WNAM на основном сервере, ввести лицензионный ключ, позволяющий использовать кластерную конфигурацию. Для версий системы WNAM выпуска до сентября 2023 года в работе кластера используется кэш Hazelcast. В конфигурационном файле /home/wnam/wnam.conf, определяющем параметры запуска приложения, следует указать два сервера системы WNAM:

export JAVA_OPTS="-Xms1g -Xmx12g -Djava.net.preferIPv4Stack=true -DHZ_OC_MEMBERS=wnam-app1,wnam-app2"
export LOG_FOLDER="/home/wnam/logs"
export LOG_FILENAME="console.log"

Для версий системы WNAM выпуска после сентября 2023 года в работе кластера не используется кэш Hazelcast. Правки в /home/wnam/wnam.conf при этом не требуются.

В конфигурационном файле /home/wnam/application.yaml, определяющем параметры работы с БД, приложения, необходимо указать три сервера БД MongoDB:

...
spring:
  data:
    mongodb:
      uri=mongodb://wnam-db1,wnam-db2,wnam-db3/wnam_db
...

При использовании нестандартного порта его можно указать после имени сервера через двоеточие:

spring:
  data:
    mongodb:
      uri=mongodb://wnam-db1,wnam-db2,wnam-db2:27120/wnam_db

В этом же файле для сервера, который должен быть предпочтительным главным по умолчанию, следует указать:

netams:
  wnam:
    cluster:
      role=master
После произведенных настроек следует перезапустить систему WNAM на основном и резервном сервере. В интерфейсе администратора каждого из серверов на главной странице появятся дополнительные записи.


При этом, оба сервера, фактически, будут обращаться к одной БД. Можно проверить, что произойдет, если изменить настройки на одном сервере системы WNAM, и проверить изменения на втором сервере.

Настройка кластерного IP-адреса

Для того, чтобы внешние по отношению к серверам системы WNAM пользователи и устройства воспринимали оба сервера как один кластер, необходимо настроить средство, позволяющее путём голосования выбрать активный сервер, присвоить ему кластерный адрес и переключать его в случае сбоя активного узла. Такое поведение можно получить, если установить и настроить какое-нибудь средство кластеризации серверов Linux.

Средство кластеризации необходимо установить на двух серверах - primary и secondary. Сервер-арбитр участвует только в выборах активного узла БД MongoDB, но не в IP-кластере, поэтому на нём дополнительные настройки не нужны.

В зависимости от того, работает ли в вашей сети между серверами multicast-трафик, можно выбрать один из двух режимов:

После настройки и появления у одного из серверов кластерного адреса, следует обратиться к веб-интерфейсу системы WNAM через кластерный адрес или DNS-имя. После подключения к веб-интерфейсу следует попытаться отключить сетевой интерфейс первого сервера. Не более чем через 30 секунд система WNAM будет снова доступна по кластерному адресу, а БД будет указывать на резервный сервер. При включении первого сервера произойдет повторное переключения кластерного адреса обратно и репликация БД.

Для внешних клиентов - беспроводных контроллеров и серверов доступа, в настройках RADIUS-клиента, форм перенаправления и т.д.  необходимо использовать только кластерный адрес 1.2.3.91 или DNS-имя wnam.domain.net. Таким образом, и сервер nginx (на обоих узлах кластера) необходимо настроить на отдачу ответов не только по его собственному IP-адресу или имени, но и по кластерному.

Также настоятельно рекомендуется в используемых системах мониторинга настроить тестирование состояния всех серверов кластера и статуса репликации.


  • No labels