SokolovS Опубликовано 28 января, 2011 · Жалоба Доброго времени суток! Сейчас ~800 Мбит/c шейпится и фильтруется (100-120 Kpps) на достаточно простом железе: Мамка: Intel S3000AH Проц: Intel® Xeon® CPU X3220 Сетевка: Intel <E1G42ET> Gigabit Adapter Dual Port на чипе 82576 Памяти: 4Гб из них 3.2 все время свободно Все это на Linux в режиме моста. Так вот приближается порог в 1Гбит, в связи с этим вопрос, реально ли на свежем железе отшейпить 2Гбит, например: Мамка: INTEL S5520SCR (RTL) Dual LGA1366 <i5520> Проц: что нибудь вроде CPU Intel Xeon E5630 2.53 ГГц/12Мб/5.86 ГТ/с LGA1366 Сетевка: такая же но 4-х головая в режиме bonding ??? Поделитесь опытом у кого уже столько же. Интересно сколько можно выжать если сетевки брать 10 Гбит? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Iva Опубликовано 29 января, 2011 · Жалоба Для 2 Гиг хватит и двух Xeon E5520. На 10Г картах выжимаем из HTB-шейпера 2.5 Гига. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bos9 Опубликовано 29 января, 2011 · Жалоба Все это на Linux в режиме моста. Т.е. сервер с шейпером полностью прозрачен по L3 или я не правильно понял? Это даёт выигрышь по производительности? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dmitry_ Опубликовано 29 января, 2011 · Жалоба Все это на Linux в режиме моста. Т.е. сервер с шейпером полностью прозрачен по L3 или я не правильно понял? Это даёт выигрышь по производительности? именно такую же схему используем, сетевуха такая же, остальное железо другоечерез бридж проходит ~55kpps также HTB шейпер с хэшами проц: Core2 Quad Q8400 @ 2.66GHz загрузка каждого ядра ~10% Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 29 января, 2011 · Жалоба Т.е. сервер с шейпером полностью прозрачен по L3 или я не правильно понял? Это даёт выигрышь по производительности?В случае бриджевания - нагрузка может ощутимо снизится за счёт того, что системе не нужно будет эзернет пакеты пересобирать и вообще как либо менять.Это характерно для L2 мостов, тк в этом случае бриджу не нужно пользоваться ARP. L3 мост смысла не имеет, это по нагрузке тот же роутинг примерно. Роутинг жрёт больше именно за счёт того что роутер вынужден пользоваться ARP и пересобирать эзернет фреймы, хотя и не трогая/пересобирая L3 (IP) пакеты. Также роутинг пользуется таблицей маршрутизации... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bos9 Опубликовано 29 января, 2011 · Жалоба но L2 бридж не может быть шейпером, тогда в чём прикол? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SokolovS Опубликовано 29 января, 2011 · Жалоба но L2 бридж не может быть шейпером, тогда в чём прикол?Почему же не может, все работает в режиме L2 бриджа. Пробуй см. brctl Для 2 Гиг хватит и двух Xeon E5520. На 10Г картах выжимаем из HTB-шейпера 2.5 Гига. Это порог? Или это просто текущее значение и возможен рост? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 29 января, 2011 · Жалоба но L2 бридж не может быть шейпером, тогда в чём прикол?Он может быть шейпером.Мост производит с транзитными пакетами меньше манипуляций, чем маршрутизатор, поэтому при одинаковом трафике процессор моста будет нагружен меньше. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Iva Опубликовано 29 января, 2011 · Жалоба На 10Г картах выжимаем из HTB-шейпера 2.5 Гига. Это порог? Или это просто текущее значение и возможен рост? Похоже порог. При 4.5 Гиг ожидаемого трафика, HTB упирался в 2.5 и даже плавно падал при увеличении объема подаваемого трафика. Процы, при этом, были загружены всего на 40%. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SokolovS Опубликовано 29 января, 2011 · Жалоба На 10Г картах выжимаем из HTB-шейпера 2.5 Гига.Это порог? Или это просто текущее значение и возможен рост?Похоже порог. При 4.5 Гиг ожидаемого трафика, HTB упирался в 2.5 и даже плавно падал при увеличении объема подаваемого трафика. Процы, при этом, были загружены всего на 40%. Если проц на 40%, тогда не понятно куда упирается? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 30 января, 2011 (изменено) · Жалоба Если проц на 40%, тогда не понятно куда упирается? Скорее всего упирается в разрешение таймера (HZ). Если ставить, скажем, 4000, а не дефолтные 250 или сколько там, думаю можно выжать побольше. Изменено 30 января, 2011 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bos9 Опубликовано 30 января, 2011 · Жалоба Цитата(bos9 @ 29.1.2011, 18:25) *но L2 бридж не может быть шейпером, тогда в чём прикол? Почему же не может, все работает в режиме L2 бриджа. Пробуй см. brctl Заинтересовало. А есть ли у данной реализации какие-то проблемы с использованием imq, iptables, u32 ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 30 января, 2011 · Жалоба 2photon: А вы пробовали ставить значения таймера выше 1000? Нормально работало всё? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SokolovS Опубликовано 30 января, 2011 · Жалоба Если проц на 40%, тогда не понятно куда упирается?Скорее всего упирается в разрешение таймера (HZ). Если ставить, скажем, 4000, а не дефолтные 250 или сколько там, думаю можно выжать побольше. По дефолту чаще 1000 сейчас ставят. Надо короче пробовать, т.к. возможно что реализация htb завязана на разрешение таймера и с 4к буде неправильно работать. Сам пробовал? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SokolovS Опубликовано 30 января, 2011 · Жалоба Цитата(bos9 @ 29.1.2011, 18:25) *но L2 бридж не может быть шейпером, тогда в чём прикол? Почему же не может, все работает в режиме L2 бриджа. Пробуй см. brctl Заинтересовало. А есть ли у данной реализации какие-то проблемы с использованием imq, iptables, u32 ? img не пробовал ибо в симметричных шейперах проще вешать все на физические интерфейсы, а NAT лучше не делать вместе с шейпингом (это ИМХО), все остальное работает без проблем. Есть ньюансы с iptables, т.к. там пропадают опции -i и -o, вместо них нужно использовать -m physdev --physdev-in/out Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bos9 Опубликовано 30 января, 2011 · Жалоба img не пробовал ибо в симметричных шейперах проще вешать все на физические интерфейсы т.е. вы на этом шейпере только полосы абонентам нарезаете? ведь, если нужно еще и глобальную приоритезацию трафика сделать, то только двумя физическими интерфейсами не обойтись? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 30 января, 2011 (изменено) · Жалоба По дефолту чаще 1000 сейчас ставят. Надо короче пробовать, т.к. возможно что реализация htb завязана на разрешение таймера и с 4к будет неправильно работать. Сам пробовал? Нет, это во FreeBSD с dummynet рекомендуют ставить HZ=1000, а в Linux этот параметр по умолчанию равен 250. В новых ядрах вообще может быть выбрана опция tickless kernel, поэтому не совсем ясно сколько там реальное разрешение. Еще по идее надо включить опцию CONFIG_HIGH_RES_TIMERS. Сам скорости выше гигабита не пробовал, т.к. негде пока. Изменено 30 января, 2011 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 30 января, 2011 · Жалоба если нужно еще и глобальную приоритезацию трафика сделать, то только двумя физическими интерфейсами не обойтись? Прекрасно обойтись. На одном приоритезируется входящий как душе угодно, на другом - исходящий.Вплоть до раскладывания каждого абонентского канала на 10 классов, на каждый из которых будет свой глобальный подкласс с глобальным лимитом/приоритетом этого типа траффика, и на все вместе - корневой класс. Была бы фантазия. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bos9 Опубликовано 31 января, 2011 · Жалоба Прекрасно обойтись. На одном приоритезируется входящий как душе угодно, на другом - исходящий.Вплоть до раскладывания каждого абонентского канала на 10 классов, на каждый из которых будет свой глобальный подкласс с глобальным лимитом/приоритетом этого типа траффика, и на все вместе - корневой класс. Была бы фантазия. Так к ingress qdisc вроде нельзя классы прикручивать? Или там приоритезация засчёт фильтров с разными приоритетами? И как определить пакет в исходящей очереди одновременно и в абонентский класс и в его подкласс? Просто нужно реализовать у себя такую штуку примерно на 1500 абонентов 100мбит внешний канал, поэтому пытаюсь разобраться в вопросе. Пока мне посоветовали использовать схему когда сначала трафик приоритизируется на imq (на нём к примеру 2 класса: один высокоприоритетный rate 90mbit ceil 100mbit, второй низкоприоритетный rate 10mbit ceil 100mbit классификация по u32), а далее уже на физическом интерфейсе нарезаются абонентские полосы (классификация по двум последним октетам ip с помощью MARK). И так в обе стороны... В этой схеме отсутствует приоритезация внутри абонентских каналов не знаю как сделать. Вообще, буду благодарен, если подскажите, как это обычно реализовано у операторов доступа (на пс с linux). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 31 января, 2011 (изменено) · Жалоба Так к ingress qdisc вроде нельзя классы прикручивать?А при чем здесь ingress qdisc? На каждом из интерфейсов повешали себе шейпера на исходящий траффик - и все. Нафиг виртуальные интерфейы лепить туда, где они не нужны, и потом спотыкаться о грабли, которые они в силу своей виртуальности предоставляют... Пока мне посоветовали использовать схему когда сначала трафик приоритизируется на imq (на нём к примеру 2 класса: один высокоприоритетный rate 90mbit ceil 100mbit, второй низкоприоритетный rate 10mbit ceil 100mbit классификация по u32), а далее уже на физическом интерфейсе нарезаются абонентские полосы (классификация по двум последним октетам ip с помощью MARK).Ну и нафига такие костыли?Вы хоть представляете, сколько ресурсов сожрет 1500 правил иптейблса + 1500 фильтров по mark'у? Советчик ваш похоже u32 классификатор даже не осилил, о том чтобы использовать u32 хеш-таблицы (которые становятся актуальными начиная где-то со 100-200 правил) - вообще помолчу. В этой схеме отсутствует приоритезация внутри абонентских каналов не знаю как сделатьu32 классификатором. А вообще - читайте LARTC, там все подробно разжевано. Изменено 31 января, 2011 пользователем NiTr0 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bos9 Опубликовано 31 января, 2011 · Жалоба Вы хоть представляете, сколько ресурсов сожрет 1500 правил иптейблса + 1500 фильтров по mark'у? по одному правилу и там и там. примерно так: iptables -t mangle -A PREROUTING -i eth0 -j IPMARK --addr=dst --and-mask=0xffff --or-mask=0x10000 tc filter add dev eth0 parent 1:0 protocol ip fw На каждом из интерфейсов повешали себе шейпера на исходящий траффик - и все. не думал, что так прокатит... всё-таки в случае с двумя интерфейсами трафик на одном входящий, а на другом исходящий... Цитата(bos9 @ 31.1.2011, 6:49) *В этой схеме отсутствует приоритезация внутри абонентских каналов не знаю как сделать u32 классификатором. u32 классификатором с двумя критериями по ip и по протоколу одновременно? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 31 января, 2011 · Жалоба всё-таки в случае с двумя интерфейсами трафик на одном входящий, а на другом исходящий...На одном интерфейсе будет шейпиться аплоад, на другом - даунлоад, в чем проблема-то? :)Да и без глобального выделения торрента в один класс, веба - в другой, можно вполне обойтись. Достаточно приоритеты пользовательским классам нарулить - из корневого класса при оверкоммите они высосут соответственно пропорционально приоритетам. u32 классификатором с двумя критериями по ip и по протоколу одновременно?Хеш-таблица (или таблицы, в одной таблице - до 256 элементов) с классификацией по ip, потом - u32 классификаторы по чему угодно (протокол/порты/etc) на каждую ячейку таблицы. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bos9 Опубликовано 31 января, 2011 · Жалоба Да и без глобального выделения торрента в один класс, веба - в другой, можно вполне обойтись. Достаточно приоритеты пользовательским классам нарулить - из корневого класса при оверкоммите они высосут соответственно пропорционально приоритетам. Примерно как тут? Но ведь приоритеты пользовательских подклассов будут влиять только на порядок наследования ими полосы пользователя, как это может повлиять на глобальную приоритизацию внутри корневого класса? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 31 января, 2011 · Жалоба Но ведь приоритеты пользовательских подклассов будут влиять только на порядок наследования ими полосы пользователя, как это может повлиять на глобальную приоритизацию внутри корневого класса?ИМХО - при отсутствии в родительском классе токенов (типичная ситуация для качка) подклассы будут выгребать токены из корневого класса опять-таки пропорционально их квантуму.Хотя - я такой эксперимент не ставил, у нас шейпера на брасах крутятся, т.к. не всем выдаем белые адреса, да и бордюров - не один... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...