[ntp:questions] question regarding NTP configuration for clusters, and "cluster time" stability

Harlan Stenn 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
>> locally?

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
timebase.

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
rotordyn1> field.

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 mailing list