Exchange 서버 다중 사이트 데이터 복제 배포 지침

 

마지막으로 수정된 항목: 2006-09-01

복제 기술을 사용하면 Microsoft® Exchange Server 데이터의 가용성을 높일 수 있습니다. 이 항목은 복제 저장 기술을 보다 잘 이해하고 해당 기술을 Exchange 서버 환경에서 사용하는 방법을 이해하도록 도와줍니다.

복제를 이용하면 여러 사이트에 중복 데이터를 두어 가용성을 높일 수 있지만, 데이터 손상을 방지하지는 못합니다. 주 저장 장치에 데이터베이스 손상을 일으키는 잘못된 데이터가 기록될 경우 해당 데이터가 원격 사이트에 복제되어 원격 사이트의 데이터베이스를 손상시킵니다. 따라서, 데이터 복제는 데이터베이스 무결성을 정기적으로 확인하는 데이터베이스 백업과 같은 데이터베이스 유지 관리 프로세스를 대체하지 못합니다.

이 항목에서 설명하는 데이터 형식은 Exchange 서비스(예: Exchange 프로세스의 쓰기 I/O 요청)를 실행하여 액세스되는 데이터입니다. 시스템/OS 데이터 복제는 여기서 다루지 않습니다.

Microsoft에는 다양한 복제 솔루션 유형에 대한 지원 정책이 있습니다. 이러한 지원 정책에 대한 자세한 내용은 Microsoft 기술 자료 문서 895847 "Exchange 2003 및 Exchange 2000의 다중 사이트 데이터 복제 기능 지원"을 참조하십시오.

참고

Deployment Guidelines for Microsoft Exchange Server Multi-Site Data Replication을 다운로드하여 인쇄하거나 오프라인 상태에서 읽어 보십시오.

복제 메커니즘

데이터 복제를 사용하는 목적은 원격 사이트에 데이터의 현재 복제본을 유지하기 위한 것입니다. 기본 위치의 저장소 또는 사이트가 중단되는 경우에도 Exchange 서버는 원격 사이트의 복제본을 사용하여 전자 메일 서비스의 연속성을 제공할 수 있습니다. 데이터 복제는 동기 또는 비동기 방식으로 전파될 수 있습니다. 기본적으로 데이터가 동기적으로 복제되는 경우 I/O 쓰기가 로컬 위치와 원격 위치 모두에 커밋되면 호스트는 저장소로부터 쓰기 완료 응답만 받게 됩니다. 즉, 쓰기 완료를 호스트에서 인식하려면 로컬 저장소와 원격 저장소 모두에서 변경을 구현해야 합니다. 비동기 모드에서는 쓰기가 로컬 저장소에 커밋되면 저장소로부터 쓰기 완료 응답을 받게 되므로 원격 저장소로부터 복제본을 업데이트했다는 알림을 기다릴 필요가 없습니다.

비동기 복제

일반적으로 호스트 응용 프로그램은 비동기 복제를 사용할 경우 동기 복제 모드에서처럼 복제 거리에 따른 쓰기 대기 시간 증가에 민감하지 않습니다. 그러나, 비동기 복제를 배포할 경우 다음과 같은 문제에 유의해야 합니다.

  • 데이터 손실   데이터 복제 빈도에 따라 주 사이트의 변경에 대한 원격 사이트의 데이터 변경이 지연될 수 있습니다. 주 사이트가 중단될 경우 원격 사이트 복제본이 최신 상태로 완전하게 유지되지 않습니다. 이 지연을 대부분의 저장소 솔루션에서 구성할 수 있지만 이 동작으로 인한 데이터 손실 가능성에 유의해야 합니다.
  • 데이터 무결성(쓰기 순서 유지)   Exchange에서는 데이터베이스와 관련 트랜잭션 로그 간에 쓰기 순서 종속성이 있습니다. Exchange는 변경 사항을 항상 로그 파일에 먼저 기록한 다음 데이터베이스 파일에 커밋합니다. 동기 복제 모드에서는 응용 프로그램이 쓰기 순서를 제어합니다. 비동기 모드에서는 복제 솔루션이 데이터를 복제할 시간을 제어합니다. 솔루션이 복제 중에 쓰기 순서를 유지하지 않으면 주 사이트에서 재해가 발생할 경우 데이터베이스가 손상되어 데이터베이스가 탑재되지 않을 수 있습니다.
  • 성능 영향   많은 공급업체는 자사의 비동기 솔루션이 저장소 성능에 영향을 주지 않는다고 주장하지만, 실제로는 비동기 복제를 실행할 경우 성능 감소가 나타납니다. 솔루션의 구현에 따라 성능 기대치를 단일 숫자로 나타낼 수는 없습니다. 따라서, 고객은 배포 이전에 솔루션을 테스트하여 해당 솔루션이 Exchange 사용자에게 적절한 저장소 성능을 제공할 수 있는지 확인해야 합니다.

쓰기 순서 유지 문제를 해결하기 위해 다양한 기술을 사용하는 솔루션 공급자도 있습니다. 비동기적으로 복제된 솔루션을 성공적으로 배포하려면 공급업체와 협력하여 공급업체의 비동기 기술이 다음 요구 사항을 충족하는지 확인해야 합니다.

  • 서로 간의 지속적인 일치를 포함하여 저장소 그룹에 있는 모든 장치의 쓰기 순서 일관성을 유지할 수 있습니다.
  • 랩 환경과 프로덕션 환경 모두에서 복구 가능한 것으로 확인되었습니다.
  • 공급업체에서 복제된 데이터에 대한 적절한 지원 계획을 제공하고 있습니다.

동기 복제

Exchange 배포에서 동기 복제에 대한 주요 관심은 성능과 관련이 있습니다. 테스트를 통해 클라이언트의 환경이 쓰기 대기 시간과 밀접한 관련이 있음을 확인했습니다. 동기 복제 솔루션을 사용하면 Exchange 서버별로 호스팅될 수 있는 사서함의 수가 감소됩니다. 성능 영향은 대체적으로 복제 거리, 복제 연결 대역폭 및 사용률에 따라 다릅니다. 동기 복제의 경우 사서함/서버 확장성의 75%가 감소될 수 있습니다. Exchange 용량 계획 방법을 진행 중인 경우 이 확장성 감소 요소를 고려해야 합니다. 자세한 내용은 이 항목 뒷부분의 "동기 복제 배포 계획"을 참조하십시오.

동기 복제에서는 복제본이 주 저장소 데이터 파일과 완벽하게 동기화되기 때문에 동기 복제는 데이터 손실이 없는 솔루션으로 간주됩니다. 그러나, 이러한 일반적인 믿음과 다르게 동기 복제 솔루션에서 데이터 손실이 발생하는 시나리오가 있습니다. 다음 예에서는 그런 시나리오를 보여 줍니다.

일반적으로 저장소 데이터 복제 솔루션은 다음 두 방법 중 하나로 복제 연결 실패를 처리합니다.

  • 쓰기 I/O를 주 저장 장치에만 계속해서 커밋하고, 복제 연결을 사용하는 모든 장치에 대한 모든 변경 사항을 로그 파일에 기록하고, 주 저장소에 로그를 저장합니다.
  • 쓰기 작업이 실패하여 응용 프로그램이 디스크가 실패한 경우처럼 실패를 처리합니다.

복제 솔루션이 첫 번째 처리 방법을 사용하는 경우 데이터 손실이 발생할 수 있습니다. 연결 오류 조건에 이어서 주 사이트 오류가 발생하면 연결 오류 이후에 커밋된 데이터는 복제되지 않기 때문에 주 저장소 실패와 함께 손실됩니다. 저장소 복제 솔루션을 디자인할 경우 이러한 실패 조건에 유의하여 그런 상황이 감소하도록 시스템을 구성하십시오. 이 예에서는 중복 복제 연결 배포를 고려하여 데이터 손실 가능성을 줄일 수 있습니다.

동기 복제 솔루션

동기 복제 솔루션은 복제가 발생하는 위치를 기준으로 분류됩니다(호스트 기반 복제 또는 저장소 기반 복제). 호스트 기반 복제는 일반적으로 호스트 기반 소프트웨어(필터 드라이버)를 통해 I/O 스트림을 중단하여 복제를 관리합니다. 저장소 기반 복제는 호스트 외부에서 저장 장치 수준으로 발생합니다. 두 복제 솔루션 모두 다음 중 일부로 배포될 수 있습니다.

  • 지리적으로 분산된 클러스터링(Geocluster)   이 범주에서는 동일한 클러스터에 속하는 노드가 서로 다른 사이트에 배치됩니다. 일반적으로 Exchange 서버는 주 사이트의 노드에서 능동적으로 호스팅됩니다. 솔루션은 Exchange 데이터의 동기 복제를 원격 사이트에 제공합니다. 주 사이트에 재해가 발생할 경우 Exchange 가상 서버는 원격 사이트의 패시브 노드에 장애 조치되고 복제된 Exchange 데이터를 사용하여 온라인 상태로 전환됩니다.
    Microsoft Windows® Server 카탈로그에는 지리적으로 분산된 클러스터 솔루션에 대한 범주가 있습니다. https://go.microsoft.com/fwlink/?LinkId=28572에서 WHQL(Windows Hardware Qualified Labs) 인증의 지리적으로 분산된 클러스터 솔루션을 검색할 수 있습니다.
  • 기타   이 범주에는 지리적으로 분산된 클러스터링을 사용하지 않는 기타 모든 동기 복제 배포 유형이 포함됩니다. 이러한 솔루션에서는 주 사이트에 오류가 발생할 경우 원격 사이트의 복제된 Exchange 데이터를 몇 가지 다른 방법으로 이용합니다(예: 대기 솔루션, 재해 복구 프로세스와 결합된 복제).

고객에게 다음 문제에 대한 복제 솔루션 공급업체의 보장을 받을 것을 강력히 권장합니다.

  • 솔루션이 지리적으로 분산된 클러스터링 솔루션의 범주에 속합니까? 그럴 경우 WHQL 인증 솔루션입니까? 그런 솔루션이 아닌 경우 Windows Server 카탈로그의 "클러스터 솔루션, 지리적으로 분산된 클러스터링 솔루션" 섹션에 솔루션에 나열된 저장 장치가 요약되어 있습니까?
  • 복제 솔루션은 모든 사이트가 동시에 잠시 중단될 경우 모든 데이터 손실 가능성을 방지합니까?
  • 장애 조치 및 장애 복구를 수행하는 절차는 무엇입니까?
  • 복제 솔루션 및 예상 대기 시간은 계획된 Exchange 사용자 로드를 처리하고 클라이언트 환경을 향상시킬 수 있습니까?

복제할 Exchange 데이터

Exchange는 데이터 중심 서버 응용 프로그램입니다. Exchange 데이터를 보조 사이트에 복제하여 저장소 관련 오류가 발생할 경우에 중복을 제공합니다. 복제할 데이터 종류를 정확하게 결정하는 것은 비즈니스 결정입니다. 여기에 설명된 다양한 데이터 형식에 대한 비즈니스의 손실 허용 오차를 평가해야 합니다.

복제할 필수 데이터

다음 데이터를 복제해야 합니다.

  • Exchange 사서함 데이터베이스 파일은 메시지 데이터를 저장합니다. 각 데이터베이스는 다음 두 파일로 구성됩니다.
    • 데이터베이스 파일(.edb) - 메시지와 MAPI 콘텐츠 보관
    • 스트리밍 파일(.stm) - 비MAPI, 전용 콘텐츠 보관
  • 트랜잭션 로그 파일(.log) - 데이터베이스에 커밋되는 각 트랜잭션 기록
  • 검사점 파일(.chk) - 디스크에 기록된 로그 파일의 항목에 대한 정보 포함

메모리에 저장되고 Exchange 서버 저장소가 완전히 종료되지 않을 경우(예: 정전)에 손실되는 데이터베이스 변경 사항의 소프트 복구 및 사서함 서버에 대한 클라이언트 액세스를 제공하려면 이러한 모든 파일이 필요합니다. 이러한 파일의 중요성 때문에 이 데이터 집합을 복제해야 합니다. 데이터베이스 파일의 경로는 데이터베이스 속성 페이지에서 지정하며 각 데이터베이스에는 자체 경로가 있습니다. 트랜잭션 로그 파일 경로 및 검사점 파일 경로는 저장소 그룹 속성 페이지에서 지정되며 해당 저장소 그룹의 모든 데이터베이스에 따라 다릅니다.

공용 폴더 데이터베이스에 대한 복제 결정은 더 복잡합니다. 공용 폴더 데이터베이스를 복제할지 여부는 해당 배포의 Exchange 토폴로지 디자인에 따라 조금씩 달라집니다. 사서함 데이터와 다르게 공용 폴더 데이터는 Exchange 서버에서 직접 복제할 수 있습니다. 변경 사항(콘텐츠)을 복제하는 공용 폴더 저장소 복제본이 여러 개 있을 수 있습니다. 이 데이터 복제는 동기적인 방식으로는 수행되지 않습니다.

Geocluster 솔루션에서는 클러스터 내의 공용 폴더를 동기적으로 복제해야 합니다. 클러스터가 보조 사이트에서 완벽하게 작동하려면 이 요구 사항이 충족되어야 합니다. 클러스터가 보조 사이트에서 사용할 수 있게 되면 클라이언트가 즉시 로그온할 수 있도록 클러스터 내의 사서함 데이터베이스는 클러스터에 함께 호스트된 공용 폴더 저장소(“기본 공용 저장소”)를 가리켜야 합니다. 오류 상태에서 사서함 로그온이 용이하도록 geocluster 내의 공용 폴더는 계층 구조만 호스팅하면 되고 전체 콘텐츠를 호스팅할 필요는 없습니다. 비즈니스에 따라, 전체 공용 폴더 콘텐츠를 호스팅하고 geocluster 내에 호스팅된 공용 폴더에서 동기적으로 복제할 수 있습니다. 공용 폴더 데이터가 핵심 비즈니스에 필수적이어서 최소의 데이터 손실만 허용되는 경우 Exchange 서버 공용 폴더 복제 메커니즘 대신 geocluster 솔루션을 사용하십시오. 이 수준의 공용 폴더 데이터 가용성이 필요하지 않은 경우 Exchange 공용 폴더에 있는 복제 메커니즘과 결합된 사서함 데이터에 대한 비geocluster 동기 복제 솔루션을 사용할 수 있습니다.

복제할 권장 데이터

SMTP(Simple Mail Transfer Protocol) 로컬 큐 데이터(Mailroot 디렉터리)는 Exchange 서버에서 처리되는 동안 저장 장치에 일시적으로 보관됩니다. 이 디자인은 서버 오류가 발생할 경우에 데이터 손실을 방지합니다. 예를 들어, 대상 서버에 연결할 수 없는 경우 해당 서버에 라우팅될 메시지는 배달이 가능해 질 때까지 로컬 서버 큐 디렉터리에 저장됩니다. 큐 데이터를 저장하는 디스크에 오류가 발생할 경우 큐에 있는 모든 메시지가 손실됩니다. 큐 데이터의 일시적인 특성으로 인해 Exchange 서버 데이터베이스 백업 프로세스처럼 메일 큐 백업 프로세스가 정의되지 않습니다. 이 큐 정보를 보관하는 저장소에 대해 내결함성 및/또는 고가용성 솔루션을 제공하여 잠재적인 데이터 손실을 방지할 수 있습니다. 또한, 사이트 실패로 인해 일시적인 메시지가 손실되지 않는 환경에서 MTA 큐 데이터(MTADATA 디렉터리)를 복제하는 것이 좋습니다.

SMTP Mailroot(가상 서버 인스턴스별 Queue, Badmail 디렉터리 포함)의 경로는 ESM(Exchange System Manager)의 SMTP Virtual Server 속성 페이지의 메시지 탭 및 MTA 큐 경로에 대한 X.400 속성 페이지에서 지정합니다. 프로필을 조사하여 Exchange 큐 데이터를 복제해야 하는지 여부를 결정해야 합니다. 기존 Exchange 토폴로지가 있는 경우 로컬 큐에서 데이터 손실이 허용되는지 여부를 결정할 수 있습니다. 로드가 가장 많은 기간 동안 성능 모니터(Perfmon.msc) 또는 ESM의 큐 뷰어에서 로컬 큐 길이를 사용하여 로컬 큐의 예상 데이터 양을 측정할 수 있습니다. 큐 데이터에 대한 복제가 필요한 경우 복제 대기 시간으로 인해 전송 지체가 발생하지 않도록 복제 환경에서 메시지 처리 성능을 테스트해야 합니다. 큐 데이터가 복제되는 동기 복제 환경에서 ESP(Exchange Server Stress and Performance) 2003 도구를 사용하여 전송 처리량을 테스트할 수 있습니다. 이 도구는 Exchange Server Stress and Performance 2003 웹 사이트에서 다운로드할 수 있습니다.

복제할 선택적 데이터

메시지 추적 로그에는 Exchange 서버에서 주고 받는 모든 메시지 및 Exchange 서버 내의 모든 메시지에 대한 정보가 포함되어 있습니다. 이 데이터는 진단을 위해 중요할 수 있습니다. 기본적으로 메시지 추적은 사용할 수 없습니다. 그러나, 이 데이터가 비즈니스에 중요한 경우 복제하여 재해가 발생할 경우에 손실을 방지할 수 있습니다. 메시지 추적 로그의 경로는 ESM의 Exchange 서버 속성 페이지에서 지정합니다.

복제 메커니즘 구성을 위한 최적의 방법

각 공급업체는 서로 다른 복제 옵션을 제공하는 다양한 전용 복제 메커니즘 구현을 보유하고 있습니다. 특정 공급업체와 솔루션에 대해 자세히 논의하여 해당 공급업체에서 제안하는 솔루션이 조직의 요구 사항과 재해 복구를 위한 서비스 수준 계약(SLA)에 가장 적합한지를 확인해야 합니다. 다음 권장 사항은 특정 복제 솔루션에만 적용될 수 있습니다.

참고

“복제 지점”이라는 용어는 복제가 발생하는 위치로 정의됩니다. 솔루션에 따라 이 위치는 호스트 필터 드라이버 수준이거나 저장소 배열 내의 디스크 조각일 수 있습니다.

  • 논리/탑재 지점 볼륨 수준으로 복제를 구성합니다.
    복제해야 하는 데이터가 이 항목의 "복제할 Exchange 데이터" 섹션에서 설명한 파일에 보관되더라도 호스트 수준에서 논리/탑재 지점 볼륨 단위에 대한 복제가 구성되는지 확인해야 합니다. 예를 들어, 사서함 데이터 경로가 G:\MDB1\MDB1.EDB인 경우 드라이브 G가 복제 수행을 위한 기본 단위여야 합니다. 따라서 드라이브 G의 모든 데이터가 복제됩니다. 파일 또는 하위 디렉터리 수준에서 복제가 발생하도록 설정하면 실수로 인한 오류가 발생하기 쉬우므로 이 방법은 Microsoft에서 지원하지 않습니다.
  • 많은 복제 지점을 만듭니다.
    동일한 복제 지점을 대상으로 하는 여러 I/O의 큐를 줄이려면 복제 지점을 가능한 많이 만들도록 저장소를 구성합니다. 많은 복제 지점을 통해 I/O 부하를 분산합니다. 저장소/복제 솔루션에 따라 이 방법은 I/O 큐 감소로 인해 전체 I/O 읽기/쓰기 대기 시간을 줄일 수 있습니다.
  • 트랜잭션 로그를 다른 논리 볼륨에 보관합니다.
    데이터를 복제하는 동안 각 쓰기 I/O 요청은 복제 지점 수준에서 대기합니다. Exchange는 로그를 순차적으로 기록하므로 이러한 I/O가 동일한 복제 지점을 대상으로 할 경우 모든 I/O가 쓰기를 위해 대기할 가능성이 커집니다. 그럴 경우 로그 쓰기 응답 시간이 더 길어져서 Exchange 성능/확장성에 부정적인 영향을 미칠 수 있습니다. 따라서 저장소 그룹별로 트랜잭션 로그를 분할하여 다른 복제 지점을 가진 다른 논리 볼륨에 기록하는 것이 좋습니다.
  • 여러 복제 연결을 사용합니다.
    주 사이트와 보조 사이트 사이에 여러 복제 연결을 구성하여 복제 솔루션의 성능/확장성을 흔히 향상시킬 수 있습니다. 이 방법은 구현 비용이 많이 들며 Exchange 데이터 복제에는 필요하지 않습니다. 그러나, 주어진 Exchange 데이터 복제 솔루션에 대해 원하는 성능/확장성을 달성하기 위해 여러 복제 연결을 구현해야 하는 배포가 있습니다. 또한, 복제를 최적의 속도로 처리하도록 사용 가능한 복제 연결을 통해 복제 지점의 부하를 분산해야 할 수 있습니다.
    Exchange에는 데이터베이스와 해당 트랜잭션 로그 간에 쓰기 순서 종속성이 존재하므로 저장소 그룹 논리 볼륨(데이터베이스 LUN(Logical Unit Number) 및 로그 LUN 포함)에서 동일한 복제 연결을 사용하도록 지원하는 복제 지점 그룹을 구성해야 합니다. 이 구성은 저장소 그룹 수준에서 쓰기 순서를 유지하는 데 필요하며, 연결 실패와 같은 실패 시나리오가 발생할 경우에 원격 사이트에서 데이터 무결성을 관리하는 데 필수적입니다.
    여러 복제 지점과 함께 여러 복제 연결을 사용하면 Exchange 데이터 복제 솔루션을 효율적으로 확장할 수 있습니다. 또한, 이 방법은 이전 섹션 "동기 복제"의 예에서 설명한 데이터 손실의 가능성을 줄일 수 있습니다.

동기 복제에 대한 Exchange 구성을 위한 최적의 방법

Exchange를 동기 복제 환경에서 배포할 경우 몇 가지 구성을 변경하여 서버 성능/확장성을 향상시킬 수 있습니다. 저장소 및 복제 디자인 과정에서 구현할 수 있도록 계획 단계에서 이러한 변경 사항을 이해해야 합니다. 구성을 위한 최적의 방법은 다음과 같습니다.

  • Exchange 서버별로 최대 수의 저장소 그룹을 만듭니다.
    동기적으로 복제된 Exchange 솔루션의 저장소 그룹 수를 늘리면 여러 논리 볼륨과 여러 복제 지점을 통해 로그 쓰기 트랜잭션의 부하를 분산하여 배포 성능/확장성을 향상시킬 수 있습니다. 일반적으로 동기 복제 환경에서 전체 트랜잭션 로그 쓰기 대기 시간을 줄일 수 있는(I/O 대기 시간 감소) 많은 병렬 로그 쓰기 프로세스가 있습니다. Exchange Server 2003 Enterprise Edition에서는 Exchange 서버별로 네 개의 저장소 그룹이 허용됩니다.
  • 트랜잭션 로그 버퍼 크기를 늘립니다.
    Exchange 로그 쓰기 I/O 대기 시간은 동기 복제 Exchange 솔루션의 중요한 확장성 요소입니다. 로그 쓰기 I/O는 순차적이고 단일 스레드로 실행되므로 로그 I/O의 대기 시간으로 인해 시스템이 지체될 수 있습니다. 로그 I/O가 로그 버퍼에 먼저 기록된 이후에 비지연 커밋 또는 용량 커밋에서 버퍼를 지웁니다. 비지연 커밋에서는 로그 버퍼가 디스크에 즉시 기록됩니다. 용량 커밋에서는 버퍼가 꽉 찰 경우 로그 버퍼가 디스크에 기록됩니다.
    로그 버퍼 크기를 늘리면 용량 플러시 빈도가 감소하고, 로그 쓰기 크기가 증가하여 전체 로그 쓰기 대기 시간이 감소됩니다. 로그 I/O 쓰기 대기 시간을 줄이면 Exchange 배포의 성능/확장성을 크게 향상시킬 수 있습니다.
    일반적으로 복제가 파이버 채널을 통해 수행될 경우 버퍼 크기를 최대값 9,000으로 늘리는 것이 좋습니다. TCP/IP 연결처럼 낮은 대역폭 연결에서는 이 매개 변수의 최적 값을 결정하기가 어렵습니다. 연결의 향상된 로그 쓰기 크기가 꽉 차서 복제가 느려질 경우 광범위한 테스트를 통해 로그 쓰기 대기 시간을 최소화하는 최적의 로그 버퍼 크기를 결정해야 합니다. 이 매개 변수를 수정하는 방법은 기술 자료 문서 328466 "ESE log buffers that are set too low can cause the Microsoft Exchange Information Store service to stop responding"을 참조하십시오. 또한, 솔루션 공급자에게 이 설정에 대해 문의하십시오.

동기 복제를 위한 배포 계획

동기 복제 저장소 솔루션이 이전 권장 사항을 모두 충족하더라도 배포하기 전에 솔루션을 철저하게 테스트하지 않을 경우 Exchange 클라이언트에 대한 성능 문제가 발생할 수 있습니다. Exchange에서 동기 복제를 구현할 때 확장성/성능에 미치는 부정적인 효과에 대한 명확한 규칙은 없습니다. 각 Exchange 복제 솔루션은 사이트 간의 거리, 복제 전송 메커니즘, 복제 연결 수, 복제 지점 수, Exchange 저장소 그룹 수, Exchange 데이터베이스/로그 구성 설정, 저장소 및 복제 아키텍처, Exchange 클라이언트 프로필 등 다양한 성능 요소를 포함할 수 있지만 이에 제한되지 않습니다. 각 솔루션은 고유하며 성공적인 배포를 위해 광범위한 계획을 수립하고 테스트해야 합니다.

동기 복제 솔루션에 기인하는 I/O 쓰기 대기 시간은 Exchange 확장성을 제한하는 주요한 요소입니다. 이렇게 I/O 대기 시간이 길어지면 Exchange 클라이언트 환경에 심각한 영향을 주는 로드가 서버에 생깁니다. 특히 높은 쓰기 대기 시간은 RPC 대기 시간을 늘려 클라이언트 환경이 느려지게 합니다. 동기 복제는 Exchange 데이터의 가용성을 향상시키는 동시에 중요한 I/O 성능 벌점을 초래합니다. 이 I/O 쓰기(경우에 따라 읽기) 벌점은 주어진 플랫폼에서 지원되는 사용자 수를 결정하는 데 중요한 요소입니다.

계획 단계에서 다음 단계를 수행하여 디자인을 확인하십시오.

  1. Exchange 2003의 저장소 최적화를 참조하여 Exchange를 위한 저장소를 디자인 및 구현하는 최적의 방법을 이해합니다.
  2. Jetstress 테스트를 사용하여 동기 복제를 구성한 상태에서 저장소의 원시 처리량을 확인합니다. Jetstress 도구를 다운로드하려면 Microsoft Exchange Server Jetstress 도구 웹 사이트를 참조하십시오.
  3. 사용자 환경에 맞게 조정된 Exchange Server Load Simulator 2003(LoadSim) 테스트를 실행하여 쓰기 대기 시간 증가가 전자 메일 클라이언트에 미치는 영향을 측정합니다. LoadSim을 다운로드하려면 Microsoft Exchange Server 2003 Load Simulator(LoadSim) 웹 사이트를 참조하십시오.
  4. LoadSim을 실행할 때의 평균 디스크 처리량을 측정합니다. 디스크 처리량은 시뮬레이트하는 프로덕션 환경(IOPS/사서함)의 예상 최고 평균 처리량보다 크거나 같아야 합니다. 최고 평균 디스크 처리량을 측정하는 방법은 Exchange 2003의 저장소 최적화를 참조하십시오.
  5. LoadSim 테스트를 실행한 후 서버의 RPC 평균 대기 시간 카운터와 클라이언트 응답 시간을 자세히 살펴보십시오. 테스트 결과를 분석할 때 세 카운터 모두가 아래에 나열된 기준을 충족해야 함에 유의하십시오.
    RPC 평균 대기 시간
    이 카운터에는 단일 RPC(Remote Procedure Call) 요청을 처리하는 데 필요한 평균 시간이 표시됩니다. 사용자 로드 또는 복제 거리를 늘리면 RPC 평균 대기 시간이 늘어납니다. 평균에 대한 최대 제한은 50ms이고 최대값은 100ms입니다. 테스트 결과에서 평균이 50ms를 초과할 경우 전체 클라이언트 환경이 느려질 것입니다. 평균이 50ms보다 작지만 스파이크가 100ms를 초과하는 경우 스파이크 시간 동안 클라이언트 환경이 느려집니다.
    디스크 대기 시간 카운터
    Microsoft Exchange 제품 팀이 여러 하드웨어 동기 복제 솔루션을 테스트하여, RPC 평균 대기 시간과 디스크 대기 시간 사이에 연관이 있음을 확인했습니다. 일반적으로 솔루션은 데이터베이스 읽기 대기 시간 평균이 20ms 미만이고 로그 읽기 및 쓰기 대기 시간 평균이 20ms 미만인 경우 주어진 로드를 처리할 수 있습니다. 이러한 대기 시간의 최대값은 40ms 미만으로 유지되어야 합니다. 이 임계값을 초과할 경우 클라이언트 환경의 응답 속도가 느려집니다.
    클라이언트 응답 시간
    모든 클라이언트 시스템에서 lslog.exe를 실행하여 전체 클라이언트 환경을 확인할 수 있습니다. 이 작업은 95번째 백분위수의 가중 평균을 반환하며, 값은 1,000ms 미만이어야 합니다. lslog.exe는 LoadSim 도구의 일부입니다. LoadSim 설명서에서는 Islog.exe를 사용하는 방법과 제공되는 결과를 해석하는 방법을 설명합니다.
    성능에 대한 자세한 내용은 Exchange Server 2003 성능 문제 해결을 참조하십시오.
  6. 계획된 복제 거리에 대해 사서함 프로필에 대한 솔루션을 테스트합니다. 복제 연결 거리는 물리적인 제한이 있습니다. 거리가 늘어나면 거리 간의 동기 복제에 의해 쓰기 대기 시간이 증가하여 클라이언트/서버 응답 시간이 느려집니다. 일반적으로 Exchange 서버 데이터의 동기 저장소 복제 임계값은 100Km로 간주됩니다. 이 임계값은 솔루션 구현에 따라 다를 수 있습니다.
  7. 데이터베이스 무결성을 정기적으로 확인하는 백업 계획을 수립합니다. 복제는 백업 프로세스를 대체하지 않습니다.
  8. 솔루션의 복제 성능처럼 철저하게 테스트하여 포괄적인 재해 복구 계획을 수립해야 합니다. Exchange 데이터, 서버 및 사이트를 복구하는 다양한 방법이 있습니다. 비즈니스 요구 사항을 충족하는 재해 복구 계획을 구현하고 재해가 발생할 경우에 신속하고 효율적인 복구 단계를 안내해 줄 서비스 수준 계약을 체결해야 합니다. 로드가 과도한 조건에서 동기 복제를 사용하여 Exchange 배포의 다양한 오류 조건을 시뮬레이트하여 계획을 테스트하고 확인합니다.