WSFC2016 工作组部署模型

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了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来和群集完成Kerbros验证

  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的最小磁盘作为见证

技术分享

这时如果执行群集验证向导,可以看到关于AD配置的警告,警告指出我们当前是工作组模式部署,需要为所有节点更新相同的补丁,确保DNS名称被复制到群集节点的权威DNS服务器

Tip:别忘记,生产环境下执行群集验证,如果勾选存储验证,会导致应用脱机联机

技术分享

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


WSFC 2016新功能大部分也都可以用于工作组模式群集 ,例如


故障域站点感知

站点运行状况检测

Cluster Log 优化

简单的SMB多通道

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

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




本文出自 “老王的微软技术研究乐园” 博客,请务必保留此出处http://wzde2012.blog.51cto.com/6474289/1968946

以上是关于WSFC2016 工作组部署模型的主要内容,如果未能解决你的问题,请参考以下文章

WSFC2016 故障域站点感知

WSFC仲裁模型优化方案选型

SQL Server 2016 + AlwaysOn 无域集群

WSFC2016 VM顺序组与管理组

WSFC2016 跨站点运行状况检测

WSFC 仲裁模型选择