1 — Planning Cell Topology

[Previous] [Next] [Contents] [Index]

This chapter describes DCE cell topology issues and methods. It describes what cell topology is, how you can approach the task of designing a cell topology, and some of the important issues you will need to consider as you create and test your design.

1.1 What Is Cell Topology?
1.2 Cell Topology Design and Test Methodology
1.3 Number and Location of Cells
1.4 Full Clients and Lightweight Clients
1.5 Application Requirements
1.6 Server Locations
1.7 Machine and Network Requirements
1.8 Intercell Communication

If you do not yet know what a cell is, you should read a good introduction to DCE before continuing. Refer to the Preface for references.

However, to recap, a cell is a collection of users, machines, and resources that share two common databases of administrative information, namely, the Cell Directory Services (CDS) namespace and the security registry. Members of a cell are usually located in a common geographic area, but they can also be geographically dispersed. A cell's size can range from only one machine to several thousand.

1.1 What Is Cell Topology?

Cell topology describes how you logically and physically layer DCE onto your network of users and computing resources. Cell topology includes the division of your organization into one cell or multiple cells, and the physical and logical arrangement of DCE services within each cell.

A cell topology design includes answers to the following questions. The rest of this chapter discusses how you can approach each of them.

1.2 Cell Topology Design and Test Methodology

The factors that influence the answers to these questions tend to be interdependent. You must consider each question separately, but you must also consider how the design issues interact. It's best to get a general feel for all of the issues involved before making specific design decisions.

A cell topology can involve complex interactions with results that are often difficult to foresee. Before making full-scale deployments, DCE cell topology designers often create test cell topologies that model the deployment environment. This allows them to test their design before committing it to their users. We recommend that you consider this approach.

You may also wish to hire consultants with experience in designing DCE cell topologies. Entegrity® provides this consulting service - for more information, contact your Entegrity sales representative.

1.3 Number and Location of Cells

If your organization is not too large, creating a single cell is the simplest solution from an administrative perspective. However, for larger organizations, you will need to consider creating multiple cells rather than a single large cell. The rest of this section discusses factors that you should consider when making this decision.

1.3.1 Performance

Multiple cells will generally provide better performance than a single large cell. In a single large cell, more users per server slows down response times.

You can improve response somewhat by strategically locating CDS and security replicas. However, users running full clients (see Section 1.4 on page 16) still need at startup to contact the master CDS hosts directory replica, which resides on a single machine. Also, there is a practical limitation on the number of replicas you can implement in a cell. Generally, more than ten replicas imposes an unreasonable administrative burden.

1.3.2 Administration

As a cell grows large it becomes increasingly difficult to administer. The sheer number of users, groups, machines, and other resources and objects becomes difficult to manage. Geographical dispersion makes the job more difficult, as does the increased number of replicas required.

Implementing multiple cells lets you divide the administration task into manageable units and delegate administrative responsibility for each cell to individual cell administrators. A multiple cell topology does have the drawback of creating some intercell administration issues. See Chapter 7 on page 103.

1.3.3 Geographical and Functional Distribution of Users

As you design your cell topology, consider your user population and how they are distributed, both geographically and functionally.

Are your users all located in a common geographic area, or are they located in different buildings, different cities, or different countries?

Are the members of functional groups (departments or workgroups, for example) located together, or are they geographically dispersed?

The answers to these questions affect cell topology design. If all potential users are located within the confines of a single LAN, the network performance favors a single cell topology. However, if the users are geographically dispersed, you must consider different approaches. You may choose to implement separate cells for each geographic region, or to implement a single cell with centrally-located master replicas and read-only CDS replicas and slave security replicas located at remote sites.

Because functional groups tend to share the same resources, you must consider functional distribution as well. If functional groups are organized geographically (for example, Product A's division is located in England and Product B's division is located in the United States), this favors multiple cells, one per group. However, if functional groups are geographically dispersed, you may consider either creating a single large cell; or multiple, geographically dispersed cells that are organized by function.

1.3.4 Cell Tuning

If you choose to implement one or more large cells, Entegrity provides cell tuning features to improve performance. These are implemented as Windows 2000, Windows NT or Windows 98 registry keys and environment variables. For example, cell tuning features allow you to increase the amount of time the DCE startup service waits for daemons to start and reduce the timeout of RPC calls to CDS and security servers.

For more information about cell tuning, refer to Appendix A on page 117.

1.3.5 Maintaining System Time

The systems in each cell must have a way to synchronize their local clocks with a central time server. DCE security requires system clocks to be accurate within five minutes.

PC-DCE™ provides the Distributed Time Service daemon (dtsd) as an option for time synchronization; however, other services may better suit your environment.

Alternatives to dtsd include:

1.4 Full Clients and Lightweight Clients

The Entegrity PC-DCE client can be configured either as a full client or a lightweight client. The choice to implement full or lightweight clients is a cell topology issue because lightweight clients are much more conservative of cell resources, effectively raising the practical maximum cell size and increasing the number of users that can rely on a single replica. If you implement lightweight clients, you may be able to run a single large cell in situations where you might otherwise need multiple cells.

For a complete discussion of full and lightweight clients, refer to the PC-DCE Overview Guide.

1.5 Application Requirements

Consider the requirements of your applications when you consider your cell design. Different applications have different performance requirements and require different types of support from DCE. For example, an application may or may not require the services of a full client, which in turn affects the practical maximum cell size (see Section 1.4 on page 16).

1.6 Server Locations

As part of your topology design, decide where to locate your master CDS replicas and master Security servers. Take into account performance, security, and failover considerations (see Section 5.2 on page 66).

1.7 Machine and Network Requirements

Your primary servers and immediate backup servers should run on high-quality hardware with adequate resources (virtual memory and physical memory) to support anticipated growth for a reasonable period of time.

1.7.1 Security Service Servers

The node that runs the master security server must be highly available and physically secure. If the host that contains the master security server goes down, slave replicas can still provide registry information, so consider having a number of replicas in each cell. Use factors such as the number of machines in your cell, the reliability of the machines that run security servers, and your cell's available resources to determine how many security replicas you need.

1.7.2 CDS Servers

CDS servers need to be located on dependable nodes.

When deciding how many CDS servers you need, consider the size of your cell and how geographically dispersed the cell is. You should have at least two copies (one master and one replica) of each CDS directory to ensure access to data if one of the servers becomes unavailable.

Use reliable network connections that can handle the estimated amount of traffic. This helps to ensure that all servers maintaining directory replicas can be reached when the CDS performs periodic updates.

1.7.3 Network Connections

If users will need to go off the local LAN to contact a server, pay careful attention that the LAN interconnections have adequate reliability and bandwidth. WAN connections are usually the source of bottlenecks.

1.8 Intercell Communication

If you implement multiple cells, you can choose to isolate them from each other, or more commonly, allow some degree of intercell communication. For example, you may want to create special foreign_user accounts so that high level DCE administrators can access multiple cells.

[Previous] [Next] [Contents] [Index]

To make comments or ask for help, contact support@entegrity.com.

Portions of this document were derived from materials provided by Compaq Computer Corporation. Copyright © 1998-2003 Compaq Computer Corporation.

Copyright © 2003 Entegrity Solutions Corporation & its subsidiaries.

All rights reserved.