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時代仲裁發生的變化！