ライブサーバーが強制フェイルオーバーを検出しないようにするにはどうすればよいですか？
プライマリサイトの2台のサーバーとリモートサイトの1台のDRサーバーで構成されるWindowsServer2016のSQL2017でAlwaysOn可用性グループを使用しています。
最近、概念実証として社内IT DRテストを実施しました。その間、会社の他のメンバーはプライマリサイトを引き続き使用しました。リモートDRネットワークを分離して、メインサイトの壊滅的な障害をシミュレートし、DRサイトをテストして、起動して正常に使用できることを確認しました。この時点までテストは非常にうまくいきましたが、通常の状態に戻すときに大きな問題が発生しました。
テスト中はメインサイトがまだ使用されていたため、テスト中に使用されたDRデータベースによってライブデータベースが破損しないようにすることが主な関心事でした。そこで、VPNを開く前にDRデータベースを削除しました。そして、メインサイトがDRサイトへの自動シードを開始することを期待していました。しかし、DRサイトでフェイルオーバーを強制する必要があったため、ネットワークリンクが再確立されるとすぐに、プライマリサイトはDRサーバーが強制クォーラムスイッチ（/ fq）で起動されたことを検出し、基本的にシャットダウンしました。 2つのライブサーバー。フェイルオーバーをLiveサーバーに強制的に戻すことができず、クラスターを再構築する必要がありました。
質問：DRサイトで強制フェイルオーバーが実行されたことをLiveサーバーが検出しないようにするにはどうすればよいですか？
ネットワークリンクを開く前にDRサーバーをシャットダウンすることを検討しましたが、オンラインになったときに何が起こるかはまだわかりません。いずれの場合も、リモートデータベースはLiveから再シードする必要があります。
スナップショット
VMの使用を想定して、ソースサイトが切断された後にDRサーバーのスナップショットを作成します。スナップショットが良好でクリーンな状態になるように、最初にサーバーをシャットダウンすることをお勧めします。 DRテストが完了したら、DRサーバーをシャットダウンして、スナップショットに戻します。これは簡単で安価です。唯一の欠点は、テスト中にソースサイトが保護されていないことです。また、ストレージインフラストラクチャによっては、スナップショットが原因でDRノードの速度が少し遅くなる場合があります。ああ、そしてあなたのプライマリは、サイトが再接続されるまでデータベースレプリケーションをキューに入れるのに十分なディスクスペースを持っている必要があります。
クローンを使用
VMを使用していて、十分なディスク容量があると仮定して、DRノードのクローンを作成し、元のDRノードをシャットダウンして、クローンでテストを実行します。完了したら、クローンを削除し、元のDRノードをオンラインにします。これにより、2つの問題が解決されます。1）データベース全体を再同期する必要がない、および2）クラスターノードを削除/参加する必要がない。
このアプローチの欠点は、テスト中にプライマリサーバーがすべてのデータをキューに入れる必要があるため、トランザクションログが非常に大きくなる可能性があることです。実行したテストでは、これが発生していたため、ログ用に十分なディスク容量があり、問題はなかったようです。
さらに多くのクローンを使用
一部の組織は、DRサイトに「バブル」ネットワークを作成し、本番DRネットワークと通信できません。次に、インフラストラクチャサーバー（ドメインコントローラー、DNSなど）のクローンが作成され、そのクローンがバブル内でオンラインになります。次に、DRテストの一部である必要がある他のサーバーがバブルに複製されます。これにより、DRテスト中に実際のDRサーバーをオンラインで機能的に保つことができます。 DRテストの開始から5時間後にプライマリサイトが破壊された場合はどうなるので、すべてを本当にフェイルオーバーする以外に、これは最も安全な方法です。サイトを切断すると、5時間のデータが失われます。
もちろん、これの欠点は、大規模な作業になり、多くのスタッフの時間やハードウェアなどを必要とする可能性があることです。
立ち退きと再参加
上記のコメントで述べたように、DRサイトが再接続される前に、クラスターからDRノードを削除してから、クラスターに再参加して、ノードを可用性グループに追加し直すことができます。これは非常に単純で、必要なハードウェアは最小限ですが、DRテスト中にプライマリサイトを保護しないままにしておくという欠点があります。