kaN5300

Открыли для себя интеловые штуки с MSI-X и драйвером igb. NAS делает всё что можно за исключением BGP. Тоесть трасса построена на не каскадном принципе а на параллельном. Сразу несколько насов (pptp + dns round robin) терминируют pptp-сессии и натят, шейпят, экспортят nf и т.д. Затыки позникают на уровне CPU (когда все ядра подпирают к 100%). Вот и родилось требование: igb-совместимая сетевуха и многоядерный камень с максимально высокой частотой. UPD: подчеркиваю, что 980X или 990X, не так принципиально. Мы осознаем что интел берет бабки просто так за свои верхние железки. Нужен один физический проц в 6 ядрами и частотой 3.2-3.5.

PCI-X разъемов на дестктопных платах не было, а теперь похоже и на серверных не будет. 1U радиатор с трудом сможет отдавать 130w. Поэтому серверные процы обычно медленнее по частоте, но возможна покупка до 10 ядер. i7-3930K разогнанный до 4,5ГГц справляется только с вентилятором 14см и радиатором 160мм в высоту. Во многие серверные корпуса можно вставлять любую материнскую плату, в том числе десктопную. I7-990X покупать вообще смысла нету - по цене тоже самое, но на 2 поколения раньше. По производительности, правда, разница не такая больша. Про PCI-X я конечно же наврал имея в виду обычный PCI Express 2.0/3.0 Цена 990X явно завышена в полтора раза известным лидером на рынке процессоров. 980X практически тоже самое но значительно дешевле. Торопились, искали, купили то что было. Приоритет был: 6 ядер на максимальной частоте. На счет охлаждения, вся надежда на хорошую пасту и хороший отвод тепла "служебными" вентиками корпуса и блока. А также на кондик. Посмотрим как оно пойдет. Непросто уговорить начальство приобретать БУ. А так сервер неплохой, спасибо за предложение. Но это скорее Db или Web или что-то подобное. NAS должен быть маленьким и легким кмк.

Один наш поставщик ответил что ожидается поставка i7 990X. Так что собираем (скорее всего последнее) решение на Гульфтаунах. У нас будет время погонять 9.0 фряху (см. мою тему в соседнем форуме) и заодно дождаться закрепления систем Sandy Bridge-E на рынке.

LGA 2011 не так давно появился, а ксеоны (которые так любят продавать магазины) вот типа такого заанонсированы на первый квартал 2012. На нашем рынке появятся весной или позже. По этому поиск результатов не дал. Всё это меня наводит на мысли - собрать мини-десктоп вот на таком кузове: http://market.yandex.ru/model.xml?modelid=6911102&hid=91028 Охлаждение будет явно лучше чем в 1U и можно будет даже погнать камень.

Всем привет! Сейчас складывается такая ситуация, что наши поставщики, которые нам ранее продавали сервера доступа (самопал на 1U / Core i7) заявляют о дефиците верхних i7 (Gulftown) в связи с падающим спросом и таком же дефиците i7 (Sandy Bridge-E) в связи с ограниченными поставками. Решили надёргать железок по поставщикам и собрать самим. Сразу возникает два вопроса: 1. Нормальная система охлаждения. Пассивный медный радиатор типа такого http://mdata.yandex.net/i?path=b1113223922_img_id8941922418757641336.jpg Под нужный сокет найти не удалось и к тому же, как я понимаю, просто закрепить не достаточно. Надо еще чтоб медные трубки уходили куда-то в систему продува БП. Где взять совместимые компоненты? 2. Мамка будет обычная десктопная форм-фактора mini-ATX или просто ATX. Подойдет ли райзер с PCI-X к планке расширения на корпусе чтобы засунуть сетевуху или легко может оказаться что всё "поедет"?

Благодарю за отзывы! Уже запустил на одном из серваков cvsup. Пусть побегает сначала на том что есть у нас из оборудования.

Давно дело было. Стабильной работы добиться не удалось.

Спасибо за ответы. Больше всего опасение вызывает нетграф. Попробуем перевести один из действующих NAS-ов на девятку перед оплатой нового железа.

Всем привет. Рассматриваем вопрос ввода нового сервера доступа на базе FreeBSD 9.0 и камня i7-3930K (Sandy Bridge-E). Гуглинг не дает ответа на вопрос: будет ли этот камень корректно работать на 7.Х. Упоменание встречается лишь для 8.2 и 9.0. 8.Х в роли NAS мы избегаем, т.к. существует много негативного опыта коллег (например здесь). По этому сразу решили попробовать 9.0. Был ли у кого-то опыт экслуатации NAS-ов на "девятке" и платформе Sandy Bridge? Стоит ли заморачиваться? или использовать проверенное решение (7.4 + Core i7)? Или всё-таки 7.X STABLE тащит Sandy Bridge-E? В HW notes такой информации найти не удалось.

На днях Глеб в r219827 исправил (вроде как) ошибки, приводящие к зависанию системы при удалении интерфейсов. Тем временем мы нашли как через сисктл поднять процессинг лимит на igb и сделали 2048: dev.igb.0.rx_processing_limit=2048 И еще некоторые sysctl ввели для нетграфа и для сетевой подсистемы. Теперь изменения Глеба должны появиться в RELENG? Пока помониторим текущее состояние дел.

Образовалась интересная тема при вводе очередного сервера доступа. Как обычно берем топовый core i7 и двухпортовку на драйвере igb. loader.conf и sysctl.conf переносим с сервера доступа, который настраивали последним и в бой. Но не все так гладко пошло. Во первых впервые была установлена (в связи с релизом) 7.4-RELEASE (на соседнем сервере стоит еще 7.3-RELEASE), глюки: - ребуты либо во времена малой активности, либо в пик (последний page fault показал current process 28 ng_queue10) - выставление в лоадере hw.igb.rxd="2048" и hw.igb.txd="2048" приводит к неработающей сетке (пришлось убрать) Для сравнения топы во времена низкой загрузки на серваке с 7.3 (где всё ок) и на серваке с 7.4) 7.3 PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 15 root 1 171 ki31 0K 8K CPU7 7 1907.9 100.00% idle: cpu7 17 root 1 171 ki31 0K 8K CPU5 5 1900.3 100.00% idle: cpu5 13 root 1 171 ki31 0K 8K CPU9 9 1879.9 100.00% idle: cpu9 12 root 1 171 ki31 0K 8K CPU10 10 1876.0 100.00% idle: cpu10 16 root 1 171 ki31 0K 8K CPU6 6 1821.2 100.00% idle: cpu6 21 root 1 171 ki31 0K 8K RUN 1 1901.8 98.14% idle: cpu1 11 root 1 171 ki31 0K 8K CPU11 11 1890.7 96.63% idle: cpu11 18 root 1 171 ki31 0K 8K CPU4 4 1807.0 95.41% idle: cpu4 19 root 1 171 ki31 0K 8K CPU3 3 1887.1 94.97% idle: cpu3 20 root 1 171 ki31 0K 8K CPU2 2 1727.5 90.58% idle: cpu2 22 root 1 171 ki31 0K 8K CPU0 0 1667.4 85.89% idle: cpu0 14 root 1 171 ki31 0K 8K CPU8 8 1354.7 69.58% idle: cpu8 59 root 1 -68 - 0K 8K CPU8 8 667.8H 29.74% irq266: igb1 55 root 1 -68 - 0K 8K WAIT 2 130.7H 6.54% irq263: igb0 9 root 1 -68 - 0K 8K sleep 9 89.5H 3.47% ng_queue7 2 root 1 -68 - 0K 8K sleep 3 89.6H 3.37% ng_queue0 7 root 1 -68 - 0K 8K sleep 6 89.6H 3.32% ng_queue5 61 root 1 -68 - 0K 8K - 2 45.3H 3.32% igb1 taskq 3 root 1 -68 - 0K 8K sleep 11 89.6H 3.22% ng_queue1 4 root 1 -68 - 0K 8K sleep 6 89.6H 3.22% ng_queue2 29 root 1 -68 - 0K 8K sleep 1 89.5H 3.22% ng_queue11 8 root 1 -68 - 0K 8K sleep 0 89.5H 3.22% ng_queue6 27 root 1 -68 - 0K 8K sleep 0 89.6H 3.12% ng_queue9 6 root 1 -68 - 0K 8K sleep 7 89.6H 3.12% ng_queue4 28 root 1 -68 - 0K 8K sleep 10 89.5H 3.12% ng_queue10 26 root 1 -68 - 0K 8K sleep 8 89.5H 2.88% ng_queue8 5 root 1 -68 - 0K 8K sleep 4 89.6H 2.83% ng_queue3 54 root 1 -68 - 0K 8K WAIT 0 35.1H 2.05% irq262: igb0 57 root 1 -68 - 0K 8K - 2 32.5H 1.90% igb0 taskq 58 root 1 -68 - 0K 8K WAIT 2 27.0H 1.22% irq265: igb1 1139 root 2 44 0 61116K 53284K select 4 0:00 1.07% mpd5 24 root 1 -32 - 0K 8K WAIT 9 40.8H 0.73% swi4: clock sio 7.4 PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 12 root 1 171 ki31 0K 8K CPU10 10 130:13 100.00% idle: cpu10 11 root 1 171 ki31 0K 8K CPU11 11 130:11 100.00% idle: cpu11 13 root 1 171 ki31 0K 8K CPU9 9 130:10 100.00% idle: cpu9 14 root 1 171 ki31 0K 8K CPU8 8 130:09 100.00% idle: cpu8 20 root 1 171 ki31 0K 8K CPU2 2 128:15 100.00% idle: cpu2 22 root 1 171 ki31 0K 8K CPU0 0 126:17 100.00% idle: cpu0 16 root 1 171 ki31 0K 8K CPU6 6 129:34 99.17% idle: cpu6 19 root 1 171 ki31 0K 8K CPU3 3 129:33 99.17% idle: cpu3 15 root 1 171 ki31 0K 8K CPU7 7 129:41 99.07% idle: cpu7 17 root 1 171 ki31 0K 8K CPU5 5 129:28 98.39% idle: cpu5 18 root 1 171 ki31 0K 8K CPU4 4 129:05 98.10% idle: cpu4 21 root 1 171 ki31 0K 8K RUN 1 129:11 97.75% idle: cpu1 65 root 1 -68 - 0K 8K WAIT 1 0:45 1.17% irq266: igb1 67 root 1 -68 - 0K 8K WAIT 2 0:32 1.17% irq267: igb1 63 root 1 -68 - 0K 8K WAIT 0 0:51 0.98% irq265: igb1 71 root 1 -68 - 0K 8K WAIT 4 0:43 0.78% irq269: igb1 73 root 1 -68 - 0K 8K WAIT 5 0:37 0.78% irq270: igb1 77 root 1 -68 - 0K 8K WAIT 7 0:34 0.68% irq272: igb1 46 root 1 -68 - 0K 8K WAIT 0 0:32 0.59% irq256: igb0 75 root 1 -68 - 0K 8K WAIT 6 0:39 0.39% irq271: igb1 69 root 1 -68 - 0K 8K WAIT 3 0:34 0.39% irq268: igb1 48 root 1 -68 - 0K 8K WAIT 1 0:18 0.10% irq257: igb0 56 root 1 -68 - 0K 8K WAIT 5 0:16 0.10% irq261: igb0 24 root 1 -32 - 0K 8K WAIT 6 0:41 0.00% swi4: clock sio 2 root 1 -68 - 0K 8K sleep 0 0:24 0.00% ng_queue0 28 root 1 -68 - 0K 8K sleep 2 0:24 0.00% ng_queue10 6 root 1 -68 - 0K 8K sleep 0 0:24 0.00% ng_queue4 26 root 1 -68 - 0K 8K sleep 8 0:24 0.00% ng_queue8 27 root 1 -68 - 0K 8K sleep 0 0:24 0.00% ng_queue9 4 root 1 -68 - 0K 8K sleep 0 0:24 0.00% ng_queue2 9 root 1 -68 - 0K 8K sleep 0 0:24 0.00% ng_queue7 5 root 1 -68 - 0K 8K sleep 0 0:24 0.00% ng_queue3 8 root 1 -68 - 0K 8K sleep 0 0:24 0.00% ng_queue6 3 root 1 -68 - 0K 8K sleep 0 0:24 0.00% ng_queue1 7 root 1 -68 - 0K 8K sleep 2 0:24 0.00% ng_queue5 29 root 1 -68 - 0K 8K sleep 2 0:24 0.00% ng_queue11 47 root 1 -68 - 0K 8K - 4 0:11 0.00% igb0 que 52 root 1 -68 - 0K 8K WAIT 3 0:11 0.00% irq259: igb0 34 root 1 -16 - 0K 8K - 11 0:10 0.00% yarrow 60 root 1 -68 - 0K 8K WAIT 7 0:10 0.00% irq263: igb0 50 root 1 -68 - 0K 8K WAIT 2 0:06 0.00% irq258: igb0 54 root 1 -68 - 0K 8K WAIT 4 0:05 0.00% irq260: igb0 58 root 1 -68 - 0K 8K WAIT 6 0:04 0.00% irq262: igb0 64 root 1 -68 - 0K 8K - 4 0:02 0.00% igb1 que Больше всего напрягает невозможность выставить повышенный hw.igb.rxd. Погуглил это про 7.4 - ничего найти не удалось. Кроме обновления до STABLE в голову ничего не идёт.

Ващето если поофтопить, я согласен с Monstreek и добавлю, что после таких проделок (а-ля 20 сессий на рыло) абоненты начнут пускать слухи о том, что провайдер, мол, говно, не дает нормально качать торренты и вобще... Мы наоборот скорость по анлимам завысили в пользу пользователя и сделали бёрсты таким образом, что спидтест показывает поначалу 16 мбит на тарифе в 6 мбит.

Приоритет понижается одновременно с урезанием полосы.

Очереди применяем по средствам микротика на седьмом уровне, очередь шейпит все файлообменные сети. Скажем у нас 2 аплинка, 1 из них грузится больше. Создается очередь на том интерфейсе, который больше загружен. Ограничивать п2п до 40 мбит в секунду до полуночи. А на серверах доступа мы уже собаку съели. Намудохавшись с ними всё-таки пришли к идеальному рецепту. Семерка, ipfw/tables, mpd5/ng_car/ng_netflow.

Есть мнение, что подобный лимитинг создаст еще большую нагрузку на nas-сервер, чем его полное отсутствие. Мы недавно оптимизировали ipfw по максимуму, отказались от pipe, проапгрейдили сетевухи. Проблему торренсов решаем выше, на bgp-роутере. Режем в микротике по времени, чтобы не допускать перегруз канала в час-пик.

Ваш вопрос звучит примерно так:"Работаю водителем на маршрутке, в последнее время пассажиры пытаются возить свинцовые плиты весом 4,2 тонны, при чем в количесве 2 штук каждый. Подскажите, следует ли ограничить вес одного пассажира вместе с багажем 150 кг?" Я думаю, Вы сами ответите на свой вопрос. По теме: у нас стоит ограничение 300 сессий на безлимитах "домашний" и 3000 сессий на помегабайтке. Можно пример лимитирования для ipfw??

У нас похожим образом раздается вип-доступ в инет для организаций с белыми адресами, которые не могут работать по pptp. Управляемое оборудование разного рода D-Link. Инцидентов пока не было и прорблему никак не решаем. Интересно будет выслушать предложения.

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

Некое конкурентное преимущество. В последнее время не так актуально. С другой стороны - кризис...

Сквид с рестикциями. Могу кинуть конфиг.

Как раз в нетапе понасоздавав различный костылей можно добиться требуемого функционала. Также, хочу заметить, что отечественные разработчики, как правило, готовы изменить функционал по требованию клиента.

создайте на свитче snmp community "public" v1 (как правило и так создано в дефолтной конфигурации) и включите snmp глобально. После этого заюзайте snmpget соглавно примерам из опеннета.

А какой биллинг?

/boot/loader.conf: hw.em.rxd="1024" hw.em.txd="1024" /etc/sysctl.conf: net.inet.ip.fw.verbose=1 net.inet.ip.fw.verbose_limit=5 net.link.ether.inet.proxyall=1 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 kern.ipc.somaxconn=512 net.inet.icmp.drop_redirect=1 net.inet.icmp.log_redirect=1 net.inet.ip.redirect=0 net.inet.ip.dummynet.hash_size=2048 net.inet.ip.dummynet.max_chain_len=32 net.inet.ip.dummynet.expire=1 net.inet.ip.dummynet.io_fast=1 # em driver tuning dev.em.0.rx_processing_limit=400 dev.em.1.rx_processing_limit=400

У нас полно глюков было, когда мы до 5.2 не доапгрейдились. Щас 5.2 - полет нормальный.