Open Stack

On Jul 20, 2017, at 7:26 PM, Raja T Nair <rtnair at gmail.com> wrote:

> Thanks a lot for the reply, John.
> 
> Yes I understand that time is really important for cluster setup, that's why I was panicking and looking for alternatives when I found time drifting while ntpd was still on.
> So I was planning to do a ``ntpdate w.x.y.z '' every 2 mins in order to keep time in sync.
> 
> Would want to investigate this. My upstream time server seems fine, its on a baremetal. Many other servers sync with this one too. Also only one controller had issues with time.
> Kind of stuck here, as I have no idea why one node's ntpd would fail :(

Doing a cron job with ntpdate will cause your time to bounce all over the place, and that will be even worse than what you've had so far.

I've been a member of the NTP Public Services Project since 2003, and I've seen a lot of NTP problems over the years, especially on virtual machines.  Historically, our advice was to not even run ntpd at all on a VM, but instead to run it on the bare hardware underneath, and then make sure that you're running the necessary hooks in the hypervisor and the guest OSes to pass good quality time up the stack to all the clients.

I'm not sure if that is still the best advice or not -- I think it may depend on your hypervisor and your guest OSes.

But if you do run ntpd on the guests, there are things you can do to measure larger-than-normal amounts of drift and compensate for that.  I would direct you to the mailing list questions at lists.ntp.org for more information.

--
Brad Knowles <brad at shub-internet.org>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20170720/83de24e5/attachment.sig>