Share via

CAS 배열 개체에 관한 오해 바로잡기 - 2부

  • Article

최초 문서 게시일: 2012년 3월 29일 목요일

저희 블로그를 다시 찾아 주셔서 감사합니다. CAS 배열 개체에 관한 오해 바로잡기 - 1부에서는 Exchange Server 2010의 CAS 배열 개체와 관련된 오해를 바로잡기 위해 아래의 세 가지 항목에 대해 다루었습니다.

  1. CAS 배열 개체는 트래픽을 부하 분산하지 않습니다.
  2. CAS 배열 개체는 OWA, ECP, EWS, 자동 검색, IMAP, SMTP 또는 POP 서비스를 제공하지 않습니다.
  3. CAS 배열 개체는 SSL 인증서에 포함되지 않아도 됩니다.

이번 2부에서는 아래의 세 가지 항목에 대해 다룹니다. 이러한 오해를 바로잡고 나면 CAS 배열 개체를 통해 기존 배포를 수정하거나 향후 배포를 보다 전략적으로 계획할 수 있을 것입니다.

  1. 외부 클라이언트에서 DNS를 통해 CAS 배열 개체를 확인할 수 없어야 합니다.
  2. Exchange Server 2010 사서함 데이터베이스를 만들고 사서함을 데이터베이스로 이동한 후 CAS 배열 개체를 구성하거나 변경해서는 안 됩니다.
  3. CAS가 하나뿐이거나 다중 역할 서버가 있는 경우에도 CAS 배열 개체를 구성해야 합니다.

4. 외부 클라이언트에서 DNS를 통해 CAS 배열 개체를 확인할 수 없어야 합니다.

1부에서 최소한 두 번은 언급한 것처럼, CAS 배열 개체 FQDN은 OWA, ECP, EWS, EAS, 자동 검색 또는 외부에서 Outlook 사용 외부 호스트 이름 등의 다른 서비스에 사용되는 FQDN과 같아서는 안 됩니다.

이처럼 FQDN이 달라야 하는 가장 큰 이유는, 외부에서 Outlook 사용 클라이언트의 경우 먼저 DNS를 통해 CAS 배열 개체 FQDN을 확인하여 RPC over TCP 연결을 시도할지 HTTPS를 바로 사용할지를 확인하기 때문입니다. 인터넷이나 인트라넷에서 RPC over TCP 연결을 직접 허용하는 것은 좋지 않으며, 허용하는 경우 Exchange Risk and Health Assessment Program(영문일 수 있음) 보고서에 위험 플래그가 표시됩니다. 클라이언트가 CAS 배열 개체 FQDN을 확인할 수 있어서 RPC over TCP를 통해 먼저 연결을 시도하지 않는 경우에는 클라이언트가 외부에서 Outlook 사용 프록시 URL에 대한 HTTPS 연결을 대신 시도할 때까지 시간이 크게 지연됩니다. 이 지연을 최종 사용자가 성능 저하 및/또는 서비스 중단으로 오해하는 경우에는 지원 센터 통화 수가 증가할 수 있습니다.

이러한 상황을 방지하려면 분할 DNS를 통해 내부 CAS 배열 개체 FQDN은 내부 DNS에 고유한 outlook.corp.contoso.com과 같은 항목으로 지정하고, RPC over TCP를 사용하지 않는 기타 서비스 URL에는 mail.contoso.com 등의 항목을 내부 및 외부에서 사용하면 됩니다.

분할 DNS를 사용할 수 없는 경우에는 contoso.com과 같은 동일 정방향 조회 영역에 대한 요청을 처리하는 내부 및 외부 DNS 서버 집합이 있는 것입니다. 이 두 DNS 인프라는 서로 완전히 격리됩니다. 영역 전송도 수행되지 않으며 각 영역이 상대 영역을 DNS 전달자로 사용하지도 않습니다. 이 구성에서는 내부 사용자가 내부 DNS 인프라를 사용하여 호스트 mail.contoso.com을 부하 분산 장치 VIP로 연결되는 내부 IP 주소(예: 192.168.1.10)로 확인할 수 있으며, 외부 사용자는 mail.contoso.com을 경계 네트워크의 인터넷 연결 Forefront TMG/UAG 인프라를 가리킬 수 있는 공용 IP 주소로 확인할 수 있습니다. CAS 배열 개체 IP 주소와 RPC over TCP를 사용하지 않는 서비스 URL(OWA, ECP, EWS 등)의 IP 주소가 같은 부하 분산 장치 VIP인 경우가 많은데, 이들 IP 주소는 적절한 서비스 상태 검색을 위해 서로 다른 활성 상태 확인 기능을 사용할 수 있습니다.

DNS의 와일드카드 응답 제공 여부

존재하지 않는 호스트 이름에 대해 받은 쿼리에 대한 응답으로 와일드카드 레코드를 사용하는 외부 DNS 서버를 보유한 고객들이 많이 있습니다. 즉, SomeFunkyNameThatDoesNotExist.contoso.com에 대한 DNS 요청을 보내면 DNS 서버는 항상 회사 웹 사이트의 IP 주소를 반환합니다. 와일드카드 레코드는 인터넷 표준 관점에서 보면 유효합니다. 자세한 내용은 RFC 1034(영문일 수 있음)의 4.3.3항을 참조하십시오. -편집자

이러한 이유로, 외부에서 Outlook 사용 클라이언트는 항상 CAS 배열 개체 FQDN을 확인할 수 있으며 HTTPS로 전환하기 전에 RPC over TCP 연결을 먼저 시도합니다. 특정 정방향 조회 영역에 대해 와일드카드 응답을 사용하는 외부 DNS 서버에서 이와 비슷한 상황이 발생하는 경우에는 외부에서 Outlook 사용 프록시 URL에 대해 해당 정방향 조회 영역을 사용하지 않는 것이 좋습니다.

부하 분산 솔루션에 대해 적절한 서비스 상태 모니터를 반드시 구성해야 합니다. 최적의 서비스 모니터링 결과를 얻으려면 부하 분산 솔루션 공급업체에 문의하십시오. Exchange 2010 솔루션 테스트를 거친 부하 분산 장치 공급업체 목록과 각 업체의 관련 웹 페이지(Exchange 2010용)는 Exchange Server 2010 부하 분산 장치 배포(영문일 수 있음)를 확인하십시오. 여기에는 지원되는 모든 부하 분산 공급업체 목록이 포함되어 있지는 않으며, Microsoft와 솔루션 테스트 및 지원을 직접 진행한 공급업체가 나와 있습니다.

여기에 대한 예를 빠르게 살펴보려면 HTTPS 서비스 기반 FQDN이 TCP/443 응답에 대해 활성 상태 테스트를 수행하도록 합니다. 그러면 부하 분산 솔루션이 클라이언트 액세스 서버로의 새 클라이언트 트래픽 전송을 중지하며, TCP/443에서 클라이언트 액세스 서버가 응답하지 않습니다. CAS 배열 개체 RPC over TCP 서비스 FQDN의 경우 TCP/135와 TCP 클라이언트 액세스 서비스 및 주소록 서비스용으로 선택한 두 정적 TCP 포트(영문일 수 있음)의 RPC 끝점 매퍼에 대해 활성 상태 테스트를 수행할 수 있습니다. 특정 클라이언트 액세스 서버에서 이 세 포트 중 하나라도 응답하지 않으면 부하 분산 솔루션은 모든 포트가 다시 응답할 때까지 RPC over TCP에 대해 해당 포트로 새 클라이언트 트래픽을 전송하지 않습니다. 정적 TCP 포트를 구성하지 않는 경우에는 Exchange에서 시작 시 각 서비스에 대해 동적 TCP 포트를 선택하므로 일부 부하 분산 솔루션의 경우 활성 상태 테스트가 불가능해지거나 더욱 어려워집니다.

5. Exchange Server 2010 데이터베이스를 만든 후에는 CAS 배열 개체를 구성해서는 안 됩니다.

대부분의 경우에는 사서함 서버를 설치한 후 바로 사서함 데이터베이스를 만들며, 시간이 허락되면 Jetstress(영문일 수 있음)를 사용하여 저장소 솔루션 유효성 검사 테스트를 시작합니다. 그러나 이후에 문제가 발생하지 않도록 하려면 각 작업 간에 여유를 두어야 합니다. 사서함 서버는 대부분의 경우 가장 중요한 서버 역할로 간주되지만, 클라이언트 액세스 서버를 통해 연결할 수 없다면 아무런 쓸모가 없습니다.

CAS 배열 개체가 없는 상태에서 사서함 데이터베이스 만들기를 시작하면 같은 Active Directory 사이트에서 각 데이터베이스의 RpcClientAccessServer 특성에 임의의 클라이언트 액세스 서버가 표시됩니다.

즉, 특성이 아래와 같이 표시되어야 하는데(CAS 배열 개체의 FQDN 사용)


그림 1: CAS 배열 개체를 만든 경우 사서함 데이터베이스의 RpcClientAccessServer 속성에 CAS 배열 개체의 FQDN이 채워짐

아래와 같이 표시됩니다.


그림 2: CAS 배열 개체를 만들지 않은 경우 사서함 데이터베이스의 RpcClientAccessServer 속성에 클라이언트 액세스 서버 FQDN이 채워짐

클라이언트 프로필은 다음과 같이 표시됩니다.


그림 3: CAS 배열 개체를 만들지 않은 경우 Outlook 클라이언트는 클라이언트 액세스 서버의 FQDN을 사용하여 구성됨

그리고 클라이언트는 다음과 같이 표시됩니다.


그림 4: 클라이언트가 클라이언트 액세스 서버의 FQDN에 연결함

얼핏 보기에는 아무런 문제가 없고 모든 항목이 정상적으로 작동하는 것 같지만, 나중에 문제가 발생하게 됩니다. 즉, 이 구성을 적용한 상태로 사서함을 Exchange Server 2010으로 이동하면 Outlook에서 사용자 프로필의 "서버(Server)" 필드에 CAS 이름을 사용합니다. 이 경우 클라이언트 액세스 서버가 사용할 수 없는 상태가 되거나 나중에 해제되어 이름이 다른 서버로 교체되는 경우를 제외하면 이동은 정상적으로 진행됩니다. 그러나 클라이언트 액세스 서버의 부하 분산된 풀을 사용하면 문제를 근본적으로 방지할 수 있습니다.

문제가 발생하면 CAS 배열 개체를 만들고 데이터베이스에서 RpcClientAccessServer를 수정하면 된다고 생각하실 수도 있을 텐데요. 이 방법은 문제 발생 이후 Exchange 2010으로 이동하는 사서함에 대해서만 작동합니다. 즉, 기존 Outlook 프로필이 CAS 배열 개체가 아닌 CAS 이름을 가리키도록 구성된 사용자의 경우에는 프로필이 계속 CAS 이름에 연결되며 CAS 배열 개체 FQDN을 사용하도록 업데이트되지 않습니다.

프로필이 자체적으로 업데이트되지 않는 이유는 클라이언트가 CAS로부터 ecWrongServer 응답을 받지 않기 때문입니다. 클라이언트가 이 응답을 받지 않는 이유는, 모든 CAS가 모든 사서함 데이터베이스에 대해 RPC over TCP를 통한 유효한 연결 지점이 되기 때문입니다. 따라서 클라이언트는 다시 구성하지 않아도 데이터 센터 전환/장애 조치(failover) 이벤트에서 계속 작동하며, 관리자는 정상적으로 작동하는 CAS 풀을 가리키도록 CAS 배열 개체 DNS 레코드를 전환하기만 하면 됩니다. 현재 사서함 프로필을 수정하는 방법은 Outlook 내에서 수동 프로필 복구를 수행하는 것뿐이며, 이렇게 하려면 GPO를 통해 Office PRF 파일을 게시하거나(도메인에 가입되지 않은 컴퓨터의 경우에는 작동하지 않음) 사용자 프로필에 이름이 지정된 CAS 서버를 해제하여 끝점을 더 이상 사용할 수 없도록 해야 합니다. 이 마지막 옵션의 경우 Outlook 2007 또는 Outlook 2010에서 테스트한 결과 자동 검색에 의한 전체 프로필 복구가 트리거되었습니다. Outlook 2003의 경우에는 PRF 파일 또는 프로필 복구를 통해서만 복구가 가능합니다. 이 문서 작성 시점에서 자동 검색은 외부에서 Outlook 사용 구성을 업데이트하고 다른 기능(예: OOF 관리, 약속 있음/없음, 받은 편지함 규칙 관리)용으로 EWS URL을 검색하는 일반 자동 검색 프로세스의 일부분으로 프로필을 새 서버 이름으로 업데이트하지 않습니다.

이를 통해 유추할 수 있는 또 다른 사실은, Boston-CASArray라는 CAS 배열 개체를 사용하는 AD Site-A의 데이터베이스에서 Redmond-CASArray라는 CAS 배열 개체를 사용하는 AD Site-B의 데이터베이스로 사서함을 이동하는 경우 프로필이 업데이트되지 않으며 서버 이름 필드는 Boston-CASArray FQDN으로 유지된다는 것입니다. 사용자가 솔루션의 수명 주기 동안 업무 변경으로 인해 다른 사이트로 마이그레이션하거나 다른 사이트로의 대량 내부 사서함 이동을 수행하는 경우에는 이 점을 염두에 두어야 합니다. CAS 배열 개체를 만들기 전에 Exchange 2010 데이터베이스를 만드는 경우에는 나중에 사서함을 데이터베이스로 이동하기 전에 CAS 배열 개체를 사용하도록 데이터베이스의 특성을 수정해야 합니다.

6. CAS가 하나뿐이거나 다중 역할 서버가 있는 경우에도 CAS 배열 개체를 구성해야 합니다.

이전 항목에서 설명했던 내용을 다시 언급하자면, 클라이언트는 나중에 CAS 배열 개체를 추가하는 경우 해당 개체를 사용하도록 자체적으로 업데이트되지 않습니다. 그러면 CAS가 하나뿐인 경우는 문제가 되지 않을까요? 해당 시점에는 문제가 되지 않을 수도 있지만, 나중에 작업 주기를 줄이고 혼란을 방지하기 위해 몇 가지 조치를 취하는 것이 좋습니다. 예를 들어 지금부터 1년 후에 해당 CAS를 교체해야 하는 경우 클라이언트 프로필이 모두 CAS 이름을 가리키지 않으면 클라이언트 작동을 중지하거나 수동 작업을 수행하지 않고는 프로필을 간편하게 전환하기가 어렵습니다. 즉, 새 CAS를 추가한 후 앞서 언급한 방법 중 하나로 프로필을 복구하거나 기존 CAS를 해지하고 같은 호스트 이름의 새 CAS를 도입해야 하는데 이 경우 어느 정도의 가동 중지 시간이 필요합니다. 개인적으로 이 중에는 적절한 옵션이 없다고 생각됩니다.

나중에 업무 요구 사항이 변경되어 클라이언트 액세스의 고가용성을 유지해야 하는 경우에는 두 번째 CAS 및 부하 분산 솔루션을 추가해야 할 것입니다. 또한 앞서 설명한 방법 중 하나를 통해 모든 사용자의 프로필을 복구해야 하므로 역시 적절한 옵션이 아닙니다.

제가 제안하고자 하는 방법은 처음부터 CAS 배열 개체를 만드는 것입니다. 부하 분산 장치가 없고 CAS가 하나뿐인 경우에도 작업은 간단합니다. 일반적인 방식으로 CAS 배열 개체를 구성하면 됩니다. 즉, 이름과 AD 사이트 및 FQDN을 지정한 다음 DNS 'A' 레코드가 해당 시점에 존재하는 유일한 CAS 또는 다중 역할 서버인 IP를 가리키도록 하면 됩니다. 그러면 나중에 문제가 발생하지 않으며, 단일 CAS 또는 다중 역할 서버를 교체해야 하는 경우에도 새 서버를 구축한 다음 DNS 레코드 IP 주소만 변경하면 모든 항목이 중단 없이 계속 작동합니다. 나중에 고가용성을 추가하려는 경우에도 부하 분산 솔루션을 작동시킨 후 해당 솔루션의 VIP를 가리키도록 CAS 배열 개체 DNS 레코드 IP 주소를 변경하면 되므로 매우 간단합니다.

이 문서를 통해 CAS 배열 개체와 관련한 몇 가지 오해를 확인하고 바로잡으셨나요? 이후 효율적인 Exchange Server 2010 마이그레이션을 수행하는 데 있어 이 문서의 내용이 모든 사용자에게 도움이 되었으면 합니다.

Brian Day
수석 현장 엔지니어(메시징)

이 문서는 번역된 블로그 게시물입니다. 원본 문서는 Demystifying the CAS Array Object - Part 2를 참조하십시오.