kaN5300

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

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

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

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

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

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 остается пустым, хотя по всем параметрам там должен оказываться дамп ядра. Словом - незачто зацепиться.

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

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

Я вот написал статейку сам для себя чтоб не забыть по методу мониторинга: http://kan5300.livejournal.com/328222.html Все сервера подключил к cacti одними и теми же способами (модули coretemp.ko для фряхи) и вижу как ростет температура в зависимости от загруженности CPU и могу соотнести полученные результаты с датой приобретения железа. Так и получилось что самый старый сервер греется больше всего. Может быть драйвер и завышает температуру, но тогда он завышает на всех (ведь камни и софт одинаковые или почти одинаковые). По этому принято решение вывести из строя этот NAS и сделать ему профилактику пока не поздно. Сейчас случайно на форуме длинка нашел вопрос про максимальную температуру чипа коммутатора. Ответ был дан такой что волноваться стоит после преодаления порога в 80 градусов. Нам вчера 4 градуса не хватило до этой отметки. ЗЫ: еще на amd-шки установил мониторинг через соответствующий .ko. Там не такие высокие частоты на оптеронах, хорошее охлаждение и idle около 80%. Максимум 54 градуса показал один из серверов. За них не волнуюсь.

Тот инсталл который помирал был отброшен на 7.4-RELEASE и вобще там не все в порядке с железом, это отдельный вопрос. Тот второй сервер о котором я писал всё-таки допустил один произвольный ребут. Самое интересное происходит на нашем новом NAS на базе процессора i7-990X. Туда был накачен 9.0-RELEASE amd64 с последующим обновлением до 9.0-STABLE. Сервак проработал пока чуть больше суток. В пике 35 kpps, 700 туннелей и idle самого загруженного ядра составлял при этом 70%. Видно что запас по производительности есть. Теперь главное - добиться стабильной работы.

А откуда такие "страшные" цифры? Для интереса попробовал "на летУ" установить net.graph.maxdgram=8388608 и net.graph.recvspace=8388608. mpd тут же ушёл в ступор (ошибка 678 у виндовых клиентов).. Пришлось вернуть всё взад и ребутать mpd. Правда перед этим не увеличивал kern.ipc.maxsockbuf (262144) и дело было на 8.0 P.S. Нагуглил довольно интересную подборку статей (kirush, не ваша случаем ? ;-)), изучаю.. У Дадва офигенные статьи. Отправил их в мемориз и засветился в коментах. Спрашивал, будут ли заметки о 9.0. Сказал что в продакш дот-зироу релизы не выставляет. Так что ждем 9.1 и тыкаем dadv'a.

Вобщем запустили новую железяку в качестве одного из NAS. Камень i7 990X, корпус Procase 1U: --- Спереди: 5x High performance Fan 10000r/pm 40x40x28mm 40x40x56mm (Optional) Сзади: Блок питания: 1U power supply max length 250mm --- напичкан этими самыми фанами. Шумит - копец. Даже если выставить энергосберегающий режим в биосе. Кондей в серверной выставлен около 22 градусов, температура самого горячего ядра меняется в зависимости от нагрузки примерно от 27 до 40 градусов. Uploaded with ImageShack.us Так что все сомнения на счет адового перегрева камня с TDP 130 в кузове 1U отвергнуты. Заодно подключил мониторинг температуры камня на остальные NAS. И вот что я обнаружил *SHOCKED*. Пиковая температура самого горячего ядра 77 градусов. Камень Core Quad. Это один из самых древних серваков, там врядли что-то запылилось, скорее всего термопаста потеряла свои свойства и возможно кулер какой погас.

работает. У нас тоже пошло всё ровно. compat7x-amd64-7.3.703000.201008_1 поставили и всё завелось.

Из более дорогих мне нравится 5017C-MF http://www.supermicro.com/products/system/1U/5017/SYS-5017C-MF.cfm Никаких хотсвапов, cd-rom опциональный, т.е. можно от него отказаться и т.д. Но это мало чем отличается от того решения, которое мы приобрели (практически тоже самое, но сокет 1366). А вот 5017C-LF мне нравится своей миниатюрностью. Никаких салазок, монтируется как обычный свитч. Не греется, энергоэффективный. Еще не совсем ясно по использованию интегрированных сетевых чипов с драйвером igb, т.к. если взять туже платформу 5017C-LF, имеем связку 82579LM + 82574L. Во фряхе это будет выглядеть как два интерфейса em. Чтоб юзать igb придется использовать райзер (там он предусмотрен) с правильной сетевухой.

Кто-нибудь пытался запустить utm5_frw на 9.0 amd64?

roysbike, спасибо за выкладку результатов. Вижу, что isr вы также как и мы принудительно не выставляли. Сегодня наш второй таз на девятке поставил новый рекорд. 92 kpps / 700 tuns 1 minute lavg в пиковый момент протяженностью около 20 минут подпрыгнул до 6.8. Вечером колебался между 3.0 - 4.0. Самое главное - обошлось без ребутов, чего мы больше всего опасались.

На счет ксеонов, я присматриваюсь, а не ищу. А тема про поиск решений 1U на сокете 2011. Полазил по сайту супермикро и вот он, сервер моей мечты! SuperServer 5017C-LF - 200W Low-noise power supply w/ PFC - Intel® 82579LM and 82574L - DDR3 ECC 1333/1066MHz - Xeon® processor E3-1200 - supports CPUs with max. TDP ≤ 45 Watts Если следовать рекомендации по максимально допустимому TDP, то сюда можно впихнуть только это (2.4 GHz). Ожидание модного Ivy Bridge для такого сетапа даст всего ничего: 100 мегагерц (модель E3-1260L v2). Смущает также предельно низкое предложение по продажам камня 1260L. Не пользуется спросом.

Завтра будем инсталлить amd64/fbsd9.0 на ящик на базе i7 990X (про выбор сервера обсуждали здесь).

У нас боксы с решением all-in-one с nat/shaper/firewall/netflow. Что-то мне подсказывает, что у вас часть этих функций выполняет вышестоящая железяка. Так? Укажите пожалуйста используемую архитектуру и "sysctl -a | grep net.isr".

Накатил на парочку насов 9.0-RELEASE. Обновлялся через cvsup в обоих случаях с 7.4-STABLE до RELENG_9_0. После ребута пересборка и обновление всех портов (включая переход с mpd 5.5 на mpd-5.6) удаление устаревших либов и еще один ребут. Весь процесс обновления проходил удаленно. Первый тазик блестяще выстоял вечер воскресенья, после чего я принял решение по обновлению второго (о чем потом правда пожалел). Сетап обоих тазов такой: Ядро стандартное + ipfw_nat и нетграф Лоадер: net.graph.maxdata=65536 net.graph.maxalloc=65536 net.graph.maxdgram="128000" net.graph.recvspace="128000" kern.hz="1000" hw.igb.rxd=4096 hw.igb.txd=4096 hw.igb.max_interrupt_rate=32000 hw.igb.enable_aim=0 сисктл: dev.igb.0.rx_processing_limit=-1 dev.igb.1.rx_processing_limit=-1 dev.igb.0.enable_aim=0 dev.igb.1.enable_aim=0 net.inet.ip.forwarding=1 net.inet.ip.fastforwarding=1 net.inet.ip.redirect=0 net.inet.ip.intr_queue_maxlen=10240 net.inet.tcp.delayed_ack=0 net.inet.tcp.sendspace=3217968 net.inet.tcp.recvspace=3217968 net.inet.tcp.blackhole=2 net.inet.tcp.drop_synfin=1 net.inet.udp.recvspace=65535 net.inet.udp.maxdgram=57344 net.inet.udp.blackhole=1 net.inet.icmp.drop_redirect=1 net.inet.icmp.icmplim=100 kern.ipc.nmbclusters=400000 kern.ipc.somaxconn=8192 kern.ipc.maxsockbuf=83886080 kern.ipc.maxsockets=204800 net.local.stream.recvspace=65535 net.local.stream.sendspace=65535 net.link.ether.inet.proxyall=1 net.link.ifqmaxlen=10240 net.graph.maxdgram=8388608 net.graph.recvspace=8388608 net.inet.tcp.tso=0 Обращаю внимание на то что net.isr принудительно через sysctl нигде не указан и на тазах с 7.4 картина такая: <kan5300@nas6>sysctl -a | grep isr net.isr.swi_count: 1616339 net.isr.drop: 0 net.isr.queued: 1763717 net.isr.deferred: 0 net.isr.directed: -1514625606 net.isr.count: -1583659636 net.isr.direct: 1 net.route.netisr_maxqlen: 4096 <kan5300@nas6>uptime 10:48AM up 42 days, 3:46, 1 user, load averages: 1.19, 1.28, 1.37 На 9.0 картина такая: net.isr.numthreads: 1 net.isr.maxprot: 16 net.isr.defaultqlimit: 256 net.isr.maxqlimit: 10240 net.isr.bindthreads: 0 net.isr.maxthreads: 1 net.isr.direct: 0 net.isr.direct_force: 0 net.isr.dispatch: direct net.route.netisr_maxqlen: 256 Пиковые нагрузки на все тазы представляют в пиках до 800 pptp-туннелей, прокачка при этом около 40 kpps и пиковый lavg доходит до 5. Количество паник на 7.4 в среднем по 30 дней аптайма на сервак. Второй тазик с 9.0 пока себя показывает нормально, а вот первый произвольно уходит в ребут при kpps около 30 и выше при этом не оставляя никаких дампов для анализа. После ребута в /var/crash ничего нет за исключением старинного vmcore от прошлого года. За отсутствием дампа можно только гадать, изза чего это происходит. И я грежу на выставленный в ноль net.isr. На опеннете пишут что в 9.0 net.isr.direct только для чтения и предлагают использовать net.isr.direct_dispatch профили (direct, hybrid, deferred). Вот вырезка из комментариев к исходнику: SYSCTL_NODE(_net, OID_AUTO, isr, CTLFLAG_RW, 0, "netisr"); /*- * Three global direct dispatch policies are supported: * * NETISR_DISPATCH_QUEUED: All work is deferred for a netisr, regardless of * context (may be overriden by protocols). * * NETISR_DISPATCH_HYBRID: If the executing context allows direct dispatch, * and we're running on the CPU the work would be performed on, then direct * dispatch it if it wouldn't violate ordering constraints on the workstream. * * NETISR_DISPATCH_DIRECT: If the executing context allows direct dispatch, * always direct dispatch. (The default.) * * Notice that changing the global policy could lead to short periods of * misordered processing, but this is considered acceptable as compared to * the complexity of enforcing ordering during policy changes. Protocols can * override the global policy (when they're not doing that, they select * NETISR_DISPATCH_DEFAULT). */ Не совсем понятно, стоит ли включать в моем случае net.isr, т.к. драйвер igb в нашей ситуации прекрасно справляется с привязкой очередей к процессам. И в результате в top всегда утилизация всех CPU распределена равномерно (как на 7.4 так и на 9.0). Вопрос лишь в том, как добиться стабильной работы. dadv в своей статье "Тюнинг FreeBSD 8.2. Часть 1. Стабильность. (ЖЖ)" описывает проблему "dangling pointer", которая особенно проявляется при слишком частом или резком одновременном удалении системных интерфейсов под высокой нагрузкой. Но эта проблема вроде как должна быть уже решена на момент выхода 9.0 RELEASE за счет стараний Глеба Смирнова, который внес исправления в 9-CURRENT в 2011 году, насколько я понял из статьи. Врубать или не врубать ISR? И вторая мысль, опираясь на статью dadv. Пора переходить на amd64 архитектуру, ибо есть мнение что это не приведет к переполнению различных структур данных на прокаченных системах. По этому мы будем планировать постепенный ввод amd64 дистрибутивов и попробуем поиграться с режимами работы net.isr.

Сейчас Xeon X5687 Gulftown (3600MHz / 4 cores) такойже горячий (130) как 990X. Xeon E3-1280 Sandy Bridge (3500Mhz / 4 cores) уже 95 Вт. Новый уже 69Вт при техже 3500. Магический "Turbo Frequency" какбы намекает на разгон (безопасный с таким TDP). Сокет одит и тотже у обоих ксеонов (v1 и v2, LGA1155). Мы изначально привязалесь к шестиядерности, т.к. наши NAS-ы которые на гульфтаунах шестиядерных очень хорошо себя показали. Вот выбрали такой: http://market.yandex.ru/model-spec.xml?modelid=7771445&hid=91019 Но продавцы оказались в тупике, т.к. нелегко найти было серверную платформу под 2011 сокет. И тут подвернулся 990X и мы заказали сервак похожий на остальные. Сейчас по действующим моделям и анонсированным ксеонам, про которые я писал выше видно что врядли в ближайшее время появятся серверные платформы на 2011, т.к. оба E3 заточенны под 1155. Конечно ксеон выглядит привлекательней если не обращать внимание на отсутствие двух ядер в отличие от i7. Тут тебе готовая серверная платформа интел http://www.nix.ru/autocatalog/server_systems_intel/Intel_1U_R1304BTLSFAN_LGA1155_C204_SATA_RAID_2xGbLAN_4DDRIII_250W_118119.html Новое поколение процессоров влезет в тотже сокет. Всё-таки зря мы зациклились на к-ве ядер кмк.

Посмотрим как себя покажет решение на 990Х. Еще слежу за Ivy Bridge, анонс которого состоится этой весной. Xeon E3 будет на 4х ядрах и с вырезанной графикой. Например Xeon E3-1270 v2 имеет TDP всего 69 Вт при эквивалетной i7 990X частоте. Разница между ними только в к-ве ядер. Шестиядерных ксеонов E3 не ожидается. Если говорить про E5, то у анонсированных серий 24XX и 26XX частота не превышает 2.9 (Xeon E5-2667).

Виноват, в первом варианте действительно интел 82575 уже два порта на борту имеется, а значит два igb интерфейса в системе. Не надо никаких райзеров больше и модулей, что есть гут. Во втором варианте один из чипов также подходит для igb (82576EB). Но всё-таки здравый смысл не позволяет мне под сервер доступа ставить двухпроцессорную мамку. У нас похожее решение используется для DB-сервера. Из того что вы предложили мне ближе второй (маленький конфиг). SDD и оперативку опустим, а вот список топовых камней которые влезут в этот сокет: Intel Core I5-680 Clarkdale (3600MHz, LGA1156, L3 4096Kb) 9к / 2 ядра Intel Core i7-880 Lynnfield (3067MHz, LGA1156, L3 8192Kb) 17к / 4 ядра Intel Xeon X3480 Lynnfield (3067MHz, LGA1156, L3 8192Kb) 22к / 4 ядра Первый сразу отметаем, между двумя вторыми разница минимальна и там 4 ядра против 6 ядер Gulftown. i7-880 Lynnfield на платформе SR1630GPRX вполне неплохое решение с низким тепловыделением (всего 73Вт). Но мы пошли по пути выбора максимально мощного по частоте и к-ву ядер процессора.

За чем же дело встало? Intel позаботился - 2xGbLAN уже + опционально установка модуля 4xGbLAN или 2x10GbLAN, а если и этого мало + полноразмерные PCI-E. И об этом тоже - вообще рекордсмен: 1U и всего 508 мм в глубину, с 5xGbLAN на борту. З.Ы. Не забываем, что это НЕ СЕРВЕР, а платформа, т.е. к цене добавляем стоимость процессор(а|ов), памяти и HDD. По первому варианту 4xHotSwapSAS и 8DDR-III это что-то уже не совсем для роутера. Сетевушками интегрированными не пользуемся, ставим dual через райзер. По второму, у нас как раз похожий корпус получился (550 в глубину) Procase 19" 1U EB140-350W

Речь шла действительно изначально про 2011, но этот вопрос был отложен на неопределенный срок и мы взяли еще один сервак на на обычном i7. И пошел уже оффтоп. Конечно можно поставить и два тазика и три, но есть начальство и есть определенные требования. В частности не сильно ограниченный бюджет, но сильно органиченные габариты и энергопотребление.