サマリー

Proxmox VE cluster再構築と移行の雑記 で構築したProxmox VEクラスタのCephベンチマークを取ったので、結果を整理しておきたいと思います。

ベンチマーク構成

• 旧クラスタの場合、Ceph NetworkはVMと共用の1G SW(2port bond)に収容されているMTU=9000です
• 新クラスタの場合、Ceph Networkは専用の10G SW(1port)に収容されておりMTU=9000です
• fioを実行するのは同クラスタ内のホストからになります
  • 負荷印加システムと負荷対象システムが同一システム上にあるため、純粋なCephの測定結果ではありません
  • Hyper-Converged構成なので同一システム上からのfioはqemuからのRBDアクセスと読み替えれば参考にはなるはず
  • 10GbEの負荷印加用ノードまでは準備できませんでした

Diskカタログスペック比較

耐久性はDWPDからおおよその数値に変換したもの。大して意味はない。

ベンチマーク項目

1. Write Cache性能影響
   • 今回導入したSATA SSDは https://yourcmc.ru/wiki/Ceph_performance に書かれているWrite Cacheを無効化した方が良いデバイスに相当する可能性があるので、Write Cacheの有無での性能差を見ておきたい
2. RBD並列数による性能(n=1)
3. RBD並列数による性能(n=2,4,8)
4. MX500とS4500の性能差

ベンチマークでは、仮想マシンを必要数分作成し、電源OFFの状態のままにしておきます。
準備が出来たらfioのiniファイルを指定してベンチマークを開始します。

1. Write Cache性能影響

SSD Cacheの有効無効はhdparmコマンドで指定します。

無効にするとき

1
2
3
4
5

root@pve-a01:~# hdparm -W 0 /dev/sda

/dev/sda:
 setting drive write-caching to 0 (off)
 write-caching =  0 (off)

有効にするときは hdparm -W 1 /dev/sda です。

使用したfioファイルは以下のものです。
fio ceph_bench.ini で実行します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

[global]
ioengine=rbd
pool=datastore
direct=1
numjobs=1
runtime=60
clientname=admin
rbdname=vm-101-disk-0
stonewall
norandommap

[4M_iodepth16_write]
bs=4M
iodepth=16
rw=write

[4K_iodepth1_randwrite]
bs=4K
iodepth=1
rw=randwrite

[4K_iodepth128_randwrite]
bs=4K
iodepth=128
rw=randwrite

結果

Sequential Write 4MB iodepth=16

若干WriteCache無効の方が良いかなという程度。

性能公称値であるSequential Write 480 MB/sには若干届いていませんでした。ちょっとiodepth浅かったかな？

Random Write 4KB iodepth=1

若干WriteCache無効の方が良いかなという程度。Latencyの最大値は無効の場合に少し大きいものの、平均で見ると無効の方が良い。

iodepth=1なので、IOPSがこの程度なのは概ね予想通り。
SSDのWrite latency (random) の公称値が59 µsでも、それ以外の処理時間が上乗せされるのは仕方ありません。

これを劇的に改善するのはCephの仕組み的に難しく、エンタープライズ製品を頑張ってチューニングして3000 IOPSに到達するかどうかだと思います。
参考: Ceph performance: benchmark and optimization | croit

Cephは並列数を上げると性能がスケールするけれども、1jobに対してはかなり低いIOPSになります。
この1job性能をどの程度維持して並列数を上げられるかが気になるところです。

Random Write 4KB iodepth=128

若干WriteCache無効の方が良いかなという程度。
Latencyの最大値は無効の場合に倍に跳ねているものの、平均で見ると無効の方が良い。
負荷印加と測定対象が同じシステム上にあるので、多少外れ値が生まれるのは諦めてください。

結論

ひとまずWriteCache無効の方が若干良さそう。
S4500はあまりWriteCacheの影響を強く意識しなくても、それなりに使えてしまうSSDなのかもしれない。
まぁ8年も前のSATA SSDなので、僕が今さら何か言うのもおこがましいよね。

起動時にWriteCacheを無効にする設定

なお再起動すると hdparm -W 0 /dev/sda の設定は消えてしまうので、起動時に設定されるようにudev ruleを書いておきます。
このやり方はCeph公式というよりはArchの方をベースにしています。

1
2
3
4
5

~# cat <<__EOL__ > /etc/udev/rules.d/69-hdparm.rules
ACTION=="add|change", KERNEL=="sd[a-z]", ENV{ID_SERIAL_SHORT}=="$(udevadm info --query=property --property=ID_SERIAL_SHORT --value /dev/sda)", RUN+="/usr/sbin/hdparm -W 0 /dev/%k"
__EOL__
~# cat /etc/udev/rules.d/69-hdparm.rules 
ACTION=="add|change", KERNEL=="sd[a-z]", ENV{ID_SERIAL_SHORT}=="BTYS915103Q83P8EGN", RUN+="/usr/sbin/hdparm -W 0 /dev/%k"

udevadm test /dev/sda コマンドを叩いて run: '/usr/sbin/hdparm -W 0 /dev/sda' が見つかればOKのはず。以下参考。

• Hardware Recommendations — Ceph Documentation - Write Caches
• https://wiki.archlinux.org/title/Hdparm
• https://wiki.archlinux.org/title/Udev#Identifying_a_disk_by_its_serial

以降はWriteCache無効の設定で測定を続けます。

2. RBD並列数による性能(n=1)

ここからは実際のユースケースに合わせて仮想マシンの数を増やしてRBDの並列アクセス性能を見ていきます。
まずはn=1のケースだけを測定します。項目は以下の通り。

• Sequential Write bs=4M iodepth=16
• Random Write bs=4K iodepth=1
• Random Write bs=4K iodepth=128
• Sequential Read bs=4M iodepth=16
• Random Read bs=4K iodepth=1
• Random Read bs=4K iodepth=128

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

[global]
ioengine=rbd
pool=datastore
direct=1
numjobs=1
runtime=60
clientname=admin
rbdname=vm-101-disk-0
stonewall
norandommap

[4M_iodepth16_write]
bs=4M
iodepth=16
rw=write

[4K_iodepth1_randwrite]
bs=4K
iodepth=1
rw=randwrite

[4K_iodepth128_randwrite]
bs=4K
iodepth=128
rw=randwrite

[4M_iodepth16_read]
bs=4M
iodepth=16
rw=read

[4K_iodepth1_randread]
bs=4K
iodepth=1
rw=randread

[4K_iodepth128_randread]
bs=4K
iodepth=128
rw=randread

結果

• Write
  • WriteCacheの影響を確認した時と概ね同等の傾向
• Read
  • Cephの利点である並列読み込みが機能して、SSD公称値よりも高いBW (MB/s)とIOPSが見られました
  • Sequential ReadのBW (MB/s)は939 MB/sに到達しており、10GbE 1portの環境としては十分な性能と言えそうです

n=1のケースの結果を元に、n=2,4,8で主にWriteの性能を見ていきます。
Readはこれ以上調べてもな…と興味を失っているので測定範囲外です。

3. RBD並列数による性能(n=2,3,4)

並列数の違いでRandom Writeにどれくらい影響するかを測定していきます。
VMを必要数分作って、iniファイルは必要数分コメントアウトします。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

[global]
ioengine=rbd
pool=datastore
direct=1
numjobs=1
runtime=60
clientname=admin
norandommap
bs=4K
iodepth=1
rw=randwrite

[VM1]
rbdname=vm-101-disk-0
[VM2]
rbdname=vm-102-disk-0
; [VM3]
; rbdname=vm-103-disk-0
; [VM4]
; rbdname=vm-104-disk-0
; [VM5]
; rbdname=vm-105-disk-0
; [VM6]
; rbdname=vm-106-disk-0
; [VM7]
; rbdname=vm-107-disk-0
; [VM8]
; rbdname=vm-108-disk-0

結果

あまり冗長でも見にくいのでさっくり平均を取った結果が以下の表です。

並列数を増やすとIOPS、Latencyが悪化していることが分かります。
測定中はceph-osdのCPU使用率が高く測定器にも影響を与えていそうだったので、8台のケースではfioの測定ノードを2つに分散させたデータも追加しています。
Latencyは露骨に影響を受けているように見えるので、実際の利用シーンではもう少し負荷は分散されてくれるだろうと思います。
ピーク性能を計画する場合は Hardware Recommendations — Ceph Documentation でも触れられているように、Cephの処理負荷に対してCPUコア当たりのIOPSを測定値と照らし合わせて判断するのが良さそうです。

Latencyのパーセンタイルで比較すると、やはり負荷ノード1台では十分な測定余裕が無いことが分かります。

測定の方向性に問題が無いか SuperMicroのベンチマーク - Ceph on Supermicro BigTwin から Table 5 – 4K Random Writes の結果を拝借して見比べてみます。

1行目の結果から、iodepth=1のクライアントが200台で176.39 KIOPSということは、200並列の場合は1クライアント当たり 881.95 IOPS。
avgLat(ms)も1.13msですから、測定結果とかなり近しい値です。
手元の環境での測定結果は8台までですが、概ね狙い通りの結果が得られたと言えそうです。

逆に、100G NICとNVMe SSD x12を揃えても、1クライアント当たりの性能傾向は手元の環境とそう大きく変わらないと思われます。
前提とするI/OワークロードによってはCeph採用に難色を示すユーザーがいる可能性はありそうですね。

4. MX500とS4500の性能差

最後に、既に利用を終了している旧クラスタ（TX1320 M2 + MX500）のCeph性能は一体どんなものだったのかを比較します。

Seqeuential Read/Write bs=4M iodepth=16

Writeは1GbEの頭打ち感がありますが、Readはローカル読み出し出来るので比較的頑張っていたみたいですね。

Random Read bs=4K iodepth=128

これまたReadはローカル読み出し出来るので比較的頑張っていたみたいですね。

Random Read bs=4K iodepth=1

これまたReadはローカル読み出し出来るので比較的頑張っていたみたいですね。

Random Write bs=4K iodepth=128

Writeはやはりどうしようもない。むしろこれでMX500がS4500と同じくらい性能出てたらどうしようかと。

Random Write bs=4K iodepth=1

こちらはもっと露骨。

Latencyを見るとMX500の悲しい性能が際立っている。

チューニングメモ

• C6ステートを無効にしたらレイテンシが改善される可能性がありましたが、改善されたのはpingのLatency程度で特段目立った効果は無し
  • SecureBoot無効にして modprobe msr でカーネルモジュール入れて python3 ./zenstates.py --c6-disable とかやってました
• BIOSの電源設定をPerformance modeにすると少しだけ性能改善がありそうでしたが、自宅サーバーなので見送りました
• 以下のカーネルパラメータも少しいじってみたものの、これも目立った効果は見られず
  • sysctl -w net.ipv4.tcp_low_latency=1
  • sysctl -w net.ipv4.tcp_fastopen=1
  • sysctl -w net.ipv4.tcp_timestamps=0
• cephxの認証/暗号化を無効にしてみたものの、これも目立った効果は見られず

  1 2 3 4 5 6 7 8 9 10 11 12 13 14

  ~# diff -u ceph.conf.bk /etc/ceph/ceph.conf --- ceph.conf.bk 2025-05-01 21:34:13.475309835 +0900 +++ /etc/ceph/ceph.conf 2025-05-01 21:34:35.000000000 +0900 @@ -1,7 +1,7 @@ [global] - auth_client_required = cephx - auth_cluster_required = cephx - auth_service_required = cephx + auth_client_required = none + auth_cluster_required = none + auth_service_required = none cluster_network = 172.16.0.21/24 fsid = 72fa059a-ebcd-4636-8eff-171873d5e392 mon_allow_pool_delete = true

• KRBDはRandom Write 4KB iodepth=1に若干改善が見られた（1400弱くらいになる）ので、とりあえず以下の設定を採用
  

おしまい

データを取ったのは5月くらいで、ほとんど覚えてなかったりして。
とりあえず今はとても安定して動いています。KRBDも特に問題ないですね。
測定をやり直したりして結構書き込みしたはずなのですがWearoutがまだ0%なので、長い付き合いになるとありがたいところ。

ストレージについて | さくらのクラウド マニュアル などを見ていると全ての標準プランでは読み込みIOPS 2000、書き出しIOPS 500でした。
これくらいならCephの共用ストレージで出せそうな感じがしました。目標にするには中々いい数字です。

でもAmazon EBS 汎用 SSD ボリュームはgp3で3000 IOPSとか平然と描かれていますし、単なるCephで太刀打ちできるラインを越えてるんですよね…
これはチープな環境で戦って勝てる数字なのか、内情を知りたくなります。
一旦Cephのことは忘れて、高IOPS仮想マシンをどう払い出すかを考えるのも思索には良さそうです。
いえ、別に暇なわけでは無いですけど…

ではまた。