新PC セットアップの続きです（終わらん・・・）。
iSCSI イニシエータの設定が完了し、ドライブとして使い始めました。ふと、iSCSI 接続を確認してみると、想定していたIPアドレスと異なるアドレスで接続されています。今回、 NIC ２枚刺しで iSCSI は専用の NIC を使おうと思っていたのですが、そうなっていませんでした。
これを機に、 iSCSI イニシエータの接続設定を見直したので、いろいろとメモっておきます。
最終的な形
下記のような形になることを想定しています。
NAS NIC1 －－－－－ 仕事場LAN, 192.168.0.x －－－－－ メインPC NIC1 NAS NIC2 －－－－－ 直結, 192.168.2.x －－－－－－－－ メインPC NIC2
普段は、直結（以後、便宜上 iSCSI 専用ネットワークと呼びます）とした側の接続を使い、こちらにトラブルがあった際に、他方に切り替えて使えればと思います。
現状の設定
まずは設定中のものを確認します。『コントロールパネル』->『iSCSI イニシエータ』->『お気に入りのターゲット』タブ->『詳細』を開くと、
となります。iSCSI ターゲットは QNAP の TS-231P に設定しており、この機種は NIC が２枚あります。ここに表示されている IP アドレスは最終形として書いたように、仕事場のLANのネットワークアドレスになっており、 iSCSI 専用ネットワークのものではありません。
ちなみに、同じことは netstat でも確認できます。iSCSI のポート番号は 3260 なのでその接続を見ると、
C:\Users\mor>netstat -n アクティブな接続 プロトコル ローカル アドレス 外部アドレス 状態 TCP 127.0.0.1:49670 127.0.0.1:49671 ESTABLISHED （中略） TCP 192.168.0.15:61656 192.168.0.7:3260 ESTABLISHED
となりました。
なので、再度接続を行ってみます。
設定変更
不要かもしれませんが、一度接続設定を削除してから、もう一度接続してみたいと思います。
現在の接続の解除
ファイル履歴を有効にした際の保存先が iSCSI 上のドライブなので、いったんファイル履歴を停止させます。
次に、ディスクの管理を開き、ドライブとしてマウントしているものを解除します。ドライブ名上で右クリックし、
『ドライブ文字とパスの変更』を選びます。
表示されたダイアログで、ドライブやパスを削除しておきます。
次に、一度 iSCSI 接続を切断します。
『お気に入りターゲット』タブを開き、接続中のターゲットを選択し、『削除』をクリックします。
次に、『ターゲット』タブを開き、現在接続中のターゲットを選択し、『切断』をクリックします。
確認を求められるので、
『はい』を選択します。
状態が非アクティブになりました。
最後に、『探索』タブを開き、
設定済みの『ターゲットを検索するポータル』を選択し、削除しておきます。
再接続
最初からもう一度設定します。
まず、『探索』タブを開き、『ポータルの探索』に iSCSI ターゲットのIPアドレスを入れます。
この時の IP アドレスは、iSCSI 専用ネットワーク側になる NAS の NIC2 のアドレスにします。続いて、『ポータルの探察』を実施します。
次に『ターゲット』タブに移ります。『検出されたターゲット』に iSCSI ターゲットが表示されていたら、これを選択し『接続』を押します。
『ターゲットへの接続』ダイアログが表示されるので、このまま『詳細設定』を押します。
詳細設定画面の『ターゲットポータル IP』に iSCSI 専用ネットワーク側の NAS NIC2 の IP アドレスを入力します。
このドロップダウンリストを見るとわかりますが、『探索』タブのターゲットポータルの探索で入力した IP アドレス（iSCSI 専用ネットワーク側のアドレス）とは別の、仕事場LAN側につながっている NAS NIC1 のIPアドレスも表示されています。このため、『規定値』のまま接続すると、リストの先頭側のアドレスに接続するんでしょうね、たぶん。
最初の接続は何も考えずに『規定値』でつなげたので、仕事場LAN側を使うことになったと思われます。便利っちゃ便利ですが、慣れてないと気付かないですね、この動作。
あと、 iSCSI ターゲット側では CHAP を有効にしているので、名前とパスワードも入力しておきます。
設定内容に問題がなければ、OKを押します。問題なく接続できれば、今度は
のようになり、接続先（iSCSI ターゲット）の IP アドレスが iSCSI 専用ネットワーク側のアドレス 192.168.2.2 になっていることが確認できます。
これで、 MC/S 化の準備が整いました。
冗長化について
次は冗長化です。 iSCSI の冗長化には、
- MC/S, Multiple Connection per Session
- MPIO, Multipath I/O
の２つの方法があるそうです。ですが、あとで詳しく述べますが、 Windows 10 の場合は MPIO が使えませんので、ここでは MC/S 一択です。
MC/S の設定
『ターゲット』タブを選択し、接続状態が『接続完了』になっているターゲットを選択し、
『プロパティ』を表示します。
表示された画面の『セッション』タブの一番下にある『MCS』を押します。
まず、接続を追加するため、『追加』を選択します。
引き続き『詳細設定』を押します。
『ターゲットポータル IP』に仕事場LAN側の NAS NIC1 のIPアドレスを指定し、CHAPの情報も入力しておきます。
次に、『MCSポリシー』を選択します。
普段は、 iSCSI 専用ネットワークで通信して、トラブル時のみ切り替えて接続したいので、『フェールオーバーのみ』としました。
フェールオーバーの場合は、一方（普段使うほう）がアクティブになり、他方（待機してるほう）がスタンバイになります。
設定内容に問題がなければ、各ダイアログで『OK』を押して設定を終了します（特に再起動など必要ありません）。
ちなみに、 NAS 側で接続状況を表示させると、こんな感じで２つの接続があることがわかります。
テスト
iSCSI 専用ネットワーク側の NAS NIC2 のネットワークケーブルを抜いてみます。MC/S のポリシーが『フェールオーバーのみ』になっているので、
のように、ステータスが自動的に『再接続中』になり、再接続処理を行ってくれました。
しばらくすると、ステータスが『接続完了』になります。もちろん、 iSCSI のドライブも問題なく使えます。
ただ、少し気になった点は、再接続が接続完了になるまで、若干タイムラグがありました。頻繁にディスクにアクセスするようなタイミングだとちょっと問題になるかもしれません。
あと、接続が復旧したあと、 MCS 設定を確認すると、アクティブとスタンバイが入れ替わってしまいました。
なので、自分で再度設定してやる必要があるかもしれません。
そう考えると、 MC/S のポリシーとしては『最小キューの深さ』とかを選択して、通常は負荷が少ないと思われる iSCSI 専用ネットワーク側を使うようにし、同時に仕事場LAN側の接続も生かしておくも、有効かもしれませんね（試してないです）。
参考：iSCSI の冗長化について
上記で少し触れましたが、 iSCSI 接続を冗長化する方法として、 MC/S のほかに MPIO というのもあるそうです。
どちらも iSCSI 利用時の接続を複数にすることで、冗長化や性能向上を行うという点では同じもののようです。違いは、 MC/S がその名の通り、１セッションでの接続を複数持つのに対し、MPIOは複数のセッションで接続を行う、というもののようです。
英語ですが下記の記事などを読むと何となくイメージがつかめます。
- MPIO and MCS under Windows – Configuration in a Nutshell – moodjbow
- A Multivendor Post to help our mutual iSCSI customers using VMware - Virtual Geek
QNAP の設定記事（PDF）の前半に書いてあるものもイメージしやすかったです。
どちらを選べばよいかについては、上述の英語の記事とそこでも参照されている Microsoft の資料（Microsoft iSCSI Initiator Version 2.x Users Guide）にいくつか基準が載っています。下記に引用しておきます。
There are a number of things to consider when choosing to use MCS or Microsoft MPIO for multipathing.
- If your configuration uses hardware iSCSI HBA then Microsoft MPIO should be used.
- If your target does not support MCS then Microsoft MPIO should be used. Most iSCSI target arrays support Microsoft MPIO. Targets which support MCS include but are not limited to Network Appliance, EMC Celerra, and iStor
- If your target does support MCS and you are using the Microsoft software initiator driver then MCS is the best option. There may be some exceptions where you desire a consistent management interface among multipathing solutions and already have other Microsoft MPIO solutions installed that may make Microsoft MPIO an alternate choice in this configuration.
- If you need to specify different load balance policies for different LUNs then Microsoft MPIO should be used.
- If you are using Windows XP or Windows Vista, MCS is the only option since Microsoft MPIO is only available with Windows Server SKUS.
Microsoft の資料（Microsoft iSCSI Initiator Version 2.x Users Guide）から引用
いろいろ条件はありますが、 MPIO の場合は、 iSCSI ターゲット単位ではなく、 LUN ごとに冗長化／ロードバランスのポリシーを変更できるので、そういうのが必要なら MPIO がよいそうです。
ちなみに、この MS の資料は、昔のもののためか、 MS の URL が見つかりません。まあ、タイトルをググれば、 PDF が落ちてるので簡単に入手できると思いますので、興味のある方は見てみると面白いと思います。
対応状況
MPIO と MC/S の対応状況もまとめておきます。
調べて驚いたのですが、WIndows 10 では MPIO は使えないようです（バグみたい）
- How to get iSCSI multipath work on Windows 10 , should I do any adjustment in linux server side? - Server Fault
- Multi-pathIO not working in Windows 10 Pro · Issue #9796 · MicrosoftDocs/azure-docs · GitHub
- Windows 10 MPIO
QNAP の NAS のほうは対応しています（仕様の iSCSI のところに、 MPIO & MC/S の文言があります）。
なので、 iSCSI イニシエータとして Windows 10 を使う場合は、 MC/S 一択になりますね。
