OpenStack、インストール後につまずかない、考え方・使い方のコツ（その1）――OpenStackはどのように構成されているか：特集：OpenStack超入門（9）（1/3 ページ）

いざ「OpenStackを使ってみよう」と思っても、方法が分からず使えなかった経験を持つ人も多いのでは？ そこで本特集では、これから数回にわたり「OpenStackの構成例」を通じて使いこなしのコツを紹介していく。

[室井雅仁,市川俊一/NTT ソフトウエアイノベーションセンタ]

OpenStackを使い始めるために

　本特集ではOpenStackが求められる理由や、システム構築・運用における従来との違いやメリットなど、さまざまな視点からOpenStackの特徴を解説してきました。これまでの記事をご覧になられた方の中には、すでにOpenStackを使っている方もいるでしょうし、これから使ってみようと考えている方も多いのではないかと思います。

　しかし、OpenStackを「使ってみよう」と行動を開始してから「使い始めた」に至るまでには、いくつかの壁があり、なかなかの労力が掛かります。というのも、OpenStack自体もオープンソースソフトウエア（以下、OSS）であるため、Githubのリポジトリからすぐにソフトウエアを取得することはできるのですが、「使い始める」ためのオペレーションまではOSSとして公開されていないからです。「全作業内容が網羅されたマニュアルがないとオペレーションできない」といった理由で、OpenStackに深い関心を持ちながらも使えなかった経験をお持ちの方もいるのではないでしょうか。

　もちろん、以下のリンクのように、OpenStackコミュニティでもオペレーションをマニュアルとしてまとめてはいます。

• オペレーションマニュアル（OpenStack.org／英語）
• オペレーションマニュアル（OpenStack.org／日本語）

　しかし、このマニュアルさえあればどのようなケースにも対応できるというわけではなく、皆さまがOpenStackでやりたいこと、すなわち個別の要件に沿ってオペレーションを応用していく必要があるのです。とはいえ、いくつかのポイントを知り、コツをつかめば、使うためのハードルをかなり下げることができます。

　そこで本連載では、複数の「OpenStackの構成例」の紹介を通じて、“使いこなすためのコツ”を分かりやすく紹介していきます。皆さまの利用目的に合わせて、OpenStackを「使い始める」までの橋渡し役となれば幸いです。

OpenStack にはどんなプロセスがいるのか？

　では最初に、「OpenStackはどんなプロセスで構成されているか」から説明していきましょう。

　OpenStackでは、仮想マシン管理機能の「Nova」、仮想ネットワーク管理機能の「Neutron」、仮想ブロックストレージ管理機能の「Cinder」など、管理機能ごとにプロジェクトが分かれていることはご存じの通りです。今回は皆さまがほぼ間違いなく利用するであろう、Novaの代表的なプロセスを元に、OpenStackのプロセス構成を説明します。もちろん、プロジェクトごとにプロセスの種類や名前は異なりますが、構成に関する特質は似たところがあるため、他のプロジェクトでも同じように考えることができます。

　まず、新しく仮想マシンを作成するときに動作するNovaのプロセスは、nova-api、nova-conductor、nova-scheduler、nova-compute の全4種類あります。そのプロセスをまとめると、以下の図1のようになります。

　

図1　VM起動までに関連するプロセス

　nova-apiはユーザーからAPIのリクエストを受け取り、後続処理を実施する nova-conductorへリクエストを渡します。そして、nova-conductorへのリクエストの送信が完了した時点で、nova-apiはユーザーへAPIリクエストの受付完了のレスポンスを返します。nova-conductorはnova-apiからリクエストを受け取った後、VM起動までの非同期処理のマネジメントを実施します。

　非同期処理の途中で、 nova-conductorは「起動するVMを、どのハイパーバイザーへスケジューリングするべきか」をnova-schedulerに問い合わせます。nova-conductorは、nova-schedulerから受け取ったハイパーバイザーの情報を元に、次はnova-computeへ実際のVM起動の依頼を行います。そして最後にnova-computeが、nova-conductorから受け取ったVM起動の依頼を元に、実際の仮想化機構に対してVMの作成を依頼します。

　一方、これらプロセス間の通信はどのようにして実現されているのでしょうか？ OpenStackでは、「nova-apiとnova-conductorの間の通信」などプロセス間の通信はメッセージキュー（以下MQ）を利用したRPC（Remote Procedure Call）で実現するのが一般的です。対して、「NovaとNeutron」など異なるプロジェクト間の通信には、それぞれのAPIを利用して通信を行っています。

　これまでのプロセスの情報に追加して、OpenStackが利用するDBを加えると、以下の図2のように、Novaの4プロセスは連携して動作します。

図2　Novaのプロセスの連携

　図2で動作しているプロセスを大別すると、次の3種類のプロセスに分類できることが分かります。

1. ユーザーからのAPIリクエストを受け付けるプロセス: nova-api
2. APIに合わせた非同期処理のタスクを管理するプロセス: nova-conductor、nova-scheduler
3. 仮想化機構に対して実際の操作を行うプロセス: nova-compute

　これらのプロセスの分類は、Novaだけに限った話ではなく、ほとんどのプロジェクトで共通しています。例えば、仮想ネットワーク管理機能のNeutronでは、1と2をneutron-serverプロセスが担当しており、3をagentプロセスが担当しています。