| Предыдущая версия справа и слеваПредыдущая версия | |
| dpi:dpi_options:use_cases:opt_uplink [2023/08/29 12:44] – elena.krasnobryzh | dpi:dpi_options:use_cases:opt_uplink [2024/09/26 15:29] (текущий) – внешнее изменение 127.0.0.1 |
|---|
| ====== opt_uplink ====== | ====== Оптимизируем использование 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|Сбор и анализ статистики по протоколам и направлениям]] |
| | * [[dpi:dpi_options:opt_shaping|Оптимизация использования внешних каналов доступа]] |
| | Дополнительные Модули: |
| | * Для приема, обработки и хранения NetFlow [[dpi:dpi_components:qoestor|программный продукт для сбора статистики QoE Store]].\\ |
| | * Для визуализации и построения отчетов [[dpi:dpi_components:dpiui|графический интерфейс 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|“Кэширование”]]. |
