[ntp:questions] Re: Architecture / best practice for small/medium company setups

Brian Utterback brian.utterback at sun.removeme.com
Thu Jun 29 13:25:51 UTC 2006


Maarten Wiltink wrote:

> People are going to scream bloody murder that there aren't four
> servers in this scenario. People are going to be ripping body parts
> over there being _two_ servers. 

Interesting. My first reaction was as you predicted. Then after thinking
about it, I started to warm to the idea. Then thinking some more, I
started to dislike it again.


> In brute fact, there aren't - there's
> only one. Backup only serves to keep the herd together if primary
> fails altogether. That's the only time anybody will listen to it.

This isn't true. They will listen to it, all the time. And some will
sync with it.  Consider: The local clock settings are utterly irrelevant
in the scenario proposed. The local clock will not be used until the
dispersion of the regular servers becomes too large. This typically
takes 24 hours. Since the scenario stipulated that the Internet
servers would never be unavailable for more than a few hours, their
dispersions will never grow large and the local refclock will never
be used.

So, in the normal case, we have two servers, which all of the leaf
nodes have configured. These servers will be one stratum apart.
So, by an large, all the leaf nodes will sync with the main server,
as planned. However, fairly often, some will sync with the backup,
due to transient errors, dropped packets, whatever.

Now the backup will be generally in sync with the primary, since
it is its only source of time. But just like a kite with only
a single string, it will tend to flutter around the right time.
Having only a single source of time eliminates many of the
algorithms NTP uses to filter out transient errors.

So, much of the time the backup will have a different time setting
than the primary and much of the time some of the leaves will be
in sync with the backup, so there will be clock hopping.

So, I still think that at least three servers would be a good idea.
I am thinking that if you pick three servers, and configure each
of them with three independent Internet servers and have them peer
with each other, that you will have a pretty robust system with
a minimum of administrative overhead. This assumes that the choice
of pool servers will be independent between them.

I still like 4 servers minimum, though. Four seems to be the number
that eliminates a whole class of problems. But three does pretty
well, and might be good enough for your requirements.

Also, it is a good idea to configure local refclocks as Martin 
described. I know that the scenario was for only a few hours, but there 
was that 9 day anomaly, wasn't there?

-- 
blu

Roses are #FF0000, Violets are #0000FF. All my base are belong to you.
----------------------------------------------------------------------
Brian Utterback - OP/N1 RPE, Sun Microsystems, Inc.
Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom




More information about the questions mailing list