Exchange Server 2003 성능 튜닝

마지막으로 수정된 항목: 2006-08-16

이 장에서는 Microsoft® Exchange Server 2003의 성능을 조정하고 향상시키는 방법에 대해 설명합니다. 이 장에는 여러 가지 튜닝 팁과 권장 사항이 들어 있으며 이 중 일부는 사용자의 현재 배포에 적용되지 않을 수도 있습니다. 이 장을 검토하여 어떤 설정이 자신의 환경에 적용되는지 결정하십시오.

Exchange 2000 Server 고객의 경우 이 장의 일부 권장 사항이 이전 성능 가이드의 권장 사항과 동일합니다. 또한 이전의 일부 변경 사항은 더 이상 필요하지 않습니다. 제거할 수 있는 설정에 대한 자세한 내용은 더 이상 사용되지 않는 설정을 참조하십시오.

성능 향상

Exchange Server 2003에는 연결 상태 소통량 및 가상 주소 공간 관리와 같이 새로 향상된 여러 가지 튜닝 기능이 들어 있습니다. 이러한 성능 개선 사항에 대한 자세한 내용은 Exchange Server 2003의 새로운 기능을 참조하십시오.

디스크 하위 시스템

다음 섹션에서는 다양한 종류의 Exchange 2003 서버에 권장되는 저장소 구성을 제공합니다. 이 섹션에서는 Exchange 2000 고객을 위해 이전 Exchange 2000 Server 성능 설명서와 동일한 권장 사항을 제공합니다.

SMTP 브리지헤드 서버

서버가 SMTP(Simple Mail Transfer Protocol) 브리지헤드 서버인 경우 일반적으로 하나의 파티션을 만들면 최상의 디스크 레이아웃을 얻을 수 있습니다. SMTP 인터페이스에 도착하는 메시지는 Mailroot 디렉터리에 기록된 후 다음 컴퓨터로 전달됩니다. Mailroot 디렉터리는 NTFS 파일 시스템으로 포맷된 시스템상에 있어야 합니다. 최적의 성능을 얻으려면 최대한 많은 수의 디스크로 Mailroot 디렉터리를 확장하십시오. SMTP 브리지헤드 서버에 둘 이상의 파티션이 있는 경우 SMTP Mailroot 디렉터리 위치를 가장 빠른 파티션으로 변경합니다. Mailroot 디렉터리를 이동하는 방법에 대한 자세한 내용은 Exchange Server 2003에서 Mailroot 디렉터리 이동 방법을 참조하십시오.

단일 스핀들은 초당 약 30개의 크기가 작은 메시지를 전송할 수 있어야 합니다. 따라서 스핀들 수가 늘어나면 성능도 향상됩니다.

사용자의 하드웨어 RAID(Redundant Array of Independent Disks) 구성은 다음 표와 같이 대개 사용 가능한 디스크 스핀들 수에 의해 결정됩니다.

RAID 권장 사항

미러링된 배터리 기반 쓰기 Write-back 캐시가 하드웨어 RAID 컨트롤러에 있고 이 캐시를 사용하여 읽기/쓰기 캐시 비율을 튜닝할 수 있는 경우 서버에서는 메시지가 디스크에 기록된 후에 메시지를 받았다는 사실만을 인식하므로 이 비율을 100% 쓰기로 설정합니다. 따라서 서버의 디스크 쓰기 속도가 빠를수록 이 서버가 다른 컴퓨터에 더 빠르게 응답합니다. 메시지 내용을 다음 컴퓨터로 릴레이하기 전 다시 읽어야 하는 경우에도 SMTP 서비스의 파일 핸들이 데이터에 개방되어 있으므로 NTFS 캐시에서 메시지 내용을 가져올 수 있습니다.

X.400 브리지헤드 서버 또는 기타 커넥터 서버

Exchange 2003 서버가 많은 수의 X.400 커넥터를 포함하거나 다른 메시징 시스템(예: Lotus cc:Mail, Lotus Notes, Novell GroupWise 또는 Microsoft Mail)에 연결되는 경우 스핀들이 충분하다면 트랜잭션 로그에 대해 별도의 디스크 파티션을 만듭니다. 이와 같은 Exchange 커넥터를 사용하는 메시지는 Store.exe 프로세스를 통해 데이터를 이동하며 서버 로드가 과도한 경우 데이터베이스에서 트랜잭션 로그를 분할함으로써 성능을 한층 향상시킬 수 있습니다.

메시지 전송 에이전트(MTA)가 메시지를 수신하면 해당 데이터가 NTFS 파티션상의 Mtadata 디렉터리에 기록되고 MTS-IN 가상 큐를 통해 Store.exe 프로세스로 전달됩니다. 메시지가 Store.exe로 전달되기 때문에 데이터가 트랜잭션 로그 파일에 기록됩니다. 그런 다음 메시지가 분류 및 라우팅 프로세스를 통해 전달됩니다. X.400 커넥터를 통해 메시지를 전달하도록 라우팅이 결정된 경우 데이터는 MTS-OUT 가상 큐로 이동합니다. 다른 메시징 커넥터도 이와 비슷한 프로세스를 사용합니다.

사용 가능한 디스크 스핀들 수는 사용자의 하드웨어 RAID 구성에 영향을 줍니다(다음 표 참조).

RAID 권장 사항

디스크가 6개인 구성에서는 페이지 파일에 RAID 파티션을 사용하지 않지만 높은 서버 가용성이 요구되는 경우 페이지 파일을 보호된 파티션에 배치합니다.

미러링된 배터리 기반 Write-back 캐시가 하드웨어 RAID 컨트롤러에 있고 이 캐시를 사용하여 읽기/쓰기 캐시 비율을 튜닝할 수 있는 경우 단일 파티션을 사용하는 구성에 대해 이 비율을 100% 쓰기로 설정하고 5개 이상의 디스크를 사용할 때 트랜잭션 로그 파티션에서 이 비율을 100% 쓰기로 설정합니다. 데이터베이스 드라이브의 읽기 캐시를 사용할 때에 비해 트랜잭션 로그의 쓰기 캐시를 사용할 때 높은 성능을 얻을 수 있습니다.

사서함 및 공용 폴더 서버

단일 데이터베이스 서버를 구성하는 경우 디스크 디자인은 Exchange Server 5.5 및 Exchange 2000 Server의 디자인과 비슷합니다. 가장 먼저 트랜잭션 로그와 데이터베이스를 별도의 디스크 스핀들로 분할해야 합니다. 이 경우 트랜잭션 로그가 다른 스핀들 집합에 위치해야 하며 이 스핀들 집합을 로그 전용으로 사용해야 합니다. 예를 들어 동일한 스핀들 집합에 페이지 파일이나 Windows® 2000 Server 또는 Windows Server™ 2003 운영 체제를 배치하면 분할에 의한 성능적인 이점을 얻을 수 없습니다.

서버에 여러 개의 저장소 그룹을 만들려는 경우에도 마찬가지로 가장 먼저 트랜잭션 로그를 전용 스핀들로 분할해야 합니다. 단, 성능 향상을 위해서는 각 저장소 그룹에 대한 전용 스핀들 집합이 있어야 합니다. 전용 스핀들 집합이 있는 경우에는 스핀들이 몇 개나 남아 있는지 결정합니다. 대다수 서버에는 사용 가능한 디스크 슬롯이 많지 않으므로 모든 데이터베이스를 동일한 파티션에 배치하는 것이 가장 좋습니다.

여러 저장소 그룹의 데이터베이스를 동일한 배열에 분산시킨 경우 이 배열을 사용할 수 없다면 해당 저장소 그룹의 모든 데이터베이스와 심지어는 다른 배열에 있는 데이터베이스조차도 일시적으로 사용할 수 없게 됩니다. 잘못된 데이터베이스는 다운된 것으로 표시되고 정상적인 데이터베이스는 다시 연결됩니다. 연결이 몇 분 동안 중단된 후 Microsoft Outlook®과 같은 MAPI 클라이언트의 연결이 다시 복원됩니다.

디스크 수가 충분한 경우는 스트리밍 데이터베이스(.stm) 파일로부터 속성 데이터베이스(.edb) 파일을 분할할 수 있습니다. 서버에 적합한 클라이언트 종류에 따라 성능상의 파일 분할 이점이 결정됩니다. 예를 들어 대용량 첨부 파일을 사용하는 IMAP4(Internet Message Access Protocol 버전 4rev1)와 POP3(Post Office Protocol 버전 3) 사용자에게만 서비스를 제공하려는 경우 일반적으로 .edb 데이터베이스상에서 MAPI 사용자에게 나타나는 크기인 4KB보다 읽기/쓰기 크기가 더 클 수 있습니다. 이러한 경우에는 파일을 분할하는 것이 좋습니다. 대용량 첨부 파일을 지원하기 위해 .stm 파일에 맞게 디스크를 최적화할 수 있습니다.

MAPI 및 Microsoft Outlook Web Access 클라이언트는 .edb 파일에 데이터를 쓰고 읽습니다. 기술적으로 보면 클라이언트가 Store.exe 프로세스와 통신합니다. 따라서 클라이언트는 .edb 파일과 .stm 파일을 구별하지 못합니다. 다른 모든 클라이언트는 .stm 파일을 사용합니다. 다음 표에서는 다양한 클라이언트에서 사용하는 기본 설정 위치를 보여 줍니다.

기본 설정 클라이언트 저장소 위치

이 표에 나오는 기본 파일 형식은 서로 바뀔 수 있습니다. 예를 들어 POP3 클라이언트가 메시지를 전송하면 실제로는 이 메시지 데이터가 .stm 파일에 저장됩니다. 메시지 헤더와 기타 데이터의 .edb 파일로 속성이 자동 승격되기도 합니다. 하지만 여기서는 MAPI 클라이언트가 메시지 읽기를 시도한다고 가정합니다. 이 시나리오에서는 .stm 파일의 메시지 데이터가 .edb 파일로 완전하게 승격됩니다. 첨부 파일은 .stm 파일에 남아 있으며 메모리에서 변환이 수행됩니다. 승격은 .stm 파일에서 .edb 파일로만 일어납니다. 이 시나리오에서 데이터가 .stm 파일로 승격되지 않으며 모든 클라이언트 변환은 임시 파일을 사용하여 메모리에서 수행됩니다.

대다수 시나리오에서는 .edb 파일과 .stm 파일을 별도의 스핀들로 분할하더라도 실제적인 이점이 없습니다. 예를 들어 6개의 디스크가 있는 경우 디스크 3개 상에 2개의 RAID5 파티션을 만드는 것이 하나의 RAID0+1(스트라이프 및 미러) 파티션을 만드는 것보다 뛰어난 성능을 제공하는지 결정해야 합니다. 이 경우는 RAID0+1이 더 뛰어난 쓰기 성능을 제공합니다.

디스크 수가 증가하면 일반적으로 사용자 데이터 처리를 위해 적은 수의 대용량 디스크를 구입하게 됩니다. 그러나 디스크 속도는 디스크 크기에 비례하지 않습니다. 따라서 실제 디스크 공간이 충분하더라도 사용자 로드에 비해 성능은 충분하지 않을 수 있습니다. 사서함 서버에 실제 디스크 스핀들을 충분히 할당합니다. 참고로 GB 단위의 캐시와 많은 수의 하드 디스크 랙을 사용하는 특수한 저장소 하위 시스템에는 파티션 관리 및 내결함성을 위한 자체의 운영 체제가 있습니다. 이러한 장치를 사용하는 경우 하드웨어 공급업체로부터 전문가의 지원을 받으십시오.

다음은 사서함 서버를 구성하기 위한 최상의 지침을 요약한 내용입니다.

• Windows 및 Exchange 이진 파일에 대해 RAID1 파티션을 만듭니다.
• 페이지 파일을 별도의 RAID1 스핀들에 배치합니다. 사서함 서버의 경우는 볼륨 손실로 인해 서버가 중단될 수 있으므로 비 RAID 파티션에 페이지 파일을 배치해서는 안 됩니다.
• 트랜잭션 로그의 저장소 그룹마다 하나의 전용 내결함성 파티션을 만듭니다(예: RAID1 또는 RAID0+1). 디스크가 2개인 RAID1 파티션에서 초당 약 300개의 순차적 쓰기 I/O 작업을 수행할 수 있어야 합니다. 이 정도의 용량이면 사용 중인 5개의 데이터베이스 저장소 그룹에 적합합니다.
• 데이터베이스에 대해 최소 하나 이상의 내결함성 파티션을 만듭니다. 배열이 하나밖에 없으면 모든 데이터베이스를 이 배열에 배치합니다. 배열이 여러 개이면 각 저장소 그룹에 대해 하나의 배열을 사용합니다(데이터베이스에만 해당).

데이터베이스, SMTP 큐 및 트랜잭션 로그 파일은 Exchange System Manager를 사용하여 다른 파티션으로 이동할 수 있습니다.

데이터베이스 및 로그 이동에 대한 자세한 내용은 Microsoft 기술 자료 문서 257184, "XADM: Exchange 2000 Server의 Exchange 데이터베이스와 로그를 이동하는 방법"을 참조하십시오.

Exchange I/O 작업을 저장소 트랙 경계에 맞춤

트랙당 64개의 섹터를 관리하는 실제 디스크에서 Windows는 항상 64번째 섹터에서 시작하는 파티션을 만들기 때문에 실제 기본 디스크와 맞춤이 틀리게 됩니다. 디스크 맞춤을 정확하게 하려면 디스크 파티션 도구인 Diskpart.exe를 사용합니다. Diskpart.exe는 Microsoft Windows Server 2003 서비스 팩 1 지원 도구의 유틸리티입니다. Diskpart.exe는 MBR(마스터 부트 레코드)에 시작 오프셋을 명시적으로 설정할 수 있는 명령줄 유틸리티입니다. 시작 오프셋을 설정하면 맞춤을 추적하고 디스크 성능을 향상시킬 수 있습니다. Exchange Server 2003에서는 4KB I/O 작업의 배수로 데이터를 기록합니다(데이터베이스의 경우 4KB, 스트리밍 파일의 경우 최대 32KB). 따라서 시작 오프셋은 4KB의 배수가 되어야 하며 그렇지 않은 경우 두 트랙에 걸쳐 있는 단일 I/O 작업의 성능이 저하됩니다.

자세한 내용은 Exchange Server 2003의 저장소 최적화 가이드에서 "저장소 트랙 경계에 Exchange I/O 맞추는 방법"을 참조하십시오.