WSFC2016 工做组部署模型

 今天老王来和你们聊聊WSFC 2016里面的工做组部署模型，正如老王刚开始在WSFC 2016系列开篇所讲，对于WSFC 2016 咱们会从维护管理，排错优化，部署迁移几个点分别讲起，基本上咱们对于WSFC 2016维护管理的新功能已经讲的差很少，优化和部署还有几篇未完

 在讲到工做组部署模型以前呢，咱们首先来看看历史问题，为何要有工做组部署模型

 早起在2003时代，若是咱们要创建一个群集，每一个群集都须要使用一个CSA(Cluster Service Account)，即一个域帐号，用于支持群集服务启动和群集资源的运行

这样的模型运行了一段时间后，有的管理员开始抱怨，一旦不当心修改了这个帐号的密码，或者应用上了一些帐号管理策略，群集没法启动了，等等。

 因而在2008时×××始，微软改变了这种群集帐户模型，引入了CNO和VCO模型

  CNO   Cluster Name Object

  1.做为群集访问标识的一部分，管理员或应用能够链接到CNO访问群集

  2.负责管理VCO 虚拟机计算机对象的建立，密码同步，VCO DNS记录建立维护。

  3.CNO会被写入特定的SPN，应用程序会经过CNO来和群集完成Kerberos验证

  4.CNO会被建立和VCO之间的关联关系，在群集节点注册表中能够获得查看

基本上当咱们建立群集的时候，输入的群集名称，群集就会拿着使用咱们当前建立群集的帐户，联系到AD，在指定OU下生成CNO计算机对象，所以咱们建立群集的帐户须要能够在OU上面建立计算机对象的权限，建立完成CNO后，还会拿着咱们的帐号去DNS里面建立CNO的DNS记录。计算机对象和DNS记录合起来算做一个CAP，管理或应用都依赖于这个CAP去访问群集。

建立完成CNO以后，所谓VCO 虚拟计算机对象，便是指，咱们在群集上面跑的群集应用，一般状况下大部分群集应用都会要单独的访问名称和IP，向导完成后，群集就会拿着咱们输入的访问名称，去AD里面建立VCO，以及VCO的 DNS记录，这里VCO的计算机对象和DNS记录，就是由CNO负责维护的了，CNO建立完成VCO后会在VCO ACL里面写入CNO的权限。

基本上你们能够看到，在2008时代以后，群集和AD域的关系变的愈来愈紧密，若是你要部署Windows Cluster，那么就必定要有一个AD，那对于不少企业来讲可能就面临一些问题

1. 我企业里面只有几个SQL DBA，咱们须要SQL群集，可是又不懂AD，部署群集须要AD，AD出现问题，SQL DBA没办法解决AD层面的问题

2. 带来额外的管理成本

3. 一旦AD域服务器进行维护，群集将没法启动

上面咱们说到群集会在AD中建立CNO，VCO计算机对象，它们和其它计算机对象也是同样的，也须要进行密码同步，启动时也须要联系到AD进行验证，在2012以前，假设这时AD服务器正在维护重启，这时候若是群集正在进行故障转移，手动切换，或冷启动，群集须要联机上线时，你会发现群集网络名称资源时没办法链接的，由于联系不到AD，CNO和VCO没法进行验证，所以群集会关闭，只有等AD从新启动时，群集才能启动，这样就致使了额外的停机时间

其关键仍是群集与AD太过于紧密了，每次联机都须要和AD进行验证，并且Kerbros验证也须要通过AD

因此有的企业若是没有AD域环境的需求，可能就在想能不能不用AD域，或者减轻群集对于AD域的依赖

微软在WSFC 2012时代更新了这方面的技术，主要有两个

1. 无Active Directory集群启动

在一些虚拟化场景下，可能域控制器也进行了虚拟化，就在群集中，那么就极可能会陷入一个循环问题，群集启动，可是虚拟机在群集里面，而域控虚拟机没启动群集又始终启不来，WSFC 2012微软在虚拟化域控制器的场景下，能够支持域控制器没启动下，先让群集节点启动。

Tip:虽然微软宣称有了这项技术，但仍是建议你们额外部署一台域控在群集外，或始终保留一台物理机域控

  2.无Active Directory依赖群集

2012开始支持无AD依赖群集，即不须要建立CNO与VCO对象的群集，群集管理员再也不须要过多关心AD，也不须要担忧CNO VCO对象被删除，致使群集没法使用的状况，在2012时代，此技术仍须要群集节点加入到域，但建立群集的时候不须要联系AD管理员分配AD写入权限，群集管理员彻底就能够自行建立群集

这种所谓的无AD依赖群集，看起来很好，结合无AD群集启动技术，能够把对于AD的依赖降到最低，可是随之也有它的弊端，No Computer Object No Kerberos，您不能对无AD依赖群集进行Kerberos的验证，虽然在群集内通讯可使用Kerberos，可是从外面访问群集名称要作验证，只有经过NTLM

如下为群集负载对于无AD依赖环境的支持状况

集群工做负载	支持/不支持	更多信息
SQL Server	支持	咱们建议您使用SQL Server身份验证进行Active  Directory独立的群集部署。
File server	支持，但不推荐	Kerberos身份验证是服务器消息块（SMB）流量的首选身份验证协议。
Hyper-V	支持，但不推荐	支持快速迁移，不支持实时迁移，由于它具备对Kerberos身份验证的依赖。
Message Queuing (also known as MSMQ)	不支持	消息队列存储属性在AD DS

除上述资源外：Bitlocker群集磁盘加密，自动更新的CAU也不被支持

基本上最适合的负载就是SQL Server了，SQL DBA如今能够部署一个SQL群集或SQL Always on，而后使用SQL身份验证，AD服务器重启维护短期也不会影响到SQL群集的正常运行。

2012时代建立一个无AD依赖群集步骤以下

#建立无AD依赖群集 

New-Cluster SQLCluster -Node sql01,sql02 -StaticAddress 10.0.0.80 -NoStorage -AdministrativeAccessPoint Dns

#查看群集管理点模式

(Get-Cluster).AdministrativeAccessPoint

命令中的AdministrativeAccessPoint即群集的管理点模式，默认状况下是由CNO计算机对象+DNS记录共同构成，若是您不须要群集依赖于AD，不须要CNO，那么您单独指定仅DNS做为管理点便可

须要注意，WSFC 2012建立无AD依赖群集，没有GUI的方式，只有经过Powershell操做

一旦建立完成后群集部署架构已定，没法更改，除非摧毁重建群集

建立完成无AD依赖群集后，您须要为群集配置共享存储，见证模型，在工做组群集或多域群集中，群集见证仅支持多数节点，磁盘见证，云见证

这是2012时代的模型，好像国内对于这项功能关注的朋友并很少，事实上老王以为一些SQL DBA却是应该了解下，至少能够减小你SQL群集对于AD域的一部分依赖

也maybe是无AD依赖环境仍是存在一些问题，例如仍然仍是须要AD，而AD又一般和DNS在一台，若是这台服务器维护，一段时间事后群集也可能出现问题。

到了WSFC 2016时代，微软完全如你们所愿，如今能够在一个彻底工做组的环境下部署WSFC群集，连域成员身份也不须要了，完全摆脱AD，直接使用工做组就能够部署群集，这对于企业没有AD域环境，又想要部署群集，或者想要部署群集可是又不一点也想管理AD域的管理员来讲就太方便了

可是和2012时代无AD依赖同样，No Computer Object No Kerberos，支持的负载依然同样，最适合的负载仍是SQL 群集&AG 使用SQL身份验证

实验验证WSFC 2016工做组模式群集

环境介绍

DNS&iscsi

lan：10.0.0.2 255.0.0.0

iscsi：30.0.0.2 255.0.0.0

HV01

MGMET:10.0.0.9 255.0.0.0 DNS 10.0.0.2

ISCSI：30.0.0.9 255.0.0.0

CLUS：18.0.0.9 255.0.0.0

HV02

MGMET:10.0.0.10 255.0.0.0 DNS 10.0.0.2

ISCSI：30.0.0.10 255.0.0.0

CLUS：18.0.0.10 255.0.0.0

工做组模式群集先决条件

1. 全部节点操做系统必须为Windows Server 2016

2. 全部节点必须使用已经认证的标识硬件

3. 全部节点必须安装故障转移群集功能

4. 工做组模式群集需在各节点使用相同密码相同用户，该用户须要是本地管理组成员，若是是非administrator用户还需额外修改注册表键值
   

5. 对于工做组模式群集，要求每一个节点须要有主DNS后缀

操做流程

• 在各节点建立相同密码本地用户

• 添加用户进入各节点本地管理员组

• 设置用户密码，并勾选密码永不过时

• 修改注册表键值

因为咱们没有使用默认的administrator用户，因此咱们须要修改各节点注册表键值

进入注册表以下位置HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System

新增DWORD键值LocalAccountTokenFilterPolicy，设定值为1

• 为各节点新增DNS主后缀，修改完成后需重启

• 先决条件都准备完成后，咱们能够经过GUI或Powershell建立工做组群集，Powershell命令和2012无AD依赖群集相同

这里咱们选择经过GUI界面进行建立，打开故障转移管理器，建立群集，添加节点名称，正常状况下输入后应该能够看到带DNS后缀的节点

群集验证，这里咱们暂时选择否

输入群集名称，这里若是咱们部署的是传统的AD域模型，会拿着咱们这个名称去建立CNO和DNS管理点，可是这里因为咱们是工做组模型，所以只会建立DNS管理点

点击下一步确认，能够看到，群集建立向导识别出咱们当前是工做组群集，自动帮咱们确认为仅DNS注册

建立完成后能够看到，群集当前正常工做，且自动帮咱们选择大于512MB的最小磁盘做为见证，WSFC 2016 不管是工做组群集或是多域群集，都不支持文件共享见证。

这时若是执行群集验证向导，能够看到关于AD配置的警告，警告指出咱们当前是工做组模式部署，须要为全部节点更新相同的补丁，确保DNS名称被复制到群集节点的权威DNS服务器

Tip:别忘记，生产环境下执行群集验证，若是勾选存储验证，会致使应用脱机联机

工做组群集建立完成后，下面咱们能够开始作基于群集的应用部署，按照微软的建议，依然是使用SQL身份验证的SQL群集&AG为最佳场景，但老王认为不须要Kerberos验证，又不须要写入AD域对象的应用，也尝试工做组部署模型。

WSFC 2016新功能大部分也均可以用于工做组模式群集 ，例如

故障域站点感知

站点运行情况检测

Cloud Winess

Cluster Log 优化

简单的SMB多通道

群集VM负载均衡 ( No LiveMigration  Only QuickMigration )

VM弹性与存储容错 ( No LiveMigration  Only QuickMigration )