Novaの最新情報：Placement機能の発展と利用拡大、大規模な環境への適応

はじめに

　Nova^※1は仮想サーバの割り当てや管理を行なうコンポーネントであり、Ironic^※2を使用したベアメタル・サーバの割り当てもサポートしています。OpenStackのコンポーネントの中で最も歴史が長く^※3、最も使用されているコンポーネント^※4です。Novaにおいては、最近数回のリリースを経てPlacement、Cells v2といった重要な機能が着実に実装されてきました。それではNovaについて、2018年5月に開催されたOpenStack Summit Vancouverでの最新情報をレポートします。

※1: https://docs.openstack.org/nova/latest/

※2: https://docs.openstack.org/ironic/latest/

※3: https://releases.openstack.org/austin/index.html

※4: https://www.openstack.org/assets/survey/April2017SurveyReport.pdf

写真1. OpenStack Summit Vancouverの看板

Placement

　Placement機能とは、REST APIを通してリソース（例えばCPU、メモリ、ディスク等）の割り当て・使用状況を管理し、また、仮想サーバ等を配置するコンピュート・ノード（ハイパーバイザ）の候補を得ることができる機能です。

　今回のサミットのレポートをする前に、Placementの歴史を振り返りたいと思います。

　Placementは2016年10月にリリースされたNewtonリリースからNovaに導入され、Ocataリリースで利用が必須の機能となりました。Novaでは各コンピュート・ノードがそのノードのリソース使用量のデータを定期的に更新する仕組みとなっています。従来のスケジューリングでは、仮想サーバの配置先となるコンピュート・ノードは、そのリソースの情報（空き容量）やアベイラビリティ・ゾーン、イメージのプロパティなどの情報をもとにスケジューラ（nova-scheduler）が選択していました（デフォルトのFilter schedulerの場合）。しかし、この従来の仕組みについては以下のような課題が指摘されていました。

• イメージやフレーバにプロパティを付与して、そのマッチングを取ることによるスケジューリングの仕組みは、そのプロパティとして設定する特性（SSDやGPUなどのアクセラレータ、他）の数が増えるについて管理の手間がかかるようになる
• 複数のコンピュート・ノードがインスタンス・ストア（仮想サーバ関連ファイルの格納先）を共有している場合、ディスクの空き容量を正しく認識できない
• スケジューラ（nova-scheduler）が複数あり、複数の仮想サーバ作成リクエストの競合が発生した場合、リソースの空き容量を正しく認識できない場合がある
• CinderやNeutronにもスケジューラがあり、各コンポーネントで似たような機能の実装が行なわれている（OpenStack全体で見ると重複する機能の実装が行なわれている）

　このような課題に対応するため、従来のスケジューリングの仕組みを抜本的に改善するための取り組みとして開発が始まったのが、Placement機能です。

　それでは、今回のサミットでのセッションを紹介していきたいと思います。

Placement, Present and Future, in Nova and Beyond （プレゼンテーション）

　Placementの機能の説明やREST APIのテストフレームワークであるGabbi^※5の紹介がありました。また、Queensリリースで実装されたNested resource provider^※6の機能（の一部）、Traits（特徴：例えばGPUなどのアクセラレータ）を利用した配置先の候補の取得などの紹介がありました。Rockyリリースの作業中の項目については、Nested resource providerの実装の継続^※7、ホスト・アグリゲートのPlacementへの反映機能が挙げられました。将来的な方向性としては、Placement機能のNovaからの分離、他のコンポーネント（Cyborg^※8）と連携したアクセラレータの完全なサポート、Placementによるクォータ機能の実現（既存クォータ機能の置き換え）が挙げられていました。

※5: http://gabbi.readthedocs.io/en/latest/

※6: https://specs.openstack.org/openstack/nova-specs/specs/queens/approved/nested-resource-providers.html

※7: https://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/nested-resource-providers-allocation-candidates.html

※8: https://docs.openstack.org/cyborg/latest/

　また、以下のForum（参加者が議論を行なうセッション）がありました。

• Building the path to extracting Placement from Nova
• Planning to use Placement in Cinder

　Forumでは、Placement機能のNovaからの分離（必要な作業項目、タイムラインなど）や他のコンポーネント（Cinder）におけるPlacement機能の利用について議論が行なわれました。なお、NeutronにおいてはOcataリリースからPlacement機能の利用が開始されています（Routed provider networks機能^※9）。

※9: https://docs.openstack.org/neutron/latest/admin/config-routed-networks.html

写真2. Marketplaceでは参加者が各社の展示ブースを回り、展示各社と参加者、参加者同士の間で活発に会話が行なわれていました

Cells v2

　Cells v2機能は、大規模なOpenStack環境を構築するための機能です。Novaとその関連コンポーネントをセルという単位で管理し、従来ボトルネックであったデータベースやメッセージ・キューをセルごとに分離することで、コンピュート・ノードのスケーラビリティを確保します。

　ここでも、まずCells v2の歴史を振り返りたいと思います。Cells v2の以前には、Cells v1機能がありました。Cells v1はCells v2同様、大規模なOpenStack環境を構築するための機能であり、スケーラビリティを確保するための機能でした。しかしながら、以下のような課題がありました。

• セルを使用していない構成からセルを使用した構成への変更に手間がかかる
• ホスト・アグリゲート、セキュリティ・グループ、サーバー・グループ関連の機能実装においてセル構成の考慮が必要となる
• 開発において各APIに対応するセル用のAPIを実装する必要がある
• APIセルとその子セルのデータベースの同期処理に問題があり、また同期処理による負荷が高い

　そのため、その課題を解決するためにCells v2の開発が開始されました。Newtonリリースで単一セルがサポートされ、Ocataリリースでは単一セル構成が必須となり、Pikeリリースでは複数セルがサポートされました（デフォルトは単一セル構成）。

　それでは、今回のサミットでのセッションを紹介していきたいと思います。

Moving from CellsV1 to CellsV2 at CERN（プレゼンテーション）

　CERN（欧州原子核研究機構）^※10における、Cells v1構成からCells v2構成への移行のプレゼンテーションです。NewtonからOcata、OcataからQueensにアップグレードした事例の紹介でした。Cells v1からの移行は決して簡単ではなかったこと、Cells v2はスケーラビリティの観点で特に問題がないこと、セルがダウンしている時の一覧取得処理等に問題があるということが語られました。また、データベースの移行に関しては特に大きな問題は発生しなかったとのことです。

※10: https://home.cern/

プリエンプティブル・インスタンス

プリエンプティブル・インスタンス（Preemptible instances）とは、ある仮想サーバが使用しているリソースの使用権を、他の優先度の高い仮想サーバに明け渡す機能です。

Containers on Baremetal and Preemptible VMs at CERN and SKA（プレゼンテーション）

　CERNにおけるプリエンプティブル・インスタンスのユースケースの説明がありました。多くのプロジェクトがあり、プロジェクトごとにクォータが設定されています。しかし、各プロジェクトは必ずしも上限まで使用している訳ではありません。そのため、システム全体においては、使用されないリソースが出てくるということになり、リソースの効率的な使用が妨げられています。

　その課題を解決するため、プリエンプティブル・インスタンスの機能が提案されています。この機能では、各プロジェクトにクォータを超えて仮想サーバ（プリエンプティブル・インスタンス）の作成を許します。もし、他のプロジェクトがクォータの範囲内で仮想サーバを作成しようとした場合にリソースの空きがなければ、プリエンプティブル・インスタンスの持つリソースを明け渡してもらい、その仮想サーバを作成して、プリエンプティブル・インスタンスは保留状態にするというものです。

　また、そのプリエンプティブル・インスタンス機能は幾つかの機能に分けてコミュニティに提案されていますが、それらについて説明がありました。

その他

　「Nova - Project Update」のプレゼンテーションでは、NovaのQueensリリースにおいて追加された新規機能や、次期リリースであるRockyリリースあるいはそれ以降のリリースで追加・対応が予定されている機能の紹介がありました。

　Queensリリースで追加された機能の紹介のところでは、筆者が機能追加したコールド・マイグレーションにおける宛先ホスト指定機能（Target a specific host during cold migrate、マイクロバージョン 2.56）やnova-manageコマンドのセルからのホスト削除（delete host mappings）機能も紹介されていました。

まとめ

　Placement機能はNovaからの分離と他のコンポーネントからの利用の拡大を目指して、引き続き活発に開発が進められるものと考えられます。Cells v2については、開発としてはまだ幾つかの課題が残っているものの一段落しており、今回はCERNの移行事例が紹介されました。今後大規模な環境での適用事例が増えるものと考えられます。また、プリエンプティブル・インスタンスのような大規模な環境（多数のユーザがいる環境）で効率的にリソースを使用する機能の実装が今後進んでいくと考えられ、ますます大規模な環境での利用に適するように進化していくものと考えられます。