How to upgrade version of RHDS 10.0 to 10.3 in RHDS Multi Master Replication architecture

Latest response

In our infrastructure, we have a two RHDS servers with a Multi-Master Replication topology, we need to upgrade our Operating system (Rhel 7 to Rhel 7.6) and our RHDS servers (10.0.0 to 10.3.0) without loosing services,
so there are several point that we need to know, like :

  • How to upgrade RHDS server from 10.0.0 to 10.3.0 ?

  • what are the best practices for upgrading a multi-master RHDS topology ?

  • how to upgrade RHDS in a multi-master replication topology without service interuption ?

I’d be very grateful if you could help us in our upgrade.

Kind Regards.

Responses

Last question first: how to do it without service disruption. This depends heavily on how your LDAP servers are exposed to their clients. Are they behind a load balancer? (e.g. an F5 routing "ldap.example.com" traffic to either ldap1.example.com or ldap2.example.com). Are they using DNS round-robin (2 "A" records for "ldap.example.com", each pointing to a different server IP address)? Or do you rely on clients being configured with both LDAP server host names, and failing over when the first host is not available? (something like "ldap_host=ldap1.example.com, ldap2.example.com").

The first option is least disruptive - while you have one server down for maintenance, all traffic will be routed to the other server (you can manually disable the server under maintenance for extra safety & to allow time for testing). The second option can be OK, if you manually update DNS to only return the IP address of the working server while you upgrade and test the other one. The last option may also be OK, but will result in slight delays on the clients as they sometimes time out waiting for a connection to the server which is down for maintenance (it also does not allow time for testing/verification - as soon as the server is up, clients may connect again).

Next ... best practices. The installation Guide (https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/installation_guide/) is not quite clear on this, but the procedure in section 4.5 seems to be as simple as "setup-ds-admin.pl -u" (in addition to an unstated "yum update" to get the DS packages and the rest of the OS up to current patch levels). Chapter 5 appears to be focused on major version upgrades (RHDS 9.x, or older, to 10.x).

In my environment, we upgraded from RHDS 9.1->9.2, and later 10.2->10.3 via simple "yum update". We did not even bother with the "setup-ds-admin.pl -u" step - that really only seems to affect some metadata on the 'config' instance and the GUI console. The major version upgrades, such as 9.2 to 10.2, require completely reinstalling the server OS - although 10.x to 11.x might be different, based on changes in the RHEL 8 upgrade process.

A direct upgrade from 10.0 to 10.3 might be a little more risky (we do not have experience with skipping more than 1 minor update), but as long as you have a good backup of the server, you should be OK. I would recommend both a "hot" backup (LDIF export) and a "cold" backup (shut down dirsrv@(instance-name), run a conventional backup utility or copy the /etc/dirsrv/slapd-/ and /var/lib/slapd-/ data files) - then copy those backup files to an external server.

As long as you have one working server to re-replicate from, or a good backup to run an LDIF import from, you can recover from the most catastrophic failure fairly quickly - simply re-install the OS, re-install DS, and re-replicate or re-import the data (start to finish, this takes about 30 minutes in our environment, with 500k entries in the directory). Of course, practicing the procedure in a test environment first is always a good idea!

Hello,

In the beginning, I want to thank you for your response on the upgrade issue.

This said, we are now sadly facing a new troubling problem with siteminder (our policy store) after the upgrade of our RHDS servers to the 10.3.0 Version.

Actually, our infrastructure is composed of: - 1 RHDS Servers (Policy Store) : RHEL 7.6 with RHDS 10.3 - 1 Policy Server : RHEL 6.10 with SiteMinder 12.52.0104

The problem occurs when we want to start the smps SiteMinder service after upgrading the rhds servers (speacially after upgrading 389-ds-base and 389-ds-base-libs packages), The start of the smps SiteMinder service fails due to an error :

[Init][ERROR][sm-xadobj-00110] Create failed. (03-7bdf31f2-44d7-4d7b-a8f5-5de2eaa0b634, Object Not Unique)

[GetSmInterface][FATAL][sm-xpsxps-03570] SiteMinder interface initialization failed.

With these RHDS packages (389-ds-base-1.3.6.1-29 and 389-ds-base-libs-1.3.6.1-29) everything is OK. The moment we upgrade them to a newest version like (389-ds-base-1.3.7.5-18 and 389-ds-base-libs-1.3.7.5-18 OR 389-ds-base-1.3.8.4-23 and 389-ds-base-libs-1.3.8.4-23) the problem occurs.

I would be very grateful if you could help us resolving this issue.

Kind Regards.

Didier--

Please open a technical support case with Red Hat -- this is a community discussion area, not the official Red Hat support site (you should see a link at the very top of this page labelled "support cases" which goes to the site https://access.redhat.com/support/cases/ - that is the best way to resolve issues like this. You may also need to open a support case with the SiteMinder app vendor (CA?).

You may find more helpful information in the RHDS access & error logs in /var/log/slapd-[instanceName]/errors (note that this directory path is a configurable option, and may have been changed on your system). That file may include information like which specific object failing to be created (looks like SiteMinder is trying to create an object that already exists?).