Always Onクラスターがクォーラムを失った場合はどうしますか？

私は会社のDR手順を確認していて、Always On Clusterのクォーラムを失う解決策をオンラインで探したときと比較しました。失われたクォーラムの件名に軽く触れるだけの件名クラスタリングvs.トランザクションレプリケーションvs.可用性グループに関する最初のSEの投稿を見つける前に、Googleの結果を3ページ読みました。

クォーラムを失うことは悪いことであり、可能性を減らすためのいくつかの提案がありますが、それでも起こりえます。Always Onクラスターのクォーラムの損失から回復するための最良の方法に対する、ピアレビューされた適切な回答を探しています。

AGはWindowsクラスタリングに基づいています。クォーラム損失のWSFC手順が適用されます。

• 強制クォーラムによるWSFC災害復旧
• クォーラムなしでWSFCクラスターを強制的に起動する

WSFCが実行されたら、必要に応じてAGを強制できます。可用性グループの強制手動フェールオーバーを実行します。

WSFCクラスターにクォーラムを強制した後（強制クォーラム）、各可用性グループを強制的にフェイルオーバーする必要があります（データ損失の可能性があります）。WSFCクラスター値の実際の状態が失われた可能性があるため、フェイルオーバーを強制する必要があります。ただし、クォーラムを強制する前にプライマリレプリカであったレプリカをホストしていたサーバーインスタンス、またはクォーラムを強制する前に同期されたセカンダリレプリカにフェールオーバーを強制できる場合は、データの損失を回避できます。詳細については、「クォーラムが強制された後のデータ損失を回避するための潜在的な方法」を参照してください。

AlwaysOnクラスターがクォーラムを失った場合はどうしますか？

特に、さまざまな国にまたがるマルチサブネットクラスタリング（NY-LD-HK）でこの状況に陥っています。

マルチサブネットクラスターでクォーラム損失を回避する方法

• クラスターのデフォルト設定をよりリラックスした監視状態に変更します。特に、を使用したクラスターハートビート設定CrossSubnetDelay、またはこの修正プログラムのCrossSubnetThresholdプロパティを使用します。
• AGはWSFCを使用します。WSFCは、クォーラムベースのアプローチを使用してクラスターの状態を判断します。クォーラムを適切に選択および構成してください。このブログ投稿はさらに深く掘り下げています、AlwaysONのクォーラム投票構成について詳しく説明しています。

• Windowsサーバー2016では、サイト対応クラスターとクラウド監視の導入により状況が変化します。

  ストレッチクラスタ内のノードは、物理的な場所（サイト）に基づいてグループ化できるようになりました。クラスターサイト認識は、フェールオーバー動作、配置ポリシー、ノード間のハートビート、クォーラム動作など、クラスターライフサイクル中の主要な操作を強化します。

  クラウド監視は、Microsoft 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日間のプロセスになります。