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

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

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

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

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


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

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

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

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

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

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

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


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

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

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

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


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

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

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

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


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

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

 

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

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


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

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

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

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

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


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

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

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


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

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

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

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


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

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

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

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


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

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

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

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

 

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

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


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

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

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

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

 

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

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

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


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

Использую 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

Изменено пользователем big-town

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


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

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

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

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


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

У меня подобное было когда оставлял штатный 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% уходило.

Изменено пользователем big-town

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


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

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

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

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

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


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

Попробуйте воспользоваться скриптом что я дал в посте 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. И покажите конфиг бондинга.

Изменено пользователем big-town

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


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

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

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 при этом идеально. Похоже через время очередь меняется и итого показатели ровные. Похоже без изучения мат части и исходников мне не обойтись :(

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

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


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

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

 

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

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


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

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

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


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

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

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

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


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

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

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

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


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

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

Разница в использовании на одном процессоре бондинга и без него составила 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

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

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


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

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

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

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


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

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

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

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


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

Join the conversation

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

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

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

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

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

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

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