はじめに
こんにちは、ストレージチームの大神です。ストレージチームでは様々なOSSを用いて新しいストレージインフラの開発・運用を行っています。OSSを使っていく上でいつどんな機能追加やバグ修正を取り込むかを決める「アップグレード戦略」を立てる事は重要です。サイボウズでは基本的にリリースごとにリリースノートの内容から変更点をチェックし、緊急のものがあれば即座にバージョンアップし、そうでなければ月一程度の頻度でバージョンアップしています。ここまでは比較的一般的なやり方ではないでしょうか。ストレージインフラに使用しているCephとRookについては、さらに一歩踏み込んだアップグレード戦略を行っており、本記事ではCephのアップグレード戦略について紹介します。
アップグレード戦略の概要
OSSは基本的にGitHubやメーリングリスト等で開発や議論が進むため、これらを定期的にチェックする事により最新情報が得られます。Cephについては以下の様な手段で開発が進みます。
ストレージチームでは上記全ての情報を毎日チェックしています。流量は時期によりまちまちですが、全て合わせると日に100件程度のチェックを行っています。この結果、重大な不具合や機能追加を早期発見し、必要ならば公式リリースを待たずにサイボウズの独自パッチとして適用することもあります。
上述の更新を全て隅から隅まで確認するのは大変なので、以下の様な手段を用いてチェックを効率化しています。
- サイボウズのストレージシステムの運用に関わるもので、かつデータ破壊やロスト等の重大な問題に関するもののみ確認を行う
- 明らかに自分たちの対象外である事が分かるキーワードをリストアップしておき、そのキーワードについてのみの話であれば読み飛ばす
- 本文を読む際も全てを隅から隅まで読むのではなく、全体をざっと読んで自分たちに関係ありそうか否かを判断する
- 該当するものの中でも緊急であると思われるものを優先して読む
- 余裕があれば緊急でないものも読んでおくと良い。他のチケットやIssue/PRを見たときに関連に気づけたりすることがある
実例
本節では、上記の取り組みで問題を早期に修正できた事例を紹介します。
バージョンアップ等でCephが管理するストレージデバイス(OSD)を停止する際、10～20秒程度I/Oが止まる現象を確認していました。このときはインフラ上のサービス提供に影響が出てしまうことに加えて、バージョンアップのたびにサービスを提供するチームに事前告知をしていました。
そのような折に、メーリングリストをチェックしていた所、OSDが自身の停止を、Cephクラスタ全体の整合性を保つためのモニターというサービスへ明示的に伝えるか否かを設定するパラメータが存在することがわかりました(デフォルトはoff)。このパラメータがonの場合はOSDが自ら停止した場合は即座にこの情報がモニターに伝わり、I/Oの停止時間が短くて済みます。これに対してサイボウズのCephクラスタのようにパラメータがoffになっていると、OSDが自ら停止した場合であっても異常終了した場合と同じくモニターはしばらくOSDの停止を認識できず、長時間I/Oが止まってしまうというわけです。
この事について議論しているPR上で「デフォルトでonにすべきでは？」と問い合わせた所、「確かにそうであり、PRを作ってくれないか？」といった回答を得られたため、PRの作成を行いました。
この修正はのちに他のバグ修正PRに取り込まれるかたちでマージされました。サイボウズで運用中のCephバージョンへもバックポートされ、無事に適用されました。
おわりに
公式の情報を積極的に収集する事によるアップグレード戦略の概要と、それにより問題を早期に修正できた事例を紹介しました。このように公式の情報を収集することで、他にも、障害調査のノウハウが溜められたり、公式の開発状況が見えたりする効果もあります。サイボウズではこのような積極的な情報収集によるアップグレード戦略を今後も行っていきます。
最後になりますが、ストレージチームでは一緒に働いてくれるかたを募集中です。ぜひ一度下記の募集要項をごらんください。
