You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 12 Next »

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

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

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

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

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

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

Репликация mongodb

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

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

Имя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.properties, определяющем параметры работы с БД, приложения, вы должны указать три сервера 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