VNX：升級支援 SMB2 安全通道通訊的程式碼後DOMAIN_CONTROLLER_NOT_FOUND

程式碼已升級至上述其中一個版本。

升級到下列其中一個代碼後，記錄中開始出現錯誤訊息，指出網域控制站已關閉：
VNX2：
8.1.9.211
VNX1：
7.1.82.0

訊息看起來如下：

2017-06-20 20:51:27: SMB: 3:[NASSERVER1] OpenAndBind[LSA] DC=DC01 failed: Bind_OpenXFailed DOMAIN_CONTROLLER_NOT_FOUND

上述代碼全部新增至新功能中，可讓 NAS 伺服器或資料移動者與 SMB2 中的網域控制站進行通訊。在此代碼之前，域控制器通信都在SMB1中處理（儘管用戶端仍然可以在SMB2/SMB3中與我們通信）。
更改為SMB2后，我們的命令並未全部序列化到域控制器。這似乎會導致某些命令同時並行運行。
例如，嘗試開啟命名的 lsarpc 命名為 pipe。

在此錯誤消息中，請務必注意我們嘗試綁定到的服務：

2017-06-20 20:51:27: SMB: 3:[NASSERVER1] OpenAndBind[LSA] DC=DC01 failed: Bind_OpenXFailed DOMAIN_CONTROLLER_NOT_FOUND

從錯誤訊息中，我們可以看到它正在嘗試開啟 LSA （以紅色強調顯示）。這就是問題所在。在收到來自 DC 的回應之前，我們嘗試多次同時打開 lsarpc 命名管道。第一個請求成功，但後續請求失敗。我們會看到指出「STATUS_PIPE_NOT_AVAILABLE失敗」訊息，並將DOMAIN_CONTROLLER_NOT_FOUND訊息記錄在記錄中。

請務必注意，這些消息並不總是表示此問題。DOMAIN_CONTROLLER_NOT_FOUND錯誤可能有許多原因。
這個特定的記錄中可能會有很多以下資訊性訊息：

2017-06-28 14:37:45: 26041909248: SMB: 6:[NASSERVER1] sendLookupSIDs pipe lsarpc reopened
2017-06-28 14:37:47: 26041909248: SMB: 6:[NASSERVER1] sendLookupSIDs pipe lsarpc reopened

如果對問題是否與問題匹配有任何問題，可以在數據包跟蹤中進行確認。在跟蹤中，我們會看到多個同時打開 lsarpc 的請求，然後收到對其中任何一個的回應，然後第一個成功，後續請求失敗，並在 DC 回應時STATUS_PIPE_NOT_AVAILABLE。

此問題往往主要發生在需要在網域控制站進行大量 SID 查詢的系統上。如果環境中有孤立的 SID，它往往會記錄更多此類錯誤。這是因為傳送到 DC 的流量很大，每次存取 ACL 時，我們都必須傳送要求給 DC，要求 SID 快取中沒有的任何 SID 身分識別。孤立的 SID 永遠不會在 SID 快取中，並且每次增加我們必須對 lsarpc 指定管道執行的打開量時，都會嘗試查找孤立的 SID。

由於第一次打開嘗試成功，這是一個不具影響的事件，可以忽略這些消息。

永久修正方法：
工程部門已察覺到此問題，並正在努力在未來的程式碼版本中進行修正。這是不中斷的問題，在此期間可以放心忽略。但是，如果您確實想要嘗試減少或消除消息，則有一些解決方法可用。

因應措施 1：
有幾種方法可以嘗試阻止這些消息在日誌中出現。由於 lsarpc 管道上的多個併發打開嘗試會導致問題，因此減少消息的最簡單方法是減少所需的 SID 查找量。

孤立的 SID 會導致這些過多的查找。可以修改以下參數以強制查找以查看未知 sid 的 secmap 快取，並應減少流向 DC 的流量：

[nasadmin@CS0 ~]$ server_param server_2 -f cifs -i acl.mappingErrorAction -v
server_2 :
name                    = acl.mappingErrorAction
facility_name           = cifs
default_value           = 8
current_value           = 8
configured_value        = 8
user_action             = none
change_effective        = immediate
range                   = (0,31)
description             = Define rules for an unknown SID/UID/GID mapping

detailed_description
Defines the rules for unknown mapping between SID/UID/GID on ACL settings. Two kinds of errors might occur: the SID set in the ACL is unknown to the Domain Controllers we are using, or the username is not yet mapped to a UID/GID. 0x01: Stores unknown sid. 0x02: Stores sid with no UNIX mapping. 0x04: Enables debug traces. 0x08: Only do lookup in cache (secmap or globalSid cache or per connection SID cache) 0x08 is HIGHLY RECOMMENDED WITH OPTION=0x01. 0x10: Disable log displayed when an unknown SID resolution takes too much time.Maximum value = 0x1F Refer to param cifs.acl.retryAuthSID

這將轉換為以下資訊：
Bit0 = 儲存未知的 sid。
Bit1 = 儲存沒有 UNIX 映射的 sid。
Bit2 = 啟用調試跟蹤。
Bit3 = 僅在快取中進行查詢 （secmap 或 globalSid 快取，或依連線 SID 快取）

如果設定了位元 0 和 1 （0x3值），則允許將孤立的 SID 儲存在檔案系統 ACL 上 （預設情況下不是）。建議將值從 0x3 更改為 0x11，這將打開位 0,1 和 3。這意味著存儲未知的 SID，沒有 unix 映射，並且只查看 secmap 和全域 SID 快取。如果設置為 0x8 或關閉位 0 和 1 的其他組合，則不允許存儲孤立 sid，並且不應對此參數進行任何更改。

如果要修改參數，可以執行以下命令：

server_param server_2 -f cifs -m acl.mappingErrorAction -v 11

這可能會減少發生次數，但可能會也可能不會完全消除它們。

因應措施 2：
消除日誌中這些錯誤的可靠方法是將DC通信行為恢復到新代碼之前的狀態（這意味著我們僅與SMB1中的域控制器通信）。

如果您想要還原至 SMB1 以進行 dc 通訊 （舊的 VNX 行為），請聯絡 Dell 支援並參考此知識文章。