HP OpenVMS Systems Documentation

If your network is large, or if you have a small network now but want to plan ahead for growth, use the additional guidelines in this chapter to plan your distributed namespace. These guidelines also are useful for planning a namespace into which a DNS Version 1 namespace and its entries will eventually merge. The chapter offers guidelines in three main areas:

• Planning a directory hierarchy
• Replicating directories
• Calculating server capacity needs

DIGITAL recommends a multilevel directory structure for large and growing networks. Multiple levels of directories offer the following advantages over a root-only namespace:

• Greater opportunity to distribute information in the network, decreasing the processing load on any one system.
• Ability to separate object entries based on where they are used, their frequency of use, the people who use them, or whatever criteria suit your needs.
• Decreased probability of duplicate names (for example,
  .Eng.Aero.Dev_disk and .Eng.Plastics.Dev_disk are unique).
• Ease of delegating access control and administrative responsibility for subsets of directories and object entries.

Overall, try to create no more than three or four directory levels. In very large networks, people at individual sites might create and own lower-level directories that are minimally replicated (for instance, not beyond a LAN) and used mainly by a specific group of local users. In such cases, users can create as many levels of directories as they deem necessary and convenient to manage.

However, remember that every directory requires additional network resources for skulking and increases administrative overhead in areas such as access control and replication. Also, a long directory path results in names that are hard to remember and type. Do not create empty directory levels to serve as place markers in names.

8.1.1 Consider Geographic and Functional Directory Names

You can design a directory structure based on functional areas of your organization, geographic areas of your network, or a mixture of both. Choose whatever scheme best suits your organization's needs and preferences. The decision should be influenced partly by how you want to populate and replicate the directories. For example, you could populate a geographic directory with names used mainly by a group of users concentrated in one geographic area, and replicate the directory close to those users. Similarly, you could populate a functional directory with names used mainly by people in a particular branch of an organization.

Functional directory names can be useful if your organization:

• Has a well-established and stable functional structure that is not likely to change much over time.
• Consists of several independently functioning units that each use their own resources.

You can use your company's organization chart as a template for designing functional directories. Remember to choose names that are not likely to change; derive directory names from a department's business function, not its current title. Some sample functional directory names are .Sales, .Admin, .Mfg, and .Eng, for storing names used by the Sales, Administrative, Manufacturing, and Engineering branches of an organization.

In addition to or instead of creating functional directories, you can create geographic directories. For example, you could name upper-level directories .NY, .Paris, and .Geneva, with lower-level directories based on site codes or some other more specific geographic name. The following are reasons for using geographic directory names:

• To organize names that are used mainly by a concentration of users in certain geographic areas.
• To avoid skulks of the root directory across wide geographic areas.

Every clearinghouse named in the root directory must store a replica of the root; see Section 8.2.2 for details. By naming clearinghouses in geographic directories below the root, you can give an indication of their location and also help reduce skulking of the root directory across long distances.

If node names are traditionally managed by site or geographic area, you might group them in geographic directories. If a node communicates most frequently with other nodes in its geographic area, this scheme would also result in more efficient lookups, provided that you replicate the geographic directory at servers in the location that the directory covers. Any other names that are used or managed primarily by location can be stored in geographic directories as well.

8.1.2 Plan Access Along with Directory Structure

While you plan the structure and contents of directories, consider an overall name administration scheme. Your plan for who will use and manage names can have a strong influence on directory structure. For example, the root and other upper-level directories should be stable, widely replicated, and limited in content, and only a few trusted people should be able to create or modify their contents.

As part of namespace creation, the DECnet configuration procedure creates an access control group called .DNS_Admin, which you can use to control access to the namespace. You can limit access to top-level directories by granting only the .DNS_Admin group the more powerful access rights (write, delete, and control) to those directories. You also can set up access control entries (ACEs) that propagate down to newly created directories and their contents, giving the .DNS_Admin group a window into activities or problems that occur anywhere in the namespace.

More flexible administration and access control is possible at lower levels of the namespace hierarchy, where directories might be created, controlled, and written to by a limited number of local users. The content and structure of these directories can be determined by the people who will use and manage them.

Keep in mind that it is possible to share a directory. Because access control is assignable to both object entries and directories, several different client applications or user groups can share a directory without being able to change or delete each other's names. A namespace administrator or server manager with access to the entire contents of a shared directory should monitor it routinely for growth.

8.1.3 Other Directory Planning Tips

The following are some additional guidelines for planning directories and their contents:

• Keep the root small and stable.
  The root directory will probably be one of the most widely replicated directories in the namespace, especially if you name most or all of your clearinghouses in the root (when a clearinghouse is named in the root directory, the root is automatically replicated in that clearinghouse). To minimize overhead from skulks of the root directory, limit the contents of the root to object entries that will not change often.
  The root should contain a maximum of 100 widely used object entries (including clearinghouse object entries and node object entries) and should not be cluttered with names used by only a small number of people. This restriction is less important for networks with only a few servers. Consider a root directory that contains 250 object entries, replicated in a namespace that contains only two servers. The impact of skulking two replicas of the directory would be less than the impact of skulking 20 replicas of that same directory. Note also that the recommended limit does not apply to the number of child directories the root can have.
• Limit other directories to a manageable size.
  Directories have a practical size limit based on manageability. Factors to consider include the following:
  • How easy is it to assign and control access to a directory's contents? If you want to implement a simple access control scheme (for example, assigning default access to the entire contents of a directory), your decision may limit a directory's contents, and thus its size.
  • How widely must a directory be replicated? A directory containing many names may need to be replicated in several places to locate the names close to their users. Update propagation and skulking on large, widely replicated directories adds overhead, especially across WAN links. For example, if you have three sites and 1,000 object entries, and all of the sites need those object entries, keep them in one directory. On the other hand, if specific object entries are used only by users at one site, you can save overhead by locating those object entries in a directory at that site.
• Anticipate growth.
  Try to design a namespace that allows horizontal expansion (more directories directly under the root) and avoids vertical expansion (more levels of directories). This design will help limit the number of directory levels and make the namespace easier to manage, even as it grows.

Your strategy for replicating directories is especially important in the initial stages of namespace operation. Once a clerk establishes a cache of frequently used names, the clerk will rarely need to locate a replica for the information it needs. However, well-planned replication of directories can make the clerk's process of learning about names in a large network easier and more efficient. The number and size of replicas that you plan in the namespace can also affect your choice of servers.

When planning replication in large networks, consider the following guidelines to enhance DECdns performance:

• Ensure availability.
  Every directory should have at least two replicas (including the master replica). Replication ensures an alternate source of information in the event that one of the replicas is temporarily unavailable. Very small namespaces with one DECdns server can use traditional operating system backups to preserve DECdns information. However, backups are not a good way to preserve data in namespaces with more than one clearinghouse. Multiple replicas are especially important in these namespaces because you cannot depend on traditional operating-system backup methods to preserve replicated data. Data restored from backups might contain outdated timestamps, which cause replicas to lose synchronization and can cause DECdns to return outdated information. Replicating is the most reliable way to create a backup of data in a clearinghouse.
• Distribute the lookup load.
  Identify directories that will get the most use for lookups and updates, and replicate them on several different servers. This helps to distribute the lookup load.
• Locate a replica where its users are.
  If you design a directory so that its most frequent users are widely dispersed geographically, replicate it accordingly. Alternatively, you can avoid wide replication of a directory by populating it with names used mainly by a group of users who are concentrated in one geographic area.
• Locate a name close to the resource it describes.
  Create an object name in a directory that is replicated close to (for example, on the same LAN as) the resource it describes. Because a resource is most often used by people close to it, replicating its name nearby can save network resources and make lookups more efficient. Usually, it is practical to limit the replication of lower-level directories to clearinghouses that are closest to where they will be used.

• Help DECdns find a name efficiently.
  Replicate the root directory and other high-level directories widely, because the clerk must often find the root and work down from it in initial attempts to look up names. Also, you can reduce WAN traffic by placing the root and other high-level directories at sites that frequently refer to names stored across a WAN link.

The following are specific guidelines for replicating the directories that contain node object entries, node synonyms, and backtranslation soft links:

• If a directory contains node object entries, locate at least one replica (preferably the master) on the same LAN as the nodes the entries describe.
• Locate at least one replica of the .DNA_NodeSynonym directory on every LAN that includes DECnet-Plus nodes.
• Locate the master replica of each .DNA_BackTranslation area directory in the area it is named after, if that area contains DECnet-Plus nodes. Also replicate an area directory in other areas likely to communicate most frequently with the nodes whose addresses it contains.
• In a solely WAN environment, try to replicate every directory so it can be reached reliably by any DECnet-Plus system that needs it.

To ensure its ability to find names, DECdns enforces some rules regarding clearinghouses and their contents. The DECnet-Plus DECdns Management guide contains an appendix that explains the rules in detail. For planning purposes, the main rule to remember is that whenever a clearinghouse is named in the root directory, the root is automatically replicated in that clearinghouse. In a network with more than 50 DECdns servers, naming all clearinghouses in the root could, therefore, cause replication of the root beyond a practical limit. Naming some clearinghouses in directories below the root helps to avoid this problem.

For instance, if you have 50 clearinghouses in a network and you name them all in the root, the root directory is replicated in at least 50 places to comply with the rule. Then, every time DECdns skulks the root directory it must be able to contact and process all 50 replicas. The greater the number of replicas, the greater the demand on system and network resources, and the greater the chance for skulks to fail. Skulks also can fail if a directory is replicated across an unreliable WAN link.

Therefore, if your namespace will have more than 50 clearinghouses, you can help avoid problems with replicating and skulking the root by naming some clearinghouses in lower-level directories. Naming a clearinghouse in a directory other than the root eliminates the requirement that a replica of the root be stored there, thus reducing the total number of root replicas in the network.

If your namespace is easily divisible by geographic area, you could create some geographic directories under the root and name clearinghouses in those directories; for example, .Tokyo.Site1_CH, .Wash.Seattle_CH, or .Paris.Branch3_CH. The geographic directories in each clearinghouse could also contain data used primarily by the people and applications in that geographic area, and the work of skulking replicas would be more evenly distributed than if all of the data were in the root.

8.3 DECdns Server Capacity Planning

To determine whether a node has the capacity to be a DECdns server, consider several factors, including the system's disk space and processing power, the demand that other applications already place on the system, and the demand you expect from DECdns.

If you expect high DECdns lookup and update demand, consider using a dedicated server. DIGITAL recommends using dedicated servers for large networks, because a dedicated system generally boots faster than a timesharing system, and you can select it specifically for optimum DECdns server performance. For example, you will probably have to increase the swap space on a server with a clearinghouse that contains many directory replicas or replicas with many entries. Keep in mind that a few large, dedicated servers can perform better than many small timesharing systems.

To estimate capacity requirements for a server, assess the number of directory replicas to be stored at each server and the number of entries in those replicas. Table 8-1 contains estimates of memory usage for ACEs, directories, node object entries, and soft links.

The numbers in the table are based on the following assumptions:

• Node name length is 30 characters or fewer.
• ACE estimates are based on a fixed requirement of about 40 bytes plus a variable requirement for the length of the principal specification. The 60-byte total is derived from an estimated average principal length of 20 bytes (for example, .Sales.Node01.Miller is a principal requiring 20 bytes).

If you plan node names of 30 characters or longer, or if you expect principal names to be longer or shorter than 20 characters, adjust the capacity estimates accordingly. Also remember that a lengthy list of ACEs can quickly increase the space requirements of a directory, object entry, or soft link.

One way to conserve space on ACEs is to use the .DNS_Admin namespace administrator group, created automatically as a part of namespace creation. You also can create and use similar administration groups for each directory you create. Then each entry needs only one ACE per group, and you can control access to the entry by adding and removing members of the group. In addition to saving space, the use of groups is easier and more efficient than adding and removing individual ACEs. See Chapter 9 and the DECnet-Plus DECdns Management guide for a complete discussion of the use of groups.

Add a 30 percent margin of safety after figuring the requirements for nodes and directories. This margin is necessary because of the way storage is allocated for object entries in the database. Even if only one object entry exists, a fixed space is allocated for it that is more than the entry actually requires.

Now that you know the amount of space your clearinghouse requires, you need to make sure that your server's disk, memory, and (on ULTRIX or DIGITAL UNIX systems only) swap space can support it. The server loads the entire clearinghouse into memory. You can obtain the best performance by providing enough physical memory to contain the entire clearinghouse. Very large ULTRIX or DIGITAL UNIX servers need to be configured for additional swap space to support the virtual memory use of the server. Similarly, OpenVMS VAX servers require sufficient paging file space to support the server. The OpenVMS VAX server startup uses the VIRTUALPAGECNT SYSGEN parameter to determine its maximum page file quota. It also uses WSMAX as its working set extent and WSMAX*.3 for the working set quota.

On ULTRIX, DIGITAL UNIX, or OpenVMS VAX servers, the disk with the clearinghouse files themselves (the /var partition or the [DNS$SERVER] directory) must be able to hold two copies of the clearinghouse.

Capacity Planning Example

The following hypothetical example is a DECdns capacity plan for a small organization, ABC Company, whose network consists of 30 nodes. The nodes are all on the same LAN and in DECnet area 1, and the planners have chosen to use a default initial domain part (IDP) of 49.

The namespace planners decided to configure two servers, each containing the same directory replicas. They decided to create no additional directories other than those required by DECnet-Plus and DECdts. So each clearinghouse would contain replicas of the following six directories:

• . (the root)
• .DNA_NodeSynonym
• .DNA_BackTranslation
• .DNA_BackTranslation.%X49
• .DNA_BackTranslation.%X49.%X0001
• .DTSS_GlobalTimeServers

Given that all of their nodes would be named in the root, and that most of their node names would not exceed 10 or 12 characters, the planners thought that the estimate of 20 bytes required for a principal was high. They decided to reduce the estimate for principals to 15 bytes, thus reducing the total storage requirements for ACEs to 55 bytes each. They estimated an average of four ACEs on each directory and entry in the namespace. They also estimated that the server needs an additional 134,000 bytes for swap space for ULTRIX. Based on these considerations, the ABC Company planners produced the following node and directory capacity worksheets:

The planners then added the node total and the directory total and factored in a 30 percent margin of safety, as shown in the following worksheet:

As a final step in capacity planning for ULTRIX or DIGITAL UNIX systems, the planners estimated that the server needs an extra 134,000 bytes for swap space and the clearinghouse database needs 268,000 bytes in the /usr/var/dss/dns partition. For OpenVMS VAX systems, the planners estimated that they need a minimum of 525 blocks in the DNS$SERVER default directory.