こんにちは、Necoチームのsatです。昨日に続きCephalocon Barcelona 2019のレポートをいたします。
一日目については以下記事をごらんください。
Keynote: What's Planned for Ceph Octopus - Sage Weil, Co-Creator, Chief Architect & Ceph Project Leader, Red Hat
昨日に引き続きCephの生みの親であるSage Weil氏によるキーノートです。昨日はCephのこれまでと現状についてが中心でしたが、ここでは将来Cephがどのように変化していくかについて述べられました。
ユーザビリティの面ではRookやsshによるオーケストレータに力を入れること、すべての操作をCLI経由でできるようにすること、ダッシュボードで操作できることを増やすこと、ドキュメントを充実させること、アップグレードを容易にすることなどが挙げられました。ドキュメントについては数か月前に発足したCeph Foundationを通じて探しているようです。これまでCeph Foundationは活動実態が謎だったのですが、初めてどういう活動しているかの一端が見えました。
品質面では主にデータ収集、とくにクラッシュ時のレポートの充実、および、これらの機能を使うようユーザに推奨することに力を入れるとのことです。これによってユーザからも、およびユーザからトラブル報告を受けた開発者たちがトラブルシュートするのが楽になることでしょう。
機能面ではCephクライアントから見たサービスレベルを制御するRADOS QOSや、高速なデバイスの性能を引き出すためのCrimsonというストレージバックエンドを取り込む予定だということを述べました。
CRUSH-ing the OSD Variance Problem - Tom Byrne, Storage Sysadmin
このセッションの発表者はRutherford Appleton Laboratory (RAL)が使っているechoと呼ばれるCephクラスタの管理者です。その彼がechoの運用を通じて得たOSD間のデータの分散について知見を共有してくれました。echoは総容量40PB、現在の使用データ量が20PBという巨大なクラスタです。
セッションの前半ではCephクラスタの見かけ上の空き容量と実質的な空き容量についての説明をしてくれました。CephはどのRADOSオブジェクトをどのOSDに配置するかをCRUSHというアルゴリズムによって決めています。これによってデータはすべてのOSDにおおよそ均等に配置される…かというと話はそう単純ではありません。
各OSDに配置されるデータ量はおおよそ正規分布しています。その平均値はおおよそ以下のように理想的になります。
OSDごとの平均データ量 = クラスタの総データ量 / OSDの総数
この値が正規分布するということは、OSDによってデータ量の多寡があるということです。クラスタの総空き容量は十分なのに個々のOSDがいっぱいなため、それ以上のデータの追加が失敗する、つまり実質的な空き容量は理想的なものより少ないという事態が発生するのです。この実質空き容量はOSDごとのデータ量の分散が小さければ多くなり、大きければ少なくなります。
セッションの後半では、echoにおいてこの分散をいかに小さくするかという闘いの記録を共有してくれました。彼はまず従来から存在するOSD rewrightという仕組みをを使いました。これはOSDごとにどれだけのデータを保持するかの重みを設定するというものです。weightが大きければ配置するデータ量を多くして、小さければデータ量を少なくします。
これを利用してOSDごとの配置データ量を定期的に監視しておき、量が多いOSDについてはweightを低くして少ないOSDについてはweightを大きくする…といった処理をすれば分散が小さくなるとというのが狙いです。ただしこの方法はそれほどうまくいきませんでした。
続いて彼が試したのはLuminousから導入されたPG upmapという機能です。この機能は特定のPGに属するデータを特定のOSDに配置するというものです。これによってオブジェクトを空き容量が多いOSDに狙って配置するというわけです。このPG upmapは実によく働いて、最終的にechoは実質空き容量を6PB増やせたとのことです。OSDごとのデータ量の分散が、とくに大きなクラスタにおいて、いかに大きなインパクトがあるかがわかります。
Geographical Redundancy with rbd-mirror: Best Practices, Performance Recommendations, and Pitfalls - Florian Haas, City Network
このセッションはrbd mirroringと呼ばれるrbdのリモートレプリケーション機能についてのものでした。
rbdにおける書き込みは通常次のような順で動作します。
- クライアントが書き込み依頼をする
- プライマリOSDに書き込みをする
- それ以外のレプリカを保持するOSDに書き込みをする
この処理は同期的に前から順番に実行します。
レプリケーションを実行するためにまず思いつくのはCRUSH ruleによってOSDのレプリカを複数のサイトに配置するように制約をかける方法です。これによってどこかのサイトが使えなくなったときでもすべてのデータについてのレプリカは別のサイトに存在する、というわけです。ただしこの方法は現実的ではありません。とくにそれはサイト間の距離が長いほど顕著です。
なぜかというと書き込みにおけるレイテンシは物理的な制約によってサイト間距離にしたがって長くなるからです。上述の通り書き込みは同期的なことより、レプリカ数が増えればレイテンシはさらに長くなります。このため、たとえば数百km離れた場所へのリモートレプリケーションは書き込み性能が(読み出しもですが)実用不可能な性能になるでしょう。
このような問題を防ぐために、Cephにはリモートレプリケーションのための専用機能があります。このためにはローカルサイトとリモートサイトに別々のクラスタを用意します。ローカルクラスタへの書き込みにおいては上述の書き込みパスに加えて、ステップ2の段階でジャーナルログにもデータを書き込みます。その後メインの書き込みパスとは非同期的にジャーナルログからリモートクラスタに書き込みをするというわけです。この方法を使えばレプリケーション処理はローカルクラスタに対する処理を邪魔しません。
ただしこの方法にも落とし穴があります。ジャーナルログからリモートクラスタへの書き込みそのものの性能インパクトは少ないのですが、ローカルサイト上の書き込みが通常のものに加えてジャーナルログにも書き込むことより、書き込みに余計に時間がかかってしまうのです。この性能インパクトが馬鹿になりません。
このことより発表者はリモートレプリケーションは安易に使うものではなく、定期的にrbdイメージのスナップショットをとってリモートサイトに転送したり、あるいはリモートレプリケーションを使うにしても何も考えずにクラスタ全部のデータをレプリケーション対象にするのではなく、大事なデータだけを対象にすべきということを述べました。
総評
CephaloconはCephがもともとニッチなソフトウェアであることもあって数百人程度の規模なのですが、個々のセッションを見るとOpen Source SummitやKubeConに負けず劣らずの盛り上がりを見せていました。また、絶対的なユーザ数が少ないこともあってか、開発者同士だけではなく開発者とユーザの距離が非常に近いというのも大きな特徴でした。このようなことは実際にイベントに参加しないと肌感覚としてなかなかわかりにくいので、今回参加した価値は大いにあったとと思います。今後もCephコミュニティがこのような雰囲気を保持しつつ、ますます活発になっていくことを願います。
