MS-DTC Setting on Windows 2003

시작하기 전에 상당히 긴 포스트가 될 것이므로 성질 급한 인간이나 걍 한번 열어본 사람이라면 잽싸게 "뒤로" 버튼을 누르는 것이 현명할 것이다. DTC 설정 때문에 몇 시간 이상을 낭비한 사람들은 비록 설정 방법을 알고 있더라도 이 글을 읽어 보면 왜 그렇게 해야 하는가를 설명하니 함 읽어 봐도 나쁘지는 않을 듯 싶다. 아니면 말고... -_-

MS-DTC는 Windows 운영체제에서 분산 트랜잭션을 관장하는 중요한 서비스이다. COM+를 사용하여 트랜잭션을 사용한다면 반드시 사용되는 것이 MS-DTC, 줄여서 걍 DTC라고 하는 것이다. DTC는 분산 트랜잭션의 TM(Transaction Manager) 역할을 수행하므로 분산 트랜잭션을 시작하는 COM+ 컴포넌트가 반드시 사용해야 하는 것이다.

여기서 의문점이 발생한다. 대개 COM+는 웹 서버 혹은 어플리케이션 서버(요즘은 대개 웹 서버에서 COM+를 수행하므로 웹 서버로만 통일해서 지칭하겠다)에서 DTC 만을 사용하면 될 듯 싶다. 하지만 데이터베이스로 SQL-Server가 사용되고 DB 서버가 별도로 존재하는 경우, DTC가 말썽을 부리는 경우가 많다. 웹 서버의 COM+가 웹 서버에서 작동하는 DTC만 액세스 하면 될 터인데 왜 DB 서버의 DTC 설정까지 다루어야 할까?

SQL-Server가 분산 트랜잭션에 관여되면 SQL-Server가 수행되는 컴퓨터의 DTC로부터 제어를 받는다. 따라서 웹 서버에서 원격 컴퓨터, 즉 DB 서버에 존재하는 SQL-Server와 분산 트랜잭션을 수행하려고 하면 웹 서버의 DTC와 DB 서버의 DTC가 서로 통신해야 하는 것이다. 그렇다면 SQL-Server가 아닌 Oracle이 사용되면 어떻게 될까? 물론 웹 서버의 DTC가 사용된다. 그리고 이 DTC가 Oracle 과 직접 통신하거나(XA 프로토콜 사용 시), Oralce Service for MTS 서비스를 통해(ODP.NET 같은 거 쓸 때) 오라클과 통신하게 된다. 따라서 DTC 끼리 통신할 때 발생하는 DTC 설정의 복잡도는 거의 없다고 볼 수 있다.

이 포스트에서 설명하는 환경은 웹 서버에 Windows 2003 혹은 Windows XP SP2 가 사용되고, DB 서버에는 SQL-Server가 Windows 2003 혹은 Windows XP SP2 가 사용될 때의 설정을 언급하는 것임을 잊지 말자.

Traditional DTC Setting

Windows 2003 과 Windows XP SP2 이전 상황에서 DTC 설정은 널리(?) 알려져 있는 것이다.

• 두 컴퓨터(웹 서버/DB 서버)가 서로 컴퓨터 이름으로 ping이 될 것
• RPC 통신이 양방향으로 가능 할 것

간단하게 보이지만 만만하지는 않다. 하나 하나 천천히 뜯어 묵어 보자.

컴퓨터 이름으로 IP 알아내기

DTC 통신에서 컴퓨터 이름으로 ping이 되어야 한다는 조건은 DTC가 RPC 프로토콜을 사용하고 이 프로토콜이 패킷 내에 전송자 컴퓨터의 이름을 기록하기 때문이다. 그리고 여기에 기록된 컴퓨터 이름으로부터 상대방이 누구인지를 알아내기 때문에 반드시 양 방향으로 컴퓨터의 이름을 통해서만 ping이 가능해야 DTC 통신이 되게 된다(사실 반드시 ping이 될거 까지는 없고, 컴퓨터 이름으로 IP 를 알아 낼 수만 있어도 된다).

컴퓨터 이름으로만 ping이 되어야 한다는 점에 주목하자. 웹 서버가 webserver.domain.com 이고 DB 서버가 dbserver.domain.com 이라면 웹 서버에서 "ping dbserver" 명령이, 그리고 DB 서버에서 "ping webserver" 명령을 수행했을 때 이것이 성공해야 한다는 말이다(뒤에 도메인 이름이 붙지 않음에 주목, 또 주목하자). ping 자체가 성공하지 않더라도 적어로 webserver, dbserver 라는 컴퓨터 이름으로 부터 IP를 알아내는 것 까지는 가능해야 하는 것이다.

이것을 만족시키기 위해 두 컴퓨터는 NetBIOS 통신이 가능하면 된다. 즉, 두 컴퓨터가 NetBIOS 프로토콜이 설치되고 사용가능 해야 하고, 같은 네트워크 내에 묶여 있다면 "컴퓨터 이름으로 IP 알아내기"는 가능하다는 것이다. 하지만, Windows 2003이나 Windows XP의 기본 설정은 NetBIOS 프로토콜이 기본적으로 선택되어 있지도 않으며, DB 서버가 같은 네트워크 (192.168.1.xxx 와 같이 같은 네트워크 서브 마스크 내에 있음을 의미)에 존재할 가능성은 희박하다. 게다가 웹 서버와 DB 서버는 대부분의 경우 방화벽에 가로 막혀 있으므로 NetBIOS 프로토콜은 택도 없는 얘기가 되겠다.

이 때문에  많이 사용하는 방법은 두 컴퓨터의 hosts 파일에 컴퓨터 이름과 IP를 기록해 두는 방법이 많이 사용된다. DB 서버의 hosts 파일에는 웹 서버의 컴퓨터 이름과 IP를, 웹 서버의 hosts 파일에는 DB 서버의 이름과 IP를 기록하면 "컴퓨터 이름 만으로 IP 알아내기" 조건을 만족시킨다. Hosts 파일을 이용하는 방법 외에 쓸만한 것은 DNS를 사용하되, DNS 접미사를 설정하여 컴퓨터 이름만이 명시되더라도 IP를 알아낼 수 있으면 되겠다.

웹 어플리케이션을 개발할 때 개발자 PC가 웹 서버의 역할을 수행하는 경우가 많은데, 이 때 개발용 DB 서버에 분산 트랜잭션으로 접근해야 할 때도 많다. 이런 경우에는 어쩔 수 없이 DB 서버의 hosts 파일에 개발자의 컴퓨터 이름하구 IP를 일일이 등록해 놓는 수 밖에 없다. 대략 귀찮지만... 아~ 흐~

RPC 통신이 양방향으로 가능할 것

왜 양방향으로 통신이 가능해야 할까에 대해 간단히 설명하자면... DTC는 분산 트랜잭션을 관리한다. 따라서 분산 트랜잭션의 대장 역할(TM)을 수행하는 웹 서버의 DTC가 트랜잭션의 자원 관리자로서 SQL Server가 수행중인 DB 서버의 DTC와 통신해야 함은 당연할 것이다. 하지만 왜 DB 서버의 DTC가 웹 서버의 DTC를 액세스 해야 할까? 분산 트랜잭션은 2단계 커밋(2-phase-commit)을 수행하고 여러 자원 관리자(DB, MSMQ 등등)가 한 트랜잭션에 참여하므로 상당히 복잡하다. 만약 트랜잭션이 아직 종료되지 않은 시점에서 웹 서버가 다운되어 버리면 DB 서버는 트랜잭션을 커밋(commit) 해야 할까 취소(abort) 해야 할까? 그냥 취소하는 것도 방법이지만, 또 다른 방법은 나중에 웹 서버에게 물어 보는 것이다. 이러한 불완전한 트랜잭션(In-doubt transaction)을 위해 양방향 통신이 요구되는 것이다.

RPC 통신이 가능해야 한다는 말은 아주 쉽게 들인다. 하지만 웹 서버와 DB 서버 사이에 방화벽(방화벽이 아니더라도 라우터의 패킷 필터링도 동일한 문제임을 잊지 말자)이 걸려 있다면 이야기는 달라진다. RPC는 하나의 고정 포트를 사용하지 않기 때문이다. 방화벽이 없다면 둘 사이의 RPC 통신은 큰 문제가 없을 것이다. 방화벽이 걸려 있다면 방화벽에서 RPC 통신이 가능하도록 포트들을 열어 주어야 한다. 열어주어야 할 포트는 다음과 같다.

• SQL Server 서비스 포트 : 1433 번
• RPC 포트 매퍼 포트 : 135 번
• RPC 서비스 포트 : xxxx ~ yyyy

RPC 서비스 포트는 기본적으로 1025 이상의 포트 번호 중 사용 가능한 임의의 포트를 사용한다. 하지만 RPC 이야기 씨리즈에서 밝혔듯이 RPC가 사용하는 포트 영역을 설정할 수 있으므로 이 포트 영역을 열어 주면 되겠다. 상세한 내용은 RPC 씨리즈 (1) 포스트와 RPC 씨리즈 (2) 포스트를 살펴보기 바란다.

테스트 하기

열거한 두 가지 조건을 만족하는가를 테스트 하기 위해서 Dtcping 프로그램을 사용하면 된다. 웹 서버와 DB 서버에서 모두  dtcping을 수행시키고 웹 서버에서 DB 서버의 이름을 입력하고 'ping' 버튼을 눌러 보자. 그러면 이 녀석은 DB 서버의 컴퓨터 이름으로 IP를 알아낼 수 있는가를 먼저 검사하고 웹 서버에서 DB 서버로의 DTC 바인딩을 수행한다. 이것이 성공하면 반대로 DB 서버에서 다시 웹 서버로 DTC 바인딩을 시도한다. 물론 이 과정에서 DB 서버에서 웹 서버의 이름으로만 IP를 알아내는 것 역시 테스트 한다.

Windows 2000 그리고 Windows XP SP1 까지 버전에서는 Dtcping 으로 테스트가 성공하면 DTC 통신 역시 작동한다고 보면 된다. 하지만 Windows 2003 이나 Windows XP SP2 이 사용되면 이야기가 달라진다. 쓰봉 이전까지 잘 작동하던 것이 SP2를 설치하고 작동이 안된다든가, Windows 2000에 SQL Server를 설치했을 때는 잘됬던 것이 서버를 2003으로 업그레이드 했더니 안되더라 등등...

DTC Security Settings

Windows 2003을 필두로 MS는 보안에 커다란 신경을 쓰게되었고 특히 RPC에 관련된 바이러스 피바람이 분 후에는 RPC의 보안 문제에 신경을 쓰곤 했다. RPC 프로토콜을 사용하는 DTC도 예외는 아니다. Windows 2003 부터 등장한 DTC의 보안 설정은 크게 다음 세 부분으로 나누어 볼 수 있다.

• 원격 컴퓨터에서 DTC를 '사용'하거나 '관리' 할 수 있는가 여부
• 원격 컴퓨터가 참여하는 분산 트랜잭션을 시작하거나 참여할 수 있는가 여부
• DTC 통신에 사용되는 RPC 프로토콜의 보안 설정

이러한 설정은 DTC 관리 탭에서 수행할 수 있다. 구성요소 관리자 > 내 컴퓨터 > 내 컴퓨터 등록 정보 대화상자의 MSDTC 탭을 살펴보면 보안설정 버튼이 존재한다. 이 버튼을 지긋이 눌러 보면 다음과 같은 화면이 나타날 것이다.

<< Windows 2003 SP1 혹은 Windows XP SP2 의 MSDTC 보안 구성 대화상자 >>

이 보안 구성 대화 상자의 내용은 Windows 2003 SP1 혹은 Windows XP SP2 에서 나타나는 대화 상자이다. Windows 2003 에서 SP1 가 설치되지 않았거나 Windows XP SP2 이전이라면 이보다 더 간단한 설정이 나타날 것이다. 이 다이얼로그에서 DTC의 보안 설정을 수행할 수 있고 이 보안 설정이 적절하지 않다면 DTC는 제대로 작동하지 않을 것이다.

가장 기본적인 옵션은 최상단의 "네트워크 DTC 액세스" 설정이다. 이 옵션이 선택되어 있지 않다면 DTC는 로컬 컴퓨터의 자원(DB, MSMQ 등)들에 대해서만 분산 트랜잭션을 제어한다. 어떤 외부의 분산 트랜잭션 요구나 원격 컴퓨터의 DB, MSMQ 등의 자원에 대해서도 분산 트랜잭션을 수행하지 않는다.

"네트워크 DTC 액세스"가 선택되어 있다면 로컬 컴퓨터의 DTC가 네트워크를 통해 다양한 작업을 수행할 수 있게 된다. DTC가 네트워크를 통해 수행하는 작업 중 하나는 원격 DTC 클라이언트의 허용과 원격 DTC 관리 허용이다. 원격 DTC 클라이언트라 함은 원격 컴퓨터가 로컬 컴퓨터의 DTC를 사용하여 분산 트랜잭션을 수행하는 것을 말한다. 예를 들어 Windows 98 클라이언트가 Windows 2003의 DTC를 통해 분산 트랜잭션을 "시작"하는 것을 예로 들 수 있겠다. 이것은 분산 트랜잭션과 혼동하지 말아야 할 개념으로서 클라이언트의 로컬 컴퓨터의 DTC가 아닌 원격 컴퓨터의 DTC를 사용하여 분산 트랜잭션을 수행하는 것이다. DTC 보안 구성에서 "원격 클라이언트 허용" 옵션이 선택되어 있는 경우에만 원격 클라이언트가 로컬 컴퓨터의 DTC를 사용하는 것을 허용한다. 또한 원격 컴퓨터에서 로컬 컴퓨터의 DTC 설정(트랜잭션 로그의 크기 등 설정이 존재한다. 비록 디폴트를 수정하는 경우가 거의 없지만...)을 바꿀 수 있도록 허용하는 옵션이 "원격 관리 허용" 옵션인 것이다.

"원격 클라이언트 허용" 옵션과 "원격 관리 허용" 옵션은 대부분 사용하지 않는다. 비록 로컬 컴퓨터의 DTC가 아닌 원격 컴퓨터의 DTC를 사용하도록 할 수도 있지만 성능, 신뢰도, 안정성 등의 다양한 이유에서 로컬 DTC를 사용하는 것이 일반적이며, 원격 DTC를 관리하는 것 역시 일반적인 상황도 아니다. 필자가 테스트 해 본 결과, 이 두 옵션을 모두 선택한 상태에서 다른 컴퓨터가 필자의 DTC를 사용하도록 설정해 보았지만 작동하지 않았다. 정확한 이유는 알 수 없었지만 아마도 Active Directory를 필요로 하는 듯 했다.

"트랜잭션 관리자 통신" 이라는 그룹으로 묶인 옵션들이 오늘의 핵심 하이라이또 이다. "트랜잭션 관리자 통신"이 소위 분산 트랜잭션에서 DTC 사이의 보안 설정을 제어한다. 대부분 이 설정들이 제대로 되어 있지 않기 때문에 DTC가 문제를 발생하는 것이다. 하나 하나 뜯어 묵어 보자. "트랜잭션 관리자 통신" 이란 옵션은 기본적으로 네트워크를 통해 분산 트랜잭션을 수행할 수 있는 가를 제어하는 것이다. 즉, 분산 트랜잭션에 참여하는 자원(DB, MSMQ 등)이 로컬 컴퓨터가 아닌 원격 컴퓨터에 존재한다던가, 아니면 원격 컴퓨터에서 시작된 분산 트랜잭션이 로컬 컴퓨터의 자원을 사용할 수 있도록 하던가 하는 네트워크 상에서 발생하는 분산 트랜잭션의 허용 여부를 제어함을 의미한다.

"인바운드 허용(allow in-bound)" 이라 함은 원격 컴퓨터에서 시작된 분산 트랜잭션이 로컬 컴퓨터의 자원(대개 SQL-Server)을 분산 트랜잭션에 포함시키고자 할 때 이것을 허용할 것인가를 제어한다. "아웃바운드 허용(allow out-bound)" 이라 함은 로컬 컴퓨터에서 시작된 분산 트랜잭션이 원격 컴퓨터의 자원(대개 SQL-Server)을 포함시킬 수 있도록 할 것인가를 제어한다. 대개의 경우 인바운드와 아웃바운드를 모두 허용하도록 해놓으면 문제가 없다. 하지만 보다 높은 보안 수준을 유지하고자 한다면 COM+ 컴포넌트가 존재하는(트랜잭션을 시작하는) 웹 서버에서는 아웃바운드를 허용해야 하며, 데이터베이스 서버에서는 인바운드를 허용해야만 한다. 물론 데이터베이스 서버에서 SQL-Server가 Linked-Server를 사용한다면 아웃바운드 역시 허용해야 할 것이다.

다음 옵션은 네트워크 상에서 발생하는 분산 트랜잭션에서 DTC 끼리 통신을 할 때 사용되는 RPC 프로토콜의 보안 설정을 제어하는 옵션으로 DTC끼리 서로 컴퓨터를 인증할 것인가, 인바운드 호출에 대해서만 인증할 것인가, 아니면 전혀 인증하지 않을 것인가를 선택할 수 있다. Active Directory가 사용되지 않는다면 컴퓨터를 인증할 방법이 없다. 따라서 AD 환경이 아니라면 무조건 "인증 필요 없음"이 선택되어야만 한다. 대부분 "인증 필요 없음" 옵션을 선택하는 것이 무난하다.

"TIP 트랜잭션 사용" 옵션은 DTC가 TIP(Transaction Internet Protocol) 사용을 허용할 것인가를 제어한다. 트랜잭션이 TIP를 사용해야 한다면 이 옵션이 선택되어야 한다. TIP에 대해서 상세한 설명은 이 포스트의 범위에서 벗어나므로 생략하기로 한다. 그렇지 않아도 길다... -_-

다음 옵션은 "XA 트랜잭션 사용" 옵션인데, XA 트랜잭션이라 함은 UNIX 플랫폼에서 표준적으로 사용되는 분산 트랜잭션 프로토콜인 XA 프로토콜을 사용하는 트랜잭션을 말한다. DTC와 SQL-Server의 분산 트랜잭션은 OLE 트랜잭션이라 불리는 프로토콜로서 XA 프로토콜과 전혀 다른 것이다. XA 프로토콜을 RPC와도 관계가 없으며 XA 라이브러리를 통해서 수행된다. 만약 COM+에서 사용되는 분산 트랜잭션이 XA를 사용한다면 이 옵션이 선택되어야 한다. 이 옵션은 대개 웹 서버에서만 설정할 필요가 있으며 SQL-Server가 수행되는 DB 서버에서는 선택할 필요가 없다. 이 옵션의 선택 여부는 어떤 데이터베이스를 사용하는가와 어떤 .NET Data Provider를 쓰는가에 따라 그때 그때 다르다. SQL-Server를 사용하거나 Oracle을 ODP.NET 혹은 MS의 Oracle Data Provider를 사용한다면 이 옵션은 선택할 필요가 없다.

마지막으로 msdtc.exe 프로세스가 사용하는 계정을 지정할 수 있으며 디폴트는 NETWORK SERVICE 계정이다. 약 99.99%는 이 설정을 바꾸어서는 안 된다. 필자 역시 이 설정을 바꾸어 본적이 없으며, 바꾸 었을 때 어떤 결과가 나올지는 예상할 수 없다. 또한 이 계정을 바꾸고 나서 다시 NETWORK SERVICE로 원상 복구 시키기 위해서는 msdtc를 다시 설치해야만 한다. 고로 바꾸지 않는 것이 정신 건강과 육체 건강에 도움이 될 것이다.

요약해 보자. 웹 서버(혹은 어플리케이션 서버)에서 COM+가 사용되고 DB 서버에서 SQL-Server가 작동한다는 가정하에서 웹 서버의 DTC 보안 설정은 다음과 같다.

• 네트워크 DTC 액세스 허용
• 아웃 바운드 허용 (혹은 인바운드, 아웃바운드 모두 허용)
• RPC 인증 필요 없음
• NETWORK SERVICE 계정 사용

DB 서버에서의 DTC 보안 설정은 다음과 같다.

• 네트워크 DTC 액세스 허용
• 인바운드 허용 (혹은 인바운드, 아웃바운드 모두 허용)
• RPC 인증 필요 없음
• NETWORK SERVICE 계정 사용

요러한 설정이 항상 DTC의 작동을 장담하지는 않지만 AD가 사용되지 않는 환경에서는 거의 작동하는 보안 설정이 되겠다. AD 환경이 사용된다면 몇 가지 선택사항이 더 있을 수 있겠지만, 각자가 자신의 환경에 맞게 설정해서 테스트 해 보기 바란다. 필자는 AD 환경에서 DTC 보안 설정 테스트를 아직 못해봐서 더 이상 뭐라 말 못하겠다... 음냐..

DTC 설정 정리

열나 빡신 DTC 설정이 되겠다. 지금까지의 DTC 가 제대로 작동하기 위해서 수행되어야 할 설정들을 살펴보았다. 요약하자면 dtcping.exe로 테스트를 수행하고 DTC의 보안설정을 수행한 다음에 dtctester.exe로써 최후의 일격을 가해보는 것이다. 보다 구체적인 요약은 다음과 같다.

• 두 컴퓨터가 컴퓨터 이름만으로 ping이 되거나 컴퓨터 이름만으로 IP를 알아 낼 수 있도록 설정.
• 방화벽이 존재하는 경우, 135 번 포트, 데이터베이스 포트(SQL-Server는 1433 포트) 그리고 RPC 동적 포트를 방화벽에서 열어 줄 것.
  (RpcPing.exe 혹은 dtcping.exe 테스트가 양방향으로 성공하는가 테스트)
• DTC 보안 설정에서 "네트워크 DTC 액세스", "인바운드/아웃바운드" 가 허용되고, RPC 인증을 사용하지 않을 것.
• 최종적으로 dtctester.exe를 통해 테스트

필자의 경험상, SQL-Server를 사용하는 경우 이러한 절차를 거치면 DTC는 잘 작동한다. 만약 DB가 SQL-Server가 아닌 Oracle 이나 Sybase라면 DTC 설정이 달라짐은 물론이다. 모든 경우에 대해 DTC 설정을 여기서 다 설명할 순 없다. 필자의 지론이자 가훈인 "자기의 일은 스스로 하자~~~ 알아서 척척척 스스로 어린이~~~"를 따르기 바란다.