仮想化によってサーバ統合することでサーバ台数を削減し、システムリソースを有効活用しているにもかかわらず、HAクラスタの稼働系／待機系用の仮想マシンをそれぞれ構築する必要がある（※1）。また、HAクラスタの待機系の仮想マシンはホットスタンバイでOSが起動した状態であるため、システムリソース（CPU、メモリ、ストレージなど）の消費に加え、OSライセンスが必要になる。

※1　第3回で説明する「vSphere HA」および「vSphere HA＋アプリ監視」の方式を採用する場合は、待機系用の仮想マシンは不要となる。

Windows、Linuxの仮想マシンでHAクラスタ製品が異なる

　WindowsとLinuxでは主要なHAクラスタ製品が異なる。そのため、それぞれのHAクラスタ製品の操作方法を習得する必要がある上、それぞれのGUIによる管理に手間が掛かる。

HAクラスタ製品のハートビート専用ネットワークが必要

　HAクラスタ製品のハートビート専用ネットワークを用意する必要がある（※2）。ただし、VMwareの機能でネットワークを冗長化した場合、NICは二重障害になってはじめてハートビート全断を検知することになり、NICが二重化されていることの意味をなさない。そのため、HAクラスタ製品の機能で冗長化する必要がある。

※2　「vSphere HA」および「vSphere HA＋アプリ監視」の方式を採用する場合は、VMwareの管理ネットワークがハートビートに使用されるため、個々のHAクラスタ製品のハートビートは不要になる。

図3　HAクラスタ製品のハートビート専用ネットワークの構成《クリックで拡大》

　サービス用ネットワークのNICはVMwareのハイパーバイザーの機能で冗長化し、ハートビート用のネットワークのNICはHAクラスタ製品の機能で冗長化することになり、設計が煩雑になる

　仮想環境はシステムリソースが有効活用できるように設計されていることが多い。裏を返せば、仮想マシンの負荷が高いケースが多い。負荷が高い状況では、HAクラスタ製品のハートビート通信が遅延し、稼働系仮想マシンの障害を誤検知してしまう場合もある。

稼働系／待機系の仮想マシンから参照できる共有データ領域が必要

　稼働系の仮想マシンから、待機系の仮想マシンへサービスを切り替えるには、データを引き継ぐための共有データ領域が必要になる。

　通常のVMDK、RDM（Raw Device Mapping）領域は1台の仮想マシンからのみアクセスが可能で、複数の仮想マシンからのアクセスを許可するためには、それぞれの仮想マシンのSCSIコントローラーに「SCSIバス共有」を設定する必要がある。

図4　共有データ領域の構成

図5　共有データ領域へのSCSIバス共有の設定《クリックで拡大》
仮想マシンの「ハードディスク2」をHAクラスタの共有ディスクにしたい場合は、そこにひも付く「SCSIコントローラ1」の「SCSIバス共有」を［物理］に設定する必要がある

図6　SCSIバス共有を設定すると仮想マシンスナップショットが不可《クリックで拡大》

　SCSIバス共有をすることによって構成として複雑になる上に、仮想マシンのスナップショットが実行できなくなるという重大な弊害も出てくる。

　HAクラスタ製品によってはRDMのクォーラムデバイス（※3）が必須のものもあり、それもまたSCSIバス共有の設定が必要になる。既存の仮想マシンのHAクラスタ化や、新規でHAクラスタ化された仮想マシンを追加する際に、ストレージの設計・設定が必要になるのは非常に手間が掛かる。

※3　HAクラスタのハートビートが全断した際に、両系が稼働状態にならないようにするための仕組み。

仮想環境のHAクラスタの課題2（運用面）

仮想マシンのスナップショットが取得できない

　SCSIバス共有を設定することで、仮想マシンのスナップショットが不可となり、それに伴い、VADPバックアップも取得できなくなる。そのため、可能なバックアップ方法は、ストレージのコピー機能によるバックアップかネットワーク経由のバックアップになる。ストレージのコピー機能によって、バックアップを行う場合でも仮想マシンのスナップショットが取得できないため、仮想マシン内のデータの整合性が確保できない。結局、ネットワーク経由のバックアップになり、効率の悪いバックアップ運用をせざるを得なくなる（参考：【技術解説】仮想化特有の課題がある、VMware環境の“従来型”バックアップ）。

vMotion／DRS／vShpere HA／vSphere FTとの併用が保障されない

　ほとんどのHAクラスタ製品は、物理環境用に開発されたもので、VMware環境上で動作していることを認識せず（意識せず）に動作する。そのため、「vSphere vMotion」などのVMwareの機能と併用した場合、想定外の動作が行われる可能性がある。中には、併用をサポートしているHAクラスタ製品がある。だが、それらの製品のほとんどで、vSphere vMotionなどを認識するためのロジックが組み込まれているのではなく、ただ「併用しても（ほぼ）問題ないでしょう」という意味で「サポート」と言ってるのである。よって、HAクラスタを構成している仮想マシンは、「vSphere DRS」や「vSphere HA」の対象外にすることを推奨する。

仮想環境のHAクラスタの課題3（機能面）

　NIC、HBAを仮想マシン上のクラスタ製品で監視すると以下の課題が生じる。物理NIC、HBAはVMwareのハイパーバイザーの機能で冗長化され、仮想マシン上では単一のNIC、HBAに見える。それらの仮想NIC、HBAをHAクラスタ製品で監視することで、仮想化特有の問題が発生する。

NIC障害時の検知やフェイルオーバーが動作しない場合がある

　NICに障害が起きたとき、その検知やフェイルオーバーが想定通りに動作しない場合がある。これは、ブレードサーバの筺体に搭載されているネットワークスイッチと、個々のブレードサーバとの関係を思い描くと分かりやすい。

図7　仮想環境のNIC障害検知の課題

　筺体のネットワークスイッチの外部ポートに障害が発生した場合、個々のブレードサーバは外部と通信できなくなる。だが、ブレードサーバのNICはスイッチと接続できているので、リンクがアップしたままである。

　これと同様にVMware ESXサーバのNICに障害が発生しても、仮想スイッチに接続されている仮想マシンの仮想NICは、リンクがアップしたままになる。

HAクラスタ製品によっては、NICの監視をリンクがアップしているか否かで判断している。その場合、外部との通信ができないにも関わらず、HAクラスタ製品はネットワークの障害を検知できない。また、ブロードキャストを実施し、その応答を監視している場合でも、同一ネットワーク上の別の仮想マシンが応答を返す可能性もある。しかし、デフォルトゲートウェイなどへのping監視を選択できる製品は障害を検知できる場合もある。

HBA障害時の検知やフェイルオーバーが動作しない場合がある

　実はNICよりHBA（※4）の方が深刻である。

※4　VMwareのデータストアがNFSデータストアの場合は、HBAをそのデータストアに接続されているNICに読み変えていただきたい。

　これは、SANブートしている物理サーバのHAクラスタ環境を考えてみると理解しやすいだろう。

図8　仮想環境のHBA障害検知の課題

　共有データ領域への読み書きを監視しているHAクラスタ製品は、HBA障害を検知することができる。

　障害検知後、まず行われることは、元の稼働系でのサービス停止である。しかし、サーバから見て障害が発生しているHBAの向こう側のストレージに、HAクラスタ製品がインストールされているOS領域がある。すなわちHBA障害時は、サーバのメモリ内のデータだけでOSが動作している非常に不安定な状態である。HAクラスタ製品はサービス停止のためのコマンドを実行しようとするのだが、結果は“コマンドが見つかりません”となる。メモリ上にそのコマンドが存在しないためだ。そのため、HAクラスタ製品としてサービス停止不可能となる。HAクラスタ製品によっては、その後OSの停止を試みるのだが、そのコマンドすら“コマンドが見つかりません”となってしまう。

　HAクラスタ製品の役割は、障害を検知することだけではなく、障害を検知した後にサービスをフェイルオーバーさせることである。フェイルオーバーとは、元の稼働系でサービスを停止し、待機系でサービスを起動することである。大事なことは、「障害が発生した稼働系でサービスを停止した後」に、「待機系でサービスを起動する」ということである。停止できなければフェイルオーバーできない。停止しないまま起動すると両系稼働状態になり、共有データ破壊につながるため、通常のHAクラスタソフトはこれを許していない。

　この状況を回避するために、OS領域と共有データ領域を、別のデータストアに配置することを推奨しているHAクラスタ製品もあるが、それは現実的ではない。

　本連載の第1回では、物理環境用のHAクラスタ製品をVMware環境に使用した際に直面する課題について説明した。本課題を理解した上で、仮想環境でHAクラスタを設計・運用している方も、今回初めて課題を認識した方もいると思う。

　今回は少しネガティブな内容だったが、次回以降では、課題が多い仮想環境のHAクラスタについてどのように方式および製品を選定していくべきかを整理していく。

　第2～4回では、vSphere HAを含めた仮想環境の3つHAクラスタ方式に関して動作、特徴、製品選定のポイントについてまとめる。第5回ではHAクラスタ製品の機能比較を行う。最後までご覧いただけると幸いである。

木島 亮（きじま りょう）

伊藤忠テクノソリューションズ　クロスファンクショングループ

ITエンジニアリング室　プラットフォーム技術部　ストレージ基盤技術課

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