07.05.2018 - HTB - Hierarchical Token Bucket на примере MikroTik

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

На современных предприятиях работают сотни, а может и тысячи сотрудников и каждому их них нужно обеспечить хорошие условия работы, стабильный доступ в интернет, гарантированную работу телефонии.

Вы наверно уже слышали о QoS (quality of service «качество обслуживания»). В интернете полно информации на примерах как его настраивать под тот или иной случай. Но просто копировать готовые примеры конфигураций адаптируя под свои задачи чревато ошибками и часами выискивания проблемы «почему все работает не совсем так как планировалось». Я считаю важно понимать теорию применения технологий, а под термином QoS технологий и способов их применений достаточно много.

В нашем примере рассмотрим теорию и несколько примеров на основе оборудования MikroTik, которое мы успешно внедряем нашим клиентам в рамках обслуживания компьютерного парка и сетевого оборудования.

Теория

 Давайте рассмотрим сначала основные понятия, которыми будем пользоваться в дальнейшем.

Шейпинг – технология которая позволяем управлять скоростью и качеством доступа в интернет (отбрасывать пакеты неудовлетворяющие условия), другими словами (от английского Shape - форма) это придания некой формы графику загрузки канала.

Schedulers – это алгоритмы которые управляют движением пакетов, то есть их задача формирование очередей по определённым правилам (приоритету, адресам назначения и отправителя и т.д.). Другими словами, это планировщик движения пакетов. И он идет перед шейпером.  Эти алгоритмы PFIFO, BFIFO, MQPFIFO, SFQ, PCQ, RED.

Дисциплина очереди - qdisc (Queuing discipline) это надстройка над шейпером и шедулером которая использует их в различных комбинациях и предполагает свои правила использования их. В микротике используется HTB «Hierarchical Token Bucket».

HTB

Дисциплина очереди HTB лежит в основе шейпинга микротика, также она реализована в Linux системах.

Главным понятием в HTB является класс «Hierarchical Token Bucket» – в самом понятии говориться о том, что это дисциплина создана чтобы строить гибкую иерархию классов.

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

Два или более класса, имеющие одного прямого родителя находятся на одном уровне и подсоединены к одной локальной выходной очереди.

На схеме выше изображена иерарха классов. Пакеты из файрволла попадают на нулевой уровень в классы Лист1 и Лист2 (мы их называем еще листьями как писали выше), после в зависимости от приоритета, загруженности канала они попадают в локальную очередь или передаются выше в родительскую.

Характеристики классов

1)      Name – имя класса.

2)      Parent – указывается родительский класс.

3)      Packet Marks – здесь можно выбрать промаркированный трафик.

4)      Queue Type – выбирается алгоритм очереди (PFIFO, BFIFO, MQPFIFO, SFQ, PCQ, RED)

5)      Priority – приоритет класса (от 1 до 8) 1 самый высший 8 низший.

6)      Bucket Size (ведро с болтами): принимает значение от 0.1 до 10.

7)      Limit-at – гарантированная скорость для этого класса.

8)      Max-limit – максимально доступная скорость для класса.

9)      Burst Limit – скорость которая будет доступна сразу при подключении (действует на класс)

10)   Burst Threshold – средняя скорость за последние burst-time секунд (действует на класс)

11)   Burst Time – время для подсчета Burst Threshold. (действует на класс).

Классы (очереди) могут быть в трех состояниях:

1)      Зеленые – это значит что канал занят меньше чем на 50 %

2)      Желтая – от 50% до 75%

3)      Красная – 75% и выше

Практика

Давайте посмотрим на примере как это работает.

Создадим несколько правил.

[admin@MikroTik] > /queue tree print

Flags: X - disabled, I - invalid

 0   name="Main_Lan" parent=global packet-mark="" limit-at=0 queue=default-small priority=8

     max-limit=50M burst-limit=0 burst-threshold=0 burst-time=0s bucket-size=0.1

 1   name="HTTP" parent=Main_Lan packet-mark=http_mark limit-at=20M queue=PCQ_HTTP priority=7

     max-limit=30M burst-limit=0 burst-threshold=0 burst-time=0s bucket-size=0.1

 2   name="TORRENT" parent=Main_Lan packet-mark=p2p-pmark limit-at=5M queue=PCQ_TORRENT priority=8

     max-limit=7M burst-limit=0 burst-threshold=0 burst-time=0s bucket-size=0.1

Клиенты передают (скачивают) данные (HTTP и Торрент) не превышающие значение limit-at. Для торрентов у нас 5 мб\с для http 20 мб\с.

Видим, что пакеты с http и torrent трафиком не передаются в родительский класс, а в соответствии с приоритетами выстраиваются в локальную очередь.

Вот так это выглядит в микротике.

Теперь давайте полностью загрузим две очереди.

Видим, что оба класса предают данные со скоростью Max Limit и у каждого есть гарантированная скорость передачи по Limit At по так как канал родительской очереди (класса) у нас не загружен то они передают со скоростью Max-limit.

Теперь давайте ограничим скорость до 25 мб\с у класса Main_Lan.

Видим, что классы отключились (визуально это не увидеть это алгоритм работы) от своих локальных очередей и так как не каких приоритетов для трафика и вообще нечего в классе Main_Lan не указанно кроме скорости Max Limit. То трафик с HTTP и TORRENT упирается в 25мб\с и выходит через родительскую очередь по своим приоритетам, но так как у них есть гарантированная скорость torrent трафик не отпускается ниже 5мб\с хоть он менее приоритетный и у HTTP есть право забрать весь канал так как в Limit Max у него 30мб\с, но он этого не делает из-за указанной гарантированной полосы.

Теперь давайте рассмотрим пример, когда не limit max не limit at не указан в классах torrent и http но приоритеты остались те же у торрента 8 у http 7.

Видим, что торрент без http пытается забрать весь канал (слабенький торрент нашел, не разгонялся больше 6-7 мб\с но нам и этого для примера хватит). Теперь пустим HTTP и посмотрим, что будет.

Что и следовало ожидать, HTTP занял весь канал так как он более приоритетный, а TORRENT почти не проходит и так будет продолжаться пока http не снизит скорость. Следует отметить что тот трафик, который не попадает под очереди является самым неприоритетным, это следует учесть при построении схем приоритезации. Вообще в такой схеме можно не делать отдельную очередь для торрента если нужен только приоритет, но если также хотим ограничить скорость торрента, то тогда этот пример подходит. В следующий статье рассмотрим практику как маркировать трафик, в какой цепочке его лучше брать и полностью разберем тот пример, который сегодня использовался для теории в этой статье.