메뉴얼에는 없지만, 익스체인지 구성을 위한 HW 를 한번 알아 보자.

물론 프로젝트를 진행했으면 컨설턴트나 MS 기술지원 인력이 있다면 친절하게 알려 주겠지만...

늘 옆에 불러다 앉혀 놓기도 힘들 뿐더러.. 외부 사람과 이야기 하려면, 어느 정도는 알아야 이야기 하기 편할 터....

물론 HW 란 놈은 돈으로 발라 버리면 가장 편하지만, 늘 부족한 것이 투자 비용이고, 어떻게 하면 효율적가가 중요하니...

그리고, 일단 돈 없는 기준으로 어떻게 구성할 건지 생각해 보기로 하자..

 

Storage

- 익스체인지의 가장 중요한 부분이다. 몇가지 서버의 기능 별로 중요하게 고려해야 할 부분이 있으니, 서버 별로 이야기해 보자.

 

1. 메일 박스

- 익스체인지 2010 으로 넘어오면서, HDD 의 부하가 급격하게 줄고 이전보다 더 많은 처리가 가능해졌다... 라고 MS 에서 이야기 하고 있지만, 기본적인 설정의 통념은 여기서도 정확하게 통한다. 일단 고성능 외장 HDD 를 강추... (성능이나 스펙은 그 때 그 때 다르니 제조사 엔지니어의 분석을 듣는 것을 권장 하고..) 버틸 수 있다면 RAID 5 도 좋지만, 임원 등 높으신 분들 전용으로 RAID 0+1 을 따로 뜯어 내는 것도 방법 중에 하나다.

- 예산이 부족해서 내장으로 모두 해결해야 하는 경우라면, 적어도 운영체제 부분과 Data 부분의 HDD 는 꼭 물리적으로 분리하도록, RAID 시스템에서 분리되어 보이도록 하라는 것이 아니라 RAID 그룹 자체를 완전히 분리해야 한다. 물리적으로 겹쳐지는 HDD 가 없어야 한다는 말.... 갑자기 사용자의 DATA Read/Write 가 몰릴 경우 HDD 가 통으로 묶여 있으면 속도에 Paging 파일에 접근도 문제가 되어 시스템의 전체적인 속도가 느려질 수 있다.

실제로 윈도우의 시작 버튼을 눌렀을 때 한칸한칸 올라오는 것을 본 경험이 있다.

어렵다고? 다 떠나서 내장 디스크에 Data 를 써야 하는 경우 물리적인 HDD 를 꼭 분할하라.... (예산 때문에 안된다면? 프로젝트를 연기해야 한다.)

MS 는 internal HDD 로도 충분할 수 있다고 하지만... 책임은 운영자가 지는 거다.. 믿지 마라...

 

2. CAS

- 가장 낮은 부하의 HDD 가 요구되는 서버다. 전형적인 웹서버 이므로... 그닥 크게 신경 안써도 된다.

 

3. Transport

- 은근 높은 성능을 요구한다. 극단적인 경우 SMTP Queue 를 위한 HDD 공간을 외장 Storage 를 사용하여 구성하는 경우도 있다. 특히 많은 사용자들이 사용하는 메일 서버의 경우 Queue 가 기하 급수적으로 쌓여 사용자 메일이 발송되지 않는 경우를 본 적이 있다.

Queue 의 구성은 그 때 그 때 다르나 초기 부터 RAID 0+1 또는 0 그도 아니라면 독자적인 Queue HDD 를 따로 구성하자. (깨지면? 복구하면 따로 또 보내는 방법이 있다. Exchange 는 절대로 메일이 손실되지 않는다.단 HW 적인 Fault 가 발생하면 배달이 좀 많이 늦어진다.)

- 문제는 대부분의 경우 CAS 와 Transport 가 같이 있다는 것이다. (실제로 2013 에는 Transport 가 CAS 와 MailBox 로 나뉘어 졌다.)

이 경우 HDD 는 Transport 의 Queue 부하를 감안하여 구성되어야 한다. 한마디로 CAS 보다 좋은 HDD 로 구성해야 한다는 말이다.

 

Memory

- 익스체인지 HW 업그레이드에 우선 순위는 메모리, HDD, CPU 라고 할만큼 그 중요성이 높은 요소다. 이 역시 많을 수록 좋지만, 서버 별로 주의할 부분을 알아 보자.

 

1. Mailbox

- 가장 메모리가 중요한 Server Role 이다. 알 사람들은 알겠지만 2003 시절에는 32bit 환경에세 메모리를 확보하려고 정말 별 짓을 다 하곤 했다. 최소한 8GB 는 탑재하는 것을 기본으로 해서 설정하도록... 메모리가 적게되면, 성능 저하는 물론이고 정기적인 리부팅을 해 주어야 한다! HDD 보다 더 중요한 것이 메일 박스 서버의 8GB 이상의 메모리다.

- 메일 박스의 Paging 파일이 설정된 (일반적으로 운영체제가 설치된) 파티션의 IO 가 급격하게 발생한다면 메모리 증설을 한번 고려해 주자. MS 에서는 Paging fault 를 메모리 지표로 이야기 하지만, 경험상 절대값을 적용하기에는 무리가 있다. (MS 가 제공하는 임계치를 넘어도 시스템의 운영 환경이 쾌적한 경우가 많다.) 단, 미리 미리 수집해서 기간별 상대값으로는 활용이 가능하다. 평균 값이 10% 이상 증가한 경우라면 메모리 증설을 고려하는 것이 좋다. (근거는... 없다... 이건 완전히 경험에서 나오는 이야기다.)

 

2. CAS

- 별로 메모리가 필요없을 것 지만, CAS 에 대부분 커스터마이징을 수행하므로 IIS 의 w3wp.exe 가 대량의 메모리를 점유한다. 섣불리 결정하지 말고, 프로젝트 파트너의 조언을 구하자,

- 메모리가 부족할 경우 수직 증설, Recycler, 수평 증설 등의 옵션이 많으므로 대응이 유연하다.

- 성능의 문제가 아니라 단순한 메모리의 부족이 문제라면 수직 증설 (메모리 추가) 가 일반적으로 더 유리하다. 서버를 추가할 경우 OS 와 Application 의 Overhead 때문에 가용 메모리의 증가 절대량은 비용 대비 떨어진다.

 

3. Transport

- 크게 메모리를 타지 않는다. 초기 권장량 정도면 크게 문제가 없다.

- 성능의 문제는 메모리에서 발생하는 경우가 드물고, IO, NW, CPU 등에서 발생한다. 메모리 증설 전에 다른 병목을 한번 의심해 보자.

- CAS 와 같이 사용하는 경우 (일반적으로 그렇다) 당연히 CAS 기준으로 구성되어야 한다. (메모리 많이 꽂아야 할 수 있다는 말이다. 섣불리 판단하지 말자.)

 

CPU

- 익스체인지 자체적으로 가장 영향이 적은 부분이다.

- 일반적으로

1. 하이퍼스레드가 유리하다.

2. Mailbox 의 경우 높은 초기 설치 이후에 CPU 추가 증설이나 업그레이드가 필요한 경우가 매우 적다.

3. CAS 의 경우 recyling, 증설, 업그레이드, 확장 등 여러가지 방법의 성능 개선이 필요할 수 있다.

여기서 이렇게 간단하게 이야기 하는 이유는 CAS 의 경우 개발자의 로직에 많은 영향을 받는 IIS 문제가 발생하기 때문이다. 이 문제는 exchange 관리와 성능 이슈가 아니라 IIS 의 관리/성능 이슈로 접근해야 하는 경우가 더 많다.

신고
Posted by 전략과 비젼