9

Lets see if someone can throw a bit of light on this subject..

I'm making a server installation in the next days. My client wants to deploy a Hortonworks HDP with 2 servers as master servers and 5 workers servers. One of the requirements for all of them is to be NTP enabled. But that's all the info I have, he hasn't told me if he wants a local server acting as NTP server or wants all 7 serves to acting as clients. The OS will be Centos 6.6 or 6.7.

So my question would be:

Taking into account that this will not be a production enviroment, but more like a "testing" enviroment, which would be your choice for configuring NTP on these machines? All 7 acting as clients or 1-2 servers and five clients?

MadHatter
  • 78,442
  • 20
  • 178
  • 229
lgg
  • 141
  • 2
  • 11

3 Answers3

9

I feel quite strongly that two local servers, which everyone else binds to, is the right way to go. NTP is designed to work that way, and it minimises the load on the public/pool servers.

I run an NTP pool server. Even in areas with well-populated pools the load is still significant (I'm running at an annualised average of 25 client requests per second, which means about 2.5 million a day). In some parts of the world, the pools are so small that the few people who run pool servers are getting quite overwhelmed.

Edit: Aaron Copley makes the excellent point that two servers will both be rejected by clients if only one of them is out-of-sync but still thinks it's correct (see, eg, this question), and that having two (instead of just one) simply doubles the single-point-of-failure. He is absolutely right that three would be better, and in a larger production network I would agree that it is appropriate for this usage case. In my experience, however, properly-configured NTPd works a lot more often than it fails, and the risk of a single server being unavailable and client clocks getting too far out of sync to recover automatically much outweighs the risk of one server advertising a faulty time and invalidating both.

For me, two is the right number of upstream-synced servers for this network - but there is definitely a legitimate discussion to be had around the issue, and I'm grateful to Aaron for raising the point.

Community
  • 1
MadHatter
  • 78,442
  • 20
  • 178
  • 229
  • 1
    One server is preferable to just two. If something were to happen that these two servers get out of sync, the NTP algorithm cannot determine which is accurate and will reject both. Even better would be three and this is considered by the maintainers to be the [minimum number of servers](http://support.ntp.org/bin/view/Support/SelectingOffsiteNTPServers#Section_5.3.3.) to configure. – Aaron Copley Sep 14 '15 at 16:58
  • I have no doubt that you have more practical experience, but something about 1 or 3, but never 2 has just stuck with me. Thanks for mention in your edit. :) – Aaron Copley Sep 16 '15 at 15:12
  • The advice against two is based entirely on the problems that occur if they disagree, and on that basis, it's excellent. I just find that doesn't often happen *without one of the servers losing sync and thus disqualifying itself as a source*. One would be fine, I'm sure; two gives more robustness. But I personally (and it's very much my opinion) feel that three is too many, of a group of seven, in terms of load on the pool. Still, as I said, it's an excellent point you make, and definitely something for people to think about; I was delighted to credit you for raising it. – MadHatter Sep 16 '15 at 15:58
  • The link from @AaronCopley above very clearly justifies why 4 should be considered the low bound for the number of sources (whether servers or peers) for accurate time keeping and still allowing for scheduled maintenance or a fault on one of them. If neither server is malicious, 2 is much more likely to be accurate than 1 (since most of the time the windows *will* overlap), and 3 is the minimum to allow NTP's clustering & intersection algorithms to operate effectively. – Paul Gear Nov 03 '15 at 22:05
  • @PaulGear as you say, in a big network four is a sensible low bound; my pool server has five sources. But as you yourself also note, "*if neither server is malicious, 2 is much more likely to be accurate than 1*", so in a small network like the OP's, where four is unjustifiable overkill, two strikes me as the right balance between service provision and overloading the pool. Of course, if you are setting up your own stratum 1 servers, then have as many as you please and can afford; my answer only relates to the tradeoff between public duty and private service when using pool servers. – MadHatter Nov 06 '15 at 09:42
  • Yes, but we already know there are 7 servers available. The difference between configuring 2 and configuring 4 (or 7) is trivial. – Paul Gear Nov 08 '15 at 10:28
  • You're missing my point. I'm not concerned about the overhead to the **client server** admin, but to the **pool server** admins. If everyone binds twice as many servers to the pool as they need to, the load on all pool servers doubles. [Server load really is a problem in certain areas of the world](http://lists.ntp.org/pipermail/pool/2015-September/007580.html). When you're using public resources, donated for free by their owners, it behoves you to minimise the load on **them**, even at your own increased expense - or they may not continue to offer their resources. – MadHatter Nov 08 '15 at 10:32
4

With such a small environment, and it designated as just "testing", I would push NTP to the edge of the network. Run the NTP server on your switch or router if you can and configure it for 3 or more upstream time sources. Then, point all 7 nodes here. Likely, this is your only path out to the Internet so configuring additional time sources "inside" wouldn't do you any favors if there's a switch failure or network outage. You'll have worse problems than time sync if your network is down.

Aaron Copley
  • 12,345
  • 5
  • 46
  • 67
0

I'd go for 1-2 Servers. You spare the pool some requests. And should you lose connectivity to the pool for an extendet period of time for some reaseon, at least the machines in your internal network stay in sync with each other.

Peter
  • 21
  • 3