![[Digital logo]](../../IMAGES/DIGITAL-LOGO.GIF){kind=logo}
![[HR]](../../IMAGES/REDBAR.GIF)
Note that the use of the underbar (or underscore) character (_), may be restricted by certain sendmail implementations. As DECnet MAIL-11 addresses may be processed by sendmail on some systems (for example, Digital UNIX), you should take this restriction into consideration.
This chapter contains basic DECdns planning guidelines if you choose to plan and implement a DECdns distributed namespace now. See Section 3.2.2 if you plan to use a Local namespace.
If you plan to use a DECdns distributed namespace, DECdns is a networkwide service that allows users and applications to assign unique names to such resources as nodes, disks, and files, and then use these resources without knowing their physical location. If your network consists of about 100 nodes and you do not expect it to grow much over its lifetime, this chapter is all you need to read to plan for DECdns.
The basic DECdns planning steps are as follows:
Digital recommends using a single namespace for your entire network. However, if your organization has special requirements that justify the use of multiple namespaces, there is nothing to prevent you from creating them. They can coexist without harm to each other.
If multiple namespaces do exist, they are separate and do not share information. You cannot replicate data across namespaces. Users can refer to a name in a namespace other than their own by including the namespace nickname in the full name reference.
Using multiple namespaces might be justified if you have two or more unconnected networks that you plan to always keep separate, or if your organization plans to acquire or connect with separate networks that have existing namespaces. Multiple namespaces might also be a solution for a company with a strong tradition of separate, autonomous departments that would find it difficult to plan a single, companywide namespace.
Another valid reason for multiple namespaces is if you decide to create a test namespace for the purpose of becoming familiar with the DECdns software. In that case, give the namespace a nickname like Test to clearly indicate its purpose. Do not give a test namespace a nickname that you eventually want to use for a networkwide production namespace. Namespace nicknames are difficult to reuse once they have been established in clerk caches throughout the network.
Creating multiple namespaces is not a way to separate names for security purposes. The access control capabilities of DECdns are sufficient to protect names from people and applications that should not see or use them. The following are some additional arguments against using multiple namespaces:
What To Do If a Namespace Already Exists
One or more namespaces might already exist in your network as a result of client applications that use an earlier version of DECdns, called VAX Distributed Name Service (DNS) Version 1. DNS Version 1 and DECdns can interoperate in the same namespace, with a few restrictions and considerations. An appendix in the DECnet-Plus DECdns Management guide contains details on interoperability.
If you have one or more existing Version 1 namespaces, plan to configure the first DECnet-Plus node in one of them. Eventually you should create a Version 2 namespace and merge the other namespaces into it. See the DECnet-Plus DECdns Management guide for details on how to merge namespaces.
Before you configure the first DECnet-Plus node, choose a namespace nickname and establish a naming convention for clearinghouses, directories, and object entries. Chapter 6 contains naming rules and guidelines.
If you decide to create a directory hierarchy, your naming policy can be influenced by the directory structure that you plan and by the way in which names will be used and managed. Your directory structure and naming policy might therefore evolve at the same time.
Small networks should not need to create a hierarchy of directories other than those required for use by Session Control and DECdts. As long as you do not anticipate major growth beyond your network's current size, you can name all of your clearinghouses and DECnet-Plus nodes in the root directory.
Naming everything in the root keeps names short and simple, and it eliminates the planning and management tasks associated with multiple directories. However, it means every node name in your namespace will be in one directory. If you want to protect some names from general access, you need to grant access to individual names rather than granting access to the entire contents of the root directory. See the DECnet-Plus DECdns Management guide for a detailed description of access control.
If your network meets any of the following conditions, read Chapter 8 for guidelines on planning a directory structure:
Before you configure your first DECnet-Plus node, you should plan an overall node-name administration policy. This section presents guidelines for controlling access to the directories containing node object entries, node synonym soft links, and backtranslation soft links. If your namespace will contain entries other than node names, you should plan and implement an access control policy that includes those entries as well.
Note
The DECnet-Plus DECdns Management guide has details on how access control works and shows sample commands for implementing varying degrees of security in your namespace. Read the access control chapter before you configure the first DECnet-Plus node. Digital recommends that you implement an access control policy immediately after you create a new namespace.
The decnet_register tool automatically grants certain access rights for directories, object entries, and soft links that it creates. Depending on the degree of security and centralization you want for node-name management, you can modify the default access control scheme. By default, the tool assigns the following access:
The following three suggested policies offer varying degrees of access control over node data in the namespace.
Note
The default access control policy established by decnet_register applies only to directories created with that tool. The tool always creates the .DNA_NodeSynonym and .DNA_BackTranslation directories. Directories to contain DECnet-Plus node object entries can be created with either the tool or the DECdns Control Program. By default, the control program grants full access for the creator of a directory. Therefore, on directories created with the control program, you must add or modify access if you want it to parallel the access granted by decnet_register.
A basic DECdns guideline is to create at least two replicas of every directory (including the original, or master replica). Replication ensures an alternate source of information in the event that one of the replicas is temporarily unavailable. Replication also creates a live backup of DECdns data in the event that a clearinghouse becomes permanently unavailable.
Replicating data requires at least two clearinghouses, and thus two servers. In very small namespaces, you can configure only one server and rely on 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. If you restore a clearinghouse whose data is replicated elsewhere in the namespace, unexpected and confusing results may occur. For example, recently created names can disappear, recently deleted names can reappear, and recent modifications can be reversed. Replication provides reliable, real-time backup of information and protects you against disk failures and common problems that may occur. Backups of the master replica protect you against deleting object entries. Therefore, the best way to back up DECdns data is to create at least two replicas of every directory.
DECdns creates the root directory automatically when you configure the first server and clearinghouse in the namespace. The root also is replicated automatically at any subsequent server whose clearinghouse you name in the root.
After decnet_register creates and populates the node directories, you should replicate them for availability and backup. Because DECnet-Plus systems are the only ones that use the directories created by the tool, you can replicate them at the same pace at which you migrate nodes to DECnet-Plus. In fact, if you do not have an existing DNS Version 1 namespace, replication must wait until you configure at least one other DECdns server. In small networks, two replicas of every directory should be sufficient. See Chapter 8 for additional replication guidelines for large networks.
Server nodes are the systems that store and maintain the clearinghouses in your namespace. Your main goals in choosing DECdns servers should be to achieve availability of data, reliability, and optimum performance. Study your network and keep in mind the following guidelines to help you achieve those goals:
Unless you already have a DNS Version 1 namespace, the first system in your network to make the transition to DECnet-Plus must be a DECdns server. Many additional factors can influence the choice of the first DECnet-Plus system (see Chapter 2 for details).
To ensure access to data in the event a server becomes unavailable and to distribute lookup load, consider using at least two servers for every thousand nodes. If a server is connected to other servers through high-speed, reliable links, you might be able to use just one server on a LAN. Factors influencing your decision can include the expected lookup load and how you want to distribute it, and the capacity of the systems that you plan to use as DECdns servers.
On extended LANs, consider the reliability of the bridge connecting LANs. If the bridge is frequently unavailable, or if it filters DECdns multicasts, you might want two servers on each side of the bridge. (DECdns servers use multicasts to advertise their existence to clerks and other servers, so LAN bridges that filter multicasts prevent the automatic passage of this information from one LAN to another.) However, if the bridge is reliable and does not filter multicasts, then one server on each side of the bridge is adequate.
Note that with the LAN Bridge 200 product and Remote Bridge Management Software, you can control filtering to allow DECdns multicast IDs to traverse the bridge. The following are the DECdns multicast IDs:
| NSAdvertisement | 09-00-2B-02-01-00 |
| NSSolicitation | 09-00-2B-02-01-01 |
When planning the placement of DECdns servers in a wide area network (WAN) environment, try to avoid connections through WAN links that are not usually stable. Place DECdns servers so that most systems can access at least one server even if a WAN connection is unavailable.
At small sites connected to the rest of the network through a WAN, a DECdns server is not necessary if the small site only occasionally uses resources on the other side of the WAN link. For example, if users at a small site sometimes contact nodes at the company's headquarters, it is probably sufficient to store the node names at headquarters, and it is not necessary to configure a DECdns server at the small site. Remember that once clerks at the small site cache frequently used names, they will rarely need to cross a WAN link for lookups anyway.
On the other hand, if the small site has many DECdns names referring to object entries at the site, it might make sense to configure a server there. Consider storing the master replica at the small site's server if you expect users there to make frequent changes to the names. Doing so further reduces WAN traffic and improves performance.
Consider that when you configure clerks at sites connected by a WAN link, you must manually enter the address of a server that the clerk can contact. This is less convenient than configuring clerks on a LAN, where the clerk automatically receives advertisements from servers on the LAN and caches their addresses.
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:
Digital recommends a multilevel directory structure for large and growing networks. Multiple levels of directories offer the following advantages over a root-only namespace:
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.
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.
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.
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.
PLAN_PROFILE_008.HTML OSSG Documentation 2-DEC-1996 12:32:15.89
Copyright © Digital Equipment Corporation 1996. All Rights Reserved.