マルチサブネットクラスタリングを使用した可用性グループ：ロールの優先所有者とAGリスナーIPの可能な所有者
HA/DRには、Windows Server 2012マルチサブネットフェールオーバークラスターでSQL Server 2016可用性グループ（AG）を使用します。ニューヨークのデータセンター（10.7.x.xサブネット）に2つのノードがあり、コロラドのデータセンター（10.8.x.xサブネット）に1つのノードがあります。コロラドサーバーは、主に災害復旧またはニューヨークがオフラインである拡張メンテナンスのためのものです。現在、問題が発生した場合にクラスターまたはAGの所有権を自動的に取得しないように、CO-SQL01ノードのクォーラムNodeWeight/Votesをゼロに設定しています。 。
私の質問はこれです。フェールオーバークラスターマネージャーの既定の設定、特にAGロールの優先所有者とAGリスナーIPリソースの実行可能な所有者を変更する必要がありますか？使用されるデフォルトは、ニューヨークの2つのノードを使用し、災害復旧にCOノードのみを使用する高可用性の目標と矛盾するようです。
マルチサブネットAGの優先所有者のデフォルト設定は次のとおりです。 
NY-SQL02の横にチェックを追加し、CO-SQL01の上に移動して、優先されるようにしますか？他の役割についてはどうですか？コアクラスターリソースの優先所有者（クラスター名など）を設定できますか？
SQL-StackOverflow_AG IPリソースのデフォルト設定は次のとおりです： 
そのIPアドレスとは異なるサブネットにあるサーバーの横のチェックマークを削除する必要がありますか？
この質問は最近の 営業時間 で出てきましたが、クラスターに問題がある場合のダウンタイムを防ぐのに役立つかもしれません。 CO-SQL01サーバーハードウェアを交換したところ、5分間の停止があり、投票を削除せずにフェールオーバークラスター（AGではなく）に追加されました。その後、CO-SQL01サーバーでハードクラッシュが発生し（高負荷時のNVMe/PCIeドライバーのバグであったと考えられます）、AGをそれを使用して管理できました（CO-SQL01は、コアクラスターリソースの所有権を受け取ったと考えています）オンラインに戻ります）。
正直に言うと、マルチサブネットフェールオーバークラスター可用性グループの使用に関して予期しない問題がいくつか発生しました。デフォルトの優先ロールの所有者と可能なリソースの所有者は正しくないか、少なくともこのシナリオでは最適ではないようです。これらの問題を回避する方法として、現在、SQL Server 2016の新しい 分散型可用性グループ 機能を使用して、マルチサブネットAGを2つの単一サブネットAG（データセンターごとに1つ）に分割することを検討しています。未来。また、これにより 最小限のダウンタイムでクラスターOSをアップグレードする が可能になると考えています。
私の質問はこれです。フェールオーバークラスターマネージャーの既定の設定、特にAGロールの優先所有者とAGリスナーIPリソースの実行可能な所有者を変更する必要がありますか？
AGリソースの優先所有者または可能な所有者をチェックまたはチェック解除しないでください。 SQL Server 2016を使用する場合、優先所有者リストを移動して上下に移動して、複数のフェイルオーバーターゲットが変更された場合に優先フェイルオーバーターゲットを制御できますが、変更できません可用性グループを使用して、everのボックスをオンまたはオフにします。限目。
このようなものにチェックを入れたり外したりすると、AGは正しく機能しません。可用性グループのクラスを教えるときは、これがどのように機能するか、なぜ機能するのか、なぜこれを実行したくないのかを常に示します（ネタバレ注意：AGが失敗する可能性が非常に高いです）。
少しわかりやすくするために、これについて説明します。
優先および可能な所有者
これらの値は、可用性グループの設定に基づいてSQL Serverによって設定されます。クラスターには、動作方法のメタデータの独自のコピーがあり、SQL Serverもは、動作方法のコピーを持っています。
これはほとんどの場合素晴らしいことであり、誰も何も変更せず、SQL Serverとクラスタの両方がうなり続けます。
ただし、SQL Serverは、AG設定に基づいてリソースの所有者である必要があるかどうかを認識しており、これを反映して、クラスターAPIを呼び出して期待される動作を設定します。これは、HADR_CLUSAPI_CALL待機タイプに反映されます。
3つの非同期レプリカ
3つの非同期コミットレプリカが存在するようにAGが設定されたSQL Serverを見てみましょう。これを行うと、AGとロールのリソースは次のようになります。 
非同期コミットレプリカには自動フェイルオーバーを設定できないことに注意してください。したがって、これは理にかなっています。私たちの現在の役割の所有者は、唯一の可能な優先所有者です。 SQL Serverはフェールオーバーする唯一の方法が強制することであるようにセットアップされているため、他のレプリカがこれを取得して実行を開始しないようにして、これをクラスタリングレベルで強制します。
2つの同期手動フェイルオーバー、1つの非同期-デモ
結果はThree Asyncデモと同じになります。どうして？
これは、3つの非同期レプリカと同じ説明です。自動フェイルオーバーはまだないため、誰も必要ありません[〜＃〜]自動的に[〜＃〜] 引取り。したがって、設定は同じです。
2つの非同期自動フェイルオーバー、1つの非同期-デモ
ここで状況が変化し、面白くなります。自動フェイルオーバーを導入しているので、これはWSFCの役割の1つです（ヘルスチェック、メタデータの配布などと共に）-wantを使用してそして可能な所有者。
その他の対応
CO-SQL01サーバーハードウェアを交換したところ、最近5分間停止しました...
特にCOから投票を削除し、残り1人の有権者だけが残っていて、予期しないクラッシュが発生しました。正常に機能していたようです。
正直に言うと、マルチサブネットフェールオーバークラスター可用性グループの使用に関して予期しない問題がいくつか発生しました。デフォルトの優先ロールの所有者と可能なリソースの所有者は正しくないか、少なくともこのシナリオでは最適ではないようです。
私はここで残酷に正直になります。可用性グループは特効薬ではありません。HAとDRをすべて修正してください。テクノロジーが使用されているようですが、その動作方法や、AGレベルとWSFCレベルの両方でこれらの機能を実行する理由についてあまり知られていないため、適切にセットアップされていない可能性があることに完全に同意します...セットアップどおりに機能しています-本来の動作を実行するためにクラスターに障害を起こすことはできません。
現在、SQL Server 2016の新しい分散可用性グループ機能を使用して、Multi-Subnet AGを2つのシングルサブネットAG（データセンターごとに1つ）に分割し、将来これらの問題を回避しています。
可用性グループでこれだけ多くの問題が発生している場合、私は自分で分散可用性グループに進出することはしないでしょう。それはあなたのユースケースに合うかもしれませんし、そうでないかもしれません-私があなたなら、私はこれらのタイプのソリューションを設計するのを手伝って、あなたのユースケースを準備してくれる人を連れてきます。それ以外の場合は、このような別の投稿を作成します。
また、これにより、最小限のダウンタイムでクラスターOSをアップグレードできると考えています。
分散可用性グループのユースケースの1つは、ダウンタイムが非常に短いクラスター間の移行です。 Windows Server 2012R2を使用している場合は、分散可用性グループを実行せずに ローリングクラスターアップグレード [2012では使用できません。R2である必要があります]を実行できます。
SQL-StackOverflow_AG IPリソースのデフォルト設定は次のとおりです
はい、触れないでください:)そのままにしておきます。