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

Compare with Current View Page History

« Previous Version 5 Next »

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

Для работы механизма кластеризации требуется mongodb версии >3.0 и утилита ucarp.

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

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

  • Настройка репликации базы данных 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

Вы должны на каждом из серверов в файлах /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

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

В конфигурационном файле /etc/wnam.properties, определяющем способ подключения к базе данных, вы должны указать все три сервера mongodb. Драйвер будет автоматически выбирать текущий активный сервер:

   mongodb_host=wnam-srv1.domain.net;wnam-srv2.domain.net;wnam-arbiter.domain.net

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

   mongodb_host=wnam-srv1.domain.net;wnam-srv2.domain.net;wnam-arbiter.domain.net:30000
Запустите WNAM на основном и резервном сервере. В административном веб-интерфейсе каждого из них на главной странице вы увидите записи:


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

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

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

Необходимо его установить на двух серверах - primary и secondary. Сервер-арбитр участвует только в выборах активного узла mongodb, но не в IP-кластере.

apt-get install ucarp

Настройка ucarpd проста и требует изменения только конфигурационного файла /etc/network/interfaces. Мы выберем кластерный адрес 1.2.3.91. На него можно зарегистрировать ваше DNS-имя wnam.domain.net.

На первом (активном) сервере:

iface eth0 inet static
address 1.2.3.89
netmask 255.255.255.192
network 1.2.3.64
broadcast 1.2.3.127
gateway 1.2.3.65
dns-nameservers 1.2.3.5
dns-search domain.net
ucarp-vid 1
ucarp-vip 1.2.3.91
ucarp-password WNAMpassword
ucarp-advskew 0
ucarp-advbase 1
ucarp-master yes
iface eth0:ucarp inet static
address 1.2.3.91
netmask 255.255.255.255

На втором (резервном) сервере:

iface eth0 inet static
address 1.2.3.90
netmask 255.255.255.192
network 1.2.3.64
broadcast 1.2.3.127
gateway 1.2.3.65
dns-nameservers 1.2.3.5
dns-search domain.net
ucarp-vid 1
ucarp-vip 1.2.3.91
ucarp-password WNAMpassword
ucarp-advskew 30
ucarp-advbase 1
ucarp-master no
iface eth0:ucarp inet static
address 1.2.3.91
netmask 255.255.255.255

Перезапустите сетевую службу на обоих серверах (service networking restart) и проверьте, что основной первый сервер получил требуемый кластерный адрес.

Попробуйте обратиться к веб-интерфейсу WNAM через кластерный адрес или имя. Попробуйте теперь отключить сетевой интерфейс первого сервера. Через не более чем 5 секунд система WNAM будет снова доступна по кластерному адресу, а база данных будет указывать на резервный сервер. При включении первого сервера произойдет повторное переключения кластерного адреса обратно, и репликация базы.

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

Вы обязательно должны в ваших системах мониторинга настроить тестирование состояния обоих серверов кластера, и статуса репликации.
  • No labels