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 )