Jump to content
Калькуляторы

Реально отшейпить 2 Гбит на новом железе?

Доброго времени суток!

 

Сейчас ~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 Гбит?

Share this post


Link to post
Share on other sites

Для 2 Гиг хватит и двух Xeon E5520.

 

На 10Г картах выжимаем из HTB-шейпера 2.5 Гига.

Share this post


Link to post
Share on other sites
Все это на Linux в режиме моста.

Т.е. сервер с шейпером полностью прозрачен по L3 или я не правильно понял? Это даёт выигрышь по производительности?

Share this post


Link to post
Share on other sites
Все это на Linux в режиме моста.

Т.е. сервер с шейпером полностью прозрачен по L3 или я не правильно понял? Это даёт выигрышь по производительности?

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

через бридж проходит ~55kpps

также HTB шейпер с хэшами

проц: Core2 Quad Q8400 @ 2.66GHz

загрузка каждого ядра ~10%

Share this post


Link to post
Share on other sites
Т.е. сервер с шейпером полностью прозрачен по L3 или я не правильно понял? Это даёт выигрышь по производительности?
В случае бриджевания - нагрузка может ощутимо снизится за счёт того, что системе не нужно будет эзернет пакеты пересобирать и вообще как либо менять.

Это характерно для L2 мостов, тк в этом случае бриджу не нужно пользоваться ARP.

L3 мост смысла не имеет, это по нагрузке тот же роутинг примерно.

 

Роутинг жрёт больше именно за счёт того что роутер вынужден пользоваться ARP и пересобирать эзернет фреймы, хотя и не трогая/пересобирая L3 (IP) пакеты.

Также роутинг пользуется таблицей маршрутизации...

Share this post


Link to post
Share on other sites

но L2 бридж не может быть шейпером, тогда в чём прикол?

Share this post


Link to post
Share on other sites
но L2 бридж не может быть шейпером, тогда в чём прикол?
Почему же не может, все работает в режиме L2 бриджа. Пробуй см. brctl

 

Для 2 Гиг хватит и двух Xeon E5520.

 

На 10Г картах выжимаем из HTB-шейпера 2.5 Гига.

Это порог? Или это просто текущее значение и возможен рост?

Share this post


Link to post
Share on other sites
но L2 бридж не может быть шейпером, тогда в чём прикол?
Он может быть шейпером.

Мост производит с транзитными пакетами меньше манипуляций, чем маршрутизатор,

поэтому при одинаковом трафике процессор моста будет нагружен меньше.

Share this post


Link to post
Share on other sites

На 10Г картах выжимаем из HTB-шейпера 2.5 Гига.

Это порог? Или это просто текущее значение и возможен рост?

Похоже порог. При 4.5 Гиг ожидаемого трафика, HTB упирался в 2.5 и даже плавно падал при увеличении объема подаваемого трафика. Процы, при этом, были загружены всего на 40%.

Share this post


Link to post
Share on other sites
На 10Г картах выжимаем из HTB-шейпера 2.5 Гига.
Это порог? Или это просто текущее значение и возможен рост?
Похоже порог. При 4.5 Гиг ожидаемого трафика, HTB упирался в 2.5 и даже плавно падал при увеличении объема подаваемого трафика. Процы, при этом, были загружены всего на 40%.

Если проц на 40%, тогда не понятно куда упирается?

Share this post


Link to post
Share on other sites

Если проц на 40%, тогда не понятно куда упирается?

Скорее всего упирается в разрешение таймера (HZ). Если ставить, скажем, 4000, а не дефолтные 250 или сколько там, думаю можно выжать побольше.

Edited by photon

Share this post


Link to post
Share on other sites
Цитата(bos9 @ 29.1.2011, 18:25) *

но L2 бридж не может быть шейпером, тогда в чём прикол?

 

Почему же не может, все работает в режиме L2 бриджа. Пробуй см. brctl

Заинтересовало. А есть ли у данной реализации какие-то проблемы с использованием imq, iptables, u32 ?

 

Share this post


Link to post
Share on other sites

2photon: А вы пробовали ставить значения таймера выше 1000? Нормально работало всё?

Share this post


Link to post
Share on other sites
Если проц на 40%, тогда не понятно куда упирается?
Скорее всего упирается в разрешение таймера (HZ). Если ставить, скажем, 4000, а не дефолтные 250 или сколько там, думаю можно выжать побольше.

По дефолту чаще 1000 сейчас ставят. Надо короче пробовать, т.к. возможно что реализация htb завязана на разрешение таймера и с 4к буде неправильно работать. Сам пробовал?

Share this post


Link to post
Share on other sites
Цитата(bos9 @ 29.1.2011, 18:25) *

но L2 бридж не может быть шейпером, тогда в чём прикол?

 

Почему же не может, все работает в режиме L2 бриджа. Пробуй см. brctl

Заинтересовало. А есть ли у данной реализации какие-то проблемы с использованием imq, iptables, u32 ?

img не пробовал ибо в симметричных шейперах проще вешать все на физические интерфейсы, а NAT лучше не делать вместе с шейпингом (это ИМХО), все остальное работает без проблем. Есть ньюансы с iptables, т.к. там пропадают опции -i и -o, вместо них нужно использовать -m physdev --physdev-in/out

Share this post


Link to post
Share on other sites
img не пробовал ибо в симметричных шейперах проще вешать все на физические интерфейсы

т.е. вы на этом шейпере только полосы абонентам нарезаете? ведь, если нужно еще и глобальную приоритезацию трафика сделать, то только двумя физическими интерфейсами не обойтись?

 

Share this post


Link to post
Share on other sites

По дефолту чаще 1000 сейчас ставят. Надо короче пробовать, т.к. возможно что реализация htb завязана на разрешение таймера и с 4к будет неправильно работать. Сам пробовал?

Нет, это во FreeBSD с dummynet рекомендуют ставить HZ=1000, а в Linux этот параметр по умолчанию равен 250. В новых ядрах вообще может быть выбрана опция tickless kernel, поэтому не совсем ясно сколько там реальное разрешение. Еще по идее надо включить опцию CONFIG_HIGH_RES_TIMERS. Сам скорости выше гигабита не пробовал, т.к. негде пока.

Edited by photon

Share this post


Link to post
Share on other sites

если нужно еще и глобальную приоритезацию трафика сделать, то только двумя физическими интерфейсами не обойтись?

Прекрасно обойтись. На одном приоритезируется входящий как душе угодно, на другом - исходящий.Вплоть до раскладывания каждого абонентского канала на 10 классов, на каждый из которых будет свой глобальный подкласс с глобальным лимитом/приоритетом этого типа траффика, и на все вместе - корневой класс. Была бы фантазия.

Share this post


Link to post
Share on other sites
Прекрасно обойтись. На одном приоритезируется входящий как душе угодно, на другом - исходящий.Вплоть до раскладывания каждого абонентского канала на 10 классов, на каждый из которых будет свой глобальный подкласс с глобальным лимитом/приоритетом этого типа траффика, и на все вместе - корневой класс. Была бы фантазия.

Так к ingress qdisc вроде нельзя классы прикручивать? Или там приоритезация засчёт фильтров с разными приоритетами? И как определить пакет в исходящей очереди одновременно и в абонентский класс и в его подкласс? Просто нужно реализовать у себя такую штуку примерно на 1500 абонентов 100мбит внешний канал, поэтому пытаюсь разобраться в вопросе. Пока мне посоветовали использовать схему когда сначала трафик приоритизируется на imq (на нём к примеру 2 класса: один высокоприоритетный rate 90mbit ceil 100mbit, второй низкоприоритетный rate 10mbit ceil 100mbit классификация по u32), а далее уже на физическом интерфейсе нарезаются абонентские полосы (классификация по двум последним октетам ip с помощью MARK). И так в обе стороны... В этой схеме отсутствует приоритезация внутри абонентских каналов не знаю как сделать. Вообще, буду благодарен, если подскажите, как это обычно реализовано у операторов доступа (на пс с linux).

 

Share this post


Link to post
Share on other sites
Так к 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, там все подробно разжевано.

Edited by NiTr0

Share this post


Link to post
Share on other sites
Вы хоть представляете, сколько ресурсов сожрет 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 и по протоколу одновременно?

 

Share this post


Link to post
Share on other sites
всё-таки в случае с двумя интерфейсами трафик на одном входящий, а на другом исходящий...
На одном интерфейсе будет шейпиться аплоад, на другом - даунлоад, в чем проблема-то? :)

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

 

u32 классификатором с двумя критериями по ip и по протоколу одновременно?
Хеш-таблица (или таблицы, в одной таблице - до 256 элементов) с классификацией по ip, потом - u32 классификаторы по чему угодно (протокол/порты/etc) на каждую ячейку таблицы.

Share this post


Link to post
Share on other sites
Да и без глобального выделения торрента в один класс, веба - в другой, можно вполне обойтись. Достаточно приоритеты пользовательским классам нарулить - из корневого класса при оверкоммите они высосут соответственно пропорционально приоритетам.

Примерно как тут? Но ведь приоритеты пользовательских подклассов будут влиять только на порядок наследования ими полосы пользователя, как это может повлиять на глобальную приоритизацию внутри корневого класса?

 

Share this post


Link to post
Share on other sites
Но ведь приоритеты пользовательских подклассов будут влиять только на порядок наследования ими полосы пользователя, как это может повлиять на глобальную приоритизацию внутри корневого класса?
ИМХО - при отсутствии в родительском классе токенов (типичная ситуация для качка) подклассы будут выгребать токены из корневого класса опять-таки пропорционально их квантуму.

Хотя - я такой эксперимент не ставил, у нас шейпера на брасах крутятся, т.к. не всем выдаем белые адреса, да и бордюров - не один...

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this