질문 :이 350,000 파일 백 로그를 더 빨리 완료 할 수있는 방법이 있습니까? 거의 모든 파일에 대해 영향을받는 각 파일의 ACL 만 변경되었습니다. 일부 파일은 내용을 변경했지만이 상황에서는 일반적이지 않습니다.
이 문제는 해결되었을 수 있습니다. 이 텍스트를 편집하여 일정 기간 및 확인 후 성공 / 실패를 확인합니다. 이 질문 텍스트의 끝 부분에 대해 최근에 수정 한 내용이 자세히 설명되어 있습니다.
약 450,000 개의 파일이있는 DFSR 복제 그룹이 있으며 1.5TB의 공간을 차지합니다. 이 상황에서 약 500 마일 떨어진 두 개의 Windows Server 2008 R2 서버가 있습니다. 다른 서버가 있지만이 복제 그룹에는 관여하지 않습니다. 서버 ALPHA는 주 서버이며 대부분의 직원이 사용하는 서버입니다. 서버 베타는 원격 사무실의 서버이며 사용량이 적습니다.
다음은 느린 복제 진행률을 보여주는 이 복제 그룹 (Google 드라이브에서 호스팅되는 PNG)에 대한 백 로그 그래프입니다 .
해당 복제 그룹의 루트 디렉토리에있는 권한 항목을 제거해야했는데, 물론 대부분의 하위 폴더에서 상속되었습니다. 서버 ALPHA에서이 변경을 수행했습니다. 그 직후 DFSR에는 350,000 개의 파일 백 로그가있었습니다. 일주일이 지났으며 지금은 267,000입니다. 처음에 변경된 유일한 것은 단일 권한 변경이었습니다.
이것이 일어난 일입니다 (이것은 해결책이 아니며이 문제를 일으킨 일에 대한 또 다른 설명 일뿐입니다) : http://blogs.technet.com/b/askds/archive/2012/04/14/saturday-mail-sack 금요일 밤이 지났기 때문에 괜찮아 싸웠습니다 .aspx # dfsr
서버 BETA에서 발생하는 모든 변경 사항은 해당 방향으로 백 로그가 없기 때문에 서버 ALPHA로 매우 빠르게 복제됩니다. 베타에서 변경된 모든 파일은 문제없이 ALPHA로 만듭니다.
한 쪽 끝을 50Mbps 연결을 통해 다른 쪽 끝의 광섬유 100Mbps에 최대 속도로 연중 무휴로 복제하고 있습니다. 준비 영역은 각 서버에서 100GB입니다. 이벤트 로그에는 전혀 흥미로운 것이 없습니다. 이 특정 복제 또는이 ALPHA / BETA 서버 쌍이 아닌 관련되지 않은 복제 그룹에 대해 표시되는 관련없는 상위 워터 마크 이벤트가 있습니다. 특히 워터 마크가 높거나 연결 오류에 대한 이벤트 로그 항목이 없습니다.
복제 그룹에 대한 ALPHA의 관점 :
대역폭 절약 : 99.83 % 감소 (18.1GB 대신 30.85MB 복제)
ALPHA 및 BETA에서 DFSR 서비스를 마지막으로 다시 시작한 이후 30.85MB / 18.1GB가 발생했다고 생각합니다. 그렇다면 시간이 오래 걸리더라도 (필자가 생각하는 것보다 오래 걸리지 만) 실제로 파일 내용을 실제로 전송하지는 않습니다.
복제 된 폴더 : 1.46TB (실제 크기), 439,387 (파일), 52,886 (폴더)
충돌 및 삭제 된 폴더 : 100.00GB (구성된 크기), 34.01GB (실제 크기), 19,620 (파일), 2,393 (폴더)
준비 폴더 : 200.00GB (구성된 크기), 92.54GB (실제 크기)
로그에 하나의 워터 마크 오류가 발생하여 (5 월 14 일 오후 7시) 스테이징 할당량을 100GB에서 200GB로 올렸습니다. Microsoft가 승인 한 경로가 20 % 증가한다는 것을 알고 있지만이 문제를 해결하지는 않습니다. 준비 디스크 어레이에 여유 공간이 충분합니다.
모든 서버에서 바이러스 백신을 비활성화 하면 도움 이 되지 는 않았지만 조금 도움이 될 것이라고 생각했습니다. 지금은 안티 바이러스를 다시 활성화했지만 방정식에서 해당 변수를 제거하기 위해 복제 그룹의 경로를 검사에서 제외하도록 설정했습니다.
더 빨리 갈 수있는 방법이 있습니까? 서버 BETA 에서도이 변경 작업을 수행하지만 ALPHA에서는 변경되었지만 BETA로 복제되지 않은 파일이 있으며 BETA에서 상속 된 권한 변경을 수행하면 OLD 파일을 BETA에서 ALPHA로 푸시 합니다 (DFSR은 충돌에서 우승 한 파일을 비교할 때는 파일 타임 스탬프를 무시하십시오). 그리고 그렇게하는 것은 오히려 나쁠 것입니다.
백 로그가 느리게 감소하고 있습니다. 아주 아주 천천히 그러나 앞으로 나아갈 것입니다. 그러나이 속도로 완료되기까지 몇 주가 걸릴 것입니다. 데이터 세트 사본을 3TB 드라이브에 넣고 원격 사무실로 배송하는 것을 고려하고 있습니다. 더 좋은 방법이 있습니까?
5 월 16 일 오전 4시 미국 태평양 표준시 : 문제를 해결 한 원인 (정직하게 고쳐 졌다고 가정) :
오래 전에해야했던 DC를 여러 번 변경했습니다. 문제는이 네트워크가 다른 누군가로부터 상속받은 다른 사람으로부터 상속 받았다는 것입니다. 어떤 변화가 문제를 해결했는지는 약속 할 수 없습니다. 여기에는 특별한 순서가 없습니다.
- 모든 DC가 "도메인 컨트롤러"OU에 없습니다. 다른 곳에서 DC가있는 Windows 도메인을 본 적이 없습니다. 나는 그들이 속한 곳으로 다시 옮겼습니다. 그들은 각 사무실에있는 도시의 이름으로 분리 된 그 OU에 이전에 있었다. (나는 내가 사람들을 움직 이니까 다루는 몇 가지 배관 작업있어 느낌,하지만 모두가 보인다 현재 좋아 ...)
- AVG Anti-Virus는 모든 DC 및 DFSR 참여 서버에서 실행됩니다. 활성 / 액세스 검색에서 복제 된 폴더와 준비 폴더를 제외했습니다. 나는 이것이 문제를 해결했다고 생각하지 않으며 나중에이 문제를 테스트하여 변경 사항을 취소하면 DFSR의 복제 속도를 방해하는지 확인할 수 있습니다. 그것은 또 다른 하루를위한 도전입니다.
- dcdiag.exe 는 RODC와 관련된 DNS 문제에 대해 불평했습니다. 도메인에 RODC가 전혀 없어도이 문제를 해결했습니다. 나는 이것이 고정 된 것을 의심한다.
- DC 중 하나 (DFSR 서버 중 하나가 아님)에 대해 _ldap._tcp.domain.GUID._msdcs.DOMAIN.NET SRV 레코드 중 하나가 누락되어 문제를 해결했습니다. 나는 이것이 도움이되지 않았다고 생각합니다.
- 서버 베타를 재부팅 한 경우 중 하나가 DFSR 데이터베이스의 종료가 잘못되었다고 불평 한 후 (이벤트 2212) 데이터베이스를 다시 빌드하는 데 몇 시간이 걸렸습니다. 완료되면 이벤트 2214를보고하여 완료되었음을 알려줍니다. 그 후에도 복제는 여전히 매우 느리게 진행되었지만 문제가 발생한 것을 풀 수있었습니다.
- DC 중 하나의 인터페이스 구성에서 보조 DNS 서버로 127.0.0.1이 없었습니다. 나는 그것을 추가했다. 이것은 DFSR 서버 중 하나가 아니 었으므로 아마도 서버와 관련이 없었을 것입니다.
- TechNet 블로그 : DFSR에서 복제 성능 조정 권장 DFSR 서버에 대한 레지스트리 설정을 따랐습니다 . AsyncIoMaxBufferSizeBytes를 제외한 모든 "테스트 된 고성능 값"값 을 4194304 로 설정 했는데 이는 높은 값보다 1 노치 낮습니다. 이것은 문제를 해결하는 데 도움이 될 수 있습니다. 변수가 너무 많이 변경되면 알기가 어렵습니다.
- dcdiag.exe 는 BETA에서 RPC 서비스와의 통신 문제에 대해 불평했지만 위의 변경을 이미 완료 한 후에 만 가능합니다. 이것은 가장 가능성이 큰 문제인 것처럼 보였지만 문제를 해결하지 못했습니다. VPN이 올바르게 실행 중이고 방화벽이 차단하지 않았습니다. 위의 항목 중 하나가 RPC 문제를 일으킨 후 수정 한 것일 수 있으며 단순한 우연의 일치 일 수도 있습니다. 나는 하지 지금 오류가 복제가 현재 원활하게 실행됩니다.
이야기의 교훈은 : 한 번에 한 가지만 바꾸거나 그것이 어떻게 고쳐 졌는지 결코 알지 못할 것입니다. 그러나 필사적으로 문제를 해결하기 위해 시간이 부족하여 문제에 총알을 발사했습니다. 수정 사항을 정확히 지적하면 여기에보고하겠습니다. 그래도 좁히지 마라.
2012 년 5 월 21 일 수정 : 어제 예비 서버 (GAMMA)를 사용하여 약 7 시간 동안 원격 사무실로 운전 하여이 문제를 해결했습니다. GAMMA는 현재 기본 서버 (BETA)가 복제를 따라 잡는 동안 기본 로컬 서버로 작동하고 있습니다. 필자가 서버를 제자리에 배치 한 이후 서버는 복제 속도를 두 배로 늘 렸습니다. 이것이 VPN 관련 문제 일 수 있다고 말하지만, 모든 새로운 업데이트가 ALPHA의 GAMMA에 복제 된 것처럼 보였기 때문에 믿기 어렵습니다.
2012 년 5 월 22 일 수정 : 현재 12000에 있으며 몇 시간 안에 완료해야합니다. 느린 시작에서 빠른 완료까지 진행 상황에 대한 멋진 그래프를 게시합니다. 문제는 실제로 실제로 "고정 된"것은 로컬 서버 연결이라는 것입니다. 현재 VPN이 문제의 일부라고 생각합니다. 그리고 그 경우라면, 나는이 질문에 아직 답변이되지 않았다고 생각합니다. VPN을 통해 상황이 어떻게 복제되는지 확인하고 실패를 확인하는 데 시간이 더 걸리면 디버깅하고 진행 상황을보고합니다.
무언가가 바뀌면 여기에서 업데이트하겠습니다.
dfsrdiag replicationstate /a파일이 두 개만 전송되지만 둘 다 동일한 파일 이름을 가지고 있음을 보여줍니다. 어쨌든 ALPHA에서 베타로 두 개의 아웃 바운드 연결이 있다고합니다. 전송중인 파일은 850MB입니다. 앞서 설명한 바와 같이, 나는 그것이 실제로 확신 아니에요 전송 잘 모르겠어요하지만, 전체 파일의 내용을 무엇을 하지 그냥 하나의 파일을 처리하는 데 시간이 오래 걸리므 경우 일 것입니다. 이 파일은 2008 년에 두 서버 모두에서 마지막으로 업데이트되었으므로 BETA의 파일에서 ACL 정보를 업데이트하는 것 외에는 아무 것도 할 필요가 없습니다.