[ntp:questions] Cluster NTP configuration

Steve Tryon x77ssiwdo at yahoo.com
Fri Jun 24 18:53:07 UTC 2011

Thanks to all for the information - it has helped a great deal.

Now I have moved on to finding a preferred configuration scheme for my clustered product and I am looking for guidance from the more experienced.

There are X nodes in the cluster.  Management of the product (configuration, metrics, SNMP, etc) resides on a subset of the servers.  A real-time application executes across a subset of the servers as well where some servers may have both the management application as well as the real-time application running.  The servers running the real-time application must stay in reasonable time synchronization (~100 milliseconds).  For consistency purposes, all of the servers should be generally synchronized (though the variance in the non-real-time applications is much more forgiving).

The goal is for the overall cluster to be driven off of a primary and secondary NTP source (possibly pools) but for the synchronization to remain pretty well intact even if no external servers are provisioned or external connections are lost.

I am trying to decide between 2 architectures:
1) The management servers synchronize with the external NTP sources and are peered to better handle the case when no external servers are available.  All other servers in the cluster (including the real-time app servers) use the management servers as their NTP source.  The real-time app servers are not peered.
2) The real-time app servers are clients of the external NTP servers and are peered.  All other servers in the cluster sync from the real-time app servers.

Thanks for reading this far and any input you can provide,
- Steve

--- On Mon, 6/20/11, Steve Kostecke <kostecke at ntp.org> wrote:

From: Steve Kostecke <kostecke at ntp.org>
Subject: Re: [ntp:questions] Cluster NTP configuration
To: questions at lists.ntp.org
Date: Monday, June 20, 2011, 6:07 PM

On 2011-06-20, Steve Kostecke <kostecke at ntp.org> wrote:

> The "local clock" is not a not a time source. It is a hack which allows
> ntpd to claim to be "synced" even when it is not.

Unless, as has been pointed out by others, an external means of
disciplinining the system clock is in use.

Steve Kostecke <kostecke at ntp.org>
NTP Public Services Project - http://support.ntp.org/

questions mailing list
questions at lists.ntp.org

More information about the questions mailing list