Using Time Provider Groups in NetWare 5.x - Page 2

 By Drew Bird
Page 2 of 2   |  Back to Page 1
Print Article

Custom Time Synchronization

The key to understanding how a custom time synchronization structure works lies in the different types of time servers and the roles they perform. NetWare provides four types of time server, each of which has different characteristics:

  • Single Reference time serverActs as the authoritative time provider for the entire NDS tree. As such, it always believes that it has the correct time and will not accept time input from other time servers. A Single Reference time server provides time to other servers and clients. As the name suggests, there can be only one Single Reference server per NDS tree.

  • Reference time serverPlays an important role in a custom time synchronization structure. Reference servers get their time from the system clock or other external source and then provide the time to other servers and clients. As with Single Reference servers, Reference servers always believe their time to be correct and so do not accept time from other time servers.

  • Primary time serverAdjusts its time to that received from a configurable list of other time servers. To provide protection against dramatic shifts in the system time, Primary servers employ a voting system to determine the valid time, and then shift gradually towards it. Primary servers will accept time information from Reference and other Primary servers and supply time to Secondary time servers and clients.

  • Secondary time serverSupplies time to clients and workstations. The Secondary time server believes that the time it has received from another server is correct, and so will correct its own clock by 100% in the event of a mismatch.

    A server can perform any of the time server roles described, regardless of its role in the NDS. The differences in the way that each server deals with the time issue makes it possible to create a time synchronization structure that reduces network traffic and provides a degree of fault tolerance. The strategy is based on the principle that certain servers are nominated to provide time to other servers on the network. These servers operate in groups, agreeing on the correct time between them and then using that as the correct time to be issued to other servers and clients.

    Each time provider group should consist of one Reference server and at least twobut no more than sevenPrimary servers. The Reference server receives its time from a reliable internal or external source such as an Internet time provider. The Primary servers then receive their time from the Reference server and the other Primary servers. All other servers that are to receive time from the group are set to Secondary servers and provided with a configured list specifying which servers to go to for the correct time. The use of the list means that each Secondary server can move to an alternate time server should the preferred time server be unavailable.

    The parameters that dictate how each server in the TIMESYNC structure should behave are defined through the TIMESYNC.CFG file, which can be found in the SYS:SYSTEM directory. The time parameters can be entered directly into the file or by using the Server Parameters | Time option in MONITOR.

    Should You Use Provide Groups?

    Do custom time provider groups have a place in your network? If you have a single location with relatively few (less than 30) servers, it should not be necessary to create time provider groups. If, on the other hand, you have a widely distributed network, custom time provider groups can provide increased fault tolerance and reduce wide area network traffic.

    That said, many people with fewer servers in a single location may still feel that a custom structure is worth the extra effort. After the initial configuration, time provider groups require little or no maintenance and provide extra peace of mind in what can be an often-overlooked part of NDS administration. //

    Drew Bird (MCT, MCNI) is a freelance instructor and technical writer. He has been working in the IT industry for 12 years and currently lives in Kelowna, B.C., Canada. You can e-mail Drew at drew.bird@tecmetrix.com.

  • This article was originally published on Dec 14, 2000
    Get the Latest Scoop with Networking Update Newsletter