|
| Sun ONE Directory Server 5.2 Installation and Tuning Guide |
Chapter 5 Tuning the Operating System
Default system and network settings are not suitable for high performance directory services. Tuning the system for optimum Directory Server performance involves at minimum checking that the latest recommended patches are installed on the system, enforcing basic security measures, and changing some system and network settings. This chapter addresses those tuning issues.
The idsktune utility (also /usr/sbin/directoryserver idsktune in the Solaris packaged version) provided with the product may help you to diagnose basic system configuration shortcomings. The utility offers system tuning recommendations for support of high performance directory services. The utility does not actually implement any of the recommendations made. Tuning recommendations should be implemented by a qualified system administrator.
Checking Platform Support
Table 1-1 specifies platforms and associated hardware architectures supported for this release. Refer to the product release notes for an updated list of supported platforms.
When installing a Windows system, specify that the computer is a stand-alone server, not a member of any existing domain or workgroup, to reduce dependencies on network security services.
Patching the System
In order to maintain overall system security, and to ensure proper installation and operation of Sun ONE Directory Server 5.2, install the latest recommended system patches, service packs, or fixes. Table 5-1 suggests where to look for required patches.
Table 5-1 Where to Obtain Patches, By Platform
Platform
Browse...
Sun Solaris™ Operating Environment
Hewlett Packard HP-UX
IBM AIX
Microsoft Windows
Red Hat Linux
Enforcing Basic Security
The recommendations in this section do not eliminate all risk. Instead, they are intended as a short checklist to help you work to limit some of the most obvious security risks.
Isolate the System
If at all possible, isolate the system running Directory Server from the public Internet using a network firewall. Isolating the system is particularly important when running Directory Server on Windows platforms that must be protected from IP-based attacks.
No Dual Boot
Do not dual boot or run other operating systems on the system running Directory Server. Other systems may permit access to otherwise restricted files.
Strong Passwords
Use a super user or Administrator password at least 8 characters long that includes punctuation or other non-alphabetic characters. Using a strong password is particularly important when running Directory Server on Windows platforms.
If you choose to use longer operating system passwords, it may be necessary to configure the way passwords are handled by the system. Refer to the operating system documentation for instructions.
(Windows) Local Security Policy
Implement a local security policy for the Windows server that locks users out after bad logon attempts. Activate and configure event logging to manage a log of appropriate size for the deployment. Also activate audit logging for logon attempts. Consider renaming the Administrator account to make it harder to guess.
Refer to Windows help for details.
(UNIX Platforms) Users and Groups
For security reasons, it is recommended not to run Directory Server or Administration Server with super user privileges. You may, for example, create a user and group without login privileges, and then install and run the servers as this user and group. If you add the user and group to local files the /etc/passwd entry could be, for example:
server:x:61001:Server User:/dev/null:/dev/null
The corresponding /etc/group entry could be, for example:
servers::61001:
To facilitate debugging, you may choose to allow processes running with this user and group identity to dump core, using utilities such as coreadm(1M) on Solaris systems.
If a particular deployment calls for sharing Directory Server files with other servers such as a messaging server, consider running those servers using the same user and group.
If you must run the Administration Server as super user, consider stopping the service when not using it.
Disabling Unnecessary Services
For top performance and less risk, dedicate the system to Directory Server alone. Running additional services, especially network services, negatively affects server performance and scalability, and may increase security risks.
Disable as many network services as possible. Directory Server uses only TCP/IP and does not require file sharing and other services. Disable services such as IP Routing, Mail, NetBIOS, NFS, RAS, Web Publishing, and Windows Network Client services. On Windows in particular, stop and disable all services except for Event Log, Plug and Play, Protected Storage, Security Accounts Manager, Sun ONE Administration Server, Sun ONE Directory Server, Remote Procedure Call (RPC), and SNMP. Consider disabling telnet and ftp.
As with many network services, telnet and ftp pose security risks. These two services are particularly dangerous in that they transmit user passwords in clear text over the network. You may be able to work around the need telnet and ftp by using clients such as Secure Shell (ssh) and Secure FTP (sftp) instead.
If the Directory Server instance does not itself provide the naming service for the network, consider enabling a naming service for the system. Remote administration tools such as Sun ONE Server Console rely on the naming service for some aspects of their operation such as translating between IP addresses and host names.
Refer to the operating system documentation for details on disabling network services.
Keeping Accurate Time
Ensure the system clock is reasonably in sync with those of other systems to facilitate replication and correlation of date and time stamps in log files between systems. Consider using a Network Time Protocol (NTP) client to set the correct system time, for example, especially on Windows systems.
Restarting After System Failure
When possible, stop Directory Server as described in the Sun ONE Directory Server Administration Guide. Database corruption may cause Directory Server to start slowly if stopped abruptly during system shutdown, rather than shut down appropriately. Time may be needed to recover the database.
(Solaris Packages) As part of the installation and configuration process, appropriate scripts enable restart at boot time.
(Windows) Configure Windows to restart automatically after system failure. Refer to Windows help for details.
For other platforms, refer to the operating system documentation for details on starting services at boot time.
Generating Basic Tuning Recommendations
Use the idsktune utility, /usr/sbin/directoryserver idsktune for the Solaris packaged version, or idsktune for other versions located in the directory containing the product binaries, to generate basic tuning recommendations on platforms other than Windows.
When you run the utility as super user, it gathers information about information about the system. It displays notices, warnings, and errors with recommended corrective actions. For example, the utility checks that:
- Operating system and kernel versions are supported for this release.
- Available memory and disk space meet minimum requirements for typical use.
- System resource limits meet minimum requirements for typical use.
- Required patches or service packs are installed.
Note Fix at minimum all ERROR conditions before installing Directory Server software on a system intended for production use.
Individual deployment requirements may exceed minimum requirements. You may opt to provide more resources than those identified as minimum system requirements by the idsktune utility.
Refer to the Sun ONE Directory Server Resource Kit documentation for details concerning the utility. The Sun ONE Directory Server Resource Kit can be obtained as described in "Downloading Directory Server Tools".
Tuning System Settings
You may use the idsktune tool that reads current system settings and recommends changes. In general, implementing the recommendations optimizes performance both on systems dedicated to running Directory Server and on systems running additional applications.
Consider local network conditions and other applications before implementing specific recommendations. Refer to the operating system documentation for additional network tuning tips.
(Windows) Deferred Procedure Calls
Windows default Deferred Procedure Call (DPC) handling of deferred interrupt requests to handle incoming network traffic in multiprocessor systems can have negative performance impact. In effect, deferred interrupts that become DPCs may be rescheduled from one processor to another, incurring significant overhead. To prevent these DPC overhead problems, set the value of ProcessorAffinityMask to 0 under the following registry key:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NDIS\Parameters
File Descriptors
Directory Server uses file descriptors when handling concurrent client connections. Having a low maximum number of file descriptors available in the system or available to a process can thus limit the number of concurrent connections. Recommendations concerning the number of file descriptors therefore relate to the number of concurrent connections Directory Server may be able to handle on the system.
On Solaris systems, the number of file descriptors available is configured through the rlim_fd_max parameter, as described in the output of /usr/sbin/directoryserver idsktune (packaged version) or idsktune (no packages). Refer to the operating system documentation for further instructions on modifying the number of available file descriptors.
After modifying the maximum number of available file descriptors on the system, refer to Table 9-2 for information on configuring Directory Server to use the available file descriptors.
(HP-UX) Large File Support
On some HP-UX systems, large files are not supported by default. Refer to the HP-UX product documentation for instructions on enabling large file support on the file systems where you intend to install Directory Server. Instructions are also provided in the output of the idsktune utility.
(HP-UX) Threads Pending Timeout
On some HP-UX systems, the maximum number of threads pending timeouts may be inappropriately set as indicated by the idsktune utility. Refer to the HP-UX documentation for instructions on increasing the maximum number of threads pending timeouts. Instructions are also provided in the output of the idsktune utility.
(HP-UX) Threads Per Process
On some HP-UX systems, the maximum number of threads per process may be too low as indicated by the idsktune utility. Refer to the HP-UX documentation for instructions on increasing the maximum number of threads per process. Instructions are also provided in the output of the idsktune utility.
Transmission Control Protocol (TCP) Settings
Specific network settings depend on the platform. On some systems, it is possible to enhance Directory Server performance by modifying TCP settings. This section discusses the reasoning behind idsktune recommendations concerning TCP settings.
Closed Connections in the TIME-WAIT State
Some systems allow you to configure how long a TCP connection is held in the kernel table after closure. While the connection is held, it may be opened again quickly. When set too high, the system may track a large number of connections in the kernel table over long intervals, reducing the number of available connections to Directory Server. For most deployments, setting this parameter to a value of 30 seconds (30,000 milliseconds) allows more concurrent connections to Directory Server.
On Solaris systems, this time interval is configured through the tcp_time_wait_interval parameter, as described in the output of /usr/sbin/directoryserver idsktune (packaged version) or idsktune (no packages).
Connections Pending Acceptance
Some systems allow you to configure the number of TCP connections pending acceptance by a TCP listener such as Directory Server. When set too low, this limits the number of pending connections Directory Server can accept. For most deployments, setting this parameter to a value of at least 1024 allows Directory Server to handle more concurrent connection requests.
On Solaris systems, the number of pending connections allowed is configured through the tcp_conn_req_max_q parameter, as described in the output of /usr/sbin/directoryserver idsktune (packaged version) or idsktune (no packages). Consider increasing tcp_conn_req_max_q0 to 2048.
Deferred Acknowledgement
Some systems allow you to configure how long TCP acknowledgements are delayed for hosts not directly connected to the system. Instead of configuring delay times directly, set nsslapd-nagle on cn=config to off as described in Table 9-2.
Inactive Connections
Some systems allow you to configure the interval between transmission of keepalive packets. This setting can determine how long a TCP connection is maintained while inactive and potentially disconnected. When set too high, the keepalive interval may cause the system to use unnecessary resources keeping connections alive for clients that have become disconnected. For most deployments, setting this parameter to a value of 600 seconds (600,000 milliseconds = 10 minutes) allows more concurrent connections to Directory Server.
On Solaris systems, this time interval is configured through the tcp_keepalive_interval parameter, as described in the output of /usr/sbin/directoryserver idsktune (packaged version) or idsktune (no packages).
Incoming Connections
Some systems allow you to configure how long a system waits for an incoming connection not sending acknowledgements. When set too high, this can cause long delays in detecting connection failure. For intranet deployments on fast and reliable networks, setting this parameter to a value of 600 seconds (600,000 milliseconds = 10 minutes) may improve performance.
On Solaris systems, this time interval is configured through the tcp_ip_abort_interval parameter, as described in the output of /usr/sbin/directoryserver idsktune (packaged version) or idsktune (no packages).
Outgoing Connections
Some systems allow you to configure how long a system waits for an outgoing connection to be established. When set too high, establishing outgoing connections to destination servers such as replicas not responding quickly can cause long delays. For intranet deployments on fast and reliable networks, setting this parameter to a value of 10 seconds may improve performance.
On Solaris systems, this time interval is configured through the tcp_ip_abort_cinterval parameter, as described in the output of /usr/sbin/directoryserver idsktune (packaged version) or idsktune (no packages).
Retransmission Timeout
Some systems allow you to configure the initial time interval between retransmission of packets. This setting affects the wait before retransmission of an unacknowledged packet. When set too high, clients may be kept waiting on lost packets. For intranet deployments on fast and reliable networks, setting this parameter to a value of 500 milliseconds may improve performance.
On Solaris systems, this time interval is configured through the tcp_rexmit_interval_initial parameter, as described in the output of /usr/sbin/directoryserver idsktune (packaged version) or idsktune (no packages).
Windows can implement the Van Jacobson TCP fast retransmit and recovery algorithm to retransmit quickly missing segments upon the receipt of an ACK without waiting for the retransmission timer to expire. To implement the Van Jacobson algorithm, edit the registry key:
HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/Tcpip/Parameters
Add TcpMaxDupAcks having type REG_DWORD. Set the value to the number of ACKs. The range is 1-3, and the default is 2.
Sequence Numbers
Some systems allow you to configure how the system handles initial sequence number generation. For extranet and Internet deployments, set this parameter such that initial sequence number generation is based on RFC 1948 to prevent sequence number attacks.
On Solaris systems, this behavior is configured through the tcp_strong_iss parameter, as described in the output of /usr/sbin/directoryserver idsktune (packaged version) or idsktune (no packages).