Onze tijdserver, een windows 2003 domain controller is. in de loop der tijd vooruit gaan lopen. We willen de tijd ongeveer een minuut of tien terug gaan zetten. Watvoor consequenties zou dit hebben voor de ESX servers en het virtual centre ? Er staan op iedere ESX server (3,5) twee NTP servers ingesteld, als eerste 127.127.1.0 en als tweede de domain controller.

ESX zal altijd de preferred (1e) pakken tenzij deze niet bereikbaar is.
Tijd aanpassen van je domain controller zal dus niet veel uithalen tenzij de 1e ntp server niet meer bereikbaar is.
Overigens, waarom stel je je domain controller ook niet via dezelfde ntp server in, dan heb je helemaal geen probleem.

Gebeuren er geen gekke dingen als de tijd van ESx server ineens 10 minuten terug gaat ? Misschien eerst eentje testen zonder actieve vm's. Doen ze onderling nog wat met deze tijd eigenlijk ? heartbeat oid ?

Regel 1: Zet NOOIT een domain controller terug in de tijd.

Wat ik eerder zou doen, is de domaincontroller een kwartiertje uitzetten. Windows is zo ingesteld dat bij het opstarten de tijd van het bios gevraagd wordt. In dit geval is dat de tijd van ESX host. Zorg dat je de ESX host dus op de juiste manier synct met de ntpservers.

Verder zou ik je adviseren om de timesync in alle VMs via de vmware tools te laten lopen. Inclusief de domain controller. Wel goed de artikelen doornemen hoe je dit moet doen, want je zult de w32time service uit moeten zetten. Op de domaincontroller is het nog wat complexer, nl hier moet je het server en client gedeelte van de time services apart instellen.

Waarom tijd via de vmware tools? Effe heeeeeel kort door de bocht want er zijn goede VMware whitepapers over die het exact uitleggen. Maar als een VM niks te doen heeft, kan het zijn dat ESX besluit om hem even niet aan de beurt te laten op de cpu. Het kan dan zijn dat de VM intern nog een aantal interrupts heeft liggen om de tijd met 1 sec op te hogen. Stel nu dat de VM opeens wel weer op de cpu mag spelen, dan heeft ie nog een aantal opdrachten staan die hij nu gaat uitvoeren. Bijv: 3x time update, 1x time sync via ntp, 5x time update.

Wat er vervolgens gebeurt is dat ie dus 3x de tijd bijwerkt, dan een sync doet en precies goed staat en dan nog eens 5x een update en dus opeens 5 seconden voorloopt.

De VMware tools voorkomen dit.

_________________
http://www.GabesVirtualWorld.com

Indeed, zet je ESX firewall open voor ntp, voeg hier een externe ntp pool in, vervolgens het vinkje aanzetten binnen iedere VM op je VMWare Tools dat je wilt syncen met je host.

Dan zal hij netjes de tijd gaan overnemen. Je kan op je host atlijd nog een tweede ntp erbij zetten mocht die down zijn dat je wel door kan syncen.

_________________
| Blog.vmpros.nl | Twitter | DBL | vExpert 2010/2011/2012 |

Domain controllers en tijd: Als de tijd meer dan 5 minuten afwijkt (of wordt aangepast) dan zullen er problemen onstaan met de toegang. Dit omdat kerberos, die gebruikt wordt voor de security iedere 5 minuten van key wijzigd.

Een unix machine (linux en ESX dus ook) is er niet op gemaakt om te stappen in de tijd. Als de tijd moet worden aangepast, zal ze herstart willen worden. Moet de tijd achteruit, dan eventueel wachten zodat ze geen tijd dubbel mee maakt.

Over ntp: Een msWindows domain controler draait standaard als sntp server, Simplifyed ntp. Dit houdt in dat ze niet zo nauwkeurig is als ze zou kunnen zijn en een aantal andere beperkingen. In theorie is de ntp installatie op een unix machine (linux en ESX dus ook) nauwkeuriger: Tot op de honderdste seconde is mogelijk, een windows machine tot op de tiende seconde.

Daarom zou ik de esx servers en eventuele andere unix/linux servers met elkaar (als 'peer') en 1 of 3 externe bronnen synchroniseren. Domaincontrollers kunnen daar ook in mee draaien maar die kunnen andere servers helaas niet als 'peer' instellen.

_________________
Wat automatisch gaat, gaat automatisch fout.

Nou wordt het nog wat ingewikkelder, want de domaincontrollers zijn nog niet gevirtualiseerd. Deze draaien met tweeen nog op eigen hardware. We hebben tevens een windows 2003 cluster (exchange 2003 + sql 2000) draaien en een Citrix xpe omgeving. Is het misschien een idee om de DCs eerst te virtualiseren ? De esx servers in te regelen met de tijd van een externe bron en vervolgens de domain controller de tijd van de esx server te laten pakken. En dan eventueel gehele cluster booten en citrix servers opnieuw starten en dat dan allemaal 's nachts... of win32time service pauzeren op cluster en citrix en weer starten als de dc op vmware up is.

p.s. ik heb ook bij MS al wat vragen uit staan...

Voor synchronisatie in het algemeen geldt dat je het beste met 1 of met 3 of meer klokken kan synchroniseren. Bij 2 klokken is namelijk niet duidelijk welke de beste is.
Daarnaast moet je altijd 1 protocol gebruiken om klokken te synchroniseren. Voor VMware gasten kan je kiezen voor de OS synchronisatie (ntp, sntp, windows-time of wat dan ook) of voor de vmware-tools sync.
Een msWindows domain controller zal altijd een sntp server willen zijn voor de leden van het domain. Een domain controller kan je daarom het beste NIET met vmware-time laten synchroniseren, maar netjes een externe ntp-klok opgeven. Dat kan dan weer wel de ntp klok van de host zijn.
Leden van een msWindows domain synchroniseren standaard vanuit het domain met het sntp protocol met de domain controllers. Ook hier bij voorkeur NIET de vmware-tools-time-sync gebruiken.

Voor wat het waard is: VMware houdt de bios klok bij maar als het OS die klok aanpast, dan zal die aanpassing ook worden bijgehouden. Installeer je msWindows, dan loopt de bios klok op de lokale tijd. Installeer je Linux, dan loopt de bios klok (standaard) op gmt of utc.
De vmware tools time instelling houdt de OS klok bij, dat is meestal NIET de bios klok. Het os synchroniseert tussen de os-klok en de bios klok.

Voor meer info: http://www.vmware.com/pdf/vmware_timekeeping.pdf

zal mij benieuwe of en wat voor antwoord die geven...

_________________
Wat automatisch gaat, gaat automatisch fout.

In het verleden stond altijd heel duidelijk dat het beste wat je kon doen is inderdaad je Vmware tools je timesync laten bijhouden.

De laatste keer dat ik het timekeeping pdf'je doorgenomen heb (+/- een maand geleden) staat het er al lang niet zo zwart/wit meer.

Persoonlijk heb ik genoeg rare dingen gezien met de Vmware Tools time sync. Dat servers ineens 15 minuten voorlopen etc. (ja, ntp was op de host gewoon goed geconfigureerd en werkte ook naar behoren).

Dat Servers ineens ver voor of achter gingen lopen heb ik met W32time service nog nooit gehad.

Dus lees het document inderdaad goed door.

_________________
Groeten,
Michiel

Met computers en dus ook met VMware en msWindows, moet je in de gaten houden dat er 2 dingen zijn die klok genoemd worden. Vaak zie je de termen 'timer' en 'wall clock'.

De timer was vroeger gewoon de kilo-herz of mega-herz klok. Later is dat een mili-seconden klok-interrupt geworden. Daarmee wordt deze klok ook wel de timer genoemt. Het is deze timer die bij VMware er voor zorgt dat de tijd in de gasten niet altijd goed loopt. Je zult begrijpen dat als deze timer op de gast met een zelfde frequentie loopt als op de host, dat het wel eens mis gaat. Details staan in het vmware-timekeeping document uitgelegd. Als de 'wall clock' op een gast vrij snel voor of achter gaat lopen, dan zal je de timer van de gast moeten verlagen (of van de host verhogen).

De 'wall clock' is geeft de (lokale) tijd aan. Dit is de tijd die gesynchroniseerd word met ntp en dergelijke. Als je de timer van de host en/of gast niet kan aanpassen, dan kan je het beste NTP gebruiken en dan zo instellen dat de centrale klok een broadcast doet en de gast daarmee synchroniseert. Dan wordt de tijd echt bijgehouden. Default zullen alle sync tools de client de tijd laten vragen. Als de klok echter veel te langzaam loopt, wordt ook niet vaak genoeg gesynchroniseerd.

_________________
Wat automatisch gaat, gaat automatisch fout.

Misschien voor deze of gene nog interessant;

Ik heb vorige week na een misconfiguratie bij een VI-3 omgeving van een klant het hele tijd sync verhaal (ESX + VM's + DC's) opnieuw ingericht. Hier heb ik gelijk een blogpost van gemaakt met de stappen en instellingen die ik hierbij heb ondernomen.

De post is te lezen op: http://www.robvanhamersveld.nl/?p=160

Groet Rob

_________________
http://www.RobvanHamersveld.nl VCP | MCSE | MCTS | MCITP

Collega van me heeft het volgende artikel geschreven, zie:

http://blog.vmpros.nl/2009/01/27/config ... e-service/

Toch blijf ik het allemaal een beetje dubbel gevoel vinden wat nou de beste manier is om te syncen betreft ntp.

Vinkje binnen VMtools, host sync (nadelen):
- Kan zijn dat je ESX NTP service blijft hangen, ESX geeft verkeerde tijd mee, vervolgens neemt je DC het over van host en gaat het ook verkeerd op je omgeving. Kijk bijv. eens naar de Timebomb waar je de datum terug heb moeten zetten.
- Je hosts toevallig afwijkende tijd hebben, dat je met een vmotion je DC in verschillende "tijdzones" terecht komt.
- Tijden lopen nogwel eens in de toekomst dat het inderdaad wel op de host goed staat

Ik denk dat je er nog het meest goed aan doet om geen gebruik te maken van host sync maar via bovengenoemde url.

_________________
| Blog.vmpros.nl | Twitter | DBL | vExpert 2010/2011/2012 |

Aardig artiekel, vooral interessant om de ntp-server via de grouppollicy te configureren. Toch een paar kleine aantekeningen (voor je collega):
- msWindows gebruikt inderdaad het ntp-protocol om de tijd te synchroniseren. Zelf noemen ze het sntp (Simplifyed ntp) voornamelijk omdat ze de een (veel) lagere synchronisatie resolutie gebruiken en minder nauwkeurig werken dan de officiële ntp implementatie.
- Het voorbeeld synchroniseerd met alle machines naar de server 'nl.pool.ntp.org' Dat is waarschijnlijk NIET wat je zou willen. Het beste is 1 (of 3 of meer) interne machines (de domain controllers?) aan te wijzen die extern synchroniseren. De rest (het domain) synct dan met de interne klokken. Overigens bieden de meeste internet-providers ook ntp-klokken aan. Beter die te gebruiken, ze zijn vaak dichterbij dan de pool.ntp.org klokken.

Zorg er voor dat je esx-server ook met je ntp-server synct. Sterker, het is een heel aardige interne ntp-bron, omdat het de echte ntp-implementatie gebruikt kan ze nauwkeuriger zijn dan de msWindows implementaties. Zelf zie ik msWindows machines afwijkingen van 1/10 secondes hebben, waar unix/linux/esx implementaties nauwkeuriger dan 1/100 seconde werken. Overigens, alles beter dan wat je echt nodig hebt: op de seconde in sync is meer dan genoeg.

Tijdzones zijn voor ntp geen probleem: Die werkt intern helemaal in 'epoc': de tijd in secondes sinds 1 januari 1970, UTC. en UTC is dan weer wat normale mensen Greenwich Mean Time noemen: Londen (UK) wintertijd.

De host wil je ook graag synchroniseren: gewoon ntp configureren en klaar is Clara.
Overigens kunnen gasten heel goed een afwijking van de host hebben. Dat is configureerbaar (maar wel handwerk).

Voor msWindows machines die onderdeel zijn van een domain kan je de default configuratie overal gebruiken: geen sync met de host en de domain-configuratie zorgt er standaard voor dat gesynct wordt met de domaincontroller.

_________________
Wat automatisch gaat, gaat automatisch fout.