Hyper-VのリダイレクトI/Oを動作確認してみた

Hyper-Vでは、ストレージのI/Oをネットワーク経由で別ノードにリダイレクトするという機能がある。これはHyper-Vの共有ボリュームの機能であるCSV(Cluster Shared Volume)にて実装される機能となり「リダイレクトI/O」と呼ばれる。ディスクI/Oをネットワークに流すという動作は、vSphere環境のVMFSではできないので非常に新鮮に感じる。

リダイレクトI/Oでは、ディスクI/Oが一度別ノードを経由することからディスクI/O遅延を引き起こすものとなるため、通常はストレージ障害発生時に利用される。

今回実際に疑似的な障害を発生させ、リダイレクトI/Oが動作することを確認してみた。

Hyper-V環境

環境は以下の通りとなる。2台のWindows Server 2019のHyper-Vノードがあり、iSCSIのボリュームをCSVとして共有している環境を想定する。

リダイレクトI/O動作時のディスクI/Oは以下図のとおりとなる。

リダイレクトI/Oの動作を確認してみる

ノード#1のiSCSI用のネットワークを切断した際に、リダイレクトI/Oが動作することを確認する。

ネットワーク切断してからしばらくすると、以下イベントログが表示され、リダイレクトI/Oが動作したことを確認できた。

ソース:FailoverClustering
id:5121
クラスターの共有ボリューム ‘Volume1’ (‘クラスター ディスク 1’) はこのクラスター ノードから直接アクセスできなくなりました。I/O アクセスは、ボリュームを所有するノードへのネットワークを介して記憶装置にリダイレクトされます。これが原因でパフォーマンスが低下した場合は、このノードから記憶装置への接続のトラブルシューティングを実施してください。記憶装置への接続が再確立されたら、I/O は正常な状態に戻ります。

また、ネットワーク切断からリダイレクトI/Oが動作するまでを時系列でまとめてみた。

発生時間 (秒)	内容	イベントログ
0	iSCSI用のNICのリンクダウン発生	ソース:e1iexpress id:27
10	MPIOのフェイルオーバー失敗	ソース:mpio id:32
140	ディスクが取り外される	ソース:Disk id:157
140	リダイレクトI/Oの開始	ソース:FailoverClustering id:5121

MPIOのフェイルオーバー失敗からリダイレクトI/Oの開始まで130秒必要(NICのリンクダウンから換算で140秒)となっている。この時間のディスクI/Oは不可となるが、OSがディスク復旧を待つ時間として設定されているタイムアウト値のようだ。OSのパラメーターとしてはMPIOのPDORemovePeriodで規定されている。これはPowerShellのGet-MPIOSettingで確認することができる。
※下記はNetApp社のユーティリティがインストールされた状態の値であり、Windowsデフォルト値ではないので注意。

PS C:\Users\tadmin\Desktop> Get-MPIOSetting
PathVerificationState     : Disabled
PathVerificationPeriod    : 30
PDORemovePeriod           : 130
RetryCount                : 6
RetryInterval             : 1
UseCustomPathRecoveryTime : Enabled
CustomPathRecoveryTime    : 40
DiskTimeoutValue          : 60

ちなみに、ESXiではディスクの全パスダウン(APD : All Paths Down)の検知時間は、デフォルト140秒として設定されている。

• VMware Docs - 一時的な APD 状態の処理
  

まとめ

以上のとおりリダイレクトI/Oの動作が確認できた。vSphere環境ではvSphere HAで仮想マシンが再起動されてしまうが、Hyper-Vではディスク遅延が発生したとしても仮想マシンの動作継続を優先するという設計思想の違いが見て取れた。