第1回で説明した（1）仮想マシン間HAクラスタと、VMwareのHAクラスタ機能である（2）vSphere HA、それにアプリケーション監視を加えた（3）vSphere HA＋アプリ監視の計3つの方式である。

　今回は、（1）仮想マシン間HAクラスタの製品選定を行うために必要な知識として、「動作」「メリット／デメリット」「製品選定ポイント」「推奨する設計・運用」について紹介していく。

　（2）vSphere HA、（3）vSphere HA＋アプリ監視については、次回の第3回で説明する。

（1）仮想マシン間HAクラスタ

動作

図2　仮想マシン間HAクラスタの動作

　仮想マシン間HAクラスタでも物理環境のHAクラスタと同様に、稼働系と待機系の仮想マシンがそれぞれ起動し、仮想マシン上のクラスタ製品がハートビートでお互いのゲストOSの稼働状態を監視している。アプリケーションの他、仮想マシン上から見たNICや共有データ領域も監視している。

　稼働系の仮想マシンが障害で停止すると、待機系の仮想マシンがハートビートでそれを検知し、待機系にサービス用IPの付与、共有データ領域のマウント、アプリケーションの起動を行い、フェイルオーバーが完了する。

　稼働系のアプリケーションに障害が発生した場合は、稼働系でアプリケーションの停止、共有データ領域のアンマウント、サービス用IPの停止をした後、待機系でそれらを起動し、フェイルオーバーが完了となる。

メリット

• 物理環境からの移行が容易

　物理環境で使用していたHAクラスタ製品とその設定、アプリケーション監視のためのスクリプトなどをほぼ変更せずにそのまま使用可能である。

• 物理サーバと仮想マシンでのHAクラスタ構成が可能

　2台構成（1対1構成）のクラスタを複数セット構築すると、アプリケーションが稼働していない待機系が複数台存在することになり、システムリソースが無駄になる。物理環境では、物理サーバの台数を削減するために、複数台の稼働系に対応する待機系を1台に兼任させた構成（N対1構成）を組む必要があった。その場合、多ノード構成が可能なHAクラスタ製品を使用する必要があり、ハートビートやクラスタ設定が複雑になりがちだった。

図3　物理環境のN対1 HAクラスタ構成

　待機系の仮想マシンをESXサーバ上に複数構築することで、それぞれのクラスタは1対1となり、構成がシンプルになる。ただし、仮想マシンと物理サーバの共有データ領域はRDM（Raw Device Mapping）で構成する必要がある。

図4　物理サーバと仮想マシン間でのクラスタ構成

• 仮想マシンの電源停止を検知可能

　稼働系／待機系の仮想マシンがハートビートでお互いのOSの稼働状態を監視しているため、OSのハングアップ（※1）、リブートに加え、仮想マシンの電源が停止した場合も検知することができる（※2）。これにより、仮想マシン電源停止時もアプリケーションをフェイルオーバーすることができる。

※1　ここでいうハングアップは、単なる高負荷状態ではなく、「仮想マシンの電源は入っているが、ネットワークとディスクへ読み書きが行われていない状態」を指す。

※2　vSphere HAは仮想マシン電源停止を障害とは認識しない。

デメリット

　仮想マシン間HAクラスタのデメリットについてまとめると下記のようになる。第1回も併せて参照していただきたい。

• vSphere HAと比較して、構成が複雑になる（複数の仮想マシン、共有データ領域、ハートビート専用ネットワーク）
• vSphere HAと比較して、仮想マシンのスナップショットや「vSphere vMotion」「vSphere DRS」などのVMware環境の運用を効率化する機能と併用できない
• 物理環境のようにNIC、HBAのハードウェア障害を検知できない、もしくは検知してもフェイルオーバーできない可能性がある

製品選定ポイント

• Windows、Linuxの両方に対応しているか

　Windows、Linuxの両方に対応し、それらを一元管理できるGUIが容易されているか。さらにUNIXにも対応している場合は、適応できる仮想／物理環境が増え、全体をより一層一元管理することができる。

• 複数のクラスタ間でのアプリケーションの起動／停止の順序が設定できるか

図5　クラスタ間でのアプリケーション起動／停止の順序設定

　一般的なHAクラスタ製品は、1つのクラスタ内でのみアプリケーションの起動／停止順序を定義することができる。製品によっては、複数のクラスタ上のアプリケーション間で起動／停止の順序を設定できる。例えば、データベース（DB）サーバ、アプリケーションサーバ、Webサーバの順でそれができると、自律的な仮想基盤となり、手動作業が減り、運用の簡素化、人為的なミスやダウンタイムの削減につながる。なお、VMwareの機能では仮想マシンの起動順序は制御できるが、アプリケーションの起動順序までは制御できない。

• アプリケーション監視のエージェントが多く用意されているか、アプリケーション監視のスクリプトを作成する場合、作成しやすいシンプルなアーキテクチャか

　仮想化基盤にクラスタを移行する際に、対応エージェントが多いことも重要だが、エージェントが用意されていないアプリケーションを監視する必要が多くなると思われる。その際、アプリケーションの起動／停止、監視を行うスクリプトを作成する必要が出てくるが、それらの仕様、仕組みがシンプルである方がよい。

　起動／停止、監視処理のタイムアウト、リトライなどについて、個々のスクリプト内に繰り返し処理などを直接記述するのではなく、スクリプトにはメインの1回分のみを記述し、タイムアウト／リトライなどをクラスタのパラメータとして設定できるHAクラスタ製品の方がスクリプト作成は用意になる。

また、起動／停止スクリプトの中で正常に実施できたかを判断するロジックを記述するのではなく、起動／停止スクリプトは起動／停止処理のみを記述し、その後の監視処理で、処理の成功／失敗を判断するような仕組みの方がスクリプトの作成がシンプルになる。

• NICの監視方法が柔軟に選択できるか

　NIC監視に、リンクアップ監視、特定IPまたはデフォルトゲートウェイへのping監視などから選択できるか。リンクアップ監視以外の監視を選択できると、物理NIC障害時に、仮想マシン上からそれを検知できる可能性が高まる。

　ESXサーバのNICに障害が発生した際に、その仮想スイッチにひも付いている仮想マシンの仮想NICのリンクをダウンさせるような設定がVMware側で選べるようになれば、仮想マシン上で動作するクラスタ製品によって物理NIC障害を検知させることができるが、現在はそのような機能はない。今後、VMware側の機能追加を期待したい。

• 障害検知時に、仮想マシンを確実に停止できる手段を持っているか

　ESXサーバとデータストア間の経路に障害が発生した際に、稼働系の仮想マシンのサービスを完全に停止できず、フェイルオーバーに失敗する場合がある。フェイルオーバーのためには、障害検知後のサービス停止の失敗は許されない。

　そのためには、クラスタ製品は仮想マシンを確実に停止できる方法を持つべきである。OSの停止コマンドを常にメモリ上に保持できる製品や、VMwareと連携して仮想マシンを停止できるなどである。

• SCSIバス共有を設定しなくても、VMDK、RDMの共有データ領域を持ったクラスタを構成できるか

　SCSIバス共有を設定すると、仮想マシンのスナップショットおよびvMotionができなくなる。これはバックアップやメンテナンスの運用上かなりのデメリットである。SCSIバス共有を設定する際は、スナップショットが存在する場合は削除し、その上、仮想マシンを停止しなくてはならない。このSCSIバス共有を仮想マシンに設定しなくても、HAクラスタ製品とVMwareが連携することで共有データ領域を持ったクラスタを構成できるクラスタ製品は、それができない製品と比較して運用上メリットがあるといえる。

　仮想マシンからiSCSI、CIFS、NFSによって共有データ領域へ接続する場合、もしくはHAクラスタ製品のオプション機能によって仮想マシン間でデータ領域をミラーリングする構成の場合は、SCSIバス共有の設定は不要になる。

• vMotion連携が可能か

　NIC障害など一部のハードウェアコンポーネントの障害の際は、アプリケーションを稼働系の仮想マシンから待機系の仮想マシンへ切り替えなくても、稼働系の仮想マシン自体をvMotionで他のESXサーバに切り替えることで復旧できる。「障害検知→vMotion開始→vMotion完了」の間、サービスのダウンタイムとなるが、アプリケーションの起動／停止が伴わないため、アプリケーションへのインパクトは少ない。2重化されている物理NICやHBAの片方に障害が発生した場合に、それを検知してvMotionが行える製品であれば、サービスダウンのリスクを軽減することができる。

推奨する設計・運用

　HAクラスタを構成している仮想マシンは、複数台のESXサーバに分散して固定で配置し、vSphere HA、DRSの管理下から外すことを推奨する。vMotionで切り替わる際に、クラスタのハートビートの断線を検知してしまう可能性があるからだ。また、クラスタの稼働系と待機系の仮想マシンが同一のESXサーバ上に稼働してしまうと、それが単一障害点（SPOF：Single Point Of Failure）になる。

　また、NIC、HBAについては、ESXサーバ内で2重化し、CIMやサーバベンダーが提供する監視の仕組み、vCenter Serverの通知機能を利用し、障害を検知した際は速やかに交換し、2重障害にならないことを前提とする運用を推奨する。

図6　ハードウェアステータスの確認《クリックで拡大》

　今回は、仮想環境のHAクラスタの課題を解決するための、（1）仮想マシン間HAクラスタの製品選定ポイントについて解説した。運用で回避しないといけない点も正直多々あるが、仮想環境に適したクラスタ製品についてご理解いただけたと思う。次回は、（2）vSphere HAについても同様に紹介する予定である。

木島 亮（きじま りょう）

伊藤忠テクノソリューションズ

ＩＴサービス事業グループ　製品・保守事業推進本部　ＩＴインフラ技術推進第１部　ストレージ技術推進課

2002年、伊藤忠テクノソリューションズ（CTC）入社。
HAクラスタやLinuxの担当を経て、現在、ストレージ／バックアップを担当する。
2008年から、仮想環境上のデータ保護や可用性ついて、技術検証やセミナーを実施し、社内外への啓蒙を行っている。
趣味はウォーキング。12カ月で22キロやせました。