네임스페이스 계획 개요

마지막으로 수정된 항목: 2008-10-22

작성자: Patricia DiGiacomo Eddy

Microsoft Exchange Server 2007을 배포하기 전에 결정해야 하는 가장 중요한 사항 중 하나는 조직의 네임스페이스 정렬 방법입니다. 네임스페이스는 일반적으로 DNS에서 도메인 이름으로 표시되는 논리 구조입니다. 네임스페이스를 정의할 때는 사서함이 들어 있는 클라이언트와 서버의 다양한 위치를 고려해야 합니다. 클라이언트의 실제 위치 외에도 Exchange 2007에 연결되는 방식도 평가해야 합니다. 이러한 질문에 대한 대답에 따라 필요한 네임스페이스의 수가 결정됩니다. 네임스페이스는 일반적으로 DNS 구성에 맞추어집니다. 인터넷 연결 클라이언트 액세스 서버가 하나 이상 있는 지역의 Active Directory 사이트마다 하나의 고유한 네임스페이스가 있는 것이 좋습니다. 이러한 네임스페이스는 일반적으로 mail.contoso.com 또는 mail.europe.contoso.com과 같은 A 레코드로 DNS에 표시됩니다.

Exchange 2007 조직을 구현하려면 먼저 조직 구성 방법 및 외부 네임스페이스 정의 방법을 결정해야 합니다. 네임스페이스에 대한 결정은 다음 사항에 영향을 미칩니다.

• DNS 구성 방법

• Exchange 2007을 실행하는 컴퓨터와 클라이언트 컴퓨터 및 장치 간 통신을 암호화하기 위해 필요한 인증서

• 클라이언트가 외부에서 Outlook 사용, Outlook Web Access 및 POP3/IMAP4 클라이언트를 사용하여 사서함에 액세스하는 방법

이 프로세스에는 실제 및 논리 네트워크 구조를 검사하고 조직 토폴로지를 선택하는 과정이 포함됩니다. 이 항목에서는 다양한 토폴로지에 대한 개요를 제공하고 각 토폴로지가 Exchange 조직에 영향을 미치는 방식에 대해 설명합니다.

Exchange 2007 조직 모델

다음과 같은 토폴로지에 대해 살펴봅니다.

• 통합 데이터 센터 모델   이 모델은 하나의 실제 사이트로 구성됩니다. 모든 서버가 하나의 실제 사이트 내에 있으며 mail.contoso.com과 같은 단일 네임스페이스가 있습니다.

• 단일 네임스페이스와 프록시 사이트   이 모델은 여러 개의 실제 사이트로 구성됩니다. 하나의 사이트에만 인터넷 연결 클라이언트 액세스 서버가 포함되어 있습니다. 다른 실제 사이트는 인터넷에 노출되지 않습니다. 이 모델에서는 사이트에 대해 하나의 네임스페이스(예: mail.contoso.com)만 있습니다.

• 단일 네임스페이스와 다중 사이트   이 모델은 여러 개의 실제 사이트로 구성됩니다. 각 사이트에 하나의 인터넷 연결 클라이언트 액세스 서버가 있거나 하나의 사이트에만 인터넷 연결 클라이언트 액세스 서버가 포함되어 있을 수도 있습니다. 이 모델에서는 사이트에 대해 하나의 네임스페이스(예: mail.contoso.com)만 있습니다.

• 국가별 네임스페이스   이 모델은 여러 개의 실제 사이트와 여러 개의 네임스페이스로 구성됩니다. 예를 들어, 뉴욕에 있는 사이트의 네임스페이스는 mail.usa.contoso.com이 되고 토론토에 있는 사이트의 네임스페이스는 mail.canada.contoso.com이 되며 런던에 있는 사이트의 네임스페이스는 mail.europe.contoso.com이 됩니다.

• 다중 포리스트   이 모델은 여러 개의 네임스페이스가 있는 다중 포리스트로 구성됩니다. 이 모델을 사용하는 조직은 두 개의 파트너 회사로 구성될 수 있습니다(예: Contoso와 ContosoOnline). 네임스페이스에는 mail.usa.contoso.com, mail.europe.contoso.com, mail.asia.contosoonline.com 및 mail.europe.contosoonline.com이 포함될 수 있습니다.

통합 데이터 센터 모델

통합 데이터 센터 모델은 이 문서에서 다뤄지는 가장 단순한 모델로서 하나의 실제 사이트로 구성됩니다.

이 모델의 장점은 다음과 같습니다.

• 다중 네임스페이스 모델보다 관리할 DNS 레코드가 적습니다.

• 관리할 인증서가 적습니다. Exchange 클라이언트 액세스 서버와 클라이언트 간의 통신을 여러 가지 방법으로 암호화할 수 있습니다. 주체 대체 이름을 지원하는 단일 인증서를 사용하는 것이 좋습니다. 자세한 내용은 Microsoft 고객지원을 참조하십시오.

  참고

  주체 대체 이름은 사이트 관리자가 서버 인증서가 필요한 모든 네임스페이스를 나열하는 단일 인증서를 구성할 수 있도록 하는 디지털 인증서의 특성입니다.

  참고

  통합 데이터 센터 모델에서 인증서를 관리하는 다른 방법으로는 와일드 카드 인증서, 다중 인증서 및 적절한 SRV 레코드를 구성하는 방법이 있습니다. 이러한 방법에 대한 자세한 내용은 White Paper: Exchange 2007 Autodiscover Service(영문)를 참조하십시오.

• 최종 사용자는 사용할 네임스페이스를 결정할 필요가 없습니다. 모든 최종 사용자가 동일한 네임스페이스와 URL을 사용하여 Microsoft Exchange에 액세스합니다.

이 모델의 단점은 다음과 같습니다.

• 이 모델은 다중 데이터 센터를 지원하지 않습니다.

• 낮은 대역폭, 긴 대기 시간 또는 많은 사용으로 인해 국가별 인터넷 연결이 느려질 경우 해당 지역의 사용자가 성능 저하를 겪게 됩니다.

단일 네임스페이스와 프록시 사이트

이 모델은 단일 네임스페이스를 사용하는 여러 개의 실제 사이트로 구성됩니다. 사이트 중 하나에 인터넷 연결 클라이언트 액세스 서버가 하나 이상 포함되어 있으며 나머지 사이트에는 인터넷 연결 클라이언트 액세스 서버가 없습니다.

다음 그림에서는 이 모델을 보여줍니다.

이 모델의 장점은 다음과 같습니다.

• 다중 네임스페이스 토폴로지보다 관리할 DNS 레코드가 적습니다. 이는 작업의 복잡성을 줄여줍니다.

• 관리할 인증서가 적습니다. 주체 대체 이름을 지원하는 단일 인증서를 사용하여 클라이언트 액세스 서버와 클라이언트 간의 통신을 암호화할 수 있습니다.

• 최종 사용자는 사용할 네임스페이스를 결정할 필요가 없습니다. 모든 최종 사용자가 동일한 네임스페이스와 URL을 사용하여 Microsoft Exchange에 액세스합니다.

단일 네임스페이스와 프록시 사이트 배포하는 경우 여러 가지 단점도 있습니다. 여기에는 다음과 같은 사항이 포함됩니다.

• 높은 비율의 사용자가 프록싱을 통해 사서함 서버에 액세스합니다. 사용자가 사서함 서버와 동일한 실제 사이트에 있지 않은 클라이언트 액세스 서버에 연결할 경우 사서함 서버와 동일한 실제 사이트에 있는 클라이언트 액세스 서버로 프록시 처리됩니다. 프록싱이 추가되어 WAN 링크 비용이 증가하고 최적의 성능이 제공되지 않습니다. 성능에 미치는 영향은 두 개의 실제 데이터 센터 간의 거리에 따라 달라집니다.

• 사용자가 사서함 서버와 동일한 사이트 내에 있지 않은 클라이언트 액세스 서버에 연결할 경우 Windows SharePoint Services 라이브러리와 Windows 파일 공유에 액세스할 수 없습니다. Windows SharePoint Services 라이브러리와 Windows 파일 공유에 액세스하기 위해서는 사용자의 사용자 이름과 암호가 필요하기 때문에 오류가 발생합니다. 프록싱 시나리오에서 Windows SharePoint Services 라이브러리와 Windows 파일 공유에 대한 통신은 Exchange 서비스 계정을 통해 수행됩니다. 이 계정은 사용자의 사용자 이름과 암호를 인식하지 않습니다.

• POP3 또는 IMAP4 프로토콜을 사용하는 클라이언트는 연결 대상 클라이언트 액세스 서버가 사서함 서버와 같은 사이트에 있지 않으면 사서함에 액세스할 수 없게 됩니다. POP3 및 IMAP4 연결은 사이트 간에 프록시 처리할 수 없습니다.

  중요

  프록시 처리되는 사이트의 각 클라이언트 액세스 서버에서 대상 가상 디렉터리를 Windows 통합 인증용으로 구성해야 합니다.

단일 네임스페이스와 다중 사이트

이 모델은 단일 네임스페이스를 사용하는 여러 개의 실제 사이트로 구성됩니다. 이 모델에서는 두 가지 배포 옵션을 선택할 수 있습니다. 즉, 하나 이상의 사이트 앞에서 ISA Server 서버를 사용할 수 있거나 클라이언트 액세스 서버 프록시 사이트를 사용할 수 있습니다. 각 사이트의 뒤에는 인터넷에 액세스할 수 있는 서버가 하나 이상 있을 수 있습니다. 이 모델에서는 들어오는 트래픽을 인터넷 연결 사이트 간에 동일하게 나누는 부하 분산 솔루션도 필요합니다.

ISA 서버에 배포

다음 그림에서는 ISA Server 또는 기타 방화벽 뒤에 이 모델을 배포하는 작업을 보여줍니다.

그림에 나와 있는 구성에서 ISA Server는 클라이언트의 그룹 구성원 자격을 확인하기 위해 연결을 사전 인증합니다. 그런 다음 트래픽이 구성된 게시 규칙을 기반으로 하여 올바른 사이트로 전달됩니다.

이 모델의 장점은 다음과 같습니다.

• 다중 네임스페이스 모델보다 관리할 DNS 레코드가 적습니다. 이는 작업의 복잡성을 줄여줍니다.

• 관리할 인증서가 적습니다. 주체 대체 이름을 지원하는 단일 인증서를 사용하여 클라이언트 액세스 서버와 클라이언트 간의 통신을 암호화할 수 있습니다. ISA Server 서버는 인식된 공급자의 신뢰할 수 있는 외부 인증서를 사용하도록 구성할 수 있습니다. ISA Server 서버와 클라이언트 액세스 서버 간의 트래픽은 내부에서 생성된 인증서를 사용하여 보호할 수 있습니다.

• 최종 사용자는 사용할 네임스페이스를 결정할 필요가 없습니다. 모든 사용자가 동일한 네임스페이스와 URL을 사용하여 Microsoft Exchange에 액세스합니다.

• 외부 네임스페이스를 변경하지 않고도 사서함을 사이트 간에 이동할 수 있습니다. 따라서 관리자가 클라이언트 구성을 변경하지 않고도 사이트 간에 트래픽을 원활하게 부하를 분산할 수 있습니다.

• 필요한 경우 나중에 국가별 네임스페이스를 추가할 수 있습니다. 다른 외부 URL을 사용하는 다른 위치에서도 이와 동일한 모델을 반복할 수 있습니다.

• 조직의 특정 요구 사항에 맞도록 ISA Server 2006 양식 기반 인증을 사용자 지정할 수 있습니다.

이 모델 배포 시의 단점은 다음과 같습니다.

• WAN(Wide Area Network) 사용이 증가할 수 있습니다. 증가량은 ISA Server 서버의 실제 위치에 따라 다릅니다.

• ISA Server를 올바르게 배포 및 구성해야 합니다.

• 트래픽이 올바른 사이트로 전달되도록 하려면 그룹 구성원 자격을 관리해야 합니다. 기본적으로 받는 사람 관리자는 보안 그룹을 만들 수 없으므로, 전용 Exchange 관리자가 그룹 구성원 자격을 만들고 업데이트할 수 있도록 Active Directory 위임을 구성해야 합니다. 그룹을 사용하는 경우 운영 오버헤드가 증가하므로, 새 사서함을 만들거나 이동할 때는 이를 고려해야 합니다. WAN을 통해 불필요한 인증 요청이 전달되지 않도록 하려면 글로벌 카탈로그 서버를 ISA Server 서버에 근접하게 배치하는 것이 좋습니다.

  중요

  단일 네임스페이스와 다중 Active Directory 사이트가 있는 토폴로지 배포는 권장하지 않습니다. 토폴로지에서 다중 Active Directory 사이트를 사용할 경우 국가별 네임스페이스 모델을 사용하는 것이 좋습니다.

  참고

  단일 네임스페이스와 다중 사이트를 배포할 때 리디렉션을 사용하지 않도록 설정하고 프록싱을 적용하려는 경우 인터넷 연결 클라이언트 액세스 서버의 가상 디렉터리에 대한 ExternalURL 값을 지워야 합니다.

클라이언트 액세스 서버 프록시 사이트 배포

다음 그림에서는 이 모델을 보여줍니다.

이 모델에서는 외부에서 생성된 모든 클라이언트 연결이 Active Directory 사이트 C로 이동한 다음 사이트 C의 클라이언트 액세스 서버를 통해 사용자 사서함이 포함된 사이트로 프록시 처리됩니다.

이 모델의 장점은 다음과 같습니다.

• 다중 네임스페이스 모델보다 관리할 DNS 레코드가 적습니다. 이는 작업의 복잡성을 줄여줍니다.

• 관리할 인증서가 적습니다. 주체 대체 이름을 지원하는 단일 인증서를 사용하여 클라이언트 액세스 서버와 클라이언트 간의 통신을 암호화할 수 있습니다. ISA Server는 인식된 공급자의 신뢰할 수 있는 외부 인증서를 사용하도록 구성할 수 있으며, ISA Server와 클라이언트 액세스 서버 간의 트래픽은 내부에서 생성된 인증서를 사용하여 보호할 수 있습니다.

• 최종 사용자는 사용할 네임스페이스를 결정할 필요가 없습니다. 모든 최종 사용자가 동일한 네임스페이스와 URL을 사용하여 Microsoft Exchange에 액세스합니다. 분할 DNS를 구성하는 경우에는 이 모델을 사용하여 내부 네임스페이스를 통합할 수도 있습니다. 분할 DNS를 구성하지 않으면 모든 내부 클라이언트 요청이 방화벽에 도달하여 적절하게 전달됩니다.

• 외부 사용자 측면에서 네임스페이스를 변경하지 않고도 사서함을 사이트 간에 이동할 수 있습니다. 따라서 관리자가 사이트 간에 원활하게 트래픽의 부하를 분산할 수 있습니다. 또한 재해가 발생하여 전체 서비스를 사이트 간에 이동해야 하는 경우에도 이 모델이 유용합니다. 클라이언트 구성을 변경하지 않아도 되기 때문입니다.

• 필요한 경우 나중에 국가별 네임스페이스를 추가할 수 있습니다. 다른 외부 URL을 사용하는 다른 위치에서도 이와 동일한 모델을 반복할 수 있습니다.

이 모델의 단점은 다음과 같습니다.

• WAN 사용률이 증가할 수 있습니다. 증가량은 인터넷 연결 사이트에서 클라이언트 액세스 서버의 실제 위치에 따라 다릅니다.

• 추가 클라이언트 액세스 서버를 올바르게 배포 및 구성해야 합니다.

• 모든 사용자가 프록싱을 통해 사서함에 액세스합니다. 사용자가 사이트 C의 클라이언트 액세스 서버에 연결할 때 이 서버는 사서함 서버와 같은 Active Directory 사이트가 아닙니다. 즉, 사용자는 사서함 서버와 같은 Active Directory 사이트에 있는 클라이언트 액세스 서버로 프록시 처리됩니다. 이와 같은 추가 프록싱 때문에 성능이 최적 상태를 유지하지 못하게 됩니다. 성능에 미치는 영향은 두 실제 사이트 간의 거리에 따라 달라집니다.

• 사용자가 사서함 서버와 동일한 사이트 내에 있지 않은 클라이언트 액세스 서버에 연결할 경우 Windows SharePoint Services 라이브러리와 Windows 파일 공유에 액세스할 수 없습니다. Windows SharePoint Services 라이브러리와 Windows 파일 공유에 액세스하기 위해서는 사용자의 사용자 이름과 암호가 필요하기 때문입니다. 프록싱 시나리오에서 Windows SharePoint Services 라이브러리와 Windows 파일 공유에 대한 통신은 Exchange 시스템 계정을 통해 수행됩니다. 이 계정은 사용자의 사용자 이름과 암호를 인식하지 않습니다.

• POP3 또는 IMAP4 프로토콜을 사용하는 클라이언트는 연결 대상 클라이언트 액세스 서버가 사서함 서버와 같은 사이트에 있지 않으면 사서함에 액세스할 수 없게 됩니다. POP3 및 IMAP4 액세스는 사이트 간에 프록시 처리할 수 없습니다.

  중요

  사용자 사서함이 들어 있는 사이트의 각 가상 디렉터리에 대한 ExternalURL 속성은 $null로 설정해야 합니다.

  중요

  클라이언트 액세스 서버에서는 여러 프록싱 수준을 지원하지 않습니다. 사용자 사서함이 들어 있는 각 사이트는 전용 프록시 사이트의 클라이언트 액세스 서버에서 액세스할 수 있어야 합니다.

  참고

  여러 위치를 사용하는 경우에는 네트워크 구성 작업을 추가로 수행해야 할 수 있습니다. 여기에는 하드웨어 부하 분산 장치, 여러 DNS 레코드 및 경로 중복 구성 작업이 포함될 수 있습니다. 실제 배포는 조직의 네트워크 토폴로지에 따라 달라집니다.
  

국가별 네임스페이스

각 사이트마다 서로 다른 네임스페이스를 사용하는 다중 사이트를 국가별 네임스페이스 모델이라고 합니다. 다음 그림에서는 국가별 네임스페이스 모델을 보여줍니다.

이 모델의 장점은 다음과 같습니다.

• 더 높은 비율의 사용자가 사서함 서버와 동일한 Active Directory 사이트에 있는 클라이언트 액세스 서버에 연결할 수 있으므로 프록싱이 감소합니다. 이를 통해 최종 사용자 환경 및 성능이 향상됩니다. 인터넷 연결 클라이언트 액세스 서버가 없는 사이트에 사서함이 있는 사용자는 여전히 프록시 처리됩니다.

이 모델의 단점은 다음과 같습니다.

• 여러 개의 DNS 레코드를 관리해야 합니다.

• 여러 개의 인증서를 가져오고, 구성하고, 관리해야 합니다.

• 각 인터넷 연결 사이트마다 ISA Server 컴퓨터 또는 다른 방화벽이 필요하기 때문에 보안 관리가 더 복잡합니다.

• 각 사용자는 자신의 국가별 네임스페이스에 연결해야 합니다. 이로 인해 지원 부서와의 통화 및 교육이 별도로 필요할 수도 있습니다.

다중 포리스트

이 모델은 여러 개의 네임스페이스가 있는 다중 포리스트로 구성됩니다. 이 모델을 사용하는 조직은 두 개의 파트너 회사로 구성될 수 있습니다(예: Contoso와 ContosoOnline). 네임스페이스에는 mail.usa.contoso.com, mail.europe.contoso.com, mail.asia.contosoonline.com 및 mail.europe.contosoonline.com이 포함될 수 있습니다.

최종 사용자에게 최고 수준의 성능을 제공하기 위해서는 각 포리스트마다 국가별 네임스페이스 모델을 구현하는 것이 좋습니다. 각 포리스트마다 여러 개의 인증서를 관리해야 합니다.

자세한 내용

Exchange 2007 SP1에 대한 자세한 내용은 What's New in Exchange Server 2007 Service Pack 1(영문)을 참조하십시오.

Windows Mobile 6.1에 대한 자세한 내용은 Windows Mobile 홈 페이지를 참조하십시오.

Patricia DiGiacomo Eddy(영문) - Microsoft Exchange Server 시니어 테크니컬 라이터