다음을 통해 공유

용량 계획에서의 다중 서버 역할 구성 이해

  • 아티클

적용 대상: Exchange Server 2010

마지막으로 수정된 항목: 2010-01-27

서버 하드웨어의 여러 추세는 Microsoft Exchange Server 2010에 적용됩니다. 한 가지 추세는 프로세서 성능의 큰 향상 및 물리적 프로세서에서 지원되는 프로세서 코어 수의 증가입니다. 이는 물리적 프로세서가 둘인 표준 서버에 하나의 Exchange 역할을 배포하면 사용 가능한 CPU의 상당 부분을 사용하지 않은 상태로 남겨둔다는 의미입니다. 어떤 고객은 서버 가상화를 통해 서버 CPU 리소스를 더욱 효과적으로 활용하고자 하고, 또 어떤 고객은 같은 물리적 서버에 Exchange 서버 역할을 결합하기를 원합니다. 둘 다 유효한 솔루션입니다.

다른 추세는 2개의 물리적 프로세서 및 10~16개의 내장 디스크를 가진 서버 모델의 가용성입니다. 10~16개의 디스크에서 제공하는 입출력이 지원할 수 있는 사서함 수를 고려하는 경우 일반적으로 사서함 서버 역할 자체는 사용 가능한 CPU 리소스의 절반 이상을 사용하지 않습니다. 클라이언트 액세스 서버 역할과 허브 전송 서버를 이 서버에 추가하면 보다 효과적으로 서버 용량을 활용할 수 있습니다.

이 항목의 정보를 여러 역할 서버 구성 배포가 적절한 경우 및 여러 역할 서버 구성의 올바른 계획 방법에 대한 참조 자료로 사용할 수 있습니다. 이해하기 쉬운 예를 통해 여러 역할 서버에 대한 서버 크기 조정 프로세스를 설명합니다.

목차

여러 역할 구성을 사용하면 좋은 경우

여러 역할 구성을 사용하지 않는 것이 좋은 경우

여러 역할 서버에 대한 프로세서 권장 사항

권장되는 프로세서 코어 비율로 여러 역할 서버 구성 배열

여러 역할 서버에 대한 메모리 권장 사항

여러 역할 서버 하드웨어 요구 사항 결정

DAG에 여러 역할 서버 배포

Exchange 2010 여러 역할 시나리오에 대한 크기 조정 예

여러 역할 구성을 사용하면 좋은 경우

여러 역할 구성은 다음과 같은 경우에 좋습니다.

  • **지점 같은 소규모 조직에서의 서버 통합   **관리할 물리적 서버, 운영 체제 인스턴스 및 Exchange 서버의 수를 줄이는 것이 주 목적인 배포의 경우 여러 역할 배포가 권장되는 솔루션입니다. 동일한 서버에서 클라이언트 액세스, 허브 전송 및 사서함 서버 역할을 실행하면 필요한 역할 중복에 2~3개 물리적 서버의 최소 요구 사항을 제공합니다.
  • **손쉬운 확장 모델   **사서함 수의 증가 추세를 예상하는 조직에서는 여러 역할 서버 배포를 고려해야 합니다. 각 여러 역할 서버는 하나의 구성 요소를 나타내므로 이 모델에서는 늘어나는 용량에 대한 요구를 지원하기 위해 구성 요소를 쉽게 추가할 수 있습니다.
  • **내부 저장소가 있는 서버 배포   **오늘날에는 2개의 물리적 프로세서(8~12코어)와 10~16개의 내장 디스크가 있는 서버가 많이 사용되고 있습니다. Exchange 2010에서는 입출력 요구 사항을 줄이기 위해 여러 가지 개선이 이루어져 이들 서버를 비용 효율적인 솔루션으로 만들어줍니다. 서버는 사용자 프로필 및 디스크 유형에 따라 대개 4,000개 이하의 사서함을 지원합니다. 클라이언트 액세스 및 허브 전송 서버 역할을 이들 서버에 추가하여 추가 CPU를 활용하고, 서버를 자체 포함된 구성 요소로 만드는 것이 좋습니다.
  • **사서함 서버에서 호스트되는 사서함 수에 제한이 있는 위험 완화 시나리오   **여러 역할 서버는 위험 관리 정책으로 인해 사서함 서버에 배포할 수 있는 사서함 수가 제한되는 배포에 대한 솔루션입니다. 예를 들어, 10,000개의 사서함이 있는 조직에서 단일 서버 중지가 사서함의 25% 이상 영향을 줄 수 없게 하는 정책을 가지고 있는 경우 사서함 서버당 사서함 수가 2,500개로 제한됩니다. 해당 서버의 추가 용량은 서버에 클라이언트 액세스 및 허브 전송 서버 역할을 추가하여 활용할 수 있습니다.

맨 위로 이동

여러 역할 구성을 사용하지 않는 것이 좋은 경우

여러 역할 구성은 다음과 같은 경우에는 권장되지 않습니다.

  • **지점 같은 소규모 조직에서 Windows NLB(네트워크 부하 분산)와 함께 서버 통합   **2~3개의 여러 서버 역할이 DAG(데이터베이스 가용성 그룹)의 구성원으로 배포되는 소규모 배포에서는 여러 역할 서버가 제대로 동작하지 않습니다. DAG에 대한 자세한 내용은 데이터베이스 가용성 그룹 관리를 참조하십시오. DAG의 구성원인 사서함 서버에 추가되는 클러스터링 구성 요소는 NLB가 서버에 설치되지 못하게 합니다. 그러나 여전히 인바운드 트래픽 부하를 클라이언트 액세스 서버로 분산하기 위한 요구 사항이 있습니다. 이 경우에는 두 가지 기본 옵션이 있습니다.

    • 하드웨어 부하 분산 어플라이언스를 구입합니다. 일부 엔트리급 어플라이언스가 있기는 하지만 이 옵션은 특히 소규모 조직에는 경제적으로 부담이 될 수 있습니다.
    • Exchange 서버 역할을 가상화합니다. 이러한 격리로 가상 컴퓨터에서 실행되는 클라이언트 액세스 서버에 NLB를 실행할 수 있습니다.

  • **지점 같은 소규모 조직에서 다른 응용 프로그램과 함께 서버 통합   **일부 환경에서는 서버 수가 제한되어 있어 Exchange 2010 서버와 동일한 물리적 하드웨어에 도메인 컨트롤러, 파일 및 인쇄 서버, 기타 응용 프로그램을 배포해야 합니다. 이런 경우 물리적 서버를 호스트 서버로 구현하여 가상 환경 내부에 응용 프로그램을 격리하는 것이 좋습니다.

    참고

    관리 소프트웨어(예: 바이러스 백신 소프트웨어, 백업 소프트웨어 또는 가상 컴퓨터 관리 소프트웨어 등)만 호스트 서버에 배포할 수 있으며, 다른 서버 기반 응용 프로그램(예: Exchange, Microsoft SQL Server 또는 Active Directory 등)은 호스트 서버에 설치해서는 안 됩니다. 호스트 서버는 게스트 가상 컴퓨터를 실행하는 데만 사용해야 합니다.

  • **가상화   **4개의 가상 프로세서를 가진 가상 컴퓨터 내부에서 여러 역할 구성을 실행하지 않는 것이 좋습니다. 그러면 가상 컴퓨터에서 호스트할 수 있는 활성 사서함의 수가 현저히 제한됩니다. 대부분의 경우, 각 가상 컴퓨터에 단일 Exchange 서버를 배포하거나 각 사서함 서버 역할 가상 컴퓨터에 대해 하나로 결합된 클라이언트 액세스 및 허브 전송 역할 가상 컴퓨터를 배포하는 것이 더 효과적입니다.
    결합된 클라이언트 액세스 및 허브 전송 역할 구성에 대한 자세한 내용은 용량 계획에서의 클라이언트 액세스 및 허브 전송 결합 역할 구성 이해를 참조하십시오. 총 500개 미만의 사서함이 있는 배포에서는 관리할 운영 체제 및 Exchange 서버의 수를 줄이기 위해 가상 환경 내부에 여러 역할 구성을 실행하는 것이 가능합니다.

맨 위로 이동

여러 역할 서버에 대한 프로세서 권장 사항

일반적으로는 하나의 여러 역할 서버가 사서함 서버 역할에 사용 가능한 프로세서 코어의 절반을 사용하고, 남아 있는 절반은 클라이언트 액세스 및 허브 전송 서버 역할에 사용하도록 조정해야 합니다. 여러 역할 서버에 대해 권장되는 최대 프로세서 코어 구성은 24코어 프로세서로 나와 있습니다. 여러 역할 서버 구성이 24코어 프로세서 이상을 사용할 수는 있지만 권장하지 않습니다.

다음은 최소 요구 사항 및 권장되는 최대 구성에 대한 설명입니다.

  • 최소   여러 역할 서버에 적합한 최소 프로세서 및 메모리 구성입니다. Microsoft 고객 지원 서비스의 지원을 받으려면 최소 하드웨어 요구 사항은 충족해야 합니다.
  • 권장되는 최대 구성   여러 역할 서버에 권장되는 최대 프로세서 및 메모리 구성입니다. 권장되는 최대 구성은 가격 대비 성능을 기준으로 한 최고의 구성입니다.

다음 표는 여러 역할 서버에 대한 Exchange 2010의 최소 및 권장되는 최대 프로세서 코어를 나타냅니다.

Exchange 2010 여러 역할 서버에 대한 프로세서 구성

Exchange 2010 서버 역할 최소 구성 권장되는 최대 구성

여러 역할 서버(동일한 물리적 서버에서 실행되는 클라이언트 액세스, 허브 전송 및 사서함 서버 역할)

2 x 프로세서 코어

24 x 프로세서 코어

맨 위로 이동

권장되는 프로세서 코어 비율로 여러 역할 서버 구성 배열

다음 표에서는 사서함 서버 역할에 배포되는 프로세서 코어 수와 관련하여 클라이언트 액세스 및 허브 전송 서버 역할에 배포되는 권장 프로세서 코어 수를 보여줍니다. 표준 코어 비율은 현재 시스템에 사용할 수 있는 프로세서 코어 수와 잘 맞지 않습니다. 클라이언트 액세스, 허브 전송 및 사서함 서버가 많이 있는 대규모 조직이 아닌 경우의 배포는 표준 프로세서 코어 비율과 일치하지 않습니다.

여러 역할 서버 구성은 이 문제를 해결하고 보다 최적화된 하드웨어 활용을 이끌어냅니다. 예를 들어, 8코어 프로세서를 가진 서버의 경우 이들 코어는 세 가지 Exchange 2010 서버 역할에 가상적으로 할당될 수 있습니다. 사서함 서버 역할이 대략 4개의 코어를 사용하고, 클라이언트 액세스 서버 역할이 대략 3개, 허브 전송 서버 역할이 대략 1개의 코어를 사용하는 경우 사서함 서버 역할과 허브 전송 서버 역할의 코어 비율이 4:1이고 사서함 서버 역할과 클라이언트 액세스 서버 역할의 코어 비율이 4:3입니다. 이는 권장되는 프로세서 코어 비율 지침과 거의 맞습니다.

다음 표에서는 여러 역할 서버에 대한 프로세서 코어를 기반으로 권장되는 서버 역할 비율을 보여줍니다.

여러 역할 서버에 대한 프로세서 코어를 기반으로 권장되는 서버 역할 비율

서버 역할 비율 권장 프로세서 코어 비율

사서함:허브 전송

7:1 (허브 전송 서버에 실행 중인 바이러스 백신 응용 프로그램이 없음)

5:1 (허브 전송 서버에 실행 중인 바이러스 백신 응용 프로그램이 있음)

사서함:클라이언트 액세스

4:3

맨 위로 이동

여러 역할 서버에 대한 메모리 권장 사항

프로세서 코어의 수가 결정되면 기준 메모리 권장 사항을 적용할 수 있습니다. 다음 표에서는 Exchange 2010 여러 역할 서버 구성에 대한 최소 메모리 구성, 권장되는 메모리 구성을 보여줍니다.

Exchange 2010 여러 역할 서버에 대한 메모리 구성

Exchange 2010 서버 역할 최소 지원 권장 구성

여러 역할(허브 전송, 클라이언트 액세스 및 사서함 서버 역할 조합)

10GB

사서함당 10GB + 3~30MB(4코어 서버)

사서함당 14GB + 3~30MB(8코어 서버)

사서함당 18GB + 3~30MB(12코어 서버)

사서함당 22GB + 3~30MB(16코어 서버)

사서함당 30GB + 3~30MB(24코어 서버)

맨 위로 이동

여러 역할 서버 하드웨어 요구 사항 결정

여러 역할 서버에 대한 하드웨어 요구 사항을 결정하는 가장 쉬운 방법은 해당 하드웨어 구성이 지원할 활성 사서함의 수를 예상하는 것으로 시작하는 것입니다. 다음 표에서는 특정 사용자 프로필에 대한 프로세서 코어가 지원할 수 있는 사용자 수의 사전 예상 값의 예를 보여줍니다. 이는 예상 값이므로 서버 프로세서 모델에 대한 보다 정확한 사서함 수를 결정하려면 사서함 서버 프로세서 용량 계획에서 사용 가능한 메가사이클을 기반으로 사서함 수를 계산하는 방법을 읽어보는 것이 좋습니다. 사용자 수를 결정한 후에는 이 항목 앞부분에 나오는 "여러 역할 서버에 대한 메모리 권장 사항"을 참고하여 필요한 시스템 메모리를 결정할 수 있습니다.

다음 표에서는 여러 역할 구성에 대한 프로세서 코어당 권장되는 사용자 수를 보여줍니다.

여러 역할 구성에 대한 프로세서 코어당 권장되는 사용자 수

하루 동안 주고받는 메시지 수(75KB 메시지 크기) 여러 역할 구성에 대한 코어당 사용자 수(16코어로 검증)

50

500

100

450

150

400

200

350

250

300

300

250

350

200

400

150

450

100

500

50

맨 위로 이동

DAG에 여러 역할 서버 배포

DAG에 단일 사서함 서버를 배포하는 경우 사서함 서버 부하와 관련하여 단일 서버 오류 및 여러 서버 오류에 대한 용량 계획을 고려하십시오. DAG에 4개의 사서함 서버가 있으면 2개의 사서함 서버에 동시 오류가 발생할 경우 활성 사서함 사용자 수의 2배를 수용할 수 있도록 사서함 서버의 크기를 50%로 조정합니다. 허브 전송 서버와 클라이언트 액세스 서버가 다른 물리적 서버에 있으므로 해당 서버의 부하는 한두 사서함 서버의 오류에는 영향을 많이 받지 않습니다.

DAG에 여러 역할 서버를 배포할 경우에는 클라이언트 액세스, 허브 전송 및 사서함 서버 부하에 대한 용량 계획을 고려하십시오. DAG에 4개의 여러 역할 서버가 있으면 허브 전송 및 클라이언트 액세스 서버 부하의 두 배를 잠재적으로 수용할 수 있도록 충분한 용량을 확보합니다. 여러 역할 구성은 서버 역할에 대해 권장되는 프로세서 코어 비율을 따르므로 사서함 서버 역할, 허브 전송 및 클라이언트 액세스 서버에 대한 최대 활성 데이터베이스의 크기를 올바르게 조정하면 권장되는 시나리오에 맞출 수 있습니다.

맨 위로 이동

Exchange 2010 여러 역할 시나리오에 대한 크기 조정 예

다음 예에서는 여러 역할 서버에 대한 서버 크기 조정 프로세스를 설명합니다. 이 예는 다음 디자인 가정을 기반으로 합니다.

  • 사서함 수   12,000
  • 총 사서함 수   8,000
  • 사서함 프로필   하루 동안 주고받은 메시지 100개(예: 받은 메시지 20개, 보낸 메시지 80개)
  • 사서함당 데이터베이스 캐시   6MB(하루 100개 메시지 프로필 기준)
  • 가용성 요구 사항   단일 사이트 내 사서함 복구, 2개 서버 동시 오류에 대한 내결함성
  • 데이터베이스 요구 사항   DAG에 데이터베이스 40개, 데이터베이스당 사서함 200개
  • 서버 플랫폼 2x4 코어 3.33 GHz 프로세서 기반 서버(8코어)

다음 프로세스가 적용됩니다.

  1. 서버 수 계산   2개 서버의 동시 오류를 허용하려면 4개 노드 DAG가 필요하므로 DAG 내에 4개의 사서함 서버로 시작하는 디자인이 필요합니다.
  2. 활성화 모델을 기반으로 서버당 최대 활성 사서함 계산   활성 데이터베이스는 각 노드에 균등하게 배포되므로 이상적으로 각 서버는 2,000개(8,000÷4)의 활성 사서함을 호스트하게 됩니다. (이 예를 기반으로) 2개 노드 동시 오류가 발생한 후 활성 사서함 수를 계산하려면 총 사서함을 남아 있는 2개 노드로 나누어 노드당 활성 사서함 수가 4,000개(8,000÷2)가 됩니다.
    이 예에서 Set-MailboxServer cmdlet의 MaximumActiveDatabases 매개 변수는 단일 서버에서 데이터베이스의 50% 이상이 활성 상태가 되지 않도록 20으로 구성됩니다.
  3. 활성 사서함 CPU 요구 사항 계산   서버의 최대 활성 사서함 수에 사서함 데이터베이스 캐시 이해의 사용자 프로필과 메시지 작업을 기반으로 하는 사서함당 사서함 데이터베이스 캐시 및 예상 IOPS 테이블을 기반으로 활성 사서함당 메가사이클을 곱합니다(4,000x2메가사이클 = 8,000메가사이클). 각 추가 데이터베이스 복사본에 대해 이 값에 10%를 곱합니다.
    이 예에서 각 데이터베이스에는 하나의 활성 복사본과 두 개의 수동 복사본이 있으므로 8,000메가사이클에 20%가 더해집니다(8,000×1.2 = 9,600메가사이클). 자세한 내용은 사서함 데이터베이스 캐시 이해에서 "데이터베이스 캐시 권장 사항"을 참조하십시오.
  4. 수동 CPU 요구 사항 계산   사서함 데이터베이스 캐시 이해의 사용자 프로필과 메시지 작업에 기반한 사서함당 사서함 데이터베이스 캐시 및 예상 IOPS 테이블을 기반으로, (서버가 최대 개수의 활성 사서함을 호스트하는 경우) 수동 사서함 수에 수동 사서함당 메가사이클을 곱합니다(4,000x.3메가사이클 = 1,200메가사이클). 자세한 내용은 사서함 데이터베이스 캐시 이해에서 "데이터베이스 캐시 권장 사항"을 참조하십시오.
  5. **총 CPU 요구 사항을 얻기 위해 수동 CPU 요구 사항 더하기   **이 예에서 9,600 활성 사서함 메가사이클+1,200 수동 사서함 메가사이클 = 10,800메가사이클(총 CPU 요구 사항)
  6. **하드웨어 플랫폼에 총 CPU 요구 사항 적용   **이 예에서는 2x4 코어 3.3-GHz 프로세서 기반 서버를 사용합니다. 값은 26,400메가사이클(8×3,300MHz)입니다. 서버 플랫폼을 기반으로 필요한 메가사이클을 사용 가능한 메가사이클로 나누어 2개 노드 오류 후 최고 사용 시간의 CPU 사용률을 예상합니다(예상 CPU 사용률은 10,800÷26,640 = 41%).
    여러 역할 구성에서 사서함 서버 역할의 비율은 최대 사용 시간 동안의 사용률이 40%를 넘지 않도록 디자인하는 것이 좋습니다. 이렇게 하면 최대 사용 시간 동안 총 서버 CPU 사용률을 80% 이하로 유지하면서 클라이언트 액세스 및 허브 전송 서버의 CPU 사용을 수용할 수 있는 충분한 공간이 확보됩니다.
  7. 활성 사서함 메모리 요구 사항 계산   활성 사서함 수에 사서함당 필요한 데이터베이스 캐시를 곱합니다. 이 예에서는 (4,000×6MB)÷1,024 = 23.4GB입니다. 데이터베이스 캐시 요구 사항은 사서함 프로필을 기반으로 합니다. 자세한 내용은 사서함 데이터베이스 캐시 이해에서 "데이터베이스 캐시 권장 사항"을 참조하십시오.
  8. 하드웨어 플랫폼에 총 메모리 요구 사항 적용   이 예에서는 8코어 프로세서가 있는 서버를 사용합니다. 위 표에 나온 것과 같이, 8코어 프로세서를 가진 여러 역할 서버에 대한 표준 메모리 지침은 14GB+활성 사서함의 총 데이터베이스 캐시입니다.
    이 예에서 여러 역할 서버에 대한 총 메모리 요구 사항은 37.4GB(14GB+23.4GB)입니다. 37GB는 표준 메모리 구성이 아니므로 48GB 또는 서버가 지원하는 가장 근접한 메모리 구성으로 올립니다. 일반 작업 시에는 메모리 요구 사항이 25.7GB(14GB+23.4GB÷2GB)지만 2개 노드의 동시 오류를 지원하려면 미리 충분한 메모리를 확보해야 한다는 점에 유의하십시오.

맨 위로 이동