about NetApp

В статье ранее я показал, как, в принципе, просто меняется контроллер на системе хранения NetApp, причем остаются на дисках доступными, без процедур миграции, все пользовательские данные, а сама процедура замены, и сопряженный с ней даунтайм, при хорошей подготовке и сноровке, можно завершить в течение буквально 20 минут. Однако в процедуре есть одна тонкость.

Если у вас на сторадже используются SAN LUN-ы, то при замене “головы”, а если более точно, то при замене NVRAM (при замене контроллера обычно с ним также меняется и NVRAM (NVMEM), установленная внутри) у этих LUN изменится их SerialID. В ряде случаев это может озадачить использующие их хосты (например Windows Cluster изменяет при этом их signatures, и не может после поднять в онлайн). Поэтому было бы правильно, после замены контроллера, и до возвращения LUN-ов использующим их системам, вернуть им старые SerialID.

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

На сайте communities.netapp.com было найдено несколько вариантов такого скрипта. На Perl, на VBS, и в виде скрипта PowerShell.

Если вы, как и я ранее, мучаетесь от совершенно запредельно ннизкой скорости работы NetApp System Manager 2.x, основного ныне инструмента администрирования NetApp, то радикально ускорить его поможет вам способ, порекомендованный в нашем форуме (если вы еще не там – настоятельно приглашаю, ссылка в шапке блога):

По видимому причина тормозов – в крайне кривом разрешении хостнейма в IP в Java при работе через DNS, поэтому добавьте соответствие имен контроллеров и их IP в локальный файл hosts. Таким доисторическим приемом вы, на глаз, в десятки раз увеличите скорость работы, открытия панелей и их обновления.

??ногда бывает нужно создать пользователя, не имеющего на системе хранения других прав, кроме read-only, например для задач демонстрации и обучения, только для получения каких-то данных или снятия показаний, или же иных подобных применений. Сделать такого пользователя можно с помощью механизма RBAC – Role-Based Access Control (кстати по RBAC в техбиблиотеке Netwell лежит дельная переведенная документация).

Пример  создания роли read-only user при помощи DataONTAP Powershell Toolkit.


#Create read-only role:
New-NaRole ro_role -Capabilities  login-*
#Add read-only capabilities to this from attached file:
$caps = Get-Content .\RoRoles.txt
ForEach ($cap in $caps)
{
  Set-NaRole ro_role -AddCapabilities  $cap
}
#Create read-only group:
New-NaGroup ro_group ro_role
#Create read-only user:
New-NaUser ro_user rouserpassword ro_group


Файл RoRoles.txt со списком вызовов API DataONTAP можно скачать тут.

Любопытную залипуху недавно пришлось разрешить. При объединении на одной системе хранения дисков, аггрегейтов и томов с нескольких других, на системе оказалось несколько томов с одинаковыми именами (ну да, на каждой был свой ???vol0’, к примеру).

Для устранения этой проблемы Data ONTAP автоматически изменяет имена таких дублирующихся ресурсов, добавляя цифру в скобках. Однако проблема (по крайней мере в 7.x) в том, что такие авто-переименованные ресурсы нельзя переименовать вручную. Но можно переименовать исходный, который вызвал автопереименование последующих. Результат будет такой:

fas1> vol status
  Vol_data    online          raid_dp, flex     create_ucode=on
  Vol_data(1) online          raid_dp, flex     create_ucode=on
  Vol_data(2) online          raid_dp, flex     create_ucode=on
 
fas1> vol rename vol_data vol_data_orig
fas1> vol status
  Vol_data_orig  online    raid_dp, flex     create_ucode=on
  Vol_data  online          raid_dp, flex     create_ucode=on
  Vol_data(1) online          raid_dp, flex     create_ucode=on

Как вы видите, можно выкрутиться из этой ситуации переименовывая тома вручную по одному.

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

Помощь, как всегда, была найдена в TFM  ;) – NetApp Storage Management Guide.

How you manage duplicate volume names

Как вы, возможно, слышали, загрузить систему хранения NetApp можно по сети, сравнительно традиционным для UNIX-систем способом загрузки OS (ядра и rootfs) через TFTP. Это может помочь, например, если из за неисправности имеющегося ядра, которое располагается в системах NetApp на внутренней CF-карточке.

Для того, чтобы загрузиться с TFTP необходимо при загрузке прервать обычное выполнение процедуры загрузки нажав при включении системы Ctrl-C (или в случае повреждения собственного загрузочного ядра OS система окажется там сама), оставшись в “биосе”. В качестве “биоса” в системах хранения NetApp используется специальный загрузчик, под названием LOADER (в более ранних системах, например FAS270 или FAS3020/3050 использовался немного другой метод – CFE – Common Firmware Environment).

Как для LOADER, так и для CFE для загрузки системы хранения с помошью netboot вам нужно скачать с сайта NetApp netboot-версию OS Data ONTAP нужной вам версии и типа платформы (для современных систем это всегда версия с индексом платформы Q, для FAS3020/3050 индекс платформы будет E, для старых, MIPS-based систем, например FAS270 – M).

Netboot-версия Data ONTAP 7.3.5.1 (наиболее свежей 7.х на момент написания этого поста) имеет размер 27,4MB (7351_netboot.q), версия Data ONTAP 8.0.1 – 144,6MB (801_netboot_q.tgz) и представляют собой kernel и rootfs завернутые в tar.gz, загружающиеся традиционным образом в память.

Далее вам следует установить и настроить в сети, доступной системе хранения, сервер TFTP, и положить туда скачанный образ.

В подсказке LOADER необходимо настроить сетевой интерфейс и запустить сетевую загрузку.

LOADER> ifconfig e0a -addr=192.168.1.10 -mask=255.255.255.0 -gw=192.168.1.1
e0a: Link speed: 1000BaseT FDX
Device e0a:  hwaddr 00-A0-98-03-48-AB, ipaddr 192.168.1.10, mask 255.255.255.0
        gateway 192.168.1.1, nameserver not set

Доступные опции для команды ifconfig можно посмотреть введя в подсказке LOADER команду help ifconfig

Проверяем работу сети пингуя default gateway:

LOADER> ping 192.168.1.1
192.168.1.1 (192.168.1.1) is alive
192.168.1.1 (192.168.1.1): 1 packets sent, 1 received

Запускаем команду netboot

LOADER> netboot tftp://192.168.1.11/tftproot/netapp_7.2.3_x86_64
Loading:. . . . . . . . . . .

Далее Data ONTAP загружается обычным образом. Если /etc , хранящийся на root volume, при этом доступен, то система запустится штатным образом, восстановив все рабочие настройки, если же система повреждена значительно, и, например /etc также  недоступен, то можно попробовать загрузиться без /etc (выбрав соответствующую опцию в boot menu) инициализировать диски, создать новый aggregate, и запустить установку OS “начисто”.

Обратите внимание, что для netboot доступны только встроенные ethernet-порты, не те, что возможно у вас на системе установлены на карте расширения, которая в момент начальной загрузки еще недоступна.

Large Sequental Read, или чтение последовательными большими блоками, это один из распространенных паттернов доступа к данным. Например, с таким характером доступа работают такие задачи, как Decision Suport System (DSS), системы Business Intelligence (BI), а также многие задачи резервного копирования (full backup, например).

Вследствие характера работы WAFL, такой паттерн доступа может быть проблемным для систем хранения NetApp, поэтому, если ваши задачи часто используют Large Sequental Read, то стоит позаботиться о некоторых методах оптимизации. Я уже писал, что ситуацию с производительностью на последовательном чтении улучшает регулярное выполнение операций реаллокации (они выполняются по расписанию, или при превышении порогового уровня non-contiguous blocks placement, не обязательно гонять его вручную). Также в блоге специалиста NetApp по нагрузочному тестированию и производительности, Wei Liu, я приметил еще одну оптимизационную фишечку.

В системах Data ONTAP версии 7.3.2 и новее имеется опция wafl_max_write_alloc_blocks, по умолчанию она установлена в 64. Если у вас работа с данными осуществляется преимущественно большими блоками, имеет смысл увеличить его значение до 256. Этот параметр, наскольно я могу судить из его названия, управляет размером экстента записи данных. О влиянии и смысле этого элемента дисковой структуры я недавно писал в посте про “фрагмнтацию”. Для версий до 7.3.2 этот параметр нужно было установить в файле /etc/rc в виде строки:
setflag wafl_max_write_alloc_blocks 256

Эта опция оптимизирует работу WAFL при работе большими последовательными блоками. Я могу ошибаться, но, исходя из моего понимания процессов за которые она отвечает, сказываться она будет не просто при включении, а при включении и последующей записи на том, или после реаллокации блоков на томе (вы помните, надеюсь, что WAFL не перезаписывает однажды занятые блоки, поэтому структура для уже записанных данных, на момент включения опции, никак не изменится). Поэтому, возможно, заметить эффект от ее использования получится не сразу же.

Опция была подсмотрена в документе: TR-3760: Building a Scalable Data Warehouse Solution, кстати любопытного и самого по себе чтива.

Отдельно обращу ваше внимание, что не стоит сразу бросаться “тюнить” систему, так как данная опция, вероятнее всего, положительно влияет только на производительность large sequental read, и может не сказаться, или сказаться отрицательно на всех других. Но если у вас DSS-like база, то, может быть, можно и попробовать.

Системы хранения NetApp позволяют ограничить доступ к админской консоли, задав IP-адрес админского хоста либо при установке, либо в параметре admin.hosts

Однако, иногда хотелось бы задать не один конкретный адрес, а подсеть, или несколько адресов.

В этом случае возможен следующий простой трюк. Можно указать в качестве админхоста gateway соответствующей подсети, например в которой находятся рабочие места админов. В этом случае доступ будет ограничен только хостами указанной подсети:

fas1> options admin.hosts 192.168.1.254

Другой вариант – указать их в таком виде:

fas1> options admin.hosts host1.domain.com:host2.domain.com:host3.domain.com

Не забывайте, что это ограничение предельно примитивное, и строить защиту админского доступа только на нем не стоит, так как определяет возможность доступа к логину консоли исключительно по легко изменяемому IP источника. Если стоит задача серьезного разграничения доступа, то стоит использовать как “секурный” доступ по SSH и HTTPS (команда secureadmin), pre-shared key, и средства RBAC (Role-based Access Control), о которых я писал ранее и есть переведенный на русский документ в техбиблиотеке.

??ногда бывает важно сделать так, чтобы трафик определенных протоколов вообще не ходил по определенным портам. Например, у нас есть система хранения, лицензированы протоколы iSCSI, CIFS и настроена репликация SnapMirror. Каждый из этих протоколов работает в своей физической сети. По CIFS ходят юзеры за файлами, по iSCSI прицеплены сервера, а SnapMirror льет свои данные по третьей сети, выделенной только под трафик репликации.

?? мы хотели бы гарантировать, что каждый трафик будет существовать только в своей сети. До ONTAP 7.3 минимальные средства такого управления были только для iSCSI. Можно было разрешить или запретить iSCSI на конкретном порту, и только. Но начиная с 7.3 появилась новая возможность.

fas> options interface.cifs.blocked e0b
fas> options interface.iscsi.blocked e1a,e1b,e1c,e1d
fas> options interface.nfs.blocked e0a,e0c
fas> options interface.snapmirror.blocked e0d

??з приведенных примеров, как мне кажется, все понятно. Обратите внимание, что настройки на обоих контроллерах кластера должны быть строго идентичны! Также имейте ввиду, что данные настройки не работают для iSCSI HBA и TOE-карт, то есть это только для обычных NIC, как onboard, так и карт расширения.

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

Для начала, вам следует найти консольный кабель. Он идет в комплекте поставки но, в случае, когда концы системы утеряны, бывает с ними же уходит и кабель.

В качестве консольного кабеля прекрасно подойдет аналогичный консольный кабель RJ-45-to-DB-9 от оборудования Cisco. Его распиновка такова:

Pinouts RJ45
Pin# Signal
1    connected to pin 8
2    Not connected
3    TXD (from appliance)
4    GND
5    GND
6    RXD (to appliance)
7    Not connected
8    connected to pin 1 

Для справки также привожу распиновку стандартного RS-232 serial DB-9

Pinouts DB9
Pin# Signal Data Flow Description
1    DCD    input     data carrier detected
2    SIN    input     serial input
3   SOUT    output    serial output
4    DTR    output    data terminal ready
5    GND    N/A       signal ground
6    DSR    input     data set ready
7    RTS    output    request to send
8    CTS    input     clear to send
9     RI    input     ring indicator 

Для сброса системы в “состояние с завода” следует выполнить в консоли загруженной системы, войдя от имени root, следующие команды:

>priv set advanced

>halt -c factory

После перезагрузки все ранее сделанные изменения конфигурации в /etc сотрутся, и будет запущен стартовый скрипт setup, обеспечивающий начальную установку впервые включенной системы.

Если необходимо сменить неизвестный или утерянный пароль root, следует, с подключенным к serial port кабелем и консолью, включить контроллер, и, при загрузке, на предложенную подсказку, нажать Ctrl-C и выбрать (3) Change password.

Обратите внимание, что сбросить пароль root возможно только с консольным подключением в контроллер.

Довольно часто админам, особенно тем, у кого в подчинении находятся несколько систем NetApp, приходится решать задачу переноса информации между системами хранения.
Например на файлереА у нас терабайт домашних папок, которые понадобилось перенести на новый файлерБ, чтобы освободить место на файлереА.
??ли перенести данные с одного ресурса на другой внутри той же системы.

Казалось бы, чего проще: монтируем обе шары на какой-нибудь сервер, запускаем на нем копирование и оставляем на ночь.

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

На помощь приходит команда ndmpcopy.
NDMP, как протокол передачи данных, тема интересная сама по себе, и когда-нибудь я до нее обязательно доберусь и распишу отдельно, но пока воспользуемся им для утилитарной цели.
Для того, чтобы запустить копирование данных средствами контроллеров NetApp, включите демон ndmp, если он у вас еще не запущен

ndmpd on

и выполните в консоли команду:

ndmpcopy -sa root:password -da root:password filer01:/vol/vol1/share1/tree1/ filer02:/vol/vol2/share2/tree2

где -sa root:password, соответственно, имя и пароль рута на source filer01, -da - на destination filer0, а далее указаны пути копирования для источника и получателя.

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

Можно копировать как внутри одной системы:

myhost> ndmpcopy -sa username:password -da username:password myhost:/vol/vol0/source_path myhost:/vol/vol0/destination_path

или короче:

myhost> ndmpcopy /vol/vol0/source_path /vol/vol0/destination_path

так и с одной системы на другую:

myhost> ndmpcopy -da username:password /vol/vol0/source_path remotehost1:/vol/vol0/destination_path

и даже с одной удаленной на другую, отдавая команды на некоей третьей, которая при этом в копировании не участвует:

myhost> ndmpcopy -sa username:password -da username:password remotehost1:/vol/vol0/source_path remotehost2:/vol/vol0/destination_path

PS. ACLs конечно же при этом также переносятся корректно.