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

NAS на FreeBSD 9.0. Тестирование под нагрузкой.

Но ngctl list при большом количестве сессий вместо результата выдавало у меня ошибку даже после нескольких удвоений дефолта, вплоть до 8M. Тогда, обозлившись, я удесятерил - и ngctl list заработал. Это было при более чем 1500 сессях.

 

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

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


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

С момента создания темы новый сервер совершил две произвольных перезагрузки. 20.02 и 29.02.

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


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

правила файрвола в студию

паники в логах есть?

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


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

00200 allow ip from any to any via lo0
00300 allow gre from any to any via igb0
00400 allow ospf from any to any via igb0
00624 allow tcp from any to 192.168.254.254 dst-port 1723 in recv igb0
00650 allow tcp from table(1) to 192.168.254.254 dst-port 1001 in recv igb0
00651 allow ip from 192.168.254.0/24 to 192.168.254.254 in recv igb0
00652 allow ip from 172.16.111.0/24 to 192.168.254.254 in recv igb0
00653 allow icmp from any to 192.168.254.254 in recv igb0
00800 nat tablearg ip from table(10) to any out xmit igb1
00800 nat tablearg ip from any to table(30) in recv igb1
10000 allow ip from table(3) to any
10001 allow ip from any to table(3)
11111 allow ip from me to any out
65000 deny ip from any to any
65535 allow ip from any to any

 

/var/crash остается пустым, хотя по всем параметрам там должен оказываться дамп ядра. Словом - незачто зацепиться.

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


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

сколько адресов в третьей таблице?

 

я к тому спрашиваю, что лишний матчинг делается при таком виде правил :)

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

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


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

5k правил в ней. Остальные таблицы для админов и для разбиения нат-адресов по подсетям. Там совсем мало записей.

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


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

Тоже были ребуты на 9.0 + MPD5. Вырезал из ядра ipv6 - рубутов нет. (полтора месяца). Сейчас на одном серваке вернул ipv6. (Начал в туннели раздавать). Посмотрим что будет.

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


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

У нас ядро GENERIC просто с инклюдом кернел-ната и нетграф.

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


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

5k правил в ней. Остальные таблицы для админов и для разбиения нат-адресов по подсетям. Там совсем мало записей.

10000 allow ip from table(3) to any

10001 allow ip from any to table(3)

 

Я бы поменял например на

 

allow ip from table(3) to any recv igb0 in

allow ip from table(3) to any xmit igb0 out

 

А вообще из практики: пока не развели направления трафика (вход, выход, внешка, пиринг) по разным skipto - ребутились машинки и на 7х и на 8х ветках.

Ребутится именно из-за избыточного матчинга по таблицам в ipfw при директ диспатчинге :(

 

PS: причем ребутилось рандомно, не в пики нагрузки

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

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


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

Спасибо за совет. Мы не стали уточнять направления для этих правил в связи с тем, что по факту это множество интерфейсов ngX. Теоретически, внешний интерфейс igb0 должен определять направления трафика от и для нат-пула до маскировки и соответственно после. Сейчас поковыряюсь с этим.

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


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

Замечу, что правила

 

 recv ... in

xmit ... out

 

это как "масло масленное". recv это альяс для in, xmit, соответственно, для out.

 

Поправьте, если я неправ.

 

 

 

Спасибо за совет. Мы не стали уточнять направления для этих правил в связи с тем, что по факту это множество интерфейсов ngX. Теоретически, внешний интерфейс igb0 должен определять направления трафика от и для нат-пула до маскировки и соответственно после. Сейчас поковыряюсь с этим.

Штука в том, что поиск в правилах идёт, насколько мне помнится, от конца правила, так что теоретически заданием интерфейсов вы сильно уменьшаете количество проверок в ipfw. Правда, говорят что "via ng*" может быть даже хуже по производительности, чем отсутствия указания - как-то там "не так" ipfw проходит по списку интерфейсов.

 

 

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


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

Замечу, что правила

 

 recv ... in

xmit ... out

 

это как "масло масленное". recv это альяс для in, xmit, соответственно, для out.

 

Поправьте, если я неправ.

Нет, это разные вещи. Один признак матчит на входе/выходе в ip_input/ip_output, другой матчит по интерфейсу.

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


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

Правда, говорят что "via ng*" может быть даже хуже по производительности, чем отсутствия указания - как-то там "не так" ipfw проходит по списку интерфейсов.

Согласен. Именно по этому я стараюсь избегать таких вольностей как ng*.

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


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

Нет, это разные вещи. Один признак матчит на входе/выходе в ip_input/ip_output, другой матчит по интерфейсу.

А можно чуть подробнее расписать прохождение пакета в обоих случаях? Я полагал, что recv $iface == via $iface in.

 

Согласен. Именно по этому я стараюсь избегать таких вольностей как ng*.

А кто-нибудь вообще проверял это поведение? А то я последний раз проверял это лет эдак 4-5 назад.

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


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

Вобщем, никакие in, recv не помогают. При указании направлений трафика всё отваливается у конечного пользователя. По этому остановился на таком сценарии:

 

10000 1200775 1174900483 Tue Mar  6 18:51:26 2012 allow ip from any to table(3) in recv igb1
10001   62726    9453822 Tue Mar  6 18:51:11 2012 deny ip from any to 10.10.0.0/16 in recv igb1
10002 1155796  330462590 Tue Mar  6 18:51:26 2012 allow ip from 10.10.0.0/16 to any
10003 1191741 1174078430 Tue Mar  6 18:51:26 2012 allow ip from any to 10.10.0.0/16

 

Теперь обращение к таблице №3, содержащей 5к записей происходит лишь в одном правиле. Правило №10000 охватывает только входящий трафик, в котором прослеживаются серые адреса пользователей после деалиасинга и позволяет отдавать его пользователям с включенным инетом. Следующее правило со схожими признаками блокирует доступ всем остальным. Теперь для того чтобы трафик смог свободно ходить по виртуальным интерфейсам ng* создаем входящую и исходящую трубу без указания интерфейсов и направлений. Такая схема лучше предыдущей только за счет более редкого обращения к таблицам.

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


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

А кто-нибудь вообще проверял это поведение? А то я последний раз проверял это лет эдак 4-5 назад.

Сомневаюсь, что load average или еще что подскочит так что будет заметно на глаз. Меня волнует прежде всего стабильность работы, по этому спустя пару перезагрузок при текущем конфиге попробую указать ng* в своих правилах.

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


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

чото я совсем запутался :)

а юзеры с реальными адресами через нас ходят? и как маршрутизируется трафик извне до клиентов на насе?

 

что до ng* - у меня

ipfw add 50 deny log logamount 100 ip from any to any not verrevpath recv ng*

уже не первый год без проблем используется

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

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


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

Про внешних я забыл и только щас вспомнил. На насе установлен белый IP. Нас выполняет шейпинг, нат, pptp, netflow. Буду перестраивать на ng* завтра утром. Пока всё вернул взад.

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


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

Просто если с бордера до наса трафик заворачивается статикой, то вполне вероятна такая ситуация:

 

пакет на реальный адрес прилетает с внехи, уходит по статике на нас, на насе такого клиента нет, нас заворачивает трафик обратно на дефолт, и так пока ттл не кончится :)

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


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

В этом плане всё нормально, NAS с бордером в одной подсети, активные туннели белые через прокси-арп видны на циске. С этим проблем нет.

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


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

Про арп-прокси я слышал плохие вещи, у меня /32 клиентские по оспф ходят.

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


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

net.link.ether.inet.proxyall=1

 

Вот за счет этого белые pptp адреса видят инет. Дело в том, что маршрутизации никакой нету. Достаточно весь трафик с наса направить на стандартный шлюз из этой же подсети. Можно конечно поизвращаться и сделать DMZ, но такой вариант у нас обкатан годами и всем устраивает.

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


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

У нас ядро GENERIC просто с инклюдом кернел-ната и нетграф.

GENERIC как раз и включает в себя ipv6.

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


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

У нас ядро GENERIC просто с инклюдом кернел-ната и нетграф.

GENERIC как раз и включает в себя ipv6.

У меня с генериком все ОК

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


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

Правда, говорят что "via ng*" может быть даже хуже по производительности, чем отсутствия указания - как-то там "не так" ipfw проходит по списку интерфейсов.

 

Тут в параллельном топике на такое утверждение меня поправили, что я редко заглядываю в сорцы и все там уже "не все так плохо" :)

 

http://forum.nag.ru/forum/index.php?showtopic=72378&view=findpost&p=694954

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


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

Join the conversation

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

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

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

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

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

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

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