about NetApp

??нтересный способ был подсмотрен в соседском блоге.

В некоторых (нечастых) случаях возникает необходимость преобразовать уже существующий виртуальный диск, например файл VMDK, лежащий на NFS-шаре, в RDM LUN (RDM – raw device mapping, подключение физического LUN в VM непосредственно, как SCSI LUN-а). Есть некоторое ограниченное число случаев, когда трудно или нельзя обойтись без RDM.

Сделать это можно без необходимости копирования данных через хост и создания второй копии данных. NetApp может создать LUN с указанием файла на диске, из которого будет взято его содержимое. При этом со стороны хоста это будет самый настоящий физический SCSI LUN, и его можно будет подключить как самостоятельное физическое устройство, например с помощью установленного внутри VM OS инициатора, допустим MS Software iSCSI Initiator, как новый диск. Но при этом на стороне стораджа такой “LUN” будет просто небольшой ссылкой на данные соотвествующего vmdk, уже хранящегося на дисках.

Опция –f может указать при создании LUN файл, хранящий содержимое сотвествующего LUN-а.

lun create -f /vol/vol1/test02/test02_1-flat.vmdk -t windows_2008 /vol/vol1/lun1
создаст физически небольшой файл LUN  /vol/vol1/lun1 (тип LUN – windows_2008), указывающий на существующий .vmdk файл test02_1-flat.vmdk. В дальнейшем вы можете работать с таким “LUN”-ссылкой как с настоящим LUN-ом.

Обратите внимание, что в качестве vmdk указан именно *-flat.vmdk, большого размера.

Помните также, что после такого “преобразования” нельзя удалить этот *–flat.vmdk, так как именно в нем будет находиться физическое содержимое LUN.

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

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

Если у вас на сторадже используются SAN LUN-ы, то при замене “головы”, а если более точно, то при замене NVRAM (при замене контроллера обычно с ним также меняется и NVRAM (NVMEM), установленная внутри) у этих LUN изменится их SerialID. В ряде случаев это может озадачить использующие их хосты (например Windows Cluster изменяет при этом их signatures, и не может после поднять в онлайн). Поэтому было бы правильно, после замены контроллера, и до возвращения LUN-ов использующим их системам, вернуть им старые SerialID.

Если у вас LUN-ов всего несколько, то это можно сделать и вручную (главное не забыть). Но если их много, то встает вопрос автоматизации.

На сайте communities.netapp.com было найдено несколько вариантов такого скрипта. На Perl, на VBS, и в виде скрипта PowerShell.

Я уже рассказывал в этом блоге отчего, несмотря на то, что на хранилище NetApp вы видите LUN, то есть объект SAN-сети, как “файл”, лежащий на пространстве тома, LUN в NetApp делаются совсем НЕ через “эмуляцию поверх файловой системы”. Однако такая любопытная “оптическая иллюзия” с видимостью LUN-а как файла, часто приводит к определенным (к сожалению распространенным) ошибкам понимания, в частности к соблазну “сбэкапить” такой LUN как файл.

Так вот, обратите внимание, что из того факта, что на “зашаренном” volume вы видите LUN-ы на нем созданные как файлы, не следует, что “LUN-ы это файлы”.

Если вы, допустим, бэкапите такие LUN-ы, то бэкапить их надо ТОЛЬКО как содержимое volume, то есть от “корня”, вместе с томом, либо с qtree, если последний используется. ??наче вы потеряете при таком копировании metadata (они хранятся внутри volume), определяющие внутри NetApp LUN именно как LUN, и не сможете восстановить его на прежнее место как LUN, то есть как устройство с блочным доступом.

То есть, для бэкапа содержимого LUN, например это LUN01, лежащий на томе vol1,  недостаточно просто скопировать “файл”, лежащий по адресу //filer1/vol1/LUN01, нужно копировать целиком vol1!

Аналогична ситуация и с восстановлением. Восстанавливать надо том вместе со всеми LUN-ами на нем, а не просто отдельный “файл” LUN-а, так как, в противном случае, не будут востановлены специфические метаданные SAN-объекта.

То есть, если вы сбэкапили LUN, а затем восстановили, и не можете смонтировать его как LUN, а видите его как “просто большой файл”, то это вот тот самый случай.

Разумеется, все изложенное выше касается только “бэкапа со стороны стораджа” (например по NDMP), а не бэкапа “изнутри” OS, работающей с данным, смонтированным на нее LUN-ом, как своей файловой системой.

Еще читать: https://now.netapp.com/Knowledgebase/solutionarea.asp?id=kb37566