仮想化基盤の規模が大きくなってくると、可用性についてもさまざまな要件が求められる。1つの方式だけでは要件を満たせない仮想マシンが出てきたり、逆に過剰なライセンス投資になるケースもある。

　大前提として、全体の構成が極力シンプルになるように設計するべきである。下記の方針を参考にしていただきたい。下記の例では、vSphere HAの使用を前提としている。

　上記の方針をベースとした上で、仮想マシン間HAクラスタは下記に該当する場合のみ選択し、最小限の採用にとどめることをお勧めする。

※1　障害検知およびフェイルオーバーが想定通り行われるかどうかは、使用するHAクラスタ製品で必ず検証して確認すること。

仮想マシン間HAクラスタ製品の機能比較

　以下、仮想マシン間HAクラスタの主要な製品について比較する。

表5　仮想マシン間HAクラスタ製品の比較表（2014年5月、筆者調べ）

　比較項目は、仮想マシン間HAクラスタを構成する際に着目するべき項目のみに絞った。その他の機能については、本稿末の各製品ドキュメントを参照してほしい。特筆するべき点は以下である。

Symantec Veritas Cluster Server（VCS）

　VMwareと連携しながら動作するHAクラスタ製品が少ない中で、「Symantec Veritas Cluster Server」（VCS）は、VMware環境との親和性が高いといえる。SCSIバス共有の設定なしで、共有データ領域を持ったクラスタを構成できる（※2）。それにより、仮想マシンのスナップショット、vMotion、VADPバックアップが可能になる。

※2　VCSのVMwareDisksエージェントの機能による

　対応OSが多い上に、異種OSのVCSクラスタ間、VCSとMSFC（Microsoft Failover Cluster）間でもサービス起動／停止順序が設定できる（※3）。それにより、自律的なデータセンターを構成することができる。管理者による手作業を減らすことができ、障害発生時は、より短時間での復旧が期待できる。

※3　RemoteGroupエージェントまたはVirtual Business Service（VBS）の機能による

　しかし、NIC監視についてはVMware環境には向いていない。リンクアップ監視を無効にすることはできるが、監視動作で必ずブロードキャストpingを実行する仕組みになっており、NIC障害時も同一ESXサーバ上の仮想マシンが応答を返し、NIC障害を検知できない可能性がある。

　また、商用UNIXのSolarisが全盛期だったころに、厳しいサービスレベルを担保してきた実績があるにも関わらず、IAサーバや仮想環境において国内での知名度が低いのが筆者個人の意見としては残念である。

サイオステクノロジー LifeKeeper

　サイオステクノロジーの「LifeKeeper」は、非常に多くのLinuxディストリビューションのバージョンに対応している他、多数のOSSや商用ソフトウェアとの連携エージェントを提供している。また、エージェントが用意されていないアプリケーションを監視するための汎用エージェント（Generic ARK）の開発およびサポートサービスも提供している。さらに、多数のクラウドサービス上で使用するための手順書を公開しており、クラウドサービス上での使用を想定した提供形態も今後予定されている。

　ただ、残念なのが下記の点である。仮想環境は物理環境に比べて、高負荷になりやすく、アプリケーション監視処理が想定時間内に完了しない可能性もある。LifeKeeperの監視処理にはタイムアウトの仕組みがあるが、タイムアウトが発生した場合も、それを異常とは認識しない。そのため、アプリケーションがハングアップしている場合でも異常を検知できず、何度も監視処理を繰り返してしまう可能性がある。また、起動や停止処理のリトライを行いたい場合も、クラスタのパラメータとして設定できるのではなく、スクリプト内でリトライ処理（繰り返し処理）を記述しないとけないので、スクリプト作成が複雑になる。下記のように、VCSの汎用エージェント（ScriptAgent）で準備するスクリプトと比較して、複雑なことが分かるだろう。

図1　スクリプト例：LifeKeeperとVCSの比較

NEC CLUSTERPRO

　vSphereのバージョン 5.0からは管理OSのサービスコンソールが廃止された。しかし、現在のバージョンでもvMA（VMware vSphere Management Assistant）を導入すれば、ほぼ同様のことが可能になる。NECの「CLUSTERPRO」をvMAにインストールし、そのvMA間でクラスタを構成することがサポートされている。それにより、仮想マシン上からではなくvMA上から物理NICや、データストアへの経路障害を検知できるようになる。NICやHBAが2重化されている環境で、それらの片方に障害が発生した場合に、仮想マシン上からはその障害を検知することはできないが、vMA上からはそれを検知できる。その際、仮想マシンをvMotionで別のESXサーバに切り替えることができ、サービスダウンのリスクを減らすことが可能だ。また、2重障害の際はESXサーバをリセットし、vSphere HAの仮想マシン切り替えを発動させることができる。さらに、ドキュメントが充実しており、検証資料や仮想環境でのベストプラクティスなどがWebサイトに公開されている。

　だが、vMA間HAクラスタ、仮想マシン間HAクラスタ、vSphere HAの全てを併用することを最も推奨しているが、構成が複雑になると思われる。

図2　CLUSTERPRO推奨構成

　しかし、vMAにインストールすることをサポートしているHAクラスタ製品はCLUSTERPRO以外に類を見ないため、今後、よりシンプルな構成が組めるようになることと、CLUSTERPROの1台構成用の製品である「Single Server Safe」（SSS）が「vSphere HA＋アプリ監視」に対応することを期待したい。

vSphere HA＋アプリ監視製品の機能比較

　続いて、vSphere HA＋アプリ監視を実現する主要な製品について比較する。

表6　vSphere HA＋アプリ監視製品の比較表（2014年5月、筆者調べ）

　VMwareの新機能「vSphere App HA」がリリースされたことで、この方式の知名度と利用頻度も上がってくるだろう。この新しい方式と思われがちなvSphere HA＋アプリ監視は、仮想マシン間HAクラスタを仮想マシン1台で構成し、vSphere HAとの連携機能を追加したものにすぎない。vSphere HA＋アプリ監視を実現する「アプリ監視製品」を選定する際は、新しい製品として調査するのではなく、ベースに採用されているHAクラスタ製品や監視製品の成熟度を確認すべきである。

Symantec ApplicationHA

　これらの製品の中で、Symantecの「ApplicationHA」が現時点では、最も優れているといえるだろう。ApplicationHAは2010年10月のリリースで、製品として安定してきている。ApplicationHAで保護されたアプリケーションとVCSで保護されたアプリケーションとの間でサービス起動／停止順序が設定できる他、監視の仕組みがVCSと同一アーキテクチャであるため、アプリケーション監視用のスクリプトが修正なしで使用可能である。

　ApplicationHAとVCSを使用することで、冒頭で記述したVMware環境のHAクラスタの全グレードに対応できる。また、ApplicationHAとVCSを一元管理できるGUIも用意されているため、運用がシンプルになる。

　その他、Symantec Backup Execと連携して、仮想マシンのリストアを自動化できる。ApplicationHAがアプリケーションの再起動、仮想マシンのリセットを行っても、アプリケーションを復旧できなかった場合、仮想マシンをリストアし、システムを復旧することができる。

　また、VMware vCenter SRM（Site Recovery Manager）と連携し、サイト間で仮想マシンを切り替えた後に、仮想マシンごとのアプリケーション起動順序や正常に起動できたかのステータス確認を行うことができる。その他のハイパーバイザーにも対応しているため、VMware以外を含めたマルチハイパーバイザー環境においてもアプリケーションを一括管理できる。

サイオステクノロジー LifeKeeper Single Server Protection（SSP）

　サイオステクノロジーの「LifeKeeper Single Server Protection（SSP）」は、旧vAppkeeperの後継製品である。VMware以外のハイパーバイザーにも対応しているが、現在はLinuxのみのサポートで、Windowsはサポートしていない。監視の仕組みなどはLifeKeeperと同等であるため、物理環境のLifeKeeperクラスタからの移行は容易だろう。

vSphere App HA

　2014年5月リリースされたApp HA バージョン1.1によって、監視エージェントが用意されていないアプリケーションもカスタムサービスとして登録できるようになった。このバージョンでOracle DatabaseやPostgreSQLにも対応した。ただ、App HAのベース部分に採用されている監視製品である「VMware vFabric Hyperic」を使用したことがない方は、監視の仕組みが想定通り行われるかをしっかり検証することを推奨する。

　本連載では、VMware環境のHAクラスタ製品の選定ポイントとして、課題、方式選定、製品比較を紹介してきた。

　物理環境から仮想環境に移行する際の可用性設計の考え方は2つある。1つ目は、物理環境で使用していたHAクラスタ製品を仮想環境上においても採用し、監視スクリプトなどの移行コストや教育コストを最小限に抑える考え方である。2つ目は、VMware環境に特化したvSphere HA＋アプリ監視製品を積極的に採用し、構成の簡素化、運用の効率化を目指す考え方である。筆者としては後者の考え方を推奨したい。

　物理環境では、単一サーバ内のハードウェアコンポーネントを2重化した上で、HAクラスタを構成し、それらのハードウェア2重障害も想定し、確実にフェイルオーバーさせる要件が当たり前だった。仮想環境では、それらの2重障害への対処を物理環境と同様には行えず、運用で回避する必要がある。ミッションクリティカルなシステムの仮想環境へ移行する際は、その点をご注意いただきたい。

　最後に、今回の記事を書くに当たり、各メーカーの問い合わせ窓口に、機能について詳細な質問をさせていただいた。丁寧な回答に加え、参考になる資料を提示いただき、私自身の理解も大変深まった。以下に、参考になる資料のURLを紹介し、連載を締めくくりたい。

木島 亮（きじま りょう）

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

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

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