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:

• Is your network a single LAN, an extended LAN, a WAN, or a combination of LANs and WANs?
• What is the current or proposed network topology (component placement)?
• How many servers will be required? Where will they be located?
• Will global servers be required? Where will they be located?
• Will you need to configure some local servers as couriers if you are using global servers?
• Will you use an external time-provider to obtain UTC?
• What will the time zone be for each system?

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:

• Your network should have a minimum of three DECdts servers.
• Each LAN should have a minimum of one server.
• You should locate the servers at the sites with the greatest number of nodes or at backbone sites with high-speed links to the rest of network.

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:

• Extended LANs that use the LAN Bridge 100 or METROWAVE bridges.
• Extended LANs that use the Vitalink TransLAN or the high-performance bridges but block multicast messages between segments.

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:

• The bridges are not bottlenecks, due to extremely high volumes of traffic.
• There are few redundant bridges connected in series.
• The network is small or medium sized.

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:

• Multicast messages are blocked at the bridge.
• The bridge is frequently unavailable.
• Delays are sometimes incurred due to high intersegment traffic.

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).

• Create a minimum of one server in each segment.
• For the lowest skew between nodes, create three or more servers in each segment.

• Configure one server on each segment as a courier.
• Use the advertise command to configure one server on each segment as a global server.
• If you are using time-providers, connect them to global servers.

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:

• A LAN or extended LAN with WAN links to remote nodes
• LANs connected by WAN links
• An all-WAN network with a central host or cluster

Your network may not exactly match any of the configurations, but you will be able to plan your network by following the recommendations for each example.

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:

• Create a minimum of one server in each LAN; to increase reliability, create three or more servers in each LAN.
• Configure servers at remote sites as global and courier servers.
• For each remote clerk, set the servers required attribute to (3).
• If you are using a single time-provider, locate it at a global server on the LAN with the greatest number of clerks.

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:

• Configure at least three DECdts servers on each LAN.
• Configure at least one server on each LAN as a courier.
• Configure at least one global server on each LAN.
• If you are using time-providers, install them in the LANs that contain global servers.

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:

• The network should have at least three servers (preferably four or more).
• Every server should be configured as a global server.
• Couriers are not required, however, you can configure any or all of the servers as couriers. The servers required attribute will force each global server to synchronize with at least two others.
• Local servers are not required.
• You can place the servers anywhere in the network, but place at least one at the central site; choose the most active remote nodes connected by the most reliable links for the rest of the servers.
• If you are using time-providers, place one at the central site. Connect each time-provider to a global server.

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.

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).