Exchange Queue & A디스크 파티션 할당, SCR 계획 및 기타 정보 디스크 파티션 할당, SCR 계획 및 기타 정보

Henrik Walther

Q: 현재 Exchange Server 2003을 새로운 Exchange Server 2007 조직으로 마이그레이션하기 위한 계획을 진행 중입니다. 원래는 새로운 조직에 공용 폴더를 복제하기 위해 Microsoft® IORepl(Inter-Organization Replication) 도구를 사용하려고 했습니다. 그런데 듣기로는 IORepl이 Exchange 2007 대상 서버를 지원하지 않으며 Exchange 2003 서버를 대상 Exchange 조직에 도입해야 한다고 하는 것 같습니다.

A: Exchange 2003 조직과 순수 Exchange 2007 조직 간에 약속 있음/없음 데이터나 공용 폴더를 복제하는 기능이 제공되지 않는다는 소문이 있지만 이것은 사실이 아닙니다. 실제로 Exchange 2007 관리 도구가 설치되어 있지만 다른 Exchange 2007 서버 역할이 없는 서버에서도 IORepl을 완전하게 사용할 수 있습니다. 그러나 서버에 Microsoft Exchange Server MAPI(Messaging Application Programming Interface) 클라이언트와 CDO(Collaboration Data Objects)를 설치해야 한다는 것을 기억하십시오. 이제 이러한 항목은 기본 제품 설치에 포함되지 않습니다.

Q: 현재 150,000명의 사용자로 구성된 대규모 조직을 위한 Exchange Server 2007 디자인을 진행하고 있습니다. Exchange 2007 메시징 인프라에 필요한 글로벌 카탈로그 서버의 수를 계산해야 하는데 도와주실 수 있겠습니까?

A: 물론입니다! 애초에 이 칼럼을 준비한 것도 바로 이러한 도움을 제공하기 위해서입니다. 먼저 여기에서 중요한 것은 사용하려는 Exchange 2007 사서함 서버 코어를 바탕으로 얼마나 많은 글로벌 카탈로그 서버를 사용할지 계산해야 한다는 것입니다. 여기에서 말하는 것은 프로세서의 수가 아니라 코어의 수입니다. 글로벌 카탈로그 서버 코어의 수를 계산할 때는 사서함 서버에 대해서만 고려하며 클라이언트 액세스, 허브 전송, 통합 메시징 또는 Edge 전송과 같은 다른 Exchange 2007 서버 역할에 대해서는 고려하지 않습니다. 다른 Exchange 2007 서버 역할도 필요한 글로벌 카탈로그 서버의 수에 영향을 주지만 배포된 사서함 서버의 수는 다른 다른 Exchange 2007 서버 역할에 영향을 주므로 사서함 서버의 수를 바탕으로 필요한 글로벌 카탈로그 서버의 수를 계산할 수 있습니다.

또한 글로벌 카탈로그 코어의 수는 Active Directory® 인프라에서 사용하는 도메인 컨트롤러가 32비트인지 또는 64비트인지에 따라서도 달라집니다. 32비트 도메인 컨트롤러의 경우에는 4:1 비율을 적용하여 사서함 서버 코어 4개당 글로벌 카탈로그 코어 1개를 사용하도록 계획해야 합니다. 64비트 도메인 컨트롤의 경우에는 8:1 비율을 적용합니다. 따라서 8개의 코어가 설치되어 있고 64비트 도메인 컨트롤러를 사용하는 환경에 Exchange 2007 사서함 서버를 배포하는 경우 Exchange 2007 사서함 서버 한 개당 글로벌 카탈로그 서버 한 개가 필요합니다. 참고로 64비트 도메인 컨트롤러를 사용하는 경우에는 전체 Active Directory 데이터베이스(NTDS.DIT 파일)를 메모리에 캐시할 수 있도록 충분한 메모리를 설치하는 것이 좋습니다.

Q: 앞서 질문을 통해서 Exchange 2007 사서함 서버당 필요한 글로벌 카탈로그 서버의 수에 대한 궁금증은 해결되었습니다. 그렇다면 Exchange 2007 허브 전송 및 클라이언트 액세스 서버 역할을 얼마나 배포해야 하는지는 어떻게 알 수 있습니까?

A: 앞서 질문에 대한 답에서 제안한 것처럼 배포해야 할 Exchange 2007 클라이언트 액세스와 허브 전송 서버(더 구체적으로는 서버 코어)의 수는 사서함 서버 코어의 수에 따라 결정해야 합니다. 결정적인 규칙은 없지만 경험상 사서함 서버 코어 4개당 클라이언트 액세스 서버 코어 1개(4:1 비율), 그리고 사서함 서버 코어 7개당 허브 전송 서버 코어 1개(7:1 비율)를 사용하면 무난합니다. 여기에서 후자는 바이러스 백신 검색을 설치하지 않은 허브 전송 서버의 경우입니다. Forefront Security for Exchange와 같은 바이러스 백신 검색 제품을 설치한 경우에는 일반적으로 사서함 서버 코어 5개당 허브 전송 서버 코어 1개(5:1 비율)를 사용해야 합니다.

Q: Exchange 2007 서버에 프로세서 코어를 8개 넘게 설치하는 것은 권장되지 않는다는 이야기를 들었습니다. 이것이 사실인지, 사실이라면 그 이유는 무엇인지 알려주십시오.

A: 예 사실입니다. 다중 코어 프로세서를 설치하면 Exchange Server 2007의 성능이 크게 개선되지만 Exchange 2007 서버용으로 설치할 코어의 수는 8개로 제한해야 합니다. 더 구체적으로 설명하면 8개까지의 추가 코어를 통해 혜택을 받을 수 있는 Exchange 2007 서버 역할은 허브 전송과 사서함 서버 역할의 단 두 가지입니다. 그리고 이것도 매일 수백만 개의 메시지를 처리하고 수천 개의 사서함을 저장하는 매우 바쁜 Exchange 2007 서버의 경우에만 해당되는 이야기입니다.

Exchange 제품 그룹에서는 프로세서 코어가 12개 설치된 서버에서 Exchange 2007 사서함 서버를 테스트했으며 저장소 성능과 확장성이 저하되는 현상을 확인했습니다. 또한 코어가 8개에서 16개로 늘어나면 RPC(원격 프로시저 호출) 평균 대기 시간이 두 배로 늘어나는 문제도 있었습니다.

매우 바쁜 사서함 서버가 아니라면 일반적으로 프로세서 코어 4개로도 충분합니다. 다른 Exchange 2007 서버 역할에 대한 자세한 내용 및 프로세서 고려 사항에 대해서는 technet.microsoft.com/aa998874를 참조하십시오.

Q: 현재 Exchange 2000 및 Exchange 2003 조직에서 새로운 Exchange 2007 조직으로 크로스 포리스트 마이그레이션을 수행하고 있습니다. 그런데 Move-Mailbox cmdlet에 -SourceMailboxCleanupOptions DeleteSourceMailbox 매개 변수를 지정하고 사용하여 원본 포리스트에서 대상 포리스트로 사서함을 이동하려고 하면 다음과 같은 오류가 표시됩니다.

"사서함을 대상 Exchange 서버로 이동하고 원본 Exchange 서버에서 제거했지만 원본 사서함 사용자에서 사서함 특성을 삭제하는 동안 오류가 발생했습니다. 도메인 컨트롤러 'file01' 운영체제 버전은 5.0 (2195) 서비스 팩 4입니다. 필요한 최소 버전은 5.2 (3790) 서비스 팩 1입니다."

원본 포리스트에 Windows Server® 2003 기반 도메인 컨트롤러(글로벌 카탈로그 서버이기도 함)가 있지만 –DomainController 매개 변수는 대상 포리스트의 도메인 컨트롤러나 글로벌 카탈로그 서버만 지정할 수 있기 때문에 원본 포리스트에서 사용할 도메인 컨트롤러를 지정할 수가 없는 것 같습니다. 맞습니까? 맞다면 해결 방법이 있습니까?

A: 맞습니다. Move-Mailbox cmdlet에서는 원본 포리스트의 도메인 컨트롤러나 글로벌 카탈로그 서버를 지정할 수 없습니다. 도메인 컨트롤러(글로벌 카탈로그 서버)는 임의로 선택됩니다. 두 가지 해결 방법이 있지만 두 가지 모두 깔끔한 방법은 아닙니다. 첫 번째 방법은 원본 포리스트에서 임의의 Windows® 2000 기반 도메인 컨트롤러를 서비스 해제하는 것이지만 이 옵션을 항상 사용할 수 있는 것은 아닙니다. 문의하신 상황에는 두 번째 방법이 유용할 것 같습니다. Move-Mailbox cmdlet이 글로벌 카탈로그 서버 역할도 하는 도메인 컨트롤러를 사용해야 하는 것이므로 원본 포리스트에 있는 임의의 Windows 2000 서버에서 글로벌 카탈로그 서버 역할을 제거하여 문제를 해결할 수 있음을 의미합니다. 이 방법은 필자는 직접 두 번의 마이그레이션 시나리오에서 사용했던 방법이므로 시도할 만한 가치는 있을 것입니다.

Q: 예를 들어 미국에서 Exchange 2007 클라이언트 액세스, 허브 전송 또는 사서함 서버를 하나의 Active Directory 사이트에 설치하고 이 서버를 덴마크와 같은 다른 Active Directory 사이트로 배송할 수 있습니까? 이것이 지원된다면 Exchange 2007 서버가 새로운 Active Directory 사이트 구성원을 자동으로 인식합니까? 아니면 수동 조작이 필요합니까?

A: 이 시나리오는 완벽하게 지원되며 수동 조작은 필요 없습니다. Net Logon(Net­Logon)과 Microsoft Exchange Active Directory Topology(MSExchangeADTopology) 서비스가 Exchange 2007 서버를 위해 사이트 구성원을 자동으로 처리합니다. 서버가 사이트 구성원을 변경하는 경우 MS­ExchangeADTopology 서비스는 msExch­ServerSite 특성으로 알려진 서버의 사이트 특성을 자동으로 업데이트합니다. 그림 1에 나와 있듯이 ADSIEdit와 같은 도구를 사용하여 msExchServerSite 특성을 볼 수 있습니다.

그림 1 msExchServerSite 특성 보기 (더 크게 보려면 이미지를 클릭하십시오.)

Exchange 2007과 Active Directory 사이트가 어떻게 연관되는지 자세히 알아보려면 technet.microsoft.com/aa998825에서 "Active Directory 사이트 기반 라우팅 이해"라는 Exchange 2007 설명서의 섹션을 읽어 보면 많은 도움이 될 것입니다.

Q: 사서함 데이터베이스를 위한 LCR(로컬 연속 복제)이 설정된 Exchange 2007 사서함 서버에서 Microsoft DPM(Data Protection Manager) 2007을 사용하여 수동 사서함 데이터베이스 복사를 통해 사서함 데이터를 백업할 수 있습니까?

A: Exchange 2007 CCR(Clustered Continuous Replication) 환경에서는 DPM 2007을 사용하여 수동 노드를 통해 사서함 데이터베이스를 백업할 수 있지만 Exchange 2007 LCR 환경에서 사서함 데이터베이스 복사를 수행할 때는 이 기능이 지원되지 않습니다.

Q: Exchange Server 2007 CMS(클러스터된 사서함 서버) 데이터베이스를 독립 실행형 사서함 서버로 이동할 수 있었는데 CCR이나 단일 복사본 클러스터(SCC) 기반 Exchange 2007 CMS에 비클러스터형 데이터베이스를 탑재할 수 있습니까?

A: Exchange Server 2007 정보 저장소는 저장소가 인식 서버의 유형을 인식하지 않으므로 비클러스터형 데이터베이스를 CCR이나 SCC 기반 CMS에 탑재하는 데는 아무런 문제가 없습니다.

Q: technet.microsoft.com/bb508861에 있는 기사를 보면 클러스터된 Exchange 2003 서버에서는 Exchange Server QMS(Quota Message Service)가 지원되지 않는다고 되어 있습니다. 향후에 Exchange 2003이나 Exchange 2007 클러스터된 환경에서 이 서비스가 지원될 예정은 없습니까?

A: Exchange Server QMS 도구는 앞으로도 Exchange 2003 CMS에서 지원되지 않을 것입니다. 또한 QMS 도구는 클러스터된(또는 클러스터되지 않은) Exchange 2007 사서함 서버에서도 지원되지 않습니다. 그러나 조직에서 Exchange 2007을 사용하고 있다면 동일한 기능이 Exchange에 기본적으로 포함되어 있으므로 QMS 도구를 설치할 이유가 없습니다. Exchange 2007에서 할당량 메시지를 관리하는 방법에 대한 자세한 내용은 technet.microsoft.com/bb232089를 참조하십시오.

Q: Active Directory 사용자 및/또는 그룹 개체에서 이러한 엔터티가 사서함을 사용할 수 있게 되거나 메일을 사용할 수 있게 되었을 때 설정되는 특성이 나열하는 참조 설명서가 있습니까?

A: Exchange 2007 설명서의 사용 권한 분할 모델 참조에 이러한 특성이 나열되어 있습니다. 이 문서는 technet.microsoft.com/bb430782에서 볼 수 있습니다.

Q: 현재 Exchange 2007 메시징 인프라에서 내부 메일 흐름을 위해 Exchange 2007 허브 전송 서버를 브리지헤드 서버로 지정하는 방법이 있습니까? 기본적인 개념은 예를 들어 Active Directory 사이트 1에서 Active Directory 사이트 2로 보내는 모든 메일은 허브 전송 서버 A(Active Directory 사이트 1에 있는)에서 허브 전송 서버 B(Active Directory 사이트 2에 있는) 통해 라우팅되고 반대의 경우는 반대로 라우팅되는 것입니다. 이것이 가능합니까?

A: 아니요, 불가능합니다. 이것이 작동하려면 Active Directory 사이트는 받는 사람이 다른 Active Directory 사이트에 있는지를 알아야 합니다. Exchange 2007 사서함 서버 역할에는 이러한 메커니즘이 없습니다.

사서함 서버에 허브 전송 서버가 로컬로 설치되어 있는 경우를 제외하고 사서함 서버는 항상 동일한 Active Directory 사이트에서 허브 전송 서버 간에 연결을 부하 분산합니다. 사서함 서버에 허브 전송 서버 역할이 설치된 경우 사서함 서버로는 항상 같은 실제 시스템의 허브 전송 서버가 선호됩니다.

Exchange 2007는 분류가 수행된 다음에야 받는 사람 사서함의 위치를 알 수 있습니다. 원래의 목표를 가장 근접하게 수행할 수 있는 방법은 그림 2에 나와 있는 것처럼 Set-Mailbox­Server cmdlet에 SubmissionServerOverrideList 매개 변수를 사용하여 사서함 서버가 사용할 허브 전송 서버의 정적 목록을 만드는 것입니다(technet.microsoft.com/bb232193 참조).

그림 2 사서함 서버 설정 (더 크게 보려면 이미지를 클릭하십시오.)

허브 전송 서버 A 또는 B를 지정하면 사서함 서버는 지정된 사이트에서 받는 사람에게 메시지를 보내는 것만이 아니라 모든 Active Directory 사이트 및 로컬 메시지 배달에도 해당 허브 전송 서버를 사용합니다. 이 때문에 이론상으로 단일 실패 지점이 만들어지므로 필자는 이러한 방식 사용을 권장하지 않습니다.

Q: Windows Server 2008에 Exchange Server 2007 SP1 사서함 서버를 설치하려고 하는데 디스크 정렬을 어떻게 해야 하는지 의문이 생깁니다. Windows Server 2003이 실행되는 서버에서 Exchange Server 2003이나 Exchange Server 2007을 설치한 경우에는 전반적인 성능을 향상시키려면 diskpart 도구를 사용하여 트랜잭션 로그 파일과 사서함 저장소를 저장할 파티션을 만드는 것이 좋다고 알고 있습니다. 공급 업체의 권장 사항에 따라서 저장소 파티션을 구성하는 것이 좋다는 것도 알고 있습니다. 저장소 공급 업체의 권장 사항이 없는 경우 Microsoft가 권장하는 최선의 방법에 따라 64KB 값을 사용하는 것이 좋다고 있습니다.

Windows Server 2008에 Exchange 2007 사서함 서버를 설치할 때는 디스크를 어떻게 구성해야 합니까? 동일한 규칙을 적용할 수 있을까요?

좋은 소식을 알려드리죠. Windows Server 2008에서는 Exchange Server 2007 SP1 트랜잭션 로그 파일과 사서함 데이터베이스를 저장할 디스크 파티션을 diskpart 도구를 사용하여 트랙 정렬할 필요가 없어졌습니다. Windows Server 2008에서는 파티션이 항상 64번째 섹터에서 시작하여 Windows 디스크 관리 도구를 사용할 때 전체 파티션의 정렬 불일치가 나타나던 Windows Server 2003의 문제가 해결되었습니다.

트랙 정렬에 대한 자세한 내용은 msexchangeteam.com/archive/2005/08/10/408950.aspx에서 Exchange 팀 블로그를 참조하십시오. 또한 Windows Server 2008은 1024KB 경계를 사용하여 디스크 파티션을 정렬합니다. TechNet의 Exchange Server 2007 설명서(technet.microsoft.com/bb738145)에 이러한 내용이 있습니다.

Q: 현재 Exchange Server 2007 SP1 기반 메시징 환경에서 SCR(대기 연속 복제)을 구현하기 위한 계획 단계에 있습니다. 우리는 비교적 규모가 작은 회사여서 두 번째 사이트에서 SCR 대상으로 작동할 Exchange 2007 서버가 설치된 실제 컴퓨터를 두 대 이상 배포할 여력이 없습니다.

SCR 대상에서 사서함 서버 역할 외에 다른 역할에 대한 지원이 있는지 확신하지 못하고 있습니다.

A: 가능합니다. 원본은 물론 대상 SCR Exchange 서버에서도 다른 Exchange 2007 SP1 역할을 실행할 수 있습니다. 완벽하게 지원된다는 의미이므로 클라이언트 액세스, 허브 전송 및 사서함 서버 역할이 설치된 Exchange 2007 SP1 서버를 배포하고 이를 SCR 대상으로 사용할 수 있습니다.

Q: Windows Server 2003 Active Directory 포리스트 및 Exchange 2007 메시징 인프라를 사용하고 있는 우리 조직에서는 최근에 인수한 다른 조직과의 합병을 앞두고 있습니다. 그런데 두 회사를 합병하는 데 있어 Exchange 2007 주소 목록을 분리하여 각 회사에서 자신의 사용자를 포함하는 주소 목록만 볼 수 있어야 한다는 한 가지 요구 사항이 있습니다.

Exchange 2003 환경에서 이와 같은 작업을 위한 단계별 지침이 포함된 Microsoft 기술 자료를 본 기억이 있습니다. Exchange 2007 기반 메시징 환경에서 주소 목록을 분리하려면 어떤 방법을 사용해야 합니까?

A: 여기에서는 필요한 모든 단계를 설명할 공간이 부족할 것 같습니다. 다행스럽게도 Microsoft에서는 최근 Exchange 2007에서 가상 조직과 주소 목록 분리를 구성하는 방법을 설명하는 기술 백서를 발표했습니다. technet.microsoft.com/bb936719에서 이 백서를 찾을 수 있습니다. 또한 이 백서에 대한 몇 가지 의견을 포스팅한 Dave Goldman의 블로그(go.microsoft.com/fwlink/?LinkId=115499 참조)도 시간을 내어 확인해 보십시오.

Q Exchange Server 2007이 올바르게 작동하려면 WINS(Windows Internet Naming Service)가 필요합니까?

A: Exchange Server 2007 제품 자체에는 WINS가 필요 없습니다. 그러나 Exchange Server 2007 메시징 환경에서 사용하고 있는 Microsoft Office Outlook® 버전에 따라서 WINS가 필요할 수 있습니다. 여러분의 메시징 환경이 Exchange 2007 서버와 Outlook 2007 또는 Outlook 2003 클라이언트로만 구성되어 있다면 WINS는 필요 없습니다.

그러나 드물게 Outlook 2007에서 WINS가 필요한 경우가 있습니다. 사서함을 Exchange 포리스트로 마이그레이션할 때 Outlook 2007 RTM 버전에서는 FQDN(정규화된 도메인 이름)이 아니라 NetBIOS 이름을 사용하여 Exchange 사서함 서버에 연결하려고 시도합니다. 그러나 이 문제는 2008년 1월에 출시된 Outlook 2007 post-SP1 핫픽스 패키지(support.microsoft.com/?id=941275)에서 해결되었습니다.

최종 사용자가 Outlook 2002를 가지고 있다면 이 클라이언트에서 NetBIOS 이름 확인을 사용하므로 WINS가 필요합니다. Outlook 2002 이전의 Outlook 클라이언트는 Exchange 2007에서 지원되지 않지만 마찬가지로 WINS가 필요합니다.

Henrik Walther는 Microsoft Certified Architect로서, 14년 이상의 IT 비즈니스 경력을 자랑하는 메시징(실습생) 및 Exchange MVP이기도 합니다. 현재 Interprise Consulting에서 기술 설계자로 근무하면서 Biblioso Corporation에서 테크니컬 라이터로도 활동하고 있습니다.