공용 폴더 복제 문제 해결 - 2부: 기존 데이터 복제 문제 해결
최초 문서 게시일: 2011년 11월 28일 월요일
영문 블로그 최초 게시일: 2006년 1월 20일
이 블로그 게시물은 공용 폴더 복제 문제 해결과 관련된 두 번째 게시물입니다. 첫 번째 게시물(영문일 수 있음)에서는 새 변경 내용 복제 문제를 해결하는 방법에 대해 설명했습니다. 이번 블로그 게시물에서는 기존 데이터 복제 문제를 해결하는 방법에 대해 다루며, 이 시리즈의 마지막 게시물(영문일 수 있음)에서는 복제본 삭제 문제 및 일반 문제를 해결하는 방법에 대해 다룹니다. 전반적인 내용을 파악하려면 참조 자료를 모두 확인하시기 바랍니다.
기존 데이터 복제 문제 해결
새 변경 내용은 복제되는데 변경되지 않은 이전 내용은 복제되지 않는 경우 백필 문제가 발생합니다. 계층 구조 백필이 수행되는 가장 일반적인 상황은 새 공용 저장소를 만들 때이며, 가장 일반적인 콘텐츠 백필 시나리오는 공용 저장소를 폴더의 복제본 목록에 추가하는 경우입니다.
이러한 백필 문제가 확인된다는 것은 해당 문제가 이미 발생했으며 모든 항목을 변경하는 것 이외의 방법으로는 해결이 쉽지 않다는 의미입니다. 모든 항목을 변경하면 백필 프로세스 손상 문제를 우회하여 모든 항목을 새 변경 내용으로 복제할 수 있습니다. 보통 이 작업에 사용되는 두 가지 도구(PFDAVAdmin 및 ModifyItems)에 대해서도 기술한 바 있지만, 일반적으로는 백필 프로세스의 문제를 해결하고 근본 원인을 수정하는 것이 가장 좋습니다. 모든 항목을 변경하여 복제하는 경우 나중에 복제본이 또 동기화되지 않으면 같은 백필 문제가 다시 발생할 수도 있습니다. 이러한 맥락에서 백필에 대해 좀 더 설명하겠습니다. 백필 프로세스를 이해하려면 먼저 변경 내용 추적 방식을 이해해야 합니다.
저장소에 있는 모든 폴더와 메시지에는 작성 시와 매 수정 시에 CN(변경 번호)이 지정됩니다. 복제를 수행할 때는 각 개체의 CN을 사용하여 개체를 복제해야 하는지 여부를 결정합니다. CN 그룹을 CNSet라고 하며, 특정 서버에 있는 특정 폴더의 CNSet를 상태 정보라고 합니다. 이 상태 정보는 모든 복제 메시지에 포함됩니다. 오류 메시지 유형 0x2에는 보내는 서버의 계층 구조 상태가 포함됩니다. 마찬가지로, 모든 메시지 유형 0x4에는 보내는 서버의 해당 특정 폴더에 대한 상태 정보가 포함됩니다. 다른 모든 복제 메시지 유형에도 해당하는 폴더의 상태 정보가 포함됩니다.
새 공용 저장소는 최초 탑재 시 계층 구조 상태 요청(0x20 유형)을 모든 기존 공용 저장소로 보냅니다. 마찬가지로 폴더의 복제본 목록에 추가되는 새 저장소는 해당 폴더의 다른 모든 복제본으로 0x20을 보냅니다. 모든 복제본 메시지와 같이, 상태 요청 역시 관련 폴더 또는 계층 구조에 대한 모든 CN의 CNSet(원래 저장소에 있는 것과 같음)를 포함하며, 다른 저장소가 원래 저장소에는 없는 CN을 포함하는 경우 응답하라는 요청을 합니다. Exchange 2003 SP2 이전 버전에서는 모든 복제본에 대해 상태 요청에 응답하라는 요청이 수행되지 않았으므로, 일부 저장소는 원래 저장소와 다른 변경 내용이 적용되어 있어도 상태 요청을 무시하는 경우가 있었습니다. 2003 SP2 서버는 모든 복제본의 응답을 요청하며 원래 서버에서 응답을 요청하지 않았더라도 원래 서버와는 다른 변경 내용이 적용되어 있으면 요청에 응답합니다. 따라서 백필 프로세스 중의 의사 결정 과정이 크게 향상됩니다. 상태 요청은 복제할 데이터를 포함하지 않으며 변경 번호 목록만 포함한다는 점에서 독특합니다. 다른 저장소는 상태 메시지(0x10)로 응답하는데, 이 메시지에는 같은 폴더 또는 계층 구조에 대한 해당 저장소의 자체 CNSet가 나열됩니다. 원래 서버는 0x10 메시지를 받으면 메시지에 포함된 CNSet와 자체 CNSet를 비교합니다. 0x10 메시지에 포함된 변경 내용이 원래 저장소에는 적용되어 있지 않으면 백필 프로세스가 시작됩니다.
백필 프로세스의 첫 단계에서는 관련 폴더의 백필 배열에 항목을 추가합니다. 이러한 항목에는 누락된 변경 내용을 설명하는 CNSet와 저장소에서 누락된 데이터를 요청하는 시간을 설명하는 제한 시간 값이 포함됩니다. 백필 제한 시간은 상황에 따라 다릅니다. 새 공용 저장소를 온라인으로 전환하거나 폴더의 새 복제본을 추가하는 경우 초기 제한 시간은 15분입니다.
정상적인 작업 과정에서도 백필 항목이 백필 배열에 추가될 수 있습니다. 특정 공용 저장소에서 두 개별 0x2 메시지를 통해 두 변경 내용을 브로드캐스트했는데, 관리자가 첫 번째 0x2 메시지는 큐에서 삭제하고 두 번째 메시지는 발송되도록 했다고 가정해 보겠습니다. 다른 서버에서는 이 0x2 메시지를 받은 후 상태 정보의 CNSet에 고유한 CN이 포함되어 있음을 확인하여 해당 데이터에 대한 백필 항목을 만듭니다. 정상 복제 과정에서 발견된 누락 데이터에 대한 백필 항목의 경우, 해당 데이터를 같은 RG(라우팅 그룹)에서 사용할 수 있으면 초기 제한 시간이 6시간으로 설정되고 데이터를 다른 RG에서만 사용할 수 있으면 제한 시간이 12시간으로 설정됩니다. 백필 요청을 실행할 때마다 다음 제한 시간은 RG 내 요청의 경우 12시간/24시간, RG 간 요청의 경우 24시간/48시간으로 설정됩니다.
저장소는 5분마다 제한 시간에 도달한 백필 항목이 있는지를 확인하며, 이러한 항목이 있는 경우 누락된 CN에 대한 백필 요청(0x8 유형)이 실행되고 제한 시간이 다음 간격으로 설정됩니다. 백필 요청은 브로드캐스트가 아니며 단일 서버, 즉 이전에 요청 서버로 보낸 상태 정보에서 누락된 CN이 있었던 것으로 확인된 서버 중 하나에서 생성됩니다. 들어오는 0x8을 받은 서버는 즉시 요청을 처리하고 하나 이상의 백필 응답(계층 구조의 경우 0x80000002, 콘텐츠의 경우 0x80000004)을 사용하여 응답합니다. 이 응답에는 요청된 변경 번호의 실제 데이터가 포함되어 있습니다. 백필 요청과 마찬가지로 백필 응답 역시 브로드캐스트가 아니며 요청 서버로만 발송됩니다.
요청 서버에서 들어오는 백필 응답을 정상적으로 처리하면 응답에 포함된 CN이 해당 저장소의 백필 배열에서 지워집니다. 실제로 CN이 포함된 들어오는 메시지가 백필 배열에 남아 있으면 해당 CN이 배열에서 지워집니다.
문제 해결
백필 프로세스의 문제를 해결할 때는 아래와 같이 다양한 사항을 파악해야 합니다.
1. 저장소에서 누락된 데이터가 있음을 인식하는지 여부
우선 서버에서 다른 저장소의 변경 내용을 요청해야 함을 인식하고 있는지를 확인해야 합니다. 백필 배열에 항목이 있는지를 직접 확인할 수 있는 지원 도구나 유틸리티는 없지만, 다른 간접적인 방식으로 이를 확인할 수 있습니다.
그 중 한 가지 방법은 기다리는 것입니다. 서버에서 데이터 누락을 인식하면 최소 24시간 또는 48시간에 한 번 데이터를 요청합니다. 즉, 로깅을 설정해 두고 0x8 메시지가 표시되는지만 확인하면 됩니다. 관련 폴더에 대해서는 0x8이 표시되지 않는데 다른 폴더에 대해서는 0x8이 표시되는 경우에는 대기 백필 제한에 도달한 것입니다. 여기에 대해서는 아래에서 설명하겠습니다.
서버에서 최신 상태 정보를 받는지 여부를 확인하는 방법도 있습니다. 서버는 새 복제본을 추가한 후 상태 요청을 한 번만 보내며, 그 후에는 일반 복제 과정을 통해서만 상태 정보를 받습니다. 그러므로 응답에서 0x20 또는 0x10이 손실되거나 삭제되어 최초 상태 가져오기 시도가 실패한 경우 서버는 해당 상태로 계속 유지되며 데이터 누락을 인식하지 못합니다. 몇 가지 방법을 통해 서버에서 폴더에 대한 상태 정보를 받았는지를 확인할 수 있습니다.
- 모든 데이터가 포함된 서버로 이동한 다음 메시지를 추가, 삭제 또는 수정하여 폴더를 변경합니다. 계층 구조의 경우에는 폴더 속성을 작성, 삭제 또는 변경합니다. 그러면 생성되는 0x4 또는 0x2에는 폴더나 계층 구조의 상태 정보가 각각 포함됩니다. 데이터가 누락된 서버에서 들어오는 복제 메시지를 정상적으로 처리하면 해당하는 항목이 백필 배열에 추가된 것입니다.
- Exchange 2003 ESM의 콘텐츠 동기화 옵션을 사용합니다. 이 옵션은 숨겨져 있지만 매우 유용합니다. 이 옵션을 찾으려면 공용 폴더 트리에서 관련 폴더로 이동하여 왼쪽 창에서 폴더를 강조 표시한 다음 오른쪽 창에서 상태 탭을 클릭합니다. 그런 후에 모든 데이터가 포함된 서버를 마우스 오른쪽 단추로 클릭하고 콘텐츠 동기화를 선택합니다. 그러면 서버에서 폴더에 대해 상태 요청 0x20을 실행하며, 모든 백필 항목의 제한 시간이 즉시 초과됩니다. 여기서 중요한 점은 이미 모든 데이터가 포함되어 있는 서버에서 콘텐츠 동기화를 수행해야 한다는 것입니다. 백필 항목의 제한 시간이 초과되도록 해야 하는 서버는 다른 서버인데 이 서버에서 콘텐츠 동기화를 수행해야 하는 이유가 궁금하실 것입니다. 앞서 언급한 것처럼, 이 시점에서는 데이터가 누락된 서버에서 백필을 수행해야 하는 항목이 있음을 '인식'하고 있는지만 확인합니다. 따라서 모든 데이터를 포함하는 서버에서 콘텐츠 동기화를 사용하여 일부 데이터가 없는 서버로 0x20을 보낼 수 있습니다. 다시 한 번 강조하지만, 이 단계에서는 0x20에 대한 상태 0x10 응답을 확인할 필요가 없으며 콘텐츠가 누락된 저장소에서 해당 콘텐츠를 포함하는 저장소로부터 폴더에 대한 복제 메시지를 받아 백필 배열에 적절한 항목을 추가하도록 하면 됩니다. 데이터가 포함된 서버에서 0x20을 보내면 이 작업을 수행할 수 있습니다. Exchange 2008 SP2부터는 공용 폴더 노드 자체를 마우스 오른쪽 단추로 클릭하면 계층 구조에 대해 콘텐츠 동기화를 사용할 수 있습니다.
- 복제 플래그 레지스트리 값을 사용합니다(KB813629). KB321082에서 설명하는 시작 시 복제 메시지 사용 값과 함께 이 값을 배치한 경우 저장소에서 시작 시 모든 폴더에 대해 상태 요청 0x20을 보냅니다. 이 방법 역시 콘텐츠가 포함된 서버에서 사용합니다. 콘텐츠를 포함하는 서버에서 해당 상태 정보를 콘텐츠가 누락된 서버로 보내도록 하는 것이 이 단계의 목적이기 때문입니다.
- 2003 ESM을 사용하여 백필 응답을 보냅니다. 2003 SP1에서는 계층 구조 보내기(Send Hierarchy) 옵션을 사용하여 계층 구조 백필 응답을 보내고, 콘텐츠 보내기(Send Contents) 옵션을 사용하여 폴더 콘텐츠 백필 응답을 보낼 수 있습니다. 2003 SP2의 경우에는 이 두 옵션이 변경 내용 다시 보내기(Resend Changes)로 통합되었습니다. 이 옵션은 지정된 데이터 범위에 대해 백필 응답을 보내는데, 일반적으로는 전체 데이터 범위를 지정해서는 안 됩니다. 이렇게 하는 경우 모든 대기 백필 항목이 해당 조건을 충족하여 최초 발생했던 문제를 해결해야 할 수 있기 때문입니다. 따라서 범위는 1~2일 정도로만 지정해야 합니다. 그러면 0x80000002 또는 0x80000004가 대상 서버로 배달되며, 대상 서버는 데이터를 포함하는 저장소에 대한 상태 정보를 제공합니다.
이러한 옵션 중 하나를 사용하여 상태 정보를 강제로 확인하고 응용 프로그램 로그를 통해 데이터가 누락된 서버에서 들어오는 메시지를 받았음을 확인하고 나면 해당 서버에서 데이터가 누락되었음을 파악할 수 있습니다.
2. 저장소에서 누락된 데이터를 요청하는지 여부
저장소가 일부 데이터를 백필해야 함을 '인식'한다는 것을 확인한 후에는 저장소에서 백필 요청을 실행하는지 확인해야 합니다. 저장소에서 데이터 백필을 두 번 시도하고 나면 다음 백필 요청까지 24시간 또는 48시간(각각 사이트 내 및 사이트 간 백필의 최대 제한 시간 간격)을 기다려야 합니다. 여기서도 콘텐츠 동기화를 사용하면 이 시간을 단축할 수 있는데, 이번에는 데이터가 누락된 서버에서 콘텐츠 동기화를 수행합니다. 그러면 해당 폴더의 백필 항목 제한 시간이 즉시 초과됩니다. 그러나 저장소에서 해당하는 폴더에 대해 백필 요청을 실행하지 않을 수도 있습니다. 이 경우에는 다음 24~48시간 동안 응용 프로그램 로그를 확인하십시오. 저장소에서 다른 폴더에 대해서는 백필 요청을 보내는데 확인 대상 폴더에 대해서는 보내지 않는 경우 대기 백필 제한에 도달했을 수 있습니다.
여러 폴더의 복제본을 새 저장소에 추가한 후 처음에는 복제가 정상적으로 작동하다가 1~2일 후에 속도가 느려지거나 멈추는 경우에는 대기 백필 제한에 도달한 것일 수 있습니다. 대기 백필 제한은 복제 제한을 위한 메커니즘입니다. 기본적으로 저장소에서는 대기 백필 요청을 한 번에 50개만 허용합니다. 대기 요청이 50개가 되면 요청이 충족될 때까지 해당 50개 요청을 계속해서 다시 요청합니다. 대기 항목 중 하나가 충족되고 나면 OBL에 새 데이터 집합을 요청할 수 있는 슬롯이 열립니다. 즉, 50개 요청을 충족하지 못하면 복제를 진행할 수 없습니다.
이러한 동작이 나타나는 경우에는 응용 프로그램 로그에서 요청을 실행 중인 저장소를 확인해야 합니다. 현재 진행 중인 대기 백필 요청 50개에 대해 주기적으로 0x8 메시지가 표시되는 경우, 해당 요청이 계속 대기 상태인 것은 백필 응답이 수신되지 않았기 때문입니다. 이 경우 저장소에서 현재 백필을 시도하고 있는 폴더 중 하나에서 문제를 해결해야 합니다. 이러한 방식으로 각 폴더의 문제를 차례로 해결할 수 있습니다.
OBL(대기 백필 제한)을 늘리는 옵션도 있습니다. 이렇게 하려면 해당 저장소의 레지스트리 키 아래에 Replication Oustanding Backfill Limit이라는 레지스트리 값을 만들면 됩니다. 최대값은 10진수 5000이지만, 이 값을 지정하면 복제 항목이 가득 차서 제한 초과의 원인이 된 50개 폴더를 확인하기가 어려워지며, 작동이 정상 상태로 돌아갈 때까지 문제 해결을 연기해야 합니다. 일반적으로는 이 제한을 늘려 문제를 해결하는 대신 50으로 유지하고 문제를 해결하는 것이 좋습니다.
OBL에는 문제가 없는 것으로 보이는데 관련 폴더에 대해 나가는 0x8 메시지가 계속 표시되지 않으면 이 시리즈의 마지막 게시물(영문일 수 있음)에서 "일반 문제"를 참조하십시오.
3. 다른 저장소에서 요청에 응답하는지 여부
문제가 되는 백필 요청이 파악되면 백필 대상이 요청을 받았는지를 확인해야 합니다. 이렇게 하려면 해당 서버의 응용 프로그램 로그에서 들어오는 0x8을 확인합니다. 요청을 보내는 서버의 나가는 이벤트에 나와 있는 메시지 ID를 응용 프로그램 로그에서 검색해도 됩니다. 응용 프로그램 로그에서 관련 메시지를 찾을 수 없으면 메시지 추적을 통해 메시지가 어디까지 이동했는지를 확인합니다. 대상이 0x8을 받은 경우 하나 이상의 0x80000002 또는 0x80000004 메시지를 통해 거의 즉시 응답해야 합니다. 변경 내용이 모두 단일 메시지로 발송되는 것은 아니므로, 단일 백필 요청에 대해 여러 백필 응답이 표시되는 경우가 많습니다. 물론 백필 응답 메시지를 생성하는 데 걸리는 시간은 폴더의 데이터 및 복제 메시지 크기 제한에 따라 다릅니다. 예를 들어 최대 복제 메시지 크기를 1GB로 설정하면 응답 서버에서는 전체 계층 구조를 단일 백필 응답으로 압축하려고 시도할 수 있으며, 그러면 압축 과정에만 1시간 이상이 걸릴 수 있습니다.
4. 요청 서버에서 응답을 받는지 여부
다음으로는 요청 서버의 응용 프로그램 로그에서 서버가 백필 응답을 받았는지를 확인합니다. 응답이 수신되지 않았으면 메시지를 추적하여 메시지가 어디까지 이동했는지를 확인합니다. 서버가 백필 응답을 받았으며 응용 프로그램 로그에 응답을 기록한 경우에는 해당 백필 요청이 충족되었으므로 작업을 진행할 수 있습니다.
앞서 설명한 것처럼, 메시지 추적을 통해 이러한 메시지 중 하나가 저장소로 배달되었음이 확인되는데 응용 프로그램 로그에는 들어오는 복제 메시지가 표시되지 않으면 이 시리즈의 마지막 게시물(영문일 수 있음)에서 "일반 문제"를 확인하십시오.
다음 블로그 게시물: 복제본 삭제 문제 및 일반 문제 해결(영문일 수 있음)
이 문서는 번역된 블로그 게시물입니다. 원본 문서는 Public Folder Replication Troubleshooting – Part 2: Troubleshooting the Replication of Existing Data를 참조하십시오.