Mathew Snyder
2014-11-18 21:50:22 UTC
We are currently in a situation where we are being pressured to re-engineer
our NTP service. We currently host it, along with other services, on
Windows DCs. Our initial plan is to move NTP off of those servers and host
it on dedicated Linux servers.
We likely won't get approval for hardware to host NTP and will thus have to
rely on VMs. This poses a few concerns such as: How will a Vmotion affect
the service? What happens if access to the sources that we use is lost (for
whatever reason)?
In the past, all of our VMs would run ntpd normally. That is, as a
constantly running daemon.. However, we found that time was drifting
significantly to the tune of several seconds a day on several servers. We
never figured out why it was happening. Instead, we found that using a cron
job which runs /usr/sbin/ntpd every five minutes kept time synced up
nicely. We haven't had any issues since.
However, now Red Hat is telling us we should (need) to be running ntpd as a
daemon because they are seeing timing issues. Interestingly, this was never
brought to the attention of us platform engineers so I don't know how bad
the problem is or how many servers are affected.
The problem could be VMware Tools conflicting with ntpd. But again, we
don't know what the problem is. Only that we have a workaround-type
solution that we're being told we have to replace.
This leads to my question to the list: those of you who have cloud
environments based on VMware solutions, how do you keep time in sync? What
issues have you encountered and how did you solve those problems? What can
you recommend for a virtualized NTP solution?
-Mathew
"When you do things right, people won't be sure you've done anything at
all." - God; Futurama
"We'll get along much better once you accept that you're wrong and neither
am I." - Me
our NTP service. We currently host it, along with other services, on
Windows DCs. Our initial plan is to move NTP off of those servers and host
it on dedicated Linux servers.
We likely won't get approval for hardware to host NTP and will thus have to
rely on VMs. This poses a few concerns such as: How will a Vmotion affect
the service? What happens if access to the sources that we use is lost (for
whatever reason)?
In the past, all of our VMs would run ntpd normally. That is, as a
constantly running daemon.. However, we found that time was drifting
significantly to the tune of several seconds a day on several servers. We
never figured out why it was happening. Instead, we found that using a cron
job which runs /usr/sbin/ntpd every five minutes kept time synced up
nicely. We haven't had any issues since.
However, now Red Hat is telling us we should (need) to be running ntpd as a
daemon because they are seeing timing issues. Interestingly, this was never
brought to the attention of us platform engineers so I don't know how bad
the problem is or how many servers are affected.
The problem could be VMware Tools conflicting with ntpd. But again, we
don't know what the problem is. Only that we have a workaround-type
solution that we're being told we have to replace.
This leads to my question to the list: those of you who have cloud
environments based on VMware solutions, how do you keep time in sync? What
issues have you encountered and how did you solve those problems? What can
you recommend for a virtualized NTP solution?
-Mathew
"When you do things right, people won't be sure you've done anything at
all." - God; Futurama
"We'll get along much better once you accept that you're wrong and neither
am I." - Me