| Re: [chrony-users] Best way to synchronize dispersed VMʼs |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
On Mon, 7 May 2018, Nicolas Embriz wrote:
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.
GPS will sync all of the servers to a common time (UTC) to of order of 1 or 2
usec. Then you have to sync the VMs to those servers. Remember that the time
around the world is about 1/7 sec going via vacuum, and probably at best about 1/4 sec
with fibre optic/routers/... Now that in itself does not matter, since chrony,
using the ntp protocol, compensates for that delay under the assumption that
the delay is equal in both directions. If there is a 1% difference on outbound
vs inbound packets, that is many ms. You still have not told us what kind of
an error in synchronization you can tolerate. 1 sec, 1ms, 1usec, 1ns?
So, best would be to hook up all your machines to a gps pps receiver. That
would give you the best synchronization.
Alternatively you could have three stratum 1 gps pps recievers in each area.
(Europe, Asia, US)
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:
ntp already compensates for the delay, but under the assumption that the delay
is symmetric (same out and back). If it is not, it cannot compensate,
especially if that asymmetry is varying (as it usually is).
You do NOT every use the local. It is a completely undisciplined clock. The
only reason for using it is if you have a server and it is far more important
that the clients sync to the server than that they have the correct time at
all.
local stratum 1
allow
Or should I use something like this for server 1:
server server-2
server server-3
local stratum 1
??? why do you have local in there at all?
You would have server 1 use gps pps to discipline it, with server 2 and 3 as
fallbacks.
refclock PPS /dev/pps0
server server-2
server server-3
server pool.ntp.org
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.
That is the purpose of a ntp program, like chrony. To sync the computer to the
best time available. Like your GPS pps slaved servers.
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?
How low is low? In 1000 people were happy with 1 hour. What are y ou happy
with?
Thanks in advance.