WSFC CLUSDB

转眼已经是2018年了，真快啊，在这里老王首先祝福各位博友新的一年身体健康，事业顺利，在新的一年里老王仍然会继续为大家分享微软企业级技术，也欢迎大家与我一同探讨，共同学习，这新年第一篇老王想和大家聊聊WSFC的群集数据库，以及和它相关的一些组件
首先，我们回忆下之前介绍过的群集基础概念，里面有提到Windows群集的运作机制，群集在运作过程中会产生一个群集数据库，存放在各节点注册表中，如果有磁盘见证也会存放在磁盘见证一份，群集会把各节点的状况，以及节点承载的群集角色纷纷记录在注册表中，然后在各节点与磁盘见证上复制，当其中一个节点宕机，群集协调其它活着的节点检查自身的群集数据库注册表，查看宕机节点承载的角色，进行failover
因此大家可以看出，群集数据库储存了群集运作过程中节点状态，群集状态，群集角色状态等配置数据，它需要被复制到各个节点，当灾难发生时其它节点会参照群集数据库进行failover，因此如果重要的群集，应该针对于群集节点OS进行备份，系统状态中会包括群集数据库
群集数据库注册表位置，位于各节点HKEY_LOCAL_MACHINECluster单元下，可以在里面看到群集的配置，各节点的状态，群集角色的配置
其中paxos标记为2008开始WSFC新增的功能，在2008之前，群集只有“仲裁驱动器”会保存一份群集数据库的最新副本，各个节点都需要和仲裁盘进行同步，由仲裁盘复制群集数据库到各节点，各节点在关机重启后也必须连接到仲裁盘同步下载群集数据库，如果仲裁盘出现故障，则群集将无法启动，因此在2008之前，仲裁磁盘成为了单一故障点，2008开始，群集引入了paxos标记的机制，每个节点本身都可以保存群集数据库最新副本，如果某个节点修改群集数据，则该节点paxos标记增加，随后各节点感应到有更新的paxos标记，会自动与其同步群集数据库内容，当节点宕机恢复后，会对比自身paxos标记与磁盘见证paxos标记，如果如果磁盘见证更新，则与其同步后上线，如果磁盘见证检测到群集节点有更新paxos标记的群集数据库也会与其同步
默认情况下节点群集服务每次启动都会检查群集数据库注册表配置单元，确保完整才可以正常启动群集，如果非最新，则需与其他节点或磁盘见证同步群集数据库，如果节点群集服务未启动，则不会加载群集数据库注册表配置单元，除了我们说的每个节点本身的群集数据库注册表单元，如果节点是见证磁盘所在节点，还会额外加载一个0.Cluster配置单元，非见证磁盘所有者节点，不会加载这个配置单元
在群集数据库注册表中我们可以看到关于群集的配置信息，在碰见一些棘手的问题时我们也许会需要改动它们，例如有一些资源没办法图形界面或命令行界面删除，这时候就可以在注册表里面进行删除处理，但是官方并不建议这样做，以下为官方推荐做法：删除群集资源的标准操作，建议采用标准做法，轻易不要直接操作注册表除了注册表，我们在另外一个位置也可以找到关于群集数据库的文件，C:WindowsCluster目录中，事实上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复制最新的群集数据库

相关推荐: Nginx常用配置详解（一）——主配置块篇

本文依照nginx官方站点文档介绍常用的nginx各种常用配置，未经过校对，如有错误还望海涵。Nginx最基本的配置语法Nginx配置分为各个配置块。主配置块负责全局配置，各个子块都会继承全局配置。各个子块也各有不同的配置项。主配置按功能分为四类：正常运行必备…