[ntp:questions] question regarding NTP configuration for clusters, and "cluster time" stability
stenn at ntp.org
Wed Sep 30 19:04:12 UTC 2009
>>> In article <2ad203b2-abc8-46da-8ad1-d0d0454a35c9 at l34g2000vba.googlegroups.com>, "rotordyn at yahoo.com" <rotordyn1 at gmail.com> writes:
rotordyn1> So I'm not sure what happens if some core servers lose access to
rotordyn1> their UTC sources, while the remainder do not. I had hoped that
rotordyn1> one core server switching to orphan mode would somehow trigger
rotordyn1> the others, but I don't see that it does in the code.
Have your core servers peer with each other.
Have as many of your machines as possible/resonable peer with each other.
If you lose network connectivity, you are going to get "time islands".
If this is bad, see below.
>> If correct time is really important, why not run an inexpensive S1 device
rotordyn1> Oddly enough, "correct time" isn't all that important, at least
rotordyn1> not to the accuracy often discussed in the context of NTP. And I
rotordyn1> think that's the root of my issues: A consistent "cluster time"
rotordyn1> among the nodes is much higher priority than accurately following
rotordyn1> UTC. Prioritizing a common cluster time absolutely over UTC in a
rotordyn1> redundant fashion seems to be difficult, since the peers that
rotordyn1> provide redundancy can diverge from each other if given different
rotordyn1> inputs. (Different in that one could lose its external UTC
rotordyn1> reference while another does not.)
Consistent "cluster time" may also mean avoiding time islands.
So while it may not be a first-order requirement to have accurate time on
all your nodes, if avoiding time islands in failure cases is a first-order
reqiurement, having sufficient distribution of a common timebase becomes a
solution to that problem which is solved by having a well-distributed common
rotordyn1> The current implementation reflects this, since we use NTP
rotordyn1> internally with no outside references. But that means that over
rotordyn1> time we can drift pretty far away from UTC, and my goal is just
rotordyn1> to limit that. I think I've said it already, but roughly speaking
rotordyn1> I need the nodes to agree with each other to less than a second,
rotordyn1> and even within a minute or even an hour to UTC is enough.
>> If it's *really* imporatant, you can build a very high quality S1 server
>> with Rb and GPS and/or modem for under US$2k.
rotordyn1> Adding hardware isn't an option. This product exists in the
You can add 9s, and at some point you may have to run a sanity check on a
node and if it's not talking to enough folks for the right time, perhaps it
should go into a holding pattern until that situation improves.
Harlan Stenn <stenn at ntp.org>
http://ntpforum.isc.org - be a member!
More information about the questions