| Although it is not a service provided by NDS, time synchronization is a very important part of maintaining the integrity of the NDS tree. Every time a change is made to an object, the change is timestamped in order to allow the change to be made on all servers holding a copy of that object, in the proper sequence. Without time synchronization, it would be possible to set up two servers with different times but holding copies of the same objects. In that case, you could change a user's password on one server and that change might not be propagated to the second server properly, and the user would be forced to log in with his or her old password. NOTE It is important to realize that NDS requires that the DS servers within a network all agree on a common time. This doesn't necessarily have to be the correct time, but everyone's time has to be in synchronization with each other.
There are four time server types: -
Single Reference -
Reference -
Primary -
Secondary The Single Reference, Reference, and Primary time servers are referred to as time providers , and they establish the network time. Secondary time servers determine the correct time by polling a time provider. Table 2.6 shows a summary of the legal provider/client combinations. No matter what role the time server plays within the network time synchronization, all the combinations shown in Table 2.6 provide time information to workstations ( clients ). Table 2.6. Legal Time Provider/Client Combinations | TIME SOURCE TYPE | CLIENT | | Single Reference | Secondary and Workstation | | Reference | Primary, Secondary, Workstation, and Reference | | Primary | Primary, Secondary, and Workstation | | Secondary | Workstation and Secondary |
NOTE The time server types discussed in the following sections really apply only to NetWare servers (but work over both IPX and IP ). Non-NetWare DS servers always report a time server type of Secondary. Furthermore, because Novell does not provide a TimeSync module for non-NetWare platforms, you need to separately set up time synchronization by using a Network Time Protocol ( NTP ) application of your choosing (discussed later in this chapter).
Single Reference Time Servers The Single Reference time server type is typically used in a small network, where one server holds the definitive time for the entire network. If you need to change the time for some reason (perhaps because the network time drifted), the Single Reference server is the one where you would change the time. NOTE It is generally recommended that if the time on the network needs to be changed, it should be changed with the SET TIMESYNC TIME ADJUSTMENT console command. You should not use the SET TIME console command because it does not perform the change in as orderly a manner.
A Single Reference time server is intended to be the only time source provider within a network. All other servers must receive time from this Single Reference time server and cannot in turn provide time to other servers (including back to the Single Reference time server). Consequently, a Single Reference time server is only useful in a network environment where there are no more than 30 DS servers because it is a potential single point of failure. An external time source, such as an atomic clock located on the Internet, can be used to set the local time on a Single Reference time server. However, the Single Reference time server will not receive time information from other DS servers on the network. Consequently, the Single Reference server decides unilaterally what time it is and tells the rest of the servers on the network that it is correct. Because of this, a Single Reference time server is incompatible with other time source provider types. NOTE Because a Single Reference time server is the authoritative time source on an NDS network, its time is always considered to be synchronized to the network, regardless of the time on any other server.
TIP See TID #10011518 and #10050215 for details on configuring TIMESYNC.NLM to obtain time from external time sources.
Reference Time Servers A Reference time server does not adjust its time to match the time obtained from the other time-provider servers. In addition, a Reference server has more voting weight than other time-provider servers in the polling process (16 versus 1). The result is that the Primary time servers adjust their time to (rather quickly) converge on the time specified by the Reference time server. The Reference time server is also part of that process, however, and if the polling servers determine that the time on the Reference server is too far off, they will disregard the time change and maintain correct time. Like Single Reference time servers, Reference time servers can use an external time source to set their local time in order to maintain accurate time. One Reference time server is allowed per NDS tree, and it can coexist with Primary time servers (but not with a Single Reference time server). NOTE To utilize a Reference time server, you need at least one other time-provider server, such as a Primary time server, to complement the operation of the Reference time server ”so the time servers have polling partners . You cannot use a Single Reference time server in this case because it does not allow itself to be polled. It is possible to have more than one Reference time server in the same network. But because Reference servers do not adjust their internal clocks, multiple Reference servers never synchronize with each other, even though they poll each other for time information. If you need to use two or more Reference servers, you should use a common external time source to synchronize them.
NOTE In implementations where a Reference time server is used, it is strongly recommended that you have at least two Primary time servers as well. This way, if one of the three time-provider servers becomes unavailable, the remaining two servers can still poll each other to exchange time information. If you have a Reference time server and only one Primary and one of these becomes unavailable, the remaining time server has no one to poll with and thus will lead to out-of-time synchronization with the network.
Reference time servers are generally used in medium- to large- size networks consisting of more than 30 DS servers. Primary Time Servers Primary time servers are used in the polling process with a Reference time server. Typically, more than one Primary time server is used in conjunction with a Reference time server. Primary time servers are best used when positioned geographically to allow time synchronization to continue with other servers, even if a link to the Reference time server is down. A Primary time server polls another Primary time server or Reference time server to determine whether that server's time matches its time. If the difference is less than the value of the SET TIMESYNC Synchronization Radius parameter, the Primary time server indicates that its time is synchronized. If the difference is greater than the value of the SET TIMESYNC Synchronization Radius parameter, the Primary time server adjusts its local time by 50% of the difference. This allows the Primary time servers to (slowly) converge on a correct network time instead of causing a sudden (big) jump in time change. Secondary Time Servers A Secondary time server receives its time from another server on the network ”whether from a Single Reference, Reference, or Primary time server. Secondary time servers do not participate in polling in the sense that their time contributes nothing to the network time. They are essentially slaves to the time synchronization process. If the difference between the network time and a Secondary time server's local time is less than the value of the SET TIMESYNC Synchronization Radius parameter, the Secondary time server indicates that its time is synchronized. Otherwise, it adjusts its local time totally (that is, by 100% of the difference) to match the network time (instead of 50% at a time, like Primary time servers). Secondary time servers are time consumers because they receive time from a time source such as a Single Reference or Primary time server. However, Secondary time servers act as time providers to clients such as workstations. Although not normally done nor generally recommended, it is indeed possible to configure a Secondary time server to obtain time information from another Secondary time server. Cross-Platform Time Synchronization Using NTP The TimeSync protocol is a Novell-proprietary time synchronization protocol, first introduced with NetWare 4.0. The protocol was implemented using IPX via TIMESYNC.NLM . With the release of NetWare 5, Novell enhanced its time synchronization service to also function over IP natively and to interoperate directly with Internet standards “based NTP time sources. TIMESYNC.NLM can now handle both IP- and IPX- related communication and provides Novell TimeSync protocol, NTP client, and NTP server capability. Instead of time server types (such as Single Reference) used by Novell, NTP uses the term stratum to indicate the accuracy of a time source. The stratum ranges from 1 to 16. 1 stands for the time source itself, 2 stands for the first server referencing that time source, 3 stands for the server referencing stratum 2, and so on. An NTP server at stratum n +1 is one that accepts time from an NTP server at stratum n . Thus a server at a lower stratum is accepted as a server that is more accurate than one at a higher stratum. NOTE Internet time sources are typically public-domain NTP time sources that are at Stratum 1 or 2.
NTP is very strict in considering a time source. If a time source is more than 1,000 seconds (17 minutes) away from the local clock, NTP rejects the time source and labels it as insane . Because of its refusal to accept insane time sources, NTP time sources are usually very reliable. You can find more information about NTP at www.ntp.org. When NTP is activated on a NetWare server, the server can serve as a NTP time server for all IP-capable servers on the network. An NTP time source can be used for IPX networks if the Reference time server (running on NetWare 5 or higher) has both IP and IPX bound to its network boards or if the Reference time server is running a Compatibility Mode Driver (CMD). The IPX-based servers must be set to act as Secondary time servers. NOTE At the time of this writing, NTP version 3 is the Internet Draft standard, formalized in RFC 1305. NetWare 6.5 supports NTP v3, but you need to use XNTPD.NLM instead of TIMESYNC.NLM for full NTP compatibility (see TID #10084753). NTP version 4, a significant revision of the NTP standard, is the current development version but has not yet been formalized in an RFC.
Depending on your environment, you first need to make a decision about whether to use TimeSync or NTP. You can use either method in a pure NetWare environment; however, if you have non-NetWare servers on the network, such as Unix servers, you should implement NTP. When implementing eDirectory on a mixture of NetWare and non-NetWare platforms, such as Solaris and Linux, you have no other option but to use NTP because it is the most common cross-platform time synchronization protocol. NOTE Although Novell does not provide applications to ensure that network time is synchronized for non-NetWare platforms, time synchronization across the network is still critical and must exist for eDirectory to function properly.
Server platforms such as Solaris and Linux provide for time synchronization via NTP as part of their core operating systems. See your operating system's documentation for information on configuring time synchronization on those platforms. Windows NT and higher does not provide this functionality out-of-the-box, so you need a third-party application to synchronize time with this server platform. Several third-party applications exist for this function. You can find information regarding such applications at www.ntp.org/links.html. NOTE Simple NTP ( SNTP ) is an adaptation of NTP . SNTP can be used when the ultimate performance of the full NTP implementation described in RFC 1305 is not needed or justified. Therefore, you can use an SNTP application or the NET TIME facility in a Windows environment, for instance, to provide time synchronization services that eDirectory requires. (On Windows 2000 and higher, you type NET TIME /HELP at a command prompt for more information.) At the time of this writing, SNTP version 4 is the current standard; it is described in RFC 2030.
| 