はじめに
本記事はCephのBest Practiceを探る第三弾になります。今回も先日紹介した記事の続編として、Cephの公式ブログで公開されているこちらの記事の内容を紹介いたします。今回も記事内容への補足や個人的なメモは青文字で加えております。
要約
- Part 1で利用した検証環境において、Red Hat Ceph Storage(RHCS)が3ノードの時と5ノードの時を比べ、パフォーマンスがどの程度向上したかを測定しました。
- Smallブロックサイズでは、ハードウェアリソースを60%追加することで、Random Read-WriteのワークロードのIOPSを95%向上し、平均レイテンシ・Tailレイテンシをそれぞれ46%、44%削減しました。
- LargeブロックサイズのRandom Readワークロードでは、クライアントネットワークがボトルネックとなり、9.8GB/sのスループットを示しました。
- LargeブロックサイズのRandom Writeワークロードは、3ノードの時と比べ、スループットが67%向上し、メディア使用率がボトルネックとなりました。
検証内容
今回の検証環境は、Part 1で利用したRHCSの環境を引き続き利用します。
Part 3で異なる点は、Smallブロックサイズ(4KB)とLargeブロックサイズ(1MB)のワークロードを使用し、1回目のパフォーマンス計測はRHCS 3ノードで、2回目の計測は1回目と全く同じ内容で5ノードで計測を行った点です。各ストレージノードは7つのメディアデバイスを接続し、デバイスあたり2つのOSDを用意しました。
計測では、Random Read / Random Read-Write / Random Writeの3つのワークロードについて行い、各ワークロードでIOPS・平均レイテンシ・Tailレイテンシを計測しました。
1. Small ブロックサイズの場合
まずはSmallブロックサイズの計測結果のグラフを載せます。グラフの縦軸はIOPSと平均レイテンシを、横軸には各ワークロードを置いています。棒グラフ・折れ線グラフは、青色が3ノード、赤色が5ノードの結果を表しています。なおIO Depthは32で固定です。
Graph 1:Small ブロックサイズの結果
Table 1:5ノードでのパフォーマンス改善率
Workload | IOPS | Average Latency | Tail Latency |
---|---|---|---|
Random Read | +55% | -29% | -30% |
Random Read-Write | +95% | -46% | -44% |
Random Write | +77% | -40% | -38% |
Graph 1・Table 1より、以下のことがわかります。
- クラスターリソースを60%増加したことで(=3ノードから5ノードにしたことで)、Random Read-Writeのパフォーマンスは大きく向上した。IOPSは95%増加し、平均レイテンシ・Tailレイテンシはそれぞれ46%・44%減少した。またパフォーマンスのボトルネックとなった要因として、最初にメディア使用率が、その次にCPU使用率がボトルネックとなった(※1参照)。
- 上記結果から、スケールアウト可能なクラスターを利用することで、小規模のクラスターからシステムを開始し、その後パフォーマンスを向上させたい場合は、単純にストレージノードを追加するだけで実現することが明らかになった。
※1:Part 2の中で、IO Depth=32の時の計測結果を比較したときに、メディア使用率よりもCPU使用率のほうがボトルネックとして強く影響していることを示唆する結果となっています。Part 3のここでの記述は、Part 2と比べて矛盾するような結果となったようにも読めますが、詳細については特に記載されていないため、これ以上は分かりませんでした。
また、上記グラフ取得時の計測とは別に、IO Depthを64に設定し、クライアント数を増加したときのパフォーマンスを比較を行った結果が、以下のGraph 2になります。
Graph 2:クライアントの負荷テスト
上記グラフから分かることとして、以下のことが言えます。
- どのクライアント数においても5ノードのほうが3ノードに比べて高いパフォーマンスを発揮した。
- ノード数を増加したことで、IOPSは100%以上の向上を、平均レイテンシ・Tailレイテンシはそれぞれ60%・50%の削減がされた。
※2:Part 1でも同様の計測を行っており、そちらと比較すると、5ノードの場合はほぼ同じような値を推移していることが分かります。
Largeブロックサイズの場合
続いてLargeブロックサイズの計測結果が以下のグラフになります。
Graph 3:Largeブロックサイズの結果
Graph 3より、以下のことが明らかとなります。
- Random Readにおいて、スループットは最大9.8GB/sで頭打ちとなった。これはクライアントネットワークの集積したスループットがボトルネックとなっていた(※3参照)。そのため、もしクライアントノードを追加したり、Cephクラスターとクライアント間のネットワーク帯域幅を増強すれば、Random Readスループットを向上できると予想された。
- Random Read-Write、Random Writeのパフォーマンスは、OSDのメディア使用率がボトルネックとなっており(※4参照)、サービス稼働時間が増加したため、パフォーマンスが一定の値に留まった。OSDノードをさらに追加することで、Random Read-Write、Random Writeのパフォーマンスをさらに向上させられる可能性もある。
※3:Part 1でも記載したように、クライアントネットワークは最大スループットが10GB/s程度となります。
※4:Part 2でのLargeブロックサイズの計測結果より、メディア使用率がボトルネックとなっていることが示唆されています。