PreviousNext

Overview - Global and Cell Considerations

The purpose of the following topics is to assist you in planning for the installation, configuration, and maintenance of DCE:

· Global and Cell Considerations

· Client and Server Considerations

· Location of Installed DCE Files

· Overview of DCE Maintenance

For detailed information about installing the DCE source tape and building DCE, refer to the OSF DCE Release Notes and the OSF DCE Testing Guide. Part 2 of this guide describes the configuration process, including installing executable files, setting up a DCE cell, and configuring servers and clients.

This topic discusses how to establish a DCE cell name. This topic also describes how the cell namespace is organized and provides guidelines for maintaining security and replicating parts of the cell namespace. The last portion of this topic discusses what you need to consider as you plan for including DFS in your cell.

You need to answer a number of questions when planning for a distributed system. Your answers to these questions determine the basic requirements of your user environment. Keep in mind the following global considerations as you plan for DCE:

· How much do you think your environment will grow in the next few years? Do you anticipate rapid or relatively slow expansion of your network.

If you think your environment will grow rapidly, consider setting up several cells representing smaller units of your organization. You can manage these smaller units as your network expands. As explained in the Introduction to OSF DCE, members of each cell share a common purpose, and the cell is a unit of administration and security. If you anticipate slow expansion of your network, you may be able to establish one or more cells based on the organization that exists now. Consider how many administrators you will need to maintain your DCE cell, based on anticipated future growth.

· How much information does your environment have that needs to be distributed? How much do the users in your network share information?

If there is a large volume of information that needs to be shared within your network, consider the amount of disk space you require and the number of DFS File Server machines you need.

· How much information updating do you require? Do the users in your network mainly look up information, or do they create and change information at their workstations?

If information changes frequently and users in your network depend on the accuracy of that information, you need to consider how much you rely on replication. It is better to go to a central source of information for data that changes frequently. If users look up information but do not need to change the information that is shared with other users, you can rely more on replicated data.

· Is the most important data the most available data? Have you made plans to replicate this data?

CDS, GDS, the Security Service, and DFS maintain master copies of their respective databases. Each CDS directory can be replicated separately. In addition to DFS databases, individual DFS filesets or groups of filesets can be replicated. GDS replication, also known as shadowing, can be done for a single object or an object and its subordinates (a subtree). The Security Service replicates the entire registry database. Because other components depend on the information managed by the Security Service and parts of the CDS namespace, that data needs to be available at all times. For example, the special character string /.: (the cell root) is stored in CDS and must always be available.

Keep in mind that while replicating data improves availability, there is a cost in terms of performance and the amount of administration required.

· If your network has a gateway, are the servers located on the same side of the gateway as the clients that rely on those servers?

CDS servers broadcast messages at regular intervals to advertise their existence to CDS clerks in the network. Clerks learn about servers by listening for these advertisements. Placing the servers and the clients that rely on them on the same side of the gateway facilitates efficient updates of information and a quick response to client requests. Additional administration is required if you rely on servers that are not available through the advertisement protocol, which is effective only in a local area network.

Consider how fast and how expensive links are if you are administering a cell that includes users in different geographic locations. You may want to keep more information locally to reduce your dependence on transmitting information across links.

· Is communication limited to your own cell, or do you need to communicate with other cells?

DCE offers two methods of connecting cells so that they can communicate:

- The standard intercell connection, in which a cell is registered in a global directory service that DCE supports and communicates with other cells registered in that directory service. A cell can be registered in both the GDS and DNS directory services. In this case, the cell has two names: one in GDS format, and one in DNS format. These names are the cell's aliases.

- The hierarchical cell connection, in which a cell is registered in another cell's CDS namespace, and communicates with other cells also registered in that cell's namespace. In a hierarchical cell configuration, the cell at the top of the hierarchy must be registered with a global directory service, but the cells beneath it do not need to be, because they communicate through CDS.

Regardless of which method you choose, in order for your cell to communicate with other cells, you must

- Establish a unique name for your cell and define it in the appropriate namespace (GDS, DNS, or CDS)

- Have at least one GDA running in the cell

- Establish a Security Service trust relationship with the other cells with which you wish to communicate