HP OpenVMS Systems Documentation
This chapter describes how to plan your DECdts implementation, including personnel selection for the planning process, and planning for DECdts on a LAN, an extended LAN, or a WAN. The DECdts software is shipped on the same media as the DECnet-Plus software, so hardware installation considerations are only included by reference. Some of the planning considerations for DECdts are tied to the planning of DECdns. Plan how you will use the two products simultaneously. For DECdns planning considerations, see Chapter 7 and Chapter 8.
Two main categories of personnel will interact with the DECdts software: system managers and applications programmers. Programmers do not usually need to be involved in the planning stages of the DECdts implementation. If you are writing a program to import a source of Coordinated Universal Time (UTC) into the service, however, you may wish to locate the time-provider at the server that is closest to the programmer. Close proximity to the time-provider will help the programmer when testing the software application with the time-provider hardware.
System managers or network architects usually plan the DECdts implementation. System managers also install the software and maintain DECdts. They decide which nodes will be servers and which will be clerks, and decide how the DECdts implementation will grow with the network. DECdts is fully scalable for networks of any size, so expanding the implementation to include new nodes is relatively simple.
All references to DECdts servers apply to those servers running on
ULTRIX, DIGITAL UNIX, or OpenVMS VAX systems.
10.1 Planning a DECdts Implementation
Consider the following questions as you plan your DECdts implementation:
The following sections will help you answer these questions. The worksheet at the end of the chapter is provided to help you map your time service plan before you begin the installation.
Although there are many network configurations that affect DECdts planning, several general rules apply regardless of your network configuration or the number of nodes in the network. These guidelines are summarized as follows:
Although you must consider many other factors when planning your
network, these factors depend on your network topology and
configuration. The following sections present some typical network
arrangements to help you implement DECdts on your own network.
10.2 Configuration Planning on a LAN
If your nodes are in a single local area network, regardless of the number of nodes, planning your DECdts implementation is relatively simple. You can configure a minimum of one system as a server, but to enhance reliability and to detect faulty time servers, configure at least three systems as servers. If you want to provide redundancy for your DECdts implementation, plan to install four or more servers in the network. That way, if one of the servers fails, DECdts can still synchronize with reliable results.
To ensure the reliability of your DECdts implementation, make sure that the network connections between server nodes are stable. If you plan to add WAN links to your LAN, do not move the servers to the remote nodes, because WAN links are usually less reliable than the LAN.
If you have a single LAN, the location of the servers on the LAN is not critical. You can locate one of the servers on a readily accessible node to aid in troubleshooting, but there are no other recommended server locations. Neither global servers nor couriers are required.
For all network configurations, you must install DECdns concurrently with DECdts to run both services. DECdns is usually configured with two name servers per LAN. To ease installation, management, and maintenance, you can locate the DECdns global name servers and two of your local DECdts servers on the same nodes. The DECdts servers will not add significantly to the processing or memory demands on a node.
If you are planning to use one or more time-providers, locate them at easily accessible systems to ease startup and maintenance. If your network requires only synchronized clocks, but does not need to closely follow a time standard such as UTC, you may not require a time-provider. If you do not use a time-provider, we recommend that you use the update command to manually set the time approximately once each week.
Figure 10-1 shows a simplified LAN configuration. Your LAN may be much larger, but the figure should resemble a portion of your network.
Figure 10-1 DECdts LAN Configuration
Configuring an extended LAN can be as simple as configuring a single LAN, or it can be more complex, depending on the type of bridge that connects each LAN segment and how many nodes are in each segment. For the purposes of DECdts, extended LANs fall into one of the following categories:
The following sections describe possible configurations for each type
of extended LAN.
10.3.1 Extended LANs Using High-Performance Bridges
If you are using the LAN Bridge 100 or METROWAVE bridges to connect the different segments of your LAN, and you have not configured the bridges to block multicast messages between segments, the bridges can be transparent to DECdts. Neither of these bridges introduces a significant amount or variation in delay during intersegment synchronization, provided that the following conditions are also met:
If you follow these guidelines, you can spread the time servers over the network at whatever locations are convenient, just as you would for a single LAN. You need not set up three servers on each segment, because multicast synchronization messages will be relayed over the network interface without delay. When placing the servers (including name servers), you need only consider the quantity of servers, not their locations. Figure 10-2 illustrates this type of configuration.
Figure 10-2 DECdts Configuration --- Unified Extended LAN
If you are using TransLAN bridges between your extended LAN segments, or if any of the following conditions exist, the number and placement of servers in each extended LAN segment is critical:
If the bridge does not forward multicast messages, local servers in each segment cannot receive advertisement messages from local servers in other segments. Even if a bridge forwards multicast messages, the variable delays between the LAN segments can lead to high clock skews between local servers on opposite sides of a bridge. In all cases, treat each segment of the extended LAN as though it were a separate LAN.
Because you should consider each segment of your extended LAN as a separate entity while planning your DECdts implementation, configure each segment according to the following guidelines. (Note that you must also take DECdns configuration into account).
Because there are many variations on WAN configurations (especially in combination with LANs and extended LANs), it is impossible to describe every case where a WAN link can be used to disseminate time. This section does not give recommendations for every case involving a WAN link, but describes how you can set up your DECdts implementation using several generic configurations as examples.
Due to the variable delay inherent in any WAN link, it is difficult to maintain a consistent skew between clocks on opposite sides of the link. DECdts synchronizes clocks across WAN interfaces, but larger inaccuracies occur between the clocks to account for the worst case transmission delay during each synchronization.
A reliable and robust DECdts implementation is important any time WAN links are part of your network. Because WANs are less reliable than LANs, plan for some redundancy in any DECdts implementation involving WAN links. Try to place servers so there will always be three or more available, even if one of the WAN links goes down.
The following sections give recommendations for three basic WAN configurations:
Your network may not exactly match any of the configurations, but you
will be able to plan your network by following the recommendations for
10.4.1 LANs with WAN Links to Remote Sites
Figure 10-3 shows a LAN that incorporates several remote nodes by using WAN links.
Figure 10-3 DECdts Configuration --- LAN with WAN Links
In this configuration, follow the basic recommendations for a single LAN, but also adhere to the following rules:
The network configuration resulting from the rules outlined above
concentrates the servers on the LAN, so clock skews are kept to a
minimum and the service is not dependent on remote nodes that may be
physically inaccessible to the system manager. Each remote clerk node
synchronizes with the global servers on the LAN in order to satisfy the
servers required requirement.
10.4.2 LANs Connected by WAN Links
The rules outlined for extended LANs that use the Vitalink bridge also apply to LANs connected by WAN links. Each LAN in such a network is a separate entity, so several DECdts components must be configured on all of the LANs. For the best performance, configure each LAN according to the following guidelines:
These recommendations will result in peak DECdts efficiency and
availability despite the irregular delays associated with WAN links.
10.4.3 WAN Networks
Figure 10-4 shows a geographically distributed network with no LANs. DECdts delivers higher clock skews in an all-WAN environment, but still provides synchronization adequate for most distributed applications. In such a network, clock skews approximate the round trip delay between nodes.
Figure 10-4 DECdts Configuration --- WAN Networks
Many of the same recommendations for a LAN with WAN links also apply to the network that does not have any LANs. Keep the following considerations in mind when planning your all-WAN network:
To closely synchronize your systems with UTC and with each other, you can place one or more time-providers in your network. Time-providers have many forms: they can be radio receivers, software/modem combinations, or satellite receivers. See the DECnet-Plus DECdts Programming guide for additional information about time-providers and the time-provider interface that you can use to integrate these devices in your network.
If you plan to use time-providers in your network, you can write a time-provider program to match the time-provider interface or use one of the sample programs that are supplied with the DECdts software. After you select your time-provider device and program, plan where to install the device in your network.
It is relatively simple to locate time-providers to your best advantage. Time-providers must be located at servers; if your network has several segments and you are using global servers to maintain synchronization across the network, locate the time-providers at the global servers. Regardless of your network configuration, place the time-providers where they will have the highest availability and use.
You cannot configure a server connected to a time-provider as a courier. A server connected to a time-provider never assumes the courier role, because the server process only solicits time values from the time-provider. For additional information about courier servers, see the DECnet-Plus DECdts Management guide.
This section provides a worksheet for you to fill out before you install the DECdts servers. The worksheet provides a place to keep track of the server systems so you can manage them remotely using the NCL management interface (you must have applicable privileges).
|Location||Node Name||Node Number||Manager||How to Contact|
|Location||Node Name||Node Number||Manager||How to Contact|
|Network DECdns Information:|
|Closest DECdns server node:|
|Format for global server name:|