Sun Directory Server Enterprise Edition 7.0 Deployment Planning Guide

Chapter 8 Identifying Administration and Monitoring Requirements

Directory Server Enterprise Edition administration has changed significantly since the 5.2 version of Directory Server. These changes are described in detail in the Sun Directory Server Enterprise Edition 7.0 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 Administration Model

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 this 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 also provides web interface to manage Directory Servers and Directory Proxy Server instances. 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.

Remote Administration

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 DSCC.

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 dsconf and dpconf utilities can be run remotely. For details of the functionality provided with dsconf and dpconf, see the dsconf(1M) and dpconf(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.

Figure 8–1 Directory Server Enterprise Edition Administration Model

Figure shows the new administration model, with administration
and configuration commands, and the Directory Control Center

Designing Backup and Restore Policies

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 Directory Server Enterprise Edition 7.0 Administration Guide.

This section provides an overview of what to consider when planning a backup and recovery strategy.

High-Level Backup and Recovery Principles

Apply the following high-level principles when designing a backup strategy:

Choosing a Backup Method

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

Binary backup produces a copy of the database files, and is performed at the filesystem 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:

Binary backup has the following advantages:

Binary backup has one limitation. Restoration from a binary backup can be performed only on a server with an identical configuration.

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.


Note –

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.

Figure 8–2 Offline Binary Backup

Offline binary backup of two servers to two separate
databases

For details on how to use the binary backup commands, see Binary Backup in Sun Directory Server Enterprise Edition 7.0 Administration Guide.

Backup to LDIF

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:


Note –

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 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).

Figure 8–3 Offline Backup to LDIF

Backup using dsadm export

For information about how to use the backup to LDIF commands, see Backing Up to LDIF in Sun Directory Server Enterprise Edition 7.0 Administration Guide.

Choosing a Restoration Method

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.

Binary Restore

Binary restore copies data at the database level. Binary restore is performed using one of the following commands:

Binary restore has the following advantages:

Binary restore has the following limitations:

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).

Figure 8–4 Offline Binary Restore

Binary restore from two separate databases to two separate
servers

Restoration From LDIF

Restoration from an LDIF file is performed at the suffix level. As such, this process takes longer than a binary restore. Restoration from LDIF can be performed using one of the following commands:

Restoration from an LDIF file has the following advantages:

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 Directory Server Enterprise Edition 7.0 Administration Guide.

In the following figure, dsadmin import is performed for each replicated suffix, on one master only (M1).

Figure 8–5 Offline Restoration From LDIF

Offline restore from and LDIF file, using dsadm import

Designing a Logging Strategy

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.

Defining Logging Policies

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:

You can manage the log files for both Directory Server and Directory Proxy Server in these ways:

Defining Log File Creation Policies

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:

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 Directory Server Enterprise Edition 7.0 Administration Guide.

Defining Log File Deletion Policies

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:

For details on how to set up a log file deletion policy, see Configuring Logs for Directory Server in Sun Directory Server Enterprise Edition 7.0 Administration Guide.

Manually Creating and Deleting Log Files

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 Directory Server Enterprise Edition 7.0 Administration Guide.

Defining Permissions on Log Files

In Directory Server 5.2, 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 Directory Server Enterprise Edition 7.0 Administration Guide.

Designing a Monitoring Strategy

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:

Monitoring Tools Provided With Directory Server Enterprise Edition

This section provides a summary of the monitoring tools that are available in Directory Server Enterprise Edition as well as additional tools that can be used to monitor server activity.

The monitoring areas described in Identifying Monitoring Areas can be monitored using one or more of these tools.

Identifying Monitoring Areas

What you monitor, and to what extent, depends on your specific deployment. In general, however, include the following elements in your monitoring strategy: