Миф о бесполезности QoS без перегрузки сети

По работе я пару раз сталкивался с воззрением, что настраивать QoS в не перегруженной ethernet сети не надо для удачного функционирования таких сервисов, как IPTV и VoIP. Это мировоззрение стоило мне и моим сотрудникам многих нервных клеток и часов на диагностику фантомных заморочек, поэтом постараюсь как можно проще поведать о том, почему это мировоззрение ошибочно.

Меня зовут Владимир и я работаю сетевым инженером в одном из маленьких ISP в Санкт-Петербурге. Одним из оказываемых нами сервисов является L2VPN под транспорт IPTV потоков. На примере этого сервиса я буду вести рассказ.

Начинается всё с воззвания в техподдержку от клиента-оператора с жалобой на качество IPTV — картина сыпется («артефакты»), теряется звук, в общем стандартный набор. IPTV у нас в сети классифицируется в очередь assured forwarding, потому диагностика состоит в том, чтоб пробежаться по железякам на маршруте и проверить, что в AF очереди на egress нет утрат, а на ingress нет физических ошибок. После чего мы бодро рапортуем клиенту, что в нашей зоне ответственности утрат не найдено, советуем клиенту находить делему у себя либо поставщика IPTV, и идём пить чай с печеньем.

Но клиент давит и продолжает настаивать, что повинны мы, а у него всё отлично. Мы проверяем всё ещё раз, смотрим правильность классификаторов и маркировку пакетов от клиента, завязывается диалог и на каком-то шаге задаём вопрос «а как у вас сконфигурирован QoS на сети?», на что получаем ответ «никак, у нас интерфейсы даже на 50% не загружены потому нам QoS не нужен». Тяжёлый вздох и поехали.

Обычно график загрузки на который все глядят имеет интервал в 5 минут. Если «real time» — то несколько секунд, начиная от 1. К огорчению и к счастью, современное сетевое оборудование оперирует периодами не в 5 минут и не в 1 секунду даже, а пикосекундами. То, что в течении секунды интерфейс не был загружен на 100%, не означает, что он точно так же не был загружен и в течении нескольких миллисекунд.

Тут мы приходим к концептуальному понятию — микроорганизмёрст(microburst). Это таковой очень маленький период времени, когда количество принимаемых устройством данных становится больше чем интерфейс способен выслать.

Обычно 1-ая реакция — как так?! Мы же живойём в эру высокоскоростных интерфейсов! 10Gb/s уже повседневность, 40 и 100Gb/s внедряется везде, а мы ждём уже 1Tb/s интерфейсы.

По сути, чем выше скорость интерфейсов, тем жёстче становятся микроорганизмёрсты и их эффект на сеть.

Механизм появления очень прост, я его рассмотрю на примере трёх 1Gb/s интерфейсов, где трафик из 2-ух из их уходит через 3-ий.

Миф о бесполезности QoS без перегрузки сети

Это единственное нужное условие для появления микроорганизмёрста — чтоб скорость входящих (ingress) интерфейсов превосходила скорость исходящего (egress) интерфейса. Ничего не припоминает? Это обычная схема уровня агрегации в ethernet сети — огромное количество портов (ingress) сливают трафик в один аплинк (egress). Так строят сети полностью все — от операторов связи до дата-центров.

У каждого egress интерфейса есть очередь отправки tx-ring, которая представляет из себя кольцевой буфер. Туда складываются пакеты для отправки в сеть и конечно этот буфер имеет конечный размер. Но у ingress интерфейсов на отправляющей стороне тоже есть такие же кольцевые буферы, которые обеспечивают такой-же line-rate. Что произойдёт, если они начнут отправлять трафик сразу? У нашего egress интерфейса не хватит места в его tx-ring, потому что заполняться он будет вдвое резвее, чем он способен отправлять пакеты. Оставшиеся пакеты необходимо кое-где хранить. В общем случае это другой буфер, который мы называем очередью (queue). Пока в tx-ring нет места, пакет хранится в очереди и ждёт свободного места в tx-ring. Но вот неудача — у очереди память тоже конечна. Что произойдёт, если ingress интерфейсы работают на line-rate довольно длительно? Память в очереди тоже завершится. В данном случае новенькому пакету уже негде храниться, и он будет отброшен — такая ситуация именуется tail drop.

Сколько времени необходимо, чтоб таковой сценарий стал реальностью? Давайте посчитаем.

Самое сложное — это отыскать ёмкость буфера интерфейса. Вендоры не очень интенсивно публикуют такую информацию. Но возьмём, для примера, период в 200ms — подольше держать пакет в очереди обычно смысла не имеет, ну и это уже сильно много.

Для 1Gb/s интерфейса нам будет нужно (1000000000 * 0.2) / 8 = 25MB памяти. Сколько времени необходимо работать на line-rate двум 1Gb/s интерфейсам, чтоб стопроцентно забить буфер? 200ms. Это время за которое передаются 25MB со скоростью 1Gb/s. Да, ingress интерфейсов то у нас два, но egress интерфейс то тоже без дела не посиживает и посылает данные с той же скоростью, потому 200ms.

Это сравнимо много. А 10Gb/s ingress интерфейсу сколько времени пригодится чтоб перегрузить 200ms буфер 1Gb/s интерфейса? ~22ms. Это уже осязаемо меньше.

А сколько необходимо памяти, чтоб хранить 200ms для 10Gb/s интерфейса? Уже 250MB. Это не то чтоб много по современным меркам, но ветер дует конкретно в эту сторону — скорости вырастают, и чтоб сохранять глубину буфера требуется всё больше и больше памяти, что выливается в инженерные и экономические трудности, а чем меньше буфер тем резвее микроорганизмёрст забьёт его.

Выходит нескончаемый вопрос для инженеров вендоров — сколько памяти давать интерфейсу в железе? Много — недешево и любая последующая миллисекунда становится бессмысленнее и бессмысленнее. Не достаточно — микроорганизмёрсты будут приводить к огромным потерям пакетов и жалобам от клиентов.

Для других сценариев сможете посчитать сами, но результат всегда один и тот же — на сто процентов забитая очередь и tail drops, а на графике полкой интерфейса и близко не пахнет, причём на любом периоде — что в 5 минут, что в 1 секунду.

Эта ситуация в пакетных сетях неминуема — интерфейс проработает на line-rate меньше секунды, а утраты уже будут. Единственный метод её избежать — строить сеть так, чтоб ingress скорость никогда не превосходила egress скорость, а это непрактично и нереально.

Предстоящая логика уже выслеживается и довольно явна. Утраты пакетов есть, а QoS не настроен — приоритетный трафик никак не классифицируется и не отличается от другого трафика, и попадает в одну общую очередь, где он имеет равные шансы быть дропнутым.

Что делать? Настраивать QoS. Непременно систематизировать приоритетный трафик и помещать его в отдельную очередь которой выделять бОльший объём памяти. Изменять методы отправки пакетов так, чтоб приоритетные пакеты попадали в tx-ring ранее других — таким макаром их очередь будет очищаться резвее.

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

Assured forwarding(AF) — «подержи но доставь». В AF очередь классифицируется трафик, который просит гарантированной доставки, но не чувствителен к задержкам. Этой очереди выделен большой объём памяти, но даётся сравнимо не много места в tx-ring, и пакеты туда попадают позднее других. Броский пример такового трафика это IPTV — он буферизиуется на клиенте(VLC либо STB), потому его можно задержать, но утрата перевоплотится в артефакт изображения.
Expedited forwarding(EF) — «доставь одномоментно либо выброси». Этой очереди выделятся минимум(либо вообщем никакой) памяти для очереди, но выставляется высший ценность для попадания в tx-ring, чтоб пакет был выслан как можно резвее. Пример трафика — VoIP. Глас нельзя доставить поздно, по другому и кодек телефонии не сумеет его корректно собрать — абонент услышит кваканье. В то же время утраты отдельных пакетов на общем качестве голоса очень не сказываются — он у людей итак не безупречный.
Есть ещё network control(NC) и best effort(BE), для управления сетью и всего остального соответственно, а трафик бывает ещё, к примеру, телеконференции, который представляет из себя гибрид меж VoIP и IPTV, но это уже совсем отдельная тема, и настраивать QoS для их следует раздельно в каждой сети, зависимо от топологии и иных причин. Всё вкупе в целом это смотрится приблизительно так(картина с веб-сайта Cisco):

Миф о бесполезности QoS без перегрузки сети

Надеюсь сейчас вы будете настраивать QoS в собственной сети?

Аналогичный товар: Комментирование на данный момент запрещено, но Вы можете оставить ссылку на Ваш сайт.

Комментарии закрыты.