Формирование трафика в Linux с HTB: странные результаты
Я пытаюсь настроить простое регулирование пропускной способности на сервере Linux, и я сталкиваюсь с тем, что кажется очень странным, несмотря на кажущуюся тривиальную конфигурацию.
Я хочу, чтобы трафик приходил на конкретный клиентский IP (10.41.240.240) до жесткого максимума 75 Кбит / с. Вот как я настроил формирование:
# tc qdisc add dev eth1 root handle 1: htb default 1 r2q 1
# tc class add dev eth1 parent 1: classid 1:1 htb rate 75Kbit
# tc class add dev eth1 parent 1:1 classid 1:10 htb rate 75kbit
# tc filter add dev eth1 parent 1:0 protocol ip prio 1 u32 match ip dst
10.41.240.240 flowid 1:10
Чтобы проверить, я запускаю загрузку файлов по HTTP с указанного клиентского компьютера и измеряю полученную скорость, глядя на Кб / с в Firefox.
Теперь поведение довольно загадочное: DL начинается с скорости около 10 Кбайт / с и продолжает набирать скорость, пока не стабилизируется на уровне около 75 Кбайт / с (килобайт, а не килобит, как настроено!). Затем, если я начну несколько параллельных загрузок одного и того же файла, каждая загрузка стабилизируется со скоростью около 45 Кбайт / с; суммарная скорость этих загрузок, таким образом, значительно превышает настроенный максимум.
Вот что я получаю, когда проверяю tc на предмет отладочной информации
[root@kup-gw-02 /]# tc -s qdisc show dev eth1
qdisc htb 1: r2q 1 default 1 direct_packets_stat 1
Sent 17475717 bytes 1334 pkt (dropped 0, overlimits 2782 requeues 0)
rate 0bit 0pps backlog 0b 12p requeues 0
[root@kup-gw-02 /]# tc -s class show dev eth1
class htb 1:1 root rate 75000bit ceil 75000bit burst 1608b cburst 1608b
Sent 14369397 bytes 1124 pkt (dropped 0, overlimits 0 requeues 0)
rate 577896bit 5pps backlog 0b 0p requeues 0
lended: 1 borrowed: 0 giants: 1938
tokens: -205561 ctokens: -205561
class htb 1:10 parent 1:1 prio 0 **rate 75000bit ceil 75000bit** burst 1608b cburst 1608b
Sent 14529077 bytes 1134 pkt (dropped 0, overlimits 0 requeues 0)
**rate 589888bit** 5pps backlog 0b 11p requeues 0
lended: 1123 borrowed: 0 giants: 1938
tokens: -205561 ctokens: -205561
Что я не могу понять на всю жизнь, так это то, что я получаю "скорость 589888bit 5pps" с конфигурацией "скорость 75000bit ceil 75000bit"? Почему эффективная ставка становится намного выше настроенной? Что я делаю неправильно? Почему он ведет себя так, как есть?
Пожалуйста, помогите, я в тупике. Спасибо, парни.
3 ответа
Попробуйте использовать этот пример вместо этого:
# tc qdisc add dev eth1 root handle 1: htb default 10
# tc class add dev eth1 parent 1: classid 1:1 htb rate 75Kbit
# tc class add dev eth1 parent 1:1 classid 1:10 htb rate 1Kbit ceil 35Kbit
# tc class add dev eth1 parent 1:1 classid 1:20 htb rate 35kbit
# tc qdisc add dev eth1 parent 1:10 handle 10: sfq perturb 10
# tc qdisc add dev eth1 parent 1:20 handle 20: sfq perturb 10
# tc filter add dev eth1 parent 1:0 protocol ip prio 1 u32 \
match ip dst 10.41.240.240 flowid 1:20
Это создает корзину htb с предельной скоростью 75 Кбит / с, затем под ней создаются два sfq (qdisc с честной очередью).
По умолчанию все будут в первой очереди с гарантированной скоростью 1 Кбит и максимальной скоростью 30 Кбит. Теперь ваш ip 10.41.240.240 будет гарантированно 35 Кбит и может занять до 75 Кбит, если используется невыбранный трафик. Два соединения с.240 должны иметь среднее значение и быть одинаковыми для каждого соединения, а соединение между.240 и не.240 будет параллельным с соотношением 35:1 между очередями.
Я вижу, что он был мертв с апреля... так что, надеюсь, эта информация все еще имеет ценность для вас.
Я думаю, что я вроде как решил проблему: мне нужно было привязать классы qdiscs/ к устройству IMQ, а не к устройству ETH. Как только я это сделал, шейпер начал работать.
Тем не мение!
Хотя я мог заставить формирователь ограничивать трафик, поступающий на машину, я не мог заставить его разделить трафик справедливо (даже при том, что я прикрепил SFQ к своему HTB).
Вот что произошло: я начал загрузку; он был ограничен до 75 Кбайт / с. Теперь, когда я начал вторую загрузку, вместо того, чтобы равномерно распределять трафик между двумя сеансами DL (35 КБ / с + 35 КБ / с), он только снизил скорость в первом сеансе и дал сеансу два скудные 500 Б / с. Через пару минут разделение установилось примерно на 65 Кбайт / с + 10 Кбайт / с. с негодованием это не честно!:)
Поэтому я разобрал свою конфигурацию, продолжил и установил ClearOS 5.2 (дистрибутив Linux с предварительно встроенной системой брандмауэра), который имеет модуль формирования трафика. Модуль использует настройку HTB + SFQ, очень похожую на ту, которую я настроил вручную.
Та же проблема справедливости! Общий лимит исполняется хорошо, но справедливости нет! - две загрузки имеют одинаковую пропорцию 65/15, а не 35/35.
Есть идеи, ребята?
Это может быть связано с этим:
От: http://www.shorewall.net/traffic_shaping.htm
Предупреждение для пользователей Xen
Если вы используете управление трафиком в dom0, а формирование трафика, по-видимому, не ограничивает исходящий трафик должным образом, это может быть связано с "разгрузкой контрольной суммы" в ваших domU. Проверьте вывод "shorewall show tc". Вот выдержка из вывода этой команды:
class htb 1:130 parent 1:1 leaf 130: prio 3 quantum 1500 rate 76000bit ceil 230000bit burst 1537b/8 mpu 0b overhead 0b cburst 1614b/8 mpu 0b overhead 0b level 0
Sent 559018700 bytes 75324 pkt (dropped 0, overlimits 0 requeues 0)
rate 299288bit 3pps backlog 0b 0p requeues 0
lended: 53963 borrowed: 21361 giants: 90174
tokens: -26688 ctokens: -14783
В приведенном выше выводе есть две очевидные проблемы:
- Показатель (299288) значительно превышает потолок (230000).
- Сообщается о большом количестве (90174) гигантов.
Эта проблема будет исправлена отключением "разгрузки контрольной суммы" в ваших domU с помощью утилиты ethtool. Смотрите одну из статей Xen для получения инструкций.