CAS 배열 개체에 관한 오해 바로잡기 - 1부
최초 문서 게시일: 2012년 3월 24일 토요일
Exchange 2010은 2009년에 출시된 이후 널리 사용되어 왔습니다. 고객을 대상으로 Exchange 2010 교육을 진행하고 Exchange 2010으로의 이전을 준비하는 과정에서 몇 가지 오해를 확인할 수 있었는데요. 그 중 한 가지는 클라이언트 액세스 서버 배열 개체(짧게 CAS 배열 개체)에 대한 오해입니다. 내부 Microsoft 메일 그룹에 관한 이러한 오해에 대해 언급하자 기술 문서 작성자이자 활발하게 활동하는 블로거인 Scott Schnoll(영문일 수 있음)이 여기에 대한 게시물을 작성해 볼 것을 권했고, 그래서 이 게시물을 작성하게 되었습니다.
이 게시물에서는 CAS 배열 개체의 기술적 측면에 대해 모두 설명하지는 않습니다. 기술 관련 내용은 Nagesh Magadev가 이전 게시물인 Exchange 2010 RPC 클라이언트 액세스 서비스 살펴보기(영문일 수 있음)에서 이미 다룬 바 있습니다.
아래 목록에는 이 게시물에서 설명하고자 하는 CAS 배열 개체에 대해 대부분의 고객이 잘 모르는 사실이 나와 있습니다. 1부에서는 첫 3개 항목에 대해, 2부에서는 마지막 3개 항목에 대해 다룰 예정입니다.
- CAS 배열 개체는 트래픽을 부하 분산하지 않습니다.
- CAS 배열 개체는 자동 검색, OWA, ECP, EWS, IMAP, POP 또는 SMTP서비스를 제공하지 않습니다.
- CAS 배열 개체의 FQDN 은 SSL 인증서에 포함되지 않아도 됩니다.
- 외부 클라이언트에서 DNS를 통해 CAS 배열 개체를 확인할 수 없어야 합니다.
- Exchange 2010 사서함 데이터베이스를 만들고 사서함을 데이터베이스로 이동한 후 CAS 배열 개체를 구성하거나 변경해서는 안 됩니다.
- CAS가 하나뿐이거나 다중 역할 서버가 있는 경우에도 CAS 배열 개체를 구성해야 합니다.
기존에 알고 계셨던 내용과 다르다고요? 이 게시물에서 위의 항목을 하나씩 설명해 드릴 예정입니다. 이 문서에서는 제가 랩에서 사용했던 서버 이름이 몇 개 나오므로 먼저 해당 서버의 정보를 제공해 드립니다.
| 이름 | 서버 역할 | 관리 표시 버전 |
|---|---|---|
| E2K10-MLT-01 | 사서함, 클라이언트 액세스, 허브 전송 | 버전 14.2(빌드 247.5) |
| E2K10-MLT-02 | 사서함, 클라이언트 액세스, 허브 전송 | 버전 14.2(빌드 247.5) |
| E2K7-MLT-02 | 사서함, 클라이언트 액세스, 허브 전송 | 버전 8.3(빌드 83.6) |
| E2003-BE | 없음 | 버전 6.5(빌드 7638.2, 서비스 팩 2) |
그러면 위 목록의 내용을 차례로 살펴보겠습니다.
1. CAS 배열 개체는 트래픽을 부하 분산하지 않습니다.
CAS 배열 개체는 부하 분산을 수행하지 않습니다. 이 개체는 Exchange 내에서 몇 가지 기능을 자동화하는 데 사용되는 Active Directory 개체일 뿐입니다. Exchange 2010 설명서에는 LB(부하 분산 장치)를 사용하여 CAS 트래픽을 부하 분산하는 것이 좋다는 설명이 여러 곳에 나와 있습니다. 그러면 'CAS 배열 개체가 부하 분산을 수행하지 않는다'는 것은 어떤 의미일까요?
부하 분산 장치에서 실제로 수행하는 작업은 CAS 풀(CAS 배열이라고도 함)의 트래픽을 분산하는 것이지 CAS 배열 개체 자체의 트래픽을 분산하는 것은 아닙니다. 이 두 작업은 미세하지만 명확하게 다릅니다. 명칭이 비슷해서 혼란을 줄 뿐입니다.
CAS 배열 개체는 개체와 같은 Active Directory 사이트에서 새로 만든 Exchange 2010 사서함 데이터베이스의 RpcClientAccessServer 특성을 자동으로 채우는 용도로만 주로 사용됩니다.
RpcClientAccessServer 특성은 프로필 만들기 프로세스 중에 프로필에 포함되어야 하는 서버 이름을 Outlook 클라이언트에 알리는 데 사용되며 그 외의 용도로는 사용되지 않습니다. CAS 배열 개체 역시 만들고 나면 Active Directory의 한 개체에 불과하며, 이 시점에서는 부하 분산이 전혀 수행되지 않습니다.
이 게시물에서는 여기까지만 설명하겠습니다. 아래의 작업은 직접 수행해 보시기 바랍니다.
- 클라이언트 컴퓨터가 호스트 이름을 IP 주소로 확인할 수 있도록 하는 'A' 레코드를 DNS에서 만듭니다. 이 IP 주소는 대개 내부 클라이언트만 연결할 수 있는 LB의 VIP(가상 IP)입니다. Outlook 또는 기타 MAPI/RPC 가능 응용 프로그램은 이 VIP에 연결하여 Exchange 2010 사서함 리소스에 대한 액세스 권한을 얻습니다.
- VIP를 통해 CAS 서버 풀로 트래픽을 전달하도록 부하 분산 솔루션을 구성합니다.
CAS 자체는 부하 분산이 수행되고 있는지를 알 수 없습니다.
또한 New-ClientAccessArray cmdlet을 사용하여 CAS 배열 개체를 만든 후 또는 Get-ClientAccessArray cmdlet을 사용하여 기존 CAS 배열 개체를 확인한 후에도 혼란을 느낄 수 있습니다.
예를 보여 드리기 위해 랩에서 이름이 CASArray-A이고 FQDN이 outlook.lab.local인 새 CAS 배열 개체를 Site-A라는 Active Directory 사이트에 만들어 보겠습니다.
그림 1: 클라이언트 액세스 배열 만들기
먼저, FQDN 및 Name 필드가 일치하지 않음을 확인할 수 있습니다. Name은 표시 이름으로 사용자가 CAS 배열 개체의 용도를 확인할 수 있도록 지정할 수 있습니다. FQDN은 DNS에서 만들어야 하는 레코드로, 이 레코드를 만들지 않으면 클라이언트가 해당 개체를 연결 대상 IP 주소로 확인할 수 없습니다. Active Directory 사이트당 CAS 배열 개체는 하나만 포함될 수 있다는 사실은 다들 알고 계시죠?
그러면 CAS를 만든 직후 Members 속성이 두 개의 CAS로 즉시 채워지는 이유는 무엇일까요? 앞에서 이 시점에는 부하 분산이 수행되지 않는다고 말씀드렸는데 말이죠.
솔직히 말씀드리자면 Members 속성에는 약간의 오류가 있습니다. CAS 배열 개체를 만드는 단계를 확인하지 않으셨다면 이 단계로 작업이 완료되었다고 생각하실 수도 있을 것입니다. CAS 배열 개체를 만들면 배열에 CAS 두 개가 자동으로 연결되니까요. 그래서 작업을 완료하고 다른 내용(영문일 수 있음)을 확인하실 수도 있을 텐데요. 아직은 작업이 완료된 것이 아닙니다.
위에서 언급한 것처럼, CAS 배열 개체를 Site-A Active Directory 사이트에 연결했기 때문에 cmdlet은 단순히 Site-A에 있는 것으로 등록된 모든 클라이언트 액세스 서버를 찾은 다음 Members 열에 나열합니다. 저는 고객들에게 이 열을 Potential Members 열이라고 말씀드리고, 제 동료인 Kamal Abburi(Microsoft PFE)는 이 열을 Site CAS Members 열이라고 합니다. 이러한 클라이언트 액세스 서버는 모두 같은 Active Directory 사이트에 있으므로 부하 분산 솔루션의 노드로 추가할 수 있습니다. 그러나 부하 분산 장치를 구성할 때까지는 부하 분산이 수행되지 않습니다.
그러면 cmdlet은 CAS가 포함된 사이트를 어떻게 알 수 있을까요? AdsiEdit.msc를 실행하여 Active Directory의 Configuration 파티션을 확인해 보겠습니다.
그림 2: 서버가 있는 Active Directory 사이트가 포함된 Exchange 2010 서버의 msExchServerSite 특성
각 Exchange 서버에는 서버가 현재 있는 Active Directory 사이트가 포함된 msExchServerSite 특성이 있습니다. 모르시는 분들을 위해 다시 말씀드리자면, Exchange 서버를 새 사이트로 이동하는 경우 이 특성은 동적으로 업데이트되므로 Microsoft Exchange Active Directory 토폴로지 서비스가 실행되어 몇 가지 항목을 업데이트합니다. 그러나 AutoDiscoverSiteScope 특성(Get/Set-ClientAccessServer의 일부분)은 동적으로 업데이트되지 않으며, 이 문제가 해결될 때까지는 사이트, 서버 및 클라이언트 레이아웃에 따라 잘못된 자동 검색 결과가 제공될 수도 있습니다.
2. CAS 배열 개체는 OWA, ECP, EWS, 자동 검색, IMAP, SMTP 또는 POP 서비스를 제공하지 않습니다.
앞서 언급했던 CAS 배열 개체가 실제로 수행하는 작업을 다시 한 번 말씀드리겠습니다. 이 개체는 Exchange 2010 사서함 데이터베이스의 RpcClientAccessServer 특성을 채우며, 이 특성은 RPC over TCP를 사용할 때 연결해야 하는 위치를 Outlook에 알리는 데 사용됩니다. 외부에서 Outlook 사용(HTTPS) 클라이언트의 경우 이 특성은 RPC-over-HTTP 프록시에서 나가는 트래픽이 사서함에 도달하기 위해 클라이언트 대신 연결해야 하는 위치를 나타냅니다.
그러면 RPC over TCP를 사용할 때 Outlook 클라이언트는 어떤 서비스에 연결을 시도할까요?
Outlook은 먼저 TCP/135의 CAS 배열 개체에 연결하여 RPC 끝점 매퍼와 통신함으로써 다음의 두 서비스가 수신 대기 중인 TCP 포트를 검색합니다.
- Microsoft Exchange RPC 클라이언트 액세스(MSExchangeRPC)
- Microsoft Exchange 주소록(MSExchangeAB)
그 외의 작업은 RPC over TCP 모드에서 수행되지 않습니다.
외부에서 Outlook 사용(RPC over HTTP) 클라이언트는 외부에서 Outlook 사용 외부 호스트 이름 또는 Outlook 프로필에 지정된 프록시 서버의 이름을 확인하여 CAS에서 TCP/443의 RPC-over-HTTP 프록시 구성 요소에 연결합니다.
관심이 있는 사용자들을 위해 간략하게 설명하자면, Outlook은 지정된 서버 이름에 /rpc/rpcproxy.dll(실제로 연결해야 하는 대상)을 자동으로 추가합니다. Outlook 2003에서와 같이 사용자에게 이 이름을 직접 입력하도록 하면 오류가 발생할 가능성이 많기 때문입니다.
그림 3: Outlook 2003에서 RPC 프록시 URL 지정
트래픽은 동적으로 할당되지 않고 하드 코드되는 TCP 포트(TCP 6001, TCP 6002 및 TCP 6004)의 목록을 사용하여 RPC-over-HTTP 프록시에서 해당하는 MAPI/RPC 끝점으로 라우팅됩니다. 외부에서 Outlook 사용 외부 호스트 이름은 CAS 배열 개체와 같은 FQDN이 아닙니다. 이는 의도적인 설정이며, 여기에 대해서는 이후에 설명하겠습니다.
클라이언트는 HTTPS를 사용하여 자동 검색, OAB 다운로드, EWS, POP, IMAP 등의 서비스에 연결하기도 하지만, 이러한 서비스는 가상 디렉터리 URL이나 AutoDiscoverServiceInternalUri 값과 같은 전혀 다른 방법으로 정의됩니다. 이러한 추가 서비스는 RPC를 사용하지 않으므로 CAS 배열 개체에 의해 제공되지 않습니다(RPC가 서비스의 연결 대상 서버와 같을 수는 있음). CAS 배열 개체의 FQDN이 다른 서비스의 URL과 같은 VIP를 공유할 수는 있지만, 분할 DNS를 사용하는 경우에는 CAS 배열 개체의 FQDN이 다른 서비스의 URL과 같지 않도록 지정하는 것이 좋습니다. 이 권장 사항에 대해서도 이후에 자세히 설명하겠습니다.
3. CAS 배열 개체의 FQDN은 SSL 인증서 이름 목록에 포함되지 않아도 됩니다.
이 항목은 보통 바로 앞에서 설명한 항목으로 인해 확산된 매우 일반적인 오해입니다. 이 문서에서 지칭하는 'SSL 인증서'는 SSL로 보호되는 HTTP 세션을 설정하는 등의 작업을 수행할 때만 사용됩니다. RPC over TCP는 HTTP 세션이 아니므로 SSL로 보호되지 않으며, 따라서 CAS 배열 개체의 FQDN이 SSL 인증서의 제목 이름 목록에 포함되지 않아도 됩니다. 아래에서 이 점에 대해 보다 자세히 설명하겠습니다.
다음 그림에는 Exchange 2010 CAS 배열 개체에 연결된 MAPI/RCP 모드의 Outlook 2010이 나와 있습니다.
그림 4: Exchange 2010 CAS에 대한 Outlook 2010의 RPC over TCP 연결
그림에 나와 있는 것처럼 디렉터리 연결 하나와 메일 연결 두 개가 설정되어 있습니다. netstat 출력(스크린샷 위쪽에 겹쳐져 표시됨)을 보면 컴퓨터가 CAS 배열 개체에 대한 끝점 매퍼 연결(TCP 135) 하나와, TCP 59531 및 TCP 59532(각각 이 랩의 MSExchangRPC 및 MSExchangeAB 서비스에 대해 정적으로 할당된 TCP 포트를 나타냄)에 대한 연결을 설정했음을 확인할 수 있습니다.
서버 쪽에서는 netstat –n –b 명령을 사용하여 서비스가 수신 대기 중임을 확인할 수 있습니다.
그림 5: RPC over TCP를 사용할 때 Outlook이 연결해야 하는 서비스
예상대로 HTTP를 통해 TCP 443에 연결하는 서비스는 없음을 확인할 수 있습니다. 따라서 SSL 인증서에 CAS 배열 개체 FQDN이 없어도 됩니다.
아래와 같이 Outlook이 HTTPS 모드일 때 연결을 표시하는 방식으로 인해 SSL 인증서에 CAS 배열 FQDN이 필요하다고 오해할 수도 있는데요.
그림 6: 외부에서 Outlook 사용 연결
위 그림의 경우에는 스크린샷을 만들 때 Outlook 2010이 메일 연결 두 개와 공용 폴더 연결 하나를 설정했으며 HTTPS를 사용합니다. Outlook 내에서는 outlook.lab.local 및 E2K10-MLT-01.lab.local에 연결되어 있는 것처럼 보이는데요. 그러나 다시 netstat를 사용해 보면 실제로는 TCP/443(HTTPS)에서 webmail.lab.local에 있는 RPC-over-HTTP 프록시에 연결되어 있음을 확인할 수 있습니다. Outlook은 항상 자체적으로 또는 RPC-over-HTTP 프록시를 통해 데이터를 가져올 목적으로 최종 연결되는 서버를 표시합니다. netstat를 통해 연결이 3개가 아닌 6개가 표시되는 이유는 HTTP가 반이중 프로토콜이므로 Outlook 내에서 표시되는 각 연결에 대해 RPC_DATA_IN 및 RPC_DATA_OUT 채널을 설정하기 때문입니다.
Outlook 2007과 2010에서는 RPC 세션이 기본적으로 암호화되기 때문에 인증서의 이름이 있어야 한다고 생각하는 분도 계실 텐데요. 아래에 나와 있는 것처럼 암호화 설정은 RPC 암호화를 사용하며, SSL은 사용하지 않습니다. 즉, 통신은 HTTPS가 아닌 RPC를 통해 진행됩니다.
그림 7: RPC over TCP를 사용하여 연결할 때 Outlook에서 사용하는 RPC 암호화
간단하죠? CAS 배열 개체가 CA(인증 기관)에 대해 인증을 할 때 인증이 필요하며 와일드카드 인증서를 사용할 수 있다고 생각하셨다고요? CAS 배열 개체에는 인증서가 필요하지 않습니다. 물론 이미 말씀드린 것처럼, CAS 배열 개체에 사용하는 FQDN이 다른 서비스 FQDN과 달라야 합니다. 이유는 앞에서 설명해 드렸습니다.
이 문서의 1부를 통해 CAS 배열 개체에 대한 몇 가지 일반적인 오해를 바로잡으셨기를 바라며, 이후 CAS 배열 개체와 관련된 나머지 세 가지 오해에 대해 다룰 2부의 내용도 확인해 주시기 바랍니다.
Brian Day
수석 현장 엔지니어(메시징)
이 문서는 번역된 블로그 게시물입니다. 원본 문서는 Demystifying the CAS Array Object - Part 1을 참조하십시오.