about NetApp

Всем привет ! :)

Сегодня мы рассмотрим в подробностях процесс настройки SAN на cDOT с подключением к Cisco MDS.

Как вы знаете из документации, Clustered Data ONTAP требует использования NPIV при работе с Fiber Channel. NPIV расшифровывается как N-Port ID Virtualization, и мы не будем путать эту аббревиатуру с NPV (N-Port Virtualization). Это две разные вещи, хоть и гуглятся бок о бок ;)

NetApp использует NPIV для того, чтобы абстрагироваться от используемого железа на пути от FC HBA до клиентского оборудования. Поскольку мы используем логические интерфейсы – LIF – мы можем не только создавать несколько логических портов на одном физическом порту HBA, но и использовать для них разные WWPN. 

Это особенно удобно при создании зон, FC-зоны создаются с использованием WWPN логических интерфейсов, а подлежащие «железные» порты могут меняться в любой момент. 

Например, возьмем двухнодовый кластер FAS6250, на каждой голове которого мы используем 2 FC-адаптера:

netapp_clus::*> fcp adapter show -fields fc-wwnn,fc-wwpn 

node                 adapter fc-wwnn                           fc-wwpn                  

———-           ——-   ———————–         ———————–  

netapp_clus-01 2a         50:0a:09:80:89:4c:bc:6d  50:0a:09:81:89:4c:bc:6d   

netapp_clus-01 2b         50:0a:09:80:89:4c:bc:6d  50:0a:09:82:89:4c:bc:6d  

netapp_clus-02 2a         50:0a:09:80:8f:ab:bd:cd  50:0a:09:81:8f:ab:bd:cd   

netapp_clus-02 2b         50:0a:09:80:8f:ab:bd:cd  50:0a:09:82:8f:ab:bd:cd  

Мы видим, что адреса портов на LIF’ах отличаются от адресов на физических портах:

netapp_clus::> net int show -vserver vs1   

(network interface show)             

Vserver  Logical                         Status         Network                    Current             Current  Is     

             Interface                   Admin/Oper Address/Mask               Node                Port       Home 

————————————————————————————————————— 

vs1        

             netapp_clus-01_fc_lif_1 up/up    20:04:00:a0:98:21:30:55 netapp_clus-01    2a      true             

             netapp_clus-01_fc_lif_2 up/up    20:05:00:a0:98:21:30:55 netapp_clus-01    2b      true

             netapp_clus-02_fc_lif_1 up/up    20:06:00:a0:98:21:30:55 netapp_clus-02    2a      true 

             netapp_clus-02_fc_lif_2 up/up    20:07:00:a0:98:21:30:55 netapp_clus-02    2b      true

В этом логе отображена конфигурация Vserver’а, на котором поднято 4 LIF’а. Они привязаны к физическим портам и имеют собственные виртуальные WWPN. Если в будущем нам потребуется заменить карточку HBA в слоте 2, идентификаторы портов на LIF’ах при этом не изменятся, и нам не придется переделывать зоны.

Переходим к следующему звену нашей сети - FC-свитчам. В данном проекте мы используем Cisco Nexus 5020, и для работы с cDOT нам понадобится включить на нем NPIV.

nxs5020-vcloud1# conf t

nxs5020-vcloud1(config)# feature npiv

Проверяем себя на адекватность:

nxs5020-vcloud1# show feature | i npiv 

npiv                  1         enabled

Проверяем, что у нас настроены VSAN’ы zoneset’ы и зоны

В этом примере мы используем VSAN 101, и у нас настроен  один zoneset, с одной zone. 

Пример настройки zoneset:

nxs5020-vcloud1# show zoneset brief vsan 101 

zoneset name test-zoneset vsan 101   

  zone test-zone

Пример настройки zone:

nxs5020-vcloud1# show zone vsan 101 

zone name test-zone vsan 101   

  fcalias name esxtest-1-vmhba2 vsan 101     

  pwwn 20:00:00:25:b5:00:00:1a      

  fcalias name netapp_clus-01_fc_lif_2 vsan 101     

  pwwn 20:05:00:a0:98:21:30:55

Для простоты чтения конфига, алиасы в этом примере названы так же, как и интерфейсы на Vserver.

Теперь, когда у нас настроены свитчи и есть связность между СХД и серверами, нам осталось настроить LUN’ы и отдать их хостам. 

Для этого нужно:

• создать initiator group

• добавить WWPN’ы хостов в эту группу

• Создать LUN

• Привязать LUN к этой igroup.

При создании igroup нам нужно правильно указать тип ОС. Это, в частности, поможет системе правильно использовать ALUA. 

netapp_clus::> igroup create -vserver vs1 -igroup esxtest_fcp_igrp  -protocol fcp -ostype vmware

После этого мы можем добавить в группу наши инициаторы:

netapp_clus::> igroup add -vserver vs1  -igroup esxtest_fcp_igrp –initiator 20:00:00:25:b5:00:00:1a

?? в результате мы получаем настроенную igroup:

netapp_clus::> igroup show -vserver vs1 

Vserver   Igroup              Protocol  OS Type   Initiators 

——————————————————————————— 

vs1       esxtest_fcp_igrp  fcp         vmware    20:00:00:25:b5:00:00:1a

Осталось совсем немного – создать LUN (обязательно правильно указать тип ОС, иначе мы обеспечим себе потенциальную потерю производительности):

netapp_clus::> lun create -vserver vs1 -path /vol/fcp/test -size 250g -ostype vmware

Привязать его к igroup:

netapp_clus::> lun map -vserver vs1 -path /vol/fcp/test -igroup esxtest_fcp_igrp

?? проверить, что мы нигде не ошиблись:

netapp_clus::> lun show -vserver vs1 

Vserver   Path                           State   Mapped   Type           Size 

—————————————————————————– 

vs1         /vol/fcp/test                online  mapped   vmware      250GB

netapp_clus::> lun mapped show -vserver vs1 

Vserver    Path                     Igroup                LUN ID  Protocol 

———————————————————————– 

vs1          /vol/fcp/test          esxtest_fcp_igrp  0          fcp

Вот и все ! Новый LUN готов к использованию нашим ESX-хостом.

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

Что вы, как пользователь системы, должны знать, уметь и сделать, чтобы поддержка не огорчала.

Начнем с основ.

1. Надеюсь, вы уже скачали и прочли NetApp Support Owner’s Guide. Для него есть русский перевод, правда не самой последней версии этого документа, но если у вас сложности с английским – читайте русский перевод, он вполне годится.

2. У вас включен и настроен NetApp Autosupport – служба, которая доставляет в поддержку NetApp логи системы и уведомления о том, что на ней происходит штатного и нештатного. Наличие таких данных, в том числе не только “моментальных”, а, в том числе, на протяжении периода времени до момента отказа, очень важное подспорье в анализе причин проблем, не недооценивайте его. С данными автосаппорта поддержка не только видит, что “все сломалось”, но также может посмотреть “когда сломалось”, “что делалось прямо перед этим”, “как работало, когда было еще не сломано”, и так далее.

3. Возможно вы установили и используете NetApp’s Remote Support Diagnostics Tool – компонет для RLM/SP, позволяющий поддержке удаленно коннектиться через него непосредственно в вашу систему хранения.

Что вам стоит сделать (проверить, если вы это делали раньше, и сделать, если еще не сделали)

1. Проверьте полноту и правильность информации, которую вы завели по своей системе и аккаунту в целом в support.netapp.com. Проверьте актуальность адреса (компании и, отдельно, доставки запчастей, если они отличаются), телефонных номеров, контактных данных (телефон, адреса email) ответственных за контакты с поддержкой.

Что делать, если необходимо обратиться в поддержку:

1. DON’T PANIC! :) Начните с того, что постарайтесь четко и однозначно сформулировать проблемную ситуацию. Поддержка оказывается на английском языке, но все мы понимаем, что иногда и на русском-то бывает сложно сформулировать и объяснить проблему. Начните с того, что опишите и запишите проблему на русском (на родном для вас языке), но обязательно запишите, оформите это как связный текст. Затем пройдите несколько раз, сокращая текст и уточняя, устраняя возможные неясности, неточноти и “мутные” места описания. Постарайтесь сократить его до минимально необходимого размера. Запишите максимально короткими и ясными предложениями.
Подумайте, какие дополнительные данные могут понадобиться в саппорте (логи, за какой период, данные perfstat, stats, что-то еще). Далее либо найдите того, кто вам поможет перевести данный текст на английский (не пользуйтесь автоматическими переводчиками!), либо, если это невозможно, тогда посылайте текст на русском, сделав в начале кейса приписку, что “case description language below is russian, please route it to appropriate person”. Да, это возможно. Разбор вашего текста и нахождение понимающего по-русски может занять какое-то время, но NetApp большая компания, в ней много народу работает, из очень разных стран, есть и русские, есть и разные восточноевропейцы, понимающие русский, так что практика показывает, что если вы совсем никак не можете по-английски, то это не является барьером для получения поддержки, на самом деле.

2. Подготовьте необходимые данные для идентификации вашей системы, такие как ее серийный номер (Serial ID), System ID, Purchase Order Number (это все можно найти, например, на странице вашей системы в http://mysupport.netapp.com/eservice/SupportHome.jsp. Таким вещам полезно всегда быть под руками и не только для NetApp. В моей практике я специально собрал все такие данные на все оборудование, потратив неделю времени, на отдельную страничку внутреннего портала, потратил неделю, зато теперь все под руками в самом экстренном случае.

3. Соберите и держите под руками необходимые данные о работе системы, такие как логи /etc/messages и syslog, актуальные результаты perfstat, сделанные во время набюдаемой проблемы. ??спользуемые версии, от версий Data ONTAP, до версий прошивок дисков, полок, и так далее. Если вы заводите кейс с высоким приоритетом (выше 3), подготовьтесь к тому, что позвонить с уточнениями могут в любое, в том числе нерабочее для вас время. Высокие приоритеты начинают колбасить всю группу поддержки и вовлекают в процесс много руководства. С одной стороны не стоит злоупотреблять, с другой - повышение приоритета, по моему опыту, хорошо гальванизирует саппорт, если ваша заявка зависла в Unassigned (Бывает, чо уж скрывать. У всех бывает). Помните, однако, также про разницу во временных поясах.

4. Заведите кейс (case) на странице службы поддержки в вашем аккаунте на http://mysupport.netapp.com/eservice/SupportHome.jsp
Снова: если есть проблема с английским, то не пользуйтесь автопереводчиком (а то он вам напереводит - не разгребете потом), либо найдите человека, который напишет вам перевод вашего текста, написанного на русском, либо посылайте на русском с припиской, которая поможет идентифицировать текст как русский и отправить его к понимающему этот язык. Напомню, официально поддержка на русском не оказывается, но неофициально компания часто идет навстречу.

TIPS: Если вы можете худо-бедно писать по-английски, но, например как я, часто “плаваете” в грамматической правильности выражений и сомневаетесь в ясности и понятности того, что вы пишете в ходе переписки с англоязычной поддержкой, могу порекомендовать вам полезный способ использования автопереводчика, например http://translate.google.com или http://www.bing.com/translator/ (не недооценивайте последний, MS проделала за несколько лет довольно серьезную работу) для проверки вашего текста “обратным переводом”.

Обычно я пишу на английском, а потом, чтобы убедиться, что получившееся разбирается в понятный текст и я не путаю никакие слова, я копирую предложение или его фрагмент в автопереводчик “английский -> русский”, и смотрю, получается ли хотя бы примерно то, что я хотел сказать? То есть я не использую переводчик как в чистом виде переводчик, к сожалению автоперевод все еще, для такого грамматически непростого языка, как русский, создает неприемлемого качества вывод, тем более для такого критичного содержимого, как переписка с поддержкой. Но в этом случае вы используете автопереводчик как своеобразный “валидатор”, парсер. Если то, что вы насочиняли, “распарсилось” в хотя бы приемлемый и понятный вам текст с англйийского на русский, то скорее всего его разберет и человек. Если нет – меняйте, подбирайте слова, упрощайте фразу до тех пор, пока даже тупой автопереводчин не начнет понимать то, что вы пишете. Это даст гарантию, что вас и ваш английский разберет и нормальный человек. Не стоит стесняться выражений типа Данила, ай нид хелп. Ваша задача быть абсолютно ясным, а не развлекать индийцев литературным английским.

Методы “самопомощи” (можно использовать как до обращения в поддержку, так и во время ожидания).

1. Поищите ответы по ключевым словам вашей ситуации на:

а. NetApp KnowledgeBase: https://kb.netapp.com/support/index?page=home&access=s

b. Пользовательском коммьюнити https://communities.netapp.com/welcome, а также в русскоязычной группе https://communities.netapp.com/groups/netapp-ru

c. Поищите зацепки в списке известных багов: http://mysupport.netapp.com/NOW/cgi-bin/bol/

d. Понятнее сообщения EMS (Enterprise Messaging System) в логах NetApp станут, если вы введете их в Syslog Translator: http://mysupport.netapp.com/eservice/ems. Если вы столкнулись с kernel panic в системе, то помочь разобраться в причинах может помочь Data ONTAP Panic Message Analyzer: http://mysupport.netapp.com/NOW/cgi-bin/pmsg/

d. Наконец, Google. Как ни банально бы прозвучал такой совет. В интернете есть несколько англоязычных форумов, где можно найти встретившихся со сходной с вашей проблемой, и Гугл довольно неплохо находит соответствующий тред по ключевым словам. Попробуйте вычленить для поиска в Google более-менее уникальную группу ключемых слов, например номера и коды ошибок в выводе, фрагменты сообщения об ошибке, взятые в кавычки в качестве строки поиска (точное соответствие), и так далее.

2. Проверьте вопросы совместимости с помощью NetApp Interoperability Matrix Tool: http://mysupport.netapp.com/NOW/products/interoperability/
Помните, “работает” не равно “поддерживается” или “будет работать всегда с любым релизом DOT”.

3. Вся информация по конфигурации и допустимым лимитам “железа” стораджей NetApp собирается на Hardware Universe: http://hwu.netapp.com/Home/Index

В следующем посте я “проинтервьюирую” сотрудника техподдержки в российском офисе NetApp. Он ответил на мои вопросы и порекомендовал ряд интересных “типсов” и “триксов”, которые можно использовать при обращении в поддержку.

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

Несколько недель назад на Хабре была забавная статья про то, как обращаются в поддержку представители разных стран. Автор работает в компании, клиенты которой есть по всему миру и сравнивает характер пользователей различных стран. Там он, правда, некритически, как мне кажется, относится к “русским”. Потому что у (условных) “русских” обращение в поддержку выглядит так:

Что-то работает не так. Пойти поискать в гугле и яндексе. Написать в форум ixbt или sysadmins.ru пост вида: “Ребята, у меня что-то не работает так, как должно. Как исправить?”. Подождать неделю. Через неделю обнаружить в треде 28 страниц флейма, кто более говно – HP или IBM (в итоге все стороны сходятся, что – Oracle), объяснений что у топикстартера кривые руки, и что под Линуксом все работает, и вообще, что автор – лох. Снова поискать в гугле. Написать пост в ЖЖ в ru_root. Почитать комменты. Попереводить найденное в гугле с помощью Google Translate. Ничего не найдя, спустя две недели, тяжело вздохнуть, и завести кейс. ?? получить через 40 минут в нем сообщение, что это была бага, поправленная пару недель назад, в патче таком-то, вот ссылка.

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

Пока же, немного о том, что нам, как кастомерам, дано в качестве интерфейса взаимодействия с поддержкой.

Continue reading ‘Как получать поддержку. Часть 1’ »

Одной из наиболее болезненных и чувствительных тем для любого пользователя энтерпрайзных систем, является вендорская поддержка. В этой и следующих публикациях в блоге я постараюсь раскрыть то, как получать поддержку вендора. Не секрет, что для наиболее эффективной поддержки, для скорейшего получения результата, приходится приложить усилия не только службе техподдержки, но и вам. Я постараюсь перечислить и описать все, что вам, с вашей стороны как клиента, нужно сделать, чтобы поддержка радовала, работала быстро, не “тупила”, и задачи решались максимально быстро.

Начнем с основ. С того, какая поддержка у NetApp есть, и как оно все работает.

Сперва разберемся, что есть Hardware Warranty, и что в нее входит,и что такое Software Subscription, и что входит в нее, и чем одно от другого отличается. Я заметил, что для некоторых моих читателей эти понятия не вполне ясны. ??так.

Continue reading ‘Как получать поддержку: Часть 0’ »

Новый перевод выложен в Netwell Techlibrary:

Руководство по дизайну, установке и настройке Flash Pool
Skip Shapiro, NetApp
Март 2014 | TR-4070

В этом руководстве рассматривается NetApp® Flash Pool™ - механизм интеллектуального кэширования ввода-вывода данных с использованием гибридных aggregate с твердотельными дисками (SSD). Приведено описание технических деталей работы механизмов кэширования, как и когда оптимальнее использовать его для ускорения работы и удешевления системы хранения, даются рекомендации и «наилучшие практики», рекомендованные дизайны и ключевые аспекты для успешного развертывания Flash Pool aggregates.

Скачать .pdf (29 страниц) можно на странице Библиотеки на сайте Netwell:
http://www.netwell.ru/production/techbiblioteka.php

??так, завершая наш цикл постов про переход с Data ONTAP 7-mode на Clustered Data ONTAP, принципиально новую версию OS Data ONTAP, переход на которую пользователей идет вот уже несколько лет, и вот, наконец, этой осенью выходит на финишную прямую, и компания NetApp, наконец, этой осенью выпускает очередную версию Data ONTAP, в которой уже не будет режима 7-mode, и будет только Clustered Data ONTAP.
Да, уже существующие системы и версии Data ONTAP продолжат поддерживаться, но все новые версии будут уже только Clustered, или C-mode (Cluster-mode).
Это значит, что именно этой осенью вам стоит решить, остаетесь ли вы на текущей версии, и отказываетесь от всех новых фич, которые уже появились, и еще появятся, или же идете вместе с NetApp.

Одной из основных проблем, среди нескольких, которые встают перед решившимся на такой переход, является невозможность перехода такого, который называется data-in-place, то есть с сохранением данных на дисках на их местах. Невозможность простой миграции - довольно привычная ситуация для пользователей систем других вендоров, стоит вспомнить, например, переход с EMC Clariion на EMC VNX, или с HP EVA на HP 3Par. Все такие переходы у большинства вендоров делается с “полной пересборкой” системы. Нельзя взять дисковую полку от EMC Celerra, со всеми лежащими на них данными, и подключить прямо к VNX, и сразу же продолжать с ними работу.
Не так было у NetApp. Много лет как апгрейд у NetApp делался с полным сохранением данных на диске. Вы могли взять FAS3040 с дисками FC в полках DS14MK4, системы, выпущенной лет 10 назад, и просто заменить ее контроллеры, или же установить на нее самую последнюю версию Data ONTAP и все заработает без необходимости делать бэкап данных, и восстанавливать их на новую систему, на новые, или те же самые диски.

К сожалению, для перехода с 7-mode на Clustered Data ONTAP такого простого перехода сделать нельзя. Структуры данных на дисках существенно и сильно поменялись, поэтому просто “сконвертировать” данные “на месте” - невозможно.

Незадолго до начала задуманной серии постов я встречался со специалистами дистрибуторской компании Netwell, компании, с сотрудниками которой меня связывает долгое сотрудничество по “переводному проекту”. Тогда же они мне рассказали, что они оказывают помощь российским пользователям NetApp по переходу на Clustered Data ONTAP, и миграции данных, предоставляя необходимое оборудование и помогая инженерами, то есть осуществляя Professional Service, как это называется “там”.
?? тогда мы договорились, что знакомый многим по нашему форуму Евгений Денисов, сотрудник Netwell, подробно расскажет про эту услугу в моем блоге.
Ниже - наш разговор.

romx: ??так, что же надо сделать, если мы “решились на переезд”?

ED: Вам нужно связаться с вашим партнером, через которого вы покупали систему, и, если вы покупали ее через нас, дистрибутора Netwell, то партнер связывается с нами и передает эту задачу нам. Мы контактируем с вами, узнаем, что за конфигурация у вас сейчас, каков объем мигрируемых данных, и прочие технические детали, согласуем сроки. Затем мы привозим к вам на сайт сторадж, собираем его в кластер, затем мигрируем ваши данные на него, затем разбираем и переконфигурируем ваш сторадж в кластер, затем мигрируем данные назад, очищаем наши диски от ваших данных, проверяем, что миграция успешна, и вы получаете готовую систему в Cluster-mode, и с вашими данными, перенесенными на нее.

romx: Этот сторадж, что это?

ED: Это “подменная” система из нашего демо-пула оборудования, которую мы держим для внутренних нужд, демонстраций у пользователей, и так далее. У нас есть также достаточный объем дисков. Впрочем, для очень больших объемов переноса могут быть сложности, так что - связывайтесь предварительно.

romx: Как все это осуществляется физически? Каким образом переносятся данные?

ED: Если это файловые шары, то есть данные хранятся в NAS-режиме, по протоколам SMB/CIFS или NFS, то есть нетапповский инструмент: 7-Mode Transition Tool, 7MTT. Он в полуавтоматическом режиме переносит все данные с системы в 7-Mode на Clustered Data ONTAP. К сожалению такого средства нет для блочных данных, поэтому их мы мигрируем вручную, копированием через хост. На новой системе создается LUN, затем данные со старого LUN-а копируются в новый, затем, после пересборки пользовательской системы в кластер - назад.

romx: Сколько все это занимает времени?

ED: Мы укладывались в довольно большом проекте за выходные. Так что можно считать, что за два выходных дня и менее можно перенести практически любую систему. Бывают всякие случаи, поэтому нам и нужно заранее согласовать объемы работы и время.

romx: Со временем - понятно. А сколько это стоит?

ED: Для пользователей это бесплатно. Ну, то есть это, как любой professional service, стоит денег, но NetApp покрывает эти затраты нам, так как заинтересован в скорейшем и максимально массовом, беспроблемном переходе. Так что для пользователя это бесплатный сервис и бесплатный процесс.

romx: Это сейчас делаете только вы, из всех дистрибуторов в России?

ED: Насколько я знаю - да. Если вы - наши, то вам повезло. Если вы, допустим, “мерлионовские”, то спрашивайте о такой услуге у них. У них также есть необходимые ресурсы это сделать для вас.

romx: Технический вопрос: Получается, что на дисках системы, которую вы привозите для проведения миграции, после нее остается копия пользовательских данных?

ED: Нет, конечно мы уважаем секьюрность пользовательских данных, после миграции все данные на наших дисках уничтожаются в присутствии клиентов. Это может быть или простое удаление всех томов и LUN-ов после обратной миграции (это уже необратимый процесс), либо, если действуют особые требования по информационной безопасности, то делается процесс disk sanitization, это полное затирание содержимого дисков. Это, впрочем, существенно дольше, чем простое удаление.

romx: ?? у вас уже есть опыт такой миграции, да и вообще быстрой сборки и развертывания кластера? Спрашиваю, потому что для любого сисадмина сломать работающую систему - поступок, причем в нашем случае - необратимый. Вдруг что-то пойдет не так? Не удастся все быстро собрать и мигрировать за “maintenance окно”?

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

romx: Спасибо, в целом на все вопросы есть ответы. Если у читателей будут еще какие-то уточнения и конкретные вопросы, то их можно задавать?

ED: Конечно, например в комментарии к посту, я их, да и вообще тебя читаю регулярно.

??так, в прошлый раз мы начали трогать тему перехода с Data ONTAP 7-mode, на Clustered Data ONTAP, и все что с этим связано.

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

Если вы уже последовали намеченным путем, то есть прочитали TR-3982 Clustered Data ONTAP 8.2: Введение, доступный в переводе на сайте Netwell. Посмотрели учебные материалы про Clustered Data ONTAP, почитали документацию, поставили и покрутили симулятор, то следующий шаг - планирование перехода.

?? тут я бы хотел напомнить, какие у нас есть сложные моменты.

Прежде всего - это ограничение, которое накладывается на число узлов кластера, с использованием старых и слабых контроллеров.
Как я уже не раз тут говорил и приводил эту пословицу: “Скорость эскадры определяет скорость самого медленного в ней корабля”. Так и в случае кластера. Да, с использованием самых топовых контроллеров, например FAS8060 или FAS6200, вы можете построить кластер вплоть до 24 узлов для NAS и 8 узлов для SAN, верно.
Но если у вас в кластер включены FAS3160 или FAS2200, то тогда максимальные размеры кластера определят эти “медленные корабли”. Это стоит помнить, и сразу здраво оценивать, хотите ли вы пихать в новый кластер старые контроллеры, которые, в теории, может быть, и могут быть в него включены, но своим включением существенно его ограничат.

Например, если у вас сейчас контроллеры FAS2240, а через год вы собираетесь перейти на мидрендж, и, допустим, покупаете четыре FAS8040, намереваясь все их включить в общий кластер, чтобы мигрировать между всеми ними ваши стораджевые задачи, то следует понимать, что вы не сможете включить все их в состав одного кластера, как бы заманчиво это ни выглядело.

Хотя определенный смысл от перехода на Clustered Data ONTAP есть и в этом случае, например облегчается миграция, даже однократная и односторонняя, со старых контроллеров на новые.

Таким образом вот ваши лимиты, по контроллерам разных моделей:

FAS3140 - 2 узла.
Такая же ситуация у FAS2520 - 2 узла максимум.
Это, фактически, ровно HA-пара и все. К этой паре больше никого не подлючить. Но эта пара будет, тем не менее, кластером.
Далее.

FAS2220, FAS2240, FAS3160, FAS3170, FAS3210, FAS3240, - 4 ноды максимум.

FAS2550, FAS3220, FAS3250, FAS3270, FAS6040, FAS6210 - 8 нод - максимум, и под NAS, и под SAN.

Наконец, топовые системы:
FAS6080, FAS6220, FAS6240, FAS6250, FAS6290, FAS8020, FAS8040, FAS8060, FAS8080EX - 24 ноды под NAS и 8 нод под SAN.

Это для нас значит, что мы не можем в нашей гипотетической конфигурации включить в уже собранный кластер из пары FAS2240 еще четыре FAS8040, потому что лимит для кластера с участием FAS2240 равен 4 нодам. Но еще пару FAS8040 - можем, безусловно.

Какой же у нас есть путь “в кластер”, для уже существующей системы?

Наиболее простой вариант - пересборка вашей пары контроллеров, работающей в 7-mode в HA-пару так называемого 2-node switchless cluster. При этом вам не требуется строить Cluster Network с использованием выделенного 10G Ethernet коммутатора, но вы можете его добавить позднее, если вам потребуется перейти на кластер, превышающий 2 узла, это не потребует больших затрат сил, а при использовании отказоустойчивой пары соединений 10G для межнодового кластерного интерконнекта, то и вовсе может быть выполнена без прерывания нормальной работы. Просто одно соединение, идущее из одного контроллера в другой напрямую, разрывается, переключается в подготовленный коммутатор, затем, после того, как ноды увидели друг друга через коммутатор, можно разорвать и перенести в коммутатор и вторую пару соединений Cluster Interconnect.

Конечно, как и всегда, для любой кластерной системы, вам обязательно нужно иметь выделенные порты 10G под Cluster Network, и для стандартной отказоустойчивой схемы с избыточностью их нужно по два порта на контроллер.
Да, для FAS2240 вы, в результате, вынуждены отдать оба имеющихся порта 10G под кластерную сеть. Ну и, конечно, в любых других контроллерах, вам тоже надо будет иметь по паре 10G портов только под эту выделенную сеть.

Как вы видите, в двухнодовый кластер вы можете (при наличии в нем пары 10G-портов) перевести почти любой из “ныне живущих” (в данном случае это понимается как “поддерживаемый”) контроллеров. Нужно ли - отвечать вам.

К сожалению, пока по-прежнему нет решения, которое бы перенесло данные из системы 7-mode в систему Clustered Data ONTAP, в data-in-place, то есть в столь привычном разбалованным юзерам NetApp варианте апгрейда, когда “перетыкаешь кабеля, и поехало”. Напомню, сегодня по-прежнему для перехода на Cluster надо полностью разобрать имеющуюся систему и переинициализировать диски, с потерей data-in-place, то есть либо через “бэкап и рестор”, либо через миграцию.

?? вот как мы будем из этой ситуации выкручиваться, вот про это будет пост “Часть 3″.

Так как российские законодатели, в неизбывной мудрости своей, никак не хотят оставить в покое сдвиг временных зон в России, рекомендую освежить в памяти текст поста, опубликованного по поводу предыдущего каталипсиса, в 2011 году: Обновление timezone на системах хранения NetApp. Помните, что совпадение временных зон и времени на системе хранения и серверах/клиентах сети, например при работе ее в домене Active Directory, абсолютно необходимо, его несовпадение чревато прекращением доступа к данным из-за рассинхронизации тикетов системы безопасности Kerberos, используемой в AD.

Несколькими месяцами ранее я уже проводил опрос, на тему перспектив перехода пользователей на Clustered Data ONTAP на их стораджах. Опрос это обозначил несколько основных групп пользователей по отношению к Clustered Data ONTAP.

Если с примерно третью, теми, кто ответил, что они уже перешли, или переходят до конца этого года (ну или в обозримое время, главное, что решение уже принято), все понятно, я могу их только поздравить с их решением, то вот с оставшимися двумя третями все сложнее. Конечно, я трезво понимаю, что среди оставшхся некоторое (значительное) количество составляют владельцы младших и старых систем, для которых переход на Clustered Data ONTAP закрыт по техническим причинам (например – старости, слабости и непригодности контроллеров предшествующих поколений стораджей). Но наверняка среди них также есть и люди, которые, возможно, могли бы перейти на Clustered Data ONTAP, но либо не понимают как и когда это проделать, либо недостаточно осведомлены о том, от каких плюшек они, в результате, отказываются. Мне бы хотелось, в серии постов, котрые я запланировал и написал для ближайших нескольких недель, детально разобрать эти новые и полезные возможности Clustered Data ONTAP.

Continue reading ‘Переход на Clustered Data ONTAP. Часть 1’ »

В связи с тем, что, постепенно, Cluster-mode Data ONTAP, или как ее теперь правильно называть Clustered Data ONTAP, входит в жизнь, и все больше пользователей задумываются о ее использовании, возникает вопрос, как бы наиболее щадящим и простым способом перенести между двумя этими системами данные.
К сожалению, разница “в потрохах” между этими двумя OS, несмотря на схожесть названий, слишком велика, чтобы просто “запустить скрипт, и все сделается за час”. К сожалению пока нет реально работающего способа преобразовать уже имеющуюся 7-mode систему в C-mode. Поэтому, обычно, о Clustered ONTAP начинают думать в случае появления новой, “чистой” системы хранения, тем более, что сегодня есть возможность сделать Clustered Data ONTAP из всего пары контроллеров. Это интересно тем, что впоследствии вы уже сможете довольно свободно добавлять к этой паре контроллеров новые пары. Например старые (если они поддерживаются) контроллеры, работавшие в 7-mode, после завершения миграции данных с них, могут быть легко добавлены в такой кластер.

Довольно быстро в голову приходит идея использовать SnapMirror, штатную репликацию данных NetApp. Но поддерживает ли она репликацию между двумя “модами”? Да, поддерживает, хотя и с ограничениями. Наиболее существенным является невозможность перенести LUN-ы FCP или iSCSI. Увы, изменения в работе с метаданными LUN-ов в C-mode слишком значительны, чтобы это можно было просто реплицировать. В случае LUN-ов вы получите при попытке репликации сообщение в логах:

wafl.voltrans.lun.exists: Volume vmware_datastore1@vserver:a0cc5791-fd70-11e2-9f1f-123478563412 contains 7-Mode LUNs. It cannot be transitioned to Cluster-Mode.


В случае LUN-ов вам придется воспользоваться ручным переносом данных, либо через хост, либо через какой-то софт создания образа диска, хотя бы Norton Ghost или Acronis True Image.

Для разделов с файловыми данными, однако, можно все сделать собственными средствами SnapMirror.

Допустим, у нас есть две физических системы: 7-mode по имени NETAPP_7MODE (192.168.2.10) и Netapp Clustered ONTAP system по имени NETAPP_CMODE (192.168.1.10).

Создадим SnapMirror peer:
NETAPP_CMODE::> vserver peer transition create -local-vserver NETAPP_CMODE -src-filers-name NETAPP_7MODE

Transition peering created

Создадим том-получатель реплики данных:
NETAPP_CMODE::> volume create -volume vmware_datastore1 -aggregate aggr1 -size 100GB -type DP

[Job 16] Job succeeded: Successful

Создадим межкластерный интерфейс LIF:
NETAPP_CMODE::> network interface create -vserver NETAPP_CMODE -lif intcl_lif1 -role intercluster -home-node NETAPP_CMODE -home-port a0a-10 -address 192.168.1.10 -netmask 255.255.255.0

NETAPP_CMODE::> network routing-groups route create -vserver NETAPP_CMODE -routing-group i192.168.1.0/24 -destination 0.0.0.0/0 -gateway 192.168.1.1


Проверим, что связь есть:
NETAPP_CMODE::> network ping -lif intcl_lif1 -lif-owner NETAPP_CMODE -destination 192.168.2.10

192.168.2.10 is alive

Устанавливаем отношения репликации SnapMirror:
NETAPP_CMODE::> snapmirror create -source-path NETAPP_7MODE:vmware_datastore1 -destination-path NETAPP_CMODE:vmware_datastore1 -type TDP

Operation succeeded: snapmirror create the relationship with destination NETAPP_CMODE:vmware_datastore1

Проводим инициализацию репликации:
NETAPP_CMODE::> snapmirror initialize -destination-path NETAPP_CMODE:vmware_datastore1

Operation is queued: snapmirror initialize of destination NETAPP_CMODE:vmware_datastore1

Ждем завершения начальной полной передачи данных, проверяя статус:
NETAPP_CMODE::> snapmirror show

При необходимости обновляем данные на получателе, если они изменились на источнике:
NETAPP_CMODE::> snapmirror update -destination-path NETAPP_CMODE:vmware_datastore1

Отрезаем реплику от источника (quiesce):
NETAPP_CMODE::> snapmirror quiesce -destination-path NETAPP_CMODE:vmware_datastore1

При необходимость снова восстановить репликацию после отреза (quiesce):
NETAPP_CMODE::> snapmirror resume -destination-path NETAPP_CMODE:vmware_datastore1

Отрываем реплику (break):
NETAPP_CMODE::> snapmirror break -destination-path NETAPP_CMODE:vmware_datastore1

При необходимости повторять репликацию назначаем расписание:
NETAPP_CMODE::> job schedule cron create -name Every15mins -minute 15

NETAPP_CMODE::> snapmirror modify -destination-path NETAPP_CMODE:vmware_datastore1 -schedule Every15mins

После завершения репликации у вас на новой системе окажется копия данных системы с 7-mode, и их можно начинать использовать.

ВАЖНО: После репликации для тома-получателя будет автоматически выставлена опция fs_fixed_size, вы не сможете ее изменить командой vol options fs_fixed_size off, вместо этого воспользуйтесь командой: vol modify -vserver -volume -filesys-size-fixed false