about NetApp

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

Так, например, как-то я там обнаруживал NetApp System Analyzer for CIFS, а также архиполезный набор утилит na_stats. А на днях автор блога Geek ONTAP показал еще одну интересную утилитку – NetApp Storage Security Editor.

Если вы используете системы NetApp как CIFS-сервер, и вынуждены часто строить сложные ACL для разграничения доступа, то вам должно быть такое интересно. Этот инструмент позволяет создавать описания настроек доступа для ресурса на языке SDDL.

SDDL – Security Descriptor Definition Language – язык описания дескрипторов доступа, позволяющий создавать строки, описывающие права доступа на ресурсы. Язык этот лишь слегка проще конфигурационного файла sendmail, поэтому наличие хорошего инструмента, позволяющего на нем писать совершенно необходимо.

Записанную в файл строку на SDDL можно импортировать в NetApp с помошью консольной команды fsecurity apply.

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

К сожалению утилита находится в крайне ранней стадии развития, поддерживает пока только NTFS-security, а в нем storage-level и file/directory-level security, также не поддерживаются не-ASCII символы во вводе.

Подробнее смотрите на странице инструмента (нужен логин в NetApp Support (NOW)).

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

Например с помощью встроенной в Data ONTAP команды ndmpcopy можно внутренними средствами контроллеров системы хранения копировать данные как внутри одной системы хранения, так и между ними (то есть не гоняя их “через внешний хост”, а непосредствено с контроллера на контроллер). Иногда это бывает очень удобно. Некоторое время назад я показывал использование ndmpcopy для переноса root volume системы хранения, там мы копировали по ndmp содержимое root vol на новый том, который потом делали новым root.

К сожалению, существующая на сайте ndmp.org программа ndmpcopy отличается по функциональности от встроенной в DOT, не умеет междевайсное копирование, и работает со старой версией протокола, что значтельно сужает область ее использования.

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

Версию его программы можно скачать тут: http://cronsult.com/jndmpcopy_man.aspx

Я уже писал, что в разделе Toolchest на NOW можно, порой, найти какие-нибудь интересные и полезные утилитки, про которых, часто, никто не знает. Вот и в этот раз там обнаружилась любопытная утилита SnapMirror Progress Monitor Tool.

Это, что явствует из названия, инструмент для слежения за процессом репликации SnapMirror.

Если в вашей системе хранения используется SnapMirror, а в особенности, если SnapMirror передает достаточно объемные репликации по сравнительно узким WAN-каналам, то, безусловно, такая утилитка будет в вашей практике весьма применима и полезна.

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

Давно у нас не было переводов по средам. И вот сегодня – перевод, посвященный выходу в начале сентября новой версии Virtual Storage Console – VSC – плагина к VMware vCenter, позволяющего непосредственно из среды vCenter управлять системой хранения NetApp.

Это бесплатный продукт, и однозначный мастхэв, если вы используете систему хранения NetApp вместе с VMware.

А вот, что появилось нового. Для начала – сам VSC 2.1

А что нового – в посте Криса Гебхарда.

NetApp Virtual Storage Console 2.1.1 - Now Available

Posted by Chris Gebhardt on Sep 8, 2011 5:18:01 AM

Конечно, мне тоже кажется, что за последнее время я говорю в своем блоге “я рад объявить о выходе” довольно часто, но в данном случае я правда рад и счастлив рассказать о выходе этого продукта! Сегодня (8.09) NetApp выпускает в свет новую версию Virtual Storage Console 2.1.1. Выход этой версии на самом деле довольно важное событие и новые технологии помогут пользователям в их работе с их серверными и десктопными виртуальными системами. Ниже список новых возможностей этой версии VSC 2.1.1.  Я хотел бы особо выделить некоторые из новых возможностей, которые, как мне кажется, наиболее важные, но так получается, что мне придется выделить почти все. Этот релиз, несмотря на минорность, на самом деле очень важен, так как начал поддерживать vSphere 5 и View 5, и ряд новых технологий, которые позволят пользователям улучшить эффективность хранения с помощью thin provisioning для виртуальных машин, а также улучшить ряд аспектов эксплуатации, развертывания и обслуживания виртуальных инфраструктур.

На протяжении следующих нескольких недель я опубликую у себя в блоге демонстрации работы некоторых новых возможностей VSC 2.1.1.

Скачать  VSC можно по ссылке: http://now.netapp.com/NOW/download/software/vsc_win/2.1.1/ <- У вас должен быть логин на NetApp NOW для скачивания!

Итак, что нового:

Virtual Storage Console 2.1.1 включает в себя все что уже было выпщено в VSC 2.1, плюс добавлены новые возможности. Список ниже объединяет новинки 2.1.1 и 2.1:

• Поддержка vSphere 5.0, включающая vCenter Server 5.0 и ESXi v5.
• Базовый модуль Virtual Storage Console переименован в Monitoring and Host Configuration для лучшего понимания его функций.
• Панель Monitoring and Host Configuration Tools теперь имеет две кнопки для скачивания и установки утилит MBR tools: одна для хостов ESXi, другая для ESX. Выберите соответствующую вашей системе версию.
• В Monitoring and Host Configuration добавлены следующие возможности:
  • Можно назначить хост как skipped
  • Отображаются контроллеры системы хранения, работающие в 8.х Cluster-Mode
  • Обеспечивается быстрый поиск (discovery), кроме того, discovery может работать как фоновый процесс
  • Отображается информация о статусе хоста, в колонке Status Reason для хостов
• Модуль Provisioning and Cloning теперь умеет следующее:
  • Высвобождает свободное место (reclaiming space) после удаления данных в guest OS *
  • Предотвращает неверное смещение партиции VM перед клонированием
  • Позволяет задать число CPU и настройки оперативной памяти для новых виртуальных машин
  • Умеет добавлять существующие датасторы новым серверам ESX в кластерах и датацентрах *
  • Сохранение учетных данных View Server для клонирования
  • Позволяет клонировать датасторы в пределах всего сайта vSphere
  • Поддерживается создание, именование, управление виртуальных машин в новых пулах View Server
  • Поддерживает импорт в Citrix XenDesktop и VMware View (расширен API)
  • Сохраняются настройки BIOS при клонировании из шаблона
  • Система хранения добавляется из под доменного аккаунта
  • Catalog-based API provisioning
  • Поддерживается Citrix XenDesktop 5.0
  • Поддерживается Data ONTAP 8.1.0 (7-Mode)
  • Поддерживается VMware View 4.6 и 5.0

* Об этом подробнее в следующем переводе, прим. romx

Некоторое время назад 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/

Даже чуть раньше графика зарелизился новый продукт NetApp – OnCommand.

Напомню, что NetApp OnCommand это новый “зонтичный” бренд для целого семейства софта управления, куда буде входить много что, например софт, ранее известный как Protection Manager, Provision Manager и Operations Manager, а также Appliance Watch и SnapManager for VMware и Hyper-V, и еще несколько продуктов. По сути под именем OnCommand будет собран весь многочисленный арсенал средств администрирования, наработанный до сего дня в NetApp (как видите, не только EMC учится у NetApp, но и NetApp тоже;).

Если у вас есть действующий логин в NOW (NetApp Support site), то вы можете получить ту часть OnCommand, что будет доступна для пользователей бесплатно (OnCommand Core Package), уже сейчас по данной ссылке.

Обратите внимание на предварительные требования к системе и оборудованию, а также прочтите release notes и installation guide.

Вы уже знаете, что каждая система хранения 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


Я уже писал (тут, тут и тут) в этом блоге о чрезвычайно полезном, свободно распространяемом тулките для PowerShell, разрабатываемом в NetApp. Этот тулкит представляет собой целый набор разнообразных “командлетов” (commandlets), для администрирования систем хранения NetApp.

На сайте communities.netapp.com (если вы работает с NetApp, но еще не там, то самое время вливаться, доступ и создание логина там свободные) можно найти хорошую презентацию о том, как установить и пользоваться тулкитом:

Getting Started With Data ONTAP PowerShell Toolkit

А недавно был выложен обновленный документ:

Making The Most Of Data ONTAP PowerShell Toolkit

Если вы умете использовать PowerShell, и планируете использовать его возможности для управления системой хранения NetApp, то рекомендую всячески.

NetApp опубликовал в своем community приглашение к публичному бета-тестированию новой версии их инструмента администрирования системы хранения – System Manager.

Существующая версия System Manager (v1.1) это программа на .Net под Windows. В версии 2.0 было принято решение делать новый System Manager под Java, он работает как java-приложение в браузере.

Что до моего мнения, то решение о возврате на Java крайне сомнительное, но поживем-увидим. Зато появилась версия под Linux. Возможно, тот небольшой процент администраторов, не имеющих в хозяйстве Windows, будут рады.

http://communities.netapp.com/groups/netapp-system-manager-20-public-beta

Ну и, понятно, вы осознаете, что это бета-версия, что компания рекомендует тестировать ее на non-production, и прочее бла-бла-бла.

Я уже упоминал этот инструмент в своей длинной и еще незаконченной серии про оптимизацию производительности систем NetApp. Правда там вкралась ошибка, perfviewer берут не в NOW, он лежит на внутреннем “партнерском” ресурсе fieldportal.netapp.com, но статус у него там свободный, а раз так, то я намерен вам его показать.

Perfviewer это java-приложение, которое запускается и берет на вход файл, сформированный скриптом perfstat, который собирает данные производительности и разнообразную статистику с работающей системы для задач поддержки. Файл из perfstat получается огромный (например пробный вывод на пять получасовых итераций получился размером в 29 мегабайт) и при этом практически нечитаемый из за своего размера. Это просто сконкатенированный последовательный вывод пары десятков команд Data ONTAP. Вот для того, чтобы распарсить этот огромный файл, и получить какую-то визуализацию  и используется PerfViewer. Текущая версия 1.5.1, не обновлялась она довольно давно, так что можно считать ее стабильной.

UPD: Как совешенно справедливо указывают мне в коментариях читатели, Perfviewer v1.5.1 давно не обновлялся, и не работает с выводом perfstat для версий 7.3.x, что очень печально, и, к сожалению, лишает эту утилиту большей части полезности на сегодня. :(

Пост все же сохраню, для истории.
Continue reading ‘Инструменты админа: Perfviewer 1.5.1’ »