今天老王来和大家聊聊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 )
转载于:https://blog.51cto.com/wzde2012/1968946