コンピュートノードの管理
最後に、コンピュートノードの状態や設定といった情報を管理する機能について説明します。
コンピュートノードの状態はnova-conductorで一括管理
インスタンスを操作する場合、そのインスタンスがどのコンピュートノードに存在するのかを、まず確認しなければなりません。また、どのコンピュートノードがどんな仮想化方式を利用しているのかの情報も必要です。
OpenStackでは、こうした各コンピュートノードの状態をデータベースで管理しています。 このデータベースの更新を行うのがnova-conductorコンポーネント（以下、nova-conductor）です。OpenStackのコンピュートノードとそこに存在するインスタンスの情報を集約し提供するnova-conductorは、いわばインスタンス管理の心臓部です。
このデータベース管理の機能をnova-apiに含めず、nova-conductorという別個のコンポーネントに機能を実装しているのは、nova-schedulerと同様にその処理が複雑である上、頻繁に実行されるからです。
コンピュートノードには追加や削除、変更が頻繁に発生します。 コンピュートノードを追加するケースには、リソースが不足してきたときがあります。 逆にコンピュートノードを削除するケースには、コンピュートノードとして使っているサーバーが物理的に壊れたときがあります。 コンピュートノードに発生する変更には、コンピュートノードが配置されている場所の変更や、利用している仮想化方式の変更があります。
もし、コンピュートノードが追加されたことが見過ごされたらどうでしょう。せっかく作成したコンピュートノードが使われないままになってしまいます。コンピュートノードが削除されたことや変更されたことを知らなければ、存在しないコンピュートノードにリクエストを送ったり、無効なリクエストをコンピュートノードに送信したりするかもしれません。
さらに、変更が大規模であったり頻繁であったりすると、更新の際に手違いが起こりかねません。 また、コンピュートノードが持つIPアドレスがDHCPによって変更されたり、意図しない理由でコンピュートノードが一時的に使用不可に陥ったりしたときに、情報を手動で更新することは困難です。 そうした事態を自動検知して情報を更新するプログラムが必要になるでしょう。
このようなことから、nova-conductorにコンピュートノードの情報を集約・提供するデータベースの管理が任されています。
nova-conductorの動作
nova-conductorは、nova-computeから送られてくる情報を受け取り、データベースに登録したり更新したりします。 管理者はコンピュートノードの一覧を手動で更新する必要はありません。 サービス利用者もコンピュートノードの状態を気にせず、常に動作しているコンピュートノードを利用できます。
nova-conductorはnova-computeに対して情報送信の要求を行いません。 nova-computeがnova-conductorへ定期的に情報を送信します。
もし、情報を送ってこないnova-computeがあれば、そのコンピュートノードは除かれたとnova-conductorは判断し、その旨をデータベースに反映します。 その後、除かれていたnova-computeが再度情報を送ってくれば、再度データベースを更新し、コンピュートノードの復旧をユーザーに知らせます。 また、未知のnova-computeが情報を送ってきた場合、nova-conductorは新しいコンピュートノードが追加されたとして、データベースに追加します。
このような仕組みで、コンピュートノードの追加や変更がスムーズに行われています。
また、このようなnova-conductorによるコンピュートノードの管理を可能にしているのは、Novaが（そしてOpenStackが）マイクロサービスアーキテクチャで設計されているからといえるでしょう。
おわりに
コンピュートノード上でインスタンスを操作するnova-computeは、インターフェイスこそ統一されていますが、内部の動作は様々なものを許容しています。そのため、単一のクラウドコンピューティングサービス上で複数の仮想化方式が利用可能となっています。
また、OpenStackでは多くのインスタンスを作成するため、コンピュートノードの数も多くなります。その中から適切なコンピュートノードを選んでインスタンスを作成するのは困難です。 これを解決するために、nova-schedulerが利用可能なコンピュートノードを抽出し、それらに重み付けを行っています。
コンピュートノードは変化が激しく、その変化を追えなければ誤操作やリソースの無駄が発生します。 そこで、nova-conductorがnova-computeから定期的に送信される情報をデータベースに集約する仕組みになっています。
このようなNovaの柔軟さは、マイクロサービスアーキテクチャによって支えられており、Novaの柔軟さによって、OpenStackへ移行する際の敷居が低くなっています。
