以下に示すように、サーバーの再起動後、iSCSI接続自体が再接続しないという問題が発生しています。
OSはWindows Server 2008 R2です。 iSCSIデバイスは、別の同一サーバーを持つフェールオーバークラスター内にあるSQL Server 2008 R2インスタンス用です。両方のサーバーで同じ問題が発生します。
ターゲットは「お気に入りのターゲット」としてリストされ、認証を必要としません。ダイジェストはオフになっています。 iSCSIターゲットはSynology NASデバイスを介して公開されます。
ファイル/プリントサーバー(同じOS)でも同じ問題が発生することにも言及する価値があります。私は自分で研究を試みましたが、これまでのところあまり助けがありません。これは非常に基本的なセットアップであり、ほとんどのソリューションはよりSANに似た構成を想定しています。
NASを除くすべてのサーバーはESXi 6ホスト上にあります(各ホストのペアでVM))。
編集:発見タブ:
更新:ログメッセージ:
編集:
さて、イベント113は KB972107 です。これはかなり一般的なクラスの問題ですが、「...ネットワークスタックが完全に準備されていません」が私の注意を引いた。次に、より興味深いイベント103が表示されます。
これを参照してください experts-exchange post 同様の問題...
サーバーsiの実行中に接続すると、すべてが正しく機能しているように見えますが、再起動すると、通常、サーバーはログイン後にハングし、ドライブがゆっくりと表示されるか、まったく表示されません。
...そして次の KB Article を指す解決策。
それ以上の情報がないと、イニシエーターがリブートされたときに接続が正常に終了されないことが私の直感です。これにより、接続がtargetデバイスで一貫性のない状態になります。イニシエーターが再接続を試みても、一方の側が単に混乱しているため、またはイニシエーターあたりのセッション数に制限が設定されているために、ターゲットは元のセッションがアクティブであると依然として認識し、接続がハングします。
先に進んで、リモートサーバーの接続の状態を監視しながら、もう一度試してください。私の直感が正しければ、NAS側でセッションがまだアクティブであることがわかります。これは、サーバーが強制的に切断される前にセッションをすぐに終了しないか、またはNASでの非常に長いセッションタイムアウトの結果である。
また、ほとんどのクライアントサイトでSynology Nasを使用しており、定期的にまったく同じ問題が発生していました。 Synologyのテクニカルサポートに連絡したところ、認証マスキングの構成を提案されました。 chapを使用して接続を認証していた場合、Windowsは常に認証エラーを記録していました。ユニットをアップグレードするとき、私は12ほどのlunを切断し、半分は一般的に再接続に失敗するため、状況はさらに悪化しました。
この変更を行って以来、再起動の約100%でこの問題が発生することから、過去6か月間に単一のマシンでのみ問題が発生するようになりました。
認証が設定されていないようですが、synology側でマスキングを設定してみる価値はあります。接続中にストレージマネージャからiqn文字列をコピーする必要があります。 iscsiターゲット画面で見つけて、編集>マスキングに移動し、文字列を貼り付けることができる新しいエントリを作成します。
私は最近これに遭遇し、マスクを設定してもそれでも失敗することを発見しました。使用中のチームNICと連動しているようです。
ボリュームとデバイスを含め、NASの既存のすべてのISCSIターゲットを削除します。CHAPを削除し、代わりにマスキングを使用します(IEはデフォルトではアクセスできませんが、接続している模倣者の読み取り/書き込みです。自動接続を使用しますが、上部に特別なNICやターゲットを設定しないでください。通常、これはデバイスが再接続しない場合の修正ですが、これが問題の原因であることがわかりました。接続したら、ボリュームとデバイスで自動構成を実行して、再接続を確認してください。
これで、再起動すると再接続することがわかります。
ありがとう、ロブ・ホームズ