Оптимизация простых очередей (hotspot, radius, queue)

[megadimasty]

Коллеги всем добра!
есть пара NAS на 1036 - авторизация hotspot eoip (mac+ip) на radius (lanbilling)
количество сессий по разному - но в топе 2к абонентов на юнит
CPU поднимается до 70+ при 2Гбит нагрузки (200+ Кпакетов) на юнит
ищу пути оптимизации обработки правил файрвола и простых очередей
пожалуйста не надо писать ответов на подобии: "купите еще n шт NAS..." - я это и сам прекрасно знаю
вопрос академический:
возможно ли оптимизировать простые очереди (которые как известно обрабатываются последовательно) - путем группирования, скажем по
подсетям /26 или /27 - добавляя в родительскую очередь без ограничения.
предполагается, что разделив на блоки общий список очередей можно сократить количество обработки пакета в очереди до списка из одного блока
такая схема работает при создании учетных записей hotspot непосредственно в routeros (закладка users)

проблема: мне не известно и я не смог найти необходимого атрибута RADIUS клиента - для того что бы передать опцию queue parent от сервера RADIUS на NAS
приветствуется любая полезная информация!

[megadimasty]

Пример созданного блока простых очередей
Simple queue tree (не путать с queue tree)

[Chupaka]

Приветствую.

Собственно, в шестой версии RouterOS достаточно хорошо оптимизировали Simple Queues в плане потребления ресурсов при огромном количестве очередей, так что тут особо ничего не сделаешь, наверное. А почему в Queue Tree с PCQ, например, не хотите?

[megadimasty]

Все относительно.
Для кого то огромное количество пара тысяч - кому то двадцать, кому-то 200к сессий
Сейчас в ЧНН NAS работает с нагрузкой 50-60% ЦПУ (надо уточнить что отдельные ядра стоят в полке 100%)
У меня NAS серверы стоят в балансировке с VRRP - если выводим юнит (причины разные) - нагрузку принимает второй.
Когда на юнит падают все сессии - 1036 оказывается перегружен. При достижении 80+% 1036 впадает в коматоз - становится слабо управляем, начинаются дропы.
Биллинг управляет NAS-ми по RADIUS (для нас это удобно) - поэтому только простые очереди (Queue tree знаю - раньше делал двойные очереди)
Собственно цель поиска решения
использовать технических потенциал на максимум - рационально выполняя работу по обработке трафика. довести емкость NAS до 6к+ сессий и 8Гбит/с пропускаемого трафика

в принципе внезапно нашлось решение как все организовать - но пока не успел проверить
если все заработает как ожидается - я напишу здесь.
аналогичных решений в интернете не нашел

[Chupaka]

Биллинг управляет NAS-ми по RADIUS (для нас это удобно) - поэтому только простые очереди (Queue tree знаю - раньше делал двойные очереди)

Почему RADIUS не может отдавать, например, Mikrotik-Address-List - и дальше уже по спискам отправлять в Queue Tree?

[megadimasty]

адрес листы это первое что пришло в голову
но речь шла об оптимизации
если добавить в адрес листы 4к адресов - работы для ЦПУ станет еще больше

[Chupaka]

Больше, но не настолько, как вы думаете. Там не просто список в памяти, там поиск хорошо оптимизирован.

[megadimasty]

я из практических наблюдений исхожу
приложил скрин
если в этот момент будет происходить ребалансировка нагрузки - NAS будет сильно тупить )

[megadimasty]

насколько будет производительнее схема с деревом очередей PCQ и самое главное - причина почему дерево очередей выигрывает в производительности?

[Chupaka]

Ребалансировка нагрузки - это когда ещё тыщонка клиентов ломанётся на роутер авторизоваться одновременно? Ну, не самая простая ситуация

Насколько производительнее - без понятия, я с 2017-го не работаю уже с такими нагруженными микротиками, а выиграть дерево может потому, что число очередей не меняется, и для шейпинга используются внутренние механизмы PCQ, а не отдельные очереди.

Понаблюдать за нагрузкой вы можете, постепенно накатывая схему: добавьте в текущую динамическое добавление клиентов в адрес-листы, посмотрите, меняется ли нагрузка и как значительно; потом добавьте маркировку пакетов (даже без создания дерева очередей)...

[Tiesto]

Собственно цель поиска решения
использовать технических потенциал на максимум - рационально выполняя работу по обработке трафика. довести емкость NAS до 6к+ сессий и 8Гбит/с пропускаемого трафика

Микротик что бы до 8гиг при 6к+ сессии на юнит не возможно... Но можно ставить отдельный 1036 для роутинг и нат - как кор роутер, а остальны1036 только для чистого сесии и шейпера и при этом Я думаю максимум 2,5к сессии и не больше...