|
HP OpenVMS Systems Documentation |
|
DECnet-Plus
|
| Previous | Contents | Index |
The Local namespace is a discrete, nondistributed namespace that exists on an individual node and provides that node with a local database of name and addressing information. The Local namespace replaces functionality previously provided by the DECdns Local Naming Option. Depending on the number of address towers stored, the Local namespace is designed to scale to at least 100,000 nodes.
DECnet-Plus recognizes that when a node full name begins with local:, information for that node is stored in a Local namespace. The following are typical node full names properly formatted for the Local namespace: local:.xyz.abc and local:.maximum.
Unlike DECdns, the Local namespace does not employ backtranslation directories for address-to node-name translation.
The DIGITAL Distributed Name Service (DECdns) is a networkwide service that makes it possible to use network resources without knowing their physical location. Users and applications can assign DECnet-Plus names to resources such as nodes. The creator of a name also supplies other relevant information, such as the resource's network address, for DECdns to store. Users then need to remember only the name, and DECdns acts as a lookup service, providing the rest of the data when necessary. DECnet-Plus for DIGITAL UNIX does not contain DECdns server software.
The DIGITAL Distributed Time Service (DECdts) is a networkwide service
that synchronizes the system clocks in the network's computers. DECdts
enables distributed applications to execute in the proper sequence even
though they run on different systems.
5.1 How DECnet-Plus Uses the Local Namespace and DECdns
All DECnet-Plus systems require a name service because the Session layer of DECnet-Plus uses it to map node names to addresses.
DECnet-Plus provides access to the node name and addressing information stored in one or more of the following name services.
While configuring DECnet-Plus, the system administrator specifies one or more of the following name services to use on the node: the Local namespace; DECdns; or Domain. Note that in this version of DECnet-Plus, even when you are using the Local namespace the DECdns clerk software is still required on each node by DECnet-Plus.
By using DECdns, you can save network resources, manage node names automatically, and scale up to thousands of nodes.
When you make the transition from DECnet Phase IV to DECnet-Plus, the nodes in your network are given DECnet-Plus full names. Along with the node names, the name service stores the address and protocol information that DECnet needs to make connections between nodes. The DECnet-Plus software includes a tool, decnet_register, to help you create and manage node information in DECdns and the Local namespace.
The major benefit of using DECdns in a distributed namespace is the ease of storing node names. With DECdns, it is not necessary to maintain a node database on every system in the network. A few DECdns servers store node names, and all other nodes in the network can depend on those servers for node-name-to-address mapping. When data associated with the node name changes, DECdns propagates the change automatically to all servers that store that node name.
Another benefit of DECnet-Plus node full names is that they can be longer and hence more descriptive than Phase IV node names. Whereas Phase IV node names are limited to six characters, any full name, including a node name, can be as long as 255 characters. See Chapter 6 for complete guidelines for all node names.
The DIGITAL Distributed Time Service (DECdts) is another important user
of DECdns in DECnet-Plus. DECdts and DECdns actually depend on each
other. DECdts uses DECdns as a networkwide registry for global time
servers that synchronize system clocks in the network. DECdns uses
timestamps to determine the order in which changes to its data occur,
and it depends on DECdts to synchronize time on DECdns servers so their
timestamps are consistent. Synchronized clocks are important to any
distributed application that needs to keep track of the order in which
events occur across multiple systems.
5.2 The Name Service Search Path
DECnet-Plus constructs a name service search path file from information entered during configuration. This file determines the order in which the namespaces available on the node will be searched and, for each namespace, any defaulting rules to allow users to enter abbreviated node names.
The name service search path applies system wide and allows DECnet-Plus to search a list of name services in a predetermined order when looking up names or addressing information. The primary name service (the name service to be searched first) is listed before the secondary name services. The secondary name services are listed in the order in which they are to be searched after the primary name service.
If you choose to use a search path and configure more than one name service on your system, the ordering of the name services is very important.
The search path also contains a list of name service keywords, each followed by a naming template that specifies a "defaulting rule" so users can enter shorter node names. In each template, the user-supplied portion of the name (usually the node's terminating name or rightmost simple name) is indicated with an asterisk (*). For example, if the DECdns template is: "ABCDE:.xyz.*" and a user supplies the name foo, then the following full name: ABCDE:.xyz.foo will be looked up in namespace ABCDE in the DECdns name service.
Only one asterisk should be supplied per template. Only the first occurrence of an asterisk (*) in the template is substituted with the user-supplied name. Any additional asterisks are passed to the name service as part of the full name. When you specify a template without an asterisk, the template string is passed to the name service unchanged.
If the user-supplied name should be passed to the name service as entered by the user, the template should simply be specified as follows: "*".
Note that the system maintains two separate search paths:
During DECnet-Plus configuration, the system administrator uses
net$configure.com (on OpenVMS systems) and
decnetsetup (on DIGITAL UNIX systems) to set up one or more
name services on each node and set up the search path. The procedure
for setting up and maintaining the search path on your node is specific
to the OpenVMS and DIGITAL UNIX systems. See your installation and
configuration guide for more information.
5.3 How DECdns Works
Operation of the name service involves several major participants:
DECdns uses a client/server model: an application, such as DECnet-Plus, that depends on DECdns to store and retrieve information because it is a client of DECdns. Client applications create names for resources on behalf of their users. Through a client application, a user can supply other information for DECdns to store with a name. This information is stored in data structures called attributes. Then, when a client application user refers to the resource by its DECdns name, DECdns retrieves data from the attributes for use by the client application.
A system running DECdns server software is a DECdns server. A DECdns server stores and maintains DECdns names and handles requests to create, modify, or look up data. You designate a system as a DECdns server during configuration of the network software.
A component called the clerk is the interface between client applications and DECdns servers. A clerk must exist on every DECnet-Plus node and is created during configuration of the network software. The clerk receives a request from a client application, sends the request to a server, and returns the resulting information to the client. This process is called a lookup. The clerk is also the interface through which client applications create and modify names. One clerk can serve many client applications.
The clerk caches, or saves, the results of lookups so that it does not have to go repeatedly to a server for the same information. The cache is written to disk periodically so the information can survive a system reboot or the restart of an application. Caching improves performance and reduces network traffic.
Figure 5-1 shows a sample configuration of DECdns clerks and servers on a nine-node LAN. Every node is a clerk, and DECdns servers run on two selected nodes.
Figure 5-1 Sample DECdns LAN Configuration
Every DECdns server has a database called a clearinghouse in which it stores names and other DECdns data. The clearinghouse is where a DECdns server adds, modifies, deletes, and retrieves data on behalf of client applications. Although more than one clearinghouse can exist at a server node, DIGITAL does not recommend it as a normal configuration.
Figure 5-2 shows the interaction between a DECdns client, clerk, server, and clearinghouse during a simple lookup. First, the clerk receives the lookup request from the client application (Step 1) and checks its cache. Not finding the name there, the clerk contacts the server on Node 2 (Step 2). The server finds the name in its clearinghouse (Steps 3 and 4) and returns the requested information over the network to the clerk (Step 5), which passes it to the client application (Step 6). The clerk also caches the information so it does not have to contact a server the next time a client requests a lookup of that same name by the same user.
Figure 5-2 Simple Lookup
The total collection of names that one or more DECdns servers know about, look up, manage, and share is called a DECdns namespace. When you create a DECdns namespace, you organize DECdns names into a hierarchical structure of directories. DECdns directories are conceptually similar to the directories that you create in your operating system's file system. They are a logical way to group names for DECdns-specific management or usage purposes.
The highest-level directory in the namespace is denoted by a dot (.) and is called the root directory. The root is created automatically when you initialize a namespace. You can then create and name other directories below the root. Any directory that has a directory beneath it is considered the parent of that directory. Any directory that has a directory above it is considered a child of the directory above it.
Figure 5-3 shows a simple hierarchy of directories. The root directory (.) is the parent of the directories named West and FarEast. The FarEast directory is a child of the root directory and the parent of the Tokyo and Osaka directories.
Figure 5-3 Example Namespace Directory Hierarchy
The complete specification of a DECdns name, going left to right from the root directory to the entry being named, is called the full name. Each element within a full name is separated by a dot and is known as a simple name. For example, the Osaka directory in the preceding figure might contain an entry for a node whose simple name is Node01. The node's full name would be .FarEast.Osaka.Node01. A full name also can include a namespace nickname, but this is not needed when only one namespace exists in a network. When you must specify a namespace, use the following format:
NamespaceNickname:.DirectoryPath.NodeObject
5.4.1 Replicas and Their Contents
Each physical copy of a directory, including the original copy, is called a replica. Directory replicas are the units by which you distribute names in clearinghouses throughout the namespace. You can think of a clearinghouse as a collection of directory replicas at a particular server. After you create a directory in one clearinghouse, you can create replicas of it in other clearinghouses.
All of the replicas of a specific directory in the namespace constitute that directory's replica set. DECdns performs a periodic skulk operation to ensure that all replicas of a directory remain consistent. During a skulk operation, DECdns collects all changes that have been made to the directory since the last skulk completed and disseminates the changes to all replicas of the directory. Every replica must be available for the skulk to be considered successful. Two types of replicas can exist:
A replica's type affects the processing that can be done on it and the way DECdns updates it. The type of replica DECdns uses when it looks up or changes data is invisible to users. However, it helps to understand how the two types differ.
The master replica is the first instance of a specific directory in the namespace. After you make copies of the directory, you can designate a different replica as the master, if necessary, but only one master replica of each directory can exist at a time.
The master replica is the only directly modifiable replica of a directory. DECdns can create, change, and delete information in a master replica. Because it is modifiable, the master replica incurs more overhead than read-only replicas, which DECdns keeps up-to-date but never modifies directly. The master replica also is the place where skulks originate.
A read-only replica is a copy of a directory that is available only for looking up information. DECdns does not create, modify, or delete names in read-only replicas; it simply updates them with changes made to the master replica. Read-only replicas save resources because DECdns does not make changes directly in them, nor does it have to gather changes from them to disseminate to other replicas.
Directory replicas can contain three kinds of entries:
An object is any real-world network resource, such as a disk, application, or node, that is given a DECdns name. When an object name is created, client applications and the DECdns software supply additional data in the form of attributes to be stored with the name. The name and its attributes make up the object entry. When a client application requests information associated with the name, DECdns returns the value of the relevant attribute or attributes.
Every object has a defined class, which is stored as an attribute of
the object entry. For example, a node object's class is
DNA$Node. Another important class of object is the group
object (class DNS$Group). Groups let you
associate, or manage as a group, names that have something in common.
They do this by mapping a specific name (the group name) to a set of
names denoting the group members. DECdns managers can create groups
that assign several users a single set of access rights to names. Two
such access control groups are created automatically during
configuration of the DECnet-Plus and DECdns software. See Section 5.6.2
for a description of them and recommendations on their use.
5.4.1.2 Soft Links
A soft link is a pointer that provides an alternate name for an object entry, directory, or other soft link in the namespace. You can restructure a namespace on a minor scale by creating soft links that point from an existing name to a new name. Soft links can be permanent, or they can expire after a period of time that you specify. If the name that a soft link points to is deleted, DECdns deletes the soft link automatically.
DECnet-Plus uses backtranslation soft links to map a
node address to a node's full name when necessary. Another kind of soft
link, called a node synonym, enables applications that
do not support the length of a DECdns full name to continue using
six-character Phase IV-style node names. Section 5.5 explains how
DECnet-Plus uses backtranslation and node synonym soft links.
5.4.1.3 Child Pointers
A child pointer connects a directory to another
directory immediately beneath it in a namespace. Users and applications
do not create or manage child pointers; DECdns creates a child pointer
automatically when someone creates a new directory. The child pointer
is created in the directory that is the parent of (one level above) the
directory to which it points. DECdns uses child pointers to locate
directory replicas when it is trying to find a name in the namespace.
Child pointers do not require management except in rare problem-solving
situations.
5.4.2 Putting It All Together
To summarize, a DECdns namespace consists of a complete set of names shared and managed by one or more DECdns servers. A name can designate a directory, object entry, soft link, or child pointer. The logical picture of a DECdns namespace is a hierarchical structure of directories and the names they contain. Every physical instance of a directory is called a replica. Names are physically stored in replicas, and replicas are stored in clearinghouses. Any node that contains a clearinghouse and runs DECdns server software is a server.
Figure 5-4 shows the components of a DECdns server. Every server manages at least one clearinghouse containing directory replicas. A replica can contain object entries, soft links, and child pointers. The figure shows only one replica and one of each type of entry possible in a replica. Normally, a clearinghouse contains many replicas, and a replica contains many entries.
Figure 5-4 Components of a DECdns Server Node
5.5 How DECnet-Plus Uses the DECdns Namespace
DECnet-Plus Session Control uses DECdns to store three kinds of entries:
The decnet_register tool is available to help you create these
entries in the distributed namespace. The DECnet configuration
procedure starts the tool automatically after creating a new namespace.
If you choose to use the Local namespace, the decnet_register
tool also enables you to create entries in the Local namespace. You
also can run decnet_register separately to create and manage
node information in the namespace. This section introduces each type of
node entry and describes how it is created and used.
5.5.1 Node Object Entries
In a Phase V network using DECdns, every DECnet node has a corresponding object entry in the DECdns namespace. During the DECnet configuration procedure, you must supply a DECdns full name for your node (the full name includes the complete path from the root directory to the node's simple name) if you decide to use a distributed namespace. The full name becomes the name of the node's object entry in the namespace. If you decide to use a Local namespace, you must enter local as your namespace name during the DECnet configuration procedure.
The Local namespace exists on a single node and provides a local database of names. The local name file, called SYS$SYSTEM:DECNET_LOC_NODE_DEFINITIONS.TXT on OpenVMS and /var/dna/decnet_loc_node_definitions on DIGITAL UNIX, contains a list of node names, node synonyms, and network addresses. You can also use the decnet_register tool to verify or modify node addresses as your network changes.
In a distributed namespace, the node object entry has an attribute called DNA$Towers, in which DECnet-Plus stores the node's address. The attribute name reflects the fact that a DECnet Phase V address consists of separate layers, sometimes called tower floors, in the DNA and OSI network models. A DECnet-Plus node communicates with another DECnet-Plus node by using the address information stored in the node's DNA$Towers attribute.
You can store DECnet-Plus node object entries in any directory in the distributed namespace. When you register a DECnet-Plus node in a distributed namespace, the decnet_register tool creates any directories in the node's full name that do not already exist. You also can create directories with the DECdns Control Program. However, DIGITAL recommends that you use decnet_register to create directories that will contain node object entries. Using decnet_register ensures that the directories are created with the proper access control; see Section 7.4 for details.
If your network includes nodes that are not yet upgraded to DECnet-Plus, their names and addresses also must be in the namespace in order for a DECnet-Plus node to communicate with them. You can use the decnet_register tool to register each Phase IV node individually in any directory in the namespace.
Alternatively, you can use the decnet_register export and import commands to extract the node information from the Phase IV database and enter it in the namespace.
| Previous | Next | Contents | Index |