Key-Manager-Server Migration

The high-level steps for migrating Key Manager Servers (front ends and back ends) involves:

1. Setting up new Key Manager Servers on RHEL 8.

2. Verifying that the new Key Manager Servers work as intended.

3. Removing the old Key Manager Servers on RHEL 7.

You can migrate Key Manager Servers as follows:

1. Note the unique IDs of your servers that are to be decommissioned at the end of the migration process. This can be done using the command-line client:

   $ /opt/sshmgr/bin/ssh-mgr-client list-mgmt-servers -H -C \
   fqdn,frontend,backend,tags,uniqueid
   
   fqdn,frontend,backend,tags,uniqueid
   ukm-fe.example.com,True,False,,cOV3ySRtWGr3oymmuHhu
   ukm-be.example.com,False,True,,cJc9XYDW85f4QrLCoKBy

   These IDs are later required for decommissioning old Key Manager Servers.

2. On the newly-provisioned hosts, set up Key Manager using the RPM installation package (as described in Installation Manuals). Make sure to install the same version used in your current deployment.

3. Join the new Key Manager Servers to your deployment. Now you should have the new Key Manager Servers (on RHEL 8) running alongside the old ones (on RHEL 7).

4. In order to validate that the new back-end servers perform satisfactorily, deactivate the old instances (on RHEL 7) by setting their Maximum processes setting to 0. Do this for each individual back-end server that needs to be deactivated:

   a. In the Key Manager GUI, go to Settings→Management Servers, then click the Settings action of the server.

   b. Set Maximum processes to 0. Click the associated Set for Server to apply your changes.

   You may then verify that the newly-created instances are preforming tasks as expected: jobs are being picked up, periodic jobs are executed per schedule, etc.

   note

   If you encounter issues with the new back-end servers, the old ones can be returned to service immediately by setting the Maximum process back to their previous values.

   It is important to deactivate the old back-end servers, since depending on various factors such as the size of the setup, database performance, etc., having a large number of active back-end servers may lead to degradation of service: The database may experience contention due to too many back ends competing for waiting tasks. This may results in increased time before a back end picks up a job from the queue (even when back ends are mostly idle).

5. Next, ensure that the new front ends perform as expected. Verify that CLI/APIv3 calls are successfully executed when requests are sent to the new front-end servers. You can use IP addresses if no FQDNs are configured at this point.

6. If you want to retain your existing FQDNs for your new servers, update the necessary DNS entries to point to your newly provisioned PKM servers.

7. If you are using User Portal, check the User Portal API-connection settings. If you have configured Key Manager’s FQDN and you have chosen to retain the old FQDNs with the newly provisioned servers, no further action is necessary.

   Verify that the User Portal service performs as expected. If User Portal is configured to connect to Key Manager by IP, or if you have chosen to assign new FQDN addresses to your new Key Manager Servers, you may need to update the API Connection address in User Portal settings, and then verify that User portal works as expected.

8. After you have verified that the new Key Manager servers work as expected, remove the old ones from your Key Manager deployment.

   To remove a Key Manager Server using the command-line client (replace <unique-id> with the ID of an old Key Manager Server, repeat for each ID):

   $ /opt/sshmgr/bin/ssh-mgr-controller --delete-server=<unique-id>

   At this point, the old servers are no longer part of the Key Manager deployment and may be decommissioned.