Ich bin Systemadministrator in einer Bibliothek in Holland. Unser Personal verwendet Thin Clients, die eine Remote-Desktop-Sitzung mit unseren Sitzungsservern durchführen. Wir haben zwei Sitzungsserver (Windows 2008 R2) in einem NLB-Cluster konfiguriert. Beide Server sind virtualisiert. Einer inHyper-V (RDS01)der andere imVMWare ESX (RDS03).
Der NLB-Cluster ist für den Unicast-Modus konfiguriert. Beide Server im NLB-Cluster verfügen über zwei Netzwerkadapter. Einer für den NLB-Cluster und der andere für die Peer-to-Peer-Kommunikation.
Das Problem, das wir haben, ist, dass eine Remote-Desktop-Sitzung zu unserem NLB-Cluster oftschlägt fehl(derselbe Fehler wie beim Verbindungsversuch mit einer nicht vorhandenen IP oder einem nicht vorhandenen Hostnamen). Nach einigem Suchen habe ich herausgefunden, dass beim Versuch, den Cluster im NLB-Manager auf RDS03 anzuzeigen, RDS01 häufig nicht „erkannt“ wird. Umgekehrt funktioniert es problemlos (von RDS01 zu RDS03).
Bild 1 unten zeigt den NLB Manager auf RDS01 (ERFOLG).
Bild 2 unten zeigt den NLB Manager auf RDS03 (SCHEITERN).
Wie Sie auf dem ersten Bild sehen können, habe ich den RDS03 im NLB-Cluster deaktiviert. Nur RDS01 ist der aktive Server im NLB-Cluster. Dieslöstdas Verbindungsproblem zum NLB-Cluster im Moment (also gehe ich davon aus, dass das Problem beim RDS03 liegt).
Ich habe erfahren, dass der NLB-Manager ICMP verwendet, um andere Hosts im Cluster zu „entdecken“. Daher habe ich beschlossen, einen Paket-Sniffer (Microsoft Network Monitoring) zu verwenden, um die vom NLB-Manager gesendeten Pakete zu überprüfen. Und mir ist aufgefallen, dass das vom RDS01 gesendete Paket die IP-Adresse des Peer-to-Peer-Adapters auf dem RDS03 verwendet. Darüber hinaus verwendet der RDS03Manchmalverwendet die NLB-Cluster-IP-Adresse von RDS01.
Nachfolgend die auf dem RDS01 erfassten Paketdetails.
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
Als nächstes die auf dem RDS03 erfassten Paketdetails. Wenn der NLB-Manager dieses Paket sendet, schlägt die Erkennung fehl.
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
Zuletzt die auf dem RDS03 erfassten Paketdetails. Wenn der NLB-Manager dieses Paket versendet, ist die Erkennung erfolgreich.
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
Nachfolgend die IP-Konfiguration für den NLB-Cluster und seine Server.
10.81.129.165...NLB-Cluster-IP
10.81.129.167...NLB-IP für RDS01
10.81.129.169...NLB-IP für RDS03
10.81.129.159...IP RDS01 (zweite Netzwerkkarte für Peer-to-Peer)
10.81.129.161...IP RDS03 (zweite Netzwerkkarte für Peer-to-Peer)
Warum verwendet RDS03 die NLB-Cluster-IP von RDS01? Und warum verwendet es auch die Peer-to-Peer-IP von RDS01? Was verursacht dieses inkonsistente Verhalten?
Antwort1
Um meine eigene Frage zu beantworten: Das Problem lag bei der DNS-Suche. Nachdem ich den DNS-Cache auf dem RDS03 geleert hatte (wo das inkonsistente Verhalten auftrat).
ipconfig /flushdns
Ich habe eine Clusteraktualisierung auf dem RDS03 NLB Manager durchgeführt und festgestellt, dass eine DNS-Suche nach RDS01 durchgeführt wurde. Jetzt wusste ich mit Sicherheit, dass der NLB Manager Hostnamen zur Kommunikation verwendete. Der DNS-Server antwortete mit den folgenden beiden IP-Adressen:
10.81.129.159 ...IP-RDS01(zweite Netzwerkkarte für Peer-to-Peer)
10.81.129.167 ...NLB-IP für RDS01
Jedes Mal, wenn die Erkennung von RDS01 fehlschlug,NLB-IP von RDS01war die erste IP der DNS-Suchantwort. Und jedes Mal, wenn die Erkennung erfolgreich war,IP-RDS01war zuerst.
Nach dem Entfernen derNLB-IP von RDS01DNS-Eintrag vom DNS-Server, das Problem war gelöst. Jetzt musste ich nur noch sicherstellen, dass sich die NLB-IP-Adressen nicht mehr beim DNS-Server registrieren. Dies war eine Einstellung im TCP/IP-Protokoll der NLB-NIC. Siehe das Bild unten.
