SQLServer 2014 本地機房HA+災備機房DR解決方案

SQLServer 2014 主數據中心HA+災備機房DR解決方案

 

SQLServer 2008 的時候使用 local WSFC+DR Mirror方式，對象是單數據庫

兩個單獨的 WSFC 上使用兩個 FCI

每一個WSFC有兩個以上的節點

數據庫鏡像容許單獨 WSFC 上的多個 FCI 使用相同的實例名稱

 

 

SQLServer 2012/2014 的時候使用 local WSFC+DR AG方式，對象是可用性組（通常爲整個實例）

單個 WSFC 上使用兩個 FCI

單個 WSFC 含有四個以上節點，每一個FCI（failover cluster instance）有兩個以上的節點

在同一個 WSFC 內，兩個 FCI 必須使用不一樣的實例名稱，例如，使用「INST_A」做爲主 FCI 的實例名稱，使用「INST_B」做爲 DR FCI 的實例名稱

 核心業務dr使用集羣

 

非核心業務dr使用單實例

 

 

(*)因爲跨機房的WSFC，共享存儲的注意事項

每一個 FCI 都有本身的共享存儲（其餘數據中心內的節點沒法訪問），稱做非對稱存儲

兩個 FCI 中的數據庫文件和事務日誌文件也應該使用徹底相同的文件路徑，磁盤應使用徹底相同的驅動器號（避免搭建ag，還原輔助副本的時候使用restore with move/建立文件組或者日誌操做的失敗）

每一個FCI中，SQL Server 實例的 FCI 故障轉移是自動執行的；AG的故障轉移模式必須是手動，AG同步模式建議異步提交

 

(*)因爲跨機房的WSFC，仲裁投票、仲裁模型 的注意事項

默認狀況下，故障轉移羣集中的每一個節點都具備投票（ 節點的 NodeWeight 屬性），引入一個修補程序 (http://support.microsoft.com/kb/2494036（用於將 1 個投票分配給 WSFC 中的特定節點，將 0 個投票分配給其餘一些節點），拓撲中的每一個節點上都必須安裝此修補程序

投票方案：

• 主數據中心的每一個節點有 1 個投票
• DR數據中心的每一個節點有 0 個投票

做爲最佳作法，WSFC 的投票總數應爲奇數。若是投票節點數目爲偶數（上圖示例拓撲），應在各自FCI中備機節點（避免使用文件仲裁，管理成本高）

(*)發生dr切換時

若是主數據中心發生停機，正常切換到DR數據中心時，須要對DR從新設置仲裁配置。必須向DR數據中心的每一個節點都分配一個投票，而將主數據中心每一個節點上的投票都設置爲「0」

當主數據中心恢復活動後，還要再次對投票進行調整

--查看仲裁設置

SELECT cluster_name, quorum_type_desc, quorum_state_desc
FROM sys.dm_hadr_cluster;

--查看是否有投票權

SELECT member_name, number_of_quorum_votes
FROM sys.dm_hadr_cluster_members
order by number_of_quorum_votes desc

 

--徹底設置

 

 

PowerShell

查看全部節點的當前投票設置

         Get-ClusterNode | fl NodeName, NodeWeight

將某一節點的投票設置爲「0」

　　　(Get-ClusterNode "DRNode1").NodeWeight=0

 

 

 

 

 

--注意：

windows故障轉移集羣+ag環境時，不能再將ag的自動故障轉移打開，但能夠打開同步模式

因爲只能使用windows故障轉移，因此避免主機房節點失敗，沒有正常切換到主機房的備機，須要拉掉dr機房的投票權（避免故障轉移到dr，實際上搭ag以前須要拉掉overlap的節點，不容許集羣不一樣實例間出現節點交叉）

The FCI already has automatic failover configured between the nodes.

The current implementation of AG doe not allow a failover outside of the FCI nodes.

詳見：

https://blogs.msdn.microsoft.com/arvindsh/2012/09/26/alwayson-availability-group-forced-failover-under-the-hood/