클러스터 MSDTC와 RPC 통신 정리되지 않은 기술

클러스터로 구성되어 있는 SQL Server 이를 이용하려는 클라이언트 서버 사이에 Firewall 존재하는 경우 MSDTC 이용한 Transaction처리를 원할 때는 가지 고려 해야 사항이 있다.

 

알려진 바와 같이 MSDTC RPC 이용한다. Windows에서 DCE/RPC 일반적으로 1024에서 5000 사이의 임의의 포트를 무작위로 사용하기 때문에 방화벽과 같은 환경에서의 포트를 열고 닫음에 있어서는 여간 곤혹스러운 것이 아니다. 하지만, 문서"INFO: Microsoft DTC 방화벽을 통해 작동하도록 구성" 확인하면, 이와 같은 RPC 동적 포트를 임의의 영역으로 제한하여 설정할 있는 방법을 제공하며, 이를 통해서 제한 설정한다면 방화벽에서도 이러한 제한된 포트들만 가지고 규칙 설정이 가능하다.

 

또한 문서 "Description of names and IP addresses that an MSDTC client in a cluster environment must have" 확인하면, 방화벽 안밖에 존재하는 서버간의 이름 확인(Name resolution) 중요한데, 이는 RPC 프로토콜이 이름 확인을 통해서 통신한다는 점에서 기인한다. 보통, 일반적으로 IP 주소로 (Ping)하여 응답이 오면 방화벽이 있거나 다른 네트워크에 존재하는 서버간의 통신에 문제없다고 여기는 경우가 있는 , RPC 프로토콜을 사용한다면, DNS 서버나 Host 파일을 통해서 이름확인이 되어야 하며, 특히 다음의 정보는 클러스터환경의 MSDTC 사용하는 클라이언트에서는 반드시 고려되어야 되는 정보로 언급되어 있다.

 

ü  MSDTC resource

ü  An instance of SQL Server if the cluster configuration is either active-passive or active-active

ü  Cluster Name

 

또한 해당 문서는 방화벽을 위한 규칙 설정 시 다음의 항목들을 반드시 고려해야 함을 언급하고 있다. (The firewall rules must include the following: )

 

ü  The IP network names and the addresses of both physical nodes on the cluster

ü  The SQL Server Instances network names and address

ü  The client network name and addresses

ü  The child network name and IP resource of the MSDTC Resource

 

그러므로, 이러한 사항만을 준수한다면, 방화벽환경에서 클러스터 MSDTC 사용하는 , 크게 문제가 없을 것이라 생각한다. 그럼에도 불구하고, 문제가 발생할 경우에는 일반적으로 DTCPing 통해서 Troubleshooting 하게 되는 , DTCPing 주로 RPC 프로토콜의 처리에 문제없는 지를 확인하는 과정으로 이뤄지며 이에 대한 에러로그등을 통해서 문제를 해결해 나갈 있다. 다음은 추가적으로 DTCPing 어떠한 네트워크 흐름을 갖는 네트워크 모니터를 통해서 확인해 보고자 한다.

 

먼저, 환경은 다음과 같다고 가정한다.

ü  192.168.0.2 클러스터 SQL Active 노드 물리적 address (Name: W2k3clusterN1) ;

ü  192.168.0.11 MSDTC 클러스트 리소스 address(Name: VCLUSTER)

ü  192.168.0.1 클라이언트 (Name: w2k3client)

 

클러스터 노드는 DTC 실행되는 Active Node 정보만 언급하였으며, W2k3clusterN1 머신에서 DTCPing 프로그램을 통해 w2k3client 머신이름으로 핑을 하고 시점에 네트워크 모니터로 잡았다. 역도 유사한 패턴이다.

 

 

NO      time            source         destination        protocol             info

======================================================================================

 

333     2010-05-25 15:57:24.989974    192.168.0.2    192.168.0.1    TCP     lkcmserver > epmap [SYN] Seq=0 Win=65535 Len=0 MSS=1460

 Transmission Control Protocol, Src Port: lkcmserver (3278), Dst Port: epmap (135), Seq: 0, Len: 0

 

334     2010-05-25 15:57:24.989974    192.168.0.1    192.168.0.2    TCP     epmap > lkcmserver [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460

 Transmission Control Protocol, Src Port: epmap (135), Dst Port: lkcmserver (3278), Seq: 0, Ack: 1, Len: 0

 

335     2010-05-25 15:57:24.989974    192.168.0.2    192.168.0.1    TCP     lkcmserver > epmap [ACK] Seq=1 Ack=1 Win=65535 Len=0

 Transmission Control Protocol, Src Port: lkcmserver (3278), Dst Port: epmap (135), Seq: 1, Ack: 1, Len: 0

 

처음 333, 334, 335 135 Port 대한 TCP Handshake 동작이다.

 

 

 

336     2010-05-25 15:57:24.989974    192.168.0.2    192.168.0.1    DCERPC  Bind: call_id: 1, 2 context items, 1st EPMv4 V3.0

 Transmission Control Protocol, Src Port: lkcmserver (3278), Dst Port: epmap (135), Seq: 1, Ack: 1, Len: 116

 

337     2010-05-25 15:57:24.989974    192.168.0.1    192.168.0.2    DCERPC  Bind_ack: call_id: 1 Unknown result (3), reason: Abstract syntax not supported

 Transmission Control Protocol, Src Port: epmap (135), Dst Port: lkcmserver (3278), Seq: 1, Ack: 117, Len: 84

 

336 337dms 135 port(End Point Mapper) 대한 Bind 동작, 보면, DCERPC Request/Response 형태로 되어 있다. 만일, 135 막혀있다면, 처음 TCP handshake 되지 않았을 것이다. Binding 되지 않으면, RPC 서버에 문제가 있을 수도 있겠다.

 

 

 

338     2010-05-25 15:57:24.989974    192.168.0.2    192.168.0.1    EPM     Map request

 Transmission Control Protocol, Src Port: lkcmserver (3278), Dst Port: epmap (135), Seq: 117, Ack: 85, Len: 156

 

339     2010-05-25 15:57:24.989974    192.168.0.1    192.168.0.2    EPM     Map response

 Transmission Control Protocol, Src Port: epmap (135), Dst Port: lkcmserver (3278), Seq: 85, Ack: 273, Len: 152

 

338 339 w2k3client End point Mapper(135 port) request/response : 실제로 이러한 통신을 통해서 w2k3client RPC 접근할 Port No 건네준다. 다음은 Bind/Bind_ack, Request/Response 반복이다. 만일, Firewall 있는 경우에, w2k3client에서 건네준 Port 막혀있다면, 다음 Binding에서 문제가 발생할 것이다. 그러므로, 대상 머신에 kb250367 문서에 맞게 설정하고 해당 Port들을 Firewall에서 연다면, 여기서 건네준 Port 레지스트리에 제한된 포트들중의 하나가 된다. 여기서는 2615번을 건네줬다. 이는 다음의 Bind Packet에서 사용하는 destination 포트를 보면 있다.

 

 

 

 

343     2010-05-25 15:57:25.005599    192.168.0.2    192.168.0.1    DCERPC  Bind: call_id: 1, 2 context items, 1st 75687379-aaaa-44f6-9512-080ac70f8ad9 V1.0

 Transmission Control Protocol, Src Port: admind (3279), Dst Port: firepower (2615), Seq: 1, Ack: 1, Len: 116

 

344     2010-05-25 15:57:25.005599    192.168.0.1    192.168.0.2    DCERPC  Bind_ack: call_id: 1 Unknown result (3), reason: Abstract syntax not supported

 Transmission Control Protocol, Src Port: firepower (2615), Dst Port: admind (3279), Seq: 1, Ack: 117, Len: 84

 

345     2010-05-25 15:57:25.005599    192.168.0.2    192.168.0.1    DCERPC  Request: call_id: 1 opnum: 0 ctx_id: 0 75687379-aaaa-44f6-9512-080ac70f8ad9 V1

 Transmission Control Protocol, Src Port: admind (3279), Dst Port: firepower (2615), Seq: 117, Ack: 85, Len: 80

 

346     2010-05-25 15:57:25.005599    192.168.0.1    192.168.0.2    DCERPC  Response: call_id: 1 ctx_id: 0

75687379-aaaa-44f6-9512-080ac70f8ad9 V1

 Transmission Control Protocol, Src Port: firepower (2615), Dst Port: admind (3279), Seq: 85, Ack: 197, Len: 44

 

 

/******** 다음 패킷은 일단 무시하자.

348     2010-05-25 15:57:25.005599    192.168.0.2    192.168.0.1    TCP     lkcmserver > epmap [ACK] Seq=273 Ack=237 Win=65299 Len=0

 Transmission Control Protocol, Src Port: lkcmserver (3278), Dst Port: epmap (135), Seq: 273, Ack: 237, Len: 0

  ***************/

 

 

 

실제로는 다음의 패킷 흐름이 재미있다.

 

349     2010-05-25 15:57:25.021224    192.168.0.2    192.168.0.1    DCERPC  Request: call_id: 2 opnum: 1 ctx_id: 0 75687379-aaaa-44f6-9512-080ac70f8ad9 V1

 Transmission Control Protocol, Src Port: admind (3279), Dst Port: firepower (2615), Seq: 197, Ack: 129, Len: 60

 

클리이언트는 MSDTC 클러스트 리소스의 IP(192.168.0.11) DCERPC Request하는 것을 있다. 역방향일 경우에는 클러스터 노드(192.168.0.2)에서 클라이언트(192.168.0.1) DCERPC Request 한다. 응답의 경우에는 클라이언트(192.168.0.1)에서 클러스터 노드(192.168.0.2) response 하거나 역방향일 경우에는 MSDTC 클러스터 리소스(11) 에서 클라이언트(1) DCERPC response 한다.

 

353     2010-05-25 15:57:25.021224    192.168.0.1    192.168.0.11   DCERPC  Request: call_id: 2 opnum: 2 ctx_id: 0 75687379-aaaa-44f6-9512-080ac70f8ad9 V1

 Transmission Control Protocol, Src Port: metricadbc (2622), Dst Port: awg-proxy (3277), Seq: 197, Ack: 129, Len: 60

 

354     2010-05-25 15:57:25.036849    192.168.0.11   192.168.0.1    DCERPC  Response: call_id: 2 ctx_id: 0 75687379-aaaa-44f6-9512-080ac70f8ad9 V1

 Transmission Control Protocol, Src Port: awg-proxy (3277), Dst Port: metricadbc (2622), Seq: 129, Ack: 257, Len: 44

 

355     2010-05-25 15:57:25.036849    192.168.0.1    192.168.0.2    DCERPC  Response: call_id: 2 ctx_id: 0 75687379-aaaa-44f6-9512-080ac70f8ad9 V1

 Transmission Control Protocol, Src Port: firepower (2615), Dst Port: admind (3279), Seq: 129, Ack: 257, Len: 44

 

356     2010-05-25 15:57:25.036849    192.168.0.2    192.168.0.1    DCERPC  Request: call_id: 3 opnum: 3 ctx_id: 0 75687379-aaaa-44f6-9512-080ac70f8ad9 V1

 Transmission Control Protocol, Src Port: admind (3279), Dst Port: firepower (2615), Seq: 257, Ack: 173, Len: 60

 

357     2010-05-25 15:57:25.036849    192.168.0.1    192.168.0.2    DCERPC  Response: call_id: 3 ctx_id: 0 75687379-aaaa-44f6-9512-080ac70f8ad9 V1

 Transmission Control Protocol, Src Port: firepower (2615), Dst Port: admind (3279), Seq: 173, Ack: 317, Len: 44

 

358     2010-05-25 15:57:25.036849    192.168.0.1    192.168.0.11   DCERPC  Request: call_id: 3 opnum: 1 ctx_id: 0 75687379-aaaa-44f6-9512-080ac70f8ad9 V1

 Transmission Control Protocol, Src Port: metricadbc (2622), Dst Port: awg-proxy (3277), Seq: 257, Ack: 173, Len: 60

 

361     2010-05-25 15:57:25.130599    192.168.0.11   192.168.0.1    DCERPC  Response: call_id: 3 ctx_id: 0 75687379-aaaa-44f6-9512-080ac70f8ad9 V1

 Transmission Control Protocol, Src Port: awg-proxy (3277), Dst Port: metricadbc (2622), Seq: 173, Ack: 317, Len: 44

 

359     2010-05-25 15:57:25.114974    192.168.0.2    192.168.0.1    DCERPC  Request: call_id: 4 opnum: 2 ctx_id: 0 75687379-aaaa-44f6-9512-080ac70f8ad9 V1

 Transmission Control Protocol, Src Port: admind (3279), Dst Port: firepower (2615), Seq: 317, Ack: 217, Len: 60

 

360     2010-05-25 15:57:25.114974    192.168.0.1    192.168.0.2    DCERPC  Response: call_id: 4 ctx_id: 0 75687379-aaaa-44f6-9512-080ac70f8ad9 V1

 Transmission Control Protocol, Src Port: firepower (2615), Dst Port: admind (3279), Seq: 217, Ack: 377, Len: 44

 

그러므로, 간혹, 클러스트 환경의 경우에 MSDTC 리소스에 대한 고려를 잊었다면, 353 패킷과 같은 DCERPC Request에서 fail 발생할 것이다. 한가지는 일반적으로 방화벽의 설정이 inbound 만을 막고 outbound any 오픈하는 경우가 일반적이므로, 경우라면, RPC 위한 동적매퍼설정시 firewall 안에 위치한 서버에만 적용해도 가능하다. 그렇지 않은 경우에는 RPC bidirectional traffic 갖기 때문에 양방향 고려가 있어야 한다.

 

 

 


덧글

댓글 입력 영역