| Oracle® Fusion Middleware Deployment Planning Guide for Oracle Directory Server Enterprise Edition 11g Release 1 (11.1.1.7.0) Part Number E28974-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Fusion Middleware Deployment Planning Guide for Oracle Directory Server Enterprise Edition 11g Release 1 (11.1.1.7.0) Part Number E28974-01 |
|
|
PDF · Mobi · ePub |
This chapter provides an overview of the administrative decisions that you must make in the planning phase of your Oracle Directory Server Enterprise Edition (ODSEE) deployment:
The ODSEE administration model leverages command-line utilites, a console known as the Directory Service Control Center (DSCC), and a DSCC agent which enables remote administration. An administrator in this model controls server instance creation and server management.
The dsadm and dsconf command-line utilties provide all the functionality, and more, supplied by the directoryserver utility in 5.x releases of Directory Server Enterprise Edition.
The dsadm utility enables the administrator to create, start, and stop a Directory Server instance. The dsadm command combines all operations that require file system access to the Directory Server instance. The dsadm command must be run on the machine that hosts the instance. The dsadm utility does not perform any operation that requires LDAP access to the instance or access to an agent.
In contrast to pre-6.0 DSEE releases, in the current administration model, a Directory Server instance is not tied to a ServerRoot. Each Directory Server instance can reside within its own filesystem location or path.
The dsconf utility combines the administration operations that require write access to cn=config. The dsconf utility is an LDAP client. It can only be executed on an active Directory Server instance. The dsconf 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.
The Directory Service Control Center is a web interface for managing Directory Servers and Directory Proxy Server instances. Three components comprise the DSCC:
DSCC web interface 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. See the Administrator's Guide for Oracle Directory Server Enterprise Edition for information about accessing the DSCC, and for information about DSCC administrators.
The DSCC is a web application (WAR file) which you must deploy into a supported web or application server. See the Installation Guide for Oracle Directory Server Enterprise Edition for detailed installation instructions.
The DSCC agent is a daemon that allows DSCC to run dsadm and dpadm commands on server hosts so that DSCC can do the following:
Create server instances
Start server instances
View server instance logs
Manage server instance certificates
Each time you install ODSEE on a server host, you can create a DSCC agent to manage from DSCC server instances on this host.
The DSCC agent can manage only server instances that belong to the same user as its owner. You can create multiple DSCC agents to manage server instances owned by different users.
By default, the DSCC agent runs on port 3997.
The DSCC registry, also known as the ads, is a private Directory Server instance that is automatically created when you use the dsccsetup ads-create command. The sole purpose of the DSCC registry is to hold registry data for all managed Directory Server instances and Directory Proxy Server instances.
Each time you install a server host, you must register its DSCC agents in the DSCC registry. You must also add to the DSCC registry all Directory Server or Directory Proxy Server instances that are managed by the DSCC Agents.
Once registration is complete, you can then use DSCC to manage the registered Directory Server or Directory Proxy Server instances. The DSCC agents securely manage the creation, deletion and pre-runtime configuration of Directory Server and Directory Proxy Server instances installed on the server hosts.
Configuration for registered Directory Server and Directory Proxy Server instances remains within the instances themselves, not in the DSCC registry. Configuration is read through the listening LDAP port.
The DSCC web application polls registered Directory Server and Directory Proxy Servers at run time. When the web interface is in use, and the administrative user navigates through the UI, the web application directly queries the managed hosts and updates the DSCC web pages with needed configuration and status information.
During Directory Server or Directory Proxy Server instance registration, the server instance is configured to allow DSCC administrators read/write access to the server configuration.
For Directory Server instances, ACIs are created and the pass-through authentication plugin is enabled. For any administrative Bind DNs containing cn=dscc, the plug-in re-directs authentication back to the DSCC registry.
For Directory Proxy Server instances, a specific connection handler for DSCC administrators is created, and dccAdminSuffix is set to cn=Administrators,cn=dscc.
If the DSCC registry is offline, DSCC administrative users can not access or manage the Directory Server instance. However, you can still manage Directory Server and Directory Proxy Server Manager accounts which are local to the server configuration.
The Directory Server Enterprise Edition administration model enables you to remotely manage any Directory Server or Directory Proxy Server in the topology. You can manager servers 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 and dpadm man pages.
The dsconf and dpconf utilities can be run remotely. For details of the functionality provided with dsconf and dpconf, see the dsconf and dpconf man pages.
The following figure illustrates how the new administration model facilitates remote administration. In the figure, DSCC and configuration commands (dsconf and dpconfig) are installed and run remotely from the Directory Server and Directory Proxy Server instances. The administration commands must be run locally to the instances.
When you log into the DSCC, you provide your administrative credentials, and DSCC delegates authentication to the DSCC registry. Once authenticated, you can manage registered servers using LDAP communication.
For specific operations that require the use of dsadm or dpadm, you must connect to the server using the DSCC agent. So to start a Directory Server instance, for example, you provide your DSCC administrative credentials. Then Directory Server uses the DSCC agent to delegate authentication to the DSCC registry using the same administrative credentials. (You no longer provide OS-based credentials in addition to the administrative credentials you provide to authenticate to the DSCC registry.)
One DSCC Agent can manage multiple Directory Servers, but only if the Directory Servers are all managed by the same user. If you need multiple server instances running as different users, then you must install and run multiple DSCC agent 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, see Chapter 8, Directory Server Backup and Restore, in Administrator's Guide for Oracle Directory Server Enterprise Edition.
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
Configuration files
Log files and the change log database
Schema files
User data
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.
A general recommendation is that you keep both. For more information, see Choosing a Backup Method and Choosing a Restoration Method.
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 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:
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.
Note:
Binary backup has one limitation. Restoration from a binary backup can be performed only on a server with an identical configuration. For more information, see Restrictions for Using Binary Copy With Replication in Administrator's Guide for Oracle Directory Server Enterprise Edition.
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:
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 Administrator's Guide for Oracle Directory Server Enterprise Edition.
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.
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 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 Administrator's Guide for Oracle Directory Server Enterprise Edition.
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 copies data at the database level. Binary restore is performed using one of the following commands:
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 Administrator's Guide for Oracle Directory Server Enterprise Edition.
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).
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:
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 Administrator's Guide for Oracle Directory Server Enterprise Edition.
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:
Access log. Lists the clients that connect to the server and the operations requested.
Error log. Provides information about server errors.
Audit log. Gives details about modifications to suffixes and to the configuration.
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 Administrator's Guide for Oracle Directory Server Enterprise Edition.
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 Administrator's Guide for Oracle Directory Server Enterprise Edition.
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 Administrator's Guide for Oracle Directory Server Enterprise Edition.
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 Administrator's Guide for Oracle Directory Server Enterprise Edition.
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.
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.
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. For information about viewing and configuring log files, see Chapter 14, Directory Server Logging, in Administrator's Guide for Oracle Directory Server Enterprise Edition.
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
For more information, see repldisc, insync and entrycmp.
You can also monitor replication status by using the DSCC. For more information about monitoring replication, see Getting Replication Status in Administrator's Guide for Oracle Directory Server Enterprise Edition.
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 Administrator's Guide for Oracle Directory Server Enterprise Edition.
What you monitor, and to what extent, depends on your specific deployment. In general, however, include the following elements in your monitoring strategy:
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
|
 Copyright © 2001, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
