Наша сетевая установка состоит из 5 серверов доступа к сети в 5 разных местах по всему миру, и ожидается, что в ближайшие дни она расширится до 15 серверов доступа к сети и больше в будущем. В настоящее время мы используем сценарии для аутентификации, но мы планируем использовать AAA на основе freeradius для аутентификации и учета с этими серверами NAS из-за многих преимуществ, которые мы можем получить от использования данных учета. Ожидается, что в ближайшие дни пользовательская нагрузка вырастет до сотен тысяч пользователей. У меня вопрос к специалистам, имеющим практический опыт работы с подобной архитектурой, с точки зрения масштабируемости. Какую топологию свободного радиуса лучше всего использовать в такой установке?
Будет ли служба AAA на основе централизованного радиуса, состоящая из нескольких узлов радиуса, лучше, чем услуга AAA с распределенным радиусом. один радиус на NAS и почему? Мы хотим использовать учетные данные во время авторизации, поэтому распределенная служба радиуса потребует синхронизации учетных данных, а также данных аутентификации пользователей практически в реальном времени. Но с десятками разных местоположений синхронизация данных в реальном времени кажется труднодостижимой. Я читал о прокси-серверах радиуса, которые пересылают запросы радиуса на сервер центрального радиуса, однако я не понимаю, как это было бы более выгодно, чем прямое использование централизованной службы радиуса непосредственно из NAS. т.е. все NAS указывают на службу одного радиуса.
Если рассматривается услуга распределенного радиуса, радиорелейные реле могут быть подходящим вариантом, но радиорелейные реле кажутся полезными для первичной и резервной конфигурации, где количество узлов радиуса в основном равно двум, и я не уверен, будут ли они хороши для использования если им нужно синхронизировать данные между множеством разных серверов RADIUS.
Я буду очень благодарен, если кто-нибудь укажет мне правильное направление.
Если вы ориентируетесь на надежность
Преимущество распределенной архитектуры с локально реплицированной копией данных - это избыточность и уменьшенная задержка.
Синхронизировать несложно, протокол Syncrepl OpenLDAP хорошо справляется с топологиями концентратора и луча или даже с ячеистой топологией. Он будет выполнять частичную и полную повторную синхронизацию данных по мере необходимости. Новые экземпляры должны синхронизироваться с мастером при первом запуске.
Тем не менее, вам придется управлять каждым из этих экземпляров (использовать анзибль или соль) и исправлять ошибки, если возникнут проблемы.
Увеличиваются затраты на оборудование из-за необходимости размещать сервер рядом с каждым NAS в конфигурации «общей судьбы» (если возможно).
Вы действительно не предоставили достаточно информации о NAS, чтобы сказать, действительно ли это уместно. Могут ли клиенты отказываться от NAS?
Если вы ориентируетесь на простоту управления
Преимущество наличия одного (кластера) серверов RADIUS за резервными балансировщиками нагрузки (подсказка) заключается в упрощенном управлении.
Пары серверов, вероятно, будет достаточно, чтобы выдержать нагрузку до миллиона пользователей. Каждый экземпляр FreeRADIUS должен иметь возможность обрабатывать около 20 000–30 000 аутентификаций в секунду на умеренном оборудовании против экземпляра OpenLDAP, на котором запущен MDB.
Обновление, мониторинг, устранение проблем с базой данных проще выполнять с меньшим количеством экземпляров.
Серверы в этой конфигурации представляют собой единую точку отказа.
Если NAS начинает работать некорректно и переполняет серверы проверки подлинности трафиком, повышается вероятность перегрузки системы.
При нарушении сетевых соединений между NAS и центральными серверами NAS не сможет аутентифицировать пользователей.
Прокси-серверы
Иногда они полезны в качестве агрегаторов или в федерациях, но сами по себе мало что делают в сквозной конфигурации.
Кэширование прокси-серверов может быть полезно, поскольку они снимают часть нагрузки с серверов аутентификации.
В среде интернет-провайдера большая часть трафика состоит из отказов, поскольку клиенты будут продолжать повторную аутентификацию.
Кэширующие прокси-серверы могут отвечать от имени центральных серверов, если они ранее видели отклонение, или если центральный сервер отключен, и они ранее видели подтверждение.