WSFC CLUSDB

   轉(zhuǎn)眼已經(jīng)是2018年了，真快啊，在這里老王首先祝福各位博友新的一年身體健康，事業(yè)順利，在新的一年里老王仍然會繼續(xù)為大家分享微軟企業(yè)級技術(shù)，也歡迎大家與我一同探討，共同學(xué)習(xí)，這新年第一篇老王想和大家聊聊WSFC的群集數(shù)據(jù)庫，以及和它相關(guān)的一些組件

   首先，我們回憶下之前介紹過的群集基礎(chǔ)概念，里面有提到Windows群集的運作機制，群集在運作過程中會產(chǎn)生一個群集數(shù)據(jù)庫，存放在各節(jié)點注冊表中，如果有磁盤見證也會存放在磁盤見證一份，群集會把各節(jié)點的狀況，以及節(jié)點承載的群集角色紛紛記錄在注冊表中，然后在各節(jié)點與磁盤見證上復(fù)制，當(dāng)其中一個節(jié)點宕機，群集協(xié)調(diào)其它活著的節(jié)點檢查自身的群集數(shù)據(jù)庫注冊表，查看宕機節(jié)點承載的角色，進行failover

   因此大家可以看出，群集數(shù)據(jù)庫儲存了群集運作過程中節(jié)點狀態(tài)，群集狀態(tài)，群集角色狀態(tài)等配置數(shù)據(jù)，它需要被復(fù)制到各個節(jié)點，當(dāng)災(zāi)難發(fā)生時其它節(jié)點會參照群集數(shù)據(jù)庫進行failover，因此如果重要的群集，應(yīng)該針對于群集節(jié)點OS進行備份，系統(tǒng)狀態(tài)中會包括群集數(shù)據(jù)庫

   群集數(shù)據(jù)庫注冊表位置，位于各節(jié)點HKEY_LOCAL_MACHINE\Cluster單元下，可以在里面看到群集的配置，各節(jié)點的狀態(tài)，群集角色的配置

其中paxos標(biāo)記為2008開始WSFC新增的功能，在2008之前，群集只有“仲裁驅(qū)動器”會保存一份群集數(shù)據(jù)庫的最新副本，各個節(jié)點都需要和仲裁盤進行同步，由仲裁盤復(fù)制群集數(shù)據(jù)庫到各節(jié)點，各節(jié)點在關(guān)機重啟后也必須連接到仲裁盤同步下載群集數(shù)據(jù)庫，如果仲裁盤出現(xiàn)故障，則群集將無法啟動，因此在2008之前，仲裁磁盤成為了單一故障點，2008開始，群集引入了paxos標(biāo)記的機制，每個節(jié)點本身都可以保存群集數(shù)據(jù)庫最新副本，如果某個節(jié)點修改群集數(shù)據(jù)，則該節(jié)點paxos標(biāo)記增加，隨后各節(jié)點感應(yīng)到有更新的paxos標(biāo)記，會自動與其同步群集數(shù)據(jù)庫內(nèi)容，當(dāng)節(jié)點宕機恢復(fù)后，會對比自身paxos標(biāo)記與磁盤見證paxos標(biāo)記，如果如果磁盤見證更新，則與其同步后上線，如果磁盤見證檢測到群集節(jié)點有更新paxos標(biāo)記的群集數(shù)據(jù)庫也會與其同步

默認(rèn)情況下節(jié)點群集服務(wù)每次啟動都會檢查群集數(shù)據(jù)庫注冊表配置單元，確保完整才可以正常啟動群集，如果非最新，則需與其他節(jié)點或磁盤見證同步群集數(shù)據(jù)庫，如果節(jié)點群集服務(wù)未啟動，則不會加載群集數(shù)據(jù)庫注冊表配置單元，除了我們說的每個節(jié)點本身的群集數(shù)據(jù)庫注冊表單元，如果節(jié)點是見證磁盤所在節(jié)點，還會額外加載一個0.Cluster配置單元，非見證磁盤所有者節(jié)點，不會加載這個配置單元

在群集數(shù)據(jù)庫注冊表中我們可以看到關(guān)于群集的配置信息，在碰見一些棘手的問題時我們也許會需要改動它們，例如有一些資源沒辦法圖形界面或命令行界面刪除，這時候就可以在注冊表里面進行刪除處理，但是官方并不建議這樣做，以下為官方推薦做法：刪除群集資源的標(biāo)準(zhǔn)操作，建議采用標(biāo)準(zhǔn)做法，輕易不要直接操作注冊表

除了注冊表，我們在另外一個位置也可以找到關(guān)于群集數(shù)據(jù)庫的文件，C:\Windows\Cluster目錄中，事實上CLUSDB正是群集數(shù)據(jù)庫的實體存在，每次群集服務(wù)啟動時都會將CLUSDB加載到注冊表配置單元，我們只有從注冊表配置單元才可以看到群集數(shù)據(jù)庫的內(nèi)容，至于為什么要設(shè)計成這樣的架構(gòu)，老王猜想可能是因為儲存為文件格式更易于各節(jié)點間傳輸，或者備份恢復(fù)操作。

打開群集見證磁盤，可以看到0.Hive的磁盤文件，它將會被加載到見證磁盤所在節(jié)點的注冊表配置單元

下面我們來實際驗證下群集數(shù)據(jù)庫的同步，首先，我們隨便在一個節(jié)點上面修改群集的配置

修改前節(jié)點paxos標(biāo)記

修改后節(jié)點paxos標(biāo)記

其它節(jié)點檢測到其它節(jié)點有paxos標(biāo)記更新，與其同步群集數(shù)據(jù)庫，同步完成后paxos標(biāo)記為最新

0.Cluster 見證磁盤注冊表單元也同步群集數(shù)據(jù)庫為最新，paxos標(biāo)記更新一致

其它節(jié)點查看群集注冊表，可以看到同步后最新的群集數(shù)據(jù)庫配置

0.Cluster見證磁盤注冊表單元 也可以看到同步后最新的群集數(shù)據(jù)庫配置

查看群集日志

此為后來老王又修改了一次群集實時遷移網(wǎng)絡(luò)后的分析

GUM (Global Update Manager) ，檢測到有節(jié)點群集配置發(fā)生變化，有paxos更新，提醒Node2節(jié)點與其更新，Node2節(jié)點收到請求后與Node1同步最新群集數(shù)據(jù)庫

接收到GUM的信號后接下來由Database Manager組件負(fù)責(zé)數(shù)據(jù)庫同步，進一步我們可以看出，具體同步的是那些注冊表鍵值，由此可見，每次群集數(shù)據(jù)庫是增量的，僅同步修改后的內(nèi)容，同步完成后，確保群集數(shù)據(jù)庫已為最新，更新節(jié)點paxos標(biāo)記

對于群集數(shù)據(jù)庫的處理，磁盤見證和文件共享見證，云見證有所不同，如上所述，磁盤見證中也保存著群集數(shù)據(jù)庫的副本，使用CLFS組件與DM組件，確保磁盤見證內(nèi)數(shù)據(jù)庫文件為最新，而文件共享和云見證，則不會在目錄中存放群集數(shù)據(jù)庫副本，只是負(fù)責(zé)存放一個日志，記錄著群集當(dāng)前那個節(jié)點擁有最新的paxos標(biāo)記

之前老王曾經(jīng)和大家說過一個時間分區(qū)場景的問題，節(jié)點1，節(jié)點2，使用文件共享見證或云見證，節(jié)點1宕機，節(jié)點2修改了群集配置內(nèi)容，然后節(jié)點2宕機，節(jié)點1開機上線，會發(fā)現(xiàn)無法聯(lián)機，為什么，因為GUM組件會發(fā)現(xiàn)當(dāng)前節(jié)點1沒有最新的群集數(shù)據(jù)庫，所以會阻止該節(jié)點聯(lián)機，這時除非強制仲裁才可以啟動節(jié)點1，但是啟動后節(jié)點1為黃金副本，節(jié)點2再開機會丟失之前修改過的內(nèi)容。

如果是見證磁盤則不會，同樣的場景，如果節(jié)點2修改內(nèi)容，節(jié)點1不在，那么修改的內(nèi)容會被同步至見證磁盤，也就是0.Cluster注冊表單元內(nèi)容，然后當(dāng)節(jié)點1聯(lián)機上線，GUM會檢測對比，告知節(jié)點1，你的群集數(shù)據(jù)庫當(dāng)前不是最新的，需要和見證磁盤進行同步，同步前節(jié)點不可以獲得成員資格，群集節(jié)點1從見證磁盤同步到最新群集數(shù)據(jù)庫后，正常聯(lián)機上線

因此，如果群集會經(jīng)常修改一些內(nèi)容，為了避免時間分區(qū)的問題，老王通常建議采用見證磁盤

群集數(shù)據(jù)庫與其他群集組件協(xié)同：

GUM：GUM為群集全局更新管理器，負(fù)責(zé)協(xié)調(diào)群集各個節(jié)點群集數(shù)據(jù)庫內(nèi)容為最新,GUM工作機制分為以下幾種

1.全局周期性更新，由群集自動完成，默認(rèn)情況下每隔四小時，告知各節(jié)點數(shù)據(jù)庫管理器復(fù)制群集數(shù)據(jù)庫內(nèi)容

2.通知性更新，在以下場景發(fā)生：節(jié)點聯(lián)機，節(jié)點脫機，群集注冊表發(fā)生修改變化，一旦檢測到節(jié)點有以上變化，則立刻通知各節(jié)點DM組件復(fù)制最新paxos標(biāo)記數(shù)據(jù)庫

3.仲裁更新，特定于磁盤見證仲裁模型，當(dāng)群集更改無法復(fù)制到其它節(jié)點時，對于群集修改的配置，會以恢復(fù)日志的方式存儲在見證磁盤，當(dāng)有節(jié)點恢復(fù)時，自動從見證磁盤獲取

GUM組件從NT4 Cluster Server開始就內(nèi)置在群集組件中，這個組件在2012R2之前一直處于自我運作的情況，工作方式不能修改，2012R2之后發(fā)生了改變，在2012R2之前，GUM的原則是有最新的群集數(shù)據(jù)庫更新了，我需要通知到你們所有節(jié)點，讓你們都更新到群集數(shù)據(jù)庫為最新，群集所有節(jié)點都需要響應(yīng)GUM的更改通知，如果有節(jié)點未響應(yīng)，數(shù)據(jù)庫更改處理將延遲等待，2012R2開始，支持下圖三種模式工作，對于Hyper-V負(fù)載默認(rèn)為1，能夠?qū)崿F(xiàn)只要大部分主機響應(yīng)GUM的更改通知，就可以完成數(shù)據(jù)庫更改處理，可以使用命令修改

（Get-Cluster).DatabaseReadWriteMode = 1

一個潛在的問題，當(dāng)針對群集中的節(jié)點請求信息時，節(jié)點必須與群集中的大多數(shù)節(jié)點進行通信得到確認(rèn)，然后才能發(fā)送對請求的響應(yīng)。對于不需要請求，這樣可以，但是當(dāng)請求經(jīng)常被放入群集時，這會給群集帶來巨大的通信負(fù)擔(dān)，會為虛擬主機帶來性能影響，于是2016開始微軟改默認(rèn)值為0

DM: Database Manager為數(shù)據(jù)庫管理器，負(fù)責(zé)在每個節(jié)點上運行并維護群集數(shù)據(jù)庫的本地副本，包括群集本身，群集節(jié)點成員資格，資源組，資源類型以及特定資源（如磁盤和IP地址）的描述，數(shù)據(jù)庫管理器使用全局更新管理器將更改復(fù)制到其它節(jié)點

MM: MemberShip Manager為節(jié)點管理器，負(fù)責(zé)記錄各節(jié)點資格，將節(jié)點資格列表在各節(jié)點復(fù)制，確保所有節(jié)點一致，節(jié)點管理器會收到各節(jié)點心跳檢測的結(jié)果，如果檢測到新的成員節(jié)點加入，則通知GUM為其復(fù)制群集數(shù)據(jù)庫。如果檢測到某個節(jié)點不可用，則將該節(jié)點從節(jié)點可用列表中標(biāo)記為不可用，下次GUM復(fù)制將不會通知被MM標(biāo)記為不可用的節(jié)點復(fù)制群集數(shù)據(jù)庫，需要注意如果節(jié)點僅是脫機狀態(tài)，并不會從群集節(jié)點可用列表完全刪除，只是會被標(biāo)記為不可用，恢復(fù)后，將通知GUM完成群集數(shù)據(jù)庫復(fù)制，如果將節(jié)點逐出群集，則徹底從節(jié)點列表刪除。

RHS&RCM: RHS為群集資源主機子系統(tǒng)，負(fù)責(zé)監(jiān)視各個群集資源的運作狀態(tài)，一旦RHS檢測到群集資源不可用，則會將結(jié)果報告給RCM資源控制管理器，RCM根據(jù)資源的故障轉(zhuǎn)移策略嘗試重啟或故障轉(zhuǎn)移資源，一旦RCM將資源轉(zhuǎn)移至其它節(jié)點，則觸發(fā)節(jié)點群集數(shù)據(jù)庫變化，更新paxos標(biāo)記，GUM收到變化后會通知各節(jié)點DM復(fù)制最新的群集數(shù)據(jù)庫