RADIUS-сервер кажется легким сервисом, пока сеть работает штатно. При массовом переподключении сервер аутентификации получает пик Access-Request и Accounting-Request, который нельзя оценить по среднему числу абонентов. Разберем, как связать RPS, EAP-TLS, аккаунтинг, СУБД и требуемое время восстановления с ресурсами платформы и подтвердить расчет нагрузочным тестом.
Три функции и почему учет тяжелее аутентификации
RADIUS реализует AAA. Аутентификация проверяет, кто подключается. Авторизация задает доступные сервисы, скорость и параметры подключения. Аккаунтинг ведет учет сессий, времени и потребления. Для каждого процесса нужен свой профиль запросов и backend.
Аутентификация создает нагрузку при подключении и повторной проверке, например при 802.1X или истечении времени жизни сессии. Аккаунтинг формирует постоянный поток Start, Stop и interim update, пока подключение активно.
Оценка фонового потока начинается с формулы: активные одновременные сессии делят на Acct-Interim-Interval и добавляют Start/Stop в секунду. Объем хранения считают как число записей в сутки, умноженное на средний размер записи и срок хранения, после чего учитывают индексы, журнал транзакций, репликацию и резервные копии.
Одна Accounting-Request не обязательно равна одной физической записи. IOPS, задержка записи и глубина очереди зависят от схемы сохранения, поэтому их измеряют на той же реализации СУБД или очереди, которая будет работать в эксплуатации.
Нагрузка измеряется не абонентами, а запросами
Сравним две сети по десять тысяч абонентов каждая.
В первой абоненты сидят на стабильных линиях, сессии живут сутками: нагрузка — фоновые сообщения учета плюс редкие аутентификации. Во второй линии с помехами, сессии рвутся по несколько раз в час, и каждый разрыв дает завершение сессии, новую аутентификацию, авторизацию и старт нового учета. При том же числе абонентов нагрузка кратно выше.
Число абонентов в договорах здесь не работает как расчетная величина. Работает число запросов в секунду, а его определяют четыре фактора.
Число одновременных сессий — сколько подключений активно в пик, а не сколько абонентов подключено формально.
Частота переподключений — зависит от качества линий и от настроек времени жизни сессии. Короткое время жизни означает регулярную переаутентификацию всей базы.
Интервал промежуточных сообщений учета влияет на точность тарификации, постоянный RPS и объем хранения. Значение выбирают с учетом возможностей NAS или BRAS, биллинга и требований к учету, а затем проверяют на нагрузочном профиле.
Для EAP-TLS измерьте число завершенных аутентификаций в секунду, количество RADIUS-пакетов на одну сессию, загрузку каждого ядра и p95/p99 задержки. Предельный профиль определяется моментом, когда растут очередь, ошибки и тайм-аут.
Если системы еще нет, оценку делают от обратного: берут ожидаемое число одновременных сессий, умножают на предполагаемую частоту событий на сессию и добавляют фоновый поток учета исходя из выбранного интервала.
Процессор, память и диск: что во что упирается
Для локальной проверки пароля ограничителем может стать однопоточный участок или backend. Для EAP-TLS возрастают стоимость криптографии и число обменов. Платформы сравнивают на смешанном профиле по RPS, p95/p99, загрузке ядер и доле ошибок или тайм-аутов.
Потребление RAM зависит от реализации: одновременно обрабатываемых запросов и EAP-диалогов, кешей, пулов соединений и локальных модулей. Учет активных абонентских сессий может находиться в СУБД или другой системе, поэтому память выбирают по измеренному RSS и профилю компонентов.
Профиль диска определяется цепочкой сохранения accounting. СУБД и журнал транзакций могут создавать мелкие случайные записи, а detail-файл или очередь дают более последовательный поток. Проверяйте IOPS, p95 задержки коммита и очередь на рабочей схеме хранения.
Емкие накопители не решают проблему задержки записи. Если очередь растет при целевом accounting RPS, меняют схему хранения, параметры СУБД или дисковую подсистему, а не просто увеличивают объем.
Сеть для самого сервиса редко бывает узким местом: пакеты небольшие, полосы хватает. Но если база абонентов вынесена на отдельный узел, канал до нее становится критичным — каждая аутентификация превращается в сетевой запрос к базе.
Соотношение ресурсов задает профиль для подбора сервера под задачу: CPU, RAM, хранение и backend проверяют на целевых RPS и задержке.
Где живет база абонентов и почему это важно
Три варианта различаются задержкой запроса, независимостью масштабирования и числом точек отказа.
Локальная база на том же узле. Минимальные задержки и простая схема, но сервер несет двойную нагрузку и масштабировать сервис отдельно не получится.
Вынесенная база на отдельном узле. Разделение нагрузки, независимое масштабирование, общая база для нескольких серверов. Цена: зависимость от канала и еще одна точка отказа — задержка базы напрямую входит в время отклика.
Внешний каталог. Логичен там, где база пользователей уже ведется централизованно.
Вынос базы разделяет нагрузку, но добавляет сетевую зависимость. Измерьте p95/p99 ответа backend и поведение при его недоступности, а окончательную схему подтвердите отказным тестом.
Отказоустойчивость: два сервера и что между ними
При недоступности RADIUS новые подключения обычно не проходят, а поведение существующих сессий зависит от NAS или BRAS, таймеров, повторной аутентификации и политики отказа. Этот сценарий проверяют испытанием, а не принимают как универсальный.
В рабочей схеме используют два и более RADIUS-сервера, а клиенты переключаются между ними по настроенным тайм-аутам и повторам. Дублированное питание, диски с горячей заменой и удаленное управление учитывают при выборе отказоустойчивого сервера вместе с требуемым RTO.
Резервный узел должен иметь актуальный backend и политики. Репликацию СУБД, согласованность данных, health-check и условия возврата на основной узел проектируют заранее, а затем измеряют время переключения.
NAS может повторять Accounting-Request до подтверждения и передавать Acct-Delay-Time. По нему сервер оценивает время события, а точность выше при наличии Event-Timestamp. Гарантия доставки и глубина локального буфера зависят от реализации и настроек NAS или BRAS. Проверьте отказным тестом, сколько записей сохраняется, как устраняются дубли и что получает биллинг после восстановления.
Если RADIUS-серверы разнесены по площадкам, резервирование каналов связи проектируют вместе с маршрутами к СУБД и сетевым оборудованием доступа.
Пиковый сценарий: массовое переподключение
Это тот момент, ради которого делается расчет.
При аварии на участке сети множество абонентов теряют сессии одновременно. После восстановления оцените пик формулой: число переподключений делят на допустимое окно восстановления, умножают на число RADIUS-обменов для одной аутентификации и добавляют повторы и фоновый accounting.
При недостаточной платформе очередь растет, часть клиентов не получает ответа вовремя и повторяет запрос — очередь растет еще быстрее. Восстановление, которое должно занять минуту, растягивается на десятки, и абоненты видят отсутствие связи уже после устранения физической проблемы.
Нагрузочный тест должен воспроизводить этот профиль на выбранной реализации RADIUS, с теми же модулями, СУБД и политиками. Результат принимают по RPS, p95/p99 задержки, ошибкам и соблюдению целевого RTO.
Ориентиры по конфигурациям
Пиковый профиль | Что измерить | CPU и RAM | Хранение | Доступность |
|---|---|---|---|---|
Access-Request RPS | RPS, обмены на сессию, доля EAP-TLS, p95/p99 | Загрузка по ядрам, RSS, кеши и пулы соединений | Нагрузка backend и журналы | Требуемый RTO и поведение NAS при тайм-ауте |
Accounting-Request RPS | Interim update, Start/Stop, объем записей в сутки | RSS модулей и соединений с СУБД | IOPS, p95 задержки записи, очередь, индексы и WAL | RPO, репликация и проверка восстановления |
Массовое переподключение | Число сессий, окно восстановления, повторы и RPS | Нагрузка каждого ядра и очередь запросов | Одновременный пик записи и backend latency | Failover, доступность СУБД и соблюдение SLA |
Таблица задает профиль измерений, а не готовую спецификацию. Пороговые значения получают нагрузочным тестом конкретной реализации с теми же модулями, СУБД и политиками. Число активных сессий используют для расчета фонового accounting-потока, а не как самостоятельный размер сервера.
Какие данные передать для расчета
Для расчета нужны пиковые Access-Request и Accounting-Request RPS, доля EAP-TLS, p95/p99 ответа backend, объем accounting за сутки и требуемые RTO и RPO.
Зафиксируйте сценарий массового переподключения, схему размещения СУБД, размер записи, срок хранения и накладные расходы репликации и резервного копирования. По этим данным формируют профиль теста и сравнивают платформы.
При закупках по 44-ФЗ и 223-ФЗ применимость национального режима проверяют по статусу заказчика и условиям процедуры. Для коммерческой закупки вне сферы этих законов обязательность требования оценивают отдельно, поскольку формулировка «частный оператор и собственные средства» недостаточна.
Окончательную конфигурацию подтверждают нагрузочным и отказным тестами. Когда исходные показатели собраны, подбор сервера под задачу ведут под пиковый профиль и заданное время восстановления.