OpenStack Placement詳説 第1回
OpenStack Placementの概要および開発の経緯
はじめに
初めまして。NTTソフトウェアイノベーションセンタの研究員の夏目貴史です。私はOpenStack®のコントリビュータで、主にNovaおよびその関連プロジェクトで開発を行なっており、現在はpython-novaclientのCore Reviewerとして活動しています。 どうか、よろしくお願いいたします。
最近のNovaの動向
現在、OpenStackのNovaにおいて最もホットなトピックとは何でしょうか。筆者は、Placementが最もホットなトピックのうちの1つだと考えています。しかしながら、Placementは基本的にNovaなどのコンポーネントから利用されており、サービスの利用者（ユーザ）が直接意識することはないため、機能の詳細についてあまり知られていないと思います。そこで、この連載ではOpenStackのPlacement機能について説明していきます。
Placementとは
Placement は、REST APIを通してリソースの割り当て・使用状況を管理し、また、仮想サーバ等の配置先の候補を得ることのできる機能です。リソースとは例えばCPU、メモリ、ディスクなどのことです。Novaにおいては、この機能はスケジューリングのため、つまり作成・移動する仮想サーバを配置するコンピュート・ノード（ハイパーバイザ）を決定するために用いられます。Placementは現在（stable/rocky）はNovaに含まれており、Novaの1つの機能となっています。
Placementはリソースを持つハードウェア、ハイパーバイザなどを「リソース・プロバイダ」（Resource Provider）というエンティティで管理します。リソース・プロバイダは、具体的にはコンピュート・ノード（ハイパーバイザ）や共有ディスクなどになります。
CPU、メモリ、ディスクなどは、「リソース・クラス」（Resource Class）として定義されています。また、リソース・プロバイダの持つ特徴をトレイト（Trait）として表すこととしており、トレイトをリソース・プロバイダに設定することができます。トレイトとは具体的には、SSDが利用可能などの特徴です。
そして、スケジューラで仮想サーバを配置するコンピュート・ノード（ハイパーバイザ）を決定する時には、リソース・クラスとその必要量、必要なトレイトなどを指定して、配置候補であるリソース・プロバイダー（＝コンピュート・ノード）を取得します。（図1）
※ Placementは各リソース・プロバイダのリソース・クラスで定義されたリソースの使用量をアロケーション（Allocation）として管理しています 。
これらの機能については次回以降に詳しく見ていきたいと思います。
Placement登場以前の課題
Placementはなぜ開発が始まったのでしょうか。そこでPlacementが登場する以前の課題について見ていきたいと思います。以前は以下のような課題がありました。
- 従来のスケジューリング機能の課題
- プロパティのマッチングを取る仕組みが限界に近づいた
スケジューリングするために、イメージやフレーバ（Flavor）にプロパティやExtra specsを設定し、マッチングを取る仕組みとなっていますが、数多くのプロパティを設定しなければならず、また、フィルタリング（マッチング）も数多く実行しなくてはなりませんでした。
- 共有されているインスタンス・ストアの容量の認識が正しくない
仮想サーバ関連のファイルが格納されているインスタンス・ストアを複数のコンピュート・ノードで共有している場合、そのディスクの空き容量がそれぞれのコンピュート・ノードに存在するように扱われてしまい、結果として正しくスケジューリングされないことがありました。
- スケジューラ（nova-scheduler）プロセスの競合
スケジューラのプロセスを複数実行していると競合により、リソースの認識が正しく行われず、結果的に正しくスケジューリングされないケースがありました。
- 複数のコンポーネントにおける重複するスケジューラ機能の実装
NeutronやCinderにおいても仮想ルータや仮想ブロック・ストレージ等の配置を決定するスケジューラの実装がそれぞれ行われており、OpenStackの各コンポーネント（プロジェクト）で重複する機能の実装が行われています。
2. Novaのスコープ・クリープ（肥大化）
- スケジューラの外だし（分離）議論
Novaは非常に機能も多く、ソースコードも規模も大きいため、幾つかに分割して開発をしやすくしようという動きもあります。その1つが、現在スケジューラが担当している機能の分離です。また、2017年2月にアトランタで開催されたPTG（Project Teams Gathering、開発者の会議）ではコンピュート・サービスの外だし議論もありました。
そして、それらの課題を解決するためにPlacementの開発が開始されました。
Placementの歴史
Placement機能の開発の歴史は以下の図2のようになっています。
※ Routed provider networksについてはこちらを参照のこと。また、ネステッド・リソース・プロバイダー（Nested resource provider）、トレイトの除外指定（Forbidden Traits）、Placementアグリゲートについては次回以降に説明します。
そして、2019年4月リリース予定のSteinリリースに向けて現在も開発が進められており、2018年11月に開催されたOpenStack Summit BerlinにおいてPlacement関連では以下のようなフォーラム（議論を行なうセッション）が開催されました。
これらの詳細は連載の最後にPlacementの将来動向と併せて見ていきたいと思います。
Placement導入による構成・設定上の変更点・留意点
Placementが導入されたことにより、運用者（Operators）にとってどのような影響があったのでしょうか。それは以下のような影響があったと考えられます。
- 従来のAPI (Compute API)とはエンドポイント（REST APIの受け口）およびデータベースは別に構成することとなりました。
- FilterSchedulerによるフィルタリングの仕組みは併用されますが、幾つかのフィルタが不要になったため、設定するフィルタ数は減少し、管理の負担が軽減されました。不要になったフィルタは具体的にはCoreFilter、RamFilter、DiskFilter、ExactCoreFilter、ExactRamFilter、ExactDiskFilter、AvailabilityZoneFilter（AvailabilityZoneFilterは設定を有効にする必要があります）などです。
- フレーバのExtra specsとイメージのプロパティへ設定するという点は以前と同じですが、フレーバにリソース(vGPUなど)の要求を設定することや トレイトの除外指定が可能になりました。
それでは次回（第2回）は、Placementの各機能の詳細について見ていきます。
