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，那對于很多企業來說可能就面臨一些問題

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依賴環境的支持情況

除上述資源外：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的最小磁盤作為見證，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 )