Exchange 2007 SP1의 새로운 고가용성 기능

적용 대상: Exchange Server 2007 SP1

마지막으로 수정된 항목: 2009-03-18

Microsoft Exchange Server 2007 SP1(서비스 팩 1)에서는 기존 고가용성 기능이 향상되었을 뿐만 아니라, 고가용성을 위한 몇 가지의 새로운 기능이 추가되었습니다. 새로운 기능과 향상된 기능을 사용하면, Exchange 2007 서버 역할에 대한 데이터 및 서비스 가용성을 얻을 수 있는 시나리오를 확장할 수 있습니다. 조직은 새 시나리오를 통해 사이트 복원 시나리오에서 고가용성 시나리오를 별도로 취급하여 조직의 특정 요구에 맞는 구성을 각 개별 영역에 배포할 수 있습니다.

Exchange 2007 SP1은 고가용성을 위한 다음과 같은 새로운 기능과 향상된 기존 고가용성 기능을 제공합니다.

• SCR(대기 연속 복제)

• Windows Server 2008의 다음과 같은 기능 지원

  • 복수 서브넷 장애 조치 클러스터

  • DHCP(Dynamic Host Configuration Protocol) IPv4(인터넷 프로토콜 버전 4)

  • IPv6

  • Exchange 및 장애 조치 클러스터 네트워크 구성

  • 새 쿼럼 모델(디스크 및 파일 공유 감시)

• CCR(클러스터 연속 복제) 환경에서 중복 클러스터 네트워크를 통한 연속 복제(로그 전달 및 시드)

• 보고 및 모니터링 향상

• 성능 향상

• 전송 쓰레기 수거통 향상

• Exchange 관리 콘솔 향상

이러한 각 기능에 대해서는 이러한 기능을 계획하고 배포 및 관리하는 방법에 대한 설명서를 볼 수 있는 링크와 함께 항목의 뒷부분에서 설명합니다. 다음 표에는 Windows Server 2003 및 Windows Server 2008의 장애 조치 클러스터 기능에 대한 Exchange 2007의 지원 사항이 요약되어 있습니다.

Exchange 2007 SP1에서 지원하는 장애 조치 클러스터 기능

대기 연속 복제

SCR은 Exchange 2007 SP1에 추가된 새로운 기능입니다. Exchange 2007 RTM의 기존 연속 복제 기능을 확장하는 SCR을 사용하면, Exchange 2007 사서함 서버에 대한 새 데이터 가용성 시나리오가 가능합니다. SCR은 LCR(로컬 연속 복제) 및 CCR에서 사용하는 동일한 로그 전달 및 재생 기술을 사용하여, 추가된 배포 옵션과 구성을 제공합니다. 이러한 SCR은 LCR 및 CCR과 유사하지만 다음과 같은 고유 특징이 있습니다.

• SCR은 저장소 그룹당 여러 대상을 지원합니다. LCR과 CCR은 저장소 그룹당 단 하나의 복제 대상(수동 복사본)을 지원합니다.

• 관리자는 SCR을 사용하여 복제 지연 시간을 지정할 수 있는데, 이는 다양한 시나리오에서 유용합니다. 예를 들어, NodeA에서 NodeB로의 손실 장애 조치(failover)를 취하는 경우, 손실된 로그 파일을 원격 NodeM에서 재생한 경우 NodeM을 다시 시드해야 합니다. 그러나 로그를 복사한 후에 재생하지 않았다면 로그가 삭제될 수 있고, 새 로그 파일을 복사하여 나중에 재생할 수 있습니다. 이 경우에는 NodeM에서 복사본을 다시 시드하지 않아도 됩니다.

• CCR 및 LCR과 달리 SCR 복사본은 백업할 수 없습니다. SCR을 사용할 때 SCR 복사본에 대한 데이터베이스 헤더가 업데이트되고, 원본 저장소 그룹에 대해 백업을 수행할 때 로그 파일이 잘립니다.

SCR을 사용하면 연속 복제를 통해, SCC 또는 CCR 환경에서 독립 실행형 사서함 서버 또는 클러스터된 사서함 서버에서 사서함 서버 데이터를 복제할 수 있습니다.

SCR에서 만들어 유지 관리하는 사서함 서버 데이터의 복사본을 활성화하는 프로세스는 수동 프로세스로, 다시 시작 또는 다른 간단한 방법으로 복구할 수 있는 단순한 서버 중단이 아니라 치명적인 오류가 발생할 때 사용하도록 설계되었습니다. 데이터베이스 이식성, 서버 복구 옵션(Setup /m:RecoverServer), 또는 사서함 서버가 클러스터된 경우에는 클러스터된 사서함 서버 복구 옵션(Setup /RecoverCMS)을 사용하여 SCR 대상을 활성화할 수 있습니다. 옵션은 해당 구성 및 발생한 오류 유형을 기준으로 선택합니다.

SCR에 대한 자세한 내용은 대기 연속 복제를 참조하십시오.

Windows Server 2008 지원

Windows Server 2008에는 Exchange 2007 SP1에서 지원하는 새 고가용성 기능이 있습니다. Windows Server 2008에서 장애 조치 클러스터(Windows Server 2003 및 이전 버전에서는 서버 클러스터라고 함)의 기능을 향상한 이유는 클러스터를 단순화하여 클러스터의 안전성과 안정성을 강화하기 위해서입니다. 또한 클러스터 설치 및 관리도 보다 쉬워지고 기본 클러스터 보안, 네트워킹 및 저장소 구성 요소도 향상되었습니다. 장애 조치 클러스터의 향상된 기능에 대한 전체 목록은 Windows Server 2008의 장애 조치 클러스터링(Failover Clustering with Windows Server 2008)을 참조하십시오.

Exchange 2007 SP1은 Windows Server 2008을 운영 체제 플랫폼으로 지원할 뿐 아니라 다음과 같은 Windows Server 2008 장애 조치 클러스터 기능도 지원합니다. 이러한 기능에 대한 지원도 명령줄 버전(Setup.com) 및 GUI(그래픽 사용자 인터페이스) 버전(Setup.exe, 또는 Exchange Server 2007 설치 마법사라고도 함)용 Exchange 2007 설치 프로그램에 통합되었습니다.

복수 서브넷 장애 조치 클러스터 지원

Windows Server 2008 장애 조치 클러스터링에서는 레거시 클러스터에서 사용하던 방법과는 상당히 다른 새 네트워킹 기능을 사용합니다. 예를 들어, Windows Server 2008 장애 조치 클러스터에는 복수 서브넷 지원 기능이 있습니다. Windows Server 2008 장애 조치 클러스터에서 실행되는 경우 Exchange 2007 SP1은 두 서브넷 간에 지리적으로 분산된 장애 조치(failover)용 클러스터를 지원하는데, CCR 환경의 사서함 서버와 두 개의 SCC를 지원합니다.

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

복수 서브넷 장애 조치 클러스터를 사용하는 경우, 네트워크 이름 리소스와 연결된 IP 주소가 온라인 상태가 되면 DNS(Domain Name System)에 동적으로 등록됩니다(동적 업데이트에 대해 구성된 경우). 따라서 온라인 상태의 IP 주소 리소스만 클라이언트에 반환됩니다. 클러스터 노드는 라우팅된 서로 다른 네트워크에 배치할 수 있으며 유니캐스트 UDP(사용자 데이터그램 프로토콜)를 통해 구현된 신뢰할 수 있는 세션 프로토콜을 사용하도록 통신 메커니즘이 변경되었으므로 지리적으로 분산된 Windows Server 2003 클러스터에 대한 네트워킹 요구 사항은 Windows Server 2008에서 더 이상 적용되지 않습니다. 이 결과 조직은 VLAN(가상 LAN) 기술을 사용하여 서브넷을 확장할 필요없이, 두 개의 실제 데이터 센터에 SCC 또는 CCR 환경을 배포할 수 있습니다.

지리적으로 분산된 여러 개의 서브넷 장애 조치 클러스터에 배포된 클러스터된 사서함 서버에 이동 또는 장애 조치(failover)가 발생하면, 클러스터된 사서함 서버의 이름은 유지 관리되지만 이 이름에 할당된 IP 주소는 유지 관리되지 않습니다. 클라이언트 및 다른 서버에 대한 이 서버의 가용성은 전체 DNS에 걸친 새 IP 주소의 전파에 따라 다릅니다. DNS 전파에는 시간이 다소 걸릴 수 있습니다. 이러한 이유로 클러스터된 사서함 서버 DNS 호스트 레코드의 TTL(Time to Live) 값을 10분으로 구성하는 것이 좋습니다.

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

ipconfig /flushdns

DHCP-IPv4 지원

Windows Server 2008 장애 조치 클러스터링에는 클러스터 IP 주소 리소스가 정적 항목을 통해서 뿐만 아니라 DHCP 서버에서 주소를 얻을 수 있는 기능이 있습니다. DHCP 서버에서 IP 주소를 가져오도록 클러스터 노드를 구성하면, 모든 클러스터 IP 주소 리소스에 대해 IP 주소를 자동으로 가져오도록 기본 작업이 수행됩니다. 클러스터 노드에 정적으로 할당된 IP 주소가 있으면 클러스터 IP 주소 리소스도 고정 IP 주소를 갖도록 구성해야 합니다. 따라서 클러스터 IP 주소 리소스 IP 할당은 실제 노드 및 노드의 각 특정 인터페이스 구성에 따라 이루어집니다.

IPv6 지원

Windows Server 2008 및 클러스터 서비스는 IPv6를 지원합니다. 그리고 IPv6 IP 주소 리소스 또는 IPv4 IP 주소 리소스를 각각 지원하거나 클러스터에서 조합하여 지원할 수 있습니다. 또한 장애 조치 클러스터는 ISATAP(Intra-site Automatic Tunneling Addressing Protocol)를 지원하고 DNS에서 동적 등록을 허용하는 IPv6 주소(AAAA 호스트 레코드 및 IP6.ARPA 역조회 영역)만을 지원합니다. 현재 IPv6 주소 유형에는 글로벌, 사이트 링크, 로컬 링크, 이 세 가지 유형이 있습니다. 링크 로컬 주소에는 동적 DNS 등록이 이루어지지 않으므로, 링크 로컬 주소는 클러스터에서 사용할 수 없습니다.

Exchange 및 장애 조치 클러스터 네트워크 구성

Exchange 2007 SP1에 대해 SCC 또는 CCR을 구성할 때 다음 요구 사항을 고려해야 합니다.

• IPv6 및 DHCP IPv4는 Windows Server 2008에서만 지원됩니다. Windows Server 2003에서 Exchange 2007을 실행하는 경우 두 가지 모두 사용할 수 없습니다.

• DHCP IPv6는 Windows Server 2008 또는 클러스터 서비스에서 지원되지 않습니다. 따라서 Exchange 2007에서도 지원되지 않습니다. 시스템에서 할당한 동적 IPv6 주소만 지원됩니다.

• 고정 IPv6 주소는 Windows Server 2008 및 클러스터 서비스에서 지원됩니다. 그러나 고정 IPv6 주소를 사용하면 최상의 결과를 낼 수 없습니다. 따라서 Exchange 2007에서는 설치 중에 고정 IPv6 주소를 구성할 수 없습니다.

• IPv4를 통한 IPv6 터널링은 Windows Server 2008 클러스터링에서 지원하지만, Exchange 설치 프로그램에서는 이 유형의 IP 주소 리소스를 만들 수 없습니다.

Exchange 2007 SP1의 설치 프로그램은 앞부분에서 설명한 변경 내용을 지원하도록 수정되었습니다. Exchange Server 2007 설치 마법사를 사용할 때, 클러스터 IP 주소 및 네트워크 이름 리소스 구성에 추가 페이지와 필드를 사용할 수 있음을 확인할 수 있습니다. 이 외에도 Setup.com의 /NewCMS 및 /RecoverCMS 옵션이 몇 가지 새로운 선택적 매개 변수를 지원하도록 업데이트되었습니다. 이 매개 변수에 대해서는 다음 표에서 설명합니다.

Exchange 2007 SP1에 추가된 /NewCMS 및 /RecoverCMS의 선택적 매개 변수

Microsoft Exchange Server 2007의 RTM(Release To Manufacturing) 버전의 /NewCMS 및 /RecoverCMS에 필수 매개 변수였던 CMSIPAddress 매개 변수는 클러스터된 사서함 서버용의 단일 고정 IPv4 주소를 지정할 때 여전히 사용됩니다. 그러나 Exchange 2007 SP1에서는 사용 가능한 네 개의 매개 변수 중 설치 시 어느 것을 사용해도 관계 없기 때문에, CMSIPAddress 매개 변수는 이제 선택적 매개 변수입니다.

위 표의 매개 변수는 Windows Server 2008에서만 사용할 수 있습니다.

Windows Server 2008의 새 쿼럼 모델

네트워크 문제가 발생하면 클러스터 노드 간 통신에 방해가 될 수 있습니다. 작은 집합의 노드는 작동하는 네트워크의 일부를 통해 서로 통신할 수 있지만, 다른 네트워크에 있는 서로 다른 집합의 노드와 통신하지 못할 수 있습니다. 이 경우에는 심각한 문제가 발생할 수 있습니다. 이 브레인 분할 상황에서는 노드 집합에 다른 노드 상태에 대한 명확한 정보가 없는 경우에도, 노드 집합 중 적어도 하나 이상의 노드가 클러스터로 실행되지 말아야 합니다.

클러스터의 분할로 인한 문제를 방지하려면, 클러스터 소프트웨어에서는 클러스터로 실행되는 모든 노드 집합에서 특정 시간에 노드 집합에 쿼럼이 있는지 결정하기 위해 응답 알고리즘을 사용하는 것이 필요합니다. 특정 클러스터에는 특정 노드 집합과 특정 쿼럼 구성이 있으므로, 클러스터는 몇 개의 응답 수가 과반수(쿼럼)를 구성하는지 인식할 수 있습니다. 응답 수가 과반수 이하이면 클러스터 실행이 중지됩니다. 다른 노드가 네트워크에 다시 표시되는 경우에는 노드에서 다른 노드가 있음을 계속해서 수신하지만, 쿼럼이 다시 존재할 때까지 노드가 클러스터로 작동하지 않습니다.

장애 조치 클러스터의 쿼럼 구성에서는 너무 많은 오류로 인해 클러스터 실행이 중지되는 지점을 결정합니다. 이 컨텍스트와 관련된 오류는 노드 오류이거나, 일부의 경우 클러스터 구성의 복사본을 포함하는 감시 디스크 또는 감시 파일 공유 오류이기도 합니다. Windows Server 2008에서는 다음과 같은 네 가지의 가능한 쿼럼 구성을 선택할 수 있습니다.

• 노드 과반수   이 모델은 노드가 홀수인 클러스터에 권장되며, 노드의 반에서 1을 뺀 수의 오류를 유지할 수 있습니다. 예를 들어, 7노드 클러스터는 3노드 오류를 유지할 수 있습니다.

• 노드 및 디스크 과반수   이 모델은 노드가 짝수인 클러스터에 권장되며, 감시 디스크가 온라인 상태인 경우 노드의 반에 해당하는 수의 오류를 유지할 수 있습니다. 예를 들어, 감시 디스크가 있는 6노드 클러스터는 3노드 오류를 유지할 수 있습니다. 또한 감시 디스크가 오프라인이거나 디스크에 문제가 발생했을 경우에는 노드의 반에서 1을 뺀 수의 오류를 유지할 수 있습니다. 예를 들어, 감시 디스크에 오류가 발생한 6노드 클러스터는 2노드 오류를 유지할 수 있습니다(3-1=2).

• 노드 및 파일 공유 과반수   이 모델은 특수 구성을 가진 클러스터용으로 설계된 것으로, CCR 환경에서 클러스터된 사서함 서버에 권장됩니다. 이 모델은 노드 및 디스크 과반수 모델과 같은 방식으로 작동하지만, 감시 디스크 대신 감시 파일 공유를 사용합니다.

• 과반수 안 됨: 디스크 전용   이 모델은 지원은 되지만 권장되지 않습니다. 이 모델은 1노드 오류를 제외한 모든 노드 오류를 유지할 수 있습니다. 그러나 디스크가 단일 지점에서 실패하므로 이 구성은 권장되지 않습니다.

중복 클러스터 네트워크를 통한 연속 복제

Exchange 2007 RTM의 경우 CCR 환경의 모든 트랜잭션 로그 파일 복사 및 시드 작업은 공용 네트워크를 통해 발생합니다. 이 구성에는 다음과 같은 제한이 있습니다.

• 수동 노드를 몇 시간 동안 사용할 수 없는 경우에는 전송해야 할 로그가 엄청나게 많이 쌓입니다. 이러한 로그는 수동 노드가 다시 사용할 수 있게 되었을 때 가능한 빨리 이동되어야 합니다. 그런데 공용 네트워크를 통해 로그를 복사하면 로그의 이동이 클라이언트 트래픽과 경쟁하게 됩니다. 이로 인해 클라이언트 트래픽에 영향을 미치게 되며 재동기화가 느려집니다.

• 공용 네트워크에 오류가 발생하면, 로그 데이터를 사용할 수 있는 경우에도 장애 조치(failover)에 손실이 발생합니다.

• 로그 통신에 격리 네트워크를 사용하면, 암호화를 사용하지 않고도 관련 성능의 손실 없이 데이터 메시징을 보안할 수 있습니다.

• 몇 가지 상황에서는 로그 폭풍이 일어날 수 있는데, 이 경우 시스템의 복제 부하량이 비정상적으로 많아집니다. 이러한 상황에서는 클라이언트와의 통신에 사용된 동일한 네트워크를 통해 로그 데이터를 통신해야 할 경우, 클라이언트 부족이 발생할 수 있습니다.

이러한 문제가 모두 같은 주기로 발생되는 것은 아닙니다. 하지만 첫 번째 문제는 수동 노드가 정기적인 유지 관리 작업을 위해 오프라인 상태로 되므로 몇 달의 주기로 발생됩니다.

Exchange 2007 SP1에서는 관리자가 로그 전달을 위한 혼합 네트워크를 하나 이상 클러스터(예: 내부 클러스터 하트비트와 클라이언트 트래픽을 모두 지원하는 클러스터 네트워크)에 만들 수 있으므로 위 문제의 영향을 최소화할 수 있습니다. Exchange 2007 SP1에서는 관리자가 시드용 네트워크를 지정할 수도 있습니다.

혼합 네트워크를 통한 로그 파일 복사 지원 기능은 Enable-ContinuousReplicationHostName라는 새로운 Exchange 관리 셸 cmdlet를 사용하여 구성됩니다. 마찬가지로 이 기능은 Disable-ContinuousReplicationHostName cmdlet를 사용하여 해제됩니다. 클러스터된 사서함 서버가 CCR 환경에 있는 경우, 관리자는 Enable-ContinuousReplicationHostName을 클러스터의 양쪽 노드에서 실행하고, 추가 IP 주소와 호스트 이름을 지정할 수 있습니다. 이후에 이러한 주소와 호스트 이름은 각 노드와 연결된 전용 클러스터 그룹에 만들어집니다. 이 작업이 수행된 이후, 구성이 완료되고 새 네트워크가 작동되는지 확인되면 바로 Microsoft Exchange Replication Service는 로그를 복사하는 데 새로 만든 네트워크를 사용하기 시작합니다. 새 네트워크가 여러 개 만들어지면, Microsoft Exchange Replication Service는 그 중 하나를 임의로 선택합니다. 특정 네트워크가 사용할 수 없게 되면 Microsoft Exchange Replication Service는 자동으로 다른 복제 네트워크를 사용하기 시작하고, 모든 네트워크를 사용할 수 없게 되면 공용 네트워크를 사용하여 5분 내에 로그를 전달합니다. (Microsoft Exchange Replication Service 네트워크 검색은 5분마다 수행됩니다.) 기본 설정 복제 네트워크를 다시 사용할 수 있게 되면 Microsoft Exchange Replication Service는 기본 설정 복제 네트워크를 사용하여 로그를 전달하도록 자동으로 전환됩니다. 이러한 cmdlet에 대한 자세한 내용은 Enable-ContinuousReplicationHostName 및 Disable-ContinuousReplicationHostName을 참조하십시오.

중복 클러스터 네트워크를 통한 시드 지원은 Update-StorageGroupCopy cmdlet를 사용하여 구성됩니다. Exchange 2007 SP1에서 이 cmdlet는 DataHostNames라는 새 매개 변수를 포함하도록 업데이트되었습니다. 이 매개 변수는 시드에 사용해야 하는 클러스터 네트워크를 지정하는 데 사용됩니다. Exchange 2007 SP1의 Update-StorageGroupCopy cmdlet 변경 내용에 대한 자세한 내용은 Update-StorageGroupCopy를 참조하십시오.

연속 복제를 위해 클러스터 네트워크를 만들었으면, Get-ClusteredMailboxServerStatus cmdlet를 사용하여 연속 복제 작업에 사용할 수 있는 클러스터 네트워크에 대한 업데이트 정보를 볼 수 있습니다. 새로운 출력 자세히는 다음과 같습니다.

• OperationalReplicationHostNames:{Host1,Host2,Host3}

• FailedReplicationHostNames:{Host4}

• InUseReplicationHostNames:{Host1,Host2}

Exchange 2007 SP1의 Get-ClusteredMailboxServerStatus cmdlet 변경 내용에 대한 자세한 내용은 Get-ClusteredMailboxServerStatus를 참조하십시오.

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

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

연속 복제에 클러스터 네트워크를 사용하지 않도록 설정하는 방법에 대한 자세한 내용은 클러스터 네트워크의 연속 복제를 사용하지 않도록 설정하는 방법을 참조하십시오.

보고 및 모니터링 향상

Exchange 2007 SP1에는 Exchange 2007의 관리 효율을 향상시키는 몇몇 변경 내용이 포함되어 있습니다. 이러한 변경 내용에는 Exchange 2007 RTM의 클러스터 보고 기능을 향상시킨 것과 연속 복제 환경을 사전 모니터링하기 위해 설계된 추가 기능이 포함된 것 등이 있습니다. 특히 변경 내용 및 기능 향상을 통해 Get-StorageGroupCopyStatus cmdlet의 알려진 결함이 수정되고, Test-ReplicationHealth라는 새로운 cmdlet가 제공되며 전송 쓰레기 수거통의 손실 창에 대해 더욱 명확히 파악할 수 있습니다. 이러한 보고 및 모니터링 향상에 대한 자세한 내용은 연속 복제 모니터링을 참조하십시오.

성능 향상

Exchange 2007 SP1에서는 성능 향상을 통해 고가용성 배포의 효율성을 높였습니다. 향상된 내용은 다음과 같습니다.

• 연속 복제 환경에서 저장소 그룹의 수동 복사본을 포함하는 디스크의 I/O 감소   Exchange 2007 SP1에서 연속 복제 아키텍처의 디자인이 수정되어, 이제 데이터베이스 캐시가 일련의 로그 재생 작업 간의 수동 노드에서 유지됩니다. 일련의 로그 재생 작업 간에 데이터베이스 캐시가 유지됨으로써, Microsoft Exchange Replication Service는 ESE(Extensible Storage Engine)의 데이터베이스 캐싱 기능을 사용할 수 있게 되어, 결과적으로 수동 복사본의 LUN(논리 단위 번호)에서 발생하는 디스크 I/O(입/출력) 양이 감소합니다. 반면 Exchange 2007 RTM에서는 각 일련의 로그 재생 작업에 대한 새 데이터베이스 캐시가 만들어져서, 일부 경우에 수동 노드의 디스크 I/O 작업이 활성 노드의 디스크 I/O 작업보다 2-3배 많아졌습니다.

  CCR 환경의 노드 간에 클러스터된 사서함 서버의 신속한 이동   이 향상된 기능을 통해 클러스터된 사서함 서버가 2분 내에 노드 간에 이동할 수 있습니다. 이에는 관리자가 Move-ClusteredMailboxServer cmdlet를 사용하여 수행하는 이동과 클러스터 서비스가 관리하는 장애 조치(failover)가 포함됩니다. 데이터베이스는 CCR 환경에서 신속하게 이동하기 위해, 데이터베이스 캐시를 플러시하지 않고 오프라인 상태가 됩니다. SCC에서 클러스터된 사서함 서버를 이동하는 데는 약 5분이 걸립니다. 클러스터된 사서함 서버가 이동되기 전에 데이터베이스 캐시는 여전히 플러시됩니다. 이는 클라이언트를 데이터베이스와 연결한 채로 유지시켜 주는 편의적 플러시입니다. 이러한 작업을 통해, 클러스터된 사서함 서버가 다른 노드로 이동될 때 발생되는 가동 중지 시간을 줄일 수 있습니다.

  장애 조치 프로세스 중에 플러시 작업 상태를 나타내는 이벤트 ID 9868이 두 번 기록되고, 복제 상태를 나타내는 이벤트 ID 113이 기록됩니다. 이러한 이벤트는 다음과 유사합니다.

  이벤트 ID: 9868 원본: MSExchangeIS 범주: 일반 유형: 정보 설명: '<사서함 서버 이름>' 서버에 대한 캐시를 플러시하려고 했으나 원하는 검사점 수준에 도달하지 못하고 0 저장소 그룹에서 끝났습니다.

  이벤트 ID: 9868 원본: MSExchangeIS 범주: 일반 유형: 정보 설명: '<사서함 서버 이름>' 서버에 대한 캐시를 플러시하려고 했으나 원하는 검사점 수준에 도달하지 못하고 2 저장소 그룹에서 끝났습니다.

  이벤트 ID: 113 원본: MSExchangeRepl 범주: 이동 유형: 정보 설명: 클러스터된 사서함 서버 '<사서함 서버 이름>'을(를) 이동하기 전에 정보 저장소 캐시 플러시가 완료되지 않았습니다. 데이터: 저장소 그룹 '<사서함 서버 이름>\<저장소 그룹 이름>': 검사점 수준 시작은 19이고 끝은 17입니다. 저장소 그룹 '<사서함 서버 이름>\<두 번째 저장소 그룹 이름>': 검사점 수준 시작은 19이고 끝은 13입니다.

전송 쓰레기 수거통 향상

전송 쓰레기 수거통은 허브 전송 서버 역할의 기능입니다. 전송 쓰레기 수거통은 CCR 환경에서 클러스터된 사서함 서버에 사서함이 있는 받는 사람에게 최근 배달된 메시지 큐를 관리합니다. 이 큐는 메일이 유지되는 시간과 사용되는 전체 공간의 구속을 받습니다. 무손실이 아닌 장애 조치(failover)가 발생하는 경우, 클러스터된 사서함 서버는 Active Directory 사이트의 모든 허브 전송 서버를 자동으로 요청하여 전송 쓰레기 수거통 큐에서 메일을 다시 전송합니다.

Exchange 2007 SP1의 전송 쓰레기 수거통 기능은 다음과 같은 방식으로 향상되었습니다.

• LCR 지원   이제 전송 쓰레기 수거통은 LCR 배포를 지원합니다. 전송 쓰레기 수거통 재배달 요청이 복구 프로세스의 일부로 자동 수행되는 CCR과 달리, LCR 환경에서는 프로세스가 수동으로 수행됩니다. Exchange 2007 SP1에서는 Restore-StorageGroupCopy cmdlet가 전송 쓰레기 수거통 재전송 요청을 포함하도록 업데이트되었습니다. 따라서 관리자는 Restore-StorageGroupCopy cmdlet를 사용하여 LCR 환경에서 저장소 그룹의 수동 복사본을 활성화하면, 전송 쓰레기 수거통 전송 요청이 활성화 프로세스의 일부로 발생합니다.

• 전송 쓰레기 수거통 통계   로그 파일이 누락된 서버를 복구하기 전에 관리자에게 보다 나은 정보를 제공하기 위해, 영향을 받은 저장소 그룹에 대한 메시지를 포함하는 모든 허브 전송 서버의 현재 상태를 제공하는 통계 정보를 포함하도록 전송 쓰레기 수거통이 향상되었습니다. 이러한 통계에는 가장 오래된 메시지 보존 기간 뿐만 아니라 Active Directory 사이트의 각 허브 전송 서버에서 사용할 수 있는 메시지 수도 포함됩니다. 이러한 통계는 DumpsterStatistics라는 Get-StorageGroupCopyStatus cmdlet의 새 매개 변수를 사용하여 볼 수 있습니다. 이 새 값을 사용하면, 액세스할 수 있는 모든 허브 전송 서버의 전송 쓰레기 수거통 통계와 액세스할 수 없는 허브 전송 서버 목록이 Get-StorageGroupCopyStatus에 대한 출력에 포함됩니다. 다음과 같이, 액세스할 수 있는 서버는 DumpsterStatistics라는 다중값 구조에 나열되고, 액세스할 수 없는 서버는 DumpsterStatisticsNotAvailable라는 다중값 문자열로 나열됩니다.

  DumpsterStatistics: {HUB1(가장 오래된 타임 스탬프; 쓰레기 수거통의 항목 수; 쓰레기 수거통 크기), HUB2(가장 오래된 타임 스탬프; 쓰레기 수거통의 항목 수; 쓰레기 수거통 크기), HUB3(가장 오래된 타임 스탬프; 쓰레기 수거통의 항목 수; 쓰레기 수거통 크기)}

  DumpsterStatisticsNotAvailable: {HUB4,HUB5}

  위의 예에서 가장 오래된 타임 스탬프는 메시지가 사서함 서버로 처음 배달된 시간이 아니라 허브 전송 서버에서 메시지를 수신한 시간입니다.

  또한 Get-StorageGroupCopyStatus cmdlet에는 다음과 같이 해결되지 않은 요청과 이러한 요청에 대한 시간 범위(low–high)가 포함된 허브 전송 서버가 있는 OutstandingDumpsterRequests라는 새 다중값 구조도 포함됩니다.

  OutstandingDumpsterRequests: {HUB1(time-low;time_high), HUB5(time_low;time_high)}

Exchange 관리 콘솔 향상

Exchange 2007 SP1에는 클러스터된 사서함 서버의 관리와 구성을 향상시키기 위해 설계된 Exchange 관리 콘솔의 새 GUI 요소가 있습니다. 향상된 내용은 다음과 같습니다.

• 클러스터된 사서함 서버 관리 마법사   이 마법사는 CCR 환경 및 SCC에서 클러스터된 사서함 서버를 이동, 중지 또는 시작하는 데 사용됩니다. 이동 및 중지 기능에는 선택적 관리자 설명 필드도 있어, 관리자는 클러스터된 사서함 서버가 이동되거나 중지된 이유를 입력할 수 있습니다. 이 마법사는 다음과 같은 Exchange 관리 셸 cmdlet를 사용하는 것과 동일한 기능을 합니다.

  • Move-ClusteredMailboxServer

  • Stop-ClusteredMailboxServer

  • Start-ClusteredMailboxServer

• 연속 복제 관리   관리자가 연속 복제를 중단, 다시 시작, 업데이트 및 복원할 수 있는 추가 사용자 인터페이스 컨트롤이 Exchange에 추가되었습니다. 이러한 컨트롤은 다음과 같은 Exchange 관리 셸 cmdlet를 사용하는 것과 동일한 기능을 합니다.

  • Suspend-StorageGroupCopy

  • Resume-StorageGroupCopy

  • Update-StorageGroupCopy

  • Restore-StoreGroupCopy

  이러한 cmdlet와 해당 Exchange 관리 콘솔 작업을 통해 LCR 환경과 CCR 환경에서 모두 연속 복제를 관리할 수 있습니다.

  참고

  CCR 환경의 경우 저장소 그룹 복사본 업데이트 마법사는 수동 노드에서만 사용할 수 있고, 저장소 그룹 복사본 복원 마법사는 활성 노드에서만 사용할 수 있습니다.

• 클러스터된 사서함 서버 탭   클러스터에 있는 사서함 서버에 대한 서버 속성 대화 상자에 새 탭이 추가되었습니다. 이 정보는 CCR 환경 및 SCC에서 사용할 수 있습니다. 클러스터된 사서함 서버에 대한 자세히가 있는 새 탭을 사용하여, 관리자는 CCR 환경에서 클러스터된 사서함 서버에 대한 AutoDatabaseMountDial 속성의 값을 구성할 수 있습니다. 새 탭에 표시되는 대부분의 정보는 Get-ClusteredMailboxServerStatus cmdlet를 통해서도 사용할 수 있습니다. 클러스터된 사서함 서버 탭에 대한 자세한 내용은 서버 속성 > 클러스터된 사서함 서버 탭을 참조하십시오.

• 클러스터 연속 복제 페이지   CCR 환경에 배포되는 사서함 서버에 대한 저장소 그룹 속성 대화 상자에 새 페이지가 추가되었습니다. 새 속성 페이지에는 클러스터의 연속 복제 상태에 대한 자세히가 있습니다. 클러스터 연속 복제 페이지에 대한 자세한 내용은 저장소 그룹 속성 > 클러스터 연속 복제 페이지를 참조하십시오.

자세한 내용

Windows Server 2008에는 향상되거나 이름이 바뀐 여러 기능이 포함되어 있습니다. Windows Server 2003과 Windows Server 2008 간에 변경된 기능에 대한 자세한 내용은 용어 변경 사항을 참조하십시오.