이 글은 오래된 전에 작성된 글입니다. 따라서 최신 버전의 기술에 알맞지 않거나 오류를 유발할 수 있습니다.
저자는 이 글에 대한 질문을 받지 않을 것입니다. 하지만 이 글이 리뉴얼 되면 이 글에 대한 질문을 하거나
토론을 할 수도 있습니다.
이번 RPC 이야기는 RPC 작동을 테스트하기 위한 다양한 도구들을 소개하고자 합니다. Rpcdump, rpcping, dtcping, dtctester 등의 도구를 통해 RPC 가 실제로 작동하는지 여부를 테스트할 수 있습니다. 특히 dtcping 이나 dtctester는 DTC를 위한 전용 테스트 도구로서 COM+ 컴포넌트가 수행되는 어플리케이션 서버와 SQL Server가 수행되는 DB 서버 사이에 분산 트랜잭션이 수행되는가를 테스트하는 중요한 도구 입니다.
About RPC... (3)
지난 RPC 이야기 두 번째에서는 RPC가 사용하는 TCP/IP 포트를 설정하는 방법을 살펴보았다. 덤으로 방화벽을 통과하여 RPC가 수행될 수 있도록 방화벽을 설정하는 방법도 살펴보았다. 이번에는 RPC 포트 설정이나 방화벽 설정이 정말 잘 되었는가를 확인하는 방법들에 대해 살펴보도록 하겠다. 대표적인 도구가 rpcping.exe 이라는 유틸리티이다. 이외에도 잘 알려지지 않은 rpcdump.exe 유틸리티가 있는데 이것에 대해서도 살펴보도록 하겠다. 그리고 각 RPC 서비스 별로 RPC 통신을 테스트 할 수 있는 도구들이 있는데, 그것들이 rpings.exe, rpingc.exe, dtcping.exe, dtctester.exe 등이 그것이다. 요것들에 대해서도 잠시 살펴보도록 하겠다.
Rpcping.exe 와 Rpcdump.exe
Rpcping.exe는 RPC 통신이 수행되는지를 검사해주는 다양한 기능을 갖고 있는 유틸리티이다. TCP/IP에서 사용하는 ping.exe 와 동일하게 RPC 프토로콜을 이용하여 해당 서버와 접속이 가능한가를 테스트 해준다. 이 녀석을 다운로드 받기 위해서는 Windows Resource Kit을 다운로드 받아야 한다(다운로드 페이지에는 마치 2003 전용인 것처럼 보이는데 Windows XP에서도 사용할 수 있다). 리소스 킷 내에는 다양한 도구들이 존재하므로 쫄지 말고 rpcping.exe를 찾아 사용하면 된다. (도움말도 있다 !!)
Rpcping.exe의 옵션은 대단히 많다. 거의 질릴 정도이다. 대부분 RPC에 대해 상세히 알고 있어야 하는 옵션들이 대부분이므로 정말 RPC를 좀 파볼 사람이 아니면 -s 옵션(대소문자를 구분 하니 조심할 것)만 알고 있으면 된다. -s 옵션으로 테스트 하고자 하는 서버의 이름이나 IP를 주면 된다. 가급적 서버 이름으로 테스트 하자.
Rpcdump.exe는 서버의 RPC 종점 매퍼가 어떤 종점들을 등록하고 있는지 조회하는 유틸리티이다. 이 녀석 역시 Windows Resource Kit에 포함되어 있으며, 사용법도 매우 쉽다. -s 옵션으로 서버 이름을 주면 서버의 종점 매퍼가 등록하고 있는 종점들의 목록이 표시된다.
일반적으로 Rpcping.exe와 rpcdump.exe는 서버의 종점 매퍼와만 통신한다. 따라서 rpcping.exe 테스트와 rpcdump.exe 테스트가 성공하기 위해서는 135번 포트가 사용될 수 있으면 된다. 즉, 방화벽에 135번 포트가 열려 있다면 rpcping.exe와 rpcdump.exe 테스트는 성공할 것이다. 여기서 뽀인뜨는 rpcping 이 성공하더라도 실제 RPC 서비스를 성공적으로 사용할 수 있는지는 알 수 없다는 것이다. 그 이유는 rpcping이 특정 RPC 서비스를 테스트하는 것이 아니라 RPC 종점 매퍼와만 통신하여 RPC 접속이 가능한가 만을 테스트 하기 때문이라는 것이다. 이것은 ping 이 성공한다고 해서 항상 FTP 서비스를 받을 수 있지 않다는 것과 동일한 이치인 것이다.
Rpings.exe 와 Rpingc.exe
Rpings.exe와 Rpingc.exe 유틸리티는 RPC 서버(rpings.exe)와 RPC 클라이언트(rpingc.exe) 역할을 하는 완전히 독립된 RPC 클라이언트/서버 세트이다. 따라서 테스트 하고자 하는 서버에서는 rpings.exe를, 클라이언트에서는 rpingc.exe를 수행시켜 이 두 프로그램이 서로 통신을 수행하는지 검사하는 유틸리티가 되겠다. 상세한 사용법은 Windows Resource Kit과 함께 설치되는 유틸리티 도움말을 살펴보기 바란다 (그래도 스스로 조금의 노력은 들어가야... -_-).
Rpcping이 단순한 ping 테스트라는 점, 즉 135번 포트를 통해 RPC 종점 매퍼와 통신할 수 있는지 만을 확인해 주는 반면, rpings.exe는 실제 가상의 RPC 서비스(아주 간단하며 rpingc.exe 만이 이해하는)를 실제로 제공하므로 135번 포트 외에 추가적인(그리고 가변적으로 바뀌는) RPC TCP/IP 포트를 사용하므로 보다 명확한 테스트를 할 수 있다. RPC에서 사용하는 포트를 지정해 놓고(구체적인 방법은 지난 포스트에서 다루었다) 실제로 RPC 서비스가 이 포트를 사용하는지 테스트할 수 있다고 하겠다(물론 TcpView로 확인하는 방법도 있겠다).
Rpingc.exe의 또 한가지 특징은 rpings.exe 뿐만 아니라 Exchange 의 RPC 서비스를 테스트하는 능력을 가졌다는 것이다. 지금은 잘 기억나지도 않고 테스트 환경도 갖추어지지 않아 정확히 테스트 해볼 수는 없지만 rpingc.exe 의 UI 에서 endpoint를 Exchange의 Storage나 Admin으로 설정하여 Exchange 서버에 RPC를 통해 접속이 가능한가 테스트가 가능하다.
비록 rpingc.exe가 Exchange 서버에 대해 RPC 테스트를 할 수 있다고는 하지만 rpings.exe와 rpingc.exe 로 테스트를 했다고 해서 모든 RPC 서비스가 잘 작동할 것이라고 가정할 수 없다. 하지만 rpcping, rpings, rpingc 유틸리티들을 통해 기본적인 RPC 통신을 테스트할 수 있고, 이 테스트가 성공했다면 RPC 프로토콜 통신 자체에는 문제가 없다고 보면 된다. 이 테스트가 성공적임에도 불구하고 정상적인 RPC 서비스를 받을 수 없다면 그것은 RPC 프로토콜 문제가 아닌 해당 서비스의 문제로 압축할 수 있기 때문에 문제 해결의 범위를 축소할 수는 있겠다.
Dtcping.exe와 Dtctester.exe
앞서 언급한 대로 rpcping, rpings, rpingc 등의 유틸리티는 일반적인 RPC 프로토콜에 대한 검증이다. 특별한 서비스를 테스트 하기 위해서는 해당 서비스를 사용하는 간단한 유틸리티를 작성해야 한다. 필자의 관심이자 많은 개발자의 관심 대상인 DTC의 경우는 친절(?)하게도 MS에서 유틸리티를 제공하고 있다. Dtcping과 Dtctester가 그것이다. 이 두 유틸리티는 RPC를 사용하여 서버 상의 DTC 서비스와 실제 통신을 한다. 이 두 유틸리티로 테스트가 성공한다면 DTC 를 통한 분산 트랜잭션 역시 성공할 것이다.
필자가 맘에 들어 하는 유틸리티는 dtcping 이다. 이 녀석은 DTC가 문제없이 작동하기 위해 필요한 사항들을 모두 점검해 주며, 문제가 발생했을 때 문제 해결을 위한 다양한 정보를 제공해 주기 때문이다. 예를 들어, DTC는 상호 호출을 수행하며(분산 트랜잭션의 특성상 그렇다) 이 때문에 DTC 끼리 통신하는 두 컴퓨터(웹 서버와 데이터베이스 서버가 전형적인 예)가 서로 컴퓨터 이름(도메인이 붙지 않는)으로만 서로의 IP를 알아낼 수 있어야 한다. Dtcping은 테스트에 참여한 두 컴퓨터의 이름으로 IP를 알아내어 RPC 통신이 가능한가를 검사하며, 그 과정을 로그파일에 남겨준다.
<< Dtcping.exe 수행 시 화면 : 서버와 클라이언트에서 모두 수행 시켜야 한다. >>
Dtcping도 단점이 있다. Dtcping의 단점은 실제 DTC를 사용하는 것이 아니라 DTC의 행동을 애뮬레이션 한다는 점이다. 이 때문에 테스트 하고자 하는 두 컴퓨터에서 모두 dtcping을 수행시켜야 한다. 또한 dtcping 테스트를 통과했더라도 실제 DTC 통신, 즉 분산 트랜잭션이 작동하지 않을 수도 있다. 웹 서버와 데이터베이스 서버가 모두 Windows 2000 이라면 dtcping 테스트가 성공하면 DTC는 제대로 작동한다고 보면된다. 하지만 Windows 2003과 Windows XP SP2의 강화된 보안 설정 중에 DTC의 보안강화도 포함되어 있으며 이 보안 설정을 Dtcping이 똑같이 애뮬레이션 하지 않기 때문에 dtcping 테스트가 성공하더라도 분산 트랜잭션에 문제가 발생하곤 한다. 따라서 dtcping 을 보완할 유틸리티가 있어야 하는 것이다.
Dtctester가 바로 보완적인 유틸리티로 볼 수 있다. Dtctester는 실제 DTC를 사용하여 분산 트랜잭션을 수행한다. 이 테스트가 성공한다면 DTC 통신에 문제가 없는 것이며 이 테스트가 성공하지 않는다면 DTC 설정이 잘못되어 있는 것이다. Dtctester는 실제 DTC 서비스를 이용하므로 Dtcping이 갖는 문제는 없다. 하지만 Dtctester는 문제 해결을 위한 정보를 거의 제공하지 않는다. 단순히 DTC 테스트가 성공했는지 실패했는지만을 간략하게 알 수 있을 뿐이다. 따라서 Dtcping을 통해 일반적인 문제를 해결하고 최종적으로 dtctester로 테스트를 한번 더 하는 것이 좋다.
마치며...
지금까지 3회에 걸쳐 RPC에 대한 썰을 풀어봤다. 도움이 되었을 수도 있고 그렇지 않을 수도 있지만 꼭 한번 정리하여 알리고 싶었던 내용이므로 갠적으로 만족하는 바이다. Windows 2003 및 Windows XP SP2의 DTC 보안 설정에 대해서 대략 간단히 언급만 하고 넘어가서 아쉽지만 스크롤의 압박이 있는지라...
다음에 기회를 내서 (언제? 못 미더워... -_-) DTC를 설정하는 완벽(?) 가이드를 작성해 볼까 한다. 말로만~~~~~
Comments (read-only)
#re: RPC에 대하여... (3) : RPC 작동을 위한 테스트 방법 / 황달봉 / 10/20/2005 8:45:00 PM
이제 1편 반 읽었는데....
언제 여까지 읽지....
#re: RPC에 대하여... (3) : RPC 작동을 위한 테스트 방법 / sintax / 8/29/2007 5:10:00 PM
개발자가 아니어서 생소하긴 하지만 어느정도 개념을 잡을수 있었습니다.
글 정말 잘 보고 갑니다. 자주 들어와서 공부해야 겠네요..
#re: RPC에 대하여... (3) : RPC 작동을 위한 테스트 방법 / jungmoon / 9/14/2007 5:39:00 PM
글 잘봤습니다. 이해 잘하고 갑니다. 수고하세요.,