Перейти к содержимому
Калькуляторы

Реально отшейпить 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 Гбит?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Все это на Linux в режиме моста.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Все это на Linux в режиме моста.

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

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

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

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

проц: Core2 Quad Q8400 @ 2.66GHz

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Изменено пользователем photon

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Цитата(bos9 @ 29.1.2011, 18:25) *

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

 

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Цитата(bos9 @ 29.1.2011, 18:25) *

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

 

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

img не пробовал ибо в симметричных шейперах проще вешать все на физические интерфейсы

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Изменено пользователем photon

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Так к 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, там все подробно разжевано.

Изменено пользователем NiTr0

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.