| |
| dpi:dpi_options:use_cases:opt_uplink:start [2023/08/29 12:44] – создано elena.krasnobryzh | dpi:dpi_options:use_cases:opt_uplink:start [Дата неизвестна] (текущий) – удалено - внешнее изменение (Дата неизвестна) 127.0.0.1 |
|---|
| ====== Оптимизируем использование Uplink канала ====== | |
| {{indexmenu_n>1}} | |
| Как СКАТ поможет уменьшить затраты на аплинк на 25% и при этом повысить QoE? | |
| |
| ====Начальные условия:==== | |
| Если посмотреть на недельный график утилизации канала типичного домового оператора, | |
| то можно заметить, что максимум обычно приходится на часы наибольшей нагрузки (ЧНН), когда все отдыхают | |
| после рабочего дня и многие проводят свой досуг в интернет: скачивают и смотрят фильмы, | |
| музыку, посещают развлекательные порталы и т.п. | |
| <note important>Пик утилизации канала происходит около 23 часов и обычно длится меньше часа, превышая обычные показатели на 30%. | |
| При этом торрент-трафик в это время может занимать до 30% канала, еще около 50% - просмотр online видео, на все остальное приходится лишь 20%.</note> | |
| |
| ====Что хотим получить:==== | |
| <note important>Отложить расширение канала путем оптимизации полосы под разные типы трафика.</note> | |
| Велик соблазн не платить за “лишнюю” полосу, которая нужна всего лишь в течении часа и остальное время все равно не используется. Но если просто не заплатить, то в час пик пользователи заметят проблемы : начнутся лаги при просмотре видео, перестанут открываться сайты, будут тормозить онлайн игры и не проходить IP-звонки. На это оператор не пойдет: ведь это, можно сказать, прайм тайм и пользователям нужен качественный интернет именно в это время. Как же быть? Хочется и сэкономить, и в то же время чтобы пользователь ничего не почувствовал, да еще и спасибо сказал. | |
| |
| ====Инструменты:==== | |
| Опции СКАТ DPI, которые будем использовать: | |
| * [[dpi:dpi_options:opt_statistics:start|Сбор и анализ статистики по протоколам и направлениям]] | |
| * [[dpi:dpi_options:opt_shaping:start|Оптимизация использования внешних каналов доступа]] | |
| Дополнительные Модули: | |
| * Для приема, обработки и хранения NetFlow [[dpi:dpi_components:qoestor:start|программный продукт для сбора статистики QoE Store]].\\ | |
| * Для визуализации и построения отчетов [[dpi:dpi_components:dpiui:start|графический интерфейс DPIUI2]].\\ | |
| |
| ====Настройка:==== | |
| Разделим трафик на классы в зависимости от используемого протокола. Всего может быть назначено до 8 классов, которые СКАТ может использовать для маркировки пакетов как в поле DSCP/TOS IP-заголовков, так и поле приоритет VLAN/MPLS, и далее QOS может управлять внешняя платформа. Но мы рассмотрим случай, когда это делает сам СКАТ. | |
| В класс самого низкого приоритета поместим сервисы, которые мы согласны ограничить в часы пик. Обычно это сервисы, скорость которых и так зависит от внешних факторов, пользователь работает с ними не в режиме интерактивности, обычно в фоне. Это закачка файлов через торрент трекеры, сервисы обновления ПО и возможно что-то еще, специфичное для вашего случая. В класс с более высоким приоритетом поместим сервисы online-трансляций, которые обычно имеют возможность адаптироваться к доступной полосе пропускания и выбирать качество, и в класс с самым высоким приоритетом поместим интерактивные сервисы, работу которых пользователь контролирует в онлайн режиме и проблемы с которыми станут сразу заметны: это web браузинг, online игры, IP-телефония (SIP, Skype), в общем для простоты поместим в этот класс все остальное. | |
| Для каждого класса ограничим максимальную полосу пропускания, которую может занять трафик данного класса, или положимся на механизм заимствования полосы с автоматическим регулированием, заложенный в СКАТ. В последнем случае СКАТ начнет ограничивать трафик по классам только при приближении утилизации полосы входящего трафика к пороговому значению. Также ограничим полосу снизу, чтобы во время пиков трафик данного класса пострадал лишь в контролируемых пределах. | |
| |
| При превышении верхнего ограничения полосы для класса исходящий трафик данного класса ограничивается СКАТ, при этом уменьшение полосы распределяется между абонентами равномерно. В силу двустороннего режима работы большинства протоколов (запрос-ответ, передача-подтверждение) ограничение исходящего трафика приводит к ограничению входящего. | |
| В автоматическом режиме регулирования степень этого влияния определяется СКАТ через механизм обратной связи и сначала ограничению подвергается трафик минимального приоритета вплоть до достижения установленного минимального порога. Если такого ограничения не достаточно, то ограничение распространяется на трафик следующего приоритета и т.п. | |
| Оба режима позволяют задействовать механизм заимствования, когда неиспользуемая полоса распределяется между классами в соответствии с текущими потребностями и подвергается перераспределению, когда ее начинает не хватать. | |
| |
| ==== Пример конфигурации для приведенного выше описания ==== | |
| Создаем файл protocols.txt: | |
| <code> | |
| default cs0 | |
| mpeg cs1 | |
| bittorrent cs7 | |
| </code> | |
| |
| Конвертируем protocols.txt в protocols.dscp | |
| <code> | |
| cat protocols.txt|lst2dscp /etc/dpi/protocols.dscp | |
| </code> | |
| |
| Добавляем жесткие ограничения по классам в файл конфигурации /etc/dpi/fastdpi.conf, | |
| ориентируясь на график со статистикой (простое решение, но далеко не оптимальное) | |
| <code> | |
| #Limit outbound torrent | |
| tbf_class7=rate 50mbit | |
| #Limit inbound torrent | |
| tbf_inbound_class7=rate 50mbit | |
| </code> | |
| |
| Или позволим DPI выполнять приоритезацию протоколов по иерархии классов | |
| самостоятельно в пределах всей доступной полосы (требует подбора параметров | |
| верхних границ для учета всплесков трафика, чтобы ограничение происходило по приоритетам dpi, | |
| а не полкой, связанной с физическими возможностями канала, за отправную точку возьмем ширину канала минус 10%, | |
| для торрентов - минус 50%) | |
| <code> | |
| htb_inbound_root=rate 180mbit | |
| htb_inbound_class0=rate 100mbit ceil 180mbit | |
| htb_inbound_class1=rate 50mbit ceil 180mbit | |
| htb_inbound_class2=rate 8bit ceil 180mbit | |
| htb_inbound_class3=rate 8bit ceil 180mbit | |
| htb_inbound_class4=rate 8bit ceil 180mbit | |
| htb_inbound_class5=rate 8bit ceil 180mbit | |
| htb_inbound_class6=rate 8bit ceil 180mbit | |
| htb_inbound_class7=rate 10mbit ceil 100mbit | |
| htb_root=rate 180mbit | |
| htb_class0=rate 100mbit ceil 180mbit | |
| htb_class1=rate 50mbit ceil 180mbit | |
| htb_class2=rate 8bit ceil 180mbit | |
| htb_class3=rate 8bit ceil 180mbit | |
| htb_class4=rate 8bit ceil 180mbit | |
| htb_class5=rate 8bit ceil 180mbit | |
| htb_class6=rate 8bit ceil 180mbit | |
| htb_class7=rate 10mbit ceil 100mbit | |
| </code> | |
| |
| Рестартуем DPI | |
| <code> | |
| service fastdpi restart | |
| </code> | |
| |
| ====Результат:==== | |
| |
| Теперь во время пиков пострадает только трафик, менее критичный и заметный для пользователей, а работа важных для пользователя онлайн сервисов, проблемы в которых сразу видны, будет осуществляться, благодаря приоритезации, быстрее и с минимальными задержками. Нам удалось снизить требования к ширине канала, а работа с интернет, с точки зрения пользователей, стала шустрее. | |
| Бонус: | |
| Во время пиков трафика большая нагрузка ложится и на другое используемое оператором оборудование и оно может начать под нагрузкой вносить свои дополнительные проблемы – терять пакеты, увеличивать время отклика и т.п. Внедрение шейпинга СКАТ позволит предотвратить превышение критической нагрузки для оборудования, после которой возникают проблемы, и отложить необходимость его апгрейда на более поздний срок. | |
| |
| Хотите сэкономить на канале еще больше, тогда смотрите описание опции [[dpi:dpi_options:opt_cache:start|“Кэширование”]]. | |
| |
