about NetApp

Неожиданный для компании, и очень заметный рост объемов в регионе EMEA, в первом, уже посчитанном полугодии этого года, кажется стал причиной того, что московское представительство NetApp “продавило” работы по “локализации” на российском рынке.

Начиная со следующего месяца на русском языке будет “на пробу” выходить ежемесячная “электронная газета”, она же рассылка по e-mail – Tech ONTAP. Возможно, что некоторые, интересующиеся тематикой, уже получают ее на английском.

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

“Квантовый скачок” в управлении виртуальными инфраструктурами – новинки компании, объявленные на VMworld 2009: NetApp® Rapid Cloning Utility (RCU) v2.1, SnapManager® for Virtual Infrastructure (SMVI) v2.0, и Virtual Storage Console v1.0. Краткий обзор возможностей.

Пример из жизни: Консолидация серверов и хранилищ среды Windows для экономии бюджета IT – описание и анализ проекта по консолидации, осуществленного в компании Osiris Terapeutical. Практический пример перевода IT-инфраструктуры конечного клиента NetApp и VMware в виртуальную инфраструктуру, уроки и достижения этого проекта.

Ускорение репликации данных по низкоскоростным линкам – технические детали появившейся в свежем релизе Data ONTAP 7.3.2 опции компрессии трафика репликации SnapMirror, позволяющей, в ряде случаев, сэкономить до 70% трафика, и ускорить процедуры репликации данных на удаленный сайт.

Также, вот уже около года я “в порядке личной инициативы” перевожу избранные, и наиболее интересные статьи Tech ONTAP в регулярную рассылку компании “Verysell” – российского дистрибутора NetApp. По ссылке можно почитать архив выпусков. Там тоже есть кое-что интересное. Нынешний официальный Tech ONTAP на русском придет на смену этой рассылке.

Для чего я все это вам тут пишу? Вот для чего. Российскому NetApp-у нужно отрапортовать о интересе к теме, и показать американским боссам “наверх” полторы тысячи подписчиков. В этом случае это будет убедительным аргументом для компании начать всерьез заниматься “русским языком”, в частности готовить актуальные русскоязычные технические материалы, такие как, например, переводимые в настоящее время “на энтузиазме” Best Practices по использованию систем хранения NetApp для различных продуктов (см. справа ссылку “Техбиблиотека на русском”) , облегчающие непростую жизнь админа.

С учетом того, что на сегодня на этот блог ходит в месяц три с половиной тысячи уников, из них почти две тысячи с той или иной степени регулярно, не считая подписанных по RSS,  мне кажется, что эта задача вполне достижимая.

Так что вот вам баннер, вот вам и ссылка на нем:

http://communicate.netapp.com/forms/ru-tot-regform?REF_SOURCE=EMM

Ступайте и подпишитесь. Будет интересно. Гарантирую отсутствие спама. Почтовый ящик хорошо бы рабочий (компании), но если другого нет, то пойдет то, что есть. Страна – разумеется Россия, не надо по привычке Гондурас и Зимбабве выбирать. :)

Очередная заметка “по существу” как и всегда – в четверг и понедельник.

Одной из ошибок настройки при работе кластерной системы NetApp FAS является проблема подключения к LUN через “неродной” для этого LUN-а контроллер.

Кластер контроллеров FAS работает таким образом, что каждый LUN имеет некий preferred path для доступа, будучи “привязанным” к какому-то из контроллеров кластерной пары.

Однако доступ к данным возможен и при работе через вторую ноду кластера, LUN “виден” с обоих нодов кластера, вне зависимости от того, какому из контроллеров он выдан. Это необходимо, в том числе, для обеспечения отказоустойчивости. Однако, доступ через “чужой” для LUN узел, это“нештатный” способ подключения, так как при этом данные пойдут с порта “неродного” контроллера, через кластерный интерконнект, в “родной” котроллер, а из него в LUN, соответственно, обратным путем пойдут данные с LUN.

Этот процесс снижает производительность, нагружает оба контроллера, загружает ненужным трафиком кластерный интерконнект, и ухудшает responce time и latency, поэтому работы через “чужой” узел кластерной пары следует избегать.

Для того, чтобы диагностировать и устранить проблему доступа к LUN через путь на “чужой” контроллер, следует сделать следующее жирным шрифтом выделены команды в консоли (в скобках – соответствующие пункты меню веб-интерфейса FilerView).

1. Определите, к какому из LUN доступ осуществляется через порт FCP target партнерской (“чужой”) ноды.
   a. lun stats -o  (LUN STATISTICS)
2. Определите какой из хостов получает доступ к этому LUN через канал партнерской ноды
   a. lun config_check -A  (LUN CONFIG CHECK)
   b. lun show -v  (LUN CONFIGURATION)
   c. igroup show -v  (INITIATOR GROUPS)
3. Определите порт FCP target основной ноды кластера, который должно использовать для доступа к этому LUN.
   a. fcp show cfmode  (FCP CFMODE)
   b. fcp show adapters  (FCP TARGET ADAPTERS)
4. Проверьте соединение инициатора хоста с основным портом FCP target и конфигурацию MPIO на хосте.
5. Убедитесь, что доступ по партнерскому пути вместо основного прекращен на обоих узлах кластера.
   a. sysstat -b 1

Убедитесь также, что настройки MPIO правильны, и не влияют на выбор пути доступа. Рекомендуется на каждом из хостов установить соответствующий host utility kit.

Оригинал текста, на основе которого сделан пост взят там: 
http://ibmnseries.blog.com/2009/10/13/partner-path-misconfigured/