고가용성 및 사이트 복구 이해

  • 아티클

 

적용 대상: Exchange Server 2010 SP2, Exchange Server 2010 SP3

마지막으로 수정된 항목: 2016-11-28

사서함 데이터베이스 및 포함된 데이터는 모든 Exchange 조직의 중요한 구성 요소 중 하나입니다(가장 중요한 구성 요소일 것임). Microsoft Exchange Server 2010에서는 고가용성 및 사이트 복구에 맞게 사서함 데이터베이스를 구성하여 사서함 데이터베이스 및 포함된 데이터를 보호할 수 있습니다. Exchange 2010은 높은 수준의 종단 간 가용성을 제공하고 대규모 사서함을 지원하는 동시에 고가용성 및 사이트 복구 메시징 솔루션을 배포하는 비용과 복잡성을 줄여줍니다. Exchange Server 2007에 도입했던 고유의 복제 기능을 기반으로 하는 Exchange 2010의 새로운 고가용성 아키텍처는 고가용성과 사이트 복구를 위한 간소화된 통합 프레임워크를 제공합니다. Exchange 2010은 Exchange의 핵심 아키텍처에 고가용성을 통합하여, 기업 규모와 업종에 상관없이 고객이 경제적으로 메시징 서비스를 조직에 배포할 수 있게 해줍니다.

고가용성 및 사이트 복구와 관련된 관리 작업에 대한 자세한 내용은 고가용성 및 사이트 복구 관리를 참조하십시오.

목차

주요 용어

Exchange Server 2010 솔루션의 주요 특징

데이터베이스 이동성

증분 배포

데이터베이스 가용성 그룹

사서함 데이터베이스 복사본

Active Manager

이전 버전 Exchange의 고가용성에서 변경된 사항

비사서함 서버 역할의 고가용성

사이트 복구

종단 간 가용성

주요 용어

다음과 같은 용어가 적용됩니다.

  • 주소록 서비스
    Microsoft Outlook 클라이언트의 디렉터리 액세스 끝점을 제공하는 클라이언트 액세스 서버의 서비스입니다.
  • 연속 복제 - 블록 모드
    각 업데이트가 활성 데이터베이스 복사본의 활성 로그 버퍼에 작성되는 SP1에서 새로운 형태의 연속 복제이며, 각 수동 사서함 복사본의 로그 버퍼로도 전달됩니다. 로그 버퍼가 꽉 차면 각 데이터베이스 복사본이 다음 로그 파일을 작성 및 검사하며 생성 시퀀스에 만듭니다.
  • 연속 복제 - 파일 모드
    닫힌 트랜잭션 로그 파일을 활성 데이터베이스 복사본에서 하나 이상의 수동 데이터베이스 복사본으로 전달하는 Exchange 2010의 RTM(release to manufacturing) 버전에 있는 원래 형태의 연속 복제의 이름입니다.
  • DAG(데이터베이스 가용성 그룹)
    복제된 데이터베이스 집합을 호스트하는 최대 16개 Exchange 2010 사서함 서버의 그룹입니다.
  • 데이터베이스 이동성
    단일 Exchange 2010 사서함 데이터베이스를 다른 Exchange 2010 사서함 서버에 복제 및 탑재하는 기능입니다.
  • 재해 복구
    수동으로 오류를 복구하는 데 사용되는 모든 프로세스입니다. 단일 항목에 영향을 주는 오류 또는 전체 물리적 위치에 영향을 주는 오류일 수 있습니다.
  • Exchange 타사 복제 API
    연속 복제 대신에 타사 동기 복제를 데이터베이스 가용성 그룹에 사용할 수 있게 하는 Exchange 제공 API입니다.
  • 고가용성
    서비스 가용성, 데이터 가용성 및 서비스나 데이터에 영향을 주는 오류(예: 네트워크, 저장소 또는 서버 오류)로부터의 자동 복구를 제공하는 솔루션입니다.
  • 증분 배포
    Exchange 2010이 설치된 후 고가용성 및 사이트 복구를 배포하는 기능입니다.
  • 지연된 사서함 데이터베이스 복사본
    0보다 큰 로그 재생 지연 시간을 가진 수동 사서함 데이터베이스 복사본입니다.
  • 사서함 데이터베이스 복사본
    활성 또는 수동인 사서함 데이터베이스(.edb 파일 및 로그)입니다.
  • 사서함 복구
    Exchange 2010에 있는 통합된 고가용성 및 사이트 복구 솔루션의 이름입니다.
  • RPC 클라이언트 액세스 서비스
    Microsoft Outlook 클라이언트의 MAPI 끝점을 제공하는 클라이언트 액세스 서버의 서비스입니다.
  • 사이트 복구
    기본 데이터 센터에서 더 이상 조직의 요구를 충족하기에 충분한 수준의 서비스를 제공할 수 없을 때 대체 또는 대기 데이터 센터를 활성화하는 데 사용되는 수동 재해 복구 프로세스입니다. 또한 복구, 복원 또는 다시 만들어진 기본 데이터 센터를 다시 활성화하는 프로세스도 포함합니다. Exchange 2010의 기본 제공 기능을 사용하여 고가용성에 맞게 메시징 솔루션을 구성하고 사이트 복구를 사용하도록 설정할 수 있습니다.
  • 섀도 중복성
    전송 중인 전체 시간 동안 메시지에 중복성을 제공하는 전송 서버 기능입니다.
  • *over("스타 오버"로 발음됨)
    전환 및 장애 조치의 약어입니다. 전환은 하나 이상의 데이터베이스 복사본에 대한 수동 활성화입니다. 장애 조치는 오류 후 하나 이상의 데이터베이스 복사본에 대한 자동 활성화입니다.

맨 위로 이동

Exchange Server 2010 솔루션의 주요 특징

Exchange 2007에서는 CCR(클러스터 연속 복제) 및 SCR(대기 연속 복제) 등의 기술을 도입하여 고가용성 구현 비용을 절감하고 사이트 복구 또한 훨씬 경제적으로 수행할 수 있었습니다. 하지만 해결해야 할 과제가 여전히 남아 있습니다.

  • Windows 장애 조치 클러스터링은 그 복잡성 때문에 혼란스러울 수 있습니다.

  • 작동 시간을 높은 수준으로 유지하려면 상당한 수준의 관리자 개입이 필요합니다.

  • 연속 복제의 각 유형이 개별적으로 다르게 관리되었습니다.

  • 대규모 사서함 서버의 단일 데이터베이스에서 오류를 복구하면 해당 사서함 서버의 모든 사용자가 일시적인 서비스 중단을 겪을 수 있습니다.

  • 허브 전송 서버의 전송 쓰레기 수거통 기능은 CCR 환경의 사서함으로 가는 메시지만 보호할 수 있습니다. 메시지를 처리하는 동안 허브 전송 서버에 오류가 발생하여 이를 복구할 수 없는 경우 데이터가 손실됩니다.

Exchange 2010의 큰 변화 중 한 가지는 고가용성이 아키텍처에 깊이 통합되어 있다는 것입니다. 이로 인해 이전 버전의 Exchange에 비해 쉽게, 또 비용 효율적으로 배포 및 유지 관리가 가능합니다. Exchange 2010에는 고가용성 및 사이트 복구 둘 다를 위한 새로운 통합 플랫폼이 포함되어 있습니다.

Exchange 2010의 향상된 주요 기능으로 연속 복제 시에 권장되는 최대 사서함 데이터베이스 크기는 Exchange 2007의 200GB에서 Exchange 2010의 2TB로 증가했습니다. 점점 더 많은 기업에서 대규모 사서함(2GB에서 10GB까지)의 중요성을 인식함에 따라 데이터베이스 크기는 빠른 속도로 증가하고 있습니다. 대용량 데이터베이스를 지원하려면 백업 및 복원과 같은 레거시 복구 메커니즘에서 벗어나서 데이터 복제 및 서버 중복성과 같은 더 빠르고 새로운 형태로 보호를 적용해야 합니다. 궁극적으로, 사서함 데이터베이스의 크기는 Exchange 2010 계획 프로세스 동안 파생되는 여러 요소에 따라 달라집니다. 사서함 및 사서함 서버에 대한 자세한 계획 지침은 사서함 서버 저장소 디자인를 참조하십시오.

Exchange 2010은 CCR 및 SCR의 핵심 복구 기능과 가용성을 단일 솔루션에 통합하여 온사이트 데이터 복제와 오프사이트 데이터 복제를 모두 처리합니다. 사서함 서버는 서버 수준 대신 사서함 데이터베이스 수준에서 자동 복구를 제공하기 위해 DAG의 일원으로 정의될 수 있습니다. Exchange 2010에는 데이터베이스 이동성 및 증분 배포 등, 다른 새로운 고가용성 개념이 도입되었습니다.

맨 위로 이동

데이터베이스 이동성

Exchange 2007에서는 Exchange에 대한 고가용성 및 사이트 복구 솔루션 배포를 보다 신속하고 간편하게 하기 위해 디자인된 새로운 아키텍처 변경을 많이 도입했습니다. 이로써 통합된 설치 프로그램, 최적화된 구성 설정, 고유의 Exchange 관리 도구를 사용한 고가용성 솔루션 관리 능력 등이 개선되었습니다.

그러나 여전히 Exchange 2007 고가용성 솔루션을 관리하기 위해 네트워크 ID 이동 및 클러스터 리소스 관리 개념 등, 복잡한 클러스터링 개념을 숙지해야 하고, 클러스터된 사서함 서버와 관련된 문제를 해결할 때는 Exchange 도구 및 클러스터 도구를 사용하여 서로 다른 두 개의 소스인 Exchange와 클러스터에서 로그와 이벤트를 검토하고 상관시켜야 했습니다.

이 외에 Exchange 2007 아키텍처의 다른 제한적인 두 가지 측면도 고객 의견을 바탕으로 평가 및 수정되었습니다.

  • 클러스터된 Exchange 2007 서버는 전용 하드웨어를 필요로 합니다. 사서함 서버 역할만 클러스터의 노드에 설치할 수 있습니다. 이는 배포의 기본 구성 요소인 핵심 서버 역할(사서함, 허브 전송, 클라이언트 액세스)의 완전한 중복을 위해서는 최소 네 개의 Exchange 서버가 필요하다는 의미입니다.

  • Exchange 2007에서 클러스터된 사서함 서버의 장애 조치는 서버 수준에서 수행됩니다. 따라서, 단일 데이터베이스에서 오류가 발생하면 관리자는 클러스터된 사서함 서버 전체를 해당 클러스터의 다른 노드로 장애 조치하거나(이는 오류 데이터베이스에 사서함을 가진 사용자뿐 아니라 서버의 모든 사용자에 대한 서비스 중단을 의미), 백업에서 데이터베이스를 복원하는 동안 오류 데이터베이스의 사용자를 수시간 동안 오프라인 상태로 두어야 했습니다.

Exchange 2010은 데이터베이스 이동성의 개념을 염두에 두고 설계되었습니다. 데이터베이스 이동성은 데이터베이스를 함께 그룹화된 여러 개의 다른 서버로 복제하여 시스템의 연속 복제 사용을 확장하며, 이로써 데이터베이스의 보호 및 가용성이 향상됩니다. 이 모델에서 자동 장애 조치 보호 및 수동 전환 제어는 서버 수준 대신에 사서함 데이터베이스 수준에서 제공됩니다.

오류가 발생할 경우 데이터베이스의 복사본을 가진 다른 서버가 데이터베이스를 탑재할 수 있습니다. 이 기능과 더불어 기타 아키텍처 변경의 결과로, 이제 이전 버전의 Exchange에 비해 훨씬 빨리 장애 조치 작업이 완료됩니다. 예를 들어 Exchange 2007 서비스 팩 1을 실행 중인 CCR 환경에서 클러스터된 사서함 서버의 장애 조치는 약 2분이 소요됩니다(클러스터된 사서함 서버의 IP 주소가 변경되지 않는 사이트 내 오류가 있다고 가정). 이에 반해 Exchange 2010 환경에서 사서함 데이터베이스의 장애 조치는 30초 이내에 완료됩니다(오류가 감지된 순간부터 데이터베이스 복사본이 탑재될 때까지의 시간을 측정했으며, 로그 재생으로 정상 상태의 최신 복사본이 있다고 가정). 이 같은 데이터베이스 수준 장애 조치와 장애 조치 시간의 단축으로 조직의 전체 가동 시간이 향상됩니다.

맨 위로 이동

증분 배포

Exchange 2010에서는 증분 배포 개념을 도입하여, Exchange가 설치된 후 모든 사서함 서버와 데이터베이스에 대한 서비스 및 데이터 가용성을 배포할 수 있습니다. 서비스 및 데이터 중복성은 DAG 및 데이터베이스 복사본 같은 Exchange 2010의 새 기능을 사용하여 확보됩니다.

이전 버전의 Exchange에서는 Exchange를 Windows 장애 조치(failover) 클러스터에 배포하여 사서함 서버 역할에 대한 서비스 가용성을 확보했습니다. Exchange를 클러스터에 배포하려면 먼저 장애 조치(failover) 클러스터를 구현한 후 Exchange 프로그램 파일을 설치해야 했습니다. 이 프로세스를 통해 클러스터된 사서함 서버라고 부르는 특수 사서함 서버(또는 이전 버전의 Exchange에서 Exchange 가상 서버)가 만들어졌습니다. Exchange 프로그램 파일을 클러스터된 서버가 아닌 서버에 이미 설치했으면 새 하드웨어를 사용하여 클러스터를 구현하거나, 기본 서버에서 Exchange를 제거하고 장애 조치 클러스터링을 설치한 후 Exchange를 다시 설치해야 했습니다.

맨 위로 이동

데이터베이스 가용성 그룹

DAG는 Exchange 2010에서 기본 제공되는 고가용성 및 사이트 복구의 기본 구성 요소입니다. DAG는 데이터베이스 집합을 호스트하는 최대 16개의 사서함 서버 그룹이며 개별 데이터베이스에 영향을 준 오류로부터 데이터베이스 수준의 자동 복구를 수행합니다. DAG의 서버는 DAG의 다른 서버로부터 사서함 데이터베이스의 복사본을 호스트할 수 있습니다. 서버를 DAG에 추가하면 DAG의 다른 서버와 함께, 사서함 데이터베이스에 영향을 준 오류(예: 디스크 오류 또는 서버 오류)로부터 자동 복구를 수행합니다.

Exchange 2007에서는 연속 복제라는 기본 제공 데이터 복제 기술을 도입했습니다. 연속 복제는 로컬, 클러스터 및 대기, 이 세 가지 형식으로 사용할 수 있으며 고가용성 Exchange 인프라를 배포하는 비용을 크게 줄여주고 이전 버전의 Exchange에 비해 훨씬 더 향상된 배포 및 관리 경험을 제공합니다. 그러나 이러한 비용 절감 및 기능 향상에도 불구하고 고가용성 Exchange 2007 인프라를 실행하려면 많은 시간과 전문 지식이 필요한데 이는 Exchange 및 Windows 장애 조치 클러스터링 간의 통합이 완벽하지 않았기 때문입니다. 또한 고객은 사이트 수준 재해에서 Exchange 환경을 보호하기 위해 전자 메일 데이터를 원격 위치에 복제하는 더 쉬운 방법을 원했습니다.

Exchange 2010은 Exchange 2007에 있는 것과 동일한 연속 복제 기술을 사용합니다. Exchange 2010에서는 온사이트 데이터 복제(CCR) 및 오프사이트 데이터 복제(SCR)가 *DAG(데이터베이스 가용성 그룹)*라는 단일 프레임워크로 결합됩니다. 서버가 DAG에 추가된 후 복제된 데이터베이스 복사본을 총 16개까지 점증적으로 추가할 수 있으며 Exchange 2010은 가용성을 유지 관리하기 위해 이러한 복사본 간에 자동으로 전환됩니다.

클러스터된 사서함 서버에 전용 하드웨어가 필요했던 Exchange 2007의 경우와 달리 DAG의 사서함 서버는 다른 Exchange 역할(클라이언트 액세스, 허브 전송 및 통합 메시징)을 호스트할 수 있으므로 단지 두 개의 서버로 Exchange 서비스 및 데이터의 완전한 중복성을 제공합니다.

또한 새로운 이 고가용성 아키텍처는 다양한 오류(디스크 수준, 서버 수준 및 데이터 센터 수준)로부터의 단순화된 복구를 제공하며 다양한 저장소 유형에 아키텍처를 배포할 수 있습니다.

DAG에 대한 자세한 내용은 데이터베이스 가용성 그룹 이해를 참조하십시오.

맨 위로 이동

사서함 데이터베이스 복사본

Exchange 2007에 먼저 도입된 고가용성 및 사이트 복구 기능은 Exchange 2010에서 데이터베이스 복사본을 만들고 유지 관리하는 데 사용되며, 이를 통해 Exchange 2010의 가용성 목표를 달성할 수 있습니다. 또한 Exchange 2010에는 Exchange가 관리하는 데이터베이스 수준 장애 조치인 데이터베이스 이동성의 개념이 도입되었습니다.

데이터베이스 이동성은 서버에서 데이터베이스를 분리하고, 단일 데이터베이스의 복사본을 최대 16개까지 지원하며, 데이터베이스에 데이터베이스 복사본을 추가합니다. Exchange 2007에서 데이터베이스 이식성이라 불렀던 기능 또한 서버 간에 사서함 데이터베이스를 이동할 수 있게 해줍니다. 데이터베이스 이식성과 데이터베이스 이동성의 주된 차이점은 데이터베이스의 모든 복사본이 같은 GUID를 갖는다는 것입니다.

데이터베이스 복사본을 활성 사서함 데이터베이스로 설정하는 것을 전환이라고 합니다. 데이터베이스에 영향을 주는 오류가 발생하고 새 데이터베이스가 활성 복사본이 될 경우 이 프로세스를 장애 조치라고 합니다. 또한 이 프로세스는 실패한 서버에서 이전에 온라인 상태였던 데이터베이스를 하나 이상의 서버에서 온라인 상태로 만드는 서버 오류라고도 합니다. 전환 또는 장애 조치가 발생할 경우 다른 Exchange 2010 서버 역할은 전환을 거의 즉시 인식하고 클라이언트 및 메시징 트래픽을 새 활성 데이터베이스에 리디렉션합니다.

예를 들어 기본 저장소 오류로 인해 DAG의 활성 데이터베이스가 실패할 경우 Active Manager는 DAG에 있는 다른 사서함 서버의 데이터베이스 복사본으로 장애 조치하여 자동으로 복구합니다. 데이터베이스가 자동 탑재 기준 외부에 있어 자동으로 탑재할 수 없는 경우 데이터베이스 장애 조치를 수동으로 수행할 수 있습니다.

사서함 데이터베이스 복사본에 대한 자세한 내용은 사서함 데이터베이스 복사본 이해를 참조하십시오.

맨 위로 이동

Active Manager

Exchange 2007 및 이전 버전에서 Exchange는 클러스터 리소스 관리 모델을 사용하여 사서함 서버 고가용성 솔루션을 설치, 구현 및 관리했습니다. 과거에는 고가용성 사서함 서버를 작성할 때 먼저 Windows 장애 조치 클러스터를 작성한 다음 클러스터된 모드에서 Exchange 설치를 실행했습니다. 이 모드에서 Exchange 클러스터 리소스 DLL 파일인 exres.dll이 등록되고 클러스터된 사서함 서버(레거시 버전에서 Exchange 가상 서버라도 함)를 작성할 수 있게 됩니다. 레거시 공유 저장소 클러스터 또는 단일 복사본 클러스터를 배포할 때 장애 조치 클러스터 형성 이전과 이후 및 클러스터된 사서함 서버와 저장소 그룹 형성 이후에 저장소를 구성하는 추가 단계가 필요했습니다.

Exchange 2010에는 이전 버전의 Exchange에 있는 클러스터 서비스와의 통합을 통해 제공되는 리소스 모델 및 장애 조치 관리 기능을 대체하는 기능을 가진 Active Manager라는 새 구성 요소가 포함되어 있습니다. Active Manager에 대한 자세한 내용은 Active Manager 이해를 참조하십시오.

맨 위로 이동

이전 버전 Exchange의 고가용성에서 변경된 사항

고가용성을 위해 Exchange를 구성하는 방법과 사이트 복구를 수행하는 방법에 직접적인 영향을 주는 몇 가지 변경이 Exchange 2010의 핵심 아키텍처에 수행되었습니다. 한 가지 중요한 변경 사항은 클러스터된 사서함 서버가 제거되고 Windows 장애 조치 클러스터 리소스 모델이 사용된 것입니다. 다른 중요한 변경 사항으로는 데이터베이스 전역화와 Exchange 2007에서 처음 소개된 기본 제공 연속 복제 기술의 향상이 있습니다.

클러스터된 사서함 서버 제거

Exchange 2010에서 Exchange는 더 이상 클러스터된 응용 프로그램이 아니고 클러스터 리소스 모델은 더 이상 Exchange 고가용성에 사용되지 않습니다. 클러스터된 사서함 서버를 비롯하여 Exres.dll 및 이 파일이 제공했던 모든 Exchange 클러스터 리소스는 더 이상 존재하지 않습니다. 대신, Exchange 2010은 고유한 내부 고가용성 모델을 사용합니다. Windows 장애 조치 클러스터링의 일부 구성 요소가 여전히 사용되지만 이제 이러한 구성 요소는 Exchange 2010에서 다른 기능에 통합됩니다.

데이터베이스 전역화

Exchange 2010에서 데이터베이스는 단일 전용 로그 스트림에 연결되고 일련의 1MB 로그 파일로 표시됩니다. 또한 저장소 그룹의 개념이 Exchange 2010에서 제거되었습니다. 이러한 변경 사항으로 인해 Exchange 데이터베이스에는 전용 로그 스트림이 있으며 더 이상 다른 데이터베이스와 로그 스트림을 공유하지 않습니다.

이전 버전의 Exchange와 달리 데이터베이스는 더 이상 특정 사서함 서버에 구속되지 않습니다. 또한 데이터베이스가 있는 사서함 서버에서 더 이상 데이터베이스를 식별하지 않으며 서버 이름은 더 이상 데이터베이스 ID의 일부가 아닙니다. 이러한 변경 사항으로 인해 데이터베이스는 이제 Active Directory 및 각 Exchange 조직에서 전역 개체입니다. Exchange 관리 콘솔을 사용할 경우 데이터베이스는 이제 조직 구성 노드 아래의 사서함 노드에서 관리됩니다.

각 사서함 서버는 최대 100개의 데이터베이스를 호스트할 수 있습니다(활성 및 수동 데이터베이스를 합친 수). 총 데이터베이스 수는 서버에 있는 활성 및 수동 데이터베이스를 합친 수와 같습니다. 복구 데이터베이스는 100개 데이터베이스 제한을 계산할 때 포함되지 않습니다.

Exchange 2010 RTM의 연속 복제에서 변경된 사항

Exchange 2007에서 소개된 연속 복제 기술은 Exchange 2010에서도 사용할 수 있습니다. 그러나 새 고가용성 기능 및 확장성을 지원하도록 기능이 상당히 향상되었습니다. 이러한 아키텍처 변경 사항 중 몇 가지 경우를 들면 다음과 같습니다.

  • 저장소 그룹이 Exchange 2010에서 제거되었으므로 이제 연속 복제는 데이터베이스 수준에서 작동합니다. Exchange 2010은 하나 이상의 다른 위치에 복제되고 하나 이상의 사서함 데이터베이스 복사본에 재생되는 트랜잭션 로그를 생성하는 ESE(Extensible Storage Engine) 데이터베이스를 계속 사용합니다. 각 사서함 데이터베이스는 무려 16개나 되는 복사본을 가질 수 있습니다.

  • 로그 전달은 더 이상 SMB(서버 메시지 블록) 및 Windows 파일 시스템 알림을 사용하지 않습니다. 로그 전달은 수동 복사본이 활성 복사본에서 닫힌 로그 파일을 끌어오는 끌어오기 모델을 더 이상 사용하지 않습니다. 대신에 수동 복사본은 TCP 기반 알림을 사용하여 수동 복사본에 필요한 로그 파일을 활성 복사본에 알립니다. 그런 다음 활성 복사본은 TCP 소켓을 통해 구성된 각 수동 복사본으로 로그 파일을 밀어넣습니다.

  • Exchange 2010 연속 복제는 관리자가 정의한 단일 TCP 포트를 데이터 전송에 사용합니다. 또한 Exchange 2010은 데이터 스트림의 네트워크 암호화 및 압축을 위한 기본 제공 옵션을 포함합니다.

  • 시드에 데이터베이스 활성 복사본만 사용하던 제한이 사라졌습니다. 이제 사서함 데이터베이스의 수동 복사본도 데이터베이스 복사본 시드 및 다시 시드를 위한 원본으로 지정할 수 있습니다.

  • 데이터베이스 복사본은 사서함 데이터베이스에 대해서만 제공됩니다. 공용 폴더 데이터베이스에 대한 중복성과 고가용성을 위해 공용 폴더 복제를 사용하는 것이 좋습니다. 같은 클러스터에 공용 폴더 데이터베이스의 복사본 여러 개가 존재할 수 없었던 CCR과 달리, 공용 폴더 복제를 사용하여 DAG의 서버 간에 공용 폴더 데이터베이스를 복제할 수 있습니다.

  • Exchange 2007에서 Microsoft Exchange 복제 서비스는 수동 데이터베이스 복사본에 로그를 재생하는 역할을 수행했습니다. 수동 복사본이 활성화된 경우 재생 활동의 결과로 Microsoft Exchange 복제 서비스에 의해 작성된 데이터베이스 캐시는 Microsoft Exchange 정보 저장소 서비스가 데이터베이스를 탑재할 때 손실됩니다. 이로 인해 데이터베이스 캐시는 콜드 상태로 알려진 상태가 됩니다. 이러한 기간 동안 읽기/쓰기 작업을 캐시하는 데 사용되는 데이터베이스 캐시의 크기가 작아집니다(콜드). 그러므로 읽기 I/O 작업을 줄이는 기능이 현저히 감소합니다. Exchange 2010에서 이전에 Microsoft Exchange 복제 서비스에 의해 수행된 수동 복사본 재생 기능은 Microsoft Exchange 정보 저장소 서비스로 이동했습니다. 결과적으로 웜 데이터베이스 캐시가 존재하며 장애 조치 또는 전환이 발생한 후 즉시 사용할 수 있습니다.

Exchange 2007 연속 복제에 사용된 몇 가지 개념 또한 Exchange 2010에 그대로 적용됩니다. 여기에는 장애 조치 관리, 확산, 자동 데이터베이스 탑재 다이얼 사용, 복제 및 클라이언트 액세스(MAPI) 네트워크 사용 등의 개념이 포함됩니다.

Exchange 2010 SP1의 연속 복제에서 변경된 사항

Exchange 2010의 RTM 버전 및 Exchange Server 2007의 모든 버전에서, 활성 데이터베이스 복사본에서 생성된 로그 파일의 복사본을 수동 데이터베이스 복사본으로 전달하여 연속 복제가 작동합니다. Exchange 2010 SP1에서 시작되는 이 형태의 연속 복제를 연속 복제 - 파일 모드라고 합니다. SP1에서는 연속 복제 - 블록 모드라고 하는 새 형태의 연속 복제도 도입합니다. 블록 모드에서는 각 업데이트가 활성 데이터베이스 복사본의 활성 로그 버퍼에 작성되므로 각 수동 사서함 복사본의 로그 버퍼로도 전달됩니다. 로그 버퍼가 꽉 차면 각 데이터베이스 복사본이 다음 로그 파일을 작성 및 검사하며 생성 시퀀스에 만듭니다. 활성 복사본에 영향을 주는 오류 발생 시, 수동 복사본은 대부분의 또는 모든 최신 업데이트로 업데이트됩니다. 활성 복사본은 복제 문제가 클라이언트 환경에 영향을 주지 않도록 하기 위해 복제가 완료될 때까지 기다리지 않습니다.

블록 모드에서는 활성 복사본의 변경 시간과 변경 내용이 수동 복사본에 복제되는 시간 간의 대기 시간이 크게 감소됩니다. 복제되는 개별 로그 파일이 작성되는 것 외에도 블록 모드는 수동 복사본의 활성화 프로세스도 변경합니다. 복사본이 블록 모드에 있는 경우 오류가 발생하면 시스템은 활성화 프로세스 동안 사용 가능한 부분 로그 콘텐츠를 사용합니다. 이렇게 하면 단일 실패 지점에서 활성 복사본의 현재 로그 파일이 삭제됩니다.

초기 작동 모드는 항상 파일 모드입니다. 블록 모드는 연속 복제가 파일 모드에서 최신인 경우에만 활성화됩니다. 블록 모드로 들어오고 나가는 전환은 로그 복사기에서 자동으로 수행됩니다. 수동 복사본이 현재 로그 파일을 요청하면 연속 복제가 최신이며(복사본 큐 길이가 0) 시스템이 파일 모드에서 블록 모드로 자동으로 전환되어야 함을 나타냅니다.

MSExchange 복제 성능 개체에서 연속 복제 - 블록 모드 활성 성능 카운터를 모니터링하여 수동 데이터베이스 복사본이 블록 모드에 있는지 확인할 수 있습니다. 각 데이터베이스 복사본에는 이 카운터의 자체 인스턴스가 있습니다. 수동 복사본이 블록 모드에 있으면 카운터의 값이 1로 설정되며 수동 복사본이 파일 모드에 있으면 0으로 설정됩니다. 다음 예에서와 같이 Get-Counter 또는 Get-WMIObject cmdlet을 사용하여 이 카운터의 값을 확인할 수도 있습니다.

Get-Counter -ComputerName <DAGMemberName> -Counter "\MSExchange Replication(*)\Continuous replication - block mode Active"
Get-WMIObject -ComputerName <DAGMemberName> Win32_PerfRawData_MSExchangeReplication_MSExchangeReplication | Where-Object {$_.ContinuousReplicationBlockModeActive -eq "1"} | Where-Object {$_.name -ne "_total"} | format-table Name,ContinuousReplicationBlockModeActive

Exchange 2007의 전송 쓰레기 수거통에서 변경된 사항

Exchange 2010 허브 전송 서버 역할은 Exchange 2007에서 처음 소개된 전송 쓰레기 수거통이라는 기능을 포함합니다. 전송 쓰레기 수거통은 CCR 또는 LCR에 의해 사서함이 보호되는 사용자에게 보내진 모든 최신 전자 메일 메시지의 큐를 유지 관리하여 데이터 손실을 방지하도록 설계되었습니다. 이러한 환경 중 하나에서 손실 오류가 발생할 경우 오류의 결과로 손실되는 것이 일반적인 대량의 데이터가 전송 쓰레기 수거통에 의해 자동으로 복구됩니다.

전송 쓰레기 수거통은 복제된 사서함 데이터베이스에만 사용됩니다. 공용 폴더에 보내진 메시지를 보호하지 않으며 복제되지 않는 사서함 데이터베이스의 받는 사람에게 보내진 메시지도 보호하지 않습니다. 특정 사서함 데이터베이스에 대한 전송 쓰레기 수거통 큐는 DAG를 포함하는 Active Directory 사이트의 모든 허브 전송 서버에 있습니다.

Exchange 2007에서 메시지는 관리자가 정의한 시간 제한 또는 크기 제한에 도달할 때까지 전송 쓰레기 수거통에서 유지되었습니다. Exchange 2010에서 이제 전송 쓰레기 수거통은 복제 파이프라인에서 피드백을 수신하여 배달 및 복제된 메시지를 확인합니다. 메시지는 허브 전송 서버를 통해 DAG의 복제된 사서함 데이터베이스로 전송되므로, 복사본은 메시지를 나타내는 트랜잭션 로그가 성공적으로 사서함 데이터베이스의 모든 복사본으로 복제되고 이러한 모든 복사본에 의해 검사될 때까지 전송 큐(mail.que)에 유지됩니다. 로그가 모든 데이터베이스 복사본으로 복제되고 이러한 모든 복사본에 의해 검사된 후 해당 로그에 있는 메시지가 전송 쓰레기 수거통에서 잘립니다. 이와 같은 방법으로 트랜잭션 로그가 아직 복제되지 않은 메시지의 복사본만 유지 관리되므로 전송 쓰레기 수거통 큐는 더 작은 크기로 유지됩니다.

각 DAG의 Active Manager는 각 수동 데이터베이스 복사본에서 조사된 마지막 로그의 값을 추적합니다. 허브 전송 서버에서 실행되는 Active Manager 클라이언트는 이 정보를 DAG의 SAM(Standby Active Manager)에서 가져와 정보를 시간 기반 워터마크로 변환합니다. 허브 전송 서버는 전송 쓰레기 수거통의 메시지 배달 시간을 워터마크와 비교합니다. 메시지 배달 시간이 워터마크보다 이전이면 메시지가 전송 쓰레기 수거통에서 잘립니다.

또한 전송 쓰레기 수거통은 단일 사서함 데이터베이스가 Active Directory 사이트 간에 이동할 수 있게 하는 사서함 서버에 대한 변경 사항을 고려하도록 향상되었습니다. DAG를 여러 Active Directory 사이트로 확장할 수 있으므로 결과적으로 하나의 Active Directory 사이트에 있는 단일 사서함 데이터베이스는 다른 Active Directory 사이트로 장애 조치될 수 있습니다. 이 경우 모든 전송 쓰레기 수거통 재배달 요청은 두 Active Directory 사이트, 즉 원래 사이트와 새 사이트 모두에 보내집니다.

DAG에 허브 전송 서버 및 사서함이 공존할 경우 라우팅 동작에 대해 변경된 사항

허브 전송 서버가 DAG의 구성원인 사서함 서버와 공존하는 경우, 두 서버 역할의 복구 기능이 해당 서버의 사용자가 주고받은 메시지에 대해 필요한 보호를 제공하도록 라우팅 동작에 변경이 있습니다. 허브 전송 서버도 DAG 구성원이고 로컬로 탑재되는 사서함 데이터베이스의 복사본을 갖는 경우, 로컬 사서함 서버에 대한 메시지를 같은 사이트에 있는 다른 허브 전송 서버로 다시 라우팅을 시도하도록 허브 전송 서버 역할을 수정했습니다. 이 추가 홉은 다른 허브 전송 서버의 전송 쓰레기 수거통에 메시지를 넣기 위해 추가되었습니다.

예를 들어 EX1은 허브 전송 서버 역할 및 사서함 서버 역할을 호스트하고, DAG의 구성원입니다. EX1에도 사서함을 갖고 있는 받는 사람에게 가는 메시지가 EX1의 전송에 도착하면 전송은 메시지를 사이트(예: EX2)의 다른 허브 전송 서버로 다시 라우팅하고, 해당 서버는 EX1의 사서함으로 메시지를 전달합니다.

Microsoft Exchange 메일 전송 서비스와 관련하여, 유사한 두 번째 동작 변경 사항이 있습니다. 이 서비스는 사서함 서버 또는 허브 전송 서버가 DAG의 구성원인 경우 로컬 허브 전송 서버 역할로 메시지를 전송하지 않도록 수정되었습니다. 이 시나리오에서 전송 동작은 같은 Active Directory 사이트의 다른 허브 전송 서버 간에 전송 요청 부하를 분산하고, 같은 사이트에 사용 가능한 다른 허브 전송 서버가 없는 경우 로컬 허브 전송 서버로 대체하는 것입니다.

맨 위로 이동

비사서함 서버 역할의 고가용성

서버 중복, 부하 분산, DNS(Domain Name System) 라운드 로빈뿐만 아니라 자동 관리 서버, 서비스 및 인프라 관리를 함께 사용하여 허브 전송, Edge 전송, 클라이언트 액세스 및 통합 메시징 서버 역할에 대한 고가용성을 달성할 수 있습니다. 일반적으로 다음 전략과 기술을 사용하여 클라이언트 액세스, 허브 전송, Edge 전송 및 통합 메시징 서버 역할에 대한 고가용성을 달성할 수 있습니다.

  • Edge 전송   여러 Edge 전송 서버를 배포하고 여러 DNS MX 리소스 레코드를 사용하여 이러한 서버에서의 작업 부하를 분산시킬 수 있습니다. NLB(네트워크 부하 분산)를 사용하여 Edge 전송 서버에 부하 분산 및 고가용성을 제공할 수도 있습니다.

  • 클라이언트 액세스   클라이언트 액세스 서버의 가용성을 높이기 위해 NLB 또는 타사 하드웨어 기반 네트워크 부하 분산 장치를 사용할 수 있습니다.

  • 허브 전송   내부 전송 가용성을 높이기 위해 허브 전송 서버를 여러 개 배포할 수 있습니다. 복구는 허브 전송 서버 역할에 대해 다음 방법으로 설계되었습니다.

    • 허브 전송 서버 간(조직 내)   조직 내 허브 전송 서버 간 통신은 대상 Active Directory 사이트에 있는 사용 가능한 허브 전송 서버 간에 자동으로 부하를 분산합니다.

    • 사서함 서버와 허브 전송 서버 간(Active Directory 사이트 내)   사서함 서버의 Microsoft Exchange Mail Submission Service는 동일한 Active Directory 사이트에 있는 사용 가능한 모든 허브 전송 서버 간에 자동으로 부하를 분산합니다.

    • 통합 메시징 서버와 허브 전송 서버 간   통합 메시징 서버는 동일한 Active Directory 사이트에 있는 사용 가능한 모든 허브 전송 서버 간 연결의 부하를 자동으로 분산합니다.

    • Edge 전송 서버와 허브 전송 서버 간   Edge 전송 서버는 인바운드 SMTP 트래픽의 부하를 Edge 전송 서버가 구독된 Active Directory 사이트에 있는 모든 허브 전송 서버에 자동으로 분산합니다.

    추가 중복(예: SMTP 릴레이가 필요한 응용 프로그램)을 위해, DNS 레코드(예: relay.company.com)를 만들고, IP 주소를 할당하며 하드웨어 부하 분산 장치를 사용하여 해당 IP 주소를 여러 허브 전송 서버에 리디렉션할 수 있습니다. 또한 허브 전송 서버의 클라이언트 커넥터에 대해 NLB도 사용할 수 있습니다. 조직 내 트래픽에서는 앞에서 설명한 기본 제공 부하 분산 알고리즘을 사용하므로 하드웨어 부하 분산 장치를 사용하는 경우, 하드웨어 부하 분산 장치와 교차하고 있는 조직 내 트래픽이 없는지 확인해야 합니다.

  • 통합 메시징   둘 이상의 서버가 단일 다이얼 플랜 내에 있는 여러 통합 메시징 서버를 배포하면 통합 메시징 배포를 보다 원활하게 수행할 수 있습니다. 통합 메시징에서 지원하는 VoIP(Voice over IP) 게이트웨이를 통합 메시징 서버에 대한 호출을 라운드 로빈 방식으로 라우팅하도록 구성할 수 있습니다. 또한 이러한 게이트웨이를 통해 DNS에서 다이얼 플랜의 서버 목록을 검색할 수 있습니다. 두 경우 모두 VoIP 게이트웨이에서는 통합 메시징 서버에 대한 호출을 제공하며 해당 호출은 수락되지 않는 경우 호출이 설정된 시점에서 중복성을 제공하는 다른 서버로 제공됩니다.

맨 위로 이동

사이트 복구

Exchange 2010에는 고가용성 및 사이트 복구 모두에 대한 통합 플랫폼이 포함되어 있습니다. Exchange 2010의 기본 사이트 복구 지원과 적절한 계획을 결합하면 두 번째 데이터 센터를 빠르게 활성화하여 실패한 데이터 센터의 클라이언트에 서비스를 제공할 수 있습니다. 데이터 센터나 사이트의 오류는 서버 또는 데이터베이스 장애 조치(failover)를 일으킬 수 있는 오류 유형과 다른 방식으로 관리합니다. 고가용성 구성에서는 시스템이 자동 복구를 시작하며 보통은 오류가 발생해도 메시징 시스템이 완전하게 작동하는 상태로 복구됩니다. 반면 데이터 센터 오류는 재해 복구 이벤트로 간주됩니다. 클라이언트 서비스를 복원하여 중지 상태를 해결하려면 수동으로 복구를 수행하여 완료해야 합니다. 이때 수행하는 프로세스를 데이터 센터 전환이라고 합니다. 다른 재해 복구 시나리오의 경우와 마찬가지로, 데이터 센터 전환을 사전에 계획하고 준비해 두면 복구 프로세스를 단순화하고 중지 기간을 단축할 수 있습니다.

사이트 복구 계획 및 배포에 대한 자세한 내용은 고가용성 및 사이트 복구 계획, 고가용성 및 사이트 복구 배포 및 데이터 센터 전환을 참조하십시오.

맨 위로 이동

종단 간 가용성

Exchange 2010에는 또한 종단 간 시스템 가용성을 높이기 위한 많은 기능이 포함되어 있습니다. 여기에는 다음과 같은 기능이 있습니다.

  • 섀도 중복성

  • 사서함 온라인 이동

  • 유연한 사서함 보호

  • 증분 다시 동기화

  • 타사 복제 API

섀도 중복성

앞에 설명된 전송 쓰레기 수거통 및 라우팅 동작 향상과 더불어, 섀도 중복성이라는 새로운 허브 전송 서버 기능이 추가되었습니다. 섀도 중복성은 전체 전환 시간 동안 메시지에 대한 중복성을 제공하며, 이 솔루션에는 전송 쓰레기 수거통과 유사한 기술이 포함되어 있습니다. 섀도 중복성을 사용할 경우 전송 데이터베이스에서의 메시지 삭제는 전송 서버가 해당 메시지의 모든 다음 홉이 배달을 완료했음을 확인할 때까지 지연됩니다. 배달 성공이 보고되기 전에 다음 홉이 실패하면 메시지가 배달을 위해 다음 홉으로 다시 전송됩니다. 섀도 중복성에 대한 자세한 내용은 섀도 중복성 이해를 참조하십시오.

사서함 온라인 이동

Exchange 2010에는 비동기적으로 사서함을 이동할 수 있는 새로운 기능이 포함되어 있습니다. Exchange 2007에서는 사서함을 이동하기 위해 Move-Mailbox cmdlet을 사용하면, 이 cmdlet이 원본 데이터베이스와 대상 데이터베이스 모두에 로깅하고, 한 사서함에서 다른 사서함으로 콘텐츠를 이동했습니다. cmdlet으로 이동 작업을 수행하는 경우 몇 가지 단점이 있었습니다.

  • 사서함 이동을 완료하려면 대개 수시간이 소요되었고, 이동 중 사용자는 자신의 사서함에 액세스할 수 없었습니다.

  • Move-Mailbox cmdlet을 실행하는 데 사용한 명령 프롬프트 창이 닫힐 경우에는 이동이 중단되고 다시 시작해야 했습니다.

  • 이동을 수행하는 데 사용한 컴퓨터는 데이터 센터에 속해 있었습니다. 관리자가 자신의 워크스테이션에서 cmdlet을 수행하면 사서함 데이터는 원본 서버에서 관리자의 워크스테이션으로, 그리고 다시 대상 서버로 이동합니다.

Exchange 2010의 New-MoveRequest cmdlet은 비동기 이동을 수행하는 데 사용할 수 있습니다. Exchange 2007에서와 달리, cmdlet은 실제 이동을 수행하지 않습니다. 이동은 클라이언트 액세스 서버에서 실행하는 새 서비스인 Microsoft Exchange 사서함 복제 서비스에서 수행하고, New-MoveRequest cmdlet은 Microsoft Exchange 사서함 복제 서비스로 요청을 보냅니다. 온라인 사서함 이동에 대한 자세한 내용은 이동 요청 이해를 참조하십시오.

유연한 사서함 보호

Exchange 2010의 핵심 아키텍처에서 사서함 데이터베이스 및 포함 사서함을 보호하는 방법에 직접적인 영향을 주는 몇 가지 변경이 있습니다.

한 가지 중요한 변경 사항은 저장소 그룹을 제거하는 것입니다. Exchange 2010에서 각 데이터베이스는 단일 로그 스트림에 연결되고, 일련의 1MB 로그 파일로 표시됩니다. 각 서버는 최대 100개의 데이터베이스를 호스트할 수 있습니다.

Exchange 2010의 또 다른 변경 사항은 이제 데이터베이스가 특정 사서함 서버에 구속되지 않는다는 점입니다. 데이터베이스 이동성은 데이터베이스를 여러 개의 다른 서버로 복제하여 시스템의 연속 복제 사용을 확장하며, 이로써 데이터베이스의 보호 및 가용성이 향상됩니다. 오류가 발생할 경우 데이터베이스의 복사본을 가진 다른 서버가 데이터베이스를 탑재할 수 있습니다.

여러 서버에서 호스트하는 데이터베이스의 복사본을 여러 개 가질 수 있다는 것은 충분한 수의 데이터베이스 복사본이 있는 경우 이러한 복사본을 백업으로 사용할 수 있음을 의미합니다. 이 전략에 대한 자세한 내용은 백업, 복원 및 재해 복구 이해를 참조하십시오.

증분 다시 동기화

Exchange 2007에서는 손실된 로그 복구 및 증분 다시 시드의 개념을 도입했습니다. 손실된 로그 복구는 ESE의 내부 구성 요소로, 가장 최근에 생성된 트랜잭션 로그 파일 중 하나 이상이 손실되거나 손상된 경우에도 Exchange 사서함 데이터베이스를 복구할 수 있게 해줍니다. 손실된 로그 복구를 사용하면 최근에 생성된 로그 파일을 사용할 수 없을 때에도 사서함 데이터베이스를 탑재할 수 있습니다. 손실된 로그 복구는 지정한 로그 생성 수가 만들어질 때까지 데이터베이스에 대한 쓰기를 지연하는 방식으로 작동합니다. 손실된 로그 복구는 데이터베이스 파일에 대한 최신 업데이트를 잠시 지연하며, 쓰기가 지연되는 시간은 로그 생성 속도에 따라 달라집니다.

또한 Exchange 2007에서는 손실된 로그 복구의 지연된 재생 기능을 바탕으로, 원본 및 대상 저장소 그룹 간 트랜잭션 로그 스트림에서 차이점을 해결하는 기능을 제공하는 증분 다시 시드의 개념을 도입했습니다. 증분 다시 시드는 차이점이 있는 로그가 재생되어 다시 시드를 완료해야 할 경우, 데이터베이스 수동 복사본의 차이점을 해결하는 수단을 제공하지는 않았습니다. Exchange 2007과 달리, Exchange 2010에는 전체 다시 시드를 필요로 하는 로그 손실이 없습니다.

Exchange 2010에서 증분 다시 동기화는 다음과 같은 조건에서 데이터베이스 복사본의 차이점을 자동으로 해결하는 기능의 새로운 이름입니다.

  • 데이터베이스의 구성된 모든 복사본에 대한 자동 장애 조치(failover) 후

  • 새 복사본이 사용되고 일부 데이터베이스와 로그 파일이 복사본 위치에 이미 있는 경우

  • 복제가 일시 중단된 뒤 다시 시작되거나 Microsoft Exchange 복제 서비스를 다시 시작하는 경우

이러한 변경 사항으로 인해 손실된 로그 복구는 이제 모든 Exchange 2010 사서함 데이터베이스에 대한 하나의 로그 파일로 하드 코드됩니다.

활성 데이터베이스와 이 데이터베이스의 복사본 간에 차이점이 감지될 경우 증분 다시 동기화가 다음 작업을 수행합니다.

  • 로그 파일 스트림을 검색하여 차이 지점을 찾습니다.

  • 차이점이 있는 복사본에서 변경된 데이터베이스 페이지를 찾습니다.

  • 활성 복사본에서 변경된 페이지를 읽은 다음 필요한 로그 파일을 복사합니다.

  • 데이터베이스 페이지 변경 내용을 차이점이 있는 복사본에 적용합니다.

  • 차이점이 있는 복사본에서 복구를 실행하고 필요한 로그 파일을 데이터베이스 복사본으로 재생합니다.

타사 복제 API

Exchange 2010에는 기본 제공되는 연속 복제 기능 대신 타사 동기식 복제 솔루션을 사용할 수 있게 하는 새로운 타사 복제 API가 포함되어 있습니다. Microsoft는 해당 솔루션이 API를 사용한 결과로 사용할 수 없는 모든 기본 연속 복제 기능을 대체하는 데 필요한 기능을 제공한다면 이 API를 사용하는 타사 솔루션을 지원합니다. API가 DAG 내에서 사용되어 사서함 데이터베이스 복사본을 관리하고 활성화하는 경우에만 솔루션이 지원됩니다. 이러한 경계 외부에서의 API 사용은 지원되지 않습니다. 또한 솔루션이 해당 Windows 하드웨어 지원 요구 사항을 충족해야 합니다(테스트 유효성 검사는 지원에 필요하지 않음).

기본 타사 복제 API를 사용하는 솔루션을 배포하는 경우, 솔루션 공급업체가 해당 솔루션에 대한 주 지원 공급자가 됩니다. Microsoft는 복제된 솔루션 및 복제되지 않은 솔루션 모두에 대한 Exchange 데이터를 지원합니다. 데이터 복제를 사용하는 솔루션은 Microsoft 기술 자료 문서 895847, Exchange Server에 대한 다중 사이트 데이터 복제 지원에서 설명한 데이터 복제에 대한 Microsoft의 지원 정책을 준수해야 합니다. 또한 Windows 장애 조치 클러스터 리소스 모델을 사용하는 솔루션은 Microsoft 기술 자료 문서 943984, Windows Server 2008 장애 조치 클러스터에 대한 Microsoft 지원 정책에서 설명한 Windows 클러스터 지원 가능성 요구 사항을 준수해야 합니다.

타사 복제 API 기반 솔루션을 사용하는 배포의 경우 Microsoft의 백업 및 복원 지원 정책은 고유의 연속 복제 배포의 경우와 동일합니다.

타사 API에 대한 정보가 필요한 파트너는 Microsoft 담당자에게 문의하십시오. Exchange 2010의 파트너 제품에 대한 자세한 내용은 Microsoft Exchange 파트너을 참조하십시오.

맨 위로 이동

 © 2010 Microsoft Corporation. 모든 권리 보유.