一月ほど前に、弊社サービス運用で実稼働している Rook/Ceph クラスタを用いて、パフォーマンス測定を行い記事にしました。

その後、ストレージ容量を増強する必要が生じ、OSD の Pod 数を 6 から 9 へ増加させました。 1 OSD が抱えるストレージは、従前と同様の Azure Managed Disk Standard_HDD 512GiB です。

「Rook/Ceph クラスタの性能を向上させるためには OSD を増強すると良い」と言われています。

実際にどの程度変化があるのか、実測してみました。

前回記事同様に、他の Pod が RADOS を共有している環境で一発撮りしています。よって統計的には何も語れません。傾向のみ掴めるという程度感で御覧ください。

本稿では RBD のみ扱います。CephFS につきましては、稿を改める予定です。

RBD の計測結果

randread

9 OSD 構成での、計測結果は下記のとおりです。

depth=128 でのスループットの伸び悩みは、現時点では理由不明です。 (いくつか仮説は考えられるため、後日検証予定)

比較対象として、前回記事(つまり 6 OSD 構成)での結果も掲載します。

スループットで2倍、IOPS でも概ね改善が見られました。

randrwrite

9 OSD 構成での、計測結果は下記のとおりです。

こちらも、depth=128 でのスループットの伸び悩みが見られます。 また depth=128 1m でのスループット値は高すぎで外れ値であるか検討の余地がありそうです。 (同様に、後日検証予定)

比較対象として、前回記事(つまり 6 OSD 構成)での結果も掲載します。

スループットは randread ほどの伸びは得られませんでした。 Ceph は、冗長性確保のため write 時には(デフォルトで) 3 つの OSD へ同じ書き込みを順番に行います。この書き込みがボトルネックになっている可能性が考えられます。

一方、IOPS は改善されました。RBD への書き込みが頻繁に起こる環境では、OSD の増強には一考の余地がありそうです。

OSD を増やすデメリット

「性能が改善するなら OSD を増やせば良いのね」とご判断頂く前に、デメリットもご紹介しておきます。

下記のデメリットが最悪な結果をもたらした場合には、クラスタ内のデータが復旧不可能という事態を招きます。OSD は計画的にデプロイされる必要があります。

コスト増

OSD はストレージ、メモリ、CPU を使います。OSD を増やすとコストが嵩むのは、すぐにお分かり頂けると思います。 メモリや CPU を節約しすぎると、OSD のクラッシュが起こりやすくなります。却って性能が出ないばかりか、回復不能なクラスタ破損へ繋がる場合もあります。

可用性の低下

各 OSD の故障率は、クラスタ全体での OSD の数に依らず一定と考えられます。OSD を増やすということは、クラスタ内で壊れている OSD 数の期待値(確率)が高まることを意味します。

RADOS はデータを 3 重冗長で OSD へ記録しています。言い換えると、3 OSD が故障した場合、運が悪いとデータが復旧不可能となります。

まとめ

Rook/Ceph で OSD を増強した場合に、RBD の性能がどう改善されるかを、弊社実運用中の Rook/Ceph クラスタで実測しました。 概ね性能は向上するものの、安易に OSD を増やした場合のリスクもご紹介しました。

「ではどのように OSD をデプロイすると良いの?」とお悩みの方がいらっしゃいましたら、ぜひ弊社までお声掛けください。いくつかのチューニングポイントを踏まえていなかったゆえに、本来の性能を発揮できずにいた、お客様の Rook/Ceph クラスタに弊社は寄り添ってきました。 本稿では Azure を例に取りましたが、AWS や GoogleCloud 等、各社クラウドにも対応可能です。