Для корректной работы системы WNAM вам необходимо запроектировать создать проекты и настроить значительное число компонентов, а именно:
- Устройства устройства сетевого доступа NAS (контроллеры БЛВС для гостевого и/или корпоративного подключения, коммутаторы ЛВС, шлюзы VPN и т.п.);
- Сетевую сетевую инфраструктуру, обеспечивающую подключение физических или виртуальных серверов WNAM;
- Физические физические или виртуальные машины с ОС Linux , для установки системы WNAM, СУБД и других компонентов;
- СМС-шлюзы или программные АТС для отправки идентификационной информации;
- Средства средства мониторинга;
- Средства средства резервного копирования.
Настоятельно рекомендуется обращаться Мы настоятельно рекомендуем привлекать для этой цели системных интеграторов, имеющих к системным интеграторам, имеющим опыт работы с нашей системой WNAM. Особенно, если речь касается построения требуется построение сложной, нагруженной и распределенной инсталляции системы WNAM для нужда нужд корпоративной авторизации. Получить рекомендации по выбору системного интегратора вы можетеможно, отправив запрос на info@netams.com. Мы, как разработчики прикладного программного обеспечения, не можем порекомендовать вам Компания-разработчик системы WNAM не может рекомендовать "идеальный" дизайн сопутствующих систем: сетевой инфраструктуры, средств виртуализации, средств обеспечения информационной безопасности, резервного копирования, доменной структуры Windows и т.п.
Приведенные ниже сценарии использования системы WNAM описывают типовые задачи, которые встречаются у наших клиентов гостевой и корпоративной авторизации. Мы настоятельно рекомендуем Настоятельно рекомендуется придерживаться одного из следующих примеров при проектировании и развертывании системы WNAM у вас.
Первым деломВ первую очередь, вам необходимо изучить сценарии работы основных способов авторизации:
В работе вашей системы вы можете одновременно использовать оба сценария. Вместе с тем, А также для использования в крупной сети настоятельно рекомендуется организовать два , не связанных между собой кластера систем WNAM, работающих в разных информационных контурах: один только для гостевой, другой только для корпоративной авторизации.
Определившись со сценарием работы, вам необходимо оценить число серверов, требуемых системой WNAM для работы, и разнесение функций системы между этими серверами. Такая оценка опирается на следующие параметры:
- Число число одновременно идущих процедур авторизации , и число одновременно работающих в сети гостей / эндпоинтов;
- Физические физические характеристики имеющихся серверов;
- Требования требования по отказоустойчивости и географическому разнесению узлов системы.
В конечном счете, устойчивая работа системы WNAM определяется нагрузкой на неё, которая напрямую связана с числом Web- и RADIUS-запросов, которые попадают попадающих на систему. Рекомендуется проектировать объемы ресурсов таким образом, чтобы:
- Нагрузка нагрузка на процессор сервера не превышала 50% (т.е. величина LA сервера была вдвое меньше числа установленных процессорных ядер);
- Задержка задержка RADIUS-ответа в среднем не превышала 40 миллисекунд.
1.Типовой сценарий малой нагрузки
Если в вашей сети находится менее 200 точек доступа (т.е. менее 1000 одновременно работающих гостевых клиентов) , или корпоративная авторизация требует менее чем 200 эндпоинтов, вам подойдет дизайн, в котором все компоненты системы авторизации работают на одном физическом или виртуальном сервере.
Типичные Типовые характеристики такого сервера:
- количество виртуальных процессоров: 2-4 vCPU;
- оперативная память для видеоизображений: 8 Gb vRAM;
- объем жесткого диска: 50 HB HDD (любого типа).
2. Сценарий средней нагрузки без отказоустойчивости
Если в вашей сети находится менее 500 точек доступа (т.е. менее 5000 одновременно работающих гостевых клиентов) , или корпоративная авторизация требует менее чем 500 эндпоинтов, рекомендовано вынести на отдельный сервер базу данных MongoDB:.
Вам В данном случае понадобится два одинаковых сервера с характеристиками:
- количество виртуальных процессоров: 2-4 vCPU;
- оперативная память для видеоизображений: 8-16 Gb vRAM;
- объем жесткого диска: 50 HB HDD (любого типа).
Дополнительно для сервера MongoDB необходимо:
- 50 объем жесткого диска: 50 HB HDD (типа SSD).
3. Сценарий высокой нагрузки с локальной отказоустойчивостью
Если в вашей сети находится менее 1000 точек доступа (т.е. менее 10000 одновременно работающих гостевых клиентов) , или корпоративная авторизация требует менее чем 1000 эндпоинтов, рекомендовано создать отказоустойчивый кластер MongoDB. Такой кластер требует трёх узлов (primary, secondary, arbiter), причем только два из них несут копию базы, а третий только участвует в кворуме. Также желательно вынесение прокси-сервера на отдельный узел для того, чтобы перенести нагрузку обработки SSL-трафика с сервера приложения:.
В случае аварии основного сервера MongoDB (на схеме справа) система WNAM автоматически переключит запись/чтение на резервный сервер СУБД (на схеме слева).
Вам В таком случае понадобится три одинаковых сервера с характеристиками:
- количество виртуальных процессоров: 4-8 vCPU;
- оперативная память для видеоизображений: 16 Gb vRAM;
- объем жесткого диска: 50 HB HDD (любого типа) - системные диски.
Дополнительно для двух серверов MongoDB (primary, secondary) необходимо:
- объем жесткого диска: 50 HB HDD (типа SSD) - для СУБД;
- объем жесткого диска: 500 HB HDD (типа SATA) - для дампов СУБД.
4. Сценарий средней нагрузки с распределенной отказоустойчивостью
Если ваша сеть соответствует характеристикам сценариев 2 или 3, но при этом вы хотите требуется получить полную отказоустойчивость системы, при которой её работоспособность сохраняется при выходе из строя одного из серверов системы WNAM, вы можете рассмотреть этот сценарий.можно использовать сценарий средней нагрузки с распределенной отказоустойчивостью.
При таком сценарии В нём репликация данных производится не средствами кластера СУБД MongoDB, а путем пересылки информационных сообщений между двумя разрозненными автономными инстансами (экземплярами) MongoDB, каждый из которых взаимодействует только с локальным экземпляром системы WNAM.
В таким таком режиме вам понадобится наcтроить репликацию данных средствами Kafka.
Для административного доступа в веб-интерфейс, а также для редиректа HTTP-запросов клиентов от оборудования хотспота , вам понадобится настроить кластерный IP-адрес серверов. Его Кластерный IP-адрес серверов (.1 на схеме) вы должны необходимо указать в качестве единственного адреса RADIUS-сервера на оборудовании.
Если вы не применяете требуется использовать гостевой доступ, вы можете настраивать можно настроить любой из двух серверов системы WNAM через веб-интерфейс, и в качестве RADUIS-сервера на вашем используемом оборудовании указать оба IP-адреса (.2 и .3 на схеме).В случае аварии любого из серверов система продолжит выполнять свои функции. Преимуществом этого сценария является отсутствия отсутствие необходимости иметь общий (кластерный) IP-адрес, что возможно лишь при нахождении обоих серверов в одном сетевом сегменте. Таким образом, вы можете можно настроить два сервера авторизации системы WNAM, находящихся в разных сетях (разных дата-центрах или даже разных городах):.
Вам При настройке данного сценария понадобится два одинаковых сервера с характеристиками:
- количество виртуальных процессоров: 4-8 vCPU;
- оперативная память для видеоизображений: 16 Gb vRAM;
- объем жесткого диска: 50 HB HDD (любого типа) - системный дисксистемные диски;
- объем жесткого диска: 50 50 HB HDD (типа SSD) - для СУБД;
- 500 HB объем жесткого диска: 500 HB HDD (типа SATA) - для дампов СУБД.
5. Сценарий высокой нагрузки с распределенной отказоустойчивостью
Если ваша нагрузка превышает характеристики сценария 3, и вам требуется обеспечить полную отказоустойчивость системы, дальнейшим возможным развитием является возможно разнесение ролей системы авторизации на отдельные сервера и виртуальные машины в каждом экземпляре кластера. При этом в пределах узла кластера обеспечивается локальная отказоустойчивость и распределение нагрузки, а между узлами кластера - репликация конфигурационных и статистических данных:.
Вам В данном сценарии понадобится создать два или три (по числу ваших имеющихся площадок ЦОД) одинаковых кластера системы WNAM в составе трех серверов, каждый из которых имеет должен иметь такие характеристики:
- количество виртуальных процессоров: 8 vCPU;
- оперативная память для видеоизображений: 32 Gb vRAM;
- объем жесткого диска: 50 HB HDD (любого типа) - системный диск;
- 50 объем жесткого диска: 50 HB HDD (типа SSD) - для СУБД (для серверов 1 и 3);
- 500 HB объем жесткого диска: 500 HB HDD (типа SATA) - для дампов СУБД (для сервера 2).
6. Сценарий высокой нагрузки с распределенной отказоустойчивостью и поддержкой изолированной работы
В случае, когда у заказчика Если имеется множество (сотни) удалённых площадок (сайтов), с которыми невозможно гарантировать постоянное наличие сетевой связи как минимум с одним из ЦОД, в котором работает экземпляр системы WNAM, необходимо сформировать сетевую конфигурацию, при которой даже при отсутствии сетевой связности будет обеспечиваться работоспособность корпоративной авторизации. При этом допустима деградация услуги (например, увеличение длительности процесса авторизации, невозможность изменения настроек и/или просмотра статистики, невозможность обеспечить подключение новых устройств и т.п.). В таком случае, на каждой такой площадке необходимо установить специализированного агента авторизации , по сути (RADIUS-прокси/кэширующий сервер). В нормальном обычном режиме работы он прозрачно пропускает через себя запросы авторизации, маршрутизируя их в сторону доступных ЦОД с работающей системой WNAM. Результат авторизации запоминаетсясохраняется. При пропадании разрыве сетевой связности этот сервер проводит авторизацию устройств самостоятельно, пользуясь накопленными ранее данными.
...
При этом в каждом филиале потребуется развернуть виртуальную машину или Docker-контейнер с ПО, имеющим следующие требования:
- количество виртуальных процессоров: 1-2 vCPU;
- оперативная память для видеоизображений: 2 Gb vRAM;
- объем жесткого диска: 16 HB HDD (любого типа).
Взаимодействие компонентов
...
Настоятельно рекомендуется настроить резервное копирование системы WNAM одновременно по обоим путямнаправлениям:
- Для для серверов, на которых работает MongoDB: через cron (демона-постановщика задач систем Unix) по расписанию, раз в сутки ночью, дамп базы данных в файлы, на другой (относительно основного) физический диск, с удалением старых резервных копий;
- Резервное резервное копирование виртуальной машины целиком, используя средства резервного копирования вашей используемой платформы виртуализации.
При использовании кластерного варианта MongoDB можно не копировать разделы, содержащие файлы БД (в любом случае восстановить из "горячего бэкапа" кластерную БД не получится). Резервное копирование виртуальных машин должно включать в себя копии дампов БД, которые должны формироваться до того, как проводится процедура бэкап.
Управление доступом к административному интерфейсу
Поскольку система WNAM представляет собой монолитное Java-приложение, то обработчик веб-интерфейса администратора ("административный веб-интерфейс"), личный кабинет клиента/менеджера подразделения , и интерфейс авторизующегося гостевого клиента де-факто по умолчанию работают внутри одного процесса. Для того, чтобы разделить возможность доступа разным категориям пользователей этого интерфейса с точки зрения безопасности, наиболее оптимальным сценарием является:
- Вынос роли веб-сервера на отдельную виртуальную машину.
...
- Установка на
...
- виртуальной машине SSL-сертификата, обеспечивающего, в конечном счете, шифрование передаваемого трафика управления системой.
...
- Настройка разграничения доступа к различным разделам интерфейса путем тонкой настройки конфигурационного файла nginx.
Применяемые в системе пути (ссылки) группированы следующий образом:
...