...
Первым делом, вам необходимо изучить принципы работы основных способов авторизации:
В работе вашей системы вы можете одновременно использовать оба сценария. Вместе с тем, для использования в крупной сети настоятельно рекомендуется организовать два, не связанных между собой кластера систем WNAM, работающих в разных информационных контурах, один только для гостевой, другой только для корпоративной авторизации.
Определившись со сценарием работы, вам необходимо оценить число серверов, требуемых WNAM для работы, и разнесение функций системы между этими серверами. Такая оценка опирается на следующие параметры:
- Число одновременно идущих процедур авторизации, и число одновременно работающих в сети гостей / эндпоинтов
- Физические характеристики имеющихся серверов
- Требования по отказоустойчивости и географическому разнесению узлов системы
В конечном счете, устойчивая работа системы WNAM определяется нагрузкой на неё, которая напрямую связана с числом Web- и RADIUS-запросов, которые попадают на систему.
Рекомендуется проектировать объемы ресурсов таким образом, чтобы:
- Нагрузка на процессор сервера не превышала 50% (т.е. величина LA сервера была вдвое меньше числа установленных процессорных ядер)
- Задержка RADIUS-ответа в среднем не превышала 40 мс.
1.Типовой сценарий малой нагрузки
Если в вашей сети находится менее 200 точек доступа (т.е. менее 1000 одновременно работающих гостевых клиентов), или корпоративная авторизация требует менее чем 1000 эндпоинтов, вам подойдет дизайн, в котором все компоненты системы авторизации работают на одном физическом или виртуальном сервере.
2. Сценарий высокой нагрузки без отказоустойчивости
3. Сценарий высокой нагрузки с локальной отказоустойчивостью
4. Сценарий высокой нагрузки с распределенной отказоустойчивостью
5. Сценарий высокой нагрузки с распределенной отказоустойчивостью и поддержкой изолированной работы
Резервное копирование
Настоятельно рекомендуется настроить резервное копирование системы одновременно по обоим путям:
- Для серверов, на которых работает MongoDB: через cron по расписанию, раз в сутки ночью, дамп базы данных в файлы, на другой (относительно основного) физический диск, с удалением старых резервных копий
- Резервное копирование виртуальной машины целиком, используя средства резервного копирования вашей платформы виртуализации.
При использовании кластерного варианта MongoDB можно не копировать разделы, содержащие файлы БД (в любом случае восстановить из "горячего бэкапа" кластерную БД не получится).
Резервное копирование виртуальных машин должно включать в себя копии дампов БД, которые должны формироваться до того, как проводится процедура бэкап