5 —
Cell Directory Service Enhancements
[Previous]
[Next]
[Contents]
[Index]
5.1 Overview of CDS Directory and Clearinghouse Operations
Product Name offers some enhancements that extend the capabilities provided by OSF DCE Release 1.2.2 software. These enhancements include:
CDS directory and clearinghouse convenience operations enable cell administrators to easily reorganize CDS directories and subtrees and to automate some tedious directory replication tasks.
5.1.1 Reorganizing Existing CDS Directory Replicas
After you have worked with a DCE cell for a period of time, you may observe that new CDS directories have been created in one or more clearinghouses within the cell.
When cells have multiple clearinghouses, CDS directory proliferation can cause problems or have overhead not associated with single-clearinghouse cells. For instance, at some point in the CDS directory hierarchy, master and read-only replicas of directories can become disorganized with master replicas spread among different or inappropriate clearinghouses.
For convenience in backing up your part of the namespace, you might want all of the master replicas in your part of the namespace to reside in one clearinghouse. With this strategy you need to back up a single clearinghouse because master replicas contain the most recent updates to CDS.
Gradient DCE for Tru64 UNIX provides special options (-propagate and -force) to the directory modify operation. These options reorganize master and read-only replicas in a CDS subtree to match the directory configuration of the subtree root directory that you name as an argument to the directory modify operation.
Say a directory subtree's replicas are spread among four clearinghouses (CH_A, CH_B, CH_C, and CH_D) as shown in Table 5-1. In the table, the master replica for /.:/subsys/dec/srvs/vsrv (the subtree root directory) is in CH_A. However, master replicas for its descendants reside in CH_B and CH_D. To back up the master CDS databases for this subtree, you must back up clearinghouses CH_A, CH_B, and CH_D.
You can perform a directory modify operation to reorganize all master and read-only directories to be in the same clearinghouse as the subtree root directory. Once all master replicas are in the same clearinghouse (CH_A in our example), you need only back up clearinghouse A.
Items 1, 2, 3, and 4 depict the master directory organization before reorganizing them with the directory modify operation. Item 5 illustrates the results of the following directory modify operation:
% directory modify /.:/subsys/dec/srvs/vsrv -propagate -force
Note that the preceding directory modify operation removes the replica from clearinghouse C (CH_C) because the root directory (/.:/subsys/dec/srvs/vsrv) has no replicas in clearinghouse C.
5.1.2 Creating Additional CDS Directory Replicas
You can also use a directory modify -propagate operation to automate the manual steps formerly needed to create additional (read-only) replicas of new directories you have created. This operation creates read-only replicas of the new directory. Note that this operation also affects any siblings of the new directory and all of their descendants.
When you create a new directory or directory subtree in a CDS clearinghouse, the directory create operation creates only the master replica. By default, the replica is created in the same clearinghouse where the parent directory's master replica resides.
You can use a directory modify -propagate operation to create read-only replicas of the new directory or directory subtree. The new replicas will be created and organized so that their master and read-only replicas will be in the same clearinghouses as the subtree root directory (the parent directory) which you name as the argument to the directory modify operation.
The next table illustrates the behavior of the directory modify -propagate operation used for creating read-only replicas of a new directory.
Item 1 shows the initial configuration of the parent directory. The master replica is in clearinghouse A (CH_A). Read-only replicas of the parent directory reside in clearinghouses B and D. Clearinghouse C does not contain any replicas of the parent directory.
Item 2a illustrates the result of the default directory create operation which creates the new directory in the same clearinghouse where the parent directory's master replica resides. Default means not specifying an alternative clearinghouse in which to create the new directory.
Item 2b shows the results of the directory modify -propagate operation which creates master and read-only directory replicas in the same clearinghouses that contain the parent's master and read-only directory replicas.
Item 3a illustrates the result of a directory create operation which creates the new directory in a different clearinghouse than where the parent directory's master replica resides. An optional -clearinghouse option to the directory create operation specifies to create the new directory in clearinghouse B.
Item 3b shows the results of the directory modify -propagate -force operation. Here, the -force option must be used. Otherwise, an error occurs because the new directory's master replica is in a different clearinghouse than the parent directory's master replica. The -force option performs an extra step, causing the new directory master and read-only replicas to conform to the same configuration as the parent directory replicas.
The directory modify -propagate operation affects all the descendant directories of the named directory. For example, assume your cell has the following subtree configuration:
/.:/subdir1/subdir2/newdir1
/.:/subdir1/subdir2/olddir1/oldsubdir1
/.:/subdir1/subdir2/olddir2/oldsubdir2
The following operation organizes the replicas of all three child directories ( newdir1 , olddir1 , and olddir2 ) and their descendant directories to match the master and read-only replica configuration of the parent directory ( /.:/subdir1/subdir2 ) which is named in the operation.
% directory modify /.:/subdir1/subdir2 -propagate -force
Of course you can have the master replicas of child directories in different clearinghouses than their parent's master replicas. However you must manually create any read-only replicas using separate directory create operations for each replica you want to create.
5.2 Enhanced Browser
The Browser is a Motif-based tool for viewing the CDS namespace. The Browser can display an overall directory structure as well as show the contents of directories, enabling you to monitor growth in the size and number of directories in your namespace. You can customize the Browser so that it displays only a specific class of object names. The Gradient DCE for Tru64 UNIX Enhanced Browser contains some additional functions beyond those contained in the OSF DCE Version 1.1 Browser.
5.2.1 Displaying the Namespace
When you start the Browser, an icon representing the root directory is the first item to appear in the window. Directories, soft links, and object entries all have distinct icons associated with them. Most object entries have unique icons based on their class; the class indicates the type of resource that the entry represents (for example, clearinghouse object entries). When the Browser does not recognize the class of an entry, it displays a generic icon.
The following figure shows the Enhanced Browser icons and what they represent.
Figure 5-1: Enanced Browser Icons
5.2.2 Filtering the Namespace Display
Using the Filters menu, you can selectively display object entries of a particular class. With the Enhanced Browser, you can choose from either the RPC_Class or CDS_Clearinghouse object classes. For example, if you are interested in seeing the entries for clearinghouse objects only, choose the class CDS_Clearinghouse from the Filters menu. If you are interested in seeing object entries used in the name service interface (NSI), choose RPC_Class. You can filter only one object class at a time.
Setting a filter does not affect the current display, but when you next expand a directory, you see only object entries whose class matches the filter. Note that soft links and directories still appear because only object entries can be filtered out. To reset the filter to view all object entries, choose the asterisk (*) from the Filters menu.
For a full description of the Browser, see the CDS part in the OSF DCE Administration Guide — Core Components.
5.3 CDS Enhanced Cache Memory Control
Two options for the cdscache discard command allow administrators to control the release of memory from the cache clerk without having to stop and shut down DCE. The new options -entry and -replica specify structures in the cache for deletion. The following command shows how to delete a replica:
dcecp -c cdscache discard -replica /.:/foo_ch
where foo_ch should be replaced by a valid clearinghouse name.
5.4 CDS Clearinghouse Preferences
With this release, CDS is able to make more intelligent choices about which clearinghouse to contact in satisfying a user request. This has the potential of greatly improving performance, depending on your cell configuration. Each client machine ranks clearinghouses in the order in which they should be contacted by the client for CDS information. Default behavior prioritizes those located "closest" to the client on the network. However, the administrator of a client node can override the default rankings.
This enhancement is useful in situations where, for example, there are multiple high-performance LANs, each with its own CDS server, connected by a low-performance WAN. With this feature, the clearinghouse with the best ranking is the one on the machine with the server, followed by one on the same LAN with the client. Local clearinghouses are preferred over distant clearinghouses. Clients use distant clearinghouses only when local clearinghouses cannot satisfy a request. The administrator can override the defaults as needed.
Clearinghouse preferences are achieved by assigning a numeric rank to each clearinghouse. A rank is a 16-bit unsigned integer (range 0-65535). Lower numbers are preferred over higher numbers (and a rank of 65535 means "don't ever use this clearinghouse").
To override defaults, ranks must be specified in a text file called opt/dcelocal/etc/cds_serv_pref. The format of the file is one clearinghouse name and one rank on each line of the file. Blank lines and comments ("#" to the end of the line) are ignored. Ranks can be 0-65535 (0x0000-0xffff) and can be specified in decimal, octal (with leading "0"), or hex (with leading "0x"). Clearinghouse names can be in any of the following formats:
/.../cellname/foo_ch
/foo_ch
foo_ch
/.:/foo_ch
If the clearinghouse's cell name is not specified, the local cell is assumed.
Example file:
/.:/foo_ch 50 # most preferred clearinghouse
/.:/bar_ch 100
/.../mycellname/baz_ch 100
If a clearinghouse is not mentioned in the preferences file, a rank is calculated for it. Thus, you need to specify rank for a clearinghouse only when you want to override its default rank.
The default ranks are calculated based on IP address:
The clearinghouse preferences file is read upon cdsadv startup and the values are cached. If you change rank values, you must stop the CDS client, remove the cache, then restart the CDS client.
The following commands now include a rank attribute:
dcecp -c cdscache show -clearinghouse /.:/foo_ch
cdscp show cached clearinghouse /.:/foo_ch
where foo_ch should be replaced by a valid clearinghouse name.
[Previous]
[Next]
[Contents]
[Index]
To make comments or ask for help, contact
support@entegrity.com.
Copyright © 2001 Entegrity Solutions Corporation & its subsidiaries.
Copyright © 1998-2001 Compaq Computer Corporation.
All rights reserved.