용량 계획에서의 다중 서버 역할 구성 이해
적용 대상: Exchange Server 2010 SP2, Exchange Server 2010 SP3
마지막으로 수정된 항목: 2016-11-28
서버 하드웨어의 여러 추세는 Microsoft Exchange Server 2010에 적용됩니다. 한 가지 추세는 프로세서 성능의 큰 향상 및 물리적 프로세서에서 지원되는 프로세서 코어 수의 증가입니다. 이는 멀티 코어 프로세서가 장착된 표준 서버에 하나의 Exchange 서버 역할을 배포하면 사용 가능한 CPU의 상당 부분을 사용하지 않은 상태로 남겨둔다는 의미입니다. 어떤 고객은 서버 가상화를 통해 서버 CPU 리소스를 더욱 효과적으로 활용하고자 하고, 또 어떤 고객은 같은 물리적 서버에 Exchange 서버 역할을 결합하기를 원합니다. 둘 다 유효한 솔루션입니다.
다른 추세는 멀티 코어 프로세서 및 10~16개의 내장 디스크를 가진 서버 모델의 가용성입니다. 10~16개의 디스크에서 제공하는 IOPS(초당 입출력 트랜잭션 수)가 지원할 수 있는 사서함 수를 고려하는 경우 일반적으로 사서함 서버 역할 자체는 사용 가능한 CPU 리소스의 절반 이상을 사용하지 않습니다. 클라이언트 액세스 서버 역할과 허브 전송 서버를 이 서버에 추가하면 보다 효과적으로 서버 용량을 활용할 수 있습니다.
이 항목의 정보를 여러 역할 서버 구성 배포가 적절한 경우 및 여러 역할 서버 구성의 올바른 계획 방법에 대한 참조 자료로 사용할 수 있습니다. 이해하기 쉬운 예를 통해 여러 역할 서버에 대한 서버 크기 조정 프로세스를 설명합니다.
목차
여러 역할 구성을 사용하면 좋은 이유
여러 역할 구성을 사용하면 좋은 경우
여러 역할 구성을 사용하지 않는 것이 좋은 경우
여러 역할 서버에 대한 하드웨어 권장 사항
DAG에 여러 역할 서버 배포
Exchange 2010 여러 역할 시나리오에 대한 크기 조정 예
여러 역할 구성을 사용하면 좋은 이유
첫째, 가장 중요한 사항이기도 하지만 Microsoft의 기준 프로세서 구성과 비교했을 때 현재 조달할 수 있는 하드웨어에는 5,000-6,000개의 메가사이클을 생성하는 매우 빠른 프로세서가 장착되어 있습니다. 해당 구성은 2 x 4 코어 Intel Xeon x5470 3.33GHz 프로세서로 구성됩니다. (사서함 서버 프로세서 용량 계획의 "사서함 서버 용량 계획의 예" 섹션에서 Microsoft의 기준 프로세서 구성에 대한 자세한 내용을 확인할 수 있습니다.) 사용자 환경의 프로세서 아키텍처를 현재 시중에 나와 있는 프로세서로 바꾸고 다른 모든 환경 요소는 동일하게 유지한다면 프로세서 사용률이 현저하게 감소하게 됩니다.
구입하는 서버의 총 소유 비용을 효과적으로 절감하려면 시스템의 효율적인 사용률을 보장해야 합니다. 즉, 시스템이 최대 부하에서 최악의 오류 모드 상태인 동안 거의 80%의 CPU 사용률을 달성하고 유지해야 합니다. 다음은 현재 사용 가능한 프로세서를 효율적으로 사용할 수 있는 4가지 방법입니다.
서버당 활성 사서함을 더 많이 배포하여 작업 부하를 증가시킵니다.
가상화 계층을 도입하고 추가 게스트 컴퓨터와 함께 사서함 역할을 게스트 컴퓨터로 배포합니다.
시스템에 추가 Exchange 서버 역할을 배포합니다.
앞의 방법론 조합을 사용하여 하드웨어를 가능한 한 효율적으로 사용하는 최적의 구성을 찾습니다.
여러 역할 아키텍처로 Exchange 2010을 배포하면 다음과 같은 여러 가지 이점이 제공됩니다.
여러 역할 아키텍처는 구성 요소 기반 아키텍처가 됩니다. 여러 역할 아키텍처에서 통합 메시징 및 Edge 전송을 제외한 Exchange 환경의 모든 서버는 정확히 동일합니다(동일한 하드웨어, 동일한 구성 등). 이 일률성은 서버의 유지 관리 및 관리의 수행뿐만 아니라 하드웨어 주문도 단순화합니다.
- 비용 관점에서 봤을 때 전반적인 목표는 아키텍처가 CPU 관점과 디스크 관점 모두에서 균형을 이루도록 하는 것입니다. 별도의 컴퓨터에 서버 역할을 배포하면 실제로 사용하는 것보다 많은 CPU, 디스크 및 메모리 리소스를 구입하게 될 수 있으므로 장기적인 비용 단점이 발생할 수 있습니다. 예를 들어 클라이언트 액세스 서버 역할만 호스트하는 서버를 고려해 봅니다. 많은 서버를 사용하면 매우 경제적인 방식으로 주어진 수의 디스크를 추가할 수 있습니다. 더욱 중요한 것은 해당 개수의 디스크를 배포하고 이러한 디스크를 사용하면 비용은 본질적으로 0이 됩니다. 그러나 주어진 수의 디스크보다 훨씬 적은 수의 디스크를 사용하는 서버 역할을 배포하면 미달 사용되거나 전혀 사용되지 않는 디스크 컨트롤러에 대한 비용을 지불하는 것이 됩니다.
대부분의 경우 여러 역할 아키텍처를 사용하면 해당 환경에 물리적 Exchange 서버를 보다 적게 지정할 수 있습니다. 물리적 서버 수가 적으면 다음과 같은 다양한 이유로 비용이 절감됨을 의미합니다.
운영 비용 지출은 거의 항상 자본 비용 지출보다 많습니다. 서버를 구입하는 데 드는 비용보다 수명 주기 동안 서버를 관리하는 데 드는 비용이 더 많습니다.
보다 적은 Exchange 서버 라이선스를 구입합니다. 여러 역할 서버에는 하나의 Exchange 서버 및 하나의 운영 체제에 대한 라이선스만 필요한 반면, 역할을 분할하면 여러 Exchange 서버 라이선스와 여러 운영 체제 라이선스도 필요합니다. 자세한 내용은 라이선스 정보: 가상 환경에 대한 라이선스를 참조하십시오.
보다 적은 수의 서버를 배포하면 나머지 인프라 전체에 트리클다운 효과가 있습니다. 예를 들어 보다 적은 수의 물리적 서버를 배포하면 Exchange 인프라에 필요한 전체 랙 및 바닥 공간을 줄일 수 있으므로 차례로 전원 및 냉각 비용이 절감됩니다.
궁극적으로 여러 역할 아키텍처는 단일 역할 서버를 여러 개 배포하는 것보다 많은 수의 서버에 부하를 분산합니다. 이는 모든 사서함 서버가 허브 전송 서버 및 클라이언트 액세스 서버로도 되기 때문입니다. 이 아키텍처는 다음과 같은 두 가지 이점을 제공합니다.
확장성 관점에서 봤을 때 보다 많은 수의 물리적 컴퓨터에 부하를 분산시킵니다. 오류 이벤트가 발생한 동안 나머지 서버에서 증가된 부하는 증분적으로만 증가되므로 해당 서버가 수행하고 있는 다른 기능에 부정적인 영향을 주지 않습니다.
복구 관점에서 봤을 때 솔루션은 보다 많은 수의 허브 전송 및 클라이언트 액세스 역할(또는 서비스) 오류가 발생한 상황에서도 유지되어 계속해서 서비스를 제공할 수 있습니다.
이러한 이유 때문에 대부분의 시나리오에서 Exchange 2010에 대해 권장되는 배포 전략은 여러 역할 서버 구성입니다.
여러 역할 구성을 사용하면 좋은 경우
다음과 같은 이유 때문에 대부분의 시나리오에서 여러 역할 구성을 사용하는 것이 좋습니다.
손쉬운 확장 사서함 수의 증가 추세를 예상하는 조직에서는 여러 역할 서버 배포를 고려해야 합니다. 각 여러 역할 서버는 하나의 구성 요소를 나타내므로 이 모델에서는 늘어나는 용량에 대한 요구를 지원하기 위해 구성 요소를 쉽게 추가할 수 있습니다.
최신 프로세서를 활용하려는 대규모 배포 Exchange 2010의 RTM(Release-To-Manufacturing) 버전 이전에 수행된 확장성 테스트를 기준으로 보면 여러 역할 서버가 단일 서버에서 헥스 코어 이상의 프로세서를 효과적으로 사용할 수 있습니다. 이러한 기능을 활용하면 큰 조직에서 사서함, 허브 전송 및 클라이언트 액세스 서버 역할을 프로세서 코어 수가 더 적은 여러 서버에 따로 배포하는 대신 모두 결합하여 서버의 수를 줄일 수 있습니다. 대규모 배포용 플랫폼을 제공하는 한편 전체적으로 필요한 서버의 수를 줄이기 위해 이 방법에는 앞서 설명한 구성 요소 모델이 사용됩니다. 코어 수가 더 많은 시스템에서의 여러 역할 구성 확장성은 프로덕션 배포 전에 실험 테스트를 통해 유효성을 검사해야 합니다.
내부 저장소가 있는 서버 배포 현재 2개의 물리적 멀티 코어 프로세서와 10~16개의 내장 디스크가 있는 서버가 많이 사용되고 있습니다 Exchange 2010에서는 입출력 요구 사항을 줄이기 위해 여러 가지 개선이 이루어져 이들 서버를 비용 효율적인 솔루션으로 만들어줍니다. 이러한 서버는 사용자 프로필 및 디스크 유형에 따라 대개 4,000개 이하의 사서함을 지원합니다. 클라이언트 액세스 및 허브 전송 서버 역할을 이들 서버에 추가하여 추가 CPU를 활용하고, 서버를 자체 포함된 구성 요소로 만드는 것이 좋습니다.
사서함 서버에서 호스트되는 사서함 수에 제한이 있는 위험 완화 시나리오 여러 역할 서버는 위험 관리 정책으로 인해 사서함 서버에 배포할 수 있는 사서함 수가 제한되는 배포에 대한 솔루션입니다. 예를 들어 10,000개의 사서함이 있는 조직에서 단일 서버 중지가 환경에 있는 사서함의 25% 이상에 영향을 줄 수 없게 하는 정책을 가지고 있다고 가정합니다. 이 요구 사항은 사서함 서버당 사서함 수를 2,500개로 제한합니다. 해당 서버의 추가 용량은 서버에 클라이언트 액세스 및 허브 전송 서버 역할을 추가하여 사용할 수 있습니다.
소규모 조직 및 지점 배포 Windows 네트워크 부하 분산이 사용될 때 아래에 기술된 경우를 제외한 상황에서 기본 목표가 관리할 물리적 서버, 운영 체제 인스턴스 및 Exchange 서버 수를 최소화하는 것이면 배포에 대해 여러 역할 배포 솔루션을 사용하는 것이 좋습니다. 동일한 서버에서 클라이언트 액세스, 허브 전송 및 사서함 서버 역할을 실행하면 필요한 역할 중복에 2~3개 물리적 서버의 최소 요구 사항을 제공합니다.
여러 역할 구성을 사용하면 좋은 이유
여러 역할 구성을 사용하지 않는 것이 좋은 경우
여러 역할 구성은 다음과 같은 시나리오에는 사용하지 않는 것이 좋습니다.
Windows NLB(네트워크 부하 분산)를 사용하려는 소규모 조직 또는 지점 배포 2-3개의 여러 역할 서버가 DAG(데이터베이스 가용성 그룹)의 구성원으로 배포되는 소규모 배포에서는 여러 역할 서버가 제대로 동작하지 않을 수 있습니다. DAG에 대한 자세한 내용은 데이터베이스 사용 가능 그룹 관리를 참조하십시오. DAG의 구성원인 사서함 서버에 추가되는 클러스터링 구성 요소는 NLB가 서버에 설치되지 못하게 합니다. 부하 분산 권장 사항에 대한 자세한 내용은 Exchange 2010의 부하 분산 이해를 참조하십시오. 그러나 여전히 인바운드 트래픽 부하를 클라이언트 액세스 서버로 분산하기 위한 요구 사항이 있습니다. 이 경우에는 두 가지 기본 옵션이 있습니다.
하드웨어 부하 분산 어플라이언스를 구입합니다. 일부 엔트리급 어플라이언스가 있기는 하지만 이 옵션은 특히 소규모 조직에는 경제적으로 부담이 될 수 있습니다.
Exchange 서버 역할을 가상화합니다. 일부 환경에서는 제한된 수의 서버로 인해 Exchange 2010 서버와 동일한 물리적 하드웨어에 도메인 컨트롤러, 파일 및 인쇄 서버와 기타 응용 프로그램을 배포해야 합니다. 이런 경우 물리적 서버를 호스트 서버로 구현하여 가상 환경 내부에 응용 프로그램을 격리하는 것이 좋습니다. 이러한 격리로 가상 컴퓨터에서 실행되는 클라이언트 액세스 서버에 NLB를 실행할 수 있습니다.
가상화 가상 컴퓨터에서 호스트할 수 있는 최대 활성 사서함 수는 여러 역할 구성에서 실행 중인 사서함과 메시지 프로필의 조합에 따라 줄어들 수 있습니다. 사용자들이 메시징을 많이 사용하지 않는 경우 가상 컴퓨터에서 서버 역할을 함께 지정하는 것이 합리적일 수 있습니다. 그러나 사용자들이 메시징을 많이 사용하는 경우 가상 컴퓨터의 리소스에 대해 제한사항이 적용될 수 있으므로 사서함 가상 컴퓨터당 사서함 수를 줄이거나 역할을 별도의 가상 컴퓨터로 분할해야 할 수 있습니다. 이러한 경우 각 가상 컴퓨터에 하나의 Exchange 서버 역할을 배포하거나 모든 사서함 서버 가상 컴퓨터에 대해 하나로 결합된 클라이언트 액세스 및 허브 전송 가상 컴퓨터를 배포하는 것이 보다 효율적일 수 있습니다.
참고
하이퍼바이저 호스트 서버에는 Exchange 서버 역할을 설치할 수 없습니다. 관리 소프트웨어(예: 바이러스 백신 소프트웨어, 백업 소프트웨어 또는 가상 컴퓨터 관리 소프트웨어 등)만 호스트 서버에 배포할 수 있으며, 호스트 서버(예: Exchange, Microsoft SQL Server 또는 Active Directory)에 다른 서버 기반 응용 프로그램을 설치해서는 안 됩니다. 호스트 서버는 게스트 가상 컴퓨터를 실행하는 데만 사용해야 합니다.
자세한 내용은 용량 계획에서의 클라이언트 액세스 및 허브 전송 결합 역할 구성 이해를 참조하십시오.
여러 역할 구성을 사용하면 좋은 이유
여러 역할 서버에 대한 하드웨어 권장 사항
일반적으로는 하나의 여러 역할 서버가 사서함 서버 역할에 사용 가능한 프로세서 코어의 절반을 사용하고, 나머지 절반은 클라이언트 액세스 및 허브 전송 서버 역할에 사용하도록 크기를 조정해야 합니다. Microsoft는 여러 역할 서버에 대해 최대 권장 프로세서 코어 수를 지정하지 않습니다. 대신, 채워진 최대 프로세서 소켓 수가 제공됩니다. 이는 멀티 코어 프로세서가 연결된 마더보드에 있는 프로세서 소켓 수를 지칭합니다. 자세한 내용은 프로세서 구성 및 Exchange 성능 이해를 참조하십시오.
프로세서 아키텍처의 크기 조정 외에 여러 역할 구성 배포를 위해 메모리의 크기도 올바르게 조정해야 합니다. 자세한 내용은 메모리 구성 및 Exchange 성능 이해를 참조하십시오.
DAG에 여러 역할 서버 배포
DAG에 단일 역할 사서함 서버를 배포하는 경우 사서함 서버 부하와 관련하여 단일 서버 오류 및 여러 서버 오류에 대한 용량 계획을 고려하십시오. DAG에 4개의 사서함 서버가 있으면 2개의 사서함 서버에 동시 오류가 발생할 경우 활성 사서함 사용자 수의 2배를 수용할 수 있도록 사서함 서버의 크기를 50%로 조정합니다. 허브 전송 서버와 클라이언트 액세스 서버가 다른 물리적 서버에 있으므로 해당 서버의 부하는 한두 사서함 서버의 오류에는 영향을 많이 받지 않습니다.
DAG에 여러 역할 서버를 배포할 경우 클라이언트 액세스, 허브 전송 및 사서함 서버 부하에 대한 용량 계획을 고려하십시오. DAG에 4개의 여러 역할 서버가 있으면 허브 전송 및 클라이언트 액세스 서버 부하의 두 배를 잠재적으로 수용할 수 있도록 충분한 용량을 확보합니다. 여러 역할 구성은 서버 역할에 권장되는 프로세서 코어 비율을 따르므로 사서함 서버 역할, 허브 전송 및 클라이언트 액세스 서버에 대한 최대 활성 데이터베이스의 크기를 올바르게 조정하면 이 시나리오의 성능 목표에 맞출 수 있습니다.
여러 역할 구성을 사용하면 좋은 이유
Exchange 2010 여러 역할 시나리오에 대한 크기 조정 예
다음 예에서는 여러 역할 서버에 대한 서버 크기 조정 프로세스를 설명합니다. 이 예는 다음 디자인 가정을 기반으로 합니다.
총 사서함 수 24,000
사서함 프로필 하루 동안 주고받은 메시지 100개(예: 받은 메시지 20개, 보낸 메시지 80개)
사서함당 데이터베이스 캐시 6MB(하루 100개 메시지 프로필 기준)
가용성 요구 사항 단일 사이트 내 사서함 복구, 3개의 데이터베이스 복사본 및 2개의 서버에 대한 동시 오류 발생 방지
데이터베이스 요구 사항 DAG에 데이터베이스 120개, 데이터베이스당 사서함 200개
서버 플랫폼 2 x 6 코어 2.26GHz 프로세서 기반(X5650) 서버(12 코어)
다음 프로세스가 적용됩니다.
서버 수 계산 2개의 서버에 대한 동시 오류 발생을 방지하려면 4노드 DAG가 필요합니다. 그러나 고객은 이중 서버 오류 이벤트가 발생하는 동안 최대 활성 사서함 수를 제어하기 위해 서버 6개를 배포하기로 결정했습니다. 따라서 설계는 DAG 내의 사서함 서버 6개로 시작됩니다.
활성화 모델을 기반으로 서버당 최대 활성 사서함 수 계산 활성 데이터베이스가 여러 노드에 균등하게 분산되어 있다고 가정하면 각 서버는 이상적으로 활성 사서함 4,000개(24,000 ÷ 6)를 호스트합니다. 이 예를 바탕으로 이중 노드 오류 발생 후 활성 사서함 수를 계산하기 위해 사서함 수를 나머지 4개 노드로 나누면 노드당 활성 사서함 수가 6,000개(24,000 ÷ 4)가 됩니다.
이 예에서 Set-MailboxServer cmdlet의 MaximumActiveDatabases 매개 변수는 단일 서버에서 데이터베이스의 40% 이상이 활성 상태가 되지 않도록 30으로 구성됩니다.
활성 사서함 CPU 요구 사항 계산 서버의 최대 활성 사서함 수에 사서함 데이터베이스 캐시 이해의 메시지 활동 및 사서함 데이터베이스 캐시 기반의 사서함당 예상 IOPS 테이블을 기반으로 활성 사서함당 메가사이클을 곱합니다(6,000 × 2메가사이클 = 12,000메가사이클). 각 추가 데이터베이스 복사본에 대해 이 값에 10%를 곱합니다.
이 예에서 모든 데이터베이스에는 하나의 활성 복사본과 3개의 수동 복사본이 있으므로 12,000메가사이클에 30%가 더해집니다(12,000 × 1.3 = 15,600메가사이클). 자세한 내용은 사서함 데이터베이스 캐시 이해의 "데이터베이스 캐시 메트릭"을 참조하십시오.
수동 사서함 CPU 요구 사항 계산 서버가 최대 활성 사서함 수를 호스트하는 경우 수동 사서함 수에 사서함 데이터베이스 캐시 이해의 메시지 활동 및 사서함 데이터베이스 캐시 기반의 사서함당 예상 IOPS 테이블을 기반으로 수동 사서함당 메가사이클을 곱합니다(10,000 × 0.3메가사이클 = 3,000메가사이클). 자세한 내용은 사서함 데이터베이스 캐시 이해의 "데이터베이스 캐시 메트릭"을 참조하십시오.
**총 CPU 요구 사항을 얻기 위해 활성 및 수동 CPU 요구 사항 더하기 **이 예에서 15,600 활성 사서함 메가사이클 + 3,000 수동 사서함 메가사이클 = 18,600메가사이클(총 CPU 요구 사항)
하드웨어 플랫폼에 사서함 CPU 요구 사항 적용 이 예에서는 2 x 6 코어 2.26GHz 프로세서 기반(x5650) 서버를 사용합니다. 사서함 서버 프로세서 용량 계획의 지침에 따라 이는 60,083메가사이클에 해당합니다. 필요한 메가사이클 수를 서버 플랫폼을 기반으로 사용 가능한 메가사이클 수로 나누면 이중 노드 오류 발생 후 최대 사용 시간의 CPU 사용률을 예상할 수 있습니다(예상 CPU 사용률: 18,600 ÷ 60,083 = 31%).
여러 역할 구성에서 사서함 서버 역할의 비율은 최대 사용 시간 동안 사용률의 40%를 넘지 않도록 설계하는 것이 좋습니다. 이 설계에서는 최대 사용 시간 동안 총 서버 CPU 사용률을 80% 이하로 유지하면서 클라이언트 액세스 및 허브 전송 서버 역할의 CPU 사용을 수용할 수 있는 충분한 공간이 확보됩니다.
활성 사서함 메모리 요구 사항 계산 활성 사서함 수에 사서함당 필요한 데이터베이스 캐시를 곱합니다. 이중 서버 오류가 있는 이 예에서 나머지 서버는 활성 사서함 6,000개를 호스트합니다(6,000 × 6MB ÷ 1,024 = 35.1GB). 데이터베이스 캐시 요구 사항은 사서함 프로필을 기반으로 합니다. 자세한 내용은 사서함 데이터베이스 캐시 이해의 "데이터베이스 캐시 메트릭"을 참조하십시오.
하드웨어 플랫폼에 총 메모리 요구 사항 적용 총 필요 메모리는 데이터베이스 캐시 요구 사항 및 서버 설계(전용 또는 여러 역할)에 따라 결정됩니다. 자세한 내용은 사서함 데이터베이스 캐시 이해의 기본 사서함 데이터베이스 캐시 크기 테이블을 참조하십시오. 이 예에서 여러 역할 서버에 대한 총 메모리 요구 사항은 52.2GB((4GB + 35.1GB) ÷ 0.75)입니다. 52.2 GB는 표준 메모리 구성이 아니므로 64 GB 또는 서버가 지원하는 가장 근접한 메모리 구성으로 올립니다.
여러 역할 구성을 사용하면 좋은 이유
© 2010 Microsoft Corporation. 모든 권리 보유.