Windows Server 2008에 클러스터 연속 복제 설치

적용 대상: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1

마지막으로 수정된 항목: 2008-12-19

Windows Server 2008에서 CCR(클러스터 연속 복제)을 배포하는 프로세스와 Windows Server 2003에 CCR을 배포하는 프로세스는 비슷하지만 몇 가지 중요한 차이점이 있습니다. CCR을 배포하기 전에 클러스터 연속 복제를 충분히 검토하여 주십시오. 이 외에도 클러스터 연속 복제 계획에 지정된 모든 요구 사항을 반드시 만족해야 합니다.

Windows Server 2008에 CCR을 설치하는 작업은 여러 단계로 진행합니다.

1. 하드웨어 설치 구성, 클러스터 네트워크 형성 및 구성 시작

2. 클러스터 만들기, 첫 번째 노드로 시작한 후 두 번째 노드 시작

3. 클러스터 네트워크 및 누락된 클러스터 하트비트 허용 범위 구성

4. 파일 공유 감시 구성 및 보안

5. 활성 및 수동 사서함 서버 역할을 클러스터에 설치. CMS(클러스터된 사서함 서버)는 활성 사서함 서버 역할을 설치하는 동안에 만들어집니다.

   참고

   각 단계를 완료한 뒤에 다음 단계를 시작하도록 하십시오. 모든 단계가 완료되면 프로덕션에 들어가기 전에 CCR 솔루션을 확인하십시오.

수행해야 하는 일부 사후 설치 작업도 있습니다.

• 장애 조치(failover) 제어 설정 조정

• 전송 쓰레기 수거통의 기본 구성 조정

• 클러스터의 노드 간에 CMS를 이동할 수 있는지 여부 확인

• 연속 복제 작업에 여러 네트워크 사용

아래에 참조된 절차를 수행하기 전에 먼저 사용할 컴퓨터에 Windows Server 2008에 필요한 운영 체제 구성 요소가 설치되어 있는지 확인해야 합니다. Windows Server 2008에 Microsoft Exchange 필수 구성 요소를 설치하는 방법에 대한 자세한 단계는 Windows Server 2008 또는 Windows Vista에 Exchange 2007 SP1 및 SP2 필수 구성 요소를 설치하는 방법을 참조하십시오.

다음 섹션에서는 각 설치 단계를 보다 자세하게 살펴봅니다.

네트워크 형성 및 구성

CMS를 Windows Server 2008의 2개 노드 CCR 환경에 만들 때는 사용할 수 있는 IP 주소의 수가 충분해야 합니다. Windows Server 2008 장애 조치 클러스터링에서는 레거시 클러스터에서 사용하던 방법과는 다른 새 네트워킹 기능을 사용합니다. 예를 들어, Windows Server 2008 장애 조치 클러스터는 여러 서브넷, DHCP(Dynamic Host Configuration Protocol) IPv4(Internet Protocol Version 4) 및 IPv6을 지원합니다. Windows Server 2008 장애 조치(failover) 클러스터를 실행하는 경우 Microsoft Exchange Server 2007 SP1(서비스 팩 1)에서는 두 서브넷 간에 지리적으로 분산된 장애 조치(failover)용 클러스터를 지원합니다. CCR 환경의 사서함 서버와 두 개의 SCC(단일 복사본 클러스터)를 지원합니다.

Windows Server 2008 장애 조치(failover) 클러스터링을 시작하면서 개별 클러스터 노드를 라우팅된 별도의 네트워크에 배치할 수 있습니다. 이를 위해서는 IP 주소 리소스(예: 네트워크 이름 리소스)를 사용하는 리소스를 통해 OR 논리를 구현해야 합니다. 그 이유는 각 클러스터에서 인식하는 모든 네트워크에 해당 클러스터 노드가 로컬 방식으로 직접 연결될 가능성이 적기 때문입니다. 이를 통해 서비스 또는 응용 프로그램이 원격 노드로 장애 조치될 때 IP 주소와 네트워크 이름 리소스를 온라인 상태로 손쉽게 전환할 수 있습니다.

DNS(Domain Name System)가 동적 업데이트에 대해 구성되어 있으면 네트워크 이름 리소스와 관련된 모든 온라인 IP 주소는 온라인 상태의 IP 주소 리소스가 클라이언트에 먼저 반환되도록 순서가 지정된 목록과 함께 이 DNS에 동적으로 등록됩니다. 클러스터 노드는 라우팅된 서로 다른 네트워크에 배치할 수 있으며 유니캐스트 UDP(사용자 데이터그램 프로토콜)를 통해 구현된 신뢰할 수 있는 세션 프로토콜을 사용하도록 통신 메커니즘이 변경되었으므로 지리적으로 분산된 클러스터에 대한 네트워킹 요구 사항은 더 이상 적용되지 않습니다. 따라서 조직은 VLAN(가상 LAN) 기술을 사용하지 않고도 두 곳의 실제 데이터 센터에 장애 조치(failover) 클러스터를 배포하여 두 위치의 클러스터 서브넷을 포괄할 수 있습니다.

IP 주소는 공용 네트워크와 개인 네트워크 모두에 필요합니다. 개인 및 공용 주소와 관련된 요구 사항은 다음과 같습니다.

• 개인 주소 각 노드마다 클러스터 개인 네트워크에 사용되는 각 네트워크 어댑터에 대해 하나의 IP 주소가 필요합니다. 정적 IPv4 주소 또는 동적으로 할당된 IPv6 주소를 사용할 수 있습니다. 공용 네트워크 중 하나와 동일한 서브넷이나 네트워크에 있지 않은 IP 주소를 사용해야 합니다. 서브넷 마스크가 255.255.255.0인 10.10.10.10 및 10.10.10.11을 노드의 개인 IP 주소로 사용하는 것이 좋습니다.

• 공용 주소 노드마다 혼합 네트워크라고도 하는 클러스터 공용 네트워크에 사용되는 각 네트워크 어댑터에 대해 하나의 IP 주소가 필요합니다. 또한 클라이언트와 관리자가 액세스할 수 있도록 장애 조치 클러스터와 CMS에 대해 IP 주소가 필요합니다. 개인 네트워크 중 하나와 동일한 서브넷이나 네트워크에 있지 않은 IP 주소를 사용해야 합니다. 정적 IPv4 주소, DHCP IPv4 주소 또는 정적 IPv6 주소를 사용할 수 있습니다.

  중요

  클러스터 네트워크에 사용되는 모든 네트워크 어댑터의 경우 동일한 버전의 TCP/IP를 사용해야 합니다. 즉, 모두 IPv4만 사용하거나 IPv4와 IPv6을 둘 다 사용해야 합니다.

클러스터된 사서함 서버에 대한 네트워크 유용한 정보

또한 클러스터 네트워크에 대해 이 유용한 정보를 따르는 것이 좋습니다.

• 의미 있는 이름 사용 클러스터를 만들면 클러스터 노드, 클러스터 네트워크 인터페이스, 클러스터 이름 및 CMS 이름에 대해 의미 있는 이름을 사용할 경우가 많습니다. 예를 들면 다른 Exchange 서버 및 클라이언트와 통신하는 데 사용되는 네트워크를 공용이라고 하고 클러스터 노드 간 통신에 사용되는 네트워크를 개인이라고 할 수 있습니다. 토폴로지 맵을 검토할 필요 없이 서로 관련이 있는 이름을 사용합니다. 또 다른 유용한 규칙은 클러스터의 노드를 CMS 이름과 연관시키는 것입니다. 예를 들어 CMS와 두 노드에 대해 각각 mbx01, mbx01-node1 및 mbx01-node2를 사용합니다.

• 개인 네트워크 인터페이스에 개인 IP 주소 사용   각 노드의 개인 네트워크 인터페이스에 사용할 수 있는 IP 주소 범위 및 서브넷 마스크 목록은 다음 표를 참조하십시오.

  개인 네트워크 인터페이스용 주소 범위 및 서브넷 마스크

  네트워크/노드	IP 주소 범위	서브넷 마스크
  개인/NODE1	10.10.10.10-255	255.255.255.0
  개인/NODE2	10.10.10.11-255	255.255.255.0

참고:

• 공용 네트워크에서 10.x.x.x 네트워크와 255.255.255.0 서브넷 마스크를 사용하는 경우, 대체 개인 네트워크 IP 주소와 서브넷 마스크를 사용하는 것이 좋습니다.

• 개인 네트워크에 대해 내결함성 어댑터 유형이나 팀을 사용하지 않는 것이 좋습니다. 개인 네트워크에 중복성이 필요하면 클러스터 전용으로 구성된 여러 개의 네트워크 어댑터를 사용합니다. 이 기술을 사용할 때는 펌웨어와 드라이버가 최신 버전인지 반드시 확인하십시오. 서버 클러스터의 호환성에 대한 자세한 내용은 네트워크 어댑터 제조업체에 문의하십시오. 장애 조치(failover) 클러스터 배포의 네트워크 어댑터 팀에 대한 자세한 내용은 Microsoft 기술 자료 문서 254101 네트워크 어댑터 팀과 서버 클러스터링을 참조하십시오.

장애 조치 클러스터 만들기

장애 조치 클러스터는 첫 번째 노드를 클러스터에 추가할 때 형성됩니다. 이러한 프로세스로 클러스터는 고유한 네트워크 이름과 고유한 네트워크 IP 주소를 갖게 됩니다. 클러스터의 네트워크 ID를 총체적으로 일컫는 네트워크 이름 및 IP 주소는 노드가 온라인/오프라인 상태로 변경될 때 클러스터의 노드 사이를 이동합니다. 일반적으로 클러스터의 네트워크 ID는 CMS 관리에 거의 사용되지 않습니다.

이전 버전의 장애 조치 클러스터 또는 Exchange 클러스터 배포에 익숙하면 CCR에 대한 클러스터 배포가 매우 다르다는 사실을 알게 됩니다. 클러스터 솔루션이 처음이면 배포가 일반 클러스터 구성보다 덜 복잡하다는 사실을 알게 됩니다.

클러스터 연속 복제를 위한 Windows Server 2008 장애 조치 클러스터를 만드는 방법의 지침에 따라 새 클러스터를 만들 수 있습니다.

추가 노드 추가

첫 번째 노드에 클러스터 서비스를 설치하면 두 번째 노드에서 클러스터 서비스를 설치하는 시간이 단축됩니다. 설치 프로그램이 첫 번째 노드에 구성된 네트워크 구성 설정을 사용하여 후속 노드의 네트워크 설정을 구성하기 때문입니다. 두 번째 노드를 추가하고 구성하기 전에 클러스터 구성을 확인해야 합니다. 명령 프롬프트에서 Cluster.exe group을 실행하여 클러스터 서비스가 실행 중이며 클러스터가 작동하는지 확인할 수 있습니다. 다음과 비슷한 출력이 나와야 합니다.

C:\>cluster group
Listing status for all available resource groups:
Group                   Node            Status
------------------ ---------------      ------
Cluster Group         <NODEName>        Online

또한 주의해야 하는 오류와 경고를 이벤트 로그에서 확인한 후에 계속 진행하는 것이 좋습니다. 클러스터에 두 번째 노드를 추가하는 방법에 대한 자세한 단계는 클러스터 연속 복제를 위한 Windows Server 2008 장애 조치 클러스터를 만드는 방법을 참조하십시오.

클러스터 네트워크 구성

클러스터 네트워킹 구성 요소는 두 노드 모두 클러스터에 추가된 후에 구성해야 합니다. 특히 클러스터 및 클라이언트 액세스가 가능하도록 네트워크를 구성하고 누락된 클러스터 하트비트에 대한 허용 범위 설정을 구성해야 합니다. 또한 의미 있는 이름을 사용하여 클러스터 네트워크의 이름을 바꾸는 것이 좋습니다.

다음 표에 클러스터 하트비트에 대해 클러스터 네트워크를 구성하는 데 사용할 수 있는 옵션이 자세히 나옵니다.

클러스터 네트워크 구성 옵션

CCR 환경에 배포된 CMS를 사용하려면 두 노드 모두에 최소한 두 개 이상의 네트워크 카드가 필요합니다. Exchange 2007 SP1에서는 클러스터 서비스에서 관리하고 클러스터에서 사용 및 연결할 수 있도록 설정(예: 혼합 네트워크로 구성)된 네트워크를 시드, 로그 전달, 다시 시드 등의 연속 복제 기능에 사용할 수 있습니다. 이 작업은 Exchange 2007 SP1에서 Enable-ContinuousReplicationHostName이라는 새 cmdlet를 사용하여 수행할 수 있습니다.

누락된 클러스터 하트비트에 대한 허용 범위 설정 구성

클러스터 통신 및 네트워크 우선 순위를 구성했으면 누락된 클러스터 하트비트에 대한 특정 허용 범위 설정을 구성하는 것이 좋습니다. 이렇게 하면 클러스터 노드 간의 네트워크 연결을 모니터링하는 클러스터 서비스가 사소한 중단을 허용하도록 구성되므로 네트워크 중단이 짧은 경우 장애 조치(failover)가 발생하지 않습니다. 모든 노드에 있는 개인 및 혼합 클러스터 네트워크가 10개의 누락된 하트비트를 담당하도록 구성하는 것이 좋습니다. 이 설정 수준은 약 12초에 해당합니다.

클러스터 네트워킹 구성 요소를 구성하는 방법에 대한 자세한 단계는 장애 조치(failover) 클러스터에 대해 클러스터 네트워크를 구성하는 방법을 참조하십시오.

클러스터된 사서함 서버 네트워크 이름 리소스의 TTL 설정 구성

중단 또는 복구 옵션을 사용하면 CMS에 할당된 IP 주소가 변경되는 배포 시나리오에는 두 가지가 있습니다.

• CMS가 여러 서브넷 환경에 배포되는 경우

• 대기 클러스터가 실패한 클러스터를 복구하는 데 사용되는 경우

이 두 시나리오에서 CMS의 이름은 변경되지 않지만 CMS에 할당된 IP 주소는 변경됩니다. IP 주소가 변경된 CMS와 통신하는 다른 서버 및 클라이언트는 DNS를 새 IP 주소로 업데이트하고 로컬 DNS 캐시를 업데이트한 후에야 CMS와의 통신을 다시 설정할 수 있습니다. DNS 변경 내용을 클라이언트와 다른 서버에 알리는 데 걸리는 시간을 최소화하려면 CMS의 네트워크 이름 리소스에 대한 DNS TTL 값을 5분으로 설정하는 것이 좋습니다.

기본적으로 클러스터 서비스에서 사용하는 네트워크 이름 리소스의 DNS TTL 값은 20분으로 설정되어 있습니다. DNS 관리 도구를 사용하여 DNS 데이터베이스에서 직접 호스트 이름에 대한 TTL 값을 수동으로 조정할 수 있지만 DNS의 네트워크 이름 등록을 새로 고칠 때마다 DNS 데이터베이스의 TTL 값이 덮어써 지고, 클러스터 서비스 기본값인 20분으로 설정됩니다. CMS를 시작 또는 이동하거나 오류 또는 장애 조치 후에 온라인 상태로 다시 설정할 때마다 DNS의 네트워크 이름 등록이 새로 고쳐집니다.

Windows Server 2008에서는 새 개인 속성이 장애 조치 클러스터의 네트워크 이름 리소스에 추가되었습니다. 이 새 속성은 HostRecordTTL이며 Cluster.exe를 사용하여 구성할 수 있습니다.

다중 서브넷 CMS나 대기 클러스터 배포에 사용할 CMS 네트워크 이름 리소스의 DNS TTL 값을 구성하는 방법에 대한 자세한 단계는 네트워크 이름 리소스에 대해 DNS TTL 값을 구성하는 방법을 참조하십시오.

클러스터 쿼럼 구성

클러스터 네트워크를 구성했으면 다음 단계는 노드 및 파일 공유 과반수 쿼럼 리소스를 사용하도록 장애 조치(failover) 클러스터를 구성하는 것입니다. 노드 및 파일 공유 과반수 쿼럼 모델을 사용하도록 장애 조치(failover) 클러스터를 구성하는 방법에 대한 자세한 단계는 노드 및 파일 공유 과반수 쿼럼을 구성하는 방법을 참조하십시오.

장애 조치(failover) 클러스터 유효성 검사

Windows Server 2008에는 장애 조치 클러스터의 상태 및 구성을 확인하는 데 사용할 수 있는 구성 유효성 검사 마법사라는 새 마법사가 있습니다. 클러스터에서 Exchange 2007을 설치하기 전에 먼저 이 마법사를 실행하는 것이 좋습니다. Exchange 2007을 설치하기 전에 먼저 이 마법사를 실행하면, Exchange를 설치하지 못하게 하는 클러스터 내의 구성 문제를 확인하고 해결할 수 있습니다.

구성 유효성 검사 마법사에는 클러스터가 Microsoft의 지원을 받는 데 필요한 요구 사항을 충족하는지 확인하기 위해 설계된 4개의 테스트 그룹이 있습니다. 이는 클러스터 솔루션에서 Designed for Windows Server 2008이라는 호환성 로고를 제공하는 데 필요한 요구 사항 이외의 요구 사항입니다.

4개의 테스트 그룹은 인벤토리, 네트워크, 저장소 및 시스템 구성입니다. CCR에서는 공유 저장소를 사용하지 않으므로 저장소 그룹 테스트를 실행할 필요가 없습니다. CCR용으로 설계된 장애 조치(failover) 클러스터 등 클러스터된 저장소 리소스가 없는 장애 조치(failover) 클러스터에 대해 저장소 그룹 테스트를 실행하면 실패합니다. CCR용으로 설계된 장애 조치(failover) 클러스터에는 공유 저장소가 없을 것이므로 모든 저장소 그룹 테스트의 실패를 안전하게 무시할 수 있습니다.

장애 조치(failover) 클러스터의 유효성을 검사하는 방법에 대한 자세한 단계는 장애 조치(failover) 클러스터 구성의 유효성 검사를 수행하는 방법을 참조하십시오.

클러스터된 사서함 서버 설치 및 구성

각 노드에서 몇 가지 단계를 실행하여 클러스터에 사서함 서버 역할을 설치할 수 있습니다. 클러스터를 형성하고 확인한 이후 및 파일 공유 미러링 모니터가 있는 MNS(주 노드 집합) 쿼럼을 사용하도록 클러스터를 구성한 이후에는 먼저 활성 노드에 사서함 서버 역할을 설치해야 합니다. 활성 노드에 사서함 서버 역할을 설치하는 방법에 대한 자세한 단계는 Windows Server 2008의 CCR 환경에서 활성 클러스터된 사서함 역할을 설치하는 방법을 참조하십시오.

활성 노드에 사서함 서버 역할과 CMS를 설치하고 첫 번째 저장소 그룹의 구성을 확인했으면 수동 노드에 사서함 서버 역할을 설치해야 합니다. 수동 노드에 사서함 서버 역할을 설치하는 방법에 대한 자세한 단계는 Windows Server 2008의 CCR 환경에서 수동 클러스터된 사서함 역할을 설치하는 방법을 참조하십시오.

사서함 서버 역할을 설치한 후에는 선택적으로 장애 조치 설정을 조정할 수 있습니다. 장애 조치 조정에 대한 자세한 내용은 클러스터 연속 복제의 탑재 및 장애 조치(failover) 설정을 조정하는 방법을 참조하십시오.

사후 설치 작업

사서함 서버 역할을 두 노드에 모두 설치하고 CMS를 만들었으면 몇 가지 사후 설치 작업을 수행해야 합니다. 다음과 같은 작업들이 포함됩니다.

• 연속 복제 작업에 여러 네트워크 사용

• 장애 조치(failover) 제어 설정 조정

• 전송 쓰레기 수거통의 기본 구성 조정

• 클러스터의 노드 간에 CMS를 이동할 수 있는지 여부 확인

연속 복제 작업에 여러 네트워크 사용

Microsoft Exchange Server 2007 RTM(Release to Manufacturing) 버전에서는 모든 로그 파일이 공용 네트워크를 통해 복사되고 시드됩니다. Exchange 2007 SP1에서는 혼합 네트워크로 구성된 클러스터 네트워크를 연속 복제 작업에 사용하도록 설정할 수 있습니다. 이 작업에는 저장소 그룹 시드, 다시 시드 및 로그 전달이 포함됩니다.

Exchange 2007 SP1에서는 혼합 네트워크로 지정된 클러스터 네트워크만 연속 복제에 사용할 수 있습니다. 혼합 네트워크는 클러스터(노드 간 통신)와 클라이언트 액세스 트래픽에 모두 구성되는 클러스터 네트워크입니다. 클라이언트 액세스(개인 네트워크라고도 부름)가 아닌 클러스터 액세스를 위해 구성된 클러스터 네트워크는 연속 복제에 사용할 수 없습니다.

혼합 네트워크를 통한 로그 전달의 지원은 Enable-ContinuousReplicationHostName이라는 새 cmdlet를 사용하여 구성됩니다. 마찬가지로 이 기능은 Disable-ContinuousReplicationHostName cmdlet를 사용하여 해제됩니다. CMS가 CCR 환경에 있으면, 관리자는 Enable-ContinuousReplicationHostName을 클러스터의 두 노드에서 실행하고 두 개의 IP 주소와 호스트 이름을 지정할 수 있습니다. 이 작업이 수행된 이후, 구성이 완료되고 혼합 네트워크가 작동되는지 확인되면 시스템은 로그 복사를 위한 혼합 네트워크를 무작위로 선택합니다.

연속 복제 작업에 클러스터 네트워크를 사용하는 방법에 대한 자세한 단계는 Windows Server 2008에서 로그 전달 및 시드에 중복 클러스터 네트워크를 사용하도록 설정하는 방법을 참조하십시오.

Update-StorageGroupCopy cmdlet를 사용하여 CCR 환경에서 시드 및 다시 시드 작업을 수행합니다. 이 cmdlet는 Microsoft Exchange 2007 SP 1(서비스 팩 1)에서 이제 DataHostNames라는 새 매개 변수도 포함하도록 확장되었습니다. 이 매개 변수는 시드 또는 다시 시드 작업에 사용할 네트워크를 지정하는 데에 사용됩니다. 값은 FQDN(정규화된 도메인 이름)이나 호스트 이름, 이 두 개의 이름으로 구성된 다중값 목록입니다. 이 이름 중 하나는 수동 노드를 식별해야 합니다.

장애 조치 제어 설정 조정

CCR에는 CMS의 장애 조치 작업을 제어할 수 있는 특성이 포함됩니다. Set-MailboxServer cmdlet를 사용하여 이 특성을 구성할 수 있습니다. 다음 두 가지 결정 알고리즘을 제어할 수 있도록 이러한 특성을 제공합니다.

• 알고리즘 1 알고리즘 1은 장애 조치(failover) 시 데이터베이스가 탑재되는지 여부를 제어합니다. 장애 조치 시 구성된 로그 양보다 손실이 적은 데이터베이스가 발견되는 경우 이 데이터베이스는 자동으로 탑재됩니다. 허용되는 손실 로그 수는 AutoDatabaseMountDial이라고 하는 값을 사용하여 구성할 수 있습니다. msExchDataLossForAutoDatabaseMount라는 Exchange Server 특성에 의해 Active Directory에 표시되는 이 매개 변수는 Lossless, Good Availability, Best Availability, 이 세 가지 값을 가집니다. Lossless는 0개 로그를 손실한 것이고, Good Availability와 기본값인 Best Availability는 각각 3개와 6개 로그를 손실한 것입니다. 이러한 값을 구성하는 방법에 대한 자세한 단계는 클러스터 연속 복제의 탑재 및 장애 조치(failover) 설정을 조정하는 방법을 참조하십시오.

• 알고리즘 2   알고리즘 2를 사용하면 기존 데이터를 오프라인보다 온라인 상태에 두는 것이 더 중요한지 여부를 결정할 수 있습니다. 알고리즘 1에 의한 데이터베이스 탑재가 실패하면 두 번째 확인을 수행하기 위한 시간을 설정할 수 있습니다. 대기 시간은 ForcedDatabaseMountAfter 특성으로 구성됩니다. 값은 시간 단위이며 기본값은 무제한입니다.

  중요

  ForcedDatabaseMountAfter 값에 도달하면 저장소 그룹 복사본이 1개 로그 뒤에 있든 10개 로그 뒤에 있든 1000개 로그 뒤에 있든 간에 데이터베이스가 탑재되며, 이로써 상당한 데이터 손실이 발생할 수 있습니다. 이러한 이유로, 발생할 수 있는 최대 데이터 손실량에 대해 SLA(서비스 수준 계약)에서 보증할 경우 이 매개변수를 사용하지 말아야 합니다.

전송 쓰레기 수거통 조정

전송 쓰레기 수거통은 LCR(로컬 연속 복제) 또는 CCR을 사용할 때 구성해야 하는 허브 전송 서버 역할의 기능으로 LCR과 CCR 환경에서만 사용됩니다. 전송 쓰레기 수거통은 갑작스런 정전 이후의 최근 전달된 메일을 전송합니다. 전송 쓰레기 수거통은 LCR 또는 CCR을 사용할 때 항상 켜져 있어야 합니다. 전송 쓰레기 수거통는 저장소 그룹당 사용할 수 있는 저장소의 양을 설정하고 전송 쓰레기 수거통에 메일을 보관하는 시간을 설정함으로써 조직 전체에서 사용됩니다.

허브 전송 서버는 CMS로 최근에 배달된 메일의 큐를 유지 관리합니다. 무손실이 아닌 장애 조치의 경우, CCR은 사이트의 모든 허브 전송 서버가 전송 쓰레기 수거통 큐에서 메일을 다시 전송하도록 자동으로 요청합니다. LCR 환경에서 다시 전송 요청은 Restore-StorageGroupCopy 작업의 일부로 수행됩니다. 다시 전송되면 정보 저장소에서는 자동으로 중복 메일을 삭제하고 손실된 메일을 다시 배달합니다. Set-TransportConfig cmdlet를 사용하여 저장소 그룹 수준에서 적용되는 전송 쓰레기 수거통의 기본 구성 설정을 변경할 수 있습니다. 또는 Exchange 2007 SP1에서는 Exchange 관리 콘솔을 사용하여 전송 쓰레기 수거통 값을 구성할 수 있습니다.

저장소 그룹별 최대 크기(MaxDumpsterSizePerStorageGroup 매개 변수)는 전송 가능한 최대 메시지의 1.5배 크기로 구성하는 것이 좋습니다. 예를 들어, 메시지의 최대 크기가 10MB이면 MaxDumpsterSizePerStorageGroup 매개 변수를 15MB로 구성해야 합니다. 최대 메시지 크기가 없는 조직의 경우 저장소 그룹별 최대 크기를 조직에서 전송하는 평균 메시지의 1.5배 크기로 구성하는 것이 좋습니다.

또한 저장소 그룹별 최대 보관 기간(MaxDumpsterTime 매개 변수)은 7일에 해당되는 07.00:00:00 값으로 구성하는 것이 좋습니다. 이 정도의 시간이면 장기간 중단되는 상황에서도 전자 메일이 유실되지 않습니다. 전송 쓰레기 수거통 기능을 사용하는 경우에는 전송 쓰레기 수거통 큐를 호스팅하기 위해 허브 전송 서버에서 추가 디스크 공간이 필요합니다. 필요한 저장소 공간의 크기는 MaxDumpsterSizePerStorageGroup 값과 허브 전송 서버가 포함되어 있는 Active Directory 사이트에서 연속 복제를 사용하는 모든 사서함 서버의 저장소 그룹 수를 곱한 것과 거의 같습니다.

전송 쓰레기 수거통을 사용하고 구성하는 방법에 대한 자세한 단계는 전송 쓰레기 수거통을 구성하는 방법을 참조하십시오.

CCR 솔루션 확인

CCR 솔루션을 설치했거나 중요한 구성 변경을 수행한 후에는 CMS의 상태를 확인하고 두 노드가 CMS를 지원하도록 올바르게 구성되어 있는지 확인하는 것이 좋습니다.

CMS의 상태를 확인하려면 Test-ReplicationHealth, Get-StorageGroupCopyStatus 및 Get-ClusteredMailboxServerStatus cmdlet를 실행하는 것이 좋습니다.

• Test-ReplicationHealth cmdlet는 Exchange 2007 SP1에 새로 추가되었습니다. 이 cmdlet는 연속 복제의 사전 모니터링과 연속 복제 파이프라인을 위해 설계되었습니다. Test-ReplicationHealth cmdlet는 복제, 클러스터 서비스 및 저장소 그룹 복제의 모든 측면을 검사하고 상태를 재생하여 복제 시스템의 전체 개요를 제공합니다. Test-ReplicationHealth cmdlet에 대한 자세한 내용은 Test-ReplicationHealth를 참조하십시오.

• Get-StorageGroupCopyStatus cmdlet는 각 저장소 그룹에 대한 최신 복제 상태 정보를 제공합니다. CCR 환경에서 저장소 그룹 상태를 확인하는 방법에 대한 자세한 단계는 Exchange 관리 셸을 사용하여 클러스터 연속 복제 복사본 상태를 표시하는 방법을 참조하십시오.

• Get-ClusteredMailboxServerStatus cmdlet를 실행하면 CMS의 기본 작동 상태에 대해 알려줍니다. CMS의 기본 작동 상태를 얻는 방법에 대한 자세한 단계는 클러스터된 사서함 서버의 상태를 보는 방법을 참조하십시오.

두 노드를 사용하여 CMS를 온라인 상태로 만들 수 있는지 확인하는 데 권장되는 방법은 Move-ClusteredMailboxServer cmdlet를 사용하여 CMS를 각 노드로 이동하는 것입니다. 또한 Exchange 2007 SP1에서는 Exchange 관리 콘솔의 클러스터된 사서함 서버 관리 마법사를 사용하여, CMS를 노드 간에 이동하여 두 노드에서 CMS를 온라인 상태로 만들 수 있는지 확인할 수 있습니다.