» 윈도우 서버+가상화 » Exchange Server: Mailbox Server Storage Design

Exchange Server: Mailbox Server Storage Design

TechNet에서 Exchange Server 2013의 Mailbox Server(사서함 서버) 저장소 디자인 문서를 찾을 수 없었다. 그래서 아쉽지만 Exchange Server 2010의 사서함 서버 저장소 디자인에 대한 글을 찾아보게 되었다. Exchange Server 2013의 사서함 서버 자체에 대한 정보는 그래도 조금 찾을 수 있었는데, 지난 번 글에서 이를 정리해두었다. 이번에도 TechNet에서 모아 놓은 정보를 조금씩 잘라 붙여 기록해 보았다.

다음 포스트에서는 메일박스 서버의 고가용성 부분을 모아 볼 예정이다.

 

사서함 서버 저장소 디자인

Exchange 2010

적용 대상: Exchange Server 2010 SP3, Exchange Server 2010 SP2

마지막으로 수정된 항목: 2011-02-08

저장소 디자인은 성공적인 Microsoft Exchange Server 2010 사서함 서버 역할 배포에 결정적인 부분입니다. 최적의 Exchange 2010 저장소 디자인을 완성하려면 저장소 성능, 용량, 관리 효율성 및 비용 등 여러 요구 사항을 고려해야 합니다. 이 섹션에서는 Exchange 2010 사서함 서버 역할과 관련된 저장소 디자인 프로세스뿐 아니라 저장소 디자인 옵션, 지원 조건, 모범 사례 등을 소개합니다. 필요한 저장소 입력 및 저장소 테스트와 유효성 검사에 대한 정보도 함께 제공됩니다.

출처: <http://technet.microsoft.com/ko-kr/library/dd346703(v=exchg.141).aspx>

 

사서함 저장소 디자인 프로세스

Exchange 2010

적용 대상: Exchange Server 2010 SP3, Exchange Server 2010 SP2

마지막으로 수정된 항목: 2012-07-23

저장소 디자인 프로세스는 세 단계로 나누는 것이 좋습니다. 다음 섹션에서는 사서함 저장소 요구 사항 및 모범 사례를 비롯한 각 디자인 단계에 대한 자세한 내용을 설명합니다.

1단계: 저장소 입력 요구 사항 수집

몇몇 Exchange 2010 아키텍처 요소는 사서함 저장소 디자인에 영향을 줍니다. 다음 표에서는 사서함 저장소 디자인에 영향을 주는 가장 중요한 요소를 설명합니다.

사서함 저장소 디자인의 아키텍처 요소

디자인 요소

설명

저장소 디자인 영향

사서함 수

특정 사서함 서버에서 호스트되는 최대 사서함 수

성능   사서함 수가 많을수록 서버당 배달되고 열리는 메시지 수도 많아집니다. 이로 인해 더 많은 로그와 데이터베이스 입출력이 발생합니다.

용량   사서함 수가 많을수록 사서함 콘텐츠를 저장하기 위한 용량도 더 많이 필요합니다. 이는 데이터베이스 및 서버당 데이터베이스 크기에 영향을 줍니다. 또한 사서함 수가 많아지면 하루 동안 서버당 생성되는 로그의 수도 많아집니다.

안정성   일반적으로 사서함 서버에서 호스트되는 사서함 수가 많을수록 고가용성에 대한 필요성이 커집니다.

사서함 동시성

한 시간 이상의 간격으로 측정되는, 사서함 서버에 동시에 연결하는 사용자 비율

성능   동시성이 높을수록 서버당 배달되고 열리는 메시지 수도 많아집니다. 이로 인해 더 많은 로그와 데이터베이스 입출력이 발생합니다. 일반적으로 표준 정보 처리 저장소 크기로 100% 동시성이 사용됩니다.

용량   동시성이 높아질수록 하루 동안 서버당 생성되는 로그의 수가 많아집니다.

사서함 크기

사서함당 최대 사서함 할당량, 예를 들면 최대 사서함 크기는 10GB입니다. 여기에는 기본 사서함, 개인 보관, 복구 가능한 항목(휴지통) 데이터에 필요한 용량이 포함됩니다.

성능   기본 사서함 크기가 커질수록 가끔 수행되는 데이터베이스 작업(예: 전체 Microsoft Outlook 오프라인 폴더 파일(.ost) 동기화 및 Microsoft Office Outlook Web App에서의 새로운 보기 생성)을 위해 처리할 콘텐츠가 많아집니다. 이로 인해 조금 더 많은 로그와 데이터베이스 입출력이 발생할 수 있습니다.

용량   사서함이 커질수록 사서함 콘텐츠를 저장하기 위한 용량도 더 많이 필요합니다. 이는 데이터베이스 및 서버당 데이터베이스 크기에 영향을 줍니다.

사서함 사용 프로필

일반적으로 하루 동안 주고받는 메시지 수와 평균 메시지 크기(KB)로 정의되는 사서함 서버의 사용자 사용 특성

성능   사서함 사용 프로필이 집약적일수록 생성되는 로그와 데이터베이스 입출력이 늘어납니다.

용량   사서함 사용 프로필이 집약적일수록 하루 동안 서버당 생성되는 로그의 수가 많아집니다.

전자 메일 클라이언트 유형

서로 다른 전자 메일 클라이언트(예: Outlook 2003 캐시된 Exchange 모드, Windows Mobile, Microsoft Exchange ActiveSync 및 Microsoft Office Outlook Web App)의 유형 및 비율

성능   서로 다른 클라이언트는 서버에서 서로 다른 성능 특성을 나타냅니다.

전자 메일 클라이언트 확장명

전자 메일 클라이언트의 기능을 확장하는 Microsoft 및 타사 응용 프로그램(예: Office Communicator 및 Windows Desktop Search 클라이언트)

성능   구현에 따라, 전자 메일 클라이언트 확장 응용 프로그램은 사서함 서버 데이터베이스 입출력에 다양한 입출력 영향을 줄 수 있습니다.

서버 응용 프로그램

Exchange 사서함 서버에서 또는 사서함 서버에 대해 실행되는 응용 프로그램(예: 타사 모바일 장치 응용 프로그램 및 바이러스 백신 응용 프로그램)

성능   구현에 따라, 서버 응용 프로그램은 사서함 서버 데이터베이스 입출력에 다양한 입출력 영향을 줄 수 있습니다.

고가용성 요구 사항

Exchange 2010 고가용성의 사용 여부 및 구성 방식(예: 복사본 수, 사이트 수, 지연된 복사본)

성능   고가용성 솔루션은 로그 복제에 의해 발생하는 추가 로그 볼륨 입출력을 처리하기 위해 비고가용성 솔루션에 비해 조금 더 많은 입출력이 필요할 수 있습니다.

용량   고가용성을 사용하면 (복사본 수에 따라) 필요한 데이터베이스 파일 저장소의 크기를 증가시킵니다. 순환 로깅을 사용하면 로그 용량이 감소될 수 있습니다. 고가용성을 사용하면 하루 동안 서버당 생성되는 로그의 수가 많아집니다.

안정성   고가용성을 배포하면 실행 가능한 저장소 옵션의 수가 늘어납니다. RAID가 구현되지 않은 저장소나 JBOD(Just a Bunch Of Disks) 같이 안정성이 떨어지는 스토리지는 고가용성 배포에서 여러 데이터베이스 복사본이 사용될 때 사용할 수 있습니다.

 

2단계: 입출력 및 용량 요구 사항을 기반으로 저장소 아키텍처 디자인

수동으로 사서함 서버 역할 요구 사항 계산

사서함 서버 역할 요구 사항 계산기 사용

 

3단계: 저장소 성능 및 안정성 확인

프로덕션 환경에서 저장소 솔루션을 구현하기 전에 해당 솔루션이 올바르게 구성되었는지를 확인해야 합니다. 이 섹션에서는 Microsoft Exchange용 저장소 솔루션 테스트에 대한 지침을 제공합니다. 이 과정은 이미 테스트한 솔루션을 포함하는 프로그램으로 시작됩니다.

또한 저장소 솔루션을 관리, 테스트 및 모니터링하는 데 도움이 되는 몇 가지 도구에 대한 정보도 제공합니다. 입출력 성능의 이해 및 문제 해결에 대한 자세한 내용은 데이터베이스와 로그 성능 요소 이해를 참조하십시오.

  • Exchange Solution Reviewed Program
  • 저장소 테스트
  • 저장소 관련 도구

 

서버 저장소 상태 모니터링

저장소 솔루션 모니터링 작업은 하드웨어 및 소프트웨어 경고와 오류 상태로 인해 데이터가 손상되거나 가동이 중지되기 전에 이러한 상태를 확인하는 매우 중요한 작업입니다.

다음과 같은 도구를 사용하여 저장소 솔루션을 모니터링할 수 있습니다. 이러한 도구는 Exchange 관리 콘솔의 도구 상자 노드에서 사용 가능합니다.

  • 모범 사례 분석 도구
  • 성능 모니터
  • 성능 문제 해결사

또한 Microsoft System Center Operations Manager 2007을 사용하여 저장소 솔루션과 Exchange 조직의 다양한 측면을 모니터링할 수도 있습니다.

성능 모니터(perfmon.exe)는 Exchange 2010의 MMC(Microsoft 관리 콘솔) 성능 스냅인입니다. Perfmon은 MSExchangeIS 성능 개체를 사용하여 카운터 정보를 검색하며 저장소 솔루션의 상태를 알아볼 수 있는 정보를 제공합니다. 자세한 내용은 성능 및 확장성 카운터 및 임계값를 참조하십시오.

 

저장소 솔루션 상태 모니터링

대다수의 저장소 솔루션의 경우 성능 메트릭을 확인할 수 있는 방법이 있습니다. 이러한 매트릭을 모니터링하면 Exchange에 영향을 주기 전에 성능 문제를 확인할 수 있습니다. 저장소 공급업체에서 제공하는 통합된 System Center Operations Manager 2007을 사용할 수 있으면 전용 메트릭을 쉽게 이해할 수 있습니다. 확인해야 하는 몇 가지 일반 메트릭은 다음과 같습니다.

  • 디스크 사용률   실제 디스크의 사용률
  • 읽음 캐시 적중률   저장소 컨트롤러 캐시의 활용도
  • 쓰기 대기 중인 요청   컨트롤러의 실제 디스크 대기 빈도
  • 저장소 프로세서 사용률   저장소 컨트롤러 프로세서의 사용률

출처: <http://technet.microsoft.com/ko-kr/library/ff367907>

(출처 링크를 통해 자세한 사항 살펴보기)

 

고가용성 요소 이해

Exchange 2010

적용 대상: Exchange Server 2010 SP3, Exchange Server 2010 SP2

마지막으로 수정된 항목: 2011-02-02

고가용성 사서함 서버 및 데이터베이스 아키텍처 계획 시 다음과 같은 디자인 결정 사항을 고려해야 합니다.

  • 여러 데이터베이스 복사본을 배포할 것인지 여부
  • 배포할 데이터베이스 복사본의 개수
  • 사이트 복구를 제공하는 아키텍처를 보유할 것인지 여부
  • 배포할 사서함 서버 복구 모델의 유형
  • 배포할 사서함 서버의 개수
  • 데이터베이스 복사본을 배포하는 방법
  • 사용할 백업 모델
  • 사용할 저장소 아키텍처

Microsoft Exchange Server 2010에서는 사서함 복구를 위해 구성된 사서함 서버 또는 독립 실행형 사서함 서버를 사용하여 사서함 서버 인프라를 배포할 수 있습니다. 사서함 복구를 위해 구성된 사서함 서버는 DAG 전체에 효율적으로 배포된 여러 데이터베이스 복사본이 포함된 DAG(데이터베이스 가용성 그룹)를 적용합니다. 여러 데이터베이스 복사본을 배포하는 경우는 다음과 같은 장점이 있습니다.

  • 백업 사용에 대한 일반적인 문제를 완화해 주는 솔루션을 디자인할 수 있습니다. 데이터베이스 복사본이 하드웨어, 소프트웨어 및 데이터 센터 오류로부터 보호합니다.
  • 백업에서 복원하는 대신 다른 데이터베이스 복사본을 이용한 복구 메커니즘을 사용하여 데이터베이스 크기가 2테라바이트까지 증가합니다.
  • 데이터베이스 복사본을 세 개 이상 배포하는 경우 JBOD(Just a Bunch Of Disk) 등의 일반 RAID 구성에 대한 대체 저장소 아키텍처를 고려할 수 있습니다. JBOD와 저렴한 디스크를 조합하여 사용하면 조직에서 비용을 절감할 수 있습니다.

DAG에 참가하는 모든 서버에 활성 데이터베이스를 배포하면 하드웨어 효율을 극대화할 수 있습니다.

자세한 내용은 고가용성 및 사이트 복구 계획백업, 복원 및 재해 복구 이해를 참조하십시오.

출처: <http://technet.microsoft.com/ko-kr/library/ee832790(v=exchg.141).aspx>

(출처 링크를 통해 자세한 사항 살펴보기)

 

사서함 데이터베이스 및 로그 용량 요소 이해

Exchange 2010

적용 대상: Exchange Server 2010 SP3, Exchange Server 2010 SP2

마지막으로 수정된 항목: 2012-02-24

이 항목에서는 Microsoft Exchange Server 2010의 사서함 서버 저장소 디자인의 일부로 사서함 데이터베이스 및 로그 용량을 계획할 때 고려해야 하는 요소를 설명합니다.

사서함 데이터베이스 용량

Exchange Server 2010 사서함 데이터베이스의 용량 계획에 영향을 미치는 요소는 많습니다. 이 섹션에서는 다음 내용에 대해 설명합니다.

출처: <http://technet.microsoft.com/ko-kr/library/ee832796(v=exchg.141).aspx>

 

사서함 데이터베이스 캐시 이해

Exchange 2010

적용 대상: Exchange Server 2010 SP3, Exchange Server 2010 SP2

마지막으로 수정된 항목: 2012-04-23

ESE(Extensible Storage Engine) 엔진은 데이터베이스 캐시를 사용하여 I/O 작업을 줄입니다. 일반적으로 사용 가능한 데이터베이스 캐시가 많을 수록 Microsoft Exchange Server 2010 사서함 서버에서 생성되는 I/O가 적습니다. 데이터베이스 I/O 감소는 주로 서버에서 사용할 수 있는 데이터베이스 캐시의 양과 사용자 메시지 프로필에 따라 달라집니다.

출처: <http://technet.microsoft.com/ko-kr/library/ee832793(v=exchg.141).aspx>

 

데이터베이스와 로그 성능 요소 이해

Exchange 2010

적용 대상: Exchange Server 2010 SP3, Exchange Server 2010 SP2

마지막으로 수정된 항목: 2013-04-17

이 항목에서는 Microsoft Exchange Server 2010의 데이터베이스 및 로그 I/O 성능 요소에 대해 설명합니다. 이러한 요소를 이해하는 것은 사서함 서버 저장소 디자인 솔루션에 중요합니다. 디자인 프로세스의 다른 주요 요소에 대한 자세한 내용은 사서함 서버 저장소 디자인을 참조하십시오.

목차

 

출처: <http://technet.microsoft.com/ko-kr/library/ee832791(v=exchg.141).aspx>

 

Exchange 2013 저장소 구성 옵션

적용 대상: Exchange Server 2013, Exchange Server, Exchange Online

마지막으로 수정된 항목: 2014-07-10

Microsoft Exchange Server 2013의 사서함 서버 역할에 대한 저장 옵션 및 요구 사항을 이해하는 것은 사서함 서버 저장소 설계 솔루션에 있어서 중요합니다.

목차

출처: <http://technet.microsoft.com/ko-kr/library/ee832792>

(오! 이 부분은 2013 버전에 맞게 제공된다. 20341A MOC 교재에서도 이 문서를 읽어라고 되어 있다.)

 

Exchange 2010 LUN 아키텍처 이해

Exchange 2010

적용 대상: Exchange Server 2010 SP3, Exchange Server 2010 SP2

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

대부분의 경우 운영 체제에서 인식하는 실제 디스크 또는 최적의 LUN(논리 단위 번호)은 운영 체제에 디스크를 제공하는 데 사용되는 하드웨어에서 요약됩니다. LUN 아키텍처는 Microsoft Exchange Server 2010에서 사용됩니다.

Exchange 2010에서는 다양한 방식으로 LUN을 디자인할 수 있지만 LUN이 복잡해지지 않도록 다음과 같은 디자인 방식을 사용하는 것이 좋습니다.

출처: <http://technet.microsoft.com/ko-kr/library/ee832794(v=exchg.141).aspx>

 

사서함 서버 프로세서 용량 계획

Exchange 2010

적용 대상: Exchange Server 2010 SP3, Exchange Server 2010 SP2

마지막으로 수정된 항목: 2011-10-19

사서함 서버 용량 계획은 Microsoft Exchange Server 2010에 제공되는 사서함 복구 기능으로 인해 이전 버전의 Exchange와 비교해서 크게 달라졌습니다. Exchange 2010은 사서함 복구 개념으로 다시 엔지니어링되어, 이제 서버 수준이 아닌 개별 사서함 데이터베이스 수준에서 자동 장애 조치(failover) 보호를 제공하도록 아키텍처가 변경되었습니다. 사서함 서버 역할 용량 계획 프로세스에 영향을 주는 주요 변경 사항은 두 가지입니다.

  • 동일한 서버의 활성 및 수동 데이터베이스 복사본 호스트
  • 데이터베이스 복사본 수 제공

이 항목의 정보는 이러한 변경 사항을 보다 잘 이해하기 위해, 그리고 사서함 복구를 위해 구성할 때 사서함 서버의 크기 조정을 위한 디자인 참고 자료로 사용할 수 있습니다.

목차

 

출처: <http://technet.microsoft.com/ko-kr/library/ee712771(v=exchg.141).aspx>

 

mailboxExchange 2010 사서함 서버 역할 디자인 예

Exchange 2010

적용 대상: Exchange Server 2010 SP3, Exchange Server 2010 SP2

마지막으로 수정된 항목: 2011-09-01

이 항목에서는 사서함 서버 역할과 관련 아키텍처에 적절한 메모리, 용량, I/O 및 CPU 성능 요구 사항을 결정하는 방법의 예를 보여줍니다.

입력 요소 집합을 지정하여 Exchange Server 2010 사서함 서버 역할 요구 사항 계산기를 사용하면 사서함 서버 역할에 적절한 요구 사항을 결정할 수 있습니다. 계산기로 이 예에서 설명한 요구 사항을 결정할 수 있습니다. 계산기에 대한 자세한 내용과 다운로드 방법은 Exchange Server 팀 블로그 문서 Exchange 2010 사서함 서버 역할 요구 사항 계산기(영문)를 참조하십시오.

참고:

각 블로그의 콘텐츠와 해당 URL은 사전 통지 없이 변경될 수 있습니다. 각 블로그의 콘텐츠는 어떠한 보증 없이 “있는 그대로” 제공되며 어떠한 권한도 제공하지 않습니다. 포함된 스크립트 샘플 또는 코드는 Microsoft 서비스 계약에 명시된 조건의 적용을 받습니다.

사서함 서버 역할 저장소 디자인에 대한 자세한 내용은 사서함 서버 저장소 디자인을 참조하십시오.

이 예에서 사용된 시나리오는 JBOD(여러 디스크 모음) 저장소를 사용하는 세 개의 데이터베이스 복사본 솔루션입니다. 이 예에서는 다음 아키텍처 요구 사항을 고려합니다.

  • 단일 DAG(데이터베이스 가용성 그룹)에 참가하는 6개의 사서함 서버
  • Exchange 사서함 서버는 허브 전송 및 클라이언트 액세스 서버 역할도 호스팅함
  • 세 개의 고가용성 사서함 데이터베이스 복사본, 지연된 데이터베이스 복사본 없음
  • 7.2K(7,200RPM) 1TB SATA 스핀들 사용
  • JBOD 저장소 구성(1 LUN(논리 단위 번호)/데이터베이스 LUN 아키텍처)
  • 백업 아키텍처의 경우 단일 항목 복구 및 사서함 복구를 통해 제공되는 고유 데이터 보호 기능 사용
  • 유지 관리 및 복구 작업을 위한 복원 LUN이 배포됨
  • 각 LUN에 여유 공간 최소 20%
  • 솔루션이 이중 서버 오류 이벤트를 견딜 수 있음
  • 유일하게 설치된 서버 역할은 사서함 서버 역할

목차

출처: <http://technet.microsoft.com/ko-kr/library/ee832789>

(위 글이 아주 중요한 내용이라고 보임. 위에서 제시한 예에 알맞은 사서함 크기, DAG, RAM, I/O, CPU에 대한 정보를 알려준다. 다른 것은 읽지 않더라도 이 글은 찬찬히 살펴봐야겠다.)

이것도 살펴보세요!

Azure Cloud Shell(Linux Bash)

에헹? Azure Portal에서 Linux Bash가? 콘솔 버튼이 생겼다! 아마 Bash or PowerShell로 적용 가능할 것 …

답글 남기기

이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다.