こんにちは、Necoプロジェクトのsatです。Necoではストレージ基盤として分散ストレージソフトウェアCephを使う予定です。その情報収集のために現在わたしはCephalocon 2019 BarcelonaというCephについての大きなカンファレンスに参加しています。Cephaloconは今日と明日の2日間にわたって開催されるため、2日に分けて本イベントの様子を報告いたします。
Cephaloconは2日後に始まるKubeCon + CloudNativeCon Europe 2019と同じ場所で開催されています。KubeConについても毎日レポートする予定です。
Cephaloconの参加者は開発者やユーザなどを合わせて合計数百人程度です。それぞれOSディストリビュータ、クラウドベンダ、およびストレージベンダなどさまざまなバックグラウンドの人たちが集まっています。
Cephについてまったくご存じないかたは、以前このブログにおいて簡単に紹介した記事を事前にいただくと本記事の内容を理解しやすいかと思います。
では、ここからは本日わたしが参加したセッションのうち、印象に残ったものを紹介いたします。
Keynote: State of the Cephalopod - Sage Weil, Co-Creator, Chief Architect & Ceph Project Leader, Red Hat
オープニングセッションはCephのオリジナル開発者であるSage Weil氏によるキーノートでした。Cephとは何かから始まって、その後に、ここ数年の間に出たバージョンに取り込まれた様々な機能を紹介しました。
ここでCephのバージョンについて説明しておきます。現在Cephは9か月ごとに新バージョンが出るようになっています。各バージョンにはコードネームがついています。名前はアルファベット順になっていて、それぞれ頭足類(イカやタコ)にちなんだ名前がついています。なぜ頭足類かというと、CephがCephalopod(英語で頭足類の意)にちなんで名づけられたものだからです。ここ数回のバージョンにはLuminous,Mimic,Nautilus(現在の最新版)という名前がついています。
ダッシュボードはWebベースでCephの管理をするツールです。以前からCeph本体とは独立した形で存在していましたが、Luminousから公式のダッシュボードが導入され、それがさらにMimicにおいて新たに作り直されて今の形になりました。ダッシュボードについての詳細はこちらをごらんください。
Cephは複雑なソフトウェアなので、そのまま使うには管理コストが高いです。このため、Cephの管理を楽にするためのさまざまなオーケストレーターが存在します。ここではceph-ansible, Ceph本体に取り込まれているdeapseaやシンプルなssh orchestrator、およびKubernetes上で動作するRookなどを紹介していました。
Cephは設定項目が大量にあるため、それぞれを適切に設定するのにユーザは頭を悩ませてきました。その最たるものがPlacement Group(PG)というものの数です。Cephの各RADOSオブジェクトがどのOSDに配置されるかは、オブジェクトが属するPGによって決まります。このPGの適切な数を決めるのは次のような理由によってユーザの大きな負担になっていました。
- 適切な値を管理者が自分で見積もらなくてはいけない
- 見積もりが難しい
- 不適切な値を設定すると性能が劣化したり、OSDごとに配置されるデータ量の不均衡が発生したりといった問題が起きる
この問題を解決するためにNautilusにおいてはPGの数をCephが自動的に決めてくれるPGオートチューニング機能が追加されました。
今後もCephにはさまざまな機能が追加されたり、性能が向上したり、設定が容易になったりしていくことでしょう。
Day 2 Operations : Make Friends with Your Ceph Cluster - Adrien Gillard, Pictime Groupe
このセッションは長年Cephクラスタを運用してきた発表者が自身のノウハウを共有してくれるというものでした。各種デバイスやdaemonが正常に動作しているかを確認しておくべきということ、および、それには具体的にどのようなコマンドやツールを使えばいいかといったことが具体的に述べられました。ログレベルを変える方法やそれを一か所に集約する方法などについても述べていました。
バージョンアップについての話題もありました。クラスタを特定バージョンに固定して塩漬けにするのではなく、最新バージョンほど機能が高く性能もよくなり、使い勝手もよくなっているため、継続的にバージョンを上げることがよいというメッセージを発信していました。その際はリリースノートを注意深く読んで、書いてある手順通りにアップグレードをすることを口を酸っぱくして言っていました。発表者の苦労が偲ばれます。
このセッションにおいては「得た知見をみんなに共有しよう」と言っていたのがとくに印象的でした。まさに有言実行なので素晴らしいですね。
Object Bucket Provisioning in Rook-Ceph - Jonathan Cope & Jeff Vance, Red Hat
本セッションはKubernetesにオブジェクトストレージを管理する機構を追加するという話でした。Kubernetesはファイルシステムやブロックデバイスをプロビジョニングしてpodから使えるようにする方法をPersistent Volume(PV), Persistent Volume Claim(PVC)というしくみを使って実現しています。しかし、オブジェクトストレージについてはこのようなしくみが存在しないため、管理が面倒です。
発表者のアプローチは、Kubernetesのカスタムコントローラやカスタムリソースを作ることによってオブジェクトストレージのバケットをプロビジョニングするというものでした。カスタムリソースはPV,PVCに倣ってObject Bucket(OB), Object Bucket Claim(OBC)という名前になっています。
発表のタイトルどおり、OBやOBCはもともとRookで使うために出てきたアイデアなのですが、Rook以外にも使えそうなのでいずれはKubernetes公式機能として取り込みたいということでした。
Making Ceph Fast in the Face of Failure - Neha Ojha, Red Hat
本セッションはCephクラスタ上のストレージデバイスが故障した状態からのリカバリ処理についてのものでした。デバイス故障からの復旧は直観的には速ければ速いにこしたことはなさそうなのですが、事はそう単純ではありません。
ストレージデバイスが故障したとき、当該デバイスに存在するRADOSオブジェクトの冗長度を回復するためには、当該データを他のOSDにコピーしなければなりません。このリカバリ処理においてはI/Oが発生するため、リカバリ処理が動いている間はクライアントI/Oの性能が低下します。ここでリカバリ処理を高速に終わらせようとすると、この処理のためのI/O負荷が高くなり、それだけクライアントI/Oの性能劣化が激しくなってしまいます。
発表者はリカバリ処理におけるクライアントI/Oの性能劣化が最新から数えて6つ前のバージョンであるHammerから最新版であるNautilusまでにどのように改善してきたかについて、性能測定結果だけでなく、技術的になぜそうなったかについて述べました。
Hammerにおいてはリカバリ処理に対する制限はほぼ何もつけられなかったのですが、Luminousにおいて、一定量リカバリ処理が走ってからはしばらくしてからでないと次のリカバリ処理が動かないというスロットリング機能が入りました。
Mimicではリカバリ処理が非同期処理になりました。どういうことかというと、一つ前のバージョンのLuminousまでは、あるRADOSオブジェクトのリカバリ処理が動作している途中に当該オブジェクトへの書き込み処理が発生した場合、この処理はリカバリ完了まで待たされていました。それに対して非同期リカバリの場合はこのような待ちが無く書き込みができるようになりました。この機能はNautilusになるとさらに洗練されました。
今後もこのような改善は続く見込みです。
