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 서버 또는 Data Mover가 SMB2의 도메인 컨트롤러와 통신할 수 있는 새로운 기능에 추가되었습니다. 이 코드 이전에는 도메인 컨트롤러 통신이 모두 SMB1에서 처리되었습니다(클라이언트는 여전히 SMB2/SMB3에서 통신할 수 있음).
SMB2로 변경됨에 따라 명령이 모두 도메인 컨트롤러로 직렬화되는 것은 아닙니다. 이로 인해 일부 명령이 동시에 병렬로 실행되는 것으로 보입니다.
명명된 lsarpc 명명된 파이프를 열려고 시도하는 경우를 예로 들 수 있습니다.

이 오류 메시지에서 바인딩하려는 서비스를 기록하는 것이 중요합니다.

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의 ID를 요청해야 합니다. 분리된 SID는 SID 캐시에 있지 않으며 lsarpc 명명된 파이프에 대해 수행해야 하는 열기의 양이 증가할 때마다 조회됩니다.

첫 번째 열기 시도가 성공하면 이는 영향을 주지 않는 이벤트이므로 이러한 메시지는 무시해도 됩니다.

영구 수정:
엔지니어링 팀은 이 문제를 알고 있으며 향후 코드 릴리스에서 수정할 수 있도록 노력하고 있습니다. 이는 운영 중단이 없는 문제이며 그 동안 무시해도 됩니다. 그러나 메시지를 줄이거나 제거하려는 경우 몇 가지 해결 방법을 사용할 수 있습니다.

해결 방법 1:
로그에서 이러한 메시지가 발생하지 않도록 하는 몇 가지 방법이 있습니다. lsarpc 파이프에서 여러 번의 동시 열기 시도로 인해 문제가 발생하므로 메시지를 줄이는 가장 쉬운 방법은 필요한 SID 조회의 양을 줄이는 것입니다.

분리된 SID로 인해 이러한 과도한 조회가 발생합니다. 다음 매개변수를 수정하여 조회가 알 수 없는 sids에 대한 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이 켜집니다. 즉, unix 매핑 없이 알 수 없는 SID를 저장하고 secmap 및 전역 SID 캐시만 확인합니다. 0x8 또는 비트 0과 1이 꺼져 있는 다른 조합으로 설정된 경우 분리된 SID를 저장할 수 없으며 이 매개 변수를 변경해서는 안 됩니다.

매개변수를 수정하려는 경우 다음 명령을 실행할 수 있습니다.

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

이렇게 하면 발생이 줄어들 수 있지만 완전히 제거할 수도 있고 완전히 제거하지 못할 수도 있습니다.

해결 방법 2:
로그에서 이러한 오류를 제거하는 확실한 방법은 DC 통신 동작을 새 코드 이전으로 되돌리는 것입니다(즉, SMB1의 도메인 컨트롤러와만 통신합니다).

DC 통신을 위해 SMB1(이전 VNX 동작)로 되돌리려면 Dell 지원에 문의하고 이 기술 자료 문서를 참조하십시오.