How to Configure and Optimize eDirectory LDAP Servers

H
O
W
-
T
O
A
R
T
I
C
L
E
How to Configure and Optimize
eDirectory LDAP Servers
DeveloperNet University
Publications
.......................................................................................................................................
Gary Anderson
Director
eDirectory Core Technologies
[email protected]
Posted: 08/01/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.
Contents:
Copyright © 2000 by Novell, Inc. All rights
reserved. No part of this document may be
reproduced or transmitted in any form or by
any means, electronic or mechanical,
including photocopying and recording, for
any purpose without the express written
permission of Novell.
•
Operating System
•
Physical Configuration
•
LDAP Server Configuration
•
Memory Management
•
Tree Configuration
•
Catalog Services and Bindery
•
Schema
•
Indexes
•
NetWare Specific Configuration
All product names mentioned are trademarks
of their respective companies or distributors.
N O V E L L
A P P N O T E S
•
S E P T E M B E R
2 0 0 0
55
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.
56
H O W
T O
C O N F I G U R E
A N D
O P T I M I Z E
E D I R E C T O R Y
L D A P
S E R V E R S
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.
N O V E L L
A P P N O T E S
•
S E P T E M B E R
2 0 0 0
57
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.
58
H O W
T O
C O N F I G U R E
A N D
O P T I M I Z E
E D I R E C T O R Y
L D A P
S E R V E R S
Figure 2: The LDAP
Attribute Map tab from the
Properties page of the LDAP
group object.
Figure 3: Mapping
control functionality for
class names.
N O V E L L
A P P N O T E S
•
S E P T E M B E R
2 0 0 0
59
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.
60
H O W
T O
C O N F I G U R E
A N D
O P T I M I Z E
E D I R E C T O R Y
L D A P
S E R V E R S
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.
N O V E L L
A P P N O T E S
•
S E P T E M B E R
2 0 0 0
61
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.
62
H O W
T O
C O N F I G U R E
A N D
O P T I M I Z E
E D I R E C T O R Y
L D A P
S E R V E R S
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
N O V E L L
A P P N O T E S
•
S E P T E M B E R
2 0 0 0
63
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
64
H O W
T O
C O N F I G U R E
A N D
O P T I M I Z E
E D I R E C T O R Y
L D A P
S E R V E R S
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.
N O V E L L
A P P N O T E S
•
S E P T E M B E R
2 0 0 0
65
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.
66
H O W
T O
C O N F I G U R E
A N D
O P T I M I Z E
E D I R E C T O R Y
L D A P
S E R V E R S
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.
N O V E L L
A P P N O T E S
•
S E P T E M B E R
2 0 0 0
67
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
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.
68
H O W
T O
C O N F I G U R E
A N D
O P T I M I Z E
E D I R E C T O R Y
L D A P
S E R V E R S
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.
At least
one index 0.31
in query
No index
in query
1085.13
0
200
time in seconds
400
600
800
1000
1200
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.
N O V E L L
A P P N O T E S
•
S E P T E M B E R
2 0 0 0
69
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.
70
H O W
T O
C O N F I G U R E
A N D
O P T I M I Z E
E D I R E C T O R Y
L D A P
S E R V E R S
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.
N O V E L L
A P P N O T E S
•
S E P T E M B E R
2 0 0 0
71
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.
72
H O W
T O
C O N F I G U R E
A N D
O P T I M I Z E
E D I R E C T O R Y
L D A P
S E R V E R S