I/OベンチマークとLustre性能
DDN Storage
Shuichi Ihara
2022/12/09

I/O性能とベンチマーク• I/O性能o ストレージシステム選定の１つの要件

o I/O性能といってもその範囲は⾮常に多岐にわたる• I/Oベンチマークは複雑o ストレージだけでなく、ネットワーク、クライアントに関連

o 多くのベンチマークツールが存在し、I/Oワークロードを再現は⼿間• ストレージシステムの性能を正しく理解o どのようにI/Oすればアプリケーションが速くなるか

o 得意、不得意なI/Oは何か。どのように改善できるか© 2022 DDN

IO500• HPCのワークロードを想定したI/Oベンチマークスイート

o 標準化されたベンチマークツールで簡単にベンチマークできることを想定
o テストの種類はI/O帯域、メタデータ操作およびメタデータ検索
o それぞれのテストに“Hero”(Easy)と”Anti-Hero”(Hard)が存在
o 単⼀性能基準に依存しない• 登録されたベンチマーク結果は公開しランキング
o SC17(2017, 11⽉)が最初のリスト

o 他のxxx500同様、リストは年２回更新

o “Full“リストと”10クライアント”のリストが存在

o プロダクション、テストシステム、オンプレ、クラウド等環境は問わない© 2022 DDN

IO500• ベンチマークはIOR, mdtestおよびfindから構成される
oIOR Easy (WriteとRead)• プロセス毎のファイル、IOサイズは⾃由に設定可能

oIOR Hard (WriteとRead)• 全プロセスが共通単⼀ファイルに同時アクセス(Stride IO)• IOサイズはページアラインされていない47,008バイト

o相乗平均
Bandwidth
スコア

MDTEST Easy (Write, Stat, Delete)

相乗平均
合計スコア

• プロセス毎にユニークなディレクトリ、0byteのファイルサイズo

MDTEST Hard (Write, Stat, Read, Delete)• 全プロセスが共通単⼀ディレクトリに同時アクセス• ファイルサイズは3901バイト

oFind• ⽣成された全ファイルから3901 byteだけのファイル数を検索• ⾃由なツール利⽤を許可• その他相乗平均
IOPS(Metadata)
スコア

書き込みはそれぞれ5分以上。作成されたファイルは、永続メディアへの保存必須
o クライアントキャッシュは利⽤できないo© 2022 DDN

IO500トレンドと注意点• IO500のスコアが⾼ければ、すべての性能問題が解決するわけではないo あくまでもHPCにおけるI/Oワークロードのいくつかをピックアップしたもの
o それぞれのテストが同時に⾏われるわけでなく⼀つ⼀つ個別に実⾏• プロダクションでは、不特定多数のユーザが不特定のIOを実施• どのようなファイルシステムでもIO500が正しく実⾏できれば登録申請可能
o ストレージシステムの構成に⼤きく依存• Top100等と⽐較してIO性能実⾏効率(実測値/理論値)が分かりづらい

o 聞きなれないファイルシステムも多く存在• IO500のアイデアを利⽤できるところは多数存在
o ⾃分のワークロードに当てはめてみる例) 単⼀の共有ファイルに対して多くのプロセスから同時書き込み、読み込み
ただしIOサイズは47008バイトではなく1Mバイト© 2022 DDN

IO500をどう活⽤するか︖• ⼀貫性のあるベンチマーク

o 構成を最⼩化し持続的ベンチマーク• 性能のリグレッションテスト
• 性能課題の明確化• 性能改善のデモンストレーション、製品反映

IO500 ベンチマーク基本構成
10 クライアント

1 x Gold 5218(16 CPU)
96GB RAM
1 x HDR100

1 x IB-HDR100• 性能効率の改善

o 少ないハードウェアリソースで⾼いI/O性能
o HPC以外のワークロードにも有⽤• IO500を通じてI/O性能の理解
o ボトルネックの特定o リアルな性能問題への適応
o I/Oトレーサビリティ© 2022 DDN

VM0

VM1

VM2

VM3

1 x ストレージアプライアンス

継続的な性能改善による成果
プラットフォーム

ES400NV

ES400NVX

ES400NVX2

8 x CPU, 150GB RAM
PCI Gen3, 20 x NVMe

10 x CPU

12 x CPUPCI Gen4, 200Gbps

4 x Lustre Server(VM)••

PreSC19IOR Easy Write
IOR Easy Read
IOR Hard Write
IOR Hard Read
Find
Mdtest Easy Write
Mdtest Easy Stat
Mdtest Easy Delete
Mdtest Hard Write
Mdtest hard Read
Mdtest Hard Stat
Mdtest Hard Delete
Bandwdith© 2022 DDNIOPS
Score

25.88
39.94
2.78
8.99
1,735.41
143.88455.03
88.52
32.33
44.92
20.41
16.35
12.68
91.41
34.05

SC19

ISC20
28.62
41.72
2.96
42.19
810
152.84451.97132.7679.65
172.59449.9375.15
19.65
207.62
63.87

37.56
45.95
2.77
40.81
1,698.00
157.22453.51135.0990.47
169446.7576.94
21.02
232.6969.93

ISC2255.95
83.86
5.02
39.73
6,248.55
270.04740.01223.61
119.41
194.33514.36101.9831.10
368.48107.05

SC22
58.07
77.56
5.27
49.36
12628.78
312.9
1,278.50
272.64157.4
238.82
1,214.03
122.4432.90
544.23133.81

性能改善およびチューニング(1)• Lustreの機能強化によるもの

o ReadAhead for StrideRead (Lustre-2.14/EXA5.1)• Single shared fileおよびStrideReadの性能改善• ior-hard-reado Lustre OverStripe (Lustre-2.13/EXA5.1)• Single shared fileの⼤幅な性能改善• ior-hard-writeo Batched RPCs for Statahead(Lustre-2.16)• 連続したstat()ワークロード性能改善• 全体的なnetworkレイテンシーの⼤幅な削減• mdtest-{easy,hard}-stat© 2022 DDN

性能改善およびチューニング(2)• その他

o Linux Kernel• VFS Parallel Lookup (kenrel-4.7以降でサポート)
omdtest-hard-statの性能改善• VFS Parallel Updatesの制限

クライアント側に１つのファイルシステムに対して複数のマウントポイントを設定
o Singularityを利⽤してMPIのランク毎にマウントポイントをラウンドロビン
o mdtest-hard-{write,delete}の改善
oo メタデータスキャン• findコマンドの代替として利⽤• メタデータデバイスを直接スキャン• findの性能を20倍向上© 2022 DDN

Lustre Striping
root@ubuntu1804-1:~# lfs setstripe -c -1 /ai200x1/shared-file(”-c -1”は全てのOST)

root@ubuntu1804-1:~# lfs getstripe /ai200x1/shared-file/ai200x1/sharedfile
lmm_stripe_count:4

lmm_stripe_size:

1048576

lmm_pattern:

raid0

lmm_layout_gen:0shared-filelmm_stripe_offset: 1
obdidx objid objid group
1

20x2

0

3

20x2

00

20x2

0

2

20x20© 2022 DDN

プロセス数 > ストライプ数の場合
OSTオブジェクトに対する競合が発⽣

P0

P1

P2

P3

P4

1M

1M

1M

1M

1M

P5

1M

P6

1M

P7

1M

S1

S2

S3

S4

obj1

obj2

obj3

obj4

OST0

OST1

OST2

OST3

Lustre OverStriping (Lustre-2.13/EXA-5.1)
root@ubuntu1804-1:~# lfs setstripe -C 8 /ai200x1/shared-file-OSroot@ubuntu1804-1:~# lfs getstripe /ai200x1/shared-file-OS/ai200x1/shared-file-OS
lmm_stripe_count:8

lmm_stripe_size:

1048576

lmm_pattern:

raid0,overstriped

lmm_layout_gen:0shared-file-OS

lmm_stripe_offset: 0
obdidx objid objid group
0

40x4

0

2

40x40

1

40x40

3

40x4

00

50x50250x50

150x50350x50© 2022 DDN

P0P1

P2P3P41M

1M

1M

1M

1M

1M

1M

1M

S1

S2

S3

S4

S5

S6

S7

S8

obj1

obj2

obj3

obj4

obj5

obj6

obj7

obj8

OST0

OST1

OverStriping機能によってOST数以上のストライプ数が作成可能になりオブジェクト内における競合を排除

P5

OST2

P6

P7

OST3

Striping vs OverStriping 性能⽐較
Striping vs OverStriping (8 x OST)
18000

THroughput (MB/sec)

16000
14000
12000
10000

• ES7990(160 x HDD, 2 x OSS, 8 x OST)

Write

• 32クライアント, 512プロセス

Read• 1MB, SingleShared File

複数プロセスからのSingle
Shared Fileの⼤幅な性能向上# ior/src/ior -w -r -C -g -i 3 -vv -s 13000 -b
1m -t 1m -a POSIX -e• ストライプカウント8と512で⽐較

8000
6000

OverStripeではOST数以上にストライプ数を設定可能

4000
2000
08

以前は最⼤ストライプ数=OST数© 2022 DDN

512

StripeCountLustre ReadAheadの改善(Lustre-2.14/EXA5.1)• Lustre ReadAheadの効率向上
o IOパターンを正しく検知

P0

o Readahead Windowのリセットの回避• Cache Missを減らす• ReadするまえのCacheの破棄を減らす

P1

Sequential Reado これまでSequential Readをサポート• Unaligned ReadAahedサポート

P0

o ReadAheadをページ単位からByte単位へ変更(例47008byte)でもCacheMissしない© 2022 DDN

P3File• Stride Readパターンをサポート

o ページサイズにアラインしていないIOサイズ

P2P1P2File

Stride Read

P3

Lustre ReadAheadの改善(Lustre-2.14/EXA5.2.3)
IO500 IOR Easy/Hard Workloads(32 client, 512 Process)90

lustre-2.13.0

80

lustre-2.14.0

Bandwidth (GB/sec)

70

Lustre-2.13# lctl get_param llite.*.read_ahead_stats
llite.exafs-ffff9b96c1349800.read_ahead_stats=hits
3340631 samples [pages]
misses32901120 samples [pages]

Readahedキャッシュヒット率: 9%60
50

Lustre-2.1440

12倍⾼速化

3020

llite.exafs-ffff9b96b8117000.read_ahead_stats=hits
33616605 samples [pages]
misses4444696 samples [pages]

Readahedキャッシュヒット率: 88%

100

IOR Easy Read

IOR Hard Read

IOR Easy Read: プロセス毎のファイル、16MB IOサイズ、Sequential Read
IOR Hard Read: 全プロセスから単⼀のファイル、47008 Byte IOサイズ、Stride Read
© 2022 DDN

Lustre Batched Stataheadのサポート(Lustre-2.16)
従来の Statahead
MDT# lctl get_param llite.*.stats
readdir
1223 samples [usecs] 0 22518 562923 3229697067
getattr1000002 samples [usecs] 2 12215 10099392 1764429274
getxattr
1 samples [usecs] 95 95 95 9025
inode_permission 10000021 samples [usecs] 0 197 2527584 3966880

Batched Statahead
MDS

100万ファイルあるDIRに対して”ls –l”を実⾏した場合

Client

MDS

ファイル数に応じてnetworkのlatencyが⼤きく影響

MDT

ls –l /mnt/lustre/dir

readdir()stat()
getxattr()
stat()
getxattr()... ファイルの数繰り返す

Client# lctl get_param llite.*.stats
readdir
1223 samples [usecs] 0 20710 196717 454495281
getattr1000002 samples [usecs] 2 13734 5410470 2600319924
readdir()
getxattr
1 samples [usecs] 96 96 96 9216
inode_permission
10000021 samples [usecs] 0 8814 2289195 80999859“stat()-stat()-stat()...”

getxattr()“stat()-stat()-stat()...”
getxattr()© 2022 DDN

100万回のgetattr()に費やした時間10秒

複数のファイルへのstat()リ
クエストを束ねて⼤きなRPCとしてバッチで送受信100万回のgetattr()に費やした時間5.4秒に短縮

まとめと今後• IO500が１つのきっかけで、多くのLustre性能が改善

o IO500のスコアだけではなく、実アプリケーションのI/O性能向上にも貢献
o 良いLustreのプロダクトサイクル••••

パフォーマンス制限または性能ボトルネックの特定
アセスメント(原因の特定、現在の実装、実アプリケーションの影響等)
プロトタイプの実装、性能のデモ(IO500、実アプリケーション)、フルパッチの実装
EXAScaler/Upstream Lustreへの反映• 更なるメタデータ性能の改善

o Batch statahead後のstatオペレーションはCPUの利⽤率はほぼ100%o Batchフレームワークに適応させることで他のメタデータオペレーションも⾼速化可能• ⼤量の⼩さなファイルの読み込みおよび作成• 将来的には全てのメタデータオペレーション

ご期待下さい︕© 2022 DDN