[chrony-users] Best way to synchronize dispersed VM’s

[Nicolas Embriz]

I have some legacy VM’s/ instances dispersed around the world currently
using npt and pool.ntp.org.

I have been updating them and using chrony now, so far all good.

Now I created a server, 94.16.116.82 (Germany) and start to use it on all
my instances around the globe from Asia to USA, it works but here is were I
have some doubts.

- when using pool.ntp.org the server use the closest one based on its
location, so a server in Singapore will have less latency pulling from a
server in Asia than o one from Germany, same for a server in USA, they all
will be let’s say “on time” but between them the offsets will differ and
what I would like to have is rather than being on time to be as
synchronized as possible, therefore wondering if by using a own server for
all the infrastructure despite the network latency is the way to go? (All
my instances using my server now have stratum 3)

- currently I have only one server but in the case I of having 2 just for
example purposes, let’s say Germany and in USA, they have a stratum 2 and
using pool.ntp.org, the VM’s using the USA server will differ from the
once using the server in Germany, so question here is how to synchronize
the “master” servers , I was thinking on using in both the same source, for
example a own stratum 1 server.

At the end my goal is to have all instances well synchronize hopefully will
the smallest possible offset, being on time is important but not as much as
being almost identically in sync.


Thanks in advance

Regards

[Stephen Satchell]

I have some legacy VM’s/ instances dispersed around the world
currently using npt and pool.ntp.org.

Note tha VMs are pretty horrible timekeepers at the best of times. The best
thing is to run ntp on the real hardware-- the host for the VMs, and
have the VMs get their time from
that .

"The right tool for the right job" -- Scotty, _Star Trek_

I've worked with a number of VM objects for the past few years, and have
tried to use the "trick" of running NTP in the host and having the
virtual objects sync to them. Still have time differences.

The problem isn't the NTP daemon running on the host; it's the
slipperiness of clock accuracy in the virtual objects. NTP (and CHRONY)
make the assumption that the clock in the "computer" is driven by a
crystal oscillator or AC power-line frequency.

Crystal oscillators in modern computing devices have a tracking accuracy
of under 1 ppm, closer to 0.010 ppm. Very few modern devices track
power-line frequency anymore.

Virtual clocks have considerably worse tracking accuracy, so the clock
in a VM object can't be regulated nearly as well as one in bare iron.
Short story: I had an automation server running on bare iron for years.
Time tracking was excellent, even without NTP running. When $DAYJOB
moved that server to a virtual environment, the clock started running
slow at times. At one point, the clock was running four hours behind
wall time, which pissed the customers off no end. The "fix" was to run
NTPdate every hour against an external time standard, a fix that
continues to this day. No more unpredictable clock drift.

At satchell.net, I've added an GPS-based NTP appliance. One server
slaves to that (and other Stratum 1 servers). Everything else slaves to
that. Last time I checked time accuracy against WWV, all the computers
were well within one second of the radio clock time.

From some things you said, you don't own the VM hosts. That can be
a...problem.

Also, latency is not as important as jitter. If you have a constant
latency, the chronyd algorithms can take that into account. Then there
is the false-ticker problem, but that's another issue.

(N.B.: if you plan to use a commercial NTP server for your reference
time base, make sure it can handle all the traffic on your network.
Embedded IP stacks tend to be fragile, particularly in consumer-grade
products. When I got my GPS-based NTP appliance, I found that I had to
use a VLAN to isolate the poor thing from the traffic on my network.
Otherwise the TCP/IP stack would choke. That's also why ONE server
synced with the appliance, and served time to the rest of my network.)

[Nicolas Embriz]

Hi Guys, thanks for your comments, please bear with me since I am trying to
grasp, learn and apply the best practices.

Has mentioned, my goal is to have all the VM's in sync with the minimum
offset possible, time is important but would like to focus more on having
all of them in sync for now.

If I am understanding correctly the best way could be to have a GPS/PPS
hardware, not a VM, use it as a stratum0 and then connect to that device
one or more servers (preferably not VM's) that will behave like my pool of
stratum 1.

Now let's say that I create a pool of 3 servers in this using the following
setup:


my.pool
GPS/PPS hardware --- server 1 (America)
`-- server 2 (Europe)
`-- server 3 (Asia)

The main source for all of them is the GPS/PPS hardware but how to
"compensate" the latency and sync between them probably there is no need
for this but just wondering, for example, the configuration for the servers
would be something using only local or also the need of the servers are
needed:


local stratum 1
allow

Or should I use something like this for server 1:

server server-2
server server-3
local stratum 1
allow

For server 2:

server server-1
server server-3
local stratum 1
allow

For server 3:

server server-1
server server-2
local stratum 1
allow


If I also understood probably could be better to have a GPS/PPS device per
zone something like:

my.pool
GPS/PPS -- server 1 (America)
GPS/PPS -- server 2 (Europe)
GPS/PPS -- server 3 (Asia)

But again how to compensate or sync the pool itself so that all the child’s
or machines using this service could be in sync.

And in cases (my current case) where I don’t have a GPS/PPS hardware device
could I make a pool full in sync using an existing public ntp server at
least just to try to achieve a very low offset?


Thanks in advance.