Я уже несколько часов борюсь с tc prio qdisc. Я прочитал документацию lartc, примеры и инструкции, но все это для меня немного ново и немного сбивает с толку :)
Итак, это мой сценарий: пара файловых серверов, обслуживающих большой объем трафика http и ftp. Мне нужно расставить приоритеты трафика mysql, потому что часто, когда ссылки заполнены, трафик sql становится медленным и / или искаженным, что приводит к ошибкам подключения, тайм-аутам и так далее.
Вот что у меня есть:
# tc qdisc add dev eth0 root handle 1: prio
# tc filter add dev eth0 protocol ip parent 1: prio 1 u32 match ip dport 22 0xffff flowid 1:1
# tc filter add dev eth0 protocol ip parent 1: prio 1 u32 match ip dport 3306 0xffff flowid 1:1
# tc filter add dev eth0 parent 1: prio 3 protocol all u32 match u32 0 0 flowid 1:3
# tc -s qdisc ls dev eth0
qdisc prio 1: root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
Sent 125836067 bytes 87549 pkt (dropped 0, overlimits 0 requeues 347)
backlog 0b 0p requeues 347
Если я не ошибаюсь в документации lartc, это должно поместить трафик ssh и mysql в приоритетную полосу 1, а все остальное - в приоритетную полосу 3, согласно документам, prio qdisc имеет 3 полосы по умолчанию, нижние полосы должны иметь более высокий приоритет
Может ли кто-нибудь подтвердить или опровергнуть это или у вас есть другие мысли? Я не хочу тестировать это на производственных системах, прежде чем я буду абсолютно уверен, что он будет работать. Меня отталкивает статистика, так как она не показывает четкого разделения трафика
edit: я только что провел еще несколько тестов с этой конфигурацией, выполнил ping на сервере, загрузил ссылки, ping идет от 40 мс до 170 мс. Делая это:
# tc filter add dev eth0 protocol ip parent 1: prio 1 u32 match ip protocol 1 0xff flowid 1:1
Пинг снижается до 40 мс, так что это может уже работать :)
edit2: после еще нескольких тестов я пришел к следующему:
tc qdisc add dev eth0 root handle 1: prio
tc filter add dev eth0 protocol ip parent 1: prio 1 u32 match ip dport 22 0xffff flowid 1:1
tc filter add dev eth0 protocol ip parent 1: prio 1 u32 match ip dport 3306 0xffff flowid 1:1
tc filter add dev eth0 protocol ip parent 1: prio 1 u32 match ip protocol 1 0xff flowid 1:1
для сопоставления «любого другого трафика» можно использовать:
tc filter add dev eth0 protocol ip parent 1: prio 2 u32 match ip src 0/0 flowid 1:2
или
tc filter add dev eth0 parent 1: prio 2 protocol all u32 match u32 0 0 flowid 1:2
но я обнаружил, что не указание фильтра «поймать все» тоже работает, похоже, что диапазон приоритета по умолчанию уже низкий.
В заключение, вот простое решение для приоритетного трафика на основе любого параметра без ограничения пропускной способности.
tc qdisc add dev eth0 root handle 1: prio
tc filter add dev eth0 protocol ip parent 1: prio 1 u32 match ip dport 22 0xffff flowid 1:1
tc filter add dev eth0 protocol ip parent 1: prio 1 u32 match ip dport 3306 0xffff flowid 1:1
tc filter add dev eth0 protocol ip parent 1: prio 1 u32 match ip protocol 1 0xff flowid 1:1
Объяснение:
Вы можете указать "u32 match src" или указать вид спорта или любой протокол.
Qdisc pfifo_fast по умолчанию уже должен быть способен делать то, что вам нужно, подчиняясь битам ToS. Таким образом, другим решением, вообще не вмешиваясь в tc, было бы просто настроить демоны ssh и MySql для установки битов ToS в их трафике.