Always Onクラスターがクォーラムを失った場合はどうしますか？
私は会社のDR手順を確認していて、Always On Clusterクォーラムを失う解決策をオンラインで探したとき、比較しました。私は、件名に関する最初のSEの投稿を見つける前に、Googleの結果に3ページを入れました クラスタリングvsトランザクションレプリケーションvs.可用性グループ 失われたクォーラムの件名に軽く触れるだけです。
クォーラムを失うことは悪いことであり、可能性を減らすためのいくつかの提案があることに誰もが同意しますが、それでも発生する可能性があります。 Always Onクラスターのクォーラムの損失から回復するための最良の方法に対する、ピアレビューされた適切な回答を探しています。
AGはWindowsクラスタリングに基づいています。クォーラム損失のWSFC手順が適用されます。
WSFCが実行されたら、必要に応じてAGを強制できます。 可用性グループの強制手動フェイルオーバーを実行 ：
WSFCクラスターにクォーラムを強制した後（強制クォーラム）、各可用性グループを強制的にフェールオーバーする必要があります（データ損失の可能性があります）。 WSFCクラスター値の実際の状態が失われた可能性があるため、フェイルオーバーを強制する必要があります。ただし、クォーラムを強制する前にプライマリレプリカであったレプリカをホストしていたサーバーインスタンス、またはクォーラムを強制する前に同期されたセカンダリレプリカにフェールオーバーを強制できる場合は、データの損失を回避できます。詳細については、「 クォーラムを強制した後のデータ損失を回避するための潜在的な方法 」を参照してください。
AlwaysOnクラスターがクォーラムを失う場合はどうしますか？
特に、さまざまな国にまたがるマルチサブネットクラスタリング（NY-LD-HK）でこの状況に陥っています。
マルチサブネットクラスタでのクォーラム損失を回避する方法
- クラスターのデフォルト設定をより緩和された監視状態に特に変更 クラスターハートビート設定
CrossSubnetDelay、またはCrossSubnetThresholdプロパティを使用して this hotfix を使用します。 - AGはWSFCを使用します。WSFCは、クォーラムベースのアプローチを使用してクラスターの状態を判断します。 クォーラムを適切に選択して構成する であることを確認してください。このブログ投稿では、さらに詳しく AlwaysONのクォーラム投票構成
サイト対応クラスター と クラウドウィットネス の導入により、Windows Server 2016では状況が変わります。
ストレッチクラスタのノードは、物理的な場所（サイト）に基づいてグループ化できるようになりました。クラスターサイト認識は、フェールオーバー動作、配置ポリシー、ノード間のハートビート、クォーラム動作など、クラスターライフサイクル中の主要な操作を強化します。
Cloud Witnessは、Microsoftを活用する新しいタイプのフェイルオーバークラスターquorum witnessです仲裁ポイントとしてのAzure。 Microsoft Azure Blob Storageを使用してblobファイルを読み書きし、スプリットブレイン解決の場合のアービトレーションポイントとして使用されます。
クォーラムが失われた場合の対処方法
- 計画外の停止/災害が原因でクラスターがダウンした場合は、手動による介入が必要です。 Windows管理者またはクラスター管理者のどちらかが 手動でクォーラムを強制する（この点をカバーする@Remusの回答にリンクする）と生き残ったノードをもたらす必要があるオンライン。
いつものように、根本原因分析（RCA）を行うには、Windowsクラスターログを収集します。AlwaysONRCAの場合は SQL Serverフェールオーバークラスター診断ログ を使用します。 SQL Serverログディレクトリ内のこれらのファイルの形式は次のとおりです：<HOSTNAME>_<INSTANCENAME>_SQLDIAG_X_XXXXXXXXX.xel。
ミラーサーバーが接続を失った停止に関与したことがあります。心配することの1つは、アプリケーションが単一のインスタンスを指すようにすることです。ネットワーク障害では、Always Onクラスターのすべてのノードが稼働しているが、相互に通信できないことがあります。強制的にフェイルオーバーをセカンダリに行い、停止が発生している間は、元のプライマリが強制的なフェイルオーバーを認識できないため、2つのプライマリノードを使用できます。
アプリケーションサーバーの場所、その構成、およびSQLサーバーに到達するための機能に応じて、理論的には、2つのノードがプライマリであると信じ、同時にデータが変更されると考えることができます。ネットワークの問題を修正してノードが接続を再開すると、元のプライマリで変更されたすべてのデータが、フェイルオーバーが強制されたノードから上書きされます。これにより、重要なデータが失われる可能性があります。
この状況は、SQL 2005とミラーリングで一度見たことがあります。そして、フェイルオーバーを強制せず、到達不能のままにすることにしました。最悪の場合、ミラーリングを再開するためにバックアップと復元を行わなければならない場合、トランザクションログがいっぱいになり、ディスクが拡張されないというリスクがあるため、2日間のプロセスになるでしょう。