SQL Server Always On File Share Witness（Quorum vote）on different subnet to other nodes
現在、ノード1とノード2の相互間の接続が失われている一部の可用性グループで問題が発生しています"以前に確立された可用性レプリカへの接続で接続タイムアウトが発生しました"。
フェールオーバークラスターマネージャーのエラーは次のようになります"ファイル共有監視リソース 'ファイル共有監視'がファイル共有の調停に失敗しました"ファイル共有が置かれているサーバーが再起動していないか、問題が発生しています権限が機能しています。
唯一わかるのは、ファイル共有サーバーがクラスター内の他の2つのSQL Serverノードとは異なるサブネット上にあることです。
誰かが、AlwaysOn環境では、ファイル共有サーバーが別のサブネットにあることを確認できますか？他のノードと通信できるため、すべてのファイアウォールルールが整っていますが、（通常）時間外に接続が失われます。
もう1つの奇妙なことは、ファイル共有を含む3票がクォーラムにあるため、ファイル共有がフェールオーバークラスターへの接続を失っても、クォーラムへの十分な票があるため、node1とnode2は相互間の接続を失うべきではありません（2）
誰かが、AlwaysOn環境では、ファイル共有サーバーが別のサブネットにあることを確認できますか？
FSWを別のサブネットに配置することは完全に問題ありませんが、これには何の問題もありません。同じサブネット上に配置する必要はありません。実際、同じサブネット上にはないAzureの監視があり、問題なく動作します。
「可用性レプリカへの以前に確立された接続で接続タイムアウトが発生しました」
問題が発生しているネットワーク内の何かを指しているようですorこれが仮想マシン上にある場合、ゲスト/ホストで何か問題が発生し、この問題が発生しています。これに寄与できるホスト、ゲスト、OSレベルでの詳細な構成設定が多数あるので、このサイトの範囲外であるため、これ以上詳しく説明しません。
フェールオーバークラスターマネージャーのエラーで、「ファイル共有監視リソース 'ファイル共有監視'がファイル共有の調停に失敗しました」と表示されます。ファイル共有が置かれているサーバーが再起動していないか、問題がなく、すべてのアクセス許可が機能しています。
これは、証人の仲裁を試みた者は、クラスターの定足数を獲得したことから1票しか投票できなかったことを意味します。これは2ノードのクラスターであるため、ノードが相互に通信できなかった場合は、まさにこの状況になります。
どちらのノードも互いに通信できず（明らかに問題）、どちらのノードもFSWと通信できない（もう1つの問題）場合、インフラストラクチャーの何が壊れているのか、仮想レイヤーまたは物理（ネットワーク）レイヤーのどちらでも不思議に思います。何かがこれを引き起こしていることは明らかであり、SQL Serverではなく環境に固有のものです。
もう1つの奇妙なことは、ファイル共有を含むクォーラムに3つの投票があるため、ファイル共有がフェールオーバークラスターへの接続を失っても、クォーラムへの十分な投票があるため、node1とnode2は相互間の接続を失うべきではありません（2）
はい、ただし、ノード間の接続が失われたことは間違いありません。おそらく、クラスタログに、ハートビートの欠落、3343への接続、再グループ化などに関するいくつかのエントリがあります。
接続性は投票を意味するのではなく、接続性はヘルスチェックを意味します。ヘルスチェックに失敗すると、ノードが分割され、そのときにこれらのイベントが発生します。これが起こった頃にあなたの環境で何が起こったかを知る必要があります。非常に頻繁にスケジュールどおりに発生する場合、それは環境内の何らかのタスクまたはソフトウェアであり、ランダムに発生する場合は、負荷がかかっているときに発生する場合、ネットワークまたはホスト/ゲスト/ OS設定などのインフラストラクチャの問題である可能性が高いです。
VMWareの仮想マシンでAAGを実行しているときにのみ、同様の動作が見られました。ミラーリング監視でファイルロックを保持しているときにセカンダリレプリカが気絶すると、奇妙になります（VM Stun： https://cormachogan.com/2015/04/28/when-and-why-do-we-stun-a-virtual-machine / ）たとえば、ディスクを拡張する場合、VMが気絶する可能性があります（一時停止）大きなディスクの場合、数秒から20〜30秒。