前回 は、以前 紹介した弊社サービス運用基盤である Kubernetes (k8s) クラスタ上で、Rook/Ceph が提供するブロックデバイスストレージ (RBD) のパフォーマンス計測を行い、また Azure が提供する Managed Disk との性能的な特徴を比較しました。

RBD は、Rook/Ceph が k8s の PV/PVC として提供するストレージの中では最も使い勝手がよく、またチューニングが必要になる機会が少ないものです。

今回パフォーマンス測定する CephFS は、RBD とは異なり、ReadWriteMany でのアクセスを提供します。つまり競合となるのは、共有ファイルシステムです。クラウド上でマネージド・サービス提供されているものとしては、 CIFS (SMB) や NFS が候補に上がりやすいでしょう。Azure での FileShare や AWS の EBS は、製品選定時の比較対象になるはずです。

技術者が多めな SNS を眺めてみると、NFS に対して CephFS は性能面で望めないという声が日本語圏で多めで、英語圏では反対にポジティブな声がそこそこあり、それぞれ定性的な意見に留まっている感があります。(SNS のリコメンデーション機能により、筆者の見える範囲が偏っている可能性はあります。)

相反する意見がある理由は、筆者には想像がつきます。CephFS は、構築時に以下のポイントを抑えていたか否かで、運用時性能に差が出やすい傾向があります。

  • Rook/Ceph クラスタの構成
  • ベンチマークを基にした CephFS (MDS) のチューニング

今回は、CephFS でのベンチマーキングを行い、製品選定時の比較対象になりそうな製品である、マネージド NFS との比較を行っていきます。

テストベンチは、弊社サービス用に実運用中の AKS クラスタです。Rook/Ceph クラスタの構成はベストプラクティスを踏まえていますが、MDS のパラメータについては詰めたチューニングは行っていません。

前回も注釈したとおり、下記の理由により、得られた数値そのものは統計的な正しさを持つとは保証されません。ただし傾向を見るだけなら十分な値となりえるはずです。

  • 一回計測のデータであり、統計的な処理が為されていない。
  • 実運用中のクラスタなので、計測環境以外の Pod が RADOS を共有しており、ベンチマーク性能に(CephFS にとって悪い方向で)影響する可能性がある。

さて、前口上はこのくらいにして、計測と結果グラフを示していきます。

計測方法

前回と同様とします。

共有ファイルシステムの計測については別の観点での評価も必要ですが、その辺りは次回で取り扱います。

CephFS の計測結果

randread

cephfs-randread

randread は RBD の 60% 程度のスループットで頭打ちとなりました。様々な理由が考えられますが、まずは下記の観点でより詳細なベンチマークによる検討を行う余地があります。(本記事では、詳細には踏み込みません)

  • CephFS は共有ファイルシステムなのでキャッシュが期待できない(ので性能を受け入れる)。
  • メタデータを保持している MDS の、パフォーマンスチューニング余地を探る。
  • depth とブロックサイズが共に大きくなると IOPS 値が伸び悩むことに着目し、改善を試みる。

randwrite

cephfs-randwrite

RBD での値と比して 10〜20% 程度低いですが、もしかすると誤差に収まるかもしれない範囲かもしれません。CephFS の典型的ユースケースを考えると、複数クライアントから並行した書き込みが発生する可能性は高く、「ベンチマークの設定が甘かった」と判断する余地はあります。

ブロックサイスを変えず depth を増やしたときの IOPS 値の伸びが randread よりも良い場面が見られます。CephFS を利用するアプリケーションの特性と掛けられる予算次第ですが、OSD の数を増やすことで実運用時性能を向上させられる余地はありそうです。

NFS (Azure FileShare) の計測結果

手元にデプロイ済みの AKS には NFS を用いる前提の StorageClass は存在しませんでした。そこで、下記の通り作成しました。一部情報は伏せてあります。

---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azurefile-csi-nfs
provisioner: file.csi.azure.com
parameters:
  resourceGroup: <<hidden>>
  storageAccount: <<hidden>>
  server: <<hidden>>.file.core.windows.net
  protocol: nfs
reclaimPolicy: Delete
allowVolumeExpansion: true
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-pvc
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 300Gi
  storageClassName: azurefile-csi-nfs

FileShare とは PrivateLink で繋いでいます。 バックエンドで使われるストレージ (Disk) の種類等はデフォルトとしました。 Azure FileShare は、他のクラウドプロバイダの類似サービス同様に、確保するストレージ容量で IOPS やスループットは変動します。まずは、 CephFS で確保したのと同じ 300Gi としました。 カタログスペックは下記のとおりになります。

最大IOPS 最大IOPS(バースト時) スループット
3300 10000 130.0 MiB/s

randread

nfs-1-randread

IOPS はバースト時の最大値を出し、ブロックサイズ増加と共に値を減らしていきます。 今までのグラフと比べて特異的なのは、スループットが安定しないことです。 カタログスペックの最大スループットは 130.0 MiB/s と低い値にとどまります。 実測値はカタログスペックより高く、ブーストがかかっている可能性はありますが、詳細は未調査です。

この環境で CephFS と比較すると、ブロックサイズ 256k 未満で NFS (Azure FileShare) より CephFS が優位であり、スループットも数倍の差がつく結果となりました。

randwrite

nfs-1-randwrite

randread では大差で CephFS が値を叩き出しましたが、 randwrite では NFS (Azure FileShare) が概ね優勢です。特にブロックサイズが小さい場合の IOPS では大差がついています。

一方、ブロックサイスが大きくなるにつれ IOPS 性能が拮抗し始め、4m では逆転します。(誤差範囲である可能性はあります)。

randread で見られた、スループットの不安定性さも見られます。

NFS (Azure FileShare) の計測結果(3000Gi)

上記の計測結果と同条件で、NFS のストレージサイズを 3000Gi まで増加させ、再計測を行いました。 カタログスペックは、下記のようになります。

最大IOPS 最大IOPS(バースト時) スループット
6000 10000 400.0 MiB/s

randread

nfs-1-3Ti-randread

ストレージ容量 300Gi のときに見られた、スループットのバタつきは収まりました。 しかし、スループットおよび IOPS ともに最大値に制限があり CephFS と比して苦戦を強いられています。 単に値が絞られているだけでなく、最大 400.0 MiB/s あるはずのスループットが 300 MiB/s 付近で頭打ちになっているのも着目する余地がありそうです。

randwrite

nfs-1-3Ti-randread

randread ほどではないですが、IOPS およびスループット共に値のバタつきは収まっているように見えます。 スループットは最大値が得られるケースはあるものの、安定していません。 原因としていくつかの可能性が考えられますが、仮に K8s クラスタと NFS サーバとのネットワーク的な距離の問題が絡んでいるなら、ユーザ側での解決が難しい場合もありそうです。

まとめ

「NFS に比べ、CephFS は世間で言われるほど遅いのか?」という観点を織り交ぜながら、ベンチマークを取り比較しました。

今回の範囲で言えば「randread は CephFS のほうが速い。randwrite は、ブロックサイズが小さいと NFS のほうが速い。ブロックサイズが大きいと大差ない」辺りに落ち着きそうです。

  • 小さな BLOB を書き込むなら、マネージド NFS
  • 大きな BLOB を読み書きするなら大差はないが、ストレージ容量が少ないなら CephFS

一例として、GitLab や Gerrit のような Git サーバ用ストレージについてご相談いただいた場合なら…

  • 常識的にソースコードを管理しているなら、マネージド NFS をバックエンドにできるかも?
  • AOSP の Gerrit のように、大サイズのバイナリを管理しているなら、CephFS のほうが無難かも?

…という感じでおすすめするかもしれません。

しかし、NFS 派の中には、この暫定結果に対して不満を抱く方もいらっしゃるかもとも思います。

今回は数あるマネージド NFS のうち Azure FileShare という一製品しか比較対象となっていません。例えば Azure と AWS とでは、帯域予約のメニューなどが異なりますし、コスト面での pros/cons があります。 コスト面で更に言えば、Rook/Ceph を効果的に構築するには、ストレージに関し相応の知見のあるエンジニアの支援が必要となります。「人件費分をマネージド NFS の帯域予約に注ぎ込む」というのも現実的には採り得る選択肢です。

また、オンプレであれば、帯域制限なしの NFS 環境も作れます。

つまり「NFS vs CephFS」と単純化できない部分が、この技術選定には存在します。

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

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

To be continued

今回のベンチマークは 1 ファイルに対しブロックサイズを変更しながらベンチマークを採りました。 これも一つの指標として有効なのですが、共有ファイルシステムの場合、metadata に関するベンチマークが実運用時の性能予測に対し重要です。

次回は、その辺りを踏まえたベンチマークを、NFS (Azure FileShare) と CephFS に対し行う予定でいます。