Directory and Security Server Configuration and Tuning

by Ken Whitfield

''This article provides an overview of performance implications to consider when planning and installing the IBM Directory and Security Server product. This is not an installation guide; rather, it is a companion document that can help you achieve optimum performance.''

Underlying the IBM Directory and Security Server (DSS) product is IBM's Distributed Computing Environment (DCE) architecture and software. Before discussing DSS configuration and tuning, let's define some equivalent terms between DSS and DCE.

The term DSS Directory Server is used interchangeably with DCE Cell Directory Services (CDS) and CDS Server. DCE uses the term CDS Namespace to denote the database that contains the resources and services information.

The term DSS Security Server is used interchangeably with DCE Security Services. DCE uses the term Registry to denote the security database.

The DSS product CD-ROM contains DCE Cell Directory Services, DCE Security Services, DSS Domain Controller, and DSS Full and Slim Clients. The two DCE services can be installed together on one machine, on two different machines, or on the same machine as the DSS Domain Controller. A replica (copy) of the DCE Security Server is automatically installed with the DSS Domain Controller.

There are, of course, performance considerations for each of these products. This article presents some of those considerations, including: The Appendix details the significant requirements for disk space in a large DSS cell.
 * DSS capacity and hardware requirements for servers and clients
 * Tips for getting the best performance from software servers in a DSS cell
 * Considerations for locating servers in diverse geographic areas

Capacity Planning
DCE provides global connectivity with first class security. Software that offers this much functionality requires more system resources (such as memory and disk space) than do local area network (LAN) products.

As illustrated in this article's Appendix, disk space requirements for 5,000 DSS users in an enterprisewide network are quite large; however, in theory, DSS can accommodate many times that number of users within a single DCE cell.1

If your application requires large hardware capacity, you may want to consider installing CDS Server and Security Server on an operating system other than OS/2, such as DCE on AIX, or DCE on MVS/Open Edition, both of which comply with Open Systems Foundation's (OSF's) DCE 1.1.

Scalability is one of the key benefits of DCE's multiplatform, open architecture. Scalability lets you maintain centralized administration while providing a well defined path for system growth.

Clients
DSS clients, like DSS servers, have more function and therefore require additional memory and disk space. For many existing LAN Server clients, however, this additional function initially is not a requirement.

Tip: Unless you require DSS client functionality, you should run existing 486-based client systems as non-integrated (legacy) LAN Server or OS/2 Warp Server clients.

Legacy LAN Server and OS/2 Warp Server clients cannot directly access the Security Server or Directory Server but must go to the DSS Domain Controller for account and resource information.

Tip: DSS client performance is directly affected by how much system memory is installed, so for best performance use at least 24 MB instead of the minimum 16 MB of required memory.

Client workstation performance is usually better without the DSS client code, because more memory is available for other applications. Pentium-class client systems with sufficient memory are unlikely to incur a performance impact when the DSS client function is installed.

In general, when you are considering new hardware, you should plan for growth in your desktop system's processing power and capacity to support your personal applications as well as current DSS requirements.

Tip: You should perform DSS administrative functions on a Pentium-class client system.

In a reasonably configured Pentium system (one that runs at 90 MHz or faster and has at least 32 MB of memory), the speed of administrative functions is about the same in DSS as it was for equivalent operations in LAN Server 4.0 or OS/2 Warp Server. Also, most DSS administrative functions cannot be performed on legacy client systems.

Security Server
The DSS Security Server primarily contains information about principals in the DCE cell. A principal is defined as a user, or a server that a user wants to access. DCE loads the entire registry into memory when the Security Server is started.

Tip: Security Server performance is directly related to processor speed and the amount of installed system memory, so for best performance use the recommended system instead of the minimum system. (See Figure 5 in the Appendix for the relevant requirements.)

The registry requires approximately 2 KB of memory for each defined DSS user. If there is enough system memory to store the active portion of the registry, response time does not degrade significantly as the number of users increases. But when the amount of memory required to store the registry exceeds available memory, some (perhaps all) of the registry is written to the swap file on the hard disk. Therefore, if a user's registry information is in the swap file on disk (rather than in memory), that user's logon response time will be slower. (See the Appendix for the Security Server's disk requirements.)

If the DSS Security Server is installed on a server system that already has LAN Server or OS/2 Warp Server installed, you should verify that the HPFS386 cache size is not too large. (See the "File/Print Server" section in this article for more information about setting the HPFS386 cache size.)

Tip: Replicating your Security Server will improve availability and enhance overall performance.

Each Security Server replica contains the entire registry. Clients tend to spread their requests evenly across multiple servers, so replication can help reduce the load on a single server, thus reducing response time for client requests.

Tip: Give user access credentials a longer expiration time to lighten the Security Server's workload.

A DSS client system contacts the Security Server when its user logs in. At that time, the Security Server issues credentials to the user for accessing DSS servers. The credentials are cached on the client's disk for later use and must be refreshed after they expire.

The duration of the credentials, determined by policy set by the security administrator, has some effect on Security Server performance. A shorter duration (for tighter security) means more workload for the Security Server, because when the credentials expire, the server has to revalidate them.

Tip: To save access time and resources, give users a level of security protection that lets them access cached credentials on their client systems.

Clients' queries for Security Server data can be directed to any of several sources. The choice of a source affects both the response speed of the query and the accuracy of the information.

In particular, sources for the Security Server data include the master, one or more replicas, and the cached informa-tion at a client resulting from a previous query. The master database is the most reliable source; a replica is the next most reliable, since it reflects the master database after time passes; and a cache is the least reliable, since it is updated only by another query.

Associated with each data source is a level of security protection called a confidence level. The lower the confidence level, the faster the information is retrieved. The master database might be remote from the client and take a long time to be queried, whereas replicas are likely to be quickly accessible. Therefore, you should set the average user's confidence level as low as possible, while keeping it consistent with your organization's desired security level.

The confidence levels and the sources searched at each level are:
 * High, which lets queries search only the master database.
 * Medium, which lets queries search either the master database or any replica.
 * Low, which directs queries to first search a cache of previous queries, then search either the master or a replica.

Directory Server
The Directory Server, also called Cell Directory Services (CDS) or the CDS Server, contains location information for all resources and services in the DCE cell. DCE loads the entire CDS namespace into memory when the Directory Server is started.

Tip: Directory Server performance is directly related to processor speed and the amount of installed system memory, so for best performance use the recommended system instead of the minimum system. (See Figure 5.)

As long as there is enough system memory to store the active portion of the CDS namespace, response time does not degrade significantly as the number of users and servers increase. But when the memory required to store the CDS namespace exceeds available memory, some (perhaps all) of the namespace memory is written to the swap file. In this case, because of the disk access, the query for location information will be slower.

If the CDS Server is installed on a server system that already has LAN Server or OS/2 Warp Server installed, you should verify that the HPFS386 cache size is not too large. (See the "File/Print Server" section in this issue for more information about setting the HPFS386 cache size.)

Tip: To minimize long-distance traffic and improve local performance, use CDS Server replicas in geographically dispersed regions of a cell.

CDS administrators create replicas of the CDS namespace called clearinghouses. A clearinghouse is the CDS namespace managed by a CDS Server. A clearinghouse need not contain the entire name environment for the cell. The cell administrator can choose to replicate only those directories and information most frequently accessed by local users. Once a DSS client has obtained the location of resources or services from the CDS Server, it caches this information, thus eliminating subsequent duplicate CDS accesses until the cache expires.

Even though DCE directory operations can be serviced by any CDS Server, the local subnet is tried first to avoid crossing router boundaries. The directory operation goes outside the local subnet only when the information cannot be found on a local server.

In addition to the resources and services objects and directories kept in the CDS namespace, DSS adds objects and directories for resource domains, aliases, and public applications.

See the Appendix for details about Cell Directory Services disk requirements, including unique requirements for DSS.

DSS and Backup Domain Controllers
To migrate a LAN Server (or OS/2 Warp Server) domain into a DSS cell, you must upgrade the LAN Server (or OS/2 Warp Server) Domain Controller to a DSS Domain Controller. The LAN Server (or OS/2 Warp Server) domain is migrated to a resource domain in which the DSS Domain Controller is the key server. Since LAN Server (or OS/2 Warp Server) requesters and additional servers in the domain do not need to be upgraded, the DSS Domain Controller plays a major role in supporting these requesters and servers.

Unlike DSS clients and servers, which contact the CDS Server and the Security Server directly, legacy LAN Server or OS/2 Warp Server requesters and additional servers still request account identification and resource information from the DSS Domain Controller. However, the DSS Domain Controller no longer maintains the master version of these databases. The master versions are now maintained by the DSS Security Server and Directory Server. For this reason, the DSS Domain Controller contains functions to synchronize the LAN Server (or OS/2 Warp Server) NET.ACC database and domain control database (DCDB) with the registry and CDS namespace databases. These synchronization functions allow legacy LAN Server or OS/2 Warp Server requesters and additional servers to participate in the cell.

A DSS Domain Controller always runs a Security Server replica if the resource domain includes legacy LAN Server or OS/2 Warp Server requesters and servers. It is possible to run without a Security Server replica if all legacy clients have LAN Server 4.0 plus APAR IC13565 or later and if all the legacy servers in the resource domain are integrated into the DSS cell.

Tip: Domain Controller and Backup Domain Controller performance is directly related to processor speed and the amount of installed system memory, so for best performance use the recommended system instead of the minimum system. (See Figure 5.)

If the DSS Domain Controller is installed on a server system that already has LAN Server or OS/2 Warp Server installed, you should verify that the HPFS386 cache size is not too large. (See the "File/Print Server" section in this article for more information about setting the HPFS386 cache size.)

Tip: To reduce logon congestion at the DSS Domain Controller and improve logon response time, use a Backup Domain Controller and assign it as the logon server for some users by means of an attribute in the user definition.

A Backup Domain Controller that is not integrated with DSS can still provide access to the DSS cell for legacy LAN Server or OS/2 Warp Server clients. Since the DSS Domain Controller keeps the logon information updated in the Backup Domain Controller's NET.ACC file, logon to the LAN can take place without any communication to the CDS Server or Security Server.

A user definition attribute can specify the Backup Domain Controller as the user's logon server. Once logged on to the network, legacy LAN Server or OS/2 Warp Server clients can access resources in any resource domain contained in the cell of which they are a member.

Tip: You can reduce the time it takes for a user to log on by reducing the number of logon aliases associated with that user.

DSS uses CDS and Security Services primarily when the user logs on and connects to resources.

In a DSS environment, aliases are stored in the Cell Directory; connection to logon aliases is performed at logon time. Connecting to a DSS server will take longer for legacy LAN Server or OS/2 Warp Server clients, because the DSS alias server must get the alias location information from CDS, then authenticate the legacy client with the Security Server. In contrast, logged-on DSS clients have a security token and certificate to the alias, so they receive immediate access.

File/Print Server
Once a session has been established with the file server, file and print serving performance is much the same under LAN Server 4.0 or OS/2 Warp Server.

Tips: The following suggestions may improve the performance of file and print services.
 * Install a server on the same LAN as the clients that most frequently access it.


 * To optimize file and print performance, click on the LAN Services folder and run the Tuning Assistant. This allocates more resources to LAN Server based upon the number of users specified. Caution: The Tuning Assistant assigns a large amount of system memory to file system caches, so if you need to reserve some of that memory for other applications, be sure to specify your requirement when you run Tuning Assistant.


 * If your file and print server is running DSS Client, Security Server, Directory Server, or other applications, you should make certain that not too much memory is assigned to file system caches. (See the Performance Tuning section of the DSS Administrators' Reference for more information about using the Tuning Assistant.) In addition to allocating memory, the Tuning Assistant is useful in DSS servers for ensuring that the NetBIOS resources are properly configured for all the possible NetBIOS users.


 * For best file and print performance in a cell with a moderate to heavy workload on the CDS Server, do not run the CDS Server on the same machine as the file and print server. Under light load situations a combined server may provide acceptable performance.


 * Although file and print serving performance is good in the DSS environment, under a heavy workload some extra overhead in authority checking is noticeable in the Entry Server. Therefore, if you have a busy Entry Server or an Entry Server with a small amount of memory, consider adding memory or moving up to the Advanced Server for better performance.

Articles on the IBM Developer Connection for LAN Systems CD-ROM cover tuning LAN Server and OS/2 Warp Server for best file and print performance. In addition, a paper titled OS/2 Warp Server Performance Highlights and Tuning Tips is on the World Wide Web at http://www. austin.ibm.com/pspinfo/wstun.html and is also in the May/June 1996 issue of this magazine.

DSS Administration Graphical User Interface
Tips: The following suggestions may enhance the performance of the DSS Administration GUI.


 * If you frequently use the DSS Admini-stration GUI, leave it open and running on the DSS administrator's client machine, because loading it can take a significant amount of time.
 * Close the Administration GUI once a week to release any unneeded resources it has acquired.
 * Open an object collection (such as the Accounts container) in the sorted mode. Operations on sorted objects are much faster than on unsorted objects. The sorted screen position is kept in an initialization (INI) file, which eliminates the need to determine each object's screen position by reading its attribute information.

Network Topology Placement of Directory and Security Servers in a distributed network should be driven by two factors: the topology (the physical features and characteristics) of the network and the workload and number of systems in each piece of the network.

Low bandwidth (which can be thought of as skinny) and high latency (long) links effectively divide the network into pieces. High bandwidth (fat) and low latency (short) links do not.

Consider the network shown in Figure 1. This network has three pieces: Hawaii in one, Chicago and Austin in a second, and Liberty Hill (30 miles from Austin) in a third.

Hawaii is in its own piece because the high-latency satellite link to the rest of the network slows down conversations that are sensitive to response time. Liberty Hill is in its own piece because the skinny 9600 bps link slows requests down. For most purposes, Austin and Chicago can be treated as a single piece because the low-utilization T1 lines should have enough bandwidth to handle the traffic, and land lines generally have low enough latency to stay responsive to distributed network protocols.2

Each piece of the network in Figure 1 requires its own Security Server and Directory Server.

The term preferred replica denotes a Security Server that is physically on the same LAN or connected to the server via the fastest link available. You should set up your configuration to have a logon request sent to a preferred replica. If you don't do this configuration, your logon request is randomly sent to any known Security Server, which, on average, causes poorer performance. (See the article titled Configuration Steps for Preferred Security Replica at http://ps.boulder.ibm.com/pbin-usa-ps/getobj.pl?/pdocs-usa/dssnews.html)

Within a single piece of the network, the number of active clients that a single Directory Server or Security Server can handle will vary with client workload and system power. The load should be similar to what is seen by existing OS/2 DCE customers; this indicates that Pentium 90-class servers should be able to support 1,000 active clients. (This capacity estimate is either a Directory Server or a Security Server workload statement; it does not claim that 1,000 active file/print clients can be supported.) This workload on a server allows some concurrent file and print sharing, but the degree of sharing is not strictly quantifiable.

Tip: Replicas of the master Security and Directory Servers should be used in the separate network pieces to provide best performance. At least one Security Server replica and one CDS Server replica are recommended for each cell.

You can set up different configurations of CDS Server masters and replicas. The easiest combination to manage consists of a master in the central network piece and one or more replicas in the other pieces. However, if update activity is heavy or the CDS namespace is large, you may choose to have multiple CDS Server replicas, each managing a portion of the CDS namespace.

You can configure a CDS Server replica (a clearinghouse) to contain only the subset of the CDS namespace that is important to nearby users. Each clearinghouse contains a copy of the cell root directory, which contains pointers to all of the cell's child directories. For searches to child directories not contained in a particular clearinghouse, the CDS Server returns the location of another clearinghouse that has the directory.

CDS Server replicas can have read-only replicas for availability and performance. The Security Server containing the registry cannot be distributed across replicas but must contain the complete set of data about accounts and principals.

The need for Directory and Security Server replicas depends upon your system availability requirements. You may want to have these replicas, or you can rely instead on a backup and recovery scheme. Generally, it is much easier to recover a system from a CDS Server or Security Server replica than from a backup device.

You have to decide between backup and recovery philosophies--whether you want to have replicas available that can take over for failing servers or whether you want to have a periodic backup plan that causes an outage while recovering. The outage can be either absolute (when there is only one master with no replicas) or a slowdown (when access continues to other servers, but performance is degraded by a long or skinny link, perhaps to a server that cannot handle the extra load).

Appendix
This Appendix presents calculations of disk space requirements for the Security Server, CDS namespace, and CDS Server.

Security Server Disk Space
Figure 2 shows the amount of disk space required on a server system running Security Server and serving 5,000 users. '''Figure 2. Disk Space Requirements for Security Server'''

Directory Server Disk Space
Here we see the factors that contribute to the size of the CDS namespace, and we calculate overall CDS disk space requirements.

For each DSS client (excluding DSS Slim Client and LAN Server legacy clients) or resource server, there is an entry in the CDS namespace consisting of one directory and four objects. All clients and servers known to DCE have such an entry in the CDS namespace.

Additionally, DSS uses the CDS namespace to store information about resource domains, aliases, and public applications.

The entire CDS namespace is contained in the Checkpoint file, which requires disk space. The amount of virtual memory required for this data is 2.9 times the size of the Checkpoint file. If there is not enough real memory, some (possibly all) of the data in virtual memory is written to the swap file (SWAPPER.DAT) on disk. Therefore, a system without adequate real memory must have enough disk space to accommodate all of the data in virtual memory. If you are concurrently running system and application software other than CDS Server on your server system, your swap file has to be large enough to accommodate that software and data.

The calculations here assume there are CDS namespace entries for 5,000 DSS clients and servers plus a representative set of LAN Server resource domain entries. The size of the CDS namespace (Checkpoint file) is calculated in Figure 3, and disk space requirements for the CDS Server are calculated in Figure 4. '''Figure 3. CDS Namespace (Checkpoint File) Size''' '''Figure 4. Disk Space Requirements for CDS Server'''

Figure 5 contains a subset of the DSS product's system requirements, which are published in the DSS announcement document and various DSS product documents. It shows the difference between minimum system requirements and recommended system requirements. '''Figure 5. System Requirements for Each DSS Component''' (Directory Server or Security Server or Domain Controller)

1) For details about an experiment with DCE server capacities, see the article "DCE Cell Performance: High Water Marks" in this magazine's November/December 1995 issue.