![[Amazon FSx for NetApp ONTAP] ボリュームを別SVMにリホストしてみた](https://devio2023-media.developers.io/wp-content/uploads/2022/08/amazon-fsx-for-netapp-ontap.png)
[Amazon FSx for NetApp ONTAP] ボリュームを別SVMにリホストしてみた
リホストをするときは注意事項をよく確認してリホスト前後の設定を照らし合わせよう
別のSVMにボリュームを移動させたいな
こんにちは、のんピ(@non____97)です。
皆さんは「Amazon FSx for NetApp ONTAP(以降FSx for ONTAP)のボリュームを別のSVMにリホストしたいな」と思ったことはありますか? 私はあります。
同じFSx for ONTAPファイルシステムに本番用SVMと検証用SVMがあり、検証用SVMで加工したデータをボリュームごと本番用SVMに持っていきたいみたいなこともあると思います。
NetApp公式ドキュメントを眺めているとボリュームを別SVMにリホストする機能がONTAPにあることが分かりました。
一般的にデータの移行であればSnapMirrorやDataSyncを使うと思いますが、設定するのが少し手間です。一方リホストであればボリュームごと移行することができるので、リホスト元のSVMからボリュームがなくなっても良いのであれば選択肢になるのかなと思います。
試してみたので紹介します。
いきなりまとめ
- リホスト時にはボリュームへのアクセスを停止する必要がある
- リホスト前にSVMからアンマウントする必要がある
- リホストを行うとエクスポートポリシーやスナップショットポリシーなど一部設定が失われる
- リホスト後に再設定してあげる必要がある
注意事項の確認
リホストにはいくつか注意事項があります。
注意事項はSMB、NFS、iSCSIとボリュームにアクセスするプロトコルによって異なります。
- 共通
- ボリュームはオンラインである必要がある
- ボリュームの移動や LUN の移動など、ボリューム管理操作を実行してはならない
- リホストするボリュームへのデータアクセスを停止する必要がある
- SMBとNFS
- リホストするボリュームのデータアクセスをサポートするようにターゲット SVM の ns-switch とネームサービスを設定する必要がある
- ボリュームのユーザ ID とグループ ID をターゲット SVM で使用可能であるか、またはホストするボリュームを変更する必要がある
- ローカルユーザとローカルグループが設定されていて、それらのユーザまたはグループに対して権限が設定されたボリューム上にファイルとディレクトリがある場合、それらの権限は無効になる
- SMB
- ソース SVM とデスティネーション SVM の Active Directory ドメインと DNS ドメインが同じであることが必要
- ソース SVM とデスティネーション SVM の Active Directory ドメインが異なる場合は、ボリューム上のオブジェクトへのアクセスが失われる可能性がある
- ソース SVM にローカルユーザとローカルグループが含まれている場合、ファイルとディレクトリに対して設定された権限（ ACL ）はボリュームのリホスト処理後に無効になる。監査 ACL （ SACL ）についても同様
- iSCSI
- ボリュームまたは LUN にアクティブな I/O がないこと
- デスティネーション SVM に同じ名前でイニシエータが異なる igroup がないことを確認しておく必要がある
- igroup の名前が同じ場合は、どちらか（ソースまたはデスティネーション）の SVM で igroup の名前を変更する必要がある
- force-unmap-luns オプションを有効にしておく必要がある
リホスト時に引き継がれない情報は以下の通りです。
- 共通
- ウィルス対策ポリシー
- ボリューム効率化ポリシー
- Quality of Service （QoS）ポリシー
- スナップショットポリシー
- ns-switch とネームサービスの設定のエクスポートポリシーとルール
- ユーザ ID とグループ ID
- SMBとNFS
- ボリュームと qtree のエクスポートポリシー
参考 :
ボリュームへのアクセスを停止する必要がある & 設定が一部引き継がれないというのがポイントですね。リホストは基本的にワークロードが稼働していないメンテナンス期間に実施する方が良さそうです。
検証環境
検証環境は以下記事のものを流用します。
SVMはSVM1とSVM2の2つを用意しました。こちらのSVM間でボリュームをリホスト(再割り当て)します。
$ aws fsx describe-storage-virtual-machines
{
"StorageVirtualMachines": [
{
"ActiveDirectoryConfiguration": {
"NetBiosName": "SVM1",
"SelfManagedActiveDirectoryConfiguration": {
"DomainName": "CORP.NON-97.NET",
"OrganizationalUnitDistinguishedName": "OU=FSxForONTAP,DC=corp,DC=non-97,DC=net",
"UserName": "FSxServiceAccount",
"DnsIps": [
"10.0.1.10"
]
}
},
"CreationTime": "2022-12-17T02:35:55.509000+00:00",
"Endpoints": {
"Iscsi": {
"DNSName": "iscsi.svm-0b0149bf226af89a4.fs-01f8ffb4adbf236d1.fsx.us-east-1.amazonaws.com",
"IpAddresses": [
"10.0.1.100",
"10.0.1.69"
]
},
"Management": {
"DNSName": "svm-0b0149bf226af89a4.fs-01f8ffb4adbf236d1.fsx.us-east-1.amazonaws.com",
"IpAddresses": [
"10.0.1.119"
]
},
"Nfs": {
"DNSName": "svm-0b0149bf226af89a4.fs-01f8ffb4adbf236d1.fsx.us-east-1.amazonaws.com",
"IpAddresses": [
"10.0.1.119"
]
},
"Smb": {
"DNSName": "SVM1.CORP.NON-97.NET",
"IpAddresses": [
"10.0.1.119"
]
}
},
"FileSystemId": "fs-01f8ffb4adbf236d1",
"Lifecycle": "CREATED",
"Name": "SVM1",
"ResourceARN": "arn:aws:fsx:us-east-1:<AWSアカウントID>:storage-virtual-machine/fs-01f8ffb4adbf236d1/svm-0b0149bf226af89a4",
"StorageVirtualMachineId": "svm-0b0149bf226af89a4",
"UUID": "90ccba40-7db3-11ed-a26f-3df7250d3ffe"
},
{
"CreationTime": "2022-12-17T06:45:09.462000+00:00",
"Endpoints": {
"Iscsi": {
"DNSName": "iscsi.svm-0b0c9e66d39afdc54.fs-01f8ffb4adbf236d1.fsx.us-east-1.amazonaws.com",
"IpAddresses": [
"10.0.1.125",
"10.0.1.101"
]
},
"Management": {
"DNSName": "svm-0b0c9e66d39afdc54.fs-01f8ffb4adbf236d1.fsx.us-east-1.amazonaws.com",
"IpAddresses": [
"10.0.1.104"
]
},
"Nfs": {
"DNSName": "svm-0b0c9e66d39afdc54.fs-01f8ffb4adbf236d1.fsx.us-east-1.amazonaws.com",
"IpAddresses": [
"10.0.1.104"
]
}
},
"FileSystemId": "fs-01f8ffb4adbf236d1",
"Lifecycle": "CREATED",
"Name": "SVM2",
"ResourceARN": "arn:aws:fsx:us-east-1:<AWSアカウントID>:storage-virtual-machine/fs-01f8ffb4adbf236d1/svm-0b0c9e66d39afdc54",
"StorageVirtualMachineId": "svm-0b0c9e66d39afdc54",
"UUID": "5c6616e0-7dd6-11ed-a26f-3df7250d3ffe"
}
]
}
ボリュームのリホスト
早速ボリュームのリストアをします。vol1というSVM1上のボリュームをSVM2にリホストします。ボリュームのリホストはvolume rehostで行います。
# ボリュームの確認
::> volume show -fields junction-path
vserver volume junction-path
------- --------- -------------
SVM1 SVM1_root /
SVM1 vol1 /vol1
SVM2 SVM2_root /
3 entries were displayed.
# vol1 を SVM1 から SVM2 にリホスト
::> volume rehost -vserver SVM1 -volume vol1 -destination-vserver SVM2
Warning: Rehosting a volume from one Vserver to another Vserver does not change the security information about 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.
Do you want to continue? {y|n}: y
[Job 42] Job is queued: Volume rehost operation on volume "vol1" on Vserver "SVM1" to destination Vserver "SVM2" by administrator "fsxadmin".
Error: command failed: [Job 42] Job failed:
Volume rehost precheck failed for reasons:
Cannot rehost volume "vol1" on Vserver "SVM1" because the volume is part of a junction path. Use the "volume show
-vserver SVM1 -volume vol1 -fields junction-path" command to view a volume's junction path. Use the "volume
unmount" command to remove the junction path.
SVMのジャンクションパスにマウントされているためエラーとなりました。自動でアンマウントまでしてくれると思ったのですが、そこまではしてくれないようです。
ボリュームをSVM1からアンマウントして再チャレンジします。
# ボリュームのアンマウント
::> volume unmount -vserver SVM1 -volume vol1
# ボリュームがアンマウントされたことを確認
::> volume show -fields junction-path
vserver volume junction-path
------- --------- -------------
SVM1 SVM1_root /
SVM1 vol1 -
SVM2 SVM2_root /
3 entries were displayed.
# vol1 を SVM1 から SVM2 にリホスト
::> volume rehost -vserver SVM1 -volume vol1 -destination-vserver SVM2
Warning: Rehosting a volume from one Vserver to another Vserver does not change the security information about 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.
Do you want to continue? {y|n}: y
[Job 44] Job is queued: Volume rehost operation on volume "vol1" on Vserver "SVM1" to destination Vserver "SVM2" by adminis[Job 44] Job succeeded: Successful
Info: volume is rehosted on the target Vserver.
Set the desired volume configuration - such as the export policy and QoS policy - on the target Vserver.
# リホストされたことを確認
::> volume show -fields junction-path
vserver volume junction-path
------- --------- -------------
SVM1 SVM1_root /
SVM2 SVM2_root /
SVM2 vol1 -
3 entries were displayed.
# vol1 を SVM2 の /vol1 にマウント
::> volume mount -vserver SVM2 -volume vol1 -junction-path /vol1
# vol1 を SVM2 の /vol1 にマウントされたことを確認
::> volume show -fields junction-path
vserver volume junction-path
------- --------- -------------
SVM1 SVM1_root /
SVM2 SVM2_root /
SVM2 vol1 /vol1
3 entries were displayed.
# リホストしたボリュームのエクスポートポリシー、スナップショットポリシーの確認
::> volume show -vserver SVM2 -volume vol1 -fields policy, snapshot-policy
vserver volume policy snapshot-policy
------- ------ ------- ---------------
SVM2 vol1 default default
アンマウントされた状態だとvol1をSVM1上のボリュームをSVM2にリホストすることができました。
NFSクライアントからアクセスしてみます。
# ボリュームがマウントされていることを確認 $ df -hT -t nfs4 df: ‘/mnt/fsxn’: Stale file handle df: ‘/mnt/fsxn/.snapshot/snaphost1’: Stale file handle $ mount | grep nfs4 svm-0b0149bf226af89a4.fs-01f8ffb4adbf236d1.fsx.us-east-1.amazonaws.com:/vol1 on /mnt/fsxn type nfs4 (rw,relatime,vers=4.1,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.0.1.41,local_lock=none,addr=10.0.1.119) # マウントポイントにアクセスできるか確認 $ ls -la /mnt/fsxn/ ls: cannot access /mnt/fsxn/: Stale file handle # アンマウント $ sudo umount /mnt/fsxn # SVM2 の vol1 をマウント $ sudo mount -t nfs svm-0b0c9e66d39afdc54.fs-01f8ffb4adbf236d1.fsx.us-east-1.amazonaws.com:/vol1 /mnt/fsxn/ # マウントされたことを確認 $ df -hT -t nfs4 Filesystem Type Size Used Avail Use% Mounted on svm-0b0c9e66d39afdc54.fs-01f8ffb4adbf236d1.fsx.us-east-1.amazonaws.com:/vol1 nfs4 95G 7.1G 88G 8% /mnt/fsxn # マウントポイントにアクセス $ ls -l /mnt/fsxn/ total 1052716 -rw-r--r-- 1 root root 1073741824 Dec 17 02:59 random_block_file_restore drwxr-xr-x 2 root root 4096 Dec 17 06:26 snapshot_test -rw-r--r-- 1 root root 5 Dec 17 05:58 test.txt
元々SVM1の/vol1をマウントしていたのでアンマウントして、SVM2の/vol2をマウントしたところアクセスできました。
エクスポートポリシーとスナップショットポリシーがリホスト後も引き継がれるのか
スナップショットポリシーの割り当て
先述した通り、エクスポートポリシーとスナップショットポリシーやQoSポリシーなど一部設定値はリホスト時に失われます。
ただし、ドキュメントからリホスト先のSVMに同一の名前の設定をしていた際にはどのような挙動をするのか記載がなかったので、試してみます。FSx for ONTAPにはデフォルトでfsx-root-volume-policyというエクスポートポリシーが作成されます。リホスト前のエクスポートポリシーにこちらのポリシーを設定して、どのような挙動をするのか確認します。
また、せっかくなのでリホスト先のSVMに存在しないスナップショットポリシーを作成し、ボリュームに作成したスナップショットポリシーを指定した場合の挙動も確認します。
まず、スナップショットポリシーを作成します。作成するスナップショットポリシーはevery_10_minという10分間隔でスナップショットを取得するものです。
# 現在のスナップショットポリシーの確認
::> snapshot policy show
Vserver: FsxId01f8ffb4adbf236d1
Number of Is
Policy Name Schedules Enabled Comment
------------------------ --------- ------- ----------------------------------
default 3 true Default policy with hourly, daily & weekly schedules.
Schedule Count Prefix SnapMirror Label
---------------------- ----- ---------------------- -------------------
hourly 6 hourly -
daily 2 daily daily
weekly 2 weekly weekly
default-1weekly 3 true Default policy with 6 hourly, 2 daily & 1 weekly schedule.
Schedule Count Prefix SnapMirror Label
---------------------- ----- ---------------------- -------------------
hourly 6 hourly -
daily 2 daily -
weekly 1 weekly -
none 0 false Policy for no automatic snapshots.
Schedule Count Prefix SnapMirror Label
---------------------- ----- ---------------------- -------------------
- - - -
3 entries were displayed.
# スナップショットポリシーの作成
::> snapshot policy create -vserver SVM2 -policy every_10_min -enabled true -schedule1 10min -count1 6 -prefix1 every_10_min
# スナップショットポリシーが作成されたことを確認
::> snapshot policy show
Vserver: FsxId01f8ffb4adbf236d1
Number of Is
Policy Name Schedules Enabled Comment
------------------------ --------- ------- ----------------------------------
default 3 true Default policy with hourly, daily & weekly schedules.
Schedule Count Prefix SnapMirror Label
---------------------- ----- ---------------------- -------------------
hourly 6 hourly -
daily 2 daily daily
weekly 2 weekly weekly
default-1weekly 3 true Default policy with 6 hourly, 2 daily & 1 weekly schedule.
Schedule Count Prefix SnapMirror Label
---------------------- ----- ---------------------- -------------------
hourly 6 hourly -
daily 2 daily -
weekly 1 weekly -
none 0 false Policy for no automatic snapshots.
Schedule Count Prefix SnapMirror Label
---------------------- ----- ---------------------- -------------------
- - - -
Vserver: SVM2
Number of Is
Policy Name Schedules Enabled Comment
------------------------ --------- ------- ----------------------------------
every_10_min 1 true -
Schedule Count Prefix SnapMirror Label
---------------------- ----- ---------------------- -------------------
10min 6 every_10_min -
4 entries were displayed.
every_10_minというスナップショットポリシーを作成できました。
こちらのスナップショットポリシーをvol1に割り当てます。
# vol1 に every_10_min を割り当て
::> volume modify -vserver SVM2 -volume vol1 -snapshot-policy every_10_min
Warning: You are changing the Snapshot policy on volume "vol1" to "every_10_min". Snapshot copies on this volume that do
not match any of the prefixes of the new Snapshot policy will not be deleted. However, when the new Snapshot
policy takes effect, depending on the new retention count, any existing Snapshot copies that continue to use the
same prefixes might be deleted. See the 'volume modify' man page for more information.
Do you want to continue? {y|n}: y
Volume modify successful on volume vol1 of Vserver SVM2.
# vol1 に every_10_min が割り当てられたことを確認
::> volume show -fields snapshot-policy
vserver volume snapshot-policy
------- --------- ---------------
SVM1 SVM1_root default
SVM2 SVM2_root default
SVM2 vol1 every_10_min
エクスポートポリシーの割り当て
次にエクスポートポリシーfsx-root-volume-policyをvol1に割り当てます。
# 各SVMに fsx-root-volume-policy があることを確認 ::> export-policy show Vserver Policy Name --------------- ------------------- SVM1 default SVM1 fsx-root-volume-policy SVM2 default SVM2 fsx-root-volume-policy 4 entries were displayed. # vol1 に fsx-root-volume-policy を割り当て ::> volume modify -vserver SVM2 -volume vol1 -policy fsx-root-volume-policy Volume modify successful on volume vol1 of Vserver SVM2. # vol1 に fsx-root-volume-policy が割り当てられたことを確認 ::> volume show -fields policy vserver volume policy ------- --------- ---------------------- SVM1 SVM1_root fsx-root-volume-policy SVM2 SVM2_root fsx-root-volume-policy SVM2 vol1 fsx-root-volume-policy 3 entries were displayed.
リホスト
それではこの状態でリホストを行います。
# vol1 を SVM2 からアンマウント
::> volume unmount -vserver SVM2 -volume vol1
# vol1 が SVM2 からアンマウントされたことを確認
::> volume show -vserver SVM2 -volume vol1 -fields junction-path
vserver volume junction-path
------- ------ -------------
SVM2 vol1 -
# vol1 を SVM2 から SVM1 にリホスト
::> volume rehost -vserver SVM2 -volume vol1 -destination-vserver SVM1
Warning: Rehosting a volume from one Vserver to another Vserver does not change the security information about 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.
Do you want to continue? {y|n}: y
[Job 48] Job is queued: Volume rehost operation on volume "vol1" on Vserver "SVM2" to destination Vserver "SVM1" by adminis[Job 48] Job succeeded: Successful
Info: volume is rehosted on the target Vserver.
Set the desired volume configuration - such as the export policy and QoS policy - on the target Vserver.
# リホストされたことを確認
::> volume show
Vserver Volume Aggregate State Type Size Available Used%
--------- ------------ ------------ ---------- ---- ---------- ---------- -----
SVM1 SVM1_root aggr1 online RW 1GB 972.3MB 0%
SVM1 vol1 aggr1 online RW 100GB 87.92GB 7%
SVM2 SVM2_root aggr1 online RW 1GB 972.5MB 0%
3 entries were displayed.
# リホストされた vol1 のエクスポートポリシーとスナップショットポリシーを確認
::> volume show -vserver SVM1 -volume vol1 -fields policy, snapshot-policy
vserver volume policy snapshot-policy
------- ------ ------- ---------------
SVM1 vol1 default default
リホスト後のボリュームを確認すると、エクスポートポリシー、スナップショットポリシーどちらもdefaultとなっていました。どうやらリホスト先のSVMに同一の設定があろうとなかろうとデフォルトの値になるようです。
リホストをするときは注意事項をよく確認してリホスト前後の設定を照らし合わせよう
Amazon FSx for NetApp ONTAPのボリュームを別のSVMにリホストしてみました。
いくつか注意点はありますが特に詰まることはなく、あっさりとリホストすることができました。
ただし、実際に業務でリホストをするときは注意事項をよく確認した上で実施をしてください。特に、リホスト前後に引き継がれない情報を照らし合わして、リホスト後にどの設定を変更する必要があるのか明らかにするのが大切です。
この記事が誰かの助けになれば幸いです。
以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!
![[アップデート]CloudTrail Lake で高度なイベントセレクターがサポートされました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-64f6cd71568d228b1e7f3831e5287d75/1b5c0e8e5797b4bff5913d5033b03348/aws-cloudtrail)
![[アップデート] Amazon QuickSight へロゴやテーマカラーを設定するための「ブランド管理機能」が追加されました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-19e77b9a51519e08b94d0f688c125729/4f439c75e1ee56c70e315fa46fa45f81/amazon-quicksight)
