[ntp:questions] question regarding NTP configuration for clusters, and "cluster time" stability
mills at udel.edu
Mon Sep 28 18:02:43 UTC 2009
I don't know where you got "the docs", but it appears not to be from the
official documentation. There is an explanation with diagrams at
rotordyn at yahoo.com wrote:
>On Sep 15, 5:14 am, Harlan Stenn <st... at ntp.org> wrote:
>>Orphan mode sure sounds to me like what you are looking for.
>>Harlan Stenn <st... at ntp.org>http://ntpforum.isc.org - be a member!
>Quick question. The docs say
> "Orphan Mode allows a group of ntpds to automonously
> select a leader in the event that all real time sources
> become unreachable (i.e. are inaccessible)."
>What if, among this group of ntpds, only a subset consider that
>all time sources have become unreachable? I'll use real numbers
>to make it a bit clearer: I have 32 nodes in a cluster, and all of
>are interconnected with private cluster networks, while 4 of them
>also have connections to a corporate LAN. If my time reference
>becomes unavailable, all 4 will see that they have no external
>source. (Reading ntp_proto.c, it looks like the first ntpd to see
>this state declares itself the orphan parent?)
> But what if 1 or 2 of these group of 4 lose LAN connections?
>They will go into orphan mode, while the other 2 do not. This
>seems that it could cause the group of 4 to move in different
>directions timewise. Or do the two that still have contact with
>the external reference also go into orphan mode, and ignore
>the external reference? It appears not, but I'm trying to avoid
>the scenario where node's clocks in the cluster drift apart.
>(Since I care far more about the nodes following a single
>"cluster time" than any individual nodes fidelity to UTC)
> Our testing with peers that are clients of an external reference
>while at the same time servers to the internal leaf nodes
>shows that this divergence is possible.
> If it isn't possible to force this group of ntpds to prioritize
>a common cluster time over UTC, we'll need to define a single
>master node statically. And then handle high-availability
>issues externally to the reference implementation in our
>questions mailing list
>questions at lists.ntp.org
More information about the questions