about NetApp

Я уже упоминал, что в Data ONTAP есть очень полезная команда stats, с помошью котрой можно вывести массу информации о работе системы. К сожалению, формат вывода ее “человеконечитаемый”, в большинстве случаев, поэтому для того, чтобы извлечь из ее вывода что-нибудь полезное, приходится предпринять некоторые усилия.

Так, например, довольно интересной задачей яляется поиск и вывод так наываемых busy spindles, или физических дисков, нагрузка по вводу-выводу на которые превышает норму по аггрегейту. Такое случается иногда при несбалансированности aggregate, например, чаще всего, при добавении дисков, которые, в ряде случаев, могут потребовать “рестрайпинга данных”.

В community.netapp.com я увидел интересную строчку для использования в скрипте вывода такой информации:

watch -n 3 "ssh NetAppHost stats show disk:\*:disk_busy | awk '{FS=\":\"; print \$1 \" \" \$2 \" \" \$3 \" \" \$13}'| sed 's/%//g' | awk '\$4>40{print}'"

Можете воспользоваться, кому интересно, и расскажите как работает.

Когда вы поставили и запустили симулятор Data ONTAP 8, вы увидите, что он идет с 28 (2х14) “дисками”, размером 1GB. Этого в общем вполне достаточно для большинства целей использования, однако, если вам потребуется больше дисков, вы можете увеличить их количество (но не размер!) до 56 штук. Обратите внимание, что вы не можете увеличить размер дисков, он для симулятора не может превышать 1GB. Ну… например чтобы не было соблазна устраивать из не предназначенного для этого симулятора бесплатный “виртуальный сторадж” ;). Как говорил один большой друг СССР – “Doverjai no proverjai!” ;)

Но сперва стоит немного остановится на некоторых деталях.

В отличие от Data ONTAP 7, в версии 8 появился специальный user-mode shell (консоль админа, несмотря на внешнюю схожесть, шеллом как таковым не является). Он доступен для специального, отключенного в целях безопасности, пользователя diaguser.

Мы рассмотрим добавление дисков только для симулятора 7-Mode. Для Cluster-mode это возможно также, но чтобы не удлиннять пост я его опущу (если кому-то понадобится процедура для Cluster-mode Simulator – напишите).

Итак, начнем с того, что разблокируем diaguser, от имени которого в шелле мы проделаем операции добавления:

priv set advanced
useradmin diaguser unlock
useradmin diaguser password

Теперь зайдем с systemshell этм пользователем:

systemshell
login: diag
password: <password>

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

cd /lib
sudo mount -u -o rw /
sudo ln -s libc.so.6 libc.so.7
sudo mount -u -o ro /

Установим переменную пути:

setenv PATH "${PATH}:/sim/bin"
echo $PATH

И перейдем в директорию эмулированных устройств

cd /sim/dev
ls ,disks/

Тут вы увидите уже созданные 28 дисков. К ним мы сейчас добавим еще 28. Имена уже существующих файлов-дисков начинаются с v1 и v2, что означает, что они “подключены” к адаптерам v1 и v2. У нас есть еще два неиспользованных адаптера (v3 и v4), к каждому из которых мы “подключим” по 14 дисков (это похоже на то, как подключаются обычные FC-полки к адаптерам отдельной FC-“петлей”, каждая полка на 14 дисков на свой адаптер).

Для этого воспользуемся утилитой makedisk.main:

makedisks.main -h
sudo makedisks.main -n 14 -t 23 -a 2
sudo makedisks.main -n 14 -t 23 -a 3
ls ,disks/

Первая команда печатает пояснение по доступным ключам. Две другие создают по 14 дисков
(-n 14) с типом диска 23 (-t 23) на адаптерах 2 и 3 (-a 2 и -a 3). Симулятор Data ONTAP 8.0.1 поддерживает конструктивно только диски размером 1GB и менее. Даже если вы видите в подсказке команды диски большего размера, воздержитесь от соблазна попробовать добавить их в симулятор. С виртуальными дисками размером больше 1GB Data ONTAP упадет в panic при перезагрузке, и вам придется устанавливать симулятор заново.

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

exit
useradmin diaguser lock
priv set admin
reboot

После перезагрузки необходимо назначить ownership новым дискам:

disk show -n
disk assign all
disk show -v

Теперь у вас в симуляторе 56 “дисков” по 1GB каждый. Они уже zeroed, и вы можете непосредственно добавить их в нужный вам aggregate.

Исходный текст был взят тут: https://communities.netapp.com/docs/DOC-9579

В ряде случаев, например когда вы планируете использовать несколько установленных симуляторов, подключенных в Operations Manager, необходимо задать каждому из этих симуляторов индивидуальный SystemID и Serial Number. В будущем в NetApp обещают генерировать при установке произвольный номер, а пока все симуляторы идут с одним. Поэтому нужно проделать небольшой трюк.

При начальной загрузке прервите ее и войдите в SIMLOADER.

Выполните там две следующие команды:

SIMLOADER> set bootarg.nvram.sysid=1111111101
SIMLOADER> set SYS_SERIAL_NUM=1111111101

SystemID это 10-значное число. Последние две цифры должны быть уникальны в пределах Cluster-mode кластера для того, чтобы обеспечить уникальность UID дисков. Таким образом первые 8 цифр определяют кластер, а последние 2 – ноду в этом кластере. Впрочем, если вы используете симулятор только как 7-mode, вам это не важно, назначьте туда любое 10-циферное число.

Дайте команду:

SIMLOADER> boot

Войдите в Boot Menu нажатием Ctrl-C и выберите там Maintenance mode boot

Переназначьте диски на новый SystemID, если вы уже назначили их ранее контроллеру на его прежний SystemID. Если вы делаете описываемую процедуру при самом первом старте, то переназначать диски еще не нужно, назначьте из обычным образом.

UPD: Приведенный метод, к сожалению, НЕ РАБОТАЕТ для Simulator версии 8.1, он работает только для 8.0.1

В предыдущей статье я показал, как поставить виртуальную машину, в виде которой сейчас идет симулятор 8.0.1 на сервер VMware ESX. А сейчас попробуем начать с ним работу.

Как я уже рассказывал в предыдущем посте, Data Ontap Simulator это виртуальная машина, в которой работает версия Data ONTAP 8 для выполнения в среде VM. Data ONTAP 8 базируется на OS FreeBSD, однако, вопреки распространенному (ошибочному) мнению, Data ONTAP 8 это НЕ FreeBSD. Это даже не программа под FreeBSD. Это самостоятельная OS, которая использует FreeBSD как загрузчик своего kernel space code, а также использует некоторые ее ресурсы, например driver model, и драйвера оборудования. Ситуация была примерно та же, что с гипервизором VMware ESX-не-i, если вы помните, там сперва грузился RedHat, под которым затем запускался как модуль собственно ESX, который уже Linux не являлся. Именно этим объясняется то, что мы в прошлой статье создали VM типа “FreeBSD 64-bit”, действительно, сперва VM загружается с использованием loader FreeBSD, а затем использует ее драйверную модель для внешних устройств.

Симулятор, как я уже рассказывал выше, это полноценная версия Data ONTAP, за некоторым исключением: установлено ограничение по поддерживаемой емкости, не работает протокол FC (но работает iSCSI) и, в настоящий момент, реализована только одноконтроллерная конфигурация. Но для экспериментов и обучения этого будет вполне достаточно.

Давайте, для начала, отключим на симуляторе Autosupport. Симулятор это экспериментальная площадка, и лучше будет не беспокоить поддержку NetApp странными сообщениями, которые будет при наших экспериментах посылать”в центр” служба Autosupport. Войдя в консоль даем команду:

options autosupport.enable off

Штатным образом Simulator приходит с набором из 28 “как-бы дисков” размером 1GB (как я уже сказал, для экспериментов этого объема достаточно). Изначально, только 3 диска назначены (assigned) контроллеру, и на них создан root volume на RAID-DP. Остальные диски помечены как unassigned. Назначим оставшиеся диски нашему симулятору:

disk assign all

Теперь добавим ключи-лицензии. Эти ключи предназначены только для симулятора, и не будут работать на физической системе. Можно установить только то, что используется на вашей продакшн-системе, или поставить дополнительные лицензии, чтобы посмотреть “что это и как работает”, или же просто все, и экспериментировать со всеми возможными фичами.

• a_sis MTVVGAF
• cifs DZDACHD
• disk_sanitization PZKEAZL
• http NAZOMKC
• flex_clone ANLEAZL
• iscsi BSLRLTG
• multistore NQBYFJJ
• nearstore_option ELNRLTG
• nfs BQOEAZL
• smdomino RKBAFSN
• smsql HNGEAZL
• snapmanagerexchange BCJEAZL
• snapmirror DFVXFJJ
• snapmirror_sync XJQIVFK
• snaprestore DNDCBQH
• snapvalidator JQAACHD
• sv_linux_pri ZYICXLC
• sv_ontap_pri PVOIVFK
• sv_ontap_sec PDXMQMI
• sv_unix_pri RQAYBFE
• sv_windows_ofm_pri ZOFNMID
• sv_windows_pri ZOPRKAM
• syncmirror_local RIQTKCL

Лицензионный ключ – это 7 заглавных букв после имени функции. Для того, чтобы ввести лицензионный ключ дайте команду:

license add XXXXXXX

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

Если же мы собираемся оставить 3 диска root vol в отдельном aggregate, то просто создавайте новый aggregate на оставшихся 25 дисках. Однако тут имеет смысле сделать небольшие изменения в опциях системы. Дело в том, что размер RAID-группы по умолчанию в Data ONTAP равен 16 дискам (а максимальный для дисков FC, SAS и виртуальных дисков симулятора – 28). Если вы создаете большой единый aggregate на всех 25 дисках, то, при установленном размере RAID-группы равной 16, он создастся так:

Сперва будет взято 16 дисков, из которых 2 будут RAID-DP parity и dparity, а остальные 14 будут data в RAID-группе rg0. Затем на оставшихся будет создана вторая RAID-группа (rg1), из оставшихся 9 дисков, которые, в свою очередь, станут двумя parity и 7 data. В дальнейшем, если в aggregate добавляются новые диски они добавляются в “неполную” RAID-группу, пока она не достигнет заданного в опциях размера в 16 дисков, а следующие создадут еще одну новую “неполную” группу.

Логично было бы, особенно на небольшом числе дисков, не полагаться на такую автоматику, а самостоятельно расчитать и создать RAID-группы, по возможности равного размера. То есть, с точки зрения порядка, аккуратности (да и производительности) вариант 12+12+1 hot spare будет лучше, чем 16+8+1hs. А в нашем случае мы поступим еще лучше, мы просто увеличим заданный размер RAID-группы до максимума (28), или, хотя бы до 25. Тогда все наши диски поместятся в одну группу. Дадим в консоли команду:

aggr options aggr1 raidsize 28

Теперь добавим оставшиеся unassigned диски в созданный aggr0

aggr add aggr1 24

Мы оставим один диск под spare, это требование Data ONTAP. Для того, чтобы в логах не валились сообщения о нехватке spares, проверьте значение опции:

options raid.min_spare_count 1

Здесь 1 – количество spare для данного контроллера. Одного будет вполне достаточно, а при количестве дисков более 16 поставить 0 система не даст.

Имеет смысл также уменьшить резерв под snapshots уровня aggregate. Что это я уже тоже писал в блоге, есл вкратце и в двух словах – это вам не надо, это для Metrocluster, синхронной репликации, и может помочь для ремонта сильно поврежденной WAFL. Если у вас этого всег нет, то можете этот резерв убрать и выключить расписание создания их.

snap reserve -A aggr1 0
snap sched -A aggr1 0

Отдельно отмечу, это ТОЛЬКО для специальных, внутренних снэпшотов уровня aggregate, на обычные и привычные пользовательские снэпшоты уровня volume и файлов это не влияет, они буду работать по-прежнему, и вы по-прежнему сможете их использовать.

Вот теперь все готово к созданию томов и экспериментам. Можете начать из консоли, или же подключить к симулятору System Manager, если вам в GUI привычнее. Симулятор, повторюсь, работает и ведет себя идентично реальной системе хранения (за вычетом FC, SnapLock и ограничения по объему хранения). К нему можно подключить любой софтовый продукт (System/Operations/Protection/Provision Manager, SnapManager, VSC), настроить на него репликацию, использовать его как получатель (secondary) или источник (primary) для SnapVault, и так далее.

В основу этого поста легла статья http://mtellin.com/2011/01/03/getting-started-with-the-netapp-ontap-8-0-1-simulator/.

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

Я уже рассказывал в этом блоге про то, что такое Data ONTAP Simulator, и чем он полезен, не только когда у вас нет “живой” системы хранения NetApp под руками, но даже, причем в большей степени, когда она у вас есть. На таком симуляторе можно упражняться “на кошечках”, можно проверять какие-то свои идеи, ставить эксперименты, отлаживать какие-то решения (не на продакшновом же сторадже это проделывать?), наконец учиться и обучать новичков.

Однако, как вы знаете, Data ONTAP 8 отличается от DOT7 довольно прилично. Была изменена платформа, на которой выполняется код собственно NetApp. В результате теперь по другому выглядит и Симулятор. Если раньше, для версии 7, это была программа под Linux, то Симулятор под Data ONTAP v8 это самостоятельный образ виртуальной машины, который можно запустить из под, например, VMware Player, или установить ее как VM в ESX.

Вот как раз этому варианту и посвящена эта статья, которую в оригинале я подсмотрел на http://mtellin.com/2010/03/12/use-ontap-8-0-7-mode-simulator-on-esx/

Continue reading ‘Как поставить Data ONTAP Simulator v8 на VMware’ »

Как вы знаете, каждый контроллер в HA-паре системы хранения NetApp владеет собственным набором дисков. Когда-то, много лет назад, еще до систем серии 3000, использовался так называемый hardware ownership, при котором привязка к контроллеру происходила “физически”, на уровне полки и петли FCAL. Начиная с 3020 в системах NetApp применяется так называмый sowtware ownership, при котором владелец диска назначается согласно WWN этого диска, и появилась возможность более гибко назначать владельца и разделять диски между контроллерами. Например, можно даже имея одну дисковую полку произвольно назначить диски из нее разным контроллерам.

Иногда же возникает задача перераспределить диски, например передать часть дисков от одного контроллера-владельца другому.

Как это сделать показывает статья в Knowledge Base

KB ID: 1011998 Version: 3.0 Published date: 01/13/2011

Описание

Приведенная процедура смены контроллера-владельца диска применима к любой системе, поддерживающей software-based ownership (на сегодняшний день все выпускаемые системы используют software-based ownership).

Процедура

В разбираемом примере, FilerA владеет spare-диском, который мы хотим передать контроллеру FilerB.

1. Получим Disk ID

FilerA> vol status -s
Spare disks
RAID Disk Device HA SHELF BAY CHAN Pool Type RPM Used (MB/blks) Phys (MB/blks)
——— —— ————- —- —- —- —– ————– ————–
Spare disks for block or zoned checksum traditional volumes or aggregates
spare 0b.22 0b 1 6 FC:B - FCAL 10000 68000/139264000 69536/142410400

2. Перейдем в режим повышенных привилегий (advanced mode)

FilerA*> priv set advanced
Warning: These advanced commands are potentially dangerous; use them only when directed to do so by NetApp personnel.

3. Удалим текущего владельца диска

FilerA*> disk remove_ownership 0b.22
Volumes must be taken offline. Are all impacted volumes offline(y/n)?? yes
FilerA*> Sat Jan 14 17:46:42 GMT [FilerA: raid.config.spare.disk.missing:info]: Spare Disk 0b.22 Shelf 1 Bay 6 [NETAPP X272_HJURE073F10 NA14] S/N [xxxxxx] is missing.

Внимание:

• Команду disk remove_ownership можно дать сразу на группу дисков, разделив их имена пробелами, disk remove_ownership 6c.64 6c.65 6c.66 снимет владельца со всех перечисленных дисков.
• В случае систем серии 30×0, проверьте установку опции options disk.auto_assign. Если она установлена в on, то когда вы снимете владельца с дисков, система автоматически назначит их назад. По этой причине убедитесь, что перед началом операции эта опция установлена в off. Можно ее включить назад, после передачи диска контроллеру.
• Сообщение volumes must be taken offline это предохранительная мера, вы должны подтвердить, что не удаляете диск с данными из активного тома/aggregate. В данном примере мы перемещаем spare-диск, а не диск, уже назначенный в RAID.

4. Подключаемся к контроллеру FilerB и переходим в advanced mode

FilerB*> priv set advanced
Warning: These advanced commands are potentially dangerous; use
them only when directed to do so by NetApp
personnel.

5. Назначаем нового владельца

FilerB*> disk assign 0b.22
Sat Jan 14 17:47:32 GMT [FilerB: diskown.changingOwner:info]: changing ownership for disk 0b.22 (S/N xxxxxx) from unowned (ID -1) to FilerB (ID xxxxxx)

6. Проверяем, что диск теперь spare у нового контроллера

FilerB*> vol status -s
Spare disks
RAID Disk Device HA SHELF BAY CHAN Pool Type RPM Used (MB/blks) Phys (MB/blks)
——— —— ————- —- —- —- —– ————– ————–
Spare disks for block or zoned checksum traditional volumes or aggregates
spare 0b.22 0b 1 8 FC:B - FCAL 10000 68000/139264000 69536/142410400

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

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

Как вы знаете, все действующие в настоящее время 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.

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

Я уже писал в этом блоге о такой любопытной штуке в системах 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’ »