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

この記事が役に立ったらシェア!
メルマガの登録はこちら Web担当者に役立つ情報をサクッとゲット!

人気記事トップ10(過去7日間)

今日の用語

アップロード
手元のPCなどの機器から、ネットワークを介して、別のPCやファイルサーバー、ウェ ...→用語集へ

インフォメーション

RSSフィード


Web担を応援して支えてくださっている企業さま [各サービス/製品の紹介はこちらから]