В настоящее время я работаю над решением по формированию трафика для компаний уровня интернет-провайдеров и столкнулся с интересной (своего рода философской) проблемой.
Глядя на количество конечных точек, которые должна обрабатывать система (около 20 тыс.), Я немного волновался, что произойдет, когда мне нужно будет настроить / сформировать трафик большего числа пользователей. Поскольку в настоящее время я использую дерево формирования HFSC (см. Tc-hfsc, в основном такая же, но крутая вещь, как более известный HTB) для всей сети, мне нужно было бы использовать больше ClassID (очевидно, по крайней мере, по одному для каждого пользователя в сеть). Проблема, которую я обнаружил, заключалась в том, что идентификаторы TC ClassID в некотором роде ограничены - это 16-битные числа, что дает мне возможное максимальное количество пользователей 64k, сформированных этим решением.
Точно так же, если я хочу эффективно управлять фильтрами TC (например, не использовать метод «очистить все»), мне нужно иметь возможность удалять или изменять отдельные записи фильтров. (Я использую что-то похожее на хеш-таблицу из LARTC [1]). Опять же, единственный метод, который, похоже, работает с этим, - это пронумеровать все фильтры с использованием индивидуальных приоритетов (tc filter add dev ... prio 1). Нет другого параметра, который можно было бы использовать для этой цели, и, к сожалению, prio также поддерживает только 16 бит.
Мой вопрос следующий: существует ли какой-нибудь хороший метод для увеличения доступного «пространства идентификаторов», например 32-битный clsid для команды 'tc class' и 32-битные приоритеты (или любые другие дескрипторы модификации) для 'tc filter' команда?
Огромное спасибо,
-мк
(Между прочим, я надеюсь, что это не пойдет по сценарию «64k пользователей должно хватить для всех» ...)
Я думаю, что вы не должны помещать пользователей 64k с классами и фильтрами для каждого из них в один и тот же интерфейс. Вы можете повторить обработчики для каждого интерфейса, который у вас есть, поэтому добавьте больше интерфейсов. Для этого вам понадобится невероятная работа / сервер / сетевая карта. Если сервер выйдет из строя, у вас будет 64k пользователей в автономном режиме (и он легко выйдет из строя с таким объемом трафика). Не забывайте, что КАЖДЫЙ пакет, который проходит через вашу сетевую карту, будет проверяться и классифицироваться фильтром и отправляться в класс для постановки в очередь. Это большая работа для сетевой карты шлюза ISP с 64 КБ клиентов. В основном со всем видеопотоком, который у нас есть сейчас (который сложно правильно поставить в очередь).
Вы можете разделить обработку трафика на две машины (используя третью) вместо обработки всего трафика на одной машине. Трафик можно маршрутизировать просто на основе IP-адреса источника. Таким образом, у вас будет оптимально 10 тыс. Пользователей, если вы сможете равномерно разделить диапазон (-ы) IP-адресов.
Конечно, при необходимости вы можете использовать более двух машин. Думаю, это может быть лучше, чем исправление ядра Linux и другие хаки. Короче говоря, формирование трафика будет распределено на несколько машин. Центральный узел просто перенаправит трафик на правильный узел обработки.