直接キャパシティプールストレージに書き込みたい
こんにちは、のんピ(@non____97)です。
皆さんはAmazon FSx for NetApp ONTAP(以降FSxN)のキャパシティプールストレージに直接書き込みたいなと思ったことはありますか? 私はあります。
従来のFSxNではTiering PolicyをAllにしていたとしても、書き込み時は一度SSDに書き込まれてからキャパシティプールストレージに書き込まれていました。そのため、大容量のデータを一気に書き込むとSSDが溢れる可能性があります。
SSDの空き容量を気にしながらの転送となると、移行やバックアップなど大量のデータを書き込む際には想定以上に時間がかります。
「この仕様はなんとかならないかな」と思いながらFSxNのドキュメント履歴を見ると、「cloud write modeをサポートした」と記載がありました。
抜粋 : Document History for Amazon FSx for NetApp ONTAP - FSx for ONTAP
リンク先のAWS公式ドキュメントにはcloud write modeを有効にすることで、どのような挙動をするのか記載はありませんでした。
よくよく調べるとONTAP 9.14.1からの機能のようです。
調べて試してみたので紹介します。
いきなりまとめ
- cloud write modeを有効にすることでキャパシティプールストレージに直接書き込みができる
- SSDの空き容量以上の書き込みがある場合でも、一気に書き込みができる
- 条件は以下のとおり
- 既存のボリュームに対してのみ設定可能
- サポートプロトコルはNFSのみ
- SMBなどの他のプロトコルは2024/2/11時点では未サポート
- 対象ボリュームのタイプはRWである必要がある
- SnapMirrorの転送先のボリュームはDPであるため、使用不可
- Tiering PolicyはAllである必要がある
- 検証した限りcloud write modeを有効にしても、無効状態と比べて書き込み速度の大きな差はない
cloud write modeとは
概要
cloud write modeとはデータ書き込み時にSSDに一度書き込むのではなく、直接キャパシティプールストレージに書き込むモードです。
ONTAP 9.14.1 以降では、FabricPool 内の新規または既存のボリュームでクラウド書き込みモードを有効または無効にして、NFS クライアントが階層化スキャンを待たずにクラウドに直接データを書き込むことができるようになりました。 SMB クライアントは引き続き、クラウド書き込み対応ボリュームのパフォーマンス層に書き込みます。クラウド書き込みモードはデフォルトでは無効になっています。
こうすることで、大量の書き込みによってSSDが圧迫されることを気にする必要がなくなります。
NetApp公式ドキュメントにもFabric Poolのローカル層(FSxNの場合はSSD)のサイズ以上の書き込みがある場合に役立つと記載がありました。
クラウド書き込みモードは、クラスターがローカル層でサポートできる量を超える大量のデータがクラスターに転送される移行などの場合に役立ちます。クラウド書き込みモードを使用しない場合、移行中、移行が完了するまで、少量のデータが転送され、その後階層化され、さらに転送され、再び階層化されます。クラウド書き込みモードを使用すると、データがローカル層に転送されないため、この種の管理は必要なくなります。
大規模移行の時にはかなり役立ちますね。帯域制御をかけてSSDの空き容量をケアしながら転送する必要がないので、移行にかかる時間も短くなります。
条件
条件は以下のとおりです。
- 既存のボリュームに対してのみ設定可能
- FSxNファイルシステム、またはSVMの管理者であること
- advanced 以上の権限が必要
- ボリュームタイプはRWであること
- ボリュームのTiering PolicyはAllであること
- サポートプロトコルはNFSのみ
通常のONTAPではボリューム作成時にcloud write modeを有効にすることができるようですが、FSxNでは有効にできないようです。作成後に設定変更を行いましょう。
特に気になるのは以下2点です。
- ボリュームタイプはRWであること
- サポートプロトコルはNFSのみ
ボリュームタイプがRWである必要があります。そのため、転送先ボリュームのボリュームタイプがDPである必要があるSnapMirrorでは必然的に使用できません。それに関連して、FSxNのバックアップからのリストアもSnapMirror Cloudを使用しているためcloud write modeは使用できないと考えます。ONTAP間での移行ではSnapMirrorを使用するのがベターと考えます。SnapMirrorによる移行をスムーズに行えるようにするためにも、早くDPボリュームでも使用できることを期待しておきましょう。
2024/2/11時点でのサポートプロトコルはNFSのみです。SMBによる書き込み時はcloud write modeが有効であってもSSDに一度書き込まれるようです。
移行元のファイルサーバーがSMBでアクセスするものの場合、一時的にNFSとのマルチプロトコルアクセスを有効化してNFSでデータ転送をするとスムーズに転送ができそうです。(未検証)
やってみた
cloud write modeが無効な状態での書き込み
実際にやってみましょう。
ONTAPのバージョンを確認します。
::> version
NetApp Release 9.13.1P6: Tue Dec 05 16:06:25 UTC 2023ONTAP 9.13.1P6でした。cloud write modeはONTAP 9.14.1からの機能のようですが、FSxNにおいてはONTAP 9.13.1でも使用できるようです。
cloud write modeを設定できるか確認すると、確かにvolume modifyで設定できそうでした。なお、volume createでは設定できませんでした。
::> set diag
Warning: These diagnostic commands are for use by NetApp personnel only.
Do you want to continue? {y|n}: y
FsxId04e5e03055492f9d9::*> volume
activity-tracking analytics autosize clone
conversion create delete efficiency
encryption expand file flexcache
flexgroup make-vsroot modify mount
move offline online qtree
quota reallocation rebalance recovery-queue
rehost remove-junction rename restrict
show show-footprint show-space size
snaplock snapshot unmount
FsxId04e5e03055492f9d9::*> volume ?
activity-tracking> The activity-tracking directory
analytics> The analytics directory
autosize Set/Display the autosize settings of the flexible volume.
clone> Manage FlexClones
conversion> *The conversion directory
create Create a new volume
delete Delete an existing volume
efficiency> Manage volume efficiency
encryption> The encryption directory
expand Expand the size of a volume by adding constituents
file> File related commands
flexcache> Manage FlexCache
flexgroup> *Manage FlexGroup operations
make-vsroot *Designate a non-root volume as a root volume of the Vserver
modify Modify volume attributes
mount Mount a volume on another volume with a junction-path
move> Manage volume move operations
offline Take an existing volume offline
online Bring an existing volume online
qtree> Manage qtrees
quota> Manage Quotas, Policies, Rules and Reports
reallocation> Commands for measuring and optimizing data layout
rebalance> The rebalance directory
recovery-queue> *Manage volume recovery queue
rehost Rehost a volume from one Vserver into another Vserver
remove-junction *Remove a dead junction by junction path
rename Rename an existing volume
restrict Restrict an existing volume
show Display a list of volumes
show-footprint Display a list of volumes and their data and metadata footprints in their associated aggregate.
show-space Display space usage for volume(s)
size Set/Display the size of the volume.
snaplock> Manages SnapLock attributes of a SnapLock volume
snapshot> Manage snapshots
unmount Unmount a volume
::*> volume modify -volume vol1 ?
[ -vserver <vserver name> ] Vserver Name (default: svm)
[ -size {<integer>[KB|MB|GB|TB|PB]} ] Volume Size
[ -state {online|restricted|offline|force-online|force-offline|mixed} ] Volume State
[ -policy <text> ] Export Policy
[ -user <user name> ] User ID
[ -group <group name> ] Group ID
[ -security-style <security style> ] Security Style
[ -unix-permissions <unix perm> ] UNIX Permissions
[ -junction-active {true|false} ] *Junction Active
[ -comment <text (size 0..1023)> ] Comment
[ -space-nearly-full-threshold-percent <percent> ] Volume Nearly Full Threshold Percent
[ -space-full-threshold-percent <percent> ] Volume Full Threshold Percent
{ [ -max-autosize {<integer>[KB|MB|GB|TB|PB]} ] Maximum Autosize
[ -min-autosize {<integer>[KB|MB|GB|TB|PB]} ] Minimum Autosize
[ -autosize-grow-threshold-percent <percent> ] Autosize Grow Threshold Percentage
[ -autosize-shrink-threshold-percent <percent> ] Autosize Shrink Threshold Percentage
[ -autosize-mode {off|grow|grow_shrink} ] Autosize Mode
| [ -autosize-reset [true] ] } Autosize Reset
[ -files <integer> ] Total Files (for user-visible data)
[ -files-set-maximum {true|false} ] *Set Total Files (for user-visible data) to the Highest Value that the
Volume can Hold
[ -maxdir-size {<integer>[KB|MB|GB|TB|PB]} ] *Maximum Directory Size
{ [ -space-slo {none|thick|semi-thick} ] Space SLO
| [ -space-guarantee|-s {none|volume} ] Space Guarantee Style
[ -fractional-reserve <percent> ] Fractional Reserve
[ -min-readahead {true|false} ] *Minimum Read Ahead
[ -atime-update {true|false} ] *Access Time Update Enabled
[ -snapdir-access {true|false} ] Snapshot Directory Access Enabled
[ -percent-snapshot-space <percent> ] Space Reserved for Snapshot Copies
[ -snapshot-policy <snapshot policy> ] Snapshot Policy
[ -language <language_code> ] Language
[ -foreground {true|false} ] Foreground Process
[ -nvfail {on|off} ] NVFAIL Option
[ -in-nvfailed-state {true|false} ] *Volume's NVFAIL State
[ -dr-force-nvfail {on|off} ] Force NVFAIL on MetroCluster Switchover
[ -filesys-size-fixed {true|false} ] Is File System Size Fixed
[ -extent-enabled {off|on|space-optimized} ] (DEPRECATED)-Extent Option
[ -max-write-alloc-blocks {0..2048} ] *Maximum Write Allocation Blocks
[ -convert-ucode {true|false} ] *Convert Directories to Unicode Format
[ -space-mgmt-try-first {volume_grow|snap_delete} ] Primary Space Management Strategy
[ -read-realloc {off|on|space-optimized} ] Read Reallocation Option
[ -sched-snap-name {create-time|ordinal} ] Naming Scheme for Automatic Snapshot Copies
{ [ -qos-policy-group <text> ] QoS Policy Group Name
| [ -qos-adaptive-policy-group <text> ] } QoS Adaptive Policy Group Name
[ -caching-policy <text> ] Caching Policy Name
[ -cache-retention-priority {normal|low|high} ] *Cache Retention Priority
[ -is-autobalance-eligible {true|false} ] *Is Eligible for Auto Balance Aggregate
[ -flexgroup-index <integer> ] *FlexGroup Index
[ -max-constituent-size {<integer>[KB|MB|GB|TB|PB]} ] *Maximum size of a FlexGroup Constituent
[ -vserver-dr-protection {protected|unprotected} ] Vserver DR Protection
[ -snapshot-snapdb-enabled {true|false} ] *SnapDB Snapshot Metadata Cache
[ -is-space-reporting-logical {true|false} ] Logical Space Reporting
[ -is-space-enforcement-logical {true|false} ] Logical Space Enforcement
[ -tiering-policy <Tiering Policy> ] Volume Tiering Policy
[ -cloud-retrieval-policy {default|on-read|never|promote} ] *Volume Cloud Retrieval Policy
[ -tiering-minimum-cooling-days {2..183} ] *Volume Tiering Minimum Cooling Days
[ -tiering-object-tags <text>, ... ] Tags to be Associated with Objects Stored on a FabricPool
[ -is-qos-internal-allowed {true|false} ] *Allow Volume to Use Internal QoS Policy
[ -is-flexgroup-constituent-active {true|false} ] *Is Active FlexGroup Constituent
[ -workflow {auto|data|hybrid|metadata} ] *Type of Workflow
[ -anti-ransomware-state {disabled|enabled|dry-run|paused|dry-run-paused|enable-paused|disable-in-progress} ] Anti-ransomware State
[ -granular-data {disabled|enabled} ] Granular data
[ -atime-update-period <integer> ] *Access Time Update Period (Seconds)
[ -snapshot-locking-enabled {true|false} ] Enable Snapshot Copy Locking
[ -is-large-size-enabled {true|false} ] Are Large Size Volumes and Files Enabled
[ -is-preserve-unlink-enabled {true|false} ] *Is Preserve Unlink Enabled
[ -is-cloud-write-enabled {true|false} ] *Is Cloud Write Enabled
[ -aggressive-readahead-mode {none|file_prefetch} ] *Aggressive readahead mode
::*> volume create ?
[ -vserver <vserver name> ] Vserver Name (default: svm)
[-volume] <volume name> Volume Name
{ [[-aggregate] <aggregate name>] Aggregate Name
| [ -aggr-list <aggregate name>, ... ] List of Aggregates for FlexGroup Constituents
[ -aggr-list-multiplier {1..1000} ] Aggregate List Repeat Count
[ -optimize-aggr-list {true|false} ] Have the System Optimize the Order of the Aggregate List
| [ -auto-provision-as <FlexGroup> ] Automatically Provision as Volume of Type
[ -support-tiering {true|false} ] Automatically Provision FlexGroup on FabricPools
[ -use-mirrored-aggregates {true|false} ] Automatically Provision FlexGroup on Mirrored Aggregates
[ -encryption-type {none|volume|aggregate} ] Encryption Type
[ -nodes <nodename>, ... ] } List of Nodes Hosting the Volume
[ -size {<integer>[KB|MB|GB|TB|PB]} ] Volume Size
[ -state {online|restricted|offline|force-online|force-offline|mixed} ] Volume State (default: online)
[ -policy <text> ] Export Policy (default: default)
[ -user <user name> ] User ID
[ -group <group name> ] Group ID
[ -security-style <security style> ] Security Style
[ -unix-permissions <unix perm> ] UNIX Permissions (default: ---rwxr-xr-x)
[ -junction-path <junction path> ] Junction Path
[ -junction-active {true|false} ] *Junction Active (default: true)
[ -vsroot {true|false} ] *Vserver Root Volume (default: false)
[ -comment <text (size 0..1023)> ] Comment
{ [ -max-autosize {<integer>[KB|MB|GB|TB|PB]} ] Maximum Autosize
[ -min-autosize {<integer>[KB|MB|GB|TB|PB]} ] Minimum Autosize
[ -autosize-grow-threshold-percent <percent> ] Autosize Grow Threshold Percentage
[ -autosize-shrink-threshold-percent <percent> ] Autosize Shrink Threshold Percentage
[ -autosize-mode {off|grow|grow_shrink} ] Autosize Mode
[ -files-set-maximum {true|false} ] *Set Total Files (for user-visible data) to the Highest Value that the Volume can Hold
[ -maxdir-size {<integer>[KB|MB|GB|TB|PB]} ] *Maximum Directory Size
{ [ -space-slo {none|thick|semi-thick} ] Space SLO
| [ -space-guarantee|-s {none|volume} ] Space Guarantee Style
[ -type {RW|DP} ] } Volume Type (default: RW)
[ -snapdir-access {true|false} ] Snapshot Directory Access Enabled (default: true)
[ -percent-snapshot-space <percent> ] Space Reserved for Snapshot Copies
[ -snapshot-policy <snapshot policy> ] Snapshot Policy (default: default)
[ -language <language_code> ] Language
[ -foreground {true|false} ] Foreground Process (default: true)
[ -nvfail {on|off} ] NVFAIL Option
[ -max-write-alloc-blocks {0..2048} ] *Maximum Write Allocation Blocks (default: 0)
[ -vm-align-sector|-e {1..7} ] *Virtual Machine Alignment 512-Byte Sector Count
[ -vm-align-suffix|-u <text (size 1..32)> ] *Virtual Machine Alignment Suffix
[ -constituent-role <Constituent Roles> ] Constituent Volume Role
{ [ -qos-policy-group <text> ] QoS Policy Group Name
| [ -qos-adaptive-policy-group <text> ] } QoS Adaptive Policy Group Name
[ -caching-policy <text> ] Caching Policy Name
[ -cache-retention-priority {normal|low|high} ] *Cache Retention Priority
[ -is-autobalance-eligible {true|false} ] *Is Eligible for Auto Balance Aggregate
[ -max-constituent-size {<integer>[KB|MB|GB|TB|PB]} ] *Maximum size of a FlexGroup Constituent
[ -efficiency-policy <efficiency policy> ] *Storage Efficiency Policy
[ -snaplock-type {non-snaplock|compliance|enterprise} ] SnapLock Type
[ -vserver-dr-protection {protected|unprotected} ] Vserver DR Protection
[ -snapshot-snapdb-enabled {true|false} ] *SnapDB Snapshot Metadata Cache
[ -encrypt {true|false} ] Enable or Disable Encryption
[ -is-space-reporting-logical {true|false} ] Logical Space Reporting
[ -is-space-enforcement-logical {true|false} ] Logical Space Enforcement
[ -tiering-policy <Tiering Policy> ] Volume Tiering Policy (default: none)
[ -cloud-retrieval-policy {default|on-read|never|promote} ] *Volume Cloud Retrieval Policy
[ -tiering-minimum-cooling-days {2..183} ] *Volume Tiering Minimum Cooling Days
[ -tiering-object-tags <text>, ... ] Tags to be Associated with Objects Stored on a FabricPool
{ [ -application-io-size <Application I/O Size> ] *Block Size to Use by Compression
| [ -storage-efficiency-mode {default|efficient} ] } Storage Efficiency Mode
[ -is-qos-internal-allowed {true|false} ] *Allow Volume to Use Internal QoS Policy
[ -workflow {auto|data|hybrid|metadata} ] *Type of Workflow
[ -analytics-state <Analytics State> ] File System Analytics State (default: off)
[ -activity-tracking-state <Activity Tracking State> ] Activity Tracking State (default: off)
[ -key-manager-attribute <text> ] Key Manager Attribute
[ -anti-ransomware-state {disabled|enabled|dry-run|paused|dry-run-paused|enable-paused|disable-in-progress} ] Anti-ransomware State (default: disabled)
[ -granular-data {disabled|enabled} ] Granular data (default: disabled)
[ -atime-update-period <integer> ] *Access Time Update Period (Seconds)
[ -snapshot-locking-enabled {true|false} ] Enable Snapshot Copy Locking (default: false)
[ -is-large-size-enabled {true|false} ] Are Large Size Volumes and Files Enabled
[ -is-preserve-unlink-enabled {true|false} ] *Is Preserve Unlink Enabled (default: false)
[ -aggressive-readahead-mode {none|file_prefetch} ] *Aggressive readahead mode現在のボリュームの状態は以下のとおりです。cloud write modeは無効です。
FsxId04e5e03055492f9d9::*> volume show -volume vol1 -fields available, filesystem-size, total, used, percent-used, performance-tier-inactive-user-data, performance-tier-inactive-user-data-percent, size, dedupe-space-saved, dedupe-space-saved-percent, dedupe-space-shared,logical-used, logical-used-percent,logical-used-by-afs, logical-available, physical-used, physical-used-percent, tiering-policy, is-cloud-write-enabled
vserver volume size available filesystem-size total used percent-used dedupe-space-saved dedupe-space-saved-percent dedupe-space-shared physical-used physical-used-percent logical-used logical-used-percent logical-available logical-used-by-afs tiering-policy performance-tier-inactive-user-data performance-tier-inactive-user-data-percent is-cloud-write-enabled
------- ------ ----- --------- --------------- ------- ----- ------------ ------------------ -------------------------- ------------------- ------------- --------------------- ------------ -------------------- ----------------- ------------------- -------------- ----------------------------------- ------------------------------------------- ----------------------
svm vol1 128TB 860.6GB 128TB 121.6TB 308KB 0% 0B 0% 0B 308KB 0% 308KB 0% - 308KB all - - false
FsxId04e5e03055492f9d9::*> volume show-footprint -volume vol1
Vserver : svm
Volume : vol1
Feature Used Used%
-------------------------------- ---------- -----
Volume Data Footprint 308KB 0%
Footprint in Performance Tier 1.85MB 100%
Footprint in FSxFabricpoolObjectStore 0B 0%
Volume Guarantee 0B 0%
Flexible Volume Metadata 107.5MB 0%
Delayed Frees 1.55MB 0%
File Operation Metadata 4KB 0%
Total Footprint 109.3MB 0%
Effective Total Footprint 109.3MB 0%
FsxId04e5e03055492f9d9::*> aggr show-space
Aggregate : aggr1
Performance Tier
Feature Used Used%
-------------------------------- ---------- ------
Volume Footprints 1.12GB 0%
Aggregate Metadata 4.36MB 0%
Snapshot Reserve 45.36GB 5%
Total Used 46.48GB 5%
Total Physical Used 51.32MB 0%
Total Provisioned Space 128.0TB
14449%
Aggregate : aggr1
Object Store: FSxFabricpoolObjectStore
Feature Used Used%
-------------------------------- ---------- ------
Logical Used 0B -
Logical Referenced Capacity 0B -
Logical Unreferenced Capacity 0B -
Total Physical Used 0B -
2 entries were displayed.まず、cloud write modeが無効な状態での書き込みをしてみます。
NFSクライアントからボリュームをマウントして、32GiBのファイルを作成します。
$ sudo mount -t nfs svm-00a3699667c00c2c0.fs-04e5e03055492f9d9.fsx.us-east-1.amazonaws.com:/vol1 /mnt/fsxn/vol1
$ df -hT -t nfs4
Filesystem Type Size Used Avail Use% Mounted on
svm-00a3699667c00c2c0.fs-04e5e03055492f9d9.fsx.us-east-1.amazonaws.com:/vol1 nfs4 122T 121T 861G 100% /mnt/fsxn/vol1
$ sudo dd if=/dev/urandom of=/mnt/fsxn/vol1/random_pattern_binary_block_32GiB bs=1M count=32768
32768+0 records in
32768+0 records out
34359738368 bytes (34 GB, 32 GiB) copied, 232.134 s, 148 MB/s書き込み速度は148MBpsでした。
この時のボリュームの情報は以下のとおりです。
::*> date show -fields date
(cluster date show)
node date
------------------------- -------------------------
FsxId04e5e03055492f9d9-01 2/11/2024 07:17:56 +00:00
FsxId04e5e03055492f9d9-02 2/11/2024 07:17:56 +00:00
2 entries were displayed.
FsxId04e5e03055492f9d9::*> volume show -volume vol1 -fields available, filesystem-size, total, used, percent-used, performance-tier-inactive-user-data, performance-tier-inactive-user-data-percent, size, dedupe-space-saved, dedupe-space-saved-percent, dedupe-space-shared,logical-used, logical-used-percent,logical-used-by-afs, logical-available, physical-used, physical-used-percent, tiering-policy, is-cloud-write-enabled
vserver volume size available filesystem-size total used percent-used dedupe-space-saved dedupe-space-saved-percent dedupe-space-shared physical-used physical-used-percent logical-used logical-used-percent logical-available logical-used-by-afs tiering-policy performance-tier-inactive-user-data performance-tier-inactive-user-data-percent is-cloud-write-enabled
------- ------ ----- --------- --------------- ------- ------- ------------ ------------------ -------------------------- ------------------- ------------- --------------------- ------------ -------------------- ----------------- ------------------- -------------- ----------------------------------- ------------------------------------------- ----------------------
svm vol1 128TB 844.1GB 128TB 121.6TB 32.14GB 0% 0B 0% 0B 32.14GB 0% 32.14GB 0% - 32.14GB all - - false
FsxId04e5e03055492f9d9::*> volume show-footprint -volume vol1
Vserver : svm
Volume : vol1
Feature Used Used%
-------------------------------- ---------- -----
Volume Data Footprint 32.14GB 4%
Footprint in Performance Tier 308.5MB 1%
Footprint in FSxFabricpoolObjectStore
32GB 99%
Volume Guarantee 0B 0%
Flexible Volume Metadata 322.4MB 0%
Delayed Frees 167.4MB 0%
File Operation Metadata 4KB 0%
Total Footprint 32.62GB 4%
Effective Total Footprint 32.62GB 4%
FsxId04e5e03055492f9d9::*> aggr show-space
Aggregate : aggr1
Performance Tier
Feature Used Used%
-------------------------------- ---------- ------
Volume Footprints 1.63GB 0%
Aggregate Metadata 16.08GB 2%
Snapshot Reserve 45.36GB 5%
Total Used 63.06GB 7%
Total Physical Used 32.96GB 4%
Total Provisioned Space 128.0TB
14449%
Aggregate : aggr1
Object Store: FSxFabricpoolObjectStore
Feature Used Used%
-------------------------------- ---------- ------
Logical Used 17.36GB -
Logical Referenced Capacity 17.36GB -
Logical Unreferenced Capacity 0B -
Total Physical Used 17.36GB -
2 entries were displayed.
---
::*> date show -fields date
(cluster date show)
node date
------------------------- -------------------------
FsxId04e5e03055492f9d9-01 2/11/2024 07:21:56 +00:00
FsxId04e5e03055492f9d9-02 2/11/2024 07:21:56 +00:00
2 entries were displayed.
FsxId04e5e03055492f9d9::*> volume show -volume vol1 -fields available, filesystem-size, total, used, percent-used, performance-tier-inactive-user-data, performance-tier-inactive-user-data-percent, size, dedupe-space-saved, dedupe-space-saved-percent, dedupe-space-shared,logical-used, logical-used-percent,logical-used-by-afs, logical-available, physical-used, physical-used-percent, tiering-policy, is-cloud-write-enabled
vserver volume size available filesystem-size total used percent-used dedupe-space-saved dedupe-space-saved-percent dedupe-space-shared physical-used physical-used-percent logical-used logical-used-percent logical-available logical-used-by-afs tiering-policy performance-tier-inactive-user-data performance-tier-inactive-user-data-percent is-cloud-write-enabled
------- ------ ----- --------- --------------- ------- ------- ------------ ------------------ -------------------------- ------------------- ------------- --------------------- ------------ -------------------- ----------------- ------------------- -------------- ----------------------------------- ------------------------------------------- ----------------------
svm vol1 128TB 859.9GB 128TB 121.6TB 32.14GB 0% 0B 0% 0B 32.14GB 0% 32.14GB 0% - 32.14GB all - - false
FsxId04e5e03055492f9d9::*> volume show-footprint -volume vol1
Vserver : svm
Volume : vol1
Feature Used Used%
-------------------------------- ---------- -----
Volume Data Footprint 32.14GB 4%
Footprint in Performance Tier 308.5MB 1%
Footprint in FSxFabricpoolObjectStore
32GB 99%
Volume Guarantee 0B 0%
Flexible Volume Metadata 322.4MB 0%
Delayed Frees 167.4MB 0%
File Operation Metadata 4KB 0%
Total Footprint 32.62GB 4%
Effective Total Footprint 32.62GB 4%
FsxId04e5e03055492f9d9::*> aggr show-space
Aggregate : aggr1
Performance Tier
Feature Used Used%
-------------------------------- ---------- ------
Volume Footprints 1.63GB 0%
Aggregate Metadata 257.4MB 0%
Snapshot Reserve 45.36GB 5%
Total Used 47.23GB 5%
Total Physical Used 4.12GB 0%
Total Provisioned Space 128.0TB
14449%
Aggregate : aggr1
Object Store: FSxFabricpoolObjectStore
Feature Used Used%
-------------------------------- ---------- ------
Logical Used 32.28GB -
Logical Referenced Capacity 32.12GB -
Logical Unreferenced Capacity 159.8MB -
Total Physical Used 32.28GB -
2 entries were displayed.書き込み完了後にすぐに確認すると、volume show-footprintでは99%のデータがキャパシティプール上にあるとレポートされていましたが、実際にはキャパシティプールストレージには17.36GBしか書き込まれていませんでした。しばらくすると、32.28GB書き込まれていたので、SSDからキャパシティプールストレージへの書き込みにはラグがあることが分かります。
CloudWatchメトリクスは以下のとおりです。
書き込みを開始すると、まずSSDの使用量が増加し、その後キャパシティプールストレージの使用量が増加していることが分かります。
ONTAPの挙動として、階層化の処理よりもNASアクセスの方が優先されます。大量の書き込みがあればキャパシティプールストレージへの書き込みよりもSSDが一杯になってしまうでしょう。
cloud write modeが有効な状態での書き込み
次に、cloud write modeが有効な状態での書き込みです。
cloud write modeを有効にします。
::*> volume modify -volume vol1 -is-cloud-write-enabled true
Volume modify successful on volume vol1 of Vserver svm.
FsxId04e5e03055492f9d9::*> volume show -volume vol1 -fields is-cloud-write-enabled
vserver volume is-cloud-write-enabled
------- ------ ----------------------
svm vol1 true先ほどと同様に32GiBのファイルを作成します。
$ sudo dd if=/dev/urandom of=/mnt/fsxn/vol1/random_pattern_binary_block_32GiB_2 bs=1M count=32768
32768+0 records in
32768+0 records out
34359738368 bytes (34 GB, 32 GiB) copied, 233.64 s, 147 MB/s書き込み速度は147MBpsでした。cloud write modeが無効の場合と変わりありません。SSDとキャパシティプールストレージを比較すると、SSDの方が書き込み性能は優れていそうです。書き込み速度が変わらないということは、FSxNのメモリ上で一度受け止めて捌いているのでしょうか。それともキャパシティプールストレージへの書き込み速度はSSDと遜色ないのでしょうか。
この時のボリュームの情報は以下のとおりです。
FsxId04e5e03055492f9d9::*> volume show -volume vol1 -fields available, filesystem-size, total, used, percent-used, performance-tier-inactive-user-data, performance-tier-inactive-user-data-percent, size, dedupe-space-saved, dedupe-space-saved-percent, dedupe-space-shared,logical-used, logical-used-percent,logical-used-by-afs, logical-available, physical-used, physical-used-percent, tiering-policy, is-cloud-write-enabled
vserver volume size available filesystem-size total used percent-used dedupe-space-saved dedupe-space-saved-percent dedupe-space-shared physical-used physical-used-percent logical-used logical-used-percent logical-available logical-used-by-afs tiering-policy performance-tier-inactive-user-data performance-tier-inactive-user-data-percent is-cloud-write-enabled
------- ------ ----- --------- --------------- ------- ------- ------------ ------------------ -------------------------- ------------------- ------------- --------------------- ------------ -------------------- ----------------- ------------------- -------------- ----------------------------------- ------------------------------------------- ----------------------
svm vol1 128TB 859.4GB 128TB 121.6TB 64.27GB 0% 0B 0% 0B 64.27GB 0% 64.27GB 0% - 64.27GB all - - true
FsxId04e5e03055492f9d9::*> volume show-footprint -volume vol1
Vserver : svm
Volume : vol1
Feature Used Used%
-------------------------------- ---------- -----
Volume Data Footprint 64.27GB 7%
Footprint in Performance Tier 466.7MB 1%
Footprint in FSxFabricpoolObjectStore
64GB 99%
Volume Guarantee 0B 0%
Flexible Volume Metadata 429.9MB 0%
Delayed Frees 186.4MB 0%
File Operation Metadata 4KB 0%
Total Footprint 64.88GB 7%
Effective Total Footprint 64.88GB 7%
FsxId04e5e03055492f9d9::*> aggr show-space
Aggregate : aggr1
Performance Tier
Feature Used Used%
-------------------------------- ---------- ------
Volume Footprints 1.89GB 0%
Aggregate Metadata 507.5MB 0%
Snapshot Reserve 45.36GB 5%
Total Used 47.74GB 5%
Total Physical Used 19.66GB 2%
Total Provisioned Space 128.0TB
14449%
Aggregate : aggr1
Object Store: FSxFabricpoolObjectStore
Feature Used Used%
-------------------------------- ---------- ------
Logical Used 64.56GB -
Logical Referenced Capacity 64.25GB -
Logical Unreferenced Capacity 319.5MB -
Total Physical Used 64.56GB -
2 entries were displayed.書き込みが完了して数秒以内に確認しましたが、すでにキャパシティプールストレージの使用量は64.56GBとなっています。
CloudWatchメトリクスは以下のとおりです。
SSD使用量の増減がほとんどありません。一方で、キャパシティプールストレージの使用量は書き込んでいる間、ほぼ単調に増加しています。
これはすごい。顧客が求めていたものです。
cloud write modeが有効な状態での書き込み (64GiB)
より、大きいサイズのデータを一気に書き込む場合はどうでしょうか。転送速度が落ちるのか気になります。
FSxNファイルシステムのスループットキャパシティは128MBpsです。
::*> node virtual-machine instance show-settings -node FsxId04e5e03055492f9d9-01 -instance
Node: FsxId04e5e03055492f9d9-01
Provider VM Name: -
Consumer of this Instance: FSx
Storage Type for the Instance: SSD
Storage Capacity for the Instance in GB: 1024
Committed IOPS per GB for the Instance: 3072
Maximum Throughput Capacity in MB/s for the Instance: 128
Total Network Bandwidth Limit in MB/s: -
Total Volume Bandwidth Limit in MB/s: -スループットキャパシティが128MBpsの場合のインメモリキャッシュサイズは16GBです。インメモリキャッシュサイズ = メモリサイズという訳ではないですが、目安にはなるような気がします。
試しに64GiBのファイルを追加します。
64GiBのデータを受け止められるように、ボリュームサイズを256GiBに変更します。
::*> volume modify -volume vol1 -size 256GB
Volume modify successful on volume vol1 of Vserver svm.
FsxId04e5e03055492f9d9::*> volume show -volume vol1
Vserver Volume Aggregate State Type Size Available Used%
--------- ------------ ------------ ---------- ---- ---------- ---------- -----
svm vol1 aggr1 online RW 256GB 178.9GB 26%64GiBのファイルを作成します。
$ sudo dd if=/dev/urandom of=/mnt/fsxn/vol1/random_pattern_binary_block_64GiB bs=1M count=65536
65536+0 records in
65536+0 records out
68719476736 bytes (69 GB, 64 GiB) copied, 467.893 s, 147 MB/s書き込み速度は147MBpsでした。またしてもcloud write modeが無効の状態と変わりありません。
ボリュームの状態は以下のとおりです。
FsxId04e5e03055492f9d9::*> volume show -volume vol1 -fields available, filesystem-size, total, used, percent-used, performance-tier-inactive-user-data, performance-tier-inactive-user-data-percent, size, dedupe-space-saved, dedupe-space-saved-percent, dedupe-space-shared,logical-used, logical-used-percent,logical-used-by-afs, logical-available, physical-used, physical-used-percent, tiering-policy, is-cloud-write-enabled
vserver volume size available filesystem-size total used percent-used dedupe-space-saved dedupe-space-saved-percent dedupe-space-shared physical-used physical-used-percent logical-used logical-used-percent logical-available logical-used-by-afs tiering-policy performance-tier-inactive-user-data performance-tier-inactive-user-data-percent is-cloud-write-enabled
------- ------ ----- --------- --------------- ------- ------- ------------ ------------------ -------------------------- ------------------- ------------- --------------------- ------------ -------------------- ----------------- ------------------- -------------- ----------------------------------- ------------------------------------------- ----------------------
svm vol1 256GB 114.7GB 256GB 243.2GB 128.5GB 52% 0B 0% 0B 128.5GB 50% 128.5GB 53% - 128.5GB all - - true
FsxId04e5e03055492f9d9::*> volume show-footprint -volume vol1
Vserver : svm
Volume : vol1
Feature Used Used%
-------------------------------- ---------- -----
Volume Data Footprint 128.5GB 14%
Footprint in Performance Tier 782.7MB 1%
Footprint in FSxFabricpoolObjectStore
128GB 99%
Volume Guarantee 0B 0%
Flexible Volume Metadata 752.3MB 0%
Delayed Frees 224.1MB 0%
File Operation Metadata 4KB 0%
Total Footprint 129.5GB 14%
Effective Total Footprint 129.5GB 14%
FsxId04e5e03055492f9d9::*> aggr show-space
Aggregate : aggr1
Performance Tier
Feature Used Used%
-------------------------------- ---------- ------
Volume Footprints 2.51GB 0%
Aggregate Metadata 748.3MB 0%
Snapshot Reserve 45.36GB 5%
Total Used 48.60GB 5%
Total Physical Used 22.83GB 3%
Total Provisioned Space 257GB 28%
Aggregate : aggr1
Object Store: FSxFabricpoolObjectStore
Feature Used Used%
-------------------------------- ---------- ------
Logical Used 129.1GB -
Logical Referenced Capacity 128.5GB -
Logical Unreferenced Capacity 639MB -
Total Physical Used 129.1GB -
2 entries were displayed.書き込みが完了して即座に確認しましたが、キャパシティプールストレージの使用量は129.1GBとなっています。
cloud write modeが有効な状態での書き込み (スループットキャパシティ 512MBps)
スループットキャパシティが512MBpsの場合はどうでしょうか。もしかすると、キャパシティプールストレージへの書き込みスループットの上限が150MBpsほどで、それ以上はスケールしないかもしれません。
FSxNファイルシステムのスループットキャパシティを128MBpsから512MBpsに変更しました。30分ほどかかりました。
::*> node virtual-machine instance show-settings -node FsxId04e5e03055492f9d9-0* -instance
Node: FsxId04e5e03055492f9d9-01
Provider VM Name: -
Consumer of this Instance: FSx
Storage Type for the Instance: SSD
Storage Capacity for the Instance in GB: 1024
Committed IOPS per GB for the Instance: 3072
Maximum Throughput Capacity in MB/s for the Instance: 512
Total Network Bandwidth Limit in MB/s: -
Total Volume Bandwidth Limit in MB/s: -
Node: FsxId04e5e03055492f9d9-02
Provider VM Name: -
Consumer of this Instance: FSx
Storage Type for the Instance: SSD
Storage Capacity for the Instance in GB: 1024
Committed IOPS per GB for the Instance: 3072
Maximum Throughput Capacity in MB/s for the Instance: 512
Total Network Bandwidth Limit in MB/s: -
Total Volume Bandwidth Limit in MB/s: -
2 entries were displayed.ファイルを追加するにあたって、ボリュームサイズを100TiBに拡張します。
::*> volume modify -volume vol1 -size 100TB
Volume modify successful on volume vol1 of Vserver svm.
FsxId04e5e03055492f9d9::*> volume show -volume vol1
Vserver Volume Aggregate State Type Size Available Used%
--------- ------------ ------------ ---------- ---- ---------- ---------- -----
svm vol1 aggr1 online RW 100TB 858.6GB 0%また、EC2インスタンスの性能がボトルネックになるのは嫌です。c7i2.xlargeに変更します。
$ lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 46 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-7
Vendor ID: GenuineIntel
Model name: Intel(R) Xeon(R) Platinum 8488C
CPU family: 6
Model: 143
Thread(s) per core: 2
Core(s) per socket: 4
Socket(s): 1
Stepping: 8
BogoMIPS: 4800.00
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq
pni pclmulqdq monitor ssse3 fma cx16 pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single ssbd ibrs ibpb stibp ibrs_enhanced fsgsbase tsc_a
djust bmi1 avx2 smep bmi2 erms invpcid avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves avx_vnni avx512_bf16 wbnoinvd ida arat avx512vbmi umip pku ospk
e waitpkg avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg tme avx512_vpopcntdq rdpid cldemote movdiri movdir64b md_clear serialize amx_bf16 avx512_fp16 amx_tile amx_int8 flush_l1d arch_capabilities
Virtualization features:
Hypervisor vendor: KVM
Virtualization type: full
Caches (sum of all):
L1d: 192 KiB (4 instances)
L1i: 128 KiB (4 instances)
L2: 8 MiB (4 instances)
L3: 105 MiB (1 instance)
NUMA:
NUMA node(s): 1
NUMA node0 CPU(s): 0-7
Vulnerabilities:
Gather data sampling: Not affected
Itlb multihit: Not affected
L1tf: Not affected
Mds: Not affected
Meltdown: Not affected
Mmio stale data: Not affected
Retbleed: Not affected
Spec rstack overflow: Not affected
Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl
Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Spectre v2: Mitigation; Enhanced IBRS, IBPB conditional, RSB filling, PBRSB-eIBRS SW sequence
Srbds: Not affected
Tsx async abort: Not affectedせっかくなのでfioで計測しましょう。fioをインストールします。
$ sudo dnf install fio
Last metadata expiration check: 2:24:20 ago on Sun Feb 11 07:02:45 2024.Dependencies resolved.
==============================================================================================================
Package Architecture Version Repository Size
==============================================================================================================
Installing:
fio x86_64 3.32-2.amzn2023.0.3 amazonlinux 5.2 M
Installing dependencies:
librdmacm x86_64 37.0-1.amzn2023.0.3 amazonlinux 72 k
Installing weak dependencies:
fio-engine-http x86_64 3.32-2.amzn2023.0.3 amazonlinux 20 k
fio-engine-libaio x86_64 3.32-2.amzn2023.0.3 amazonlinux 17 k
fio-engine-rdma x86_64 3.32-2.amzn2023.0.3 amazonlinux 23 k
Transaction Summary
==============================================================================================================
Install 5 Packages
Total download size: 5.3 M
Installed size: 7.6 M
Is this ok [y/N]: y
Downloading Packages:
(1/5): fio-engine-http-3.32-2.amzn2023.0.3.x86_64.rpm 300 kB/s | 20 kB 00:00
(2/5): librdmacm-37.0-1.amzn2023.0.3.x86_64.rpm 801 kB/s | 72 kB 00:00
(3/5): fio-engine-rdma-3.32-2.amzn2023.0.3.x86_64.rpm 546 kB/s | 23 kB 00:00
(4/5): fio-engine-libaio-3.32-2.amzn2023.0.3.x86_64.rpm 301 kB/s | 17 kB 00:00
(5/5): fio-3.32-2.amzn2023.0.3.x86_64.rpm 26 MB/s | 5.2 MB 00:00
--------------------------------------------------------------------------------------------------------------
Total 22 MB/s | 5.3 MB 00:00
Running transaction check
Transaction check succeeded.
.
.
(中略)
.
.
Installed:
fio-3.32-2.amzn2023.0.3.x86_64 fio-engine-http-3.32-2.amzn2023.0.3.x86_64
fio-engine-libaio-3.32-2.amzn2023.0.3.x86_64 fio-engine-rdma-3.32-2.amzn2023.0.3.x86_64
librdmacm-37.0-1.amzn2023.0.3.x86_64
Complete!fioでスループット計測します。16多重でランダムで書き込みます。
$ sudo fio \
--directory=/mnt/fsxn/vol1/ \
--name fio_rw_1MiB_block_128GiB_16jobs \
--ioengine=psync \
--direct=1 \
--rw=randwrite \
--bs=1M \
--size=128G \
--numjobs=16 \
--runtime=600 \
--group_reporting \
--norandommap
fio_rw_1MiB_block_128GiB_16jobs: (g=0): rw=randwrite, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=psync, iodepth=1
...
fio-3.32
Starting 16 processes
fio_rw_1MiB_block_128GiB_16jobs: Laying out IO file (1 file / 131072MiB)
fio_rw_1MiB_block_128GiB_16jobs: Laying out IO file (1 file / 131072MiB)
fio_rw_1MiB_block_128GiB_16jobs: Laying out IO file (1 file / 131072MiB)
fio_rw_1MiB_block_128GiB_16jobs: Laying out IO file (1 file / 131072MiB)
fio_rw_1MiB_block_128GiB_16jobs: Laying out IO file (1 file / 131072MiB)
fio_rw_1MiB_block_128GiB_16jobs: Laying out IO file (1 file / 131072MiB)
fio_rw_1MiB_block_128GiB_16jobs: Laying out IO file (1 file / 131072MiB)
fio_rw_1MiB_block_128GiB_16jobs: Laying out IO file (1 file / 131072MiB)
fio_rw_1MiB_block_128GiB_16jobs: Laying out IO file (1 file / 131072MiB)
fio_rw_1MiB_block_128GiB_16jobs: Laying out IO file (1 file / 131072MiB)
fio_rw_1MiB_block_128GiB_16jobs: Laying out IO file (1 file / 131072MiB)
fio_rw_1MiB_block_128GiB_16jobs: Laying out IO file (1 file / 131072MiB)
fio_rw_1MiB_block_128GiB_16jobs: Laying out IO file (1 file / 131072MiB)
fio_rw_1MiB_block_128GiB_16jobs: Laying out IO file (1 file / 131072MiB)
fio_rw_1MiB_block_128GiB_16jobs: Laying out IO file (1 file / 131072MiB)
fio_rw_1MiB_block_128GiB_16jobs: Laying out IO file (1 file / 131072MiB)
Jobs: 16 (f=16): [w(16)][100.0%][w=360MiB/s][w=360 IOPS][eta 00m:00s]
fio_rw_1MiB_block_128GiB_16jobs: (groupid=0, jobs=16): err= 0: pid=26180: Sun Feb 11 09:37:45 2024
write: IOPS=404, BW=405MiB/s (424MB/s)(237GiB/600022msec); 0 zone resets
clat (msec): min=9, max=379, avg=39.51, stdev=29.64
lat (msec): min=9, max=379, avg=39.55, stdev=29.64
clat percentiles (msec):
| 1.00th=[ 23], 5.00th=[ 25], 10.00th=[ 26], 20.00th=[ 27],
| 30.00th=[ 27], 40.00th=[ 28], 50.00th=[ 28], 60.00th=[ 29],
| 70.00th=[ 32], 80.00th=[ 39], 90.00th=[ 74], 95.00th=[ 108],
| 99.00th=[ 171], 99.50th=[ 188], 99.90th=[ 218], 99.95th=[ 236],
| 99.99th=[ 305]
bw ( KiB/s): min=235520, max=606208, per=100.00%, avg=414409.25, stdev=3333.75, samples=19184
iops : min= 230, max= 592, avg=404.61, stdev= 3.25, samples=19184
lat (msec) : 10=0.01%, 20=0.01%, 50=84.13%, 100=10.27%, 250=5.55%
lat (msec) : 500=0.04%
cpu : usr=0.13%, sys=0.28%, ctx=242772, majf=0, minf=142
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued rwts: total=0,242718,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=1
Run status group 0 (all jobs):
WRITE: bw=405MiB/s (424MB/s), 405MiB/s-405MiB/s (424MB/s-424MB/s), io=237GiB (255GB), run=600022-600022msec書き込みスループットは405MiBpsです。これは速い。また、そこまでCPUは使われていなさそうです。
EC2インスタンスのCloudWatchメトリクスCPU使用率を確認すると、8%ほどでした。
CloudWatchメトリクスは以下のとおりです。線形に増加していますね。
ボリュームの情報は以下のとおりです。
FsxId04e5e03055492f9d9::*> volume show -volume vol1 -fields available, filesystem-size, total, used, percent-used, performance-tier-inactive-user-data, performance-tier-inactive-user-data-percent, size, dedupe-space-saved, dedupe-space-saved-percent, dedupe-space-shared,logical-used, logical-used-percent,logical-used-by-afs, logical-available, physical-used, physical-used-percent, tiering-policy, is-cloud-write-enabled
vserver volume size available filesystem-size total used percent-used dedupe-space-saved dedupe-space-saved-percent dedupe-space-shared physical-used physical-used-percent logical-used logical-used-percent logical-available logical-used-by-afs tiering-policy performance-tier-inactive-user-data performance-tier-inactive-user-data-percent is-cloud-write-enabled
------- ------ ----- --------- --------------- ----- ------- ------------ ------------------ -------------------------- ------------------- ------------- --------------------- ------------ -------------------- ----------------- ------------------- -------------- ----------------------------------- ------------------------------------------- ----------------------
svm vol1 100TB 853.4GB 100TB 95TB 357.9GB 0% 0B 0% 0B 357.8GB 0% 357.9GB 0% - 357.9GB all - - true
FsxId04e5e03055492f9d9::*> volume show-footprint -volume vol1
Vserver : svm
Volume : vol1
Feature Used Used%
-------------------------------- ---------- -----
Volume Data Footprint 357.8GB 39%
Footprint in Performance Tier 4.18GB 1%
Footprint in FSxFabricpoolObjectStore
355.4GB 99%
Volume Guarantee 0B 0%
Flexible Volume Metadata 2.08GB 0%
Delayed Frees 1.73GB 0%
File Operation Metadata 4KB 0%
Total Footprint 361.6GB 40%
Effective Total Footprint 361.6GB 40%
FsxId04e5e03055492f9d9::*> aggr show-space
Aggregate : aggr1
Performance Tier
Feature Used Used%
-------------------------------- ---------- ------
Volume Footprints 7.27GB 1%
Aggregate Metadata 1.11GB 0%
Snapshot Reserve 45.36GB 5%
Total Used 53.74GB 6%
Total Physical Used 26.59GB 3%
Total Provisioned Space 100.0TB
11289%
Aggregate : aggr1
Object Store: FSxFabricpoolObjectStore
Feature Used Used%
-------------------------------- ---------- ------
Logical Used 368.2GB -
Logical Referenced Capacity 366.4GB -
Logical Unreferenced Capacity 1.78GB -
Space Saved by Storage Efficiency 59.97MB -
Total Physical Used 368.2GB -
2 entries were displayed.cloud write modeの有無での書き込みスループットの比較
cloud write modeが有効の場合
少しだけcloud write modeの有無での書き込みスループットの比較をしていきます。
EC2インスタンスがボトルネックになると嫌なのでc7i.16xlargeに変更します。
$ lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 46 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 64
On-line CPU(s) list: 0-63
Vendor ID: GenuineIntel
Model name: Intel(R) Xeon(R) Platinum 8488C
CPU family: 6
Model: 143
Thread(s) per core: 2
Core(s) per socket: 32
Socket(s): 1
Stepping: 8
BogoMIPS: 4800.00
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmo
n rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq monitor ssse3 fma cx16 pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_de
adline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single ssbd ibrs ibpb stibp ibrs_enhanced fsgsbase tsc_adjust bmi1 avx2 s
mep bmi2 erms invpcid avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves avx_vnni a
vx512_bf16 wbnoinvd ida arat avx512vbmi umip pku ospke waitpkg avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg tme avx512_vpopcntdq rdpid cldemot
e movdiri movdir64b md_clear serialize amx_bf16 avx512_fp16 amx_tile amx_int8 flush_l1d arch_capabilities
Virtualization features:
Hypervisor vendor: KVM
Virtualization type: full
Caches (sum of all):
L1d: 1.5 MiB (32 instances)
L1i: 1 MiB (32 instances)
L2: 64 MiB (32 instances)
L3: 105 MiB (1 instance)
NUMA:
NUMA node(s): 1
NUMA node0 CPU(s): 0-63
Vulnerabilities:
Gather data sampling: Not affected
Itlb multihit: Not affected
L1tf: Not affected
Mds: Not affected
Meltdown: Not affected
Mmio stale data: Not affected
Retbleed: Not affected
Spec rstack overflow: Not affected
Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl
Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Spectre v2: Mitigation; Enhanced IBRS, IBPB conditional, RSB filling, PBRSB-eIBRS SW sequence
Srbds: Not affected
Tsx async abort: Not affected1MiBブロックを64多重で書き込みます。
$ sudo fio \
--directory=/mnt/fsxn/vol1/ \
--name fio_rw_1MiB_block_128GiB_64jobs \
--ioengine=psync \
--direct=1 \
--rw=randwrite \
--bs=1M \
--size=128G \
--numjobs=64 \
--runtime=600 \
--group_reporting \
--norandommap
fio_rw_1MiB_block_128GiB_64jobs: (g=0): rw=randwrite, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=psync, iodepth=1
...
fio-3.32
Starting 64 processes
fio_rw_1MiB_block_128GiB_64jobs: Laying out IO file (1 file / 131072MiB)
fio_rw_1MiB_block_128GiB_64jobs: Laying out IO file (1 file / 131072MiB)
.
.
(中略)
.
.
fio_rw_1MiB_block_128GiB_64jobs: Laying out IO file (1 file / 131072MiB)
fio_rw_1MiB_block_128GiB_64jobs: Laying out IO file (1 file / 131072MiB)
Jobs: 64 (f=64): [w(64)][100.0%][w=387MiB/s][w=387 IOPS][eta 00m:00s]
fio_rw_1MiB_block_128GiB_64jobs: (groupid=0, jobs=64): err= 0: pid=7110: Sun Feb 11 10:14:00 2024
write: IOPS=400, BW=400MiB/s (420MB/s)(235GiB/600060msec); 0 zone resets
clat (msec): min=62, max=797, avg=159.79, stdev=67.63
lat (msec): min=62, max=797, avg=159.81, stdev=67.62
clat percentiles (msec):
| 1.00th=[ 106], 5.00th=[ 108], 10.00th=[ 109], 20.00th=[ 111],
| 30.00th=[ 113], 40.00th=[ 116], 50.00th=[ 120], 60.00th=[ 142],
| 70.00th=[ 180], 80.00th=[ 215], 90.00th=[ 275], 95.00th=[ 305],
| 99.00th=[ 342], 99.50th=[ 355], 99.90th=[ 451], 99.95th=[ 493],
| 99.99th=[ 793]
bw ( KiB/s): min=184348, max=610656, per=100.00%, avg=410607.87, stdev=1172.25, samples=76672
iops : min= 180, max= 596, avg=400.84, stdev= 1.14, samples=76672
lat (msec) : 100=0.01%, 250=85.88%, 500=14.07%, 750=0.01%, 1000=0.03%
cpu : usr=0.02%, sys=0.06%, ctx=240512, majf=1, minf=704
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued rwts: total=0,240286,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=1
Run status group 0 (all jobs):
WRITE: bw=400MiB/s (420MB/s), 400MiB/s-400MiB/s (420MB/s-420MB/s), io=235GiB (252GB), run=600060-600060msec書き込みスループットは400MiBpsですね。
4KiBブロックを64多重で書き込みます。
$ sudo fio \
--directory=/mnt/fsxn/vol1/ \
--name fio_rw_4KiB_block_128GiB_64jobs \
--ioengine=psync \
--direct=1 \
--rw=randwrite \
--bs=4K \
--size=128G \
--numjobs=64 \
--loop=0 \
--group_reporting \
--norandommap
fio_rw_4KiB_block_128GiB_64jobs: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=1
...
fio-3.32
Starting 64 processes
fio_rw_4KiB_block_128GiB_64jobs: Laying out IO file (1 file / 131072MiB)
fio_rw_4KiB_block_128GiB_64jobs: Laying out IO file (1 file / 131072MiB)
.
.
(中略)
.
.
fio_rw_4KiB_block_128GiB_64jobs: Laying out IO file (1 file / 131072MiB)
fio_rw_4KiB_block_128GiB_64jobs: Laying out IO file (1 file / 131072MiB)
^Cbs: 64 (f=64): [w(64)][-.-%][w=95.3MiB/s][w=24.4k IOPS][eta 00m:00s]
fio: terminating on signal 2
fio_rw_4KiB_block_128GiB_64jobs: (groupid=0, jobs=64): err= 0: pid=8020: Sun Feb 11 10:26:51 2024
write: IOPS=32.1k, BW=125MiB/s (132MB/s)(54.9GiB/447899msec); 0 zone resets
clat (usec): min=1312, max=1118.4k, avg=1990.60, stdev=2670.15
lat (usec): min=1312, max=1118.4k, avg=1990.91, stdev=2670.15
clat percentiles (usec):
| 1.00th=[ 1483], 5.00th=[ 1549], 10.00th=[ 1598], 20.00th=[ 1663],
| 30.00th=[ 1713], 40.00th=[ 1762], 50.00th=[ 1811], 60.00th=[ 1844],
| 70.00th=[ 1909], 80.00th=[ 1991], 90.00th=[ 2147], 95.00th=[ 2376],
| 99.00th=[ 6587], 99.50th=[ 8160], 99.90th=[ 21627], 99.95th=[ 40109],
| 99.99th=[104334]
bw ( KiB/s): min=20689, max=152396, per=100.00%, avg=128517.47, stdev=244.54, samples=57276
iops : min= 5172, max=38099, avg=32127.63, stdev=61.16, samples=57276
lat (msec) : 2=81.03%, 4=17.28%, 10=1.40%, 20=0.18%, 50=0.07%
lat (msec) : 100=0.03%, 250=0.01%, 500=0.01%, 750=0.01%, 1000=0.01%
lat (msec) : 2000=0.01%
cpu : usr=0.27%, sys=0.78%, ctx=14380851, majf=1, minf=737
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued rwts: total=0,14380182,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=1
Run status group 0 (all jobs):
WRITE: bw=125MiB/s (132MB/s), 125MiB/s-125MiB/s (132MB/s-132MB/s), io=54.9GiB (58.9GB), run=447899-447899msec書き込みスループットは125MiBpsでした。ただしIOPSが32.1Kです。FSxNファイルシステムSSDのIOPSは3,072です。IOPS周りのメトリクスを確認してみます。
10:03~10:15の山が1MiBブロックで書き込んだとき、10:18~の山が1KiBブロック書き込んだときです。ファイルサーバーとストレージボリューム間のディスク IOPSをSSDのプロビジョニングされたディスク IOPS 制限に対する割合DiskIopsUtilizationはどちらのパターンも100%付近を指しています。
一方で、ファイルサーバーの使用可能なディスク IOPSキャパシティのIOPS 使用率FileServerDiskIopsUtilizationは20%未満と低い値を指しています。そのため、NFSクライアントとFSxNファイルシステムのインターフェイス間のIOPSには余裕がありそうです。
SSDに対する書き込みIOPSを確認してみます。
3,000前後を推移しています。cloud write modeを有効化していてもFSxN的にはSSDに書き込むときと同じ操作を指しているようです。そのため、SSDのIOPS上限の影響は受けそうですね。
キャパシティプールストレージの書き込みIOPSを確認してみます。
こちらは100前後です。キャパシティプールストレージの書き込みは4KiBのデータブロックを1,000個単位でまとめて行うので違和感はありません。
続いて、4MiBブロックで64多重で書き込みます。
$ sudo fio \
--directory=/mnt/fsxn/vol1/ \
--name fio_rw_4MiB_block_64GiB_64jobs \
--ioengine=psync \
--direct=1 \
--rw=randwrite \
--bs=4M \
--size=64G \
--numjobs=64 \
--runtime=60 \
--group_reporting \
--norandommap
fio_rw_4MiB_block_64GiB_64jobs: (g=0): rw=randwrite, bs=(R) 4096KiB-4096KiB, (W) 4096KiB-4096KiB, (T) 4096KiB-4096KiB, ioengine=psync, iodepth=1
...
fio-3.32
Starting 64 processes
fio_rw_4MiB_block_64GiB_64jobs: Laying out IO file (1 file / 65536MiB)
fio_rw_4MiB_block_64GiB_64jobs: Laying out IO file (1 file / 65536MiB)
.
.
(中略)
.
.
fio_rw_4MiB_block_64GiB_64jobs: Laying out IO file (1 file / 65536MiB)
fio_rw_4MiB_block_64GiB_64jobs: Laying out IO file (1 file / 65536MiB)
Jobs: 64 (f=64): [w(64)][100.0%][w=368MiB/s][w=92 IOPS][eta 00m:00s]
fio_rw_4MiB_block_64GiB_64jobs: (groupid=0, jobs=64): err= 0: pid=9083: Sun Feb 11 10:30:55 2024
write: IOPS=97, BW=391MiB/s (410MB/s)(23.0GiB/60214msec); 0 zone resets
clat (msec): min=92, max=1355, avg=653.74, stdev=128.16
lat (msec): min=92, max=1355, avg=653.93, stdev=128.16
clat percentiles (msec):
| 1.00th=[ 439], 5.00th=[ 510], 10.00th=[ 523], 20.00th=[ 558],
| 30.00th=[ 592], 40.00th=[ 625], 50.00th=[ 642], 60.00th=[ 659],
| 70.00th=[ 693], 80.00th=[ 735], 90.00th=[ 776], 95.00th=[ 827],
| 99.00th=[ 1284], 99.50th=[ 1351], 99.90th=[ 1351], 99.95th=[ 1351],
| 99.99th=[ 1351]
bw ( KiB/s): min=524271, max=533376, per=100.00%, avg=524387.68, stdev=106.77, samples=5824
iops : min= 127, max= 130, avg=128.01, stdev= 0.03, samples=5824
lat (msec) : 100=0.02%, 500=4.13%, 750=81.29%, 1000=12.33%, 2000=2.24%
cpu : usr=0.02%, sys=0.07%, ctx=6107, majf=1, minf=583
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued rwts: total=0,5889,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=1
Run status group 0 (all jobs):
WRITE: bw=391MiB/s (410MB/s), 391MiB/s-391MiB/s (410MB/s-410MB/s), io=23.0GiB (24.7GB), run=60214-60214msec書き込みスループットは391MiBpsでした。
cloud write modeが無効の場合
cloud write modeが無効の場合も確認します。
まず、cloud write modeを無効にします。
::*> volume modify -volume vol1 -is-cloud-write-enabled false
Volume modify successful on volume vol1 of Vserver svm.
FsxId04e5e03055492f9d9::*> volume show -volume vol1 -fields is-cloud-write-enabled
vserver volume is-cloud-write-enabled
------- ------ ----------------------
svm vol1 false4MiBブロックを64多重で書き込みます。
$ sudo fio \
--directory=/mnt/fsxn/vol1/ \
--name fio_rw_1MiB_block_64GiB_64jobs_cloud_write_false \
--ioengine=psync \
--direct=1 \
--rw=randwrite \
--bs=1M \
--size=64G \
--numjobs=64 \
--runtime=60 \
--group_reporting \
--norandommap
fio_rw_1MiB_block_64GiB_64jobs_cloud_write_false: (g=0): rw=randwrite, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=psync, iodepth=1
...
fio-3.32
Starting 64 processes
fio_rw_1MiB_block_64GiB_64jobs_cloud_write_false: Laying out IO file (1 file / 65536MiB)
fio_rw_1MiB_block_64GiB_64jobs_cloud_write_false: Laying out IO file (1 file / 65536MiB)
.
.
(中略)
.
.
fio_rw_1MiB_block_64GiB_64jobs_cloud_write_false: Laying out IO file (1 file / 65536MiB)
fio_rw_1MiB_block_64GiB_64jobs_cloud_write_false: Laying out IO file (1 file / 65536MiB)
Jobs: 64 (f=64): [w(64)][100.0%][w=553MiB/s][w=552 IOPS][eta 00m:00s]
fio_rw_1MiB_block_64GiB_64jobs_cloud_write_false: (groupid=0, jobs=64): err= 0: pid=9502: Sun Feb 11 10:34:41 2024
write: IOPS=555, BW=555MiB/s (582MB/s)(32.6GiB/60067msec); 0 zone resets
clat (msec): min=4, max=153, avg=115.13, stdev= 4.08
lat (msec): min=4, max=153, avg=115.16, stdev= 4.08
clat percentiles (msec):
| 1.00th=[ 108], 5.00th=[ 109], 10.00th=[ 111], 20.00th=[ 113],
| 30.00th=[ 114], 40.00th=[ 115], 50.00th=[ 115], 60.00th=[ 116],
| 70.00th=[ 117], 80.00th=[ 118], 90.00th=[ 120], 95.00th=[ 121],
| 99.00th=[ 126], 99.50th=[ 129], 99.90th=[ 146], 99.95th=[ 148],
| 99.99th=[ 148]
bw ( KiB/s): min=489659, max=655440, per=99.97%, avg=568523.63, stdev=977.84, samples=7649
iops : min= 477, max= 640, avg=555.18, stdev= 0.96, samples=7649
lat (msec) : 10=0.01%, 50=0.01%, 100=0.18%, 250=99.81%
cpu : usr=0.03%, sys=0.09%, ctx=33604, majf=0, minf=586
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued rwts: total=0,33359,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=1
Run status group 0 (all jobs):
WRITE: bw=555MiB/s (582MB/s), 555MiB/s-555MiB/s (582MB/s-582MB/s), io=32.6GiB (35.0GB), run=60067-60067msec書き込みスループットは555MiBpsでした。cloud write modeが有効の場合はインスタンスタイプと書き込み時の多重度が違うので直接的な比較はできないですが、流石の速さです。
1KiBブロックを64多重で書き込みます。
$ sudo fio \
--directory=/mnt/fsxn/vol1/ \
--name fio_rw_4KiB_block_64GiB_64jobs_cloud_write_false \
--ioengine=psync \
--direct=1 \
--rw=randwrite \
--bs=4K \
--size=64G \
--numjobs=64 \
--runtime=60 \
--group_reporting \
--norandommap
fio_rw_4KiB_block_64GiB_64jobs_cloud_write_false: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=1
...
fio-3.32
Starting 64 processes
fio_rw_4KiB_block_64GiB_64jobs_cloud_write_false: Laying out IO file (1 file / 65536MiB)
fio_rw_4KiB_block_64GiB_64jobs_cloud_write_false: Laying out IO file (1 file / 65536MiB)
.
.
(中略)
.
.
fio_rw_4KiB_block_64GiB_64jobs_cloud_write_false: Laying out IO file (1 file / 65536MiB)
fio_rw_4KiB_block_64GiB_64jobs_cloud_write_false: Laying out IO file (1 file / 65536MiB)
Jobs: 64 (f=64): [w(64)][100.0%][w=108MiB/s][w=27.7k IOPS][eta 00m:00s]
fio_rw_4KiB_block_64GiB_64jobs_cloud_write_false: (groupid=0, jobs=64): err= 0: pid=9738: Sun Feb 11 10:36:15 2024
write: IOPS=34.0k, BW=133MiB/s (139MB/s)(7977MiB/60003msec); 0 zone resets
clat (usec): min=1319, max=98844, avg=1877.64, stdev=635.29
lat (usec): min=1319, max=98844, avg=1877.95, stdev=635.30
clat percentiles (usec):
| 1.00th=[ 1467], 5.00th=[ 1549], 10.00th=[ 1598], 20.00th=[ 1663],
| 30.00th=[ 1696], 40.00th=[ 1745], 50.00th=[ 1778], 60.00th=[ 1827],
| 70.00th=[ 1876], 80.00th=[ 1942], 90.00th=[ 2073], 95.00th=[ 2245],
| 99.00th=[ 4359], 99.50th=[ 7242], 99.90th=[ 9241], 99.95th=[10421],
| 99.99th=[15664]
bw ( KiB/s): min=77136, max=151000, per=100.00%, avg=136180.57, stdev=164.80, samples=7616
iops : min=19284, max=37750, avg=34045.14, stdev=41.20, samples=7616
lat (msec) : 2=85.16%, 4=13.65%, 10=1.13%, 20=0.06%, 50=0.01%
lat (msec) : 100=0.01%
cpu : usr=0.28%, sys=0.83%, ctx=2042283, majf=2, minf=649
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued rwts: total=0,2042017,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=1
Run status group 0 (all jobs):
WRITE: bw=133MiB/s (139MB/s), 133MiB/s-133MiB/s (139MB/s-139MB/s), io=7977MiB (8364MB), run=60003-60003msec書き込みスループットは133MiBpsでした。SSD IOPS3,000前後と頭打ちだからかcloud write modeが有効の場合と変わりありません。
4MiBブロックを64多重で書き込みます。
$ sudo fio \
--directory=/mnt/fsxn/vol1/ \
--name fio_rw_4MiB_block_64GiB_64jobs_cloud_write_false \
--ioengine=psync \
--direct=1 \
--rw=randwrite \
--bs=4M \
--size=64G \
--numjobs=64 \
--runtime=60 \
--group_reporting \
--norandommap
fio_rw_4MiB_block_64GiB_64jobs_cloud_write_false: (g=0): rw=randwrite, bs=(R) 4096KiB-4096KiB, (W) 4096KiB-4096KiB, (T) 4096KiB-4096KiB, ioengine=psync, iodepth=1
...
fio-3.32
Starting 64 processes
fio_rw_4MiB_block_64GiB_64jobs_cloud_write_false: Laying out IO file (1 file / 65536MiB)
fio_rw_4MiB_block_64GiB_64jobs_cloud_write_false: Laying out IO file (1 file / 65536MiB)
.
.
(中略)
.
.
fio_rw_4MiB_block_64GiB_64jobs_cloud_write_false: Laying out IO file (1 file / 65536MiB)
fio_rw_4MiB_block_64GiB_64jobs_cloud_write_false: Laying out IO file (1 file / 65536MiB)
Jobs: 64 (f=64): [w(64)][0.6%][w=400MiB/s][w=100 IOPS][eta 02h:54m:19s]
fio_rw_4MiB_block_64GiB_64jobs_cloud_write_false: (groupid=0, jobs=64): err= 0: pid=10046: Sun Feb 11 10:38:09 2024
write: IOPS=101, BW=408MiB/s (427MB/s)(24.0GiB/60303msec); 0 zone resets
clat (msec): min=315, max=1181, avg=627.54, stdev=182.18
lat (msec): min=316, max=1181, avg=627.73, stdev=182.18
clat percentiles (msec):
| 1.00th=[ 439], 5.00th=[ 439], 10.00th=[ 443], 20.00th=[ 443],
| 30.00th=[ 447], 40.00th=[ 485], 50.00th=[ 567], 60.00th=[ 735],
| 70.00th=[ 768], 80.00th=[ 802], 90.00th=[ 844], 95.00th=[ 927],
| 99.00th=[ 1133], 99.50th=[ 1133], 99.90th=[ 1183], 99.95th=[ 1183],
| 99.99th=[ 1183]
bw ( KiB/s): min=524237, max=1048576, per=100.00%, avg=546491.41, stdev=1642.92, samples=5834
iops : min= 125, max= 256, avg=133.39, stdev= 0.40, samples=5834
lat (msec) : 500=41.96%, 750=23.71%, 1000=33.28%, 2000=1.04%
cpu : usr=0.04%, sys=0.06%, ctx=6336, majf=0, minf=560
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued rwts: total=0,6144,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=1
Run status group 0 (all jobs):
WRITE: bw=408MiB/s (427MB/s), 408MiB/s-408MiB/s (427MB/s-427MB/s), io=24.0GiB (25.8GB), run=60303-60303msec書き込みスループットは408MiBpsでした。cloud write modeが有効の場合と変わりありません。
パターン数はかなり少ないですが、検証した限りcloud write modeを有効にしても、無効状態と比べて書き込み速度の大きな差はないように思えます。
大容量のデータ移行の時は有効にしたい
Amazon FSx for NetApp ONTAPでcloud write modeを試してみました。
大容量のデータ移行をする際、転送先のFSxN上で重複排除を追加でかける必要がないのであれば、ぜひ使っていきたいですね。
この記事が誰かの助けになれば幸いです。
以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!
3
