Sun Java System Directory Server Enterprise Edition 6.0 Evaluation Guide

Chapter 4 High Data Availability and Integrity

This chapter describes the Directory Server Enterprise Edition features that provide high data availability and integrity. This chapter covers the following topics:

Robust Replication

Directory Server provides a robust replication mechanism, including the following features:

Unlimited Masters for Replication

In a multimaster replication environment, data is updated on multiple masters. Each master maintains a change log, and the changes made on each master are replicated to the other servers. Each master plays the role of supplier and consumer. Directory Server removes previous limits on the number of masters, allowing your multimaster replication topology to include an unlimited number of masters in multiple data centers.

You can also configure your replication topology to contain only masters, eliminating the need to route operations to consumers and simplifying your overall deployment.

Prioritized Replication

Directory Server allows you to prioritize updates for replication. Priority is a boolean feature and is on or off. You can prioritize replication according to the following parameters:

The priority rules are configured on each master replica. The master can replicate an update to one or more hubs or consumer replicas. The priority of the update is then cascaded across all of the hubs and consumer replicas. If one parameter is configured for prioritized replication, all updates that have that parameter are prioritized for replication. If multiple parameters are configured for prioritized replication, only updates that match all parameters are prioritized for replication.

See Replication Priority in Sun Java System Directory Server Enterprise Edition 6.0 Administration Guide for instructions on configuring prioritized replication using command-line tools.

Globally Synchronized Replication Using the Retro Changelog

The retro changelog receives updates from all master replicas in the topology. The updates from each master replica are combined in the retro changelog. The retro changelog provides a way for applications to track changes so that they can be synchronized. Directory Server enables you to access a coherent version of the retro changelog on any master in a multimaster topology. You can also update your application to manage its state according to change numbers. This makes it possible to fail over between retro changelogs on different servers.

The global retro changelog contains all of the changes. If two changes occur on the same entry in two different locations, the retro changelog provides an ordered change description. If you query the retro changelog from any server, it will contain similar information.

See Replication and the Retro Change Log Plug-In in Sun Java System Directory Server Enterprise Edition 6.0 Reference for background information about the retro changelog.

Replicated Account Lockout Attributes

Directory Server replicates account lockout data that is stored when a client application fails to authenticate to the server. You can use this feature with the Directory Proxy Server capability to route binds appropriately. Together, these features provide global account lockout. Global account lockout prevents a client application from gaining more than a specified number of login attempts across an entire directory service topology.

See Preventing Authentication by Using Global Account Lockout in Sun Java System Directory Server Enterprise Edition 6.0 Deployment Planning Guide for an overview of the topic.

Monitoring Replication Convergence

Directory Server quickly calculates the number of pending replication changes using the ds5ReplicaPendingChangesCount attribute. Directory Server finds the oldest change that the consumer is aware of and can compare it with the other servers, making it possible to calculate the replication delay. From this change, the consumer can also browse the list of changes until the most recent change, and count the number of changes that need to be applied.

Moreover, this attribute can be queried with virtually no impact to Directory Server performance, regardless of how large the change log grows.

In the Directory Service Control Center, you can view a summary of all the pending changes for a given suffix .In the Suffixes tab, the pending changes are in the Missing Changes column, as shown in the following figure.

Illustration of the Suffixes tab in the Directory Service Control Center.

Importing Many Entries to Large Replicated Suffixes

Directory Server provides a mechanism for adding new entries to an existing database. This import process checks if a given entry already exists so that data is not overwritten. This feature allows you to import an LDIF file in multiple passes at different times. Successive imports do not delete what already exists in the database.

For more information about importing entries to large replicated suffixes, see Incrementally Adding Many Entries to Large Replicated Suffixes in Sun Java System Directory Server Enterprise Edition 6.0 Administration Guide.

Synchronized Backup and Export

All offline and online backup methods can be invoked in the CLI by using dsadm or dsconf. The default behavior forthese commands is to operate in synchronous mode. The commands do not return a completion code until the task is complete. The commands also offer an asynchronous mode, by setting the -a flag.

Online Binary Backup

You can perform an online binary backup with dsconf or by using the Directory Service Control Center (DSCC).

For example, to back up master sA1 and store the resulting binary backup in the /install-path/sA1-bak directory, run the following command:

$ dsconf backup -p 20390 /install-path/sA1-bak

Use the -a or --async option to start a backup task that returns immediately.

Online LDIF Export

You can perform an online LDIF export using the command line or using the DSCC. For example, use the following command to export to a file called export.ldif:

$ dsconf export -p 20390 "dc=example,dc=com" /install-path/export.ldif
Beginning export of 'example'
example: Processed 8 entries (100%).
Export finished.

Task completed (slapd exit code: 0).

Offline Binary Backup

The following command performs an offline binary backup:

$ dsadm backup  /install-path/sA1 /install-path/sA1-bak
[28/Oct/2006:23:38:13 -0500] - Backup starting (/install-path/sA1-bak)
[28/Oct/2006:23:38:13 -0500] - WARNING<20509> - Backend Database - conn=-1 op=-1 msgId=-1 -  
  Cannot create new directory /install-path/sA1-bak/dsA1 (-5943) Cannot create or rename a filename that already exists.
[28/Oct/2006:23:38:13 -0500] - Backing up file 1 (/install-path/sA1-bak/dsA1/dsA1_objectclass.db3)
[28/Oct/2006:23:38:13 -0500] - Backing up file 2 (/install-path/sA1-bak/dsA1/dsA1_id2entry.db3)
  [28/Oct/2005:23:38:13 -0500] - Backup completed (/install-path/sA1-bak)

Offline LDIF Export

The following command performs an offline LDIF export:

$ dsadm export /install-path/sA1 "dc=example,dc=com" /install-path/export.ldif
Exporting data...
[28/Oct/2005:23:37:46 -0500] - DEBUG - conn=-1 op=-1 msgId=-1 -  Backend Instance: dsA1
ldiffile: /install-path/export.ldif
[28/Oct/2005:23:37:46 -0500] - export dsA1: Processed 8 entries (100%).

Binary Restore Methods

The dsadm and dsconf commands can also be used to restore data. The commands are used the same way as for backups except that the commands passed are dsadm restore and dsconf restore.

File System Snapshot of Frozen Database

Directory Server provides a configurable feature that enables you to stop database updates on disk so that a file system snapshot can be taken safely.

When frozen mode is set, all configured databases are taken offline. Any internal operations in progress are notified of the database going offline. LDAP operations in progress are completed, and the database environment is flushed. Subsequent incoming operations are refused until the server property is reset to read-write or read-only. In a single server topology, operations received when frozen mode is on result in an LDAP error being returned.

The standard error message for database offline is logged. In a replicated topology, a referral is returned. For this feature to work correctly, no other tasks should be running on the databases. When the operation to turn frozen mode on has returned LDAP_SUCCESS (0), it is safe to take the file system snapshot.

See Backing Up a File System in Sun Java System Directory Server Enterprise Edition 6.0 Administration Guide for instructions on configuring frozen mode using command-line tools.

Changing Attributes While the Server Is Online

In previous versions of Directory Server, attributes such as the all IDs threshold required the server to be offline when the attribute value was changed. You can now change the values of such attributes while the instance is online.

    Although the value can be changed online, changes for some attributes might not take effect until after the instance has been restarted. In addition, some changes require manual intervention before restarting. For example, you can change the path to the data directory with the server online, but before the change takes effect, you need to do the following:

  1. Stop the instance.

  2. Ensure that the new directory exists and has the correct permissions.

  3. Move the data from its present location to the new location.

  4. Restart the instance.

The following sections describe the changes that can now be made with the server online.

Changing the All IDs Threshold

You can change the global and index-specific values of the all IDs threshold with the server online. The change does not take effect until the affected indexes are re-indexed or the data is re-initialized.

For example, on the command line, you can change the global all IDs threshold by running the following command:


# dsconf set-server-prop -p 20390 all-ids-threshold:2000

Changing the Database Path

You can change the database path attribute while the server is online. After you have changed the path, you then need to stop the server, move the database files, and start the server.

The database path attributes include nsslapd-db-home-directory, nsslapd-db-logdirectory, and nsslapd-directory. These attributes correspond to the dsconf command properties db-env-path, db-log-path, and db-path, respectively.

For example, to change the location of the example backend database, do the following:


# /opt/sun/install-path/bin/dsconf set-suffix-prop -p 20390 "dc=example,dc=com" \
db-path:/install-path/dbtst
Changing "db-path" does not move the database file automatically.
You will have to stop the server, move the database files and restart the server.
Do you want to continue [y/n] ? y
Directory Server needs to be restarted for changes to take effect
# mv /install-path/sA1/db/example /install-path/dbtst
# /opt/sun/install-path/bin/dsadm start /install-path/sA1
Server started: pid=29050

Attribute Syntax Validation on Update

Every attribute defined in the server's schema has a syntax associated with it. The syntax defines the kind of information that is expected to be held in the attribute so that the server can perform the appropriate kinds of matching against it. The syntax definition also allows the server to properly index the values so that searches against it can be processed quickly.

Directory Server Enterprise Edition introduces a configurable option, check-syntax-enabled, set by using the dsconf command, to ensure that updated attributes adhere to the syntax definitions. Attribute values are rejected when they violate the syntax definitions. For example, when syntax checking is on, if a user tries to update an attribute with an integer syntax to include a non-numeric value, the update will be rejected.

By default, syntax checking is off. When syntax checking is on, all import and update operations are checked.

Schema Validation by Directory Proxy Server

Directory Proxy Server provides schema validation to ensure that only the allowed data is permitted on write operations. For example, when entries are aggregated using the virtual directory functionality, the aggregate entries might not match the schema of any of the backend servers participating in the entry aggregation. In this case, schema checking can occur on the Directory Proxy Server using a virtual schema.

When schema checking is enabled, Directory Proxy Server retrieves schema available in the cn=schema suffix and uses it to do schema checking. You can define the LDIF data view holding the cn=schema suffix. The content of the cn=schema suffix can point to an LDAP server or to a schema stored in an LDIF file local to the Directory Proxy Server.

Where to Go From Here

To read more about the features presented in this chapter, refer to the following documentation.

Feature

Documentation

Designing a highly available deployment 

Chapter 12, Designing a Highly Available Deployment, in Sun Java System Directory Server Enterprise Edition 6.0 Deployment Planning Guide

Backing up and restoring directory data 

Chapter 8, Directory Server Backup and Restore, in Sun Java System Directory Server Enterprise Edition 6.0 Administration Guide

Using a global retro changelog 

Replication and the Retro Change Log Plug-In in Sun Java System Directory Server Enterprise Edition 6.0 Reference

Using global account lockout 

Preventing Authentication by Using Global Account Lockout in Sun Java System Directory Server Enterprise Edition 6.0 Deployment Planning Guide

Making a file system snapshot when the database is in frozen mode 

Backing Up a File System in Sun Java System Directory Server Enterprise Edition 6.0 Administration Guide

Checking valid attribute syntax on update 

Checking Valid Attribute Syntax in Sun Java System Directory Server Enterprise Edition 6.0 Administration Guide

For a hands-on demonstration of the features described in this chapter, use the scripts provided with the Evaluation Kit. The following table lists the scripts available to demonstrate each feature.

Feature

Evaluation Script

Synchronizing replicas in a multimaster environment, even under a heavy load 

Demo_Replication_Sync.sh

Backing up, recovering, exporting, and importing data 

Demo_Backup_Strategies.sh

Creating a file system snapshot when the database is in frozen mode 

Demo_Frozen_Mode.sh

Changing the all IDs threshold while the server is online 

Demo_AllIDsThreshold.sh

Changing the backend database of a directory server instance while the server is online 

Demo_Changing_DB_Dir.sh

Enabling and using Directory Proxy Server schema checking  

Demo_DPS_Schema_Checking.sh