WSFC CLUSDB

   轉眼已是2018年了，真快啊，在這裏老王首先祝福各位博友新的一年身體健康，事業順利，在新的一年裏老王仍然會繼續爲你們分享微軟企業級技術，也歡迎你們與我一同探討，共同窗習，這新年第一篇老王想和你們聊聊WSFC的羣集數據庫，以及和它相關的一些組件

   首先，咱們回憶下以前介紹過的羣集基礎概念，裏面有提到Windows羣集的運做機制，羣集在運做過程當中會產生一個羣集數據庫，存放在各節點註冊表中，若是有磁盤見證也會存放在磁盤見證一份，羣集會把各節點的情況，以及節點承載的羣集角色紛紛記錄在註冊表中，而後在各節點與磁盤見證上覆制，當其中一個節點宕機，羣集協調其它活着的節點檢查自身的羣集數據庫註冊表，查看宕機節點承載的角色，進行failover

   所以你們能夠看出，羣集數據庫儲存了羣集運做過程當中節點狀態，羣集狀態，羣集角色狀態等配置數據，它須要被複制到各個節點，當災難發生時其它節點會參照羣集數據庫進行failover，所以若是重要的羣集，應該針對於羣集節點OS進行備份，系統狀態中會包括羣集數據庫

   羣集數據庫註冊表位置，位於各節點HKEY_LOCAL_MACHINE\Cluster單元下，能夠在裏面看到羣集的配置，各節點的狀態，羣集角色的配置

其中paxos標記爲2008開始WSFC新增的功能，在2008以前，羣集只有「仲裁驅動器」會保存一份羣集數據庫的最新副本，各個節點都須要和仲裁盤進行同步，由仲裁盤複製羣集數據庫到各節點，各節點在關機重啓後也必須鏈接到仲裁盤同步下載羣集數據庫，若是仲裁盤出現故障，則羣集將沒法啓動，所以在2008以前，仲裁磁盤成爲了單一故障點，2008開始，羣集引入了paxos標記的機制，每一個節點自己均可以保存羣集數據庫最新副本，若是某個節點修改羣集數據，則該節點paxos標記增長，隨後各節點感應到有更新的paxos標記，會自動與其同步羣集數據庫內容，當節點宕機恢復後，會對比自身paxos標記與磁盤見證paxos標記，若是若是磁盤見證更新，則與其同步後上線，若是磁盤見證檢測到羣集節點有更新paxos標記的羣集數據庫也會與其同步

默認狀況下節點羣集服務每次啓動都會檢查羣集數據庫註冊表配置單元，確保完整才能夠正常啓動羣集，若是非最新，則需與其餘節點或磁盤見證同步羣集數據庫，若是節點羣集服務未啓動，則不會加載羣集數據庫註冊表配置單元，除了咱們說的每一個節點自己的羣集數據庫註冊表單元，若是節點是見證磁盤所在節點，還會額外加載一個0.Cluster配置單元，非見證磁盤全部者節點，不會加載這個配置單元

在羣集數據庫註冊表中咱們能夠看到關於羣集的配置信息，在遇見一些棘手的問題時咱們也許會須要改動它們，例若有一些資源沒辦法圖形界面或命令行界面刪除，這時候就能夠在註冊表裏面進行刪除處理，可是官方並不建議這樣作，如下爲官方推薦作法：刪除羣集資源的標準操做，建議採用標準作法，輕易不要直接操做註冊表

除了註冊表，咱們在另一個位置也能夠找到關於羣集數據庫的文件，C:\Windows\Cluster目錄中，事實上CLUSDB正是羣集數據庫的實體存在，每次羣集服務啓動時都會將CLUSDB加載到註冊表配置單元，咱們只有從註冊表配置單元才能夠看到羣集數據庫的內容，至於爲何要設計成這樣的架構，老王猜測多是由於儲存爲文件格式更易於各節點間傳輸，或者備份恢復操做。

打開羣集見證磁盤，能夠看到0.Hive的磁盤文件，它將會被加載到見證磁盤所在節點的註冊表配置單元

下面咱們來實際驗證下羣集數據庫的同步，首先，咱們隨便在一個節點上面修改羣集的配置

修改前節點paxos標記

修改後節點paxos標記

其它節點檢測到其它節點有paxos標記更新，與其同步羣集數據庫，同步完成後paxos標記爲最新

0.Cluster 見證磁盤註冊表單元也同步羣集數據庫爲最新，paxos標記更新一致

其它節點查看羣集註冊表，能夠看到同步後最新的羣集數據庫配置

0.Cluster見證磁盤註冊表單元 也能夠看到同步後最新的羣集數據庫配置

查看羣集日誌

此爲後來老王又修改了一次羣集實時遷移網絡後的分析

GUM (Global Update Manager) ，檢測到有節點羣集配置發生變化，有paxos更新，提醒Node2節點與其更新，Node2節點收到請求後與Node1同步最新羣集數據庫

接收到GUM的信號後接下來由Database Manager組件負責數據庫同步，進一步咱們能夠看出，具體同步的是那些註冊表鍵值，因而可知，每次羣集數據庫是增量的，僅同步修改後的內容，同步完成後，確保羣集數據庫已爲最新，更新節點paxos標記

對於羣集數據庫的處理，磁盤見證和文件共享見證，雲見證有所不一樣，如上所述，磁盤見證中也保存着羣集數據庫的副本，使用CLFS組件與DM組件，確保磁盤見證內數據庫文件爲最新，而文件共享和雲見證，則不會在目錄中存放羣集數據庫副本，只是負責存放一個日誌，記錄着羣集當前那個節點擁有最新的paxos標記

以前老王曾經和你們說過一個時間分區場景的問題，節點1，節點2，使用文件共享見證或雲見證，節點1宕機，節點2修改了羣集配置內容，而後節點2宕機，節點1開機上線，會發現沒法聯機，爲何，由於GUM組件會發現當前節點1沒有最新的羣集數據庫，因此會阻止該節點聯機，這時除非強制仲裁才能夠啓動節點1，可是啓動後節點1爲黃金副本，節點2再開機會丟失以前修改過的內容。

若是是見證磁盤則不會，一樣的場景，若是節點2修改內容，節點1不在，那麼修改的內容會被同步至見證磁盤，也就是0.Cluster註冊表單元內容，而後當節點1聯機上線，GUM會檢測對比，告知節點1，你的羣集數據庫當前不是最新的，須要和見證磁盤進行同步，同步前節點不能夠得到成員資格，羣集節點1從見證磁盤同步到最新羣集數據庫後，正常聯機上線

所以，若是羣集會常常修改一些內容，爲了不時間分區的問題，老王一般建議採用見證磁盤

羣集數據庫與其餘羣集組件協同：

GUM：GUM爲羣集全局更新管理器，負責協調羣集各個節點羣集數據庫內容爲最新,GUM工做機制分爲如下幾種

1.全局週期性更新，由羣集自動完成，默認狀況下每隔四小時，告知各節點數據庫管理器複製羣集數據庫內容

2.通知性更新，在如下場景發生：節點聯機，節點脫機，羣集註冊表發生修改變化，一旦檢測到節點有以上變化，則馬上通知各節點DM組件複製最新paxos標記數據庫

3.仲裁更新，特定於磁盤見證仲裁模型，當羣集更改沒法複製到其它節點時，對於羣集修改的配置，會以恢復日誌的方式存儲在見證磁盤，當有節點恢復時，自動從見證磁盤獲取

GUM組件從NT4 Cluster Server開始就內置在羣集組件中，這個組件在2012R2以前一直處於自我運做的狀況，工做方式不能修改，2012R2以後發生了改變，在2012R2以前，GUM的原則是有最新的羣集數據庫更新了，我須要通知到大家全部節點，讓大家都更新到羣集數據庫爲最新，羣集全部節點都須要響應GUM的更改通知，若是有節點未響應，數據庫更改處理將延遲等待，2012R2開始，支持下圖三種模式工做，對於Hyper-V負載默認爲1，可以實現只要大部分主機響應GUM的更改通知，就能夠完成數據庫更改處理，可使用命令修改

（Get-Cluster).DatabaseReadWriteMode = 1

一個潛在的問題，當針對羣集中的節點請求信息時，節點必須與羣集中的大多數節點進行通訊獲得確認，而後才能發送對請求的響應。對於不須要請求，這樣能夠，可是當請求常常被放入羣集時，這會給羣集帶來巨大的通訊負擔，會爲虛擬主機帶來性能影響，因而2016開始微軟改默認值爲0

DM: Database Manager爲數據庫管理器，負責在每一個節點上運行並維護羣集數據庫的本地副本，包括羣集自己，羣集節點成員資格，資源組，資源類型以及特定資源（如磁盤和IP地址）的描述，數據庫管理器使用全局更新管理器將更改複製到其它節點

MM: MemberShip Manager爲節點管理器，負責記錄各節點資格，將節點資格列表在各節點複製，確保全部節點一致，節點管理器會收到各節點心跳檢測的結果，若是檢測到新的成員節點加入，則通知GUM爲其複製羣集數據庫。若是檢測到某個節點不可用，則將該節點從節點可用列表中標記爲不可用，下次GUM複製將不會通知被MM標記爲不可用的節點複製羣集數據庫，須要注意若是節點僅是脫機狀態，並不會從羣集節點可用列表徹底刪除，只是會被標記爲不可用，恢復後，將通知GUM完成羣集數據庫複製，若是將節點逐出羣集，則完全從節點列表刪除。

RHS&RCM: RHS爲羣集資源主機子系統，負責監視各個羣集資源的運做狀態，一旦RHS檢測到羣集資源不可用，則會將結果報告給RCM資源控制管理器，RCM根據資源的故障轉移策略嘗試重啓或故障轉移資源，一旦RCM將資源轉移至其它節點，則觸發節點羣集數據庫變化，更新paxos標記，GUM收到變化後會通知各節點DM複製最新的羣集數據庫