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端口

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

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