NLB 클러스터의 피어 - 투 - 피어 통신


1

저는 네덜란드 도서관의 시스템 관리자입니다. 직원들은 씬 클라이언트를 사용하여 세션 서버에 대한 원격 데스크톱 세션을 만듭니다. NLB 클러스터에 두 개의 세션 서버 (Windows 2008 R2)가 구성되어 있습니다. 두 서버 모두 가상화되었습니다. 하나의 Hyper-V (RDS01) 다른 하나는 VMWare ESX (RDS03) .

NLB 클러스터는 유니 캐스트 모드로 작동하도록 구성됩니다. NLB 클러스터의 두 서버에는 두 개의 네트워크 어댑터가 있습니다. 하나는 NLB 클러스터 용이고 다른 하나는 피어 - 투 - 피어 통신 용입니다.

우리가 겪고있는 문제는 종종 NLB 클러스터에 대한 원격 데스크톱 세션을 만드는 것입니다. 실패하다 (기존 IP 또는 호스트 이름에 연결하려고 시도하는 것과 같은 오류). 내가 RDS03의 NLB 관리자에서 클러스터를 보려고 할 때 RDS01을 "발견"하지 못하는 것으로 밝혀졌습니다. 다른 방법은 잘 작동합니다 (RDS01에서 RDS03까지).

아래 그림 1은 RDS01의 NLB 관리자를 보여줍니다 ( 성공 ). NLB Manager on RDS01

아래 그림 2는 RDS03의 NLB 관리자 ( 실패 ). NLB Manager on RDS03

첫 번째 그림에서 알 수 있듯이 NLB 클러스터에서 RDS03을 사용하지 않도록 설정했습니다. RDS01 만 NLB 클러스터의 활성 서버입니다. 이 해결하다 지금 NLB 클러스터 연결 문제 (그래서 문제가 RDS03 주위에 있다고 가정 함).

NLB 관리자가 ICMP를 사용하여 클러스터의 다른 호스트를 "검색"한다는 것을 알게되었습니다. 그래서 패킷 스니퍼 (Microsoft Network Monitoring)를 사용하여 NLB 관리자가 보내는 패킷을 검사하기로 결정했습니다. 그리고 패킷에서 RDS01이 전송하는 것으로 RDS03에서 피어 - 투 - 피어 어댑터의 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 (피어 투 피어의 두 번째 NIC)
10.81.129.161 ... IP RDS03 (피어 투 피어의 두 번째 NIC)

왜 RDS03은 RDS01의 NLB 클러스터 IP를 사용합니까? 왜 RDS01의 피어 - 투 - 피어 IP도 사용합니까? 이 모순 된 행동의 원인은 무엇입니까?


나는 불규칙한 행동의 원인을 발견했다. 분명히 NLB Manager는 검색 프로세스에서 호스트 이름을 사용합니다. 우리의 DNS 서버가 RDS03의 IP 주소로 응답 할 때 IP 주소 순서 차이. RDS01 용 NLB IP가 처음 인 경우 검색이 실패합니다. IP RDS01 (피어 투 피어의 두 번째 NIC)이 처음 발견되면 검색이 성공합니다. 또한 RDS03에서 NDS IP를 Ping 할 수 없습니다.
Charlie Vieillard

답변:


0

내 자신의 질문에 대답하기 위해 문제는 DNS 조회에있었습니다. RDS03에서 DNS 캐시를 지운 후에 (일관성없는 동작이 발생한 곳)

ipconfig /flushdns

RDS03 NLB 관리자에서 클러스터 새로 고침을 수행하고 RDS01에 대한 DNS 조회를 수행 한 것으로 나타났습니다. 이제 NLB 관리자가 호스트 이름을 사용하여 통신하고 있는지 확인했습니다. DNS 서버는 다음 두 IP 주소로 응답했습니다.

10.81.129.159 ... IP RDS01 (피어 - 투 - 피어의 두 번째 NIC)
10.81.129.167 ... RDS01 용 NLB IP

RDS01의 발견이 실패 할 때마다 RDS01의 NLB IP DNS 조회 응답의 첫 번째 IP입니다. 그리고 발견이 성공할 때마다 IP RDS01 처음이었다.

제거한 후 RDS01의 NLB IP 문제가 해결 된 DNS 서버의 DNS 레코드 이제는 NLB IP 주소가 더 이상 DNS 서버에 등록되지 않도록해야했습니다. 이것은 NLB NIC의 TCP / IP 프로토콜 설정입니다. 아래 이미지를 참조하십시오.

Don't register IP at DNS server

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.