[アップデート] Amazon FSx for NetApp ONTAPファイルシステムの最大スループットキャパシティと最大SSD IOPSが倍増しました #reInvent
もっとハードにAmazon FSx for NetApp ONTAPを使いたいな
こんにちは、のんピ(@non____97)です。
皆さんはもっとハードにAmazon FSx for NetApp ONTAP(以降FSx for ONTAP)を使いたいなと思ったことはありますか? 私はあります。
FSx for ONTAPのSSDの最大IOPSは80,000で、スループットキャパシティは2,048 MBpsでした。一般的なワークロードではこのパフォーマンスでも十分かもしれませんが、重たい分析処理や高スループットのDBなどを動作させるには少し心許ないです。
そんな折、最大スループットキャパシティと最大SSD IOPSが倍増しました。
誇張ではなく、以下のように倍増です。
- 最大スループットキャパシティ : 2,048 MBps -> 4,096 MBps
- 最大SSD IOPS : 80,000 -> 160,000
最大SSD IOPSについてはgp3と同じになりました。
これはありがたいアップデートです。早速確認してみたので紹介します。
いきなりまとめ
- Amazon FSx for NetApp ONTAPファイルシステムの最大スループットキャパシティと最大SSD IOPSが倍増
- 最大スループットキャパシティ : 2,048 MBps -> 4,096 MBps
- 最大SSD IOPS : 80,000 -> 160,000
- シングルAZでも2022/11/28以降に作成されたファイルシステムで、スループットキャパシティが2,048 MBps以上の場合はNVMeリードキャッシュが追加
- 最大スループットキャパシティを4,096 MBpsにする場合は、以下の2つの条件を満たす必要がある
- SSDのサイズが5,120 GiB以上
- SSD IOPSが160,000
- 2022/11/29でアップデートの対象となるリージョンは以下の4つ
- us-east-1 (バージニア北部)
- us-east-2 (オハイオ)
- us-west-2 (オレゴン)
- eu-west-1 (アイルランド)
アップデート内容の確認
アップデートの内容を確認します。
FSx for ONTAPファイルシステムの最大スループットキャパシティと最大SSD IOPSが倍増するのは全リージョンではなく、以下の4リージョンが対象になります。
- us-east-1 (バージニア北部)
- us-east-2 (オハイオ)
- us-west-2 (オレゴン)
- eu-west-1 (アイルランド)
各リージョンのSingle-AZ/Multi-AZの最大スループットの組み合わせは以下の通りです。
今回のアップデートの対象リージョン | 同左 | 今回のアップデートの対象外のリージョン | 同左 | |
---|---|---|---|---|
読み取りスループット (MBps) | 書き込みスループット (MBps) | 読み取りスループット (MBps) | 書き込みスループット (MBps) | |
Single-AZ | 4,096 | 1,000 | 2,048 | 750 |
Multi-AZ | 4,096 | 1,800 | 2,048 | 1,300 |
また、今回のアップデートの対象リージョンでは、シングルAZでも2022/11/28以降に作成されたファイルシステムで、スループットキャパシティが2,048 MBps以上の場合はNVMeリードキャッシュが追加されていました。
表にまとめると以下のようになります。
スループットキャパシティ (MBps) | ネットワークスループット (MBps) | 同左 | ネットワーク IOPS | インメモリ キャッシュ (GB) | NVMe リードキャッシュ (GB) | 同左 | ディスク スループット (MBps) | 同左 | SSD ドライブの IOPS | 同左 |
---|---|---|---|---|---|---|---|---|---|---|
ベースライン | バースト | シングル AZ | マルチ AZ | ベースライン | バースト | ベースライン | バースト | |||
128 | 188 | 1,500 | 数万のベースライン | 16 | – | 238 | 128 | 1,250 | 6,000 | 40,000 |
256 | 375 | 1,500 | 同上 | 32 | – | 475 | 256 | 1,250 | 12,000 | 40,000 |
512 | 750 | 1,500 | 数十万のベースライン | 64 | – | 950 | 512 | 1,250 | 40,000 | – |
1,024 | 1,500 | – | 同上 | 128 | – | 1,900 | 1,024 | 1,250 | 40,000 | – |
2,048 | 3,125 | – | 同上 | 256 | 2,700 | 3,800 | 2,048 | – | 80,000 | – |
4,096 | 6,250 | – | 同上 | 512 | 5,400 | 7,600 | 4,096 | – | 160,000 | – |
Amazon FSx for NetApp ONTAP performance - FSx for ONTAP
やってみる
スループットキャパシティが128 MBpsで、最大IOPSが3,072のFSx for ONTAPファイルシステムの動作確認
それでは試してみます。
比較用にスループットキャパシティが128 MBpsで、最大IOPSが3,072のFSx for ONTAPファイルシステムに対して書き込みのスループットの速度を確認します。
用意したFSx for ONTAPファイルシステムとSVM、ボリュームは以下の通りです。
# FSx for ONTAPファイルシステム $ aws fsx describe-file-systems { "FileSystems": [ { "OwnerId": "<AWSアカウントID>", "CreationTime": "2022-11-29T02:57:05.601000+00:00", "FileSystemId": "fs-0d9f2fdfa4d7e83eb", "FileSystemType": "ONTAP", "Lifecycle": "AVAILABLE", "StorageCapacity": 1024, "StorageType": "SSD", "VpcId": "vpc-08b84da1f793ed513", "SubnetIds": [ "subnet-08dc789896a48a3b4" ], "NetworkInterfaceIds": [ "eni-0eefe426a2c352732", "eni-09746bf8119630d70" ], "KmsKeyId": "arn:aws:kms:us-east-1:<AWSアカウントID>:key/365ae19c-8016-4963-9afd-05f703509254", "ResourceARN": "arn:aws:fsx:us-east-1:<AWSアカウントID>:file-system/fs-0d9f2fdfa4d7e83eb", "Tags": [ { "Key": "aws:cloudformation:stack-name", "Value": "FsxnStack" }, { "Key": "aws:cloudformation:logical-id", "Value": "FSxforONTAPfilesystem" }, { "Key": "aws:cloudformation:stack-id", "Value": "arn:aws:cloudformation:us-east-1:<AWSアカウントID>:stack/FsxnStack/78cdb890-5423-11ed-81fb-0eac30df53d1" }, { "Key": "Name", "Value": "fsx-for-ontap-file-system" } ], "OntapConfiguration": { "AutomaticBackupRetentionDays": 7, "DailyAutomaticBackupStartTime": "16:00", "DeploymentType": "SINGLE_AZ_1", "Endpoints": { "Intercluster": { "DNSName": "intercluster.fs-0d9f2fdfa4d7e83eb.fsx.us-east-1.amazonaws.com", "IpAddresses": [ "10.0.1.104", "10.0.1.80" ] }, "Management": { "DNSName": "management.fs-0d9f2fdfa4d7e83eb.fsx.us-east-1.amazonaws.com", "IpAddresses": [ "10.0.1.91" ] } }, "DiskIopsConfiguration": { "Mode": "AUTOMATIC", "Iops": 3072 }, "PreferredSubnetId": "subnet-08dc789896a48a3b4", "ThroughputCapacity": 128, "WeeklyMaintenanceStartTime": "6:17:00" } } ] } # SVM $ aws fsx describe-storage-virtual-machines { "StorageVirtualMachines": [ { "CreationTime": "2022-11-29T06:00:07.697000+00:00", "Endpoints": { "Iscsi": { "DNSName": "iscsi.svm-0550f106a09cb81cd.fs-0d9f2fdfa4d7e83eb.fsx.us-east-1.amazonaws.com", "IpAddresses": [ "10.0.1.75", "10.0.1.105" ] }, "Management": { "DNSName": "svm-0550f106a09cb81cd.fs-0d9f2fdfa4d7e83eb.fsx.us-east-1.amazonaws.com", "IpAddresses": [ "10.0.1.110" ] }, "Nfs": { "DNSName": "svm-0550f106a09cb81cd.fs-0d9f2fdfa4d7e83eb.fsx.us-east-1.amazonaws.com", "IpAddresses": [ "10.0.1.110" ] } }, "FileSystemId": "fs-0d9f2fdfa4d7e83eb", "Lifecycle": "CREATED", "Name": "SVM", "ResourceARN": "arn:aws:fsx:us-east-1:<AWSアカウントID>:storage-virtual-machine/fs-0d9f2fdfa4d7e83eb/svm-0550f106a09cb81cd", "StorageVirtualMachineId": "svm-0550f106a09cb81cd", "Subtype": "DEFAULT", "UUID": "25e7a2d4-6fab-11ed-bcb2-db44cb4de9a2" } ] } # ボリューム $ aws fsx describe-volumes { "Volumes": [ { "CreationTime": "2022-11-29T06:00:42+00:00", "FileSystemId": "fs-0d9f2fdfa4d7e83eb", "Lifecycle": "CREATED", "Name": "SVM_root", "OntapConfiguration": { "FlexCacheEndpointType": "NONE", "JunctionPath": "/", "SecurityStyle": "UNIX", "SizeInMegabytes": 1024, "StorageEfficiencyEnabled": false, "StorageVirtualMachineId": "svm-0550f106a09cb81cd", "StorageVirtualMachineRoot": true, "TieringPolicy": { "Name": "NONE" }, "UUID": "2822bc55-6fab-11ed-b653-1f3b338f63c0", "OntapVolumeType": "RW" }, "ResourceARN": "arn:aws:fsx:us-east-1:<AWSアカウントID>:volume/fs-0d9f2fdfa4d7e83eb/fsvol-0771e9d050d9afc70", "VolumeId": "fsvol-0771e9d050d9afc70", "VolumeType": "ONTAP" }, { "CreationTime": "2022-11-29T06:05:45.577000+00:00", "FileSystemId": "fs-0d9f2fdfa4d7e83eb", "Lifecycle": "CREATED", "Name": "vol1", "OntapConfiguration": { "FlexCacheEndpointType": "NONE", "JunctionPath": "/vol1", "SizeInMegabytes": 1048576, "StorageEfficiencyEnabled": false, "StorageVirtualMachineId": "svm-0550f106a09cb81cd", "StorageVirtualMachineRoot": false, "TieringPolicy": { "CoolingPeriod": 31, "Name": "AUTO" }, "UUID": "e11b15eb-6fab-11ed-bcb2-db44cb4de9a2", "OntapVolumeType": "RW" }, "ResourceARN": "arn:aws:fsx:us-east-1:<AWSアカウントID>:volume/fs-0d9f2fdfa4d7e83eb/fsvol-0135cdfbe21537bd7", "VolumeId": "fsvol-0135cdfbe21537bd7", "VolumeType": "ONTAP" } ] }
クライアントがネットワーク帯域がボトルネックにならないように、インスタンスタイプはc7g.mediumを選択しました。c7g.mediumのネットワーク帯域幅は最大 12.5Gbpsです。こちらのEC2インスタンスから/vol1
というボリュームをマウントします。
# マウントポイントを作成 $ sudo mkdir /mnt/fsx # /vol1をマウント $ sudo mount -t nfs svm-0550f106a09cb81cd.fs-0d9f2fdfa4d7e83eb.fsx.us-east-1.amazonaws.com:/vol1 /mnt/fsx # マウントできていることを確認 $ df -ht nfs4 Filesystem Size Used Avail Use% Mounted on svm-0550f106a09cb81cd.fs-0d9f2fdfa4d7e83eb.fsx.us-east-1.amazonaws.com:/vol1 973G 113G 861G 12% /mnt/fsx
マウントしたボリュームに対して10 GiB分の書き込みを行います。
$ sudo dd if=/dev/urandom of=/mnt/fsx/test bs=1M count=10240 10240+0 records in 10240+0 records out 10737418240 bytes (11 GB) copied, 71.872 s, 149 MB/s
149 MBpsでした。ぼちぼちといったところです。
スループットキャパシティを4,096 Mbpsに変更
それではスループットキャパシティを4,096 Mbpsに変更します。
対象のFSx for ONTAPファイルシステムを選択してアクション
-スループットキャパシティを更新
をクリックします。
希望するスループットキャパシティで、4,096 Mbpsを選択して更新
をクリックします。
すると、Amazon FSx does not support provisioning 4096 MB/s of throughput capacity on ONTAP file systems with less than 5120 GiB of storage or 160,000 SSD IOPS.
と怒られてしまいました。
どうやら、ストレージサイズが5,120 GiB未満、もしくはSSD IOPSが160,000未満である場合は、スループットキャパシティを4,096 Mbpsとすることはできないようです。
AWS公式ドキュメントにも記載されていました。
To provision 4 GBps of throughput capacity, your file system must be configured with a minimum of 5,120 GiB of SSD storage capacity and 160,000 SSD IOPS.
実際に試してみましょう。試しにストレージサイズを1,024 GiBから5,120 GiBに変更します。
しばらくすると、ストレージサイズが5,120 GiBに変わりました。しかし、ストレージキャパシティのステータスが更新、最適化
となっています。
AWS CLIで確認するとAdministrativeActions
のSTORAGE_OPTIMIZATION
がIN_PROGRESS
になっていました。
$ aws fsx describe-file-systems { "FileSystems": [ { "OwnerId": "<AWSアカウントID>", "CreationTime": "2022-11-29T02:57:05.601000+00:00", "FileSystemId": "fs-0d9f2fdfa4d7e83eb", "FileSystemType": "ONTAP", "Lifecycle": "AVAILABLE", "StorageCapacity": 5120, "StorageType": "SSD", "VpcId": "vpc-08b84da1f793ed513", "SubnetIds": [ "subnet-08dc789896a48a3b4" ], "NetworkInterfaceIds": [ "eni-0eefe426a2c352732", "eni-09746bf8119630d70" ], "KmsKeyId": "arn:aws:kms:us-east-1:<AWSアカウントID>:key/365ae19c-8016-4963-9afd-05f703509254", "ResourceARN": "arn:aws:fsx:us-east-1:<AWSアカウントID>:file-system/fs-0d9f2fdfa4d7e83eb", "Tags": [ { "Key": "aws:cloudformation:stack-name", "Value": "FsxnStack" }, { "Key": "aws:cloudformation:logical-id", "Value": "FSxforONTAPfilesystem" }, { "Key": "aws:cloudformation:stack-id", "Value": "arn:aws:cloudformation:us-east-1:<AWSアカウントID>:stack/FsxnStack/78cdb890-5423-11ed-81fb-0eac30df53d1" }, { "Key": "Name", "Value": "fsx-for-ontap-file-system" } ], "AdministrativeActions": [ { "AdministrativeActionType": "FILE_SYSTEM_UPDATE", "RequestTime": "2022-11-29T06:22:36.984000+00:00", "Status": "UPDATED_OPTIMIZING", "TargetFileSystemValues": { "StorageCapacity": 5120 } }, { "AdministrativeActionType": "STORAGE_OPTIMIZATION", "ProgressPercent": 0, "RequestTime": "2022-11-29T06:22:36.984000+00:00", "Status": "IN_PROGRESS" } ], "OntapConfiguration": { "AutomaticBackupRetentionDays": 7, "DailyAutomaticBackupStartTime": "16:00", "DeploymentType": "SINGLE_AZ_1", "Endpoints": { "Intercluster": { "DNSName": "intercluster.fs-0d9f2fdfa4d7e83eb.fsx.us-east-1.amazonaws.com", "IpAddresses": [ "10.0.1.104", "10.0.1.80" ] }, "Management": { "DNSName": "management.fs-0d9f2fdfa4d7e83eb.fsx.us-east-1.amazonaws.com", "IpAddresses": [ "10.0.1.91" ] } }, "DiskIopsConfiguration": { "Mode": "AUTOMATIC", "Iops": 15360 }, "PreferredSubnetId": "subnet-08dc789896a48a3b4", "ThroughputCapacity": 128, "WeeklyMaintenanceStartTime": "6:17:00" } } ] }
FSxのAPI Referenceを確認すると、以下のように記載がありました。
STORAGE_OPTIMIZATION - After the FILE_SYSTEM_UPDATE task to increase a file system's storage capacity has been completed successfully, a STORAGE_OPTIMIZATION task starts.
- For Windows and ONTAP, storage optimization is the process of migrating the file system data to newer larger disks.
- For Lustre, storage optimization consists of rebalancing the data across the existing and newly added file servers.
You can track the storage-optimization progress using the ProgressPercent property. When STORAGE_OPTIMIZATION has been completed successfully, the parent FILE_SYSTEM_UPDATE action status changes to COMPLETED. For more information, see Managing storage capacity in the Amazon FSx for Windows File Server User Guide, Managing storage and throughput capacity in the Amazon FSx for Lustre User Guide, and Managing storage capacity and provisioned IOPS in the Amazon FSx for NetApp ONTAP User Guide.
裏でディスクの移行が行われているようですね。
20分ほど待つと、FILE_SYSTEM_UPDATE
がCOMPLETED
となっていました。
$ aws fsx describe-file-systems { "FileSystems": [ { "OwnerId": "<AWSアカウントID>", "CreationTime": "2022-11-29T02:57:05.601000+00:00", "FileSystemId": "fs-0d9f2fdfa4d7e83eb", "FileSystemType": "ONTAP", "Lifecycle": "AVAILABLE", "StorageCapacity": 5120, "StorageType": "SSD", "VpcId": "vpc-08b84da1f793ed513", "SubnetIds": [ "subnet-08dc789896a48a3b4" ], "NetworkInterfaceIds": [ "eni-0eefe426a2c352732", "eni-09746bf8119630d70" ], "KmsKeyId": "arn:aws:kms:us-east-1:<AWSアカウントID>:key/365ae19c-8016-4963-9afd-05f703509254", "ResourceARN": "arn:aws:fsx:us-east-1:<AWSアカウントID>:file-system/fs-0d9f2fdfa4d7e83eb", "Tags": [ { "Key": "aws:cloudformation:stack-name", "Value": "FsxnStack" }, { "Key": "aws:cloudformation:logical-id", "Value": "FSxforONTAPfilesystem" }, { "Key": "aws:cloudformation:stack-id", "Value": "arn:aws:cloudformation:us-east-1:<AWSアカウントID>:stack/FsxnStack/78cdb890-5423-11ed-81fb-0eac30df53d1" }, { "Key": "Name", "Value": "fsx-for-ontap-file-system" } ], "AdministrativeActions": [ { "AdministrativeActionType": "FILE_SYSTEM_UPDATE", "RequestTime": "2022-11-29T06:22:36.984000+00:00", "Status": "COMPLETED", "TargetFileSystemValues": { "StorageCapacity": 5120 } } ], "OntapConfiguration": { "AutomaticBackupRetentionDays": 7, "DailyAutomaticBackupStartTime": "16:00", "DeploymentType": "SINGLE_AZ_1", "Endpoints": { "Intercluster": { "DNSName": "intercluster.fs-0d9f2fdfa4d7e83eb.fsx.us-east-1.amazonaws.com", "IpAddresses": [ "10.0.1.104", "10.0.1.80" ] }, "Management": { "DNSName": "management.fs-0d9f2fdfa4d7e83eb.fsx.us-east-1.amazonaws.com", "IpAddresses": [ "10.0.1.91" ] } }, "DiskIopsConfiguration": { "Mode": "AUTOMATIC", "Iops": 15360 }, "PreferredSubnetId": "subnet-08dc789896a48a3b4", "ThroughputCapacity": 128, "WeeklyMaintenanceStartTime": "6:17:00" } } ] }
せっかくなので、この状態でも書き込み速度を確認してみましょう。
$ sudo dd if=/dev/urandom of=/mnt/fsx/test2 bs=1M count=10240 10240+0 records in 10240+0 records out 10737418240 bytes (11 GB) copied, 72.2536 s, 149 MB/s
ストレージサイズを5,120 GiBに増やしたので、SSDのIOPSも15,360になっているはずが、速度は変わりませんでした。どうやらIOPSではなくネットワークスループットなど別の要素がボトルネックになっていそうですね。
それでは、この状態で再度スループットキャパシティを4,096 GiBに変更しようとしてみます。
はい、怒られました。やはり、SSD IOPSも160,000である必要があるようです。
「それでは」ということで、SSD IOPSも160,000に変更しようとします。
Unable to perform the storage capacity update. A new storage capacity update can be initiated only 6 hours or more after the prior storage capacity update request
と怒られました。ストレージサイズを増やした場合は6時間変更できないのは知っていましたが、SSD IOPSも一度変更されたら6時間待つ必要があるようです。
スループットキャパシティが4,096 MBpsで、最大IOPSが160,000のFSx for ONTAPファイルシステムの動作確認
しょうがないのでスループットキャパシティが4,096 MBpsで、最大IOPSが160,000のFSx for ONTAPファイルシステムを作成します。ファイルシステムのその他の設定やSVM、ボリュームは同じ設定にしています。
しばらくすると、FSx for ONTAPファイルシステムが作成されました。
$ aws fsx describe-file-systems { "FileSystems": [ { "OwnerId": "<AWSアカウントID>", "CreationTime": "2022-11-29T08:48:25.066000+00:00", "FileSystemId": "fs-0c16099e23c5a3a87", "FileSystemType": "ONTAP", "Lifecycle": "AVAILABLE", "StorageCapacity": 5120, "StorageType": "SSD", "VpcId": "vpc-08b84da1f793ed513", "SubnetIds": [ "subnet-08dc789896a48a3b4" ], "NetworkInterfaceIds": [ "eni-0e1e123a56186869b", "eni-0cea1b20245db4f6c" ], "KmsKeyId": "arn:aws:kms:us-east-1:<AWSアカウントID>:key/365ae19c-8016-4963-9afd-05f703509254", "ResourceARN": "arn:aws:fsx:us-east-1:<AWSアカウントID>:file-system/fs-0c16099e23c5a3a87", "Tags": [ { "Key": "Name", "Value": "fsxn" } ], "OntapConfiguration": { "AutomaticBackupRetentionDays": 7, "DailyAutomaticBackupStartTime": "07:00", "DeploymentType": "SINGLE_AZ_1", "Endpoints": { "Intercluster": { "DNSName": "intercluster.fs-0c16099e23c5a3a87.fsx.us-east-1.amazonaws.com", "IpAddresses": [ "10.0.1.119", "10.0.1.110" ] }, "Management": { "DNSName": "management.fs-0c16099e23c5a3a87.fsx.us-east-1.amazonaws.com", "IpAddresses": [ "10.0.1.123" ] } }, "DiskIopsConfiguration": { "Mode": "USER_PROVISIONED", "Iops": 160000 }, "PreferredSubnetId": "subnet-08dc789896a48a3b4", "ThroughputCapacity": 4096, "WeeklyMaintenanceStartTime": "2:03:00" } } ] }
ボリュームをマウントして書き込み速度を確認してみます。
# ボリュームをマウント $ sudo mount -t nfs svm-0e9e6df5cb2817e2d.fs-0c16099e23c5a3a87.fsx.us-east-1.amazonaws.com:/vol1 /mnt/fsx # マウントできたことを確認 $ df -ht nfs4 Filesystem Size Used Avail Use% Mounted on svm-0e9e6df5cb2817e2d.fs-0c16099e23c5a3a87.fsx.us-east-1.amazonaws.com:/vol1 973G 320K 973G 1% /mnt/fsx # 書き込み速度の確認 $ sudo dd if=/dev/urandom of=/mnt/fsx/test3 bs=1M count=10240 10240+0 records in 10240+0 records out 10737418240 bytes (11 GB) copied, 35.8928 s, 299 MB/s
書き込み速度がほぼ倍になりましたね。
今までブロックサイズを1 MBにしていましたが、ブロックサイズで書き込み速度が異なるのか気になってきました。
ブロックサイズを以下のように変更して、各ブロックサイズ毎の速度を確認します。
- 10 MB
- 100 KB
- 10 KB
# ブロックサイズが 10 MB $ sudo dd if=/dev/urandom of=/mnt/fsx/test4 bs=10M count=1024 1024+0 records in 1024+0 records out 10737418240 bytes (11 GB) copied, 36.6013 s, 293 MB/s # ブロックサイズが 100 KB $ sudo dd if=/dev/urandom of=/mnt/fsx/test5 bs=100K count=102400 102400+0 records in 102400+0 records out 10485760000 bytes (10 GB) copied, 35.4918 s, 295 MB/s # ブロックサイズが 10 KB $ sudo dd if=/dev/urandom of=/mnt/fsx/test6 bs=10K count=1048576 1048576+0 records in 1048576+0 records out 10737418240 bytes (11 GB) copied, 37.5771 s, 286 MB/s
ブロックサイズで書き込み速度は特に変わらないようですね。
そういえば、読み込み速度の確認をしていませんでした。読み込み速度も確認してみましょう。
$ sudo dd if=/mnt/fsx/test3 of=/dev/nul bs=1M dd: error writing ‘/dev/nul’: No space left on device 882+0 records in 881+0 records out 924168192 bytes (924 MB) copied, 1.73721 s, 532 MB/s
532 MBpsとなかなかの速さです。
ブロックサイズを変更して、各ブロックサイズの読み込み速度を確認してみます。
# ブロックサイズが 1 KB $ sudo dd if=/mnt/fsx/test3 of=/dev/nul bs=1K dd: error writing ‘/dev/nul’: No space left on device 902509+0 records in 902508+0 records out 924168192 bytes (924 MB) copied, 1.81519 s, 509 MB/s # ブロックサイズが 10 KB $ sudo dd if=/mnt/fsx/test3 of=/dev/nul bs=10K dd: error writing ‘/dev/nul’: No space left on device 90251+0 records in 90250+0 records out 924168192 bytes (924 MB) copied, 1.51241 s, 611 MB/s # ブロックサイズが 100 KB $ sudo dd if=/mnt/fsx/test3 of=/dev/nul bs=100K dd: error writing ‘/dev/nul’: No space left on device 9026+0 records in 9025+0 records out 924168192 bytes (924 MB) copied, 0.93112 s, 993 MB/s # ブロックサイズが 1 MB $ sudo dd if=/mnt/fsx/test3 of=/dev/nul bs=1M dd: error writing ‘/dev/nul’: No space left on device 882+0 records in 881+0 records out 924168192 bytes (924 MB) copied, 0.53076 s, 1.7 GB/s # ブロックサイズが 10 MB $ sudo dd if=/mnt/fsx/test3 of=/dev/nul bs=10M dd: error writing ‘/dev/nul’: No space left on device 89+0 records in 88+0 records out 924168192 bytes (924 MB) copied, 0.642005 s, 1.4 GB/s # ブロックサイズが 100 MB $ sudo dd if=/mnt/fsx/test3 of=/dev/nul bs=100M dd: error writing ‘/dev/nul’: No space left on device 9+0 records in 8+0 records out 924168192 bytes (924 MB) copied, 0.842585 s, 1.1 GB/s
NVMeリードキャッシュが効いているのか爆速です。これがNFS経由なのですから頼もしいですね。
Amazon FSx for NetApp ONTAPがよりハードなワークロードで使いやすくなりました
Amazon FSx for NetApp ONTAPファイルシステムの最大スループットキャパシティと最大SSD IOPSが倍増したアップデートを紹介しました。
IOPSなど性能観点でFSx for ONTAPを選択肢から除いてしまうこともあったかと思いますが、かなり高性能になりました。ハードなワークロードに組み込む場合はPoCでベンチマークを行った上で最適なスループットキャパシティとSSD IOPSを選定ください。
この記事が誰かの助けになれば幸いです。
以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!