Здравствуй, Хабр.

В данной статье речь пойдет о некоторых, но далеко не о всех, об эффективных и не очень, методах распределения трафика по каналам.

Если позволите, немного предыстории. Итак, предположим, Вы провайдер в небольшом далеком городе. Занимаетесь этим уже очень давно. Когда-то, каналы у вас были не большие, а интернет помегабайтный и всё было хорошо. С течением времени, вы заказываете канал(ы) пошире и начинаете считать уже не мегабайты, а скорость. Клиентская база растёт —> канал растет. И вот, вы достигаете того момента, когда больше ещё нельзя, а уже надо. Хотя подождите, больше конечно можно, но условия весьма и весьма не реальные. Такая ситуация далеко не везде, но мы имеем то, что имеем.


Что же делать?

Конечно, можно крутить гайки на тарифах, либо отрезать (ограничить, др.) какой-либо объемный трафик. На самом деле вариантов много, но вы заинтересованы в качестве предоставляемых пользователям услуг.

Как пытался решить проблему я?
Не могу похвастаться, что подошел к решению проблемы профессионально ввиду многих факторов, но что-то вышло и из моих попыток, о которых пойдет речь далее.

В наличии имелись несколько каналов: парочка медленных (latency), но широких (обслуживаемый поток данных), и быстрых, но узких (прошу простить за такие аналогии, мне так проще). Крутилось всё это дело на линуксе. Вот что было предпринято для того, чтобы пользователи были относительно довольны. А именно это, от части, является конечной целью.

1. NAS-сервера

Изначально, для пользователей были предоставлены несколько NAS-серверов (Network access server) с разными каналами и они сами выбирали, где им комфортнее. Но, как показала практика, в вышеописанных ограниченных условиях эта схема оказалась малоэффективной и весьма неудобной для пользователей.

2. Приоритеты

Далее, выбор пал на установку приоритетов необходимым портам: web-серфинг, игрушки, dns, ssh, etc. Некоторые порты были найдены тут и тут, некоторые — экспериментально.
Был испытан wondershaper (в ubuntu доступен из репозиториев, если не ошибаюсь), собственно сам htb, а начиналось всё со следующего скрипта (не хочу загромождать статью). Документации в интернете по этим вещам более чем достаточно, но если будут вопросы, то в помощи не откажу.

Каналы были разделены между двумя NAS-серверами и сбалансированы аппаратно, но вы можете попробовать сделать это и программно.

Ну что ж, эта схема порадовала больше. Каналы стали использоваться несколько эффективнее. Плюс к тому, приоритеты тоже дали о себе знать. Web-серфинг, однозначно, стал приятнее, да и в игрушках разница была ощутима, ровно как и во всём остальном, на что были ориентированы приоритеты. Хочется отметить, что ssh стал работать просто идеально, что не могло не порадовать. В общем, всё было хорошо, но казалось очевидным, что могло быть и лучше. Идём дальше.

3. Мухи — отдельно, котлеты — отдельно. (с) В.В.П.

Посмотрев-подумав, решил, что в идеале, лучше собрать все каналы в один шлюз для NAS-серверов, коих предполагается несколько для снятия нагрузки с, непосредственно, железа и др.

В таком случае, рассмотрим шлюз.
Подразумевается, что медленные и быстрые каналы соединяются и балансируются в два отдельных аппаратно. Было решено направить приоритетный трафик по быстрому каналу, а весь остальной — через медленный. Что и было сделано с помощью iptables и iproute2.
Необходимые пакеты помечались (mark) с помощью iptables и, согласно маркировке, направлялись в нужный канал с помощью iproute2. Документации в интернете опять же много, но, хотелось бы отменить, что вам, быть может, будет проще отключить rp_filter для определенного интерфейса (и главное для default, рас уж взялись), чем составить окончательно правильные правила (масло масляное?) для iproute2. Могу описать весь этот процесс подробнее, если потребуется.

Взглянем, что получилось. С приоритетами всё идеально (со всеми без исключения). Каналы не загружены по максимуму даже в пиковое время. Все довольны, все счастливы, до поры до времени.

Так получилось именно в моём случае, что не обязательно должно получиться в вашем. Всё зависит от соотношения ширины каналов. В данном случае, совершенно случайно случилось так, что широкий канал относится к узкому как 2/1, соответственно. Хотя, вы можете сами распределить трафик так, как вам будет угодно.

Примечание: Если вы ещё не используете графический мониторинг проходящего через сервера трафика, то рекомендую сделать это. Попробуйте, например, Cacti.

Хочется отметить, что одна проблема всё же осталась — идентификация трафика Skype и/или BitTorrent.
Как вам известно, они используют огромный диапазон портов, что автоматически затрудняет распознавание их пакетов из общего потока на маршрутизаторе.
В итоге, пришлось сделать медленный канал общим для всего трафика (куда и попали наши друзья), а приоритеты отправлять в быстрый. Это не создало серьезных проблем со связью в Skype, но разница между идеальной связью и имеющейся ощутима.

П.С.: Первый хабратопик, друзья. Отнеситесь, пожалуйста, с пониманием.

Надеюсь, статья будет полезна.

Успехов!

UPD: Спасибо за карму, перенес в соответствующий блог.