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