Linux TC класс / нумерация фильтров

В настоящее время я работаю над решением по формированию трафика для компаний уровня ISP, и пришел к интересной (своего рода философской) проблеме.

Глядя на количество конечных точек, которые должна обрабатывать система (что составляет около ~ 20 тыс.), Я немного беспокоился о том, что произойдет, когда мне понадобится настроить / настроить трафик большего числа пользователей. Поскольку в настоящее время я использую дерево формирования HFSC (см. Tc-hfsc, в основном то же самое, но более крутое, что и более известный HTB) для всей сети, мне нужно будет использовать больше ClassID (очевидно, по крайней мере один для каждого пользователя в сети). Проблема, которую я обнаружил, заключалась в том, что идентификаторы TC ClassID ограничены - это 16-битные числа, что дает мне возможный максимум 64 тыс. Пользователей, сформированных этим решением.

Точно так же, если я хочу эффективно управлять фильтрами TC (например, не используя «метод очистки всех»), мне нужно иметь возможность удалять или изменять отдельные записи фильтра. (Я использую что-то похожее на хеш-таблицу из LARTC [1]). Опять же, единственный метод, который, кажется, работает с этим, состоит в том, чтобы пронумеровать все фильтры, используя индивидуальные приоритеты (tc filter add dev ... prio 1). Нет другого параметра, который можно было бы использовать для этой цели, и, к сожалению, prio также работает только в 16-битном режиме.

Мой вопрос заключается в следующем: существует ли какой-нибудь хороший метод для расширения доступного «пространства идентификаторов», например, 32-битные clsid для команды 'tc class' и 32-битные приоритеты (или любые другие дескрипторы модификации) для 'tc filter' команда?

Огромное спасибо,

-MK

(Кстати, я надеюсь, что это не пойдет на сценарий "64k пользователей должно быть достаточно для всех" ...)

— экса
источник

Все эти значения хранятся в пространстве ядра, чтобы увеличить их, вам потребуется перекомпилировать ядро и утилиты пространства пользователя. Вы пробовали использовать 64-битное ядро? Они могут быть определены как 32-битные там.

— Хьюберт Карио

64-битное ядро использует те же размеры. Например, номер фильтра представляет собой целое число u32, которое состоит из верхней (протокол) и нижней части (prio), очевидно, 16 бит. Идентификаторы классов жестко закодированы как u16. Возможно, попробую спросить кого-нибудь на LKML.

— экса

даже если вы используете хеш для своих фильтров, у вас будет много проблем с вводом-выводом, если вы используете столько фильтров (я думаю, для восходящего и нисходящего потоков). Я потратил много времени и должен был пропатчить реализацию очередей в ядре, чтобы все работало без ksoftirqd. Я использовал патч от парня по имени Саймон Лодал, которого я встретил на LARTC 4 года назад. Взгляните на его патч mail-archive.com/lartc@mailman.ds9a.nl/msg16279.html . Вы можете попробовать отправить ему электронное письмо, потому что у него всегда есть очень обновленная версия (против последнего ядра) с ним.

— Паблюз

@Pabluez Большое спасибо, я постараюсь извлечь из этого максимум пользы.

— Ex

Я думаю, что ваше требование справедливо, но, как писал Паблюз, это, безусловно, связано с большим количеством изменений в ядре. Я не хочу говорить «вы делаете это неправильно», но я бы посоветовал вам проверить openflow, где нижние части обработки пакетов выполняются на уровне коммутатора, а применение политик выполняется в пользовательском программном обеспечении, предположительно работает в пространстве пользователя. Я не знаю, соответствует ли это вашему требованию, но это, безусловно, стоит исследовать.

— AndreasM

Ответы:

я думаю, что вы не должны помещать 64k пользователей с восходящими и нисходящими классами и фильтрами для каждого из них на одном интерфейсе. Вы можете повторить обработчики для каждого вашего интерфейса, поэтому добавьте больше интерфейсов. Вам понадобится невероятная работа / сервер / сетевая карта, чтобы иметь эти вещи. Если сервер выйдет из строя, у вас будет 64 тыс. Пользователей в автономном режиме (и при таком количестве трафика он будет легко падать). Не забывайте, что КАЖДЫЙ пакет, который проходит через вашу сетевую карту, будет проверен и классифицирован фильтром и отправлен в класс для постановки в очередь. Это большая работа для NIC шлюза ISP с 64 тыс. Клиентов. Главным образом со всем видео потоком, который у нас есть в настоящее время (который трудно поставить в очередь должным образом).

— Pabluez
источник

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

— Ex

Что касается первоначального вопроса, меня больше интересовали такие вещи, как добавление 5 разных классов для каждого пользователя, что позволило бы мне сделать действительно хорошую работу по QOS (например, обработку потоков и трафика в реальном времени отдельно), но в большинстве случаев это немыслимо в текущих условиях (с моими текущий случай использования ~ 20 тыс. конечных точек, я бы уже за пределом).

— Ex

Ладно, пересылка 10 Гбит - не проблема, проблема в том, что у нас много фильтров и классов 64k * 2 (взлеты и падения). Удачи, хотя: D

— Pabluez

Вы можете разделить обработку трафика на две машины (используя третью) вместо обработки всего трафика на одной машине. Трафик может быть направлен просто на основе IP-адреса источника. Таким образом, у вас будет оптимально 10 000 пользователей, если вы сможете равномерно разделить диапазон IP-адресов.

Конечно, вы можете использовать более двух машин, если это необходимо. Я думаю, что это может быть лучше, чем патчить ядро Linux и делать другие хаки. Короче говоря, формирование трафика будет распределено на несколько машин. Центральный узел просто перенаправит трафик на правильный обрабатывающий узел.

— Халед
источник