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