Archive for the ‘howto’ Category.

Read-Only юзер для System Manager и PowerShell Toolkit

??ногда бывает нужно создать пользователя, не имеющего на системе хранения других прав, кроме read-only, например для задач демонстрации и обучения, только для получения каких-то данных или снятия показаний, или же иных подобных применений. Сделать такого пользователя можно с помощью механизма RBAC – Role-Based Access Control (кстати по RBAC в техбиблиотеке Netwell лежит дельная переведенная документация).

Пример  создания роли read-only user при помощи DataONTAP Powershell Toolkit.


#Create read-only role:
New-NaRole ro_role -Capabilities  login-*
#Add read-only capabilities to this from attached file:
$caps = Get-Content .\RoRoles.txt
ForEach ($cap in $caps)
{
  Set-NaRole ro_role -AddCapabilities  $cap
}
#Create read-only group:
New-NaGroup ro_group ro_role
#Create read-only user:
New-NaUser ro_user rouserpassword ro_group

 

Файл RoRoles.txt со списком вызовов API DataONTAP можно скачать тут.

SAN boot

Я обратил внимание, что очень многие, в особенности впервые сталкивающиеся с SAN, обязательно хотят реализовать у себя возможность бездисковой загрузки серверов из SAN, с созданного в ней LUN-а. Но потом как-то охладевают к этой идее, по причине ряда сложностей реализации и неочевидности преимуществ. Действительно, если у вас blade-ферма на три десятка blades в ней, то экономия на жестких дисках по ценам изготовителя blades, может вылиться в экономию, за которую можно пострадать, но при всего 2-4 серверах в SAN это обычно не стоит выделки. Однако если вы все же решили заняться SAN boot, то вот какие полезные сведения я обнаружил в блоге группы поддержки решений Microsoft, сформированной в NetApp.

Во-первых, следует знать, что на сегодняшний день загрузка из SAN для актуальных OS Microsoft полностью поддерживаемое решение. См. статью из Knowledge Base.

Во-вторых, следует помнить, что проблемы с зонингом – есть “номер один” всех проблем с SAN boot. Если у вас что-то не работает – начните с проверки зонинга. Чаще всего разрешение проблемной ситуации с зонингом и есть решение проблемы загрузки из SAN. Если ваша система на поддержке – обратитесь в поддержку NetApp, они “знают много гитик”. Проверяйте и перепроверяйте все настройки зонинга ДО того, как начнете долбить поддержку.

Третий момент, который стоит помнить, это то, что поддержка MS MPIO на этапе загрузки крайне ограничена. ??спользуемый в MS на этапе инсталляции WinPE (Windows Preinstall Environment) не рассчитан на работу с MPIO, и подключение LUN по нескольким путям может давать непредсказуемые результаты. При первой загрузке этапа установки, инсталлятор Windows загружает модуль boot.wim (это и есть WinPE) и начинает копирование файлов из дистрибутива в “локальный диск”, который в вашем случае будет SAN LUN-ом. После копирования загрузится уже собственно Windows. Поддержка рекомендует на время работы WinPE физически отключать второй путь, который можно будет подключить назад позже, когда у вас уже будет работающий MPIO.

Также стоит помнить, что MPIO не поддерживается в sysprep. Вам придется настроить MPIO непосредственно на том образе, с которого будут грузиться система, но официально не поддерживается его конфигурирование непосредственно в syspreped образе. Оно работает, как показывает опыт. Но не поддерживается MS. Be warned, есличо.

MPIO, несмотря на написанное выше, настоятельно рекомендуется для загрузки SAN boot! Если в момент загрузки вы потеряете связь с SAN LUN, с которого система загружается, она упадет в BSOD Inacessible boot device. Смотрите по этому поводу статью в TechNet.

Для того, чтобы LUN в SAN был увиден системой на этапе инсталляции, он должен быть подключен из BIOS карты HBA. Это поддерживается для “аппаратных” HBA FC (FCoE), а также для hardware HBA iSCSI. Теоретически есть методы загрузки из SAN и для Software iSCSI, но рассмотрение этой темы выходит за рамки данной статьи.

Напомню еще раз, что, для двухпортовых карт, вы должны активировать поддержку загрузки в BIOS только для одного из двух имеющихся портов HBA! Реализация отличается в зависимости от вендора HBA, так что внимательно проследите эту тему самостоятельно по документации. На этапе загрузки не работает MPIO, и LUN должен видеться только по одному пути!

Если после всего перечисленного выше, инсталлятор по прежнему не видит диск, на который он может установить OS, то, скорее всего, в дистрибутиве проблема с драйверами для данного типа HBA. Можно попробовать вставить правильные драйвера непосредственно в инсталлятор, в модули boot.wim и install.wim, либо подставьте драйвера вручную, когда это запрашивает инсталлятор. Опять же тема интеграции драйверов в дистрибутив Windows достаточно хорошо рассмотрена в интернете.

Помните, что если вы вынули CD/DVD-диск, чтобы вставить на его место диск с драйверами, то не забудьте вернуть назад диск с дистрибутивом для продолжения установки. :)

Обратите внимание, что в Windows Host Utilities Installation and Setup Guide со страницы 95 идет очень детальное и подробное описание настройки SAN Boot.

Для практической проверки и отработки решения группа построила стенд из 22 серверов Fujitsu RX200, снабженных двухпортовыми FCoE HBA Brocade 1020, включенных в два коммутатора Brocade 8000 FCoE, куда также подключены два контроллера FAS6030 с дисками. HBA обладают возможностью загрузки из SAN в их BIOS, а сервера имеют средства управления Fujitsu iRMS (аналог HP iLO и DELL DRAC). Система хранения NetApp имеет активированную лицензию FlexClone, используемую в дальнейшем процессе. В принципе, описываемые процессы могут быть реализованы и без FlexClone, но с ним они куда эффективнее расходуют пространство хранения, так как место на диске занимают только изменения относительно мастер-LUNа.

Начнем с создания пустого volume и на нем LUN-а, который будет мастер-образом. Смонтируем данный LUN на один из серверов, заполним и сконфигурируем его, а позже склонируем для остальных серверов. Не забудьте установить в этот образ OS все нужные роли, драйвера и приложения, в данном случае были установлены NetApp DSM, Host Utilities, а также драйвера и приложение управления HBA от Brocade.

Запустим sysprep с опциями –generalize и –shutdown, после чего сервер отключится и LUN необходимо отмапить от сервера. Эталонный мастер-образ подготовлен.

Теперь подготовим остальные сервера на загрузку из SAN. Помните, что в BIOS HBA необходимо включить загрузку с SAN LUN только для одного порта! Смотрите ссылку на документ Boot from SAN in Windows Server 2003 and Windows Server 2008 из MS Download Center.

В имеющемся HBA в BIOS была выбрана опция загрузки “First visible LUN” (эти настройки могут отличаться для разных HBA, решайте по аналогии) с тем чтобы обеспечить наиболее простую загрузку, которая не потребует в дальнейшем перенастройки при изменениях, как в случае опции “Preferred LUN”. Вариант First visible LUN, разумеется, требует некоторых предосторожностей, например дисковый массив с загрузочным LUN должен располагаться в ближайшей к серверам фабрике, чтобы минимизировать задержки, а также иметь LUN ID 0.

Создаем клон тома мастер-образа, например с помощью FlexClone. Маппим LUN в клоне тома (не оригинальный мастер-образ, а клон!) на сервер. Включаем сервер с использованием iRMC и подключаемся к серверной консоли.

Сервер загружается и запускается mini-setup после sysprep. В нем вы можете задать пароль, изменить имя сервера, назначить IP-адрес, и так далее (если вы знакомы с развертыванием образов Windows с использованием sysprep, это не должно быть неожиданностью). После завершения mini-setup вы получаете созданную из мастер-образа индивидуальную копию установки Windows.

??так, мы за несколько минут получили полностью загруженный в индивидуальный образ Windows физический сервер, загружаемый из SAN.

Немного иначе происходит процесс для загрузки виртуальных серверов из SAN.

В случае pass-through disks Hyper-V все происходит также, как и в случае физического сервера, но нужно создать для VM еще один клон, и назначить ему LUN ID отличный от 0, чтобы он не пересекся с LUN, используемым для загрузки физического сервера. ??спользуя LUN FlexClone вы можете создать клоны мастер-LUN непосредственно на том же volume, где он сам и находится. Следите, чтобы на volume либо было достаточно места для записи хранимых “разностных” изменений, или чтобы была активирована опция “volume autogrow” и места было достаточно уже на aggregate этого тома. Если вам понадобится создать больше VM, просто создайте еще несколько клонов мастер-LUN.

В случае использования VHD, следует создать LUN для физического сервера, содержащий файлы VHD для находящихся на нем виртуальных. Также можно использовать возможности sub-LUN клонирования FlexClone, создав один клон LUN-а с множеством клонов VHD в нем.

Преимущества SAN boot, кроме экономии на локальных дисках, это, безусловно, большая гибкость. Особенно это полезно в условиях тестового стенда, когда развертывание из чистого эталонного образа занимает всего несколько минут, а если вам понадобилось вернуть предшествующую конфигурацию, например для продолжения работ по предыдущей теме, вы просто маппите ранее созданный и оставшийся на сторадже LUN и загружаетесь в предыдущую установку, без необходимости восстанавливать ее из бэкапа, как в “традиционном” варианте с локальными дисками.

??спользование же FlexClone в данном случае поможет значительно сократить занятый объем. Например, в описываемом случае, около 50 LUN-ов разлчных проектов данного стенда имеют совокупную емкость около 5TB, занимая при этом на диске всего около 300GB.

Обновление timezone на системах хранения NetApp

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

Как вы знаете, все действующие в настоящее время OS умеют автоматически осуществлять переход  и производить соответствующий сдвиг времени, в какой бы стране они ни были установлены (конечно, если правильно эта страна для OS указана). Средство, которое позволяет OS правильно, и в соответствии с национальными правилами (часто разными в разных странах), провести эту корректировку времени – это составляемая  Американской Национальной Лабораторией Времени (NIST) специальная база данных в файлах, которую производители OS, будь то Linux или Windows, распространяют с регулярными апдейтами.

Но как быть с такими OS, как Data ONTAP? Ведь от правильной установки времени, например, зависит работа механизма аутентификации Kerberos, и при несовпадении локального времени сервера или NAS-стораджа и контроллера домена, пользователи не смогут получить доступ к данным (их сессионные тикеты системы аутентификации Kerberos “испортятся”, например для домена Windows допустимо временное смещение для членов домена не более 15 минут).

Если вы обновляете Data ONTAP регулярно, то новое содержимое timezone у вас придет с новой версией. Если же нет – нужно записать свежий timezone, на место старого, в вашей текущей версии.

По этому поводу в Knowledge Base у NetApp есть соответствующая статья, вот вам ее сокращенный перевод.
(Я не стал переводить части, относящиеся к NetCache, VTL, а также 8.0 Cluster-mode системам).

How to update timezone information on NetApp appliances

KB ID: 1011616 Version: 3.0 Published date: 08/02/2011

Эта статья рассматривает следующие темы:

  • Обновление информации timezone на Data ONTAP 7G / 7-Mode
    • Версии Data ONTAP, на которые распространяется эта информация
    • Скачивание и обновление файлов timezone
    • Установка новых значений timezone

[опущены разделы о NetCache, 8.0 Cluster-mode и пр.]

На какие версии Data ONTAP распространяется эта информация:

Все версии Data ONTAP подвержены изменениям правил в  timezone. Эти правила определяют, когда и каким образом происходит переключение локального Daylight Savings Time, а также прекращается такое переключение и производится возврат к Standard Time.

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

Скачивание и обновление файлов timezone:
Файлы timezone, которые поставляет в составе Data ONTAP компания NetApp, берутся из репозитория NIST (ftp://elsie.nci.nih.gov/pub/) , а затем компилируются и помещаются как zip, tar или в виде обычных файлов. NetApp отслеживает изменения в репозитори и автоматически получает самую свежую версию файлов, размещаемую на сайте NOW (NetApp Support).

Процесс скачивания файла на компьютер администратора под Windows/UNIX и распаковка его на систему хранения

С компьютера под управлением UNIX, с использованием NFS для подключения к  root volume:

Complete the following steps to extract the ontap_zoneinfo.tar file from a UNIX admin host to the storage system’s /etc directory:

  1. Войдите на сайт NetApp Support.
  2. Скачайте и запишите на локальный диск свежую версию файла ontap_zoneinfo.zip (щелкните по ссылке ниже и выберите Save as… или Записать файл как…:
    http://now.netapp.com/NOW/download/tools/ontap_timezone/current_version/ontap_zoneinfo.zip
    Если вы по какой-то причине не можете скачать его оттуда, то версия на момент написания этого перевода лежит тут (обратите внимание! Эта версия не обновляется, и действительна для октября 2011 года!).
  3. Введите следующие команды:
    unix> mount   <filername:/vol/ROOTVOLUME>   /MOUNTPOINT
    Внимание: Если вы получили в ответ на команду сообщение RPC error, это означает, что система хранения не имеет экспорта для root voume. Если вы получаете RPC error, войдите на систему хранения как root, и выполните следующую команду:
    exportfs -i -o /
    Затем повторите команду монтирования.
  4. Введите команду:
    unix> cd MOUNTPOINT/>etc
  5. Введите команду:
    unix> gunzip PATHTOZONEFILE>/ontap_zoneinfo.zip
  6. Введите команду:
    unix> cd /
  7. Введите команду:
    unix> umount MOUNTPOINT>
  8. Проведите инициализацию новых установок и правил нового timezone.

С компьютера под управлением Windows, с использованием CIFS для подключения к root volume:

Выполните следующие шаги, для того, чтобы распаковать ontap_zoneinfo.zip в сетевую папку ETC$ на системе хранения:

  1. Войдите на сайт NetApp Support.
  2. Скачайте и запишите на локальный диск свежую версию файла ontap_zoneinfo.zip (щелкните по ссылке ниже и выберите Save as… или Записать файл как…:
    http://now.netapp.com/NOW/download/tools/ontap_timezone/current_version/ontap_zoneinfo.zip
  3. Подключите сетевой ресурс (share) ETC$ с системы хранения как сетевой диск на букву диска T: на админском компьютере.
    Внимание: Выбор имен диска T: приведен для примера. ??спользуйте любую доступную букву.
  4. Распакуйте содержимое файла ontap_zoneinfo.zip на диск T: .
  5. Проведите инициализацию новых установок и правил нового timezone.

??нициализация новых установок и правил timezone

ВАЖНО: Обязательно выполните приведенные шаги для успешного обновления информации timezone!

Для загрузки новых установок timezone, исполните следующие команды:

  1. Введите команду:
    filer> timezone
    Current time zone is Location/YourTimezone     <— введите текст, который будет выведен на месте выделенного курсивом на следующем шаге.
  2. Введите команду:
    filer> timezone Location/YourTimezone 

(например: filer> timezone Europe/Moscow)

Система хранения НЕ ТРЕБУЕТ перезагрузки для обновления и установки новых значений правил timezone.

Внимание: НЕ ПЕРЕСТАВЛЯЙТЕ ВРЕМЯ НА С??СТЕМЕ ХРАНЕН??Я ВРУЧНУЮ ВПЕРЕД ?? НАЗАД. Это не является правильным способом проверить новые изменения DST (Daylight Saving Time). Если вы так сделаете, не будут работать расписания создания снэпшотов, пока система не будет перезагружена. Такое поведение документировано в баге BUG 234237 (в настоящий момент считается fixed на всех актуальных версиях Data ONTAP. прим romx).

??нженеры NetApp проверили и подтвердили, что процедура, описанная в данной статье, успешно решает задачу изменения установок и правил DST.

Multistore и использование vFiler

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

Я уже писал в этом блоге о такой любопытной штуке в системах NetApp, как так называемый Multistore, или возможности создать в одном “физическом” файлере множество “логических”, виртуальных, так называемых vFilers. Хотя эта опция существует аж с 2002 года, она все еще, как я заметил, не слишком популярна и даже не слишком известна.

В двух словах, Multistore (можете также посмотреть мою заметку о нем ранее) это способ создать “виртуальные мини-нетаппы” внутри физического, которые будут почти полностью такие же, как и физические, за исключением отсутствия в них протокола FC, но с наличием iSCSI, NFS, CIFS и так далее, если они лицензированы на “большом” нетаппе.

Такие “виртуальные файлеры” можно применять, например, при необходимости разделять данные по зонам безопасности (secure multi-tenant). Например на одной системе хранения могут располагаться виртуальные файлеры с данными внутренней сети, и “внешние”, например для DMZ или данными внешнего вебсайта, или же между разным клиентами, использующими один сторадж (что полезно, например, при построении “облака”). ??золяция между такими виртуальными файлерами достаточно безопасна для такого использования и независимый аудит безопасности показал отсутствие проблем с безопасностью и изоляцией данных. vFiler также может располагаться в своем собственном IP space, то есть независимо маршрутизируемом пространстве, и даже на отдельном физическом интерфейсе.

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

Наконец, как я также уже немного рассказывал ранее, с помощью vFilers можно использовать сравнительно новую возможность, под названием NetApp Data Motion.

Data Motion это возможность делать с виртуальными системами хранения vFiler то же, что VMware делает с виртуальными машинами при VMotion, то есть не прерывая их работы мигрировать их с одного физического контроллера на другой. Эта возможность работает для любых приложений, использующих сторадж NetApp с Data Motion, не обязательно для виртуальных машин, например. Также обратите внимание, что при такой миграции мигрируют, например, и отношения репликации. То есть если у вас мигрируемый vFiler располагался на контроллере fas1, и реплицировал через SnapMirror свои данные в резервный датацентр на контроллер drnetapp, а потом был мигрирован с помощью Data Motion на контроллер fas2, например чтобы снизить нагрузку на загруженный fas1 и сбалансировать ее на недогруженный fas2, то его данные по прежнему будут, без вмешательства администратора и перенастройки, реплицироваться на drnetapp уже с контроллера fas2.

Но для того, чтобы всем этим воспользоваться, надо, во-первых, vFiler-ы создать.
Continue reading ‘Multistore и использование vFiler’ »

Выравнивание партиций виртуальных машин с помощью MBRscan/MBRalign

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

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

Самый удобный вариант – организовать подключение по 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.

putty-listing

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

putty-gen

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

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

putty-keygened-pic

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

key in-line

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

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 Storage Pools – как это работает “под крышкой”.

Продолжаю свои изыскания в теме технологий 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 (и что с ним делать)?

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

Multi-path High Availaility (MPHA) FAQ

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

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

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

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

Перенос root volume

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