RPCping hoge latency van HyperV server naar VM

[Tijntje]

In mijn omgeving heb ik een HyperV server deze draait 4 hosts alles is Windows 2012 R2 met de laatste updates.
Nu heb ik regelmatig in mijn Server Manager een Target Name resolution error naar Server1.


Dan krijg ik ook dit soort errors in mijn Event Log

Verder is het system log netjes schoon.

Het vreemde is als ik vanuit deze HyperV server een nslookup doe naar de host in kwestie dit geen enkel probleem is.

code:

C:\Windows\system32>nslookup
Default Server:  dc1.home.lan
Address:  192.168.2.2

> server1
Server:  dc1.home.lan
Address:  192.168.2.2

Name:    server1.home.lan
Address:  192.168.2.4

Ook het pingen is geen enkel probleem.

code:

Pinging server1.home.lan [192.168.2.4] with 32 bytes of data:
Reply from 192.168.2.4: bytes=32 time<1ms TTL=128

Waar het vreemd wordt is dat een RPC ping vanaf de HyperV naar Server1 heel traag is.

code:

C:\Windows\system32>rpcping -s server1
Completed 1 calls in 21047 ms
0 T/S or 21047.000 ms/T

De zelfde ping vanuit de Server1 naar de HyperV is gewoon snel.

code:

C:\Windows\system32>rpcping -s hyperv
Completed 1 calls in 16 ms
62 T/S or  16.000 ms/T

Een zelfde ping vanuit een andere virtuele host naar de Server1 is ook snel

code:

C:\Windows\system32>rpcping -s server1
Completed 1 calls in 16 ms
62 T/S or  16.000 ms/T

Soms werkt het ineens weer zoals het hoort maar na een dag heb ik vaak weer de zelfde problemen.

[ Voor 4% gewijzigd door Tijntje op 21-02-2015 19:21 ]

[Tijntje]

Heb het probleem weer dus de rpc ping waarde even bijgevoegd.

[Turdie]

Wat wil je precies testen met RPCPing? Met andere woorden, welk probleem heb je dat je RPCPing nodig hebt?

[Tijntje]

Het probleem is dat al het RPC verkeer tussen deze twee host enorm traag wordt waardoor onder andere hij een timeout krijgt in de Server Manager. Normaal Ping verkeer en SMB verkeer lijkt geen hinder te ondervinden.

[Brahiewahiewa]

Aannemende dat dc1.home.lan ook virtueel is, is die altijd bereikbaar?
En heb je op de HyperV misschien 2 dns-servers geconfigureerd?

[Tijntje]

Ja DC1 is inderdaad virtueel maar altijd als eerste beschikbaar.
Op de HyperV zijn 2 DNS servers ingevuld:
Namelijk de DC1 als primaire en 8.8.8.8 als secundair.
Een nslookup van de servers gaat overigens wel altijd goed.

[Brahiewahiewa]

Tijntje schreef op woensdag 25 februari 2015 @ 12:51:
...Op de HyperV zijn 2 DNS servers ingevuld:
Namelijk de DC1 als primaire en 8.8.8.8 als secundair...

Configureer dat nou ff goed: 8.8.8.8 als forwarder op de DNS server van dc1 en op de hyperV maar één DNS server: dc1
't Probleem is gewoon dat RPC je interne servers niet kan resolven via 8.8.8.8

[Tijntje]

Brahiewahiewa schreef op woensdag 25 februari 2015 @ 13:30:
[...]

Configureer dat nou ff goed: 8.8.8.8 als forwarder op de DNS server van dc1 en op de hyperV maar één DNS server: dc1
't Probleem is gewoon dat RPC je interne servers niet kan resolven via 8.8.8.8

De primaire DNS is altijd aanwezig dus zou hij nooit naar de secundaire moeten gaan.
Heb overigens wel even voor de zekerheid de 8.8.8.8 verwijderd aangezien die ook niet nodig is en enkel nog aanwezig was vanuit de installatie.
De DNS werkte al met forwarders

[ Voor 11% gewijzigd door Tijntje op 25-02-2015 13:43 ]

[Widow]

Die secundaire DNS word alleen gebruikt als de primaire DNS server niet bereikbaar is. Ook als je primaire DNS server het antwoord geeft dat hij een hostname niet kan resolven, zal je client niet naar de secundaire DNS gaan om het daar te vragen. Dat doet je client _alleen_ als de primaire DNS niet bereikbaar is.

[ZeroCode]

Toevallig geen Intel netwerkkaarten erin? Ik had ook wazige problemen met mijn HyperV server, bleek ik een broadcom cheapo netwerkkaart erin te hebben welke af en toe de verbinding dropte. Het probleem trad alleen op als ik de virtuele netwerkkaart gebruikte ipv de legacy netwerkkaart.

Alles was opgelost met een intel netwerkkaart welke tcp offloading e.d. ondersteunde. Weken naar gezocht...

[johnkeates]

Wat gebeurt er als je gewoon gaat debuggen en kijkt waar het probleem ligt? Dus Wireshark er op en packets opslaan zodat je kan zien wat je server uitvreet. Gokken en gissen en op knopjes drukken in de hoop dat dat je probleem is heeft natuurlijk niet altijd even veel zin.

Bij een probleem moet je gewoon onderzoeken, en het probleem oplossen. Dat begint inderdaad bij je logs, maar als je daar niet verder mee komt moet je dus zelf gaan kijken. Voor je netwerk is dat een packet capture regelen en live of offline uitzoeken wie wat doet en wat er gebeurt. Stel dat er niks mis blijkt te zijn maar de error door wat anders veroorzaakt wordt kan je weer verder gaan, bijvoorbeeld kijken welke calls de software zit te maken, misschien dat daar wel wat mis gaat.

[Killah_Priest]

Maar welk probleem ervaart de TS precies?
Het komt op mij over dat je geen probleem ervaart behalve een bepaald event wat af en toe (blijkbaar onterecht) naar voren popt in de server manager.

[Tijntje]

Het probleem is dat in de Server Manager de SERVER1 als onbereikbaar verschijnt en niet meer te managen is.
Verder lijkt alles normaal te blijven functioneren, het SMB netwerk verkeer vanuit HYPERV naar SERVER1 blijft bijvoorbeeld gewoon werken.
Het is dus op zich geen ramp echter kan ik het niet uitstaan dat er iets niet goed werkt.

[Question Mark]

Widow schreef op woensdag 25 februari 2015 @ 15:33:
Die secundaire DNS word alleen gebruikt als de primaire DNS server niet bereikbaar is. Ook als je primaire DNS server het antwoord geeft dat hij een hostname niet kan resolven, zal je client niet naar de secundaire DNS gaan om het daar te vragen. Dat doet je client _alleen_ als de primaire DNS niet bereikbaar is.

De grap is nu net dat de primaire dns-server van TS virtueel is, en tijdens het booten van de host niet beschikbaar is. Op dat moment gaat de Hyper-V host dus al naar zijn secundaire dns-server.

Het ligt er ook aan of een host multi-homed is, met dns-servers ingesteld op meerdere adapters. In dat geval worden nl. ook bij een negatieve response van een dns-server op adapter A, de dns-server(s) op adapter B uitgevraagd. Dat scenario speelt hier overigens waarschijnlijk niet.

Verder gebruikt de dns-client service ook nog eens een algoritme die ook rekening houdt met response tijden van dns-servers.

DNS Processes and Interactions

The DNS Client service keeps track of which servers answer name queries more quickly, and it moves servers up or down on the list based on how quickly they reply to name queries.

Je kunt niet zomaar stellen welke dns-server door een client gebruikt wordt. Ja, er zit een volgordelijkheid in, maar die kan aangepast worden door het systeem.

[ Voor 10% gewijzigd door Question Mark op 26-02-2015 09:23 ]

[Tijntje]

Question Mark schreef op donderdag 26 februari 2015 @ 09:14:
[...]

De grap is nu net dat de primaire dns-server van TS virtueel is, en tijdens het booten van de host niet beschikbaar is. Op dat moment gaat de Hyper-V host dus al naar zijn secundaire dns-server.

Het ligt er ook aan of een host multi-homed is, met dns-servers ingesteld op meerdere adapters. In dat geval worden nl. ook bij een negatieve response van een dns-server op adapter A, de dns-server(s) op adapter B uitgevraagd. Dat scenario speelt hier overigens waarschijnlijk niet.

Verder gebruikt de dns-client service ook nog eens een algoritme die ook rekening houdt met response tijden van dns-servers.

DNS Processes and Interactions

[...]


Je kunt niet zomaar stellen welke dns-server door een client gebruikt wordt. Ja, er zit een volgordelijkheid in, maar die kan aangepast worden door het systeem.

Opzich ben ik het met je eens maar dat verklaart niet waarom een nslookup, SMB file copy, ping, etc allemaal blijven werken en een rpcping niet.
Zoals eerder aangegeven heb ik wel de 8.8.8.8 verwijderd omdat er ook geen noodzaak is om deze op de HyperV host beschikbaar te hebben.

Vanwege het feit dat de DC virtueel is heb ik een script wat een aantal services op de HyperV host herstart zodra de DC in de lucht is. Denk hierbij aan de netlogon, network location awareness en DNS.

[SirDarkAngel]

Probeert TCP offloading eens uit te zetten op je NICS.

[Wim-Bart]

Andere oplossing pas ik toe en werkt perfect. Gewoon op 1 of 2 HYPER-V dozen de DNS Server role installeren en deze Secondary maken van de Domain Controller maken voor je domein (zone). Deze hosts wel opnemen als NS record in de zone. Op je Hyper-V hosts 1e en 2e DNS opgeven waarbij 1e een Hyper-V host is met DNS role en de tweede een je DC VM.

Doordat een secondary DNS zone lokaal fysiek gecached is (dus er is altijd een kopie fysiek aanwezig op deze server) gaan name-lookups altijd goed en haal je bij booten de latency weg.

[Question Mark]

Dat betekend alleen wel dat je formeel gezien je Hyper-V hosts een licentie moet gaan toekennen, je gebruikt deze dan immers voor meer dan alleen het managen en hosten van Hyper-V workloads waardoor een licentie benodigt is.

[Wim-Bart]

Question Mark schreef op vrijdag 27 februari 2015 @ 21:32:
Dat betekend alleen wel dat je formeel gezien je Hyper-V hosts een licentie moet gaan toekennen, je gebruikt deze dan immers voor meer dan alleen het managen en hosten van Hyper-V workloads waardoor een licentie benodigt is.

Met datacenter licenties maakt dat allemaal niet uit :-)

[Question Mark]

True..

Overigens wel een goede tip. Vaak zie ik bij Hyper-V omgevingen vaak nog een fysieke DC staan om dergelijke problemen te voorkomen, maar dit kan ook een prima oplossing zijn.

[Tijntje]

Question Mark schreef op maandag 02 maart 2015 @ 08:34:
True..

Overigens wel een goede tip. Vaak zie ik bij Hyper-V omgevingen vaak nog een fysieke DC staan om dergelijke problemen te voorkomen, maar dit kan ook een prima oplossing zijn.

Als je al je DC's wil virtualiseren moet je wel op een aantal dingen letten.
Ik heb deze 2 artikelen als leidraad gebruikt:
http://www.altaro.com/hyp...controllers-part-1-myths/
http://www.altaro.com/hyp...trollers-part-2-practice/

Uiteindelijk heb ik op de virtuele DC een script neergezet die wordt uitgevoerd na het opstarten van de DC via een Scheduled task.
De volgende Services krijgen een schop:

• dnscache
• netlogon
• netprofm
• nlasvc
• WinRM

Overigens heb ik tot op heden met het weghalen van de 8.8.8.8 DNS nog geen problemen gehad.

[Question Mark]

Wat is de achterliggende gedachte van het herstarten van die services?

Je Hyper-V host is volledig up als je DC gaat opstarten, dat maakt dan totaal geen verschil met bv. een fysieke DC. Waarom dan handmatig services herstarten?

[Tijntje]

Question Mark schreef op maandag 02 maart 2015 @ 16:21:
Wat is de achterliggende gedachte van het herstarten van die services?

Je Hyper-V host is volledig up als je DC gaat opstarten, dat maakt dan totaal geen verschil met bv. een fysieke DC. Waarom dan handmatig services herstarten?

Voor de duidelijkeheid, de virtuele DC is ook de enige DC.

Zonder het herstarten van de network services dacht de HyperV server dat hij in een Private Network profiel stond. Na de herstart van de services is dat netjes het Domain Profile.
De Netlogon had te maken met een aantal authenticatie problemen, deze loste zich zelf na verloop van tijd wel op echter hoef ik daar zo niet op te wachten.

[ Voor 4% gewijzigd door Tijntje op 09-03-2015 14:54 ]