![[アップデート] Amazon FSx for NetApp ONTAPでファイルシステムのストレージとスループットキャパシティの変更ができるようになりました](https://devio2023-media.developers.io/wp-content/uploads/2022/05/amazon-fsx-for-NetApp-ONTAP.png)
[アップデート] Amazon FSx for NetApp ONTAPでファイルシステムのストレージとスループットキャパシティの変更ができるようになりました
後から設定変えたいな
こんにちは、のんピ(@non____97)です。
皆さんは緻密な計画を立てることは得意ですか? 私は得意ではありません。
クラウドを利用するようになって、数年後を見越した厳密なプロビジョニングをする必要がある場面に遭遇することが減り、ありがたい限りです。
そんな折、Amazon FSx for NetApp ONTAPでファイルシステムのストレージとスループットキャパシティの変更ができるようになりました。
これにより、Amazon FSx for NetApp ONTAPファイルシステムを使う場合の「当初想定よりも性能が求められた」や「保存しているデータが増えてきてストレージの空き容量が足りなくなってきた」といった悩みから解放されそうです。
こちらのアップデートについて検証してみたので紹介します。
いきなりまとめ
- ファイルシステムのストレージとスループットキャパシティの変更ができるようになった
- ストレージキャパシティ変更の注意点は以下の通り
- ファイルシステムのストレージキャパシティを 増加のみ 可能
- ストレージキャパシティを減らすことはできない
- ストレージキャパシティを増加させる際はファイルシステムの現在のストレージキャパシティの最低10％を指定する必要がある
- 最大値は 196,608GiB
- 最後のストレージキャパシティ増加がリクエストされてから6時間後、またはストレージの最適化プロセスが完了するまでのどちらか長い期間は、ファイルシステムのストレージキャパシティをさらに増やすことはできない
- ファイルシステムのストレージを変更してもボリュームには反映されない
- ボリュームのサイズは伸縮可能
- ボリュームはThin Provisioningで、ファイルシステムのストレージキャパシティ以上のサイズを指定可能
- スループットキャパシティを変更することで以下の値が変動する
- ネットワークスループット
- ネットワークIOPS
- インメモリキャッシュ
- NVMeキャッシュ
- ディスクスループット
- SSD IOPS
- スループットキャパシティ変更時は自動フェイルオーバーとフェイルバックが発生する
アップデート内容の確認
ストレージキャパシティ
まず、ストレージキャパシティのアップデート内容を確認します。
Amazon FSx for NetApp ONTAPファイルシステムのSSDストレージキャパシティを増やせるようになりました。
ストレージキャパシティの変更は数分で完了するようなので、すぐに空き容量を確保したい時にありがたいですね。
Amazon FSx ファイルシステムの SSd ストレージ容量を増やすと、新しい容量は数分以内に使用できます。
ストレージキャパシティはCloudWatchメトリクスで監視できます。「空き容量不足で業務が中断した」といった事態にならないように、一定の閾値を超えたら通知するようなCloudWatchアラームを準備するのが良さそうです。
使用可能なプライマリ階層ストレージが不足している場合は、ファイルシステムのストレージ容量を増やすことをお勧めします。ストレージが不足すると、データセットのアクティブな部分のプライマリ層のサイズが小さくなることを示します。
ファイルシステム上で利用可能な空きストレージの量をモニタリングするには、ファイルシステムレベル StorageCapacity と StorageUsed Amazon CloudWatch メトリクスを使用します。このメトリクスで CloudWatch アラームを作成し、特定のしきい値を下回ったときに通知を受け取ることができます。詳細については、「Amazon CloudWatch によるモニタリング」を参照してください
ストレージキャパシティとIOPS変更時の考慮ポイントは以下の通りです。
- Storage capacity increase only :
- ファイルシステムのストレージキャパシティを 増加のみ 可能
- ストレージキャパシティを減らすことはできない
- Storage capacity minimum increase :
- ストレージキャパシティを増加させる際はファイルシステムの現在のストレージキャパシティの最低10％を指定する必要がある
- 最大値は 196,608GiB
- Time between increases :
- 最後のストレージキャパシティ増加がリクエストされてから6時間後、またはストレージの最適化プロセスが完了するまでのどちらか長い期間は、ファイルシステムのストレージキャパシティをさらに増やすことはできない
- Provisioned IOPS modes
- プロビジョンド IOPS の変更について、以下どちらかのモードを指定する必要がある
- Automaticモード : 3 IOPS/GBでIOPSが設定される。最大は80,000 IOPS
- User-provisionedモード : 3 IOPS/GB以上のIOPSを指定する
スループットキャパシティ
続いて、スループットキャパシティについてです。
スループットキャパシティを以下の中から選択して変更できるようになりました。
- 128MBps
- 256MBps
- 512MBps
- 1,024MBps
- 2,048MBps
スループットキャパシティはネットワークI/Oパフォーマンスのレベル = ファイルサーバーがネットワーク経由でファイルデータにアクセスするクライアントに提供できる速度を示す設定値です。スループットキャパシティを変更することで以下の値が変動します。
- ネットワークスループット
- ネットワークIOPS
- インメモリキャッシュ
- NVMeキャッシュ
- ディスクスループット
- SSD IOPS
各スループットキャパシティ毎の値は以下AWS公式ドキュメントの表をご覧ください。
ファイルシステムの作成
作成するリソースの整理
前回の記事ではマネージメントコンソールからファイルシステムを作成しました。
同じ手順ではつまらないので、今回はAWS CLIでファイルシステムを作成してみます。
なお、AWS CLIでファイルシステムを作成してもストレージ仮想マシン(SVM)とボリュームは自動で作成されません。そのため、OSにボリュームをマウントできるように以下順番でリソースを作成してあげる必要があります。
- ファイルシステムの作成
- SVMの作成
- ボリュームの作成
ファイルシステムの作成
それでは、ファイルシステムの作成を行います。
ファイルシステムの作成はcreate-file-systemで行います。
いきなりAWS CLIでファイルシステムを作成するのもかなり大変なので、CLIスケルトンを確認してから各種パタメーターをJSONで指定してあげます。
CLIスケルトンの使い方は以下記事が参考になります。
まず、create-file-systemのCLIスケルトンを以下コマンドで確認します。
$ aws fsx create-file-system \
> --generate-cli-skeleton
{
"ClientRequestToken": "",
"FileSystemType": "OPENZFS",
"StorageCapacity": 0,
"StorageType": "HDD",
"SubnetIds": [
""
],
"SecurityGroupIds": [
""
],
"Tags": [
{
"Key": "",
"Value": ""
}
],
"KmsKeyId": "",
"WindowsConfiguration": {
"ActiveDirectoryId": "",
"SelfManagedActiveDirectoryConfiguration": {
"DomainName": "",
"OrganizationalUnitDistinguishedName": "",
"FileSystemAdministratorsGroup": "",
"UserName": "",
"Password": "",
"DnsIps": [
""
]
},
"DeploymentType": "SINGLE_AZ_1",
"PreferredSubnetId": "",
"ThroughputCapacity": 0,
"WeeklyMaintenanceStartTime": "",
"DailyAutomaticBackupStartTime": "",
"AutomaticBackupRetentionDays": 0,
"CopyTagsToBackups": true,
"Aliases": [
""
],
"AuditLogConfiguration": {
"FileAccessAuditLogLevel": "SUCCESS_ONLY",
"FileShareAccessAuditLogLevel": "DISABLED",
"AuditLogDestination": ""
}
},
"LustreConfiguration": {
"WeeklyMaintenanceStartTime": "",
"ImportPath": "",
"ExportPath": "",
"ImportedFileChunkSize": 0,
"DeploymentType": "SCRATCH_2",
"AutoImportPolicy": "NEW_CHANGED",
"PerUnitStorageThroughput": 0,
"DailyAutomaticBackupStartTime": "",
"AutomaticBackupRetentionDays": 0,
"CopyTagsToBackups": true,
"DriveCacheType": "READ",
"DataCompressionType": "NONE",
"LogConfiguration": {
"Level": "ERROR_ONLY",
"Destination": ""
}
},
"OntapConfiguration": {
"AutomaticBackupRetentionDays": 0,
"DailyAutomaticBackupStartTime": "",
"DeploymentType": "SINGLE_AZ_1",
"EndpointIpAddressRange": "",
"FsxAdminPassword": "",
"DiskIopsConfiguration": {
"Mode": "USER_PROVISIONED",
"Iops": 0
},
"PreferredSubnetId": "",
"RouteTableIds": [
""
],
"ThroughputCapacity": 0,
"WeeklyMaintenanceStartTime": ""
},
"FileSystemTypeVersion": "",
"OpenZFSConfiguration": {
"AutomaticBackupRetentionDays": 0,
"CopyTagsToBackups": true,
"CopyTagsToVolumes": true,
"DailyAutomaticBackupStartTime": "",
"DeploymentType": "SINGLE_AZ_1",
"ThroughputCapacity": 0,
"WeeklyMaintenanceStartTime": "",
"DiskIopsConfiguration": {
"Mode": "USER_PROVISIONED",
"Iops": 0
},
"RootVolumeConfiguration": {
"RecordSizeKiB": 0,
"DataCompressionType": "LZ4",
"NfsExports": [
{
"ClientConfigurations": [
{
"Clients": "",
"Options": [
""
]
}
]
}
],
"UserAndGroupQuotas": [
{
"Type": "GROUP",
"Id": 0,
"StorageCapacityQuotaGiB": 0
}
],
"CopyTagsToSnapshots": true,
"ReadOnly": true
}
}
}
表示されたJSONをベースに、作成するファイルシステムのパラメーターのJSONを用意します。
$ filesystem_name=classmethod-dev-fsx-netapp-ontap-filesystem-single-az
$ subnet_id=subnet-xxxx
$ security_group_id=sg-xxxx
$ fsx_admin_password='xxxx'
create_file_system_input=$(cat <<EOM
{
"FileSystemType": "ONTAP",
"StorageCapacity": 1024,
"StorageType": "SSD",
"SubnetIds": [
"$subnet_id"
],
"SecurityGroupIds": [
"$security_group_id"
],
"Tags": [
{
"Key": "Name",
"Value": "$filesystem_name"
}
],
"OntapConfiguration": {
"AutomaticBackupRetentionDays": 7,
"DailyAutomaticBackupStartTime": "16:00",
"DeploymentType": "SINGLE_AZ_1",
"FsxAdminPassword": "$fsx_admin_password",
"DiskIopsConfiguration": {
"Mode": "AUTOMATIC"
},
"ThroughputCapacity": 128,
"WeeklyMaintenanceStartTime": "6:17:00"
}
}
EOM
)
用意したJSONをcreate-file-systemのパラメーターとして指定して実行します。
$ create_file_system_output=$(aws fsx create-file-system \
--cli-input-json "$create_file_system_input"
)
実行結果を確認すると以下のようになります。確かにファイルシステムの作成が開始していそうです。
$ echo $create_file_system_output \
| jq -r
{
"FileSystem": {
"OwnerId": "<AWSアカウントID>",
"CreationTime": "2022-05-18T01:21:22.777000+00:00",
"FileSystemId": "fs-005d4c8343b8e32de",
"FileSystemType": "ONTAP",
"Lifecycle": "CREATING",
"StorageCapacity": 1024,
"StorageType": "SSD",
"VpcId": "vpc-xxxx",
"SubnetIds": [
"subnet-xxxx"
],
"KmsKeyId": "arn:aws:kms:ap-northeast-1:<AWSアカウントID>:key/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"ResourceARN": "arn:aws:fsx:ap-northeast-1:<AWSアカウントID>:file-system/fs-005d4c8343b8e32de",
"Tags": [
{
"Key": "Name",
"Value": "classmethod-dev-fsx-netapp-ontap-filesystem-single-az"
}
],
"OntapConfiguration": {
"AutomaticBackupRetentionDays": 7,
"DailyAutomaticBackupStartTime": "16:00",
"DeploymentType": "SINGLE_AZ_1",
"Endpoints": {
"Intercluster": {
"DNSName": "intercluster.fs-005d4c8343b8e32de.fsx.ap-northeast-1.amazonaws.com"
},
"Management": {
"DNSName": "management.fs-005d4c8343b8e32de.fsx.ap-northeast-1.amazonaws.com"
}
},
"DiskIopsConfiguration": {
"Mode": "AUTOMATIC",
"Iops": 3072
},
"PreferredSubnetId": "subnet-xxxx",
"ThroughputCapacity": 128,
"WeeklyMaintenanceStartTime": "6:17:00"
}
}
}
25分ほど待つと、ファイルシステムの作成が完了しました。
$ filesystem_id=$(echo $create_file_system_output \
| jq -r ".FileSystem.FileSystemId"
)
$ aws fsx describe-file-systems \
--file-system-ids "$filesystem_id"
{
"FileSystems": [
{
"OwnerId": "<AWSアカウントID>",
"CreationTime": "2022-05-18T01:46:22.782000+00:00",
"FileSystemId": "fs-005d4c8343b8e32de",
"FileSystemType": "ONTAP",
"Lifecycle": "AVAILABLE",
"StorageCapacity": 1024,
"StorageType": "SSD",
"VpcId": "vpc-xxxx",
"SubnetIds": [
"subnet-xxxx"
],
"NetworkInterfaceIds": [
"eni-0a1b6df97f82d25f0",
"eni-07970a960e5112831"
],
"KmsKeyId": "arn:aws:kms:ap-northeast-1:<AWSアカウントID>:key/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"ResourceARN": "arn:aws:fsx:ap-northeast-1:<AWSアカウントID>:file-system/fs-005d4c8343b8e32de",
"Tags": [
{
"Key": "Name",
"Value": "classmethod-dev-fsx-netapp-ontap-filesystem-single-az"
}
],
"OntapConfiguration": {
"AutomaticBackupRetentionDays": 7,
"DailyAutomaticBackupStartTime": "16:00",
"DeploymentType": "SINGLE_AZ_1",
"Endpoints": {
"Intercluster": {
"DNSName": "intercluster.fs-005d4c8343b8e32de.fsx.ap-northeast-1.amazonaws.com",
"IpAddresses": [
"10.0.10.22",
"10.0.10.152"
]
},
"Management": {
"DNSName": "management.fs-005d4c8343b8e32de.fsx.ap-northeast-1.amazonaws.com",
"IpAddresses": [
"10.0.10.56"
]
}
},
"DiskIopsConfiguration": {
"Mode": "AUTOMATIC",
"Iops": 3072
},
"PreferredSubnetId": "subnet-xxxx",
"ThroughputCapacity": 128,
"WeeklyMaintenanceStartTime": "6:17:00"
}
}
]
}
SVMの作成
ファイルシステムの作成が完了したので、次にSVMの作成です。
SVMの作成をする前にも以下コマンドでCLIスケルトンを確認します。
$ aws fsx create-storage-virtual-machine \
--generate-cli-skeleton
{
"ActiveDirectoryConfiguration": {
"NetBiosName": "",
"SelfManagedActiveDirectoryConfiguration": {
"DomainName": "",
"OrganizationalUnitDistinguishedName": "",
"FileSystemAdministratorsGroup": "",
"UserName": "",
"Password": "",
"DnsIps": [
""
]
}
},
"ClientRequestToken": "",
"FileSystemId": "",
"Name": "",
"SvmAdminPassword": "",
"Tags": [
{
"Key": "",
"Value": ""
}
],
"RootVolumeSecurityStyle": "UNIX"
}
表示されたJSONをベースに、作成するSVMのパラメーターのJSONを用意します。
$ svm_name=classmethod-dev-fsx-netapp-ontap-single-az-svm
$ net_bios_name=SINGLE-AZ-SVM
$ domain_name=fsx-dev.classmethod.jp
$ organizational_unit_distinguished_name='OU=FSxForNetAppONTAP,DC=fsx-dev,DC=classmethod,DC=jp'
$ filesystem_administrators_group=FSxAdminGroup
$ service_account_user_name=FSxServiceAccount
$ service_account_password='xxxx'
$ dns_ip=10.0.0.138
$ svm_admin_password='xxxx'
create_storage_virtual_machine_input=$(cat <<EOM
{
"ActiveDirectoryConfiguration": {
"NetBiosName": "$net_bios_name",
"SelfManagedActiveDirectoryConfiguration": {
"DomainName": "$domain_name",
"OrganizationalUnitDistinguishedName": "$organizational_unit_distinguished_name",
"FileSystemAdministratorsGroup": "$filesystem_administrators_group",
"UserName": "$service_account_user_name",
"Password": "$service_account_password",
"DnsIps": [
"$dns_ip"
]
}
},
"FileSystemId": "$filesystem_id",
"Name": "$svm_name",
"SvmAdminPassword": "$svm_admin_password",
"Tags": [
{
"Key": "Name",
"Value": "$svm_name"
}
],
"RootVolumeSecurityStyle": "MIXED"
}
EOM
)
用意したJSONをcreate-storage-virtual-machineのパラメーターとして指定して実行します。
$ create_storage_virtual_machine_output=$(aws fsx create-storage-virtual-machine \
--cli-input-json "$create_storage_virtual_machine_input"
)
実行結果を確認すると以下のようになります。確かにSVMの作成を受け付けていそうです。
$ echo $create_storage_virtual_machine_output \
| jq -r
{
"StorageVirtualMachine": {
"ActiveDirectoryConfiguration": {
"NetBiosName": "SINGLE-AZ-SVM",
"SelfManagedActiveDirectoryConfiguration": {
"DomainName": "fsx-dev.classmethod.jp",
"OrganizationalUnitDistinguishedName": "OU=FSxForNetAppONTAP,DC=fsx-dev,DC=classmethod,DC=jp",
"UserName": "FSxServiceAccount",
"DnsIps": [
"10.0.0.138"
]
}
},
"CreationTime": "2022-05-18T02:14:09.094000+00:00",
"Endpoints": {
"Iscsi": {
"DNSName": "iscsi.svm-0373dd4ba425ecc61.fs-005d4c8343b8e32de.fsx.ap-northeast-1.amazonaws.com"
},
"Management": {
"DNSName": "svm-0373dd4ba425ecc61.fs-005d4c8343b8e32de.fsx.ap-northeast-1.amazonaws.com"
},
"Nfs": {
"DNSName": "svm-0373dd4ba425ecc61.fs-005d4c8343b8e32de.fsx.ap-northeast-1.amazonaws.com"
},
"Smb": {
"DNSName": "SINGLE-AZ-SVM.fsx-dev.classmethod.jp"
}
},
"FileSystemId": "fs-005d4c8343b8e32de",
"Lifecycle": "PENDING",
"Name": "classmethod-dev-fsx-netapp-ontap-single-az-svm",
"ResourceARN": "arn:aws:fsx:ap-northeast-1:<AWSアカウントID>:storage-virtual-machine/fs-005d4c8343b8e32de/svm-0373dd4ba425ecc61",
"StorageVirtualMachineId": "svm-0373dd4ba425ecc61",
"Subtype": "DEFAULT",
"Tags": [
{
"Key": "Name",
"Value": "classmethod-dev-fsx-netapp-ontap-single-az-svm"
}
]
}
}
10分ほど待つと、SVMの作成が完了しました。
$ svm_id=$(echo $create_storage_virtual_machine_output \
| jq -r ".StorageVirtualMachine.StorageVirtualMachineId"
)
$ aws fsx describe-storage-virtual-machines \
--storage-virtual-machine-ids "$svm_id"
{
"StorageVirtualMachines": [
{
"ActiveDirectoryConfiguration": {
"NetBiosName": "SINGLE-AZ-SVM",
"SelfManagedActiveDirectoryConfiguration": {
"DomainName": "fsx-dev.classmethod.jp",
"OrganizationalUnitDistinguishedName": "OU=FSxForNetAppONTAP,DC=fsx-dev,DC=classmethod,DC=jp",
"UserName": "FSxServiceAccount",
"DnsIps": [
"10.0.0.138"
]
}
},
"CreationTime": "2022-05-18T02:14:09.094000+00:00",
"Endpoints": {
"Iscsi": {
"DNSName": "iscsi.svm-0373dd4ba425ecc61.fs-005d4c8343b8e32de.fsx.ap-northeast-1.amazonaws.com",
"IpAddresses": [
"10.0.10.74",
"10.0.10.199"
]
},
"Management": {
"DNSName": "svm-0373dd4ba425ecc61.fs-005d4c8343b8e32de.fsx.ap-northeast-1.amazonaws.com",
"IpAddresses": [
"10.0.10.18"
]
},
"Nfs": {
"DNSName": "svm-0373dd4ba425ecc61.fs-005d4c8343b8e32de.fsx.ap-northeast-1.amazonaws.com",
"IpAddresses": [
"10.0.10.18"
]
},
"Smb": {
"DNSName": "SINGLE-AZ-SVM.fsx-dev.classmethod.jp",
"IpAddresses": [
"10.0.10.18"
]
}
},
"FileSystemId": "fs-005d4c8343b8e32de",
"Lifecycle": "CREATED",
"Name": "classmethod-dev-fsx-netapp-ontap-single-az-svm",
"ResourceARN": "arn:aws:fsx:ap-northeast-1:<AWSアカウントID>:storage-virtual-machine/fs-005d4c8343b8e32de/svm-0373dd4ba425ecc61",
"StorageVirtualMachineId": "svm-0373dd4ba425ecc61",
"Subtype": "DEFAULT",
"UUID": "3776bdda-d650-11ec-9740-0728d01982a2"
}
]
}
こちらのSVMのボリュームを確認すると、ルートボリュームが1つ作成されていました。
$ aws fsx describe-volumes \
--filters Name=storage-virtual-machine-id,Values="$svm_id"
{
"Volumes": [
{
"CreationTime": "2022-05-18T02:14:33+00:00",
"FileSystemId": "fs-005d4c8343b8e32de",
"Lifecycle": "CREATED",
"Name": "classmethod_dev_fsx_netapp_ontap_single_az_svm_root",
"OntapConfiguration": {
"FlexCacheEndpointType": "NONE",
"JunctionPath": "/",
"SecurityStyle": "MIXED",
"SizeInMegabytes": 1024,
"StorageEfficiencyEnabled": false,
"StorageVirtualMachineId": "svm-0373dd4ba425ecc61",
"StorageVirtualMachineRoot": true,
"TieringPolicy": {
"Name": "NONE"
},
"UUID": "41caaa85-d650-11ec-95af-f3d7842b1bd0",
"OntapVolumeType": "RW"
},
"ResourceARN": "arn:aws:fsx:ap-northeast-1:<AWSアカウントID>:volume/fs-005d4c8343b8e32de/fsvol-0f5e8dcc8113af4cc",
"VolumeId": "fsvol-0f5e8dcc8113af4cc",
"VolumeType": "ONTAP"
}
]
}
AWS公式ドキュメントのSVMについての説明を見ると、ルートボリュームを使うことはオススメされていないので、別途ボリュームを用意してあげます。
すべてのストレージ仮想マシンには、名前空間階層の最上位レベルに ルートボリューム (/) があり、SVM で作成するボリュームのジャンクションパス (マウントポイントとも呼ばれる) を格納しています。ルートボリュームにはユーザーデータを保存しないことをお勧めしますが、ストレージ仮想マシン内にいつでも追加のボリュームを作成できます。
ボリュームの作成
それではボリュームの作成を行います。
ボリュームの作成をする前にも以下コマンドでCLIスケルトンを確認します。
$ aws fsx create-volume \
--generate-cli-skeleton
{
"ClientRequestToken": "",
"VolumeType": "OPENZFS",
"Name": "",
"OntapConfiguration": {
"JunctionPath": "",
"SecurityStyle": "MIXED",
"SizeInMegabytes": 0,
"StorageEfficiencyEnabled": true,
"StorageVirtualMachineId": "",
"TieringPolicy": {
"CoolingPeriod": 0,
"Name": "ALL"
}
},
"Tags": [
{
"Key": "",
"Value": ""
}
],
"OpenZFSConfiguration": {
"ParentVolumeId": "",
"StorageCapacityReservationGiB": 0,
"StorageCapacityQuotaGiB": 0,
"RecordSizeKiB": 0,
"DataCompressionType": "LZ4",
"CopyTagsToSnapshots": true,
"OriginSnapshot": {
"SnapshotARN": "",
"CopyStrategy": "FULL_COPY"
},
"ReadOnly": true,
"NfsExports": [
{
"ClientConfigurations": [
{
"Clients": "",
"Options": [
""
]
}
]
}
],
"UserAndGroupQuotas": [
{
"Type": "GROUP",
"Id": 0,
"StorageCapacityQuotaGiB": 0
}
]
}
}
表示されたJSONをベースに、作成するボリュームのパラメーターのJSONを用意します。
volume_name=classmethod_dev_fsx_netapp_ontap_single_az_volume_share
junction_path='/share'
volume_size=1024
create_volume_input=$(cat <<EOM
{
"VolumeType": "ONTAP",
"Name": "$volume_name",
"OntapConfiguration": {
"JunctionPath": "$junction_path",
"SecurityStyle": "MIXED",
"SizeInMegabytes": $volume_size,
"StorageEfficiencyEnabled": true,
"StorageVirtualMachineId": "$svm_id",
"TieringPolicy": {
"CoolingPeriod": 31,
"Name": "AUTO"
}
},
"Tags": [
{
"Key": "Name",
"Value": "$volume_name"
}
]
}
EOM
)
用意したJSONをcreate-volumeのパラメーターとして指定して実行します。
$ create_volume_output=$(aws fsx create-volume \
--cli-input-json "$create_volume_input"
)
実行結果を確認すると以下のようになります。確かにボリュームの作成を開始していそうです。
$ echo $create_volume_output \
| jq -r
{
"Volume": {
"CreationTime": "2022-05-18T02:39:33.023000+00:00",
"FileSystemId": "fs-005d4c8343b8e32de",
"Lifecycle": "CREATING",
"Name": "classmethod_dev_fsx_netapp_ontap_single_az_volume_share",
"OntapConfiguration": {
"FlexCacheEndpointType": "NONE",
"JunctionPath": "/share",
"SecurityStyle": "MIXED",
"SizeInMegabytes": 1024,
"StorageEfficiencyEnabled": true,
"StorageVirtualMachineId": "svm-0373dd4ba425ecc61",
"StorageVirtualMachineRoot": false,
"TieringPolicy": {
"CoolingPeriod": 31,
"Name": "AUTO"
},
"OntapVolumeType": "RW"
},
"ResourceARN": "arn:aws:fsx:ap-northeast-1:<AWSアカウントID>:volume/fs-005d4c8343b8e32de/fsvol-032b46c1b745a1bf5",
"Tags": [
{
"Key": "Name",
"Value": "classmethod_dev_fsx_netapp_ontap_single_az_volume_share"
}
],
"VolumeId": "fsvol-032b46c1b745a1bf5",
"VolumeType": "ONTAP"
}
}
少し待つと、ボリュームの作成が完了しました。
$ aws fsx describe-volumes \
> --volume-ids "$volume_id"
{
"Volumes": [
{
"CreationTime": "2022-05-18T02:39:33.023000+00:00",
"FileSystemId": "fs-005d4c8343b8e32de",
"Lifecycle": "CREATED",
"Name": "classmethod_dev_fsx_netapp_ontap_single_az_volume_share",
"OntapConfiguration": {
"FlexCacheEndpointType": "NONE",
"JunctionPath": "/share",
"SecurityStyle": "MIXED",
"SizeInMegabytes": 1024,
"StorageEfficiencyEnabled": true,
"StorageVirtualMachineId": "svm-0373dd4ba425ecc61",
"StorageVirtualMachineRoot": false,
"TieringPolicy": {
"CoolingPeriod": 31,
"Name": "AUTO"
},
"UUID": "c442a9c5-d653-11ec-9740-0728d01982a2",
"OntapVolumeType": "RW"
},
"ResourceARN": "arn:aws:fsx:ap-northeast-1:<AWSアカウントID>:volume/fs-005d4c8343b8e32de/fsvol-032b46c1b745a1bf5",
"VolumeId": "fsvol-032b46c1b745a1bf5",
"VolumeType": "ONTAP"
}
]
}
OSへのマウント
Windows Server
それでは、作成されボリュームをOSにマウントします。
せっかくSVMをドメイン参加させたので、Windows Server(SMB)と、Amazon Linux 2(NFS)でそれぞれ接続します。
まずはWindows Serverからです。
> Get-PSDrive Name Used (GB) Free (GB) Provider Root CurrentLocation ---- --------- --------- -------- ---- --------------- Alias Alias C 14.65 15.35 FileSystem C:\ Windows\system32 Cert Certificate \ Env Environment Function Function HKCU Registry HKEY_CURRENT_USER HKLM Registry HKEY_LOCAL_MACHINE Variable Variable WSMan WSMan > net use Z: \\SINGLE-AZ-SVM.fsx-dev.classmethod.jp\C$\share 'SINGLE-AZ-SVM.fsx-dev.classmethod.jp' のユーザー名を入力してください: fsx-dev.classmethod.jp\FSxAdmin SINGLE-AZ-SVM.fsx-dev.classmethod.jp のパスワードを入力してください: コマンドは正常に終了しました。 > Get-PSDrive Name Used (GB) Free (GB) Provider Root CurrentLocation ---- --------- --------- -------- ---- --------------- Alias Alias C 14.66 15.34 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 0.95 FileSystem \\SINGLE-AZ-SVM.fsx-dev.classmet...
Zドライブにボリュームをマウントできました。
こちらのボリュームに空フォルダを作成しておきます。
> New-Item z:\non-97 -type directory
ディレクトリ: Z:\
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 2022/05/18 3:00 non-97
Amazon Linux 2
続いて、Amazon Linux 2からボリュームをマウントします。
# マウント前のディスクサイズの確認 $ df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 462M 0 462M 0% /dev tmpfs 470M 0 470M 0% /dev/shm tmpfs 470M 344K 470M 1% /run tmpfs 470M 0 470M 0% /sys/fs/cgroup /dev/nvme0n1p1 8.0G 1.6G 6.5G 20% / # マウントポイントの作成 $ sudo mkdir /fsx-share # マウント $ sudo mount -t nfs svm-0373dd4ba425ecc61.fs-005d4c8343b8e32de.fsx.ap-northeast-1.amazonaws.com:/share /fsx-share # マウント後のディスクサイズの確認 $ df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 462M 0 462M 0% /dev tmpfs 470M 0 470M 0% /dev/shm tmpfs 470M 348K 470M 1% /run tmpfs 470M 0 470M 0% /sys/fs/cgroup /dev/nvme0n1p1 8.0G 1.6G 6.5G 20% / svm-0373dd4ba425ecc61.fs-005d4c8343b8e32de.fsx.ap-northeast-1.amazonaws.com:/share 973M 320K 973M 1% /fsx-share # マウント情報の確認 $ mount sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) devtmpfs on /dev type devtmpfs (rw,nosuid,size=472592k,nr_inodes=118148,mode=755) securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755) tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd) pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct) cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb) cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio) cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids) cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) /dev/nvme0n1p1 on / type xfs (rw,noatime,attr2,inode64,logbufs=8,logbsize=32k,noquota) debugfs on /sys/kernel/debug type debugfs (rw,relatime) hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M) systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=32,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=12692) mqueue on /dev/mqueue type mqueue (rw,relatime) sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime) svm-0373dd4ba425ecc61.fs-005d4c8343b8e32de.fsx.ap-northeast-1.amazonaws.com:/share on /fsx-share 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.0.93,local_lock=none,addr=10.0.10.18) tmpfs on /run/user/0 type tmpfs (rw,nosuid,nodev,relatime,size=96224k,mode=700)
/fsx-shareにボリュームをマウントできました。
/fsx-share内を確認すると、Windows Serverで作成したディレクトリが表示されました。
$ ls -l /fsx-share/ total 4 drwxr-xr-x 2 root daemon 4096 May 18 03:00 non-97
SMB、NFSどちらのプロトコルを使っても接続できるのはかなりありがたいですね。
ちなみにAmazon Linux 2はドメイン参加していないため、ファイルを作成しようとしても権限が足りず怒られます。
$ touch /fsx-share/non-97-test touch: cannot touch ‘/fsx-share/non-97-test’: Permission denied
ファイルシステムのストレージキャパシティの変更
それでは本題のファイルシステムとストレージとスループットキャパシティの変更です。
まずはファイルシステムのストレージキャパシティの確認です。
こちらの作業はマネージメントコンソールから行います。
FSxのコンソールから対象のファイルシステムを選択し、SSDストレージキャパシティ横の更新をクリックします。
SSDストレージキャパシティとIOPS更新の画面が表示されます。今回はデフォルトで指定されていた増加率10%でストレージキャパシティを拡張します。問題なければ拡張をクリックします。
拡張クリック後は1024 GiB (1127 GiB へ更新)と表示されていましたが、2分ほど待つと更新が完了しました。爆速ですね。
メトリクスから使用可能なプライマリストレージキャパシティを確認すると、確かにストレージキャパシティが増えたことを確認できます。
ちなみに、6時間以内にストレージキャパシティを再度拡張しようとすると、「ストレージ容量の更新を実行できません。既に進行中のリクエストがあります。」と表示され、拡張することができません。
なお、ファイルシステムを拡張してもボリュームは自動で拡張されません。
$ aws fsx describe-volumes \
--filters Name=storage-virtual-machine-id,Values="$svm_id"
{
"Volumes": [
{
"CreationTime": "2022-05-18T02:14:33+00:00",
"FileSystemId": "fs-005d4c8343b8e32de",
"Lifecycle": "CREATED",
"Name": "classmethod_dev_fsx_netapp_ontap_single_az_svm_root",
"OntapConfiguration": {
"FlexCacheEndpointType": "NONE",
"JunctionPath": "/",
"SecurityStyle": "MIXED",
"SizeInMegabytes": 1024,
"StorageEfficiencyEnabled": false,
"StorageVirtualMachineId": "svm-0373dd4ba425ecc61",
"StorageVirtualMachineRoot": true,
"TieringPolicy": {
"Name": "NONE"
},
"UUID": "41caaa85-d650-11ec-95af-f3d7842b1bd0",
"OntapVolumeType": "RW"
},
"ResourceARN": "arn:aws:fsx:ap-northeast-1:<AWSアカウントID>:volume/fs-005d4c8343b8e32de/fsvol-0f5e8dcc8113af4cc",
"VolumeId": "fsvol-0f5e8dcc8113af4cc",
"VolumeType": "ONTAP"
},
{
"CreationTime": "2022-05-18T02:39:33.023000+00:00",
"FileSystemId": "fs-005d4c8343b8e32de",
"Lifecycle": "CREATED",
"Name": "classmethod_dev_fsx_netapp_ontap_single_az_volume_share",
"OntapConfiguration": {
"FlexCacheEndpointType": "NONE",
"JunctionPath": "/share",
"SecurityStyle": "MIXED",
"SizeInMegabytes": 1024,
"StorageEfficiencyEnabled": true,
"StorageVirtualMachineId": "svm-0373dd4ba425ecc61",
"StorageVirtualMachineRoot": false,
"TieringPolicy": {
"CoolingPeriod": 31,
"Name": "AUTO"
},
"UUID": "c442a9c5-d653-11ec-9740-0728d01982a2",
"OntapVolumeType": "RW"
},
"ResourceARN": "arn:aws:fsx:ap-northeast-1:<AWSアカウントID>:volume/fs-005d4c8343b8e32de/fsvol-032b46c1b745a1bf5",
"VolumeId": "fsvol-032b46c1b745a1bf5",
"VolumeType": "ONTAP"
}
]
}
OSから見てもマウントしているボリュームの容量は増えていません。
$ df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 462M 0 462M 0% /dev tmpfs 470M 0 470M 0% /dev/shm tmpfs 470M 348K 470M 1% /run tmpfs 470M 0 470M 0% /sys/fs/cgroup /dev/nvme0n1p1 8.0G 1.6G 6.5G 20% / svm-0373dd4ba425ecc61.fs-005d4c8343b8e32de.fsx.ap-northeast-1.amazonaws.com:/share 973M 384K 973M 1% /fsx-share
そのため、ファイルシステム拡張後はボリュームを拡張してあげる必要があります。
ボリュームの拡張をする際は、対象のボリュームを選択しアクション-ボリュームを更新をクリックします。
ボリュームサイズを上限の104857600に変更します。ちなみに104857600MiB = 102400GiB = 100TiBです。ファイルシステムでプロビジョニングしているストレージキャパシティは1127GiBを余裕で超えています。
1分ほど待つとボリュームのサイズが100.00TBとなりました。こちらも更新は爆速です。
ボリュームサイズはファイルシステムのストレージキャパシティ以上を指定できたので、Amazon FSx for NetApp ONTAPのボリュームはThin Provisioningでオーバーコミット可能なようですね。
OSから見ても95TBのボリュームと認識されています。
$ df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 462M 0 462M 0% /dev tmpfs 470M 0 470M 0% /dev/shm tmpfs 470M 348K 470M 1% /run tmpfs 470M 0 470M 0% /sys/fs/cgroup /dev/nvme0n1p1 8.0G 1.6G 6.5G 20% / svm-0373dd4ba425ecc61.fs-005d4c8343b8e32de.fsx.ap-northeast-1.amazonaws.com:/share 95T 95T 949G 100% /fsx-share
ボリュームはファイルシステムと異なり、減らすことも可能です。
減らす際は、ボリュームサイズ拡張時と同様の手順で行えます。
試しにボリュームサイズを2048MiBに変更します。
1分ほど待つと、ボリュームサイズが2.00 GBに変更されたことを確認できました。
OSから見ても2.0Gのボリュームと認識されています。
$ df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 462M 0 462M 0% /dev tmpfs 470M 0 470M 0% /dev/shm tmpfs 470M 404K 470M 1% /run tmpfs 470M 0 470M 0% /sys/fs/cgroup /dev/nvme0n1p1 8.0G 1.6G 6.5G 20% / svm-0373dd4ba425ecc61.fs-005d4c8343b8e32de.fsx.ap-northeast-1.amazonaws.com:/share 2.0G 384K 1.9G 1% /fsx-share tmpfs 94M 0 94M 0% /run/user/0
また、メトリクスから使用可能なストレージ容量を確認すると、ストレージキャパシティが変動したことを確認できます。
この柔軟さはとても良いですね。
「こっちのボリュームは思ったより使われないから、別のよく使われているボリュームにストレージサイズを割り当て直そう」みたいな運用もできそうです。
ファイルシステムのスループットキャパシティの変更
続いて、ファイルシステムのスループットキャパシティの変更も行っていきます。
FSxのコンソールから対象のファイルシステムを選択し、スループットキャパシティ横の更新をクリックします。
更新をクリックすると以下のようなメッセージが表示されます。
スループット容量の更新アクションを開始すると、Amazon FSx がファイルサーバーを切り替えるので、マルチ AZ ファイルシステムはフェイルオーバーおよびフェイルバックします。
スループットキャパシティ変更時の注意点について、AWS公式ドキュメントを確認すると以下のような記載がありました。
ファイルシステムのスループット容量を変更すると、Amazon FSx はファイルシステムのファイルサーバーをスイッチアウトします。このプロセス中にファイルシステムで自動フェイルオーバーとフェイルバックが発生します。これは通常、完了するまでに数分かかります。フェイルオーバーおよびフェイルバックプロセスは、NFS、SMB、iSCSI クライアントに対して完全に透過的であり、中断や手動による介入なしにワークロードの実行を継続できます。ファイルシステムで使用可能になると、新しいスループット容量が課金されます。
ここから「Multi-AZ構成じゃないと数分間のダウンタイムが発生するのではないか」と思われるかもしれません。大丈夫です。FSx for ONTAPファイルシステムはSingle-AZ構成でも内部的には1AZ内に複数のノードがあり、HA構成を組んでいます。
そのため、Single-AZであってもスループットキャパシティ変更時に大きなダウンタイムは発生せず、NFSやSMBを継続して使用することができます。iSCSIについてはスループットキャパシティ変更時の影響を低減するためにはイニシエーター側でDM Multipath(Device Mapper Multipath)を設定する必要があります。
DM Multipathにより複数のノードにセッションが確立されます。そのため、フェイルオーバー/フェイルバックした際も稼働しているしているノードとのセッションで継続して通信するので、スループットキャパシティ変更時にワークロードの中断は発生しません。DM Multipathを使用しない場合、スループットキャパシティ変更時に数分間ダウンタイムが発生する可能性があります。
DM Multipathを用いたiSCSI LUNのマウント方法は以下AWS公式ドキュメントに記載があります。
DM Multipathの詳細な説明については以下Red Hat公式ドキュメントが参考になります。
実際に設定した際の記事は以下になります。
ちょっと横道にそれました。
希望するスループットキャパシティで256MB/秒に変更して更新をクリックします。
更新中は「128 MB/ 秒 (256 MB/ 秒に更新)」となっており、更新ボタンが非活性になりました。これ以上は触らせない強い意志を感じます。
20分ほど待つとスループットキャパシティが256MB/秒に変更されました。
ファイルシステムの更新履歴は更新タブから確認できます。
Amazon FSx for NetApp ONTAPが使いやすくなりました
Amazon FSx for NetApp ONTAPでファイルシステムのストレージとスループットキャパシティの変更ができるようになったアップデートを紹介しました。
柔軟にストレージやスループットを変更できるのはクラウドらしくてとても良いですね。
Amazon FSx for NetApp ONTAPはSAP HANA ワークロードの認定されるレベルで非常にパフォーマンスが良いです。
Amazon FSx for NetApp ONTAPのパフォーマンスは以下のように紹介されています。
レイテンシー
Amazon FSx for NetApp ONTAP は、ソリッドステートドライブ (SSD) ストレージを使用したサブミリ秒のファイルオペレーションのレイテンシーを提供し、容量プールストレージには数十ミリ秒のレイテンシーを提供します。さらに、Amazon FSx では、各ファイルサーバー (NVMe ドライブとインメモリ) に 2 つのレイヤーのリードキャッシュがあり、最も頻繁に読み取られるデータにアクセスする場合のレイテンシーがさらに低くなります。スループットと IOPS
各 Amazon FSx ファイルシステムは、最大、複数の GB / 秒 のスループットと数十万の IOPS を提供します。ファイルシステム上でワークロードが駆動できるスループットと IOPS の特定の量は、アクティブなワーキングセットのサイズを含むワークロードの性質とともに、ファイルシステムのスループット容量とストレージ容量の設定によって異なります。SMB マルチチャネルおよび NFS nconnect のサポート
Amazon FSx では、単一の SMB セッションで ONTAP とクライアント間に複数の接続を提供するように SMB マルチチャネルを設定できます。SMB マルチチャネルは、クライアントとサーバ間の複数のネットワーク接続を同時に使用して、ネットワーク帯域幅を集約し、最大限の利用率を実現します。NetApp ONTAP CLI を使用して SMB マルチチャネルを設定する方法については、[Configuring SMB Multichannel for performance and redundancy] (パフォーマンスと冗長性のための SMB マルチチャネルの設定) を参照してください。NFS クライアントは、nconnect マウントオプションを使用して、単一の NFS マウントに関連付けられた複数の TCP 接続 (最大 16) を持つことができます。このような NFS クライアントは、ラウンドロビン方式でファイル操作を複数の TCP 接続に多重化するため、使用可能なネットワーク帯域幅から高いスループットが得られます。NFSv3 と NFSv4.1 の両方が nconnect をサポートします。[Amazon EC2 instance network bandwidth] (Amazon EC2 インスタンスのネットワーク帯域幅) に、ネットワークフローあたりの全二重 5 Gbps の帯域幅制限を示します。nconnect 経由での複数のネットワークフローの使用、または、SMB マルチチャネルがこの制限を克服します。クライアントバージョンで nconnect がサポートされているかどうかを確認するには、NFS クライアントのドキュメントを参照してください。nconnect の NetApp ONTAP のサポートの詳細については、[ONTAP support for NFSv4.1] (ONTAP NFSv4.1 のサポート) を参照してください。
サービスをスモールスタートで様子見しながら使っていくということもクラウドならではだと思うので、AWS上で高パフォーマンスなストレージを運用してみたい場合はAmazon FSx for NetApp ONTAPを検討してみてはいかがでしょうか。
この記事が誰かの助けになれば幸いです。
以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!
![[Amazon FSx for NetApp ONTAP] SMBでファイルオープン中にフェイルオーバーが発生した場合の挙動を確認してみた](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-9e9d102dfa6d7896319b16fe069cdf55/c3bbbeab42ba5764c5a573e979719805/amazon-fsx-for-netapp-ontap)
