リソースモニタリングなど機能の充実が進むBlazar

　今回のOpenStack Summit Vancouverレポートでは、Blazarプロジェクト^※1の最新動向をお届けいたします。

Summit会場からの眺め

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

Blazarプロジェクトとは

　BlazarプロジェクトはOpenStackにおいてReservation as a Serviceとして定義されており、ユーザが将来利用するインスタンスやコンピュートホストなどのリソースを事前に予約する機能を提供します。予約機能を利用することで、ユーザは事前に利用する量と時間が判明しているリソースを確実にプロビジョニングできるようになります。

図1: Blazarプロジェクトの公式マスコット

　通常、VMインスタンスなど仮想リソースの作成リクエストを契機として、OpenStackはハードウェアの割り当てなどをスケジューリングします。そのため、OpenStackがリクエストを処理する順番は先勝方式です。例えば、VMの作成リクエスト（需要）がハイパーバイザ×VMの最大収容数（供給）を上回った場合には、最大収容数を超えるVMの作成リクエストは失敗することになります。

　Blazarを利用することで「予約」の概念をOpenStackに導入できます。利用予定のリソースをユーザが事前に「予約」しておくことで、需要が供給を想定外に上回ったとしても、利用予定のユーザへOpenStackが予約済みリソースを確実に提供できるようになります。

　例えば、あるユーザAがショッピングサイトを運営していたとします。週末にセールを予定している場合、週末はアクセスの増加が予測されるため、確実にサービスのスケールを実施したいと考えます。もし予約機能がなく週末までに別のユーザBが想定外にハイパーバイザを使い切ってしまった場合、ユーザAのサービスはハイパーバイザに余裕がなく、スケールできません。対してユーザAが予約機能を利用した場合、セール期間中のスケールに必要なリソースを事前に予約して確保しておくことができます。

　Blazarの予約では図2のように、予約対象のリソースごとにタイムテーブルを管理することでOpenStackクラウドへ「予約」の概念を導入しています。

図2: Blazarが管理するタイムテーブル（コンピュートホストの例）

　Blazarの代表的な適用例は、Chameleon Cloud^※2など科学計算用テストベッドやOPNFV Promise^※3のNFV領域があります。科学計算用テストベッドではホスト単位の予約によりNoiseyNeighbor対策を実施しており、NFV領域では複数のVMで構成されるVNFの起動・スケールを確実に実施するための実現手段として、Blazarの予約機能が利用されています。詳細は以前のSydney Summitの記事^※4にて紹介していますので、気になる方はこちらをご覧ください。

※2: https://www.chameleoncloud.org/

※3: https://wiki.opnfv.org/display/promise/Promise

※4: https://thinkit.co.jp/article/13007

Queensの注目機能

　Queensリリースの注目機能として、リソースモニタリングとステートマシンの2つが紹介されました。

　リソースモニタリングを一言で表すと、予約対象リソースのヘルスチェック機能です。予約対象のリソースの状態を監視し、故障など何らかの理由によりユーザが予約した資源をプロビジョニングできない状態となった時、既存の予約をリアロケーションします。

　コンピュートホストのリソースモニタリングを図2の例で紹介します。日曜日から月曜日の間に「Host 2」が故障したとします。今後、「Project A」と「Project B」が「Host 2」を利用予定のため、現状の予約状況のままでは、2つのプロジェクトは予約した分だけリソースを利用できません。そこでBlazarが、「Project A」と「Project B」が利用するリソースを別の稼働中のリソースに自動的に変更することで、予約したリソースの利用を保証します。

　ステートマシンの導入により、ユーザが登録した予約の開始、終了、更新といった操作をBlazarがより厳密に管理できるようになり、かつユーザ向けの状態表示も充実しました。今までは予約の開始前、予約期間中、予約終了といった時間に対して、予約の開始や終了のステータスのみが管理されていました。Queensリリースから、予約の作成中、開始処理中といった操作中ステータスの管理に加えて、Blazar内部では状態遷移に従ったユーザからのAPI呼び出しが行われているかなどのチェック機構が導入されました。

「リソースの有効活用」がForumでの議論ポイント

　Forumセッションは通常のプレゼンテーション方式のセッションではなく、開発者、運用者やユーザが集まって様々なトピックを議論するセッションです。このForumセッションの一つに、Blazarの予約に関連するユースケースや要望を議論するセッションがありましたので紹介したいと思います。

　BlazarのForumセッションでは、ネットワークリソースの予約対象の提案などのトピックについて主に議論が行われました。中でも注目が集まったのが、コンピュートリソースの予約時間外の活用方法としてのPreemptibleインスタンスの提案と、ミドルウェア開発者向けのハードウェア専有方法の提案についてです。

　Preemptibleインスタンスは通常のVMインスタンスと異なり、ハイパーバイザの収容容量に空きがある場合のみ起動できるインスタンスです。Preemptibleインスタンスは優先度が低いインスタンスで、もしハイパーバイザがPreemptibleインスタンスで埋まっていた場合には、自動的に削除され通常のVMインスタンスへハイパーバイザの空きを渡します。プライベートクラウドを最大限有効活用するための手段として、Novaなどプロジェクトをまたいで機能実現に向けた議論がSientific SIGにより実施されています。

　Blazarが管理するハイパーバイザのうち、予約がない期間を有効活用するための方法として、Preemptibleインスタンスが活用できるか、またどのように実現できるかどうか、といった議論が行われました。

　次にミドルウェア開発者向けのハードウェア専有方法の実現として、Ironicインスタンスを予約したいという提案がありました。Ironicを用いたベアメタル環境においてベアメタルの数に限りがあり、スケジューラなどを用いて開発者同士が譲り合いながら開発しているので、Blazarを用いてOpenStackレベルで予約できるようにしたいという要望です。

　また、Blazarは予約の終了時点で次の予約に向けてリソースをクリーンアップするため、その点についても開発者同士でデータの削除作業などが不要になる点も注目されていました。セッションの参加者は、それぞれが利用・運用しているOpenStackクラスタで多かれ少なかれ同様の問題があるとの事で、議論が盛り上がっていました。

Rockyリリースに向けて

　現在開発中のRockyリリースで、Blazarは3つの大きな機能を開発していることが紹介されました。

• Ironic Support: IronicインスタンスをBlazarから予約できるようにする機能
• Availability Zone（以下AZ）awareness: ホスト予約およびインスタンス予約にてAZを指定した予約機能
• 予約候補API: リクエストに対して予約可能な時間を返すAPI

　Ironic Supportではその名の通り、Ironicインスタンスを予約対象にする機能です。科学計算用テストベッドでは高パフォーマンスを得るために利用されており、Forumでも議論に挙がっている通り非常に注目を集めています。

　AZ awarenessはホスト予約およびインスタンス予約時に、予約条件の一つとしてハイパーバイザが所属するAZを指定できるようになる機能です。

　予約候補APIは、リソースの予約したい時間と内容を記述したリクエストを呼び出すと、予約可否を返却するAPIです。今までは予約可能かどうかを調べるには、実際に予約を作成するリクエストを呼び出す必要がありました。これではAPIの呼び出しコストが非常に高いというユーザからのフィードバックがあり、予約の可否を返却するAPIの開発が進んでいます。

さいごに

　QueensリリースはBlazarが公式プロジェクトに組み込まれてから最初のリリースとなりました。Blazarプロジェクトはまだ小さく、始まったばかりのプロジェクトです。リリースごとに新しい機能の追加はもちろんのこと、プロジェクトとして実際のBlazarのオペレータやユーザのフィードバックを元にした開発を重視しています。

　今あるBlazarの適用事例は、科学計算やNFVなど大規模なOpenStack環境ばかりが取り沙汰されれています。しかしながら、Forumで議論があったように小規模なOpenStackだからこそ、「予約」という概念が生きてくる使い方も登場し始めました。Blazarを皆さんのOpenStack環境へ導入し、ぜひ「予約」の便利さを味わってみてはいかがでしょうか。