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，那对于很多企业来说可能就面临一些问题
我企业里面只有几个SQL DBA，我们需要SQL群集，但是又不懂AD，部署群集需要AD，AD出现问题，SQL DBA没办法解决AD层面的问题
带来额外的管理成本
一旦AD域服务器进行维护，群集将无法启动
上面我们说到群集会在AD中创建CNO，VCO计算机对象，它们和其它计算机对象也是一样的，也需要进行密码同步，启动时也需要联系到AD进行验证，在2012之前，假设这时AD服务器正在维护重启，这时候如果群集正在进行故障转移，手动切换，或冷启动，群集需要联机上线时，你会发现群集网络名称资源时没办法连接的，因为联系不到AD，CNO和VCO无法进行验证，因此群集会关闭，只有等AD重新启动时，群集才能启动，这样就导致了额外的停机时间
其关键还是群集与AD太过于紧密了，每次联机都需要和AD进行验证，而且Kerbros验证也需要经过AD
所以有的企业如果没有AD域环境的需求，可能就在想能不能不用AD域，或者减轻群集对于AD域的依赖
微软在WSFC 2012时代更新了这方面的技术，主要有两个
无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
工作组模式群集先决条件
所有节点操作系统必须为Windows Server 2016
所有节点必须使用已经认证的标识硬件
所有节点必须安装故障转移群集功能
工作组模式群集需在各节点使用相同密码相同用户，该用户需要是本地管理组成员，如果是非administrator用户还需额外修改注册表键值
对于工作组模式群集，要求每个节点需要有主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 )
