about NetApp

Продолжаем начатый в прошлых выпусках список полезностей из команд консоли NetApp.

• /etc/exports : файл, управляющий экспортами NFS
• rdfile /etc/exports : прочитать файл экспортов NFS
• wrfile /etc/exports : записать в файл экспортов NFS
• exportfs -a : экспортировать все файловые системы, перечисленные /etc/exports
• cifs setup : устанавливает и настраивает cifs для использования
• cifs shares : создает/показывает шары cifs
• cifs access : изменяет параметры доступа к шарам cifs
• lun create : создает LUN для iscsi или fcp
• lun map : маппит LUN для igroup
• lun show : показывает все LUN системы хранения
• igroup create : создает igroup на контроллере
• lun stats : показывает статистику ввода-вывода для LUN
• disk show : отображает все диски системы
• disk zero spares : затирает содержимое дисков, отмеченных как spare
• disk_fw_update : обновляет firmware всех дисков системы
• options : показывает/устанавливает различные опции системы хранения
• options nfs : показывает/устанавливает опции NFS
• options timed : показывает/устанавливает опции NTP
• options autosupport : показывает/устанавливает опции autosupport
• options cifs : показывает/устанавливает опции CIFS
• options tcp : показывает/устанавливает опции TCP
• options net : показывает/устанавливает опции сети

продолжение следует.

Продолжим составление списка полезных команд управления в консоли NetApp.

• license : отображает/добавляет/удаляет лицензии на системе хранения
• maxfiles : показывает и добавляет inodes на томе
• aggr create : создает aggregate
• vol create <volname> <aggrname> <size> : создает том на aggregate
• vol offline <volname> : переводит том в offline
• vol online <volname> : переводит том в online
• vol destroy <volname> : уничтожает и удаляет том
• vol size <volname> [+|-]<size> : изменяет размер тома
• vol options : отображает/изменяет опции тома
• qtree create <qtree-path> : создает qtree
• qtree status : отображает статус qtrees
• quota on : включает механизм квоты на системе хранения
• quota off : выключает квоты
• quota resize : изменяет значения квот
• quota report : сообщает значения квот и использованного места
• snap list : показывает список всех снэпшотов на томе
• snap create <volname> <snapname> : создает снэпшот вручную
• snap sched <volname> <schedule> : назначает расписание создания снэпшотов
• snap reserve <volname> <percentage> : показывает/устанавливает резервирование места под снэпшоты

продолжение следует

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

• sysconfig -a : показывает развернутую информацию по аппаратной конфигурации
• sysconfig -d : показывает информацию о дисках, подключенных к контроллеру
• version : показывает версию Data ONTAP OS version.
• uptime : показывает время uptime
• dns info : выводит данные по dns, такие как число попаданий в кэш dns и промахов
• nis info : выводит название домена nis, серверов yp, и т.д.
• rdfile : похоже на "cat" в Linux, используется для отображения содержимого текстового файла
• wrfile : создает/перезаписывает файл. Похоже на "cat > filename" в Linux
• aggr status : показывает статус aggregate
• aggr status -r : показывает конфигурацию RAID, информацию о ходе ребилда
• aggr show_space : показывает использование пространства на aggreate, WAFL reserve, overheads и т.д.
• vol status : выводит информацию о томе
• vol status -s : показывает spare disks системы
• vol status -f : показывает сбойные (failed) диски системы
• vol status -r : показывает конфигурацию RAID, информацию о ходе ребилда
• df -h : отображает использование пространства на томе
• df -i : отображает количество inode на всех томах
• df -Ah : отображает данные "df" применительно к aggregate

продолжение следует

Многие пользователи NetApp, в особенности их младших моделей (Low Enterprise Class, FAS2020 и FAS2050) часто жалуются на большие потери при создании usable space. Зачастую usable space может составлять всего 50% от raw, а иногда бывает и того менее.
Действительно, на системах с малым числом дисков, а зачастую именно такие попадают в сравнительно небольшие компании и проекты, величина пространства, которая отнимается по умолчанию из дискового пространства такой системы довольно велика. Чем больше в системе дисков, тем меньшую роль это играет, однако на небольших системах этот эффект довольно значителен.

Что с этим делать, и насколько это серьезная проблема?

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

Однако такой том нужен для каждого из двух контроллеров, и, в случае использования RAID-4 мы потратим на их создание как минимум 2 диска на parity disks для их RAID-групп (и 4 в случае RAID-DP), плюс еще диски на parity для RAID-групп данных. Плюс hot spare. Вот и убегает, при создании системы с настройками “по умолчанию”, половина всех доступных дисков. Хотя, говоря начистоту, при использовании RAID-10 в “других система хранения” мы тоже получаем 50% usable от raw, но в данном случае все равно как-то жаба грызет.

??так, каким хитрым способом можно получить максимально возможное количество usable space на системе типа FAS2020A, с, допустим, дисками SATA 1TB 7200RPM?

С самого начала скажу, что нижеописанная схема никакой не Best Practices (а скорее даже Bad Practices), но тем не менее позволят получить максимум usable space на небольших системах, типа FAS2020. Если вас угораздило купить такую, да еще с небольшим количеством больших дисков SATA в базе, невзирая на все, что вам говорили при этом при продаже - читайте дальше.

Можно создать aggr0 из всего пары дисков в RAID-4 (1 диск данных и 1 диск parity), и разместить на нем vol0 для первого контроллера. На этом vol0 находится служебная информация, необходимая для загрузки и работы контроллера, директория /etc, поэтому создавать его придется на “полностью чистой” системе из меню Maintenace mode. Служебная директория займет примерно мегабайт 30. Остальное место, почти терабайт, мы можем использовать для хранения каких-нибудь наших данных. По умолчанию на vol0 создается директория home, в которой можно разместить homedir подключенных к NAS пользователей. Однако следует помнить, что быстродействие тома, построеного на RAID из всего двух дисков будет невелико. Так что лучше если это будут какие-нибудь не критичные к быстродействию данные

Оставшиеся 10 дисков мы распределяем таким образом: 1 диск оставляем в hot spare*, а все оставшиеся 9 помещаем в один большой aggregate, в одну RAID-группу типа RAID-4 или RAID-DP (1 или 2 pariy, 8 или 7 дисков данных). ?? на этой большой группе создаем vol0 для второго контроллера.
А все оставшееся место, за вычетом 30Mb на содержимое /etc, мы можем занять нашими данными, причем они будут распределены уже по “длинному” и, следовательно, более быстродействующему RAID.

Disk layout

Отмечу, что, если не ошибаюсь, начиная с ONTAP 7.3, для системы хранения NetApp назначается 2 диска hot spare на каждый контроллер, что для малых систем, на мой взгляд, чересчур расточительно. Это значение можно изменить в системных опциях*.

Преимущества:

1. Мы получаем величину usable space равную 75% от raw (из 12 дисков выпадают 3: 1 на parity на первом контроллере, 1 на parity на втором контроллере, 1 на общий spare)
2. Мы получаем большой раздел “одним куском”, и можем, например, создать на нем LUN размером 8TB (больше все равно не поддерживается на 2020)
3. Этот большой раздел получается относительно быстродейстующий, так как распределен на максимально возможное в данном случае количество дисков.

Недостатки:

1. Мы, по сути, делаем резко асимметричную систему, в которой контроллер 1 практически не занят, и вся рабочая нагрузка по обслуживанию доступа к данным ложится на второй.
2. RAID-4 менее отазоустойчив, чем RAID-DP, в особености на SATA, и обеспечивает более долгое время ребилда в случае сбоя.
3. 1 spare на 2 контроллера это “не рекомендованная” NetApp конфигурация.
4. Такая схема разбиения “не рекомендуется” NetApp для использования.

Так что на свой страх и риск.

* Необходимо изменить системный параметр:
set options raid.min_spare_count 1

Порой процесс взаимодействия меня, как автора, с читателями бывает довольно необычен.
Тем 44 посетителям, что зашли в течении прошедшего месяца с поисковиков по запросу:
netapp simulator how to add disk

Вот так:)

В корне папки симулятора лежит скрипт makedisks. Кроме добавления дисков, как видите, он еще может изменить кучу настроек, которые обычно ставятся в момент инсталляции симулятора.

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

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

filer01> config
Usage:
config clone
config diff [-o ] [ ]
config dump [-f] [-v]
config restore [-v]

Команда простая и понятная. Сперва вы сохраняете (dump) конфигурацию с системы хранения. Это проделывается с содержимым /etc/configs. Далее вы можете клонировать (clone) эту конфигурацию на другую систему, или сравнить ее (diff) с ранее сделанным дампом конфига. Запуск diff это отличный способ сравнить два конфига между двумя моментами времени, если вы не уверены или не помните что вы изменяли. ??, наконец, вы можете воспользоваться средствами восстановления (restore), однако не забудьте, что это потребует перезапуска системы хранения.

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

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

Новая полезная команда для администратора CIFS NAS появилась в версии 7.3 (и новее). Любому win-админу известно, какая катавасия начинается с доступом, когда становится много пользователей и групп безопасности. Юзеру “Петя” позволено то, но не позволено это, но когда он входит в группу “Менеджеры”, то ему позволяется еще вот это и это, но зато запрещается вон то, что раньше было разрешено индивидуальному пользователю (как известно, в системе безопасности NT DENY всегда перекрывает ALLOW). ?? такое спагетти из прав работает до тех пор, пока однажды не запутается намертво, заставляя админа лезть на стену. ?? вот тут пригодится инструмент, который покажет что не так, не просто access denied, а почему, и отчего.

Например
sectrace add -a -path /vol/software

выведет в лог что-то наподобие:

Sun Feb 1 13:10:52 IST [jim: sectrace.filter.allowed:info]: [sectrace index: 2] Access allowed because ‘Synchronize, Read Attributes’ permission (0×100080) is granted on file or directory (Access allowed by an explicit access control entry) - Status: 1:58720452:0:0 - 10.1.20.107 - NT user name: support\administrator - UNIX user name: root(0) - Qtree security style is NTFS and NT ACL is set on file/directory - Path: /vol/software/

Возможные опции: sectrace add, sectrace remove, sectrace show, sectrace print-status

Подсмотрено у http://filers.blogspot.com/

Многие админы, пользующиеся командной строкой консоли администрирования NetApp справедливо критикуют ее за отсутствие таких привычных в более продвинутых “шеллах” современных юникс-линуксов, как шорткаты и прочие удобные Ctrl-сочетания, экономящие время.
Однако кое-что любопытное в консоли все же есть:

1. CTRL-W: Удаляет “слово”, так что вам нужно меньшее число раз нажимать Backspace. Например, если у вас написано следующее:

snap delete myvol this_is_a_really_long_snapshot_name_to_use

то нажав CTRL-W, вы получите:

snap delete myvol

2. CTRL-A, CTRL-E, CTRL-F, CTRL-B: Переход, соответственно, к началу строки, концу (end) строки, вперед (forward) на символ, и назад (backward) на символ. CTRL-A и CTRL-E довольно полезны, а CTRL-F и CTRL-B просто дублируют курсорные стрелки.

3. CTRL-K: “Убивает” (Kill) весь следующий за курсором текст. Например мы передумали выполнять команду с уже введенными путями:

lun show -v /vol/exch_db1/exch_db1_g.lun

Нам надо нажать CTRL-A чтобы перейти к началу строки, CTRL-F (или курсорные стрелки) чтобы перейти на нужное место, на “-v”, и нажать CTRL-K. Строка станет:

lun show

Также можно воспользоваться первым описанным шорткатом, CTRL-W, дважды, удалив два “слова” (”словом” считается последовательность символов ограниченная пробелами или точкой).

4. CTRL-N, CTRL-P: Переход по истории введенных команд, соответсвенно Next и Previous. Удобно когда надо повторно вводить какие-то уже введенные ранее команды. Например выводим в онлайн три разных тома — myvol1, myvol2 and testvol3. Обычным образом вам надо набрать:

vol online myvol1

vol online myvol2

vol online testvol3

Более быстрый путь с использованием клавиатурных шорткатов. Набираете первую команду:

vol online myvol1

Когда она выполнена нажимаете CTRL-P и backspace для удаления ‘1′, и вводите номер ‘2′:

vol online myvol2

Нажимаете CTRL-P, и CTRL-W и набираете ‘testvol3′.:

vol online testvol3

Вот и все, вы сэкономили несколько секунд полезного времени своей жизни. :)

По умолчанию, TCP-окно Snapmirror равно 1,994,752 байт. В структурах, где SnapMirror используется для репликации данных через WAN, такое значение может заметно замедлять процесс репликации. Важно правильно вычислить верные настройки TCP-окна, и соответствующим образом их установить. Базовая формула такова:

Window Size = Round Trip Delay X Desired Rate

Таким образом, если у вас используется канал 10Mb/s и средний RTD равен 100ms, то window size должен быть 125,000 байт.

Несколько замечаний о этом TCP Window size:

Это теоретически минимальное возможное окно, используемое SnapMirror, и может не быть самым оптимальным. Попробуйте несколько вариантов в районе этой цифры, чтобы выбрать наилучшее.
Установить размер TCP window size можно в файле /etc/snapmirror.conf в параметре wsize.
Это надо установить и на системе-получателе репликации.

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

options snapmirror.delayed_acks.enable off

Эта установка выключает TCP/IP delayed acknowledgments. В сетях с высоким значением задержки, это может дать выгоду. По умолчанию она включена.

romx: Хочу также обратить внимание, что в речь идет именно о тонкой настройке и оптимизации определенных вариантов конфигурации, так как настройки SnapMirror по умолчаню выбраны для удовлетворительной работы в любых условиях. Если вы не уверены в том, что вы делаете, то лучше оставьте по умолчанию. Помните первое правило профессионала: “Работает - не трогай!” :)

Оригинал тут:
http://rajeev.name/blog/2008/03/18/optimizing-snapmirror-performance/
(будьте внимательны, на хостинге этой страницы сейчас сидит веб-червяк-троян!)