はじめに

深津による第一弾、第二弾に続き、OpenStack Summit Austin報告の第三弾をお届けします。
第三弾では、私が今回特に盛り上がっていると感じた技術トピックである、OpenStack自体の監視や管理を行うコンポーネントに関するセッションを取り上げます。
過去に参加したOpenStack Summitでは、監視や管理の分野はむしろ各社の腕の見せ所で、独自ツールの出来栄えやノウハウをセッションで発表していましたが、近年ではそういった部分もコミュニティに組み込んで育てていくという傾向があるようです。
おそらく、OpenStackのアップデートに伴う仕様変更に追従するよりも、コミュニティとして育てた方がお得であるとの判断ではないかと推測しています。

以下、現地で見聞きした各セッションについて紹介します。

Senlin Clustering Service Deep Dive

引用元：https://www.youtube.com/watch?v=kh2aqlwKz7k

MitakaリリースからBig tent入り（注1）したニューフェイスのプロジェクト、Senlinの紹介です。
SenlinはOpenStackクラウド向けにクラスタリングサービスを提供するコンポーネントで、Heatのstack資源やNovaのserver(VM) 資源、Cinderのvolume資源等をクラスタリングし、スケールイン/アウトや高可用性の提供等がAPIから手軽に行えます。
セッションでは主に、Senlinの開発経緯や動作概要、これからの展望が語られました。
次のNewtonリリースでは、クラスタに対するアクションをユーザ定義可能にする、コンテナのクラスタリングを可能にする、他サービスへの通知等の機能が追加されるようです。
ただし、これらはあくまで計画であり、実際に全てがNewtonで追加されるとは限りませんが。

Senlinは弊社で実際に検証したことがないため実際の使い勝手は把握できていないのですが、クラスタリング機能を個々のOpenStackコンポーネントに持たせるのではなく外部から行うという発想は、方式として柔軟性が高く面白いと感じました。
特にアクションがユーザ定義可能になれば、使い途は大きく広がりそうです。

注1:
Big tentはOpenStackコミュニティで採用されているリリース方針で、中心的なCore Serivices（Nova, Keystoneなど6プロジェクト）に対して周辺的なプロジェクトがまとめられています。

Congress in NFV-based Mobile Cellular Network Fault Recovery

引用元：https://www.youtube.com/watch?v=lqTRMCNFdso

Congressを使って、NFVベースの携帯電話ネットワークの障害復旧を行う例の紹介です。
障害復旧シナリオとして、冗長化しているポートに障害が発生した場合に、適切な復旧を行う実演ビデオを上映していました。
その中で利用していたのが、Push Type Datasource Driverという、Push型で情報を収集する（Congressの）ドライバです。
従来のCongressは、例えば定期的にNovaのAPIを発行して結果を受け取るなど、Pull型で情報を収集していました。対して、このPush Type Datasource Driverはモニタからの通知を待ち受けることで、Push型で情報を収集できるようになります。
従来のPull式の場合は、Congressにドライバが用意されていないシステムの監視は出来ませんでしたが、Push Type Datasource Driverですとモニタ側が所定の形式で通知を送りさえすればCongressと連携することができますので、より簡単に連携をとることが可能となります。
元々Congressはユーザがポリシーを定義できる柔軟性の高さが魅力でしたが、このPush Type Datasource Driverによって更に利用の幅が広がりそうです。
Push Type Datasource Driver は、Mitakaリリースではまだ実装されておらず、Newtonリリースに向けて開発中です。

Mistral: Stories from advanced users

Mistralを実際に使用した事例を、当事者が紹介するセッションです。
こちらはデザインサミットの一環として行われたので、残念ながらビデオはありません（デザインサミットは基本的にビデオ撮影なしとなっています。代わりといってはなんですが、デザインサミット会場の入り口に設置されていた看板の写真を載せておきます）。

以下の事例が紹介され、いずれもOpenStack外のシステムとMistralをインテグレーションさせていたことが印象的でした。

• githubへのプルリクエストを契機に、そのパッチを適用して特定の操作を行う試験を実行する......という動作をMistralに行わせる。
  • (聴いていて、Jenkinsで十分出来るのでは？という疑問も湧きましたが、Mistralを使うとOpenStackを操作するAPIを発行する部分の作り込みの手間が省けることが利点なのかもしれません。)
• まずTOSCA（Topology and Orchestration Specification for Cloud Applications）に従ってシステム構成の記述を行い、それをMistralのワークフロー書式に変換して環境構築を行う。変換は独自に自動化している。
  
  • (従来あったTOSCA記述後の環境構築の手作業部分が、Mistralで自動化できたという話でした。)

特に後者のような、マスターとなる情報からMistralワークフローに変換するような使い方は、変換先の形式をMistral以外も選べるように作り込めばハイブリッドクラウドにも対応しやすいと思いますので、環境によっては有用かもしれません。

Watcher, a Resource Manager for OpenStack: Plans for the N-release and Beyond

引用元：https://www.youtube.com/watch?v=mxN7Pi13ppk

Watcherというコンポーネントの紹介です。
Watcherプロジェクトはサミット開催時点ではBig tent入りしていなかったのですが、私が本記事の執筆にもたついている間に、Big tent入りが承認されました。

さて、このWatcherが何をするコンポーネントかというと、目的はクラウド環境の「最適化」です。
例えば、特定Compute NodeにCPU使用率が高いVMが集中している場合、そのVMを他のCompute Nodeにライブマイグレーションで移すことで全体としての使用量を平均化する......といった使い方を想定しています。
資源の平準化（もしくは集中化）であれば各コンポーネント（NovaやNeutronなど）のスケジューラがやっているじゃないかと思うかもしれませんが、それらが行うのはあくまで仮想資源の割り当てのスケジューリングであり、仮想資源作成後の実使用量に基づいたスケジューリングは担当範囲外です。そのため、このようなコンポーネントが必要になるケースが出てきます。
まだ発展途上のコンポーネントですが、IBMやAT&T、インテルなど大物企業が開発に携わっており、今後発展していく可能性が高いかもしれません。
ただしMonascaとCongressを組み合わせることで同等のことが出来るのではないか？という気もしますが。

High Availability for Pets and Hypervisors - State of The Nation

引用元：https://www.youtube.com/watch?v=lddtWUP_IKQ

こちらは（Novaで作成した）VMの高可用性に関する様々な技術の紹介、比較です。
VMとVM上で実行されるサービスの運用は、しばしば「ペットと家畜（Pets vs. Cattle）」という比喩で語られます。
ペットは一匹ずつ名前があり、もし死んでしまえば替えは効きません。
一方、家畜はその逆で、問題があっても替えが効きます。
スケーラビリティや障害復旧を考慮すれば、基本的にVMやサービスの運用は家畜型のほうが便利ですが、従来の運用を家畜型に切り替えるコストが高すぎる場合等、実際にはVM高可用性の需要はあるというのが発表者の主張でした。

セッションでは主に、OpenStackコミュニティで開発しているPacemakerのOCFリソースエージェント(注2)を利用した手法、Masakariという開発中のコンポーネントを利用した手法、Mistralを利用した手法の3つについて紹介と比較がされました。
以下がその比較表です。

引用元：https://www.youtube.com/watch?v=lddtWUP_IKQ

各々得手不得手ありますが、単純に「Yes」の数をカウントした場合、Masakariが最も多いという結果でした。

なお、このMasakariはまさにVM高可用性を目的としたコンポーネントであり、現在Big tent入りを目指し、NTTが主体となって開発を進めています。
若干手前味噌な話ですが、このコンポーネントは弊社も開発に携わっています。
Masakariの最新コードは以下のgithubリポジトリから取得できますので、興味ある方はご覧ください。
https://github.com/ntt-sic/masakari

注2:
リソースエージェントは、以下のgithubリポジトリで管理されています。
https://github.com/openstack/openstack-resource-agents

おわりに

OpenStackの監視や管理を行うコンポーネントは云わば群雄割拠の状態で、お互い多少機能的な重複もあるようですが、そのあたりはプロジェクト間で調整をしつつ各自精力的に開発が進んでいるようです。
まだドキュメントが整っていないプロジェクトも多く、現時点で実環境に導入するには慎重さが要求されますが、うまく利用すればOpenStackクラウド運用の労力を削減してくれるはずですので、弊社としても動向を注視し検証を行っています。

なお、ここで挙げたコンポーネントも含めOpenStackの監視や管理を行う各コンポーネントの機能や差異については、7月6～7日に開催されるOpenStack Days Tokyo 2016の「トップエンジニアが語るOpenStack開発者（Dev）側のホットトピック」というセッションにてより詳しくご紹介する予定です（私が発表者となります）。
OpenStackの監視や管理で困っているなど、ご興味のある方は、ぜひお越しください。
また、上記イベント以外でも、本記事に関するお問い合わせやOpenStackの監視・管理に関するお問い合わせ、弊社は常時お待ちしております。