WSFC基礎知識奠基

  前面主要和大家介紹了一下群集的種類，以及一些群集通用的基本知識，本章開始我們將專注于微軟故障轉移群集的深入研究與理論解析

  微軟故障轉移群集即是我們上篇文章介紹的，一個典型的高可用性群集解決方案，它內置在Windows Server的角色與功能里面，不需要安裝額外工具，故障轉移群集通常情況下都是主從工作的模式，即一個群集應用同時只有一個節點對外提供服務，然后故障轉移群集利用心跳檢測機制檢測節點存活狀態，一旦檢測到節點宕機，會通過查詢群集數據庫，來講宕機節點承載的群集應用進行上線

  同時故障轉移群集也具備了完善的群集應用健康感知，節點健康狀態感知，群集健康狀態感知，這在2008時代之后開始得到增強，12R2時趨于成熟。

  有的群集應用可以和DNS輪詢相配合，或者群集應用本身具備的輪詢技術，則可以基于故障轉移群集來實現雙活的群集應用工作模式，例如SOFS，SQL Server Always On等技術

  微軟故障轉移群集于NT4時代就被引入，那時它叫做 MSCS(Microsoft Cluster Service),2003時代正式全面提供使用，更多企業開始采用MSCS搭建群集，但2003時代的群集，雖說2003是個出色的系統，上面跑業務也相對穩定，但是2003時代的MSCS群集配置也確實麻煩了一些，讓很多人望而卻步，不過話說回來，2003時代的群集，老王認為是最便于IT人員理解群集運作原理的版本之一

  到了2008時，群集開始發生了改變，它改名叫做WSFC (Windows Server Failover Clustering),提供了群集創建向導，幫助相關人員可以更快更簡單的創建使用高可用群集，以前2003時代可以能創建一個群集要花費一小天的時間，到了2008時代規劃好了開始做可能也就1-2小時就可以完成

  2008時代老王可以算是WSFC的一個轉折點，這個時代，群集摒棄了2003時代的UI，換了新的群集UI，把原有的群集組等技術細節進行了屏蔽，換成了看起來更容易的添加群集角色，新增了全新的群集驗證報告

  2008R2，這個版本微軟發布了大量的更新，其中針對于群集，微軟推出了CSV群集文件系統，改變了群集虛擬化的運作模式，原來2008如果在群集上面跑虛擬機，都是以傳統群集組的方式運作，假設10臺虛擬機運行在一個群集磁盤上面，如果要遷移其中一臺虛擬機，只能把其余9臺一起遷移，因為他們是一個整體的傳統群集組，到了2008R2有了CSV之后，這個做法發生了一些改變，所有節點都可以同時讀取CSV文件系統，虛擬機也有了新的群集組模式，可以一次遷移一臺虛擬機。

  2012，2012R2時代是微軟WSFC大放光彩的一代，2012時代微軟推出了動態投票的概念，2012R2時代更新為動態仲裁，即群集可以自動幫助我們調整節點和見證的投票數，確保群集始終是奇數的投票，這在以前，是需要我們管理人員實現設計好的，群集可不會自動幫助我們做這些事

  同時，2012時代，還對群集在少數投票，平等投票場景上面新增了很多新的屬性，例如Lowerquorumprioritynodeid，可以幫助我們在分區兩端投票數一致的情況下選擇其中一方關閉，2012 2012R2時代的群集，針對于群集仲裁，群集節點維護，推出了很多很棒，很智能化的功能，例如

DrainOnShutdown，CAU等

  簡單說，2012 2012R2時代的群集，在成熟化的基礎上更趨于智能化，群集可以自己進行一部分自我化的維護管理，來保證群集的持續高可用，也新增了一些智能化的功能，讓管理員可以根據業務場景做更多的群集設計。

  到了2016時代，老王認為群集更靠近了云端化，借助了部分云端的功能來幫助群集，也針對當前熱門的超融合技術進行了支援，2016時代，群集仲裁可以使用Azure上面blob進行仲裁，這在之前，可能架構管理人員在設計仲裁位置的時候，可能會和其中一個站點的群集放在一起，或者單獨放在第三個站點中，現在借助Azure上面的blob實現可以節省一部分成本，還可以利用Azure上面存儲的冗余技術，2016群集也開始支援SDS技術，類似于VSAN，可以把多個服務器上面節點肚子里面的存儲，貢獻出來形成群集的存儲池，然后基于這個貢獻的群集存儲池，上面再跑群集應用。

  總結來說，2016時代的群集，借助了云的功能來優化群集，也針對于當下熱門的技術，瞬時防斷，滾動更新，SDS超融合，存儲復制，延伸群集等技術進行了更新，可以看到WSFC不斷在跟著時代的腳步進步，不斷更新，可以滿足更多場景的需求

  以上老王簡單的對微軟故障轉移群集的發展歷史做了個基本介紹，其中涉及到了一些概念，例如群集組，仲裁，見證，我將在接下來為大家進行講解，涉及到的2012及2016新功能，后續有時間也將寫出博客與大家探討，下文將對微軟故障轉移群集統一簡稱為WSFC

 在正式介紹群集細節概念之前，我們先來看下WSFC對于硬件軟件的要求

  1.確保多個節點可以訪問到相同內容的共享存儲，不論是SAS，ISCSI，FCOE，JBOD,RBOD，或是SDS出來的都可以，確保同一個共享存儲可以被所有群集內節點訪問，以便發生故障轉移時其它節點可以從共享存儲上線資源

  2.確保群集節點OS是正版，非盜版，否則可能會遇見一些奇奇怪怪的問題

  3.確保群集節點是域成員，在2012時×××始發生了一些改變，2012時代提出了不依賴AD的群集架構，即是說，群集應用可以不創建VC0，但仍然需要節點加入域，2016時×××始支持真正的工作組群集，跨域，跨林架構的群集。

  4.確保群集節點硬件相同，這個并非硬性要求，但是強烈建議各節點硬件采用完全一致的服務器，否則會出現虛擬機無法遷移等情況，老王還建議針對群集節點服務器采用模塊化便于擴展的架構，充分利用例如冗余交換機，熱拔插，RAID，MPIO，網卡組合，LBFO，ODX，RDMA，RSS等高可用技術和硬件卸載技術，消除單一故障點。

  5.確保創建群集的賬戶是群集節點本機的本地管理員權限，同時也在AD具備一定的寫入權限，或者是預先被AD管理員設置好的權限。

  6.確保群集節點至少一塊可用網卡，即使群集節點只有一個卡你也可以安裝起一個群集，但是建議至少兩塊，原因之前博客已經說過，傳送門：http://wzde2012.blog.51cto.com/6474289/1947451 ，如果不做虛擬化，最好三塊卡，做虛擬化建議4塊，群集對外的管理地址，可以是IPv6或者IPV4，可以是DHCP或者靜態，到了2008時代之后微軟并沒有嚴格限制，但是通常我們都是采用靜態IP地址，不過在多站點場景下DHCP有時候會減少一部分宕機時間，后續博客會提到。

 針對于群集網絡的設置這里多說幾句，針對于群集通訊網卡，建議禁止netbios注冊查找，這樣做了之后群集名稱就會僅解析到對外的網絡，并不會在心跳網絡上面試圖進行netbios解析，DNS解析，防止進行干擾

 建議調整網卡順序將群集對外網卡設置優先級最高，其次是心跳卡或存儲卡，微軟也曾說過，2012時代之后網卡順序開始不再重要，但還是建議遵守下

 在2003時代，只有企業版和數據中心版可以安裝MSCS群集功能，2008時代也是只有企業版，數據中心版可以安裝WSFC功能，標準版和Web版只可以安裝NLB群集，在2008時×××始有Core版本，Core版本也可以安裝群集功能，但同樣只有企業版和數據中心版可以，到了2012時代，只有標準版和數據中心版，兩個版本功能一致都可以安裝群集功能，區別只在于虛擬化OS授權，2016同2012一樣。

  WSFC群集支持節點是虛擬機也支持節點是物理機，你可以一個節點是物理機一個節點是虛擬機，也可以兩個節點都是虛擬機，也可以在物理機群集上面再搭建虛擬群集，WSFC群集并不care你到底是物理還是虛擬，只要系統，網絡，存儲配置符合群集標準即可

 以上為群集安裝時的一些硬性要求，以及建議，實際操作的時候建議大家去看下technet，按照technet的文檔進行執行，老王這里只選出安裝要求

要點作為介紹，下面將開始介紹WSFC群集的工作原理和細部概念

 首先我們先來看一下WSFC故障轉移簡單的工作原理，有個大概的印象

  1.首先按照要求部署配置群集節點，確保群集服務器利用了冗余技術消除了服務器，網絡，存儲的單一故障點

  2.保證群集內所有節點都可以訪問到共享存儲

  3.群集應用將應用數據寫入到群集共享存儲

  4.管理員新增節點1服務器上面功能角色，新增完成后節點1服務器群集數據庫記錄新增的角色功能以及相關聯的信息，稍后會把信息同步至其它節點2，及群集仲裁磁盤

  5.群集節點之間按照預定的心跳檢測頻率進行全網握手檢測

  6.節點1出現故障服務器忽然關機，這時節點2心跳檢測頻率達到閾值，判定節點1已經離線

  7.節點2判定節點1已經離線后，會根據已經同步的群集數據庫信息，查看節點1服務器當前承載的群集應用，重新將群集應用與關聯IP地址，群集磁盤在節點2進行上線

  8.客戶端正常訪問群集名稱，使用群集服務，但原有節點1的群集應用，現已由節點2提供，故障轉移結束

 總結下這里關鍵的兩個點

  1.共享存儲一定要確保是所有節點都可以訪問，都可以做正常掛載卸載的，因為一個傳統的群集應用數據一定是寫入共享存儲里面，共享存儲成了權威的存儲源，當其中節點宕機，其它節點會查看群集數據庫的信息，然后掛載上共享存儲，重新上線應用，因此共享存儲的訪問一定要確保

  2.群集數據庫是WSFC的運作的主要概念之一，群集數據庫里面會記載著群集應用當前的狀態，例如當前節點1運行了一個DHCP角色，狀態是上線，運行了一個文件服務器角色，狀態是離線，以及群集配置，群集成員配置，群集資源的添加，創建，啟動，刪除，停止，下線等狀態變化，群集數據庫就是為了幫助各個節點知道對方上面運行了什么樣的群集服務，一旦對方宕機之后，將按照群集數據庫里面的進行的狀態信息連接上共享存儲進行故障轉移上線操作

 說起群集的細部概念呢，老王想先從CNO和VCO講起，因為經過考慮先講這兩個會便于后面概念的理解起來更順暢

 那么什么是CNO呢，之前還記得老王在寫群集介紹的時候曾經和大家說過，群集就是讓一組計算機協作工作，對外感覺就好像一臺計算機在提供服務一樣，這臺讓人感覺是一臺對外提供的計算機，就是CNO了，也叫群集管理對象，當我們運行群集創建向導時會提示讓我們輸入一個群集名稱和群集IP地址，實際上群集創建向導會用我們運行這個群集創建向導的賬號，去群集中創建一個計算機對象，計算機對象的名稱就是我們輸入的群集名稱，同時也會創建出相對的DNS記錄，有計算機對象了，有DNS記錄了，也有IP地址了，像是一臺計算機了對不對。

 這里關鍵的點，要確保運行群集創建向導的賬戶，有權限在AD中寫入計算機對象，默認需要在AD域級別賦予權限，也可以采用實現創建好計算機對象的方式，創建好對應名稱的CNO計算機對象，即創建向導賬戶對其具備完全控制權限，然后將賬戶加入到群集節點本地管理員組，這就是該賬戶所需要的權限

 當創建出CNO后 , CNO即作為群集管理點，以后我們管理群集，直接輸入CNO群集名稱即可，除了作為群集管理點，一些不需要創建VCO的群集角色也可以直接使用CNO作為對外訪問名稱，CNO具備一定的自我管理特性，當CNO被正常創建出來之后，CNO就會維護群集角色虛擬計算機VCO，及VCO的DNS記錄

  所謂VCO，即是說，一些基于WSFC群集上面跑的應用，需要有自己單獨計算機對象和名稱的，例如SQL，文件服務器角色，當它們需要使用Kerberos 身份驗證的時候就需要計算機對象，我們在群集中添加角色和功能的時候，VCO實際上是由CNO去AD里面相同OU中幫忙創建，因此也需要確保CNO在OU下面具備創建計算機對象的權限，VCO的DNS記錄也會由CNO去幫忙建立，有些時候可能會出現群集資源名稱無法連接，這時候就要看看是不是CNO VCO計算機對象離線了，或者是CNO沒有權限創建DNS記錄或VCO對象。

  CNO或是VCO的DNS記錄 IP地址實際運作時都會被綁定在一個節點上，該節點對于VCO CNO來說就是主節點，例如CNO的主節點可以是節點1，VCO的主節點可以是節點2，當節點1出現故障時候，CNO的IP地址和域名就會故障轉移到節點2進行綁定，如果節點1活了，這時候節點2又掛掉，那么CNO和VCO的IP地址和域名都會轉移至節點1綁定，這里的綁定可以理解為hosting

  說完了CNO和VCO的概念之后，再來談群集組的概念相對就更好理解了一些

  群集組大家可以把它理解為群集最小故障轉移單位，在2003時代，我們創建群集之后就可以直觀的看到群集組的工作狀態，這也就是上面我說2003時代的群集更便于大家理解群集工作狀態，2003時代我們創建好了一個群集后，就會有一個群集組，群集組里面有群集IP地址，群集名稱，群集見證磁盤，這就是群集所需要的最基本最重要的信息，這些東西活著，群集也就可以對外提供服務，這個概念一直延續至今，直至2016，群集創建完成后默認群集背后都會產生一個群集組，也叫做群集核心資源，它可以理解為其它群集角色群集組之父，一切的群集應用都是要因為已經已由群集核心資源組才可以被建立出來，我們打開群集管理控制臺可以看到有個主服務器，核心資源組在那臺機器上，那臺機器就是群集主服務器。

  當我們在群集中添加角色的時候，傳統的群集應用都會讓我們輸入應用名稱，應用IP地址，與可以用的群集磁盤，用于存放群集應用數據，這里的群集應用名稱，應用IP地址，選擇的群集磁盤，就構成了一個群集組

  例如當前我們建立了個傳統的文件服務器角色，要向把它進行計劃內的故障轉移，實質上我們會按照整體的一個群集組來進行遷移，將群集應用IP地址，群集應用DNS名稱從節點1轉移到節點2上面hosting，然后把掛載在節點1上面的共享磁盤，掛載到節點2。

  在傳統群集組中單個群集磁盤通常只能被一個群集應用占用，例如如果文件服務器使用了這塊群集磁盤，那么其他群集應用則不能重復使用這塊磁盤，而且要遷移只能整個群集組一起遷移

  這對于虛擬機來說就很不方便，既然你一個群集應用只能用一個群集磁盤，那在2008時代，群集用虛擬化，如果虛擬機都創建在一個群集組中，虛擬機都在同一塊群集磁盤上，即是說當你要遷移其中一臺虛擬機，只能把上面的其它和你用同一個群集組的虛擬機都一起遷移走，很快微軟發現這種傳統群集組的方式并不太適合虛擬化，于是在2008R2開始，微軟推出了CSV群集文件系統，同時也對群集虛擬機的運作方式做了改變，摒棄傳統群集組的故障轉移做法，針對于群集上面的虛擬機有了新的群集組模型，和傳統的群集組都不一樣，新的虛擬機群集組里面只包含單臺虛擬機的虛擬機配置信息，虛擬機磁盤，虛擬機狀態等單臺虛擬機特定的信息，每次每臺虛擬機的計劃內或計劃外遷移將只涉及到這些信息，再不需要被迫遷移所有虛擬機。

 以上為群集組的簡要介紹，只要大家知道群集組是群集最小的故障轉移單位就可以，當我們計劃內或計劃外遷移一個傳統群集應用的時候，實際上后臺會發生把應用整體群集組一并遷移到其它節點進行hosting，針對于虛擬機2008R2開始我們則可以只遷移單虛擬機相關信息的群集組。

 說完群集組之后，我們來看下群集驗證報告的概念，在2003時代并沒有這種東西，2003只是群集安裝完成后會產生安裝log，在2008時×××始，群集換了新的UI，也推出了群集驗證報告，時至今日，群集驗證報告也是很多微軟支持員工的排錯利器。

 簡單來說，群集驗證報告是什么呢，可以把它理解為一個群集的私人醫生，當我們創建群集的時候，強烈建議運行一次群集驗證報告，它會幫助我們從系統配置，網絡，存儲等多個角度來診斷，當前環境是否適合創建群集，如果創建群集，那些條件是已經滿足的，已經滿足的會顯示一片綠色的對勾，那些條件是沒有遵守微軟最佳實踐，但是不會影響到群集建立的，這類報告會顯示為×××的驚嘆號，那些條件如果不滿足群集的要求，會導致群集創建出現錯誤的，會顯示紅色的叉叉，一定要進行處理才行。

 通常老王建議創建群集的時候群集驗證報告是一定要運行的，然后當針對于群集環境，例如變更了網絡，存儲，新增了節點，都建議運行一下群集驗證報告，確保變更不會為現有群集帶來故障

 需要特別注意的是群集驗證報告中的存儲，在進行群集驗證報告的時候我們可以選擇，要驗證什么，可以是系統配置，網絡，或存儲等，其中當驗證存儲的時候，可能會導致群集磁盤出現暫時的離線，如果上面跑了業務，也許會出現短暫的停機時間，因此當進行群集驗證報告時勾選了存儲一定要謹慎，如果不勾選存儲驗證，則不會導致宕機時間，一起都正常執行著。

 群集驗證報告是群集重要的的私人醫生，它告訴我們那些是正確的，那些是不正確的，那些是可以改進的，當我們因為一個群集的問題給微軟開case，微軟的支持工程師可能首先就會叫你把群集驗證報告導出生成，發給他一份，群集驗證報告本身已經針對很多群集內容進行了驗證，對WSFC感興趣的朋友有時間可以好好看下群集驗證報告。

 接下來也是本文的重中之重，我們要講解WSFC中的仲裁，見證，投票的概念，坦白說，之前剛做微軟的產品的時候老王對于這些概念是一頭霧水的，做可以，但從來搞不清楚真正含義，我相信很多剛踏入微軟世界的朋友可能也會有同樣的問題，接下來老王會試著把這些東西講清楚

 提到見證投票概念之前我們先來看下仲裁，群集到底為什么需要仲裁，仲裁到底起到什么作用，你有沒有去思考過呢，最初老王就是總也搞不清仲裁到底起到一個什么作用，經過一段時間的學習研究，我有了一點自己的體會

  仲裁，在老王看來，是一種群集用于維護群集持續可用的機制，例如，當群集里面宕機了一個節點，仲裁要根據仲裁模型決定宕機了一個節點，是否違背群集仲裁模型的要求，如果群集宕機節點超過了一定數量，違背了仲裁模型的要求，仲裁會認為，群集當前已經無法正常對外提供服務，而將群集關閉

 因此，仲裁的第一個作用，老王認為是在群集節點發生狀態變化下，根據預定的仲裁模型，來決定群集是否可以繼續存活下去

 第二個作用，則是當群集發生分區時，維持保證群集多數節點一方的分區正常運行，舉個例子，例如當前群集在北京廣州兩個站點，北京站點有三臺群集節點，廣州站點有兩臺，當前他們使用的仲裁模型是多數節點，這時，北京廣州直接出現一個網絡故障，北京沒辦法訪問廣州，這時群集仲裁會去判斷，阿，群集一共兩個站點，北京站點還剩下三個節點，它是多數，它可以活下來，這時由北京三個節點重新組成群集，當廣州節點網絡恢復正常，群集將重新形成繼續

 除了維護多數，仲裁還需要解決處理腦裂的問題，例如當前群集在北京廣州兩個站點，北京有兩個節點，廣州也有兩個節點，它們采用了多數節點仲裁模型，這時候如果北京與廣州直接出現網絡故障沒辦法聯系，那么北京的節點和廣州的節點都會試圖去爭取寫入數據到共享磁盤，北京廣州各自都以為自己活著，自己才是主節點，結果就會導致群集數據損壞，群集不正常工作，這種情況在2008R2的時代經常會遇到，可能兩個站點之間節點數一致，忽然忘了不通，或者使用了見證磁盤，但是見證磁盤聯系不上了，就會導致這種腦裂的情況發生

 因此，仲裁的目的，就是要始終確保，群集分區情況下是由多數的節點負責運作，少數節點一方應該關閉，即應該始終確保群集投票數是奇數，因為一旦出現偶數投票，就又會出現腦裂各自為政的情況，怎么確保群集投票數始終是奇數呢，一方面我們可以利用群集現有的技術，一方面是架構設計人員的設計理念要準確，如果是四個節點，那么你就一定要設計成磁盤見證或共享見證，否則腦裂一觸即發。

 那么什么是見證呢，大家可能常常會聽見仲裁盤，見證盤，其實所謂的見證，就是WSFC 2008時代為了幫助我們在偶數節點下避免腦裂而推出的一項技術

  默認情況下，群集內每個節點都會有自己的投票，當節點可以通過網絡狀況檢測，切當前與共享存儲連接正常，系統也正常可用，則該節點的投票有效，假設當前是一個四個節點的群集，如果每個節點都工作正常的話，那么應該是有四個投票，如果是兩個站點，即每個站點兩票，當發生一個網絡分區的時候群集就會出現腦裂，這時如果引入了見證磁盤的話，當出現一個50/50分區時，那一端可以聯系到見證，就可以獲取見證的票數，即見證磁盤也會具備自己分區的投票數，當發生50/50分區時，那一端可以先和見證磁盤建立連接，那一端就會獲勝，繼續運行群集，沒能聯系到見證磁盤的一方則會被關閉。

 磁盤見證和共享文件夾都是同樣的目的，是微軟最初用于解決腦裂問題的方案，雖然可以解決一部分腦裂的問題，但有時還是會存在腦裂的情況，雖說磁盤見證和共享文件夾是做同樣的目的，但是它們有些地方還是不太相同，磁盤見證和共享文件夾都可以處理腦裂的問題，但是一旦出現一個時間分區的時候，磁盤見證就可以很好的處理，而共享文件夾不行，例如，當前節點1 節點2 使用了共享文件夾，當節點1上面添加了DHCP角色，然后節點1宕機，這時只有節點2活著，我們在上面添加了文件服務器角色，然后節點2也宕機，這時我們開啟節點1，會在群集中看到節點1群集無法啟動對外提供服務

 原因是節點1不具備最新的群集數據庫，因為共享文件夾見證中沒有存放群集數據庫，因此群集檢測到節點1沒有最新的群集數據庫，將會阻止該節點的啟動，如果是使用磁盤見證則不會，因為磁盤見證中也存在群集數據庫，群集節點的數據庫也會同步至見證磁盤，如果使用磁盤見證的話，節點1開機會聯系到磁盤見證，與磁盤見證同步最新的群集數據庫，然后上線群集資源，因此，建議如果可以選擇磁盤見證，盡量選擇磁盤見證，磁盤見證是黃金法則！

 到了2012時代，群集做出了重要的更新，推出了動態投票，動態見證的智能化方式，簡單來說，你可以4個節點用磁盤見證了，3個節點也可以用磁盤見證，因為群集會自己動態的為你去調整見證的票數，例如，現在群集是3個節點加見證磁盤，那么會自動去掉見證磁盤的一票，群集現在是3票，如果又新增了一個節點進來，當前四個節點，又會重新加上見證的一票，群集現在是5票，因此在2012時代及之后，WSFC群集是始終建議大家針對群集配置磁盤見證的，不論是奇數或是偶數節點都可以，因為群集會自動幫我們去調整票數，通過動態仲裁可以幾乎幫我們處理百分之80的腦裂場景。

 在一些極端情況下，例如第三個站點的見證磁盤無法聯系，我們也可以通過強制啟動群集，或Lowerquorumprioritynodeid等技術，來在50/50的情況下處理腦裂，利用強制啟動也可以在群集分區少數的一方將群集進行啟動，例如當前5個節點的群集，四個節點都在站點1,1個站點在站點2，站點1全部崩潰，站點2還活著，但由于仲裁算法默認不會讓少的票數一方提供服務，但有時少不少，能提供服務就行，我們也可以通過強制啟動技術將站點2的一個節點強制啟動起來提供服務，因此現在的WSFC已經可以很好的處理腦裂，50/50場景，以及少數節點存活場景。

 以目前中國最多使用的2008R2群集為例，在2008R2中WSFC仲裁模型一共有四種

節點多數：每個群集節點具備自己的投票數，要求多數節點投票，群集才可以正常運行，例如5節點至少要有3個有效票，3節點至少要有2個有效票，低于有效票默認群集不會對外提供服務。

節點和磁盤多數：每個節點具備自己的投票數，見證磁盤也具備一票，當見證磁盤活著的時候，允許群集壞掉節點的半數，例如6節點群集，見證磁盤活著，則可以允許壞掉3個節點，加上見證磁盤的一票，群集依然可以正常活著，當見證磁盤掛掉，則節點必須有多數投票，群集才可以活著，例如，如果見證磁盤掛掉，5個節點的群集，最多只能壞兩臺，要至少保證3個可用票

節點和共享多數：同磁盤多數一致，不通點在于共享見證里面沒有群集數據庫，不會處理時間分區的問題，適用于沒有見證存儲的場景

僅硬盤：在這種仲裁模型下，只有見證磁盤具有一票，所有節點都會試圖去爭取到見證磁盤，當發生分區時能夠和見證磁盤連接的節點即可以存活，例如如果是一個8節點的群集，那怕壞掉7個節點，只剩下一個節點，但是它可以和磁盤聯系，那么群集也可以活下去，群集應用會盡可能的在這臺節點上托管，這時最早2003時代引入的仲裁模型，優點是在磁盤可用的情況下，能夠在群集只有一個節點的情況下存活。缺點是磁盤成為了單一故障點，在2003之后的版本微軟已經不再推薦這種仲裁模型

以上我們介紹了仲裁，見證，投票，仲裁模型，下面我們把這些概念串起來看下是否會更加容易理解

 群集需要仲裁來判定群集是否可以存活，仲裁根據仲裁模型的要求來評測群集內的投票數，當投票數按照仲裁模型設定，達到最少容許存活及以上，則仲裁判定群集可以存活，若超過仲裁模型的最少容許存活，則群集關閉，當出現腦裂分區時，仲裁會去利用見證的投票數，來選擇其中一方分區繼續提供服務，另外一方關閉

 至于仲裁為什么默認會判定票數多的一方可以作為權威方存活，為什么不是選少的一方，老王認為微軟可能是思考，多的一方可以承擔更多的群集應用，隨著技術的不斷更新，仲裁也可以在50/50，或少數節點存活的情況下強制選擇其中一方啟動，另外一方關閉。

 老王又想到一個形象的例子，來闡述仲裁，投票，我們以酒店的例子來說

  誠意酒店要開張，首先得去工商部門注冊，我們要開一個酒店，工商部門說，這里有幾種運作模式，你們選一下吧，最少要有幾個服務員一起干活才能算是合理的酒店，這個就是仲裁模型，比如老王選了我們酒店一共五個服務員，最少也應該提供3個服務員對外服務，工商部門說那好吧，記住哦，你們最少應該有3個服務員的時候才可以以酒店身份正常對外營業。

  辦完工商注冊老王回店里開店，掛牌子，牌子就是群集對外名稱，大家看到你這個名稱，就都進來吃飯了，每個員工上班的時候都會自動打卡報告，我今天是健康的，我可以正常和別人溝通，我可以工作，這個就是投票，這時候服務員小李有病請假了，四個服務員仍然可以干活，然后又有一個服務員小黃要結婚也請假了，還剩下三個服務員，也可以干活，只是每個人干的活比以前多了一點，這時候小紅又請假了，哎呀經理啊，我生病了不能來干活了，這時候只剩下兩個服務員干活，這時候工商局立馬就來了，說你們酒店當初不是說至少三個人提供服務嗎，現在就剩下兩個人了，你們酒店不能開了先關了吧，等人來了再開，這時候酒店雖然關了，但是內部裝修什么的都沒動，不過牌子暫時不能訪問進來吃飯了，但是當服務員又齊了，就又可以恢復對外提供服務了。

  不知道這個例子大家是否可以理解，仲裁就可以理解為你與群集簽訂的一個協議，群集會遵守這個協議來判斷你這個群集是否可以存活

  如果出現腦裂的情況呢，舉個例子，比如誠意酒店在北京和天津都設有分公司，兩個分公司都需要和工商部門報告工作，只有匯報了工作才可以正常對外提供服務，工商部門正常情況下只對應一個分公司，只有當這個分公司出現問題，才是另外分公司和它報告，然后呢，天津酒店有兩個服務員，北京酒店也有兩個服務員，正常情況下每天他們都要電話溝通，今天到底是你匯報還是我匯報。

  這天忽然電話線路出故障了，北京聯系不上天津，天津也聯系不上北京，那怎么辦，但是也得匯報啊，于是兩邊就都以為我應該匯報，我應該提供服務，于是兩邊就都給工商部打電話匯報工作，但是匯報的又都不一致，工商部領導一會聽北京的，一會聽天津的，于是工商部領導也蒙了，你們酒店到底怎么回事今天，能不能干了，一會這樣一會那樣，于是這就是腦裂了

  如果有見證呢，那就是相當于兩家分公司和工商部談好了，領導，我們正常情況下都是通過通電話來確認是誰和您報告工作，一旦電話出現故障，我們就以人為準，您看這個大胖子，他是我們公司的專家，它在哪個分公司，您就聽哪個分公司的就行，工商部領導說好的，然后過兩天電話線路又壞了，但是大胖子在北京，和工商部領導一說，阿，大胖子在你們分公司，你們分公司人多，那就你們先對外提供服務把，天津那邊等他線路修好再說

  如果是強制仲裁呢，那就是說北京分店和天津分店又出現線路故障了，但是北京分店這邊和工商部領導談話了，領導啊，我們這邊今天比較重要，您聽我們的吧，于是工商部領導說，那好吧，既然你們著急今天就聽你們的，然后北京分店和領導匯報完工作，好啦，北京分店現在可以正常提供服務了，但是天津那邊我回頭也要通知它一下呢，告訴他我今天聽了北京的了，明天你們先休息一天。

  到了2012R2之后呢，一旦發生這種強制仲裁，是不用再通知天津，告訴他明天你們先不要開的，等通知，2012R2之后一旦天津檢測到北京這面發生了強制仲裁，天津自動就不會啟動，它會知道北京這面已經存在了強制仲裁操作，我應該遵守它的操作。

  如果是使用Lowerquorumprioritynodeid屬性，或者2016里面的Site preferred屬性呢，就是說，事先工商局那邊已經訂好規則了，當出現北京天津都是兩個人，沒有大胖子的時候，我應該不聽誰的，例如設置了Lowerquorumprioritynodeid是天津的節點，那即是說當出現腦裂情況，直接北京的自動被提升對外提供服務。

  以上為老王對于WSFC的基礎知識簡要介紹，希望看到的朋友都能夠有自己的收獲，理論奠基篇已經結束，下篇老王將使用一套2008R2的環境帶大家實作群集仲裁發生時的真實形態，以及應對的正確方式。