about NetApp

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

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

В прошлый раз мы нашли и посмотрели команду 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, могут быть небезопасны, не требуются для повседневного администрировани и конфигурирования, и использование их требует ясного понимания возможных результатов и рисков использования и настоятельно не рекомендуется на “боевых” системах с рабочими даными. ?? уж тем более это так для команд из “недокументированного” и “слабодокументирванного” списка.

Администратору системы хранения иногда приходится перебрасывать данные с тома на том. Чуть ранее я уже рассказал про один из способов решения, инструменте ndmpcopy, позволяющий произвести копирование данных тома силами самой системы хранения, по протоколу NDMP.

Однако существует и другой способ копирования содержимого тома, это команда vol copy. Оба эти способа бесплатно присутствуют во всех системах хранения NetApp, но имеют отличия, давайте рассмотрим разницу.

ndmpcopy это копирование по сетевому протоколу NDMP. Даже когда это происходит в пределах одной системы, все равно это копирование происходит по сетевому сокету, и, как правило, этот процесс медленнее, чем копирование vol copy, который осуществляется непосредственно, а не по сети.

vol copy копирует содержимое тома поблочно, в отличие от ndmpcopy, причем копируется также и структура блоков, в том виде, в каком она находится на томе. То есть, например, сильно фрагментированный том, при копировании с помощью vol copy будет скопирован также фрагментированным, в то время, как копирование ndmpcopy происходит “пофайлово”, и при этом копирование сложит скопированные данные наиболе оптимальным образом.

Ограничения при использовании vol copy таковы:

• Том-источник данных и том-получатель данных должны быть одного типа. ??ли оба flexible, или оба traditional
• Том-получатель должен быть равен или больше по объему, чем том-источник
• Обе системы хранения, участвующие в копировании, должны быть в доверительных отношениях (trust relationship), на обоих должен быть включен доступ по rsh (Remote Shell)
• Том-получатель на момент начала копирования должен существовать
• Нельзя скопировать root volume
• Том-получатель будет полностью затерт содержимым тома-источника
• Состояние тома-источника на момент запуска процесса должно быть online, а тома-получателя – offline.

Малоизвестной, но полезной командой для администратора NAS является команда filestats.
С ее помощью можно быстро составить картину распределения файлов на системе хранения по размеру, времени хранения, владельцу, и использовать это в планировании и администрировании.

Вот простой пример использования. Выведем статистику по файлам тома vol0 (системного root-vol), взяв для анализа снэпшот hourly.1:

toaster> filestats volume vol0 snapshot hourly.1
VOL=vol0 SNAPSHOT=hourly.1
INODES=274528 COUNTED_INODES=875 TOTAL_BYTостой примеррES=458354190 TOTAL_KB=143556

FILE SIZE         CUMULATIVE COUNT       CUMULATIVE TOTAL KB
1K                465                    1576
10K               832                    3356
100K              853                    3980
1M                856                    4660
10M               864                    32808
100M              875                    143524
1G                875                    143254
MAX               875                    143254

AGE(ATIME)        CUMULATIVE COUNT       CUMULATIVE TOTAL KB
0                 0                      0
30D               841                    132780
60D               850                    132932
90D               859                    143464
120D              875                    143528
MAX               875                    143528

UID               COUNT                  TOTAL KB
#0                873                    143528
#20041            2                      0

GID               COUNT                  TOTAL KB
#0                851                    41556
#30               21                     1972
#1                3                      0

Обратите внимание: счетчик количества выводится “накопительный” (cumulative). То есть, например, число файлов размера “до 1K” равно 465. А число файлов “до 10К (включая и файлы, посчитанные ранее в “до 1К”)” – 832. Таким образом число файлов “больше 1К, но меньше 10К” равно 832-465=367.

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

??ногда в работе админа случается необходимость найти и идентифицировать, например в целом шкафу дисков, какой-то конкретный. Допустим, вы не ведете подробную документацию по установленой системе (а зря), и расположение дисков и полок системы у вас не записано. Допустим вы хотите извлечь из стойки 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, с понятным отличием, она светодиодом мигает.

Если с занимающими много места на дисках пользователями NAS можно справиться механизмом квот, то что делать с пользователями, которые используют много, но не места, а системных ресурсов, например загружая систему большим числом операций ввода-вывода?

Прежде всего таких следует найти и оценить загрузку от них. В этом поможет команда cifs top.

Для начала нам надо включить системную опцию:

fas1> options cifs.per_client_stats.enable on

Далее, собрав некоторую статистику, введем команду:

fas1> cifs top –n 3 –s w - показать трех самых активных пользователей, отсортировав список по объемам записи

    ops/s  reads(n, KB/s) writes(n, KB/s) suspect/s   IP              Name
     263 |     29   215 |     137   627 |        0 | 10.56.10.120 ENGR\varun
     248 |     27   190 |     126   619 |        1 | 10.56.10.120 ENGR\jill
     246 |     26   195 |     125   616 |       19 | 10.56.12.118 MKTG\bob


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

Простая, малоизвестная, но весьма полезная команда – logger. Эта команда пишет данную ей в аргументе текстовую строку в системный лог (/etc/messages). С ее помошью можно заносить в лог определенные записи, например отмечать там свои действия.

fas1> logger   *** Starting shelf firmware upgrade ***

Запущенная без аргумента она ожидает ввода со stdin (клавиатуры), завершаемого “по юниксному” – точкой в начале новой строки

fas1> logger 
—– > System going down for UPS system maintenance  < —–
System is expected to halt ungracefully while we test battery duration
-  > Sysadmin
.

В админской консоли, будь то терминал консольного порта, телнет или ssh, при подключении можно вывести на экран подключающегося (до ведения логина) какую-нибудь полезную информацию. В Linux/UNIX это часто называется banner или motd (message of the day).

Например туда можно написать какую-нибудь полезную информацию о контакте с дежурным админом:

В экстренных случаях, для контакта с системным администратором данной системы, позвоните по номеру +7-916-1234567 (круглосуточно)

??ли принадлежности данной системы в большом хозяйстве датацентра:

Данная система хранения принадлежит отделу автоматизации ОАО Проммехавтоматика (комната 414, здание Б), ответственный Приходько Б.П.

??ли вывесить в нем строгое предупреждение любителям посканировать открытые порты:

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

Для того, чтобы вывести сообщение при подключении, запишите его в файл /etc/issue или /etc/motd

Самым простым способом будет сделать это непосредственно из консоли с помощью команды wrfile, которая перенаправляет нажатия клавиш в файл, завершить запись файла можно нажатием Ctrl-C:

fas> wrfile /etc/issue
Warning: This system to be accessed only by Acme Corporation employees.
Have a nice day.
 
<Ctrl+C> error: broken pipe

Вы уже знаете, что системы хранения NetApp - мультипротокольны. В зависимости от введенных лицензий они позволяют работать с данными по протоколам CIFS и NFS (как NAS), а также по "блочным" протоколам, таким как FC, FCoE и iSCSI (IP-SAN). Но немногие знают, что кроме перечисленных протоколов, данные с NetApp также могут быть также доступны по протоколам HTTP (WebDAV) и FTP.

По умолчанию работа демона ftpd выключена. Для его включения введите в командной строке консоли контроллера команду:

> options ftpd

Вы увидите список опций, относящихся к ftpd:

Как вы видите, изначально ftpd остановлен (ftpd.enable off),вы можете включить его командой options ftpd.enable on.

Далее вы можете установить параметр ftpd.dir.override на директорию, которую вы хотите отдавать по FTP (options ftpd.dir.override /vol/vol1/my-home/my-shared-directory/). Теперь можно попробовать войти с помощью ftp-клиента и скорее всего вы увидите что-то типа 530 Login incorrect - User has no home directory., если директория, указанная в ftpd.dir.override это не корень тома. Это может означать, что пользователь, которым вы входите, не имеет так называемых traversal rights для директории, отдаваемой по FTP, поэтому вам нужно исправить это, либо если вы используете Data ONTAP 7.3.0 или старше, то в можете включить опцию ftpd.bypass_traverse_checking (options ftpd.bypass_traverse_checking on).

В заключение хочу напомнить, что протокол ftp это довольно простой и даже примитивный, в особенности с точки зрения безопасности данных, протокол. Все логины и пароли, а также содержимое файлов данных пересылается "открытым текстом", а реализованные в более современных и совершенных серверах ftp методы безопасного подключения и передачи данных в имеющемся в Data ONTAP ftpd не используются. Кроме того, надо понимать, что протокол ftp, как и сервер ftpd в системах NetApp никогда не планировался для напряженной и интенсивной работы, и, наверняка, не тестировался как следует ни на безопасность, ни на стабильность работы, играя сугубо вспомогательную роль, поэтому организовывать на нем "рапидшару", открытую во внешний интернет, наверное все же не стоит.

??сточник: http://www.m4r3k.org/english/netapp/ftp-services-on-netapp/