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