WSFC AD&SMB依賴性討論

   WSFC雖然只是Window Server上面的一個功能，但其實這個產品內部的組件協同性以及和微軟其它解決方案的協同性特別強，對比微軟其它產品，老王認爲WSFC的MSDN blog作得很是好，寫過不少篇關於WSFC內部組件運做機理的博客，主要用心閱讀加以實踐就能很快的掌握，至於和其它產品的協同性，例如WSFC會和AD，SMB協同，以提供羣集基本運做，上層應用又有exchange dag，sql ag基於WSFC實現應用高可用，外層管理又有SCVMM，Honolulu，OMS，SCOM，SCO等管理套件，能夠說WSFC便是數據中心運做的邏輯高可用實現，又是一個應用持續運做避免不了的中轉站

  這篇文章中老王想和你們探討下WSFC基本運做中所依賴的AD與SMB，究竟什麼狀況下會依賴，爲何要依賴它們，若是沒有它們會產生怎樣的效果。

  首先先談AD，沒什麼好說的，相信你們或多或少對微軟AD域都有一些瞭解，也是微軟爲數很少能夠拿出手的產品之一，AD最主要的用途就是集中身份驗證，經過一套身份數據庫，就能夠爲環境裏面的用戶，計算機，應用程序統一提供身份驗證，進一步還能夠針對於工做環境作集中管理，策略分發，資源分發。

  和WSFC最直接相關聯的就是身份驗證了，咱們知道如今WSFC部署能夠分爲正常AD集成， RODC，無CNO，工做組，多域部署，其中無CNO，工做組模式，多域部署模式相似，都是不在羣集中產生計算機對象，這樣致使的效果就是羣集應用不能執行Kerberos身份驗證，只能走NTLM驗證，或單獨的驗證機制，例如SQL SA驗證，這三種部署模式部署出來的羣集所可以支持的應用也受限，例如不支持MSMQ，對於文件服務器羣集不能使用kerberos身份驗證，hyper-v羣集不支持實時遷移

  其根本緣由是由於羣集裏面沒有CNO對象，咱們都知道高可用羣集的一個主要實現是要作到對外就像是一臺計算機同樣，應用不知道我是在和一個羣集交互，只知道我在一個一個計算機交互，而且我應該是能夠一直和它進行交互的，但實際上這個計算機是邏輯構建的，背後會由羣集組件協調不一樣節點提供服務，正常來說這個對外計算機應該要有本身的netbios名稱，dns名稱，計算機對象，纔算一個能夠完整的能夠進行訪問和身份驗證的計算機，若是咱們採用無CNO，工做組模式，多域部署，則這個羣集邏輯計算機對外就只有一個DNS名稱，而不能提供身份驗證服務。

  在一個AD域環境中，當用戶發送登錄域請求時，本地Local Secutity Subsystem首先會向域控申請用戶的session ticket，若是用戶帳戶密碼正確，則頒發，拿到用戶ticket後，LSS還會向域控申請計算機的session ticket，校驗計算機密碼是否正確，若是和AD中符合則頒發session ticket，本地LSS拿到這兩個ticket後，纔會爲此次登錄構建access token令牌，後續用戶纔可使用這個token去執行程序，得知這個過程是很是關鍵的，這樣便是說每次身份驗證登錄都須要和AD拿用戶的ticket和計算機ticket，一旦其中一個失效，則此次驗證失敗，沒法登錄。

 在WSFC環境中這一樣很重要，舉個例子，正常狀況下，若是我配置了一個DTC羣集，外面的程序要想訪問，是能夠直接經過DTC羣集的CNO對外進行身份驗證，這樣作的目的是爲了給用戶提供一個統一邏輯，當後臺一個節點宕機，用戶仍是使用一樣的名稱訪問，只不過是另一個節點提供服務。可是，若是DTC當前所在的節點，計算機對象出現了問題，例如計算機對象被誤刪除了，這時候經過cluster log能夠看到日誌，RHS會按期檢測機器網絡名稱，會一直檢測到這個機器網絡名稱沒法訪問，當前節點沒法與AD聯繫，沒法登錄，這時候，羣集並不會所以發生故障轉移。但用戶程序能夠感知到，這時候訪問到羣集沒法執行身份驗證了，由此看來雖然咱們有了邏輯的CNO，但仍須要關注各節點的AD計算機狀態，所以具體身份驗證仍是會涉及到應用所在節點，這時產生的直接效果就是DTC這個羣集應用沒法執行身份驗證，由於所在節點沒法正常登錄到AD拿到計算機ticket，處理方式就是最終排錯發現問題，先把DTC轉移至其它正常能夠和DC拿到ticket的的節點上，恢復正常身份驗證，而後再從AD恢復被刪除的計算機對象。

節點域計算機對象的正常是否，能夠直接影響到須要身份驗證的羣集應用，所以羣集應用的服務帳戶，計算機對象，CNO對象一樣重要，都是羣集在AD中須要重點關注的內容

除了對於計算機ticket的依賴，WSFC還會依賴AD實現Kerberos驗證，例如SQL羣集，SQL Server使用Windows身份驗證時，SQL Server經過Windows安全支持提供程序接口（SSPI）間接支持Kerberos，默認狀況下SQL 會首先嚐試經過SSPI和AD協商，若是能夠執行Kerberos驗證，則經過Kerberos驗證，若是沒法經過則回退爲NTLM驗證，所以不少SQL管理員不少時候遇到的驗證問題每每都和SPN有關，SQL羣集配置的時候會寫入服務帳戶特有的SPN值，若是寫入失敗，或後期被誤刪除，沒法校驗SPN，則Kerberos驗證將失敗，所以對於使用Kerberos驗證的程序，也須要關注其服務帳戶以及CNO VCO對象的SPN值，能夠在健康的時候進行記錄下來，以便往後恢復時增補

CNO VCO會寫入AD計算機的三個屬性：

DnsHostName ：FQDN值

ServicePrincipalName：SPN值

HOST / 虛擬服務器的NetBIOS名稱
HOST / FQDN的虛擬服務器
MSClusterVirtualServer / 虛擬服務器的NetBIOS名稱
MSClusterVirtualServer / FQDN的虛擬服務器
MSServerCluster / 虛擬服務器的NetBIOS名稱（此SPN僅爲默認羣集名稱建立）
MSServerCluster / FQDN（此SPN僅爲默認羣集名稱建立）

DisplayName ：網絡名稱資源的NetBIOS名稱

上述SPN值爲羣集安裝後默認註冊的SPN，若是基於羣集上層跑了一些應用，應用若是須要進行kerberos驗證，也會註冊SPN到CNO或VCO，之前曾經有一些第三方軟件會在註冊的時候僅針對單節點註冊SPN，致使故障轉移後用戶還須要訪問新的名稱進行驗證，後來開始大部分應用都會直接註冊羣集CNO名稱，當一個節點宕機，自動切換至另一個節點驗證

以上是老王認爲WSFC對於AD主要的兩點依賴，若是你的程序訪問帳戶密碼正確，但就是沒法正常驗證羣集應用，能夠進一步查看是否因爲應用所在節點計算機對象不正常，或未按照預期的kerberos驗證，請查看服務帳戶和VCO對象的SPN值是否正確，若是使用沒有VCO則檢查CNO，這裏須要注意的是，羣集並不會由於你的節點計算機對象丟失或SPN值丟失而進行故障轉移，因此若是基於羣集的應用驗證出現問題還須要去檢查程序和AD，羣集只是能作到提供一個統一的對外名稱，一個節點宕機，你能夠繼續經過這個統一對外名稱來完成驗證。

另外還有一點，AD組策略的計算機密碼重置期限有時會影響到計算機對象或CNO對象沒法正常聯機，所以建議把羣集計算機對象和節點對象統一放置到單獨OU，針對此OU單獨設置一個計算機嗎重置期限，能夠長一些，在羣集OU對象或CNO對象上面配置防刪。

上述簡單爲你們介紹了下老王一時想起的WSFC對於AD的依賴，CNO，VCO，登錄憑證驗證，計算機密碼重置策略，Kerberos驗證，SPN，若有不全之處歡迎你們補充

對於SMB，相信你們都有所瞭解，它是一個網絡文件共享協議，容許應用程序和終端用戶從遠端的文件服務器訪問文件資源，區別於FTP，SMB是能夠直接互相傳輸，而不須要有上傳下載的過程

在以前的版本2003 2000 2008中，你們對於SMB的理解大概就是一個共享傳輸協議，我兩個機器之間作共享互相拷貝文件走的是SMB協議，主要用做客戶端互傳，文件服務器共享，DFS等等，可是到了2012開始，SMB協議變的愈來愈重要，例如引入了SMB多通道，SMB Direct(RDMA)，SOFS模型，性能開始有了很大提高，更多的加入到企業級場景中，2012R2開始，官方正式宣佈，羣集內部CSV元數據傳輸與CSV重定向流量由走SMB協議，2016宣佈存儲複製各節點走SMB協議。

咱們首先來關注CSV部分對於SMB的依賴，2012R2開始，CSV使用SMB做爲各節點間元數據交互與重定向IO的流量，這裏簡單和你們介紹介紹下CSV，以2012R2架構爲例，CSV給管理員的感受好像是它被掛載在全部節點，全部節點均可以訪問CSV卷，但事實上，真正CSV同一時刻只實際被掛載到一個節點，這個節點稱爲協調者節點，只有協調節點得能夠直接和下層的NTFS文件系統交互，其它節點若是但願執行文件操做，建立文件，關閉文件，重命名文件，更改文件屬性，刪除文件，更改文件大小，任何文件系統控制等，都須要把要執行的操做，以及目標文件，這些元數據信息反饋給協調者節點，最終由協調者節點完成真正的對文件系統操做，CSV並非一個文件系統，它只是一個編排層，編排各節點按照順序讀取寫入NTFS或REFS文件系統，還有一種流量則是重定向流量，這種流量是比較可怕的，當該節點失去到物理磁盤的資格，全部寫入讀取操做，都將被轉發到協調者節點執行，這會給協調者節點帶來巨大流量，同時失去資格的節點上面應用也將低效運做，這種重定向流量也會使用SMB協議傳輸。

針對於元數據交互和重定向IO，2012開始SMB引入多通道機制，羣集會挑選網絡度量值最低的做爲CSV流量，兩個相近度量值得網絡會經過SMB多通道執行，默認狀況下僅羣集通訊網絡度量值最低，度量值得數字評定2012開始也和網卡是否支持RDMA,RSS有關，管理員也能夠手動指定網絡度量值，CSV流量能夠利用SMB多通道和SMB RDMA等技術。

以上爲官方的說法，那麼若是羣集沒有CSV，沒有使用文件共享見證，也不提供文件共享服務，是否就能夠關閉SMB端口了呢，由於去年病毒鬧得好多公司安所有門提出關閉445端口的需求，那麼羣集這邊是否能夠支持，老王作了個嘗試，當前羣集無CSV，沒有使用文件共享見證，也不提供文件共享服務，老王直接禁用掉SMB服務

關閉方法

一、運行regedit打開註冊表

二、依次依次點擊註冊表選項」HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\NetBT\Parameters

三、在右邊空白處右擊新建「QWORD（64位）值」，而後重命名爲「SMBDeviceEnabled」，再把這個子鍵的值改成0

四、禁用系統Server服務

五、重啓電腦 SMB 445端口再也不偵聽

配置完成後雖然羣集能夠正常啓動，但能夠看到工做已經很不正常，例如DTC應用沒法聯機，查看日誌提示DCOM沒法鏈接到DTC VCO對象

事實上老王已經猜到可能會是這樣的結果，由於SMB協議運做多年，依賴它的服務衆多，例如此外CIFS，SMB，RPC，DFS，Netlogon等等，這種完全關掉的方式還須要中止Server服務，不少依賴該服務的功能都將中止運做

另外官網沒說的還有兩點，其一，客戶端登錄到域的過程會從netlogon獲取開機登錄啓動腳本，若是由組策略下發，用戶也會從SYSVOL目錄去獲取組策略GPT，而這兩個目錄都是在域控上面的共享目錄，用戶勢必要經過SMB協議去訪問，若是禁止SMB，則新的組策略下發將不正常

其二，老王發現過一個有意思的事情，羣集節點net share除了能夠看到默認C盤會共享外，若是自身有見證磁盤，也會把見證磁盤進行共享，羣集不會平白無故設計成這樣，雖然咱們關閉SMB以後，羣集能夠正常啓動，但見證磁盤再也不共享，老王猜測仍是會對羣集產生一些影響。

總結來看若是要關閉SMB端口，首先確保羣集沒有應用CSV，其二可能承擔沒法應用組策略風險，其三上層應用可能會不正常工做，具體還要根據不一樣的羣集應用進行測試，只有確保確定不依賴於SMB，Server服務的應用才能夠正常工做

還有一種途徑即更改羣集的SMB端口，網上有已經寫好的修改SMB端口教程，可是按照網上的方式修改後，全部要和羣集節點通訊的設備必須也將SMB端口改成和羣集端口一致，我舉個例子，例如SQL羣集把SMB端口改成555，那麼須要和AD下載組策略把，可是DC默認是445端口，因此也須要把DC的SMB端口修改成555，連SQL的應用也要修改SMB端口爲555，若是是後端SOFS羣集改SMB端口，則前端HV也要修改，如此一來未免過於麻煩，若是在沒有域的單機環境下，修改SMB端口以維持SMB協議也許可行，可是在域環境下涉及到牽一髮動全身的問題。

所以在老王看來，WSFC，AD，SMB這三個組件相結合的很是緊密，關閉端口或者修改SMB端口目前看來都不是最佳的方案，仍是要從物理架構和安全策略調整，例如爲核心數據庫應用構建在DMZ區域，與其餘服務器經過防火牆嚴格控制通訊，更新病毒補丁等層面進行處理。