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

創(chuàng)新互聯(lián)公司專業(yè)成都網(wǎng)站設計、成都網(wǎng)站建設、外貿(mào)網(wǎng)站建設，集網(wǎng)站策劃、網(wǎng)站設計、網(wǎng)站制作于一體，網(wǎng)站seo、網(wǎng)站優(yōu)化、網(wǎng)站營銷、軟文平臺等專業(yè)人才根據(jù)搜索規(guī)律編程設計，讓網(wǎng)站在運行后，在搜索中有好的表現(xiàn)，專業(yè)設計制作為您帶來效益的網(wǎng)站！讓網(wǎng)站建設為您創(chuàng)造效益。

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

1.   跟蹤群集當前運作票數(shù)是否符合仲裁模型協(xié)定，如果低于最少允許節(jié)點，則決定關閉群集（2012之前）

2.   當發(fā)生分區(qū)時，確保由多數(shù)一方負責接管群集提供服務，少數(shù)票數(shù)方將關閉

回顧一下歷史，在2003時代之前，群集只有一種仲裁模型，即僅磁盤仲裁，在這種模型下，只有磁盤見證會存放群集數(shù)據(jù)庫，所有節(jié)點啟動前必須能夠聯(lián)機到磁盤見證獲取群集數(shù)據(jù)庫才可以啟動，當發(fā)生分區(qū)時，那一側可以聯(lián)系到磁盤見證，則獲勝，如果在所有節(jié)點都正常連接到磁盤見證的情況下，群集可以支撐到最后一個節(jié)點，但是在此模式下磁盤見證成為單一故障點，一旦磁盤見證失聯(lián)，群集將關閉，因為僅有磁盤見證有決定群集是否存活的資格，那時候還沒投票這個概念，只要磁盤見證在，群集就可以存活

后來2003時代 開始，MSCS在企業(yè)版和數(shù)據(jù)中心版引入了多數(shù)節(jié)點集，MNS仲裁模型，這種模型的好處是去中心化，可以讓每個群集節(jié)點本地磁盤也能夠存放群集數(shù)據(jù)庫，這樣就不必每次每次群集啟動都必須要聯(lián)系見證磁盤，通過MNS仲裁模型，可以允許群集大部分節(jié)點存活，每個節(jié)點都可以有決定群集是否存活的資格，即后來多數(shù)節(jié)點仲裁的前身。

2003 SP1時代 開始，群集引入了文件共享見證機制，為了解決兩個節(jié)點MNS仲裁模型下，任何一個節(jié)點宕機，都將導致群集關閉，那時引入的文件共享見證和后來的一樣，文件共享見證最開始就不包含群集數(shù)據(jù)庫，僅起到一個投票的作用，當群集當前MNS模型，兩節(jié)點加一個文件共享見證，一個節(jié)點宕機，另外一個節(jié)點可以聯(lián)系到文件共享見證，就可以存活，因為獲取到了多數(shù)節(jié)點資格，另外也可以阻止腦裂，當兩個節(jié)點發(fā)生分區(qū)，都試圖爭奪資源時，那一方可以聯(lián)系到文件共享見證即可以獲勝維持運行。

從2003SP1推出功能開始，大家就開始在嘗試在MNS仲裁模型+FSW見證上面部署各種群集應用，當時用的最多的是2003SP1+EX2007 CCR，隨著使用，大家意識到了一個問題，我的FSW共享見證依然是個單一故障點，能不能有什么機制可以讓這個文件共享也高可用，因為默認情況下，一個理想的場景應該是有第三臺服務器，非群集節(jié)點的服務器來承擔文件共享，其實就是在上面跑一個共享目錄，并不占用什么系統(tǒng)資源，但是一旦這臺服務器宕機，那我群集運作就又沒了保證，于是大家開始想辦法維持FSW服務器的高可用，經(jīng)過實踐大家一致認為可行的方案，只有做fileserver cluster，（如果到2012時代應該是傳統(tǒng)群集文件服務器，而非SOFS），能夠維持FSW的高可用，也有人試圖使用DFS，但是后來大家發(fā)現(xiàn)了弊端，其主要原因在于，DFS的意義在于邏輯的屏蔽物理層，例如，對MSCS提供了一個DFSN路徑，但是復合組呢，是兩個站點各自的DFSR服務器，然后每個站點又各自有一臺群集節(jié)點，當發(fā)生分區(qū)的時候，每個站點都可以訪問到文件共享，還是會出現(xiàn)腦裂分區(qū)的問題，因為投票資格還是一致的，因為DFS所有節(jié)點都是AA的，又有這種站點感知設計，所以它并不適合群集FSW，F(xiàn)SW需要的應該是一個同一時間，只有一個共享服務器提供服務，且發(fā)生災難時能夠決出分區(qū)勝者的。

不過雖然說是這樣說，但是真真正正在企業(yè)里面專門為了群集文件共享見證而做一個file cluster的還是少見，但這確實也應該是一個考慮點，如果企業(yè)里面有幾十套群集，那么未嘗也不可專門部署一套file cluster提供高可用的文件共享見證，通常國內(nèi)如果單臺構建文件共享見證，會在DC，DHCP等穩(wěn)定的服務器進行構建，或單獨構建服務器。

到了2008時代，群集從MSCS變成了WSFC，仲裁模型也有了新的變化，首先是引入了投票這個概念，把投票引入了群集仲裁管理器，每個節(jié)點和見證都多了一個投票的屬性，群集的存活和分區(qū)處理開始由投票數(shù)決定，雖然機制和2003類似，都是維持多數(shù)，但是變的更為明朗，把以前看不見的東西拿了上來。2008開始仲裁模型分為四種：僅磁盤，多數(shù)節(jié)點，多數(shù)節(jié)點加見證磁盤，多數(shù)節(jié)點加文件共享，2008時代強制仲裁這一功能也發(fā)生了改變，在2003時代如果要執(zhí)行強制仲裁，需要在群集關閉的情況下執(zhí)行，并且需要給定強制啟動節(jié)點列表，2008開始可以在群集開啟的情況下執(zhí)行強制仲裁，另外一點，2008時×××始各個節(jié)點和群集見證磁盤都可以存放群集數(shù)據(jù)庫，而且見證磁盤并非單一故障點，每個節(jié)點的群集數(shù)據(jù)庫都是最新的，見證磁盤群集數(shù)據(jù)庫不是最新也可以和其它節(jié)點進行同步，這點非常重要。

2008時代雖然引入了四種仲裁模型，但其實2008時代的仲裁還是比較死板，依然主要強調(diào)群集節(jié)點存活必須符合仲裁模型最少節(jié)點協(xié)定

例如，如果是奇數(shù)節(jié)點，選擇多數(shù)節(jié)點仲裁，需要存活至 (節(jié)點票數(shù))/2+1，即3節(jié)點必須要有兩個節(jié)點存活。如果奇數(shù)節(jié)點選擇磁盤見證或文件共享見證，則同樣智能壞掉一個節(jié)點，并不會因為多出見證一票而允許存活至最后一個節(jié)點，原因是如果3節(jié)點加磁盤見證，則為4票，同樣算法除襲來仍然必須要三票存活，宕機一個節(jié)點后，見證一票加節(jié)點兩票已到極限。

如果偶數(shù)節(jié)點，選擇多數(shù)節(jié)點+磁盤見證或多數(shù)節(jié)點+共享見證，在見證設備在線的情況下可以存活至半數(shù)節(jié)點，如果見證節(jié)點不在線，或采用多數(shù)節(jié)點仲裁，則需要存活 （節(jié)點票數(shù)/2 )+1，即是說四節(jié)點多數(shù)節(jié)點，至多只能宕機一臺

因此在2008時代選擇群集仲裁模型基本上是固態(tài)的，如果你希望群集能夠盡可能多的時間提供服務，那么如果你是奇數(shù)節(jié)點就選擇多數(shù)節(jié)點仲裁，偶數(shù)節(jié)點就選擇多數(shù)節(jié)點加磁盤見證或文件共享見證，偶數(shù)節(jié)點不能選多數(shù)節(jié)點，奇數(shù)節(jié)點不能選見證設備，否則就會浪費一個節(jié)點

到了2012時代 開始這種固態(tài)的仲裁思維被打破，群集開始不必遵守仲裁模型的最少節(jié)點協(xié)定，而是可以動態(tài)調(diào)整節(jié)點的票數(shù)至最后一個節(jié)點，微軟于WSFC 2012引入了動態(tài)仲裁功能，即動態(tài)調(diào)整各節(jié)點票數(shù)，舉個例子，如果5個奇數(shù)節(jié)點，宕機一個節(jié)點后，群集會再去掉一個節(jié)點票數(shù)，確保群集為3票，再宕機一個節(jié)點，正好是3個節(jié)點則不做操作，如果是剩下兩個節(jié)點，則隨機去掉一個節(jié)點的投票，在正常關機，或非票數(shù)節(jié)點宕機的場景下，可以存活至最后一個節(jié)點，如果票數(shù)節(jié)點宕機來不及交換投票，則群集關閉，因此2012動態(tài)仲裁存活至最后一個節(jié)點的幾率為百分之66。偶數(shù)節(jié)點同樣，如果四節(jié)點，群集會上來就動態(tài)仲裁去掉一個節(jié)點的投票，宕機一臺再去掉一票，存活至最后一個節(jié)點的幾率為百分之66。

通過動態(tài)仲裁始終讓群集維持奇數(shù)投票，從2012開始，群集不再維持多數(shù)，而是維持奇數(shù)，仲裁的目的更多的是幫助我們存活至最后一個節(jié)點，避免腦裂分區(qū)

如果我們在2012時代選擇配置為偶數(shù)節(jié)點+見證設備，那么在見證設備在線的情況下，群集可以存活至最后一個節(jié)點，見證設備脫機，則可以存活為(節(jié)點票數(shù))/2+1

如果我們在2012時代選擇配置為奇數(shù)節(jié)點+見證設備，在宕機一個節(jié)點+見證設備脫機的情況下，群集將關閉，例如群集當前三節(jié)點，1個節(jié)點和見證設備宕機，則群集會因為剩下兩個投票，無法決出勝者而關閉，因此，2012時代奇數(shù)節(jié)點還是要使用多數(shù)節(jié)點仲裁模型，2012奇數(shù)節(jié)點并不會因為見證設備而帶來存活優(yōu)勢

到了2012R2時代，WSFC動態(tài)仲裁的基礎上又演變?yōu)閯討B(tài)見證，即群集始終建議配置磁盤見證或文件共享見證，因為見證設備可以動態(tài)的調(diào)整票數(shù)，例如3節(jié)點+見證磁盤，群集會自動去掉見證磁盤的一票，現(xiàn)在群集是三個投票，如果壞掉一個節(jié)點，群集是2個投票，群集會自動再加上見證的一票，現(xiàn)在群集又是三票，還是奇數(shù)，這時候如果再壞一個節(jié)點，還剩下最后一個節(jié)點和見證，群集依然可以存活。即是說，只要群集見證設備設備，不論當前是奇數(shù)還是偶數(shù)節(jié)點都可以存活至最后一個節(jié)點，總之始終為群集配置一個見證設備就對了。

之前說過2012開始引入動態(tài)仲裁功能，可以在偶數(shù)節(jié)點的情況下，自動去掉一個節(jié)點投票，始終維持群集為奇數(shù)票數(shù)，2012R2開始可以通過LowerQuorumPriorityNodeID屬性指定，始終去掉那個節(jié)點的票數(shù)

例如，我偶數(shù)節(jié)點四個節(jié)點，分布在兩個站點，那么我就可以指定群集自動去掉備站點一個節(jié)點的投票，這樣備站點僅剩下1票，主站點2票，如果兩個站點發(fā)生分區(qū)，則主站點直接獲勝，如果主站點全部宕機，備站點也有百分之66的幾率可以直接接管。在2012R2之前，通常我們會手動直接去掉備站點節(jié)點的票數(shù)，已達到此效果，但是只有2012是有百分之66的幾率備站點可以自動接管，2012之前都需要手動強制啟動備站點接管。但是也有一些企業(yè)會故意設計成手動故障轉(zhuǎn)移這種架構，原因是群集上層跑的應用故障轉(zhuǎn)移時間太長，故障轉(zhuǎn)移之后還需要執(zhí)行一些操作應用才能提供服務，這種情況下適用于手動故障轉(zhuǎn)移。

雖然2012R2說的很好，群集可以存活至最后一個節(jié)點，但是這句話有一個前提，見證設備在線的情況下，一旦見證設備脫機，群集變成百分之五十存活至最后一個節(jié)點，這個實驗老王前面的文章已經(jīng)做過，當前群集宕機至3節(jié)點+見證設備，如果這時候見證設備和一個節(jié)點宕機，群集并不會自動調(diào)整投票，還是2個節(jié)點+1個見證投票，但其實這時候應該自動從動態(tài)見證切換至動態(tài)仲裁，3票變1票，但群集沒變，如果變了還可以百分之66存活至最后一臺，但沒變，沒變的話，如果剩下兩個節(jié)點，任意一臺宕機，則群集關閉。

這里關鍵的問題還是3剩2的時候，一個節(jié)點和見證設備脫機，群集不能從動態(tài)見證切換至動態(tài)仲裁，導致群集仲裁不準，其實這時候群集應該是先變成2票，然后再動態(tài)仲裁去掉1票，但是群集沒有，沒有自動調(diào)整失敗的見證票數(shù)，也沒有調(diào)整節(jié)點的票數(shù)，導致的結果就是兩個節(jié)點任意一個宕機，群集關閉。

2012是奇數(shù)節(jié)點加見證設備，見證設備和節(jié)點脫機，一旦群集變成2節(jié)點偶數(shù)投票，群集會直接關閉

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

說到底，都是見證設備脫機后不能切換為動態(tài)仲裁的原因

因此2012R2時代見證設備特別重要，只有見證設備在(各個群集節(jié)點可以訪問)，才可以存活至最后一個節(jié)點

OK，我們從WSFC仲裁歲月的小河終于說到了近代，在這條漫長的小河中，曾出現(xiàn)過一個激流，這個激流至今也影響著WSFC，它就是群集數(shù)據(jù)庫

2008時代 開始WSFC群集數(shù)據(jù)庫引入了paxos機制，群集數(shù)據(jù)庫在各個節(jié)點同步，每個節(jié)點都可以對群集進行更新，其它節(jié)點會跟隨最新修改的節(jié)點進行同步，跟隨過程主要對比paxos標記，發(fā)現(xiàn)對方的比我的新，則與之同步，群集數(shù)據(jù)庫除了在各節(jié)點記錄群集信息一致性用于故障轉(zhuǎn)移，也用于群集服務啟動檢查，每次節(jié)點群集服務啟動時都會檢查自身的群集數(shù)據(jù)庫是否為最新，是否和其它節(jié)點一致，如果非最新，則需要和其它節(jié)點同步后才能上線。

需要注意的是如果群集使用了見證磁盤，則各節(jié)點同步后也會把群集數(shù)據(jù)庫同步至見證磁盤一份，見證磁盤的群集數(shù)據(jù)庫會在磁盤所在節(jié)點被加載。僅磁盤見證里面會有群集數(shù)據(jù)庫，而共享見證和2016云見證里面，僅記載著當前群集最新paxos標記是多少。

當出現(xiàn)一個時間分區(qū)的場景時就能看出究竟那種仲裁模型更優(yōu)秀

時間節(jié)點1 節(jié)點1 節(jié)點2 文件共享在線

時間節(jié)點2 節(jié)點1宕機

時間節(jié)點3 節(jié)點2修改群集數(shù)據(jù)

時間節(jié)點4 節(jié)點2宕機

時間節(jié)點5 節(jié)點1啟動

如果使用的是文件共享見證，這時候節(jié)點1會因為當前節(jié)點沒有最新的群集數(shù)據(jù)庫而無法啟動，群集啟動時和文件共享里面的paxos標記對照，發(fā)現(xiàn)為舊，則群集成員管理器阻止該節(jié)點啟動，這時候只有等待節(jié)點2開機后，節(jié)點1才可以與其同步群集數(shù)據(jù)庫后啟動，如果不等待節(jié)點2開機，強制在節(jié)點1啟動，則節(jié)點1的群集數(shù)據(jù)庫將會被提升為黃金副本，節(jié)點2啟動后會被節(jié)點1的黃金副本覆蓋，導致之前修改的群集數(shù)據(jù)丟失，云共享見證同樣。

如果使用的是磁盤見證，時間節(jié)點5的時候，節(jié)點1啟動，啟動后會聯(lián)系到見證磁盤，因為群集數(shù)據(jù)庫也會在見證磁盤同步，時間節(jié)點3修改時，群集見證磁盤也會同步到，所以節(jié)點1可以從見證磁盤獲取到最新paxos標記的群集數(shù)據(jù)庫，而正常啟動。

基于此，老王的建議是2012R2的群集，不論是奇數(shù)節(jié)點或偶數(shù)節(jié)點，都配置見證磁盤

您也可以選擇多數(shù)節(jié)點，但是多數(shù)節(jié)點動態(tài)仲裁的弊端在于：百分之六十六支持到最后一個節(jié)點

多數(shù)節(jié)點加見證磁盤，您需要維護確保見證磁盤始終在線

兩者都需要有一個權衡的點

進一步討論的話，老王認為如果是在同一個數(shù)據(jù)中心內(nèi)的話，見證磁盤加多數(shù)節(jié)點，毫無疑問，首先就應該選擇它，只要見證磁盤在線，群集就百分百能夠挺到最后一個節(jié)點，至于見證磁盤的可靠性，可以在陣列上面通過配置Raid，配置各節(jié)點到陣列的多路徑，以保證見證磁盤的持續(xù)可用，或者底層直接由超融合軟件，例如S2D，VSAN跨機架構建起虛擬磁盤，再使用虛擬磁盤創(chuàng)建群集見證磁盤。

如果是異地數(shù)據(jù)中心的話，在條件允許的情況下，老王仍然建議使用見證磁盤，見證磁盤加多數(shù)節(jié)點 2012R2之后永遠是最佳方案，異地數(shù)據(jù)中心的群集架構，通常架構師會推薦兩種方案，一種是第三個數(shù)據(jù)中心存放見證設備，兩數(shù)據(jù)中心連接第三個數(shù)據(jù)中心，但是這樣做的話，又需要額外考慮兩個數(shù)據(jù)中心到第三個數(shù)據(jù)中心之間的鏈路問題，帶來額外的成本，另外一種是現(xiàn)在用的比較多的，存儲復制，即在兩個數(shù)據(jù)中心各一個存儲設備，互相做同步復制，一般是硬件設備直接實現(xiàn)，或軟件實現(xiàn)，一個站點宕機后，直接另外一個站點存儲和計算都啟動起來，需要注意，如果涉及到見證磁盤的復制，目前2016的存儲復制還是不能實現(xiàn)，2016存儲復制只能復制CSV和角色磁盤，不能復制見證磁盤。

說到底還是成本的問題，如果資金允許的情況下可以在第三個站點分配見證磁盤到兩個數(shù)據(jù)中心，或直接兩個站點同步存儲復制陣列

如果資金不允許的情況下，可以在第三個站點找一臺文件服務器，做文件共享見證，分配到兩個數(shù)據(jù)中心，這樣做也可以，只需要規(guī)避掉時間分區(qū)的問題就可以了，例如已經(jīng)出現(xiàn)有節(jié)點宕機的情況下，不在現(xiàn)有節(jié)點上面修改群集數(shù)據(jù)

或者如果連第三個站點也沒有的情況下，可以使用2016的云共享見證，在Azure上面開個blob用于群集仲裁，但需要開通本地數(shù)據(jù)中心到Azure的443端口

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

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