Nova最新動向：スコープを広げず安定性と機能性を追求

NovaはOpenStackの中心に位置するプロジェクトであり、「Nova無しにOpenStackと言うことができない」ほど重要なものになっています。OpenStack Summitに合わせて公開されたユーザサーベイ^※1でも、Novaが最も使われているプロジェクトであることがわかります。

※1: （出典: OpenStack User Survey October 2015）

このようにOpenStackの中で最も重要なNovaですが、現在のNova PTLであるJohn Garbutt氏は、「Novaプロジェクトの重要なミッションは、Novaのスコープを拡張しすぎないことだ」と言います^※2。スコープの拡張は、Novaからのスピンアウトで行えばよく、Novaとしてはより堅牢で安定した基盤としてOpenStackを支えるのだ、という意思が感じられます。そのため、Novaに対する機能追加が多く提案されていますが、スコープ拡張につながるものは受け入れられにくい状況になっています。Novaのデザインサミットでも、新機能よりは既存課題の解消方法、既存機能の改善方針などについての議論が多くなされました。

※2: Stop Scope Creep（出典: OpenStack Nova Project Update）

以降、カンファレンスやデザインサミットでのNovaに関するトピックを解説します。

APIに関する話題

Libertyでは新しくmark host downというAPIが追加されました。このAPIをたたくと、即座にホストを強制的にダウン状態にすることができます。

Novaには、各ホストのヘルスチェックを行い、無応答な状態が続くとそのホストをダウン状態にするというヘルスチェック機能がありますが、検出時間は比較的長めです。HAという観点で見ると、障害が起きたホストは即座に切り替えたいという要望があります。OpenStackとは別のHAツール（例えばPacemaker）でホストを監視すれば障害を素早く見つけることはできますが、Nova側ではホストがダウン状態とは認識していないため、ダウンしているホストに新たなVMが割り当ててしまうというケースがありえました。

今回、mark host downのAPIができたことで、外部ツールを使って故障を検出したら、Novaにはmark host down APIで通知することでNovaの動作としては一貫性を保ちつつ、即座にフェイルオーバーするといったことが実現できます。特にNFVのように高可用性を求めるユースケースで効果を発揮するでしょう。

外部HAツールに有効（出典: OpenStack Nova Project Update）

デザインサミットでは、MitakaでのAPI改善について議論^※3が行われました。これまでNovaはEC2互換APIをサポートしてきましたが、長い間メンテナンスがされておらず現在非推奨になっています。また、独立コンポーネントとしてec2-api^※4ができたため、「いつEC2互換APIのコードをNovaから削除するか」という議論が行われました。結論としては、既存ユーザー、オペレーターに問い合わせた後で削除する、ということになりました。EC2互換APIを利用している方はec2-apiコンポーネントの利用を早めに検討した方がよいでしょう。

NovaはOpenStackの中で最も大きなプロジェクトであり、多くのAPIを実装しています。しかし、APIドキュメントの整備が不十分であり、「API利用者はNovaのソースコードを読まなければならない」という課題があります。その結果、正しいAPIの使い方をしていないユーザーが多くいることがLibertyの開発期間中に分かってきました。デザインサミットでは、「APIドキュメントの整備が必須」という共通認識がなされ、OpenStack共通のAPIドキュメント形式として採用が決まったSwagger[5]で実装していくことになりました。SwaggerはAPI仕様を表現するフレームワークであり、Swagger定義と呼ばれるAPI仕様から、ドキュメントやクライアントコードなどを生成できます。これにより、高品質なAPIドキュメントを生成できるようになることが期待されています。

※3: https://etherpad.openstack.org/p/mitaka-nova-api

※4: https://github.com/openstack/ec2-api

※5: http://swagger.io/

エラーハンドリングの改善

OpenStackの仮想マシンに対して時間がかかるアクションを実行した際、実行状況を把握する方法として、os-server-actions APIがあります。しかしこのAPIは「実行ノード側で起きた障害を通知できない場合が多い」という課題があります。また、「通知機能の利用方法も一貫性がなく使いにくい」という課題もあります。

この状況を改善するため、エラーハンドリングとアクションの実行状況通知のあるべき方向性や設計について議論が行われました。これらの改善が行われると、

• 実行可能なアクションの通知
• 実行中アクションの中断

などユーザー、オペレーターにとって有用な機能ができることになります。

Liberty開発サイクルでは、ライブマイグレーション機能の状況提供、中断機能APIが提案されていましたが、ライブマイグレーション専用で汎用性がなかったため、機能開発が進みませんでした。今回のデザインセッションでの議論をきっかけにして、エラーハンドリングのフレームワークが整備されると、多くのアクションに対応し一貫性もある状況通知が実装されていくと期待できます。

Cells

Cells v2については、前回のバンクーバー・サミット（2015年5月）での議論の結果として、Libertyリリース（2015年10月）で単独Cell構成を完成させ、その後のリリースにおいて複数Cell構成を実現するということでした。しかし、Libertyリリースにおいては、DBテーブルの追加やオブジェクトの追加など一部の実装が実施されましたが、単独Cell構成の実装までは完了しませんでした。Cells v2は引き続きMitaka向けにも重点項目として開発されることになりました。

Cellsとは、大規模なOpenStack環境を構築するための機能で、CERN、eBayなどで実際に使われています。OpenStackでノード数を増やしていくと、DB、メッセージキュー、ノードへのヘルスチェックなどのボトルネックが出てくるため、数100ノードで限界が来ると言われています。そこで、Novaと周辺コンポーネントをCellというまとまりにし、その上にAPIを受け付けるTop Cellをおいてツリー構造にしたのがCellsです。今回のCERNのセッションでは、Cells v1を使ったシステムの詳細が説明されました^※6。CERNでは約5000のComputeノードを26のCellに分割して運用しています。Cellあたり200Computeノードが目安になるそうです。Cellsを使うことで、このような大規模のOpenStack環境を、一つのAPIエンドポイントで見せることが可能になっています。

※6: （出典: Unveiling CERN Cloud Architecture）

しかし、Cells v1はnova-cellsという独自コンポーネントを必要とし、それがNovaの進化についていけないという問題やNeutronやCinderとの連携ができないなど様々な制限事項がありました。そのため1年ほど前からCellsをどうしていくかという議論があり、結論としてCells v2を作り、Cells v2自体をNovaのデフォルトにすることになりました。つまり、Nova自体がnova-cellsを取り込み、通常の使い方はCellが一つしかない状態という見え方になります。今回のサミットの議論の結果としては、Cells v2はMitaka Priorityに入り、NovaコミュニティとしてMitakaリリース（2016年4月リリース予定）に向けて優先度を高くして取り組むということになりました。また、複数Cell構成ですが、Mitakaの次のNリリースで実現し、Cells v1からCells v2への移行についてはNリリースよりも後に取り組むというようなロードマップとなりました。

（出典: OpenStack Nova Project Update）

Scheduler

Novaのスケジューラについてデザインサミットで議論が行われました。フレーバーの解体（flavor decomposition）の議論や、Novaスケジューラの課題、例えばnova-schedulerとnova-computeの持つリソースの情報等にはリトライやタイムラグ等により差が生じる時があることや、SSDやGPUを考慮したスケジューリングが必要ではないかといった意見が出ました。スケジューラはユーザが自分たちの環境やポリシーに合わせてチューニングしたり独自のスケジューラを開発することがままあります。コミュニティではユーザの経験や課題を踏まえて、コミュニティとしてどのようなスケジューラを開発していくべきかを議論しています。Mitakaリリースに向けて今後とも議論を継続することになりそうです。

他プロジェクトの機能強化への対応

NovaはOpenStackの中心にあり、他プロジェクトとのやりとりが最も多いと言えます。そのため、他プロジェクトで機能を追加しようとすると、Novaにも対応が必要になることがままあります。今回のデザインサミットでは、以下のような項目について議論され、実装が進むことになりそうです。

• Nested Quota Driver
  KeystoneのHierarchical multitenancy機能（プロジェクトの階層構造）に対応したクォータ機能。
• Nova Image Signature Verification
  Glanceの署名された(signed)イメージを検証する機能。
• Attach/Detach Filesystem API
  Manilaによって提供されるファイルシステムをCinderボリュームのようにアタッチ／デタッチする機能。
• Ceph RBD instance snapshots
  RBDスナップショットの機能を使用したVMインスタンスのスナップショット機能。

まとめ

NovaはOpenStackの中心として今後も開発がされていくでしょう。PTLのJohn Garbuttが強調していたように、だからこそ安定して動作し、APIの設計を慎重に行い、健全でオープンなコミュニティを作る必要があります。Novaはコード規模が拡大し続けており、レビューが追いつかないという課題があります。ここにきてIronicやMagnumを別プロジェクトとして切り出し、スコープを広げないことで、この傾向も歯止めがかかってきたように見えます。エンジニア、プログラマは、新しい機能を作りたいという本能を持っていると思います。しかし、それをあえて押さえて、OpenStackを支える役割を果たそうとしているとも言えます。大きな話題になるような新機能は無いかもしれませんが、Novaのプロジェクトがどう運営されていくかはOpenStack全体にとって重要なポイントであり続けると思います。

編集部より：出典を明記するように修正しました（2015/12/22）