Ich bin ein Systemadministrator in einer Bibliothek in Holland. Unser Personal verwendet Thin Clients, die eine Remotedesktopsitzung mit unseren Sitzungsservern durchführen. In einem NLB-Cluster sind zwei Sitzungsserver (Windows 2008 R2) konfiguriert. Beide Server sind virtualisiert. Eins in Hyper-V (RDS01) der andere in VMWare ESX (RDS03) .
Der NLB-Cluster ist für den Unicast-Modus konfiguriert. Beide Server im NLB-Cluster verfügen über zwei Netzwerkadapter. Eine für den NLB-Cluster und die andere für die Peer-to-Peer-Kommunikation.
Das Problem ist, dass wir häufig eine Remotedesktopsitzung mit unserem NLB-Cluster durchführen scheitert (der gleiche Fehler wie beim Versuch, eine Verbindung zu einer nicht vorhandenen IP-Adresse oder einem nicht vorhandenen Hostnamen herzustellen). Nach einigem Durchsuchen stellte ich fest, dass der Cluster im NLB-Manager auf RDS03 RDS01 häufig nicht "erkennt". Der umgekehrte Fall funktioniert einwandfrei (von RDS01 bis RDS03).
Bild 1 zeigt den NLB Manager auf RDS01 ( ERFOLG ). 
Bild 2 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. Diese löst das Verbindungsproblem mit dem NLB-Cluster für jetzt (also ich nehme an, das Problem liegt um den RDS03).
Ich habe erfahren, dass der NLB-Manager ICMP verwendet, um andere Hosts im Cluster zu "erkennen". Daher habe ich mich für einen Paket-Sniffer (Microsoft Network Monitoring) entschieden, um die vom NLB-Manager gesendeten Pakete zu überprüfen. Und im Paket, das vom RDS01 gesendet wird, ist mir aufgefallen, dass es die IP-Adresse des Peer-to-Peer-Adapters auf dem RDS03 verwendet. Darüber hinaus ist der RDS03 manchmal Verwendet die NLB-Cluster-IP-Adresse von RDS01.
Unten 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 werden die Paketdetails auf dem RDS03 erfasst. Wenn die NLB-Manager dieses Paket senden, schlägt die Ermittlung 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
Als letztes die auf dem RDS03 erfassten Paketdetails. Wenn der NLB-Manager dieses Paket sendet, ist die Ermittlung 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
Unten 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 (zweiter NIC für Peer-to-Peer)
10.81.129.161 ... IP RDS03 (zweiter NIC für Peer-to-Peer)
Warum verwendet der RDS03 die NLB-Cluster-IP von RDS01? Und warum wird auch die Peer-to-Peer-IP von RDS01 verwendet? Was verursacht dieses inkonsistente Verhalten?
quelle
Antworten:
Um meine eigene Frage zu beantworten, lag das Problem in der DNS-Suche. Nachdem ich den DNS-Cache auf dem RDS03 geleert habe (wo das inkonsistente Verhalten aufgetreten ist).
Ich habe eine Clusteraktualisierung im RDS03-NLB-Manager durchgeführt und festgestellt, dass ein DNS-Lookup für RDS01 durchgeführt wurde. Jetzt wusste ich, dass der NLB-Manager Hostnamen für die Kommunikation verwendete. Der DNS-Server hat mit den beiden folgenden IP-Adressen geantwortet:
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 Entdeckung von RDS01 fehlschlug, schlug die NLB IP von RDS01 war die erste IP der DNS-Lookup-Antwort. Und jedes Mal, wenn die Entdeckung erfolgreich war IP RDS01 war zuerst.
Nach dem Entfernen der NLB IP von RDS01 DNS-Eintrag vom DNS-Server Das Problem wurde behoben. 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-Netzwerkkarte. Siehe das Bild unten.
quelle