Open Stack

To Brad's point - if your controllers are VM's you might also want to have
a look at Chrony https://chrony.tuxfamily.org/. It's supposed to perform
much better on virtual machines.

___

John Petrini

On Thu, Jul 20, 2017 at 9:20 PM, Brad Knowles <brad at shub-internet.org>
wrote:

> 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20170720/45dcdaea/attachment.html>