about NetApp

Бродя по бесконечным просторам внутренних пространств вебсайта NetApp обнаружил там в глухом уголке чрезвычайно полезную вещь, каковой и поделюсь.
Называется Data ONTAP Cookbook.

Представляет собой сравнительно краткий “сборник рецептов” (cookbook – кулинарная книга) для повседневной жизни админа, этакая “настольная книга домосистемохозяина”.
Как и обычная кулинарная книга это сборник пошаговых инструкций по выполнению тех или иных практических действий на системе хранения NetApp, например:

• Как создать том
• Настроить NFS export
• Сконфигурировать порт FC
• ??зменить размер LUN
• Создать и настроить VIF/ifgrp
• Настроить SnapMirror
• …и так далее, всего 70 страниц.

Скачать можно тут: http://www.divshare.com/download/12748580-cab

Несколько слов о такой теме, которая, как я заметил, часто вызывает замешательство и непонимание.

Для начала кратко о том, что такое aggregate и как они соотносятся с RAID-группами (например для тех, кто тут впервые, пришел из поисковика, и еще не разглядел, что тут порядка двух сотен постов, в которых о многом написано не по разу).

Aggregate это “уровень виртуализации” для физических дисков в системах хранения NetApp, это своеобразный виртуальный мета-том, на котором можно размещать уже непосредственно адресуемые пользователем тома, сетевые шары для NAS или LUN для SAN. ??спользование такого уровня виртуализации, например, позволяет равномерно распределять операции ввода-вывода по всем нижележащим дискам, увеличивая общую произвдительность, а также с легкостью увеличивать и уменьшать в объемах лежашие поверх него ресурсы – тем самые тома, LUN, сетевые шары, и так далее. Aggregate это одна из самых полезных и эффктивных “фич” систем хранения NetApp.

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

В физической иерархии aggregate находится на уровне, на котором в традиционных системах хранения находится volume. Ниже него лежат непосредственно физические диски, на которых организованы RAID-группы. Каждый aggregate может занимать одну или, обычно, несколько сконкатенированных RAID-групп, причем размер этих групп в количестве дисков может быть разным. NetApp рекомендует, если нет каких-то особых причин, создавать минимально возможное количество максимально “длинных” aggregate. Это повышает производительность ввода-вывода всех лежащих на них томов и LUN.

Для OS Data ONTAP семейства G7 (версий 7.х.x) максимальный размер aggregate был равен 16TB.
В версиях семейства G8 (8.x.x), для нового формата, под названием 64-bit aggregate, его размер варьируется в зависимости от мощности контроллера, и достигает 100TB для систем FAS6080, самых мощных на сегодня.

Подходить к созданию aggregate следует очень вдумчиво и аккуратно, так как то, что aggregate это фундамент в основе всех вышележащих структур, накладывает на его создание большую ответственность. Просчеты при создании aggregate будут влиять на все использующие его структуры выше. Кроме того, добавленные в aggregate диски нельзя из него извлечь не уничтожая весь aggregate вместе со всеми вышележащими структурами – LUN-ами, томами и сетевыми шарами, вместе со всем их содержимым.

Для того, чтобы создать aggregate, надо отдать команду в командной строке админской консоли, или запустить мастер в FilerView web-GUI. ?? там и там от нас потребуется задать величину RAID-групп.

Какой же должна быть величина этих RAID-групп в количестве дисков?
На сегодня, максимальный размер RAID-групп для дисков FC и SAS равен 28 дискам (то есть, например, для RAID-DP это 26 дисков данных и 2 диска parity), а для дисков SATA – 16 дисков (в версии 8.0.1 будет увеличена до 20).
Однако “рекомендованные величины”, выбранные “по умолчанию”, несколько меньше, это 16 и 14 дисков соответственно. (Все для типа RAID – RAID-DP).

“Если не знаете что делать – не делайте ничего” гласит по легенде главное правило в учебнике по пилотированию самолетов. Последуем ему и мы. Если вы не знаете, какие параметры при создании aggregate нужно выбрать, например размер RAID-групп – рекомендую вам оставить параметры по умолчанию.

Однако какие параметры стоит рассмотреть в том случае, если мы хотим разобраться и создать максимально оптимизированную структуру RAID?

Прежде всего, рекомендуется создавать RAID-группы, на которых лежит aggregate, по возможности равного размера. Причины этому понятны. Сильный дисбаланс в размерах может ограничить производительность aggregate производительностью самой маленькой RAID-группы.

То есть  между вариантами распределения 26 дисков в виде: 22 диска (RAID-DP 20+2) и 4 (RAID-DP 2+2) или же 13 и 13 (RAID-DP 11+2), следует предпочесть второе, несмотря на то, что в первом случае одна из групп будет значительно крупнее, второй вариант будет иметь в целом гораздо более стабильное быстродйствие в IOPS.

Создавать группы равного размера в принципе дело несложное в том случае, если количество дисков, которыми мы располагаем, заранее определено. Но что делать, если нам понадобится добавить дисков в aggregate, причем количество добавляемых дисков не 13, а заметно меньше, то есть создать из добавляемых дисков целую новую RAID-группу и растянуть на нее aggregate у нас не выйдет?

Допустим, у нас есть 6 дисков, на которые мы хотим увеличить наш aggregate, лежащий на двух группах RAID-DP по 13 дисков каждый.

У нас есть два варианта:

Вариант 1. Мы може просто, не особо думая, добавить эти диски командой aggr add <aggrname> 8a.1, 8a.2, 8a.3 (и прочие необходимые нам диски), или соответствующим GUI-мастером. Если ранее мы задали, что наш aggregate имеет размер RAID – 13 дисков, то вновь добавленные диски образуют третью RAID-группу rg2 (вдобавок к имещимся rg0 и rg1) размером 6 дисков (RAID-DP 4+2). Если в дальнейшем мы будем добавлять в этот aggregate еще дисков, то диски автоматически станут наращивать эту группу, пока она не достигнет размера 13 дисков, после чего начнется новая группа rg3.
Результат в целом простой, но не совсем для нас желательный. Для системы с высокими требованиями по производительности мы можем столкнуться с ситуацией, когда производительность ввода-вывода системы будет заметно колебаться в зависимости от того, какая порция данных на каком RAID окажется.
Хотя этот эффект часто не слшком ярко выражен, и часто переоценивается, но мы хотели бы его избежать.

Вариант 2. Несколько более хитрый. Как я уже сказал выше, мы не можем вывести уже введенные в aggregate диски. Также мы не можем уменьшить уже установленный в aggregate размер RAID-групп (ведь на дисках уже могут располагаться данные). Однако мы можем увеличивать размер RAID-группы в параметре входящих в нее дисков, вплоть до максимального размера, равного 28 для SAS/FC и 16/20 для SATA. Как вы уже знаете, особенностью использованного у NetApp типа RAID, как RAID-4, так и RAID-DP, является то, что добавление в них новых дисков и увличение RAID производится без необходимости полного перестроения RAID, как это привычно при использовании, например, RAID-5. Новый диск добавляется в RAID-4 или RAID-DP, и сразу же на него можно писать, расширив RAID-группу на размер этого диска.

Начнем с того, что зададим в свойствах aggregate размер его RAID-групп больше, чем было установлено ранее (13), в случае необходимости добавления 6 дисков зададим их величину в 16 дисков.

fas1> aggr options aggr1 raidsize 16

После выполнения этой команды мы получаем тот же aggregate, только теперь вместо двух заполненных RAID-групп на 13 (11d+2p) дисков, мы имеем две неполных RAID-группы по 13 дисков (11d+2p), с максимальным размером 16 (13d+2p). Слдующей командой мы добавляем 6 наших дисков в aggr1:

fas1> aggr add aggr1 8a.1, 8a.2, 8a.3, 8a.4, 8a.5, 8a.6

Логика добавления дисков неполные RAID-группы проста. Если в aggregate имеются неполные группы, то сперва системе следует заполнить эти группы до максимального зачения, начиная с самой младшей, затем переходя к следующей. Таким образом диски 1, 2, 3 добавятся RAID-группе rg0, а 4, 5, 6 – группе rg1. При необходимости можно и вручную задать какой диск в какую группу будет добавляться.

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

Системы хранения 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), о которых я писал ранее и есть переведенный на русский документ в техбиблиотеке.

В блоге Vaughan Stewart-а, “главного блоггера NetApp по VMware” найдена полезная информация. NetApp предлагает специальный скидочный код для покупки full conference pass for individuals для VMworld в San Francisco, а также VMworld в Copenhagen. С дисконтом NetApp цена снижается с $1745 до $1495 (USD) и с € 1150 до € 950 (Euro).

??спользовать код можно при регистрации на VMworld по следующему адресу:

http://www.vmworld.com/registration.jspa?sponsorCode=NAPP

Просто введите один из этих кодов при завершении покупки билета:

San Francisco code: NETAPP_EB_US2010
Copenhagen code: NETAPP_EB_EMEA2010

Дополнение: Как пишет Nick Howell, дисконт NetApp работает и “задним числом”, то есть, если вы уже приобрели билет за полную цену, вы можете получить вашу скидку, послав запрос по email: VMworld2010Registration@vmware-events.com.

При выходе из строя жесткого диска система начинает процесс RAID reconstruction. Время его завершения зависит от загрузки системы задачами ввода-вывода и установленного приоритета задачи реконструкции. Это приоритет (вернее степень влияния на производительность системы в целом задачей реконструкции) может быть настроен с помощью системной опции:

fas1> options raid.reconstruct.perf_impact [high | medium | low]

Обратите внимание, эта опция и ее изменение глобально (для всех RAID-групп системы в целом), и, что важно, не работает для уже запустившейся reconstruction. То есть увидеть слишком долгий процесс восстановления, поменять ее на high и ждать, что процесс ускорится, не стоит.

По умолчанию она установлена в medium, и менять ее стоит только если вы в самом деле хорошо представляете зачем вы это делаете.

В прошлый раз мы нашли и посмотрели команду filersio – внутренний генератор нагрузки ввода-вывода. Однако оказывается, такая штука, как stress test tool, внутри Data ONTAP есть не одна.

Еще один инструмент нагрузочного тестирования системы хранения – hammer

hammer это в чистом виде stress load generator, не делающий ничего, кроме нагрузки. Если вы хотите не просто “подвесить систему”, но еще и наблюдать за тем, что эта нагрузка дает вам в плане показателей, воспользуйтесь средствами sysstat или stats.

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

В недрах Data ONTAP кроме малоизвестных команд можно отрыть и какие-то совсем загадочные вещи. Занятие по отрыванию таких загадок никак нельзя рекомендовать как безопасное, но иногда находятся интересные штуки.

Вот, например, команда filersio (доступна в advanced mode)

filer1*> filersio
The following commands are available; For more information
filersio help
asyncio_pause asyncio_active spc1
status stop


Эта команда включает встроенный генератор ввода-вывода нагрузки на систему хранения.

filer1*> filersio asyncio_active 50 -r 50 4 0 10m 60 5 /vol/vol0/filersio.test -create -print_stats 5
filersio: workload initiated asynchronously. Results will be displayed on the
console after completion
filersio: starting workload asyncio_active, instance 0

Read I/Os       Avg. read       Max. read       Write I/Os      Avg. write      Max write
                latency(ms)     latency(ms)                     latency(ms)     latency(ms)
6087            0               11              6216            3               981
4410            0               471             4300            5               1551
5323            0               11              5375            4               1121
5439            0               113             5379            4               1151
4354            0               105             4304            5               1674
4307            0               411             4300            5               1171
5459            0               20              5371            5               1260
5384            0               180             5379            4               1071
5439            0               211             5375            4               1011
4396            0               71              4300            5               1311

Statistics for active_active model, instance 0
Running for 60s
Total read latency(ms) 16383
Read I/Os 51687
Avg. read IOPS 861
Avg. read latency(ms) 0
Max read latency(ms) 471
Total write latency(ms) 286501
Write I/Os 51413
Avg. write IOPS 856
Avg. write latency(ms) 5
Max write latency(ms) 4891
filersio: instance 0: workload completed successfully


Напомню еще раз, что все команды, доступные в advanced mode, могут быть небезопасны, не требуются для повседневного администрировани и конфигурирования, и использование их требует ясного понимания возможных результатов и рисков использования и настоятельно не рекомендуется на “боевых” системах с рабочими даными. ?? уж тем более это так для команд из “недокументированного” и “слабодокументирванного” списка.

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

Для того, чтобы настроить логи на передачу их на удаленную машину, надо изменить настройки в /etc/syslog.conf
Его синтаксис идентичен таковому в Linux/UNIX.

# Log all kernel messages, and anything of level err or higher to the console.
    *.err;kern.*                  /dev/console
# Also log console messages to a remote loghost system called adminhost.
    *.err;kern.*                  @adminhost

То есть: выводим все сообщения уровня ядра, а также все сообщения с уровнем err и выше в системную консоль, а также передаем их на систему adminhost (где его должен принимать syslog-сервер).

На указанной машине запустим сервер syslog (например Kiwi Syslog Server), и будем получать и обрабатывать эти логи, настроив по ним желаемые алерты и репорты.

Смотрите также статью: Swatch and Kiwi Syslog Daemon. К сожалению, за время, прошедшее с ее публикации, компанию-производителя Kiwi Syslog Daemon купили, и теперь их продукт платный, что, впрочем, не может помешать найти множество бесплатных вариатов той или иной степени удобности.

??ногда в работе админа случается необходимость найти и идентифицировать, например в целом шкафу дисков, какой-то конкретный. Допустим, вы не ведете подробную документацию по установленой системе (а зря), и расположение дисков и полок системы у вас не записано. Допустим вы хотите извлечь из стойки spare disk и переставить его в другую полку. Как найти правильный диск, и не выдернуть, ненароком, неправильный, рабочий?

На помошь приходит специальная команда led_on

fas1> priv set advanced – включаем режим повышенного приоритета (будьте осторожны!)
fas1> led_on 0c.54 – зажигает на диске с данным номером светодиод (LED) желтого цвета
fas1> led_off 0c.54 – гасит светодиод на диске с данным номером
fas1> priv set – выводит консоль из режима повышенных привелегий

Аналогично работает команда blink_on/blink_off, с понятным отличием, она светодиодом мигает.

Хотя в Data ONTAP и нет таких мощных скриптовых средств командной строки, как bash или PowerShell в Windows, но что-то для простейших скриптовых действий все же есть.

Команда называется source, и просто воспроизводит из поданного на вход файла команды одну за другой.

fas1> source /etc/my_scripts/vol_create.txt

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

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

• ??сполнение не прерывается и не останавливается в случае ошибок, так что следует быть особенно внимательным при создании скрипта, условием в котором является обязательное выполнение каких-то предшествующих шагов. Особенно внимательно проверяйте опечатки и ошибки в аргументах и ключах.
• Команда не умеет делать пайп (|) или перенаправление вывода в лог-файл.
• Не поддерживаются wildcards (?, *, %).
• Нет условного выполнения (IF THEN ELSE)
• Нет операции паузы, так что команды выполняются последовательно и одна за другой, даже если какая-то команда может быть и не завершила операцию (например процесс выполнения команды продолжителен). Простой workaround – запускать команду sysstat между командами.
• Почти единственное отклонение от простого листинга команд – возможность использовать # в качестве знака комментария. Строка, начинающаяся с # в подаваемой на вход source последователности команд, игнорируется.