about NetApp

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

У NetApp есть два способа восстанавливать данные на дисках из созданных снэпшотов, это простым копированием нужного файла из псевдо-директории .snapshots на его прежнее место, и с помощью команды snap restore. Последняя использует технологию SnapRestore, это отдельно лицензируемая, но, наверное, почти у всех имеющаяся функция, которая используется во многих продуктах NetApp, например в SnapManager for Apps.

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

Однако в использовании SnapRestore есть один, как оказалось, довольно неочевидный для новичка “факап”, как выражается современная молодежь.

Дело в том, что SnapRestore восстанавливает из снэпшота файловую систему соответствующего тома целиком, на момент создания соответствующего снэпшота. “Целиком” означает вообще целиком, совсем целиком. И набор доступных после восстановления снэпшотов для этой файловой системы – тоже.

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

Вы выбираете, например в SnapManager, или же просто вручную, снэпшот недельной давности, и делаете ему snap restore vol1 weekly.1

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

Опа. А у вас нету на томе снэпшота “три дня назад”. Том восстановился на состояние “неделя назад”, и никаких более новых, чем “неделя назад” снэпшотов на нем еще нет. Вы же помните, я не зря сказал, что восстанавливается том целиком, включая и состояние снэпшотов на нем.

Что делать: Ну, во-первых хорошо понимать то, как работает механизм снэпшота на NetApp. Не восстанавливать через snap restore том целиком, если есть необходимость оставить доступными более новые, чем точка восстановления, снэпшоты, или ради всего нескольких файлов. Наконец, пользоваться SnapVault, средством для “резервного копирования” снэпшотов на другой сторадж NetApp.

О любопытной функции внутри Data ONTAP прочитал недавно в блоге ntapgeek. Эта фича называется WAFL File Folding и позволяет экономить место на дисках для файлов, отдаваемых по протоколу CIFS.

Принцип работы File Folding таков. Как вы уже знаете (а кто не знает – идите и читайте), все перезаписи данных на WAFL осуществляются, согласно конструкции файловой системы, таким образом, что они не меняют собственно содержимого блока данных в файле, а записываются в отдельный свободный блок, куда переставляется “указатель”-inode. Это позволяет быстро и просто делать снэпшоты, так как в WAFL не нужно, как во всех прочих реалиациях снэпшотов, переносить содержимое перезаписывамых блоков в отдельное место. Единожды записанный блок, помещенный в снэпшот, уже никак не будет изменен, так устроена FS.

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

Я теряюсь в догадках, что это за операция такое проделвывает, но факт того, что это сделано именно для CIFS, подсказывает мне, что что-то в CIFS любит перезаписывать целиком файлы, даже, например, при незначительных изменениях в нем. Например, представм, что это какой-нибудь Winword, и в нем большой файл, в котором мы поправили запятую, и нажали “сохранить”. И весь этот файл, блок за блоком, перезаписался поверх теми же данными, что были (за исключением этой запятой). Не знаю, возможно кто-то подскажет, о чем тут идет речь.

Так или иначе, в результате такой перезаписи, мы будем иметь на дисках два файла, из равного набора блоков, один в снэпшоте, а один в собственно файловой системе, ведь WAFL не видит, что там такое произошло с файлом. Попросили из приложения перезаписать стотыщ блоков – вот вам стотыщ свободных блоков, пишите в них, ведь исходный файл в снэпшоте, блоки его нельзя трогать.

Вот для решения такой проблемы и предназначена малоизвестная фича, под названием WAFL File Folding.

Включают ее командой:

> options cifs.snapshot_file_folding.enable on

и эта команда делает следующее:

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

Теоретически, как и любой процесс экономии пространства, этот процесс дополнительно нагружает процессор и занимает память задачей попарного сравнения блоков. Однако, если этот процес достигает определенного для него лимита использования RAM, он приостанавливается, и ждет ее освобождения, так что в принципе страшного ничего произойти не должно.

Утверждается, что фича эта тихо живет уже довольно давно, полагаю она была добавлена по заказу какого-нибудь Особо Любимого Клиента и его специфической задачи, и не особенно раскручивается для прочих. Данная опция существует в Data ONTAP вплоть до версии 8.1 в 7-Mode.

Так что если в ващем хранилище CIFS есть сходная проблема с перезаписью, то можете попробовать, по идее это должно экономить какое-то количество пространства на дисках, при использовании снэпшотов. Помните, однако, что это займет сколько-то процессора и памяти, так что включив это обязательно проследите за поведением системы какое-то время.

UPD: из комментариев к “зеркалу” данного поста на https://communities.netapp.com/groups/netapp-ru (если вы там еще не были - сильно рекомендую сходить и ознакомиться, это форум и сообщество по NetApp, созданное мною на официальном сайте NetApp, чтобы было удобнее вести дискуссии и обсуждения, в формате форума, и так далее. Я туда также зеркалю свои посты отсюда).

“Ну именно офисные приложения word и exel и перезаписывают файлы целиком. При открытии файла на редактирование ms офис создает новый временный файл и работаем в нем, а операция сохранения это удаляем старый, копируем новый. То есть файл всегда пишется целиком. А так как на CIFS разделах делать снепшоты очень удобно (в винде встроены механизмы отслеживания версионности файлов и нет необходимости привлекать администраторов чтоб открыть любой файл из предыдущих версий) то начинает быстро “распухать” раздел по них.

Поэтому на томах доступных для CIFS где работают с офисными приложениями и снепшоты делаются по сколько раз в день, что затрудняет возможность проведения дедупликации перед ними, данная опция маст хэв :) “

По умолчанию, Data  ONTAP генерирует уведомление (trap) в SNMP, а также записывает сообщение в логах, когда заполненность тома превышает пороговую величину. По умолчанию существует два порога: “Nearly Full” и “Full”. Первый по умолчанию установлен на значение 95%, а второй – на 98% от емкости тома.

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

Для того, чтобы именить значения порогов на нужные вам, надо сделать следующее:

Войдем в режим повышенных привилегий:

netapp> priv set advanced
netapp*>

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

Установим нужные нам значения. Например, пусть это будут 85% и 99%. Помните, что баловаться с системным реестром в Data ONTAP также опасно, как и с реестром Windows!

netapp*> registry set options.thresholds.fsFull 99
netapp*> registry set options.thresholds.fsNearlyFull 85

Можно и вовсе выключить эти уведомления, задав заведомо недостижмый уровень заполнения, больше 100%, например – 101%

netapp*> registry set options.thresholds.fsFull 101
netapp*> registry set options.thresholds.fsNearlyFull 101

Обратите внимание, что парамеры fsFull и fsNearlyFull – чувствительны к регистру.

Проверим, что все установилось так, как мы хотели:

netapp*> registry walk options.thresholds

Вернемся в стандартный уровень привилегий:

netapp*> priv set
netapp>

Готово. Теперь Data ONTAP будет генерировать SNMP traps о заполнении тома по достижении заданных нами величин (или не генерировать их вовсе, если мы их установили на 101%).

Я уже упоминал, что в 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

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

Досадная недоработка в конфигураторе NetApp, не позволяющая купить FAS3210 без сконфигурированного MPHA, для которого требовалась дополнительная карта портов SAS, занимающая один из двух слотов расширения контроллера, и, например, мешавшая получить в 3210 и 10GB Ethernet и Flash Cache разом, в одной системе –  устранена.

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

Теперь нет нужды в хитрых маневрах, чтобы купить FAS3210 с 10G Ethernet и Flash Cache (по факту, весьма популярный вариант), конфигуратор исправлен, и теперь такую конфигурацию можно без проблем сконфигурировать и заказать.

Любопытную залипуху недавно пришлось разрешить. При объединении на одной системе хранения дисков, аггрегейтов и томов с нескольких других, на системе оказалось несколько томов с одинаковыми именами (ну да, на каждой был свой ‘vol0’, к примеру).

Для устранения этой проблемы Data ONTAP автоматически изменяет имена таких дублирующихся ресурсов, добавляя цифру в скобках. Однако проблема (по крайней мере в 7.x) в том, что такие авто-переименованные ресурсы нельзя переименовать вручную. Но можно переименовать исходный, который вызвал автопереименование последующих. Результат будет такой:

fas1> vol status
  Vol_data    online          raid_dp, flex     create_ucode=on
  Vol_data(1) online          raid_dp, flex     create_ucode=on
  Vol_data(2) online          raid_dp, flex     create_ucode=on
 
fas1> vol rename vol_data vol_data_orig
fas1> vol status
  Vol_data_orig  online    raid_dp, flex     create_ucode=on
  Vol_data  online          raid_dp, flex     create_ucode=on
  Vol_data(1) online          raid_dp, flex     create_ucode=on

Как вы видите, можно выкрутиться из этой ситуации переименовывая тома вручную по одному.

Лучше, конечно, в такую ситуацию не попадать, и проверять на возможность дублирования ресурсы (аггрегейты и тома) до миграции. Самым лучшим будет заранее разработать name convention, препятствующую дублированию имен ресурсов на разных стораджах, и следовать ей при развертывании.

Помощь, как всегда, была найдена в TFM  ;) – NetApp Storage Management Guide.

How you manage duplicate volume names