WSFC真實場景仲裁處理

  在本篇文章中，老王將從實際應用的角度來爲你們講解下羣集仲裁在真實狀況下的呈現，以及出現不一樣點數的節點宕機應該如何處理，在老王本篇文章中以及之後的文章中，我並不會去講如何去安裝一個羣集，後面咱們也將主要專一於羣集的深刻知識，概念理解，架構設計，遷移優化。

  本篇文章分爲如下幾個場景

  場景1.兩個站點，三個節點的羣集，假設北京站點兩個節點，保定站點一個節點，羣集採用多數節點方式，咱們將依次測試重現，羣集壞掉1個節點會發生什麼，應該如何處理，羣集壞掉兩個節點會發生什麼，應該如何處理。

  場景2.兩個站點，四個節點的羣集，假設北京站點兩個節點，保定站點兩個節點，羣集採用磁盤仲裁的方式，咱們將依次測試重現，羣集見證磁盤活着時候，壞掉一個節點時羣集會發生什麼，應該如何處理，壞掉兩個節點時羣集會發生什麼，應該如何處理，當見證磁盤不在，會發生什麼狀況，應該如何處理。

 場景1環境介紹

 北京站點

 Node1 

 管理網卡 10.0.0.3 網關10.0.0.1 DNS10.0.0.2

 存儲網卡 40.0.0.3 網關40.0.0.1

 心跳網卡 18.0.0.1

 Node2 

 管理網卡 10.0.0.4 網關10.0.0.1 DNS10.0.0.2

 存儲網卡 40.0.0.4 網關40.0.0.1

 心跳網卡 18.0.0.2

 08DC

 lan1 10.0.0.2 網關10.0.0.1

 網關服務器 

 10.0.0.1

 20.0.0.1

 30.0.0.1

 40.0.0.1

 保定站點

 管理網卡 20.0.0.5 網關20.0.0.1 DNS10.0.0.2

 存儲網卡 30.0.0.5 網關30.0.0.1

 心跳網卡 18.0.0.3

 這次設計上，並無採起一些最佳實踐，老王只是爲了重現出這樣一個多站點的場景，把兩個站點間管理網卡和存儲網卡的網絡分開，在以後的實驗08DC也會承擔ISCSI Server角色，嚴格來講，網關服務器和存儲應該要放在一個相對來講比較穩定安全的地方，防止因爲網關或存儲致使羣集出現單點故障，另外

   你們看到我在心跳卡上面兩個站點的用的是同一個網端，這在實際企業環境裏面不會這樣，一般狀況下是打通一個大VLAN這樣去作，可是要注意，羣集節點網卡，必定要至少有一塊網卡，不配置網關，由於羣集在建立的時候會去利用啓發性算法來查找，羣集默認會找沒有配置網關的網卡來做爲心跳網卡，若是所有網卡都配置上網關，你會發現羣集出現故障，所以，若是心跳網卡也須要跨越網段，能夠採起在節點上面用route -p的方式，手動添加路由表進行解決

   參考 https://blogs.technet.microsoft.com/timmcmic/2009/04/26/windows-2008-multi-subnet-clusters-and-using-static-routes/ 

  另外也須要考慮跨站點DNS緩存的問題，因爲環境有限，因此在這裏老王只用了一臺DNS服務器，嚴格來講，應該是各站點有本身的DNS服務器的，例如，當前羣集角色testdtc在北京站點的羣集聯機地址是10.0.0.9，可是北京DNS就會記錄這個VCO是這個10網段的地址，而後每隔一段時間複製到保定的DNS服務器，這個複製時間就是個時間差，跨站點故障轉移時間實際也須要考慮到DNS服務器複製的緩存和客戶端的客戶端的緩存，由於在北京沒複製到保定以前，保定從北京或獲得testdtc就是10網段的地址，就會cache下來，客戶端來請求就都返回這個地址，可是當羣集應用轉移到保定，保定是20網段，所以就須要CNO從新註冊VCO的DNS記錄，而後羣集資源名稱才能夠正常聯機對外使用，一般這種跨子網的羣集應用咱們會設置綁定多個IP地址，而後依賴關係設置爲or，即只要其中一個IP能夠活着 綁定註冊DNS就能夠，羣集請求DNS更新了VCO的地址，這時候VCO能夠正常聯機了，可是客戶端能不能訪問了呢，還不必定，由於客戶端還有dns cache，針對於跨站點羣集VCO的DNS緩存和記錄生命週期，後面老王會單獨寫一篇深刻介紹多站點羣集的博客，在裏面會指出一些最佳實踐，其中網絡部分會深刻講解，這裏只是簡單帶過

首先能夠看到節點服務器目前都是正常的狀態，以及按照預約規劃的多站點羣集網絡架構

咱們建立了一個羣集DTC應用，能夠看到當前是主運行在node1節點上

直接將node1進行斷電關機，能夠看到羣集DTC已經轉移至node2繼續提供服務

打開node2服務器系統日誌能夠看到關於檢測node1已經離線了的日誌

這時雖然羣集還能夠運做，可是已經仲裁已經提示警告，意思就是提醒你一下，你以前和我簽定的仲裁協議是多數節點的3節點羣集，如今你壞了一臺了，不能再壞了，再壞羣集就要關了，真實場景下若是三節點羣集壞了一個節點，應該馬上修復節點從新上線，否則再壞一臺羣集將再也不對外提供服務。

這時候咱們將node2也直接斷電關機，咱們失去了整個北京站點，以後打開羣集管理器能夠看到，羣集狀態已經變成了下移，這時候實際上羣集已經再也不對外提供服務，CNO和VCO都將沒法訪問

打開事件管理器系統日誌能夠看到，羣集服務由於仲裁協議違反，已經被迫中止

針對於羣集的分析，主要分爲系統日誌，羣集詳細分析日誌，羣集驗證報告，cluster目錄日誌，cluster.log日誌，其中系統日誌和詳細分析日誌相對比較容易理解，建議你們能夠先從這方面的日誌看起，後面會有文章專門介紹羣集日誌分析

這時羣集因爲連續的節點崩潰已經只剩下最後一個節點，這時候羣集也關閉了，再也不對外提供服務，可是咱們也能夠經過強制啓動的方式把最後一個節點的羣集服務啓動起來，讓羣集繼續對外提供服務，雖然一個節點能承載的負載有限，可是能夠訪問一部分總比什麼也訪問不到強

直接運行命令 

net stop clussvc

net start clussvc /FQ

便可，把羣集服務先中止，而後強制啓動起來

   執行完成強制啓動後能夠看到羣集已經使用，可是羣集有提示咱們，當前是在forcequorum狀態運行，羣集配置可能會丟失

   老王猜測是由於，這是使用多數節點仲裁的緣由，或者共享見證時會遇到的問題，由於這類仲裁模式，羣集數據庫只存在本地節點間互相同步，假設如今只有Node3強制啓動了，其它節點都不在，咱們修改了羣集資源，而後節點3下，其它節點上，會由於時間分區的緣由致使沒法啓動等相似緣由

    所以建議你們強制啓動只能是做爲實在沒辦法下的最後一道手段，能讓羣集短暫的起死回生，可是回生以後應該當即修復其它節點加入羣集，解除ForceQuorum模式。

能夠看到強制啓動以後 羣集DTC服務已經在保定站點正常啓動了起來，羣集名稱對應的IP地址如今是保定那邊的20網段

若是你們點擊一個羣集角色的依賴報告能夠看到相似下面的這種圖，理解依賴關係對於多站點羣集應用上線很重要，AND則表明，雖有關聯的子資源必須聯機，父資源才能夠聯機，OR則表明選項中的幾個子資源有一個活着，父資源就能夠啓動，例如網絡名稱須要綁定IP，若是10能夠綁定註冊就綁定10網段，若是10子網沒法綁定，那麼20網段能夠綁定註冊，網絡名稱也能夠上線聯機。

以上咱們實際看了三節點多數節點仲裁狀況下，節點依次宕機時的處理

接下來咱們再看第二個場景 

 

場景2環境介紹

 北京站點

 Node1 

 管理網卡 10.0.0.3 網關10.0.0.1 DNS10.0.0.2

 存儲網卡 40.0.0.3 網關40.0.0.1

 心跳網卡 18.0.0.1

 Node2 

 管理網卡 10.0.0.4 網關10.0.0.1 DNS10.0.0.2

 存儲網卡 40.0.0.4 網關40.0.0.1

 心跳網卡 18.0.0.2

 08DC

 lan1 10.0.0.2 網關10.0.0.1

 lan2 20.0.0.2 網關10.0.0.1

 lan3 30.0.0.2 網關30.0.0.1

 網關服務器 

 10.0.0.1

 20.0.0.1

 30.0.0.1

 40.0.0.1

 保定站點

 Node3

 管理網卡 20.0.0.5 網關20.0.0.1 DNS10.0.0.2

 存儲網卡 30.0.0.5 網關30.0.0.1

 心跳網卡 18.0.0.3

 Node4

 管理網卡 20.0.0.6 網關20.0.0.1 DNS10.0.0.2

 存儲網卡 30.0.0.6 網關30.0.0.1

 心跳網卡 18.0.0.4

能夠看到羣集已經新增至四個節點，同時也已經配置了磁盤見證

依舊部署一個羣集DTC，目前託管在北京node2節點

咱們直接將node2斷電，能夠看到如今DTC羣集應用已經自動轉移至本站點的node1服務器

接下來咱們把Node1也直接斷電，模擬咱們失去了整個北京站點的節點，能夠看到，因爲咱們採用了磁盤見證，所以咱們能夠接受一半的節點壞掉，羣集依然能夠正常工做，可是提示咱們了，在當前的狀況下，只要再壞掉一個節點或者羣集磁盤宕機，都會致使羣集關閉，這時應該抓緊時間修復北京站點，儘快上線，不要讓這種狀況持續過久

假設這時沒搶救好北京站點，保定站點又壞了一個節點，羣集則會變成下移關閉狀態，全部羣集服務也將都沒法訪問

這時因爲羣集宕機節點數已經違背了仲裁協議中的節點數，所以也只能使用強制啓動的方式把羣集啓動起來，可是這種狀態一樣也不要持續過久，仍是應該儘快修復其它節點上線

接下來咱們來模擬下腦裂的場景，即北京與保定直接發生了網絡分區，兩邊各自爲政，實際最佳老王應該模仿是羣集四個節點先是失去了到仲裁磁盤的鏈接，而後變成四個節點，四個投票的狀況下，中間產生一個分區，可是因爲老王AD和ISCSI模擬在了一塊兒，若是直接把這臺機器宕機全部節點別想正常工做了，所以老王這裏臨時將羣集仲裁模型改成了多數節點，即四個節點，四票的一個多數節點架構，腦裂一觸即發的架構，哇哈哈

這時咱們模擬腦裂分區，將node3和node4直接改到另一個網絡中

So it begin，能夠在node2上面看到只有node1和node2活着，node3 node4造成羣集，或沒法造成

可是若是訪問羣集名稱測試會發現仍是不能訪問的，由於這是羣集已經沒辦法執行仲裁，兩邊沒有一方是多數的，所以整個羣集都將沒辦法正常工做，都在摸瞎胡中

這時因爲域控和存儲在北京這邊，北京這邊能夠正常工做，保定那邊網絡還未修復，所以咱們強制啓動北京的羣集分區，在node2上面運行強制啓動命令

能夠看到只須要在node2上面運行一下強制啓動的命令以後，整個羣集就都變得可用了，node1和node2在同一個分區內，node1感受到node2造成了權威分區因而自動又融入了羣集，但這時因爲咱們是強制啓動的羣集，羣集還處於強制啓動狀態，不論任何狀況下，都不要長時間讓羣集處於強制啓動狀態，仍是應該儘快的去恢復網絡。

能夠看到羣集DTC如今已經在北京站點正常聯機工做

當保定站點網絡修復好了後，這一側的羣集分區感應到了北京的權威羣集分區，就又會自動融合進去，羣集如今又正常工做了，強制啓動狀態的警告也已經消除

  總結一下，咱們看了再多數節點仲裁模型下，羣集節點在不停宕機時羣集的變化處理，又看了在磁盤見證模型下，磁盤在的狀況下，羣集節點在不停宕機時羣集的變化處理，以及磁盤見證不在，發生網絡分區時的變化處理

  簡單來講，在羣集工做狀態中，只要不違揹你與羣集簽定仲裁協議的規則，羣集都是能夠正常運做的，當達到臨界值時，羣集會提醒當前已經達到臨界值，再宕機一票，羣集就要關了，這時候應該要抓緊時間修復羣集其它節點

   而後假設出現了連續宕機的狀況下，只剩下一個節點，或者只剩下少數節點，若是想讓羣集起死回生出來提供服務，可使用強制仲裁的方式，在少數節點的狀況下也可讓羣集啓動起來

  強制仲裁主要就是用於在少數節點的狀況下啓動起來羣集，或者在羣集發生腦裂，50 50的狀況下，啓動起來其中一端出來提供服務，一樣強制仲裁狀態時間不能夠太長，不然會出現配置不一樣步風險，也要儘快修復節點或網絡故障上線纔是

  當咱們執行強制仲裁命令以後，實際上背後羣集會作兩件事，確立強制仲裁一方爲權威方，提高強制仲裁分區的羣集配置Paxos標記提高爲最高，相似於AD裏面的受權恢復，讓強制仲裁的一方爲黃金權威方，羣集將在權威方進行運做，其它節點的羣集配置，將會與強制仲裁一端同步，不能否認強制仲裁，不少時候仍是很實用的

  以上就是老王想和你們說的強制仲裁，以及仲裁處理，但願你們看過以後能有收穫，當羣集出現逐個節點宕機時內心有數該如何處理

  補充幾點

1.強制啓動起來，只是咱們把羣集救活了，可是可不能夠完整的對外提供服務呢，不必定，由於假設是四個節點的羣集，資源都是一致的，那強制啓動起來的節點可否承載起來四個節點的負載呢，這是個問題，若是支持不起來負載，一些羣集應用也是沒辦法聯機訪問的，所以，實際規劃時，也須要考慮到這種只剩下最後一個節點的場景，最佳是設計的時候可以作好規劃，服務器資源足夠，固然最好，也能夠經過規劃羣集應用優先級的方式規劃，一旦發生這種狀況，那些羣集應用優先級比較高，先讓這些應用活起來，或者設置一個冷備機，平時不參加羣集投票，一旦出現這種只剩下一個節點的狀況下，能夠再把冷備節點啓動來承載負載

 2.上面其實還有一種場景老王沒寫到，最後上張圖把，出於好奇心我在2008R2的羣集上面試了下3個節點+見證磁盤的仲裁模型，結果死的很慘，能夠看到，當羣集壞一個節點，就已經告訴我當前已經達到了臨界值，見證磁盤失效或者再壞一個節點節點，羣集就關了，這樣來看徹底沒什麼優點啊，由於我若是3個節點多數節點，我只須要考慮保證兩個節點可用就行了，這樣的話，我還要多考慮一個見證磁盤的可用，對於保持羣集可用可謂一點用處沒有，惟獨能想到的可能就是這種場景下，能夠避免時間分區的問題，若是最後剩下一個節點和見證磁盤，還能夠把配置修改信息同步到見證磁盤，其它節點再上線也能夠正常使用，到了2012時代這個就變了，再也不雞肋，3節點配見證磁盤，不須要強制啓動的狀況下也能夠活到最後一個節點，下篇文章咱們就來實際測試2012時代仲裁發生的變化！