URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID1
Нить номер: 76960
[ Назад ]

Исходное сообщение
"Шейпинг больших потоков - выбор фаервола"

Отправлено Metaller , 23-Окт-07 13:01 
Приветствую.

Есть некоторая сеть довольно больших размеров, клиентский трафик сейчас шейпится ipfw, на общем потоке 400 мбит р4 2.8 уже начинает не хватать (шейперов около 100). Топ показывает в среднем около 50% загрузки, если шейперы снять, то 10-15 (при трафике возросшем до 600-700 мбит).

Так вот, дошли слухи, что ipfw работает только на первом процессоре и покупка мощного многокаменного тазика его счастливым не сделает. Религия не запрещает перейти на pf, но интересно, как он с этим дружит.

Да и вообще - поделитесь опытом шейпинга больших потоков на ipfw и pf.

ЗЫ: таблицы не использую, шейпинг по направлениям сделан на основе ядерных таблиц роутинга: бгпой разные направления трафика разнесены по вланам и правила выглядят так:

${ipfw} pipe 14020 config bw 5Mbit/s
${ipfw} pipe 14021 config bw 5Mbit/s
${ipfw} pipe 14022 config bw 15Mbit/s
${ipfw} pipe 14023 config bw 15Mbit/s
${ipfw} add 14020 pipe 14020 ip from any to any recv vlan402 xmit vlan200
${ipfw} add 14021 pipe 14021 ip from any to any recv vlan200 xmit vlan402
${ipfw} add 14022 pipe 14022 ip from any to any recv vlan402 xmit vlan201
${ipfw} add 14023 pipe 14023 ip from any to any recv vlan201 xmit vlan402
${ipfw} add 14024 pass ip from any to any via vlan402

ЗЫЫ: Трафик считать не надо.
                                                                                    


Содержание

Сообщения в этом обсуждении
"Шейпинг больших потоков - выбор фаервола"
Отправлено zedis , 23-Окт-07 14:38 
IPFW шейпит траффик через DUMMYNET, а это SOFTWARE Shayper довольно приметивный, а PF шейпит траффик через ALTQ, а это уже HARDWARE Sheyper, и работает он через выходную очередь сетевой карты, то есть ты не можешь на одной карточке шейпить входной и выходной траффик как в IPFW+DUMMYNET, для этого тебе нужно иметь две карточки в рутору на вход и на выход, штука мощная но уже давно небыло нового релиза. Скорее в твоем случаетебе может помочь сетёвки с подержкой POLLING и не IPFW а IPFW2, и тонкий тюнинг ядра, основываясь на количестве прираваний, MBUF, загрузки проца на SYSTEM, INTERUPT, USER CPU utilisation, я задавался таким вопросом но это дело проб и ошибок инфы об этом не много.


"Шейпинг больших потоков - выбор фаервола"
Отправлено Metaller , 23-Окт-07 15:00 
AltQ - хардварный? Пардон, как? Насколько знаю, к железу он не привязан, т.к. реализован не в микросхемах (даже уровня поганого реалтека), а в коде pf. А если не умеет воспринимать влан как отдельный интерфейс, то совсем глупый.

Естественно, фаервол второй, поллинг включен, ядро затюнено. Тонкое место - именно шейпер. Потому и спрашиваю, кто как режет большие потоки.


"Шейпинг больших потоков - выбор фаервола"
Отправлено zedis , 23-Окт-07 17:56 
ALTQ - заточен под определёные карточки на определёные драйвера сетёвок. Это решение для сетевых карточек это больше не софт решение.

А вообще для таких объёмов используют железяки вроде Алои или что нибудь похожее


"Шейпинг больших потоков - выбор фаервола"
Отправлено universite , 24-Окт-07 02:29 

>Естественно, фаервол второй, поллинг включен, ядро затюнено. Тонкое место - именно шейпер.
>Потому и спрашиваю, кто как режет большие потоки.

Озвучьте uname -a


"Шейпинг больших потоков - выбор фаервола"
Отправлено Metaller , 24-Окт-07 02:46 
>Озвучьте uname -a

FreeBSD 6.2-RELEASE #0

Почему #0 - туда нормально ставится патч для ipfw, который учит его натить большие потоки.


"Шейпинг больших потоков - выбор фаервола"
Отправлено butcher , 24-Окт-07 08:43 
>>Озвучьте uname -a
>
>FreeBSD 6.2-RELEASE #0
>
>Почему #0 - туда нормально ставится патч для ipfw, который учит его
>натить большие потоки.

Ссылочку можно?


"Шейпинг больших потоков - выбор фаервола"
Отправлено Metaller , 24-Окт-07 09:40 
>>Почему #0 - туда нормально ставится патч для ipfw, который учит его
>>натить большие потоки.
>
>Ссылочку можно?

Пожалуйста: http://lists.freebsd.org/pipermail/freebsd-ipfw/2006-April/0...


"Шейпинг больших потоков - выбор фаервола"
Отправлено Rednikov , 24-Окт-07 11:37 
>работает он через выходную очередь сетевой карты, то есть ты не
>можешь на одной карточке шейпить входной и выходной траффик как в
>IPFW+DUMMYNET, для этого тебе нужно иметь две карточки в рутору на
>вход и на выход

В случае с вланами в этом проблем нет. Трафик роутиться насквозь.. И поэтому режется в обе стороны. Есть множество машин где такое работает... НО. к вопросу о производительности.. На неособо загруженных узлах проблем нет...
А вот где 5 minute input rate 30272000 bits/sec, 10013 packets/sec нефиговый рутер не справляется. Валится по интераптам...
Или 5 minute input rate 12239000 bits/sec, 3580 packets/sec средненькая машинка валится просто на лопатки...


"Шейпинг больших потоков - выбор фаервола"
Отправлено Rednikov , 24-Окт-07 11:42 
>[оверквотинг удален]
>>вход и на выход
>
>В случае с вланами в этом проблем нет. Трафик роутиться насквозь.. И
>поэтому режется в обе стороны. Есть множество машин где такое работает...
>НО. к вопросу о производительности.. На неособо загруженных узлах проблем нет...
>
>А вот где 5 minute input rate 30272000 bits/sec, 10013 packets/sec нефиговый
>рутер не справляется. Валится по интераптам...
>Или 5 minute input rate 12239000 bits/sec, 3580 packets/sec средненькая машинка валится
>просто на лопатки...

Кстати попробую тогда поднять этот вопрос....
Кто нить тюнил каким либо образом PF чтоб он хоть не проигрывал ipfw в вопросах производительности..


"Шейпинг больших потоков - выбор фаервола"
Отправлено Metaller , 24-Окт-07 12:07 
>А вот где 5 minute input rate 30272000 bits/sec, 10013 packets/sec нефиговый
>рутер не справляется. Валится по интераптам...
>Или 5 minute input rate 12239000 bits/sec, 3580 packets/sec средненькая машинка валится
>просто на лопатки...

Кстати, чем снимали статистику? Попробую свою привести.


"Шейпинг больших потоков - выбор фаервола"
Отправлено Rednikov , 24-Окт-07 12:23 
>Кстати, чем снимали статистику? Попробую свою привести.

Да просто на цисковском свиче sh int fa0/??


"Шейпинг больших потоков - выбор фаервола"
Отправлено Metaller , 24-Окт-07 12:29 
>>А вот где 5 minute input rate 30272000 bits/sec, 10013 packets/sec нефиговый
>>рутер не справляется. Валится по интераптам...
>>Или 5 minute input rate 12239000 bits/sec, 3580 packets/sec средненькая машинка валится
>>просто на лопатки...
>
>Кстати, чем снимали статистику? Попробую свою привести.

Судя по выводу, похоже на кошку. Моя говорит так:

5 minute input rate 173037000 bits/sec, 19113 packets/sec
5 minute output rate 179100000 bits/sec, 25659 packets/sec


"Шейпинг больших потоков - выбор фаервола"
Отправлено Rednikov , 24-Окт-07 12:45 
>Судя по выводу, похоже на кошку. Моя говорит так:
>
>5 minute input rate 173037000 bits/sec, 19113 packets/sec
>5 minute output rate 179100000 bits/sec, 25659 packets/sec

Ну... Что я вам скажу...
Исходя из моего опыта, не могу представить машинку способную выдержать это:))))
Но думаю есть какие то нюансы способные эту ситуацию поправить... Просто я пока решения ещё не нашёл.:( Есть опция в ядро для ALTQ_NOPCC для многопроцессорных машинок.. Может она поможет.


"Шейпинг больших потоков - выбор фаервола"
Отправлено Andrew , 24-Окт-07 13:01 
>А вот где 5 minute input rate 30272000 bits/sec, 10013 packets/sec нефиговый
>рутер не справляется. Валится по интераптам...

По каким таким интераптам? По интераптам из-за забивания очередей на вход/выход и как следствие из-за нехватки памяти в ядре под сетевую обработку во времена коротких, резких скачков вверх потока? А если памяти ядру на сеть добавить, мегабайт 500? Может сгладяться пики? Просто я знаю сумашедших админов, которые потоки в районе 70-80 Мб/с через фрибсд пускали и проблемы у них были другого плана.


"Шейпинг больших потоков - выбор фаервола"
Отправлено Rednikov , 24-Окт-07 13:22 
> А если памяти ядру на
>сеть добавить, мегабайт 500? Может сгладяться пики?

как конкретно это сделать??
если не секрет


"Шейпинг больших потоков - выбор фаервола"
Отправлено Andrew , 24-Окт-07 14:06 
>> А если памяти ядру на
>>сеть добавить, мегабайт 500? Может сгладяться пики?
>
>как конкретно это сделать??
>если не секрет

Вы сначала проверте в этом ли проблема с помощью, netstat -m, параметра два в sysctl
kern.ipc.nmbclusters и kern.ipc.nsfbufs.

The NMBCLUSTERS kernel configuration option dictates the amount of network Mbufs available to the system. A heavily-trafficked server with a low number of Mbufs will hinder FreeBSD's ability. Each cluster represents approximately 2 K of memory, so a value of 1024 represents 2 megabytes of kernel memory reserved for network buffers. A simple calculation can be done to figure out how many are needed. If you have a web server which maxes out at 1000 simultaneous connections, and each connection eats a 16 K receive and 16 K send buffer, you need approximately 32 MB worth of network buffers to cover the web server. A good rule of thumb is to multiply by 2, so 2x32 MB / 2 KB = 64 MB / 2 kB = 32768. We recommend values between 4096 and 32768 for machines with greater amounts of memory. Under no circumstances should you specify an arbitrarily high value for this parameter as it could lead to a boot time crash. The -m option to netstat(1) may be used to observe network cluster use.
kern.ipc.nmbclusters loader tunable should be used to tune this at boot time. Only older versions of FreeBSD will require you to use the NMBCLUSTERS kernel config(8) option.
For busy servers that make extensive use of the sendfile(2) system call, it may be necessary to increase the number of sendfile(2) buffers via the NSFBUFS kernel configuration option or by setting its value in /boot/loader.conf (see loader(8) for details). A common indicator that this parameter needs to be adjusted is when processes are seen in the sfbufa state. The sysctl variable kern.ipc.nsfbufs is a read-only glimpse at the kernel configured variable. This parameter nominally scales with kern.maxusers, however it may be necessary to tune accordingly.
Important: Even though a socket has been marked as non-blocking, calling sendfile(2) on the non-blocking socket may result in the sendfile(2) call blocking until enough struct sf_buf's are made available.