| Linux Advanced Routing & Traffic Control HOWTO | ||
|---|---|---|
| Назад | Глава 9. Дисциплины обработки очередей для управления пропускной способностью | Вперед |
Классовые дисциплины широко используются в случаях, когда тот или иной вид трафика необходимо обрабатывать по разному. Примером классовой дисциплины может служить CBQ -- Class Based Queueing (дисциплина обработки очередей на основе классов). Она настолько широко известна, что многие идентифицируют понятие "Дисциплина Обработки Очередей" с названием CBQ, однако это далеко не так.
CBQ -- один из старейших алгоритмов и кроме того -- один из самых сложных. К сожалению он может далеко не все. Это может оказаться неожиданностью для тех, кто свято верит в то, что если какая-либо достаточно сложная технология распространяется без документации, то это лучшая технология из имеющихся вариантов.
Чуть ниже мы поближе рассмотрим CBQ и его альтернативы.
Когда трафик передается на обработку классовой дисциплине, он должен быть отнесен к одному из классов (классифицирован). Определение принадлежности пакета к тому или иному классу выполняется фильтрами. Очень важно понимать, что именно фильтры вызываются из дисциплины, а не наоборот!
Фильтры, присоединенные к дисциплине, возвращают результат классификации (грубо говоря -- класс пакета), после чего пакет передается в очередь, соответствующую заданному классу. Каждый из классов, в свою очередь, может состоять из подклассов и иметь свой набор фильтров, для выполнения более точной классификации свой доли трафика. В противном случае пакет обслуживается дисциплиной очереди класса.
Кроме того, в большинстве случаев классовые дисциплины выполняют шейпинг (формирование) трафика, с целью переупорядочивания пакетов (например, с помощью SFQ) и управления скоростью их передачи. Это определенно необходимо в случае перенаправления трафика с высокоскоростного интерфейса (например, ethernet) на медленный (например, модем).
Каждый из интерфейсов имеет одну исходящую корневую дисциплину. По-умолчанию это, упоминавшаяся ранее дисциплина -- pfifo_fast. Каждой дисциплине и каждому классу назначается уникальный дескриптор, который который может использоваться последующими инструкциями для ссылки на эти дисциплины и классы. Помимо исходящей дисциплины, интерфейс так же может иметь и входящую дисциплину, которая производит управление входящим трафиком.
Дескрипторы дисциплин состоят из двух частей -- старшего и младшего номеров, в виде: <старший>:<младший>. Корневой дисциплине общепринято присваивать дескриптор '1:', что эквивалентно записи '1:0'. Младший номер в дескрипторе любой дисциплины всегда '0'.
Старшие номера дескрипторов классов всегда дублируют старший номер дескриптора своего "родителя". Старший номер должен быть уникальным в пределах блоков настроек для входящего и исходящего трафиков. Младший номер должен быть уникальным в пределах дисциплины и ее классов.
Типичная иерархия может выглядеть следующим образом:
1: корневая дисциплина
|
1:1 дочерний класс
/ | \
/ | \
/ | \
/ | \
1:10 1:11 1:12 дочерние классы
| | |
| 11: | краевой класс
| |
10: 12: дисциплины
/ \ / \
10:1 10:2 12:1 12:2 краевые классы
Не дайте ввести себя в заблуждение! Вы не должны полагать, что ядро находится на вершине диаграммы, а
сеть под ней! Пакеты ставятся в очередь и извлекаются из очереди корневой дисциплиной, она единственная,
с которой работает ядро.
Порядок классификации некоторого пакета может быть представлен в виде цепочки, например:
1: -> 1:1 -> 1:12 -> 12: -> 12:2
Таким образом, пакет помещается в очередь, которая управляется дисциплиной, присоединенной к классу 12:2. В данном примере, к каждому узлу дерева присоединен фильтр, который принимает решение -- по какой ветви продолжить классификацию пакета. Но возможен и другой вариант:
1: -> 12:2
В этом случае, фильтр, присоединенный к корню, сразу же классифицировал пакет, как принадлежащий классу 12:2.
Когда ядро решает, что пора извлечь очередной пакет из очереди и передать его сетевому интерфейсу, оно посылает запрос на извлечение корневой дисциплине. Далее этот запрос передается по цепочке классу 1:1, а от него всем элементам одного уровня -- 10:, 11:, и 12:. В данном случае запрос полностью обходит все дерево, поскольку только класс 12:2 имеет пакет.
Проще говоря, вложенные классы "общаются" ТОЛЬКО со своими "родительскими" дисциплинами и никогда не работают напрямую с интерфейсом. Только корневая дисциплина получает запрос на извлечение пакета из очереди напрямую от ядра!
В результате, классы никода не получат запрос на извлечение раньше, чем это будет сделано их "родителями". А это как раз и есть то, что нам нужно: мы можем определить внутренний класс, который выполняет только планирование и дисциплину, которая отвечает за шейпинг.
Дисциплина PRIO фактически никак не ограничивает трафик, она лишь выполняет его классификацию на основе присоединенных к ней фильтров. Вы можете рассматривать дисциплину PRIO как более мощную версию pfifo_fast, в которой каждая из полос является отдельным классом, а не простой очередью FIFO.
Постановка пакета в очередь выполняется дисциплиной PRIO на основе фильтров, заданных вами. По-умолчанию создаются три класса. Эти классы по-умолчанию содержат обычные дисциплины FIFO, но они могут быть заменены дисциплинами любого типа, какие вам только доступны.
Когда необходимо извлечь пакет из очереди, то первым проверяется класс :1. Каждый последующий класс проверяется только в том случае, если в предыдущем нет ни одного пакета.
Эта дисциплина может с успехом применяться в тех случаях, когда необходимо "раскидать" трафик по приоритетам, основываясь не только на флагах TOS. Вы можете так же добавить другие дисциплины к предопределенным классам, что повысит возможности управления трафиком, по сравнению с pfifo_fast.
Поскольку данная дисциплина не имеет возможности шейпинга трафика, считаю своим долгом предупредить вас: используйте эту дисциплину только в том случае, если она полностью соответствует вашим требованиям, либо присоединяйте ее к классовым дисциплинам, которые могут выполнять шейпинг. Последнее замечание относится к владельцам кабельных модемов или DSL устройств.
Формально, дисциплина PRIO относится к разряду планировщиков типа Work-Conserving.
Применительно к данной дисциплине, утилита tc допускает следующие параметры:
Число создаваемых полос. Каждая полоса фактически является классом. Если вы изменяете это число, то вы должны так же изменить и следующий параметр.
Если ваша конфигурация не предусматривает наличие фильтров, выполняющих классификацию трафика, то дисциплина PRIO присваивает приоритеты по-умолчанию.
Все это работает точно так же, как и в случае с pfifo_fast.
Повторюсь еще раз, полоса 0 получит младший номер дескриптора -- 1! Полоса 1 -- 2 и так далее.
В качестве примера создадим такое дерево:
1: корневая дисциплина
/ | \
/ | \
/ | \
1:1 1:2 1:3 классы
| | |
10: 20: 30: дисциплины
sfq tbf sfq
полоса 0 1 2
Объемный трафик будет обслуживаться дисциплиной 30: , интерактивный -- 20: или 10:.
Конфигурирование:
# tc qdisc add dev eth0 root handle 1: prio
## Эта команда создаст классы 1:1, 1:2, 1:3
# tc qdisc add dev eth0 parent 1:1 handle 10: sfq
# tc qdisc add dev eth0 parent 1:2 handle 20: tbf rate 20kbit buffer 1600 limit 3000
# tc qdisc add dev eth0 parent 1:3 handle 30: sfq
Теперь посмотрим -- что у нас получилось:
# tc -s qdisc ls dev eth0
qdisc sfq 30: quantum 1514b
Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
qdisc tbf 20: rate 20Kbit burst 1599b lat 667.6ms
Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
qdisc sfq 10: quantum 1514b
Sent 132 bytes 2 pkts (dropped 0, overlimits 0)
qdisc prio 1: bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
Sent 174 bytes 3 pkts (dropped 0, overlimits 0)
Как видите, через полосу 0 уже "проскочил" какой-то трафик, пока отрабатывали наши команды!
Теперь выполним передачу достаточно большого объема данных неким инструментом, который корректным образом устанавливает флаги TOS и проверим еще раз:
# scp tc [email protected]:./ [email protected]'s password: tc 100% |*****************************| 353 KB 00:00 # tc -s qdisc ls dev eth0 qdisc sfq 30: quantum 1514b Sent 384228 bytes 274 pkts (dropped 0, overlimits 0) qdisc tbf 20: rate 20Kbit burst 1599b lat 667.6ms Sent 2640 bytes 20 pkts (dropped 0, overlimits 0) qdisc sfq 10: quantum 1514b Sent 2230 bytes 31 pkts (dropped 0, overlimits 0) qdisc prio 1: bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 Sent 389140 bytes 326 pkts (dropped 0, overlimits 0)На этот раз видно, что весь трафик был отправлен через дисциплину 30:, которая в нашем случае имеет наименьший приоритет. Чтобы убедиться в том, что интерактивный трафик поступает в высокоприоритетные полосы, выполним следующую команду:
# tc -s qdisc ls dev eth0
qdisc sfq 30: quantum 1514b
Sent 384228 bytes 274 pkts (dropped 0, overlimits 0)
qdisc tbf 20: rate 20Kbit burst 1599b lat 667.6ms
Sent 2640 bytes 20 pkts (dropped 0, overlimits 0)
qdisc sfq 10: quantum 1514b
Sent 14926 bytes 193 pkts (dropped 0, overlimits 0)
qdisc prio 1: bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
Sent 401836 bytes 488 pkts (dropped 0, overlimits 0)
Как видите, все работает правильно, весь трафик был отправлен в 10: -- через самую высокоприоритетную
дисциплину.
Как уже упоминалось ранее, CBQ -- одна из самых сложных дисциплин. Пожалуй я не погрешу против истины, если заявлю, что это самая объемная, самая непонятная и самая запутанная дисциплина организации очередей. Это не потому, что авторы алгоритма некомпетентны, а потому, что идеология этого алгоритма абсолютно не совпадает с идеологией Linux.
Кроме того, что эта дисциплина является классовой, она так же может выполнять и шейпинг трафика, правда именно эта ее сторона является самым слабым местом. Если вы попробуете ограничить 10 мегабитный канал величиной в 1 мегабит, то окажется, что соединение будет просто простаивать 90% всего времени. Вместо определения объема трафика, CBQ измеряет время в микросекундах между запросами и на основе полученного времени рассчитывается средняя загруженность канала.
Такой алгоритм работы не всегда дает нужные результаты. Например, что если сетевой интерфейс не может обеспечить полную загрузку канала на всю его возможную ширину, из-за некачественного драйвера? Как тогда правильно определить время простоя?
Проблема становится еще острее, если вам приходится иметь дело с такими вещами, как PPP через Ethernet или PPTP через TCP/IP. Эффективная пропускная способность в данном случае может быть определена как пропускная способность канала в пространство пользователя, а это величина очень не маленькая.
Те, кто близко сталкивался с CBQ отмечают, что эта дисциплина не всегда точна, и иногда допускает грубые просчеты при измерении времени.
Однако, в других случаях она показывает неплохие результаты. Прочитав этот документ, вы сможете сконфигурировать эту дисциплину и получить неплохие результаты в случае отказа от шейпинга.
Как уже говорилось выше, ограничение пропускной способности в CBQ выполняется за счет определения промежутка времени между прохождением соседних пакетов среднего размера.
В процессе работы измеряется эффективное время простоя, как экспоненциальное взвешенное среднее по скользящему окну. Кстати, UNIX рассчитывает величину loadaverage (средняя величина нагрузки) аналогичным способом.
Расчетное время простоя вычитается из взвешенного среднего, в результате получается величина avgidle. Полностью загруженный канал имеет величину avgidle равную нулю -- промежуток времени между пакетами точно совпадает с расчетным. В случае превышения заданного ограничения, величина avgidle становится отрицательной. Если превышение достигает некоторого порога, CBQ приостанавливает передачу.
С другой стороны, после нескольких часов простоя, величина avgidle может получиться слишком большой и это приведет к тому, что канал "распахнется" на всю ширину. Чтобы этого не происходило, величина avgidle ограничивается числом maxidle.
В случае перегрузки, теоретически, алгоритм CBQ должен приостанавить передачу на вычисленный временной интервал, потом передать следующую порцию данных и снова остановиться. Но в реализации алгоритма есть свои нюансы, смотрите ниже описание параметра minburst.
Рассмотрим параметры дисциплины CBQ, позволяющие настроить ограничение полосы пропускания:
Усредненный размер одного пакета. Совместно с величиной maxburst (которая измеряется в пакетах) используется для вычисления значения maxidle.
Физическая пропускная способность устройства. Необходима для вычисления времени простоя.
Время, необходимое на передачу пакета через интерфейс может увеличиваться с определенным шагом. Например, передача пакетов с размерами 800 и 806 байт займет одно и тоже время, а пакетов с размерами 810 байт -- немного больше. Данный параметр задает размер шага, с которым увеличивается расчетное время передачи. Чаще всего устанавливается значение '8'. Значение должно быть степенью числа 2.
Параметр используется для вычисления значения maxidle. Он задает количество усредненных пакетов, которые будут обработаны до того, как значение avgidle станет равным нулю. Параметр maxidle нельзя задать напрямую, только косвенно, с помощью этого параметра.
Как я уже говорил, в случае перегрузки, CBQ должна прекратить передачу данных. Идеальным решением является ожидание в течение расчетного промежутка времени, после этого передать один пакет и снова приостановить передачу. Однако, в Unix существует определенные сложности с измерением интервалов времен, короче 10 мс, потому лучше увеличить промежуток ожидания, после которого можно будет выполнить передачу уже не одного, а несколько пакетов, количество которых определяется параметром minburst. Соответственно, промежуток ожидания между передачей пакетов увеличивается пропорционально значению данного параметра.
Промежуток времени между передачей пакетов называется offtime. Большие значения параметра minburst позволяют более точно ограничить полосу пропускания на длительных временных интервалах, но на коротких интервалах трафик будет вести себя скачкообразно.
Отрицательное значение avgidle указывает, что канал перегружен, и нужно прекратить передачу на время, пока avgidle не увеличится достаточно для передачи следующего пакета. Однако, это может вызвать длительные периоды ожидания после интенсивных всплесков трафика. В таких случаях avgidle присваивается значение параметра minidle.
Величина minidle измеряется в отрицательных микросекундах, следовательно значение "10" говорит о том, что параметр avgidle не может опуститься ниже -10 микросекунд.
Минимальный размер пакета -- необходим, поскольку даже "пустой" пакет дополняется до 64 байт для передачи по сети ethernet, и передача такого пакета занимает определенное время. Алгоритм CBQ должен знать минимальный размер, чтобы правильно рассчитать время простоя.
Желаемая величина пропускной способности. Для данной дисциплины -- это "педаль газа"!
Кроме ограничения полосы пропускания, CBQ имеет возможность классифицировать трафик, подобно дисциплине PRIO, и назначать классам приоритеты.
Каждый раз, когда нужно передать пакет, запускается процесс взвешенной циклической выборки (WRR) из очередей, начиная с высокоприоритетных классов. Классы группируются по приоритетам, затем, после выборки определенного количества данных из одного класса, выполняется попытка получить данные из другого класса с тем же приоритетом.
Следующие параметры позволяют управлять процессом выборки данных:
Когда производится выбор пакета для передачи, CBQ начинает опрашивать свои подклассы в соответствии с их приоритетами. Когда классу предоставляется возможность передачи, выбирается определенный объем данных. Базовая единица этого объема определяется параметром allot.
Приоритет. Дисциплина CBQ может присваивать классам приоритеты. Чем меньше значение -- тем выше приоритет. Пока не будет обработан трафик с высшим приоритетом, трафик с меньшим приоритетом не обрабатывается.
Вес. Каждому из имеющихся классов предоставляется возможность передать данные. Если у вас есть классы, которые значительно отличаются полосой пропускания, имеет смысл разрешить классам с большой пропускной способностью посылать за раз больше данных, чем классам с небольшой пропускной способностью
Дисциплина CBQ вычисляет сумму весов всех классов и затем нормирует их полученной величиной, потэому, в качестве весов, можно использовать любые значения: важно отношение этих значений. Обычно используется простое правило: вес = полоса пропускания / 10. Для определения количества данных, посылаемых классом за раз, нормированное значение умножается на величину allot.
Кроме простого ограничения полосы пропускания для определенных типов трафика, можно давать возможность классам занимать часть полосы пропускания у других классов.
У класса, созданного с параметром isolated, нельзя занимать полосу пропускания. То есть другие классы, настроенные на заем доступной полосы пропускания никогда не смогут занять полосу этого класса, даже если она будет свободной.
Наоборот, класс созданный с параметром sharing будет предоставлять неиспользуемую часть своей пропускной способности другим классам.
Эти два параметра определяют, может ли класс занимать пропускающую способность других классов. Параметр bounded запрещает, а borrow разрешает занимать неиспользуемую часть полосы пропускания классов, сконфигурированных с параметром sharing.
Внутри каждого такого класса могут находиться подклассы с опциями sharing и borrow. В этой ситуации заем будет выполняться в пределах родительского класса.
1: корневая дисциплина
|
1:1 дочерний класс
/ \
/ \
1:3 1:4 краевые классы
| |
30: 40: дисциплины
(sfq) (sfq)
Рассмотрим реализацию следующего сценария. Необходимо ограничить полосу пропускания веб-трафика до 5
мегабит, а SMTP -- до 3 мегабит. Суммарная полоса пропускания не должна превышать 6 мегабит. На
сервере стоит 100-мегабитная сетевая карта, классы могут занимать пропускную способность друг у друга.
# tc qdisc add dev eth0 root handle 1:0 cbq bandwidth 100Mbit \
avpkt 1000 cell 8
# tc class add dev eth0 parent 1:0 classid 1:1 cbq bandwidth 100Mbit \
rate 6Mbit weight 0.6Mbit prio 8 allot 1514 cell 8 maxburst 20 \
avpkt 1000 bounded
В этой части устанавливается корневая дисциплина и класс 1:1, пропускная способность которого
ограничена величиной в 6 мегабит.
Как видите, CBQ требует много больше настроек по сравнению с HTB.
# tc class add dev eth0 parent 1:1 classid 1:3 cbq bandwidth 100Mbit \
rate 5Mbit weight 0.5Mbit prio 5 allot 1514 cell 8 maxburst 20 \
avpkt 1000
# tc class add dev eth0 parent 1:1 classid 1:4 cbq bandwidth 100Mbit \
rate 3Mbit weight 0.3Mbit prio 5 allot 1514 cell 8 maxburst 20 \
avpkt 1000
Здесь создаются два класса, управляющие веб и почтовым трафиками. Обратите внимание на то, как
указаны веса классов. Пропускная способность классов не ограничивается, но они подчинены классу 1:1,
который имеет ограничение по полосе пропускания. Таким образом, сумма пропускных способностей этих
классов не сможет превысить ограничение родительского класса. Старшие номера дескрипторов дочерних
классов (classid) наследуют старший номер родительского класса.
# tc qdisc add dev eth0 parent 1:3 handle 30: sfq
# tc qdisc add dev eth0 parent 1:4 handle 40: sfq
При создании, к каждому из классов, по-умолчанию присоединяется дисциплина FIFO, однако, для более
равномерного распределения пропускной способности между соединениями, присоединим к каждому
из классов дисциплину обработки очереди SFQ.
# tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip \
sport 80 0xffff flowid 1:3
# tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip \
sport 25 0xffff flowid 1:4
В заключение, трафик классифицируется с помощью фильтров и направляется в нужные классы.
Обратите внимание: команда tc class add СОЗДАЕТ класс в пределах дисциплины, а tc qdisc add -- добавляет дисциплину к классу.
У вас может возникнуть резонный вопрос: "Что будет с трафиком, который не подпадает под условия установленных фильтров?". В этом случае трафик останется неклассифицированым и будет обработан корневой дисциплиной 1:0, т.е. пройдет без ограничений.
Если сумма SMTP+web трафиков превысят сконфигурированные 6 мегабит, то вся полоса пропускания будет разделена между классами, в соответствии с их весами. Таким образом WEB-сервер получит 5/8 ширины канала, а SMTP-сервер -- 3/8.
В соответствии с данной конфигурацией можно утверждать, что WEB-сервер всегда будет иметь полосу, как минимум 5/8*6=3.75 мегабита.
Как уже говорилось выше, для классификации трафика, полноклассовые дисциплины используют фильтры.
Но кроме фильтров, CBQ может предложить вам параметры split и defmap. Хотя назначение этих параметров достаточно сложно понять, и к тому же они не являются жизненно необходимыми, тем не менее я постараюсь описать их.
Так как наиболее часто классификация трафика производится только на основе поля TOS, в заголовке пакета, то предусматривается специальный синтаксис команд. Каждый раз, когда CBQ сталкивается с необходимостью определения -- в какую из очередей поставить пакет, она проверяет -- является ли этот узел "узлом разбиения" и если это так, то выбирается подочередь с заданным приоритетом, который может быть рассчитан исходя из значения поля TOS.
Значение приоритета пакета складывается по "И" с параметром defmap и проверяется -- есть ли совпадение. Проще говоря -- это самый простой способ создания высокоскоростных фильтров, которые работают с незначительным числом приоритетов. С параметром defmap, равным 0xFF будет совпадать любой пакет, 0x00 -- ни один. Возможно пример настройки поможет вам полнее понять вышесказанное:
# tc qdisc add dev eth1 root handle 1: cbq bandwidth 10Mbit allot 1514 \
cell 8 avpkt 1000 mpu 64
# tc class add dev eth1 parent 1:0 classid 1:1 cbq bandwidth 10Mbit \
rate 10Mbit allot 1514 cell 8 weight 1Mbit prio 8 maxburst 20 \
avpkt 1000
Самое обычное начало для CBQ. Значения для параметра defmap можно
определить из следующей таблицы:
TC_PRIO.. Число Значение поля TOS
-------------------------------------------------
BESTEFFORT 0 Maximize Reliablity (0x04) (Максисальная надежность)
FILLER 1 Minimize Cost (0x02) (Минимальная стоимость)
BULK 2 Maximize Throughput (0x08) (Максимальная пропускная способность)
INTERACTIVE_BULK 4
INTERACTIVE 6 Minimize Delay (0x10) (Минимальная задержка)
CONTROL 7
Уровень приоритета TC_PRIO.. рассчитывается исходя из значения поля TOS (за дополнительной информацией
о значениях приоритета пакета, обращайтесь к разделу pfifo_fast).
Теперь создадим классы, через которые пойдет интерактивный и объемный трафик:
# tc class add dev eth1 parent 1:1 classid 1:2 cbq bandwidth 10Mbit \
rate 1Mbit allot 1514 cell 8 weight 100Kbit prio 3 maxburst 20 \
avpkt 1000 split 1:0 defmap c0
# tc class add dev eth1 parent 1:1 classid 1:3 cbq bandwidth 10Mbit \
rate 8Mbit allot 1514 cell 8 weight 800Kbit prio 7 maxburst 20 \
avpkt 1000 split 1:0 defmap 3f
В данном случае "узлом разбиения" назначается дисциплина 1:0, это та точка, где будет делаться выбор.
Число 0xC0 в двоичном представлении имеет вид 11000000, а 0x3F -- 00111111, таким образом оба класса
перекрывают весь диапазон возможных приоритетов. Первому классу будут соответствовать пакеты, приоритеты
которых имеют 6 и/или 7 биты в установленном состоянии, что соответствует интерактивному и управляющему
трафику. Ко второму классу будут отнесены все остальные пакеты.
Таблица выбора для узла 1:0 теперь будет иметь следующий вид:
приоритет класс
0 1:3
1 1:3
2 1:3
3 1:3
4 1:3
5 1:3
6 1:2
7 1:2
Кроме того, можно изменять приоритеты отдельных видов трафика. Для этого используется команда вида:
tc class change, например, чтобы повысить приоритет трафика best effort и
классифицировать его, как принадлежащий классу 1:2, нужно дать следующую команду:
# tc class change dev eth1 classid 1:2 cbq defmap 01/01
В этом случае, таблица выбора будет иметь следующий вид:
приоритет класс
0 1:2
1 1:3
2 1:3
3 1:3
4 1:3
5 1:3
6 1:2
7 1:2
FIXME: Корректность работы команды tc class change не проверена. Выводы были сделаны
исключительно на основе изучения исходных текстов.
Мартин Девера (Martin Devera) aka <devik> справедливо отмечает, что CBQ слишком сложна и слабо оптимизирована для большинства типичных ситуаций. Его подход более точно соответствует конфигурациям, когда необходимо распределить заданную полосу пропускания между различными видами трафика на полосы гарантированной ширины, с возможностью заимствования.
HTB работает точно так же, как и CBQ, но, в отличие от последней, принцип работы основан не на вычислении времени простоя, а на определении объема трафика, что полностью соответствует названию Token Bucket Filter. Эта дисциплина имеет незначительное число параметров настройки, которые достаточно хорошо описаны на сайте http://luxik.cdi.cz/~devik/qos/htb/.
Хотя конфигурирование HTB -- задача достаточно сложная, тем не менее конфигурации хорошо масштабируются. В случае же с CBQ процесс конфигурирования становится слишком сложным даже в самых простых случаях! HTB3 теперь стала частью ядра (начиная с версий 2.4.20-pre1 и 2.5.31). Однако, вам может потребоваться пропатченная версия утилиты tc: старший номер версии HTB в ядре и пользовательских утилит должны совпадать, в противном случае tc откажется работать с HTB.
Если у вас установлено достаточно свежее или пропатченное ядро, вам определенно стоит посмотреть в сторону HTB!
Конфигурация практически идентична вышеприведенному примеру:
# tc qdisc add dev eth0 root handle 1: htb default 30
# tc class add dev eth0 parent 1: classid 1:1 htb rate 6mbit burst 15k
# tc class add dev eth0 parent 1:1 classid 1:10 htb rate 5mbit burst 15k
# tc class add dev eth0 parent 1:1 classid 1:20 htb rate 3mbit ceil 6mbit burst 15k
# tc class add dev eth0 parent 1:1 classid 1:30 htb rate 1kbit ceil 6mbit burst 15k
Автор рекомендует устанавливать дисциплину SFQ для этих классов:
# tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10
# tc qdisc add dev eth0 parent 1:20 handle 20: sfq perturb 10
# tc qdisc add dev eth0 parent 1:30 handle 30: sfq perturb 10
Добавим фильтры, которые будут выполнять классификацию трафика:
# U32="tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32"
# $U32 match ip dport 80 0xffff flowid 1:10
# $U32 match ip sport 25 0xffff flowid 1:20
В результате получаем ясную и понятную конфигурацию -- никаких малопонятных чисел, никаких
недокументированных параметров.
В HTB все выглядит достаточно прозрачно -- классы 10: и 20: имеют гарантированную пропускную способность, при наличии свободной части пропускной способности они заимствуют ее в отношении 5:3.
Неклассифицированый трафик будет отнесен к классу 30:, который имет достаточно небольшую ширину, но может заимствовать незанятую часть канала.
| Назад | В начало документа | Вперед |
| Терминология | К началу раздела | Классификация пакетов с помощью фильтров. |