[ntp:questions] orphan mode, manycast, and virtualization
Mark C. Stephens
marks at non-stop.com.au
Mon Sep 9 18:22:51 UTC 2013
I can remember esx4 coming up with the system time wrong because the NTP servers were offline.
For some reason the time came up at UTC and not at the time zone time.
Catastrophic results for everything that relied on Kerberos.
We were using your option B with VM tools performing the time sync.
Haven't seen it happening for a while now, they must have fixed it.
From: questions-bounces+marks=non-stop.com.au at lists.ntp.org [mailto:questions-bounces+marks=non-stop.com.au at lists.ntp.org] On Behalf Of Horvath Bob-BHORVAT1
Sent: Tuesday, 10 September 2013 2:23 AM
To: questions at lists.ntp.org
Subject: [ntp:questions] orphan mode, manycast, and virtualization
Another question if you guys have the time :),
We situations in which we have almost everything deployed as virtualized servers running inside of VMware ESXi. It seems like the recommendation on time synchronization with ESXi has changed from release to release. It seems to boil down to one of the following:
A) Run ntpd on the bare iron at the ESXi layer and let it change the virtual hardware clock (without ntpd running on VMs)
B) Run ntpd on the bare iron at the ESXi layer and let ntpd on the VMs use it as a time source
C) Run ntpd on all the VMs and point them to as many "good" ntp servers that you can find whether in its own ESXi or another physical server's ntpd.
One of the other constraints we have is sometimes we don't have a good time source, and the requirement is that they all be consistent, if not correct. In other words, there is no stratum one source, and no connectivity to a network that has one.
Other times there is a good time source, but we have to survive being unable to reach it. We are looking to take advantage of orphan mode but the version of ESXi we are using has the version of ntpd that has the orphan mode bug where the stratum starts climbing. I am not sure we can change that, so the thinking is that we have orphan modes in "pairs" of stratum. Of course, a man with two watches is never quite sure what time it is.
One thought I had was using manycast to let the various servers, physical and virtual, to find the best set of time sources (again physical or virtual) they can find. I am assuming over time they will mark inaccurate virtualized sources as false tickers. Even if all the instances of ntpd were virtualized (which I know is crazy), would ntp eventually find the best source of time, or would it thrash about dealing with the best of a lot of bad clocks?
Is there any wisdom out there to deal with such cases?
questions mailing list
questions at lists.ntp.org
More information about the questions