Directory Server Enterprise Edition administration has changed significantly since the 5.x version of Directory Server. These changes are described in detail in the Sun Java System Directory Server Enterprise Edition 6.2 Administration Guide.
This chapter provides an overview of these changes and describes the administrative decisions that you must make in the planning phase of your deployment:
Directory Server Enterprise Edition gives the administrator more control over instance creation and administration. This control is achieved by using two new commands, dsadm and dsconf. These commands provide all the functionality previously supplied by the directoryserver command plus additional functionality.
The dsadm command enables the administrator to create, start, and stop a Directory Server instance. This command combines all operations that require file system access to the Directory Server instance. The command must be run on the machine that hosts the instance. It does not perform any operation that requires LDAP access to the instance or access to an agent.
In the new administration model, a Directory Server instance is no longer tied to a ServerRoot. Each Directory Server instance is a standalone directory that can be manipulated in the same manner as an ordinary standalone directory.
The dsconf command combines the administration operations that require write access to cn=config. The dsconf command is an LDAP client. It can only be executed on an active Directory Server instance. The command can be run remotely, enabling administrators to configure multiple instances from a single remote machine.
Directory Proxy Server provides two comparable commands, dpadm and dpconf. The dpadm command enables the administrator to create, start, and stop a Directory Proxy Server instance. The dpconf command enables the administrator to configure Directory Proxy Server by using LDAP and to access the Directory Server configuration through Directory Proxy Server.
In addition to these command-line utilities, Directory Server Enterprise Edition is integrated into the Java Web Console. The Console enables Directory Server Enterprise Edition and other Sun products to be managed from a centralized user interface. Directory Service Control Center (DSCC) is a service of the Java Web Console that is specifically for managing Directory Servers and Directory Proxy Servers. DSCC provides the same functionality as the command-line utilities, as well as wizards that enable you to configure several servers simultaneously. In addition, DSCC provides a replication topology drawing tool that enables you to monitor replication topologies graphically. This tool simplifies replication monitoring by providing a real-time view of individual masters, hubs, and consumers, and the replication agreements between them.
The Directory Server Enterprise Edition administration model, described in the previous section, also enables remote administration of any Directory Server or Directory Proxy Server in the topology. Servers can be administered remotely using both the command-line utilities and the Java Web Console.
The dsadm and dpadm utilities cannot be run remotely. These utilities must be installed and run on the same machine as the server instance that is being administered. For details of the functionality provided with dsadm and dpadm, see the dsadm(1M) and dpadm(1M) man pages.
The following figure illustrates how the new administration model facilitates remote administration. This illustration shows that the console and configuration commands can be installed and run remotely from the Directory Server and Directory Proxy Server instances. The administration commands must be run locally to the instances.
In any failure situation that involves data corruption or data loss, it is imperative that you have a recent backup of your data. Avoid reinitializing servers from other servers where possible. For information about how to back up data, seeChapter 8, Directory Server Backup and Restore, in Sun Java System Directory Server Enterprise Edition 6.2 Administration Guide.
This section provides an overview of what to consider when planning a backup and recovery strategy.
Apply the following high-level principles when designing a backup strategy:
Identify the data that must be backed up.
For Directory Server Enterprise Edition this data includes the following:
Shared binaries and plug-ins
Certificate database files
Log files and the change log database
Ensure that your backup and recovery strategy includes the hardware, operating system, and software components.
Decide whether you will keep binary backups or LDIF backups.
Build automation around backup and recovery tools, and ensure that automatic scripts are maintained.
This strategy avoids unnecessary delays if you have to restore from a backup in an emergency.
Determine a retention and rotation strategy.
This strategy includes how often you perform backups and how long you keep them. When determining retention and rotation of backups, be aware of the purge delay and its impact on backups in a replicated topology. As modifications occur on a supplier, changes are recorded in the change log. Without a method of emptying the change log, its size would continue to increase until the change log consumed all available disk space. By default, changes are purged every seven days. This period is known as the purge delay. When a change has been purged, the change can no longer be replicated. For this reason, make sure that databases are backed up at least as often as the purge delay.
Use the backup and recovery tools provided with Directory Server Enterprise Edition rather than merely performing a system backup and recovery.
Directory Server Enterprise Edition provides two methods of backing up data: binary backup and backup to an LDIF file. Both of these methods have advantages and limitations, and knowing how to use each method will assist you in planning an effective backup strategy.
Binary backup produces a copy of the database files, and is performed at the file-system level. The output of a binary backup is a set of binary files containing all entries, indexes, the change log, and the transaction log. A binary backup does not contain configuration data.
Binary backup is performed using one of the following commands:
dsadm backup must be run offline, that is, when the Directory Server instance is stopped. The command must be run on the local server containing the Directory Server instance.
dsconf backup can be run online and remote to the Directory Server instance.
Binary backup has the following advantages:
All suffixes can be backed up at the same time.
Binary backup is significantly faster than a backup to LDIF.
The replication change log is backed up.
Binary backup has one limitation. Restoration from a binary backup can be performed only on a server with an identical configuration.
This limitation implies the following:
Both machines must use the same hardware and the same operating system, including any service packs or patches.
Both machines must have the same version of Directory Server installed, including binary format (32 bits or 64 bits), service packs and patch levels.
Both servers must have the same directory tree that is divided into the same suffixes. The database files for all suffixes must be copied together Individual suffixes cannot be copied.
Each suffix must have the same indexes configured on both servers, including virtual list view (VLV) indexes. The database files for the suffixes must have the same name.
Each server must have the same suffixes configured as replicas. If fractional replication is configured, fractional replication must be configured identically on all master servers.
Attribute encryption must not be used on either server.
At a minimum, you need to perform a regular binary backup on each set of coherent machines. Coherent machines are machines that have an identical configuration, as defined previously.
Because restoration from a local backup is easier, perform a binary backup on each server.
These abbreviations are used in the remaining diagrams in this chapter:
M = master replica
RA = replication agreement
The following figure assumes that M1 and M2 have an identical configuration and that M3 and M4 have an identical configuration. In this scenario, a binary backup would be performed on M1 and on M3. In the case of failure, M1 or M2 could be restored from the binary backup of M1 (db1). M3 or M4 could be restored from the binary backup of M3 (db2). M1 and M2 could not be restored from the binary backup of M3. M3 and M4 could not be restored from the binary backup of M1.
For details on how to use the binary backup commands, see Binary Backup in Sun Java System Directory Server Enterprise Edition 6.2 Administration Guide.
Backup to LDIF is performed at the suffix level. The output of a backup to LDIF is a formatted LDIF file, which is a copy of the data contained in the suffix. As such, this process takes longer than a binary backup.
Backup to LDIF is performed using one of the following commands:
dsadm export must be run offline, that is, when the Directory Server instance is stopped. This command must be run on the local server containing the Directory Server instance.
dsconf export can be run online and remote to the Directory Server instance.
Replication information is backed up unless you use the -Q option when running these commands.
The dse.ldif configuration file is not backed up in a backup to LDIF. To enable you to restore a previous configuration, back this file up manually.
Backup to LDIF has the following advantages:
Backup to LDIF can be performed from any server, regardless of its configuration.
Restoration from an LDIF backup can be performed on any server, regardless of its configuration.
Backup to LDIF has one limitation. In situations where rapid backup and restoration are required, backup to LDIF might take too long to be viable.
You need to perform a regular backup by using backup to LDIF for each replicated suffix, on a single master in your topology.
In the following figure, dsadm export is performed for each replicated suffix, on one master only (M1).
For information about how to use the backup to LDIF commands, see Backing Up to LDIF in Sun Java System Directory Server Enterprise Edition 6.2 Administration Guide.
Directory Server Enterprise Edition provides two methods of restoring data: binary restore and restoration from an LDIF file. As with the backup methods, both of these methods have advantages and limitations.
dsadm restore must be run offline, that is, when the Directory Server instance is stopped. This command must be run on the local server containing the Directory Server instance.
dsconf restore can be run online and remote to the Directory Server instance.
Binary restore has the following advantages:
All suffixes can be restored at the same time.
The replication change log is restored.
Binary restore is significantly faster than restoring from an LDIF file.
Binary restore has the following limitations:
Restoration can be performed only on a server with an identical configuration, as defined in Binary Backup. For more information about restoring data with the binary restore feature, see Binary Restore in Sun Java System Directory Server Enterprise Edition 6.2 Administration Guide.
If you are not aware that your database was corrupt when you performed the binary backup, you risk restoring a corrupt database. Binary backup creates an exact copy of the database.
Binary restore is the preferred restoration method if the machines have an identical configuration and time is a major consideration.
The following figure assumes that M1 and M2 have an identical configuration and that M3 and M4 have an identical configuration. In this scenario, M1 or M2 can be restored from the binary backup of M1 (db1). M3 or M4 can be restored from the binary backup of M3 (db2).
dsadm import must be run offline, that is, when the Directory Server instance is stopped. This command must be run on the local server containing the Directory Server instance.
dsconf import can be run online and remote to the Directory Server instance.
Restoration from an LDIF file has the following advantages:
This command can be performed on any server, regardless of its configuration.
A single LDIF file can be used to deploy an entire directory service, regardless of its replication topology. This functionality is particularly useful for the dynamic expansion and contraction of a directory service according to anticipated business needs.
Restoration from an LDIF file has one limitation. In situations where rapid restoration is required, this method might take too long to be viable. For more information about restoring data from an LDIF file, see Importing Data From an LDIF File in Sun Java System Directory Server Enterprise Edition 6.2 Administration Guide.
In the following figure, dsadmin import is performed for each replicated suffix, on one master only (M1).
Logging is managed and configured at the individual server level. While logging is enabled by default, it can be reconfigured or disabled according to the requirements of your deployment. Designing a logging strategy assists with planning hardware requirements. For more information, see Hardware Sizing For Directory Server.
This section describes the logging facility of Directory Server Enterprise Edition.
Each Directory Server in a topology stores logging information in three files:
Each Directory Proxy Server in a topology stores logging information in two files:
Access log. Lists the clients that connect to Directory Proxy Server and the operations requested.
Error log. Contains server error messages.
You can manage the log files for both Directory Server and Directory Proxy Server in these ways:
Defining log file creation policies
Defining log file deletion policies
Manually creating and deleting log files
Defining log file permissions
A log file creation policy enables you to periodically archive the current log and start a new log file. Log file creation policies can be defined for Directory Server and Directory Proxy Server from the Directory Control Center or using the command-line utilities.
When defining a log file creation policy, consider the following:
How many logs do you want to keep?
When this number of logs is reached, the oldest log file in the folder is deleted before a new log is created. If this value is set to 1, the logs are not rotated and grow indefinitely.
What is the maximum size, in Megabytes, for each log file?
When a log file reaches this maximum size or the maximum age defined in the next item, the file is archived. A new log file is started.
How often should the current log file be archived?
The default is every day.
At what time of day should log files be rotated?
Time-based rotation makes operations like log analysis and trending easier, because each log file covers the same time period.
Log file rotation can also be based on a combination of criteria. For example, you can specify that logs be rotated at 23h30 only if the file size is greater than 10 Megabytes.
For details on how to set up a log file creation policy, see Configuring Logs for Directory Server in Sun Java System Directory Server Enterprise Edition 6.2 Administration Guide.
A log file deletion policy enables you to automatically delete old archived logs. Log file deletion policies can be defined for Directory Server and Directory Proxy Server from the Directory Service Control Center or using the command-line utilities. A log file deletion policy is not applied unless you have defined a log file creation policy. Log file deletion will not work if you have just one log file. The server evaluates and applies the log file deletion policy at the time of log rotation.
When defining a log file deletion policy, consider the following:
What is the maximum size of the combined archived logs?
When the maximum size is reached, the oldest archived log is automatically deleted.
What is the minimum free disk space that should be available?
When the free disk space reaches this minimum value, the oldest archived log is automatically deleted.
What is the maximum age of log files?
When a log file reaches this maximum age, the log file is automatically deleted.
For details on how to set up a log file deletion policy, see Configuring Logs for Directory Server in Sun Java System Directory Server Enterprise Edition 6.2 Administration Guide.
Manual file rotation and forced log rotation do not apply to Directory Proxy Server.
If you do not want to define automatic creation and deletion policies for Directory Server, you can create and delete log files manually. In addition, Directory Server provides a task that enables you to rotate any log immediately, regardless of the defined creation policy. This functionality might be useful if, for example, an event occurs that needs to be examined in more detail. The immediate rotation function causes the server to create a new log file. The previous file can therefore be examined without the server appending logs to this file.
For information about how to rotate logs manually and how to force log rotation, see Rotating Directory Server Logs Manually in Sun Java System Directory Server Enterprise Edition 6.2 Administration Guide.
In 5.x version of Directory Server, log files could only be read by the directory manager. Directory Server Enterprise Edition enables server administrators to define the permissions with which log files are created. For information about how to define log file permissions, see Configuring Logs for Directory Server in Sun Java System Directory Server Enterprise Edition 6.2 Administration Guide.
An effective monitoring and event management strategy is crucial to a successful deployment. Such a strategy defines which events should be monitored, which tools to use, and what action to take should an event occur. If you have a plan for commonplace events, possible outages and reduced levels of service can be prevented. This strategy improves the availability and quality of service of your directory.
To design a monitoring strategy, do the following:
Select the appropriate monitoring tools. See Monitoring Tools Provided With Directory Server Enterprise Edition.
Identify the key areas to be monitored in the directory architecture.
These areas are frequently the same as the sizing and tuning attributes. See Identifying Monitoring Areas.
Define what triggers an event or alarm condition when monitoring the key performance measure.
This strategy implies defining an acceptable level of performance or operation for each performance measure.
Determine what action should be taken when an alarm condition occurs.
The monitoring areas described in Identifying Monitoring Areas can be monitored using one or more of these tools.
Command-line tools. Include operating system-specific tools to monitor performance such as disk usage, LDAP tools such as ldapsearch to collect server statistics stored in the directory, third-party tools, or custom shell or Perl scripts.
Directory Server and Directory Proxy Server logs. Include the access, audit, and error logs. These logs can be monitored manually or parsed using custom scripts to extract monitoring information that is relevant to your deployment. The Directory Server Resource Kit provides a log analyzer tool, logconv, that enables you to analyze the access logs. The log analyzer tool extracts usage statistics and counts the occurrences of significant events. For more information about this tool, see logconv(1). For information about viewing and configuring log files, see Chapter 14, Directory Server Logging, in Sun Java System Directory Server Enterprise Edition 6.2 Administration Guide.
Directory Service Control Center (DSCC). Is a graphical user interface that enables you to monitor directory operations in real time. DSCC provides general server information, including a resource summary, current resource usage, connection status, and global database cache information. It also provides general database information, such as the database type, status, and entry cache statistics. Cache information and information relative to each index file within the database is also provided. In addition, DSCC provides information relative to the connections and the operations performed on each chained suffix.
Replication monitoring tools. Include the command-line tools, repldisc, insync and entrycmp.
These tools enable you to do the following:
Monitor the state of synchronization between a master replica and one or more consumer replicas
Compare the same entry on two or more different replicas so that you can assess replication status
Depict your complete replication topology, which is particularly beneficial when dealing with complex directory deployments
You can also monitor replication status by using the DCC. For more information about monitoring replication, see Getting Replication Status in Sun Java System Directory Server Enterprise Edition 6.2 Administration Guide.
Simple Network Management Protocol (SNMP). Is the standard mechanism for global network control and monitoring, and enables network administrators to centralize network monitoring activity.
For information about monitoring using an SNMP agent, see Chapter 15, Directory Server Monitoring, in Sun Java System Directory Server Enterprise Edition 6.2 Administration Guide.
Java ES Monitoring Framework. Enables monitoring of performance and other statistics through JMX. For more information, see Directory Server and CMM/JMX in Sun Java System Directory Server Enterprise Edition 6.2 Reference.
Server activity such as resource usage, server status, and connection information
Database activity such as cache, transactions, locks, and log information
Disk status including available disk space and threshold information
Replication activity including status (whether or not replication is running), and the state of synchronization
Indexing efficiency including unindexed searches, search filters, and frequently used indexes
Security status including failed bind attempts, open connections, and effective rights
The Directory Editor component of Directory Server Enterprise Edition is a Java web application that enables you to manage directory data by using a web browser. Directory Editor provides all users with remote access to directory data without having to install any client software.
Directory Editor offers the following functionality:
Enables administrators and end users to create and edit directory users, groups, and containers.
Supports several concurrent users, depending on the application server and underlying hardware.
Supports large enterprise directory installations.
Enables customization, branding, and embedding of the interface.
Customization dynamically adapts to the Directory Server schema.
Enables customization through the configuration of forms, rather than by direct programming.
Supports SSL-encrypted transmissions between the client browser and Directory Server.
Limits access to menus and functions, based on roles.
Roles are scanned to match group names. Roles have access to certain capabilities, which are high-level actions such as Browse, Configure, Debug, Edit, Create, and Search.
Limits access to the data based on the existing ACIs in Directory Server. It is not necessary to define ACIs that are specific to Directory Editor.
Enables paged display of large volumes of data, based on the virtual list view (VLV) index.
For details on installing, configuring, and using Directory Editor, see the Directory Editor Documentation Collection.