about NetApp

С выходом в активную жизнь Data ONTAP 8 с ее cluster-mode в этом блоге я начинаю менять используемую терминологию. Теперь, во избежание путаницы, я буду называть “cluster-classic”, который был в ONTAP 7 – как “HA-кластер” (High Availability), а под кластером “просто” будет подразумеваться multinode-cluster или ONTAP 8 cluster-mode.

Как вы знаете, HA-кластерная функцинальность систем NetApp позволяет прозрачно для приложений и задач, в случае отказа одного из контроллеров HA-кластерной пары, перенести все его ресурсы, то есть IP-адреса, сетевые имена, WWN-ы FC, а следовательно доступ к сетевым шарам, LUN-ам, и так далее, с вышедшего из строя контроллера на действующий. Таким образом доступ ко всем ресурсам полностью сохраняется и не требует перенастройки клиентов или “фабрики” для продолжения доступа.

Однако такая схема переключения может занимать, подчас, довольно значительное время, исчисляемое десятками секунда на совершение этого HA-cluster takeover. Это связано с тем, что “выживший” контроллер должен понять, что его HA-кластерный партнер не просто не отвечает вовремя, а дейтвительно перестал работать.

Значительно ускорить этот процесс можно с помощью операции Hardware-assisted Takeover, которая использует для определеня состояния контроллера возможности RLM – автономного аппаратного микроконтроллера, который по основной своей задаче предназначен для удаленного “out-of-band” администрирования, и работает как независимое аппаратное устройство. RLM был опциональным устройством в системах серии 3000/6000, и встроен в контроллер для серии 3100 и новее. Будучи “внешним” для системы watchdog-ом, RLM позволяет значительно сократить время кластерного takeover, быстро определяя и сообщая состояние своего контроллера. RLM даже имеет автономное (хотя и не слишком длительное по времени автономной работы) питание, и остается включенным в сети даже, например, при полной потере электропитания контроллером, позволяя определять даже такое событие.

Для того, чтобы включить Hardware-assisted Takeover, при наличии на контроллере OS Data ONTAP 7.3 и новее, дайте в консоли команду

fas> options cf.hw_assist.enable on

Для того, чтобы изменить IP-адрес для получения партнером уведомлений об отказе, используйте команду (по умочанию это адрес порта e0a):

fas > options cf.hw_assist.partner.address <IP or hostname>

Подробнее смотрите во встроенной документации на систему Data ONTAP вашей версии, по словам ???hardware-assisted takeover’.

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

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

Малоизвестной, но полезной командой для администратора 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.

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

Несмотря на то, что Data ONTAP не только не является “Линуксом”, она даже UNIX в общепринятом смысле этого слова не является (не устаю это повторять снова и снова, потому что это один из самых распространенных мифов в отношении NetApp), тем не менее, для удобства администраторов, а первыми администраторами систем хранения NetApp были, конечно же, администраторы UNIX-систем, в ней многое сделано “очень похожим на UNIX”. Структура директорий, правила именования файлов, и даже большинство команд похожи на свои аналоги из мира Юникса.

Вот, например, даже имется хорошо известная команда dd, хотя она и немного спрятана.

Отдайте в консоли команду

fas1> priv set advanced

Эта команда переведет вас в специальный “расширенный режим”, в котором вы получаете доступ к расширенному набору команд, но, ВН??МАН??Е, эти команды могут быть опасны для работы системы, и для сохранности данных! Пользуйтсь ими с ответственностью, и исключительно на свой страх и риск!
После ввода этой команды вы заметите изменившийся значок подсказки. Он указывает вам на то, что вы работаете в режиме повышенных привилегий. Для того, чтобы вернуться на обычный уровень, введите команду priv set admin или просто priv set

Среди множества дополнительных команд вам будет доступна и команда dd – disk dump, прямого посектороного копирования.

fas1*> dd if=/vol/vol0/etc/rc of=/vol/newroot/etc/rc – копирование rc в новое место 
  
Обратите внимание, вы НЕ можете запустить команду dd в фоне (еще раз напомню, что Data ONTAP это не линукс, и внешняя схожесть команд еще не значит внутреннего подобия), поэтому, если вы используете dd, то все копирование будет происходить “основной задачей”, наберитесь терпения. Кстати это еще один повод использовать вместо dd что-нибудь более продвинутое, например ndmpcopy.
Прервать работу dd можно нажатием Ctrl-C

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

Для того, чтобы лучше разобраться в сообщениях syslog, на сайте NOW (NetApp on Web) есть полезная служба: System Log Translator
ниже – скриншот:

Например, мы видим в логе сообщение:

[scsitarget.partnerPath.misconfigured:error]: FCP Partner Path Misconfigured - Host I/O access through a non-primary and non-optimal path was detected.

Введенное в Syslog Translator оно покажет следующее:

Уже гораздо понятнее что делать и куда бечь.

Если с занимающими много места на дисках пользователями 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
.

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

fas> environment status – показывает всю доступную информацию 
fas> environment shelf – показывает информацию, относящуюся к дисковым полкам 
fas> environment chassis all – показывает информацию о шасси контроллера
fas> environment chassis list-sensors – показыват все датчики шасси, их состояния и пороги

Пример вывода команды environment status shelf:

          Environment for adapter 3:
                  Shelves monitored: 1    enabled: yes
                  Swap in progress? no    Environmental failure? no

                  EDM 1 (active):
                  SES Configuration, via loop id 3 in shelf 0x0:
                   logical identifier=0x3003040000000000
                   vendor identification=EuroLogc
                   product identification=Eurologic EDM
                   product revision level=0x01000101
                  Vendor-specific information:
                   backplane byte=0x1e     cabinet id=0x0
                   Backplane Type : Single Fibre Channel Backplane
                   Backplane Function : Storage System
                   Kernel Version : 1.0.A          App. Version : 1.1.A
                  Shelf:0         SES path:3.3    Device mask: 0x7f
                  Power Supply present: 0x3; with error: 0x0
                  Fans present: 0x3; with error: 0x0
                  Temperature Sensor present: 0x1; with error: 0x0
                  SES Electronics present: 0x1; with error: 0x0
                  Shelf temperature: 29C (84F)
                  High thresholds: critical: 55C (131F); warning 50C (122F)
                  Low thresholds: critical: 0C (32F); warning 10C (50F)

                  Disks physically present on adapter 3
                    Devices 0x1f-0x00: 0000007f
                    Devices 0x3f-0x20: 00000000
                    Devices 0x5f-0x40: 00000000
                    Devices 0x7f-0x60: 00000000