최근 공유 파일에 DFS를 사용하도록 Windows 네트워크를 마이그레이션했습니다. 한 가지 성가신 문제를 제외하고 DFS는 잘 작동합니다. 사용자는 한동안 액세스하지 않은 DFS 네임 스페이스에 액세스하려고 할 때 상당한 지연이 발생합니다. 문제를 해결하려고 시도했지만 지금까지 성공하지 못했으며 여기 누군가가 문제를 해결하는 데 도움이되는 몇 가지 조언이 있기를 바랍니다.
첫째, 우리 네트워크의 일부 배경 :
네트워크는 2 개의 Windows 2008 DC와 2 개의 DNS 서버 (각 DC에 하나씩)가있는 Windows 2008 기능 수준 Active Directory 도메인을 사용합니다. 네트워크는 DNS 전용이며 WINS는 없습니다. 모든 컴퓨터는 같은 사이트에 위치하고 기가비트 이더넷으로 연결됩니다. Windows 2008 모드에는 약 20 개의 도메인 기반 DFS 네임 스페이스가 있으며 각 DFS 네임 스페이스에는 두 개의 Windows 2008 DFS 네임 스페이스 서버 (모든 네임 스페이스에 대해 동일한 두 서버)가 있습니다. 모든 네임 스페이스 서버는 FQDN 모드에 있으며 모든 폴더 대상은 해당 FQDN을 사용하여 지정됩니다. 모든 컴퓨터는 서비스 팩 및 패치가 최신 상태입니다.
실제 폴더 대상 (예 : DMB 폴더가 가리키는 SMB 공유)은 여러 파일 및 응용 프로그램 서버에 분산되어 있으며, Windows 2008 R2를 실행하는 두 개의 응용 프로그램 서버 (Windows 2003 R2를 실행하는 응용 프로그램 서버는 전혀 복제 설정 없음) (예 : 현재 모든 DFS 폴더) 폴더 대상이 하나뿐입니다).
문제에 대한 자세한 내용은 다음과 같습니다.
네임 스페이스 액세스 지연은 일반적으로 1-10 초이며 특정 컴퓨터가 약 5 분 이상 동안 요청 된 네임 스페이스에 액세스하지 않은 경우에 발생하는 것으로 보입니다.
예를 들어, 사용자가 5 분 이상 \\ domain.name \ namespace1 \에 액세스하지 않고 Windows 탐색기를 통해 \\ domain.name \ namespace1 \에 액세스하려고하면 탐색기 창이 1-10 초 동안 정지되고 마지막으로 \\ domain.name \ namespace1에있는 폴더를 다시 시작하고 표시합니다. 그런 다음 탐색기 창을 닫고 5 분 내에 \\ domain.name \ namespace1 \에 다시 액세스하려고하면 내용이 거의 즉시 표시됩니다. 5 분 이상 기다리면 1-10 초의 일시 중지가 다시 발생합니다.
네임 스페이스를 “내부”로 설정하면 모든 것이 멋지고 빠릅니다. 네임 스페이스에 대한 초기 연결 일뿐입니다.
브라우징 지연은 우리가 사용하는 모든 Windows 변형 (Windows 2008 x64 SP2, Windows 2003 R2 x86 SP2, Windows XP Pro x86 SP3)에 영향을 미치는 것으로 보입니다. Windows 2008/2008에서는 Windows 2008보다 약간 더 나쁠 수 있습니다. 차이가 심리적 인 것이 아닌지 확실하지 않습니다.
기본 폴더 대상에 직접 액세스하면 지연이 전혀 없습니다. 즉, DFS가 가리키는 SMB 공유에 직접 액세스하면 (DFS 무시) 일시 중지가 없습니다.
문제를 해결하는 동안 모든 DFS 루트의 “캐시 기간”이 300 초-5 분으로 설정되어 있음을 알았습니다. 이것이 일시 중지를 트리거하는 데 필요한 시간과 같다는 점을 감안할 때 클라이언트에 캐시 된 내용을 정확히 알지 못하기 때문에 5 분이 지나면 다시 조회 해야하는 내용이 있지만이 캐싱은 어떻게 든 관련이 있다고 가정합니다.
문제를 해결하기 위해 이미 다음을 시도 / 확인했습니다 (성공하지 않음).
- 두 도메인 컨트롤러 모두에서 dcdiag를 실행하십시오. 문제가 없습니다.
- 문제를 찾지 않고 기본적인 DNS 서버 검사를 완료했습니다. DNS 서버를 자세히 검사하는 방법을 모르겠지만 네트워크에 DNS 문제를 나타내는 다른 이상한 동작이 나타나지 않는다고 덧붙입니다.
- 클라이언트 및 서버에서 비활성화 된 바이러스 백신
- 네임 스페이스 서버 중 하나를 몇 개의 네임 스페이스에서 제거
그래서 그것은 내가 할 수있는 곳이며 아이디어가 없습니다. 지연을 유발하는 원인 및 / 또는 다음에 시도해야 할 것을 제안 할 수 있습니까?
답변
글쎄, 우리 마침내 우리 환경에서이 문제를 해결 한 것으로 보입니다. 다른 사람들의 이익을 위해 다음과 같이 발견 한 내용과 문제를 해결 한 방법이 있습니다.
지연 전 / 중 / 후에 발생한 상황에 대한 추가 정보를 얻기 위해 클라이언트 컴퓨터에서 Wireshark를 사용하여 네트워크 트래픽을 캡처 / 분석하는 동안 클라이언트가 DFS 공유에 액세스하려고했습니다.
이러한 캡처는 이상한 것으로 나타났습니다. 지연이 발생할 때마다 클라이언트에서 DC로 DFS 요청이 전송되고 DC에서 클라이언트로 다시 오는 DFS 루트 서버에 대한 참조 사이에서 DC는 여러 브로드 캐스트 이름을 전송했습니다. 네트워크를 찾습니다.
먼저 DC는 DOMAIN에 대한 NetBIOS 조회를 브로드 캐스트합니다 (여기서 DOMAIN은 Windows 2000 이전의 Active Directory 도메인 이름입니다). 몇 초 후, DOMAIN에 대한 LLMNR 조회를 브로드 캐스트했습니다 . 그런 다음 DOMAIN에 대한 또 다른 브로드 캐스트 NetBios 조회가 이어집니다. 이 세 가지 조회가 브로드 캐스트 된 후 (시간이 초과 된 것으로 가정) DC는 DFS 루트 서버에 대한 (올바른) 조회를 통해 클라이언트에 최종 응답합니다.
DOMAIN에 대한 이러한 브로드 캐스트 이름 조회는 DFS 공유 열기가 오래 지연된 경우에만 전송되었으며, Wireshark 캡처에서 DC가 3 개의 조회를 모두 보낼 때까지 DFS 루트 서버에 대한 조회를 반환하지 않았 음을 분명히 알 수있었습니다 ( ~ 7 초가 지났습니다). 따라서 이러한 브로드 캐스트 이름 조회는 분명히 지연의 원인이었습니다.
문제가 무엇인지 알았으므로 브로드 캐스트 이름 조회가 왜 발생했는지 알아 내기 시작했습니다. 더 많은 인터넷 검색과 시행 착오 끝에 우리는 답을 찾았습니다 .DNS 전용 환경에서 DFS를 사용할 때와 같이 도메인 컨트롤러의 DfsDnsConfig 레지스트리 키를 1로 설정하지 않았습니다.
우리는 원래 설치 DFS는 우리의 환경에서 우리는 때 않았다 (예 : DNS 전용 환경을 위해 DFS를 구성하는 방법에 대한 다양한 기사를 읽을 마이크로 소프트 KB244380을 및 기타)이 레지스트리 키를 알고 있었다, 그러나 때 / 방법에 대한 지침을 misintepreted했다 사용해.
KB244380의 말 :
모든 컴퓨터가 완전한 이름을 이해하려면 DFS 네임 스페이스에 참여할 각 서버에 DFSDnsConfig 레지스트리 키를 추가해야합니다.
이는 레지스트리 키가 DFS 네임 스페이스 서버 에만 설정되어야 하며 도메인 컨트롤러에도 필요하다는 것을 인식하지 않아야한다는 것을 의미했습니다. 도메인 컨트롤러에서 DfsDnsConfig를 1로 설정하고 “DFS 네임 스페이스”서비스를 다시 시작하면 문제가 사라졌습니다.
분명히 우리는이 결과에 만족하지만, 이것이 여전히 우리의 유일한 문제라는 것을 100 % 확신하지는 않는다고 덧붙일 것입니다. DC에 DfsDnsConfig = 1을 추가하는 것이 문제를 해결하는 것이 아니라 문제를 해결 한 것이 아닌지 궁금합니다. . DC가 DNS가 아닌 환경에서도 DFS 조회 프로세스 중에 DC가 DOMAIN (도메인의 서버가 아닌 도메인 이름 자체)을 찾으려고하는 이유를 알 수 없으며 다른 DNS 전용 환경의 도메인 컨트롤러에서 DfsDnsConfig = 1을 설정하지 않았으며 같은 문제가 없었습니다. 그래도 우리는 문제를 해결하여 행복했습니다.
나는 이것이 비슷한 문제를 겪고있는 다른 사람들에게 도움이되기를 바랍니다. 그리고 제안을 해준 사람들에게 다시 감사드립니다.
답변
이것은 DNS 서버 넷 마스크 순서로 인해 발생할 수 있습니다. 최근에 Server 2003에서이 문제가 발생했습니다. 이는 현재 서브넷에 따라 다릅니다.
예.
사이트 1 : IP 서브넷 10.0.0.0/24 사이트 2 : IP 서브넷 10.0.1.0/24
사이트 2의 클라이언트는 도메인 기반 네임 스페이스에 대한 DNS 쿼리를 만들고 DNS 서버가 사이트 IP 경계를 인식하지 못하므로 기본적으로 사이트 1의 DFS 서버에 제공됩니다. 응답 할 IP 주소를 식별하는 데 사용할 서브넷 마스크를 DNS 서버에 알려 주어야합니다.
답변
Active Directory 팀 블로그에는 DFS 지연에 관한 3 가지 기사가 있습니다.
http://blogs.technet.com/b/askds/archive/2009/09/29/o-dfs-shares-where-art-thou-part-1-3.aspx
추천 프로세스의 기본 사항을 다루고 dfsUtil 및 dfsDiag를 포함한 다양한 도구를 사용하여 지연의 실제 원인을 찾는 방법을 보여줍니다.
내 문제를 찾는 데 도움이되었습니다. 도메인 사용자의 공유 디렉토리에 대한 읽기 권한이없는 것으로 밝혀졌습니다.
HTH, 다니엘
답변
DNS 문제처럼 보이지만 아무 문제가 없습니다. 초음파와 같은 진단 도구가 매우 유용했기 때문에 이전 FRS를 선호했습니다.
대상의 DFS 복제 이벤트 로그에 어떤 것이 있습니까? (DFS 상태 보고서는 이벤트 로그에서 경고를 표시합니다)
WINS없이 실행하는 것은 훌륭한 목표이며 훌륭합니다.하지만 비스타 / 2008 이전 Windows 시스템이 내 경험에 WINS없이 항상 예상대로 또는 빨리 작동하지 않기 때문에 거의 반대입니다. 중요하지 않습니다.
답변
클라이언트는 DFS 조회를 캐시합니다. 즉, \ domain.name \ namespace를 입력하면 실제 서버 domain.name이 참조하는 캐시가 캐시됩니다. 캐시에서 조회가 만료되면 클라이언트는 기본적으로 DFS 토폴로지를 다시 “발견”해야하므로 지연됩니다.
http://technet.microsoft.com/en-us/library/cc758234(WS.10).aspx 및 여기 http://blogs.technet.com/filecab/archive/2006/01/20을 살펴보십시오. 작동 방식에 대한 자세한 내용 은 /417832.aspx 를 참조하십시오.
가능한 해결책? 해킹 방법은 몇 분마다 “살아남는”작은 프로그램을 작성하는 것일 수 있습니다. 예를 들어 찾은 첫 번째 파일 인 fopen은 즉시 닫는 C 프로그램입니다. 나는 이것을 시도하거나 테스트하지 않았으므로, 그렇게하려고한다면 신중하게 고려해야합니다.
답변
DFS 공유에 매핑 된 드라이브를 클릭하고 공유 내의 폴더를보고 탐색 할 때까지 사용자가 지연 (최대 1 분)되는 비슷한 소리가났습니다.
또한 사용자는 동일한 볼륨에서 다른 DFS 공유에 홈 드라이브를 매핑했으며 폴더에 액세스 할 때 지연되지 않았습니다.
이 둘의 차이점은 ABE (Access-Based Enumeration)입니다. 문제 공유에이 기능이 활성화되어 있습니다 (이 폴더는 수천 개의 폴더를 가진 사용자에게는 일반적인 드라이브입니다)-ABE는 사용자가 권한이있는 폴더 만 볼 수 있음을 의미합니다.
ABE를 비활성화하면 문제가 완전히 제거되었습니다. 분명히 이것은 사용자가 모든 폴더를보고 혼동하기 때문에 해결책이 아닙니다. 여분의 디스크를 임시 측정 값으로 사용하여 서버에 DFS 공유를 복제했으며이 새 대상에서 ABE를 사용하더라도 지연이 발생했습니다.
문제 서버는 2k3R2이고 가동 시간이 150 일 (!) 이상이므로 다시 부팅되고 CHKDSK가 문제가되는 볼륨에서 실행됩니다. 이것이 문제와 다른 점이 있다면 여기에 다시 게시하겠습니다. 새로운 대상은 2k8 서버에 있습니다.
답변
dfsutil / spcflush 및 dfsutil / pktflush는 다중 사이트 네트워크에서도 솔루션이 될 수 있습니다. 홈 사이트의 DFS 링크가 캐시가 아닌 로컬 서버에서 오는지 확인하십시오.
