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:
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:
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:
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:
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:
The following are specific guidelines for replicating the directories that contain node object entries, node synonyms, and backtranslation soft links:
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
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.
|Node object entry||750 bytes|
|Node synonym soft link||520 bytes|
|Backtranslation soft link||520 bytes|
The numbers in the table are based on the following assumptions:
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.
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:
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.