CCR을 배포하기 전에 다음과 같은 시스템 차원 요구 사항이 충족되었는지 확인하십시오.

• 저장소 그룹마다 하나의 데이터베이스를 사용해야 합니다. 저장소 그룹을 CCR 환경에 만든 경우 단일 데이터베이스만 포함할 수 있습니다. 이러한 방법으로 복구 기능이 향상되고 관리하기 용이한 Microsoft Exchange 저장소 토폴로지를 만들 수 있습니다.
  
• DNS(Domain Name System)를 실행해야 합니다. 이상적으로 DNS 서버는 동적 업데이트를 허용해야 합니다. DNS 서버가 동적 업데이트를 허용하지 않으면 각각의 클러스터된 사서함 서버 및 해당 클러스터 각각에 대해 DNS 호스트(A) 레코드를 하나씩 만들어야 합니다. 그렇지 않으면 Exchange 가 제대로 작동하지 않습니다. Exchange 에 대해 DNS를 구성하는 방법에 대한 자세한 내용은 Microsoft 기술 자료 문서 322856, Exchange Server에서 DNS를 사용할 수 있도록 구성하는 방법을 참조하십시오.
  
• 클러스터 노드가 컴퓨터가 가입한 Active Directory 디렉터리 서비스 도메인과 이름이 다른 디렉터리 이름 서비스 영역에 속하는 경우 DNSHostName 속성은 기본적으로 하위 도메인 이름을 포함하지 않습니다. 이러한 경우에는 FRS(파일 복제 서비스)와 같은 일부 서비스가 제대로 작동하도록 DNSHostName 속성을 변경해야 할 수 있습니다. 자세한 내용은 기술 자료 문서 240942, Active Directory DNSHostName property does not include subdomain을 참조하십시오.
  
• 모든 클러스터는 동일한 도메인에 있는 구성원 서버이어야 합니다. Microsoft Exchange Server 2007 은 Active Directory 서버 역할을 하는 노드나 다른 Active Directory 도메인의 구성원 역할을 하는 노드에서 지원되지 않습니다.
  
• Exchange 2007 을 설치하려면 클러스터를 만들어야 합니다. Windows Server 2008 장애 조치 클러스터를 만드는 방법에 대한 내용은 Windows Server 2008에 클러스터 연속 복제 설치를 참조하십시오. Windows Server 2003 장애 조치 클러스터를 만드는 방법에 대한 내용은 단일 복사본 클러스터 설치를 참조하십시오.
  
• CMS(클러스터된 사서함 서버) 이름은 15자 이하여야 합니다.
  
• Exchange 2007 이 설치된 클러스터에는 Exchange Server 2003, Exchange 2000 Server 또는 모든 클러스터 인식 버전의 Microsoft SQL Server 가 포함될 수 없습니다. 그러므로 위에 나와 있는 응용 프로그램이 설치된 클러스터에서의 Exchange 2007 실행은 지원되지 않습니다. SQL Server 2005 Express Edition 또는 다른 데이터베이스 응용 프로그램(예: Microsoft Office Access)이 클러스터되지 않은 경우 이러한 응용 프로그램이 설치된 클러스터에서의 Exchange 2007 실행이 가능합니다.
  
• Exchange 2007 을 설치하기 전에 Exchange 데이터를 설치할 폴더가 비어 있는지 확인합니다.
  
• 클러스터된 사서함 서버의 호스트로 구성된 클러스터의 모든 노드에 동일한 Exchange 2007 버전을 설치해야 합니다. 또한 클러스터에 있는 모든 노드의 같은 경로 및 드라이브에 운영 체제와 Exchange 파일을 설치해야 합니다. 그러기 위해서는 모든 컴퓨터의 디스크 구성이 동일하지는 않아도 비슷해야 합니다.
  
• 클러스터 서비스 계정이 클러스터된 사서함 서버를 호스팅할 수 있는 각 노드의 로컬 관리자 그룹 구성원이어야 합니다.
  
• 기본 클러스터 그룹의 리소스를 클러스터된 사서함 서버를 포함한 리소스 그룹에 설치하거나, 만들거나, 이동하지 마십시오. 또한 클러스터된 사서함 서버를 포함한 그룹의 리소스도 기본 클러스터 그룹에 설치하거나, 만들거나, 이동하지 마십시오. 기본 클러스터 그룹에는 클러스터 IP 주소, 네트워크 이름 및 쿼럼 리소스만 있어야 합니다. 따라서 기본 클러스터 그룹으로의 리소스 이동 및 통합은 지원되지 않습니다.
  

  중요:

  이전 버전의 Exchange 를 실행하는 클러스터에는 MSDTC(Microsoft Distributed Transaction Coordinator)의 클러스터된 인스턴스가 필요하지만, Exchange 2007 에서는 클러스터된 MSDTC 리소스가 없어도 됩니다. CCR 환경의 클러스터된 사서함 서버에서는 장애 조치 클러스터에 설치된 MSDTC 리소스를 사용하지 않으며 필요로 하지도 않습니다. 타사 응용 프로그램에는 COM+ 의존성으로 인해 MSDTC 리소스가 필요할 수 있습니다. Windows Server 2003 에서는 MSDTC 클러스터 리소스에 클러스터의 공유 저장소를 사용해야 합니다. 공유 저장소를 CCR 환경에 추가하는 것은 좋지 않습니다. Windows Server 2008 에서 제공하는 클러스터되지 않은 로컬 MSDTC 인스턴스의 경우 Windows Server 2008 장애 조치 클러스터에 공유 저장소가 없어도 됩니다. Windows Server 2008 의 MSDTC 변경 내용에 대한 자세한 내용은 Windows Server 2008 도움말을 참조하십시오.

일반 하드웨어 계획 정보는 프로세서 및 메모리 구성 계획 및 디스크 저장소 계획을 참조하십시오. CCR 환경 관련 하드웨어 요구 사항은 다음과 같습니다.

• Windows Server 2003 에서 파일 공유 감시 기능이 있는 MNS(과반수 노드 집합) 쿼럼을 사용할 경우 클러스터에는 두 개의 노드만 있을 수 있습니다. 클러스터에 노드가 하나 또는 셋 이상 있는 경우 파일 공유 감시 기능이 있는 MNS 쿼럼을 사용할 수 없습니다. 대신 클러스터에 셋 이상의 노드가 필요한 일반적인 MNS 쿼럼을 사용해야 합니다.
  
• Windows Server 2008 에서 노드 및 파일 공유 과반수 쿼럼을 사용할 경우 클러스터에는 노드가 두 개만 있을 수 있습니다. 클러스터에 노드가 하나 또는 셋 이상 있는 경우 노드 및 파일 공유 과반수 쿼럼을 사용할 수 없습니다. 대신 클러스터에 셋 이상의 노드가 있어야 하는 노드 과반수 쿼럼을 사용해야 합니다.
  

  참고:
  파일 공유 감시 기능이 있는 MNS 쿼럼 또는 노드 중 하나를 사용하고 파일 공유 과반수 쿼럼을 사용하는 2개 노드 장애 조치 클러스터를 사용하는 것이 좋습니다. 그러면 클러스터에 세 번째 Voter 노드가 필요 없습니다.

• 사용 서버는 설치될 운영 체제에 대해 테스트된 제품의 Microsoft Windows Server 카탈로그에 있어야 합니다. 하지만, 공유 저장소가 클러스터에서 사용되지 않는 경우 이 서버는 클러스터 범주에 포함될 필요가 없습니다.
  
• 사서함 서버 역할을 호스트하는 두 서버는 다음과 같은 항목에서 비슷해야 하지만 같아서는 안 됩니다.
  
  • CPU
    
  • 메모리
    
  • I/O(입출력) 기능
    
  • 네트워킹
    
  • 공급업체
    
  • 공간 및 I/O 작업 기능을 포함하는 가용 디스크 저장소
    

일반적으로 클러스터된 응용 프로그램은 설치된 클러스터가 사용하는 쿼럼의 유형을 감지하지 못합니다. CCR 환경에 쿼럼 구성 요소를 설계할 경우 다음 권장 사항과 요구 사항을 확인해야 합니다.

• Windows Server 2008 에서는 노드 및 파일 공유 과반수 쿼럼이 CCR에 가장 좋은 쿼럼 유형입니다.
  
• Windows Server 2003 에서는 파일 공유 감시 기능이 있는 MNS 쿼럼이 CCR에 매우 좋은 쿼럼 유형입니다.
  

위의 쿼럼 유형 중 하나가 CCR에 사용될 경우 노드는 테스트된 제품의 Microsoft Windows Server 카탈로그에 있을 필요가 없습니다.

공유 저장소 쿼럼이 CCR에 사용될 경우 전체 시스템은 테스트된 제품의 Microsoft Windows Server 카탈로그에 있어야 합니다.

파일 공유 감시 또는 파일 공유 과반수가 구성되어 있지 않으면 Exchange Server 2007 SP1(서비스 팩 1)의 설치 프로그램에서 2개 노드 클러스터 구성을 차단합니다. 구성에서 과반수가 유지 관리되지 않으므로 클러스터의 노드 손실을 처리할 수 없게 되어 클러스터가 오프라인 상태가 되기 때문입니다.

CCR 환경을 위한 소프트웨어 요구 사항은 다음과 같습니다.

• 클러스터의 두 노드에는 동일한 부팅 및 시스템 드라이브 문자를 사용하는 Windows Server 2008 Enterprise 운영 체제 또는 Windows Server 2003 Enterprise Edition 운영 체제가 클러스터의 각 노드에 설치되어야 합니다. 한 노드에서 Windows Server 2008 이 실행되고 다른 노드에서 Windows Server 2003 이 실행되는 클러스터는 사용할 수 없습니다. 장애 조치(failover) 클러스터에서의 혼합 운영 체제 버전은 지원되지 않습니다.
  
• Windows Server 2003 에서 Exchange 2007 의 RTM(Release To Manufacturing) 버전을 사용하여 CCR 환경을 구축하는 경우, 장애 조치 클러스터의 두 노드에는 Windows Server 2003 SP2(서비스 팩 2) 또는 Windows Server 2003 SP1 중 하나가 설치되거나 기술 자료 문서 921181 파일 공유 감시 기능 및 구성 가능한 클러스터 하트비트 기능을 Windows Server 2003 서비스 팩 1 기반의 서버 클러스터에 추가하는 업데이트 사용 가능(영문)에 설명된 핫픽스가 설치되어야 합니다. 이 핫픽스는 Windows Server 2003 SP2에 포함되어 있습니다. Windows Server 2003 에서 Exchange 2007 SP1을 사용하여 CCR 환경을 구축하는 경우 장애 조치 클러스터의 두 노드에는 Windows Server 2003 SP2가 설치되어야 합니다.
  
• 클러스터는 일반 MNS 쿼럼을 사용하는 3개 노드 클러스터이거나 파일 공유 미러링 모니터와 함께 MNS 쿼럼을 사용하는 2개 노드 클러스터이어야 합니다. 일반적으로 Windows Server 2003 에는 파일 공유 감시가 있는 MNS 쿼럼을 사용하는 2 노드 클러스터가 사용되고 Windows Server 2008 에는 노드 및 파일 공유 과반수 쿼럼이 있는 2 노드 클러스터가 사용되는 것으로 간주됩니다.
  
• MNS 또는 파일 공유 과반수 쿼럼에 대한 파일 공유 감시 기능은 전용 컴퓨터에 없어도 됩니다. Windows Server 를 실행하는 임의의 컴퓨터에 있을 수 있습니다. 하지만 Exchange 관리자가 제어할 수 있도록 허브 전송 서버나 다른 Exchange 서버에서 파일 공유 감시 기능을 호스팅하는 것이 좋습니다.
  
• 클러스터에는 사서함 서버 역할만 설치할 수 있으며 다른 서버 역할은 장애 조치(failover) 클러스터에 속하는 컴퓨터에 설치할 수 없습니다.
  

클라이언트와 클러스터 통신에 사용되는 서버를 올바르게 구성하는 것이 중요합니다. 이 섹션에서는 개인 및 공용 네트워크 설정이 제대로 구성되었는지 확인하는 데 필요한 절차에 대한 링크를 제공합니다. 또한 클러스터의 네트워크 연결 순서가 제대로 구성되어 있는지 확인해야 합니다. CCR 환경을 위한 네트워크 인프라를 설계할 때는 다음과 같은 사항을 고려하십시오.

• 각 노드에는 Windows 클러스터링에 사용할 수 있는 네트워크 어댑터가 최소 2개 이상 있어야 합니다. 클라이언트와 다른 서버는 이 두 네트워크 어댑터 중 하나에서만 노드에 액세스해야 합니다. 다른 네트워크 어댑터는 클러스터 내의 통신에 사용됩니다. 권장되는 구성은 개인 네트워크를 내부 클러스터 통신 전용으로 사용하고 공용 네트워크를 혼합으로 지정하는 것입니다.
  
• 클러스터 공용 네트워크는 Active Directory 및 DNS와 같은 Exchange 서버와 기타 서비스에 연결할 수 있어야 합니다. 네트워크 어댑터 팀이나 유사한 기술을 활용하여 이 단일 지점에서 오류가 발생하지 않도록 예방할 수 있습니다.
  
• 별도의 클러스터 개인 네트워크가 제공되어야 합니다. 개인 네트워크는 클러스터 하트비트에 사용됩니다. 개인 네트워크에는 DNS가 필요하지 않습니다.
  
• 데이터 센터가 2개인 구성에서는 하트비트 요구 사항이 가장 엄격한 공용 네트워크 대역폭 및 대기 시간 요구 사항이 아닐 수도 있습니다. 클라이언트 액세스, Active Directory, 전송, 연속 복제 및 기타 응용 프로그램 트래픽을 포함한 전체 네트워크 부하를 평가하여 환경에 필요한 네트워크 요구 사항을 결정해야 합니다.
  
• CCR 환경에 Gigabit 이더넷을 사용하여 다시 시드하는 시간을 최대화하는 것이 좋습니다. Gigabit 이더넷을 권장하는 이유에 대한 자세한 내용은 이 항목 뒷부분의 "데이터베이스 크기 및 클러스터 연속 복제"를 참조하십시오.
  
• Exchange 2007 RTM 버전에서 클러스터된 사서함 서버가 포함된 리소스 그룹은 네트워크 이름 리소스를 하나만 가질 수 있습니다. Exchange 2007 RTM에서는 클러스터된 사서함 서버가 있는 리소스 그룹에서 둘 이상의 네트워크 이름 리소스를 갖는 것을 지원하지 않습니다. 하지만 이 제한은 Exchange 2007 SP1에는 해당되지 않습니다. 클러스터된 사서함 서버를 Exchange 2007 SP1으로 업그레이드 하면 클러스터된 사서함 서버가 있는 리소스 그룹에 둘 이상의 네트워크 이름 리소스가 있어도 됩니다.
  

 Windows Server 2008에 CCR을 설치하기 위한 네트워크 요구 사항

Windows Server 2008 에 CCR을 설치하기 위한 네트워크 요구 사항은 Windows Server 2003 에 CCR을 설치하기 위한 요구 사항과 약간 차이가 있습니다. Windows Server 2003 과 마찬가지로 Windows Server 2008 에 CCR을 설치하는 경우 두 노드 및 CMS(클러스터된 사서함 서버)에 사용할 수 있는 IP 주소가 충분히 있어야 합니다. 하지만 다음과 같은 일부 추가 옵션은 Windows Server 2003 에서는 사용할 수 없지만 Windows Server 2008 에서는 사용이 가능합니다.

• 클러스터 노드가 서로 다른 서브넷에 위치할 수 있습니다. Windows Server 2003 의 경우 각 노드의 네트워크 각각에 대한 네트워크 인터페이스가 다른 노드에 있는 해당 네트워크와 동일한 서브넷에 있어야 합니다. Windows Server 2008 에는 이 요구 사항이 없습니다. 결과적으로 장애 조치 클러스터 내의 노드는 네트워크 라우터를 통해 통신할 수 있으므로 노드 연결에 VLAN(가상 LAN) 기술을 사용할 필요가 없습니다.
  
• CCR 환경에서 서브넷을 여러 개 사용하는 경우, 노드 간에 CMS 장애 조치나 전달이 이루어지면 DNS 복제로 인해 CMS에 다시 연결하기 위한 클라이언트 기능이 영향을 받을 수 있습니다. IP 주소가 변경된 클러스터된 사서함 서버와 통신하는 다른 서버 및 클라이언트는 DNS를 새 IP 주소로 업데이트하고 로컬 DNS 캐시를 업데이트한 후에야 클러스터된 사서함 서버와의 통신을 다시 설정할 수 있습니다. DNS 변경 내용을 클라이언트와 다른 서버에 알리는 데 걸리는 시간을 최소화하려면 클러스터된 사서함 서버의 네트워크 이름 리소스에 대해 DNS TTL(Time to Live) 값을 5분으로 설정하는 것이 좋습니다. 대부분의 환경에서 CMS 네트워크 이름 리소스에 대해서만 DNS TTL 값을 설정하는 것이 좋습니다. 단, 관리를 위해서 클러스터에 비 Exchange 관리 도구를 이름으로 연결한 환경에서는 클러스터의 네트워크 이름 리소스에 대한 TTL 값을 더 낮게 설정하는 것이 좋습니다. 다중 서브넷 CMS나 대기 클러스터 배포에 사용할 네트워크 이름 리소스의 DNS TTL 값을 구성하는 방법에 대한 자세한 단계는 네트워크 이름 리소스에 대해 DNS TTL 값을 구성하는 방법을 참조하십시오.
  
• Windows Server 2008 장애 조치 클러스터링에는 클러스터 IP 주소 리소스가 정적 항목을 통해서 뿐만 아니라 DHCP(Dynamic Host Configuration Protocol) 서버에서 주소를 얻을 수 있는 기능이 있습니다. DHCP 서버에서 IP 주소를 가져오도록 클러스터 노드를 구성하면, 모든 클러스터 IP 주소 리소스에 대해 IP 주소를 자동으로 가져오도록 기본 작업이 수행됩니다. 클러스터 노드에 고정 IP 주소가 할당되어 있으면 클러스터 IP 주소 리소스도 고정 IP 주소로 구성해야 합니다. 따라서 클러스터 IP 주소 리소스의 IP 주소 할당은 실제 노드 및 노드의 각 특정 인터페이스 구성에 따라 이루어집니다. 클러스터된 사서함 서버에는 DHCP를 사용하지 않는 것이 좋습니다. CMS에 DHCP를 사용하기 전에 다음 사항을 고려하는 것이 좋습니다.
  
  • IP 주소가 변경될 경우 클러스터 서비스에서는 DHCP 사용 가능 IP 주소 리소스를 온라인 상태로 만들지 않습니다.
    
  • DHCP 서버는 클러스터된 사서함 서버에서 사용하는 모든 DHCP 할당 주소에 대해 무제한 임대를 부여하도록 구성되어야 합니다.
    
• Windows Server 2008 과 해당 클러스터 서비스에서도 IPv6(Internet Protocol version 6)를 지원합니다. 그리고 IPv6 IP 주소 리소스 또는 IPv4 IP 주소 리소스를 각각 지원하거나 클러스터에서 조합하여 지원할 수 있습니다. 또한 장애 조치 클러스터는 ISATAP(Intra-site Automatic Tunneling Addressing Protocol)를 지원하고 DNS에서 동적 등록을 허용하는 IPv6 주소(AAAA 호스트 레코드 및 IP6.ARPA 역조회 영역)만을 지원합니다. Windows Server 2008 을 실행하는 컴퓨터에 Exchange 2007 SP1을 배포하고 이 컴퓨터에서 IPv6 및 IPv4가 모두 사용되도록 설정되어 있으며 네트워크에서 이 두 버전의 IP 주소를 지원하는 경우에만, IPv6 주소 및 IP 주소 범위를 사용할 수 있습니다. 이 구성에서 Exchange 2007 SP1을 배포하면, 모든 서버 역할은 IPv6 주소를 사용하는 장치, 서버 및 클라이언트와 데이터를 주고받을 수 있습니다. Windows Server 2008 을 기본 설정으로 설치하면 IPv4 및 IPv6을 사용할 수 있습니다. Exchange 2007 SP1을 Windows Server 2003 에 설치하면 IPv6 주소가 지원되지 않습니다. Exchange 2007 SP1의 IPv6 주소 지원에 대한 자세한 내용은 Exchange 2007 SP1 및 SP2에서 IPv6 지원을 참조하십시오.
  

 Windows Server 2003에 CCR을 설치하기 위한 네트워크 요구 사항

Windows Server 2003 에 CCR을 설치하는 경우 2개 노드 CCR 환경에서 클러스터된 사서함 서버를 만들 때 사용할 수 있는 고정 IP 주소가 충분히 있어야 합니다. IP 주소는 클러스터와 클러스터된 사서함 서버에 필요합니다. 또한 각 노드의 공용 및 개인 네트워크에도 IP 주소가 필요합니다.

• 개인 주소   노드마다 클러스터 개인 네트워크에 사용되는 각 네트워크 어댑터에 대해 하나의 고정 IP 주소가 필요합니다. 공용 네트워크 중 하나와 동일한 서브넷이나 네트워크에 있지 않은 고정 IP 주소를 사용해야 합니다. 서브넷 마스크가 255.255.255.0인 10.10.10.10과 10.10.10.11을 두 노드에 대한 개인 IP 주소로 각각 사용하는 것이 좋습니다. 공용 네트워크에서 10.x.x.x 네트워크와 255.255.255.0 서브넷 마스크를 사용하는 경우, 대체 개인 네트워크 IP 주소와 서브넷 마스크를 사용하는 것이 좋습니다. 개인 네트워크를 2개 이상 구성하는 경우 각 개인 네트워크 어댑터와 네트워크에 대해 고유한 주소 및 서브넷이 필요합니다.
  
• 공용 주소 노드마다 클러스터 공용 네트워크에 사용되는 각 네트워크 어댑터에 대해 하나의 고정 IP 주소가 필요합니다. 또한 고정 IP 주소는 클라이언트 및 관리자가 액세스할 수 있도록 서버 클러스터와 클러스터된 사서함 서버에 필요합니다. 개인 네트워크 중 하나와 동일한 서브넷이나 네트워크에 있지 않은 고정 IP 주소를 사용해야 합니다.
  

클러스터의 모든 노드에 사용되는 개인 네트워크는 동일한 서브넷상에 있어야 하지만 두 노드 간 상호 연결에 VLAN 스위치를 사용할 수 있습니다. VLAN을 사용할 경우 지점 간 왕복 이동 대기 시간이 0.5초 미만이어야 합니다. 또한 노드에서 실행 중인 Windows Server 2003 운영 체제에 두 노드 간 연결이 단일 지점 간 연결로 나타나야 합니다. 단일 지점에서의 오류 발생을 방지하려면 노드 간 서로 다른 경로에 독립적인 VLAN 하드웨어를 사용합니다. Windows Server 2008 이 실행되는 장애 조치(failover) 클러스터에는 같은 서브넷 제한이 적용되지 않습니다.

클러스터에 있는 모든 노드의 공용 네트워크는 동일한 서브넷에 있어야 하며 개인 네트워크에서 사용하는 서브넷과는 다른 서브넷을 사용해야 합니다. Windows Server 2008 이 실행되는 장애 조치(failover) 클러스터에는 같은 서브넷 제한이 적용되지 않습니다.

Windows 의 클러스터 네트워크 연결 순서의 경우 공용 네트워크가 연결 순서 목록의 맨 위에 있도록 구성해야 하며, 클러스터의 네트워크 우선 순위는 우선 순위 순서의 맨 위에 있는 개인 네트워크와 함께 구성해야 합니다.

여러 데이터 센터가 포함된 구성에서 Windows Server 2003 에 CCR을 설치하는 경우 다음을 수행합니다.

• 클라이언트 액세스에 사용되는 모든 네트워크는 클라이언트가 각 데이터 센터에서 클러스터된 사서함 서버에 액세스할 수 있을 만큼 충분한 대역폭과 매우 짧은 대기 시간을 제공해야 합니다.
  
• 트랜잭션 로그 복제에 사용되는 모든 네트워크는 가능한 한 로그 파일의 백로그가 생기지 않도록 로그 파일을 빨리 복사할 수 있을 만큼 충분한 대역폭과 매우 짧은 대기 시간을 제공해야 합니다.
  
• 클러스터 하트비트에 사용되는 네트워크는 필요한 다시 시도의 횟수 구성 이내에 하트비트 패킷을 주고받을 수 있어야 합니다. Windows Server 2003 SP2 또는 Windows Server 2003 SP1 중 하나와 기술 자료 문서 921181 파일 공유 감시 기능 및 구성 가능한 클러스터 하트비트 기능을 Windows Server 2003 서비스 팩 1 기반의 서버 클러스터에 추가하는 업데이트 사용 가능(영문)에 설명된 핫픽스에 CCR을 설치하는 경우, 손실된 인터페이스 하트비트 다시 시도 및 손실된 노드 하트비트 다시 시도가 클러스터 구성 속성으로 노출됩니다. Windows Server 2008 에 CCR을 설치하려면 이 업데이트가 필요 없습니다. 어느 경우이든 하트비트는 계속 1.2초마다 보내지지만 복구 작업을 수행하기 전에 손실된 패킷, 과도한 대기 시간, 인터페이스 실패, 또는 노드 실패 등에서 누락이 더 많이 발생하도록 클러스터를 구성할 수 있습니다. 속성 값의 단위는 경과 시간이 아니라 누락된 하트비트입니다. 따라서 클러스터에서 5초 경과 후에 인터페이스 실패를 의심하도록 구성할 수는 없습니다. 5회 누락 후에 인터페이스 실패를 의심하도록 구성할 수는 있으며, 하트비트 기간 중 실제 실패가 발생한 시기에 따라 5회 누락이 약 5초에서 6초가 될 수 있습니다. 이러한 두 가지 설정 모두 허용된 최소값은 2초이며 허용된 최대값은 20초입니다.
  

 CCR에 Windows 2003 네트워킹 최적화

Windows Server 2003 에서 CCR을 사용할 때는 특정 네트워크 링크의 속도 및 대기 시간에 대해 Windows Server TCP/IP 설정을 최적화하는 것이 좋습니다. 특히 활성 노드와 수동 노드에서 TCP(Transmission Control Protocol) 수신 창 크기와 RFC(Request for Comments) 1323 창 배율 옵션을 조정해야 할 수 있습니다. 또한 ARP(Address Resolution Protocol) 캐시 만료 설정을 구성하고 Windows 레지스트리에서 Windows Server 2003 SNP(Scalable Networking Pack)에 대해 고급 TCP/IP 옵션을 사용하지 않도록 설정하면 유용할 수 있습니다.

작업 환경에서 IPsec(IP 보안) 프로토콜을 사용하는 경우에는 이러한 권장 사항 외에도 CCR 환경 전체에서 IPsec을 일관성 있게 구성하는 것이 좋습니다. 즉, 활성 노드와 수동 노드에서 모두 IPsec을 사용도록 하거나 모두 사용하지 않도록 설정해야 합니다. 한 노드만 IPsec을 사용하도록 구성되어 있는 경우에 IPsec 보안 연결 프로세스를 수행하면 패킷이 지연되거나 손실될 수 있습니다.

 TCP 수신 창 및 RFC 1323 배율 옵션

TCP 수신 창 크기는 연결을 통해 한 번에 받을 수 있는 최대 데이터 양(바이트 단위)입니다. 송신 컴퓨터에서는 수신 컴퓨터에서 데이터 수신을 확인하고 TCP 창을 업데이트하도록 기다릴 때까지 데이터를 이 최대 양만큼만 보낼 수 있습니다. 이 설정을 조정하면 로그 전달 중에 처리량을 높이는 데 도움이 될 수 있습니다.

TCP 처리량을 최적화하려면 송신 컴퓨터에서 송신자와 수신자 간의 파이프를 채우는 데 충분한 패킷을 전송해야 합니다. 네트워크 파이프의 용량은 파이프의 대역폭과 대기 시간(왕복 시간)을 기준으로 합니다. 대기 시간이 길수록 데이터 수신을 확인하는 사이에 데이터를 보낼 수 있는 시간이 늘어나므로 네트워크 파이프의 용량도 늘어납니다. TCP 창 크기를 늘리면 시스템이 더 많은 데이터를 보냄으로써 데이터 수신 확인 사이의 시간을 활용할 수 있습니다.

TCP/IP 표준에서는 수신 창의 크기를 최대 65,535(8진수)까지 지정할 수 있습니다. 이는 16비트 TCP 창 크기 필드에서 지정할 수 있는 최대값입니다. 대기 시간이 긴 고대역폭 네트워크에서 성능을 높이기 위해 Windows Server TCP/IP는 RFC 1323, 고성능을 위한 TCP 확장에 설명되어 있는 확장 가능한 창을 사용하여 65,535(8진수)보다 큰 수신 창 크기를 보급하는 기능을 지원합니다. 창 배율을 사용할 때는 대화 중인 호스트가 파일 전송 프로토콜에서 자주 사용되는 패킷과 같은 다수의 대형 패킷을 수신자 버퍼에서 보류하도록 허용하는 창 크기를 협상할 수 있습니다. RFC 1323에는 TCP가 연결 설정 시에 창 크기에 대한 크기 조정 인수를 협상하도록 허용하여 보다 큰 수신 창 크기를 지원하는 방법이 자세히 설명되어 있습니다.

두 레지스트리 항목을 수정하여 Windows Server 2003 을 실행하는 컴퓨터에서 TCP 수신 창 크기 및 RFC 1323 창 배율 옵션을 최적화할 수 있습니다. 이 두 레지스트리 항목은 TCPWindowSize와 TCP1323Opts입니다. 이러한 기능에 대한 자세한 내용은 Microsoft 기술 자료 문서 224829, Windows 2000 및 Windows Server 2003 TCP 기능 설명(영문)을 참조하십시오.

네트워크 링크 및 네트워크 대기 시간을 기준으로 하여 이러한 레지스트리 항목의 최적 설정을 결정하려면 버전 13 이상의 Exchange 2007 Mailbox Server Role Storage Requirements Calculator를 사용하는 것이 좋습니다. Storage Calculator는 여기(영문)를 클릭하면 표시되는 Exchange 팀 블로그에서 다운로드할 수 있습니다. Storage Calculator에는 서버에서 레지스트리 값을 입력하기 위한 단계별 지침도 포함되어 있습니다.

참고:
블로그의 내용과 해당 URL은 예고 없이 변경될 수 있습니다. 각 블로그의 내용은 보증 없이 "있는 그대로" 제공되며 권한을 제공하지 않습니다. 포함된 스크립트 샘플 또는 코드의 사용은 Microsoft - 사용 약관에 대한 정보에 지정되어 있는 약관을 따릅니다.

 ARP 캐시 만료

ARP 캐시는 IP 주소를 MAC(미디어 액세스 제어) 주소로 매핑하는 메모리 내 테이블입니다. ARP 캐시의 항목은 아웃바운드 패킷을 항목에 있는 IP 주소로 보낼 때마다 참조됩니다. 기본적으로 Windows Server 2003 은 시스템의 요구 사항에 맞게 ARP 캐시 크기를 자동으로 조정합니다. 보내는 데이터그램에서 2분 동안 사용되지 않는 항목은 ARP 캐시에서 제거됩니다. 그리고 현재 참조되는 항목은 10분 후에 ARP 캐시에서 제거됩니다. 수동으로 추가한 항목은 캐시에서 자동으로 제거되지 않습니다.

Microsoft의 내부 IT 부서에서 시행한 내부 테스트 결과에 따르면, 기본 ARP 캐시 만료 설정을 사용하는 경우 CCR 및 SCR 환경에서 패킷이 손실됩니다. 패킷이 손실되면 전송 서버가 손실된 데이터를 다시 전송해야 합니다. 연속 복제 환경에서는 로그 파일을 최대한 빨리 수동 노드로 복사해야 합니다. 또한 패킷 손실로 인해 데이터를 다시 전송하면 로그 전달 처리량이 떨어질 수 있습니다.

Windows 레지스트리에서 ArpCacheMinReferencedLife TCP/IP 매개 변수를 수정하여 ARP 캐시 만료를 제어할 수 있습니다. 이 매개 변수는 참조되는 항목이 삭제될 때까지 ARP 캐시 테이블에 보관되어야 하는 기간을 결정합니다. Microsoft에서는 내부적으로 ArpCacheMinReferencedLife 레지스트리 값에 대한 최적 설정은 네트워크의 라우터에서 ARP 캐시 만료에 사용하는 것과 같은 값(4시간)을 사용하는 것임을 확인했습니다.

작업 환경에서 ArpCacheMinReferencedLife의 값을 수정하기 전에 Microsoft 네트워크 모니터 또는 유사한 캡처 도구를 사용하여, 활성 노드에서 수동 노드로 로그를 복사하는 데 사용되는 네트워크 인터페이스에서 네트워크 트래픽을 수집 및 분석하는 것이 좋습니다. ArpCacheMinReferencedLife 레지스트리 값을 수정하는 방법에 대한 자세한 단계는 부록 A: TCP/IP 구성 매개 변수(영문)를 참조하십시오.

 Scalable Networking Pack 고급 TCP/IP 기능

Windows Server 2003 SNP(Scalable Networking Pack)는 Windows 네트워크 스택을 가속화하기 위한 상태 저장 및 상태 비저장 오프로드를 포함하는 Windows Server 2003 용 별도 업데이트입니다. 이 업데이트에는 TCP Chimney 오프로드, RSS(수신측 배율) 및 NetDMA(Network Direct Memory Access) 등이 있습니다.

TCP Chimney는 상태 저장 오프로드입니다. TCP Chimney 오프로드를 사용하면 하드웨어에서 TCP/IP 프로세스를 처리할 수 있는 네트워크 어댑터로 TCP/IP 프로세스를 오프로드할 수 있습니다.

RSS 및 NetDMA는 상태 비저장 오프로드입니다. 여러 CPU가 단일 컴퓨터에 있는 경우 Windows 네트워킹 스택은 "수신" 프로토콜 처리를 단일 CPU로 제한합니다. RSS는 네트워크 어댑터로부터 수신한 패킷이 여러 CPU에 걸쳐 균형을 이루도록 함으로써 이 문제를 해결합니다. NetDMA는 PCI(Peripheral Component Interconnect) 버스에서 DMA(직접 메모리 액세스) 엔진을 사용하도록 허용합니다. TCP/IP 스택은 복사 작업을 처리하기 위해 CPU를 인터럽트하는 대신 DMA 엔진을 사용하여 데이터를 복사할 수 있습니다. 관련 구성 요소인 TCPA는 PCI 버스에서 하드웨어 DMA 엔진을 사용하여 수신 프로세스를 도울 수 있는 또 다른 오프로드 기능입니다.

일부 환경에서 이러한 기능을 사용하면 네트워크 성능이 향상되지만, 다른 기술을 사용하는 일부 경우에는 이러한 기능을 사용할 수 없습니다. 예를 들어, 다음 기술을 사용하는 경우에는 TCP Chimney 오프로드 및 NetDMA를 사용할 수 없습니다.

• Windows 방화벽
  
• 인터넷 프로토콜 보안(IPsec)
  
• IPNAT(Internet Protocol Network Address Translation)
  
• 타사 방화벽
  
• NDIS 5.1 중간 드라이버
  

또한 이러한 기능을 사용하면 네트워크 성능이 저하될 수 있는 일부 환경(예: Microsoft Exchange 가 설치된 환경)에서 발생하는 알려진 문제도 있습니다. 이러한 일부 문제에 대한 자세한 내용은 Exchange 팀 블로그 게시물, Windows 2003 Scalable Networking Pack 및 Exchange에 미칠 수 있는 영향(영문)을 참조하십시오.

참고:
블로그의 내용과 해당 URL은 예고 없이 변경될 수 있습니다. 각 블로그의 내용은 보증 없이 "있는 그대로" 제공되며 권한을 제공하지 않습니다. 포함된 스크립트 샘플 또는 코드의 사용은 Microsoft - 사용 약관에 대한 정보에 지정되어 있는 약관을 따릅니다.

운영 체제와 시스템의 각 NIC(네트워크 인터페이스 카드)에 대해 모두 Windows Server 2003 운영 체제에서 실행되는 CCR 환경의 모든 기능을 사용할 수 없도록 설정하는 것이 좋습니다. 이러한 기능은 다음과 같은 방법으로 사용되지 않도록 설정할 수 있습니다.

• TCP Chimney 오프로드 기능을 사용하지 않도록 설정하려면 명령 프롬프트를 열고 다음 명령을 실행합니다. Netsh int ip set chimney DISABLED
  
• 다른 SNP 기능을 사용하지 않도록 설정하려면 Windows 레지스트리에서 EnableRSS 및 EnableTCPA TCP/IP 레지스트리 매개 변수의 값을 0으로 설정하면 됩니다. 이 작업을 수행하는 방법에 대한 자세한 단계는 Microsoft 기술 자료 문서 936594, Microsoft 고객지원를 참조하십시오.
  
• 시스템의 NIC에서 이 기능이 사용되지 않도록 설정하려면 NIC와 함께 제공된 지침을 참조하거나 하드웨어 공급업체에 문의하십시오.
  

SNP에 대한 자세한 내용은 기술 자료 문서 912222, Microsoft Windows Server 2003 Scalable Networking Pack 릴리스(영문) 및 Scalable Networking(영문) 웹 사이트를 참조하십시오.

지리적으로 분산된 다중 서브넷 장애 조치(failover) 클러스터에 배포된 CMS에 대해 이동 또는 장애 조치(failover)가 발생할 경우, CMS의 이름이 유지 관리됩니다. 그러나 이 이름에 할당된 IP 주소는 유지 관리되지 않습니다. 클라이언트 및 다른 서버에 대한 이 서버의 가용성은 전체 DNS에 걸친 새 IP 주소의 전파에 따라 다릅니다. DNS 전파에는 시간이 다소 걸릴 수 있습니다. 이러한 이유로 CMS DNS 호스트 레코드의 TTL(Time to Live) 값을 5분(300초)으로 구성하는 것이 좋습니다. CMS의 DNS TTL 값을 구성하는 방법에 대한 자세한 단계는 네트워크 이름 리소스에 대해 DNS TTL 값을 구성하는 방법을 참조하십시오. CMS의 DNS TTL 값을 구성한 후 CMS를 중지하고 다시 시작해야 변경 내용이 적용됩니다.

내부 Microsoft Office Outlook 클라이언트에는 새 IP 주소를 사용하여 연결할 새로운 프로필 또는 다시 구성된 프로필이 필요하지 않지만, CMS의 이름 확인이 이전 IP 주소에서 새 IP 주소로 진행되도록 로컬 DNS 캐시가 지워질 때까지 기다려야 합니다. IP 주소를 DNS 서버로 전파한 후에는 Outlook 클라이언트의 명령 프롬프트에서 다음 명령을 실행하여 이 클라이언트에서 DNS 캐시를 지울 수 있습니다.

ipconfig /flushdns

다음 섹션에서는 다양한 구성에서 Outlook의 동작을 보여줍니다.

 Windows Server 2003의 확장된 CCR(단일 서브넷)

이 구성에는 네트워크 이름 리소스 하나와 이 리소스가 사용하는 IP 주소 리소스 하나가 있습니다. DNS에서 네트워크 이름은 IP 주소와 연결됩니다. IP 주소 리소스를 포함한 모든 리소스는 클러스터의 두 노드 간에 이동할 수 있습니다. Outlook 측면에서 볼 때 장애 조치(failover) 시의 네트워크 변경 내용은 컴퓨터 MAC 주소에 대한 IP 주소의 연결뿐이며, 이는 클라이언트를 변경하지 않으므로 IP 주소는 변경되지 않습니다.

 Windows Server 2008의 확장된 CCR(두 개의 서브넷, IPv4로 가정)

이 구성에는 네트워크 이름 리소스 하나와 이 리소스가 사용하는 IP 주소 리소스 두 개(논리적 "OR")가 있습니다. DNS에서 네트워크 이름은 현재 온라인 IP 주소와 연결됩니다. 장애 조치(failover) 중에 네트워크 이름 리소스가 온라인 상태가 되면 클러스터 서비스는 네트워크 이름에 대한 DNS 항목을 다른 서브넷에 해당하는 두 번째 IP 주소로 업데이트합니다. 레코드 업데이트 내용은 DNS 전체로 전파해야 합니다. Outlook 측면에서 볼 때 Outlook 에는 새 프로필이나 다시 구성된 프로필은 필요하지 않지만, 네트워크 이름을 다른 IP 주소로 해석하려면 로컬 DNS 캐시가 플러시될 때까지 대기해야 합니다. 클라이언트에서 다음을 실행하여 이 작업을 수동으로 수행할 수 있습니다.

IPConfig /flushdns

 원격 사이트의 SCR이 포함된 로컬 CCR(단일 또는 두 개의 서브넷)

이 구성에는 네트워크 이름 리소스 하나와 이 이름이 사용하는 IP 주소 리소스 하나가 있습니다. IP 주소를 포함한 모든 리소스는 클러스터의 두 노드 간에 이동할 수 있습니다. Setup.com /recoverCMS를 실행하여 SCR 대상을 활성화하는 사이트 장애 조치(failover) 시 CMS는 다른 사이트/클러스터로 이동됩니다. 이 명령을 실행할 때는 원격 사이트에서 네트워크 이름과 연결해야 하는 IP 주소를 제공합니다. 설치 프로그램은 네트워크 이름과 IP 주소 리소스를 만들고, 클러스터 서비스는 새 IP 주소로 DNS를 업데이트합니다. DNS 업데이트 내용은 DNS 전체로 전파해야 합니다. Outlook 측면에서 볼 때 Outlook 에는 새 프로필이나 다시 구성된 프로필은 필요하지 않지만, 네트워크 이름을 다른 IP 주소로 해석하려면 로컬 DNS 캐시가 플러시될 때까지 대기해야 합니다. 클라이언트에서 다음을 실행하여 이 작업을 수동으로 수행할 수 있습니다.

IPConfig /flushdns

CCR은 Windows 클러스터에서 공유 저장소의 필요성을 없애기 위해 설계되었습니다. 이전 버전의 Exchange 에서는 공유 저장소가 반드시 필요했습니다. CCR을 위해서는 Windows 지원 저장소의 성능과 용량이 충분하기만 하면 됩니다.

CCR로 인해 저장소 그룹과 데이터베이스에서 사용하는 저장소에 추가적인 I/O 고려 사항이 발생하지는 않습니다. CCR 저장소 솔루션을 설계할 경우 다음과 같은 최적의 방법을 따르는 것이 좋습니다.

• 저장소 그룹 및 데이터베이스의 위치는 모든 클러스터 노드에서 동일해야 합니다.
  
• 서로 다른 LUN(논리 단위 번호)으로 데이터베이스 파일 및 트랜잭션 로그 파일을 저장합니다.
  
• NTFS 파일 시스템 볼륨 탑재 지점을 사용하여 운영 체제에 볼륨을 표시합니다.
  
• 호스팅되는 저장소 그룹 또는 데이터베이스와 직접적으로 명확하게 연결될 수 있는 인식 가능한 이름을 사용합니다. 로그 및 데이터베이스에 사용되는 볼륨이 서로 다른 경우 경로에 데이터 형식이 식별됩니다. 이렇게 하면 데이터베이스 및 저장소 그룹 수가 증가할 때 실수로 인한 오류를 방지할 수 있습니다. 기본 설치를 수행하는 경우 저장소 그룹과 데이터베이스는 Exchange 2007 의 설치 위치 아래 만들어집니다.
  

  참고:
  Exchange 2007 은 볼륨의 루트에 트랜잭션 로그나 데이터베이스 파일을 배치하는 것을 지원하지 않습니다.

CCR 환경에는 충분한 성능과 용량을 제공하는 저장소가 필요합니다. 시스템의 성능과 용량에 상응하는 저장소가 각 저장소 그룹과 데이터베이스에 대해 동일한 위치(드라이브 문자 및 경로)를 사용하는 두 노드 모두에 구성되어야 합니다.

 데이터베이스 크기 및 클러스터 연속 복제

CCR에서 저장소 오류나 실제 데이터베이스 손상을 방어하는 첫 번째 방법은 데이터의 수동 복사본으로 되돌리고 백업에서 복원하지 않는 것입니다. 이로써 보관 또는 테이프 복원을 기반으로 한 짧은 RTO(Recovery Time Objective)에 대한 중요성이 훨씬 줄어들었습니다. 테이프 복구 대신, 데이터베이스 수동 복사본을 활성화하여 몇 시간이 아니라 몇 분 이내에 클라이언트에서 데이터를 사용할 수 있습니다. 이런 의미에서 CCR을 빠른 복구 메커니즘으로 생각하고 Exchange Server 2003 에서 VSS(볼륨 섀도 복사본 서비스)를 사용하여 만들어진 하드웨어 기반 스냅샷 및 복제본과 동일한 범주에 넣을 수 있습니다.

잘못된 백업(예: 잘못된 테이프 또는 복구 실패)으로 인한 복구와 같은 오프라인 데이터베이스 작업을 수행하는 것은 관리자에게 일반적인 일입니다. CCR의 경우 이 시나리오를 피하며 데이터베이스에 대해 복구를 실행해야 할 가능성이 훨씬 적습니다. 복구가 필요한 상황의 비율이 크게 줄어들지만 그래도 여전히 복구가 필요한 경우가 있게 됩니다. 데이터베이스 크기를 결정할 때 최악의 시스템 고장에 대한 오차 허용 범위를 반드시 고려하도록 합니다.

CCR에서는 온라인 유지 관리 창을 더 많이 확장할 수 있습니다. CCR에서는 저장소 그룹의 수동 복사본에서 백업할 수 있으므로 활성 클러스터 노드의 온라인 유지 관리 창을 확장할 수 있습니다. 많은 경우에 온라인 유지 관리 창을 두 배로 확장할 수 있으며, 따라서 큰 사서함 및 데이터베이스를 가질 수 있습니다.

LLR(Lost Log Resiliency)이라는 Exchange 2007 의 또 다른 기능은 손실된 로그로 인한 데이터베이스 불일치가 발생하는 것을 크게 감소시킵니다. 일반적으로 관리자가 데이터베이스를 복구하는 가장 흔한 이유는 필요한 로그가 손실되거나 손상되어 데이터베이스를 탑재할 수 없게 될 때 데이터베이스를 가져와 일관성 있는 상태로 만들기 위함입니다. LLR에서는 복구를 실행하지 않아도 데이터베이스가 탑재될 수 있도록 이러한 손실되고 손상된 로그 시나리오에 복구 기능을 제공합니다. LLR에 대한 자세한 내용은 Exchange 2007의 손실된 로그 복원 및 트랜잭션 로그 작업을 참조하십시오.

여기서 연속 복제가 위험 없이 원하는 만큼 데이터베이스를 커지게 할 수 있는 것처럼 보일 수 있습니다. 그러나 그렇지 않습니다. 적절한 시간 안에 완료되는 데이터베이스당 온라인 유지 관리는 여전히 데이터베이스 크기를 제한하는 요소입니다. 그러나 CCR에서는 데이터베이스를 다시 시드해야 할 가능성 또한 제한 요소입니다 CCR에서는 데이터베이스가 중복되므로 데이터베이스의 활성 복사본이 손실되거나 손상되는 경우 데이터베이스의 수동 복사본을 활성화하여 빠르게 복구를 수행할 수 있습니다. CCR은 장애 조치라는 프로세스를 통해 자동 활성화를 제공합니다.

장애 조치가 발생한 후에는 한 개의 데이터베이스 복사본, 즉 새로운 활성 복사본만 남습니다. 수동 복사본이 더 이상 없기 때문에 데이터베이스 복구가 위태로울 수 있습니다. 그러나 여전히 백업이 필요합니다. 복구를 다시 가능하게 하려면 손실되거나 손상된 데이터베이스를 제거해야 하며 데이터베이스의 새 수동 복사본을 만들어 활성 복사본에서 다시 시드해야 합니다. 데이터베이스 크기에 따라 시간이 오래 걸릴 수 있습니다. 최악의 시나리오는 모든 활성 복사본의 손실 또는 손상으로, 이 경우 모든 수동 복사본을 다시 시드해야 합니다. 이 시나리오가 CCR 환경을 위해 Gigabit 이더넷을 권장하는 이유 중 하나입니다.

CCR 환경에서는 Gigabit 이더넷에 대한 속도가 다음과 같을 것으로 예상하며 디스크 또는 프로세서 지체가 없습니다.

• 단일 데이터베이스 다시 시드: 초당 약 25MB
  
• 다중 데이터베이스 다시 시드(병렬로): 초당 약 100MB(네트워크 대역폭으로 제한)
  

연속 복제를 사용할 때는 최대 데이터베이스 크기를 더 크게 조정할 수 있습니다. Exchange 2007 에 대한 최대 데이터베이스 크기를 다음과 같이 설정하는 것이 좋습니다.

• 연속 복제 없이 사서함 서버에서 호스팅되는 데이터베이스: 100GB(기가바이트)
  
• 연속 복제 및 Gigabit 이더넷을 사용하는 사서함 서버에서 호스팅되는 데이터베이스: 200GB
  

  참고:
  대형 데이터베이스는 복구 시나리오를 수용하기 위한 증가된 대역폭을 위해 최신 저장소 기술이 필요할 수 있습니다.

  중요:
  데이터베이스의 실제 최대 크기는 조직에서 사용 중인 SLA(서비스 수준 계약)에 의해 지정되어야 합니다. 조직의 SLA에 지정되어 있는 기간 내에 백업 및 복구할 수 있는 최대 크기의 데이터베이스를 결정하는 것이 데이터베이스의 최대 크기를 결정하는 방법입니다.

CCR에는 독립형 서버의 모든 Active Directory 인프라 요구 사항뿐 아니라 추가적인 요구 사항도 있습니다. 데이터 센터 솔루션이 여러 개인 경우 언제라도 데이터 센터에서 클러스터된 사서함 서버를 호스팅할 수 있으므로 적절한 Active Directory 인프라 지원이 뒷받침되어야 합니다. 다른 데이터 센터를 사용할 수 없는 경우에도 이 기능은 제공되어야 합니다. 또한 클러스터의 모든 노드는 동일한 도메인에 있어야 하며 클러스터 서비스 계정에 적절한 권한이 있어야 합니다.

참고:
클러스터의 모든 노드가 같은 같은 사이트의 구성원이어야 하기 때문에 지리적으로 분산된 클러스터의 사서함 서버에서는 단일 Active Directory 사이트가 데이터 센터 간에 확장되어야 합니다. 그러나 데이터 센터 내의 다른 서버가 같은 서브넷에 있거나 같은 Active Directory 사이트에 있으면 추가로 요구되는 사항은 없습니다.

Windows Server 2008 에 CCR을 설치하는 경우에는 클러스터 서비스 계정이 LocalSystem(SYSTEM) 계정으로 실행됩니다.

Windows Server 2003 에 CCR을 설치하려면 도메인 계정을 클러스터 서비스 계정으로 사용해야 합니다. 클러스터에 있는 노드는 모두 같은 도메인의 구성원이어야 하며 같은 클러스터 서비스 계정을 사용해야 합니다. 또한 클러스터 서비스 계정은 클러스터된 사서함 서버를 호스팅할 수 있는 각 노드의 로컬 관리자 그룹 구성원이어야 합니다.

클러스터 서비스 계정은 리소스를 온라인 상태로 만들 때 장애 조치 클러스터의 네트워크 이름 리소스와 함께 연결되고 이로 인해 식별되는 컴퓨터 계정을 만들고 유지 관리합니다. 클러스터 서비스 계정에 적절한 사용 권한이 있는지 확인하려면 기술 자료 문서 307532, 컴퓨터 개체 수정 시 클러스터 서비스 계정 문제를 해결하는 방법을 참조하십시오. 추가 정보는 기술 자료 문서 251335, 도메인 사용자가 워크스테이션이나 서버를 도메인에 참가시킬 수 없다에서 확인할 수 있습니다.

CCR과 공용 폴더 복제는 Exchange 에서 기본 제공되는 매우 다른 두 가지 복제 형태입니다. 연속 복제와 공용 폴더 복제 간의 상호 운용성 제한으로 인해 Exchange 조직의 하나 이상의 사서함 서버에 공용 폴더 데이터베이스가 있을 경우 공용 폴더 복제가 사용하도록 설정되며 공용 폴더 데이터베이스를 CCR 환경에서 호스팅해서는 안 됩니다.

Exchange 조직에서 공용 폴더 데이터베이스와 CCR을 사용하는 경우 다음과 같이 구성하는 것이 좋습니다.

• Exchange 조직에 사서함 서버가 하나만 있고 이 사서함 서버가 CCR 환경의 클러스터된 사서함 서버인 경우 이 사서함 서버는 공용 폴더 데이터베이스를 호스팅할 수 있습니다. 이러한 구성에서는 Exchange 조직에 공용 폴더 데이터베이스가 하나만 있습니다. 따라서 공용 폴더 복제를 사용할 수 없습니다. 이 시나리오에서는 CCR을 사용하여 공용 폴더 데이터베이스 중복성을 획득할 수 있습니다. CCR은 공용 폴더 데이터베이스의 두 개 복사본을 유지 관리합니다.
  
• 사서함 서버가 여러 대 있는 경우, 전체 Exchange 조직에 공용 폴더 데이터베이스가 하나뿐이면 CCR 환경에서 공용 폴더 데이터베이스를 호스팅할 수 있습니다. 이 시나리오에서도 CCR을 사용하여 공용 폴더 데이터베이스 중복을 획득합니다. 이러한 구성에서는 Exchange 조직에 공용 폴더 데이터베이스가 하나만 있습니다. 따라서 공용 폴더 복제를 사용할 수 없습니다.
  
• CCR 환경으로 공용 폴더 데이터를 마이그레이션하는 경우, 공용 폴더 복제를 사용하여 공용 폴더 데이터베이스의 콘텐츠를 독립 실행형 사서함 서버나 SCC의 클러스터된 사서함 서버에서 CCR 환경의 클러스터된 사서함 서버로 이동할 수 있습니다. CCR 환경에서 공용 폴더 데이터베이스를 만들었으면 공용 폴더 데이터를 CCR 환경에 완전히 복제할 때까지만 추가 공용 폴더 데이터베이스가 존재해야 합니다. 복제가 완료되면 CCR 환경 외부의 모든 공용 폴더 데이터베이스를 제거해야 하며 Exchange 조직에서 어떠한 다른 공용 폴더 데이터베이스도 호스팅해서는 안 됩니다.
  
• CCR 환경 외부에서 공용 폴더 데이터를 마이그레이션하는 경우, 공용 폴더 복제를 사용하여 공용 폴더 데이터베이스의 콘텐츠를 CCR 환경의 클러스터된 사서함 서버에서 독립 실행형 사서함 서버나 SCC의 클러스터된 사서함 서버로 이동할 수 있습니다. CCR 환경 외부에서 추가 공용 폴더 데이터베이스를 만들었으면 공용 폴더 데이터를 추가 공용 폴더 데이터베이스에 완전히 복제할 때까지만 CCR 환경에 공용 폴더 데이터베이스가 존재해야 합니다. 복제가 완료되면 모든 CCR 환경에 있는 공용 폴더 데이터베이스를 모두 제거해야 하며 모든 후속 공용 폴더 데이터베이스를 연속 복제에 사용하도록 설정된 저장소 그룹에 호스팅해서는 안 됩니다.
  

Exchange 조직에 공용 폴더 데이터베이스가 두 개 이상 있으며 CCR 환경에 하나 이상의 공용 폴더 데이터베이스가 호스팅되어 있는 동안(예: 앞에서 설명한 마이그레이션 시나리오) 예약된 중단(무손실) 및 예약되지 않은 중단(손실)이 발생할 경우의 차이점을 생각해 봅니다.

• 예약된 무손실 중단이 발생하면 공용 폴더 데이터베이스는 온라인 상태가 되고 공용 폴더 복제가 예상한 대로 계속 수행됩니다.
  
• 예약되지 않은 중단이 발생하면 원본 서버를 사용할 수 있거나 공용 폴더 데이터베이스를 호스팅하는 저장소 그룹의 모든 로그를 사용할 수 있을 때까지 공용 폴더 데이터베이스가 온라인 상태가 되지 않습니다. 중단으로 인해 데이터가 손실된 경우 공용 폴더 복제를 사용하도록 설정되어 있으면 CCR에서는 공용 폴더 데이터베이스가 온라인 상태가 되도록 허용하지 않습니다. 이 경우 데이터 손실이 발생하지 않도록 원래 노드를 온라인 상태로 만들거나, CCR 환경의 클러스터된 사서함 서버에서 공용 폴더 데이터베이스를 다시 만들고 CCR 환경 외부에 있는 공용 폴더 데이터베이스의 공용 폴더 복제를 사용하여 콘텐츠를 복구해야 합니다.
  

Exchange 인식 백업은 VSS 기술을 이용하여 저장소 그룹 및 데이터베이스를 만들고 복사할 때 모두 지원됩니다. 스트리밍 백업은 활성 노드에서만 지원됩니다.

참고:
Exchange 인식 백업을 수행하는 동안 백업이 완료되면 트랜잭션 로그 파일을 잘라내는 것이 일반적입니다. CCR의 복제 기능을 사용하면 복제되지 않은 로그가 삭제되지 않습니다. 이 작업은 복제가 로그 복사보다 훨씬 늦게 진행될 경우 로그 삭제 모드에서 실행 중인 백업에서 사실상 사용 가능한 공간을 확보할 수 없음을 의미합니다.

활성 복사본에 대한 Exchange 인식 복원은 스트리밍 또는 VSS 백업 솔루션을 사용하여 수행할 수 있습니다. Exchange 인식 복원은 수동 복사본에 대해 지원되지 않습니다.

참고:
복원하기 전에 저장소 그룹 및 데이터베이스 파일을 수동 저장소 그룹 복사본에서 모두 제거해야 합니다.

데이터베이스를 백업에서 CCR 환경의 저장소 그룹으로 복원한 후에는 각각 Suspend-StorageGroupCopy 및 Resume-StorageGroupCopy를 사용하여 저장소 그룹에 대한 연속 복제를 일시 중단했다가 다시 시작해야 합니다. 이 프로세스는 올바른 로그 생성 정보를 사용하여 Microsoft Exchange 복제 서비스를 업데이트하는 데 필요합니다. 연속 복제를 일시 중단했다가 다시 시작하지 않으면 Microsoft Exchange 복제 서비스에 오래된 로그 생성 정보가 사용되어 로그 파일 복제가 중지됩니다.

 Exchange 2007 SP1에서 온라인 유지 관리 체크섬 및 데이터베이스 페이지 비우기

체크섬은 데이터베이스의 무결성을 검사하는 프로세스입니다. 페이지 삭제는 스트리밍 백업이 끝날 때 데이터베이스를 비우는 프로세스입니다. Exchange 2007 RTM은 데이터베이스에 대해 온라인 전체 스트리밍 백업을 수행할 때 전체 데이터베이스를 체크섬합니다. 앞에서 설명한 대로 연속 복제 환경에서 스트리밍 백업은 데이터베이스의 활성 복사본에 대해서만 수행할 수 있습니다. 데이터베이스의 수동 복사본에 대해 스트리밍 백업을 수행할 수 없습니다. VSS는 수동 복사본 전체를 스냅숏하거나 복제하는데 사용될 수 있으며, 전체 스냅숏 및 복제 또한 체크섬될 수 있습니다. 하지만 일반적으로 연속 복제 환경에서는 데이터베이스 복제본 중 하나만(활성 또는 수동 여부에 관계없이) 관리자의 개입 및 시스템 중지 시간 없이 체크섬할 수 있습니다. 그 이유는 다음과 같습니다.

• 데이터베이스의 활성 복사본을 스트리밍 백업하는 것은 성가신 작업이며 같은 데이터베이스의 수동 복사본을 VSS 백업하는 작업 또한 마찬가지입니다.
  
• VSS를 활성 데이터베이스 복사본과 수동 데이터베이스 복사본 모두에 사용할 수 있지만, 이는 활성 복사본에서 수동 복사본으로 오프로드 백업 작업을 하라는 권고와 배치됩니다.
  
• Exchange Server 데이터베이스 유틸리티(Eseutil)를 사용하여 수동으로 무결성 검사를 수행하려면 연속 복제를 일시 중단해야 하므로 복구가 일시적으로 손상될 수 있습니다.
  

앞에서 설명한 문제에 대한 경험 또는 대안이 필요 없도록 모든 데이터베이스 복사본에 페이지 삭제와 데이터베이스 체크섬을 사용할 수 있게 Exchange 2007 SP1에서는 온라인 유지 관리 데이터베이스 체크섬과 온라인 유지 관리 데이터베이스 페이지 비우기 기능을 도입했습니다. 관리자는 이 기능을 사용하여 데이터베이스에 대해 백그라운드 페이지 삭제와 백그라운드 체크섬을 설정할 수 있습니다. 스캔할 데이터베이스가 있는 사서함 서버의 레지스트리 값을 수동으로 구성하고 Microsoft Exchange Information Store 서비스를 다시 시작하여 이 두 기능을 각각 별도로 또는 연이어 사용할 수 있습니다. 레지스트리 값은 Microsoft Exchange 정보 저장소 수준에서 구성됩니다. 이렇게 사용하도록 설정한 후에는 사서함 서버의 모든 데이터베이스가 구성된 백그라운드 작업을 수행합니다. 사용 가능한 레지스트리 항목은 이 항목 뒷부분에서 설명합니다.

주의:
레지스트리를 잘못 편집하면 운영 체제를 다시 설치해야 하는 심각한 문제가 발생할 수 있습니다. 레지스트리를 잘못 편집하여 발생한 문제는 해결되지 않을 수 있습니다. 레지스트리를 편집하기 전에 모든 중요 데이터를 백업하십시오.

온라인 유지 관리 데이터베이스 체크섬 사용

위치: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem 이름: Online Maintenance Checksum 다음과 같이 입력합니다. REG_DWORD 값: 0x00000001

온라인 유지 관리 데이터베이스 페이지 비우기 사용

위치: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem 이름: Zero Database Pages During Checksum 다음과 같이 입력합니다. REG_DWORD 값: 0x00000001

온라인 유지 관리 데이터베이스 체크섬 제한

위치: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem 이름: Throttle Checksum 다음과 같이 입력합니다. REG_DWORD 값: 0x00000000(밀리초)