openfilerのiSCSIにおけるマルチパス障害テスト

避けては通れないiSCSIのマルチパス障害テストを行いました。

[サーバ側]
ESX3.5
eth0 一般ネットワーク (192.168.0.0/24)
eth1 iSCSI用パスA (10.1.0.0/16)
eth2+eth3 iSCSI用パスB (10.0.0.0/16)

[iSCSIターゲット]
Openfiler2.3
eth0 メンテナンス用ネットワーク (192.168.0.0/24)
eth1 iSCSI用パスA (10.1.0.0/16)
eth2+eth3 iSCSI用パスB (10.0.0.0/16)

一般用、パスA、パスBすべてが別々のHubに接続されています。
通常時はパスBで接続しておいて障害時のみパスAに切り替えようという構成です。

ESXで正常に認識されている状態では下のように合計2破損0となっています。

また、優先設定はテストにあたってパスAに設定しておきます。
パスBだとLANケーブル2本抜かないとダメで面倒なので＾＾

この状態で、仮想マシンを走らせHDDへアクセスするためにCrystalDiskMarkを
500Mｘ9回の設定で実行しておきます。
実行中にパスAのLANケーブルを抜いてHDD障害を発生させると下のように合計2破損1
と表示がかわり切り替わっているのがわかります。

切り替わるまでに数秒〜十数秒かかっているようで仮想マシンは止まったように思えます。
実際に、HDDの負荷グラフを見ると一時的にHDDアクセスが止まっているのがわかります。

このあとLANケーブルをもどすと初期状態にもどるのですがその際にアクセスが
止まるようなことはありませんでした。（グラフを見る限り）
またWindowsのイベントログには障害イベント等はとくに見あたらなかったので
OSからはHDDの軽微な遅延か一時的なアクセス不可状態と見えるようです。

万が一の際の保険的機能なので十分な動作性能でしょう。
すくなくとも仮想マシンが全部死んで一斉にfsckという悲惨な事態は避けられるのではないでしょうか？

要検証項目
今回は、LANケーブルを物理的に切断しましたがリンクした状態のまま故障等で通信不可に
なったりした場合にも正常に動作するかどうかは検証の必要があるかと思います。
そういう状況を作り出すのが難しいので今回は検証しませんでした。
大抵障害が発生するのは、HUBの設定をいじってたとか配線整理してたとか自業自得な場合が
多いので個人的にはこれで十分とも言えます・・・