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的環境帶你們實做羣集仲裁發生時的真實形態，以及應對的正確方式。