КорзинаПример второй. Приоритет одних, над другими.
Допустим, что мы администратор организации с небольшим количеством сотрудников.
Имеем исходные данные:
- WAN интерфейс с белым адресом (1.1.1.1) и входящей скоростью 32 мегабита в секунду.
- LAN — c подсетью 192.168.0.0/24 (Рабочие станции Директоров).
- LAN2 — c подсетью 192.168.1.0/24 (Рабочие станции Менеджеров).
В данном примере мы как раз, имеем один канал и две группы потребителей с разными приоритетами. Где директора имеют приоритет над менеджерами. Именно в этом случае для реализации данной схемы потребуется раздельная маркировка пакетов и раздельные очереди для групп пользователей.
Правила для маркировки:
/ip firewall mangle add action=mark-packet chain=forward comment=GROUP-A_DW disabled=no dst-address-list= GROUP-A new-packet-mark= GROUP-A_DW passthrough=yes;
/ip firewall mangle add action=mark-packet chain=forward comment=GROUP-B_DW disabled=no dst-address-list= GROUP-B new-packet-mark= GROUP-B_DW passthrough=yes;
Два правила для маркировки трафика с разными packet-mark и два списка для присвоения адресам принадлежности к группам.
/ip firewall address-list add address=192.168.0.0/24 disabled=no list=GROUP-A;
/ip firewall address-list add address=192.168.1.0/24 disabled=no list=GROUP-B;
Пришло время создать профили PCQ для очередей.
Сколько нужно профилей? По идее на загрузку хватит и одного профиля, но я всегда создаю по отдельному профилю на каждую группу и на каждое направление. Это позволяет иметь гибкие настройки на будущее, без дополнительного вмешательства в уже созданные правила и очереди.
/queue type add kind=pcq name= GROUP-A_DW pcq-burst-rate=0 pcq-burst-threshold=0 pcq-burst-time=10s pcq-classifier=dst-address pcq-dst-address-mask=32 pcq-dst-address6-mask=64 pcq-limit=50 pcq-rate=0 pcq-src-address-mask=32 pcq-src-address6-mask=64 pcq-total-limit=2000;
/queue type add kind=pcq name= GROUP-B_DW pcq-burst-rate=0 pcq-burst-threshold=0 pcq-burst-time=10s pcq-classifier=dst-address pcq-dst-address-mask=32 pcq-dst-address6-mask=64 pcq-limit=50 pcq-rate=0 pcq-src-address-mask=32 pcq-src-address6-mask=64 pcq-total-limit=2000;
Создаем дерево очередей:
Родительская очередь:
/queue tree add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=30M name=DOWNLOAD parent=global priority=8;
Потомки:
/queue tree add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=0 name= GROUP-A_DW packet-mark= GROUP-A_DW parent=DOWNLOAD priority=7 queue= GROUP-A_DW;
/queue tree add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=0 name= GROUP-B_DW packet-mark= GROUP-B_DW parent=DOWNLOAD priority=8 queue= GROUP-B_DW;
В данном примере нет ничего сложного, разница между очередями лишь в разных маркировках пакетов и разных приоритетах.
При низких скоростях данная схема будет прозрачно пропускать трафик через себя и любой из потребителей может получить все 30М указанных в родительской очереди.
При нехватке скорости в родительской очереди скорость начнет перераспределяться между потребителями по следующей схеме:
Группа с адресами GROUP-A_DW имеет более высокий приоритет (priority=7), ей будет отдана вся скорость родительской очереди (30M) и равномерно разделена между активными потребителями в пределах этой очереди.
Если данная группа не утилизировала весь доступный лимит скорости (30М), остатки этого лимита будут переданы в очередь с более низким приоритетом GROUP-B_DW (priority=8), где данные остатки будут равномерно разделены между активными потребителями в пределах этой очереди.
Если группа GROUP-A_DW утилизировала весь доступный лимит в 30 мегабит, группа GROUP-B_DW не получит вообще никакой скорости и никакой возможности передавать и получать пакеты из сети.
Для того чтобы группе с низким приоритетом оставалось хотя бы некоторое количество скорости, можно задать в очереди параметр limit-at=5M. Но данный параметр можно задать только совместно с параметром Max-Limit, ограничивать максимальную скорость группы нам не требуется — поэтому просто скопируем его из родительской очереди.
И вторая очередь после правок будет выглядеть так:
/queue tree add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=5M max-limit=30M name=GROUP-B_DW packet-mark=GROUP-B_DW parent=DOWNLOAD priority=8 queue=GROUP-B_DW;
В таком случае при нехватке скорости в родительской очереди, очередь с низким приоритетом будет всегда получать минимум 5 мегабит, которые сможет равномерно разделить между активными потребителями в пределах этой очереди.
Пример третий. Реализация тарифных планов с разделением на группы с разными приоритетами
Предположим, что мы субпровайдер с ограниченными финансовыми и техническими возможностями. У нас есть узкий канал в интернет, пара тарифных планов и две категории абонентов (физ.лица и юр.лица). Чаще всего, при предоставлении услуг юридическим лицам мы получаем от них большую выгоду, чем от физических лиц на тех же показателях скорости. Вместе с этим, мы предоставляем юридическим лицам некоторые дополнительные гарантии в виде гарантированной скорости и более оперативной технической поддержки.
Ну и как чаще всего бывает — мы немного увлеклись и подключили чуть больше абонентов, чем может вытянуть наш канал в интернет. По правильному — нужно расширить канал или подключить дополнительный с последующей балансировкой нагрузки. Но как уже было сказано, на это пока нет возможностей.
Но скорости в прайм-тайм не хватает, юридические лица начинают звонить и жаловаться на несоответствующую тарифному плану скорость, задержки пакетов, заикания телефонии и пр.
Частично облегчить данную ситуацию поможет шейпер с приоритетами как во втором примере, единственные отличия в том, что в данном примере скорость на одного абонента строго лимитирована и присутствует несколько тарифных планов.
Так же как и в предыдущих примерах, мы рассмотрим только входящую скорость. Однако во избежание путаницы в комментариях, именах маркировок и именах очередей будет присутствовать upload скорость.
Сокращения:
- FIZ — физическое лицо.
- UR — юридическое лицо.
- 1024K-1024K — Скорости по тарифу: Download-Upload.
- DW- Download.
- UL — Upload.
Маркировка пакетов:
/ip firewall mangle add action=mark-packet chain=forward comment=FIZ_1024K-1024K_DW disabled=no dst-address-list= FIZ_1024K-1024K new-packet-mark= FIZ_1024K-1024K_DW passthrough=yes;
/ip firewall mangle add action=mark-packet chain=forward comment=FIZ_3072K-3072K_DW disabled=no dst-address-list= FIZ_3072K-3072K new-packet-mark= FIZ_3072K-3072K_DW passthrough=yes;
/ip firewall mangle add action=mark-packet chain=forward comment=UR_1024K-1024K_DW disabled=no dst-address-list= UR_1024K-1024K new-packet-mark= UR_1024K-1024K_DW passthrough=yes;
/ip firewall mangle add action=mark-packet chain=forward comment=UR_3072K-3072K_DW disabled=no dst-address-list= UR_3072K-3072K new-packet-mark= UR_3072K-3072K_DW passthrough=yes;
Четыре правила маркировки, которые выдадут нам четыре потока помеченных пакетов, рассортированных по четырем тарифным планам (Два для физ.лиц и два для юр.лиц.)
Чтобы привязать абонента к определенному тарифному плану, нужно поместить его ip адрес в нужный адрес-лист:
/ip firewall address-list add address=192.168.0.1 disabled=no list= FIZ_1024K-1024K;
/ip firewall address-list add address=192.168.0.2 disabled=no list= FIZ_3072K-3072K;
/ip firewall address-list add address=192.168.0.3 disabled=no list= FIZ_3072K-3072K;
/ip firewall address-list add address=192.168.0.4 disabled=no list= UR_3072K-3072K;
/ip firewall address-list add address=192.168.0.5 disabled=no list= UR_3072K-3072K;
И т.д.
Теперь необходимо добавить необходимые профили для очередей:
/queue type add kind=pcq name= FIZ_1024K-1024K_DW pcq-burst-rate=0 pcq-burst-threshold=0 pcq-burst-time=10s pcq-classifier=dst-address pcq-dst-address-mask=32 pcq-dst-address6-mask=64 pcq-limit=50 pcq-rate=1M pcq-src-address-mask=32 pcq-src-address6-mask=64 pcq-total-limit=2000;
/queue type add kind=pcq name= FIZ_3072K-3072K_DW pcq-burst-rate=0 pcq-burst-threshold=0 pcq-burst-time=10s pcq-classifier=dst-address pcq-dst-address-mask=32 pcq-dst-address6-mask=64 pcq-limit=50 pcq-rate=3M pcq-src-address-mask=32 pcq-src-address6-mask=64 pcq-total-limit=2000;
/queue type add kind=pcq name= UR_1024K-1024K_DW pcq-burst-rate=0 pcq-burst-threshold=0 pcq-burst-time=10s pcq-classifier=dst-address pcq-dst-address-mask=32 pcq-dst-address6-mask=64 pcq-limit=50 pcq-rate=1M pcq-src-address-mask=32 pcq-src-address6-mask=64 pcq-total-limit=2000;
/queue type add kind=pcq name= UR_3072K-3072K_DW pcq-burst-rate=0 pcq-burst-threshold=0 pcq-burst-time=10s pcq-classifier=dst-address pcq-dst-address-mask=32 pcq-dst-address6-mask=64 pcq-limit=50 pcq-rate=3M pcq-src-address-mask=32 pcq-src-address6-mask=64 pcq-total-limit=2000;
Опять же я создал четыре профиля вместо двух, для сохранения гибкости настроек на будущее.
Далее построим дерево очередей:
Родительская очередь:
/queue tree add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=30M name=DOWNLOAD parent=global priority=8
Потомки:
/queue tree add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=0 name=FIZ_1024K-1024K_DW packet-mark=FIZ_1024K-1024K_DW parent=DOWNLOAD priority=8 queue= FIZ_1024K-1024K_DW;
/queue tree add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=0 name=FIZ_3072K-3072K_DW packet-mark=FIZ_3072K-3072K_DW parent=DOWNLOAD priority=8 queue= FIZ_3072K-3072K_DW;
/queue tree add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=0 name=UR_1024K-1024K_DW packet-mark=UR_1024K-1024K_DW parent=DOWNLOAD priority=7 queue= UR_1024K-1024K_DW;
/queue tree add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=0 name=UR_3072K-3072K_DW packet-mark=UR_3072K-3072K_DW parent=DOWNLOAD priority=7 queue= UR_3072K-3072K_DW;
При реализации данного примера все будет работать следующим образом:
При низких скоростях абоненты без проблем получают свою тарифную скорость, которая ограничена параметром pcq-rate. Но самое интересное, начинается, когда активных абонентов больше чем может выдать канал.
Родительская очередь ограничена 30 мегабитами.
Тарифные планы физических лиц и сами физические лица между собой равноправны. Тарифные планы юридических лиц и сами юридические лица тоже между собой равноправны. Но в связи с тем, что очередь юридических лиц имеет более высокий приоритет, отсюда следует, что и сами юридические лица с их тарифными планами тоже имеют более высокий приоритет — и они будут обрабатываться первыми.
Вся доступная скорость отдается в тарифы для юридических лиц, каждый такой абонент ограничен скоростью тарифа заданной в параметре pcq-rate. Тем не менее, если данные абоненты интенсивно работают и их потребление трафика превышает в сумме 30 мегабит, то получим такую картину:
30 мегабит будут разделены поровну между юридическими лицами, на основании текущего количества пакетов в каждой PCQ очереди. На самом деле объяснить данную ситуацию не так просто, но я попробую.
Предположим, что у нас все перечисленные юридические лица качают «по полной». В данный момент есть четыре абонента с тарифом в 1 мегабит и двенадцать абонентов с тарифом в 3 мегабита.
Но у нас всего 30 мегабит. Все бы было просто в случае одинаковых тарифных планов: 30 мегабит поровну поделились бы между абонентами и все. Но как будет распределена скорость, если тарифы у нас разные в пределах одной приоритетной группы.
Как распределится недостаток скорости?
В голову приходит два варианта развития событий, но лишь один из них верный.
Недостаток скорости будет распределен в процентном соотношении исходя из скорости тарифного плана. Примерно как то так:
Проверяем:
В принципе логично и относительно честно, только вот к сожалению данный сценарий будет обработан несколько иначе, а именно:
Вся доступная скорость (30 мегабит) будет распределятся равномерно, между участниками в равные единицы времени. Представьте чан с 30 литрами воды, из которого отходят трубки одинакового сечения и N- количество стаканов разных размеров на столе, в которые одновременно разливают ограниченный объем воды одинаковыми струйками. В нашем примере самый маленький стакан имеет объем один литр, стакан побольше — три литра. (Три литра! Карл!) Как только мелкие стаканы будут наполнены — в них перестают лить воду. Вся оставшаяся вода будет продолжать разливаться в более крупные стаканы. Если и после этого вода в чане останется — она будет разлита в стаканы на другом низкоприоритетном столе. Но воды, то у нас не хватает даже на один стол.
Сложные вычисления:
Первый этап, первый временной промежуток:
Второй этап, второй временной промежуток:
В связи с тем, что стаканов более трех литров в примере нет — просто разделим остатки воды между трехлитровыми стаканами.
14 литров / 12 стаканов= 1,1666666666666666666666666666667
Итог вычислений:
Тоже самое если использовать простые вычисления:
(30 литров — 1 литр * 4) / 12 =2,16
Если внимательно посмотреть на оба примера (неправильный и верный) можно увидеть что в первом примере общая нехватка скорости по тарифу у всех ровно четверть от заявленной скорости и пострадали все тарифы одинаково. Во втором случае мелкие тарифные планы не почувствовали нехватки и получили заявленную скорость, однако тарифы с более высокой скоростью ощутили нехватку почти на треть.
Исходя из излишне-изложенной и не самой удачной метафоры, можно условно сказать, что тарифы с низкими скоростями имеют некий приоритет над тарифами с более высокими скоростями, при нехватке скорости, даже с одинаковым приоритетом.
Да это не совсем честно, но, к сожалению, данное поведение шейпера никак нельзя изменить. Вот на этом моменте точка зрения господина Шарикова резко ушла в аут. Страдать будут не все равномерно, а лишь те, кто имеет более веселый тарифный план. Ну и как водится чем больше скорость — тем больше платит абонент. Если данная ситуация еще более-менее допустима с физ.лицами, то с юр.лицами это даже досадным недоразумением назвать нельзя.
Ну да вернемся к дальнейшему обсуждению…
При данных условиях видно, что канала в 30 мегабит не хватает даже для обслуживания тарифных планов юридических лиц. Следовательно, пока юридические лица интенсивно получают данные, физические лица не получают вообще никакой скорости. Эту проблему можно решить заданием параметра limit-at, но в данном случае это еще сильнее снизит доступную скорость для юридических лиц.
Понятное дело, что подобная ситуация в реальности будет равна катастрофе. Но отодвинем катастрофу подальше и представим что юридических лиц не так много. А именно: 2 с тарифами в 1 мегабит и два с тарифами в 3 мегабита. И качают они «по полной».
Путем нехитрых вычислений (2*1 + 2*3 = 8, 30-8=22) понимаем, что после обслуживания юридических лиц, до очереди физических лиц дойдет всего 22 мегабита и разделятся они между ними согласно их тарифам. Если физических лиц слишком много и данной скорости на них не хватает — начнется дележка как в вышеописанном случае с большим количеством юридических лиц. Но как бы, ни хватало скорости физическим лицам, юридические лица будут обслужены первыми.
Пример четвертый. Приоритет одного типа трафика над другим
Дополнительно к классической системе приоритетов, когда поток разделен на несколько групп абонентов с разными приоритетами можно прикрутить дополнительные критерии разделения на приоритеты.
На эту тему можно спорить часами. Одни люди скажут, что при особых обстоятельствах, безусловно, стоит использовать приоритеты. И, конечно же, предоставят весомые аргументы в пользу данных решений. Другие начнут кричать про производительность и как бы этичность данного решения — мол, кто мы такие, чтобы решать за пользователя или абонента какой тип трафика ему важнее.
Я в этот дурацкий холивар никогда не влезал. Просто в виду большого опыта у меня своя точка зрения на этот счет. Все зависит от каждого конкретного случая и типа применения данной технологии.
Есть системы, в которых применение приоритетов только вредит общей работе — напрасно нагружает оборудование, следовательно, жрет электричество, мешает конечному пользователю самостоятельно определить какие либо проблемы с сетью (прим. — высокий приоритет icmp). Так же встречались системы на мыльницах с полностью загруженным маршрутизацией процессором, на который еще навешали приоритезацию и удивлялись, почему упала скорость.
Так же есть масса примеров, где данные решения нашли свое место и значительно улучшили работу сети и репутацию данных субпровайдеров. В некоторых случаях казалось, что применение приоритезации в каком-то конкретном случае было неоправданно (широкие каналы, всем всего хватает и данная фича просто нагружает процессор) тем не менее, при отвале сразу четырех аплинков из шести, скорости стало катастрофически не хватать. И эта якобы ненужная фича очень сильно снизила количество звонков в техническую поддержку. Да, существенно просела скорость загрузки торрентов тем не менее жалоб от «танкистов» на длинный пинг и лаги в игре не поступало.
Кроме всего этого, те люди у кого больше опыта знают, что под словом приоритезация понимается очень обширная тема и различные области применения. Думаю, что стоит перечислить основные типы:
Приоритезация по типу пользовательского трафика
Пользовательский поток делится на два, с разными приоритетами. Критериями разделения могут быть порты, протоколы, адреса назначения, адреса источники и целые подсети.
Производительность для высокого приоритета достигается за счет выделения дополнительной полосы скорости сверх тарифа абонента и более высокого приоритета очереди. Таким образом, абонент получает скорость тарифа под высокий приоритет + скорость тарифа под остальной трафик. По факту: абонент получает скорость тарифа умноженную на два. На практике, при свободном аплинке и полном использовании абонентом своей скорости по тарифу, абонент в среднем использует скорость тарифа+20%. При нехватке аплинка, низкоприоритетный трафик задерживается (полоса сужается), высокоприоритетный пропускается (отдельная полоса с более высоким приоритетом).
Приоритезация по направлению внешний внутренний
Пользовательский поток делится на два, с разными приоритетами. Критериями разделения обычно служат подсети. В одном потоке идет внешний трафик в мир, во втором внутренний или межабонентский трафик. Используется крайне редко, обычно в распределенных системах, состоящих из нескольких маршрутизаторов.
Приоритезация по направлению внешнего трафика Download Upload
Почти не используется в проводных сетях. Администраторы беспроводных сетей знают, что при односторонней передаче данных через радиооборудование (симплекс), скорость в разы выше чем при наличии встречного трафика (дуплекс). Чаще всего при наличии встречного трафика более 30% линк сильно деградирует.
Для примера:
В шестой версии ROS с ее изменениями (корневая очередь global и пометка в forward) появилась возможность контролировать дуплексный трафик с ограничением и снижением приоритета исходящего трафика от абонентов.
Данная теория в основном относится к B/G/N, при использовании оборудования работающего в AC режиме встречный трафик уже не так страшен.
Другие части:
- Mikrotik QOS в распределенных системах или умные шейперы. Часть 1.
- Mikrotik QOS в распределенных системах или умные шейперы. Часть 2.
- Mikrotik QOS в распределенных системах или умные шейперы. Часть 3.
- Mikrotik QOS в распределенных системах или умные шейперы. Часть 4.
© Григорьев Дмитрий https://habrahabr.ru/post/307214/
