Ceph BlueStore：キャッシュするかしないか、それが問題だ。

キャッシュするかしないか、それが問題です。

あなたならどうしますか？ Ceph^® クラスターをキャッシュしますか？ その答えは「場合による」です。

Micron^® 9200 MAX などのハイエンドのエンタープライズ NVMe™ドライブを使用する場合は、何も心配せずにCephクラスターから最大限のパフォーマンスを引き出すことができます。けれども、大部分がSATAドライブで構成されているシステムでパフォーマンスを向上させたいときはどうでしょうか。このような状況では、BlueStoreデータベースとログ先行書き込みを保存するCeph OSD サーバーに、いくつかの高速ドライブを追加するとメリットがあります。

マイクロンは、人気のAccelerated Cephストレージソリューションを開発しテストしました。このソリューションは、Red Hat Linux上で実行するRed Hat Ceph Storageを搭載したサーバーを活用しています。これから、いくつかのワークロードシナリオを見ていただき、マイクロンのソリューション テストラボによる実際の結果に基づいて、キャッシュがどのような状況で役立つかをご紹介したいと思います。

システム構成

テストは、次の構成の4つのOSDノードCephクラスターを使用して実施しました。

表1：Ceph OSDサーバーの設定

4KiBランダムブロックテスト

FIO（Flexible I/O）を使用した4KiBのランダム書き込みの場合、キャッシュドライブを使用すると、高負荷時でもテールレイテンシーを低く抑えながらパフォーマンスが大幅に向上することがわかります。FIOの40インスタンスの場合、パフォーマンスは71%向上し（190K 対 111K）、テールレイテンシーは72%低下します（119ms 対 665ms）。

図1：4KiBランダム書き込みパフォーマンスとテールレイテンシー

4KiBランダム読み取りテストではパフォーマンスが向上しますが、あまり説得力はありません。これは、予想されることです。読み取りテスト中にログ先行書き込みが使用されず、BlueStoreデータベースがほとんど変更されないからです。

図2：4KiBランダムリードパフォーマンスとテールレイテンシー

混合ワークロード（読み取り70%、書き込み30%）でも、システムにキャッシュデバイスを配置することのメリットがわかります。パフォーマンスの向上は、キュー深度64で30%、キュー深度6で162%の範囲です。

図3：4KiBランダム70% 読み取り／30% 書き込みパフォーマンスとテールレイテンシー

4MiBオブジェクトテスト

4MiBオブジェクトでRados benchコマンドを実行すると、キャッシュデバイスがあるとパフォーマンスが多少向上しますが、小さなブロックのワークロードほど劇的ではありません。ログ先行書き込みは小さく、オブジェクトも大きいため、キャッシングデバイスを追加することでパフォーマンスへの影響が大幅に軽減されます。Rados benchのインスタンスを10個実行したとき、キャッシュありの場合はキャッシュなしと比べてスループットが9%向上し（4.94 GiB／秒 対 4.53 GiB／秒)、平均レイテンシーは7%低下します（126ミリ秒 対 138 ミリ秒)。

図4：4MiBオブジェクト書き込みパフォーマンス

読み取りの場合も、全体的にパフォーマンスの向上はごくわずかです。

図5：4MiBオブジェク読み取りパフォーマンス

まとめ

ご覧のように、ワークロードがほぼすべて読み取りである場合、BlueStoreデータベースと先行書き込みログ ストレージ用のCephクラスターにキャッシュデバイスを追加しても、ほとんどメリットはありません。しかし、書き込みでは、それはまったく別の話です。大きなオブジェクトの場合は、ある程度のメリットがありますが、キャッシュデバイスに関して現実的に問題となるのは、小さなブロック書き込みと混合ワークロードです。システムにマイクロンパフォーマンス9200 NVMeドライブを2台追加するという小さな投資で、Cephクラスターを最大限に活用できます。

オープンソースストレージでは、どのような結果が得られるのでしょうか。詳細は、マイクロンAccelerated Ceph Storageをご覧ください。

Xでマイクロン@MicronStrageをフォローし、LinkedInでマイクロンとつながることで、最新情報をチェックできます。