Windchill Directory Server (WindchillDS) supports replication. Two or more instances of WindchillDS could be configured to contain the same data and replicate changes to other servers in the replication configuration.

Before starting the WindchillDS replication, perform the following steps:

WindchillDS replication uses a multi-master replication model. That is, directory servers participating in replication can fully respond to LDAP requests that modify directory content as well as LDAP requests that query directory content. A change made on one server will appear, almost immediately, on the other servers.

Replication can be used to provide a basis for high availability. If an LDAP server on one system fails, Windchill can be quickly reconfigured to use an alternate server with no loss of data. Alternatively, a load balancer can be used in front of the directory servers so that failover can occur automatically in the event of an LDAP server failure.

Replication can also aide backup. However, it should never replace consistent use of the recommended daily backups and weekly exports. If all servers in a replication configuration have the same baseDNs, and if all baseDNs are being replicated, then a backup needs to be taken on only one server in the replication configuration. If backup is being performed on only one server, the backup (and exports) should be taken consistently from the same server. If the primary server to which Windchill is connected is expected to be heavily loaded, backups and exports could be generated on a different server in the replication configuration. However, the overhead to generate backups and export files should be small, and it is recommended that you generate backups and exports on all servers.

The following image illustrates the use of two instances of the WindchillDS set up to replicate data between installations on two different hosts. As the diagram shows, the WindchillDS can be configured to include both an embedded LDAP server to respond to LDAP requests and an embedded Replication Server to manage replication and exchange data with other replication servers.

The LDAP Server sends all changes it receives to the included Replication Server. The Replication Server, in turn, sends all such changes it receives on to all other Replication Servers. When a Replication Server receives a change from another Replication Server, it forwards the change to the associated LDAP server, but not on to the other Replication Servers. This ensures that all changes are propagated correctly without too much protocol overhead.

As an LDAP server receives replicated changes, the changes are applied to the local database. So, all servers contain about the same data at any point in time. And, all LDAP servers will contain the same data and thus be considered synchronized if LDAP changes stop occurring and all outstanding changes have been replicated and applied to all servers. Normally changes are replicated and applied very promptly, so all directories will appear to be synchronized almost all the time.

More complex replication configurations are possible than the two-host example above.

The following image shows a possible replication configuration between two geographically separated locations.

The following configurations, while possible, are not supported or recommended due to their complexity and the performance issues they may cause.

Replication is configured per baseDN. The examples shown later illustrate configuration for just a single baseDN: o=ptc. If you have multiple baseDNs and you want them to be replicated, you will need to repeat the sample steps for each baseDN.

The following is an overview of the steps involved in setting up replication.

For the two-host configuration, only two commands are needed to enable replication and synchronize data. Both servers must be running before entering these commands. If you have an existing server with data, that server must be identified as the hostSource and portSource in the initialize command. The following assumes that the two servers will be on different hosts, and:

You must modify the baseDN value (o=ptc in this example), hosts, passwords, and, possibly ports to make the following appropriate for your configuration:

For the four-host configuration, four commands are needed to enable replication and synchronize data. All four servers must be running before entering these commands. If you have an existing server with data, that server must be identified as the hostSource and portSource in the initialize command. The following assumes all servers are on different hosts, and:

You must modify the baseDN value (o=ptc in this example), hosts, passwords, and, possibly ports to make the following appropriate for your configuration:

In typical Windchill installations, most LDAP requests that modify LDAP data will be directed at a particular WindchillDS. In such a configuration, replication conflicts should not occur, or be very unlikely to occur. However, it may be useful to understand more about replication conflicts so you can recognize conflicts if they do occur.

A replication conflict can occur in a replication configuration if changes are made at about the same time on two or more servers and the changes are not compatible, or involve the same entry or set of entries. These are examples of possibly conflicting changes:

There are two types of replication conflicts: modify conflicts and naming conflicts. Modify conflicts occur when conflicting LDAP modify requests are made to two different servers at about the same time. Naming conflicts are those in which at least one of the conflicting changes is an LDAP request other than an LDAP modify request. The first conflict in the list above is a modify conflict and the other two are naming conflicts.

A replication conflict is detected as conflicting changes are replicated and applied on the local server. When a replication conflict is detected, WindchillDS attempts to automatically resolve the conflict in a logical way. Modify conflicts are relatively simple to resolve, and the resolution is performed in an intuitive way. In general, modify conflicts will be resolved based on the order in time in which the change occurred. For this to work properly, of course, system clock settings must be accurate.

If, for example, an attribute is deleted from an entry on one server, and immediately thereafter a value is added to the same attribute on another server, the final result will be the same as if the first change and then the second happened on the same server and in that order. In this example, the final result will be that the attribute will have only the value added on the second server. If the timing of the two changes is reversed, the final result will be that the attribute is deleted from the entry.

Naming conflicts, however, can be much more complex and are more difficult to resolve. In all cases, WindchillDS will resolve the naming conflict. However, in some cases, the likelihood of an incorrect resolution may be high and after resolving the conflict it saves the losing entries involved in the conflict. This allows later recovery by an administrator, if appropriate.

As one simple example, suppose two entries with different content, but the same DN are added at about the same time to two different servers. When the conflict is detected, the entry added first will be retained, and the entry added second will be saved and given a name based on the entry’s UUID. The DN of such an entry might look like this:entryuuid=6c6ac8ba-80ca-4ffd-9b83-4e63954078e7+o=conflict,o=ptc

In the event a server is down or failed, there are different recovery actions needed depending on the type of failure:

The following are some of the administrative actions you may perform when administering your WindchillDS Replication.

If you want to disable replication, you must perform these steps on each server:

You might want to occasionally search for conflict entries left over from resolving naming conflicts. To do so, enter a subtree search request looking for entries that have the attribute ds-sync-conflict. This would be a search filter of (ds-syncconflict=*). Such entries could be helpful if a naming conflict is resolved in an unexpected way. However, the best choice is probably to simply delete such entries.

You can monitor replication by using the following:

To replicate WindcillDS, perform the following steps: