WSFC 仲裁模型選擇

今天咱們再來詳細討論下關於WSFC的仲裁模型，主要仲裁模型的優缺點，應該如何去思考選擇最佳合適方案

WSFC引入仲裁，主要有兩個目的

1.   跟蹤羣集當前運做票數是否符合仲裁模型協定，若是低於最少容許節點，則決定關閉羣集（2012以前）

2.   當發生分區時，確保由多數一方負責接管羣集提供服務，少數票數方將關閉

回顧一下歷史，在2003時代以前，羣集只有一種仲裁模型，即僅磁盤仲裁，在這種模型下，只有磁盤見證會存放羣集數據庫，全部節點啓動前必須可以聯機到磁盤見證獲取羣集數據庫才能夠啓動，當發生分區時，那一側能夠聯繫到磁盤見證，則獲勝，若是在全部節點都正常鏈接到磁盤見證的狀況下，羣集能夠支撐到最後一個節點，可是在此模式下磁盤見證成爲單一故障點，一旦磁盤見證失聯，羣集將關閉，由於僅有磁盤見證有決定羣集是否存活的資格，那時候還沒投票這個概念，只要磁盤見證在，羣集就能夠存活

後來2003時代 開始，MSCS在企業版和數據中心版引入了多數節點集，MNS仲裁模型，這種模型的好處是去中心化，可讓每一個羣集節點本地磁盤也可以存放羣集數據庫，這樣就沒必要每次每次羣集啓動都必需要聯繫見證磁盤，經過MNS仲裁模型，能夠容許羣集大部分節點存活，每一個節點均可以有決定羣集是否存活的資格，即後來多數節點仲裁的前身。

2003 SP1時代 開始，羣集引入了文件共享見證機制，爲了解決兩個節點MNS仲裁模型下，任何一個節點宕機，都將致使羣集關閉，那時引入的文件共享見證和後來的同樣，文件共享見證最開始就不包含羣集數據庫，僅起到一個投票的做用，當羣集當前MNS模型，兩節點加一個文件共享見證，一個節點宕機，另一個節點能夠聯繫到文件共享見證，就能夠存活，由於獲取到了多數節點資格，另外也能夠阻止腦裂，當兩個節點發生分區，都試圖爭奪資源時，那一方能夠聯繫到文件共享見證便可以獲勝維持運行。

從2003SP1推出功能開始，你們就開始在嘗試在MNS仲裁模型+FSW見證上面部署各類羣集應用，當時用的最多的是2003SP1+EX2007 CCR，隨着使用，你們意識到了一個問題，個人FSW共享見證依然是個單一故障點，能不能有什麼機制可讓這個文件共享也高可用，由於默認狀況下，一個理想的場景應該是有第三臺服務器，非羣集節點的服務器來承擔文件共享，其實就是在上面跑一個共享目錄，並不佔用什麼系統資源，可是一旦這臺服務器宕機，那我羣集運做就又沒了保證，因而你們開始想辦法維持FSW服務器的高可用，通過實踐你們一致認爲可行的方案，只有作fileserver cluster，（若是到2012時代應該是傳統羣集文件服務器，而非SOFS），可以維持FSW的高可用，也有人試圖使用DFS，可是後來你們發現了弊端，其主要緣由在於，DFS的意義在於邏輯的屏蔽物理層，例如，對MSCS提供了一個DFSN路徑，可是複合組呢，是兩個站點各自的DFSR服務器，而後每一個站點又各自有一臺羣集節點，當發生分區的時候，每一個站點均可以訪問到文件共享，仍是會出現腦裂分區的問題，由於投票資格仍是一致的，由於DFS全部節點都是AA的，又有這種站點感知設計，因此它並不適合羣集FSW，FSW須要的應該是一個同一時間，只有一個共享服務器提供服務，且發生災難時可以決出分區勝者的。

不過雖說是這樣說，可是真真正正在企業裏面專門爲了羣集文件共享見證而作一個file cluster的仍是少見，但這確實也應該是一個考慮點，若是企業裏面有幾十套羣集，那麼何嘗也不可專門部署一套file cluster提供高可用的文件共享見證，一般國內若是單臺構建文件共享見證，會在DC，DHCP等穩定的服務器進行構建，或單獨構建服務器。

到了2008時代，羣集從MSCS變成了WSFC，仲裁模型也有了新的變化，首先是引入了投票這個概念，把投票引入了羣集仲裁管理器，每一個節點和見證都多了一個投票的屬性，羣集的存活和分區處理開始由投票數決定，雖然機制和2003相似，都是維持多數，可是變的更爲明朗，把之前看不見的東西拿了上來。2008開始仲裁模型分爲四種：僅磁盤，多數節點，多數節點加見證磁盤，多數節點加文件共享，2008時代強制仲裁這一功能也發生了改變，在2003時代若是要執行強制仲裁，須要在羣集關閉的狀況下執行，而且須要給定強制啓動節點列表，2008開始能夠在羣集開啓的狀況下執行強制仲裁，另一點，2008時×××始各個節點和羣集見證磁盤均可以存放羣集數據庫，並且見證磁盤並不是單一故障點，每一個節點的羣集數據庫都是最新的，見證磁盤羣集數據庫不是最新也能夠和其它節點進行同步，這點很是重要。

2008時代雖然引入了四種仲裁模型，但其實2008時代的仲裁仍是比較死板，依然主要強調羣集節點存活必須符合仲裁模型最少節點協定

例如，若是是奇數節點，選擇多數節點仲裁，須要存活至 (節點票數)/2+1，即3節點必需要有兩個節點存活。若是奇數節點選擇磁盤見證或文件共享見證，則一樣智能壞掉一個節點，並不會由於多出見證一票而容許存活至最後一個節點，緣由是若是3節點加磁盤見證，則爲4票，一樣算法除襲來仍然必需要三票存活，宕機一個節點後，見證一票加節點兩票已到極限。

若是偶數節點，選擇多數節點+磁盤見證或多數節點+共享見證，在見證設備在線的狀況下能夠存活至半數節點，若是見證節點不在線，或採用多數節點仲裁，則須要存活 （節點票數/2 )+1，便是說四節點多數節點，至多隻能宕機一臺

所以在2008時代選擇羣集仲裁模型基本上是固態的，若是你但願羣集可以儘量多的時間提供服務，那麼若是你是奇數節點就選擇多數節點仲裁，偶數節點就選擇多數節點加磁盤見證或文件共享見證，偶數節點不能選多數節點，奇數節點不能選見證設備，不然就會浪費一個節點

到了2012時代 開始這種固態的仲裁思惟被打破，羣集開始沒必要遵照仲裁模型的最少節點協定，而是能夠動態調整節點的票數至最後一個節點，微軟於WSFC 2012引入了動態仲裁功能，即動態調整各節點票數，舉個例子，若是5個奇數節點，宕機一個節點後，羣集會再去掉一個節點票數，確保羣集爲3票，再宕機一個節點，正好是3個節點則不作操做，若是是剩下兩個節點，則隨機去掉一個節點的投票，在正常關機，或非票數節點宕機的場景下，能夠存活至最後一個節點，若是票數節點宕機來不及交換投票，則羣集關閉，所以2012動態仲裁存活至最後一個節點的概率爲百分之66。偶數節點一樣，若是四節點，羣集會上來就動態仲裁去掉一個節點的投票，宕機一臺再去掉一票，存活至最後一個節點的概率爲百分之66。

經過動態仲裁始終讓羣集維持奇數投票，從2012開始，羣集再也不維持多數，而是維持奇數，仲裁的目的更多的是幫助咱們存活至最後一個節點，避免腦裂分區

若是咱們在2012時代選擇配置爲偶數節點+見證設備，那麼在見證設備在線的狀況下，羣集能夠存活至最後一個節點，見證設備脫機，則能夠存活爲(節點票數)/2+1

若是咱們在2012時代選擇配置爲奇數節點+見證設備，在宕機一個節點+見證設備脫機的狀況下，羣集將關閉，例如羣集當前三節點，1個節點和見證設備宕機，則羣集會由於剩下兩個投票，沒法決出勝者而關閉，所以，2012時代奇數節點仍是要使用多數節點仲裁模型，2012奇數節點並不會由於見證設備而帶來存活優點

到了2012R2時代，WSFC動態仲裁的基礎上又演變爲動態見證，即羣集始終建議配置磁盤見證或文件共享見證，由於見證設備能夠動態的調整票數，例如3節點+見證磁盤，羣集會自動去掉見證磁盤的一票，如今羣集是三個投票，若是壞掉一個節點，羣集是2個投票，羣集會自動再加上見證的一票，如今羣集又是三票，仍是奇數，這時候若是再壞一個節點，還剩下最後一個節點和見證，羣集依然能夠存活。便是說，只要羣集見證設備設備，不論當前是奇數仍是偶數節點均可以存活至最後一個節點，總之始終爲羣集配置一個見證設備就對了。

以前說過2012開始引入動態仲裁功能，能夠在偶數節點的狀況下，自動去掉一個節點投票，始終維持羣集爲奇數票數，2012R2開始能夠經過LowerQuorumPriorityNodeID屬性指定，始終去掉那個節點的票數

例如，我偶數節點四個節點，分佈在兩個站點，那麼我就能夠指定羣集自動去掉備站點一個節點的投票，這樣備站點僅剩下1票，主站點2票，若是兩個站點發生分區，則主站點直接獲勝，若是主站點所有宕機，備站點也有百分之66的概率能夠直接接管。在2012R2以前，一般咱們會手動直接去掉備站點節點的票數，已達到此效果，可是隻有2012是有百分之66的概率備站點能夠自動接管，2012以前都須要手動強制啓動備站點接管。可是也有一些企業會故意設計成手動故障轉移這種架構，緣由是羣集上層跑的應用故障轉移時間太長，故障轉移以後還須要執行一些操做應用才能提供服務，這種狀況下適用於手動故障轉移。

雖然2012R2說的很好，羣集能夠存活至最後一個節點，可是這句話有一個前提，見證設備在線的狀況下，一旦見證設備脫機，羣集變成百分之五十存活至最後一個節點，這個實驗老王前面的文章已經作過，當前羣集宕機至3節點+見證設備，若是這時候見證設備和一個節點宕機，羣集並不會自動調整投票，仍是2個節點+1個見證投票，但其實這時候應該自動從動態見證切換至動態仲裁，3票變1票，但羣集沒變，若是變了還能夠百分之66存活至最後一臺，但沒變，沒變的話，若是剩下兩個節點，任意一臺宕機，則羣集關閉。

這裏關鍵的問題仍是3剩2的時候，一個節點和見證設備脫機，羣集不能從動態見證切換至動態仲裁，致使羣集仲裁不許，其實這時候羣集應該是先變成2票，而後再動態仲裁去掉1票，可是羣集沒有，沒有自動調整失敗的見證票數，也沒有調整節點的票數，致使的結果就是兩個節點任意一個宕機，羣集關閉。

2012是奇數節點加見證設備，見證設備和節點脫機，一旦羣集變成2節點偶數投票，羣集會直接關閉

2012R2是當剩下奇數節點+見證設備，見證設備和節點脫機，一旦羣集變成2節點偶數投票，壞掉任何一個節點，羣集都會關閉。

說到底，都是見證設備脫機後不能切換爲動態仲裁的緣由

所以2012R2時代見證設備特別重要，只有見證設備在(各個羣集節點能夠訪問)，才能夠存活至最後一個節點

OK，咱們從WSFC仲裁歲月的小河終於說到了近代，在這條漫長的小河中，曾出現過一個激流，這個激流至今也影響着WSFC，它就是羣集數據庫

2008時代 開始WSFC羣集數據庫引入了paxos機制，羣集數據庫在各個節點同步，每一個節點均可以對羣集進行更新，其它節點會跟隨最新修改的節點進行同步，跟隨過程主要對比paxos標記，發現對方的比個人新，則與之同步，羣集數據庫除了在各節點記錄羣集信息一致性用於故障轉移，也用於羣集服務啓動檢查，每次節點羣集服務啓動時都會檢查自身的羣集數據庫是否爲最新，是否和其它節點一致，若是非最新，則須要和其它節點同步後才能上線。

須要注意的是若是羣集使用了見證磁盤，則各節點同步後也會把羣集數據庫同步至見證磁盤一份，見證磁盤的羣集數據庫會在磁盤所在節點被加載。僅磁盤見證裏面會有羣集數據庫，而共享見證和2016雲見證裏面，僅記載着當前羣集最新paxos標記是多少。

當出現一個時間分區的場景時就能看出究竟那種仲裁模型更優秀

時間節點1 節點1 節點2 文件共享在線

時間節點2 節點1宕機

時間節點3 節點2修改羣集數據

時間節點4 節點2宕機

時間節點5 節點1啓動

若是使用的是文件共享見證，這時候節點1會由於當前節點沒有最新的羣集數據庫而沒法啓動，羣集啓動時和文件共享裏面的paxos標記對照，發現爲舊，則羣集成員管理器阻止該節點啓動，這時候只有等待節點2開機後，節點1才能夠與其同步羣集數據庫後啓動，若是不等待節點2開機，強制在節點1啓動，則節點1的羣集數據庫將會被提高爲黃金副本，節點2啓動後會被節點1的黃金副本覆蓋，致使以前修改的羣集數據丟失，雲共享見證一樣。

若是使用的是磁盤見證，時間節點5的時候，節點1啓動，啓動後會聯繫到見證磁盤，由於羣集數據庫也會在見證磁盤同步，時間節點3修改時，羣集見證磁盤也會同步到，因此節點1能夠從見證磁盤獲取到最新paxos標記的羣集數據庫，而正常啓動。

基於此，老王的建議是2012R2的羣集，不管是奇數節點或偶數節點，都配置見證磁盤

您也能夠選擇多數節點，可是多數節點動態仲裁的弊端在於：百分之六十六支持到最後一個節點

多數節點加見證磁盤，您須要維護確保見證磁盤始終在線

二者都須要有一個權衡的點

進一步討論的話，老王認爲若是是在同一個數據中心內的話，見證磁盤加多數節點，毫無疑問，首先就應該選擇它，只要見證磁盤在線，羣集就百分百可以挺到最後一個節點，至於見證磁盤的可靠性，能夠在陣列上面經過配置Raid，配置各節點到陣列的多路徑，以保證見證磁盤的持續可用，或者底層直接由超融合軟件，例如S2D，VSAN跨機架構建起虛擬磁盤，再使用虛擬磁盤建立羣集見證磁盤。

若是是異地數據中心的話，在條件容許的狀況下，老王仍然建議使用見證磁盤，見證磁盤加多數節點 2012R2以後永遠是最佳方案，異地數據中心的羣集架構，一般架構師會推薦兩種方案，一種是第三個數據中心存放見證設備，兩數據中心鏈接第三個數據中心，可是這樣作的話，又須要額外考慮兩個數據中心到第三個數據中心之間的鏈路問題，帶來額外的成本，另一種是如今用的比較多的，存儲複製，即在兩個數據中心各一個存儲設備，互相作同步複製，通常是硬件設備直接實現，或軟件實現，一個站點宕機後，直接另一個站點存儲和計算都啓動起來，須要注意，若是涉及到見證磁盤的複製，目前2016的存儲複製仍是不能實現，2016存儲複製只能複製CSV和角色磁盤，不能複製見證磁盤。

說到底仍是成本的問題，若是資金容許的狀況下能夠在第三個站點分配見證磁盤到兩個數據中心，或直接兩個站點同步存儲複製陣列

若是資金不容許的狀況下，能夠在第三個站點找一臺文件服務器，作文件共享見證，分配到兩個數據中心，這樣作也能夠，只須要規避掉時間分區的問題就能夠了，例如已經出現有節點宕機的狀況下，不在現有節點上面修改羣集數據

或者若是連第三個站點也沒有的狀況下，可使用2016的雲共享見證，在Azure上面開個blob用於羣集仲裁，但須要開通本地數據中心到Azure的443端口

雖然文件共享見證和雲見證沒有羣集數據庫，可是這兩種仲裁模型也能夠支持動態見證仲裁模型，幫助羣集支撐到最後一個節點，避免腦裂分區問題。

不管是文件共享見證，仍是雲見證，仍是磁盤見證，異地數據中心最主要關注的仍是鏈路問題，各節點到見證設備的鏈路不須要很快，但必定要保證質量。