about NetApp

Иногда бывает важно сделать так, чтобы трафик определенных протоколов вообще не ходил по определенным портам. Например, у нас есть система хранения, лицензированы протоколы 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 конечно же при этом также переносятся корректно.

Начиная с версии Data ONTAP 6.4 можно посмотреть текущие логи системы и забрать core dump, при его существовании, через веб-браузер по адресу:

http://your-fas-system/na_admin/logs
и
http://your-fas-system/na_admin/cores

Начиная с версии 7.2 эта опция по умолчанию выключена, вернее выключено формирование индексной страницы, так что если вы хотите попробовать, то сперва скажите в консоли:

fas> options httpd.autoindex.enable on

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