Novell is now a part of Micro Focus

How to Configure and Optimize eDirectory LDAP Servers

Articles and Tips: article

Gary Anderson
Director
eDirectory Core Technologies
glanderson@novell.com

01 Sep 2000


Thanks to thank David Wilbur, Paul Kelley, Qiang Tian, Brian Jensen, Andy Hodgkinson, Daniel Sanders, Scott Pathakis, Tom Doman, Duane Buss, Steve McLain, Howard VanFleet, and Kevin Ward who contributed information and took the time to ensure that the presentation was accurate. With the implementation of full LDAP V3 functionality and the addition of a scalable data store in 1999, Novell's Directory Server (now known as eDirectory) began a transition from a NOS-centric directory to a fully functional full-service directory. Many new features have been added. This article will explain basic server hardware and software configuration. The physical configuration of the server will be discussed, then tuning parameters and tips on directory organization will be presented.

Operating System

Novell's eDirectory provides a wide variety of choices for the underlying operating system. The directory currently ships on:

  • NetWare 5.X

  • Windows NT 4.X

  • Windows 2000

  • Solaris 2.7, 8, and 9 on Sparc hardware

  • Compaq Tru64 5.0f

  • Red Hat LINUX 6.2 and 6.3

  • Note: Other LINUX and UNIX platforms will be supported in the future.

The install program that comes with eDirectory will correctly prepare the directory for operation on any of the supported operating system platforms. The eDirectory server will provide consistent functionality on all of these operating systems as well. Server performance does vary based on the operating system selected and on the configuration of the server. eDirectory can be loaded on servers loaded with any combination of these operating systems and a consistent tree can be built.

Physical Configuration

Any discussion of server configuration should start with the hardware. In particular, the factors affecting directory performance are available RAM; type, speed and number of processors; and data storage devices. Optimized performance on the data storage devices of a server really needs no explanation. The greater the performance in this area, the better any server-based program relying on disk I/O will perform. It also goes without saying that high performance network connections also enhance the server's ability to handle large traffic loads.

Processors

The next area to look at in configuring a server is the number of processors in the box. Certain portions of eDirectory are already configured to take advantage of the presence of multiple processors in the NetWare, Windows NT, Windows 2000, Solaris, and LINUX environments. The core directory, security, encryption, and LDAP modules are multi-processor enabled. The TCP/IP stack is multi-processor safe on NetWare. Since eDirectory uses the native TCP/IP stack in all environments, the multi-processor capability of the stack in the Windows NT, Windows 2000, Solaris and LINUX environments depends on the system's installation characteristics.

RAM

The final point of hardware configuration is RAM. How much RAM is enough? The answer really depends on the number of other processes the server is running, and on the size of the directory data store. I haven't met an IS manager yet who would say no to more RAM in his systems. The real guideline here is to install as much RAM as you can fit and afford. If the directory's RAM usage is properly configured, then added RAM usually results in increased performance.

Excellent reference information on server configuration can be found in an article titled "System Requirements for NDS eDirectory" by Nancy McLain, published in the July issue of Novell AppNotes.

LDAP Server Configuration

Several configuration options are available via ConsoleOne. Some of these can be set on the LDAP Group object and thereby applied to all LDAP servers in the group. Others are configurable on the LDAP Server object.

Properties of LDAP Group

Figure 1 shows the general configuration tab of the Properties page for the LDAP group object in ConsoleOne.

Figure 1: Properties page for the LDAP group object.

General Configuration Tab

This tab allows configuration of the referral mechanisms.

Referral Option.     The Always Chain forces the server to follow all referrals internally. No referrals are returned to the LDAP client. This setting should be used in trees that contain NetWare 4.x servers. The "Refer and chain" setting will return referrals to NDS eDirectory servers that support LDAP V3 connections. Chaining will be used if other versions of NDS in the tree are the target of the referral. The last option is to Always Refer. In order to select this option, you must make sure that all the servers in your tree are eDirectory servers.

Allow Clear Text Passwords.    This page also allows configuration of the LDAP clear text communication to NDS eDirectory. The box for Allow Clear Text Passwords must be checked if you want people to be able to authenticate to the directory using LDAP binds on the non-SSL LDAP port. If this box isn't checked and a user attempts to bind on the clear text port, the bind request will fail. If the user attempts a search, he will be bound using the anonymous connection.

Proxy Username.    The Proxy Username box allows the administrator to select the user that will become the LDAP anonymous user. By default, this is set to Public.

LDAP Group Attribute Map and Class Map

These pages (shown in Figure 2 and 3) are used to control the mapping of NDS names to LDAP names. Since NDS has been around much longer than the LDAP V3 specification, a lot of schema was created with non-LDAP names. Novell has historically tried to keep new versions of the directory as compatible as possible with older versions of the directory. When the IETF defined the LDAP schema, Novell decided that it was not feasible to go back and upgrade the schema on all of the installed NDS servers or to change all of the applications that were built based on NDS attribute and class names. Therefore, Novell implemented a system for mapping existing NDS attribute and class names to LDAP compliant names. Mappings are done by default for the NDS attributes and classes in the base installed schema. Other products installing schema must make sure that the attribute and class names are LDAP compliant, or mappings must be created so that the objects and attributes are accessible via LDAP. These pages allows attribute mappings to be defined, deleted and modified.

Figure 2: The LDAP Attribute Map tab from the Properties page of the LDAP group object.

Figure 3: Mapping control functionality for class names.

Properties of LDAP Server

Figure 4 shows the general LDAP server tab of the properties of the Properties of LDAP Server page.

General Tab of the LDAP Server Object.   This screen (see Figure 4) allows various time and size limits to be set for the server. This screen is also where the clear text LDAP port is set. The default for this port is 389. Any other port can be slected simply by editing the number in this field.

To disable clear text communications:

  1. Click the Disable TCP Port check box.

Figure 4: The General tab of the LDAP Server object properties page.

SSL Configuration.   Figure 5 shows the Server Properties tab (or page) for secure communication configuration. The default SSL port is 636. If you are running eDirectory on the same server as another directory server, you may need to reconfigure the TCP and SSL port assignments for one of the directories so that both are available to the client.

Figure 5: The SSL configuration tab of the LDAP Server properties page.

To disable SSL communications:

  1. Click the check box next to Disable SSL Port.

The SSL Certificate edit window allows the base certificate to be selected for SSL communications. A browse button is provided to help the administrator find the certificate easily. The default SSL method for eDirectory is to export a server-based certificate to the client. The client presenting the server's certificate in the SSL handshake establishes the connection.

When NDS is installed an Organizational (root) Certificate Authority (CA) is created in the Security container of the tree. Each tree can only have one Organizational CA. Other servers installed in the tree will use the Organizational CA of the first server installed.

When each server is installed, two base Key Material Objects (KMO) (or certificates) are created. The first is a DNS KMO and the second is an IP KMO. The only difference between the two certificates is in the name field. One contains the DNS name of the server, the other contains the IP address of the server. The system administrator can create more certificates (KMOs) as needed. Only one certificate can be associated with the server object. If one of these two base certificates is used, the system administrator needs to understand the primary method for referencing the directory server. If most clients refer to the server by name, associate the DNS certificate with the server. If most access is by IP address, then the IP certificate should be used.

In certain configurations, NDS eDirectory also supports Certificate Based Client Authentication as a SASL External method. To enable this method, your NDS eDirectory server needs to be configured with the Novell Modular Authentication Services (NMAS) product. NMAS is currently available on the NetWare platform and will soon be released on the NT platform. Release on the various flavors of UNIX and LINUX will follow the NT release. If you check the box for Enable Mutual Authentication, then the secure port will be configured so that only Certificate Based Client Authentication is allowed. The default server certificate method will no longer work. The two methods are mutually exclusive in NDS eDirectory at this time.

Certificates.    In order to use the server certificate method for establishing an SSL connection, it is necessary to export the certificate that the LDAP server recognizes from the server and import it into the client.

Figure 6: The Certificates tab of the Properties page of the SSL Certificate (KMO) selected for use by the LDAP server.

To export the certificate for use by a client:

  1. Click the Export button in the Trusted Root Certificate window. The Export A Certificate screen like the one in Figure 7 will appear.

    Figure 7: The Export screen.

  2. Select the file type you wish to export and the file name. The recommended mechanism is the binary DER format.

  3. Click the Export button to export the certificate file. The certificate can now be transferred to a client machine and imported.

Memory Management

NDS eDirectory uses memory for database cache and for directory usage. These are separate allocated memory pools. The directory engine uses memory from the operating system's available memory pool on an as-needed basis. The database has a cache pool that is defined by parameters detailed below. Under normal conditions, the more database cache you can give to NDS eDirectory, the better your performance. However, there are some caveats to this general rule. Since NDS eDirectory uses available system memory for its buffers, if clients are performing queries that require large data sets to be returned, you may need to decrease the size of the database cache in order to have enough system memory for the directory to handle building the query responses.

The database engine uses database cache to hold the most recently accessed blocks. This cache is initially defined with a fixed size of 16 Mb. The size of this cache can be changed from the command line in shipping versions of eDirectory. The following example command will set the eDirectory database cache to 80 million bytes.

set dstrace=!mb 80000000

You can also define a file named _ndsdb.ini in the sys:\_netware directory on a NetWare server, or in the directory containing the eDirectory database files on the Windows, Solaris, and LINUX environments (normally \novell\nds\dbfiles). This text file simply needs to contain a line like the following:

cache=80000000

Note: Don't put any white space around the = sign

The about to be released 85.00 version of eDirectory provides for a wider range of control over the database cache. The cache can be initialized with a hard limit just like the older versions. In addition, the 85.00 version allows upper and lower limits to be set either as hard numbers or as a percentage of available memory. Dynamic allocation control parameters allow the cache size to grow or shrink depending on usage. If the proper configuration parameters are set, the database cache will dynamically grow or shrink based on other system resource needs.

A ConsoleOne snap-in that will control the database memory usage is being developed. No release date for this snap-in has been decided yet. Until the snap-in is ready, editing the _ndsdb.ini file can control database memory usage. The format for ini file commands is given below:

cache=<cacheBytes<   # Set a hard memory limit

An alternative format is given in the following table.


cache=<cache options<

Set a hard limit or dynamically adjusting limit.# Multiple <cache options< may be specified, in any order, separated by# commas. All are optional. They are as follows:

DYN or HARD

# dynamic or hard limit

AVAIL or TOTAL

# These only apply if a HARD limit was chosen. Omit for a dynamic # limit.

%:<percentage<

# percentage of available or total physical memory.

MIN:<bytes<

# minimum number of bytes

MAX:<bytes<

# maximum number of bytes

LEAVE:<bytes<

# minimum number of bytes to leave for the OS.

blockcachepercent=<percentage<

#split of cache between block and record cache

If a hard limit is specified and the administrator wants to define the database cache to use a percentage of the memory, the administrator can choose between a percentage of total memory (all the memory on the box) or a percentage of available memory (all the memory not in use). Dynamic limits always refer to a percentage of available memory. Some examples of possible commands are in order. The following commands are all valid in the _ndsdb.ini file.

Dynamic limit of 75% available memory, minimum of 16 million bytes, and always leave 32 million bytes for the OS.

cache=DYN,%:75,MIN:16000000, LEAVE 32000000

Hard limit of 75% total physical memory, minimum of 18 million bytes, maximum of 512 million bytes.

cache=HARD, TOTAL,%:75,MIN:18000000, MAX 512000000

Old style - hard limit of 8 million bytes.

cache=8000000

Database cache is divided between block cache and record cache. Block cache holds data and index blocks that mirror storage on disk. Record cache holds in-memory representations of directory objects and attributes. If you are doing a lot of updates or additions to the directory, you want to favor the block cache setting. If you are doing mostly reads, then record cache should be favored. It is possible to cause a thrashing condition in both caches if you are doing numerous sequential updates and you haven't allocated cache size properly. Unless specifically changed, the cache is allocated to be 50% block cache and 50% record cache. The blockcachepercent option can be included in the _ndsdb.ini file to specify the percentage of cache that will be devoted to caching data and index blocks (default = 50%). The remaining cache will be used for entries.

Example (60% block cache, 40% record cache): blockcachepercent=60

It is not a good idea to select 100% of the cache for either block or record cache and starve the other cache type. In practice, you probably don't want to allocate more than 75% of your cache memory to one or the other type.

Database cache settings can also be controlled using NDS iMonitor.

Figure 8: The lower portion of the NDS agent configuration page for iMonitor.

Notice that it is possible to adjust all of the cache parameters (identified in Figure 8) using this page. If a parameter needs to be changed, simply modify the value on the page and click the submit button. The _ndsdb.ini file will be updated as a result of this action. A ConsoleOne snap-in for modifying these parameters is also under development and will be released when it is completed.

Tree Configuration

A flat namespace is the implied model for LDAP tree architecture. The flat directory design provides fast enumeration of data, better search speed, and a shorter access path. The problem with a flat namespace is that you lose the context for the information. In a flat tree design, context information can be held in attributes of each object.

The hierarchical namespace is better for browsing. However, searches are a little slower in a more hierarchical directory organization.

LDAP servers work best when all of the data is held on one server, and copies of that data are replicated to other servers in the organization. The number and location of servers is heavily influenced by network organization. It is best to design for one or more servers local to a specific area or within a high-speed network segment that contain all of the data required by users in that network segment. Multiple servers in the segment provide for a measure of fault tolerance. Replication among network segments keeps the data consistent.

NDS eDirectory 85.00 provides a filtered replication function that allows portions of the entire directory data store to be replicated to specific servers or groups of servers, thus cutting down on the replication traffic.

Catalog Services and Bindery

Older versions of NDS (prior to NDS 8) relied on catalogs to provide search performance increases and to provide contextless login. The contextless login feature became very important with older NDS versions because of the limits on the number of objects in a container and because of very 'deep' or hierarchical tree designs. Searches to find user objects in the tree would often require traversing to several servers, sometimes over slow WAN links. A user would much prefer to login as jsmith instead of jsmith.QA.cedar.lumber.Oregon.US.mypapercompany.

The catalog service basically dredged specified information from the entire tree on a regular basis, and held this sorted subset in a small database. The catalog APIs would begin reading catalog information at a specified offset in the file for a specified number of bytes or entries. Contextless login was possible because all occurrences of jsmith could easily be brought back from the catalog. If multiple jsmiths appeared in the catalog, the user could be prompted to select the correct one.

Because NDS 8.x servers can hold so much more data, it is now possible to hold replicas of the entire tree on a single server in many cases. If a customer is still using an application that relies on the catalog, it is now possible to hold all the data that needs to be dredged in one place. If the catalog is implemented on a server holding copies of all partitions, the dredging operation will be much quicker because it will not be necessary to leave the server to find all the data. Catalog operations will continue to be supported in the next releases of NDS eDirectory on servers holding non-filtered replicas of data. The catalog will not dredge against filtered replicas. Novell is not planning on providing any enhancements for catalog operations.

Support for LDAP in NDS eDirectory removes the need for catalog searches. NDS eDirectory servers can hold much more data than prior NDS servers, and LDAP searches are very fast. Filtered replication can also provide performance improvements in finding data. The need to dredge the directory periodically to mine data for a catalog has been removed. Novell recommends upgrading from applications that require the catalog to applications that access data via LDAP as soon as possible.

Previous versions of NDS supported the bindery APIs. The 85.00 release of eDirectory also supports bindery APIs. However, the bindery has severe performance impacts on the directory. Use of the bindery should be avoided wherever possible.

Schema

Novell continues to refine the schema that ships with NDS eDirectory. The latest major enhancements include the addition of the LDAP operational attributes creatorsName, createTimestamp, modifiersName, and modifyTimestamp per RFC 2252.

Many applications based on earlier versions of NDS had schema designed to rely on Novell's User object. To some extent, this practice still continues. Thus, when an application is installed on a server, the definition of the NDS User object is extended with the attributes required for that application. LDAP defines several other objects that are analogous to the NDS User object. The standard definition is inetOrgPerson. The net effect of this is that many valid objects that can login to the directory may not have the schema required to support some applications.

The IETF accepted as a standard the concept of auxiliary classes. These classes were designed to add schema to existing objects on an object by object basis. Novell recommends that any new applications requiring extension to 'User' type objects be done as auxiliary classes. The new schema definitions can then be applied to all objects that require them whether the object class be defined as User, inetOrgPerson, or myCompanyUserDefinition.

One of the major questions fielded by the NDS team is why eDirectory doesn't ship with the definition for inetOrgPerson as part of the base installed schema. NDS existed long before inetOrgPerson was standardized as a user definition. As inetOrgPerson was being defined, Novell originally chose to map the definition to the NDS User object class. Thus, in the base install of eDirectory, a subset of the attributes of inetOrgPerson are mapped in the LDAP mapping table to corresponding attributes of User, and the inetOrgPerson class is mapped to User. Many installations want a full definition of this object class. Novell has provided four schema files for download. They can be found at http://www.novell.com/products/nds/schema. The files are as follows:

iperson.zip - a zip file containing instructions and a .sch file for the full definition of inetOrgPerson as a separate directory object class.

nov_inet.zip - a zip file containing instructions and a .sch file to extend the definition of the NDS User object class so that it has all of the attributes of inetOrgPerson.

rperson.zip - a zip file containing instructions and a .sch file to create the residentialPerson directory object class.

nperson.zip - a zip file containing instructions and a .sch file to create the newPilotPerson directory object class.

As a general rule, a system administrator will want to keep the schema of his tree focused on the applications running against the directory. Excess schema is a pain to manage, and slows down bringing new servers into a tree because of the volume of schema that must synchronize.

Directory schema can be extended using several methods. ConsoleOne has methods for managing schema and NDS to LDAP name mappings. LDIF files can also be used to provide this functionality. Other Novell and third party applications also focus on schema management. A full discussion of schema and schema management is beyond the scope of this document. Further information can be found in the soon to be released book Novell's LDAP Developer's Guide.

Indexes

NDS eDirectory can store a great deal of data on a single server. The restrictions for earlier versions of NDS relating to 5,000 objects in a container, limited containers in a partition, and limited objects held on a single server were removed when version 8 of NDS (eDirectory) was released. Obviously, the more data that can be held on a server, the more time it takes to get a single entry. Many directories have very high performance when enough RAM is available on the directory server to cache the entire content of the directory. However, as your directory size grows beyond the capacity of the cache, performance decreases dramatically.

The greatest factor in LDAP search performance in eDirectory is the use of indexes. When an LDAP search filter is analyzed, the directory determines if an index that has been defined on the server can be applied to the search. The graph below shows the difference in search time when an index is used versus no index being used. The tests were done in a directory containing two million objects split among twenty containers on one server.

Figure 9: Impact of an index on search performance.

As you can readily see, the presence of an index has a profound effect on search performance.

Selecting the right indexes to optimize performance on a specific server is beyond the scope of this article. Indexes can be defined and managed using ConsoleOne and LDAP. Index status can be monitored using the NDS iMonitor product. Using the dstrace and predicate statistics facilities provided in NDS eDirectory can help determine which attributes to index and which index is being used for a particular query. Detailed information on handling indexes in eDirectory can be found in an article by this author titled "How to Supercharge LDAP Searches with eDirectory Indexes" published in the July issue of Novell AppNotes.

Since the eDirectory version containing this functionality has not been fully released yet, the ConsoleOne screen for migrating the index definition to other servers that was defined in the titled "How to Supercharge LDAP Searches with eDirectory Indexes" has been changed. It will not generate a list of servers in the tree. This takes too long when you have a lot of servers in your tree! Instead, a browse capability will be implemented, so that specific servers can be selected to receive the new or updated index definition.

NetWare Specific Configuration

This article will only deal with configuring the NetWare operating system for optimal NDS eDirectory performance. The following parameters were used in Novell's load and performance testing for eDirectory. Each parameter has an explanation of its effect on performance. Each of these are NetWare SET parameters. They can be modified from the NetWare monitor screens or from the command line. Command line control is done by typing set <command name<=<value<.

Max TCP Port Limit = 45000

The Max TCP Port Limit parameter sets the upper boundary for the number of TCP ephemeral ports used by the system. The lower bound is set at 1024. The upper bound can be set to 54,999. NDS eDirectory uses three ephemeral ports per authenticated connection. The TCP/IP stack that shipped with versions of NetWare prior to 5.1 had a hard limit on ephemeral ports that allowed only about 3,750 ports to be used on the server. This resulted in a maximum of about 1,100 simultaneous connections. NetWare 5.1 contains a new TCP/IP stack that sets the default number of ports to 54,999 and contains this set parameter for tuning. This stack is also available from Novell consulting for the NetWare 5 release.

Maximum Pending TCP Connectio]n Requests = 4096

The default value for this parameter is 128. Setting this parameter to the upper limit of 4096 allows the server to handle the larger number of connection requests that occur in systems where numerous clients are attaching. Novell's test configuration was 1,500 simultaneous client connections.

Maximum Packet Receive Buffers = 10000

This limits the number of buffers that the receiving protocol stack has available. The default value is 500. This parameter limits the memory consumption of the IP stack. It should be about 3x the Minimum Packet Receive Buffers value.

Minimum Packet Receive Buffers = 3000

The operating system will allocate the minimum number of receive buffers as a contiguous block of memory at startup. These buffers are used to handle all received communications. LDAP worker threads use these buffers during searches. In Novell's performance testing, we set the minimum limit to two buffers per anticipated client. The default value is 128.

Maximum Physical Receive Packet Size=2048

The TCP/IP packet receive buffer size defaults to 4224 on a NetWare server. In a TCP/IP only environment, this parameter can be set to 2048. TCP packets are less than 2K and will fit in this buffer size. This is done to conserve memory.

Maximum Concurrent Disk Cache Writes = 2000

This NetWare parameter is used to limit the number of writes to give priority to reads. The default value is 750. Newer disk systems can handle more writes faster, so this value is increased. In our testing environment, we increased this value to improve bulk loading performance in the directory. It had no effect on regular directory operation.

Maximum Concurrent Directory Cache Writes = 500

This directory cache relates to the NetWare file system cache. Larger values here help when the file system is doing a lot of writes. In our testing environment, we increased this number to improve bulk loader performance. It had no effect on directory operation. However, if your directory server is also supporting a lot of NetWare file system operations, you may want to look at increasing this value from the default setting of 75.

Maximum Directory Cache Buffers = 200000

This parameter relates to the NetWare file system directory cache, not to any cache associated with NDS. The default setting of 500 is probably fine for most NDS operations, and will allow more available memory to be used for NDS database cache. You would want to increase the number of directory cache buffers if your eDirectory server is also doing a lot of file system operations. This will improve the performance for the file system. The maximum limit for directory cache buffers is 200000. Each buffer is 4160 bytes.

Maximum Number Of Internal Directory Handles = 100

This parameter also applies to NetWare file system directory handles available to processes running on the NetWare server. The default value of 100 should be fine for most eDirectory operations. If other processes are running on your eDirectory NetWare server that require a lot of file I/O, you may want to consider upping this limit so that directory handles remain available to a connection longer, thus eliminating the need to re-check rights on the connection.

Maximum Number Of Directory Handles = 20

This parameter limits the number of NetWare file system directory handles available to client applications. The default value is 20. This value has no effect on eDirectory operations. If other client processes are running against your eDirectory NetWare server that require a lot of file I/O, you may want to consider upping this limit so that directory handles remain available to a connection longer, thus eliminating the need to re-check rights on the connection.

Nancy McLain's article "System Requirements for NDS eDirectory," published in the July issue of Novell AppNotes, refers to the above parameters in the list of configuration settings. Her information came from an incomplete copy of the above list. The information given above for these parameters should be considered as the definitive definition.

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates