如下圖所示為clussvc主服務包括的組件，可以看到幾乎所有的群集組件都寄生於clussvc下面，因此clussvc的服務啟停至關重要，一旦clussvc服務停止，則該節點將無法使用群集功能，如果群集所有節點clussvc服務關閉，則群集將停止對外服務。

下圖為Clussvc在群集架構中扮演的位置，可以看到，clussvc負責接收API傳來的操作，再將用戶的請求傳給其它群集組件進行工作，同時也負責群集內部組件的協同通信，RHS和CPrepSrv的檢測也將反饋給Clussvc

由於clussvc作為群集的托管主服務，因此它比較特殊，不同的場景會需要不同的啟動開關，啟動命令如下 net start clussvc /啟動參數

從2000到2003時代，clussvc群集服務的啟動參數如下

Fixquorum：適用於2000與2003時代，該開關主要適用於處理，因為仲裁設備而導致群集服務無法啟動的場景，例如被掛載的群集見證磁盤不穩定，經常出現脫機情況，使用fixquorum參數啟動後可以讓群集服務啟動，但是不聯機群集仲裁設備，僅聯機群集IP和群集名稱，同時關閉日誌記錄存儲到仲裁設備功能，通過該模式啟動後，群集應用資源和仲裁資源將被脫機，管理員可以手動聯機仲裁資源以觀察日誌進行診斷

該啟動參數最好用於群集只剩下一個節點的場景，通過該參數啟動後，將在該節點掛載群集數據庫，群集IP，群集名稱，便於排錯，如果群集其它節點正在運行，建議排除仲裁設備問題前，為其它節點停止群集服務，以防止搶奪群集IP，群集名稱。

排除問題後重新以正常開關net start clussvc啟動節點

NoQuorumLogging ：透過該參數啟動後群集將關閉日誌記錄存儲到仲裁設備功能，用於診斷仲裁設備中的仲裁日誌和檢查點問題，通常情況下，該開關僅在一個節點上使用，主要用於2003時代當仲裁設備日誌文件或檢查點文件損壞，並且您想手動將這些文件替換為備份副本時使用。

需要註意，通過該參數啟動群集有可能引發時間分區問題，通過NoQuorumlogging啟動的節點最好不要修改群集信息

在2008之前，群集只有“仲裁設備”會保存一份群集數據庫的最新副本，各個節點都需要和仲裁盤進行同步，由仲裁盤復制群集數據庫到各節點，各節點在關機重啟後也必須連接到仲裁盤同步下載群集數據庫，如果仲裁盤出現故障，則群集將無法啟動，因此在2008之前，仲裁磁盤成為了單一故障點，2008開始，群集引入了paxos標記的機制，每個節點本身都可以保存群集數據庫最新副本，如果仲裁設備出現問題，最快的解決辦法，新加入一個仲裁磁盤，把舊的替換掉，仲裁磁盤檢測到群集節點的數據庫paxos標記比較新，會自動同步新的群集數據庫過來。

Debug：在2003時代群集日誌僅包含群集服務啟動後的群集日誌，而不包含群集服務啟動過程的日誌，因此，如果要排除群集服務啟動過程的故障，需要使用debug開關執行操作，切換到C:\System32\Cluster 目錄下，使用命令提示符執行clussvc /debug > c:\clusdebug.txt，則可以將群集服務以debug的用途啟動，並將捕捉整個啟動過程信息至日誌，主要用於2003時代，因為群集啟動賬號或系統配置而導致群集服務無法啟動問題，2008之後群集服務啟動日誌可在clusterlog看到

Debug參數也支持設置啟動診斷日誌級別，方法如下：clussvc / debug loglevel = 3> c:\debug.log

level 0 不記錄

level 1 只記錄錯誤

level 2 記錄錯誤和警告

level3 記錄所有事件，包括未寫入事件日誌的事件

DebugResMon : 用於調試資源監視器進程，並因此調試由資源監視器加載的資源動態鏈接庫（DLL）,開發人員可以使用此開關來調試資源監視器進程及其自定義資源DLL,在資源監視器進程啟動之前，群集服務進程等待，並等待消息“等待調試器連接到resmon進程X”，其中X是資源監視器進程的進程ID（PID）.群集服務會執行此操作，以等待由其創建的所有資源監視器進程。在用戶將調試器附加到資源監視器進程並且資源監視器進程啟動後，群集服務將繼續其初始化。

用法：Clussvc /debug /debugresmon

ResetQuorumLog : 用於2000及2003時代，如果仲裁日誌和檢查點文件未找到或已損壞，則可用於根據本地節點的％SystemRoot％\ Cluster \ CLUSDB註冊表配置單元中的信息來創建文件，適用於仲裁磁盤仲裁日誌，出現損壞的場景，即使用各節點本地文件註冊表創建仲裁日誌和檢查點文件，而後使用fixquorum方式啟動群集，替換仲裁磁盤。

用法：net start clussvc / resetquorumlog，執行該命令後，MSCS會自動檢測仲裁日誌損壞，自動使用節點本地註冊表配置單元重新生成仲裁日誌

ResetQuorumLog 與 NoQuorumLogging 不同適用場景

NoQuorumLogging：有仲裁設備備份，暫時停掉寫入，然後把已備份的恢復覆蓋

ResetQuorumLog： 沒有仲裁設備備份，利用各節點本地註冊表重建仲裁日誌

兩種參數啟動群集服務後，都需使用net start clussvc再正常啟動一次。

NoRepEvtLogging ：適用於2000與2003 ，在2000和2003時代cluster log是群集服務實時產生的，此參數可以防止事件日誌的復制，如果有大量事件日誌條目，則群集服務將復制這些條目，並將它們記錄到cluster.log。這可能會導致cluster.log快速換行。通過該參數可以阻止節點的cluster log被復制到其它節點，減少網絡通信帶寬，並且可以把該節點未刷新到cluster log 的日誌轉移至本地log中

net start clussvc /norepevtlogging 阻止該節點的事件日誌復制到其它節點，但可以正常接收其它節點的信息

clussvc /debug /norepevtlogging > c:\debugnorep.log 將該節點群集服務還未刷新至cluster log的日誌轉移至本地log

ForceQuorum：最廣為大家熟悉的群集啟動參數，在2003時代引入，2003時代該參數縮寫為FO,FQ是fixquorum，2003時代的forcequorum，主要起到讓少數分區提供服務的作用，和2008時代的forcequorum有一些區別，例如2003時代北京站點4節點，上海站點3節點，兩站點間發生分區，但是北京已知無法對外提供服務，因此需強制啟動上海站點，但起點過程需指定上海站點節點名稱，如net start clussvc / forcequorum / forcequorum node5，node6，node7，使用該命令起點後，上海站點將重新啟動一個群集，這個群集的可用所有者列表只有 5 6 7 節點。啟動上海站點後應手動停止北京各節點群集服務，防止搶奪資源，當分區恢復時重新正常啟動群集服務

在2008時代WSFC引入了幾個新的參數， PreventQuorum，IgnorePersistentState，以及發生變化的ForceQuorum

正如老王在前面文章可以大家提到過的，ForceQuorum在2008時代發生了變化，引入了paxos標記機制，和之前的作用一樣，幫助群集節點在少數節點的情況下也能強制啟動提供服務，但是卻比之前版本方便了許多，在2008中，我們只需要在少數節點其中一個節點執行net start clussvc /FQ 即可，2008開始FQ縮寫開始指forcequorum，被執行FQ的節點自身的群集數據庫會被提升為黃金副本，之後其它所有節點如果希望參與群集，都必須和FQ節點同步群集數據庫後，才可以正常參與進群集，在2008時代，如果少數方執行FQ強制仲裁後，需要到多數方執行PQ，阻止多數方形成群集，日後分區解除，多數方將自動與FQ方同步最新群集數據庫

IPS參數於2008R2引入，ForceQuorum為2008起發生改變，PQ為2008R2引入，2008可通過hotfix獲得

IPS開關是一個有意思的參數，類似於2000時代的Fixquorum，不同的是fixquorum僅聯機群集IP和群集名稱，其它資源一律不聯機，而IgnorePersistentState參數可以幫助我們聯機群集IP，群集名稱，仲裁磁盤，這些所有核心組組件，而不聯機任何基於群集的應用，可以幫助管理員先恢復群集正常服務，再排查基於群集的應用問題

在正常情況下，群集服務啟動時，默認行為是將所有資源聯機。IPS開關所做的是忽略當前的資源PersistentState值，並將所有內容保持為離線狀態

使用該參數後群集整體處於聯機狀態，可以對外提供服務，此開關只會影響群集中的服務和應用程序組

該參數要求群集符合法定人數要求下才可以使用

適用場景

1.群集各節點資源負載飽滿，導致啟動時群集節點崩潰，可以使用/IPS模式啟動群集，先聯機一部分群集應用，進行排錯，排錯完成後，再聯機其它群集應用。

2.基於群集的第三方應用導致群集偽掛起，使用IPS參數啟動群集後正常啟動群集，檢查應用問題，修復後再聯機應用。

用法：net start clussvc /ips 或 net start clussvc /ips /fq ，如果在不符合法定仲裁人數運作需添加fq參數

2012開始，阻止仲裁技術發生了改變，多數節點一方檢測到少數節點一方存在強制仲裁會自動執行阻止仲裁操作，即確保承認強制仲裁一方為群集，與其群集數據庫同步至最新後，才會啟動自身群集服務，在之前2008時代，如果遇到強制仲裁的場景下，大多數時間都需要手動去執行阻止仲裁，否則會出現群集數據庫覆蓋等情況，到了2012則會自動幫助我們做這件事。

2016 WSFC開始向最新的技術看齊整合了，存儲副本，超融合技術，可以和Azure相配合，實現WSFC on Azure，Azure witness，除了這些還改變了群集默認的檢測機制，新導入了瞬斷機制，防止由於瞬時中斷而導致群集應用故障轉移，可以設定在指定時間內群集的故障不需要執行故障轉移，如果某時間內發生了某次數的瞬時中斷，則判定節點為檢疫隔離狀態，節點處在檢疫狀態下的時間，默認為7200秒，在這段時間，節點將不承載應用，所有虛擬機被實時遷移走，其它群集資源被移動走，如果節點提前恢復可使用 net start clussvc /CQ 或 Start-ClusterNode -CQ ，執行ClearQuarantine操作，把節點手動恢復正常。

總結到最新2016還剩下的clussvc啟動參數：FQ，PQ，IPS，CQ

WSFC 服務啟動開關詳解