OpenStackディストリビューション「RDO」を用いて、実際に動作するOpenStack環境を構築しながら、OpenStackの利用方法や内部構造を学ぶ特集の第6回です。今回は、OpenStackの主要コンポーネントであるNovaとCinderの内部構造を解説します。HorizonダッシュボードやCLIツールからAPIリクエストを受け取った後、仮想マシンインスタンスの起動やブロックボリュームの作成が行われる仕組みを理解していきましょう。

Novaを構成するサービス群

 Novaを構成する主要なサービスと関連するコンポーネントは、図1のようにまとめられます。ここでは、管理機能がインストールされた「コントローラーノード」と仮想マシンインスタンスが起動する「コンピュートノード」が分かれた構成を想定しています。「基礎編」の第1回で構築したオールインワン構成の環境では、これらはまとめて1台のPCに導入されていますが動作上の違いはありません。

図1●Novaを構成する主要なサービス
図1●Novaを構成する主要なサービス
[画像のクリックで拡大表示]

 ここで言うサービスは、特定の処理を担当するデーモンプロセスに当たります。まず、コントローラーノードの「Nova API」は、REST APIでクライアントからのリクエストを受け付けます。受け取ったリクエストは、メッセージングサーバーを経由して、「Nova Scheduler」に受け渡します。

 Nova Schedulerは、コンピュートノードのリソースの空き状況を確認して、仮想マシンインスタンスを起動するコンピュートノードを決定すると、コンピュートノードで稼働する「Nova Compute」に起動を依頼します。この部分もまた、メッセージングサーバーを経由して行われます。

 Nova、Cinderなどのコンポーネントは、お互いにREST APIで連携しますが、コンポーネント内部のサービス群は、メッセージングサーバーを経由して連携する点に注意してください。OpenStackでは、メッセージングサーバーとして、オープンソースのRabbitMQが使用されています。これは複数のサービスに情報を配信する機能を持ちます。

 例えば、クライアントからのリクエストが多くて、Nova Schedulerの処理がボトルネックになったとします。このような場合、複数のNova Schedulerを起動しておくと、メッセージングサーバーによりNova APIからの依頼が振り分けられるようになります。このように同一のサービスを複数起動することで、管理機能の負荷分散や冗長化が実現できるようになっています。

 図1の「Nova Conductor」は、コンピュートノードのリソース情報を収集してデータベースに保存する役割を持ちます。コンピュートノードで稼働するNova Computeは、該当ノードのリソース使用状況を定期的にNova Conductorに通知するので、それらをまとめてデータベースに書き込みます。