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復制最新的群集數據庫