about NetApp

Некоторое время назад NetApp разработал и начал распространять в составе своего набора полезных утилит под ESX (ESX Host Utilities) специальные утилитки mbrscan и mbralign (в самой последней версии остался один mbralign, который же и scan делает, запускаясь с другим ключом).

Описание процесса выравнивания партиций освещена в документах NetApp не раз. Для примера могу указать на главу 6.3 в переведенном TR-3749 Руководство по наилучшим способам использования систем NetApp с VMware vSphere v4.1 , главу 4.4.8 в TR-3702 Наилучшие методы использования систем хранения NetApp для решений виртуализации Microsoft Hyper-V, а также отдельный документ TR-3747 File System Alignment in Virtual Environments

Отдельной строкой хочу отметить, что проблема с корректным выравниванием партиций виртуальных машин по границам блоков нижележащих структур НЕ есть проблема, характерная только для NetApp! Это общая, “платформонезависимая” проблема, требующая решения вне зависимости от того, что за система хранения у вас используется, даже если используются только лишь локальные диски сервера. Влияние ее на производительность (и загрузку процессора контроллера системы хранения) варьируется в зависимости от характера доступа к данным, и обычно все же не слишком велика (обычно оценивается в 10-15% снижения общей производительности от величины оптимально выравненной партиции), иногда меньше, иногда, в особо критичных редких случаях – больше. Тем не менее, это вполне реальная причина, могущая вызвать заметное на глаз снижение производительности, с которым вы вполне можете столкнуться в практике вашей работы, и которое можно поправить достаточно просто и легко.

Кроме того неверное выравнивание может значительно ухудшить показатели дедупликации.

Почти наверняка с проблемой выравнивания вы столкнетесь для виртуальных машин под Windows XP и 2003(R2), а также для старых (не-текущих) версий Linux. В Windows Vista/7/2008(R2) и новых Linux (RHEL6, например) уже выбраны значения смещения партиции по умолчанию, которые не требуют выравнивания, так как обычно уже удовлетворительно выравнены в большинстве случаев использования.

К сожалению, такая полезная утилитка идет сейчас в составе огромного пакета Virtual Storage Console, и отдельно не отдается.
Посему я и решил их выковырять и положить отдельно. Может кому пригодится.

Еще одна сложность заключается в том, что утилиты эти предназначены для ESX, но НЕ для ESXi, так как устанавливаются в хост-систему ESX, и запускаются из консоли.

Но тут можно сделать вот какой финт. Если у вас есть на нетаппе протокол NFS, то вы можете смонировать датастор по NFS на Linux-машину, и на этой Linux-машине запустить это выравнивание, также, как оно работало из консоли ESX.

Получится что-то типа: 
# mkdir /nfs_esx_export
# mount IP_adress_of_NFS_Server:/vol/nfs_datastore  /nfs_esx_export 
# /usr/bin/mbrscan <path to the -flat.vmdk>

Если вы хотите выполнить сканирование сразу множества vmdk, то можно сделать это так:

# find /nfs_datastore -name "*-flat.vmdk" -maxdepth 3 -exec /usr/bin/mbrscan {}

Затем можно выполнить выравнивание для файлов vmdk, которые mbrscan указал как невыравненные:

[root@rhel1 WinXp2]# /usr/bin/mbralign WinXp2-flat.vmdk

Выравнивание выполняется отдельно для каждого vmdk, которому эта процедура может понадобиться.

Обратите внимание, что VM должна находиться в состоянии power off, и выравнивание невозможно для виртуальных машин со снэпшотами средствами VMware:

Error: WinXp2.vmdk has a snapshot (WinXp2-000001.vmdk).  All snapshots must be removed before using this tool.

Обратите внимание, что если были выравнены партиции Linux с загрузчиком GRUB, понадобится восстановить GRUB обычным для Linux образом.

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

Помните, что, хотя официально mbrscan/mbralign и бесплатны, но требуют, для своего использования, чтобы вы были пользователем NetApp, с действующим контрактом саппорта, и иное есть формальное нарушение правил их использования.

MBRscan/MBRalign из ESX Host Utilities 5.1

Чуть более новый MBRalign (уже с встроенным scan), но чуть глючной, из состава 5.2 и VSC 2.1

При обнаружении глюков вида сообщений при выравнивании ‘cannot find mbralign.pl at line 1667′ в новом, рекомендуется пользоваться предыдущей версией из ESXHU5.1

Если у вас есть логин в NOW с доступом к загружаемыми продуктам NetApp, то вы можете воспользоваться ссылкой:

http://now.netapp.com/NOW/download/software/sanhost_esx/ESX/

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

Самый удобный вариант – организовать подключение по SSH, однако, для того, чтобы не передавать пароль, сгенерировать заранее public key, и авторизоваться на консоли NetApp с его помощью.

Вот как это сделать с помощью популярного PuTTY.

Предполагаем, что PuTTY у вас уже установлен, и вы в общем понимаете что это и как им пользоваться.

Выберите пользователя, для которого мы будем устанавливать ключ. Помните также, что если вы используете выполнение каких-то скриптов от стороннего, специально сконфигурированного пользователя (например используя RBAC – Role-based Accees Control), то это надо будет также проделать и для него. Закрыв доступ для всех ключей, кроме заранее сконфигурированных, вы заблокируете таких пользователей также.

Далее нам надо создать на контроллере поддиректорию для файла ключей, она должна располагаться внутри директории sshd
полный путь, таким образом, с точки зрения стораджа будет выглядеть примерно так (для пользователя root):

/vol/vol0/etc/sshd/root/.ssh/

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

Смонтируйте root-vol в директорию на вашем компьютере по NFS или CIFS.

Перейдите в директорию /mountpoint/etc/sshd и создайте в ней директорию с именем нужного пользователя, например мы будем использовать для администрирования пользователя romx, а для исполнения скриптов пользователя scripter.

Перейдите в созданную директорию и создайте в ней поддиректорию с именем .ssh (с точкой в начале!)

Убедитесь, что директория успешно создалась, выйдите на уровень /mountpoint, например командой cd ../../../ и размонтируйте шару.

Вы получили следующую структуру на контроллере NetApp: /etc/sshd/romx/.ssh и /etc/sshd/scripter/.ssh соответсвенно.

Теперь сгенерируем пары ключей. Запустите программу puttygen.exe, входящую в состав пакета PuTTY.

Убедитесь, что используете security algorithm SSH2-DSA (Data ONTAP умеет использовать cipher для SSH только TripleDES), щелкните “Generate!” и поводите мышкой для генерации случайной инициализацонной последовательности.

Ключ сгенерирован, теперь надо указать контроллеру NetApp использовать для аутентификации этот ключ. Запишите его в файл с расширением .ppk, например romx.ppk

Не указывайте никакую passphrase.

Скопируйте из файла public-информацию, затем создайте в созданной на контроллере директории файл authorized_keys (без расширения) и запишите туда скопированный фрагмент. Обратите внимание, что в текстовом редакторе, где вы это проделываете, должен быть выключен режим перевода строк, иначе в ваш ключ могут попасть лишние символы перевода строки. Вся последовательность public key должна располагаться в файле в одну строку! Сохраните файл. Обратите внимание на то, что файл должен не иметь расширения!

Теперь включите на контроллере режим использования преконфигурированных ключей:

filer1> options ssh.pubkey_auth.enable on

Давайте протестируем подключившись с помощью программы plink из состава PuTTY, и запросив что-нибудь из консоли:

c:\putty> plink.exe -i romx.ppk romx@filer1 vol status

В результате мы должны получить вывод команды vol status (или любой другой), использовав аутентификацию подключения по заранее сконфигурированному ключу, без необходимости вводить пароль при логине данным пользователем.

Также рекомендуется для аккаунта, исполняющего скрипты, из соображений безопасности, запретить “лишние” возможности. Подробнее об ограничении прав аккаунта смотрите в документе RUS TR-3358 Role-Based Access Control for Data ONTAP 7G.

Продолжаю свои изыскания в теме технологий EMC. На этот  раз я заинтересовался механизмом, лежащим в основе всех новых фишечек EMC CLARiiON/VNX – так называемым Storage Pool. Самым интересным и понятным для меня объяснением оказалась статья блоггера virtualeverything (он не сотрудник EMC, а, как я понял, работает в партнере-интеграторе, и имеет довольно широкое поле зрения, в котором и продукты EMC, и NetApp, и, например, Hitachi). Незначительно сокращенный перевод этой его заметки я предлагаю вашему вниманию.

Глубокое погружение в тему EMC Storage Pool.

Posted by veverything on March 5, 2011

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

Некоторое время назад EMC представила в своей линейке систем хранения CLARiiON новый принцип так называемого Virtual Provisioning и Storage Pools. Основная идея заключалась в упрощении администрирования системы хранения. Традиционный метод управления хранилищем это взять дисковый массив, наполненный дисками, создать из них дискретные группы RAID, и затем нарезать из этих групп LUNы, которые, затем, предоставляются хостам. Дисковый массив, в зависимости от своего размера, при этом может содержать до нескольких сотен таких групп, и часто превращается в архипелаг разрозненных "островков хранения" на этих RAID-группах. Это может вызывать серьезные затруднения при планировании пространства хранилища, чтобы устранить проблему нерационально потраченного при таком разбиении места, так как у большинства пользователей их потребности к хранилищу, и планы как разбить под задачи, меняются со временем, и, обычно, еще не ясны до конца в "день 1". Нужны были средства гибкого и простого администрирования, и родилась идея Storage Pools.

Storage pools, как следует из его имени, позволяет администраторам создавать "общий массив" (pool) хранения. В ряде случаев вы даже можете создать один большой, общий пул, куда входят все диски системы хранения, что значительно упрощает процессы администрирования. Больше нет отдельных пространств, не нужно углубляться в "тонкие материи" устройства и организации RAID group, схем разбиения, и так далее. Кроме того, появилась также технология FAST VP, которая позволяет перемещать блоки данных в соответствии с их активностью, по уровням хранения, например на более емкие и дешевые, или более быстрые и дорогие диски. Просто выделите и назначьте пространство из такого "пула" вашей задаче, динамически, гибко, и при этом еще и позволяя использовать auto tiering. Звучит здорово так? По крайней мере так утверждает маркетинг. Давайте разберемся с тем, как это работает "физически", и нет ли не вполне очевидных "подводных камней".

Continue reading ‘EMC Storage Pools – как это работает “под крышкой”.’ »

Я обратил внимание, что, довольно часто, пользователи сталкиваются с ошибкой конфгурации, которая индицируется в логах сообщением: FCP Partner Path Misconfigured. Несмотря на то, что ошибка эта довольно банальна, и исправление вызвавших ее причин тривиально, я заметил, что у многих пользователей возникают проблемы с диагностикой, да и вообще с пониманием того, что именно вызывает эту ошибку.

Поэтому я взял на себя труд перевести на русский прекрасно написанную статью из Knowledge Base с сайта NetApp, в которой подробно рассматривается эта ошибка, причины ее вызывающие, и методы устранения.

Что означает сообщение FCP Partner Path Misconfigured

https://kb.netapp.com/support/index?page=content&id=3010111

KB ID: 3010111 Version: 7.0
Published date: 04/29/2011

Проблема

AutoSupport message: FCP PARTNER PATH MISCONFIGURED

Сообщения Syslog и EMS

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

Continue reading ‘Что означает сообщение FCP Partner Path Misconfigured (и что с ним делать)?’ »

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

Однако мне на прошедшей и этой неделе пока некогда, поэтому пока позвольте представить вашему вниманию перевод официального FAQ на тему MPHA, от NetApp, а свои мысли на этот счет я оставлю до времени, когда я смогу подробнее “посидеть над столом” и сформулировать их.

Пока же – официальная позиция NetApp на тему использования MPHA в системах хранения NetApp.

Continue reading ‘Multi-path High Availaility (MPHA) FAQ’ »

Вы уже знаете, что каждая система хранения NetApp, вернее даже каждый ее контроллер, обязательно имеет на подключенных к нему дисках специальный, обычно самый первый, том, так называемый root volume или vol0. На этом томе хранится содержимое настроек и установок внутренней OS Data ONTAP (для знакомых с миром UNIX OS скажу проще – /etc), а также много всего прочего, включая директорию документации и веб-интерфейса, прошивки дисков, конфиг-файлы репликации и прочее жизненно необходимое. Такая схема позволяет легко и просто менять контроллер системы хранения, ведь если все индивидуальные настройки системы находятся на дисковых полках, вместе с данными, а в контроллере только ядро, то подключенный на замену новый (даже другого типа) контроллер загрузится, обнаружит и подключит /etc с дисков, и загрузится в той конфигурации и с теми самыми настройками, которыми обладал старый контроллер.

Том root vol, обычно vol0, создается при начальной установке системы и очень часто уже никогда не меняется. Но что делать, если нам понадобилось изменить положение root vol, создать новый, на других дисках, например? Каким образом правильно перенести root vol на новый том?

Допустим, мы мигрируем с 7.x на 8.0.1, и хотим использовать 64-bit aggregate only. Так как в настоящий момент нет средства преобразовать 32-bit, 7.x-style aggregate в новый, 64-bit, нам придется создать на пустых дисках новый 64-bit aggregate, затем перенести в него root vol и другое содержимое старого aggregate, затем убить старый aggregate и добавить его диски в новый.

Или, например, наша старая система когда-то создала свой root vol на старых дисках FC 144GB, а теперь мы используем SAS 600GB, и хотим вывести старые полки из эксплуатации, перенеся их содержимое на новые, в том числе и root vol.

Но как вы догадываетесь, root vol это немного особенный том, недостаточно его просто скопировать, надо чтобы его опознало ядро Data ONTAP как “свое”.

Посмотрим на имеющуюся картину:

filer> vol status
Volume State Status Options
vol1 online raid_dp create_ucode=on
vol0 online raid4 root, create_ucode=on

Как вы видите, том vol0 имеет специальный атрибут – root.

Начнем с того, что на нужном aggregate создадим том, который будет в будущем нашим новым root vol.

> vol create <new_root_volname> <aggrname> <size>

Размер тома (size) следует выбрать согласно рекомендациям для используемого типа контроллера (он зависит от используемого в контроллере объема памяти, потому что на нем должно быть место для сброса core dump, “если что-то пошло не так” и дальнейшей диагностики проблем системы, кроме того определенный объем занимают файлы самой OS).

Рекомендованные значения размеров тома:
Для 7.3.х:
FAS2020 – 10GB, FAS2050 – 12GB, FAS2040, FAS3140 – 16GB, FAS3160 – 23GB, FAS3170, FAS6040 – 37GB, FAS6080 – 69GB.

Для 8.х.х:
FAS2040, 3040, 3140 – 160GB,  остальные – 250GB.

Напомню, что размер тома вы можете увеличить и после его создания, но не более, чем на 95% от объема его содержащего aggregate. Проверить доступную емкость aggregate можно командой df -A

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

Убедимся что ndmp daemon включен или включим его, если он выключен.

> ndmpd on

Скопируем содержимое тома в новый том. В отличие от копирования “через хост”, эта операция осуществляется внутренними средствами системы хранения и не нагружает канал передачи данных.

> ndmpcopy /etc /vol/new_root_vol/etc

Ndmpcopy: Starting copy [ 2 ] …
Ndmpcopy: filer: Notify: Connection established
Ndmpcopy: filer: Notify: Connection established
Ndmpcopy: filer: Connect: Authentication successful
Ndmpcopy: filer: Connect: Authentication successful
Ndmpcopy: filer: Log: DUMP: creating "/vol/vol0/../snapshot_for_backup.4" snapshot.
Ndmpcopy: filer: Log: DUMP: Using subtree dump
Ndmpcopy: filer: Log: DUMP: Date of this level 0 dump: Mon Mar 7 10:18:18 2005.
Ndmpcopy: filer: Log: DUMP: Date of last level 0 dump: the epoch.
Ndmpcopy: filer: Log: DUMP: Dumping /etc to NDMP connection
Ndmpcopy: filer: Log: DUMP: mapping (Pass I)[regular files]
Ndmpcopy: filer: Log: DUMP: mapping (Pass II)[directories]
Ndmpcopy: filer: Log: DUMP: estimated 365193 KB.
Ndmpcopy: filer: Log: DUMP: dumping (Pass III) [directories]
Ndmpcopy: filer: Log: RESTORE: Mon Mar 7 10:18:25 2005: Begin level 0 restore
Ndmpcopy: filer: Log: RESTORE: Mon Mar 7 10:18:25 2005: Reading directories from the backup
Ndmpcopy: filer: Log: DUMP: dumping (Pass IV) [regular files]
Ndmpcopy: filer: Log: RESTORE: Mon Mar 7 10:18:28 2005: Creating files and directories.
Ndmpcopy: filer: Log: RESTORE: Mon Mar 7 10:18:32 2005: Writing data to files.
Ndmpcopy: filer: Log: DUMP: dumping (Pass V) [ACLs]
Ndmpcopy: filer: Log: RESTORE: Mon Mar 7 10:19:06 2005: Restoring NT ACLs.
Ndmpcopy: filer: Log: RESTORE: RESTORE IS DONE
Ndmpcopy: filer: Notify: restore successful
Ndmpcopy: filer: Log: DUMP: 365298 KB
Ndmpcopy: filer: Log: DUMP: DUMP IS DONE
Ndmpcopy: filer: Log: DUMP: Deleting "/vol/vol0/../snapshot_for_backup.4" snapshot.
Ndmpcopy: filer: Notify: dump successful
Ndmpcopy: Transfer successful [ 49 seconds ]
Ndmpcopy: Done

Укажем для OS, что созданный том и есть наш новый root vol

> vol options new_root_vol root

Mon Mar 7 10:21:24 PST [filer: fmmbx_instanceWorke:info]: Disk 8a.37 removed from primary mailbox set
Mon Mar 7 10:21:24 PST [filer: fmmbx_instanceWorke:info]: Disk 8a.36 removed from primary mailbox set
Mon Mar 7 10:21:24 PST [filer: fmmbx_instanceWorke:info]: Disk 8a.35 is a primary mailbox disk
volume new_vol_root will become root volume at the next boot.

При необходимости переименуем новый том понятным именем

> vol rename new_root_vol rootvol

Если вы использовали NAS-шары на старом томe (например для доступа к содержимому /etc и корня root vol, автоматически при инсталляции создаются шары etc$ и c$), они будут автоматически переставлены на новые места. Проверьте это, и, при необходимости, поправьте.

> cifs shares

> exportfs

Проверьте новые настройки томов

filer> vol status
Volume State Status Options
vol1 online raid_dp create_ucode=on
vol0 online raid4 create_ucode=on
rootvol online raid4 root, raidsize=4, create_ucode=on

Как вы видите, созданный вами том rootvol теперь является root.

Перезагрузитесь (в кластерной системе вместо перезагрузки можно сделать кластерный takeover/giveback), и убедитесь, что все хорошо.

> reboot

Готово, вы перенесли root volume на новое место.

UPD: Как правильно заметили в комментариях, я забыл еще одну операцию. Дело в том, что после переноса root vol перестает работать доступ по https в FilerView и System Manager. Поэтому необходимо перегенерировать SSL-сертификаты из командной строки:


filer> options ssl.enable off
filer> secureadmin setup ssl
filer> options ssl.enable on


Как вы, возможно, слышали, загрузить систему хранения NetApp можно по сети, сравнительно традиционным для UNIX-систем способом загрузки OS (ядра и rootfs) через TFTP. Это может помочь, например, если из за неисправности имеющегося ядра, которое располагается в системах NetApp на внутренней CF-карточке.

Для того, чтобы загрузиться с TFTP необходимо при загрузке прервать обычное выполнение процедуры загрузки нажав при включении системы Ctrl-C (или в случае повреждения собственного загрузочного ядра OS система окажется там сама), оставшись в “биосе”. В качестве “биоса” в системах хранения NetApp используется специальный загрузчик, под названием LOADER (в более ранних системах, например FAS270 или FAS3020/3050 использовался немного другой метод – CFE – Common Firmware Environment).

Как для LOADER, так и для CFE для загрузки системы хранения с помошью netboot вам нужно скачать с сайта NetApp netboot-версию OS Data ONTAP нужной вам версии и типа платформы (для современных систем это всегда версия с индексом платформы Q, для FAS3020/3050 индекс платформы будет E, для старых, MIPS-based систем, например FAS270 – M).

Netboot-версия Data ONTAP 7.3.5.1 (наиболее свежей 7.х на момент написания этого поста) имеет размер 27,4MB (7351_netboot.q), версия Data ONTAP 8.0.1 – 144,6MB (801_netboot_q.tgz) и представляют собой kernel и rootfs завернутые в tar.gz, загружающиеся традиционным образом в память.

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

В подсказке LOADER необходимо настроить сетевой интерфейс и запустить сетевую загрузку.

LOADER> ifconfig e0a -addr=192.168.1.10 -mask=255.255.255.0 -gw=192.168.1.1
e0a: Link speed: 1000BaseT FDX
Device e0a:  hwaddr 00-A0-98-03-48-AB, ipaddr 192.168.1.10, mask 255.255.255.0
        gateway 192.168.1.1, nameserver not set

Доступные опции для команды ifconfig можно посмотреть введя в подсказке LOADER команду help ifconfig

Проверяем работу сети пингуя default gateway:

LOADER> ping 192.168.1.1
192.168.1.1 (192.168.1.1) is alive
192.168.1.1 (192.168.1.1): 1 packets sent, 1 received

Запускаем команду netboot

LOADER> netboot tftp://192.168.1.11/tftproot/netapp_7.2.3_x86_64
Loading:. . . . . . . . . . .

Далее Data ONTAP загружается обычным образом. Если /etc , хранящийся на root volume, при этом доступен, то система запустится штатным образом, восстановив все рабочие настройки, если же система повреждена значительно, и, например /etc также  недоступен, то можно попробовать загрузиться без /etc (выбрав соответствующую опцию в boot menu) инициализировать диски, создать новый aggregate, и запустить установку OS “начисто”.

Обратите внимание, что для netboot доступны только встроенные ethernet-порты, не те, что возможно у вас на системе установлены на карте расширения, которая в момент начальной загрузки еще недоступна.

Конечно этот пост должен был быть написан и опубликован до начала известной распродажи FAS2020, стартовавшей в первом квартале этого года, так как именно с ними в ряды владельцев NetApp начали вливаться новые, необтёртые и необстрелянные пользователи, но, увы, лучше поздно чем никогда. Да и, я уверен, распродажа эта не последняя, а темпы роста NetApp на рынке не уменьшаются, что говорит о том, что новых владельцев систем хранения NetApp будет еще много.

Давайте с самого начала рассмотрим путь самурая нового пользователя NetApp, и те сложности, с которыми он может столкнуться, запуская новую для себя систему.
Вот вы купили сторадж, и вам его даже доставили, и вот он стоит у вас в датацентре, в коробке. Что делать дальше?
(тут должна быть ссылка на видеоролик на ютубе, в популярном нынче жанре unboxing. Надо будет сделать как-нибудь;)

Continue reading ‘Запускаем новую систему хранения. Часть 1.’ »

Рассмотрим еще одну полезную команду для глубокой диагностики, позволяющую находить и анализировать проблемы канала передачи данных от диска к контроллерам на системах, использующих интерфейс FC к дискам. Это системы с полками DS14, которые постепенно заменяются на дисковые полки, работающие по SAS, в новых моделях FAS, но все еще широко распространенные в продакшне.

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


na_fcstat - Fibre Channel stats functions

Формат:
fcstat link_stats [ adapter number ]
fcstat fcal_stats [ adapter number ]
fcstat device_map [ adapter number ]

Continue reading ‘Оптимизация производительности. Часть 4. fcstat’ »

Но кроме “встроенных” в Data ONTAP средств, есть еще и очень полезные “внешние” утилиты сбора и анализа. Например, для пользователей NetApp на NOW есть скрипт perfstat, собирающий с контроллера разнообразную информацию по производительности в единый “лист”. В дальнейшем этот вывод perfstat можно обрабатывать и анализировать другими утилитами, а также использовать в сайзинге.

Скрипт существует как для UNIX (в виде bash-скрипта), так и для Windows, оба варианта работают через rsh/ssh.
Запущенный без параметров, он выведет подробную инструкцию по использованию. Рекомендую начать с ее изучения.

Perfstat: Version 7.32 12-2008
    - perfstat.sh is a simple Bourne Shell script that
      captures performance and configuration statistics.
    - Output from perfstat is sent to standard out and
      is typically captured in an output file for
      later analysis.
    - perfstat.sh is capable of capturing info from host(s) and
      NetApp storage controllers simultaneously.
    - Currently perfstat supports these OS platforms:
      Solaris, HP-UX, OSF1, Linux, AIX, FreeBSD, OpenBSD, ESX 3.5
    - perfstat.sh is typically run as root from the host or
      as a user with root-level permissions
    - For controller data capture, the user must have RSH or
      SSH privileges to the controller. Unless instructed otherwise,
      perfstat will use 'root' as the default username to communicate
      remotely with storage controllers and hosts.

Usage: (basic options list)
 perfstat [-f controllername] [-t time] > perfstat.out
    where:
    -f controllername - host name (or IP address) of target controller
    -t time - collect performance data for 'time' minutes

 Simple Examples:
   Capture data on local host and one controller for 5 minutes:
     perfstat -f controller1 -t 5 > perfstat.out
   Capture data on multiple hosts and controllers for 10 minutes:
     perfstat -h host1,host2 -f controller1,controller2 -t 10 > perfstat.out
   Capture data for five 1 minute iterations, with 10 minutes between
   successive iterations:
     perfstat -f controller1 -t 1 -i 5,10 > perfstat.out

Usage: (more complete options list)
 perfstat
          [-f controllername[,controllername1,controllername2,...]]
          [-h hostname[,hostname1,hostname2,...]]
          [-t time] (sample time per iteration, default 2)
          [-i n[,m]] (repeat n times with m minutes between samples,
                      defaults: n=1, m=0)
          [-I] (force perfstat to execute all iterations)

          [-r rootcmd] (e.g. sudo)
          [-l login[:password]] (RSH/SSH login and RSH password)
          [-S] (use SSH instead of RSH)
          [-s param1[,value1][:param2[,value2]]...] (optional RSH/SSH
                                                     arguments)

          [-F] (do not capture information from local host)
          [-V] (do not capture vfiler data)
          [-p] (capture performance data only, no config info)
          [-c] (capture config info only, no performance data)
          [-L] (capture logs - beware verbose output)
          [-E cmd[,cmd2,cmd3] (exclude commands)
          [-P domain1[,domain2,domain3...] (capture profiles,
              use "-P flat" to capture complete profile)

          [-a app_name -o app_param] (E.g., -a oracle)

          [-v] (print version info only)
          [-q] (quiet mode - suppress all console output)
          [-x] (print what commands will be issued without actually
                issuing them)
          [-d] (debug mode - beware verbose output)

          [-b] (begin sampling and return immediately)
          [-e] (end sampling - used in conjunction with -b)

          [-n] (RAM Service Invocation)

          [-k] (disable collection of "stutter" statit; i.e.,
                collect 1 statit report that covers the entire
                iteration)
          [-K] (collect only "stutter" statit reports over
                the entire iteration)

          [-T default | sk_mod,level[,sk_mod2,level,...]] (collect sktrace)
          [-B sk_buffer_size] (specify sktrace buffer size)

Notes:
 -h option adds hosts to be monitored.  By default, the local
    host is always monitored, unless the -F flag is specified.
    E.g., executing this command
      perfstat -h host1 > perfstat.out
    on machine host0 will result in data captured from both
    host0 and host1
    This command:
      perfstat -F -h host1 > perfstat.out
    on machine host0 will result in data captured from host1 only
 -l option is only applied to RSH/SSH commands to the controller.
    RSH/SSH commands to other hosts do not use the -l information.
    perfstat.sh does not support password authentication over SSH,
    so if '-S -l login:password' is specified, the password will
    be stripped from the subsequent SSH invocations.
 -S requires passwordless (public key) SSH authentication to be
    configured for all controllers and hosts
    An SSH username may prefix a hostname using a '@'
    E.g.,
      perfstat -S -h root@host1,user@host2
    Additionally, the -l option can be used to specify usernames for
    controller login. E.g.,
      perfstat -S -f controllername -l user
 -s arguments to this option use the syntax 'param,value', and param
    value pairs can be separated by a ':'
    E.g. the syntax '-S -s p1,22:p2:p3,v3' tells perfstat to build
    the following SSH invocation string:
     'SSH -o BatchMode=yes -2 -ax -p1 22 -p2 -p3 v3'
 -a is limited to these applications currently:
    oracle: -o specifies sub arguments.  run -o help for details
 -b|-e are provided for legacy compatibility and can be used to
    manually perform an iteration. Use -b to start the iteration
    and after perfstat returns, use -e to stop that iteration.
 -P saves profiling data in a tar.gz file in the current working
    directory and deletes any existing gmon files on the controller
 -E excludes all foreground commands that have at least the cmd as a
    substring; E.g.
      -E snap,vol       - excludes all 'snap*' and 'vol*' commands
      -E "snap list -v" - excludes only the command 'snap list -v'
 -T used to toggle sktrace collection and specify sk modules and the
    levels at which trace data should be collected for those modules.
    Some valid sk modules include SK, WAFL, DISK and SCSITARGET. For
    default values of 'SK 7 WAFL 4', specify '-T default'. sktrace data
    will be copied off of the controller(s) and into the current working
    directory from where perfstat was invoked.
 -B used to manually set the sktrace buffer size. By default, perfstat
    will use a default value of '40m' (40MB). Please note that it is
    required that the units be specified with the size in the format:
    k (KB), m (MB), or g (GB). This value should only be changed if
    specifically advised by global support.
 Early termination of execution: as of v7.00 perfstat will terminate
   iterations early if a calculated max runtime is met or exceeded.
   If it is required that perfstat must execute all iterations regardless
   of the total runtime, please use the '-I' option.

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

Например, можно поместить в cron на администраторском хосте команду вида:

perfstat -f filer1 -t 30 -i 46 > perfstat.$date.out

Такая строка запуска делает 46 “снимков” с 30-минутным интервалом, что покрывает примерно 23 часа суток. Из-за некоторых сложностей, связанных с тем, что выполнение множества команд в rsh при выполнении скрипта может подтормаживать, и за сутки может набежать довольно существенная задержка, NetApp рекомендует делать полный интервал снятия показаний не 24, а 23 часа (46 снимков каждые полчаса), оставив запас между сутками в час,  чтобы быть уверенным, что из-за таких задержек исполнения, не набежит нежелательная погрешность для времени запуска.

Так как официально perfstat раздается только с NOW, то есть действующим пользователям NetApp, наверное я вам его раздавать не буду, сами скачайте с NOW.

Для обработки вывода perfstat можо воспользоваться интересной утилитой PerfViewer.

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

Берут там же. :)