Я хотел бы добавить какое-то управление трафиком к нашей интернет-линии. После прочтения большого количества документации я думаю, что HFSC слишком сложен для меня (я не понимаю всего, что связано с кривыми, боюсь, я никогда не пойму это правильно), CBQ не рекомендуется, и в основном HTB - это способ пойти для большинства людей.
Наша внутренняя сеть имеет три «сегмента», и я хотел бы более или менее равномерно распределить пропускную способность между ними (по крайней мере, в начале). Кроме того, я должен расставить приоритеты для трафика в соответствии с как минимум тремя видами трафика (трафик в реальном времени, стандартный трафик и объемный трафик). Совместное использование полосы пропускания не так важно, как тот факт, что трафик в реальном времени всегда следует рассматривать как премиальный трафик, когда это возможно, но, конечно, никакой другой класс трафика также не может голодать.
Вопрос в том, что имеет больше смысла, а также гарантирует лучшую пропускную способность в реальном времени:
Создание одного класса для каждого сегмента, каждый из которых имеет одинаковую скорость (приоритет не имеет значения для классов, которые не являются листьями по мнению разработчика HTB), и каждый из этих классов имеет три подкласса (листья) для 3 уровней приоритета (с различными приоритетами и разные тарифы).
Наличие одного класса для каждого уровня приоритета сверху, каждый из которых имеет разную скорость (опять-таки приоритет не имеет значения), и у каждого есть 3 подкласса, по одному на сегмент, тогда как все 3 в классе реального времени имеют самый высокий первичный уровень, самый низкий первичный уровень в основной массе. класс и тд.
Я постараюсь прояснить это с помощью следующего художественного изображения ASCII:
Case 1:
root --+--> Segment A
| +--> High Prio
| +--> Normal Prio
| +--> Low Prio
|
+--> Segment B
| +--> High Prio
| +--> Normal Prio
| +--> Low Prio
|
+--> Segment C
+--> High Prio
+--> Normal Prio
+--> Low Prio
Case 2:
root --+--> High Prio
| +--> Segment A
| +--> Segment B
| +--> Segment C
|
+--> Normal Prio
| +--> Segment A
| +--> Segment B
| +--> Segment C
|
+--> Low Prio
+--> Segment A
+--> Segment B
+--> Segment C
Случай 1 Похоже на то, как это делает большинство людей, но если я не буду правильно читать подробности реализации HTB, Случай 2 может предложить лучшую расстановку приоритетов.
В руководстве по HTB говорится, что если класс достиг своей скорости, он может заимствовать у своего родителя, а при заимствовании классы с более высоким приоритетом всегда сначала получают пропускную способность. Однако в нем также говорится, что классы, имеющие пропускную способность, доступную на более низком уровне дерева, всегда предпочтительнее, чем классы на более высоком уровне дерева, независимо от приоритета .
Давайте предположим следующую ситуацию: Сегмент C не отправляет трафик. Сегмент A отправляет только трафик в реальном времени, настолько быстро, насколько это возможно (достаточно для насыщения только одной ссылки), а сегмент B отправляет только объемный трафик настолько быстро, насколько это возможно (опять же, достаточно для насыщения только полной ссылки). Что случится?
Случай 1:
Сегмент A-> High Prio и Сегмент B-> Low Prio имеют пакеты для отправки, поскольку A-> High Prio имеет более высокий приоритет, он всегда будет планироваться первым, пока не достигнет своей скорости. Теперь он пытается заимствовать у Сегмента A, но поскольку Сегмент A находится на более высоком уровне, а Сегмент B-> Low Prio еще не достиг своей скорости, этот класс теперь обслуживается первым, пока он также не достигнет ставки и не хочет брать у Сегмент B. Как только оба достигли своих показателей, оба снова находятся на одном уровне, и теперь Сегмент A-> High Prio снова будет побеждать, пока не достигнет уровня Сегмента A. Теперь он пытается заимствовать у корня (который имеет много свободного трафика, так как Сегмент C не использует какой-либо гарантированный трафик), но опять же, он должен ждать, пока Сегмент B-> Low Prio также достигнет корневого уровня. Как только это произойдет,
Случай 2:
High Prio-> Segment A и Low Prio-> Segment B оба имеют пакеты для отправки, снова High Prio-> Segment A собирается выиграть, так как имеет более высокий приоритет. Как только он достигает своей скорости, он пытается заимствовать у High Prio, у которого есть запас пропускной способности, но, находясь на более высоком уровне, ему приходится снова ждать, пока Low Prio-> Segment B также достигнет своей скорости. Как только оба достигнут своей ставки и оба займут, High Prio-> Segment A снова победит, пока не достигнет уровня High Prio. Как только это происходит, он пытается заимствовать у root, у которого снова остается достаточно пропускной способности (в настоящее время вся пропускная способность Normal Prio не используется), но ему приходится снова ждать, пока Low Prio-> Segment B не достигнет предела скорости Низкий класс Прио, а также пытается позаимствовать у root. Наконец оба класса пытаются позаимствовать у root, приоритет учитывается, и High Prio->
Оба случая кажутся неоптимальными, так как в любом случае трафику в реальном времени иногда приходится ждать массового трафика, даже если для его заимствования достаточно большой полосы пропускания. Тем не менее, в случае 2 кажется, что трафик в реальном времени должен ждать меньше, чем в случае 1, так как он должен только ждать, пока не будет достигнут объемный трафик, который, скорее всего, меньше, чем скорость всего сегмента (и в случае 1 это скорость, которую он должен ждать). Или я тут совершенно не прав?
Я думал о еще более простых настройках, используя приоритет qdisc. Но приоритетные очереди имеют большую проблему в том, что они вызывают голод, если не ограничены каким-либо образом. Голодание не приемлемо. Конечно, можно поместить TBF (Token Bucket Filter) в каждый класс приоритетов, чтобы ограничить скорость и, таким образом, избежать голодания, но при этом один класс приоритета не может больше насыщать ссылку самостоятельно, даже если все другие классы приоритета пустые, TBF предотвратит это. И это также неоптимально, так как почему класс не получит 100% пропускной способности линии, если никакой другой класс не нуждается в этом в данный момент?
Любые комментарии или идеи относительно этой установки? Кажется, это так сложно сделать, используя стандартные tc qdiscs. Для программиста это было бы такой простой задачей, если бы я мог просто написать свой собственный планировщик (что мне не разрешено делать).