Enterprise Networking Planet content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
For Novell NetWare and NDS administrators, time is an important commodity. Having the correct time on the servers means more than knowing when it’s time to go home: It means the health and consistency of the data on the network. In this article, we will look at some factors that affect NetWare and NDS time synchronization and examine the steps necessary to create a custom time synchronization structure.
Why Time Matters
Having the correct time on network servers is always important, but the distributed nature of the NDS complicates matters. For example, it is possible for an NDS change to originate from more than one location. When it does, the timestamp of the change is used to determine which change is the most recent. If the timestamps are incorrect, the latest change could be overwritten by an earlier one. On a broader scale, the time synchronization mechanism allows NDS replicas to make sure that they are consistent with each other. In addition to the NDS-related functions, time also plays an important role in network applications and the file system.
NetWare’s Time System
The time system in NetWare is called TIMESYNC. The functionality is provided by an NLM of the same name, which is automatically loaded on all servers. In an IPX-only network, the servers listen for time information in Service Advertising Protocol (SAP) packets. In a pure IP or a mixed IP/IPX environment, the time information is received by TIMESYNC through the Network Time Protocol (NTP). If you are operating in a mixed environment, you must use NTP. It is important to understand that in both cases TIMESYNC issues time to serversSAP and NTP are simply the mechanisms used to deliver the time.
NetWare servers can be configured to receive their time from external sources such as Internet time providers, atomic clocks, or radio clocks. If it’s practical to do so, configuring your servers to receive time from external sources provides for a reliable and relatively low-hassle approach. If it is not possible to configure your NetWare servers this way, another option is to use time provider groups that allow just a few servers to receive the time and provide that time information to other servers on the network.
Time Servers
NetWare achieves consistent time across the network by letting you configure certain file servers as time servers. Time servers, depending on their configuration, receive and/or supply time to other servers and clients. In a default NetWare installation, the first server in the NDS is configured as a Single Reference time server, and each subsequent server is configured as a Secondary time server. In relatively small networks this approach is more than adequate and often doesn’t need any further configuration.
If your network is more complex or spans multiple locations, the default configuration is not as practical, because it can lead to the propagation of time parameters across slow or expensive wide area network links. If this is the case, you probably should investigate a custom time synchronization structure.
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:
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.
