高性能マウント・ターゲットでファイル・システムの性能を見てみる。

OCIのファイル・ストレージ・サービス（FSS）は、ManagedなNFSのサービスです。
自分でNFSサーバーを構築する必要がなく、簡単にNFSで共有可能なストレージ領域を利用することができます。

昨年8月に、このファイル・ストレージ・サービスに、高性能マウント・ターゲット（High Performance Mount Target、略してHPMT）が新しく追加されました。
高性能マウント・ターゲット（HPMT）は、その名の通り高性能が出せるマウント・ターゲットです。
従来の通常のマウント・ターゲットは、マウント・ターゲットごとに最大性能があり、それを超える性能が必要な場合は複数のマウント・ターゲットを利用する必要がありました。HPMTでは、一つのマウント・ターゲットあたりの最大帯域が大幅に拡張されています。

ファイル・ストレージ・サービスの性能に関しては以下のホワイトペーパーにまとまっているので読んでおくとよいです。

[OCI File Storage Performance Characteristics](https://docs.oracle.com/en-us/iaas/Content/Resources/Assets/whitepapers/file-storage-performance-guide.pdf)


上記ホワイトペーパーから抜粋した、各マウント・ターゲットごとの性能指標です。

![image-20250423091438955.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2524827/69360457-021c-4306-b167-f9c6cb3be39f.png)


Standardに比べて、HPMTでは帯域幅やIOPSが大幅に改善されていることが分かります。

- 上記ホワイトペーパーにも記載されていますが、表を理解するうえでの注意点を抜粋しておきます
  - マウントターゲットの性能はIOサイズ1Mの場合のReadスループット値を元にしている。
      - IOサイズが1Mよりも小さければ最大スループットは出ない可能性が高いことが想定される。
  - IOPSに関してはIOサイズによって変わるが、NFSのクライアント側からのreadやwriteのリクエストだけではなく、FSSのバックエンド側でNFSのメタデータ処理も必要となるため、一つのリクエストで複数のIO処理が発生する。つまりクライアント側から見えるIOPSとFSS上でのIOPSは異なる。
      - ここに書かれているのはFSSとしてのIOPSの目安なので、クライアント側のIOPSはもっと少なくなることが想定される。
  - 上記の数値はホワイトペーパー発行時点での想定される性能数値であり、実際に使用するリージョンや環境によっても変わってくる。より高性能が出ることもある。



また、高性能マウントターゲットの費用は、単価自体は通常のStandardのタイプと変わりませんが、タイプごとに「容量資格」（= Capacity Entitlement。マウント・ターゲットごとに最低限課金される容量）が設定されており、また、 30日間の請求コミットメント（30日サイクルでの課金）があります。

詳細は[価格表](https://www.oracle.com/jp/cloud/price-list/#pricing-storage)を参照してください。

- 単価：Oracle Cloud Infrastructure File Storage Service - High Performance Mount Target ￥46.50 / Performance Units Per Gigabyte Per Month

- 日本円の定価の場合、各マウント・ターゲットごとの最低金額は以下の通りとなります。

  | マウント・ターゲットのタイプ        | Readスループット | 容量資格 (Capacity Entitlement) | 最低課金月額 | 請求コミットメント |
  | ----------------------------------- | :--------------- | ------------------------------- | ------------ | ------------ |
  | 標準(Standard)                      | 1 Gbps          | 0 GB                            | ¥0           | なし         |
  | 高性能(High  Performance) : HPMT-20 | 20 Gbps          | 20,000 GB                       | ¥930,000     | 30日         |
  | 高性能(High  Performance) : HPMT-40 | 40 Gbps          | 40,000 GB                       | ¥1,860,000   | 30日         |
  | 高性能(High  Performance) : HPMT-80 | 80 Gbps          | 80,000 GB                       | ¥3,720,000   | 30日         |



お試しするために気軽に手が出せる金額ではないかもしれませんが、今回は、このHPMTの環境を触れる機会があったためFIOで性能測定を行ってみました！



注）あくまで今回の計測での結果であって、なんらかの性能を保証するような情報ではありません。


## 検証環境と測定パターン

#### 環境

- リージョン：US West (San Jose)
- マウント・ターゲット：HPMT-20
- マウント・ターゲットと同一VCN内のNFSクライアント用インスタンス
  - VM.Standard.E4.flex、32 OCPU、256 GB Memory、32 Gbps　x 1インスタンス
  - Oracle Linux 8



#### 使用したNFSマウントオプション

- ホワイトペーパーにもある通り nconnect = 16 のオプションのみ使用しました。

```
sudo mount -o nconnect=16 <マウント・ターゲットのIPアドレス>:/<ファイルシステム名> /mnt/<マウント用ディレクトリ名>
```



#### 使用したFIOコマンドと計測パターン

- 以下のパラメーターで1MBの計測を行ったところ、特に問題がなさそうだったのでパラメーターの調整はせずに同じ条件で全ケースを実施しました。

```
sudo fio --name=<ケースごとの名前> --directory=/mnt/<マウント用ディレクトリ名> --numjobs=32 -size=1G --time_based --runtime=600 --ioengine=libaio --direct=1 --verify=0 --bs=<IOサイズ。ケースによって変更。> --iodepth=64 --rw=<Read/Write。ケースによって変更。> --group_reporting=1
```

- bs：1M / 32K / 4K の3パターンで計測
- rw：read / randread / write / randwrite の4パターンで計測



参考までに以下のような実行結果となります。（1M readの場合の実行例）

```
[opc@tk-test-inst01 ~]$ 
[opc@tk-test-inst01 ~]$ sudo fio --name=fss-perf-1M-read --directory=/mnt/tkfilesystem01 --numjobs=32 -size=1G --time_based --runtime=600 --ioengine=libaio --direct=1 --verify=0 --bs=1m --iodepth=64 --rw=read --group_reporting=1

fss-perf-1M-read: (g=0): rw=read, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=libaio, iodepth=64
...
fio-3.19
Starting 32 processes
fss-perf-1M-read: Laying out IO file (1 file / 1024MiB)
fss-perf-1M-read: Laying out IO file (1 file / 1024MiB)
fss-perf-1M-read: Laying out IO file (1 file / 1024MiB)
fss-perf-1M-read: Laying out IO file (1 file / 1024MiB)
fss-perf-1M-read: Laying out IO file (1 file / 1024MiB)
fss-perf-1M-read: Laying out IO file (1 file / 1024MiB)
fss-perf-1M-read: Laying out IO file (1 file / 1024MiB)

<<中略>>

Jobs: 32 (f=32): [R(32)][100.0%][r=2059MiB/s][r=2058 IOPS][eta 00m:00s]
fss-perf-1M-read: (groupid=0, jobs=32): err= 0: pid=48388: Tue Apr 22 04:24:58 2025
  read: IOPS=2462, BW=2462MiB/s (2582MB/s)(1444GiB/600675msec)
    slat (usec): min=70, max=15518, avg=108.53, stdev=32.73
    clat (msec): min=28, max=4094, avg=831.34, stdev=251.65
     lat (msec): min=28, max=4094, avg=831.44, stdev=251.65
    clat percentiles (msec):
     |  1.00th=[  414],  5.00th=[  498], 10.00th=[  558], 20.00th=[  625],
     | 30.00th=[  676], 40.00th=[  735], 50.00th=[  793], 60.00th=[  860],
     | 70.00th=[  927], 80.00th=[ 1011], 90.00th=[ 1150], 95.00th=[ 1301],
     | 99.00th=[ 1653], 99.50th=[ 1770], 99.90th=[ 1938], 99.95th=[ 2005],
     | 99.99th=[ 2123]
   bw (  MiB/s): min=  200, max= 3850, per=100.00%, avg=2464.67, stdev=12.05, samples=38354
   iops        : min=  182, max= 3850, avg=2464.60, stdev=12.06, samples=38354
  lat (msec)   : 50=0.01%, 100=0.01%, 250=0.07%, 500=5.14%, 750=38.34%
  lat (msec)   : 1000=34.96%, 2000=21.42%, >=2000=0.05%
  cpu          : usr=0.03%, sys=0.90%, ctx=1457647, majf=2, minf=1529
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=99.9%
     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.1%, >=64=0.0%
     issued rwts: total=1479054,0,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):
   READ: bw=2462MiB/s (2582MB/s), 2462MiB/s-2462MiB/s (2582MB/s-2582MB/s), io=1444GiB (1551GB), run=600675-600675msec
[opc@tk-test-inst01 ~]$
```



## 測定結果
#### 結果一覧

| IOサイズ | R/W          | IOPS  | スループット |
| ------- | ------------ | ----- | ---------- |
| 1M      | Read         | 2462  | 2462MiB/s  |
|         | Random Read  | 2406  | 2407MiB/s  |
|         | Write        | 1516  | 1517MiB/s  |
|         | Random Write | 1501  | 1502MiB/s  |
| 32K     | Read         | 50.1k | 1565MiB/s  |
|         | Random Read  | 50.1k | 1565MiB/s  |
|         | Write        | 17.2k | 538MiB/s   |
|         | Random Write | 16.8k | 525MiB/s   |
| 4K      | Read         | 47.6k | 186MiB/s   |
|         | Random Read  | 50.1k | 196MiB/s   |
|         | Write        | 15.0k | 58.6MiB/s  |
|         | Random Write | 15.3k | 59.7MiB/s  |

- スループットはIOサイズ1MのSequential Readが最も高く、2462MiB/s = 約20Gbps 程度出ているので、スペック通りの帯域性能が実現できている。
- IOPSは Read 約50k, Write 約15k ～ 17k 程度。（IOサイズ 32K, 4Kの場合）
- FSS側のメトリックを確認すると、32K, 4Kのread時にはIOPSは約100Kで張り付いているように見える。FSS側のメタデータ処理等含めたIOPSは期待通りの値が出ていると考えられる。（下記IOPSメトリック参照）


計測中は、マウント・ターゲットのメトリックも確認しながら実施しました。

#### MountTargetReadThroughput メトリック

もっともスループット性能が出ているケース（IOサイズ 1M、前半の山がRandom Read、後半の山がSequential Read）でのメトリックを確認すると、2.5G Byte程度出ていることがわかりました。スループットはクライアント側から計測できる値と大きくは変わらないことがわかります。
![image-20250422141143736.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2524827/4a226d89-4d7d-4b3a-a3b9-3242c151988f.png)



#### MountTargetIOPS メトリック

計測期間を通じてのIOPSメトリックを表示すると、最大約100KのIOPSで頭打ちになっている様子が見られました。（途中で間が空いているところはありますが、テストケース12個を1M→32K→4Kの順で実行している状態です。）

クライアント側から見ると最大50K程度のIOPS（IOサイズ 4k、32kの場合）ですが、FSS側のNFSメタデータ処理を含めるとスペック通り約100Kが最大IOPSとなっていることが分かります。

![image-20250423090251764.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2524827/b455c055-b0fd-429a-94dc-a2c3537ff5f2.png)



## まとめ

- ファイル・ストレージの高性能マウント・ターゲットでは、特別なチューニングなど不要で期待通りの性能が出せることが確認できた。
  - マウントオプションやfioのパラメーター調整など行えばさらに最適化することはできたかもしれないが、今回は未実施。
- HPMT-20での最大スループットは20Gbps。IOサイズ 1MのReadの場合に2400MiB/s 以上のスループットを確認できた。
- HPMT-20のマウントターゲット側の期待されるIOPSは最大100K。マウントターゲット側では最大100KでIOPSが頭打ちになっている様子が確認できた。
  - クライアント側のIOPS値はIOサイズやRead/Writeによって異なるが、IOサイズ 4K, 32Kの場合はReadで50K程度のIOPSが確認できた。