EMC NX4がありますSANボックスは、多数のWindows Server 2008 R2アプリサーバーにCIFS共有を提供しています。アプリサーバーは、CIFS共有を使用して多数のイメージファイル(〜2500 ops/sec on the share)、ただしSAN=もアプリサーバーも明らかなストレスの兆候を示していません。
時々、アプリサーバーが突然突然、SANへの接続を切断します。 SAN=からファイルを提供しようとする.NETコードは、次のエラーで失敗します。
System.IO.IOException: The specified network name is no longer available
アプリサーバーにRDPを実行し、エクスプローラーから「\ san-name」にアクセスしようとすると、同じエラーが発生します。他のすべてのアプリサーバーは問題なくそれにアクセスできます。 「\ ip-of-san」にも完全にアクセスでき、pingも機能します。
アプリサーバーを再起動すると問題が解決しますが、SANは正常に機能しており、コンピューターがアクセスできるようです。 「\ san-name」アクセスが制限されました。
これは先週、2つの異なるアプリサーバーで発生したため、1つのアプリサーバーが原因であるとは思いません。現時点では原因を無視しています。マシンを再起動せずに「\ san-name」接続を復元するにはどうすればよいですか?そして、何が問題だったかをどうにかして照会できますか?
イベントログには、アプリサーバー上でもSAN上でも(問題によって引き起こされた関連するASP.NETエラー以外に)何も表示されません。
更新:
提案に基づいて、次回Workstationサービスを再起動してみて、問題が解決するかどうかを確認します。間違いなく修正ではありませんが、現在行っているようにマシン全体を再起動するよりもはるかに高速です。 Workstationサービスが維持する接続のステータスを照会する方法はありますか?
更新2:
Workstationサービスを再起動すると問題が「修正」されることを確認しました。次のステップは、MaxCmds値を高めるために、reg変更を試すことです。それが問題であるかどうかを確認することはできません。問題なく長期間実行される場合にのみ想定できます。
アプリサーバーでワークステーションサービスを再起動してください。
EMCバックエンドではなくても、以前にこのようなケースがありました。ユーザーランドアプリケーションの場合、リモートサーバーへの接続を強制的に閉じてから再度開くと、接続が元に戻ります。ただし、接続が機能するまでに数回試行する必要がある場合があります。サーバーランドアプリケーションの場合、そのサービスのアプリケーションプールのリサイクルは機能します。それが失敗した場合、Workstation Serviceをリサイクルすると再起動を回避できますが、それはほとんど同じです。
ソースで:
アプリサーバーにインストールされているソフトウェアについて詳しく教えてください。ネット上では、通常AVに問題があることがわかりますが、何も実行していないので...バックアップソフトウェアのような別のカーネルモードアプリですか?
ファイアウォールはアクティブですか?障害のあるアプリサーバーのDC=でイベントログを確認しましたか?
また、問題が発生したときにCIFSネットワークトラフィックをスニッフィングして、何が起きているかを確認する必要もあります。
私がこのエラーに遭遇したのは、サーバー/ワークステーションがドメインとのリンクを何らかの方法で「失った」ときだけでした。ドメインメンバーシップを強制することでトリックが行われました(netdom/resetpwd)。問題が発生したときにotherネットワーク共有(RDPセッションからアプリサーバーへ)にアクセスできますか?
これは名前解決に問題がありますか? DNSサーバーで確認できますか?名前の解決が許可されていない場合、アプリサーバーを再起動すると、アクセスが許可されます。
一部のワークステーションユーザーが別のサーバーに保存されているアプリケーションにアクセスできないと不平を言ったときも同じ問題がありましたが、名前ではなく機能するserver-ipでアクセスしようとしたため、DNSをチェックしました。静的IPネットワークがあるため、別のサーバーにアクセスしてIPアドレスを使用するようにアプリケーションを変更しました。
私の提案がうまくいくかどうか教えてください。
私は同様の問題に遭遇しました。 Windows 2003サーバーからWindows Server 2012に共有をマップできませんでした。
ネットワークグループは、低いバージョンのTLSが高いバージョンのTLSを実行しているサーバーに接続することを許可しないADコンテナーに低いウィンドウバージョンを分離するADポリシーを実装していました。サーバーを戻すか、ポリシーを無効にして古いバージョンのTLSで接続すると、この問題が修正されました。
ここに私がシステムログで遭遇したいくつかのエラーがあります:
リモートサーバーから受信した証明書は、信頼されていない証明機関によって発行されました。このため、証明書に含まれるデータを検証できません。 SSL接続要求が失敗しました。添付データにはサーバー証明書が含まれています。
致命的なアラートが生成され、リモートエンドポイントに送信されました。これにより、接続が終了する場合があります。 TLSプロトコルで定義された致命的なエラーコードは48です。WindowsSChannelのエラー状態は552です。
問題の解決に役立つことを願っています。