새로운 고가용성 및 사이트 복구 기능

적용 대상: Exchange Server 2010 SP2

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

Microsoft Exchange Server 2010은 배포 시의 비용과 복잡성은 줄이면서 최고 수준의 서버 가용성과 사이트 복구 기능을 제공하는 전자 메일 솔루션입니다. Exchange Server 2007에 도입했던 고유의 복제 기능을 기반으로 하는 Exchange 2010의 새로운 고가용성 아키텍처는 고가용성과 재해 복구를 위한 간소화된 통합 프레임워크를 제공합니다. Exchange 2010은 Exchange의 핵심 아키텍처에 고가용성을 통합하여, 기업 규모와 업종에 상관없이 고객이 경제적으로 메시징 서비스를 조직에 배포할 수 있게 해줍니다.

Exchange Server 2007 진행 중 얻은 개선 사항

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

• 일부 관리자는 Windows 장애 조치(failover) 클러스터링의 복잡성을 우려했습니다.

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

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

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

• 사이트 복구 솔루션이 원활하게 진행되지 않았습니다.

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

Exchange 2010의 큰 변화 중 한 가지는 고가용성이 아키텍처에 깊이 통합되어 있다는 것입니다. 이로 인해 Exchange 2007에 비해 쉽게, 또 비용 효율적으로 모든 고객에 대한 배포 및 유지 관리가 가능합니다. 조직에서는 이제 단 두 개의 서버로 완벽하게 중복된 Exchange 조직을 배포할 수 있으며, 데이터베이스 수준의 장애 조치(failover)도 수행할 수 있습니다. 고객은 Windows 장애 조치(failover) 클러스터링 전문가가 아니어도 데이터베이스 수준의 자동 장애 조치(failover) 기능의 이점을 누리게 됩니다. 또한 한결 간소화된 과정을 통해 기존 고가용성 배포에 사이트 복구 기능을 추가할 수 있습니다.

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

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

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

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

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

사서함 복구

Exchange 2010은 사서함 복구 개념에 입각하여 재설계되어, 이제 서버 수준이 아닌 개별 사서함 데이터베이스 수준에서 자동 장애 조치(failover) 보호를 제공하도록 아키텍처가 변경되었습니다. 이는 Exchange 2010에서 데이터베이스 이동성이라고도 합니다. 이 기능과 더불어 기타 데이터베이스 캐시 아키텍처 변경의 결과로 이제 이전 버전의 Exchange에 비해 훨씬 빨리 장애 조치 작업이 완료됩니다. 예를 들어 Exchange 2007 SP2(서비스 팩 2)를 실행 중인 CCR 환경에서 클러스터된 사서함 서버의 장애 조치(failover)는 약 2분이 소요됩니다. 이에 반해 Exchange 2010 환경에서 사서함 데이터베이스의 장애 조치(failover)는 30초 이내에 완료됩니다. (오류가 감지된 순간부터 데이터베이스 복사본이 탑재될 때까지의 시간을 측정했으며, 로그 재생으로 사용 가능한 정상 상태의 최신 복사본을 전제로 합니다.) 이 같은 데이터베이스 수준 장애 조치(failover)와 장애 조치(failover) 시간의 단축으로 조직의 전체 가동 시간이 크게 향상됩니다.

Exchange 2010에 구현된 사서함 복구 아키텍처는 조직과 메시징 관리자가 새로운 이점을 누릴 수 있게 해줍니다.

• 여러 개의 서버 역할이 고가용성을 제공하는 서버에 공존할 수 있습니다. 따라서 소규모 조직에서 클라이언트 액세스 및 허브 전송 서비스에 대한 중복과 동시에 사서함 데이터와 서비스에 대한 중복도 제공하는 두 서버 구성을 배포할 수 있습니다.

• 관리자는 고가용성을 위해 장애 조치(failover) 클러스터를 구현하지 않아도 됩니다. 이제 장애 조치(failover) 클러스터는 관리자 개입 없이 Exchange 2010에서 자동으로 만듭니다. Exchange에서 제공하는 클러스터 리소스 DLL인 ExRes.dll을 사용했던 이전 버전의 Exchange 클러스트와 달리 Exchange 2010에서는 클러스터 리소스 DLL을 사용하거나 필요로 하지 않습니다. Exchange 2010은 클러스터된 응용 프로그램이 아니며, 데이터베이스 이동성을 제공하기 위해 장애 조치(failover) 클러스터 구성 요소의 극히 일부분(하트비트 기능과 클러스터 데이터베이스)만 사용합니다.

• Exchange 2010가 배포된 후 관리자는 Exchange를 제거하지 않고 Exchange 환경에 고가용성을 추가하고, 이를 고가용성 구성으로 다시 배포할 수 있습니다.

• Exchange 2010은 운영 체제의 이벤트와 Exchange의 이벤트를 결합하는 이벤트 스트림 보기를 제공합니다.

• 이제 Exchange 2010에는 저장소 그룹 개체가 존재하지 않고, 모든 Exchange 2010 사서함 서버 간에 사서함 데이터베이스를 이동할 수 있으므로 필요할 때 쉽게 데이터베이스를 이동할 수 있습니다.

자세한 내용은 고가용성 및 사이트 복구를 참조하십시오.

유연한 사서함 보호

Exchange 2010을 올바르게 배포하고 구성할 경우, 기존 방식의 데이터 백업이 필요하지 않은 유연한 사서함 보호를 제공하는 몇 가지 새로운 기능과 중요한 변경 사항이 있습니다. Exchange 2010에 구현된 고가용성 기능을 사용하면 재해 발생 시의 가동 중지 시간과 데이터 손실이 최소화되며 메시징 시스템의 총 소유 비용이 줄어듭니다. 조직은 이러한 기능을 법적 보유 등의 다른 기본 제공 기능과 결합하여 사용함으로써 기존의 특정 시점 백업에 대한 의존도를 줄이거나 없애고 비용 절감을 실현할 수 있습니다.

Exchange 2010에서는 기존의 특정 시점 백업이 필요하지 않은 장점을 확인하는 것과 함께, 현재 백업 인프라의 비용을 평가해 보는 것이 좋습니다. 기존 백업 인프라를 사용하여 재해를 복구할 때 최종 사용자에 대한 서비스 중지 및 데이터 손실 비용을 고려해 보십시오. 또한 하드웨어, 설치 및 라이선스 비용, 백업 유지 관리 및 데이터 복구와 관련된 관리 비용도 여기에 추가되어야 합니다. 조직의 요구 사항에 따라, 세 개 이상의 사서함 데이터베이스 복사본이 있는 순수 Exchange 2010 환경에 대한 총 소유 비용은 기존 백업을 사용하는 환경보다 적을 가능성이 아주 높습니다.

유연한 사서함 보호에 대한 자세한 내용은 백업, 복원 및 재해 복구 이해를 참조하십시오.

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

Exchange 2010에서는 핵심 아키텍처의 많은 부분이 변경되었습니다. Exchange 2010은 CCR 및 SCR의 핵심 복구 기능과 가용성을 단일 고가용성 솔루션에 통합하여 온사이트 데이터 복제와 오프사이트 데이터 복제를 모두 처리합니다. 사서함 서버는 서버 수준 대신 개별 사서함 데이터베이스 수준에서 자동 복구를 제공하기 위해 DAG(데이터베이스 가용성 그룹)의 일원으로 정의될 수 있습니다. 각 사서함 데이터베이스는 최대 16개의 복사본을 가질 수 있습니다. Exchange 2010에는 데이터베이스 이동성 및 증분 배포 등, 다른 새로운 고가용성 개념이 도입되었습니다. 백업과 RAID가 필요하지 않은 조직의 개념도 Exchange 2010에 도입되고 있습니다.

요약하면, 사서함 서버 역할과 사서함 데이터베이스에 대한 데이터 및 서비스 가용성의 핵심은 다음과 같습니다.

• Exchange 2010은 Exchange 2007에 도입된 동일한 연속 복제 기술의 향상된 버전을 사용합니다. 자세한 내용은 이 항목 뒷부분의 Exchange Server 2007의 연속 복제에서 변경된 사항를 참조하십시오.

• Exchange 2010에는 저장소 그룹이 존재하지 않습니다. 대신, 간단하게 사서함 데이터베이스, 사서함 데이터베이스 복사본, 공용 폴더 데이터베이스가 있습니다. Exchange 데이터베이스의 기본 관리 인터페이스는 Exchange 관리 콘솔의 서버 구성 아래 사서함 노드에서 조직 구성 아래 사서함 노드로 이동했습니다.

• 일부 Windows 장애 조치(failover) 클러스터링 기술은 Exchange 2010에서 사용되지만, 이제 Exchange에 의해 완벽하게 관리됩니다. 관리자는 고가용성을 갖춘 사서함 서버를 배포할 때 장애 조치(failover) 클러스터링 요소를 설치, 구현 또는 구성할 필요가 없습니다.

• 각 사서함 서버는 최대 100개의 데이터베이스를 호스트할 수 있고, 각 데이터베이스는 최대 16개의 복사본을 가질 수 있습니다.

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

증분 배포

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

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

데이터베이스 가용성 그룹

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

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

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

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

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

데이터베이스 이동성의 다른 주요 특징은 다음과 같습니다.

• Exchange 2010에는 저장소 그룹이 없으므로, 이제 데이터베이스 수준에서 연속 복제가 수행됩니다. Exchange 2010에서 트랜잭션 로그는 하나 이상의 사서함 서버로 복제되고, 해당 서버에 저장된 사서함 데이터베이스의 복사본으로 재생됩니다.

• 장애 조치(failover)는 데이터베이스 수준 또는 서버 수준에서 수행되는 자동 활성화 프로세스입니다. 전환은 데이터베이스, 서버 또는 데이터 센터(사이트) 수준에서 수행할 수 있는 수동 활성화 프로세스입니다.

• Exchange 2010의 데이터베이스 이름은 Exchange 조직 내에서 고유해야 합니다.

• 사서함 데이터베이스가 하나 이상의 데이터베이스 복사본으로 구성된 경우, 모든 데이터베이스 복사본의 전체 경로는 복사본을 호스트하는 모든 사서함 서버에서 같아야 합니다.

• 사서함 데이터베이스 복사본(활성 또는 수동 복사본)은 Exchange 인식 VSS(볼륨 섀도 복사본 서비스)를 기반으로 하는 백업 응용 프로그램을 사용하여 백업할 수 있습니다.

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

Exchange Server 2007의 연속 복제에서 변경된 사항

이전에 CCR 및 SCR에 적용되었던 기본 연속 복제 기술이 Exchange 2010에서도 유지됩니다. 이 기술은 데이터베이스 복사본, 데이터베이스 이동성 및 DAG 등, 새로운 고가용성 기술을 지원하기 위해 더욱 향상되었습니다. 이러한 새로운 아키텍처 변경 사항을 간략하게 설명하면 다음과 같습니다.

• Exchange 2010에는 저장소 그룹이 없으므로, 이제 데이터베이스 수준에서 연속 복제가 수행됩니다. Exchange 2010은 하나 이상의 다른 위치로 복제되고 사서함 데이터베이스의 복사본으로 재생되는 트랜잭션 로그를 작성하는 ESE(Extensible Storage Engine)를 계속 사용합니다.

• Microsoft Exchange에서 Exchange 2007 복제 서비스에 의해 수행되었던 로그 재생 기능은 Microsoft Exchange 저장소 서비스(store.exe)의 Exchange 2010으로 이동했습니다. 장애 조치(failover) 및 전환과 관련한 성능 저하는 이제 발생하지 않습니다. 장애 조치(failover) 또는 전환이 수행되면 활성화된 데이터베이스는 바로 사용할 수 있는 웜 캐시를 보유하게 됩니다.

• 로그 전달 및 시드는 데이터 전환에 SMB(서버 메시지 블록)를 더 이상 사용하지 않습니다. Exchange 2010 연속 복제는 단일 관리자가 정의한 TCP 포트를 데이터 전환에 사용합니다. 또한 Exchange 2010은 데이터 스트림의 네트워크 암호화 및 압축을 위한 기본 제공 옵션을 포함합니다.

• 로그 전달은 수동 복사본이 활성 복사본에서 닫힌 로그 파일을 끌어오는 끌어오기 모델을 더 이상 사용하지 않습니다. 대신, 활성 복사본은 구성된 각 수동 복사본으로 로그 파일을 밀어넣습니다.

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

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

• Microsoft Exchange Replication Service의 LogReplayer 구성 요소에 복사 큐 길이가 지정된 임계값을 초과하는 경우 로그 재생을 중단시키는 새로운 논리가 포함되어 있습니다. 복사 큐의 로그 수가 수동 데이터베이스 복사본에 복사된 로그 파일 수보다 많지만 수동 복사본에서 검사하지 않은 경우 Microsoft Exchange Replication Service가 수동 복사본에 대한 로그 재생을 중단시키고 경고 이벤트 4110을 이벤트 로그에 기록합니다. 복사 큐의 로그 파일 수가 검사하지 않은 복사된 로그 파일 수보다 낮아지면 Microsoft Exchange Replication Service가 수동 복사본에 대한 재생을 다시 시작하고 정보 이벤트 4111을 이벤트 로그에 기록합니다.

Exchange 2007 연속 복제에 사용된 몇 가지 개념 또한 Exchange 2010에 그대로 적용됩니다. 장애 조치(failover) 관리, 차이점, 자동 데이터베이스 탑재 다이얼 사용, 공용 및 개인 네트워크의 사용 등이 여기에 해당합니다.

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

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

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

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

종단 간 가용성

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

• 전송 복구

• 사서함 온라인 이동

• Exchange 고유 데이터 보호

• 증분 다시 동기화

• 타사 복제 API

전송 복구

Exchange 2007에서는 허브 전송 서버의 전송 휴지통 기능을 도입했습니다. 전송 휴지통은 CCR(및 Exchange 2007 SP1, LCR) 환경에 사서함을 가지고 있었던 받는 사람에게 배달된 메시지의 큐를 유지 관리합니다. 이 기능은 관리자에게 클러스터된 사서함 서버가 데이터 손실량이 제한된 다른 노드에서 자동으로 온라인 상태가 되도록 하는 옵션을 제공하여 데이터 손실로부터 보호하기 위해 디자인되었습니다. 이를 손실 장애 조치(failover)라고 합니다. 손실 장애 조치(failover)가 수행되면 시스템은 전자 메일 메시지가 아직 저장되어 있는 전송 휴지통을 사용하여, 오류가 발생한 클러스터된 사서함 서버의 사용자에게 보낸 최신 전자 메일 메시지를 자동으로 다시 배달했습니다. 이 솔루션을 사용하면 손실 장애 조치(failover)에서 손실되는 데이터 양을 최소화할 수 있었지만, 특정 사이트 내의 데이터 손실만 방지할 뿐 전송 중인 메시지는 보호할 수 없었습니다.

Exchange 2010에서는 두 가지 문제를 해결하는 핵심 아키텍처 변경이 있습니다. DAG는 여러 Active Directory 사이트로 확장될 수 있으므로, Active Directory 간에 개별 사서함 데이터베이스를 이동하는 것이 가능합니다. 이러한 디자인 변경 때문에, 손실 데이터베이스 장애 조치(failover)로 인한 전송 휴지통 재배달 요청은 이제 데이터베이스의 원래 및 새 Active Directory 사이트의 허브 전송 서버로 넘어갑니다.

전송 휴지통에 대한 또 다른 중요한 변경 사항은 복제 파이프라인으로부터 피드백을 수신한다는 것입니다. 전송 휴지통의 메시지는 모든 사서함 데이터베이스 복사본으로 복제된 후 전송 휴지통에서 제거됩니다. 이렇게 하면 복제되지 않은 데이터만 전송 휴지통에 보관됩니다.

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

사서함 온라인 이동

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

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

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

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

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

Exchange 고유 데이터 보호

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

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

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

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

증분 다시 동기화

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

증분 다시 시드는 LLR의 지연된 재생 기능을 바탕으로, 원본 및 대상 저장소 그룹 간 트랜잭션 로그 스트림에서 차이점을 해결하는 기능을 제공했습니다. 증분 다시 시드는 차이점이 있는 로그가 재생되어 다시 시드를 완료해야 할 경우, 데이터베이스 수동 복사본의 차이점을 해결하는 수단을 제공하지는 않았습니다.

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

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

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

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

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

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

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

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

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

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

타사 복제 API

Exchange 2010에는 기본 제공되는 연속 복제 기능 대신 타사 동기식 복제 솔루션을 사용할 수 있게 하는 새로운 타사 복제 API가 포함되어 있습니다. Exchange 2010의 파트너 제품에 대한 자세한 내용은 Exchange 2010 파트너 웹 사이트를 참조하십시오. 타사 복제 API의 정보가 필요한 파트너는 Microsoft 담당자에게 문의하십시오.

Exchange Server 2007에서 제외된 기능

Exchange 2007과 Exchange 2007 SP1의 다음 기능은 Exchange 2010에는 제공되지 않습니다. 아래 표에 대체 기능이 나와 있습니다.

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