OpenStackのコンピュートノードを冗長化する構成

CTC教育サービスはコラム「OpenStackのコンピュートノードを冗長化する構成 」を公開しました。
はじめに
　前回のコラムでは、OpenStackのコントローラーノードをクラスター構成でインストールするツールを紹介しました。これは、Red Hatの商用ディストリビューションRed Hat Enterpirse Linux OpenStack Platform 7(RHEL-OSP7)では、OSP directorとして提供されています（アップストリーム版のRDOでは、RDO Managerという名称）。OSP directorでインストールすると、Pacemakerによるクラスターによって、各種コンポーネントの冗長化や負荷分散が行われるようになります。

　そして、RHEL-OSP7（RDOの場合は、Kiloリリース）では、さらにコンピュートノードも冗長化することが可能になっています。あるコンピュートノードが障害で停止すると、それを検知して、該当ノードで稼働していた仮想マシンインスタンスを他のコンピュートノードで自動的に起動しなおすという仕組みです。今回は、この仕組みについて解説したいと思います。なお、現在はまだ、この仕組みをOSP directorから構成することはできません。OSP directorで環境を構築した後、手作業での追加設定が必要となります(*1)。

Nova evacuateの仕組み
　コンピュートノードが障害で停止すると、当然ながら、そこで稼働していた仮想マシンインスタンスも障害停止状態となります。この時、OpenStackの利用者は、「nova evacuate」コマンドによって仮想マシンインスタンスを他のコンピュートノードで起動しなおすことが可能です。これは、OpenStack Novaが従来から提供していた機能です。ただし、nova evacuateコマンドの動作は、仮想マシンインスタンスの起動方法（Novaブート、もしくは、Cinderブート）によって少し異なります（図1)。

fig01

図1 nova evacuateコマンドの動作

　コンピュートノードのローカルディスク上のイメージから仮想マシンインスタンスを起動する、いわゆる「Novaブート」の場合、移動先のコンピュートノードでは、新しいディスクイメージをGlanceから取得して仮想マシンインスタンスを起動します。つまり、停止する直前のディスクイメージの内容は失われます。一方、Cinderボリューム内のOSイメージを用いて、Cinderボリュームから仮想マシンインスタンスを起動する「Cinderブート」の場合、移動先のコンピュートノードでは、同じCinderボリュームを用いて、仮想マシンインスタンスを起動します。この場合は、停止直前の状態のディスクイメージから、仮想マシンインスタンスを再起動することが可能になります。つまり、Cinderボリュームからの起動と、nova evacuateコマンドを組み合わせることで、仮想マシンインスタンスの完全な復旧が可能となります。

この続きは以下をご覧ください
http://www.school.ctc-g.co.jp/columns/nakai/nakai79.html