Updating LDAP configurations settings in a sysplex without server outage

This section describes updating configuration option settings for the LDAP servers that run in a sysplex without server outage. For example, you can update the serverCompatLevel configuration option to change supported functions.

In general, for those options that are not sysplex-related, you can change them and restart this specific server for changes to take effect, and the sysplex service is not impacted. However, you might want some sysplex level configuration changes such as:
  • Upgrade the server compatibility level.
  • Revert to an earlier version of the server compatibility level.
  • Add new backends.
  • Remove existing backends. This does not include SDBM, which is not sysplex-related

To ensure that the entire sysplex is able to handle LDAP requests during the update, a new server needs to be started in transition mode. For more information about how to start a server in transition mode, see Setting up and running the LDAP server. For the convenience of description, the server that is running in transition mode is called a transition server. The entire task when you update the configuration options setting in a sysplex is called transition work. The transition server that is running in transition mode is in a special intermediate state to handle the LDAP requests while other LDAP servers in the sysplex group are having updates done to their configurations. The transition server is restored to normal work mode after the entire sysplex update completes.

The steps to take are:
  1. Back up your database files.
  2. Prepare the new configuration file that contains the new setting of the options you want to update.
  3. Start a new LDAP server in transition mode as the transition server with the updated configuration file. You can also shut down an existing LDAP server of the sysplex and restart it as the transition server. For the transition server, the serverCompatLevel configuration option must be set even if you want to upgrade the backends with the same compatibility level as before. The current setting can be found in the startup messages of the sysplex owner.

    The transition server starts with the old serverCompatLevel and does not apply the new serverCompatLevel until it becomes the sysplex owner, but the new backend configurations take effect immediately. The transition server cannot process requests for the removed backends. The other servers cannot process requests for the new backends until they are restarted with the new backends defined in the configuration. Therefore, do not initiate any LDAP requests that target the updated backends until transition completes.

  4. Shut down the non-owner servers first, and then the current sysplex owner server to avoid unnecessary owner switching. The transition server then becomes owner and begins processing requests by using the new serverCompatLevel and backend configurations.
  5. Start other servers with updated configurations.
  6. Shut down the transition server, or restart it in normal (non-transitional) mode and transition completes.
Notes:
  1. Select the time with the least number of client requests that are handled by the LDAP server to do sysplex level updates.
  2. The prerequisite to do transition work is that all servers in the target sysplex group are to be run with z/OS® Version 2 Release 2 or higher, including the transition server itself and compatibility level of 4 or higher. If not, you must upgrade to the appropriate z/OS release and compatibility level first.
  3. If you want to undo the transition or lower the server compatibility level, any DIT-related updates that result from the compatibility level upgrade must be undone manually.
  4. If the transition involves removing backends from the configuration, any LDAP request for the eliminated backends fails if it is directed into the transition server before the transition server becomes the owner. Also, it fails no matter which server it is directed to when the transition completes. If any error occurs during the transition, the transition server terminates, and is an LDAP service outage.
  5. If any error occurs during the transition, the transition server ends and an LDAP service outage occurs.
  6. ARM is not enabled after the transition completes, even though it was enabled before the transition.
  7. Not all configuration options support sysplex level updates without outages. The transition server is not able to join the current sysplex group when the following options are updated:
    • schemaPath
    • serverName
    • serverSysplexGroup
    Notes:
    • The schemaPath must be set with the same value within the whole sysplex.
    • The serverName must be the same for all TDBM and Db2®-based GDBM backends.
  8. Because changing the suffixes (except TDBM), the database path or dbuserid for the existing backends are not supported for the transition. The transition server fails to start if any change is detected for an existing backend name. If you want to remove one or more backends and add new backends, do not reuse the backend names of any that are removed.
  9. If advanced replication is defined, examine each replication queue to ensure many pending changes are not awaiting replication. To avoid a long time of transition, commit the pending changes and clean up the replication queue before starting to use the transition mode.
  10. If the transition involves removing backends from the configuration, make sure that there are no replication topologies that are related to the backends that are removed. Otherwise, delete the corresponding replication topologies first.

    If you remove replication topology entries under the cn=localhost suffix such that this suffix is no longer needed, and the suffix is in an LDBM backend that is not being removed, you cannot remove the suffix from the configuration in transition mode. To remove a suffix from an LDBM backend, all servers in the target sysplex group must be taken down simultaneously.