Я системный администратор в библиотеке в Голландии. Наш персонал использует тонкие клиенты, которые создают сеанс удаленного рабочего стола для наших серверов сеансов. У нас есть два сервера сеансов (Windows 2008 R2), настроенных в кластере NLB. Оба сервера виртуализированы. Один вHyper-V (RDS01)другой вVMWare ESX (RDS03).
Кластер NLB настроен на работу в одноадресном режиме. Оба сервера в кластере NLB имеют два сетевых адаптера. Один для кластера NLB, а другой для использования в одноранговой связи.
Проблема, с которой мы сталкиваемся, заключается в том, что частое создание сеанса удаленного рабочего стола для нашего кластера NLBтерпит неудачу(та же ошибка, что и при попытке подключиться к несуществующему IP или имени хоста). После некоторых раскопок я обнаружил, что когда я пытаюсь просмотреть кластер в NLB manager на RDS03, он часто не может "обнаружить" RDS01. Обратный путь работает отлично (с RDS01 на RDS03).
На рисунке 1 ниже показан диспетчер NLB на RDS01 (УСПЕХ).
На рисунке 2 ниже показан диспетчер NLB на RDS03 (НЕУДАЧА).
Как вы можете видеть на первой картинке, я отключил RDS03 в кластере NLB. Только RDS01 является активным сервером в кластере NLB. Эторешаетпроблема с подключением к кластеру NLB на данный момент (поэтому я предполагаю, что проблема связана с RDS03).
Я узнал, что NLB Manager использует ICMP для «обнаружения» других хостов в кластере. Поэтому я решил использовать анализатор пакетов (Microsoft Network Monitoring) для проверки пакетов, отправляемых NLB Manager. И я заметил в пакете, отправляемом RDS01, что он использует IP-адрес адаптера Peer-to-Peer на RDS03. В дополнение к этому, RDS03иногдаиспользует IP-адрес кластера NLB RDS01.
Ниже приведены сведения о пакете, полученные с помощью 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 Managers отправляет этот пакет, обнаружение не удается.
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 Manager отправляет этот пакет, обнаружение успешно.
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
Ниже приведена конфигурация IP для кластера NLB и его серверов.
10.81.129.165...IP-адрес кластера NLB
10.81.129.167...NLB IP для RDS01
10.81.129.169...NLB IP для RDS03
10.81.129.159...IP RDS01 (вторая сетевая карта для одноранговой сети)
10.81.129.161...IP RDS03 (вторая сетевая карта для одноранговой сети)
Почему RDS03 использует IP-адрес кластера NLB RDS01? И почему он также использует одноранговый IP-адрес RDS01? Что вызывает это непоследовательное поведение?
решение1
Отвечая на свой собственный вопрос, проблема была в поиске DNS. После того, как я очистил кэш DNS на RDS03 (где и возникло непоследовательное поведение).
ipconfig /flushdns
Я выполнил обновление кластера на RDS03 NLB Manager и заметил, что он выполнил DNS-поиск для RDS01. Теперь я точно знал, что NLB Manager использует имена хостов для связи. DNS-сервер ответил двумя следующими IP-адресами:
10.81.129.159 ...IP-RDS01(второй сетевой адаптер для одноранговой сети)
10.81.129.167 ...NLB IP для RDS01
Каждый раз, когда открытие RDS01 терпело неудачу,NLB IP RDS01был первым IP ответа поиска DNS. И каждый раз, когда открытие успешноIP-RDS01был первым.
После удаленияNLB IP RDS01DNS-запись с DNS-сервера, проблема была решена. Теперь мне оставалось только убедиться, что IP-адреса NLB больше не будут регистрироваться на DNS-сервере. Это была настройка в протоколе TCP/IP NLB NIC. Смотрите изображение ниже.
