WSFC2012 为何网络名称联机失败

各位朋友可能在WSFC2012上面安装群集角色时常常会遇见网络名称联机失败的问题，致使群集应用没有配置成功，最终应用不会正常对外提供服务，例如SQL Server，DTC，一些时候即使是重装也不能解决，那么到底为何会产生这个问题，今天咱们就来从头分析

The cluster resource ‘SQL Server’ could not be brought online due to an error bringing the dependency resource ‘SQL Network Name ’ online.

提到这个典型错误，若是想完全理解，就不得不从CNO，VCO讲起，本文老王将把这些概念再串起来说一次，力图让管理员可以完全理解

高可用群集的一个最关键特色，就是要持续对外提供服务，所以须要实现一个逻辑对外名称，背后由群集逻辑进行协调，若是当前正在对外提供服务的某节点宕机，自动将用户对逻辑对外名称的访问请求转移至其它活着的节点上提供，让用户始终觉得群集应用是活着的

这个逻辑对外名称在微软WSFC体系中实现为客户端访问点，客户端访问点，一般有DNS，CNO，VCO三部分，DNS记录用于客户端访问解析群集及群集应用，CNO用于支持群集链接，群集Kerberos验证，VCO用于帮助特定群集应用实现节点导向

对于一个群集来讲，完整的客户端访问点包括群集DNS记录+群集CNO名称，若是仅使用DNS记录，例如工做组群集，多域群集，将不支持Kerberos验证。

对于一个群集应用来讲，完整的群集应用访问点，包括应用DNS记录+应用VCO名称，具体采用什么级别的应用访问点，视应用状况而定，例若有的群集应用能够共用群集DNS+群集CNO，则不须要再建立应用访问点，或者仅须要DNS记录，或者建立完整应用访问点，若是群集应用是完整的应用访问点，那么应该是群集应用在身份验证，或者故障转移导向上面有所要求，须要使用单独的计算机对象实现。

  CNO   Cluster Name Object于WSFC 2008被引入

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

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

  3.CNO建立完成VCO后会在VCO ACL里面写入CNO的权限

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

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

  6.误删CNO或VCO对象会致使群集没法正常联机，应用没法和群集进行Kerberos验证

简单看了下概念以后下面咱们经过实际案例进一步理解，为何网络名称没法联机在WSFC 2008时代不多见，而在WSFC 2012常常看到

最关键的答案是CNO对象建立位置原则

在WSFC 2008时代，不论咱们的群集节点计算机对象，在那个OU下面，群集CNO对象和VCO对象，都只会被建立在默认Computer容器下，除非咱们提早在其它OU下面预置了CNO，VCO对象

如图所示，我已经按照规划把群集计算机节点放置在单独OU下

可是当安装群集的时候，WSFC 2008依然会把CNO VCO放置在默认Computers容器

又由于默认计算机容器每一个对象都有权建立计算机对象，所以只要建立群集的帐户具有Computers的建立计算机对象 及 读取全部属性权限 ，CNO对象和VCO对象就能够被正常建立出来，即便CNO已移到不一样的OU，VCO仍是会在默认计算机容器建立

所以，WSFC 2008时代基本上不会遇见网络名称没法联机的问题，网络名称没法联机，该问题一般就是指CNO或VCO对象，没法在AD中被正常建立，权限不足

为何 WSFC 2012以后常常碰见这个错误，答案就是CNO对象建立位置原则发生了改变

最关键的两点

1. WSFC 2012开始CNO对象将跟随群集计算机对象在同一个OU下建立

2. CNO将跟随VCO对象在同一个OU下建立

规则改变后带来什么影响，好的一面是能够帮助AD计算机对象规范化，很差的一面就是带来了额外的权限授予工做

设想一下，WSFC 2012中，若是咱们将群集节点计算机对象移到一个新OU下，那么群集CNO也将在该OU建立

建立CNO的工做由群集安装帐户完成，所以须要确保群集安装帐户对节点所在OU具有建立计算机对象 及 读取全部属性权限  或直接加入domain admins组

CNO建立完成后，紧接着咱们须要在上面跑群集应用，建立VCO，而VCO是由CNO负责建立维护，可是因为不是默认计算机OU，因此CNO对于节点所在OU并无权限，所以建立VCO过程会失败，进而群集显示网络名称没法联机。

错误呈现以下

解决办法，针对单独规划的群集OU，添加CNO计算机权限 建立计算机对象 及 读取全部属性权限 ，不管是规划好的全新安装，或是先安装好了群集，而后CNO对象和群集计算机对象移到了其它OU，都在当前CNO对象所在OU执行此操做。

权限授予完成后，再次启动群集角色，问题可解，群集应用正常联机

要规避此问题，解决办法有二

1. 不作规划，群集节点计算机就在默认计算机OU下，这样CNO和VCO就能够正常联机，也无需添加CNO权限

2. 一般状况下企业里面计算机对象不少，都放在默认计算机OU下面也很差看，不便于管理，所以老王建议为群集节点建立单独OU是应该的，CNO，VCO对象会被建立在关联的节点OU中也很好，惟独就是安装群集角色时须要单独授予CNO对象对于OU的权限，若是该OU下面会有不少个群集的话，老王建议您能够建立一个CNO计算机对象组，将全部刚安装好的群集CNO对象都自动加入到组里面，而后针对于OU授予CNO组的权限，这样每当建立应用的时候权限都是准备无缺的

还有一个问题，群集名称资源在DNS中注册失败，出于如下缘由，群集网络名称资源'SQL Network Name（VirutalClusterName）'注册一个或多个关联的DNS名称失败

出现这个问题，是由于CNO对象对于DNS服务器没有权限而致使，由于CNO对象负责维护VCO计算机对象和DNS记录，所以VCO的DNS记录也将由CNO对象去DNS中注册建立，出现这个错误，就是CNO对象对于DNS区域没有权限

手动为CNO添加对DNS区域的 修改权限 建立权限便可，添加完成后，再次脱机联机群集角色，问题可解

小技巧，在WSFC中，若是咱们删除群集角色，则该VCO对象会变成禁用，销毁群集，CNO对象会变成禁用，若是咱们规划好群集OU，看见禁用的CNO和VCO对象，就能够知道，它们是已经被删除的群集角色或群集，能够直接删除，默认状况下GUI界面销毁群集CNO对象为禁用，若是使用命令Remove-Cluster -CleanupAD销毁，则能够销毁过程直接删除CNO