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

Linux NAT оптимизация для 10G+ трафика

1. Сколько максимум выжимали pps на nat, выше писали 2.2mpps, это фуллдуплекс? есть где-нибудь тесты не 100 летней давности.

Сколько линуксовым натом хз, а вот натом на писюке делали 110 гигабит, правда размер какета я не знаю.

Share this post


Link to post
Share on other sites

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

не обязательно линукс, можно и фряху. интересует софтнат. 110 гигабит, хм, наверно размер пакета 1 гиг и был :)

Естественно нат айпи в айпи не интересует, я такое минут за 10 напишу на любой оси.

Просто все что я находил меньше 1мппс, ну редко чуть больше. Интересуют возможности. Про ограничение пси-экспресс и слушать не хочу. Процы растут, память тоже, а все топчутся на 1-2мппс, ну не верю. К примеру есть статья "Recipe for building a 10Mpps FreeBSD based router" и другие, но это все синтетик тесты, я же интересуюсь практическим использованием.

Edited by nshut

Share this post


Link to post
Share on other sites

У меня есть тазик, в ЧНН 2.6Mpps, но 2x10G уже почти забиты (7.41Gbit/s на каждом порту). Насчет правил - я даже не особо оптимизировал, т.к. делаю хитрые реверансы с connmark и прочим, и тем не менее больше половины процессорного ресурса свободны.

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

Share this post


Link to post
Share on other sites

У меня есть тазик, в ЧНН 2.6Mpps, но 2x10G

неплохо, а какие камни и сколько? я на гугл пока натю, но можно сказать специально, сейчас цель проверить производительность. Ибо lisg имеющиеся скоро в полки войдут. Завтра если выпрошу подсеть на нат, плюну 7 гигабит в добавок к 6FD, и будь что будет :)

Share this post


Link to post
Share on other sites

3. nat events, я так понимаю берет эвенты с модуля контрэк, т.е. храним все сессии без направления трафика в netflow. а как же скачанные байты и пакеты, где их снимают? или я не так понимаю. И можно настройки модуля тоже в студию, у меня модуль в2.2 нагло жрет от 4% до 20%, фактически пики цпу он и делает

 

nat events построен поверх событий от conntrack. Счётчики пакетов и байтов так же хранятся в записях коннтрака, но в самом conntrack-е должны обязательно быть включены таймстампы и аккаунтинг.

Share this post


Link to post
Share on other sites

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

а вы с улогом не путаете? а то я обрадовался, все настроил и включил. счетчики по нулям, но сами нат евенты работают прекрастно. ядро 3.10.104, ipt_netflow 2.2.

получается nat events нужен только для логирования сессий и конечно плюс, не надо расчитывать сначенный ip

Share this post


Link to post
Share on other sites

От включенного в conntrack аккаунтинга проц немного растет, замерял давно "на глаз".

Share this post


Link to post
Share on other sites

От включенного в conntrack аккаунтинга проц немного растет, замерял давно "на глаз".

ну netflow коллектор тоже проц грузит, я допустим пока с миррор порта не хочу трафик снимать. На глаз евенты загрузили проц тоже больше, чем трафик правилом, а так как каунтеры не помогли отбросил пока. На больших скоростях погляжу за netflow, может тоже в исходники придется лезть. Сейчас запустил пользователей еще в сервер, в ЧНН поглядим. Пока на одном проце X5660 (частота ограничена 2ггц) 750kpps, 5Gb full duplex загрузка 5%, жду с нетерпением вечера.

Share this post


Link to post
Share on other sites

У меня нагрузка на проц от ipt_NETFLOW была минимальна (но ессно была), необходимости в исходники лезть не было. Да и не думаю, что будет особо толк.

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

Share this post


Link to post
Share on other sites
не обязательно линукс, можно и фряху. интересует софтнат. 110 гигабит, хм, наверно размер пакета 1 гиг и был :)

Там линукс + кастомный софт который через DPDK пакеты жуёт.

rdp.ru это пишет и барыжит.

 

В обычных ОС на каждый отдельный пакет сильно много проверок, а там сильно облегчённый даже не стёк а просто транслятор.

Share this post


Link to post
Share on other sites
не обязательно линукс, можно и фряху. интересует софтнат. 110 гигабит, хм, наверно размер пакета 1 гиг и был :)

Там линукс + кастомный софт который через DPDK пакеты жуёт.

rdp.ru это пишет и барыжит.

 

В обычных ОС на каждый отдельный пакет сильно много проверок, а там сильно облегчённый даже не стёк а просто транслятор.

зашел на сайт, кроме красивых слов ничего толком не нашел, ну да ладно. Не раз думал о dpk и нетмап, но от фул стэйт никуда ведь не денешся. А доп протоколы типо гре требуют вмешательства в пакет, как и нат обязан adjust seq делать, т.е. одними заголовками не отделаться. Лень считать по производительности шины и памяти, но софтос врядли 110 выдаст, если речь x86-64, а не специфические спарк и т.д. с ценой соотетствующей.

Share this post


Link to post
Share on other sites

Использую Linux nat 3.5.0-23-generic #35~precise1-Ubuntu SMP Fri Jan 25 17:13:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux В час пик натит трафик 2.5Гбит.

post-126228-030845500 1481060957_thumb.png

железо:

2хIntel® Xeon® CPU E5620 @ 2.40GHz

Intel Corporation 82599EB 10-Gigabit SFI/SFP+

на нем же

ipt_NETFLOW - сбор статистики

IPSET+squid 3.4 - как фильтр РКН

 

Загрузка в пике около 30%.

00:27:03 up 231 days, 36 min, 1 user, load average: 0.31, 0.43, 0.47

post-126228-028324100 1481061005_thumb.png

 

Мой sysctl.conf

net.ipv4.ip_forward = 1
net.ipv4.neigh.default.gc_thresh1 = 4096
net.ipv4.neigh.default.gc_thresh2 = 8192
net.ipv4.neigh.default.gc_thresh3 = 8192
net.ipv4.neigh.default.base_reachable_time = 86400
net.ipv4.neigh.default.gc_stale_time = 86400
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2
net.ipv4.conf.all.arp_filter = 1
net.ipv4.tcp_syn_retries = 4
net.ipv4.tcp_synack_retries = 4
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.tcp_fin_timeout = 15
net.core.somaxconn = 16384
net.core.netdev_max_backlog = 10000
net.core.rmem_default = 16777216
net.core.wmem_default = 16777216
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_mem = 287160 16777216 16777216
net.ipv4.tcp_rmem = 287160 16777216 16777216
net.ipv4.tcp_wmem = 287160 16777216 16777216
net.ipv4.ip_local_port_range = 1024 65500
net.ipv4.ip_local_reserved_ports = 3333,10050

net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 60
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 20
net.netfilter.nf_conntrack_tcp_timeout_established = 12500
net.netfilter.nf_conntrack_max=1048576
net.nf_conntrack_max=1048576

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

net.core.warnings=0

Обязательно нужно раскинуть по прерываниям, на интеловском сайте есть скрипт.

Буферы делаем по максимуму.

ethtool -G ethX rx tx 4096

Очередь рекомендуют 30000, но на моем трафике разницы не заметил.

ifconfig ethX txqueuelen 30000

Edited by big-town

Share this post


Link to post
Share on other sites

День добрый. Снова вопросы. ядро 3.10.104, использую bonding X520da2. процы 2xX5660.

Два порта в бондинге, а там вланы. Распределение загрузок ядер неравномерное, т.е. то одни ядра загружены, то другие, каждые 2-5 сек меняется. При 1.7mpps то и дело одно из ядер пытается вырваться в полку. По иперфу на втором месте _raw_spin_lock 2%, выше писали что его бондинг и вызывает. 2% не много, но я понимаю, что на 12 ядрях, 2% это одно ядро в в сплошном локе. очереди 4096. Прерывания в ЧНН и понижал и повышал, через rx-usec. Толку нет. Какие то есть специфические настройки bonding чтобы было ровней все это дело? Никаких потерь и ошибок нет, но в полке конечно будут. На форуме находил кучу обсуждений bondinga, но кроме совета его не использовать решения не видел. Хотя здесь же выше писали что 20gbps выжали и работает. Как он вообще тюнится, где рыть? может есть ixgbe надо специфично настроить для бондинга. и да, очереди конечно прибиты жестко, в интеруптах по количеству прерываний на очередь все ровно, как и сама балансировка.

Share this post


Link to post
Share on other sites

У меня подобное было когда оставлял штатный irqbalancer. Его вырубить все сетевухи вручную развести по прерываниям.

Скрипт для разведения по прерываниям использую такой:

for interface in eth0 eth1 eth2 eth3
do
/sbin/ethtool -K $interface tso off gso off gro off
/sbin/ethtool -A $interface autoneg off rx off tx off

/sbin/ethtool -G $interface rx 4096
/sbin/ethtool -G $interface tx 4096

n=`cat "$filenn"`
for irq in `cat /proc/interrupts |grep " ${interface}-"|cut -d: -f1 |tr -d ' '`
do
f="/proc/irq/$irq/smp_affinity"
test -r "$f" || continue
cpu=$[$ncpus - ($n % $ncpus) - 1]
   if [ $cpu -ge 0 ]
    then
     mask=`printf %x $[2 ** $cpu]`
     echo "$mask" > "$f"
     echo "$n $interface" "$mask" "$f"
     let n+=1
   fi
   echo "$n">"$filenn"
done
done

Иначе после запуск скрипта все ОК,а со временем одно ядро в 100% уходило.

Edited by big-town

Share this post


Link to post
Share on other sites

У меня подобное было когда оставлял штатный irqbalancer

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

дело думаю именно в бондинге и его локах, т.к. допустим до 800мппс загрузка максимум 7%, после 850 50%, т.е. слишком резкий рывок, так локи обычно чудят. Да и разбаланс по ядрам видмо tx queue делает. Беда в том, что не могу найти нормальную конфигурацию и тесты бондинга на высокой производительности. Все только пишут как научились болячки бондинга решать, а решений не видел. Может вообще тупость в какой-нить настройке о которой я и не помню(не знаю).

Share this post


Link to post
Share on other sites

Попробуйте воспользоваться скриптом что я дал в посте http://forum.nag.ru/forum/index.php?showtopic=98864&view=findpost&p=1350319, и твиками отсюда http://forum.nag.ru/forum/index.php?showtopic=98864&view=findpost&p=1350120, затем покажите atop 1 при 850. И покажите конфиг бондинга.

Edited by big-town

Share this post


Link to post
Share on other sites

настройки простые:

BONDING_OPTS="mode=802.3ad miimon=100 xmit_hash_policy=layer3+4"

тюнинг и прибитие попробовал, изменений ни в какую сторону не произошло.

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

и вот на нем четко видно, что в бондинге не размазывается исходящий трафик по очередям, rx все ок, а отправка идет только с одной очереди каждого интерфейса, к примеру ix0 tx_queue_3_packets: 3945387.

на 3.10 ядрах драйвера менял и интела и родные центоса, не помогало. Видимо bonding зло, другие сервера без него работают прекрасно. Но все-равно пытаюсь разобраться. Т.к. разруливать bgp или еще чем то, это лишний костыль, если есть технология lacp, она обязана работать.

загрузил 3.10 ядро, подождал 10 сек и снял нагрузку

tx_queue_0_packets: 796470

tx_queue_0_bytes: 862901227

tx_queue_1_packets: 127331

tx_queue_1_bytes: 154521719

tx_queue_2_packets: 105433

tx_queue_2_bytes: 113146569

tx_queue_3_packets: 110952

tx_queue_3_bytes: 131290894

tx_queue_4_packets: 112896

tx_queue_4_bytes: 139732927

tx_queue_5_packets: 108352

tx_queue_5_bytes: 105378175

видно, что в этот момент времени отправка шла большую часть в очередь 0, tx при этом идеально. Похоже через время очередь меняется и итого показатели ровные. Похоже без изучения мат части и исходников мне не обойтись :(

Edited by nshut

Share this post


Link to post
Share on other sites

А это пробовали выставлять ?

 

for i in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
do
   echo performance > $i
done

Share this post


Link to post
Share on other sites

Вроде встречал тут инфу про какой-то крутилятор генерирования прерываний в случае бондинга..

Share this post


Link to post
Share on other sites

Похоже без изучения мат части и исходников мне не обойтись

Попробуйте проделать это на свежей ubuntu lts, поставить актуальное ядро, собрать свежий драйвер сетевых карт руками. Мне помогло в свое время.

Share this post


Link to post
Share on other sites

Попробуйте проделать это на свежей ubuntu lts, поставить актуальное ядро, собрать свежий драйвер сетевых карт руками. Мне помогло в свое время

последую вашему совету, ну немножко. Начал интегрировать свои патчи в ядро 3.18. Увы не хочу переставлять и менять цент на убунту, только из-за ядра, ведь роутинг и нат затрагивают только ядро. Попробовал и 4ое ядро, но не буду разглагольстовать на предмет выбора. В общем на недельку пропал, пока все пилю, далее выложу результаты. Обязательно выложу результаты бондинга и без него, чего увы сам не нашел, да геморой, но истину узнать хочется =)

Share this post


Link to post
Share on other sites

В общем поигрался я и с очередями через исходники, и с разными ядрами и еще много чем.

Разница в использовании на одном процессоре бондинга и без него составила 100mpps, что примерно 8% от общей производительности, т.е. не загрузка процессора, а именно производительность железа и текущей конфигурации. Тест проводится с идентичными настройками, бондинг был разобран без перезагрузки. Двух процессорный результат получить не удалось, т.к. уперся в полку сетевой. Для себя сделал вывод, 100мппс погоды не играют, т.к. на графиках видно, что сервер когда достигает критического момента производительности, следующие 50-100мппс уложат его в полку, а работа на пределе, это любой флуд сделает ваш сервер трупом. Возможно мои показатели и настройки ужасные, я продолжаю экспереминтировать пока. Тесты проводились на X5660 @ 2.80GHz, память 3CH 1333, сетевая X520da2, сервисы 25правил iptables (есть ipset и xmark), ipt_netflow, весь трафик NATится в 3 подсети.

Ядро линукса: до этого было 3.10.104, последние тесты на ядре 3.18.45, интересный момент, последнее показывает загрузку на 10-15% меньше в общем, но полка наступает одновременно, т.е. ложит сервер мппс и никаких улучшений в эту сторону не сделано.

Когда наступает полка: игры с usec_rx и другими умными параметрами сильно результата не дают, т.е. тупо нехватает Mpps vs (частота*ядра).

Один проц производительнее двух, вымывание кэша в разы меньше, но частота дополнительных ядер отодвигает полку. Отсюда вывод: один проц с кучей ядер и максимальной частотой, точно лучше двух в сумме частота*ядра.

post-106448-057479700 1481865694_thumb.png

Edited by nshut

Share this post


Link to post
Share on other sites

Отсюда вывод: один проц с кучей ядер и максимальной частотой, точно лучше двух в сумме частота*ядра.

поэтому мы натим на дешевых e3-1240 =)

Share this post


Link to post
Share on other sites

поэтому мы натим на дешевых e3-1240 =)

А в качестве платформы, какое железо?

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