ストレージオーケストレーターRookへのサイボウズのコミット方針

はじめに

こんにちは、Necoプロジェクトのsatです。

NecoではKubernetes上のアプリケーションが使うストレージをCephによって提供すること、およびCephクラスタの管理にKubernetes上で動作するストレージオーケストレーターRookを使うことを決めています。本記事はNecoがなぜRook/Cephを選択したのか、Rookに対する現在のコミット状況、および今後のコミット方針について紹介します。

CephやRookがどういうものなのかについては以下の記事をごらんください。

blog.cybozu.io

blog.cybozu.io

なぜRook/Cephなのか

まずはNecoがなぜストレージをRook/Cephによって提供することにしたのかを簡単に書いておきます。

Ceph

Necoで提供するストレージには、既存のインフラで苦労した点を無くす、あるいは軽減するために次のような要件を定義しました。

  • OSSである: トラブル発生時に自分たちの手によって早急に問題を解決したい。
  • コミュニティが活発である: バグの検出や修正、機能開発に必要な人的資源が多いほどよい(後述のようにサイボウズもその一員となる)
  • スケーラビリティが高い: サーバ一台に搭載できる程度の容量にとどまらず、数PB単位のデータを保持したい。
  • 高可用性: ハードウェア障害の発生時やハードウェアメンテナンス時にサービスを継続したい。
  • セルフヒーリング: デバイスが壊れてもオペレータの介在なしにデータの冗長性を回復したい。
  • bit-rot耐性: ストレージデバイスの障害によってデータが壊れても自動検出/復旧可能したい。

様々な候補の中から上記の要件を満たすものを調査したところ、Cephが適しているという結論に至りました。

Rook

Cephの機能は豊富なのですが、いざ運用するとなるときには一つ大きな課題があります。それはノードの追加/削除を含めた管理が難しいためにオペレータへの負担が大きいということです。この課題を解決する既存の方法があるかを調査したところ、Kubernetesを活用してCephクラスタを宣言的に管理するRookが候補にあがりました。

幸いにもRookは必要な機能の多くが既に実装されており、かつ、コミュニティも活発であったことより採用することになりました。

これまでのRookコミュニティへの貢献

前節において述べたようにRookはNecoに必要な機能の多くを実装しているのですが、いくつか不足している機能もあります。これらの不足機能についてはRookの修正を自社内で済ませるのではなく、弊社のオープンソースソフトウェアポリシーに従ってアップストリームの Rook にPull Requestを送ることにしました。 blog.cybozu.io

では具体的にどのような機能を追加する予定なのかを簡単に紹介いたします。

デバイスの指定にudevがつけたpersistent device nameを使う

現在RookがCephのOSDに使用するデバイスは/dev直下のものだけを指定できます。しかしこれには大きな落とし穴があります。

たとえばノードに/dev/sda,/dev/sdb,および/dev/sdcという3つのデバイスが存在しており、かつ、/dev/sdbをOSDとして使いたい場合を考えると、次のような問題が発生します。

  • /dev/sdbが故障した状態でノードを再起動すると/dev/sdcは/dev/sdbとして認識される
  • デバイスが故障していなくてもハードウェアの設定変更やストレージデバイスの挿入位置などによってデバイスの認識順序が変わる

f:id:cybozuinsideout:20191203012740j:plain

つまり/dev直下に表示されるデバイス名はカーネルがデバイスを認識した順に適当につけたものであって、ハードウェアの構成変更によって変化しうる信用ならないものであるということです。

この問題を解決するためにLinuxにはudevというデバイス管理ツールが存在します。udevを使えば各デバイスには例えばどのバス上にどのスロットに挿入されているかという位置情報をもとにした名前を付けられます。この位置情報はノードごとに一意であるため*1、このようなデバイス名はpersistent device nameと呼ばれます。

我々はこの問題をすでにissueとして報告しており、かつ、この問題を修正するためのPull Requestも発行しました。現在は実装方針についてメンテナと議論中です。

github.com

github.com

OSD on PVC機能においてLogical Volumeをサポートする

Rookは前節において述べたようにCephのOSDに使うデバイスとしてノード上のデバイス名を指定できます。これに加えてRook 1.1からは、KubernetesのPVCによって作成されるブロックボリューム上にOSDを作成できるようになりました。これによってユーザはノード上のデバイス構成を意識する必要が無くなったため、Rookの管理がさらに簡単になりました。

その一方でNecoはTopoLVMというCSIドライバを自作することによって、ノード上のNVMe SSDをPVCとして用途別に切り出せるようにしています。

blog.cybozu.io

ここでTopoLVMとOSD on PVCを組み合わせると、LVMから切り出したLogical VolumeをPVCという形でCephに提供できるというわけです。

f:id:cybozuinsideout:20191203012841j:plain

ただし現状のOSD on PVCは、PVCによって提供されるデバイスがLogical Volumeである場合はうまく動かないという問題があります。この問題についてもissueおよびPull Requestを発行してマージに向けて活動中です。

github.com

github.com

OSDの分散配置

OSD on PVCにはLogical Volumeサポートとは別に、致命的とも言える大きな問題があります。それは、耐障害性を最大限に高めるためにはOSDはすべてのノードに可能な限り均等に分散配置する必要があるものの、現状ではそれが困難であるというものです。

まず前提として、Rookは1つのOSDに対して1つのPodを動作させます。通常Podはどのノード上で動くかが不定なので、極端なことをいうと全OSD Podが同じノードに配置される可能性もあります。OSD用のPodがどのノード上で動かすかは一応nodeAffinity、podAffinity、podAntiAffinity、およびtolerationsを使って制御できるのですが、これらの方法では1つのノード上に1つのOSD Podしか置けないのです(詳細は以下リンクのコメントを参照)。

github.com

この問題を解決するのがKubernetes 1.16においてalphaになったPod Topology Spread Constraintsという機能です。この機能は、簡単に言うと特定のラベルが付与された沢山のPodをノード間やラック間で均等に分散配置するためのものです。この機能をOSD Podに適用すると、上記の要件が達成できるというわけです。

f:id:cybozuinsideout:20191203012915j:plain

すでにRookにおいてPod Topology Spread Constraintsをサポートするためのfeature requestを発行しており、現在は実装方針についてメンテナと議論中です。

github.com

Pod Topology Spread Constraintsについての詳細はKubernetesの公式ドキュメントやチェシャ猫さんのドキュメントをごらんください。

kubernetes.io

speakerdeck.com

Rook/Cephコミュニティへのコミット方針

先日開催されたKubeCon North America 2019において、NecoプロジェクトのメンバはKubernetes関連のメンテナと対話できる"Meet the Maintainer"という機会を利用して、Rookのメンテナと会ってきました。

events19.linuxfoundation.org

kccncna19.sched.com

このときに我々(Neco)は自社(サイボウズ)の次期インフラにおいてRook/Cephを使うことにしたこと、および、次期インフラが存在する限りアップストリームのRookに機能追加やバグ修正をし続けることを伝えました。これに加えて、我々が直接必要なもの以外でも、ユーザ対応やPull Requestのレビューなどにおいて可能な限り協力することも伝えました*2。Rookコミュニティには開発者の人的資源が不足しているらしく、我々の申し出は非常に歓迎されました。

今後はメンテナに表明したことを有言実行すべく、引き続きRookコミュニティのよき一員として、機能追加やバグ修正などの貢献をしていく予定です。RookはNecoの中において非常に大事なコンポーネントの一つであるため、Necoのメンバからメンテナを出すくらいの勢いで活動いたします。

おわりに

最後になりますが、Necoでは本記事で述べたような活動に興味のあるかたを絶賛募集中です。ご興味のあるかたは是非応募していただきたいと思います。

cybozu.co.jp

もちろんそれ以外の業務に興味のあるかたもお待ちしています。

*1:正確には一意に定まらないケースもあるのですが、ここでは割愛します

*2:すでにgithubのissueやRookのslackを介していくつかユーザサポートをしています