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

Novaを構成するサービス群

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

図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に通知するので、それらをまとめてデータベースに書き込みます。

この先は会員の登録が必要です。有料会員(月額プラン)は初月無料!

日経 xTECHには有料記事(有料会員向けまたは定期購読者向け)、無料記事(登録会員向け)、フリー記事(誰でも閲覧可能)があります。有料記事でも、登録会員向け配信期間は登録会員への登録が必要な場合があります。有料会員と登録会員に関するFAQはこちら