Nova最新動向：スケジューラ、セル、ライブマイグレーションの改善は継続、他のプロジェクトとの連携が課題に

はじめに

今回のAustinサミットでは、以前のデザインサミットから議論されているCells v2、スケジューラ、ライブマイグレーション、APIのセッションが引き続き行われました。今回のサミットでは、前回までのデザインサミットと異なり、他のプロジェクトとのジョイント・セッションが多かったことが特徴として挙げられます。以下に、議論のあったそれぞれの項目について解説します。なおデザインサミットでの議論はEtherpadにまとめられています。Novaについては、https://wiki.openstack.org/wiki/Design_Summit/Newton/Etherpads#Novaを参照ください。

Cells v2

https://etherpad.openstack.org/p/newton-nova-cells

セルとは、大規模なOpenStack環境を構築するための機能です。Novaとその関連コンポーネントをセルというまとまりで管理し、従来ボトルネックであったDBやメッセージキューをセルごとに分離することで、コンピュート・ノード（VMインスタンスが配置される物理サーバ）を数千台以上の規模までスケール可能です。また、APIリクエストを受け付けるAPIセルを上位に設けることで、大規模な環境を1つのエンドポイントから操作できます。

Cells v2のアーキテクチャ（コア開発者Andrew Laski氏の講演資料［※1］から抜粋）

※1 https://www.openstack.org/videos/video/nova-cells-v2-whats-going-on

コミュニティでは、従来のCells v1を改良したCells v2をKiloサイクルから開発しており、Mitakaリリースでは下準備となる機能が開発されています。Cell v2は、Newtonサイクルでのリリースに向けて、引き続きNovaの重点開発項目として設定されました。今回のサミットでも、一般講演やデザインサミットで活発に議論が行われました。

Mitakaリリースまでの開発状況ですが、トップセルに配置するnova_apiがnova DBから切り出され、nova DBのマイグレーションのための機能・ツールがマージされました。今回のデザインサミットのセッションでは、Newtonでのリリースに向けた残りの作業項目（AMPQミドルウェアのスイッチング、データベース・スキーマの整理など）が整理されました。その他、nova-networkを使用している場合のセル追加時の挙動や、セルをまたがった検索・ソート結果の「pagination」、アップグレードについても議論が行われました。Cells v1からCells v2へのマイグレーションの手段も提供される予定とのことです。

スケジューラ

https://etherpad.openstack.org/p/newton-nova-scheduler

現在、Novaの一コンポーネントであるスケジューラを、REST APIを備えた汎用的なモジュールとして切り出そうという取り組みが行われています。

今回のサミットでは、スケジューラ切り出しに向けたNewtonサイクルでの大きな取り組みとして、リソース・プロバイダーおよびリソース・プールが取り上げられ、デザインサミットでは時間枠を2つ使って活発な議論が行われました。リソース・プロバイダー、リソース・プールは、コンピュート・ノードが備えるリソース（CPU、メモリ、ストレージなど）を、より柔軟に定義・管理する機能です。この機能を使うことで、GPUなどを含んだ多岐にわたるリソースの管理や、従来誤認識されていたノード間の共有リソース（共有ストレージなど）の適切な管理が実現可能になります（従来のOpenStackでは、コンピュート・ノードが共有ストレージを利用している場合、ストレージ容量が正しく認識されず、各ノードごとにその容量が利用可能であると認識されてしまう問題がありました。リソース・プロバイダー、リソース・プールの機能は、この問題を解決する手段としてコミュニティで期待されています）。

デザインサミットでは、まずMitakaリリースまでの取り組みとして、リソースを定義するリソース・クラスと、データベース・テーブルの変更方針が紹介されました。その後、実際にリソースを定義するデータベース・テーブルについて、リソースとして定義されるべきハードウェアの種類と、それらを汎用的に定義可能なスキーマに関する議論が行われました。また将来的なスケジューラの切り出しに向けて、リソース情報を取得するインタフェースやVMインスタンスの配置先のコンピュート・ノードを取得するインタフェースを、現在のRPCからREST APIへ変更する方向性も確認されました。

一方で、リソース管理とは別のトピックとして、既存の仕組みを改良する「Shared-state scheduler」の提案も行われました。現状では、コンピュート・ノードがコンダクタと通信してデータベースを更新し、スケジューラがそのデータベースの情報をもとにスケジューリングを行っていますが、データベースを介さずに直接コンピュート・ノードとスケジューラでコンピュート・ノードのリソースの情報をやり取りすることにより、スケジューラでのキャッシュ・リフレッシュ処理によるパフォーマンス低下の問題を解決しようとする提案です。

ライブマイグレーション

https://etherpad.openstack.org/p/newton-nova-live-migration

ライブマイグレーション機能は、引き続き取り組まれているトピックです。Mitakaサイクルでは、本機能の使いやすさを向上するため、APIパラメータや設定オプションの簡略化が行われました。Newtonサイクルでは、移動先コンピュート・ノードがスケジューラのルールを満たしていることを確認する機能の追加といった、さらなる使い勝手の改善とともに、機能品質向上のためのCIカバレッジ強化などに取り組むこととなっています。

機能追加の面では、リサイズおよび（コールド）マイグレーションにおいて、従来のsshではなくストレージ・プールを使用したデータ移行機能の利用が提案されました。また大きな機能として、マイグレーション完了までマイグレーション元のVMにワークロードを維持する従来のプレ・コピー・ライブマイグレーションに加えて、マイグレーション先にワークロードを移行するポスト・コピー・ライブマイグレーションの機能追加が提案されました。本機能については、マイグレーション時間短縮などの利点とともに、エラー発生時の切り戻しの考え方など、注意すべき項目がいくつか議論されました。これらの機能については、Newtonサイクルで取り組むことが決定しています。

サミット会場でのイラストが書かれたオブジェクト

他のプロジェクトとのインテグレーション

OpenStackの中核コンポーネントであるNovaは他のコンポーネントとの連携が重要視されており、他のプロジェクトの開発者と合同で議論するインテグレーションのセッションが開かれます。前回のサミットではCinderとIronicの2つのジョイント・セッションだけでしたが、今回は、Neutron、Cinder、Glance、Ironic、Keystoneといったコアコンポーネント5つとOpsを合わせた計6つのジョイント・セッションが開かれました。

Neutron

https://etherpad.openstack.org/p/newton-nova-neutron

NovaとNeutronの連携では、大きなトピックとして次の3点が議論されました。

1. Neutron Routed Network

現在、Neutronのチームでは大規模な構成への対応に向けて、ラック単位にL3スイッチを設けてL2ネットワークセグメントを分離し、ブロードキャストドメインを分離する構成を実現するための機能開発が行われています。今回のサミットでは、本機能の実現にむけた、L2セグメントを意識したNovaのスケジューリングなど、Novaに修正が必要な個所についての議論・確認が行われました。今後、この機能はスケジューラの機能開発と合わせて、コミュニティで実装が進んでいくこととなりました。

2. VMインスタンス作成時のネットワーク自動割り当て（Get me a network）

現在のOpenStackでは、VMインスタンスの作成（boot）時にネットワークを指定しなかった場合、利用可能なネットワークを自動で割り当てるか、利用可能なネットワークがなければネットワークの割り当てを行わないという動作となっています。本機能は、利用可能なネットワークがない場合に、自動的にネットワークを作成して割り当てる機能です。セッションではエラー時のふるまいについて議論がありました。

3. nova-networkの廃止

nova-networkは、初期のOpenStackにおいてVM間のネットワークを管理するための標準的なコンポーネントでしたが、現在ではNeutronがネットワーキングの標準となっており、nova-networkの廃止は数サイクル前からコミュニティ内で決定されています。しかし廃止は決定したものの、既にnova-networkを用いて環境を構築したユーザ向けのNeutronへのマイグレーションパス提供など、コミュニティとして解決すべき課題がいくつか存在したため、廃止が進んでいませんでした。

今回のサミットでは、nova-networkの廃止に向けた具体的な課題やスケジュールについての議論が行われました。課題についてはNovaのnova-networkに関するAPIとNeutronのAPIの差分や、nova-networkとNeutronの機能の差分が洗い出されました。スケジュールについては、Newtonサイクルから廃止の作業を始めて、完了期限は特に定めないことが決定されました。

Cinder

https://etherpad.openstack.org/p/newton-nova-cinder

NovaとCinderの連携の改善については、Austinサミット前から個別のIRCミーティングが開かれるなど、コミュニティとして非常に関心度が高いトピックとなっています。今回のデザインサミットで議論の中心となったのは、ボリュームのマルチアタッチ機能です。この機能は、1つのCinderボリュームを複数のVMインスタンスにアタッチできる機能で、共有ストレージを使ったDBのHA構成など、いわゆる「レガシー」なシステム構成をOpenStackに移行する際に必要となる機能です。

Nova、Cinderプロジェクトの双方で、この機能のユースケースや重要性が議論され、機能の必要性が合意されました。機能の実装方式についてはいくつかの候補が挙げられ、そのうち一番有力であったCinderで抽象化ボリュームを実装する方式について、Cinderのコア開発者がPoCを行ったうえで、今後の詳細な実装を詰めていく運びとなりました。また機能開発と並行して、機能の品質を担保するために、マルチノードのCinderのマイグレーション操作のCIジョブを追加することなどが決定されました。

Glance

https://etherpad.openstack.org/p/newton-nova-glance

Glance v1からv2 APIへの移行に際し、APIの互換性などの移行にあたっての課題や移行方法について議論が行われました。移行方法については、v2 APIを使用するかどうかを決定するconfigオプションをNovaに導入することが決まりました。またコード品質の確保のため、CIにおいて、このオプションをTrueにしてGlance v1 APIを無効にした構成でのテストを導入することなどが話し合われました。

Keystone

https://etherpad.openstack.org/p/newton-nova-keystone

クォータ設定およびフレーバへのアクセス設定におけるプロジェクトID（テナントID）のバリデーション機能について議論がありました。現在のOpenStackでは、クォータ設定およびフレーバへのアクセス設定を行う際に、存在しないプロジェクトIDの指定が可能です。このバリデーション機能は、設定の際にプロジェクトの有無を確認し、存在しないプロジェクトIDであれば、設定できないようにしようという機能追加です。バリデーションの際のKeystone呼び出しにおける権限やエラー時の挙動、APIのマイクロバージョンについて議論が行われました。

Ironic

https://etherpad.openstack.org/p/newton-nova-ironic

現状のNova-Ironic連携で一番重要な機能として、テナント・ネットワークの分離が挙げられます。従来のIronicでは、フラットなネットワークのみサポートされていましたが、ベアメタルクラウドサービスなどのユースケースを踏まえ、テナント・ネットワーク（テナント毎に分離されたネットワーク）に対応させようという提案が、Ironicチームにて行われています。今回のサミットでは、この機能提案に関する議論が行われました。本機能はNewtonサイクルでの機能のマージが見込まれています。また複数のnova-compute対応や、Ironicのコンソール・サポートなどの改善についても議論が行われています。

Ops

https://etherpad.openstack.org/p/AUS-ops-Nova-maint

こちらは正確にはOps（運用者）セッションでNovaに関するセッションがあり、そこにOpsの人とともにNovaの開発者も参加して議論が行われた、ということになります。今回議論の対象となったのは、NFVのユースケースであり、NovaのComputeノードがメンテナンスの状態になったケースについて、具体的な課題とその対応策についての議論が行われました。

議論された課題の一例としては、ComputeノードのメンテナンスをVMインスタンスに通知する方法が挙げられます。本課題については、開発者からCeilometerのアラームを使用した方法などが解決方法の一例として提示されました。

OpenStack NovaのAPI

https://etherpad.openstack.org/p/newton-nova-api

APIについては、大きく以下の項目が決定されました。

v2.0 APIの削除

OpenStackのいくつかのプロジェクトでは、APIのマイクロバージョンが導入されています。マイクロバージョンは、APIのバージョンとして小数点以下のバージョン（2.1など）を指定可能にする考え方で、機能追加・改善の過程で、APIの一部に変更が加わった際に、マイクロバージョンが更新されていきます。Nova APIでは、現行のバージョン2のなかで、2.0から2.26までのマイクロバージョンが存在します。今回のサミットでは、最初のバージョン2 APIであるv2.0 APIについて、現在では利用しているユーザがほとんどいないことから、コードをリポジトリから削除することが決定されました。newton-1（2016年6月初旬）のマイルストンを目標に、作業を実施することも決定されました。

APIリファレンスの形式変更

OpenStackのドキュメンテーションチームにおける議論の結果、APIのリファレンスについて、現行のDocbookおよびWADLの形式から、より維持管理しやすいSphinx対応の形式（RST）への変換を行うことが決まっています。本セッションでは、ドキュメント形式のマイグレーション方法についての情報共有・議論が行われました。

ポリシー設定のコード化

現在、認可（ロールなどにより実行できるAPIを制御する）についてはpolicy.jsonで設定されており、デフォルト値も含めすべてそのファイルで定義されているため、分かりにくいといった課題があります。そのため、デフォルト値をコードで定義して、変更したいもの（差分）のみを設定する提案について議論がありました。まず、oslo.policyを修正する方向で進めることとなりました。

Newton開発サイクルでの優先度

https://etherpad.openstack.org/p/newton-nova-summit-priorities

Cells v2、スケジューラ、API（APIリファレンスの形式変更とポリシー設定のコード化）、ライブマイグレーション（Libvirtのストレージ・プールの利用）、OS-VIFライブラリ、「Get me a network」、Glance v2対応がNewton開発サイクルにおいて優先度が高い項目として決定されました。

デザインサミットのセッションが開催された部屋

初心者向けセッション

https://etherpad.openstack.org/p/newton-nova-getting-started

OpenStackでは、キーノートの際、コミュニティに貢献した人に起立してもらい拍手を送るなど、新しいメンバーがOpenStackコミュニティに加わってくることを奨励しています。近年のサミットでは、パッチの投稿の方法や、よりコア開発者に近づくためにはどうしたらよいか、というトピックを取り上げるセッションも行われています。

OpenStackの最古のコンポーネントとして保守的なイメージがあるNovaですが、今回のデザインサミットでは、そのイメージとは異なる取り組みとして従来にないセッションも開催されました。それが、初心者向けセッションの「Low-hanging fruit / getting started in Nova」です。どのような点でNovaへの貢献を始めることができるのかという点について議論が行われ、アイデアが出されました。

osloライブラリの新機能への対応、Python 3対応、ユニットテストなどのカバレッジの改善といったアイデアが挙げられました。また、開発の活性化のための開発状況のトラッキング方法やレビューの進め方についても議論され、今後も引き続きコミュニティ内でのプロセスの改善が行われていくものと考えられます。

Unconference／Contributors Meetup

https://etherpad.openstack.org/p/newton-nova-summit-unconferencehttps://etherpad.openstack.org/p/newton-nova-meetup

デザインサミットのセッションは、あらかじめPTLやコア開発者らによって各セッションで取り扱うテーマが決定され、スケジュールが会期前に決められます。一方で、セッションで扱うテーマに入らなかった項目について議論するのがUnconferenceであり、Contributors Meetupです。Cinderとのジョイント・セッションで話し合われたボリュームのマルチアタッチ（1つのCinderボリュームを複数のVMインスタンスにアタッチする機能）やバージョンド・ノーティフィケーション（Novaの外部に操作の開始・終了等を知らせるノーティフィケーションのペイロードが、リリースにより変更されることに対応するための仕組み）についての議論がありました。

終わりに

Novaでは既存機能の抜本的な改善が行われ、Novaをより幅広いユースケースで安定して使いやすくするための開発が行われています。これらの実装には時間がかかりますが、着実に進められています。また、Novaは多くの他のプロジェクト（コンポーネント）と連携しています。今回は多くのプロジェクトとのジョイント・セッションが開催されました。方向性としては、既存機能の抜本的な改善と他プロジェクトとの連携をより改善する方向に向かっています。