Tijd issues met clients

[Remi]

In ons bedrijfsnetwerk hebben de clients regelmatig last van afwijkingen in datum en tijd. Het gaat dan niet om seconden maar meestal weken tot maanden verschil ten opzichte van de werkelijke tijd. Het probleem lijkt zich compleet willekeurig voor te doen en soms heeft een client ook weken geen last. Het doet zich sowieso voor sinds de opbouw van het netwerk en alle clients hebben last van dit issue.

Vanwege de werkzaamheden die verricht worden is het netwerk fysiek compleet afgesloten van de wereld dus een online timeserver is sowieso niet voorhanden. Het netwerk ziet er als volgt uit:

1 fysieke bak met Windows 7 (pro) SP1 waarop een virtuele (virtualbox) Windows 2003 server actief is die als DC werkt.
6 fysieke clients met Windows 10 en 1 met Windows 7 (verschillende hardware configs)

Daar ik het netwerk niet heb ontworpen kan ik niks zeggen over de gemaakte keuzes of efficiëntie daarvan.
Voorop staat dat een correcte datum en tijd op ons platform cruciaal zijn voor ons werkveld dus als er wijzigingen moeten gebeuren in de opbouw dan is dit geen probleem.

Alle clients hangen in het het domein en geven aan hun time te syncen met de DC. De W2k3 server staat te draaien als NTP server en heb ik nog nooit kunnen betrappen op afwijkingen.

Uiteraard heb ik de afgelopen maanden al het e.e.a. getest aan de hand vergelijkbare problemen die ik heb gevonden op internet maar het probleem blijft zich voordoen. Op internet lees ik terug dat het probleem best veroorzaakt kan worden door het feit dat de DC als VM is opgezet maar dat er ook partijen zijn die dit probleemloos hebben draaien.

In de eventlogs van een client heb ik de volgende gegevens aangetroffen van zo'n recente afwijking.

code:

31-10-2016 15:46:57
The time service is now synchronizing the system time with the time source DC SERVER (ntp.d|0.0.0.0:123->192.168.10.5:123).
17-10-2016 15:00:43
The time service has detected that the system time needs to be  changed by 1216305 seconds. The time service will not change the system time by more than 4294967295 seconds. Verify that your time and time zone are correct, and that the time source DC SERVER (ntp.d|0.0.0.0:123->192.168.10.5:123) is working properly.
17-10-2016 17:00:11
The time service detected a time difference of greater than 5000 milliseconds for 900 seconds. The time difference might be caused by synchronization with low-accuracy time sources or by suboptimal network conditions. The time service is no longer synchronized and cannot provide the time to other clients or update the system clock. When a valid time stamp is received from a time service provider, the time service will correct itself.

Heeft iemand een idee hoe dit probleem met de huidige setup kan worden opgelost?

[marccom]

Is je DC / onderliggende host af en toe druk qua cpu/mem gebruik? Zien hier op onze virtuele Windows systemen dat de tijd gaat afwijken wanneer de onderliggende server (in ons geval een Centos systeem) het druk krijgt en dan is de enige optie nog om ze goed te krijgen een handmatige sync starten (net time \\dc /set /yes).
Gebruikt je DC een externe NTP server?

[Remi]

marccom schreef op dinsdag 01 november 2016 @ 10:50:
Is je DC / onderliggende host af en toe druk qua cpu/mem gebruik? Zien hier op onze virtuele Windows systemen dat de tijd gaat afwijken wanneer de onderliggende server (in ons geval een Centos systeem) het druk krijgt en dan is de enige optie nog om ze goed te krijgen een handmatige sync starten (net time \\dc /set /yes).
Gebruikt je DC een externe NTP server?

Niet dat ik hier een constante monitoring heb draaien maar ik heb de systemen nog nooit kunnen betrappen op load. Het zijn maar een paar clients die tegen de DC praten en meer is er niet actief. Een afwijking in datum en tijd op de host/VM heb ik ook nog niet gezien. Het zijn puur de clients die willekeurig van datum en tijd wijzigen.

Zoals aangegeven gaat het om een offline (fysiek afgescheiden) netwerk die dus geen externe NTP kan benaderen.

[ Voor 8% gewijzigd door Remi op 01-11-2016 10:59 ]

[Fanatix]

Hoe zit het met de datum/tijd op de Windows 7 machine waar je VirtualBox op hebt geinstalleerd? Draait deze wel goed? En synchroniseert deze soms ook met jouw DC?
Het zou namelijk kunnen zijn dat jouw 2003 VM via VirtualBox zijn datum/tijd weer synchroniseert met de onderliggende host (de Windows 7 machine).

[Dennism]

Afgezien van het feit dat dit een extreem hobby bob opgezette situatie lijkt, 2003 virtueel via Virtualbox op een Windows 7 desktop als Domaincontroller, hoe verzin je het zou ik bijna zeggen.

Hoewel het niet je hoofd issue is, zou ik zeker zorgen dat daar wat aangedaan wordt, voor de continuïteit van het bedrijf kan dit eigenlijk geen wenselijke situatie zijn. Windows 2003 is al een flinke tijd uit support, en het draaien van een server OS virtueel op een desktop machine in een productie omgeving nu ook niet echt best practise om het aardig te zeggen. Ik weet niet hoe de backups geregeld zijn, maar voor mij ziet dit er uit als een recipe for disaster.

Om je issue op te lossen gezien je aangeeft dat de Timesync echt van groot belang is zou ik kijken naar een NTP appliance die op basis van GPS de tijd bepaald, deze kunnen zonder internet hun werk doen, waarna je er voor kan zorgen dat de DC met deze appliance synchroniseert en de andere machines in het netwerk met de DC, of dat alle machines met de Appliance syncen.

Zorg er verder uiteraard voor dat op de DC de NTP server correct is ingesteld en geconfigureerd en dat ook de clients correct zijn geconfigureerd om de tijd te syncen. Mogelijk dat hier momenteel iets misgaat, en de clients met een andere bron dan de NTP server syncen (bijv. de bios clock). Zie bijv. hier http://theitbros.com/configure-ntp-time-sync-group-policy/

[CAPSLOCK2000]

NTP en virtualisatie is inderdaad een probleem. NTP probeert het gedrag van je hardware te modelleren en corrigeert op grond daar van voortdurend je klok. NTP snapt niet dat de hardware virtueel is en dus niet 100% van de tijd draait en dat gaat gruwelijk mis. Je virtualisatie omgeving draait aan de klok om te verbergen dat de VM de processor moet delen met andere VMs en tegelijkertijd draait NTP ook aan de klok. Met een beetje pech loopt dat helemaal uit de hand omdat NTP steeds harder gaat proberen om te compenseren voor deze verschillen.

Iedere leverancier van virtualisatiesoftware heeft documentatie met instructies over hoe je hier mee om moet gaan. De vuistregel is dat er één systeem de baas moet zijn over de klok en dat de rest er van af moet blijven.

Het gebruik van een radioklok lijkt me niet nodig. In een gesloten omgeving ben je immers niet geinteresseerd in de echte tijd, het gaat er vooral om dat alle klokken binnen die omgeving gelijk lopen.

[KillerAce_NL]

Een virtuele DC die fungeert als timeserver mag je nooit laten syncen met de host waarop de vm draait.
Dit omdat je door cpu overcommitment time-drift krijgt.
Laat je dc syncen met een een externe time server/device, extern als in niet op de hardware bak.

[vso]

KillerAce_NL schreef op dinsdag 01 november 2016 @ 13:19:
Een virtuele DC die fungeert als timeserver mag je nooit laten syncen met de host waarop de vm draait.
Dit omdat je door cpu overcommitment time-drift krijgt.
Laat je dc syncen met een een externe time server/device, extern als in niet op de hardware bak.

Niet helemaal waar,

1) daar hem je de virtuele tools voor die deze NTP timedrift corigeert
2) overcommit kan je counteren door een CPU te dedicaten/niet over commiten.

Maar een externe NTP server kan wel praktisch zijn.

Als de BIOS datum/tijd niet correct staat zal een VM die als eerste overnemen, dan de Virtualisatie laag en dan de VM zelf. dus in alle stappen is het raadzaam om ze te controlleren.
Indien nodig de bios batterij vervangen.

[KillerAce_NL]

Dan nog, ga je dat professioneel niet zo doen.
Maar goed, deze oplossing rammelt sowieso aan alle kanten, nachtmerrie qua management.

Deze afwijking is natuurlijk extreem, hier is op meerdere fronten waarschijnlijk iets mis.
Dagen tijdsverschil in 2 uur, kan natuurlijk niet.

[Dennism]

CAPSLOCK2000 schreef op dinsdag 01 november 2016 @ 13:15:

Het gebruik van een radioklok lijkt me niet nodig. In een gesloten omgeving ben je immers niet geinteresseerd in de echte tijd, het gaat er vooral om dat alle klokken binnen die omgeving gelijk lopen.

Dat ligt er natuurlijk maar aan, ik heb bijv. gesloten omgevingen mee gemaakt waar juist de "exacte" (niet 100% op de seconde exact) tijd wel van belang was, want van ieder product moest bekend en automatisch geregistreerd zijn op welk datum en tijdstip de productie afgerond was en daar mocht geen afwijking in zitten.