ストレッチ（ジオ）クラスターの処理Node失敗
シナリオ：
Windows Server 2012上の3ノード（シェアードナッシング）クラスター。プライマリデータセンター内の2つのノード、両方とも投票（ノードの重み= 1）、およびファイル共有監視。 3番目のノードはリモートデータセンターにあり、投票はありません（ノードの重みは0）。
問題：1つのクラスターノード（クラスター名を所有）が自動更新のためにダウンしました。クラスター名がリモートデータセンターノードに失敗し、リモートノードがファイル共有監視ファイルのロックを取得できました。その時点で、VPNトンネルはドロップしました。プライマリデータセンターで稼働していた（そしてサービスが実行されていた）1つのノードは、リモートクラスターノードがダウンしていることに気づき、クラスター名をオンラインにしようとしました。ファイル共有監視ファイルは引き続きリモートノードによってロックされており、プライマリデータセンターで実行中の1つのクラスターノードがクラスター名をオンラインにできず、クラスターサービス自体をシャットダウンしました。
警告：リモートノードからファイル共有をファイアウォールで保護することは、それを使用する他のプロセスのためにオプションではありません。
クラスター名の所有者候補からリモートクラスターノードを削除することを検討しましたが、これまでに実行またはテストしたことがなく、実稼働クラスターを爆破したくありません。クラスター名の可能な所有者からクラスターノードを削除することは可能ですか？リモートデータセンターへのサービスを失敗させる必要がある場合、調整が必要な可動部分がいくつかあるため、リモートデータセンターへのサービスの「自動化された」フェイルオーバーは望ましくありません。リモートノードがクラスター内にある理由は、SQLServer可用性グループがリモートノードへのレプリケーションを管理するためです。
また、ファイル共有監視を削除して、リモートノードに投票することも検討しました。新しい動的クォーラムは、再起動のために1つのノードがダウンし、リモートデータセンターへのネットワーク接続が失われた場合に、クラスターをオンラインに保つ必要があります。
私のシナリオを考えると、どのオプション（または他の選択肢）が私に最高の可用性を与えるでしょう。
計画されたフェイルオーバーがはるかに簡単になるため、実際にはリモートノードに投票するのが好きです。データベースとリソースをリモートデータセンターに移行してから、プライマリデータセンターのノードを徐々にシャットダウンすることができます。これを機能させるために投票を行う必要はありません。さらに、ファイル共有の高可用性について心配する必要はありません。
だから私はここでブレントと一緒です。あなたがそれを気にしないと絶対に100％確信していない限り、私は投票者としてノードを削除するのが好きではありませんでした。努力すべきことの1つは、プライマリレプリカがスプリットブレインを回避することであるWSFCクラスターグループを維持することです。
WSFCから所有者候補としてクラスターノードを削除することはお勧めできません。これを行う必要がある場合は、ノードをクラスターから削除します。悪い、悪いモジョ。
Windows Server 2012では、動的クォーラムも使用できるため、障害がすべて同時に発生しない限り、最後の人に立ち向かうことができます（もちろん警告付き）。
また、ネットワークの問題も解決します。あなたが言うことができるように、彼らは地理的に分散した状況でキラーになります。