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