前回の記事で「ReadWriteMany 型の分散共有ファイルシステムを採用検討する際には、スループットだけでなくメタデータの性能も考慮する必要がある」。

という旨の説明をいたしました。

実運用時性能を考慮したベンチマーク測定を厳密に行うには、そのアプリケーションの特性を、分析し加味する必要があります。

よって、技術ブログ記事の解説では一般論を超えられない、という限界があります。予めご承知おきください。

metadata に関するベンチマークで、比較的手軽に行なえ、古くから知られているツールとして bonnie++ があります。

bonnie++ のソースコードは、ストレージの速度が現在よりも桁違いに遅かった時代から更新されていないため、2023 年現在で使うためには与えるパラメータに一工夫が必要です。そこを踏まえていれば、動作そのものは安定しており信頼に足ります。

今回のベンチマークでは、下記のオプションで実行しました。

$ ./bonnie++ -d /{各ストレージのマウント先ディレクトリ} -n 256:1024:1024:16

それぞれのストレージを CSI 経由でマウントした Pod から bonnie++ を実行しています。以前 fio で取ったベンチマーク環境と変わらない構成です。

今回も、得られたデータの絶対値は環境により異なるので意味はなく、傾向のみ着目できるよう、グラフのみ掲示します。

fio と bonnie++ とは、互いに計測方法が異なります。両者が出したデータの直接比較も、概ねな傾向を見る程度に留めておくことをお勧めします。(両者で同じ傾向が出たなら、その傾向を信じて良い、など)

bonnie++ では、下記の 3 視点でのベンチマークを取得できます。

  • シーケンシャルアクセス
  • ランダムアクセス
  • メタデータ関連

ランダムアクセスも重要な視点ですが、今回はスループットとメタデータに着目しているので、割愛します。

シーケンシャルアクセスのベンチマーク

シーケンシャルアクセスのベンチマーク結果は、いわゆるスループット性能を表しています。既に fio を使った計測を行っており重複する部分も大きいので、ざっと読んでいきます。

fio を使ったベンチマーキング結果については、下記記事をご参照ください。

performances on sequential access

out は write、in は read と読み替えて結構です。

下記概況の結果を踏まえると、スループットのみの計測なら「Ceph より NFS が高性能」と判断する可能性が高いのではないでしょうか。

out 概況

char 単位の out (per char) では、CephFS RBD ともに軟調です。Ceph の基盤である RADOS の弱みが現れています。 block 単位の out も、値は今ひとつです。3 つのストレージに書き込む Ceph は、やはり書き込み性能でハンディキャップを追いがちです。 rewrite(out)、つまり同じブロックへの再書き込みを行ったとき、やっと Azure FileShare (NFS) と拮抗します。

in 概況

char 単位の in では、RBD が優位に立ちます。fio を用いたベンチマークで RBD が 800MB/s 辺りで飽和していたのを想起させるような結果となっています。

メタデータのベンチマーク

さて、今まで計測を行ってこなかった、metadata 関連のベンチマーク結果をグラフで示します。

performances about metadata

まず、このグラフは片対数であることに注意してください。つまり縦軸の目盛りが一つ増える毎に性能は 10 倍となります。

今回計測の結果を見る限り、CephFS と NFS との性能差は、 比喩ではなく、桁違い です。

前回記事でも示唆したとおり、メタデータのアクセスは、いくつかの用途、特にデータベースやソースコードリポジトリのようなアプリケーションで多用されます。

これが、ReadWriteMany の共有ファイルシステムを検討する際に、メタデータの処理性能もベンチマーキングすることを、弊社が強く推奨する理由です。

検討の余地

今回 Azure FileShare (NFS) と CephFS との間で、メタデータの性能差が歴然としていました。差があまりにも大きいため、「パラメータを選んだ出来レースなのでは?」と訝しむ声も出そうかもしれません。

しかし、CephFS は Rook がデプロイしたままのデフォルトの設定です。Azure FileShare も CSI ドライバのデフォルト設定でデプロイされたものです。bonnie++ に与えたオプションも、他の技術系ブログで使われているものを流用し、データは一発撮りです。加工の余地はありません。

Azure 側を擁護するならば、下記のような事情は考えられます。

  • 価格性能比が考慮されていない。Rook/Ceph クラスタのリソース使用料を考慮するなら、もっと高価格高性能のストレージを選択できる余地はある。
  • Azure は Microsoft 提供のサービスなので NFS よりも、競合技術である CIFS のほうが得意である。CIFS ならもっと性能を出せる。(仮説)

また、マネージド NFS サービスを提供するクラウドプロバイダ毎に事情が異なる可能性はあります。 Azure に限らず大抵のクラウドプロバイダのマネージド NFS では、メタデータについて今回と同様の性能差を示すはずです。しかし、AWS EFS のように「インタフェースを NFS に合わせているだけで、内実は最適化された分散ストレージシステム」であるサービスの場合、CephFS との性能差が縮まる可能性はあります。

一方 Rook/Ceph に寄った立場では「このクラスタでは CephFS 関連のチューニングは全く行っておらず、性能改善の余地は大いにある」ということは言えそうです。

まとめ

「ReadWriteMany の共有ストレージでは、スループット性能のみに着目するのは危うい」という着地点を目指して、数回に分けて記事を書きました。

分散共有ファイルシステムは、ブロックストレージとは性能評価ポイントが異なる面があります。パソコンやスタンドアロンのサーバではブロックストレージの利用が一般的なので、マネージド NFS 導入前性能評価では見落としてしまう項目が出がちで、結果、導入後の性能問題に繋がりがちです。

弊社は、8〜16 ノード程度の中規模 Rook/Ceph の導入検討や運用でお困りのお客様に向けて、サポートサービスを行っております。ご相談の結果、クラウドのマネージドソリューションのほうが合理的な場合には、その旨をご提案する場合もあります。

Rook/Ceph 導入という結論ありきではない、事前検討のお手伝いも承ります。ぜひお問い合わせください。