Volume rehost
Хотел рассказать про новую функцию volume rehost, которая появилась в ONTAP 9, но за меня это отлично сделал Justin Parisi. Поэтому мне осталось всего лишь перевести его пост.
Но для начала я бы хотел напомнить, что такое Storage Virtual Machine (SVM). Потому что часто сталкиваюсь с тем, что даже у опытных пользователей NetApp отсутствует четкое понимание. Чего уж говорить о новичках.
Итак, SVM, которые раньше назывались Vservers, появились в кластерной версии Data ONTAP. По-простому, это виртуальная СХД. Но не у всех есть понимание какие ресурсы кластера явлются общими, а какие привязаны к SVM.
Все ресурсы кластера грубо можно разделить на физические:
- controller или node, которые объединяются в HA-пару
- disks и RAID-group
- aggregates
- network ports, как Ethernet, так и FC
И логические:
- FlexVol (тома)
- LUN
- qtree
- files
- igroup
- LIF (logical interface)
- namespace
- exports и shares
- и т. д.
Так вот SVM это виртуальная система хранения, которая объединяет в себе логические ресурсы и реализует доступ к данным по одному или нескольким доступным нам протоколам. Эти логические ресурсы не привязаны жёстко к физическим ресурсам. Можно переносить тома с агрегата на агрегат. Агрегаты при этом могут принадлежать разным контроллерам и HA-парам. LIF могут мигрировать с одного физического порта на другой, и также не привязаны к нодам (исключение с SAN LIF, они не мигрируют). В кластере может существовать больше одной SVM. И они спокойно могут размещать свои логические ресурсы на одних и тех же физических ресурсах. Каждая SVM изолирована от другой. У каждой SVM свой администратор и ими можно управлять независимо.
——
В Clustered Data ONTAP (теперь уже NetApp ONTAP) применяются виртуализированные контейнеры хранения, называемые Storage Virtual Machine (SVM). Они обеспечивают безопасную изоляцию в многопользовательских средах.
Каждая SVM владеет объектами вроде сетевых интерфейсов, FlexVol и выступает в качестве отдельной системы хранения поверх кластера из контроллеров и дисковых полок. В предыдущих версиях ONTAP тома были жёстко привязаны к SVM и перенос их на другую SVM в кластере был не так прост. Необходимо было использовать SnapMirror для репликации тома или скопировать данные другим способом. Процесс занимал время, был неэффективным и клиенты долгое время просили добавить возможность простой миграции томов между SVM.
Эта функциональность в ограниченном варианте была доступна в Data ONTAP 8.3.2 для использования во время миграции с 7-mode при помощи Copy-Free Transition.
Но теперь в ONTAP 9 мы можем перемещать тома между SVM без фактического копирования данных.
Как это работает?
Каждая SVM имеет уникальный идентификатор — UUID. Для того, чтобы узнать его необходимо выполнить следующую команду в advanced режиме:
ontap9-tme-8040::*> vserver show -vserver parisi,SVM1 -fields uuid
vserver uuid
------- ------------------------------------
SVM1 05e7ab78-2d84-11e6-a796-00a098696ec7
parisi 103879e8-2d84-11e6-a796-00a098696ec7
2 entries were displayed.
Когда том находится во владении SVM, то он ассоциируется с UUID SVM. И для него имеется специальный файл-хендлер, связанный с root namespace SVM.
В прошлых версиях ONTAP вы могли пренести том “руками”, если вы знаете секретную последовательность команд и у вас хватит на это смелости. Теперь же команда volume rehost автоматизирует весь этот процесс. Нет необходимости самостоятельно править кластерные базы и проверять, что нигде не напортачили.
К делу!
Теперь посмотрим как эта команда работает на практике. Ниже вывод man из ONTAP 9. Но имейте в виду, что использовалась предварительная версия “девятки” и в релизе вывод мог ненмого поменяться.
ontap9-tme-8040::*> man volume rehost
volume rehost Data ONTAP 9.0 volume rehost
NAME
volume rehost -- Rehost a volume from one Vserver into another Vserver
AVAILABILITY
This command is available to cluster administrators at the admin privilege
level.
DESCRIPTION
The volume rehost command rehosts a volume from source Vserver onto desti-
nation Vserver. The volume name must be unique among the other volumes on
the destination Vserver.
PARAMETERS
-vserver <vserver name> - Source Vserver name
This specifies the Vserver on which the volume is located.
-volume <volume name> - Target volume name
This specifies the volume that is to be rehosted.
-destination-vserver <vserver name> - Destination Vserver name
This specifies the destination Vserver where the volume must be
located post rehost operation.
{ [-force-unmap-luns {true|false}] - Unmap LUNs in volume
This specifies whether the rehost operation should unmap LUNs
present on volume. The default setting is false (the rehost opera-
tion shall not unmap LUNs). When set to true, the command will unmap
all mapped LUNs on the volume.
| [-auto-remap-luns {true|false}] } - Automatic Remap of LUNs
This specifies whether the rehost operation should perform LUN map-
ping operation at the destination Vserver for the LUNs mapped on the
volume at the source Vserver. The default setting is false (the
rehost operation shall not map LUNs at the destination Vserver).
When set to true, at the destination Vserver the command will create
initiators groups along with the initiators (if present) with same
name as that of source Vserver. Then the LUNs on the volume are
mapped to initiator groups at the destination Vserver as mapped in
source Vserver.
Том, который будет “менять” SVM называется “move_me” и принадлежит SVM1.
ontap9-tme-8040::*> volume show -vserver SVM1 -fields msid,dsid,uuid,vserver -volume move_me
vserver volume dsid msid uuid
------- ------- ---- ---------- ------------------------------------
SVM1 move_me 1027 2163225631 cc691049-2d84-11e6-a796-00a098696ec7
Чтобы перенести этот том, просто вводим команду:
ontap9-tme-8040::*> volume rehost -vserver SVM1 -volume move_me -destination-vserver parisi
После запуска команды появляется предупреждение:
Warning: Rehosting a volume from one Vserver to another Vserver does not
change the security information on that volume.
If the security domains of the Vservers are not identical, unwanted
access might be permitted, and desired access might be denied. An
attempt to rehost a volume will disassociate the volume from all
volume policies and policy rules. The volume must be reconfigured
after a successful or unsuccessful rehost operation.
В общем, предупреждают, что, если на другой SVM используются отличные от первой настройки AD или LDAP, то могут быть проблемы с доступом к тому. (Vserever это то же самое, что и SVM).
Через несколько секунд получаем результат:
[Job 42] Job succeeded: Successful
Info: Volume is successfully rehosted on the target Vserver.
Set the desired volume configuration - such as the export policy and QoS policy - on the target Vserver.
Проверяем том. Он не принадлежит старой SVM:
ontap9-tme-8040::*> volume show -vserver SVM1 -fields msid,dsid,uuid,vserver -volume move_me
There are no entries matching your query.
Теперь том в новой SVM:
ontap9-tme-8040::*> volume show -vserver parisi -fields msid,dsid,uuid,vserver -volume move_me
vserver volume dsid msid uuid
------- ------- ---- ---------- ------------------------------------
parisi move_me 1028 2163225632 cc691049-2d84-11e6-a796-00a098696ec7
Другая SVM. Другие MSID/DSID. Тот же UUID для тома (это UUID именно тома, а не SVM, поэтому он не меняется). Для файлового доступа достаточно перемонтировать том, так как поменлся IP-адресс и хендлер.
Для LUNов можно использовать следующие флаги:
{ [-force-unmap-luns {true|false}] - Unmap LUNs in volume
This specifies whether the rehost operation should unmap LUNs
present on volume. The default setting is false (the rehost opera-
tion shall not unmap LUNs). When set to true, the command will unmap
all mapped LUNs on the volume.
| [-auto-remap-luns {true|false}] } - Automatic Remap of LUNs
This specifies whether the rehost operation should perform LUN map-
ping operation at the destination Vserver for the LUNs mapped on the
volume at the source Vserver. The default setting is false (the
rehost operation shall not map LUNs at the destination Vserver).
When set to true, at the destination Vserver the command will create
initiators groups along with the initiators (if present) with same
name as that of source Vserver. Then the LUNs on the volume are
mapped to initiator groups at the destination Vserver as mapped in
source Vserver.
А что с FlexClones?
Тома могут иметь клоны (FlexClone). FlexClone — это копия тома, доступная на запись и чтение, котрая создана на основе снепшота, и не занимающая места пока в этот клон не начнут вносить изменения.
Что будет, если попытаться перенести том, у кторого есть клон, из одной SVM в другую?
Для начала создаём клон:
ontap9-tme-8040::*> volume clone create -vserver parisi -flexclone clone -type RW -parent-vserver parisi -parent-volume move_me -junction-active true -foreground true
[Job 43] Job succeeded: Successful
А потом узнаём, что rehost для томов с клонами пока не работает:
ontap9-tme-8040::*> vol rehost -vserver parisi -volume move_me -destination-vserver SVM1 -force-unmap-luns false -allow-native-volumes false
Error: command failed: Cannot rehost volume "move_me" on Vserver "parisi"
because the volume is a parent of a clone volume.
ontap9-tme-8040::*> vol rehost -vserver parisi -volume clone -destination-vserver SVM1 -force-unmap-luns false -allow-native-volumes false
Error: command failed: Cannot rehost volume "clone" on Vserver "parisi"
because the volume is a clone volume.
Вот и все для начала.
——