고가용성
적용 대상: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
마지막으로 수정된 항목: 2009-04-01
이 고가용성 콘텐츠 영역에는 Microsoft Exchange Server 2007의 RTM(Release To Manufacturing) 버전 및 Exchange 2007 SP1(서비스 팩 1)을 바탕으로 고가용성 메시징 시스템을 설계, 구축 및 운영하는 데 사용할 수 있는 항목이 포함됩니다. 이 영역의 관련 설명서는 다음과 같습니다.
Exchange 2007 SP1을 바탕으로 고가용성 메시징 솔루션을 설계하거나 배포하기 전에 해당 설명서를 검토하는 것이 좋습니다.
지속적인 업데이트를 통해 이 영역의 설명서에는 Exchange 2007 SP1을 Windows Server 2008 및 Windows Server 2003 SP2(서비스 팩 2)에 배포하기 위한 최신 권장 사항과 모범 사례가 포함되어 있습니다.
Exchange Server 2007의 고가용성
최소 작동 시간 요구 사항이 조직마다 다르지만 모든 조직은 높은 수준의 작동 시간을 달성하기를 원합니다. 메시징이 업무에 중요한 조직은 이 작동 시간을 제공하기 위해 일반적으로 고가용성 메시징 시스템을 디자인합니다.
Exchange 2007 RTM 버전 및 Exchange 2007 SP1에는 Exchange 2007 사서함 서버를 위한 빠른 복구, 고가용성 및 사이트 복구를 제공할 수 있는 다음과 같은 기본 제공 기능이 포함되어 있습니다.
LCR(로컬 연속 복제) LCR은 기본 제공되는 비동기 로그 전달 기술을 사용하여 프로덕션 저장소 그룹과 동일한 서버에 연결되는 두 번째 디스크 집합에 저장소 그룹의 복사본을 만들고 유지 관리하는 단일 서버 솔루션입니다. LCR은 로그 전달 및 로그 재생을 제공하며 데이터의 보조 복사본으로 빨리 수동 전환할 수 있도록 합니다.
CCR(클러스터 연속 복제) 저장소가 공유되지 않는 장애 조치(failover) 클러스터 솔루션인 CCR은 Exchange 2007에서 사용할 수 있는 두 가지 유형의 CMS(클러스터된 사서함 서버) 배포 중 하나입니다. CCR은 기본 제공되는 비동기 로그 전달 기술을 사용하여 장애 조치 클러스터의 보조 서버에 각 저장소 그룹의 복사본을 만들고 유지 관리하는 클러스터된 솔루션(CCR 환경이라고도 함)으로, 고가용성과 사이트 복구 기능을 모두 제공하는 하나 또는 두 개의 데이터 센터 솔루션으로 설계되었습니다. CCR은 이전 버전의 Exchange Server에서의 클러스터링과는 매우 다릅니다. 몇 가지 차이점에 대한 자세한 내용은 클러스터된 사서함 서버의 Exchange 클러스터 리소스 및 클러스터 연속 복제 복구 동작을 참조하십시오.
SCR(대기 연속 복제) SCR은 Exchange 2007 SP1에 도입된 새로운 기능입니다. 이름이 암시하듯이 SCR은 대기 복구 서버를 사용하는 시나리오를 위해 설계되었습니다. SCR은 기존의 연속 복제 기능을 확장하여 Exchange 2007 사서함 서버에 새로운 데이터 가용성 시나리오를 사용할 수 있도록 합니다. SCR은 LCR과 CCR에서 사용하는 동일한 로그 전달 및 재생 기술을 사용하여 관리자에게 추가 저장소 그룹 복사본을 만들 수 있는 기능을 제공함으로써 추가된 배포 옵션과 구성을 제공합니다. SCR을 사용하면 독립 실행형 사서함 서버 및 클러스터된 사서함 서버의 데이터를 복제할 수 있습니다.
SCC(단일 복사본 클러스터) 저장소가 공유되는 장애 조치 클러스터 솔루션인 SCC는 Exchange 2007에서 사용할 수 있는 두 가지 유형의 클러스터된 사서함 서버 배포 중 나머지 하나입니다. SCC는 클러스터의 노드 간에 공유되는 저장소의 저장소 그룹에 대한 단일 복사본을 사용하는 클러스터된 솔루션으로, 이전 버전의 Exchange Server의 클러스터링과 다소 유사한 점이 있지만, 수많은 향상된 기능과 더불어 몇 가지 중요한 변경 내용도 있습니다. 이러한 변경 내용 중 몇 가지 내용에 대한 자세한 내용은 단일 복사본 클러스터 리소스 모델 및 단일 복사본 클러스터 복구 동작을 참조하십시오.
SP1에 도입된 기타 고가용성 기능에 대한 자세한 내용은 Exchange 2007 SP1의 새로운 고가용성 기능을 참조하십시오.
사서함 서버의 고가용성
사서함 서버의 고가용성은 서비스 가용성과 데이터 가용성이라는 두 가지 형태로 제공됩니다. 서비스 가용성은 Windows Server 장애 조치 클러스터 사용을 통해 제공되며, 데이터 가용성은 연속 복제라는 기본 제공 기능을 통해 제공됩니다.
클러스터된 사서함 서버
CCR과 SCC 모두 Windows Server 장애 조치 클러스터에 배포되는 솔루션입니다. 장애 조치 클러스터에는 사서함 서버 역할만 설치할 수 있으며 다른 역할은 설치할 수 없습니다. 장애 조치 클러스터에 배포된 사서함 서버를 클러스터된 사서함 서버라고 부릅니다. CCR 환경에서 실행되는 클러스터된 사서함 서버는 SCC 환경에서 실행되는 클러스터된 사서함 서버와 큰 차이가 있습니다. 또한 Exchange 2007 RTM 버전 및 Exchange 2007 SP1의 클러스터된 사서함 서버도 Microsoft Exchange 이전 버전의 클러스터된 사서함 서버와 큰 차이가 있습니다.
Exchange 관리 셸의 Get-MailboxServer <CMSName> | fl Name, ClusteredStorageType을 사용하면 클러스터된 사서함 서버가 CCR 환경 또는 SCC에서 호스팅되는지를 확인할 수 있습니다. 값이 NonShared인 경우 클러스터된 사서함 서버가 CCR 환경에 있는 것이고, Shared인 경우 클러스터된 사서함 서버가 SCC에 있는 것입니다. 값이 Disabled인 경우에는 사서함 서버가 독립 실행형 서버인 것입니다.
또한 사서함 서버 개체의 msExchClusterStorageType 특성 값을 검토하여 Active Directory를 확인함으로써 클러스터된 사서함 서버가 CCR 환경 또는 SCC에서 호스팅되는지를 확인할 수 있습니다. msExchClusterStorageType 특성의 값이 1인 경우 클러스터된 사서함 서버가 CCR 환경에서 호스팅되는 것이고, 값이 2인 경우 클러스터된 사서함 서버가 SCC에 있는 것입니다. 값이 **<Not Set>**인 경우에는 사서함 서버가 독립 실행형 서버인 것입니다.
CCR 환경
Exchange 2007 RTM 버전 및 Exchange 2007 SP1는 CCR 환경에서 사서함 서버 역할이 설치된 노드를 최대 두 개(하나는 활성 노드, 하나는 수동 노드) 지원합니다. Voter 노드 하나와 기존 MNS(과반수 노드 집합) 쿼럼 하나를 사용하는 3개 노드 장애 조치 클러스터도 지원하지만 선호하는 클러스터 모델은 아닙니다. 하지만 대부분의 사용자는 단 두 개의 노드와 함께 노드 하나와 파일 공유 과반수 쿼럼(Windows Server 2008) 또는 파일 공유 감시 쿼럼이 포함된 과반수 노드 집합(Windows Server 2003)을 사용하는 CCR 환경을 배포하는 것이 좋습니다. 따라서 CCR에 대한 설명서는 이러한 쿼럼 모델 중 하나를 사용하는 2개 노드 장애 조치 클러스터에 초점을 둡니다.
참고
CCR 환경에 배포된 단일 노드 장애 조치 클러스터 역시 지원되지만 클러스터에 중복성이 없으므로 고가용성 솔루션으로 간주되지 않습니다. CCR 환경에 배포된 단일 노드 장애 조치 클러스터를 사용하는 경우 과반수 노드 집합 쿼럼(기존, 파일 공유 감시 포함 안됨)을 사용해야 합니다.
단일 복사본 클러스터
Exchange 2007 RTM 버전 및 Exchange 2007 SP1에서는 SCC에서 최대 8개의 노드를 지원합니다. Windows Server 장애 조치 클러스터에서의 올바른 Exchange 2007 SP1 SCC 조합은 다음과 같습니다.
활성 노드 7개/수동 노드 1개
활성 노드 6개/수동 노드 1-2개
활성 노드 5개/수동 노드 1-3개
활성 노드 4개/수동 노드 1-4개
활성 노드 3개/수동 노드 1-5개
활성 노드 2개/수동 노드 1-6개
활성 노드 1개/수동 노드 0-7개
참고
64비트 버전의 Windows Server 2008은 단일 장애 조치 클러스터에서 최대 16개의 노드를 지원하지만 Exchange 2007은 이 클러스터에서 최대 8개의 노드를 지원합니다. 장애 조치 클러스터에는 여전히 최대 16개의 노드를 포함할 수 있지만 Exchange 2007은 장애 조치 클러스터의 8개 이하의 노드에 설치되어야 합니다.
일반적으로 클러스터에서 각 활성 노드에 수동 노드를 여러 개 사용할 필요가 없습니다. 그러므로 활성 노드 한 개와 수동 노드 여러 개를 사용하는 구성보다 활성 노드와 수동 노드를 하나씩 사용하는 구성이 좋습니다. 단일 노드 SCC를 사용하는 경우 공유 저장소 쿼럼이나 과반수 노드 집합 쿼럼(기존, 파일 공유 감시 포함 안됨) 중 하나를 사용할 수 있습니다. 단일 노드 SCC가 지원되기는 하지만 클러스터 내에 중복성이 없으므로 고가용성 솔루션으로 간주되지는 않습니다.
확장 클러스터
지리적으로 분산된 클러스터라고도 하는 확장 클러스터는 여러 실제 데이터 센터로 확장(스팬)되는 장애 조치(failover) 클러스터입니다. 이 확장 클러스터는 Exchange 조직에서 사이트 복구 기능의 일부분으로 사용할 수 있습니다. CCR은 공유 저장소를 사용하지 않으므로 Windows Server 2008의 여러 서브넷 확장 클러스터를 포함해 지리적으로 분산된 장애 조치(failover) 클러스터에 쉽게 배포할 수 있습니다. 확장 클러스터에서는 SCC도 지원되지만 SCC를 확장하려면 타사 동기 복제 기술을 사용해야 합니다. 확장 클러스터에 대한 자세한 내용은 Site Resilience Configurations을 참조하십시오.
대기 클러스터
Exchange 2007 및 Exchange 2007 SP1에서 지원되는 또 다른 클러스터 유형은 대기 클러스터입니다. 대기 클러스터는 클러스터된 사서함 서버가 포함되지 않은 Windows Server 장애 조치 클러스터이지만 재해나 프로덕션 장애 조치 클러스터의 오류 발생 또는 그 밖의 몇 가지 복구 시나리오에서 클러스터된 사서함 서버를 대체하도록 신속하게 제공될 수 있습니다.
연속 복제
로그 전달이라고도 하는 연속 복제는 닫힌 트랜잭션 로그 파일을 프로덕션 저장소 그룹에서 로컬 컴퓨터나 다른 서버의 두 번째 디스크 집합에 있는 해당 저장소 그룹의 복사본으로 자동으로 복제하는 프로세스입니다. 두 번째 위치에 복사된 로그 파일은 데이터베이스의 복사본으로 재생되며, 그로 인해 약간의 지연 시간을 두고 저장소 그룹의 동기화를 유지합니다.
연속 복제는 Exchange 2007 RTM에서 두 가지 형태(LCR 및 CCR)로, Exchange 2007 SP1에서는 세 가지 형태(LCR, CCR 및 SCR)로 사용할 수 있습니다.
기타 서버 역할의 고가용성
서버 중복성, NLB(네트워크 부하 분산), 하드웨어 부하 분산, DNS(Domain Name System) 라운드 로빈뿐만 아니라 자동 관리 서버, 서비스 및 인프라 관리를 함께 사용하여 허브 전송, Edge 전송, 클라이언트 액세스 및 통합 메시징 서버 역할에 대한 고가용성을 달성할 수 있습니다. 일반적으로 다음 전략과 기술을 사용하여 클라이언트 액세스, 허브 전송, Edge 전송 및 통합 메시징 서버 역할에 대한 고가용성을 달성할 수 있습니다.
Edge 전송 여러 Edge 전송 서버를 배포하고 여러 DNS MX(메일 교환기) 레코드를 사용하여 이러한 서버에서의 작업 부하를 분산시킬 수 있습니다. NLB를 사용하여 Edge 전송 서버에 부하 분산 및 고가용성을 제공할 수도 있습니다.
클라이언트 액세스 클라이언트 액세스 서버의 가용성을 높이기 위해 NLB 또는 타사 하드웨어 기반 네트워크 부하 분산 장치를 사용할 수 있습니다. NLB에 대한 자세한 내용은 Windows Server TechCenter를 참조하십시오.
허브 전송 내부 전송 가용성을 높이기 위해 허브 전송 서버를 여러 개 배포할 수 있습니다. 복구는 허브 전송 서버 역할에 대해 다음 방법으로 설계되었습니다.
허브 전송 서버 간(조직 내) 조직 내 허브 전송 서버 간 통신은 대상 Active Directory 디렉터리 서비스 사이트에 있는 사용 가능한 허브 전송 서버 간에 자동으로 부하를 분산합니다.
사서함 서버와 허브 전송 서버 간(Active Directory 사이트 내) 사서함 서버의 Microsoft Exchange Mail Submission Service는 동일한 Active Directory 사이트에 있는 사용 가능한 모든 허브 전송 서버 간에 자동으로 부하를 분산합니다.
통합 메시징 서버와 허브 전송 서버 간 통합 메시징 서버는 동일한 Active Directory 사이트에 있는 사용 가능한 모든 허브 전송 서버 간 연결의 부하를 자동으로 분산합니다.
Edge 전송 서버와 허브 전송 서버 간 Edge 전송 서버는 인바운드 SMTP(Simple Mail Transfer Protocol) 트래픽의 부하를 Edge 전송 서버가 구독된 Active Directory 사이트에 있는 모든 허브 전송 서버에 자동으로 분산합니다.
추가 중복(예: SMTP 릴레이가 필요한 응용 프로그램)을 위해, 새 DNS 레코드(예: relay.company.com)를 만들고, IP 주소를 할당하며 하드웨어 부하 분산 장치를 사용하여 해당 IP 주소를 여러 허브 전송 서버에 리디렉션할 수 있습니다. 또한 Exchange 2007 SP1에서는 허브 전송 서버의 클라이언트 커넥터에 대해 NLB도 사용할 수 있습니다. 조직 내 트래픽에서는 앞에서 설명한 기본 제공 부하 분산 알고리즘을 사용하므로 하드웨어 부하 분산 장치를 사용하는 경우, 하드웨어 부하 분산 장치와 교차하고 있는 조직 내 Exchange 2007 트래픽이 없는지 확인해야 합니다. 부하 분산 및 전송 서버에 대한 자세한 내용은 Hub 전송 서버의 배포 옵션 및 전송 서버에 대한 부하 분산 및 내결함성을 참조하십시오.
통합 메시징 둘 이상의 서버가 단일 다이얼 플랜 내에 있는 여러 통합 메시징 서버를 배포하면 통합 메시징 배포를 보다 원활하게 수행할 수 있습니다. 통합 메시징에서 지원하는 VoIP(Voice over IP) 게이트웨이를 통합 메시징 서버에 대한 호출을 라운드 로빈 방식으로 라우팅하도록 구성할 수 있습니다. 또한 이러한 게이트웨이를 통해 DNS에서 다이얼 플랜의 서버 목록을 검색할 수 있습니다. 두 경우 모두 VoIP 게이트웨이에서는 통합 메시징 서버에 대한 호출을 제공하며 해당 호출은 수락되지 않는 경우 호출이 설정된 시점에서 중복성을 제공하는 다른 서버로 제공됩니다.
데이터 및 서비스 중복성을 사용하여 가용성 높이기
Exchange 2007 고가용성 아키텍처의 기본 전제는 배포 과정에 중복성을 도입하는 것입니다. 발생하는 오류는 Exchange 서비스를 지원하기 위해 나머지 컴퓨팅 리소스를 사용하여 복구됩니다. 그리고 오류가 복구되면 컴퓨팅 리소스를 다시 Exchange 및 해당 클라이언트에서 사용할 수 있습니다. 이러한 맥락에서 볼 때 컴퓨팅 리소스는 컴퓨터일 수도 있고 사서함 또는 다른 Exchange 데이터의 저장소일 수도 있습니다.
중복성을 단일 데이터 센터 내로 도입할 수 있습니다. 이 방법은 일반적으로 개별 서버 오류를 방지하기 위해 수행됩니다. 예를 들어 조직의 기본 데이터 센터에 두 번째 허브 전송 서버를 도입하면 두 서버 중 하나에 오류가 발생해도 메일 흐름이 계속 진행됩니다.
또한 중복성을 두 번째 데이터 센터에 도입할 수도 있습니다. 두 개의 데이터 센터를 구성하면 데이터 센터에 오류가 발생해도 서비스를 계속 제공할 수 있습니다. 추가 허브 전송 서버를 보조 데이터 센터에 도입하는 경우 기본 허브 전송 서버에 오류가 발생하거나 프로덕션 데이터 센터를 사용할 수 없을 때 이 두 번째 허브 전송 서버에서 메일 흐름을 처리하도록 할 수 있습니다. 세 대의 허브 전송 서버를 배포하는 경우 세 서버 중 두 대의 서버는 프로덕션 데이터 센터에, 나머지 하나는 보조 데이터 센터에 배포할 수 있습니다.
이러한 배포 작업에서 가장 중요한 점은 중복성으로 인해 발생하는 여러 가지 오류 없이도 중복성을 통해 작업 중단을 방지할 수 있다는 것입니다. 중복 컴퓨터 및 서비스를 배포하는 방법에 따라, 발생하더라도 데이터나 서비스 가용성에 영향을 주지 않는 오류가 확인됩니다. 조직에서는 자체 요구 사항을 파악하여 운영 문제를 확인한 다음 해당 문제에 대해 가장 적합한 솔루션을 찾아야 합니다. 예를 들어, 특정 조직에서는 프로덕션 데이터 센터에 오류가 발생한 지 20분만에 백업 데이터 센터를 활성화하고자 할 수 있습니다. 이 경우 해당 조직에는 백업 데이터 센터 활성화 및 작업을 정기적으로 확인하는 데 필요한 프로세스가 준비되어 있어야 합니다. 또 다른 조직에서는 지속적인 백업 데이터 센터 유효성 검사가 작업을 제대로 수행하는 데 필수적일 수 있습니다. 이러한 조직의 경우에는 다른 배포 구성을 사용해야 합니다.