RPC 클라이언트 액세스 교차 사이트 연결 변경 내용
최초 문서 게시일: 2012년 5월 30일 수요일
약 2년 전인 2010년의 북미 TechEd에서 고가용성 디자인 고려 사항(영문일 수 있음)이라는 세션을 진행한 적이 있습니다. 이 세션에서는 사서함 이동 및 교차 사이트 데이터베이스 *over 이벤트 이후 MAPI 연결을 수행하는 방법이 어떻게 변경되고 있는지를 설명했었는데요. 아쉽게도 그 프레젠테이션 이후에 도입해야 하는 변경이 복잡해지고 서비스 팩 1 출시 전에 테스트할 시간이 부족하여 해당 기능은 제외되었습니다. 그리고 이 기능과 관련한 작업을 우선적으로 처리하기 위해 노력했지만, 서비스 팩 2에서도 해당 변경 내용을 포함할 수가 없었습니다.
그러나 일단 포함되었던 기능은 완전히 제외할 수 없기 때문에 변경된 코드의 일부분은 실제로 SP1에 남아 있었습니다. 예를 들어 Set-DatabaseAvailabilityGroup cmdlet에는 AllowCrossSiteRPCClientAccess라는 속성이 있습니다. 이 부울 속성을 원하는 콘텐츠로 토글할 수는 있지만, 그래도 제품의 동작에는 아무런 영향을 주지 않습니다.
교차 사이트 RPC 클라이언트 액세스 연결 동작(RTM, SP1, SP2~SP2-RU2)
본론으로 들어가기 전에 일단 몇 가지 기본적인 사항을 잠시 짚고 넘어가겠습니다.
Exchange 2010에서는 클라이언트가 사서함 관련 데이터에 연결 및 액세스하는 방식이 크게 변경되었습니다. 이전 버전과는 달리, 클라이언트는 더 이상 사서함 데이터에 액세스하기 위해 사서함 서버 역할의 정보 저장소에 직접 연결하지 않습니다. 대신 클라이언트는 연결하는 사용자를 대신하여 사서함 서버에서 MAPI/RPC를 사용해 CAS(클라이언트 액세스 서버) 역할의 서비스 집합 및 CAS 역할 액세스 사서함 데이터 내의 서비스에 연결합니다. 이러한 방식의 연결은 추상화 계층으로 생각할 수 있습니다.
기본적으로는 한 가지 간단한 변경이 적용되어, 모든 사서함 관련 MAPI 연결은 클라이언트 액세스 서버 역할의 RPC 클라이언트 액세스 서비스를 통해 이동하게 되었습니다. 이러한 추상화 계층을 원활하게 사용하기 위해, 데이터베이스 개체는 더 이상 사사함 서버의 하위 개체가 아니도록 변경되었습니다. 사서함 데이터베이스에는 RPCClientAccessServer라는 새 속성이 추가되었는데, 이 속성은 특정 데이터베이스에 액세스하는 데 사용해야 하는 legacyExchangeDN을 정의하며 해당 값으로 FQDN을 사용합니다. CAS 장애 시 고가용성 및 내결함성을 유지하려면 이 값은 부하 분산된 CAS 배열의 FQDN이어야 합니다. 이 부하 분산된 FQDN을 RPC 클라이언트 액세스 서버 배열이라고 합니다.
자세한 내용은 Brian Day의 CAS 배열 개체 소개 게시물 1부 및 2부를 참조하십시오.
일반적인 Outlook 환경
모든 Outlook 버전은 단일 데이터 센터 또는 단일 Active Directory 사이트 시나리오에서 일관된 방식으로 동작합니다. Outlook 프로필의 RPC 끝점은 RPC 클라이언트 액세스 서버 배열이거나, 배열을 만들어야 하는데 만들지 않은 경우에는 특정 CAS입니다. 배열을 만들어야 하는 이유는 Brian의 게시물을 확인해 보시기 바랍니다. DAG에서 데이터베이스 오류, 서버 오류 등의 오류가 발생할 때 RPC 끝점은 변경되지 않기 때문에 Outlook은 동일한 RPC 클라이언트 액세스 서버 배열에 계속 연결합니다. CAS 배열 내에서 CAS 오류, 부하 분산 장치 오류 등의 오류가 발생할 때도 RPC 끝점은 변경되지 않으므로 Outlook은 RPC 클라이언트 액세스 서버 배열에 대한 연결을 계속 시도합니다.
해당 지침을 따르는 경우 모든 Outlook 버전은 데이터 센터 전환 시나리오에서도 일관되게 동작합니다. 그 이유는, 데이터 센터 전환 시에는 기본 데이터 센터 RPC 클라이언트 액세스 서버 배열 DNS 항목의 IP 주소를 대기 데이터 센터의 RPC 클라이언트 액세스 서버 배열을 가리키도록 변경하기 때문입니다. 자동 검색은 계속해서 기본 데이터 센터 RPC 클라이언트 액세스 서버 배열을 RPC 끝점으로 제공합니다. 기존 Outlook 클라이언트를 다시 구성할 필요는 없습니다. 클라이언트의 DNS 캐시가 업데이트되면 클라이언트는 단순히 대기 데이터 센터에 있는 끝점에 연결합니다. 이러한 방식이 작동하는 이유를 완전하게 이해하려면, 클라이언트와 CAS는 모두 CAS가 있는 사이트를 고려하지 않으며 연결이 가능하고 클라이언트가 연결되는 CAS에서 사서함에 대한 액세스를 제공할 수 있으면 정상적으로 기능한다는 점을 파악해야 합니다.
교차 사이트 데이터베이스 *over 동작
이 시나리오를 이해하려면, 다중 사이트 DAG를 구성할 때는 지정된 데이터베이스에 대한 RPCClientAccessServer 속성이 일반적으로 RPC 클라이언트 액세스 서버 배열(활성화 기본 설정 번호가 가장 낮은 사서함 데이터베이스 복사본과 같은 AD 사이트에 있는 배열)에 연결된다는 점을 기억해야 합니다. 예를 들면 다음과 같습니다.
그림 1: 두 Active Directory 사이트 간에 확장된 데이터베이스 가용성 그룹
대기 데이터 센터에서 데이터베이스 복사본이 활성화되면 사용자는 활성화 기본 설정 값이 가장 낮은 사서함 데이터베이스가 있는 AD 사이트의 RPC 클라이언트 액세스 서버 배열을 연결 끝점으로 계속 사용합니다.
그림 2: 대기 Active Directory 사이트에서 MDB1 데이터베이스가 활성화됨
원본 RPC 클라이언트 액세스 서버 배열에서 RPC 클라이언트 액세스 로그를 검토하면 다음과 같은 내용을 확인할 수 있습니다.
2012-05-06T15:44:29.001Z,67,112,/o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SFPDLT)/cn=Recipients/cn=userded,,OUTLOOK.EXE,14.0.6025.1000,Classic,,,ncacn_ip_tcp,,OwnerLogon,0,00:00:00.0468822,"Logon: Owner, /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded in database mdb1 last mounted on MBX-C.contoso.com at 5/6/2012 3:43:23 PM, currently Mounted; LogonId: 5",
활성화 기본 설정 값이 가장 낮은 사서함 데이터베이스가 있는 AD 사이트의 RPC 클라이언트 액세스 서버 배열에 사용자가 액세스할 수 없게 되면 Outlook 클라이언트가 반대쪽 데이터 센터에 있는 사서함에 연결할 수 없습니다. 즉, 데이터 센터 중단 이벤트가 발생하여 데이터 센터 전환 프로세스를 수행해야 합니다.
Outlook은 RPCClientAccessServer 속성 값에 관계없이 구성된 RPC 끝점(연결 가능한 경우)에 항상 연결한다는 점을 기억하면 이 동작을 보다 간단하게 확인할 수 있습니다.
시스템에서 RPCClientAccessServer 값을 자동으로 변경하는지 여부
시스템이 데이터베이스에 대해 RPCClientAccessServer 값을 변경하는 경우는, 관리자가 활성화된 데이터베이스 복사본의 ActivationPreference 번호를 변경하여 그림 3에 나와 있는 것처럼 해당 복사본의 값이 가장 작아지는 경우(해당 복사본이 기본 설정 복사본이 됨)뿐입니다.
그림 3: 대기 Active Directory 사이트에서 MDB1 데이터베이스가 활성화되고 RPCClientAccessServer 속성이 변경됨
그러나 기존 Outlook 프로필을 포함하는 Outlook 클라이언트는 자동 검색에서 변경 내용을 탐지하더라도 새 RPC 끝점이 아닌 이전 RPC 끝점을 계속 사용합니다. 이전 RPC 끝점이 클라이언트에 ecWrongServer 응답을 반환하지 않기 때문입니다. RPC 끝점은 연결을 수락하며, 따라서 Outlook은 작동하는 연결이 있기 때문에 자동 검색의 응답을 무시합니다. 이전 RPC 끝점에 액세스할 수 없게 되면 Outlook 2007/2010은 해당 설정을 업데이트합니다. 반면 Outlook 2003은 자동 검색을 사용하지 않으므로 설정을 업데이트하지 않습니다. 언제든지 프로필 복구를 강제 수행하여 Outlook이 새 RPC 끝점을 사용하도록 강제 지정할 수 있습니다.
관리자가 교차 사이트 데이터베이스 *over 이벤트 이후 RPCClientAccessServer 값을 수동으로 업데이트하는 경우
그림 2로 돌아가서, MBX-C의 사서함 데이터베이스 복사본(해당 ActivationPreference가 1보다 큼)이 활성화된 후 관리자가 MDB1에 대해 RPCClientAccessServer 값이 cas-sec.contoso.com을 가리키도록 수동으로 업데이트하는 경우에도 기존 프로필을 포함하는 Outlook 클라이언트는 이전 RPC 끝점을 사용할 수 있는 한 새 RPC 끝점이 아닌 이전 RPC 끝점을 계속 사용합니다. 이 경우에도 역시 프로필 복구를 통해 문제를 해결할 수 있습니다. RPCClientAccessServer 값이 변경된 후에 만들어진 Outlook 프로필은 새 RPC 끝점을 사용합니다.
Active Directory 사이트 간에 사서함 이동
Exchange 2010 이전 버전에서는 서버 간에 사서함을 이동하면 사서함이 있는 데이터베이스를 호스팅하는 사서함 서버 또는 클러스터된 사서함 서버 인스턴스를 가리키도록 Outlook RPC 끝점이 업데이트됩니다. 사서함 이동이 완료되고 나면 Outlook 클라이언트 사용자에게는 "사용자가 Outlook을 끝내고 다시 시작하도록 Microsoft Exchange 관리자가 설정을 변경했습니다."라는 메시지가 포함된 대화 상자가 표시됩니다. Outlook을 다시 시작하고 나면 클라이언트가 새 RPC 끝점에 연결됩니다.
Exchange 2010에서는 AD 사이트 간에 사서함을 이동할 때 사용자에게 이 대화 상자가 표시되지 않습니다. 또한 사서함을 이동한 후 사서함이 있는 AD 사이트의 사서함 데이터베이스에 연결된 RPC 클라이언트 액세스 서버 배열을 반영하도록 RPC 끝점이 업데이트되지도 않습니다. 이전 RPC 끝점이 클라이언트에 ecWrongServer 응답을 반환하지 않기 때문입니다. RPC 끝점은 연결을 수락하며, 따라서 Outlook은 작동하는 연결이 있기 때문에 자동 검색의 응답을 무시합니다. 이전 RPC 끝점에 액세스할 수 없게 되면 Outlook은 해당 설정을 업데이트합니다. 반면 Outlook 2003은 자동 검색을 사용하지 않으므로 설정을 업데이트하지 않습니다. 언제든지 프로필 복구를 강제 수행하여 Outlook이 새 RPC 끝점을 사용하도록 강제 지정할 수 있습니다.
이제 기본적인 개념은 어느 정도 이해가 되셨으리라 생각합니다.
SP2 RU3 이후의 변경 내용
저희 팀에서는 이 문제를 해결하기 위해 지속적으로 노력해 왔습니다. 저는 RPC 클라이언트 액세스 개발 팀 및 Exchange 서비스 팀과 협력하여 제품에 반드시 필요한 두 가지 변경 내용을 적용했습니다. 즉 사서함을 단순히 다른 AD 사이트의 데이터베이스 간에 이동할 때와, 교차 사이트 *over로 인해 Outlook이 현재 활성화되어 있는 데이터베이스의 위치에 최적이 아닌 CAS를 사용할 때 Outlook 프로필을 수정했습니다.
사서함 이동
기본적으로 SP2 RU3을 설치한 후 AD 사이트 간에 사서함을 이동하면 모든 Outlook 버전에서 Outlook을 다시 시작하라는 메시지가 표시되며 Outlook 프로필의 RPC 끝점이 업데이트됩니다.
원본 RPC 클라이언트 액세스 배열에서 RPC 클라이언트 액세스 로그를 검토하면 다음과 같은 내용을 확인할 수 있습니다.
2012-05-06T14:43:03.875Z,37,1,/o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded,,OUTLOOK.EXE,14.0.6025.1000,Classic,,,ncacn_ip_tcp,,OwnerLogon,1144 (rop::WrongServer),00:00:00.0156267,"Logon: Owner, /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded in database mdb2 last mounted on MBX-C.contoso.com at 5/5/2012 9:44:05 PM, currently Mounted; Redirected: this server is not in a preferred site for the database, suggested new server: /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=cas-sec.contoso.com",RopHandler: Logon:
여기서 ROP(RPC 작업)는 WrongServer(ecWrongServer라고도 함)입니다. 이 항목은 Outlook 클라이언트가 프로필 검색을 수행하고 디렉터리 내에서 발견되는 새 정보를 기준으로 프로필을 업데이트하도록 강제 지정합니다. 따라서 프로필이 업데이트되며, 클라이언트는 다시 시작되고 나면 새 RPC 끝점에 대한 연결을 설정합니다.
그러면 위에서 언급한 "사용자가 Outlook을 끝내고 다시 시작하도록 Microsoft Exchange 관리자가 설정을 변경했습니다."라는 대화 상자가 표시되도록 하는 또 다른 조건은 무엇일까요?
- New-MoveRequest에 대해 DoNotPreserveMailboxSignature속성을 지정하는 경우
- 원본 사서함 데이터베이스와 대상 사서함 데이터베이스의 공용 폴더 계층 구조 저장소가 다른 경우
- 사서함을 레거시 버전 Exchange에서 Exchange 2010으로 이동하는 경우
교차 사이트 데이터베이스 *over 이벤트
교차 사이트 데이터베이스 *over 동작은 DAG 속성 AllowCrossSiteRPCClientAccess의 값에 따라 달라집니다. AllowCrossSiteRPCClientAccess 속성 값을 $true로 설정하면 이전 섹션에서 설명한 동작이 기본 동작으로 사용됩니다. 즉, 데이터베이스가 대기 데이터 센터에서 활성화되면 사용자는 활성화 기본 설정 값이 가장 낮은 사서함 데이터베이스가 있는 AD 사이트의 RPC 클라이언트 액세스 배열을 연결 끝점으로 계속 사용합니다.
AllowCrossSiteRPCClientAccess 속성 값을 $false로 설정하는 경우(이 속성의 기본값이 $false임) Outlook 프로필의 RPC 끝점은 데이터베이스가 활성 상태이며 탑재되어 있는 것과 같은 AD 사이트의 RPC 클라이언트 액세스 서버 배열로 업데이트됩니다. RPCClientAccessServer 속성은 기본 설정 사이트를 정의하므로 업데이트되지 않습니다.
그림 4: 대기 Active Directory 사이트에서 MDB1 데이터베이스가 활성화되고 Outlook 프로필이 자동으로 업데이트됨
원본 RPC 클라이언트 액세스 서버 배열에서 RPC 클라이언트 액세스 로그를 검토하면 다음과 같은 내용을 확인할 수 있습니다.
2012-05-06T15:12:42.958Z,47,7,/o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded,,OUTLOOK.EXE,14.0.6025.1000,Classic,,,ncacn_ip_tcp,,OwnerLogon,1144 (rop::WrongServer),00:00:00.0156262,"Logon: Owner, /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded in database mdb1 last mounted on MBX-C.contoso.com at 3/6/2012 2:59:30 PM, currently InTransitSameSite; Redirected: this server is not in a preferred site for the database, suggested new server: /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=cas-sec.contoso.com",RopHandler: Logon:
사서함 이동 시나리오와 마찬가지로, WrongServer ROP는 Outlook 클라이언트가 프로필 검색을 수행하고 디렉터리 내에서 발견되는 새 정보를 기준으로 프로필을 업데이트하도록 강제 지정합니다. 따라서 프로필이 업데이트되며, 클라이언트는 다시 시작되고 나면 새 RPC 끝점에 대한 연결을 설정합니다.
결론
지금까지 설명한 것처럼, SP2 RU3 이상을 설치하는 경우 AD 사이트 간에 이동되는 사서함의 프로필이 올바르게 업데이트됩니다. 또한 교차 사이트 데이터베이스 *-over 시나리오에서는 교차 사이트 RPC 연결을 허용할지 아니면 Outlook 클라이언트가 활성화 및 탑재된 데이터베이스와 같은 AD 사이트에 있는 RPC 클라이언트 액세스 서버 배열을 사용하도록 강제 지정할지(기본 동작)를 제어할 수 있습니다. 이상으로 이 게시물을 마치겠습니다.
Ross Smith IV
주임 프로그램 관리자
Exchange Customer Experience
이 문서는 번역된 블로그 게시물입니다. 원본 문서는 RPC Client Access Cross-Site Connectivity Changes를 참조하십시오.