前回の記事では Nova の機能とその使用方法について紹介しましたが、本記事では引き続き Nova のアーキテクチャについて紹介します。
OpenStack Nova システムアーキテクチャ
Nova は複数のサーバープロセスで構成されており、各プロセスが異なる機能を実行します。ユーザー向けのインターフェースは REST API ですが、Nova 内部の各コンポーネント間は RPC を介して通信を行い動作します。
API サーバーは REST リクエストを処理します。これには通常、データベースの読み書きや、他の Nova サービスへの RPC メッセージの送信が含まれ、対応する REST レスポンスを生成します。RPC メッセージの伝送は oslo.messaging を通じて行われます。これは OpenStack コンポーネント共通の RPC メッセージ抽象化レイヤーであり、OpenStack の各コンポーネントが下位の RPC 実装を意識せずに済むように設計されています。
ほとんどの主要な Nova コンポーネントは複数のサーバー上で実行可能であり、マネージャーが RPC メッセージをリスニングすることで、高可用性と負荷分散を実現しています。主な例外は nova-compute で、管理対象の各ハイパーバイザー上で単一のプロセスとして動作します（VMware や Ironic ドライバーを使用する場合を除きます）。
Nova のすべてのコンポーネント間では、論理的に共有された中央データベースが使用されています。しかし、アップグレード時の負担を軽減するため、データベースとの通信はオブジェクトレイヤーを介して行われます。これにより、アップグレード後のコントロールプレーンが以前のバージョンの nova-compute と引き続き通信できることが保証されます。そのため、nova-compute はすべての DB リクエストを RPC 経由で nova-conductor というコンポーネントにプロキシします。詳細な動作については、以下を参照してください。この記事の Objects セクション。
Nova の各コンポーネントとその担当機能
公式ドキュメントの図を参考に、Nova 内部のコンポーネントと OpenStack の他のコンポーネントとの相互関係、およびそれらがどのように通信しているかを確認してみましょう。
以下のように整理できます。
- Novaと他のコンポーネント間の通信はすべてREST APIを介して行われます。
- Novaの内部コンポーネントはすべて、oslo.messagingが提供するRPCを介して通信します。
- nova-computeのDBリクエストはすべてnova-conductorを介して処理されます。
次に、各コンポーネントが主に担当する機能について紹介します。
- DB：データを保存するためのSQLデータベース。通常はMariaDBが使用されます。
- API：HTTPリクエストを受信し、コマンドを変換して、oslo.messaging RPCまたはHTTPを介して他のコンポーネントと通信します。
- Scheduler：各インスタンス（instance）を生成するホスト（hypervisor）を決定する役割を担います。
- Compute：Novaとハイパーバイザおよび仮想マシン間の通信を管理します。
- Conductor：複数のコンポーネントの調整が必要なリクエスト（build/resizeなど）や、nova-computeのデータベースプロキシなどのタスクを処理します。
- Placement：リソースプロバイダーの在庫と使用状況を追跡します。
以上が Nova のアーキテクチャに関する技術的な紹介です。不明な点があれば、コメント欄で質問してください。
まとめ
本記事で Nova のアーキテクチャ全体とその機能についての紹介は終了です。次回は Keystone について紹介します。
著作権表示：このブログのすべての記事は、特記のない限りCC BY-NC-SA 4.0ライセンスの下で提供されています。
