저는 네덜란드 도서관의 시스템 관리자입니다. 우리 직원은 세션 서버에 대한 원격 데스크톱 세션을 만드는 씬 클라이언트를 사용합니다. NLB 클러스터에 두 개의 세션 서버(Windows 2008 R2)가 구성되어 있습니다. 두 서버 모두 가상화되었습니다. 하나에하이퍼-V(RDS01)다른 하나는VMWare ESX(RDS03).
NLB 클러스터는 유니캐스트 모드에서 작동하도록 구성됩니다. NLB 클러스터의 두 서버에는 두 개의 네트워크 어댑터가 있습니다. 하나는 NLB 클러스터용이고 다른 하나는 피어 투 피어 통신에 사용됩니다.
우리가 겪고 있는 문제는 NLB 클러스터에 대한 원격 데스크톱 세션을 자주 만드는 것입니다.실패하다(기존 IP 또는 호스트 이름이 아닌 연결을 시도하는 것과 동일한 오류) 몇 가지 조사 끝에 RDS03의 NLB 관리자에서 클러스터를 보려고 할 때 RDS01을 "발견"하지 못하는 경우가 많다는 사실을 알게 되었습니다. 다른 방법은 RDS01에서 RDS03까지 잘 작동합니다.
아래 그림 1은 RDS01의 NLB 관리자를 보여줍니다(성공).
아래 그림 2는 RDS03의 NLB 관리자를 보여줍니다(실패하다).
첫 번째 그림에서 볼 수 있듯이 NLB 클러스터에서 RDS03을 비활성화했습니다. RDS01만이 NLB 클러스터의 활성 서버입니다. 이것해결하다지금은 NLB 클러스터에 대한 연결 문제입니다(따라서 RDS03에 문제가 있다고 가정합니다).
NLB 관리자가 ICMP를 사용하여 클러스터의 다른 호스트를 "검색"한다는 것을 알게 되었습니다. 그래서 나는 NLB 관리자가 보내는 패킷을 검사하기 위해 패킷 스니퍼(Microsoft 네트워크 모니터링)를 사용하기로 결정했습니다. 그리고 RDS01이 보내는 패킷에서 RDS03의 P2P 어댑터의 IP 주소를 사용한다는 사실을 발견했습니다. 그 외에도 RDS03때때로RDS01의 NLB 클러스터 IP 주소를 사용합니다.
RDS01에서 캡처된 패킷 세부 정보는 다음과 같습니다.
Frame: Number = 2812, Captured Frame Length = 74, MediaType = ETHERNET
+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-15-5D-63-97-23],SourceAddress:[00-15-5D-63-96-2B]
+ Ipv4: Src = 10.81.129.159, Dest = 10.81.129.161, Next Protocol = ICMP, Packet ID = 8406, Total IP Length = 60
+ Icmp: Echo Request Message, From 10.81.129.159 To 10.81.129.161
다음으로 RDS03에서 캡처된 패킷 세부 정보입니다. NLB 관리자가 이 패키지를 보내면 검색이 실패합니다.
Frame: Number = 211, Captured Frame Length = 74, MediaType = ETHERNET
+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[02-BF-0A-51-81-A5],SourceAddress:[00-15-5D-63-97-23]
+ Ipv4: Src = 10.81.129.161, Dest = 10.81.129.167, Next Protocol = ICMP, Packet ID = 11326, Total IP Length = 60
+ Icmp: Echo Request Message, From 10.81.129.161 To 10.81.129.167
마지막으로 RDS03에서 캡처된 패킷 세부 정보입니다. NLB 관리자가 이 패키지를 보내면 검색이 성공한 것입니다.
Frame: Number = 2095, Captured Frame Length = 74, MediaType = ETHERNET
+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-15-5D-63-96-2B],SourceAddress:[00-15-5D-63-97-23]
+ Ipv4: Src = 10.81.129.161, Dest = 10.81.129.159, Next Protocol = ICMP, Packet ID = 21180, Total IP Length = 60
+ Icmp: Echo Request Message, From 10.81.129.161 To 10.81.129.159
NLB 클러스터 및 해당 서버에 대한 IP 구성 아래.
10.81.129.165...NLB 클러스터 IP
10.81.129.167...RDS01용 NLB IP
10.81.129.169...RDS03용 NLB IP
10.81.129.159...IP RDS01(P2P용 두 번째 NIC)
10.81.129.161...IP RDS03(P2P용 두 번째 NIC)
RDS03이 RDS01의 NLB 클러스터 IP를 사용하는 이유는 무엇입니까? 그리고 왜 RDS01의 P2P IP도 사용합니까? 이렇게 일관되지 않은 동작을 일으키는 원인은 무엇입니까?
답변1
내 질문에 대답하자면 문제는 DNS 조회에 있었습니다. RDS03에서 DNS 캐시를 지운 후(일관되지 않은 동작이 발생한 곳)
ipconfig /flushdns
RDS03 NLB 관리자에서 클러스터 새로 고침을 수행했고 RDS01에 대한 DNS 조회를 수행한 것을 확인했습니다. 이제 NLB 관리자가 호스트 이름을 사용하여 통신하고 있다는 것을 확실히 알았습니다. DNS 서버는 다음 두 IP 주소로 응답했습니다.
10.81.129.159 ...IP RDS01(P2P용 두 번째 NIC)
10.81.129.167 ...RDS01용 NLB IP
RDS01 검색이 실패할 때마다RDS01의 NLB IPDNS 조회 응답의 첫 번째 IP였습니다. 그리고 발견이 성공할 때마다IP RDS01처음이었습니다.
제거한 후RDS01의 NLB IPDNS 서버의 DNS 레코드 문제가 해결되었습니다. 이제 NLB IP 주소가 더 이상 DNS 서버에 등록되지 않는지 확인하기만 하면 되었습니다. 이는 NLB NIC의 TCP/IP 프로토콜에 있는 설정입니다. 아래 이미지를 참조하세요.
