WSFC動態仲裁及投票調整2

  OK~ WSFC 2012 R2 年度盛宴開始~ 在本文中，老王將用一系列的場景，把動態仲裁，動態見證，票數調整，LowerQuorumPriorityNodeID，阻止仲裁等群集仲裁技術串起來，完成一個又一個復雜的場景，本篇文章可能并不太適合對于WSFC不了解的朋友，適合對于WSFC群集仲裁技術及2012動態仲裁技術有一定初步了解的朋友，如果您還不了解WSFC，建議您去先看下老王寫過的博客，或者其它地方相關的資料，如果您對于WSFC仲裁，動態仲裁技術已經有了初步的了解，相信跟著老王這篇文章中的場景會幫助您更加深入的理解群集投票，動態仲裁等知識，話不多說，我們現在就開始，跟著老王上車吧，過山車開了~滴

 開始之前先介紹環境，為了準備這次的博客，老王一共開了七臺虛擬機，主要是為了重現一些真實的分區場景，之前在2008R2的時候，我們用了六臺服務器，兩邊各兩個節點，一臺域控+ISCSI，一臺路由服務器，但是只有一側有域控，另外一側沒有域控，因此發生分區時，沒有域控的一方是沒辦法上線聯機搶奪群集的，雖然效果是一樣的，最終兩端出現分區，群集都無法使用，我們強制選擇其中一方啟動，在這次的環境里面老王特地用了七臺服務器，兩端都有域控，都可以形成群集的一個場景

  環境介紹

  北京站點

   HV01

   MGMET：80.0.0.2  GW：80.0.0.254 DNS：80.0.0.1 100.0.0.20 

   ISCSI：90.0.0.2

   CLUS：70.0.0.2

   HV02

   MGMET：80.0.0.3  GW：80.0.0.254 DNS：80.0.0.1 100.0.0.20

   ISCSI：90.0.0.3

   CLUS：70.0.0.3

   BJDC&ISCSI

   Lan：80.0.0.1 GW：80.0.0.254

   ISCSI：90.0.0.1

  佛山站點

   HV03

   MGMET：100.0.0.4  GW：100.0.0.254 DNS：100.0.0.20 80.0.0.1

   ISCSI：90.0.0.4

   CLUS：70.0.0.4

   HV04

   MGMET：100.0.0.5  GW：100.0.0.254 DNS：100.0.0.20 80.0.0.1

   ISCSI：90.0.0.5

   CLUS：70.0.0.5

   FSDC

   Lan：100.0.0.20 GW：100.0.0.254

 Router 

    03Route

    Beijing:80.0.0.254

    Fuosha:100.0.0.254

   首先我們先來看一道開胃小菜，在這個場景中我們將模擬，一個四個節點的跨站點群集，在見證磁盤始終在線的情況下節點逐個宕機的場景，以下是老王已經組建起來的一個多站點群集，其中的群集名稱和群集IP，可能在后面的圖會變，因為實驗過程中老王拆了又建了幾次群集，不過其他架構都按照規劃好的不會改變。

可以看到我們在群集中跑了一個DTC應用，當前DTC應用綁定了兩個IP地址，它們之間是OR關系

   在多站點群集的設計規劃中有很多需要考慮的地方，例如存儲復制，網絡檢測，加密處理，AD的同步，DNS的緩存等都會影響到多站點的故障轉移時間，后續會單獨寫博客來詳細講，這里簡單講兩個影響客戶端直接訪問的地方

   默認情況下在多站點群集中，例如我們的DTC應用當前在北京站點運行，它的聯機地址會是80.0.0.89，當它轉移到佛山站點，聯機地址會是100.0.0.89，但是這時候，客戶端能不能訪問DTC服務呢，不一定

    設想一下，北京和佛山站點做了AD多站點，它們的DNS會相互同步，當DTC在北京站點時它是80.0.0.89，經過一段時間它同步到了佛山站點，佛山的DNS也知道了DTC是80.0.0.89這個地址，那么當北京站點宕機，轉移到佛山站點了，雖然這時候DTC應用已經聯機，但是當客戶端訪問DTC，會返回80.0.0.89這個地址，并不會返回100.0.0.89的可用地址，這也導致了停機時間的延遲

    原因是由DNS的緩存機制導致，默認情況下群集應用聯機后注冊的主機記錄都是會有1200秒的TTL，即是說，客戶端如果請求了這個VCO的主機記錄，1200秒以內，不會再重新請求了，會使用緩存中的地址

    2008時代WSFC新增了用于多站點的HostRecordTTL屬性，使我們可以設置VCO記錄注冊到DNS時的TTL，TTL生命周期現在可以進行縮短，微軟建議縮短為300秒，即五分鐘之后重新請求DNS新的地址

    打開佛山站點的客戶端，輸入ipconfig /display可以看到被緩存的VCO記錄和生存時間(TTL)

   另外一個2008時代新增用于多站點的屬性則是RegisterAllProvidersIP，正常情況下，我們的VCO即使你設計了多個地址，它們默認會是OR的關系，即始終只注冊一個群集IP地址，當前在北京站點就是80網段的地址，當聯機到佛山站點，則會有CNO替VCO去注冊更新成100網段的地址，同一時間VCO默認只有一個站點的地址在線，通過RegisterAllProvidersIP屬性我們可以讓CNO去幫我們注冊所有的VCO地址，但是這就要求群集應用支持地址重試

   一個完美的場景應該是群集應用默認連接到80網段的地址，當80網段不可用，自動重試連接到100網段聯機使用，因為所有地址都已經注冊至DNS，所以可以減少由于DNS緩存導致的停機時間，在群集應用支持自動重試的話，可以使用這個屬性 ，SQL Server 2012開始支持在連接字符串加入MultiSubnetFailover=True參數和RegisterAllProvidersIP配合使用，當連接其中一個地址不通，會自動連接另外一個

這里我們遵循微軟的建議，配置DTC應用的HostRecordTTL為300

設置方法如下

#獲取群集應用資源名稱 

Get-ClusterResource | Select Name, ResourceType

#獲取群集應用資源屬性

Get-ClusterResource "devtestdtc" | Get-ClusterParameter

#修改HostRecordTTL屬性，脫機再聯機可以看到設置已經生效

Get-ClusterResource "devtestdtc" | Set-ClusterParameter HostRecordTTL 300

輔菜說完，下面來看我們的正菜，可以看到目前我們是四個節點的群集，見證磁盤可以正常參與投票

#查看節點投票數

Get-ClusterNode | ft ID, NodeName, NodeWeight, DynamicWeight, State -AutoSize

#查看見證投票數

(Get-Cluster).WitnessDynamicWeight 

這兩個命令后面我們會經常用到

當前群集DTC正常運行在HV01

我們直接將HV01進行斷電操作，可以看到群集應用自動轉移至HV02，HV01已下線所以去掉了它的投票，同時由于現在是4票，所以自動去掉了見證磁盤的一票，始終保證投票數為奇數。

直接將HV02也斷電，我們徹底失去了北京站點，可以看到現在又自動加上了見證磁盤的一票，現在群集還是三票，我直接強制DNS服務器更新，然后在客戶端ipconfig /flushdns了，此時再嘗試聯devtestdtc則會返回100網段的地址，如果不清除DNS緩存，可以等300秒時間到了，再次請求自動更新至100網段

DTC當前在HV03上面運行，我們再把HV03也斷電，現在群集只剩下HV04，可以看到現在群集會顯示三票，但其實已經不重要了，因為我們只剩下一個節點，他可以和見證磁盤聯系，因此可以存活至最后。

以上是我們的第一道小菜，怎么樣，還算簡單開胃把，可以看出在見證磁盤在情況下，群集節點逐步宕機，WSFC2012R2會始終動態的調整群集投票，確保群集投票始終是奇數，即始終一方可以存活，最后可以只剩下一個節點和見證存活。

接下來我們來模擬第二個場景，北京站點和佛山站點的管理網絡失去聯系，即80網絡和100網絡不通，我們直接關掉路由服務器，為了防止其中一方聯系到見證磁盤獲勝，我們也模擬見證磁盤失去聯系

這時候我們可以看到，群集檢測到見證磁盤失效，已經自動調整三個節點投票數為奇數

另外可以看到我們把管理網絡斷開了，群集依然可以正常工作，為什么呢，因為群集內置的網絡拓撲生成器會實時自動生成調整全網檢測的拓撲，管理網絡既可以對外訪問也可以做心跳檢測，心跳網絡只可以做心跳檢測，因此只要不影響群集節點之間心跳檢測，是不會有任何反應的。

群集并不會知道你的管理網絡故障，因為在北京站點管理網絡可以正常訪問，在佛山站點管理網絡也可以正常訪問，群集就以為它是好的，心跳檢測還有其它卡可以進行嘛

  假設現在這家公司的員工都從佛山出差來北京辦公，即所有的用戶都要在北京80網段的客戶端訪問，但是如果這時候群集DTC忽然漂移佛山去了，雖然它在佛山也可以正常工作，但是北京站點的用戶都訪問不到那邊，因為我們知道佛山站點100網段已經和外界失去聯系

   默認如果不做調整群集應用，DTC是應用是隨機漂移的，不一定會漂到那個節點去，可能看那個節點內存多，它就過去哪里了，一旦漂到佛山站點的服務器就慘了

   這時我們可以通過以下手段進行控制，首先設置DTC的習慣節點為HV01，HV02，這樣如果當前DTC托管在北京，當它發生故障轉移的時候，會優先考慮轉移到HV01或HV02

   但是僅僅設置首選所有者還是不夠的，因為設置首選所有者，只是在沒有發生分區的情況下會有用，當發生了一個網絡分區，HV01 HV02沒辦法與HV03 HV04聯系，這時由于HV01沒有投票數，而HV03 HV04一方有投票數，所以應用還是會轉移到佛山站點運行

   應對這種場景，我們可以徹底去掉HV03，HV04站點的投票數，這樣做了之后，即便發生一個網絡分區，北京站點剩下一票，佛山站點兩票，但因為我們去掉了佛山站點兩臺服務器的投票數，所以佛山站點會嘗試形成群集，但是始終是沒辦法成功的，因為他們沒有合法的票數。

   即是說我們通過手動去掉投票數，讓佛山的兩個節點永遠也沒辦法形成群集，要不然就訪問北京的節點，北京的節點一旦無法啟動，群集應用就停止訪問或強制啟動。

#手動去掉群集投票數

(Get-ClusterNode -Name hv03).NodeWeight = 0

(Get-ClusterNode -Name hv04).NodeWeight = 0

在2008和2008R2中可以通過添加一個Hotfix來獲得手動控制節點的投票的功能，2012及之后則WSFC自帶

   以上是手動調整群集投票數的場景之一，即我們知道一方的站點已經無法對外提供訪問服務，需要讓該站點始終停止對外服務，直到網絡恢復再重新賦予投票數

   手動調整投票數老王認為是很有用處的一項技術，除了這種已知站點無法對外提供的場景，在其它很多場景下也都有用武之地

   例如在一個完全手動故障的場景，有北京，天津，河北三個站點，只有北京站點的節點有投票，手動取消了天津和河北的投票，因為當故障發生時，可能要舉行一個災難恢復會議，商討一下，當前由那個站點繼續承擔群集更合適，例如商討天津站點當前更合適承擔群集，手動賦予天津站點節點票數，節點檢測到當前有投票，于是天津站點啟動形成群集，繼續對外提供服務

   或者還有一個場景，假設當前有北京站點，河北站點兩個站點，兩個節點各有兩個節點，當前群集一共四個節點，我手動去掉了河北站點其中一個節點的投票，讓它始終不參與群集投票，這時假設群集發生了故障，北京站點和河北站點的三個節點都已經無法啟動提供服務，我們可以強制啟動去掉投票的節點，重新賦予它票數，讓它繼續對外提供服務，或者北京站點宕機，強制仲裁后所有業務都跑到河北站點的一個節點運行，已經把機器的負載跑滿，這時候可以把去掉投票的節點重新賦予投票，一起承擔負載，這樣作為一個災備節點來使用。

    接下來我們假設當前群集是動態仲裁，群集見證磁盤先失效，繼而管理網絡也失效，心跳網絡也失效，出現一個分區時的場景

   針對網絡分區，我們到時除了把路由服務器關了，也把HV03 HV04的心跳網卡直接改了個網絡

    針對見證磁盤失效，我們還是依舊采用直接ISCSI上面禁用磁盤的方式，可以看到大概過了30秒左右，仲裁檢測到了見證磁盤已經處于非聯機狀態，于是自動去掉了它的票數，同時也隨機去掉了一個節點的票數，現在群集變成了三票

仲裁磁盤會按照故障轉移策略，在各個節點嘗試聯機掛起

都嘗試失敗后會顯示為失敗狀態，過一段時間會在嘗試聯機掛起，但始終不會成功

可以看到現在由于見證磁盤失敗，仲裁已經動態的調整了投票數，又隨機去掉了一個節點的投票數，現在群集還是奇數三個投票

  如果這時一個網絡分區發生，北京站點與佛山站點沒辦法心跳檢測，沒有網卡可以用于檢測，這時候佛山的站點會獲勝，繼續對外提供服務，而北京站點則會關閉

  因為北京站點被選中去掉了一個投票，只有一票，而佛山站點有兩票，所以佛山站點可以形成群集，形成群集后佛山站點又自動去了一票，現在佛山站點也是奇數投票數

  大家可以看到，這里的核心在于，群集選擇去掉那個站點的投票，被去掉投票的站點，當發生投票時會被關閉，默認情況下群集會根據各個節點的狀態變化，網絡監測情況，不斷的去調整票數，每次都會隨機選擇去掉投票站點的節點是誰，這有點像是每次都要隨機抓一個倒霉蛋，反正都是抓，那么我們可不可以控制每次固定抓一個人呢，答案是可以的

  通過2012R2里面新增的LowerQuorumPriorityNodeID屬性，我們可以控制在偶數節點下，讓動態仲裁始終去掉指定節點的投票，實現當發生50/50網絡分區時始終是我們想要的站點獲勝，或者在兩個節點的情況下，最終動態仲裁要隨機去掉一個節點的投票，我們也可以根據情況事前指定，始終去掉指定節點的投票。

#查看當前LowerQuorum節點，默認是0，即每次發生變化時隨機調整

(Get-Cluster).LowerQuorumPriorityNodeID

 #獲取節點ID，手動設置每次偶數投票數時丟棄HV04節點投票，每次都確保北京站點獲勝

(Get-Cluster).LowerQuorumPriorityNodeID=3

當再次發生網絡分區時可以看到，佛山站點關閉，北京站點存活下來，并自動調整為奇數投票

群集應用也始終正常運行著

以上為老王給朋友們上來的第二道菜和第三道菜

    第二道菜我們在一個已知站點故障的情況下，手動取消了該站點的投票，阻止應用遷移到上面提供服務，這里我們是假設的一個沒有分區的場景，因為兩端還是可以通過心跳網卡互相做心跳檢測的，我們在北京站點設置取消佛山站點的投票，佛山站點是可以知道的，如果是心跳網卡也發生了故障，即兩邊沒辦法進行進行心跳檢測，這時候就要分情況來看，如果分區之前我們已經設置好了取消投票的站點，那么很好，群集會選擇沒被設置取消投票的站點啟動，如果已經出現分區之后，那么只有強制啟動需要的少數站點，啟動之后再設置取消另外站點的投票，當另外站點上線時會以強制仲裁方為主。

    第三道菜呢，默認情況下在見證磁盤失效的動態仲裁場景中，當發生偶數投票節點的情況下會動態隨機為我們去掉一個節點的票數，我們可以通過LowerQuorumPriorityNodeID屬性來手動下降一個站點，確保當中間網絡分區發生時，始終是自己想要的站點獲勝

   因此大家可以看出，在動態仲裁存在的場景下，我們幾乎很少會用到強制仲裁，因為我們有很多新的技術可以選擇，例如LowerQuorumPriorityNodeID，事前手動調整投票數，強制仲裁在一些場景下也或許有用，尤其是2012R2之后，阻止仲裁技術發生了改變，多數節點一方檢測到少數節點一方存在仲裁會自動執行阻止仲裁操作，即確保承認強制仲裁一方為群集，與其群集數據庫同步至最新后，才會啟動自身群集服務，在之前2008時代，如果遇到強制仲裁的場景下，大多數時間都需要手動去執行阻止仲裁，否則會出現群集數據庫覆蓋等情況，到了2012R2則會自動幫助我們做這件事

   所以老王給大家的建議是，按照場景選擇合適的技術，能通過手動調整投票解決或者通過LowerQuorumPriorityNodeID解決就盡量不用強制仲裁，2012R2之前使用強制仲裁需要考慮阻止仲裁問題，2012R2不需要考慮。

   實際上在動態仲裁啟動的情況下，絕大部分場景動態仲裁都能幫助我們保證群集的可用性，始終讓群集保持奇數投票，即便動態仲裁默認選擇的站點你不滿意，也可以用LowerQuorumPriorityNodeID，票數調整，強制仲裁等技術切換到滿意的站點，像是以前50/50的腦裂分區場景，在動態仲裁的情況下是很難見到了，因此如果想看到腦裂場景最好的辦法就是關閉動態仲裁

    在第四道菜中，我們將模擬一個腦裂場景，北京佛山兩個站點，關閉動態仲裁的情況下，禁用見證磁盤，兩端出現網絡分區時心跳網絡和管理網絡都已關閉，沒辦法進行站點間心跳檢測

#確認群集動態仲裁狀態，默認為1，修改為0

(Get-Cluster).DynamicQuorum = 0

緊接著我們觸發網絡分區，修改HV03和HV04心跳網卡為其它網段，然后暫停路由服務器，讓兩端管理網絡和心跳網絡都不能互相做站點間的心跳檢測，但是在各自站點內又都可以正常和AD通信

這時打開各個節點上面可以看到日志，提示群集網絡已分區

運行查看投票數節點命令，可以看到當前所有節點，都在各自站點嘗試形成加入群集

但是這種狀態僅維持不到20秒，再次運行命令就會看到群集服務已經停止

在每個節點的事件管理器都可以看到關于群集服務停止的系統日志

可見當出現腦裂分區時，群集會出現短暫的爭奪階段，緊接著群集仲裁會檢測到當前發生分區，之后會關閉所有群集節點，老王并沒有看到網上說的發生仲裁時各個分區各自生成群集，然后爭奪寫入群集磁盤的場景，或許時間太短了沒有看到，或許是2012開始針對于腦裂分區做了優化，檢測到腦裂會自動關閉，不過老王實際看到的效果就是這樣，我感覺這樣都關了也好，誰也別搶，讓管理員手動選擇

假設這時管理員判定當前權威站點應該是北京站點，手動在HV01上面執行強制啟動命令

#強制啟動HV01

net stop clussvc

net start clussvc /FQ

HV01上面首先運行查看節點投票數命令，首先會看到HV01的投票，緊接著HV02由于和HV01是一個分區內，檢測到這一方發生強制仲裁，他會優先融入進來，狀態會先是Joining，最終變成Up

實際上在這一步的時候，老王是希望看到一個東西的效果，什么呢，就是阻止仲裁的效果，老王在10/90這種比例下，強制仲裁了10的一方之后，當剩下的90網絡聯機之后，可以在日志看到阻止仲裁的日志，但是在50/50比例下，當各節點網絡恢復正常后，老王沒看到這個日志

但是當老王嘗試用命令查看節點阻止仲裁狀態的時候卻可以看到

#查看各阻止仲裁狀態 1代表節點目前需要阻止仲裁，0代表節點當前不需要阻止仲裁

(Get-ClusterNode -Name HV02).NeedsPreventQuorum

(Get-ClusterNode -Name HV03).NeedsPreventQuorum

(Get-ClusterNode -Name HV04).NeedsPreventQuorum

可以看到節點2已經去掉了阻止仲裁的狀態，3和4節點仍需要阻止仲裁

什么是阻止仲裁呢，在上面老王也提到過一點，阻止仲裁簡單來講，就是讓其它節點遵守強制仲裁分區的技術，我們用強制仲裁之后，會把強制仲裁節點的paxos標記提至最高，即成為群集內最權威的存活節點，你們其它所有節點的群集數據庫都要以我的為準，阻止仲裁就是為了配置強制仲裁的這個目標，當其它節點網絡連通后可以和強制仲裁節點通信，節點會檢測到當前環境內存在強制仲裁的節點，我應該以他為首，我不應該形成群集，即使我是多數節點的一方，然后群集服務會暫時停止，直到可以阻止仲裁節點的群集數據庫完全和強制仲裁一方同步一致之后，才可以重新加入強制仲裁啟動節點形成的群集分區

在2012R2之前，遇到阻止仲裁的場景，尤其是10/90場景，你強制啟動了少數，是需要手動在其他站點執行阻止仲裁的，2012R2開始支持這種檢測到強制仲裁，自動阻止仲裁。

可以看到當佛山節點恢復和北京站點通信后，經過一段時間，節點的阻止仲裁狀態也變成了0，并且正常上線加入了強制仲裁方形成的群集分區

最后一道菜我們來嘗試一個反轉性的場景，假設當前北京站點有1個節點，佛山站點有3個節點，佛山站點發生了網絡故障，雖然佛山內部三個節點可以通信，但是它們無法對外提供服務，我們需要強制反轉至北京節點提供服務，本場景見證磁盤禁用，群集啟用動態仲裁

#重新啟用群集動態仲裁

(Get-Cluster).DynamicQuorum = 1

修改HV02為100.0.0.3，網關為100.0.0.254，DNS設置為100.0.0.20 80.0.0.1

#重新注冊網卡DNS記錄

ipconfig /registerdns

確保兩個站點的DNS上面都記錄了HV02的新地址

直接將HV02 HV03 HV04三個節點的群集網卡都改到同一個網絡，然后暫停路由服務器

這時候在HV01上面運行查看群集節點投票數的命令可以看到群集服務已停止

如果在HV03上面運行查看群集投票的命令則可以看到當前群集已經在佛山站點順利形成，因為這邊占據多的投票數，所以北京站點的群集目前會被關閉

#使用命令強制仲裁啟動北京站點的群集

net stop clussvc

net start clussvc /FQ

啟動完成后可以看到，在北京站點現在可以看到群集節點投票狀態了，同時也提升了paxos標記，更新HV01的群集數據庫為最新

由于HV02 HV03 HV04還沒有和HV01聯網，沒辦法知道北京站點那邊發生了強制仲裁，所以還會嘗試形成群集，在HV03上面查看群集投票狀態，可以看到還是舊的記錄

這時我們在北京站點上面需要做一件事，由于現在北京站點和佛山站點依然都可以訪問存儲，所以當應用在北京站點聯機的時候，可能會出現失敗的情況，因為佛山有三個節點也在和我搶群集磁盤，所以當務之急是取消掉佛山站點的投票數，防止和北京站點搶占資源

#手動取消佛山站點節點投票數

(Get-ClusterNode -Name hv02).NodeWeight = 0

(Get-ClusterNode -Name hv03).NodeWeight = 0

(Get-ClusterNode -Name hv04).NodeWeight = 0

需要注意的一點，這里如果需要執行去掉節點投票的操作，一定要在強制仲裁方進行，因為一旦在多數節點方執行，當再次網絡通信的時候也會被強制仲裁方的記錄蓋掉，不會生效。

之后我們再次將群集應用聯機，可以看到這時候實際上HV01已經從佛山站點搶奪過來了群集磁盤，佛山的三個站點再也沒辦法搶占群集資源，因為群集磁盤已經在權威一方重新上線，現在群集應用可以始終在北京站點運行

當佛山三個站點網絡修復完成后，試圖加入北京站點的群集分區時，可以在日志中看到阻止仲裁的日志，目前節點狀態不會是UP，只有當佛山三個站點承認北京站點為權威一方，并且群集數據庫已經和北京站點同步一致后，才可以正常加入群集。

經過一段時間后，可以看到佛山節點已經都完成阻止仲裁，正常加入群集，最后我們再重新為佛山節點賦予投票，讓佛山節點可以正常參加故障轉移，賦予投票后，群集仲裁會檢測到當前恢復四個節點，又將根據動態仲裁機制自動選擇節點去掉一票，實現始終奇數投票。

以上為老王通過實踐得出的一點經驗之談，寫這篇文章時老王的愿景是通過不斷的實驗把動態仲裁，動態見證，票數調整，LowerQuorumPriorityNodeID，阻止仲裁這些技術反復驗證明白，然后通過場景的形式盡可能形象的講出來，告訴朋友們具體都是什么樣的功能，應該如何使用，希望能夠用更多的人知道2012R2群集的這些技術，越來越多的人來真正的使用群集，研究群集，群集絕不只是一根心跳線，一個存儲，把節點連起來就完了，里面很多東西都值得我們花心思去研究，用心去研究技術，自然會找到樂趣。