Creating a Synchronous Shadow DSA

As mentioned in the section “Replication Services” in the chapter “Introducing DirX Directory” in the DirX Directory Introduction, asynchronous shadowing allows for complete flexibility with regard to defining the replication area, including attribute and object class selection, the type of updates performed, the update mode, and other aspects of configuration.The protocol supports high update operation rates, even at long distances between supplier and consumer DSA; however, if a supplier DSA outage occurs, recent update operations may be lost at consumer DSAs.

Recall from the chapter “Creating a Shadow DSA” that at the time of total update, the DSA replicates entries and their attributes starting with the context prefix or a subtree below it as specified in the shadowing agreement information.After the total update occurs, every update in the tree that matches the specific shadowing agreement information initiated via DAP, DSP or DISP is also replicated.Recall, too, that changes made via RPC are not replicated; this means that changes made with dirxadm, such as deletion, creation and modification of entries in the tree and changes to audit and database configuration are not replicated to consumer DSAs.

The following figure illustrates asynchronous shadowing protocol flow.In the example, the LDAP client is connected to DSA1.

As shown in the figure:

As you can see from this example, the LDAP client receives the result after the master DSA has committed the transaction but before the asynchronous shadow consumer DSAs have performed this operation locally. This principle is good for high update operation rates, but recent update operations can be lost at the asynchronous consumer DSAs if a master DSA outage occurs.

Synchronous shadowing is designed to replicate the complete DIT of a DirX Directory service to full shadow DSAs in a fast and efficient way. The underlying protocol is synchronous: a DAP or LDAP client receives the result of an update operation only after the master DSA and all of the synchronous consumer DSAs have committed it. Synchronous shadowing operates at a lower update operations rate than asynchronous shadowing in favor of synchronized data. The main advantages of synchronous replication are:

Synchronous shadowing agreement configuration offers fewer options than asynchronous shadowing:

Although synchronous shadow agreement configuration is limited, DirX-Directory-compliant asynchronous shadowing agreements like the samples discussed in the chapter “Creating the Shadow DSA” (the disp_type value in the –consumerkind option is CENTRALADMIN) and X.500-compliant shadowing agreements (the disp_type value in the –consumerkind option is X500) can co-exist in a shadowing configuration as long as different DSAs are affected and the REPLS subcomponent of the DirX-Directory-compliant/asynchronous shadowing agreement is always FALSE; that is, you can administer DirX-Directory-compliant/asynchronous shadowing agreements and X.500 shadowing agreements for consumer DSAs if they don’t participate in synchronous shadowing.

At the time of total update, the DSA replicates the complete DIT, starting with the root DSE, to all consumer DSAs that participate in synchronous shadowing. After the total update occurs, every update in the tree initiated via DAP, DSP and LDAP is also replicated. As with asynchronous shadowing, changes made via RPC are not replicated; this means that changes made with dirxadm, such as deletion, creation and modification of entries in the tree and changes to audit and database configuration are not replicated to consumer DSAs.

Synchronous shadowing has a much greater impact on performance than asynchronous shadowing does. Although the performance numbers given in this section are derived from an actual scenario, they serve only for discussion purposes and may not reflect performance numbers in your configuration.

First we’ll look at the response time for a typical modify operation measured at the DirX Directory LDAP server. When asynchronous shadowing is enabled (the disp_type value in the
–consumerkind option is CENTRALADMIN; see the dirxadm sob create operation in the DirX Directory Administration Reference for details), this time may take up to three (3) milliseconds (ms) and includes:

Independent of asynchronous consumer DSA performance, a subsequent modify operation will still take about three (3) milliseconds, except for some local performance fluctuations due to disk flushes and so on.

When synchronous shadowing is enabled (the disp_type value in the –consumerkind option is SYNCHRON; see the dirxadm sob create operation in the DirX Directory Administration Reference for details), the response time will be greater since the time for transmitting the incremental update PDU and receiving the result PDU to/from synchronous consumer DSAs is added plus the time for performing the modify operation at synchronous consumer DSA.Thus, response time increases up to six (6) milliseconds.

Another aspect is network latency, which depends on the distance between DSAs, installed network equipment and type of cable, among other items.For example, a fiber optic cable typically brings about 5 microseconds (µs) of latency per kilometer.For longer distances, this value may be even greater due to the deployment of amplifiers or regenerators.In our example, response time may increase up to eight (8) milliseconds (ms) or greater if the cable distance between DSAs is 200 kilometers (km).

Another interesting performance measure is the maximum possible update operations per second within a synchronous shadowing scenario.This number is influenced by many factors, such as system performance, network latency, PDU size and type of modification, and is thus impossible to predict exactly without knowing what these characteristics are.Performance is certainly not the reciprocal of response time, since multiple operations are processed simultaneously.However, you should take into account that the slowest consumer DSA at the greatest distance slows down update operation performance in synchronous shadowing scenario.

The DSA1 administrator creates the synchronous shadowing agreements for DSA2 and DSA3 on the supplier DSA1. Since synchronous shadowing is applied to these DSAs, their shadowing agreement configuration is as follows:

The following dirxadm command creates the synchronous shadowing agreement for DSA2:

The DSA1 administrator uses a similar dirxadm sob create to create the synchronous shadowing agreement for DSA3, specifying the consumer-specific data for DSA3 and an agreement identifier of 300.

Meanwhile, the DSA4 administrator in Boston must also create a shadowing agreement. This agreement is an asynchronous shadowing agreement that:

The following dirxadm command creates the asynchronous shadowing agreement for DSA4:

To perform a total update by media with synchronous shadowing, the DSA1 administrator:

An alternative method for performing a backup is to initiate an LDIF dump with the dirxadm ldif_dump command. In this scenario, the DSA1 administrator:

You can also perform the total update by media for multiple consumer DSAs in one sequence. In this scenario, the DSA1 administrator:

The procedure is the same when using an LDIF dump.

To restore an older dirxbackup archive, the administrator performs the following steps to synchronize the supplier DSA and the synchronous consumer DSAs:

Attribute index configurations are not inherited from master to consumer DSAs.As a result, the administrators of DSA1 through DSA4 must individually configure their DSA attribute indexes with the dirxadm db attrconfig command (see the dirxadm section in the DirX Directory Administration Reference for details).In this sample configuration, the Greater Munich administrators configure identical attribute index configurations for DSA1, DSA2 and DSA3 because these DSAs act as equivalent directory servers that handle the same kind of operation requests.The DSA4 administrator creates a different attribute index configuration for DSA4 that matches the workload expected from LDAP applications in Boston.

Recall from the section “How Data Synchronicity is Managed” that master and consumer DSAs keep a recent modification sequence number (recent MSN) operational attribute (in the entry /CN=DirXDBVersionSubentry). One way to determine whether data is synchronized between a master DSA and a synchronous consumer DSA is to compare the DSAs’ recent MSNs. Since the master DSA knows exactly what it has sent to the consumer DSA and what the consumer DSA has confirmed, you can easily evaluate the data status with dirxadm sob show commands at the master and consumer DSAs.

The following dirxadm command run on the master DSA1 shows the value of its recent MSN:

As you can see, the master’s Recent-MSN attribute has a value of 12346. The Sync-Status (this is the DirX Directory In Sync operational attribute described in the section “How Data Synchronicity is Managed”) at the master DSA is always TRUE.

The following dirxadm command run on the master DSA1 shows the values of the consumer DSA recent MSNs:

As you can see from this output, DSA2’s Recent-MSN attribute is 9875. Its Sync-Status (DirX Directory In Sync attribute) is also FALSE, which indicates that DSA2’s data is not synchronized with the master DSA because its Recent-MSN is different (and was caused by taking DSA2 off-line for a period of time). DSA3’s Recent-MSN value is the same as DSA1, because DSA3 remained online. DSA4 does not show a Recent-MSN value, because it is an asynchronous consumer DSA and thus does not maintain this attribute and the other synchronous shadowing attributes. Subsequent status checks of DSA2’s Recent-MSN attribute over time show that it increases and eventually reaches the same value as the master DSA1.

Recall from the section “How Data Synchronicity is Managed” that the entry /CN=DirXDBVersionSubentry and its operational attributes are administered by both master and synchronous consumer DSAs. Another way to check a consumer DSA’s data synchronicity status is to read this subentry and its attributes using dirxcp/DAP or dirxcp/LDAP operations. First, make sure you set the service controls that direct the DSA to perform the read operation locally, as shown in the dirxcp/DAP example below (in the dirxcp/LDAP example, the default LDAP server service control settings have already been considered). For more information about service controls, see the dirxcp args and ldapargs operations in the DirX Directory Administration Reference.

The following dirxcp/DAP commands read the entry /CN=DirXDBVersionSubentry from DSA2:

You can also display this subentry with the following dirxcp/LDAP command:

In the dirxcp/DAP output, the From-Entry attribute shows the value FALSE, which indicates that this entry comes from the consumer DSA. In the LDAP example, this fact is indicated by the (ChainedResult=no) comment. The DirX Directory Recent DN attribute (LDAP name dirxRecentDN) shows the DN of the last update operation. The DirX Directory Recent Operation attribute (LDAP name dirxRecentOperation) shows the type of request of the last update operation. Valid values are add, remove, modify and modifydn. The DirX Directory Recent MSN Time-Stamp attribute (LDAP name dirxRecentMSNTimeStamp) shows the modification time stamp of the last update operation. The DirX Directory Recent MSN attribute (LDAP name dirxRecentMSN) shows the modification sequence number of the last update operation. The DirX Directory In Sync attribute (LDAP name dirxInSync) of the consumer DSA shows the status of data synchronicity. The value is TRUE, which indicates that DSA2’s data is synchronized with the master DSA’s data.

Recall from the section “How Data Synchronicity Status Affects Read Operation Service Controls” that synchronous shadowing’s data synchronicity management overrides service controls for read and search operations in favor of accurate results.

In our example, DSA2’s data is not yet synchronized after the upgrade procedure, but DSA2 can perform read and search operations when it comes online. As long as DSA2’s data is out of sync with the master DSA1, it chains the read/search requests to the master DSA1. You can follow the changes in a consumer DSA’s synchronicity status with:

When a consumer DSA becomes unsynchronized with the master DSA, the following notice is reported in DSA logging:

When a consumer DSA becomes synchronized with the master DSA, the following notice is reported in DSA logging:

As you can see, the notices refer to an operational binding ID that is synonymous with the shadow agreement ID.The clear text message string gives the reason for the status change along with a simple explanation.

Synchronicity status changes are also reported in DSA audit records and via SNMPv2 traps, if these DirX Directory monitoring tools are enabled.See the chapter “Monitoring DirX Directory” for more information about these tools.

Switching supplier DSAs in a synchronous shadow configuration functions in much the same way as in an asynchronous shadow configuration: a non-emergency switch is performed when all of the DSAs participating in the synchronous shadow configuration are online and their agreements are not disabled.The synchronous master DSA propagates all outstanding incremental updates to all synchronous and asynchronous consumer DSAs.This procedure can take some time; for example, when a scheduled shadowing agreement to an asynchronous consumer DSA exists.

As an alternative, you can perform a sob synchronize command to propagate all outstanding incremental updates before you invoke the sob switch command.After all outstanding incremental updates have been propagated, the master DSA updates all shadowing agreements in the cooperating DSA table locally and then propagates the updated table to all consumer DSAs.As long as the non-emergency switch lasts, all update operations are rejected.

In our example, the administrator of master DSA1 needs to upgrade the DSA with the newest system and DirX Directory patches after the consumer DSAs have been upgraded.To provide an uninterruptible DirX Directory service while DSA1 is being upgraded, the administrator performs the following tasks:

A supplier DSA may fail for various reasons. An administrator may perform an emergency switch, depending on the reason for the failure. A crash of the dirxdsa or dirxldapv3 process does not require an emergency switch since a restart of the DirX Directory service typically lasts within the range of seconds. But a system crash or a network interruption may take a longer time and an emergency switch is recommended. In this case, the administrator can run a dirxadm sob switch –emergency command on one of the synchronous consumer DSAs. This command performs the following actions:

Once the old supplier DSA is online again, the new supplier DSA sends a total update if the maximum recovery time has not been exceeded. Please refer to the section "SOB-Policies" in the DirX Directory Syntaxes and Attributes for more information on this topic. If the maximum recovery time has been exceeded, the shadowing agreement to the old supplier DSA is disabled and the administrator should be enable it manually,

Under normal conditions, all synchronous consumer DSAs should have equal recent modification sequence numbers at the time of the emergency switch. However, it is possible that a synchronous consumer DSA’s data may be out of sync, as indicated by a difference in the recent modification sequence number when compared to the new supplier DSA. In this case, the supplier DSA automatically sends a total update to the relevant synchronous consumer DSA after the emergency switch.

Returning to our example, suppose that the master DSA1’s system crashes and that synchronous consumer DSA2’s data is still not in sync (DSA2’s dirxRecentMSN attribute should have a value of 9999, for example). An emergency switch at DSA2 is rejected, as shown in the following example:

On synchronous consumer DSA2, the following actions are performed:

After the emergency switch has completed, the new synchronous supplier DSA sends a total update to all synchronous consumer DSAs whose recent modification sequence number was different from the new supplier DSA’s at the time of the switch. In our example, DSA3 sends a total update to DSA2, since DSA2’s recent modification sequence number had a lesser value than that of DSA3.

The agreement to the old supplier DSA1 goes into the recovery state: the new supplier DSA3 tries to connect to DSA1 every 2 minutes. This time interval is specified in the RI=*recovery_interval component of the SOB-Policies attribute. If DSA2 can’t be connected to within the maximum number of retries (component *RMR), then DSA3 sets the agreement to the disabled state and won’t try any further connections. In this case, the administrator needs to enable the shadow agreement manually once DSA1 is online again.

Since the recent modification sequence number is not maintained at asynchronous consumer DSAs, the new supplier DSA can’t evaluate the data synchronicity status at emergency switch time. Thus, it is necessary to invoke a total update to asynchronous consumer DSAs manually to be sure that asynchronous consumer DSAs do not miss any updates due to the system crash on DSA1. A typical method to initiate a total update is to terminate and then establish an asynchronous shadowing agreement. If the asynchronous shadowing agreement is configured for total update by media, perform the following procedures:

In this example, the shadowing agreements to asynchronous consumer DSA4 are configured to perform a total update by protocol. Consequently, the administrator needs to terminate and establish agreements 400 and 410, as shown in the following dirxadm commands: