Rook/Ceph クラスタの導入検討に際し、ベンチマークは必ず求められるものと思います。
ストレージやファイルシステムのベンチマーク用ツールとして、 fio や bonnie++ など有名なオープンソースソフトウェアが存在します。Rook/Ceph でも、これらの使用を検討される方が多いのではないでしょうか。
それらのソフトウェアでの計測も無駄ではありません。しかし Rook/Ceph の場合は、それらのツールを用いる前に rados bench での計測をお勧めします。
Ceph は RADOS という KVS を基盤とし、RBD、CephFS、NFS 等々のストレージインタフェースを提供しています。
つまり、基盤である RADOS 層での性能が出せていないと、上層の性能も出ません。
Ceph には RADOS を直接操作する rados という CLI が用意されています。そのサブコマンド bench は、読み書きのベンチマークを取得し、判りやすい形式で指標を出力します。
本稿では、実況チュートリアル形式で、使い方を概説します。
前提
Rook/Ceph では、CLI 操作のための rook-ceph-tools という deployment が提供されています。
本稿では既に rook-ceph-tools が、名前空間 rook-ceph にデプロイされているものとして話を進めます。
初めての rados bench
まずは深く考えず、実行してみましょう。
はじめに、ベンチマーク対象となる pool を探します。
kubectl exec -it -n rook-ceph deploy/rook-ceph-tools -- ceph osd pool ls
下記のような一覧が得られます。内容は、お使いの環境により異なるはずです。
.mgr
replicapool
testfs-metadata
testfs-data0
本稿では testfs-data0 を、ベンチマーク対象とします。
書き込みベンチマーク
kubectl exec -it -n rook-ceph deploy/rook-ceph-tools -- rados bench -p testfs-data0 10 write
10 は、計測を行う秒数です。write は、書き込み性能の計測を指示しています。
10 秒間、途中経過が表示されたあと…
hints = 1
Maintaining 16 concurrent writes of 4194304 bytes to objects of size 4194304 for up to 10 seconds or 0 objects
Object prefix: benchmark_data_rook-ceph-tools-555c879675-qv_257860
sec Cur ops started finished avg MB/s cur MB/s last lat(s) avg lat(s)
0 0 0 0 0 0 - 0
1 16 48 32 127.994 128 0.165356 0.349761
2 16 88 72 143.987 160 0.530343 0.407533
3 16 127 111 147.985 156 0.175736 0.395974
4 16 164 148 147.928 148 0.218061 0.391926
5 16 198 182 145.537 136 0.413798 0.418438
6 16 238 222 147.814 160 0.445741 0.412941
7 16 270 254 144.983 128 0.6776 0.415378
8 16 311 295 147.355 164 0.142006 0.422009
9 16 350 334 148.313 156 0.619627 0.420417
10 16 383 367 146.681 132 0.286598 0.421052
…結果が表示されます。
Total time run: 10.4443
Total writes made: 383
Write size: 4194304
Object size: 4194304
Bandwidth (MB/sec): 146.682
Stddev Bandwidth: 14.3666
Max bandwidth (MB/sec): 164
Min bandwidth (MB/sec): 128
Average IOPS: 36
Stddev IOPS: 3.59166
Max IOPS: 41
Min IOPS: 32
Average Latency(s): 0.428837
Stddev Latency(s): 0.274607
Max latency(s): 1.79436
Min latency(s): 0.0270248
Cleaning up (deleting benchmark objects)
Removed 383 objects
Clean up completed and total clean up time :0.178074
ちょっと待って! 私の IOPS…遅すぎ? (Average IOPS: 36)
と思われるかもしれません。これには理由があります。
多くのストレージソリューションで、公表最大性能は、小さなサイズで達成されます。典型的には 4KB や 16KB です。
一方、rados bench のデフォルトの書き込みサイズは 4MB です。
一般に、書き込みサイズが大きくなると IOPS は低下します。
名誉回復のため、書き込みサイズを指定して再計測してみます。
kubectl exec -it -n rook-ceph deploy/rook-ceph-tools -- rados bench -p testfs-data0 10 write -b 4096 --no-cleanup
-b 4096 によって、書き込みサイズを 4096 バイト(4KiB) と指定しています。
再計測とは直接関係ないのですが、--no-cleanup を追加しています。これにより、ベンチマークの後片付けが行われなくなります。次に行う読み込みベンチマークのために必要です。
下記、実行結果です。
Total time run: 10.02
Total writes made: 9172
Write size: 4096
Object size: 4096
Bandwidth (MB/sec): 3.57567
Stddev Bandwidth: 0.446151
Max bandwidth (MB/sec): 4.13672
Min bandwidth (MB/sec): 2.95703
Average IOPS: 915
Stddev IOPS: 114.215
Max IOPS: 1059
Min IOPS: 757
Average Latency(s): 0.0174597
Stddev Latency(s): 0.0431238
Max latency(s): 0.582154
Min latency(s): 0.00281438
4MB 時と比較すると、bandwidth は下がります。IOPS とトレードオフの関係なので、やむを得ません。
IOPS は平均で 915 と出ました。この環境では、下記理由により、この程度の IOPS に留まるのは想定の範囲です。
- この環境での OSD では、比較的低速 (500 IOPS) なストレージを使っています。
- Ceph は書き込み時に、 3 つの OSD へ順に書き込みます。
読み込みベンチマーク
つづいて読み込み性能を測ります。読み込み方法はシーケンシャルとランダムを選べます。
シーケンシャル読み込み
測ってみましょう。
kubectl exec -it -n rook-ceph deploy/rook-ceph-tools -- rados bench -p testfs-data0 10 seq --no-cleanup
Total time run: 0.798155
Total reads made: 9172
Read size: 4096
Object size: 4096
Bandwidth (MB/sec): 44.8887
Average IOPS: 11491
Stddev IOPS: 0
Max IOPS: 9169
Min IOPS: 9169
Average Latency(s): 0.00138091
Max latency(s): 0.188503
Min latency(s): 0.000181109
シーケンシャル読み込みの IOPS は、書き込み比 10 倍以上の値となりました。bandwidth も書き込みよりよい数値となっています。
latency も書き込みよりよい値なのですが、読み書きいずれも最大最小の差が大きいのが気になるところです。
ランダム読み込み
seq を rand に変更する他は、シーケンシャル読み込みと同じです。
kubectl exec -it -n rook-ceph deploy/rook-ceph-tools -- rados bench -p testfs-data0 10 rand --no-cleanup
Total time run: 10.0007
Total reads made: 144762
Read size: 4096
Object size: 4096
Bandwidth (MB/sec): 56.544
Average IOPS: 14475
Stddev IOPS: 3794
Max IOPS: 17507
Min IOPS: 5522
Average Latency(s): 0.00109415
Max latency(s): 0.555312
Min latency(s): 0.000152902
Ceph はシーケンシャルよりもランダムのほうが性能が出る傾向があり、それを裏付ける結果が出ました。
cleanup
上記のようなベンチマークは、計測ごとに値が変動します。継続時間を長く取るか、何回か計測してメタ解析を行うと、より信頼性のある値が得られます。
十分に計測が行えたら、計測で使ったオブジェクトを削除します。
kubectl exec -it -n rook-ceph deploy/rook-ceph-tools -- rados cleanup -p testfs-data0
クリーンアップには時間がかかる場合があります。しばらく待つと、下記のように削除されたオブジェクトの数が表示され終了します。
Removed 9172 objects
どう改善に結びつける?
数値は採れました。次はどうしましょう?
いくつか案はあります。
- ストレージの種類を変えて比べてみる。
- ノードの種類やサイズを変えてみる。
- ネットワーク構成を変えてみる。
- Linux のカーネルパラメータについて検討する。
お手元の環境がオンプレかクラウドか、クラウドにしても K8s がマネージドかセルフホストかで、変更の容易性は変わると思いますが、何らか改善の方法はあるかと思います。
一方、お勧めしないのは「rados や ceph の CLI でチューニングを試みる」です。
最近のバージョンの ceph では、自己最適化能力が備わっています。
また、Rook は、得られた custom resource の値をもとにして、(主にメモリ関連の)パラメータを最適化します。
人手を入れてしまうと、却って調子を崩しがちです。
サポート承ります
合同会社もなみ屋では、FLOSS プロフェッショナルサポートの一環で Rook に関する技術支援を行っています。またオプションで Ceph に関する技術支援も承ります。ご興味のある方は是非お問い合わせください。
(当記事は合同会社もなみ屋の技術ブログからの転載です。)