フォールト トレランス(FT)機能のメリットとデメリットを正しく理解しよう

さて、フォールトトレランス（FT）機能のメリットは、完全無停止の環境が構築できる点です。
FT機能を使える場所とはどういったシーンで活躍できるのでしょうか？
まずは、VMwareのドキュメントを読んでみますと、

より高度なレベルの継続性、および状態情報やデータ保護の強化により、フォールト トレランスをデプロイするタイミングのシナリオが通知されます。

• アプリケーションを常に利用できるようにしておく必要がある場合 （特に、ユーザーがハードウェアの障害中も維持しておきたい、長期にわたるクライアント接続があるアプリケーション）。
• カスタム アプリケーションで、これよりほかにクラスタリングを行う方法がない場合。
• カスタム クラスタリング ソリューションによって高可用性が提供されるが、これらのソリューションが複雑で構成および保持できない場合。

 と記載があります。

(参考）Fault Tolerance の使用事例
http://pubs.vmware.com/vsphere-60/index.jsp#com.vmware.vsphere.avail.doc/GUID-54BD5561-C79E-4845-8C13-AE88C9CB6681.html

FTは、高可用性な環境がアプリケーションの変更が一切不必要で構成できるという点では,確かにこれに勝る高可用性は無いと思います。

ただ、これはデメリットにもなり得るケースがあります。
FTで、カバーができない点を見ていきましょう

•  アプリケーションサービスの異常終了の検知
  （昔はApp-HA機能があったがvSphere6で廃止）
• OSのBSOD/Kernel Panic
  （VM-HA機能により仮想マシンリセットが行われる）
• パフォーマンスの問題

要するに、アプリケーションやOSなど、 仮想マシンより上のレイヤーの障害を検知できないため、上位レイヤーでの障害があってもその状態を常にミラーし続けることになります。

仮にFTで同期をとっているアプリケーションサーバーがログファイルでディスクフルになってしまい、サービスアプリケーションが落ちた場合、同じ仮想マシンが同期されているため、待機系の仮想マシンでもディスクフル状態のためサービスアプリケーションは起動できない状態になります。
つまりこの場合、メンテナンスをユーザーがしない限り障害は完了しません。
これは、OSレイヤーのクラスターの場合は、サービスの異常終了を検知して、待機ノードでサービスが起動させることができます。ログディスクを共有ディスクでない場所に保存しておけばその影響も受けません。
また、OSの異常状態になった場合、FTの場合はOS再起動になるため、OS起動までの時間サービス無停止となります。この場合もOSレベルでクラスターを組んだ場合は、稼働ノード停止を検知したら、すぐに待機ノードでVIPを引き取り、サービスが起動が行われます。

パフォーマンスの問題も重要です。
vSphere6のFT機能は、10Gbpsのロギングネットワークで、CPU/RAM/ディスクIOのいわゆる仮想マシンのすべての命令を同期します。
仮に共有ディスクI/Oが10GpsのiSCSI等の場合、ディスクバスでDiskI/Oが10Gbps出ていますが、同期側はディスクI/O以外にもメモリーやCPU命令を同期するため、その遅延に足を引っ張られる可能性が有り、パフォーマンスとしては、  シングル構成に比べて劣る可能性があります。
この場合はOSクラスター（共有ディスク構成の場合）やVM-HAの場合は、同期がそもそも不要なため、このようなパフォーマンスの心配も不要です。

このため、アプリケーションの高可用性を考えた場合、FTよりもOSレベルのクラスターの方がメリットが出るケースもあります。

手軽なOSクラスターとしては、やはりWindows Serverに標準で搭載されている、「Microsoft Windows Fault Tolerance Cluster （通称:MSFC/WSFC）」でしょう。

でも、WSFCをvSphereで利用する時は、RDMで物理互換モード利用が必須なんで、メンテナンス性が悪いよねと言われていました。（かといって今時物理サーバーで構成するのもナンセンスだし）

しかし、vSphere6からは、RDM物理互換モード構成であってもvMotionがサポートされましたので、メンテナンス性も今までの仮想マシンと同じようにできます。

高可用性と行っても要件によってよく吟味する必要があります。

簡単にメリット・デメリットをまとめておきました。

機能	メリット	デメリット	適用範囲
VM-HA (VM High Availability)	・可用性が組めないアプリにおいても簡易的に可用性を担保できる	・停止が発生するとOSの再起動が発生するため、最低でもOS起動までの停止時間が発生する。 ・OS破損の場合は、回復できない。	可用性がとりあえず担保できればよいレベル （多少の停止時間が合っても問題ないレベル）
VM-FT (VM-Fault Tolerance)	・可用性が組めないアプリにおいても簡易的に可用性を担保できる ・物理ハード障害の場合、完全無停止でフェールオーバーが可能	・OSやアプリケーションレベルの障害の場合、検知ができない/時間がかかるケースがある。 ・OS破損の場合は、回復できない。 ・VM-HAに比べてパフォーマンスが落ちる ・HAに比べて、待機ノードも稼働しているためリソース効率がよくない	VM-HAよりも高可用性を望まれる場合
WSFC/MSFC (OSクラスター)	・アプリケーションの異常終了においてもフェールオーバーが可能 ・メイン系がOS異常による障害であっても待機系で稼働が可能	・待機ノードが必須のためリソース効率がFTほどではないがよくない。 ・OSクラスターに対応していないアプリケーションは利用できない。 ・構築が複雑	アプリケーションサービスの停止時間を限りなく短くしたい

冗長化（高可用性機能）は、適材適所で選びましょう！