![[Amazon FSx for NetApp ONTAP] ボリュームのジャンクションパスが階層構造になっている時の挙動を確認してみた](https://devio2023-media.developers.io/wp-content/uploads/2022/08/amazon-fsx-for-netapp-ontap.png)
[Amazon FSx for NetApp ONTAP] ボリュームのジャンクションパスが階層構造になっている時の挙動を確認してみた
ジャンクションパスを使いこなそう
ボリュームのジャンクションパスを階層構造にするとどんな挙動をするんだ
こんにちは、のんピ(@non____97)です。
皆さんはAmazon FSx for NetApp ONTAP(以降FSx for ONTAP)のボリュームのジャンクションパスが階層構造になっている時の挙動が気になったことはありますか? 私はあります。
ジャンクションパスはボリュームをONTAPのSVMの論理ネームスペースにマウントするときのパスです。以下の図では/A/A2や、/B/B1などがジャンクションパスで、AやA2などがジャンクションポイントです。
抜粋 : ジャンクションパスとは - NetApp
ジャンクションパスはNFSやSMBでマウントするときのFSx for ONTAPのパスになります。
例えば、/nfsというジャンクションパスのボリュームをNFSでマウントするときは以下のようなコマンドを叩きます。
> sudo mount -t nfs <SVMのDNS名>:/nfs <マウントポイント>
ジャンクションパスを階層構造にすることでボリュームをグループにまとめることができます。
ここで以下のような疑問が湧いてきました。
- 上位のジャンクションパスのボリュームをマウントした場合、下位のジャンクションパスのボリュームにもアクセスできるようになるか
- NetAppのKnowledge Baseに上位のジャンクションパスのボリュームをアンマウントすると下位のジャンクションパスのボリュームのセッションが中断されると記載があった
- 逆に上位のジャンクションパスのボリュームをマウントした際に下位のジャンクションパスのボリュームにアクセスできるようになるのか記載がなかったので気になる
- マルチバイト文字を含むジャンクションパスのボリュームを作成できるのか
- 上位のジャンクションパスをマウントした時に下位のジャンクションパスのボリュームにアクセスできるようになるのであれば、ジャンクションパスがクライアントにマウントした時のディレクトリパスになると推測
- ジャンクションパスにマルチバイト文字を含む場合も正しくマウントできるのか気になる
- DataSyncを使ってデータを転送する際に、ボリュームのジャンクションパスと送信するデータのディレクトリパスが同じ場合の挙動
- ジャンクションパスがクライアントにマウントした時のディレクトリパスになるのであれば、DataSyncでサブディレクトリごと転送した時にエラーなく転送されるか気になる
上述の疑問点について検証してみました。
なお、ジャンクションパスの基本的な制限事項は以下の通りです。
- ジャンクション ポイントを指定せずにボリュームを作成することもできますが、ネームスペース内のジャンクション ポイントにボリュームをマウントするまでは、ボリューム内のデータをエクスポートしたり（NFS）、共有を作成したり（CIFS）することはできません。
- ボリュームの作成中にマウントされなかったボリュームは、作成後にマウントできます。
- ボリュームをジャンクション ポイントにマウントすることで、ネームスペースにいつでも新しいボリュームを追加できます。
- マウントされたボリュームはアンマウントできますが、ボリュームをアンマウントすると、ボリューム内のすべてのデータと、マウントされていないボリュームの下の子ジャンクションポイントにマウントされているすべてのボリュームへの新しい NAS セッションが中断されます。
- バグ 465129 で説明されているように、 NFS ファイルハンドルがボリューム MSID を参照するため、既存の NFS セッションは、ボリュームが SVM ネームスペースから削除された後も、ボリューム内のすべてのデータに引き続きアクセスできます。
- ジャンクション ポイントは、親ボリューム ジャンクションのすぐ下に作成することも、ボリューム内のディレクトリに作成することもできます。
- Snapshot コピーへのアクセスはジャンクションを通過しません。
- ボリュームは、その vserver のネームスペースに 1 か所でマウントできます。
ジャンクションパスに次の文字を使用することはできません。 * # " < > | ？ \
また、ジャンクションパスの長さは 255 文字以下にする必要があります。
いきなりまとめ
- 上位のジャンクションパスのボリュームをマウントすると、下位のジャンクションパスのボリュームにもアクセスできるようになる
- ジャンクションポイントがディレクトリ名として扱われる
- マルチバイト文字を含むジャンクションパスのボリュームの作成はできる
- ただし、ONTAP CLIからのみ可能
- AWSのAPIとしては受け付けておらず、ONTAP CLIでマルチバイト文字のジャンクションパスのボリュームを作成した場合、マネジメントコンソールやAWS CLIで表示すると文字化けする
- DataSyncで送信元データのディレクトリパスと送信先のFSx for ONTAPのジャンクションパスとが同じ階層構造でも転送エラーは発生しない
- ただしメタデータが転送されるので注意が必要
検証環境
検証環境の構成図は以下の通りです。
ボリュームの準備
以下のようなジャンクションパスになるのようにSVMにボリュームをマウントします。
.
├── nfs
│ ├── tier1A
│ └── tier1B
│ └── tier2B
└── smb
├── tier1A
└── tier1B
└── tier2B
/nfsはNFSでマウントするボリューム、/smbはSMBでマウントするボリュームです。
こちらのボリュームをAWS CDKでデプロイします。AWS CDKのコードは前回の記事で使ったAWS CDKのコードをベースに準備します。リポジトリは以下の通りです。
ボリュームを以下のように定義しました。
// FSX for ONTAP volume
const volumes = [
{
volumeName: "fsx_for_ontap_volume_nfs",
junctionPath: "/nfs",
securityStyle: "UNIX",
},
{
volumeName: "fsx_for_ontap_volume_nfs_tier1A",
junctionPath: "/nfs/tier1A",
securityStyle: "UNIX",
},
{
volumeName: "fsx_for_ontap_volume_nfs_tier1B",
junctionPath: "/nfs/tier1B",
securityStyle: "UNIX",
},
{
volumeName: "fsx_for_ontap_volume_nfs_tier2B",
junctionPath: "/nfs/tier1B/tier2B",
securityStyle: "UNIX",
},
{
volumeName: "fsx_for_ontap_volume_smb",
junctionPath: "/smb",
securityStyle: "NTFS",
},
{
volumeName: "fsx_for_ontap_volume_smb_tier1A",
junctionPath: "/smb/tier1A",
securityStyle: "NTFS",
},
{
volumeName: "fsx_for_ontap_volume_smb_tier1B",
junctionPath: "/smb/tier1B",
securityStyle: "NTFS",
},
{
volumeName: "fsx_for_ontap_volume_smb_tier2B",
junctionPath: "/smb/tier1B/tier2B",
securityStyle: "NTFS",
},
];
volumes.forEach((volume) => {
new fsx.CfnVolume(this, volume.volumeName, {
name: volume.volumeName,
ontapConfiguration: {
junctionPath: volume.junctionPath,
sizeInMegabytes: "102400",
storageEfficiencyEnabled: "true",
storageVirtualMachineId: svm.ref,
securityStyle: volume.securityStyle,
tieringPolicy: {
coolingPeriod: 31,
name: "AUTO",
},
},
tags: [
{
key: "Name",
value: volume.volumeName,
},
],
volumeType: "ONTAP",
});
});
npx cdk deployでデプロイ後、一部のボリュームでVolume created successfully but not mounted. Junction path is invalid.とエラーが出力されていました。
ボリュームは作成できたようですが、ジャンクションパスにマウントできていないようです。
FSx for ONTAPファイルシステムにSSHして、ONTAP CLIでボリュームがジャンクションパスに接続できているか確認してみます。
FsxId0ad183f269f00ec0f::> volume show -fields volume, junction-path, junction-active
vserver volume junction-path junction-active
----------------- ---------------------- ------------- ---------------
fsx-for-ontap-svm fsx_for_ontap_svm_root / true
fsx-for-ontap-svm fsx_for_ontap_volume_nfs
/nfs true
fsx-for-ontap-svm fsx_for_ontap_volume_nfs_tier1A
/nfs/tier1A true
fsx-for-ontap-svm fsx_for_ontap_volume_nfs_tier1B
- -
fsx-for-ontap-svm fsx_for_ontap_volume_nfs_tier2B
- -
fsx-for-ontap-svm fsx_for_ontap_volume_smb
/smb true
fsx-for-ontap-svm fsx_for_ontap_volume_smb_tier1A
/smb/tier1A true
fsx-for-ontap-svm fsx_for_ontap_volume_smb_tier1B
- -
fsx-for-ontap-svm fsx_for_ontap_volume_smb_tier2B
- -
9 entries were displayed.
ジャンクションパスが/nfs/tier1Bや/nfs/tier1B/tier2B、 /smb/tier1B、 /smb/tier1B/tier2Bのボリュームのjunction-activeが-になっていますね。
恐らく/nfsなど上位のジャンクションパスのボリュームを作成する前に、/nfs/tier1Bなどマウントされていないジャンクションパスのボリュームを作成しようとしたのではと推測します。
試しにONTAP CLIで手動でマウントしてみます。
# マウントされていないボリュームを指定したジャンクションパスにポイント
FsxId0ad183f269f00ec0f::> volum mount -volume fsx_for_ontap_volume_nfs_tier1B -junction-path /nfs/tier1B -active true
(volume mount)
FsxId0ad183f269f00ec0f::> volum mount -volume fsx_for_ontap_volume_nfs_tier2B -junction-path /nfs/tier1B/tier2B -active true
(volume mount)
FsxId0ad183f269f00ec0f::> volum mount -volume fsx_for_ontap_volume_smb_tier1B -junction-path /smb/tier1B -active true
(volume mount)
FsxId0ad183f269f00ec0f::> volum mount -volume fsx_for_ontap_volume_smb_tier2B -junction-path /smb/tier1B/tier2B -active true
(volume mount)
# ボリュームのマウント状況を確認
FsxId0ad183f269f00ec0f::> volume show -fields volume, junction-path, junction-active
vserver volume junction-path junction-active
----------------- ---------------------- ------------- ---------------
fsx-for-ontap-svm fsx_for_ontap_svm_root / true
fsx-for-ontap-svm fsx_for_ontap_volume_nfs
/nfs true
fsx-for-ontap-svm fsx_for_ontap_volume_nfs_tier1A
/nfs/tier1A true
fsx-for-ontap-svm fsx_for_ontap_volume_nfs_tier1B
/nfs/tier1B true
fsx-for-ontap-svm fsx_for_ontap_volume_nfs_tier2B
/nfs/tier1B/tier2B
true
fsx-for-ontap-svm fsx_for_ontap_volume_smb
/smb true
fsx-for-ontap-svm fsx_for_ontap_volume_smb_tier1A
/smb/tier1A true
fsx-for-ontap-svm fsx_for_ontap_volume_smb_tier1B
/smb/tier1B true
fsx-for-ontap-svm fsx_for_ontap_volume_smb_tier2B
/smb/tier1B/tier2B
true
9 entries were displayed.
全てのボリュームのjunction-activeがtrueになり、マウントされたことを確認できました。
上位のジャンクションパスのボリュームをマウントした場合、下位のジャンクションパスのボリュームにもアクセスできるようになるか
SMBの場合
それでは、「上位のジャンクションパスのボリュームをマウントした場合、下位のジャンクションパスのボリュームにもアクセスできるようになるか」を検証してみます。
まずはSMBの場合について確認します。
ワークグループのCIFSサーバーを用意します。
# ワークグループのCIFSサーバーを作成
FsxId0ad183f269f00ec0f::> vserver cifs create -vserver fsx-for-ontap-svm -cifs-server cifs-server -workgroup fsxn-workgroup
Notice: SMB1 protocol version is obsolete and considered insecure. Therefore it is deprecated and disabled on this CIFS server. Support for SMB1 might be removed
in a future release. If required, use the (privilege: advanced) "vserver cifs options modify -vserver fsx-for-ontap-svm -smb1-enabled true" to enable it.
# 作成したCIFSサーバーを確認
FsxId0ad183f269f00ec0f::> vserver cifs show -instance
Vserver: fsx-for-ontap-svm
CIFS Server NetBIOS Name: CIFS-SERVER
NetBIOS Domain/Workgroup Name: FSXN-WORKGROUP
Fully Qualified Domain Name: -
Organizational Unit: -
Default Site Used by LIFs Without Site Membership: -
Workgroup Name: FSXN-WORKGROUP
Authentication Style: workgroup
CIFS Server Administrative Status: up
CIFS Server Description:
List of NetBIOS Aliases: -
次にジャンクションパス/smbのボリュームを共有するようなCIFSファイル共有を作成します。
# CIFSファイルサーバーの作成
FsxId0ad183f269f00ec0f::> vserver cifs share create -vserver fsx-for-ontap-svm -share-name cifs-share -path /smb
# 作成したCIFSファイルサーバーの確認
FsxId0ad183f269f00ec0f::> vserver cifs share show -vserver fsx-for-ontap-svm -share-name cifs-share -instance
Vserver: fsx-for-ontap-svm
Share: cifs-share
CIFS Server NetBIOS Name: CIFS-SERVER
Path: /smb
Share Properties: oplocks
browsable
changenotify
show-previous-versions
Symlink Properties: symlinks
File Mode Creation Mask: -
Directory Mode Creation Mask: -
Share Comment: -
Share ACL: Everyone / Full Control
File Attribute Cache Lifetime: -
Volume Name: fsx_for_ontap_volume_smb
Offline Files: manual
Vscan File-Operations Profile: standard
Maximum Tree Connections on Share: 4294967295
UNIX Group for File Create: -
また、CIFSファイル共有にアクセスする際に使う認証に使えるユーザーはCIFS-SERVER\cifs-userです。前回の記事で作成したユーザーを再利用します。
# CIFSのローカルユーザー一覧の確認
FsxId0ad183f269f00ec0f::> vserver cifs users-and-groups local-user show -instance
Vserver: fsx-for-ontap-svm
User Name: CIFS-SERVER\Administrator
Full Name:
Description: Built-in administrator account
Is Account Disabled: true
Vserver: fsx-for-ontap-svm
User Name: CIFS-SERVER\cifs-user
Full Name: -
Description: -
Is Account Disabled: false
Vserver: fsx-for-ontap-svm
User Name: CIFS-SERVER\cifs-user02
Full Name: -
Description: -
Is Account Disabled: false
3 entries were displayed.
下準備ができたので、作成したCIFSファイル共有をZドライブにSMBでマウントします。
# 現在のドライブ一覧を確認 > Get-PSDrive Name Used (GB) Free (GB) Provider Root CurrentLocation ---- --------- --------- -------- ---- --------------- Alias Alias C 13.37 16.63 FileSystem C:\ Windows\system32 Cert Certificate \ Env Environment Function Function HKCU Registry HKEY_CURRENT_USER HKLM Registry HKEY_LOCAL_MACHINE Variable Variable WSMan WSMan # 作成したCIFSファイル共有をZドライブにマウント > net use Z: \\svm-06f51f2e59a98b1f0.fs-0ad183f269f00ec0f.fsx.us-east-1.amazonaws.com\cifs-share The password is invalid for \\svm-06f51f2e59a98b1f0.fs-0ad183f269f00ec0f.fsx.us-east-1.amazonaws.com\cifs-share. Enter the user name for 'svm-06f51f2e59a98b1f0.fs-0ad183f269f00ec0f.fsx.us-east-1.amazonaws.com': CIFS-SERVER\cifs-user Enter the password for svm-06f51f2e59a98b1f0.fs-0ad183f269f00ec0f.fsx.us-east-1.amazonaws.com: The command completed successfully. # ZドライブにCIFSファイル共有をマウントできたことを確認 > Get-PSDrive Name Used (GB) Free (GB) Provider Root CurrentLocation ---- --------- --------- -------- ---- --------------- Alias Alias C 13.37 16.63 FileSystem C:\ Windows\system32 Cert Certificate \ Env Environment Function Function HKCU Registry HKEY_CURRENT_USER HKLM Registry HKEY_LOCAL_MACHINE Variable Variable WSMan WSMan Z 0.00 95.00 FileSystem \\svm-06f51f2e59a98b1f0.fs-0ad18...
マウントできましたね。それでは、/smb/tier1Aや/smb/tier1B/tier2Bなど下位のジャンクションパスのボリュームにアクセスできるか確認してみます。
# Zドライブ配下のフォルダをリストアップ
> cd Z:\
> Get-ChildItem -Recurse
Directory: Z:\
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----l 10/8/2022 5:50 AM tier1A
d----l 10/8/2022 6:08 AM tier1B
# /smb/tier1A 配下を確認
> dir .\tier1A\
# /smb/tier1B/tier2B 配下を確認
> dir .\tier1B\
Directory: Z:\tier1B
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----l 10/8/2022 6:08 AM tier2B
ボリュームにあたるフォルダの属性がlのリパースポイントになっているためかGet-ChildItem -Recurseで再帰的にZドライブは以下のフォルダを確認することはできなかったですが、dirでアクセスすると下位のジャンクションパスである/smb/tier1Aや/smb/tier1B/にアクセスできました。
また、tier1Aやtier2Bなどボリュームのジャンクションポイントがフォルダ名になっていることから、ジャンクションパスがマウントした際のディレクトリパスにもなるようですね。
ジャンクションパス/smb/tier1B/tier2Bのボリュームにあたるフォルダ配下にテキストファイルやバイナリファイルを作成してみて、確かに/smb/tier1B/tier2Bのボリュームに書き込まれていることを確認してみます。
# テキストファイルを`/smb/tier1B/tier2B`のボリュームにあたるフォルダ配下に作成
> echo smb test > .\tier1B\tier2B\smb-test-file
# テキストファイルが作成されたか確認
> ls .\tier1B\tier2B\
Directory: Z:\tier1B\tier2B
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 10/8/2022 6:27 AM 24 smb-test-file
# バイナリファイルを /smb/tier1B/tier2B のボリュームにあたるフォルダ配下に作成
> $random_bin = new-object byte[] (1024 * 1024 * 100);
> (new-object Random).NextBytes($random_bin)
> [IO.File]::WriteAllBytes("Z:\tier1B\tier2B\binary_file", $random_bin)
# バイナリファイルが作成されたか確認
> ls .\tier1B\tier2B\
Directory: Z:\tier1B\tier2B
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 10/8/2022 6:27 AM 24 smb-test-file
-a---- 10/8/2022 6:35 AM 104857600 binary_file
テキストファイルとバイナリファイル作成後、ONTAP CLIで各ボリュームの使用量を確認して、ジャンクションパス/smb/tier1B/tier2Bのボリュームのみ使用量が増えていることを確認します。
# ジャンクションパス /smb のボリュームの使用量を確認
FsxId0ad183f269f00ec0f::> volume show-footprint -volume fsx_for_ontap_volume_smb
Vserver : fsx-for-ontap-svm
Volume : fsx_for_ontap_volume_smb
Feature Used Used%
-------------------------------- ---------- -----
Volume Data Footprint 568KB 0%
Footprint in Performance Tier
3.99MB 100%
Footprint in FSxFabricpoolObjectStore
0B 0%
Volume Guarantee 0B 0%
Flexible Volume Metadata 107.5MB 0%
Delayed Frees 3.44MB 0%
Total Footprint 111.5MB 0%
# ジャンクションパス /smb/tier1B のボリュームの使用量を確認
FsxId0ad183f269f00ec0f::> volume show-footprint -volume fsx_for_ontap_volume_smb_tier1B
Vserver : fsx-for-ontap-svm
Volume : fsx_for_ontap_volume_smb_tier1B
Feature Used Used%
-------------------------------- ---------- -----
Volume Data Footprint 560KB 0%
Footprint in Performance Tier
3.20MB 100%
Footprint in FSxFabricpoolObjectStore
0B 0%
Volume Guarantee 0B 0%
Flexible Volume Metadata 107.5MB 0%
Delayed Frees 2.66MB 0%
Total Footprint 110.7MB 0%
# ジャンクションパス /smb/tier1B/tier2B のボリュームの使用量を確認
FsxId0ad183f269f00ec0f::> volume show-footprint -volume fsx_for_ontap_volume_smb_tier2B
Vserver : fsx-for-ontap-svm
Volume : fsx_for_ontap_volume_smb_tier2B
Feature Used Used%
-------------------------------- ---------- -----
Volume Data Footprint 102.0MB 0%
Footprint in Performance Tier
105.4MB 100%
Footprint in FSxFabricpoolObjectStore
0B 0%
Volume Guarantee 0B 0%
Flexible Volume Metadata 107.5MB 0%
Delayed Frees 3.46MB 0%
Total Footprint 212.9MB 0%
他のボリュームのプリマリストレージの使用量が3 MB程度なのに対して、ジャンクションパス/smb/tier1B/tier2Bのボリュームの使用量は105.4 MBであることから、確かにジャンクションパス/smb/tier1B/tier2Bのボリュームに書き込まれていそうです。
NFSの場合
続いてNFSの場合も確認します。
まず、NFSの機能が有効であることを確認します。
# サポートしているすべてのバージョンのNFSが有効になっていることを確認
FsxId0ad183f269f00ec0f::> vserver nfs show
Vserver: fsx-for-ontap-svm
General Access: true
v3: enabled
v4.0: enabled
4.1: enabled
UDP: enabled
TCP: enabled
Default Windows User: -
Default Windows Group: -
# NFSサーバーがSVMで動作していることを確認
FsxId0ad183f269f00ec0f::> vserver nfs status
The NFS server is running on Vserver "fsx-for-ontap-svm".
マウントポイント/mnt/fsxにジャンクションパス/nfsのボリュームをマウントします。
# マウントポイントの作成 $ sudo mkdir /mnt/fsx # マウントポイント /mnt/fsx にジャンクションパス /nfs のボリュームをマウント $ sudo mount -t nfs svm-06f51f2e59a98b1f0.fs-0ad183f269f00ec0f.fsx.us-east-1.amazonaws.com:/nfs /mnt/fsx/ # NFS v4 でマウントされていることを確認 $ df -ht nfs4 Filesystem Size Used Avail Use% Mounted on svm-06f51f2e59a98b1f0.fs-0ad183f269f00ec0f.fsx.us-east-1.amazonaws.com:/nfs 95G 320K 95G 1% /mnt/fsx # マウントポイント配下のディレクトリを再帰的に確認 $ ls -R /mnt/fsx/ /mnt/fsx/: tier1A tier1B /mnt/fsx/tier1A: /mnt/fsx/tier1B: tier2B /mnt/fsx/tier1B/tier2B:
NFSでも下位のジャンクションパスである/nfs/tier1Aや/nfs/tier1B/にアクセスできました。
もう少しわかりやすく表示するためにtreeコマンドをインストールして、実行します。
# tree コマンドのインストール
$ sudo yum install tree -y
Loaded plugins: extras_suggestions, langpacks, priorities, update-motd
amzn2-core | 3.7 kB 00:00:00
Resolving Dependencies
--> Running transaction check
---> Package tree.x86_64 0:1.6.0-10.amzn2.0.1 will be installed
--> Finished Dependency Resolution
Dependencies Resolved
====================================================================================================================================================================
Package Arch Version Repository Size
====================================================================================================================================================================
Installing:
tree x86_64 1.6.0-10.amzn2.0.1 amzn2-core 47 k
Transaction Summary
====================================================================================================================================================================
Install 1 Package
Total download size: 47 k
Installed size: 83 k
Downloading packages:
tree-1.6.0-10.amzn2.0.1.x86_64.rpm | 47 kB 00:00:00
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Installing : tree-1.6.0-10.amzn2.0.1.x86_64 1/1
Verifying : tree-1.6.0-10.amzn2.0.1.x86_64 1/1
Installed:
tree.x86_64 0:1.6.0-10.amzn2.0.1
Complete!
# tree コマンドの実行
$ tree /mnt/fsx/
/mnt/fsx/
├── tier1A
└── tier1B
└── tier2B
3 directories, 0 files
ジャンクションパスの階層構造をツリー状に表示することができました。
最後にジャンクションパス/nfs/tier1B/tier2Bのボリュームにあたるディレクトリ配下にテキストファイルやバイナリファイルを作成してみて、確かに/nfs/tier1B/tier2Bのボリュームに書き込まれていることを確認してみます。
# 1GBのバイナリファイルを /nfs/tier1B/tier2B に作成 $ sudo dd if=/dev/urandom of=/mnt/fsx/tier1B/tier2B/binary_file bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 7.72336 s, 139 MB/s
バイナリファイル作成後、ONTAP CLIで各ボリュームの使用量を確認して、ジャンクションパス/nfs/tier1B/tier2Bのボリュームのみ使用量が増えていることを確認します。
# ジャンクションパス /nfs のボリュームの使用量を確認
FsxId0ad183f269f00ec0f::> volume show-footprint -volume fsx_for_ontap_volume_nfs
Vserver : fsx-for-ontap-svm
Volume : fsx_for_ontap_volume_nfs
Feature Used Used%
-------------------------------- ---------- -----
Volume Data Footprint 564KB 0%
Footprint in Performance Tier
3.21MB 100%
Footprint in FSxFabricpoolObjectStore
0B 0%
Volume Guarantee 0B 0%
Flexible Volume Metadata 107.5MB 0%
Delayed Frees 2.66MB 0%
Total Footprint 110.7MB 0%
# ジャンクションパス /nfs/tier1B のボリュームの使用量を確認
FsxId0ad183f269f00ec0f::> volume show-footprint -volume fsx_for_ontap_volume_nfs_tier1B
Vserver : fsx-for-ontap-svm
Volume : fsx_for_ontap_volume_nfs_tier1B
Feature Used Used%
-------------------------------- ---------- -----
Volume Data Footprint 556KB 0%
Footprint in Performance Tier
3.02MB 100%
Footprint in FSxFabricpoolObjectStore
0B 0%
Volume Guarantee 0B 0%
Flexible Volume Metadata 107.5MB 0%
Delayed Frees 2.48MB 0%
Total Footprint 110.5MB 0%
# ジャンクションパス /nfs/tier1B/tier2B のボリュームの使用量を確認
FsxId0ad183f269f00ec0f::> volume show-footprint -volume fsx_for_ontap_volume_nfs_tier2B
Vserver : fsx-for-ontap-svm
Volume : fsx_for_ontap_volume_nfs_tier2B
Feature Used Used%
-------------------------------- ---------- -----
Volume Data Footprint 1.01GB 0%
Footprint in Performance Tier
1.02GB 100%
Footprint in FSxFabricpoolObjectStore
0B 0%
Volume Guarantee 0B 0%
Flexible Volume Metadata 107.5MB 0%
Delayed Frees 3.32MB 0%
Total Footprint 1.12GB 0%
他のボリュームのプライマリストレージ使用量が3 MB程度なのに対して、ジャンクションパス/nfs/tier1B/tier2Bのボリュームの使用量は1.02 GBであることから、確かにジャンクションパス/nfs/tier1B/tier2Bのボリュームに書き込まれていそうです。
マルチバイト文字を含むジャンクションパスのボリュームを作成できるのか
ボリュームの準備
マルチバイト文字を含むジャンクションパスのボリュームを作成してみます。
まず、AWS CDKで/nfs/tier1B/tier2B/【マルチバイト文字テスト】 これは tier 3 です！といったジャンクションパスのボリュームを作成しようとしてみます。
// FSX for ONTAP volume
const volumes = [
{
volumeName: "fsx_for_ontap_volume_nfs",
junctionPath: "/nfs",
securityStyle: "UNIX",
},
{
volumeName: "fsx_for_ontap_volume_nfs_tier1A",
junctionPath: "/nfs/tier1A",
securityStyle: "UNIX",
},
{
volumeName: "fsx_for_ontap_volume_nfs_tier1B",
junctionPath: "/nfs/tier1B",
securityStyle: "UNIX",
},
{
volumeName: "fsx_for_ontap_volume_nfs_tier2B",
junctionPath: "/nfs/tier1B/tier2B",
securityStyle: "UNIX",
},
{
volumeName: "fsx_for_ontap_volume_nfs_tier3B",
junctionPath:
"/nfs/tier1B/tier2B/【マルチバイト文字テスト】 これは tier 3 です！",
securityStyle: "UNIX",
},
{
volumeName: "fsx_for_ontap_volume_smb",
junctionPath: "/smb",
securityStyle: "NTFS",
},
{
volumeName: "fsx_for_ontap_volume_smb_tier1A",
junctionPath: "/smb/tier1A",
securityStyle: "NTFS",
},
{
volumeName: "fsx_for_ontap_volume_smb_tier1B",
junctionPath: "/smb/tier1B",
securityStyle: "NTFS",
},
{
volumeName: "fsx_for_ontap_volume_smb_tier2B",
junctionPath: "/smb/tier1B/tier2B",
securityStyle: "NTFS",
},
{
volumeName: "fsx_for_ontap_volume_smb_tier3B",
junctionPath:
"/smb/tier1B/tier2B/【マルチバイト文字テスト】 これは tier 3 です！",
securityStyle: "NTFS",
},
];
volumes.forEach((volume) => {
new fsx.CfnVolume(this, volume.volumeName, {
name: volume.volumeName,
ontapConfiguration: {
junctionPath: volume.junctionPath,
sizeInMegabytes: "102400",
storageEfficiencyEnabled: "true",
storageVirtualMachineId: svm.ref,
securityStyle: volume.securityStyle,
tieringPolicy: {
coolingPeriod: 31,
name: "AUTO",
},
},
tags: [
{
key: "Name",
value: volume.volumeName,
},
],
volumeType: "ONTAP",
});
});
npx cdk deployでデプロイしようとすると以下のようなエラーが出力されました。
❌ FsxForOntapWindowsClientStack failed: Error: The stack named FsxForOntapWindowsClientStack failed to deploy: UPDATE_ROLLBACK_COMPLETE: /nfs/tier1B/tier2B/????????????? ??? tier 3???? is not a valid junction path. A junction path must start with "/", can only contain alphanumeric characters or ".", "-", "_", or non-sequential "/", cannot end with "/" unless it is the root volume, and cannot exceed 255 characters in length. (Service: AmazonFSx; Status Code: 400; Error Code: BadRequest; Request ID: 2627d481-07a5-4016-ab78-00bd700e067d; Proxy: null), /smb/tier1B/tier2B/????????????? ??? tier 3???? is not a valid junction path. A junction path must start with "/", can only contain alphanumeric characters or ".", "-", "_", or non-sequential "/", cannot end with "/" unless it is the root volume, and cannot exceed 255 characters in length. (Service: AmazonFSx; Status Code: 400; Error Code: BadRequest; Request ID: 1ee664a1-5663-4e83-a08d-8478cf9fbe34; Proxy: null)
at FullCloudFormationDeployment.monitorDeployment (/<ディレクトリパス>fsx-for-ontap-windows-client/node_modules/aws-cdk/lib/api/deploy-stack.ts:496:13)
at processTicksAndRejections (node:internal/process/task_queues:95:5)
at deployStack2 (/<ディレクトリパス>fsx-for-ontap-windows-client/node_modules/aws-cdk/lib/cdk-toolkit.ts:241:24)
at /<ディレクトリパス>fsx-for-ontap-windows-client/node_modules/aws-cdk/lib/deploy.ts:39:11
at run (/<ディレクトリパス>fsx-for-ontap-windows-client/node_modules/p-queue/dist/index.js:163:29)
❌ Deployment failed: Error: Stack Deployments Failed: Error: The stack named FsxForOntapWindowsClientStack failed to deploy: UPDATE_ROLLBACK_COMPLETE: /nfs/tier1B/tier2B/????????????? ??? tier 3???? is not a valid junction path. A junction path must start with "/", can only contain alphanumeric characters or ".", "-", "_", or non-sequential "/", cannot end with "/" unless it is the root volume, and cannot exceed 255 characters in length. (Service: AmazonFSx; Status Code: 400; Error Code: BadRequest; Request ID: 2627d481-07a5-4016-ab78-00bd700e067d; Proxy: null), /smb/tier1B/tier2B/????????????? ??? tier 3???? is not a valid junction path. A junction path must start with "/", can only contain alphanumeric characters or ".", "-", "_", or non-sequential "/", cannot end with "/" unless it is the root volume, and cannot exceed 255 characters in length. (Service: AmazonFSx; Status Code: 400; Error Code: BadRequest; Request ID: 1ee664a1-5663-4e83-a08d-8478cf9fbe34; Proxy: null)
at deployStacks (/<ディレクトリパス>fsx-for-ontap-windows-client/node_modules/aws-cdk/lib/deploy.ts:61:11)
at processTicksAndRejections (node:internal/process/task_queues:95:5)
at CdkToolkit.deploy (/<ディレクトリパス>fsx-for-ontap-windows-client/node_modules/aws-cdk/lib/cdk-toolkit.ts:314:7)
at initCommandLine (/<ディレクトリパス>fsx-for-ontap-windows-client/node_modules/aws-cdk/lib/cli.ts:357:12)
Stack Deployments Failed: Error: The stack named FsxForOntapWindowsClientStack failed to deploy: UPDATE_ROLLBACK_COMPLETE: /nfs/tier1B/tier2B/????????????? ??? tier 3???? is not a valid junction path. A junction path must start with "/", can only contain alphanumeric characters or ".", "-", "_", or non-sequential "/", cannot end with "/" unless it is the root volume, and cannot exceed 255 characters in length. (Service: AmazonFSx; Status Code: 400; Error Code: BadRequest; Request ID: 2627d481-07a5-4016-ab78-00bd700e067d; Proxy: null), /smb/tier1B/tier2B/????????????? ??? tier 3???? is not a valid junction path. A junction path must start with "/", can only contain alphanumeric characters or ".", "-", "_", or non-sequential "/", cannot end with "/" unless it is the root volume, and cannot exceed 255 characters in length. (Service: AmazonFSx; Status Code: 400; Error Code: BadRequest; Request ID: 1ee664a1-5663-4e83-a08d-8478cf9fbe34; Proxy: null)
英数字と-や、_など一部記号のみしか受け付けないようです。
マネジメントコンソールからもマルチバイト文字を含むジャンクションパスでボリュームを作成しようとしましたが、同様のエラーで弾かれました。
CreateVolume APIのOntapConfigurationでジャンクションパスのパターンを確認します。
JunctionPath
Specifies the location in the SVM's namespace where the volume is mounted. The JunctionPath must have a leading forward slash, such as /vol3.
Type: String
Length Constraints: Minimum length of 1. Maximum length of 255.
Pattern: ^[^\ \u2028\u2029\r\n]{1,255}$
Required: Yes
これを見る限り英数字と一部記号のみといった制限はかけられていないようですが、ダメなものはダメなようです。
AWS側からマルチバイト文字を含むジャンクションパスのボリュームは作成できないようなので、ONTAP CLIからトライしてみます。
# マルチバイト文字を含むジャンクションパスのボリュームを作成
FsxId0ad183f269f00ec0f::> volume create -volume fsx_for_ontap_volume_nfs_tier3B -size 100G -aggregate aggr1 -policy default -state online -security-style UNIX -junction-path "/nfs/tier1B/tier2B/【マルチバイト文字テスト】 これは tier 3 です！"
[Job 57] Job succeeded: Successful
FsxId0ad183f269f00ec0f::> volume create -volume fsx_for_ontap_volume_smb_tier3B -size 100G -aggregate aggr1 -policy default -state online -security-style NTFS -junction-path "/smb/tier1B/tier2B/【マルチバイト文字テスト】 これは tier 3 です！"
[Job 59] Job succeeded: Successful
# 作成したボリュームの確認
FsxId0ad183f269f00ec0f::> volume show -volume fsx_for_ontap_volume_nfs_tier3B, fsx_for_ontap_volume_smb_tier3B
Vserver Volume Aggregate State Type Size Available Used%
--------- ------------ ------------ ---------- ---- ---------- ---------- -----
fsx-for-ontap-svm
fsx_for_ontap_volume_nfs_tier3B
aggr1 online RW 100GB 95.00GB 0%
fsx-for-ontap-svm
fsx_for_ontap_volume_smb_tier3B
aggr1 online RW 100GB 95.00GB 0%
2 entries were displayed.
# 作成したボリュームのジャンクションパスに確かにマルチバイト文字が含まれていることを確認
FsxId0ad183f269f00ec0f::> volume show -volume fsx_for_ontap_volume_nfs_tier3B, fsx_for_ontap_volume_smb_tier3B -fields volume, junction-path, junction-active
vserver volume junction-path junction-active
----------------- ------------------------------- --------------------------------------------------------------------------------------- ---------------
fsx-for-ontap-svm fsx_for_ontap_volume_nfs_tier3B /nfs/tier1B/tier2B/【マルチバイト文字テスト】 これは tier 3 です！ true
fsx-for-ontap-svm fsx_for_ontap_volume_smb_tier3B /smb/tier1B/tier2B/【マルチバイト文字テスト】 これは tier 3 です！ true
2 entries were displayed.
ONTAP CLIからは作成できました。
ただし、作成したボリュームをマネジメントコンソールから確認すると、マルチバイト文字のところのみ文字化けしてしまいました。
AWS CLIから確認しても文字化けしていました。
$ aws fsx describe-volumes --volume-ids fsvol-00ca2ab2086073581
{
"Volumes": [
{
"CreationTime": "2022-10-08T07:08:47+00:00",
"FileSystemId": "fs-0ad183f269f00ec0f",
"Lifecycle": "CREATED",
"Name": "fsx_for_ontap_volume_smb_tier3B",
"OntapConfiguration": {
"FlexCacheEndpointType": "NONE",
"JunctionPath": "/smb/tier1B/tier2B/ããã«ããã¤ãæåãã¹ãã ãã㯠tier 3ãã§ãï¼",
"SecurityStyle": "NTFS",
"SizeInMegabytes": 102400,
"StorageEfficiencyEnabled": true,
"StorageVirtualMachineId": "svm-06f51f2e59a98b1f0",
"StorageVirtualMachineRoot": false,
"TieringPolicy": {
"CoolingPeriod": 2,
"Name": "SNAPSHOT_ONLY"
},
"UUID": "0dce24e8-46d8-11ed-863a-7bcd8a1a4feb",
"OntapVolumeType": "RW"
},
"ResourceARN": "arn:aws:fsx:us-east-1:<AWSアカウントID>:volume/fs-0ad183f269f00ec0f/fsvol-00ca2ab2086073581",
"VolumeId": "fsvol-00ca2ab2086073581",
"VolumeType": "ONTAP"
}
]
}
ONTAPのOSとしてはジャンクションパスにマルチバイト文字を含むことはサポートしているので、AWS側でもサポートして欲しいですね。
SMBでアクセスできるか確認
それではSMBでこのジャンクションパスにアクセスできるか確認します。
> ls Z:\tier1B\tier2B
Directory: Z:\tier1B\tier2B
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----l 10/8/2022 7:08 AM 【マルチバイト文字テスト】 これは tier 3 です！
-a---- 10/8/2022 6:27 AM 24 smb-test-file
-a---- 10/8/2022 6:35 AM 104857600 binary_file
> ls 'Z:\tier1B\tier2B\【マルチバイト文字テスト】 これは tier 3 です！\'
Z:\tier1B\tier2Bにアクセスすると、確かに【マルチバイト文字テスト】 これは tier 3 です！というフォルダが作成されていました。
書き込めるのかも確認してみます。
# バイナリファイルを /smb/tier1B/tier2B/【マルチバイト文字テスト】 これは tier 3 です！ のボリュームにあたるフォルダ配下に作成
> $random_bin = new-object byte[] (1024 * 1024 * 100);
> (new-object Random).NextBytes($random_bin)
> [IO.File]::WriteAllBytes("Z:\tier1B\tier2B\【マルチバイト文字テスト】 これは tier 3 です！\binary_file", $random_bin)
# バイナリファイルが作成されたか確認
> ls 'Z:\tier1B\tier2B\【マルチバイト文字テスト】 これは tier 3 です！\'
Directory: Z:\tier1B\tier2B\【マルチバイト文字テスト】 これは tier 3 です！
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 10/8/2022 7:27 AM 104857600 binary_file
# 現在のドライブ一覧の確認
> Get-PSDrive
Name Used (GB) Free (GB) Provider Root CurrentLocation
---- --------- --------- -------- ---- ---------------
Alias Alias
C 13.43 16.56 FileSystem C:\ Windows\system32
Cert Certificate \
Env Environment
Function Function
HKCU Registry HKEY_CURRENT_USER
HKLM Registry HKEY_LOCAL_MACHINE
Variable Variable
WSMan WSMan
Z 0.00 95.00 FileSystem \\svm-06f51f2e59a98b1f0.fs-0ad18...
書き込みも問題なくできますね。
NFSでアクセスできるか確認
NFSでもアクセスできるか確認してみます。
$ ls -l /mnt/fsx/tier1B/tier2B/ total 1052716 -rw-r--r-- 1 root root 1073741824 Oct 8 06:55 binary_file drwxr-xr-x 2 root root 4096 Oct 8 07:08 【マルチバイト文字テスト】 これは tier 3 です！
NFSでもマルチバイトも文字のディレクトリを認識できました。
このタイミングでdfコマンドを叩くと、なんと/nfs配下のボリュームもマウントされていました。
$ df -ht nfs4 Filesystem Size Used Avail Use% Mounted on svm-06f51f2e59a98b1f0.fs-0ad183f269f00ec0f.fsx.us-east-1.amazonaws.com:/nfs 95G 320K 95G 1% /mnt/fsx svm-06f51f2e59a98b1f0.fs-0ad183f269f00ec0f.fsx.us-east-1.amazonaws.com:/nfs/tier1B 95G 320K 95G 1% /mnt/fsx/tier1B svm-06f51f2e59a98b1f0.fs-0ad183f269f00ec0f.fsx.us-east-1.amazonaws.com:/nfs/tier1B/tier2B 95G 1.1G 94G 2% /mnt/fsx/tier1B/tier2B
一度アンマウントして、dfコマンドを叩きながら動きを確認してみます。
# /nfs のボリュームをアンマウント
$ sudo umount /mnt/fsx/
# NFS v4でマウントされているファイルシステムがないことを確認
$ df -ht nfs4
df: no file systems processed
# マウントポイント /mnt/fsx にジャンクションパス /nfs のボリュームをマウント
$ sudo mount -t nfs svm-06f51f2e59a98b1f0.fs-0ad183f269f00ec0f.fsx.us-east-1.amazonaws.com:/nfs /mnt/fsx/
# /nfs がNFS v4 でマウントされていることを確認
$ df -ht nfs4
Filesystem Size Used Avail Use% Mounted on
svm-06f51f2e59a98b1f0.fs-0ad183f269f00ec0f.fsx.us-east-1.amazonaws.com:/nfs 95G 320K 95G 1% /mnt/fsx
# tree で /nfs 配下をツリー状に表示
$ tree /mnt/fsx/
/mnt/fsx/
├── tier1A
└── tier1B
└── tier2B
├── binary_file
└── \343\200\220\343\203\236\343\203\253\343\203\201\343\203\220\343\202\244\343\203\210\346\226\207\345\255\227\343\203\206\343\202\271\343\203\210\343\200\221\ \343\201\223\343\202\214\343\201\257\ tier\ 3\343\200\200\343\201\247\343\201\231\357\274\201
4 directories, 1 file
# NFS v4 でマウントしているファイルシステムを確認
$ df -ht nfs4
Filesystem Size Used Avail Use% Mounted on
svm-06f51f2e59a98b1f0.fs-0ad183f269f00ec0f.fsx.us-east-1.amazonaws.com:/nfs 95G 320K 95G 1% /mnt/fsx
svm-06f51f2e59a98b1f0.fs-0ad183f269f00ec0f.fsx.us-east-1.amazonaws.com:/nfs/tier1A 95G 320K 95G 1% /mnt/fsx/tier1A
svm-06f51f2e59a98b1f0.fs-0ad183f269f00ec0f.fsx.us-east-1.amazonaws.com:/nfs/tier1B 95G 320K 95G 1% /mnt/fsx/tier1B
svm-06f51f2e59a98b1f0.fs-0ad183f269f00ec0f.fsx.us-east-1.amazonaws.com:/nfs/tier1B/tier2B 95G 1.1G 94G 2% /mnt/fsx/tier1B/tier2B
svm-06f51f2e59a98b1f0.fs-0ad183f269f00ec0f.fsx.us-east-1.amazonaws.com:/nfs/tier1B/tier2B/【マルチバイト文字テスト】 これは tier 3 です！ 95G 256K 95G 1% /mnt/fsx/tier1B/tier2B/【マルチバイト文字テスト】 これは tier 3 です！
# マウントオプションを確認
$ mount | grep nfs
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime)
svm-06f51f2e59a98b1f0.fs-0ad183f269f00ec0f.fsx.us-east-1.amazonaws.com:/nfs on /mnt/fsx 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.9,local_lock=none,addr=10.0.1.56)
svm-06f51f2e59a98b1f0.fs-0ad183f269f00ec0f.fsx.us-east-1.amazonaws.com:/nfs/tier1A on /mnt/fsx/tier1A 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.9,local_lock=none,addr=10.0.1.56)
svm-06f51f2e59a98b1f0.fs-0ad183f269f00ec0f.fsx.us-east-1.amazonaws.com:/nfs/tier1B on /mnt/fsx/tier1B 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.9,local_lock=none,addr=10.0.1.56)
svm-06f51f2e59a98b1f0.fs-0ad183f269f00ec0f.fsx.us-east-1.amazonaws.com:/nfs/tier1B/tier2B on /mnt/fsx/tier1B/tier2B 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.9,local_lock=none,addr=10.0.1.56)
svm-06f51f2e59a98b1f0.fs-0ad183f269f00ec0f.fsx.us-east-1.amazonaws.com:/nfs/tier1B/tier2B/【マルチバイト文字テスト】 これは tier 3 です！ on /mnt/fsx/tier1B/tier2B/【マルチバイト文字テスト】 これは tier 3 です！ 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.9,local_lock=none,addr=10.0.1.56)
どうやら直接マウントしていないボリュームにアクセスすると、自動でマウントする動きをするようです。
それでは、このディレクトリにも書き込みできることを確認します。
# /nfs/tier1B/tier2B/【マルチバイト文字テスト】 これは tier 3 です！ 配下にバイナリファイルを作成 $ sudo dd if=/dev/urandom of=/mnt/fsx/tier1B/tier2B/【マルチバイト文字テスト】\ これは\ tier\ 3 です！/binary_file bs=1M count=2048 2048+0 records in 2048+0 records out 2147483648 bytes (2.1 GB) copied, 15.8513 s, 135 MB/s # バイナリファイルが作成されたことを確認 $ ls -l /mnt/fsx/tier1B/tier2B/【マルチバイト文字テスト】\ これは\ tier\ 3 です！/ total 2105420 -rw-r--r-- 1 root root 2147483648 Oct 8 07:19 binary_file # /nfs/tier1B/tier2B/【マルチバイト文字テスト】 これは tier 3 です！ に書き込まれたことを確認 $ df -ht nfs4 Filesystem Size Used Avail Use% Mounted on svm-06f51f2e59a98b1f0.fs-0ad183f269f00ec0f.fsx.us-east-1.amazonaws.com:/nfs 95G 320K 95G 1% /mnt/fsx svm-06f51f2e59a98b1f0.fs-0ad183f269f00ec0f.fsx.us-east-1.amazonaws.com:/nfs/tier1A 95G 320K 95G 1% /mnt/fsx/tier1A svm-06f51f2e59a98b1f0.fs-0ad183f269f00ec0f.fsx.us-east-1.amazonaws.com:/nfs/tier1B 95G 320K 95G 1% /mnt/fsx/tier1B svm-06f51f2e59a98b1f0.fs-0ad183f269f00ec0f.fsx.us-east-1.amazonaws.com:/nfs/tier1B/tier2B 95G 1.1G 94G 2% /mnt/fsx/tier1B/tier2B svm-06f51f2e59a98b1f0.fs-0ad183f269f00ec0f.fsx.us-east-1.amazonaws.com:/nfs/tier1B/tier2B/【マルチバイト文字テスト】 これは tier 3 です！ 95G 2.1G 93G 3% /mnt/fsx/tier1B/tier2B/【マルチバイト文字テスト】 これは tier 3 です！
DataSyncを使ってデータを転送する際に、ボリュームのジャンクションパスと送信するデータのディレクトリパスが同じ場合の挙動
テスト用データの用意
最後に、DataSyncを使ってデータを転送する際に、ボリュームのジャンクションパスと送信するデータのディレクトリパスが同じ場合にどのような挙動をするのか確認します。
今回はS3バケットからFSx for ONTAPへのデータを転送してみようと思うので、S3バケット上にフォルダやファイルを配置します。各フォルダとファイルは/tier1B/tier2B/【マルチバイト文字テスト】 これは tier 3 です！のように、FSx for ONTAPのジャンクションパスと一部一致するように配置しました。配置したフォルダやファイルをs3-treeで確認すると以下の通りです。
$ /home/ssm-user/.local/bin/s3-tree datasync-s3-to-fsxn-test
datasync-s3-to-fsxn-test
├── tier1A
└── tier1B
├── bin
│ └── fsx-for-ontap-windows-client.ts
└── tier2B
├── lib
│ └── fsx-for-ontap-windows-client-stack.ts
└── \343\200\220\343\203\236\343\203\253\343\203\201\343\203\220\343\202\244\343\203\210\346\226\207\345\255\227\343\203\206\343\202\271\343\203\210\343\200\221\ \343\201\223\343\202\214\343\201\257\ tier\ 3\343\200\200\343\201\247\343\201\231\357\274\201
├── package.json
└── test
└── fsx-for-ontap-windows-client.test.ts
7 directories, 4 files
なお、s3-treeはデフォルトでインストールされていません。インストールは以下記事を参考に行いました。
DataSyncのロケーションを作成
DataSyncでS3バケットからFSx for ONTAPにデータを転送します。
まず、S3バケットとFSx for ONTAPファイルシステムのロケーションを作成します。
- S3バケットのロケーション
- FSx for ONTAPのロケーション(NFS)
この流れでSMBのFSx for ONTAPのロケーションを作成しようとしましたが、No SMB endpoint configured for FSx for ONTAP SVM.とエラーになってしまいました。
これはSVMがADに参加しておらず、SMBのエンドポイントが作成されていないためです。ワークグループのCIFSサーバーの場合はDataSyncでSMBによる接続をすることができないようなので注意が必要ですね。
DataSyncでS3バケットからFSx for ONTAPにデータを転送
作成したロケーションを使用してDataSyncタスクを作成します。
送信元ロケーションにS3バケットを指定します。
送信先ロケーションにはFSx for ONTAPを指定します。
設定はログレベルのみ転送されたすべてのオブジェクトとファイルをログに記録するに変更します。その他はデフォルトです。
内容を確認して問題なければタスクを作成します。
DataSyncタスクが作成されたらアクション-デフォルトから開始するをクリックして、データ転送を開始します。
DataSyncタスクの実行結果の確認
数秒待つとDataSyncタスクの実行が正常に完了しました。
CloudWatch Logsに出力されたログも確認します。
[INFO] Request to start task-01fca1c1e103e95f3. [INFO] Started logging in destination hostId: host-08972c456b0b816c1 for Execution exec-04c6e4fd993adfa87 [INFO] Started logging in destination hostId: host-0e6d8b9c7e0040346 for Execution exec-04c6e4fd993adfa87 [INFO] Execution exec-04c6e4fd993adfa87 started. [NOTICE] Created directory /tier1B/tier2B/【マルチバイト文字テスト】 これは tier 3 です！/test [NOTICE] Created directory /tier1B/bin [NOTICE] Created directory /tier1B/tier2B/lib [NOTICE] Transferred file /tier1B/bin/fsx-for-ontap-windows-client.ts, 286 bytes [NOTICE] Transferred file /tier1B/tier2B/lib/fsx-for-ontap-windows-client-stack.ts, 11252 bytes [NOTICE] Transferred file /tier1B/tier2B/【マルチバイト文字テスト】 これは tier 3 です！/package.json, 624 bytes [NOTICE] Transferred file /tier1B/tier2B/【マルチバイト文字テスト】 これは tier 3 です！/test/fsx-for-ontap-windows-client.test.ts, 666 bytes [NOTICE] Transferred directory metadata /tier1B/tier2B [NOTICE] Transferred directory metadata /tier1B/tier2B/【マルチバイト文字テスト】 これは tier 3 です！/test [NOTICE] Transferred directory metadata /tier1B/tier2B/【マルチバイト文字テスト】 これは tier 3 です！ [NOTICE] Transferred directory metadata /tier1B/tier2B/lib [NOTICE] Transferred directory metadata /tier1B [NOTICE] Transferred directory metadata /tier1A [NOTICE] Transferred directory metadata /tier1B/bin [NOTICE] Transferred directory metadata / [NOTICE] Verified directory /tier1B/tier2B [NOTICE] Verified file /tier1B/tier2B/【マルチバイト文字テスト】 これは tier 3 です！/package.json, 624 bytes [NOTICE] Verified directory /tier1B/tier2B/【マルチバイト文字テスト】 これは tier 3 です！/test [NOTICE] Verified file /tier1B/tier2B/【マルチバイト文字テスト】 これは tier 3 です！/test/fsx-for-ontap-windows-client.test.ts, 666 bytes [NOTICE] Verified directory / [NOTICE] Verified directory /tier1A [NOTICE] Verified directory /tier1B [NOTICE] Verified directory /tier1B/bin [NOTICE] Verified file /tier1B/bin/fsx-for-ontap-windows-client.ts, 286 bytes [NOTICE] Verified directory /tier1B/tier2B/【マルチバイト文字テスト】 これは tier 3 です！ [NOTICE] Verified directory /tier1B/tier2B/lib [NOTICE] Verified file /tier1B/tier2B/lib/fsx-for-ontap-windows-client-stack.ts, 11252 bytes [INFO] Execution exec-04c6e4fd993adfa87 finished with status Success.
差分となるファイルやディレクトリが転送されていますね。また、ジャンクションパスは正しくDataSync上でもディレクトリパスとして認識されており、メタデータが上書きされていました。
EC2インスタンスからも正しく転送されているか確認してみます。
# /nfs をマウントしているマウントポイントでツリー状にディレクトリ階層を表示
$ tree /mnt/fsx/
/mnt/fsx/
├── tier1A
└── tier1B
├── bin
│ └── fsx-for-ontap-windows-client.ts
└── tier2B
├── binary_file
├── lib
│ └── fsx-for-ontap-windows-client-stack.ts
└── \343\200\220\343\203\236\343\203\253\343\203\201\343\203\220\343\202\244\343\203\210\346\226\207\345\255\227\343\203\206\343\202\271\343\203\210\343\200\221\ \343\201\223\343\202\214\343\201\257\ tier\ 3\343\200\200\343\201\247\343\201\231\357\274\201
├── binary_file
├── package.json
└── test
└── fsx-for-ontap-windows-client.test.ts
7 directories, 6 files
# マウントポイント配下のディレクトリを再帰的に確認
$ ls -lR /mnt/fsx/
/mnt/fsx/:
total 8
drwxr-xr-x 2 nobody nobody 4096 Jan 1 1970 tier1A
drwxr-xr-x 4 nobody nobody 4096 Jan 1 1970 tier1B
/mnt/fsx/tier1A:
total 0
/mnt/fsx/tier1B:
total 8
drwxr-xr-x 2 nobody nobody 4096 Jan 1 1970 bin
drwxr-xr-x 4 nobody nobody 4096 Jan 1 1970 tier2B
/mnt/fsx/tier1B/bin:
total 4
-rwxr-xr-x 1 nobody nobody 286 Jan 1 1970 fsx-for-ontap-windows-client.ts
/mnt/fsx/tier1B/tier2B:
total 1052720
-rw-r--r-- 1 root root 1073741824 Oct 8 06:55 binary_file
drwxr-xr-x 2 nobody nobody 4096 Jan 1 1970 lib
drwxr-xr-x 3 nobody nobody 4096 Jan 1 1970 【マルチバイト文字テスト】 これは tier 3 です！
/mnt/fsx/tier1B/tier2B/lib:
total 12
-rwxr-xr-x 1 nobody nobody 11252 Jan 1 1970 fsx-for-ontap-windows-client-stack.ts
/mnt/fsx/tier1B/tier2B/【マルチバイト文字テスト】 これは tier 3 です！:
total 2105428
-rw-r--r-- 1 root root 2147483648 Oct 8 07:19 binary_file
-rwxr-xr-x 1 nobody nobody 624 Jan 1 1970 package.json
drwxr-xr-x 2 nobody nobody 4096 Jan 1 1970 test
/mnt/fsx/tier1B/tier2B/【マルチバイト文字テスト】 これは tier 3 です！/test:
total 4
-rwxr-xr-x 1 nobody nobody 666 Jan 1 1970 fsx-for-ontap-windows-client.test.ts
$
正しく転送されていそうです。また所有者はrootからnododyに変わっており、権限は644から755となっていますね。
最後に転送したファイルを表示してみます。
$ cat /mnt/fsx/tier1B/tier2B/【マルチバイト文字テスト】\ これは\ tier\ 3 です！/test/fsx-for-ontap-windows-client.test.ts
// import * as cdk from 'aws-cdk-lib';
// import { Template } from 'aws-cdk-lib/assertions';
// import * as FsxForOntapWindowsClient from '../lib/fsx-for-ontap-windows-client-stack';
// example test. To run these tests, uncomment this file along with the
// example resource in lib/fsx-for-ontap-windows-client-stack.ts
test('SQS Queue Created', () => {
// const app = new cdk.App();
// // WHEN
// const stack = new FsxForOntapWindowsClient.FsxForOntapWindowsClientStack(app, 'MyTestStack');
// // THEN
// const template = Template.fromStack(stack);
// template.hasResourceProperties('AWS::SQS::Queue', {
// VisibilityTimeout: 300
// });
});
問題なく表示できていますね。
ジャンクションパスを使いこなそう
Amazon FSx for NetApp ONTAPのボリュームのジャンクションパスが階層構造になっている時の挙動を確認してみました。
あるディレクトリの階層化ポリシーを変更したり、1ディレクトリのサイズがTB級である場合は、ボリュームを分割することになると思います。
そのような場合はジャンクションパスを上手に使ってボリュームを分けることで、ユーザーにボリュームが別れていることを意識させずにファイルサーバーとしての機能を提供できそうですね。
ただし、マルチバイト文字を含むジャンクションパスをAWSとしてはサポートしていないため、既存のファイルサーバーからFSx for ONTAPに移行する際はボリュームのマウントポイントを英数字にすることが無難と考えます。
この記事が誰かの助けになれば幸いです。
以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!
![[アップデート] Amazon DocumentDB のインスタンスベースクラスターが AWS Secrets Manager を使ったパスワード管理の統合をサポートしました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-d68351ceabdf61da8b5199452e233293/a147805341404e59db51dd45b7f0f380/amazon-documentdb)
![[レポート] VPC Lattice と PrivateLink を利用したクロス VPC リソースアクセス「Simplify cross-VPC resource access with PrivateLink and VPC Lattice」 #NET218](https://images.ctfassets.net/ct0aopd36mqt/3IQLlbdUkRvu7Q2LupRW2o/edff8982184ea7cc2d5efa2ddd2915f5/reinvent-2024-sessionreport-jp.jpg)
