|
HP OpenVMS Systems Documentation |
|
DECnet-Plus
|
| Previous | Contents | Index |
International Air Freight (IAF) Corporation is a hypothetical air freight company that does business in the United States, Europe, and Japan. The company plans to expand into other countries in the near future and anticipates considerable growth in its network.
The company consists of a New York office and a Chicago office. The New York office is corporate headquarters and is also the base for IAF's sales organization. A small engineering group in New York develops and maintains software applications specific to the company's business and distribution needs. Chicago is the hub of IAF's distribution operations. Also in Chicago is a small engineering and manufacturing group. This group designs and manufactures the packaging that IAF uses to transport freight.
The IAF network currently consists of 22 DECnet nodes on a local area network (LAN) in New York and 18 DECnet nodes on a LAN in Chicago. The two LANs are connected by DEC WANrouters that are communicating by means of a High-level Data Link Control (HDLC) link. DECnet-Plus software is in use, and the hardware includes workstations, personal computers, and large VAX systems. DECdns servers are running on DECnet-Plus for ULTRIX and DECnet-Plus for OpenVMS VAX systems. Figure 9-1 is a representation of the IAF network.
Figure 9-1 The IAF Network
IAF's introduction to DECdns came when the company decided to upgrade its network to DECnet Phase V. Network administrators learned that DECnet-Plus Session Control can use DECdns to store and look up node names. They saw the ability to distribute node names, combined with the automatic updating capability of DECdns, as a time and resource saver. In the beginning, DECnet would be the primary user of DECdns and node names would be the primary entries in the namespace. The DIGITAL Distributed Time Service (DECdts), another component of DECnet-Plus, would use DECdns to store the names of global servers that synchronize system clocks in the network.
When planning for DECdns, IAF anticipated future use by applications in addition to those that would be in place immediately after the transition to DECnet-Plus. Other client applications that IAF planned to use included DIGITAL's VAX Distributed File Service (DFS), VAX Notes, and Remote System Manager (RSM), products that use Version 1 of the name service.
IAF engineers also planned to develop their own client applications specific to the company's distribution, manufacturing, and administrative needs. For instance, IAF had a real-time application that collected data on the location and flight times of air carriers and tracked the status of freight at each of the company's distribution sites. The application used a message bus for task-to-task communications and message queuing. The message bus, in turn, would be adapted to store the names and addresses of its message queues in DECdns.
IAF assembled a planning committee to plan the transition from DECnet Phase IV to DECnet-Plus and to plan the DECdns namespace. The committee decided to make a staged DECnet transition. First, they would upgrade a portion of their LAN in New York and configure two DECdns servers there. Six to eight months later, they would begin to upgrade the Chicago LAN, configuring two DECdns servers there as well. Transition of the remaining nodes in New York would be gradual, as time and resources allowed.
This chapter discusses decisions the IAF planners made in designing and
configuring their namespace. It also describes some of the business
changes the company went through after initially setting up its
namespace, and explains the effects those changes had on the namespace.
The discussion refers to other manuals or other chapters in this manual
for more information on some of the activities described.
9.1 Part 1: Planning and Configuring the Namespace
The planning committee chose a namespace nickname based on the initials that stand for the company's name: IAF. For naming clearinghouses, the committee decided to identify a clearinghouse by the city where it was located and adopted the recommended convention of adding a _CH suffix to a name. They knew they would have fewer than 50 clearinghouses, so they also followed the recommendation for naming all clearinghouses in the root directory. For example, clearinghouses in New York would be called .NY1_CH and .NY2_CH.
Next, the committee decided to assess the size and contents of the IAF namespace to determine whether they needed to create a directory structure. They knew that, for DECnet-Plus, every node in the network would have three entries in the namespace: an object entry and two soft links. After considering the needs of other applications, the committee produced the following list of projected namespace contents:
It was clear that node names and soft links would have the most
significant impact on the namespace; the number of names created by
other applications would be minimal. Even the impact of node names and
soft links would be minimal in a network the size of IAF's. However,
the company and its network were expected to grow. Therefore, the
planning committee decided to prepare for future expansion by designing
a directory hierarchy.
9.1.1 Designing the Directory Structure
The committee decided that creating several directories, all one level below the root, would be more than sufficient to handle the size of the IAF namespace. They wanted to avoid the longer names and the additional management tasks associated with multiple directory levels. They also felt confident that it would be a long time before any one directory contained more than 5000 names: a number that they considered a practical directory size limit.
The planners decided on a functional directory naming scheme. The decision was easy, because IAF is a functionally oriented organization. Resources, including nodes, are allocated and managed on a departmental basis, regardless of geographic location. For that reason, the company's organization chart could serve as a template both for the directory structure and for designing an access control policy.
Using the organization chart, the committee planned functional directories for administration, engineering, distribution, and sales, resulting in the hierarchy shown in Figure 9-2.
Figure 9-2 IAF Namespace Hierarchy
The namespace access control policy would be closely tied to the directory structure. The committee decided to implement a policy of world read and test access on the entire namespace, but to limit other access rights for each functional directory to the main users and managers of the names in those directories. They would use DECdns access control groups to implement this policy.
The .DNS_Admin group, a namespacewide administrative group, would consist of the network manager, who was the designated namespace administrator, and other staff members from IAF's Network Control Center. The members of the .DNS_Admin group would be the only people with full access to the root directory. The planners also decided to give the group access that propagates down to all subsequent directories and their contents. The propagating access would allow the .DNS_Admin group members to monitor any changes or problems in the namespace.
The .DNA_Registrar group is an access control group created during configuration of the first DECnet-Plus node in the namespace. Its purpose is to contain the names of people responsible for managing node object entries and soft links. The planners had read the DECnet transition documentation and decided to use this group as well. They decided to make the .DNS_Admin group a member of the .DNA_Registrar group, automatically granting the namespacewide administrators access to all node-related entries in the namespace. Additionally, the .DNA_Registrar group would contain the names of people at each site who were traditionally responsible for assigning and monitoring node names.
In addition to the .DNS_Admin and .DNA_Registrar
groups, the planners decided to create separate access control groups
to manage each functional directory. The directory management groups
would be named .Admin.Dir_Admin, .Sales.Dir_Admin,
.Eng.Dir_Admin, and .Mfg.Dir_Admin. Each group would have
full access to the contents of the directory it was associated with,
and would contain the names of the current managers of that directory.
With groups as the main method of granting access control, the
namespacewide administrative group could simply add and remove members
of a group instead of creating and deleting individual ACEs whenever
management responsibility for a directory changed.
9.1.3 Assessing Directory Contents
Based on their decisions, the planners outlined the contents of each directory as follows:
In addition, the following directories would be created during or soon after configuration of the first DECnet-Plus node:
With these additional directories added into the hierarchy, the complete picture of the namespace would look like the one in Figure 9-3. The shaded areas separated by white lines indicate levels of the hierarchy.
Figure 9-3 Complete IAF Namespace Hierarchy
The committee could see that, at least in the initial stages of DECdns
usage, the sales and engineering directories and the node soft link
directories would be the most heavily populated. However, the planners
were not concerned that some directories would be larger than others.
They knew that load balancing is determined not by directory size but
by the number of servers in the namespace and how directories are
replicated on those servers. Additionally, in such a small namespace,
none of the directories would contain enough entries to have
significant impact relative to any other directory.
9.1.4 Choosing Servers and Planning Replication
The next step for the committee was to plan how they were going to replicate directories and how many DECdns servers they would need.
After considering the guidelines in Chapter 8, the planners decided to configure two servers on the New York LAN and two servers on the Chicago LAN. The clearinghouses at the two New York servers would both contain an identical set of directory replicas. The planners felt this replication scheme would help to reduce confusion during the initial configuration of DECdns in the network. They also knew it would help to balance the work load between the two servers, increase the likelihood of finding a name without going off the LAN, and provide automatic, real-time backup of data in case a clearinghouse or replica became corrupted or temporarily unavailable.
The committee selected systems based on estimates of 1 MIPS of CPU power, 3,000 disk blocks, and 1 megabyte (2,000 pages) of memory required to run DECdns in the IAF network. In choosing the first server to be configured in New York, the committee also considered additional requirements, because that system would be the first system in the network to make the transition to DECnet-Plus. Table 9-1 indicates the systems selected to be DECdns servers.
| Clearinghouse Name | Server Hardware |
|---|---|
| .NY1_CH | VAX 6310 |
| .NY2_CH | VAXstation 3500 |
| .Chicago1_CH | DECsystem 5400 |
| .Chicago2_CH | DECstation 3100 |
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.
9.2 Part 2: The Namespace Grows
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.
| Previous | Next | Contents | Index |