unsorted ~ Приоритет сетевого трафика на уровне ядра Linux.

Оцениваем различные решения, делимся советами. tc, ifb

C нами с 09.04.2005 Репутация: **0.1**

Ситуация: имеется канал в Интернет, сейчас канал делится на всех так или иначе справедливо, и полно. Народ на этих работах смотрит ютубы, одноглазников, фото в контактах. - Когда народ начинает этим заниматься массово (читай: перед праздниками, по пятницам к вечеру), проблема приобретает катастрофический характер: перестают ходить складские остатки между удалёнными офисами, наступает финита-ля комедия: почте, VPN... - Начинаются звоночки в ИТ департмент, пока одни смотрят фильмы, другие не могут закончить работу вовремя...

На Ваш суд предлагается следующее решение: см. вложение.

P.S. закрывать одноглазников, лицокниги, и прочие социалки пока не планируется.

Что скажете?

PPS: Тут показан только входящий трафик ко мне, исходящий от меня может быть настроен зеркально аналогично на eth 1 «gw just forward» который.

Разумеется цифры примерные, и могут подбираться экспериментально.

C нами с 12.02.2005 Репутация: **63.3**

Это не есть правильный шейпер (зачем придумывать велосипед?).

Заранее извиняюсь за совет очень общего плана. Но решать проблему необходимо с другой стороны: необходимо продумать, какие негативные исходы будет иметь данный инструмент (а они должны быть обязательно). Просчитать условия возникновения таких исходов и их вероятность. Убедиться, что все предпосылки, кроме человеческого фактора дают вероятность негативных исходов меньше, чем 10^-9 в случае критических систем (10^-7 ... 10^-6 для прочих). Пересмотреть методы реализации инструмента и заново всё просчитать, чтобы выработать инструкции для минимизации человеческого фактора.

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

C нами с 09.04.2005 Репутация: **0.1**

Почему не правильный шейпер? - Он не правильный в том плане, что мне есть смысл шейпить на Gw just forward. Я тупанул, машину с NAT вообще можно не трогать.

В моём решении должны удовлетворены так или иначе быть все. И серверные задачи, и клиентские.

iriah писал(а):

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

Безусловно. Только возникает вопрос оплаты данного канала. Оплачивать по 60 тыс. в месяц на нужды сотрудников пока желания на фирме нету. Однако и этот вариант не отбрасывается (я кстати что-то уже и забыл про него! Спасибо за напоминание, я думал больше в сторону расширения канала), также как и вариант расширения канала, хотя расширение также не особо спасёт, ибо один бог забьётся канал, если смотреть всякую видео ерунду. Отдельный канал тоже так или иначе велосипед тоже на самом то деле. У меня количество пользователей более сотни (постоянный on-line). Тоже придётся что-то постоянно думать... - Чтоб доступность ещё обеспечивать каналов и всё прочее.

C нами с 12.02.2005 Репутация: **63.3**

У нас на работе очень большие нагрузки по трафику. У нас с точки зрения сетей полностью отделены друг от друга
1. обслуживание оборудования, требующего 24/7 рабочего режима
2. он-лайн мониторинг оборудования из п.1
3. сеть GRID: рабочие данные (лично я иногда передаю по 300-400 Гб в день) и связь с внешними кластерами
4. внутренние кластеры (есть "песочница" для тестирования пользовательских запросов и серьёзные кластеры с разной архитектурой) и хранилища данных
5. видеоконференции (даже двадцать человек в одной HD-видеоконференции неплохо загружают канал)
6. почта
7. веб-серверы
8. пользовательские нужды (при этом для трафикоёмких приложений, например, Skype, необходимо использовать внутренний proxy, чтобы этот трафик тоже как-то регулировать)
Конечно, ещё есть резервирование и службы IT-безопасности. Но мне не доводилось ими пользоваться.

У нас работает около 10000 человек и, когда идёт какой-нибудь Чемпионат мира по футболу, и каждый третий смотрит трансляцию, пользовательские каналы сильно проседают.

Поймите меня правильно, я не говорю, что в маленькой фирме должно быть так же, как в институте с крупнейшей в мире IT-инфраструктурой. Но, может быть, это сможет чем-то Вам помочь. Подмигивание

P.S. Если что, я не администратор, а пользователь.

Добавлено спустя 30 минут 47 секунд:

В качестве конкретного совета посоветовал бы Вам выделить трафикоёмкие приложения у пользователей (youtube, skype), и направлять трафик для таких приложений через squid.

C нами с 09.04.2005 Репутация: **0.1**

iriah писал(а):

В качестве конкретного совета посоветовал бы Вам выделить трафикоёмкие приложения у пользователей (youtube, skype), и направлять трафик для таких приложений через squid.

Но зачем? Чем он поможет? Понижать скорость на нём? Так какая разница, что squidом шейпить, что уровнем ниже?

В целом интересно конечно посмотреть как это устроено у больших. Спасибо. Я считаю что вполне правильно устроено. Бюджеты ИТ конечно тут различные.

C нами с 22.01.2007 Репутация: **136.4**

В натуре как-то все заморочено Я в шоке

Зачем все это?!

У меня контролем скорости занимается HTB, настраивается на раз, закрытием ок, вк и т.п. занимается сквид3+самс2.
Работает все, ттт, не дурно, особенно если нужно наказать кого-нибудь, влепляю хулигану скорость 56 кб\с Весело

На полной ширине канала остается только почта и рдп доступ для удаленщиков, ну и ТИ отдел)))

C нами с 09.04.2005 Репутация: **0.1**

Цитата:

У меня контролем скорости занимается HTB

Ну а по каким критериям он этим занимается? Я ведь тоже предлагаю tc.

Keper писал(а):

закрытием ок, вк и т.п. занимается сквид3+самс2.

А зачем закрывать социалки? Да и обойти squid я думаю не сложно.

Keper, опишите на каком основании у вас HTB рулит.

Добавлено спустя 3 минуты 55 секунд:

Keper писал(а):

особенно если нужно наказать кого-нибудь, влепляю хулигану скорость 56 кб\с

Я предпочту в крайнем случае сообщить руководству, и заняться чем-то более продуктивным вместо этого баловства.

C нами с 22.01.2007 Репутация: **136.4**

DALDON, htb блочит по ИП или диапазону ип.
диапазон *1.30 - *1.240 стоит ограничение скорости 5 мегабит на всех по протоколам оговоренным в конфиге. Я не морочусь протоколами вроди фтп и смтп, я их просто закрыл и разрешил избранным. а трафик от *1.1 до *1.30 полная ширина канала, ибо там сервера и вип юзвери. смтп этому диапазону открыт на всю ширину канала.
В общей сложности весь трафик на шлюзе закрыт на портах от 81-65500 закрыт. а все что до 80 заворачивается на прозрачную проксю.
Хз если не внятно объяснил, просто голова ща другим забита.

Добавлено спустя 1 минуту 7 секунд:

DALDON писал(а):

Keper писал(а):

особенно если нужно наказать кого-нибудь, влепляю хулигану скорость 56 кб\с

Я предпочту в крайнем случае сообщить руководству, и заняться чем-то более продуктивным вместо этого баловства.

У Всех должны быть маааааленьки радости)))) Смотреть как паршивец мучается смотреть пробки это бесценно))))

C нами с 09.04.2005 Репутация: **0.1**

Keper писал(а):

диапазон *1.30 - *1.240 стоит ограничение скорости 5 мегабит на всех по протоколам оговоренным в конфиге.

Так я предлагаю тоже самое. Только я ещё ввожу приоритет, а у Вас получается вот чего: один начинает что-то качать, забивает пять мегабит, а у остальных начинаются тупняки. Определить какой протокол наиболее важный, а какой нет, очень трудно. - Так-как сейчас и по www, передаются порой крайне важные данные (Клиент-Банк к примеру).

ИМХО: всё остальное кроме web и skype и icq уже вымерло как класс. Всякие ftp, и прочее уже не нужно никому в том числе и smtp.

Добавлено спустя 53 секунды:

Цитата:

У Всех должны быть маааааленьки радости)))) Смотреть как паршивец мучается смотреть пробки это бесценно))))

Это да, но кстати squid частенько на самом деле как раз с пробками от Яндекса и тупит кстати.