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复制最新的群集数据库