インフラはじめにこんにちは、Necoプロジェクトのsatです。NecoではKubernetes上のアプリケーションが使うストレージをCephによって提供すること、およびCephクラスタの管理にKubernetes上で動作するストレージオーケストレーターRookを使うことを決めています。本記事はNecoがなぜRook/Cephを選択したのか、Rookに対する現在のコミット状況、および今後のコミット方針について紹介します。CephやRookがどういうものなのかについては以下の記事をごらんください。blog.cybozu.ioblog.cybozu.ioなぜRook/CephなのかまずはNecoがなぜストレージをRook/Cephによって提供することにしたのかを簡単に書いておきます。CephNecoで提供するストレージには、既存のインフラで苦労した点を無くす、あるいは軽減するために次のような要件を定義しました。トラブル発生時に自分たちの手によって早急に問題を解決したい。サーバ一台に搭載できる程度の容量にとどまらず、数PB単位のデータを保持したい。ハードウェア障害の発生時やハードウェアメンテナンス時にサービスを継続したい。デバイスが壊れてもオペレータの介在なしにデータの冗長性を回復したい。ストレージデバイスの障害によってデータが壊れても自動検出/復旧可能したい。様々な候補の中から上記の要件を満たすものを調査したところ、Cephが適しているという結論に至りました。RookCephの機能は豊富なのですが、いざ運用するとなるときには一つ大きな課題があります。それはノードの追加/削除を含めた管理が難しいためにオペレータへの負担が大きいということです。この課題を解決する既存の方法があるかを調査したところ、Kubernetesを活用してCephクラスタを宣言的に管理するRookが候補にあがりました。幸いにもRookは必要な機能の多くが既に実装されており、かつ、コミュニティも活発であったことより採用することになりました。前節において述べたようにRookはNecoに必要な機能の多くを実装しているのですが、いくつか不足している機能もあります。Requestを送ることにしました。blog.cybozu.ioでは具体的にどのような機能を追加する予定なのかを簡単に紹介いたします。nameを使う現在RookがCephのOSDに使用するデバイスは/dev直下のものだけを指定できます。これには大きな落とし穴があります。ノードに/dev/sda,/dev/sdb,および/dev/sdcという3つのデバイスが存在しており、かつ、/dev/sdbをOSDとして使いたい場合を考えると、次のような問題が発生します。/dev/sdbが故障した状態でノードを再起動すると/dev/sdcは/dev/sdbとして認識されるデバイスが故障していなくてもハードウェアの設定変更やストレージデバイスの挿入位置などによってデバイスの認識順序が変わるつまり/dev直下に表示されるデバイス名はカーネルがデバイスを認識した順に適当につけたものであって、ハードウェアの構成変更によって変化しうる信用ならないものであるということです。この問題を解決するためにLinuxにはudevというデバイス管理ツールが存在します。udevを使えば各デバイスには例えばどのバス上にどのスロットに挿入されているかという位置情報をもとにした名前を付けられます。nameと呼ばれます。Requestも発行しました。現在は実装方針についてメンテナと議論中です。VolumeをサポートするRookは前節において述べたようにCephのOSDに使うデバイスとしてノード上のデバイス名を指定できます。1.1からは、KubernetesのPVCによって作成されるブロックボリューム上にOSDを作成できるようになりました。これによってユーザはノード上のデバイス構成を意識する必要が無くなったため、Rookの管理がさらに簡単になりました。SSDをPVCとして用途別に切り出せるようにしています。VolumeをPVCという形でCephに提供できるというわけです。Volumeである場合はうまく動かないという問題があります。Requestを発行してマージに向けて活動中です。Volumeサポートとは別に、致命的とも言える大きな問題があります。それは、耐障害性を最大限に高めるためにはOSDはすべてのノードに可能な限り均等に分散配置する必要があるものの、現状ではそれが困難であるというものです。前提として、Rookは1つのOSDに対して1つのPodを動作させます。Podが同じノードに配置される可能性もあります。Podしか置けないのです(詳細は以下リンクのコメントを参照)。Constraintsという機能です。この機能は、簡単に言うと特定のラベルが付与された沢山のPodをノード間やラック間で均等に分散配置するためのものです。Podに適用すると、上記の要件が達成できるというわけです。requestを発行しており、現在は実装方針についてメンテナと議論中です。Constraintsについての詳細はKubernetesの公式ドキュメントやチェシャ猫さんのドキュメントをごらんください。Maintainer"という機会を利用して、Rookのメンテナと会ってきました。events19.linuxfoundation.orgkccncna19.sched.comこのときに我々(Neco)は自社(サイボウズ)の次期インフラにおいてRook/Cephを使うことにしたこと、および、次期インフラが存在する限りアップストリームのRookに機能追加やバグ修正をし続けることを伝えました。Requestのレビューなどにおいて可能な限り協力することも伝えました*2。Rookコミュニティには開発者の人的資源が不足しているらしく、我々の申し出は非常に歓迎されました。今後はメンテナに表明したことを有言実行すべく、引き続きRookコミュニティのよき一員として、機能追加やバグ修正などの貢献をしていく予定です。RookはNecoの中において非常に大事なコンポーネントの一つであるため、Necoのメンバからメンテナを出すくらいの勢いで活動いたします。おわりに最後になりますが、Necoでは本記事で述べたような活動に興味のあるかたを絶賛募集中です。ご興味のあるかたは是非応募していただきたいと思います。cybozu.co.jpもちろんそれ以外の業務に興味のあるかたもお待ちしています。こんにちは、Necoプロジェクトのsatです。こんにちは、Necoプロジェクトのsatです。本記事では...2019-11-08Kubernetesでローカルストレージを有効活用しようこんにちは、Necoプロジェクトの池添(@zoetro)です。cli-kintoneのテス...こんにちは。プロダクトセキ...こんにちは!Cy-PSIRTの田口です。プロダクトセキュリテ...2024-11-05kintoneライターチームのチームビルディング開...こんにちは。テクニカルライターチームのueです。引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。