Win2K8サーバーMPIOiSCSIフェイルオーバーが機能しない
Windows 2K8ServerラボシステムとNetAppファイラーの間で2つの別々のネットワークスタック*を介してiSCSIトラフィックを通過させたいと考えています。
私の構成は次のとおりです。
- iSCSIソフトウェアイニシエーターがインストールされ、MPIOコンポーネントがインストールされ、2つのネットワークインターフェイス（192.168.201.85/24および192.168.202.85/24）を備えた1つのWin2K8サーバー
- windowsサーバーのIQNに公開されたLUNを備えた1つのNetAppファイラー、および192.168.201.200/24と192.168.202.200/24の2つのインターフェイス
- 2つの別々のスイッチ。1つは192.168.201.0/24用、もう1つは192.168.202.0/24用です。どちらもフラット（VLANなし）であり、他のネットワーク機器に接続されていません。
ISCSIソフトウェアイニシエーターの「アダプター」クラスを登録するようにMPIOコンポーネントを構成しました。
次に、iSCSIイニシエーターのコントロールパネルに移動し、両方のファイラーアドレスを「ターゲット」として追加し、それらに対して検出を実行しました。これは、使用可能な単一のLUNを示しています。
次に、LUNに2回「ログオン」し、接続ごとに異なる「送信元」IPアドレスを選択しました。両方の接続で「起動時に再接続」がチェックされ、「MPIO」がチェックされています。
ターゲットを調べると、NetAppが使用しているIPアドレスごとに1つずつ、ターゲットへの2つの接続が表示されます。
持続的接続を調べると、NetAppが使用しているIPアドレスごとに1つずつ、合計2つの接続が表示されます。
（この時点で、各IPへの単一の接続を示し、そのIPを介してドライブをマウントして使用することにより、両方のファイラーIPをテストしたことを述べておく必要があります。）
次に、Disk Manglerに移動し、LUNにパーティションを設定して、オンラインとしてマークします。ディスクは期待どおりに機能します。
次に、新しいディスクのプロパティに移動し、[MPIO]タブをクリックします。このディスクで使用されている2つの接続を確認できます。ただし、このタブに表示される接続をiSCSIイニシエーター画面に表示される接続に関連付ける方法がわかりません。したがって、iSCSIイニシエーター画面の接続ごとに1つの接続があると思いますが、それを証明することはできません。 。
[MPIO]タブには、いくつかのオプションがあります。
タイマーをすべて1秒に短縮し、パス検証を有効にしました。したがって、これらの設定についての私の理解は、次のことを意味します。
- windowsサーバーは毎秒、パスが有効であること、つまりリモートターゲットIPが正しく応答していることを確認します。
- サーバーは、障害が検出された後、障害が検出されてから1秒後に1回だけ再試行します。
- サーバーは無効としてマークを付け、障害の1秒後にパスを削除します。
冗長性に関して、私が試したことがいくつかあります。
- 両方の接続をアクティブ/アクティブとして設定し、ラウンドロビン使用を選択すると、ディスクは機能します。ディスクにコピー操作を設定し、ネットワークケーブルの1つを抜いてネットワーク障害をシミュレートすると、接続は約30秒間停止し、その後続行します。
- 1つの接続をスタンバイ/パッシブとしてマークし、フェイルオーバーのみを選択して接続をフェイルオーバーのみとして設定すると、接続は再び機能します。 （興味深いことに、ディスクからディスクへのコピーは、ラウンドロビンの約2倍の速度で一貫して流れるように見えますが、とにかくです。）スタンバイケーブルを引き抜いて障害をシミュレートすると、接続は約1秒間停止し、その後続行します。 。アクティブケーブルを引き抜いて障害をシミュレートすると、接続が停止し、どちらのワイヤでもファイラーにpingを実行できません。最終的に、OSはディスクに障害が発生したことを通知します。ネットワークは数時間この状態のままです（その後、私はそれを待つのに飽きてサーバーを再起動しました）。
調査を行ったところ、Win2K8およびVistaのMPIO.sysドライバーのカウンターエラーが原因でフェイルオーバーが完了しないというMicrosoft KB 968287が見つかりましたが、この修正プログラムをインストールしても、表示される内容は変わりません。
これらすべてが、私が根本的な何かを見逃しているのではないかと私に思わせます。私はこれを間違っていますか？
ここでの本当の目標は、VMを実行し、Hyper-VクラスターにExchangeストアをマウントするためのより信頼性の高いiSCSIトランスポートを提供することです。特にExchangeは、ディスクの一時的な中断が検出された場合に情報ストアを非常に迅速にアンマウントすることを知っているため、1つのパスに障害が発生した場合でも、MPIOがデータのフローを許可することを期待していました。
* =現在1つのiSCSIスイッチがありますが、それが誤動作し始めたとき、1つのスイッチのファームウェアをフラッシュするために全世界を停止する必要がありました。したがって、2つの完全に分離されたネットワークパス（NIC、スイッチ、およびもう一方の端のインターフェイス）が必要です。これにより、世界を殺すことなく、メンテナンスのためにそれらの半分をいつでもサービス停止にすることができます。
私の理解では、Netappの7モードでは、2つのパスでIOを送信している場合でも、各LUNに優先パスがあります。効果的に実行しているのは毎秒送信ですIO追加のホップを介して、他のコントローラーが相互接続を介してそのLUNのプライマリコントローラーにリダイレクトします。観察している30秒の遅延は、ハードクラスターを完了するのにかかる時間である可能性があります。ノードの乗っ取り。
8モードは今のところおもちゃ以上のものではありませんが（Netappのアルファテストを好む場合を除いて、7モードが唯一の現実的なオプションです）、イーサネットインターフェイスを含むファイラーのいくつかのレイヤーを仮想化することでこの問題を修正します。
ISCSIまたはその他のブロックプロトコル用の真にアクティブなアクティブボックスが必要な場合は、Netappは必要ありません。テイクオーバー時間の保証はなく、過去30秒よりもはるかに長い時間がかかるのを見てきました。