はじめに
要約:ブログエピソード1では、RHCS、BlueStoreの紹介、ラボハードウェアの詳細、ベンチマーク方法論、およびデフォルトのCeph構成とチューニングされたCeph構成とのパフォーマンス比較について説明しました
これは、All–Flashクラスタ上で実行されているrhcs3.2bluestoreのパフォーマンスブログシリーズの第二のエピソードです。 ブロックサイズを小、中、大のカテゴリに分類する経験則はありません。 そのため、4Kを小ブロックサイズのカテゴリに、8K-64Kを中ブロックサイズのカテゴリに、1M-4Mを大ブロックサイズのカテゴリに指定しました。 このエピソードでは、ランダム読み取り、ランダム書き込み、およびランダム読み取り/書き込みワークロードパターン全体で、小（4K）、中（8K-32K）、大（1M-4M）のブロ
エグゼクティブサマリー
- スモールブロック4Kワークロード、最大2つまで提供。CPUとメディアの競合によって制限されるまで、200万回のランダム読み取り、691Kのランダム読み取り/書き込み（70/30）、および463Kのランダム書き込みIOPS。
- small block workloadと同様に、medium blockのパフォーマンスはCPUとメディアの競合によって制限されていることが判明しました。
- Large block4Mワークロードピークパフォーマンスは、クライアントネットワーク帯域幅によって制限されるまで、ランダム読み取り、書き込み、および読み取り-書き込み(70/30)
パート-1：小さなブロックサイズ（4KB）パフォーマンス
主要な持ち帰り
- ランダム読み取りワークロードが2を示しました。メディアの飽和によってボトルネックになるまでの平均レイテンシは200万IOPS@3msです。
- ランダム読み取り/書き込み(70/30)ミックスワークロードは、CephノードCPUリソースの競合によってボトルネックになるまで、691K IOPS@6msの平均レイテンシを示しました。
- ランダム書き込み:463K IOPS@11ms CephノードCPUリソースの競合によってボトルネックになるまでの平均レイテンシ。
概要
テストのこの部分では、cephブロックストレージインターフェイスは、ランダム読み取り、ランダム書き込み、およびランダム読み取り/書き込み(70/30) テスト中に取得される主な指標には、IOPS、平均、レイテンシ、CephノードCPU、およびメディア使用率が含まれます。
グラフ-1は、5つのオールフラッシュノードを持つ異なるアクセスパターンにわたる4Kブロックサイズのトップラインのパフォーマ そのように最大性能はあるために見つけられました
- ランダム読み取り:220万IOPS@3ms平均レイテンシ
- ランダム読み取り/書き込み(70/30)ミックス:691K IOPS@6ms平均レイテンシ
- ランダム書き込み: 463K IOPS@11ms平均レイテンシ
h graph-2とgraph-3でキャプチャされたCPUとメディアの使用率は、異なるワークロードパターンのボトルネックを理解するのに役立ちました。
- ランダム読み取り性能はＣＰＵリソース競合によってボトルネックであることが分かったが，メディア使用率も高い側にあることが分かった。 そのため、cephノード（CPUとメディア）を追加して、ランダム読み取りパフォーマンスを向上させることができました。
- random writeとrandom read-write(70/30)mixの両方で、CPU消費量が増加することによりパフォーマンスがボトルネックになりました。 興味深いことに、同時にメディアは、計算能力の欠如のために未使用のままで十分な予備のスループットを持っていた。 このように、Ceph OsdへのCPUコアの割り当てが高いほど、ランダム書き込み&ランダム読み取り/書き込みミックスワークロードのパフォーマンスが向上します。
Osdデータデバイス（P4500NVMe）の使用率は50％未満のままでしたが、BlueStore WALとRocksdbメタデータをホストしていたIntel Optane P4800デバイスは90％@非常にビジーであることが Bluestore_min_alloc_size_ssdパラメータは16KBに設定されていたため、16KB未満のすべての書き込みが延期され、書き込みは最初にWALデバイスに入り、osdデータに非同期的に書 RocksDB/WALデバイスの使用率が高いにもかかわらず、P4500osdデータデバイスで競合の兆候は見られませんでした。 しかし、この経験に基づいて、WAL/RocksDB用の単一のIntel Optane P4800の背後に7x P4500NVMeデバイスを置くことはお勧めしません。
グラフ2
グラフ3
私たちが実行したもう一つの興味深いテストは、クライアントスイープテストであり、20から140までのクライアントの数を直線的にスケールアッ クライアントの負荷を増加させると、Ceph OSDでCPUの輻輳に達するまで、線形のパフォーマンスの向上が観察されました。 100クライアントでは、445Kの集約された4K書き込みIOPSが観察されています。 この時点の後、システムリソースの輻輳は高いテールレイテンシをもたらした。 メタデータとして使用されるIntel Optaneは、平均レイテンシが40ms以下にとどまったため、多数の並列クライアントでレイテンシスパイクを吸収するのに役立.
G＜3297＞＜7379＞その2: 中ブロックサイズのパフォーマンス
主要な課題
- CPUとメディアの飽和によってパフォーマンスがボトルネックになるまで、5つのオールフラッシュCephノードは、約1.8万のランダム読み取り、約636Kのランダム読み取り(70/30)、約410Kのランダム書き込みIOPSを提供した。
- パフォーマンスを拡張するには、既存のCephクラスターに追加のCeph OSDノードを追加する必要がありました。
概要
以下のグラフでは、IOPS、平均レイテンシ、テールレイテンシ、CephノードCPU、メディア使用率など、さまざまな異なるデータポイントを表現しようとしました。 そして、これらのすべては、ランダム書き込み、ランダム読み取り、ランダム読み書き（70/30）ミックスのための4Kから64Kまでのブロックサイズの範囲
いくつかの興味深いデータポイントには、
- 予想通り、小さなブロックサイズは中程度のブロックサイズに比べて最高のIOPSを示し、平均および尾 そのため、Random Read、Random ReadWrite Mix、Random write writeの各ワークロードでは、それぞれ約180万、約636K、約410KのIOPSが観測されました。
- Ceph OSDノード上のCPUおよびメディアデバイスで高い使用率が観察されました。 CPUとメディアの使用率は、それぞれ-90％と-80％と高いことが判明しました。 そのため、既存のCephクラスターにCeph OSDノードを追加すると、パフォーマンスが向上する可能性があります。
G
Part-3:大型ブロックサイズ性能
主要課題
- 大型ブロック4M性能が10をピークに上昇した。ランダムな読み取り、書き込み、および読み書き（70/30）ミックスのための9GB/s。
- クライアントネットワークが制限要因であり、パフォーマンスのボトルネックの原因であることが判明しました。
- より多くのクライアントノードまたはより大きなネットワークパイプを持っていた場合、パフォーマンスは高くなっていた可能性があります。
概要
私たちがテストしたすべての異なるパターン、すなわち、大きなブロックサイズの4Mワークロードに対するランダム読み取り、書き込み、および読み書き(70/30)ミックスは、10.9GB/sの集約スループットを突破しました。 クライアントネットワークがパフォーマンスのボトルネックの原因となる制限要因であることが判明した。 ネットワーク以外で2番目に利用されたリソースはメディアでしたが、ネットワークがボトルネックでなければ、より多くのパフォーマンスを提供するのに十分なヘッドルームがありました。
G
Up Next
次のセクションでは、ベンチマークのブログシリーズを続けて、RHCS3.2スケーラビリティテストに関連する結果について説明します。 “3ノードクラスタから5ノードに移行することでパフォーマンスがどのように変化するか”などの重要な質問に答える。 お楽しみに。