Назад | Перейти на главную страницу

tc prio qdisc для приоритизации трафика mysql

Я уже несколько часов борюсь с 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

Объяснение:

  1. создайте приоритетный qdisc с именем 1:
  2. добавить фильтр, соответствующий порт 22 -> диапазон 1
  3. добавить еще один фильтр, соответствующий порту 3306 -> диапазон 1
  4. и другой протокол сопоставления фильтров 1 (icmp) -> полоса 1

Вы можете указать "u32 match src" или указать вид спорта или любой протокол.

Qdisc pfifo_fast по умолчанию уже должен быть способен делать то, что вам нужно, подчиняясь битам ToS. Таким образом, другим решением, вообще не вмешиваясь в tc, было бы просто настроить демоны ssh и MySql для установки битов ToS в их трафике.