Nest Org Ru Team Site

UPDATE1: VAL внес важную поправку во всю писанину – “ни черта не понятно”. Завтра запишу видео, с комментариями

Много букв, основной тезис – “аггрегация и iSCSI не работает быстро”. Чуть разверну

Почему-то не в первый раз сталкиваюсь с ситуацией, когда разнообразные товарищи пытаются что-то “пофиксить”, добиваясь максимальной производительности от связки Microsoft iSCSI Initiator и Oracle Unified Storage/Solaris 11/OSol/OI COMSTAR. В результате беглого анализа обнаруживается любопытная связка – сервер Windows 200x + NIC Teaming (Link Aggregation, или объединение линков, это по-нашему) на нем (благо многие брендовые сервера содержат в себе отличные сетевые наборы от Intel c соотв. обвязкой) + Oracle iSCSI Software Target (COMSTAR/Unified). И коронный вопрос “и где тут ваши сотни мегабайт в секунду?!”.

Ну так вот, для желающих сделать аггрегацию, дабы ускорить процессы ввода/вывода на системах – такая схема НЕ поддерживается, о чем прямо говорится в документации Microsoft iSCSI Software Initiator 2.x Users Guide на страничке 15 (зацитирую): Microsoft does not support the use of NIC teaming on iSCSI interfaces. тчк. Ну не поддерживает MS такой конфигурации (что логично в силу особенностей траффика iSCSI). Работать, тем не менее, такая схема будет, но никаких фантастических результатов на ней достигнуть, увы, не получится – как показало беглое исследование (некий свитч Cisco, как бы не 2950, x86 машина с 4-мя ethernet, uss7000 + tcpdump + наблюдение за свитчом), балансирока, применяемая для аггрегированных линков, не обеспечивает эффективное “разведение” траффика по конкретным линкам внутри аггрегации. По сути – это пустая трата ресурсов.

Дальше сколько-то слов про “что делать?” и “как быть?” Read more…

Все никак не угомонюсь – пытаюсь уложить кабеля на борту и так, и сяк – все что-то не нравиться, не так натянуто, не так лежит. Даже вроде все сделал. В процессе полетов (и только так – никак иначе!) приходит (ага, вот оно) понимание, как оно должно быть.

Собственно, ранее я подрезал почти все кабеля, которые, на мой взгляд, мешали качественно укладке кабелей. Добавил три отверстия в серво-трей. Аккуратно упаковал кабеля. И оставил свой “колхоз” с кронштейном для крепления приемника – алюминиевая поделка, которая портила внешний вид и изрядно меня раздражала.

Сегодня, с помощью двойного скотча и очень плотного и тонкого поролона сделал корзинку для приемника – хорошая виброгасящая основа появилась. Убрал алюминиевый колхоз, поставил приемник (через проставки) поверх линейного BEC’a – и место для вентиляции осталось, и помех от него не ожидается.

Завтра приложу фотографии, покажу, что и как сделано, а в субботу – по погоде – облетаем Белку. Короче, нет предела совершенству

Несколько вводных новчика про пилотаж и ремонт. Очень Много Букофф (ОМБ какой-то получился ) запихнул под “кат”…

ЗЫ: обещанные фотографии:

Read more…

Найти вменяемые комментарии про настройки мотора на русском языке – я не смог. Я не умею пользоваться гуглом, признаю. И не надо

Итак. Продолжая записки новичка. Закуплен термометр. На радостях зарегулировал двигатель. До 147 градусов Блин, за малым не спалил…

Остановился. Дождался спецов, получил втык за кривые настройки. Вернул все на место. Разобрался (чуть-чуть) с настройками. Спустился до 100-120 градусов (вроде как приемлемо). Далее – все глубокое ИМХО, так как возможностей “запороть” мотор неверными регулировками – миллион и еще один случай.
Read more…

Вводная по проблеме: после настройки Sun Storage 7000 и Windows 2008 R2 утилизация сети по данным Task Manager OS Windows, Wireshark и аналитики 7000-ной серии составляла порядка 25-30%, пропускная способность одного линка составляла не более 25-35 Мб/с в пиковых значениях. Что меня, естественно, не устраивало в корне – 3 линка в сумме давали максимальное аггрегатное значение в 100-120 Мб/с пропускной способности, и – самое нехорошее – создавало абсолютно нездоровую и непроектную нагрузку по CPU на системе хранения – SYS по аналитике на 7410 достигал странных (с моей точки зрения) значений в 7-10 процентов при фактически очень низкой нагрузке.

Кое-какие правки в реестре. Для получения вменяемых результатов с iSCSI.

Разрешаем Jumbo Frames для адаптеров (для примера взят SunFire X4600M2, Intel NIC 1000/MT Dual):

“Чиним” ключи реестра:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
	GlobalMaxTcpWindowSize = 0x01400000 (DWORD)
	TcpWindowSize = 0x01400000 (DWORD)
	Tcp1323Opts = 3 (DWORD)
	SackOpts = 1 (DWORD)

…и…

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces]
выбираем адаптера с нашими iSCSI подключения, исправляем ключи:
	TcpAckFrequency = 0x1 (DWORD)

Радуемся скорости!

Так случилось, что на Futaba T7C отломал переключатель (switch) “D”. Печально, досадно, в целом – мне не актуально (пока) – но как бы неаккуратненько. Вал посмотрел, была дана команда “не очкуй, славик, прорвемся !”. Излом получился ровный, почти не рваный, соседнюю крутилку – не зацепило вовсе – как и плату с корпусом, на котором они “сидят”. Короче, в результате получилось вот что:

Сам переключатель внутри – полый, внутри – пружинка. Для замены качалки переключателя Вал нашел где-то контакт позолоченный (понты ), пружинка успешно была укорочена дремелем (= не повредили ее геометрию).

Удачного колхоза

B) The write cache is non volatile, but ZFS hasn’t been configured
to stop flushing it (set zfs:zfs_nocacheflush = 1).
Note, ZFS enables the write cache and will flush it as necessary.

Посмотрим , что скажет ax150 на эту опцию Ожидаю увидеть сильное уменьшение asvc_t .