web-dev-qa-db-ja.com

SQL Serverは常にオンNodeおよびファイル共有マジョリティ

Windows Server 2012 R2でのSQL Server 2016 SP1 Always On可用性グループHADRソリューションの設計に関するガイダンスを探しています。プライマリレプリカとセカンダリレプリカがあるプライマリサイトAと、セカンダリレプリカとファイル共有監視があるディザスタリカバリ（DR）サイトBがあります。私たちの目標は、サイトAのプライマリレプリカサーバー1がダウンした場合、Always On可用性グループ（AG）がサイトAのセカンダリレプリカサーバー2にフェールオーバーし、サイトAの両方のサーバーがダウンした場合、AGがフェールオーバーすることです。サイトBへ.

Nodeおよびファイル共有マジョリティ構成 https://technet.Microsoft.com/en-us/library/cc731739（v = ws.11） .aspx およびこの図：

enter image description here

この図は、1つのノードと「ディスク」/ファイル共有監視が通信しているときにクラスターが実行されていることを示していますが、この状況のテストでは、WSFCのクォーラムが失われたためにクラスターが失敗しています。 SQL Server 2016は2つの自動フェイルオーバーターゲットレプリカをサポートするため、vmWareでNICを無効にすることで一度に1台のサーバーの障害をテストすると、AGの自動フェイルオーバーは機能します。ただし、サイトAの両方のサーバーに同時に障害が発生し、ポイントツーポイントのネットワーク障害またはサイトの電源障害をシミュレートします。

クォーラムを強制するために手動で介入する次のアプローチは機能しますが、自動ではありません。これが理想的な状況で必要なことです。

$node = "SQLServerC"
Stop-ClusterNode –Name $node
Start-ClusterNode –Name $node –FixQuorum

ALTER AVAILABILITY GROUP SQLServerAO FORCE_FAILOVER_ALLOW_DATA_LOSS;

$node = "SQLServerC"
Stop-ClusterNode –Name $node
Start-ClusterNode –Name $node

私はあなたが提供できる提案を感謝し、事前に感謝します！

sql-serveravailability-groupsclusteringhigh-availabilitydisaster-recovery
6
Mike Petrak

Windowsサーバー2016を検討する必要があります。 blogs.msdn-Introduction-cloud-witness

1
Danilo Braga

私たちの目標は、サイトAのプライマリレプリカサーバー1がダウンした場合、Always On可用性グループ（AG）がサイトAのセカンダリレプリカサーバー2にフェールオーバーし、サイトAの両方のサーバーがダウンした場合、AGがフェールオーバーすることです。サイトBへ.

非常に特殊なシナリオを除いて、これは機能しません。他のすべてのシナリオでは、自動的にフェイルオーバーできるようになる前にクォーラムが失われます（クォーラムが必要です）。

最良の答えは、クォーラムを強制してAGをオンラインにする方法についての適切なドキュメントを使用して、DR側を手動でフェイルオーバーすることです（それでも同期が可能です）。

また、VMWareにさらに投資してそれらのテクノロジーを使用することもできますが、これは、インフラストラクチャ、ライセンス、およびこれらの製品をこのような特定のサービスに実装する能力を前提としています。

1
Sean Gallardy

プライマリレプリカとセカンダリレプリカがあるプライマリサイトAと、セカンダリレプリカとファイル共有監視があるディザスタリカバリ（DR）サイトBがあります。

さて、3つのノードのクラスターがあり、2つのノードがサイトAでホストされ、1つのノードがサイトBでホストされています。

Site A has a primary replica (node1) and a secondary replica (node2)
Site B has a secondary replica (node3)

そして、あなたのクォーラムモデルは：Node and File Share Majority.

既定では、各ノードは1票、ファイル共有監視は1票です。

定足数投票の総数はnode1 + node2 + node3 + file share witness = 1 + 1 + 1 + 1 = 4と現在のquorum majority will be 4 out of 4、つまり100％の生存率になります。

クラスタノードのサブセット（2、2）間にネットワーク接続の問題があると仮定します。これで、クォーラムの過半数は2対4、つまり50％の生存率になります。ここでの問題は、各サブセットが多数を占め、resource groupsを所有してクラスターを稼働状態に維持しようとすることですが、**Windows Server Failover Cluster (WSFC)**は一度に1つのアクティブノード、ノードの2つのサブセットのみをサポートします同じリソースにアクセスしようとすると、競合する問題が発生します。これはsplit-brain scenarioと呼ばれます。

したがって、even number of nodes in clusterを使用することは適切なアプローチではありません。

Windows Server 2012 R2上のSQL Server 2016 SP1 Always On可用性グループHADRソリューション

上記の問題を回避するには、Windows Server 2012 R2 introduced a new feature called Dynamic Witness.

あなたの場合、（Windows Server 2012 R2以降）デフォルトの投票は次のようになります。

node1 + node2 + node3 = 1 + 1 + 1 = 3 & File Share Witness = 0

ここでは、クォーラムの合計投票数は3で、過半数は3のうちの3です。合計投票数を奇数に保つためのファイル共有監視の投票はありません。

ノードに障害が発生した場合、クラスターは動的にファイル共有監視に投票を割り当てます。 The process of assigning or revoking quorum vote to witness dynamically called as Dynamic Witness.

また、新しいクォーラムはノードの障害発生後に動的に計算されます。たとえば、ノードに障害が発生し、監視に投票権がある場合、クォーラムは3のうちの3になります（つまり、node2 + node3 +ファイル共有監視）。 The process of adopting quorum after subsequent failure is called Dynamic Quorum.

私たちの目標は、サイトAのプライマリレプリカサーバー1がダウンした場合、Always On可用性グループ（AG）がサイトAのセカンダリレプリカサーバー2にフェールオーバーし、サイトAの両方のサーバーがダウンした場合、AGがフェールオーバーすることです。サイトBへ.

あなたのケースの失敗シナリオを見てみましょう：

Default:

node1 node2 node3 File Share Witness Quorum Majority
1       1    1          0               3 out of 3 100 %

1 node failure:

node1 node2 node3 File Share Witness Quorum Majority
0       1    1          1               3 out of 3 100 %   

--> **`Dynamic Quorum and Dynamic Witness`**

この場合、クラスターは2 node cluster with witnessになります。

ここでは、デフォルトのクォーラム構成はnode2 + node3 + File Share Witness = 1 + 1 + 1 = 3 out of 3 (because dynamically quorum updated as 3)になります。

another node fails (node2)と仮定しましょう

node2 node3 File Share Witness Quorum Majority
0        1          1               2 out of 3 66.66 % 

  --> It has majority - more than 50% - the cluster will survive

これで、新しいクラスターは次のようになります。

node3 File Share Witness Quorum Majority
1      1                   2 out of 2                        --> Dynamically quorum updated as 2

別のノードに障害が発生した場合、クラスターは停止します。これが明確であることを願っています。どのノードでも任意の順序で失敗する可能性がありますが、定足数の過半数は上記と同じように計算されます。

cloud witnessを使用することをお勧めしますが、問題を解決することはできませんが、それは単なる選択肢です。 このページをチェックしてくださいWindows Server Failover Cluster Quorum

DRを設定するには、簡単な解決策を提案します。

Site A set up Always On Availability Group (AG)で2 node clusterを使用し、クォーラムモデルをNode and File Share Majority。

オンSite B set up SQL Server Standalone instanceおよび構成-自動​​化backup and restoration / log shipping from Site A.

さまざまなオプションがあります。これは、以前使用したものです。この場合、フェイルオーバーは手動で実行する必要があります。 ビジネス要件を検討し、DR戦略を設計します。

設計時に注意すべきいくつかの点HADR solutions：

  • 目標復旧時間（RTO）
  • 目標復旧時点（RPO）
  • スケーラビリティ
  • 保持ポリシー、
  • フェイルオーバーなど...

理解を深めるために、このページをチェック することをお勧めします 。この回答がお役に立てば幸いです。ありがとうございます。

0
Rathish