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

Оптимизация шлюза

Добрый день.

Господа, помогите оптимизировать работу шлюза.

Имеем 2 гига оперы ддр3, процессор Intel® Core i7-3770T CPU @ 2.50GHz + сетевая карта Intel I350-T4, драйвер загружен с опциями RSS=4,4,4,4 InterruptThrottleRate=3000,3000,3000,3000 QueuePairs=1,1,1,1 LLIPort=80

 

Также на борту вертится НАТ + iptables filtering + HTB shaping + netflow (ipt_netflow) + с десяток вланов + ifb

В таблесах филтер порядка 3000 правил + 3000 правил в мангле + в нат 3 подсети

Трафик с интерфейсов заворачивается на IFB устройства (4 штуки) и там же шейпится с помощью тс + НТВ.

В мангле правила для классификации трафика.

 

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

При этом загрузка проца под вечер пляшет от 60% до 80% и трафик валит со скоростью 350 мегабит/с в одну и 350 в другую сторону.

 

P.S.> Хотел бы через хеш классифицировать в шейпере, но проблема в том, что там траф уже светится за натом (т.е. не попадают ипник вида 192.168.*.*).

 

Что можете посоветовать по оптимизации? Пока только думаю увеличивать мощность поставить 8 ядерный амд.

Share this post


Link to post
Share on other sites

Что можете посоветовать по оптимизации? Пока только думаю увеличивать мощность поставить 8 ядерный амд.

Это тупиковый путь. Однозначно стоит забыть про такой "апгрейд".

 

Как минимум убрать вот это QueuePairs=1,1,1,1 LLIPort=80 из опций драйвера и попытаться вынести NAT с этой машины на другую, которую поставить чуть дальше.

Share this post


Link to post
Share on other sites

Что можете посоветовать по оптимизации? Пока только думаю увеличивать мощность поставить 8 ядерный амд.

Это тупиковый путь. Однозначно стоит забыть про такой "апгрейд".

 

Как минимум убрать вот это QueuePairs=1,1,1,1 LLIPort=80 из опций драйвера и попытаться вынести NAT с этой машины на другую, которую поставить чуть дальше.

т.е. Вы предлагаете вынести нат дальше, а на этой машине не классифицировать траффик, а использовать хеш фильтры?

Share this post


Link to post
Share on other sites

И еще вопрос о таком кол-ве правил в iptables. Может быть стоит эти сложности разобрать по косточкам и выяснить как уменьшить это кол-во?

Share this post


Link to post
Share on other sites

И еще вопрос о таком кол-ве правил в iptables. Может быть стоит эти сложности разобрать по косточкам и выяснить как уменьшить это кол-во?

Согласен.

Думал над этим. Просто изначально не правильно продумал, вот и получил результат.

 

Еще один вопрос.

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

Поможет ли мне включение гипертрединга? И не будет ли вываливаться ядро в кору?

Edited by vasya_petrovich

Share this post


Link to post
Share on other sites

8-миядерный амд на самом деле 4-хядерный, сделаете только хуже. Да и не в количестве ядер тут дело, а в удельной частоте ядра.

Гипертрединг вообще никакой погоды не делает, хоть и гуляет мнение что он даже вреден.

Однозначно ветвить правила, 3к последовательно это очень много. Посмотреть в сторону поменять местами порядок полисинга и ната чтобы использовать хеши.

Share this post


Link to post
Share on other sites

Чините iptables. Зачем там 6000 правил??? Если это разрешение/запрет клиентам - залейте его в ipset и используйте 1 правило, получите разгрузку раз в 10 минимум.

Edited by kayot

Share this post


Link to post
Share on other sites

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

Поможет ли мне включение гипертрединга? И не будет ли вываливаться ядро в кору?

На ядрах 3.2.x - 3.7.x и камнях E3-E5 Xeon таки допилили HT до приемлемого уровня. Поэтому, если приобретете когда-нибудь мат. плату на чипсете Intel C20x, 60x, то включайте. Все будет шоколадно.

 

С более ранними ядрами, старыми ОС, старым железом и т.п. действительно вылезали неприятные косяки и были перекосы по нагрузке на ядра. В последнее время вроде как детские болезни прошли, но нужна новая программно-аппаратная основа для юзанья HT.

Edited by replicant

Share this post


Link to post
Share on other sites

8-миядерный амд на самом деле 4-хядерный, сделаете только хуже.

8 полноценных целочисленных ядер, разве что декодер команд общий. Проблема у амд в другом кроется..

 

Да и не в количестве ядер тут дело, а в удельной частоте ядра.

Не угадали. Ключевую роль играют как раз латентность памяти и кешей.

 

По сабжу - да, цепочки ветвить или юзать ipset; htb - хеш-фильтры строить; очереди на сетевухах повключать по кол-ву ядер и привязать очередь к ядру... Дальше уже думать, если не хватит производительности, над более глубокими оптимиациями

Share this post


Link to post
Share on other sites

Не угадали. Ключевую роль играют как раз латентность памяти и кешей.

А оно с каких-то пор не соотносится к частоте? Подбором железа занимаюсь не я в основном, мог пропустить.

Share this post


Link to post
Share on other sites

Господа, спасибо за советы.

Уже занимаюсь оптимизацией (ipset, хэш фильтры htb)

О резалтах сообщу позже.

 

Нитро, в чем скрытая проблема у амд?

Edited by vasya_petrovich

Share this post


Link to post
Share on other sites

Столкнулся с непонятным для меня сабжем.

Чтобы обойти проблему НАТ, решил снимать трафик с внутренних интерфейсов (вход и исход) и редиректить их на IFB устройства.

На внутренний интерфейс прилепил дисциплину ингресс, и добавил фильтр для редиректа трафика на псевдойстройство. Фильтр отрабатывает как надо, НО! ком*** tc -s filter show dev $MY_INTERNAL_INTERFACE ничего не показывает.

Почему?

Edited by vasya_petrovich

Share this post


Link to post
Share on other sites

А оно с каких-то пор не соотносится к частоте?

Куда больше соотносится с особенностями архитектуры. Сравните латентность интела и амд.

 

Нитро, в чем скрытая проблема у амд?

Написал уже: латентность кешей/памяти больше...

Share this post


Link to post
Share on other sites

А, ну с этой точки зрения да, логично. Просто кроме Xeon'ов ничего не закупаем)

Share this post


Link to post
Share on other sites

Столкнулся с непонятным для меня сабжем.

Чтобы обойти проблему НАТ, решил снимать трафик с внутренних интерфейсов (вход и исход) и редиректить их на IFB устройства.

На внутренний интерфейс прилепил дисциплину ингресс, и добавил фильтр для редиректа трафика на псевдойстройство. Фильтр отрабатывает как надо, НО! ком*** tc -s filter show dev $MY_INTERNAL_INTERFACE ничего не показывает.

Почему?

Оказывается все просто: tc -s filter show dev $MY_INTERNAL_INTERFACE parent ffff:

Share this post


Link to post
Share on other sites

Как победить большое кол-во дропов на псевдоустройстве IFB?

Заворачиваю туда трафик и дроппед начинает расти. Хотя я еще не повесил ни одну дисциплину tc.

В чем засада?

Share this post


Link to post
Share on other sites

Надо отказываться от использования псевдоустройств и распределить разные функции по нескольким машинам (одна машина или коммутатор для терминации вланов, другая -- шейпирующий мост, третья -- border router c NAT и Netflow).

Edited by photon

Share this post


Link to post
Share on other sites

Надо отказываться от использования псевдоустройств и распределить разные функции по нескольким машинам (одна машина или коммутатор для терминации вланов, другая -- шейпирующий мост, третья -- border router c NAT и Netflow).

+1

Share this post


Link to post
Share on other sites

Надо, но вообще-то оно работает, и работает хорошо.

Хорошо нагруженный PPPoE BRAS, на ifb0 заворачивается трафик с bond-интерфейса(2х1G), реальный трафик до 1.5G.

root#nas4 ~ #ifconfig ifb0

ifb0 Link encap:Ethernet HWaddr 4A:D7:D1:01:C3:2C

UP BROADCAST RUNNING NOARP MTU:1500 Metric:1

RX packets:238564346874 errors:0 dropped:0 overruns:0 frame:0

TX packets:238564346874 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:32

RX bytes:224471746282797 (204.1 TiB) TX bytes:224471746282797 (204.1 TiB)

Share this post


Link to post
Share on other sites

Надо, но вообще-то оно работает, и работает хорошо.

Хорошо нагруженный PPPoE BRAS, на ifb0 заворачивается трафик с bond-интерфейса(2х1G), реальный трафик до 1.5G.

Такой подход усложняет масштабируемость и создает single point of failure.

Share this post


Link to post
Share on other sites

Оптимизировал работу шлюза с IPSET, результат на лицо. Теперь стоит задача с хэш фильтрами.

У меня есть деление по подсетям:

1) Пиринг (около 50 подсетей)

2) Весь остальной трафик.

 

На данный момент это реализовано тупо через линейный список, в конце которого u32 0.0.0.0 action egress redirect to dev ifb0.

Никак не вьеду, как здесь прикрутить хэш фильтры. И имеет ли смысл?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Сейчас у меня есть с десяток вланов, которые через tc filter фильтруют трафик подсеток и редиректят его на псевдодейвайсы (а на псевдодевайсах у меня весят классы + туда надо хэш фильтры затащить):

1. 123.45.0.0/18 -> ifb1 \

2. 234.56.0.0/19 -> ifb1 - ПИРИНГ направлять на ifb1

... /

50. 0.0.0.0/0 -> ifb0 - Весь остальной трафик на ifb0

 

Хочу оптимизировать это безобразие, т.к. эти фильтры на каждом интерфейсе (которые редиректят)

Edited by vasya_petrovich

Share this post


Link to post
Share on other sites

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

Сейчас у меня есть с десяток вланов, которые через tc filter фильтруют трафик подсеток и редиректят его на псевдодейвайсы (а на псевдодевайсах у меня весят классы + туда надо хэш фильтры затащить):

1. 123.45.0.0/18 -> ifb1 \

2. 234.56.0.0/19 -> ifb1 - ПИРИНГ направлять на ifb1

... /

50. 0.0.0.0/0 -> ifb0 - Весь остальной трафик на ifb0

 

Хочу оптимизировать это безобразие, т.к. эти фильтры на каждом интерфейсе (которые редиректят)

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

Share this post


Link to post
Share on other sites

Да перестаньте, нет там никаких проблем. В IMQ помню мы еще упирались на железках уровня core duo, в IFB то же железо перестало упираться, а на современной платформе его вклад вообще копеечный. Все при окологигабитных скоростях.

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