SokolovS Posted January 28, 2011 Posted January 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 Гбит? Вставить ник Quote
Iva Posted January 29, 2011 Posted January 29, 2011 Для 2 Гиг хватит и двух Xeon E5520. На 10Г картах выжимаем из HTB-шейпера 2.5 Гига. Вставить ник Quote
bos9 Posted January 29, 2011 Posted January 29, 2011 Все это на Linux в режиме моста. Т.е. сервер с шейпером полностью прозрачен по L3 или я не правильно понял? Это даёт выигрышь по производительности? Вставить ник Quote
dmitry_ Posted January 29, 2011 Posted January 29, 2011 Все это на Linux в режиме моста. Т.е. сервер с шейпером полностью прозрачен по L3 или я не правильно понял? Это даёт выигрышь по производительности? именно такую же схему используем, сетевуха такая же, остальное железо другоечерез бридж проходит ~55kpps также HTB шейпер с хэшами проц: Core2 Quad Q8400 @ 2.66GHz загрузка каждого ядра ~10% Вставить ник Quote
Ivan_83 Posted January 29, 2011 Posted January 29, 2011 Т.е. сервер с шейпером полностью прозрачен по L3 или я не правильно понял? Это даёт выигрышь по производительности?В случае бриджевания - нагрузка может ощутимо снизится за счёт того, что системе не нужно будет эзернет пакеты пересобирать и вообще как либо менять.Это характерно для L2 мостов, тк в этом случае бриджу не нужно пользоваться ARP. L3 мост смысла не имеет, это по нагрузке тот же роутинг примерно. Роутинг жрёт больше именно за счёт того что роутер вынужден пользоваться ARP и пересобирать эзернет фреймы, хотя и не трогая/пересобирая L3 (IP) пакеты. Также роутинг пользуется таблицей маршрутизации... Вставить ник Quote
bos9 Posted January 29, 2011 Posted January 29, 2011 но L2 бридж не может быть шейпером, тогда в чём прикол? Вставить ник Quote
SokolovS Posted January 29, 2011 Author Posted January 29, 2011 но L2 бридж не может быть шейпером, тогда в чём прикол?Почему же не может, все работает в режиме L2 бриджа. Пробуй см. brctl Для 2 Гиг хватит и двух Xeon E5520. На 10Г картах выжимаем из HTB-шейпера 2.5 Гига. Это порог? Или это просто текущее значение и возможен рост? Вставить ник Quote
Ilya Evseev Posted January 29, 2011 Posted January 29, 2011 но L2 бридж не может быть шейпером, тогда в чём прикол?Он может быть шейпером.Мост производит с транзитными пакетами меньше манипуляций, чем маршрутизатор, поэтому при одинаковом трафике процессор моста будет нагружен меньше. Вставить ник Quote
Iva Posted January 29, 2011 Posted January 29, 2011 На 10Г картах выжимаем из HTB-шейпера 2.5 Гига. Это порог? Или это просто текущее значение и возможен рост? Похоже порог. При 4.5 Гиг ожидаемого трафика, HTB упирался в 2.5 и даже плавно падал при увеличении объема подаваемого трафика. Процы, при этом, были загружены всего на 40%. Вставить ник Quote
SokolovS Posted January 29, 2011 Author Posted January 29, 2011 На 10Г картах выжимаем из HTB-шейпера 2.5 Гига.Это порог? Или это просто текущее значение и возможен рост?Похоже порог. При 4.5 Гиг ожидаемого трафика, HTB упирался в 2.5 и даже плавно падал при увеличении объема подаваемого трафика. Процы, при этом, были загружены всего на 40%. Если проц на 40%, тогда не понятно куда упирается? Вставить ник Quote
photon Posted January 30, 2011 Posted January 30, 2011 (edited) Если проц на 40%, тогда не понятно куда упирается? Скорее всего упирается в разрешение таймера (HZ). Если ставить, скажем, 4000, а не дефолтные 250 или сколько там, думаю можно выжать побольше. Edited January 30, 2011 by photon Вставить ник Quote
bos9 Posted January 30, 2011 Posted January 30, 2011 Цитата(bos9 @ 29.1.2011, 18:25) *но L2 бридж не может быть шейпером, тогда в чём прикол? Почему же не может, все работает в режиме L2 бриджа. Пробуй см. brctl Заинтересовало. А есть ли у данной реализации какие-то проблемы с использованием imq, iptables, u32 ? Вставить ник Quote
Dark_Angel Posted January 30, 2011 Posted January 30, 2011 2photon: А вы пробовали ставить значения таймера выше 1000? Нормально работало всё? Вставить ник Quote
SokolovS Posted January 30, 2011 Author Posted January 30, 2011 Если проц на 40%, тогда не понятно куда упирается?Скорее всего упирается в разрешение таймера (HZ). Если ставить, скажем, 4000, а не дефолтные 250 или сколько там, думаю можно выжать побольше. По дефолту чаще 1000 сейчас ставят. Надо короче пробовать, т.к. возможно что реализация htb завязана на разрешение таймера и с 4к буде неправильно работать. Сам пробовал? Вставить ник Quote
SokolovS Posted January 30, 2011 Author Posted January 30, 2011 Цитата(bos9 @ 29.1.2011, 18:25) *но L2 бридж не может быть шейпером, тогда в чём прикол? Почему же не может, все работает в режиме L2 бриджа. Пробуй см. brctl Заинтересовало. А есть ли у данной реализации какие-то проблемы с использованием imq, iptables, u32 ? img не пробовал ибо в симметричных шейперах проще вешать все на физические интерфейсы, а NAT лучше не делать вместе с шейпингом (это ИМХО), все остальное работает без проблем. Есть ньюансы с iptables, т.к. там пропадают опции -i и -o, вместо них нужно использовать -m physdev --physdev-in/out Вставить ник Quote
bos9 Posted January 30, 2011 Posted January 30, 2011 img не пробовал ибо в симметричных шейперах проще вешать все на физические интерфейсы т.е. вы на этом шейпере только полосы абонентам нарезаете? ведь, если нужно еще и глобальную приоритезацию трафика сделать, то только двумя физическими интерфейсами не обойтись? Вставить ник Quote
photon Posted January 30, 2011 Posted January 30, 2011 (edited) По дефолту чаще 1000 сейчас ставят. Надо короче пробовать, т.к. возможно что реализация htb завязана на разрешение таймера и с 4к будет неправильно работать. Сам пробовал? Нет, это во FreeBSD с dummynet рекомендуют ставить HZ=1000, а в Linux этот параметр по умолчанию равен 250. В новых ядрах вообще может быть выбрана опция tickless kernel, поэтому не совсем ясно сколько там реальное разрешение. Еще по идее надо включить опцию CONFIG_HIGH_RES_TIMERS. Сам скорости выше гигабита не пробовал, т.к. негде пока. Edited January 30, 2011 by photon Вставить ник Quote
NiTr0 Posted January 30, 2011 Posted January 30, 2011 если нужно еще и глобальную приоритезацию трафика сделать, то только двумя физическими интерфейсами не обойтись? Прекрасно обойтись. На одном приоритезируется входящий как душе угодно, на другом - исходящий.Вплоть до раскладывания каждого абонентского канала на 10 классов, на каждый из которых будет свой глобальный подкласс с глобальным лимитом/приоритетом этого типа траффика, и на все вместе - корневой класс. Была бы фантазия. Вставить ник Quote
bos9 Posted January 31, 2011 Posted January 31, 2011 Прекрасно обойтись. На одном приоритезируется входящий как душе угодно, на другом - исходящий.Вплоть до раскладывания каждого абонентского канала на 10 классов, на каждый из которых будет свой глобальный подкласс с глобальным лимитом/приоритетом этого типа траффика, и на все вместе - корневой класс. Была бы фантазия. Так к ingress qdisc вроде нельзя классы прикручивать? Или там приоритезация засчёт фильтров с разными приоритетами? И как определить пакет в исходящей очереди одновременно и в абонентский класс и в его подкласс? Просто нужно реализовать у себя такую штуку примерно на 1500 абонентов 100мбит внешний канал, поэтому пытаюсь разобраться в вопросе. Пока мне посоветовали использовать схему когда сначала трафик приоритизируется на imq (на нём к примеру 2 класса: один высокоприоритетный rate 90mbit ceil 100mbit, второй низкоприоритетный rate 10mbit ceil 100mbit классификация по u32), а далее уже на физическом интерфейсе нарезаются абонентские полосы (классификация по двум последним октетам ip с помощью MARK). И так в обе стороны... В этой схеме отсутствует приоритезация внутри абонентских каналов не знаю как сделать. Вообще, буду благодарен, если подскажите, как это обычно реализовано у операторов доступа (на пс с linux). Вставить ник Quote
NiTr0 Posted January 31, 2011 Posted January 31, 2011 (edited) Так к 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 January 31, 2011 by NiTr0 Вставить ник Quote
bos9 Posted January 31, 2011 Posted January 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 и по протоколу одновременно? Вставить ник Quote
NiTr0 Posted January 31, 2011 Posted January 31, 2011 всё-таки в случае с двумя интерфейсами трафик на одном входящий, а на другом исходящий...На одном интерфейсе будет шейпиться аплоад, на другом - даунлоад, в чем проблема-то? :)Да и без глобального выделения торрента в один класс, веба - в другой, можно вполне обойтись. Достаточно приоритеты пользовательским классам нарулить - из корневого класса при оверкоммите они высосут соответственно пропорционально приоритетам. u32 классификатором с двумя критериями по ip и по протоколу одновременно?Хеш-таблица (или таблицы, в одной таблице - до 256 элементов) с классификацией по ip, потом - u32 классификаторы по чему угодно (протокол/порты/etc) на каждую ячейку таблицы. Вставить ник Quote
bos9 Posted January 31, 2011 Posted January 31, 2011 Да и без глобального выделения торрента в один класс, веба - в другой, можно вполне обойтись. Достаточно приоритеты пользовательским классам нарулить - из корневого класса при оверкоммите они высосут соответственно пропорционально приоритетам. Примерно как тут? Но ведь приоритеты пользовательских подклассов будут влиять только на порядок наследования ими полосы пользователя, как это может повлиять на глобальную приоритизацию внутри корневого класса? Вставить ник Quote
NiTr0 Posted January 31, 2011 Posted January 31, 2011 Но ведь приоритеты пользовательских подклассов будут влиять только на порядок наследования ими полосы пользователя, как это может повлиять на глобальную приоритизацию внутри корневого класса?ИМХО - при отсутствии в родительском классе токенов (типичная ситуация для качка) подклассы будут выгребать токены из корневого класса опять-таки пропорционально их квантуму.Хотя - я такой эксперимент не ставил, у нас шейпера на брасах крутятся, т.к. не всем выдаем белые адреса, да и бордюров - не один... Вставить ник Quote
.png.5d2afa2996cc6a85d0f2c09b92dd0a28.png)
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.