Exchange Server 2007 서비스 팩 1의 대기 연속 복제

출처 : Technet 매거진 http://technet.microsoft.com/ko-kr/magazine/cc137735.aspx

 

한 눈에 보기:

• 대기 연속 복제 구성
• 중복성의 중요성
• SCR로 가동 중지 시간을 줄이는 방법

서비스 팩 1은 Exchange 2007에 몇 가지 새로운 기능과 향상된 기능을 제공합니다. 이러한 기능 중에서 SCR(대기 연속 복제)은 조직에 데이터 센터 내 중복성과 사이트 복구 기능을 모두 제공하도록 설계되었습니다. 이름이 암시하듯이 SCR은

대기 복구 서버를 사용하거나 사용할 수 있도록 지원하는 시나리오를 위해 설계되었습니다.

Exchange 2007 RTM(Release To Manufacturing) 버전을 사용해 본 적이 있다면 Exchange 2007이 로그 전달 기능과 Windows® 장애 조치(failover) 클러스터 지원을 통해 데이터 센터 내 중복성과 사이트 복구 기능 또한 제공한다는 사실을 잘 알고 계실 것입니다. RTM 버전에서는 로그 전달, 즉 연속 복제를 그림 1에 나오는 LCR(로컬 연속 복제)과 그림 2에 나오는 CCR(클러스터 연속 복제)의 두 가지 형태로 사용할 수 있습니다.

그림 1 로컬 연속 복제

그림 2 Windows 장애 조치(failover) 클러스터의 두 번째 서버에 로그를 전달하는 CCR

연속 복제는 관리자가 각 사서함 데이터베이스의 보조 복사본을 온라인으로 사용 및 유지 관리할 수 있도록 지원함으로써 데이터 가용성과 중복성을 제공합니다. 이 데이터베이스 복사본은 프로덕션 데이터베이스의 오류, 손실 또는 손상에 대비한 최전방 방어선입니다. 이 경우 데이터 복원을 위해 백업 테이프를 찾느라 시간을 낭비하는 대신 데이터베이스 복사본을 활성화하여 단 몇 분 내에 프로덕션 데이터베이스로 전환할 수 있습니다.

SCR은 조직 환경에서 데이터 및 서비스 가용성을 제공하는 기존의 시나리오를 확장합니다. 새로운 시나리오에서는 고가용성 토폴로지와 사이트 복구 토폴로지를 분리할 수 있으며 조직 내 각 영역의 특정 필요에 맞게 조정된 구성을 배포할 수 있습니다.

Exchange 2007 RTM 버전에서는 데이터 센터 내 중복성과 사이트 복구 기능을 제공하지만 LCR과 CCR은 각 데이터베이스에 대해 여분의 복사본을 하나만 제공하므로 복구 기능과 중복성 중에서 하나를 선택해야 합니다. 예를 들어 CCR이 제공하는 데이터 및 서비스 가용성 기능을 고려해 보십시오. 단일 데이터 센터에 액티브 노드와 패시브 노드를 모두 배포할 경우 두 노드가 같은 물리적 사이트에 있으므로 데이터 센터 내 데이터 및 서비스 가용성은 제공되지만 사이트 복구 기능은 제공되지 않습니다. 반면 액티브 노드를 한 데이터 센터에 배포하고 패시브 노드를 보조 데이터 센터에 배포할 경우 데이터 및 서비스 가용성을 제공하는 패시브 노드가 보조 데이터 센터에 있으므로 사이트 복구 기능만 제공되고 데이터 센터 내 가용성은 제공되지 않습니다.

서비스 팩 1의 SCR을 사용하면 각 데이터베이스의 추가 복사본을 만들 수 있어서 고가용성과 사이트 복구 기능이라는 두 가지 목적을 모두 달성할 수 있습니다. 예를 들어 그림 3에서 볼 수 있듯이 주 데이터 센터에서 로컬로 저장소 그룹을 복제하고(고가용성을 위해 CCR 사용), 보조 또는 백업 데이터 센터에서 원격으로 저장소 그룹을 복제하기 위해(사이트 복구 기능을 위해 SCR 사용) SCR과 CCR을 모두 사용할 수 있습니다. 보조 데이터 센터에는 사이트 복구 시나리오에서 클러스터된 대체 사서함 서버를 사용하여 활성화하고 신속하게 제공할 수 있는 대기 클러스터가 포함됩니다.

그림 3 레드먼드 데이터 센터에 배포된 CCR 및 퀸시 데이터 센터에 배포된 SCR (더 크게 보려면 이미지를 클릭하십시오.)

그림 3에서는 각각 고유의 Active Directory® 사이트가 있는 레드먼드와 퀸시라는 두 데이터 센터가 포함된 기업 배포를 보여 줍니다. 레드먼드 사이트는 주(프로덕션) 데이터 센터에 있고 퀸시 사이트는 보조(백업) 데이터 센터에 있습니다. 레드먼드에는 데이터 센터 내 중복성을 제공하기 위해 CCR이 배포되었습니다. 퀸시에는 사이트 복구 기능을 위해 Exchange 2007에 필요한 인프라 요소와 함께 대기 클러스터에 SCR 대상이 구성되었습니다. 클라이언트 액세스와 허브 전송 서버, Active Directory와 DNS 서버, 인터넷 액세스 등의 추가 인프라 요소는 전용 리소스일 수도 있고 비전용 리소스일 수도 있습니다. 전용 리소스는 데이터 센터에 상주하는 데이터 센터 사용자만 지원하도록 지정된 리소스입니다. 비전용 리소스는 로컬 데이터 센터의 사용자와 함께 다른 위치의 사용자도 지원하는 리소스입니다. 조직의 필요에 맞게 리소스를 전용으로 사용할지 비전용으로 사용할지를 결정해야 합니다. 전용 및 비전용 리소스에 대한 자세한 내용은 Exchange Server 2007 도움말 항목 "Site Resilience Configurations"(technet.microsoft.com/bb201662.aspx)를 참조하십시오. 새로운 유형의 MNS(주 노드 집합) 쿼럼 사용도 유의해서 보십시오. Exchange Server 2007에서는 CCR이 기존의 Voter 노드 대신 FSW(파일 공유 감시) 기능이 있는 MNS 쿼럼을 사용합니다(그림 3 참조).

그림 4의 복구 기능을 염두에 두고 설계된 CCR/SCR 환경은 EXCLUS1 서버에서 호스팅되는 사서함과 서비스에 여러 계층의 중복성을 제공함으로써 작은 규모의 오류는 물론 큰 규모의 치명적 오류로부터 사서함을 보호합니다.

그림 4 SCR을 사용하여 저장소 그룹 간을 복제하는 
독립 실행형 사서함 서버 (더 크게 보려면 이미지를 클릭하십시오.)

소규모 및 중간 규모 조직에서도 SCR을 사용함으로써 혜택을 얻을 수 있습니다. 예를 들어 그림 4에서 볼 수 있듯이 조직에서 두 개의 독립 실행형 사서함 서버(EXMBX1과 EXMBX2)를 배포한 다음 SCR을 사용하여 한 사서함 서버에서 다른 사서함 서버로 저장소 그룹 일부 또는 모두를 복제할 수 있습니다.

이 예에서 EXMBX1과 EXMBX2는 둘 다 다섯 개의 활성 저장소 그룹이 있는 프로덕션 서버입니다. 각 저장소 그룹은 SCR 원본이고 해당 SCR 대상은 다른 서버에 있습니다. 저장소에 오류가 발생하거나 SCR 원본으로 구성된 활성 저장소 그룹을 사용할 수 없는 다른 상황이 발생할 경우 Exchange 관리 셸의 몇 가지 관리 작업을 사용하여 SCR 대상 복사본을 신속하게 활성화할 수 있습니다. Microsoft® Office Outlook® 2007과 Exchange 2007의 데이터베이스 이식 및 자동 검색 기능을 사용하면 활성 저장소 그룹(또는 드물지만 여러 개의 활성 저장소 그룹)이 손실될 경우 가동 중지 시간을 단 몇 분으로 최소화할 수 있습니다.

SCR 원본 및 대상

LCR 및 CCR과 마찬가지로 SCR에서도 저장소 그룹의 활성 복사본 및 수동 복사본 개념을 사용합니다. 하지만 SCR에서는 활성과 수동 복사본이 각각 SCR 원본과 대상을 의미합니다. 물론, SCR 원본과 대상은 저장소 그룹 복사본입니다. SCR에서는 복구 저장소 그룹을 사용하도록 설정할 수 없습니다.

SCR의 시작점(SCR 원본)은 독립 실행형 사서함 서버의 저장소 그룹이거나 단일 복사본 클러스터 또는 CCR 환경에서는 클러스터된 사서함 서버의 저장소 그룹입니다. 클러스터된 사서함 서버를 SCR 원본으로 사용할 수는 있지만 SCR 자체는 클러스터된 솔루션이 아니므로 Windows 클러스터 서비스는 필요하지 않습니다. SCR의 끝점(SCR 대상)은 독립 실행형 사서함 서버이거나 사서함 역할은 설치되어 있지만 클러스터된 사서함 서버는 구성되어 있지 않은 장애 조치(failover) 클러스터의 노드입니다.

원본과 대상의 관계

각 SCR 원본 저장소 그룹에는 여러 SCR 대상이 있을 수 있습니다. 예를 들어 원본에 원본과 같은 데이터 센터에 있는 첫 번째 대상과 원본과 다른 데이터 센터에 있는 두 번째 대상이 있을 수 있습니다. 하지만 원본당 대상을 5개 이상은 사용하지 않는 것이 좋습니다. 대상을 5개 이상 사용하려는 경우 SCR 원본 서버의 메모리, CPU 및 디스크 리소스가 받는 영향을 평가하여 이에 맞게 계획을 수립해야 합니다. 각 SCR 대상 컴퓨터는 여러 개의 원본 서버를 둘 수 있습니다. 원본과 대상 컴퓨터는 모두 Exchange 2007 서비스 팩 1을 실행해야 합니다. OS는 Windows Server® 2008이나 Windows Server 2003 SP2 등 Exchange 2007 서비스 팩 1에서 지원하는 버전 중 하나를 사용해야 합니다. 하지만 사용하는 운영 체제에 관계없이 SCR은 OS를 교차 지원하지 않으므로 SCR 원본의 운영 체제와 원본의 모든 SCR 대상에서 사용하는 운영 체제가 일치해야 합니다. 따라서 SCR 원본에서 Windows Server 2003을 실행하면 해당 원본의 모든 SCR 대상에서도 Windows Server 2003을 실행해야 합니다.

SCR은 Exchange 2007 Standard Edition에서 사용할 수 있습니다. SCC 또는 CCR 환경의 클러스터된 사서함 서버를 SCR 원본으로 사용하는 경우에는 Exchange 2007 Enterprise Edition이 있어야 합니다. 각 SCR 대상에서 지원하는 최대 인스턴스 수는 Enterprise Edition을 사용하는 경우 50개(50개의 복제된 저장소 그룹)이고, Standard Edition을 사용하는 경우 5개입니다.

SCR 대상에도 만족해야 하는 요구 사항이 있습니다. 첫째, 원본과 대상 컴퓨터가 같은 Active Directory 도메인에 있어야 합니다. Active Directory 사이트는 달라도 됩니다. 둘째, SCR을 통해 복제되는 각 저장소 그룹에 대해 원본과 해당하는 모든 대상의 데이터베이스 및 로그 파일 경로가 일치해야 합니다. 마지막으로, 노드나 서버가 SCR 대상으로 구성되어 있으면 SCR 대상 컴퓨터의 저장소 그룹에 LCR을 사용하도록 설정할 수 없으며 클러스터된 사서함 서버를 대기 장애 조치(failover) 클러스터에 추가할 수 없습니다.

SCR과 CCR 및 LCR 비교

그림 5에서 볼 수 있듯이 SCR은 LCR 및 CCR에서 사용하는 것과 같은 로그 전달 및 재생 기술을 사용하여 새로운 배포 옵션과 구성을 제공합니다. LCR 및 CCR과 마찬가지로 SCR을 사용하도록 설정한 저장소 그룹에는 데이터베이스가 둘 이상 포함될 수 없습니다. 또한 Exchange 조직에 공용 폴더 데이터베이스가 둘 이상 있는 경우 공용 폴더 데이터베이스에 SCR을 사용할 수 없습니다.

그림 5 장애 조치(failover) 클러스터의 다른 서버 또는 패시브 노드에 
로그를 전달하는 SCR

한 가지 큰 차이점은 SCR은 저장소 그룹당 여러 대상을 지원하지만 LCR과 CCR은 대상(수동 복사본)을 하나만 지원한다는 것입니다. 또 다른 큰 차이점은 CCR 및 LCR과는 달리 SCR 복사본은 백업할 수 없다는 것입니다. SCR을 사용하는 경우, SCR 원본 저장소 그룹에 대해 지원되는 백업을 수행하면 SCR 대상의 데이터베이스 헤더가 업데이트되고 로그 파일이 잘립니다. CCR 및 LCR을 사용하는 경우에는 SCR 원본 저장소 그룹의 활성 또는 수동 복사본에 대해 백업을 수행할 때 SCR 대상의 데이터베이스 헤더가 업데이트되고 로그 파일이 잘립니다.

LCR 및 CCR과 마찬가지로 SCR의 로그 전달은 연속적이며 끌어오기 모델을 사용합니다. 새 로그 파일이 닫히고 이 파일의 이름이 다음 생성 시퀀스 로그 파일 번호로 지정되면 곧바로 SCR 대상 컴퓨터에서 실행되는 Microsoft Exchange Replication Service가 SCR 원본 컴퓨터에서 닫힌 트랜잭션 로그 파일을 끌어와 검사하고 유효성을 확인한 다음 이를 SCR 대상 컴퓨터의 대응되는 저장소 그룹 로그 파일 폴더로 이동합니다.

재생 지연 시간

로그 파일이 SCR 대상 컴퓨터로 복사된 후 SCR은 LCR과 CCR이 하지 않는 작업을 수행합니다. SCR은 로그 파일을 데이터베이스 복사본에 곧바로 재생하지 않습니다. 대신 SCR은 50개 로그 파일을 24시간 동안 재생 지연하는 기본 제공 재생 지연 기능을 실행합니다. 기본 제공되는 지연 시간에 추가 지연 시간을 지정할 수도 있습니다. 재생 작업 지연은 다양한 시나리오에서 유용합니다. 예를 들어 활성 데이터베이스에 논리적인 손상이 발생할 경우 지연 기능을 통해 SCR 대상 데이터베이스의 논리적인 손상을 막을 수 있습니다.

관리자는 ReplayLagTime이라는 매개 변수를 통해 재생 지연 시간을 설정할 수 있습니다. 이 매개 변수는 Exchange 복제 서비스가 SCR 대상 컴퓨터로 복사된 로그 파일을 재생하기 전에 대기해야 할 시간을 지정합니다. 형식은 일.시간:분:초이고, 기본값은 24시간입니다. 설정할 수 있는 최대값은 7일이고, 최소값은 0초입니다. 값을 0초로 설정하면 50개 로그 파일에 대한 기본 지연 외에는 로그 재생 작업이 지연되지 않습니다.

ReplayLagTime 외에도 Exchange에는 ReplayLagTime 값에 관계없이 50개 로그 파일의 재생을 지연하는 기본 제공 지연 기능이 하드코드되어 있습니다. Exchange에서는 ReplayLagTime 또는 x개 로그 파일(여기서 x=50임) 중 더 큰 값을 기준으로 로그 파일 재생 시기를 결정합니다. 이는 연속 복제를 사용하는 SCR 원본(예: CCR 환경의 클러스터된 사서함 서버)에서 장애 조치(failover)가 발생하여 Restore-StorageGroupCopy cmdlet을 사용하여 하나 이상의 저장소 그룹을 온라인으로 전환해야 하는 경우에 저장소 그룹을 다시 시드할 필요가 없도록 추가적인 안전망 역할을 합니다. 시드는 ESE(Extensible Storage Engine) 스트리밍 백업 API를 사용하여 SCR 대상 컴퓨터에 SCR 원본 데이터베이스의 온라인 복사본을 만드는 프로세스입니다. SCR 대상에 대한 재생 작업을 지연하면 SCR 원본에 대한 손실 장애 조치(failover)가 발생하는 경우 SCR 원본에 대한 데이터 손실 특성상 두 개의 복사본이 시간상 서로 근접하게 되므로 SCR 복사본을 다시 시드해야 하는 경우가 최소화됩니다.

자르기 지연 시간

Exchange 2007 RTM 버전에서는 연속 복제 환경에서 로그 파일이 백업되고 데이터베이스 복사본에 재생된 후에야 로그 파일을 삭제할 수 있는 규칙이 적용됩니다. SCR을 사용할 때는 이 규칙이 수정됩니다. 여러 데이터베이스 복사본의 개념이 도입된 SCR에서는 로그 파일이 모든 SCR 대상 컴퓨터에서 검색되는 즉시 SCR 원본 컴퓨터에서 잘릴 수 있습니다. SCR 대상 복사본의 로그 재생 지연 시간이 길게 구성될 수 있으므로 SCR 원본 서버에서 로그 자르기 작업은 모든 로그가 모든 SCR 대상으로 재생될 때까지 기다리지 않습니다.

TruncationLagTime이라는 새 매개 변수를 사용하여 로그 자르기에 대해 추가 지연을 설정할 수도 있습니다. 이 매개 변수를 사용하면 SCR 대상 컴퓨터에 복사되어 데이터베이스 복사본에 재생된 로그 파일을 Exchange 복제 서비스가 자르기 전에 대기해야 할 시간(일.시:분:초 형식)을 지정할 수 있습니다. 이 시간은 로그 파일이 데이터베이스 복사본에 성공적으로 재생된 후 즉시 시작됩니다. 최대값은 7일이고, 최소값은 0초입니다. 값을 0초로 설정하면 로그 자르기 작업이 지연되지 않습니다.

SCR 환경에서는 백그라운드 스레드가 3분마다 실행되어 잘라야 할 로그 파일이 있는지 여부를 확인합니다. 로그 파일 생성 시퀀스가 저장소 그룹에 대한 로그 파일 검사점 이전이고 로그 파일이 ReplayLagTime과 TruncationLagTime을 더한 것보다 오래되었으면 SCR 대상의 로그 파일이 잘립니다.

SCR로 확장된 LCR 또는 CCR 환경에서는 로그 파일이 백업되었고, 로그 파일 생성 시퀀스가 저장소 그룹에 대한 로그 파일 검사점 이전이고, 저장소 그룹의 수동 복사본이 로그 파일이 잘릴 수 있는 상태에 있고, 모든 SCR 대상에서 로그 파일을 검사한 경우의 네 가지 조건을 모두 충족할 때 SCR 대상의 로그 파일이 잘립니다.

SCR 설정 및 관리

SCR은 Exchange 관리 셸의 Enable-StorageGroupCopy cmdlet을 통해 사용하도록 설정할 수 있습니다. SP1에서는 이 cmdlet에 몇 가지 새로운 매개 변수가 추가되었습니다. 앞에서 설명한 것처럼 ReplayLagTime과 TruncationLagTime을 사용하여 SCR 대상의 일부 동작을 제어할 수 있습니다. SeedingPostponed라는 또 다른 매개 변수를 사용하면 SCR 대상의 초기 시드 작업을 건너뛸 수 있습니다. 시드 지연은 다양한 상황에서 유용합니다. 예를 들어 SCR을 사용하도록 설정할 저장소 그룹의 데이터베이스가 100GB라고 가정해 보십시오. 시스템 사용량이 많은 프로덕션 시간대에 100GB나 되는 데이터를 네트워크를 통해 전송하고 싶지는 않을 것입니다. 이때 SeedingPostponed 매개 변수를 사용하면 SCR은 곧바로 사용할 수 있도록 설정하되 시드 작업은 나중에 수행할 수 있습니다. 나중에 준비가 되면 Update-StorageGroupCopy cmdlet을 사용하여 수동으로 SCR 대상을 시드할 수 있습니다.

위에서 언급한 매개 변수는 선택적이지만 Enable-StorageGroupCopy의 StandbyMachine 매개 변수는 SCR을 사용하는 데 반드시 필요합니다. 이 매개 변수는 SCR 대상이 포함될 컴퓨터의 이름을 지정합니다. 이 매개 변수의 값은 SCR을 사용하도록 설정하는 저장소 그룹의 msExchStandbyCopyMachines 특성 값의 일부로 설정됩니다. msExchStandbyCopyMachines 특성은 Exchange 2007 SP1이 Exchange 조직에 설치될 때 Active Directory 스키마에 추가되는 다중 값 유니코드 문자열입니다. SP1을 사용하려면 Active Directory의 스키마 업데이트가 필요한 것도 바로 이러한 이유 때문입니다.

StandbyMachine 매개 변수는 SCR을 사용하는 데 있어서 중요한 매개 변수이며, SCR 대상을 사용하도록 설정하고 관리하는 데 이 매개 변수를 사용하도록 SP1에서 몇 가지 cmdlet이 업데이트되었습니다. 그림 6에서는 업데이트된 cmdlet에 대해 설명합니다.

Figure 6 StandbyMachine 매개 변수를 사용하는 Cmdlet

Cmdlet
설명

Disable-StorageGroupCopy
저장소 그룹에 대해 SCR 대상을 사용하지 않도록 설정합니다.

Get-StorageGroupCopyStatus
SCR 대상의 현재 상태를 확인합니다.

New-StorageGroup
Enable-StorageGroupCopy cmdlet을 사용하여 SCR을 사용하도록 별도로 설정할 필요 없이 새 SCR 사용 가능 저장소 그룹을 만듭니다.

Restore-StorageGroupCopy
SCR을 사용하지 않도록 설정하고 복구 절차의 일부로 Mount-Database 작업을 사용하여 SCR 대상 데이터베이스를 탑재 가능한 상태로 만듭니다.

Resume-StorageGroupCopy
SCR이 일시 중단된 저장소 그룹에 대해 연속 복제를 다시 시작하는 데 사용됩니다.

Suspend-StorageGroupCopy
SCR을 사용하도록 설정된 저장소 그룹에 대해 연속 복제 작업을 일시 중단합니다.

Update-StorageGroupCopy
SCR 대상 저장소 그룹을 시드하거나 다시 시드하는 데 사용됩니다.

SCR 대상 활성화

SCR에서는 원본 데이터가 손실되거나 사용할 수 없게 되면 사용할 수 있는 데이터의 최신 복사본을 하나 이상 제공합니다. SCR 대상 복사본을 가져와 프로덕션 데이터베이스로 다시 제공하는 프로세스를 활성화라고 합니다. 활성화는 복구 프로세스의 일부로 수행되며 데이터베이스 이식 또는 두 가지 설치 복구 옵션(독립 실행형 서버 복구의 경우 /m:RecoverServer, 클러스터된 사서함 서버 복구의 경우 /RecoverCMS) 중 한 가지 형태로 이루어집니다.

SCR 사용 방법

가상의 한 회사에서 SCR과 데이터베이스 이식을 통해 사서함 데이터베이스 오류가 발생했을 때 데이터베이스를 복구하는 방법을 살펴보겠습니다. 프로덕션 데이터베이스가 손상되었음을 발견한 후 관리자가 데이터베이스 이식을 통해 SCR 대상 데이터베이스를 활성화합니다.

이 조직에서는 Exchange 2007 SP1을 배포했으며 SCR을 사용하여 원격 사서함 서버에 저장소 그룹의 복사본을 제공하기로 결정했습니다. 원본과 대상 사서함 서버는 모두 같은 Active Directory 사이트에 있고 Active Directory 통합 DNS 서버를 사용하도록 구성되었습니다. Active Directory 복제 간격은 15분으로 구성되었습니다.

SCR 설정 및 복구 준비

MBX1이라는 단일 데이터베이스가 포함된 SG1이라는 단일 저장소 그룹에 대해 트랜잭션 로그 파일을 복제하도록 SCR이 구성되었습니다. 저장소 그룹 파일과 데이터베이스 파일의 경로는 각각 C:\SG1과 C:\SG1\MBX1.EDB입니다. 이 예에서 EXMBX1은 SCR 원본이고, EXMBX2는 SCR 대상입니다. 원본과 대상은 다음과 같이 구성되었습니다.

코드 복사

Enable-StorageGroupCopy EXMBX1\SG1 -StandbyMachine EXMBX2

SCR을 사용하도록 설정한 후 Get-StorageGroupCopyStatus cmdlet을 사용하여 SG1에 대한 SCR의 상태를 확인했습니다.

코드 복사

Get-StorageGroupCopyStatus EXMBX1\SG1 -StandbyMachine EXMBX2

SCR 대상 활성화 프로세스 도중 시간을 절약하기 위해 EXMBX2는 데이터베이스 이식 작업의 일부로 사용될 SG1PORT라는 저장소 그룹과 MBX1PORT라는 데이터베이스로 미리 구성되었습니다. SG1PORT와 MBX1PORT는 SCR 대상의 저장소 그룹 및 데이터베이스 파일과 별개입니다. 따라서 SCR 대상 경로와 충돌하지 않는 임시 경로를 사용하여 SG1PORT 및 MBX1PORT에 대한 경로가 구성되었습니다. SG1PORT와 MBX1PORT는 데이터베이스 이식성 개체로만 사용되며 SG1PORT에 대한 실제 저장소 그룹과 데이터베이스 파일은 필요하지 않습니다. 이 때문에 관리자가 MBX1PORT를 분리하고 저장소 그룹의 모든 파일을 삭제합니다. 저장소 그룹과 데이터베이스 개체는 이후 복구 프로세스 중에 데이터베이스 이식에 사용되므로 Active Directory에 그대로 남겨 둡니다.

활성화 및 복구

SCR 원본 데이터베이스가 물리적으로 손상되었음을 나타내는 응용 프로그램 이벤트 로그 항목이 있습니다. SG1에 대해 SCR을 사용하도록 설정되어 있으므로 관리자는 SG1에 대한 SCR 대상 데이터베이스의 수동 활성화를 수행하고, 데이터베이스 이식을 통해 데이터의 가용성을 복원하기로 결정했습니다. SCR 대상 복사본의 활성화는 다음 cmdlet을 사용하여 SG1에서 MBX1을 분리하는 것으로 시작합니다.

코드 복사

Dismount-Database EXMBX1\SG1\MBX1

그러면 SCR 대상 데이터베이스가 탑재 가능한 상태가 되고 원래 MBX1에 있었던 사서함이 MBX1PORT로 이동됩니다.

SCR을 사용하지 않도록 설정하고 SCR 대상 데이터베이스를 탑재 가능한 상태로 만드는 프로세스에서는 Restore-StorageGroupCopy cmdlet을 실행하는 작업이 수행됩니다. 이 작업은 저장소 그룹의 데이터베이스를 탑재 가능으로 표시하고 저장소 그룹에 데이터베이스를 탑재하여 발생한 데이터 손실(있는 경우)에 대한 보고서를 제공합니다. 또한 저장소 그룹의 활성 복사본에 의해 생성된 모든 로그 파일이 수동 복사본의 저장소 그룹 파일 위치에 있는지 확인합니다. 누락된 로그 파일이 있으면 로그 파일을 복사하려고 시도합니다. SCR 대상 데이터베이스를 탑재 가능한 상태로 만들기 위해서는 다음 cmdlet을 사용합니다.

코드 복사

Restore-StorageGroupCopy EXMBX1\SG1 -StandbyMachine EXMBX2

이 예에서는 SCR 원본 저장소 그룹에서 로그 파일을 복사할 수 있습니다. SCR 원본 컴퓨터가 다운되는 등의 이유로 로그 파일을 사용할 수 없는 경우 Restore-StorageGroupCopy 작업에 Force 매개 변수를 추가해야 합니다. Restore-StorageGroupCopy는 누락된 로그 파일을 복사하기 위해 항상 SCR 원본에 연결하려고 하므로 이 매개 변수를 추가하지 않으면 SCR 원본을 사용할 수 없는 경우 Restore-StorageGroupCopy 작업이 실패하고 데이터베이스가 탑재 가능한 상태가 되지 않습니다. Force 매개 변수를 추가하면 Restore-StorageGroupCopy 작업에서 원본 파일을 사용할 수 없음을 인식하여 SCR 원본으로 연결을 시도하지 않고 SCR 대상 데이터베이스를 탑재 가능한 상태로 만듭니다.

Restore-StorageGroupCopy 명령이 완료되면 관리자는 데이터베이스가 완전하게 종료된 상태인지 확인해야 합니다. 데이터베이스가 부적절한 종료 상태에 있으면(technet.microsoft.com/aa996757.aspx 참조) 완전하게 종료된 상태로 만들어야 합니다. SCR 원본(EXMBX1\SG1) 및 데이터베이스 이식에 사용되는 SCR 대상(SG1PORT)의 저장소 그룹(EXMBX2\SG1PORT)에 대해 저장소 그룹의 로그 파일 접두사(예: E00 또는 E01)가 같을 경우 복구 모드에서 Eseutil을 실행할 필요가 없으며 마지막 데이터베이스 탑재 작업 중 복제된 모든 로그 파일이 재생된 후 데이터베이스가 완전하게 종료된 상태가 됩니다. 데이터베이스가 완전하게 종료된 상태가 되지 않으면 데이터베이스에 대해 Eseutil(Exchange Server Database Utilities) 복구 모드(Eseutil /r)를 실행해야 합니다.

데이터베이스가 완전하게 종료된 상태가 되면 저장소 그룹 파일 및 데이터베이스 파일의 새 위치로 Active Directory를 업데이트하는 두 개의 명령을 실행할 수 있습니다. 다음 두 명령은 SG1PORT 및 MBX1의 원래 경로를 준비된 저장소 그룹 및 데이터베이스(SG1PORT 및 MBX1PORT)의 경로로 변경합니다.

코드 복사

Move-StorageGroupPath EXMBX2\SG1PORT -SystemFolderPath C:\SG1 -LogFolderPath C:\SG1 –ConfigurationOnly

Move-DatabasePath EXMBX2\SG1PORT\MBX1PORT -EdbFilePath C:\SG1\MBX1PORT.EDB –ConfigurationOnly

Active Directory에서 해당 개체의 구성 설정만 업데이트되도록 위 명령에 –ConfigurationOnly 매개 변수를 반드시 포함해야 합니다. SCR에서 데이터를 이미 EXMBX2의 C:\SG1로 복제했으므로 데이터나 파일이 이동되지 않으며 그럴 필요도 없습니다.

다음 단계로 복원 작업 중 덮어쓸 수 있도록 데이터베이스(MBX1PORT)를 구성합니다. 이 작업은 Exchange 관리 콘솔의 데이터베이스 개체 속성에서 "복원 시 이 데이터베이스 덮어쓰기 가능" 설정 확인란을 선택하거나 Exchange 관리 셸에서 다음 명령을 사용하여 수행할 수 있습니다.

코드 복사

Set-MailboxDatabase EXMBX2\SG1PORT\MBX1PORT -AllowFileRestore:$true

덮어쓸 수 있도록 데이터베이스를 구성했으면 그 다음 단계로 다음 명령을 사용하여 데이터베이스를 탑재합니다.

코드 복사

Mount-Database EXMBX2\SG1PORT\MBX1PORT

데이터베이스를 탑재한 후에는 SCR 원본 데이터베이스(SG1\MBX1)의 사서함을 EXMBX2의 MBX1PORT를 가리키도록 이동해야 합니다. Get-Mailbox cmdlet을 실행하고 출력을 Move-Mailbox cmdlet으로 연결하기만 하면 됩니다. 이 프로세스 중에 Move-Mailbox cmdlet으로 연결된 Get-Mailbox cmdlet의 출력에 Exchange 시스템 수행자 및 시스템 사서함이 포함되지 않아야 합니다. 이러한 사서함 개체는 이동할 필요가 없으며 이동해서도 안 됩니다. 다음 명령을 실행하여 시스템 사서함을 제외한 모든 사용자 사서함을 이동합니다.

코드 복사

Get-Mailbox -Database EXMBX1\SG1\MBX1 |where {$_.ObjectClass -NotMatch '(SystemAttendantMailbox| ExOleDbSystemMailbox)'}| Move-Mailbox -ConfigurationOnly -TargetDatabase EXMBX2\SG1PORT\MBX1PORT

이제 MBX1PORT에 대한 클라이언트 액세스가 가능합니다. 하지만 사용자가 EXMBX1\SG1\MBX1에서 EXMBX2\SG1PORT\MBX1PORT로 이동된 자신의 사서함에 실제로 액세스할 수 있는지 여부는 Active Directory 복제 지연에 따라 달라집니다. 즉, 디렉터리 서버의 수에 따라 업데이트가 환경 전체에 전파되는 데 다소 시간이 걸릴 수도 있습니다. 클라이언트 액세스 방법도 문제가 될 수 있습니다. Outlook 2007을 실행하는 메시징 클라이언트와 Outlook을 실행하지 않는 클라이언트는 사용자의 클라이언트 액세스 서버에서 사용하는 디렉터리 서버가 새 경로로 업데이트된 후 사용자 사서함에 액세스할 수 있습니다. Outlook 2003 및 이전 버전을 실행하는 메시징 클라이언트의 경우 사용자의 데스크톱 메시징 프로필이 새 서버 이름으로 업데이트되어야 합니다.

최종 단계

클라이언트가 사서함 및 사서함 데이터에 액세스할 수 있게 되면 마지막으로 SCR을 사용하도록 다시 설정하여 중복성이 제공되도록 해야 합니다. 이 작업은 EXMBX1에서 나머지 저장소 그룹과 데이터베이스 파일을 제거하여 수행할 수 있습니다. 파일을 제거하고 나면 EXMBX1\SG1\MBX1의 경로를 임시 위치로 이동하고 EXMBX1을 EXMBX2의 SCR 대상으로 만들 수 있습니다.