Для корректной работы системы WNAM 2 необходимо настроить значительное число компонентов, а именно:
Настоятельно рекомендуется обращаться для этой цели к системным интеграторам, имеющим опыт работы с системой. Особенно, если вам требуется построение сложной, нагруженной и распределенной инсталляции системы WNAM 2. Получить рекомендации по выбору системного интегратора можно, отправив запрос на info@netams.com. Компания-разработчик системы WNAM 2 не может рекомендовать "идеальный" дизайн сопутствующих систем: сетевой инфраструктуры, средств виртуализации, средств обеспечения информационной безопасности, резервного копирования, доменной структуры Windows и т.п.
Приведенные ниже сценарии использования системы WNAM 2 описывают типовые задачи, которые встречаются у наших заказчиков. Настоятельно рекомендуется придерживаться одного из следующих примеров при проектировании и развертывании системы WNAM 2.
Для крупной сети настоятельно рекомендуется организовать два не связанных между собой кластера систем, работающих в разных информационных контурах: один только для гостевой, другой только для корпоративной авторизации.
Определившись со сценарием работы, необходимо оценить число серверов, требуемых системе WNAM 2 для работы, и разнесение функций системы между этими серверами. Такая оценка опирается на следующие параметры:
В конечном счете, устойчивая работа системы WNAM 2 определяется нагрузкой на неё, которая напрямую связана с числом Web-, API-, TACACS+ и RADIUS-запросов, попадающих на систему. Рекомендуется проектировать объемы ресурсов таким образом, чтобы:
Если в сети находится менее 200 точек доступа (т.е. менее 1000 одновременно работающих гостевых клиентов) или корпоративная авторизация требует менее чем 1000 эндпоинтов, подойдет дизайн, в котором все компоненты системы авторизации работают на одном физическом или виртуальном сервере.
Типовые характеристики такого сервера:
В промышленной эксплуатации отказоустойчивость может быть обеспечена платформой виртуализации , посредством автоматического перезапуска сервера на другом хосте.
Этот сценарий также подойдет для проведения тестирования WNAM 2, ознакомления с его возможностями, и самообучения.
2. Сценарий средней нагрузки без отказоустойчивости
Если в сети находится менее 500 точек доступа (т.е. менее 5000 одновременно работающих гостевых клиентов) или корпоративная авторизация требует менее чем 5000 эндпоинтов, рекомендовано вынести на отдельный сервер базу данных PostgreSQL.
В данном случае понадобится два одинаковых сервера с характеристиками:
Дополнительно для сервера PostgreSQL необходимо:
Аналогично, в промышленной эксплуатации отказоустойчивость может быть обеспечена платформой виртуализации , посредством автоматического перезапуска сервера на другом хосте.
Работавший в WNAM 1.6 сценарий с локальным кластером MongoDB и двумя серверами WNAM на одной локации (ЦОД) в системе WNAM 2 более не поддерживается. Мы не рекомендуем без специальных инструкций от нас применять кластерную инсталляцию PostgreSQL, либо подключать два сервера WNAM 2 к одному серверу базы данных. Рассмотрите вариант использование сценариев 4.1 и 4.2 ниже.
Если сеть соответствует характеристикам сценариев 2 или 3, но при этом требуется получить полную отказоустойчивость системы, при которой её работоспособность сохраняется при выходе из строя одного из серверов системы WNAM 2, можно использовать сценарий средней нагрузки с распределенной отказоустойчивостью.
При таком сценарии (4.1) репликация данных производится не средствами кластера СУБД PostgreSQL, а путем пересылки информационных сообщений между двумя разрозненными автономными инстансами (экземплярами) PostgreSQL, каждый из которых взаимодействует только с локальным экземпляром системы WNAM 2.
Минимальное (и достаточное) число узлов (серверов) кластера равно двум. Вам не требуется третий узел системы, хотя конечно вы имеете право его поставить.
В таком режиме понадобится наcтроить репликацию данных средствами Kafka.
Для административного доступа в веб-интерфейс, а также для редиректа HTTP-запросов клиентов от оборудования хотспота понадобится настроить кластерный IP-адрес серверов. Кластерный IP-адрес серверов (.1 на схеме) необходимо указать в качестве единственного адреса RADIUS-сервера на оборудовании. В такой реализации система работает в режиме "active-standby", т.е. в каждый момент времени только один из серверов принимает на себя всю нагрузку, а второй простаивает, занимаясь только получением и синхронизацией данных от первого.
Если не требуется применять гостевой Wi-Fi доступ, можно настроить полноценный кластер "active-active" из двух серверов WNAM2 (сценарий 4.2). В качестве RADUIS-сервера на сетевом оборудовании следует указать оба IP-адреса. В случае аварии любого из серверов, каналов связи или ЦОД система продолжит выполнять свои функции. Преимуществом этого сценария является отсутствие необходимости иметь общий (кластерный) IP-адрес, что возможно сделать лишь при нахождении обоих серверов в одном сетевом сегменте. Таким образом, можно настроить два сервера авторизации системы WNAM 2, находящихся в разных сетях (разных дата-центрах или даже разных городах):
Репликация данных между серверами кластера WNAM по-прежнему производится брокером Kafka. Кластер СУБД не формируется; у каждого сервера работает свой собственный локальный экземпляр PostgreSQL.
Сетевое оборудование (коммутаторы, контроллеры и т.п.) будет проводить балансировку нагрузки между заданными в конфигурации двумя серверами сообразно собственным алгоритмам. Их реализация целиком определяется прошивкой этого оборудования.
При настройке данного сценария понадобится два одинаковых сервера с характеристиками:
Если нагрузка превышает характеристики сценария 4, и требуется обеспечить полную отказоустойчивость системы, возможно разнесение ролей системы авторизации на отдельные сервера и виртуальные машины в каждом экземпляре кластера (сценарий 5.1). При этом в пределах узла кластера обеспечивается локальная отказоустойчивость и распределение нагрузки, а между узлами кластера - репликация конфигурационных и статистических данных.
В данном сценарии понадобится создать два или три (по числу имеющихся площадок ЦОД) одинаковых кластера системы WNAM 2 в составе трех серверов, каждый из которых должен иметь такие характеристики:
Дальнейшее распределение нагрузки предполагает разделение ролей северов, и использование множества серверов типа RADIUS и TACACS+. В таком сценарии 5.2 отдельно выделяются узлы администрирования и управления (веб-интерфейс, база данных, брокер кластерной синхронизации), и отдельно обрабатывающий авторизационный траффик узлы. Эта схема схожа принципу разделению ролей серверов, который применяет Cisco ISE. Вместо PAN (Policy Administration Node) и MnT (Monitoring node) работают узлы Управления. Вместо PSN (Policy Service node) работают узлы Авторизации. Аналога pxGrid нет (но будет). При этом число узлов авторизации может быть гораздо больше числа узлов управления (их потребуется минимум два, максимум четыре). Обслуживающее клиентов сетевое оборудование NAS подключается к ближайшим узлам Авторизации так, чтобы обеспечить и отказоустойчивость, и балансировку нагрузки.
Естественно, технические требования к отдельным узлам авторизации будут ниже, чем к обычным узлам WNAM 2, несущим в себе все роли.
Если имеется множество (сотни) удалённых площадок (сайтов), с которыми невозможно гарантировать постоянное наличие сетевой связи как минимум с одним из ЦОД, в котором работает экземпляр системы WNAM 2, необходимо сформировать сетевую конфигурацию, при которой даже при отсутствии сетевой связности будет обеспечиваться работоспособность корпоративной авторизации. При этом допустима деградация услуги (например, увеличение длительности процесса авторизации, невозможность изменения настроек и/или просмотра статистики, невозможность обеспечить подключение новых устройств и т.п.). В таком случае, на каждой такой площадке необходимо установить специализированного агента авторизации (RADIUS-прокси/кэширующий сервер). В обычном режиме работы он прозрачно пропускает через себя запросы авторизации, маршрутизируя их в сторону доступных ЦОД с работающей системой WNAM 2. Результат авторизации сохраняется. При разрыве сетевой связности этот сервер проводит авторизацию устройств самостоятельно, пользуясь накопленными ранее данными.
При этом в каждом филиале потребуется развернуть виртуальную машину или Docker-контейнер с ПО, имеющим следующие требования:
За подробностями реализации такого (экзотического) сценария обращайтесь на info@netams.com.
В состав системы WNAM 2 входит значительное число системного и прикладного ПО, которое взаимодействует друг с другом в пределах одного сервера (виртуальной машины), а также между серверами. В дополнение к этому, система взаимодействует с внешним миром (сервера доступа, пользовательские устройства, администраторы) по различным протоколам стэка TPC/IP. Описание такого обмена приведено в соответствующем разделе.
Настоятельно рекомендуется настроить резервное копирование системы WNAM 2 одновременно по обоим направлениям:
При использовании кластерного варианта PostgreSQL можно не копировать разделы, содержащие файлы БД (в любом случае восстановить из "горячего бэкапа" кластерную БД не получится). Резервное копирование виртуальных машин должно включать в себя копии дампов БД, которые должны формироваться до того, как проводится процедура бэкап.