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

[vasya_petrovich]

Добрый день.

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

Имеем 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 ядерный амд.

[replicant]

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

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

 

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

[vasya_petrovich]

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

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

 

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

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

[replicant]

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

[vasya_petrovich]

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

Согласен.

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

 

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

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

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

Edited February 13, 2013 by vasya_petrovich

[sexst]

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

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

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

[kayot]

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

Edited February 14, 2013 by kayot

[replicant]

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

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

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

 

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

Edited February 14, 2013 by replicant

[NiTr0]

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

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

 

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

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

 

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

[sexst]

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

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

[vasya_petrovich]

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

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

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

 

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

Edited February 14, 2013 by vasya_petrovich

[vasya_petrovich]

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

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

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

Почему?

Edited February 14, 2013 by vasya_petrovich

[NiTr0]

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

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

 

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

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

[sexst]

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

[vasya_petrovich]

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

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

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

Почему?

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

[vasya_petrovich]

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

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

В чем засада?

[photon]

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

Edited February 17, 2013 by photon

[replicant]

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

+1

[kayot]

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

Хорошо нагруженный 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)

[photon]

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

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

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

[vasya_petrovich]

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

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

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

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

 

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

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

[photon]

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

[vasya_petrovich]

Сколько всего фильтров 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 February 19, 2013 by vasya_petrovich

[photon]

Сколько всего фильтров 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 фильтров и так работают довольно быстро, проблема в избыточных копированиях трафика на псевдоустройства. Узким местом в этом случае является не процессор, а шина оперативной памяти.

[kayot]

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