今天老王來和大家聊聊WSFC 2016里面的工作組部署模型，正如老王剛開始在WSFC 2016系列開篇所講，對于WSFC 2016 我們會從維護管理，排錯優(yōu)化，部署遷移幾個點分別講起，基本上我們對于WSFC 2016維護管理的新功能已經(jīng)講的差不多，優(yōu)化和部署還有幾篇未完
在講到工作組部署模型之前呢，我們首先來看看歷史問題，為什么要有工作組部署模型
早起在2003時代，如果我們要建立一個群集，每個群集都需要使用一個CSA(Cluster Service Account)，即一個域賬號，用于支持群集服務(wù)啟動和群集資源的運行
這樣的模型運行了一段時間后，有的管理員開始抱怨，一旦不小心修改了這個賬號的密碼，或者應(yīng)用上了一些賬號管理策略，群集無法啟動了，等等。
于是在2008時×××始，微軟改變了這種群集賬戶模型，引入了CNO和VCO模型
CNO Cluster Name Object
1.作為群集訪問標(biāo)識的一部分，管理員或應(yīng)用可以連接到CNO訪問群集
2.負(fù)責(zé)管理VCO 虛擬機計算機對象的創(chuàng)建，密碼同步，VCO DNS記錄創(chuàng)建維護。
3.CNO會被寫入特定的SPN，應(yīng)用程序會通過CNO來和群集完成Kerberos驗證
4.CNO會被創(chuàng)建和VCO之間的關(guān)聯(lián)關(guān)系，在群集節(jié)點注冊表中可以得到查看
基本上當(dāng)我們創(chuàng)建群集的時候，輸入的群集名稱，群集就會拿著使用我們當(dāng)前創(chuàng)建群集的賬戶，聯(lián)系到AD，在指定OU下生成CNO計算機對象，因此我們創(chuàng)建群集的賬戶需要可以在OU上面創(chuàng)建計算機對象的權(quán)限，創(chuàng)建完成CNO后，還會拿著我們的賬號去DNS里面創(chuàng)建CNO的DNS記錄。計算機對象和DNS記錄合起來算作一個CAP，管理或應(yīng)用都依賴于這個CAP去訪問群集。
創(chuàng)建完成CNO之后，所謂VCO 虛擬計算機對象，即是指，我們在群集上面跑的群集應(yīng)用，通常情況下大部分群集應(yīng)用都會要單獨的訪問名稱和IP，向?qū)瓿珊?，群集就會拿著我們輸入的訪問名稱，去AD里面創(chuàng)建VCO，以及VCO的 DNS記錄，這里VCO的計算機對象和DNS記錄，就是由CNO負(fù)責(zé)維護的了，CNO創(chuàng)建完成VCO后會在VCO ACL里面寫入CNO的權(quán)限。
基本上大家可以看到，在2008時代之后，群集和AD域的關(guān)系變的越來越緊密，如果你要部署Windows Cluster，那么就一定要有一個AD，那對于很多企業(yè)來說可能就面臨一些問題
我企業(yè)里面只有幾個SQL DBA，我們需要SQL群集，但是又不懂AD，部署群集需要AD，AD出現(xiàn)問題，SQL DBA沒辦法解決AD層面的問題
帶來額外的管理成本
一旦AD域服務(wù)器進行維護，群集將無法啟動
上面我們說到群集會在AD中創(chuàng)建CNO，VCO計算機對象，它們和其它計算機對象也是一樣的，也需要進行密碼同步，啟動時也需要聯(lián)系到AD進行驗證，在2012之前，假設(shè)這時AD服務(wù)器正在維護重啟，這時候如果群集正在進行故障轉(zhuǎn)移，手動切換，或冷啟動，群集需要聯(lián)機上線時，你會發(fā)現(xiàn)群集網(wǎng)絡(luò)名稱資源時沒辦法連接的，因為聯(lián)系不到AD，CNO和VCO無法進行驗證，因此群集會關(guān)閉，只有等AD重新啟動時，群集才能啟動，這樣就導(dǎo)致了額外的停機時間
其關(guān)鍵還是群集與AD太過于緊密了，每次聯(lián)機都需要和AD進行驗證，而且Kerbros驗證也需要經(jīng)過AD
所以有的企業(yè)如果沒有AD域環(huán)境的需求，可能就在想能不能不用AD域，或者減輕群集對于AD域的依賴
微軟在WSFC 2012時代更新了這方面的技術(shù)，主要有兩個
無Active Directory集群啟動
在一些虛擬化場景下，可能域控制器也進行了虛擬化，就在群集中，那么就很可能會陷入一個循環(huán)問題，群集啟動，但是虛擬機在群集里面，而域控虛擬機沒啟動群集又始終啟不來，WSFC 2012微軟在虛擬化域控制器的場景下，可以支持域控制器沒啟動下，先讓群集節(jié)點啟動。
Tip:雖然微軟宣稱有了這項技術(shù)，但還是建議大家額外部署一臺域控在群集外，或始終保留一臺物理機域控
2.無Active Directory依賴群集
2012開始支持無AD依賴群集，即不需要創(chuàng)建CNO與VCO對象的群集，群集管理員不再需要過多關(guān)心AD，也不需要擔(dān)心CNO VCO對象被刪除，導(dǎo)致群集無法使用的情況，在2012時代，此技術(shù)仍需要群集節(jié)點加入到域，但創(chuàng)建群集的時候不需要聯(lián)系A(chǔ)D管理員分配AD寫入權(quán)限，群集管理員完全就可以自行創(chuàng)建群集
這種所謂的無AD依賴群集，看起來很好，結(jié)合無AD群集啟動技術(shù)，可以把對于AD的依賴降到最低，但是隨之也有它的弊端，No Computer Object No Kerberos，您不能對無AD依賴群集進行Kerberos的驗證，雖然在群集內(nèi)通信可以使用Kerberos，但是從外面訪問群集名稱要做驗證，只有通過NTLM
以下為群集負(fù)載對于無AD依賴環(huán)境的支持情況
集群工作負(fù)載支持/不支持更多信息
SQL Server支持我們建議您使用SQL Server身份驗證進行Active Directory獨立的群集部署。
File server支持，但不推薦Kerberos身份驗證是服務(wù)器消息塊（SMB）流量的首選身份驗證協(xié)議。
Hyper-V支持，但不推薦支持快速遷移，不支持實時遷移，因為它具有對Kerberos身份驗證的依賴。
Message Queuing (also known as MSMQ)不支持消息隊列存儲屬性在AD DS
除上述資源外：Bitlocker群集磁盤加密，自動更新的CAU也不被支持
基本上最適合的負(fù)載就是SQL Server了，SQL DBA現(xiàn)在可以部署一個SQL群集或SQL Always on，然后使用SQL身份驗證，AD服務(wù)器重啟維護短時間也不會影響到SQL群集的正常運行。
2012時代創(chuàng)建一個無AD依賴群集步驟如下
#創(chuàng)建無AD依賴群集
New-Cluster SQLCluster -Node sql01,sql02 -StaticAddress 10.0.0.80 -NoStorage -AdministrativeAccessPoint Dns
#查看群集管理點模式
(Get-Cluster).AdministrativeAccessPoint
命令中的AdministrativeAccessPoint即群集的管理點模式，默認(rèn)情況下是由CNO計算機對象+DNS記錄共同構(gòu)成，如果您不需要群集依賴于AD，不需要CNO，那么您單獨指定僅DNS作為管理點即可
需要注意，WSFC 2012創(chuàng)建無AD依賴群集，沒有GUI的方式，只有通過Powershell操作
一旦創(chuàng)建完成后群集部署架構(gòu)已定，無法更改，除非摧毀重建群集
創(chuàng)建完成無AD依賴群集后，您需要為群集配置共享存儲，見證模型，在工作組群集或多域群集中，群集見證僅支持多數(shù)節(jié)點，磁盤見證，云見證
這是2012時代的模型，好像國內(nèi)對于這項功能關(guān)注的朋友并不多，事實上老王覺得一些SQL DBA倒是應(yīng)該了解下，至少可以減少你SQL群集對于AD域的一部分依賴
也maybe是無AD依賴環(huán)境還是存在一些問題，例如仍然還是需要AD，而AD又通常和DNS在一臺，如果這臺服務(wù)器維護，一段時間過后群集也可能出現(xiàn)問題。
到了WSFC 2016時代，微軟徹底如大家所愿，現(xiàn)在可以在一個完全工作組的環(huán)境下部署WSFC群集，連域成員身份也不需要了，徹底擺脫AD，直接使用工作組就可以部署群集，這對于企業(yè)沒有AD域環(huán)境，又想要部署群集，或者想要部署群集但是又不一點也想管理AD域的管理員來說就太方便了
但是和2012時代無AD依賴一樣，No Computer Object No Kerberos，支持的負(fù)載依然一樣，最適合的負(fù)載還是SQL 群集&AG 使用SQL身份驗證
實驗驗證WSFC 2016工作組模式群集
環(huán)境介紹
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
工作組模式群集先決條件
所有節(jié)點操作系統(tǒng)必須為Windows Server 2016
所有節(jié)點必須使用已經(jīng)認(rèn)證的標(biāo)識硬件
所有節(jié)點必須安裝故障轉(zhuǎn)移群集功能
工作組模式群集需在各節(jié)點使用相同密碼相同用戶，該用戶需要是本地管理組成員，如果是非administrator用戶還需額外修改注冊表鍵值
對于工作組模式群集，要求每個節(jié)點需要有主DNS后綴
操作流程
在各節(jié)點創(chuàng)建相同密碼本地用戶
添加用戶進入各節(jié)點本地管理員組
設(shè)置用戶密碼，并勾選密碼永不過期
修改注冊表鍵值
由于我們沒有使用默認(rèn)的administrator用戶，所以我們需要修改各節(jié)點注冊表鍵值
進入注冊表如下位置HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
新增DWORD鍵值LocalAccountTokenFilterPolicy，設(shè)定值為1
為各節(jié)點新增DNS主后綴，修改完成后需重啟
先決條件都準(zhǔn)備完成后，我們可以通過GUI或Powershell創(chuàng)建工作組群集，Powershell命令和2012無AD依賴群集相同
這里我們選擇通過GUI界面進行創(chuàng)建，打開故障轉(zhuǎn)移管理器，創(chuàng)建群集，添加節(jié)點名稱，正常情況下輸入后應(yīng)該可以看到帶DNS后綴的節(jié)點
群集驗證，這里我們暫時選擇否
輸入群集名稱，這里如果我們部署的是傳統(tǒng)的AD域模型，會拿著我們這個名稱去創(chuàng)建CNO和DNS管理點，但是這里由于我們是工作組模型，因此只會創(chuàng)建DNS管理點
點擊下一步確認(rèn)，可以看到，群集創(chuàng)建向?qū)ёR別出我們當(dāng)前是工作組群集，自動幫我們確認(rèn)為僅DNS注冊
創(chuàng)建完成后可以看到，群集當(dāng)前正常工作，且自動幫我們選擇大于512MB的最小磁盤作為見證，WSFC 2016 不論是工作組群集或是多域群集，都不支持文件共享見證。
這時如果執(zhí)行群集驗證向?qū)?，可以看到關(guān)于AD配置的警告，警告指出我們當(dāng)前是工作組模式部署，需要為所有節(jié)點更新相同的補丁，確保DNS名稱被復(fù)制到群集節(jié)點的權(quán)威DNS服務(wù)器
Tip:別忘記，生產(chǎn)環(huán)境下執(zhí)行群集驗證，如果勾選存儲驗證，會導(dǎo)致應(yīng)用脫機聯(lián)機
工作組群集創(chuàng)建完成后，下面我們可以開始做基于群集的應(yīng)用部署，按照微軟的建議，依然是使用SQL身份驗證的SQL群集&AG為最佳場景，但老王認(rèn)為不需要Kerberos驗證，又不需要寫入AD域?qū)ο蟮膽?yīng)用，也嘗試工作組部署模型。
WSFC 2016新功能大部分也都可以用于工作組模式群集 ，例如
故障域站點感知
站點運行狀況檢測
Cloud Winess
Cluster Log 優(yōu)化
簡單的SMB多通道
群集VM負(fù)載均衡 ( No LiveMigration Only QuickMigration )
VM彈性與存儲容錯 ( No LiveMigration Only QuickMigration )
