![[Digital logo]](../../IMAGES/DIGITAL-LOGO.GIF){kind=logo}
![[HR]](../../IMAGES/REDBAR.GIF)
Figure 9-4 shows the plan for the first two servers in the namespace and the directory replicas their clearinghouses would contain.
Figure 9-4 Replication Plan for New York Servers
Because the .Dist directory would not be used until the Chicago LAN began the transition to DECnet-Plus, the committee decided not to create the directory until that time.
IAF was ready to configure its namespace. The planning committee had established a general naming policy, planned their directory structure and decided on an access control policy, and planned to replicate the same set of directories at each of the first two servers in the namespace. The committee had chosen the first node to migrate to DECnet-Plus and had selected three additional systems to be DECdns servers. More decisions could come later, as the Chicago LAN began the transition and the namespace grew. IAF was ready to begin building its namespace.
Eight months after IAF completed the first phase of its transition to DECnet-Plus, it was ready to migrate the nodes on the Chicago LAN. In the meantime, some major changes occurred within the company as well. As part of its plan to expand its international operations, IAF bought a similar company in Paris, France, called AeroFrance. The AeroFrance network was a LAN consisting of 100 DECnet nodes running Phase IV software. It connected to New York headquarters through an X.25 link.
The AeroFrance company had a very strong sales and distribution organization, whose headquarters remained in France. It had a small engineering group that also remained in France. Some administrative functions stayed at the Paris site, which became IAF's European headquarters. Other functions moved to corporate headquarters in New York, increasing the number of nodes there to 70 and reducing the number of nodes in Paris to 50.
When IAF acquired AeroFrance, IAF consolidated its U.S. engineering operations. IAF thought that the New York engineering group should be physically closer to the distribution organization that it served. Also, both the New York and Chicago engineering groups were too small to be under separate administrators. Therefore, the two groups were combined in Chicago, increasing the number of nodes there to 40. Figure 9-5 shows the new network topology after the acquisition of AeroFrance and the combination of the domestic engineering groups in Chicago.
Figure 9-5 Expanded IAF Network
IAF decided to start migrating the AeroFrance nodes to DECnet-Plus on a parallel transition schedule with the Chicago LAN, so that the Paris LAN could also take advantage of DECdns and other features of DECnet-Plus. The acquisition, the engineering reorganization, and the DECnet-Plus transition caused several changes to the namespace over the next year.
One major change was the addition of DECdns servers. Because the newly acquired French company was a single LAN, IAF took the same approach it had planned for New York and Chicago and configured two servers in Paris. The new network, combined with transition of the Chicago site, resulted in four additional servers, with clearinghouses named .Chicago1_CH, .Chicago2_CH, .Paris1_CH, and .Paris2_CH.
Figure 9-6 shows the four new DECdns servers --- two in Chicago and two in Paris --- and their contents at the end of the year.
Figure 9-6 New Servers and Their Contents
The figure reflects the following changes:
Figure 9-7 shows the status of the two New York clearinghouses at the end of the year.
Figure 9-7 New York Server Contents a Year Later
The figure reflects these changes:
The remainder of this chapter explains in detail each of the changes that occurred and refers to other documentation for details on the activities described.
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.
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.
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.
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 each example.
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.
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.
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.
Note
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).
| Local Servers: | ||||
|---|---|---|---|---|
| Location | Node Name | Node Number | Manager | How to Contact |
| Global Servers: | ||||
| Location | Node Name | Node Number | Manager | How to Contact |
| Network DECdns Information: | ||||
| DECdns manager: | ||||
| Closest DECdns server node: | ||||
| Format for global server name: | ||||
PLAN_PROFILE_010.HTML OSSG Documentation 2-DEC-1996 12:32:19.04
Copyright © Digital Equipment Corporation 1996. All Rights Reserved.