4.動作確認および動作検証
4-2.可用性
4-2-1.VMWare HA
4-2-2.VMWare FT
！コメント！
ここでは、VMWare HA(以下、HA)とVMWare FT(以下、FT)の動作を確認していきます。
以下、かなり乱暴な書き方ですが、HAとFTの違いについて記載します。
HA 
ホスト障害が発生した際、仮想マシンを自動的に復旧させます。
但し、仮想マシンの再起動(厳密には再起動ではないため、以下の例を参照)が伴います。
1台のホスト上にて仮想マシンを稼動させておきます。
例
esx41＝Ludwig-128
esx42＝
esx41に障害が発生した際、esx42にて仮想マシンが自動的に起動(※1)します。
このため、障害発生から復帰までにはそれなりの時間(※2)を要します。
※1
esx41側の仮想マシンの対応については、以下のオプションで設定可能です。
また隔離とみなすまでの時間も設定できるようですが詳細はマニュアルを参照してください。
※2
障害発生後、esx42で仮想マシンが起動しサービスを開始するまでの時間
FT
ホスト障害が発生した際、仮想マシンを自動的に復旧させます。
但し、仮想マシンの再起動は伴いません。
2台のホスト上にて仮想マシンを2台同時に稼動させておきます。
例
esx41＝Ludwig-128(Primary)
esx42＝Ludwig-128(Secondary)
2台の仮想マシンのうちPrimary側の変更情報(HDDやメモリ上のデータ)は
Secondary側と常に同期された状態を保ちます。
ここでesx41に障害が発生しても、ほぼノンストップでesx42上のSecondaryに引き継ぎます。
このため、HAよりも復旧の時間は短くなります。
但し、HAと比べて2倍のリソース(CPU,メモリ,データストアなど)が必要となります。
詳細は以下のマニュアルを参照してください。
http://www.vmware.com/files/jp/pdf/vsp_40_u1_availability_ja.pdf
また、以下のURLも参考になると思います。
VMware HAによる可用性の向上
http://www.atmarkit.co.jp/fserver/articles/vmwaredep/15/01.html
無停止環境を実現するVMware FTとは
http://www.atmarkit.co.jp/fserver/articles/vsphere/05/01.html
4-2-1.VMWare HA
！コメント1！
上記の通り、HAの場合は障害発生後、仮想マシンを自動的に起動させます。
これに伴い、前項にて実施していた確認ポイントのうち、音声ストリーミングは未確認とします。
音声ストリーミングアプリの仕様上、サービスとして稼動しないため、
仮想マシンの起動と同時に音声ストリーミングを開始できないからです。
！コメント2！
検証の流れは以下の通り。
esx41＝Ludwig-128
esx42＝
1.ホストesx41上で稼働中の仮想マシンLudwig-128に対して、クライアントPCからExPingを開始
2.esx41が接続されているスイッチのポートをshut
3.ExPingにて通信断発生
3.vCSがesx41の障害を検知
4.esx42にてLudwig-128が起動
5.ExPingにて復旧を確認
6.esx41が接続されているスイッチのポートをno shut
7.vCSがesx41の復旧を検知
8.esx42とLudwig-128に影響が無いことを確認 ※
※
原則として、今回の構成&設定では、Failbackは発生しません。
ACP(アドミッションコントロールポリシー)の設定や
VMWare DRSとの連携による仮想マシンのリソース設計を駆使することで、
Failback可能な構成を構築することは可能かもしれませんが。
1.クラスタ(wolfgang)を右クリック→設定の編集をクリック
(本書の最初から構築している場合には設定済みですので飛ばしてください)
2.クラスタ機能を選択→以下の図の通り設定
3.VMWare HAを選択→以下の図の通り設定
4.仮想マシンのオプションを選択→以下の図の通り設定
5.仮想マシンの監視→以下の図の通り設定
6.VMWare EVCを選択→特に設定無し
7.スワップファイルの場所を選択→以下の図の通り設定→OKをクリック
8.esx41上にて仮想マシンを起動
仮想マシン(Ludwig-128)を右クリック→コンソールを開くを選択
9.esx41.luxion.biz上のLudwig-128」と表示。
10.クライアントPCからExPing開始→esx41が接続されているスイッチのポートをshut
11.結果
仮想マシンのコンソールが「esx42.luxion.biz上のLudwig-128」に変更されていることを確認
収束時間
57秒
通信断時間
57秒
！コメント！
　障害発生前から開いていたコンソール画面が操作不能になる場合があります。
　この場合は一度コンソール画面を閉じてから再度開いてください。
12.esx41が接続されているスイッチのポートをno shut
　 esx42と仮想マシン(Ludwig-128)に影響が無いことを確認
！コメント1！
vCSにてesx41の復旧が検知された後、esx41のHAエージェントが再構成され安定するまでの間、
コンソール画面左上の表示「esx42.luxion.biz上のLudwig-128」が
esx41に変わったりesx42に戻ったりといった事象を繰り返す場合があります。
以前(vSphere4 Update1より前)のVerでは、上記の事象に加え、
仮想マシンへの疎通ができなくなるといった不具合らしい動作(※)を確認しました。
※
esx41とesx42間で仮想マシンの制御を掴み合うような動作が発生
しかし、今回のVerでは上記の事象のみなため、取り合えずはOKとしますが、
HAに対してあまり大きな信頼をするのは微妙なところです。
以下、少々余談ですが、「微妙」と判断した検証結果を記載しておきます。
私の使用しているコンポーネントがしょぼいからなのか？
そもそも手順や設定が誤っているのか？
あまり詳細な点まではツッコミませんが、実環境においては事前検証が必須と考えます。
！コメント2！
ちなみに
A.esx41が接続されているSWのポートshut
B.仮想マシン(Ludwig-128)がesx42へ正常に移行したことを確認
C.esx41をReboot ←この操作を追加
D.esx41の起動確認 ←この操作を追加
E.esx41が接続されているSWのポートno shut
とした場合、
esx42にて以下のアラームが表示されました。
「Euphonium内のクラスタWolfgangのホストesx42.luxion.biz上の
HAエージェントにエラーがあります。：ホストでHAエージェントが失敗しました。」
ただし、esx41には特にアラーム表示無し。
仕方が無いので、
esx42上で起動中の仮想マシンのshutdown(※)を実施。
esx42をメンテナンスモードへ切り替え。
esx41をメンテナンスモードへ切り替え後、再度Rebootを実施。
esx41&esx42でメンテナンスモードを終了。
した結果、
正常なステータスとなりました。
※
仮想マシンをesx42→esx41へVMotionしようと試みましたが
esx41の起動時にiscsi01を認識しなかったようでVMotionできませんでした。
（ESXの起動プロセスを見ている限り、ESXは起動時にiSCSI targetを探しに行くためと想定)
！コメント3！
このままでは引き下がれないので、以下の手順に変えてみました。
A.esx41が接続されているSWのポートshut
B.仮想マシン(Ludwig-128)がesx42へ正常に移行したことを確認
C.esx41をReboot ←この操作を追加
D.Reboot中に、esx41が接続されているSWのポートno shut ←順番を入れ替えた
E.esx41の起動確認 ←順番を入れ替えた
とした場合、
上記コメント2と同様でした。
ただし、esx41には特にアラーム表示無し。
仕方が無いので、
esx42上で起動中の仮想マシンをesx41へVMotionを実施。
esx42をメンテナンスモードへ切り替え。
esx42のRebootを実施。
esc42起動後、メンテナンスモードを終了。
した結果、
esx42にて以下のアラームが表示されました。
「Euphonium内のクラスタWolfgangのホストesx42.luxion.biz上の
HAエージェントにエラーがあります。：HAの構成を完了できません」
ただし、esx41には特にアラーム表示無し。
さらに仕方が無いので、
esx41上で起動中の仮想マシンのshutdownを実施。
esx41&esx42をメンテナンスモードへ切り替え。
esx41&esx42にてRebootを実施。
esx41&esx42でメンテナンスモードを終了。
した結果、
正常なステータスとなりました。
4-2-2.VMWare FT
！コメント1！
HAと異なりFTの場合は障害発生後、ほぼノンストップでSecondaryに引き継ぎます。
このため音声ストリーミングも確認項目に加えます。
確認ポイントは「4.動作確認および動作検証」のコメント2に記載した内容を踏襲します。
！コメント2！
検証の流れは以下の通り。
esx41＝Ludwig-128
esx42＝
1-1.esx41上で稼働中の仮想マシンLudwig-128に対して、クライアントPCからExPingを開始
1-2.esx41上で稼働中の仮想マシンLudwig-128にて、Mcastストリーミングを開始(クライアントPCにて受信)
2.esx41が接続されているスイッチのポートをshut
3-1.ExPingにて通信断発生
3-2.クライアントPCにて音声断発生
4.vCSがesx41の障害を検知
4.esx42にてLudwig-128が引続き稼動を継続
5-1.ExPingにて復旧を確認
5-2.クライアントPCにて音声復旧
6.esx41が接続されているスイッチのポートをno shut
7.vCSがesx41の復旧を検知
8.Ludwig−128にて瞬断レベルの影響有り※
※
原則として、今回の構成&設定では、Failbackは発生しません。
HAのときと同様です。
確認ポイント1
収束時間＝開始から終了までに要した時間(vCSの最近のタスクに開始時刻と終了時刻が表示される)
確認ポイント2
通信断時間＝クライアントPCにてExPingを開始した後の通信断時間を計測
音声断時間＝クライアントPCにて音声ストリーミング受信を開始した後の音声断時間を計測
1.FTの構成1
仮想マシン(Ludwig-128)を右クリック→フォールトトレランス→フォールトトレランスをオンにするをクリック
2.FTの構成2
はいをクリック
！コメント！
はいをクリック後、実測値約38分掛かりました。
理由はデータストアのプロビジョニング方法がシン→シックに変更されるからです。
3.FTの構成3
完了すると、下図のように画面右下にフォールトトレランスの項目が表示されます。
仮想マシンを起動することにより、正常なステータスに変化しますので、仮想マシンを起動してください。
4.FTの構成4
仮想マシンが起動すると、画面右下のような表示となります。
5.esx41上にて仮想マシンを起動後、
仮想マシン(Ludwig-128)を右クリック→コンソールを開くを選択
「esx41.luxion.biz上のLudwig-128」と表示。
下図は音声ストリーミング開始後の画面となります。
また、クライアントPCから仮想マシンへExPingによる通信を開始します。
6.esx41が接続されているスイッチのポートをshut
7.結果
仮想マシンのコンソールが「esx42.luxion.biz上のLudwig-128」に変更されていることを確認
収束時間
1秒
通信断時間
2秒
音声断時間
21秒＝完全無音状態
32秒＝音声が安定するまでに要した時間
0秒後(音声断)　→完全無音状態→　21秒後（音声復帰）→その後、数秒おきに音声途切れ発生→　32秒(完全復帰)
vCS上においては以下の表示(画面右下)となります。
8.esx41が接続されているスイッチのポートをno shut
9.結果 その2
仮想マシンのコンソールが「esx42.luxion.biz上のLudwig-128」のまま変更されていないことを確認
収束時間
18秒
通信断時間
2秒
音声断時間
2秒＝完全無音状態
0秒＝音声が安定するまでに要した時間
0秒後(音声断)　→完全無音状態→　2秒後（音声復帰）→音声途切れ無し＝完全復帰となる
vCS上においては以下の表示(画面右下)となります。
esx41が復帰してもセカンダリの場所：esx41.luxion.bizであること=Failbackしないことが肝です。
！コメント！
かなり優秀です。
リソースを2倍使用しているだけの結果となりました。
試しに「スイッチのポートをshut」ではなく、
電源ボタン長押しにてesx41の主電源を強制的に落としましたが結果は変わらずでした。
電源復旧時も同様の結果でした。
(スイッチではないので電源コードのぶち抜きはご容赦ください；；)
HAよりも可用性は高いと判断して良いと思われます。