Cloud Pak for Business Automation

 View Only

Migrating IBM Cloud Pak for Business Automation 22.0.2 to New Clusters: A Comprehensive Guide

By Michal Pristas posted 15 days ago

  

As platform architects for IBM Cloud Pak for Business Automation (CP4BA) 22.0.2, we recently undertook the challenge of migrating our CP4BA deployments to new, faster VPC clusters. This migration was necessitated by our need to upgrade to version 23.0.1 and beyond, which was blocked due to our initial cluster scope common services installation. Without an official migration guide in the CP4BA documentation, we developed a custom procedure to ensure a smooth transition.

In this blog, I will outline the steps we took to successfully migrate our CP4BA deployments. This guide aims to assist other platform architects and provide insights for the product team to potentially incorporate into the official documentation.

1. Preparing for Migration: Disaster Recovery

The first crucial step was to follow the disaster recovery procedure as outlined in the official documentation. This involved two main tasks:

1.1 Backup Namespace Using IBM Storage Fusion

We used IBM Storage Fusion to back up the namespace. Detailed steps for this process can be found here.

1.2 Backup Selected Secrets

We identified and backed up the necessary secrets as per the documentation. A thorough backup of the database was also performed to safeguard against potential data loss during migration. Here you can find details about secrets that needs to be backed up.

  • Export each secret using kubectl get secret <secret-name> -n <namespace> -o yaml > <secret-name>.yaml.

2. Setting Up the New Cluster

With the backups in place, we proceeded to set up the new cluster.

2.1 Install IBM Storage Fusion as a Spoke

  • Install IBM Storage Fusion on the new cluster as a Spoke following procedure here.

  • Connect the old cluster to the new one and recover selected PVCs following the documentation here.

2.2 Recover Selected Secrets and ICP4ADeploy CR

Restore the necessary secrets and the ICP4ADeploy custom resource (CR):

  • Apply the secret YAML files using kubectl apply -f <secret-name>.yaml.

  • Recreate the ICP4ADeploy CR with kubectl apply -f icp4adeploy-cr.yaml.

2.3 Install Operators Using Cluster-Admin Script

  • Obtain the cluster-admin script from the CP4BA installation package.

  • Run the script with appropriate permissions to install necessary operators.

  • Verify the successful installation of operators.

2.4 Prepare New SSL Certificates

Generate and configure new SSL certificates for the new cluster.

3. Addressing CPE Identity Provider URL

An important discovery during this process was the need to update the CPE identity provider URL in the GCD database due to the change from cluster scope to namespace scope.

3.1 Update GCD Database

Use the GCD utility to export the GCD XML file, edit instances of ibm-common-services to the new namespace (e.g., cp4ba), and import it back.

  • Steps:

    • Export the GCD XML using the GCD utility: gcd export -f gcd.xml.

    • Edit the exported XML file to replace all occurrences of ibm-common-services with the new namespace.

    • Import the modified XML back into the GCD database using gcd import -f gcd-modified.xml.

4. Applying ICP4ADeploy YAML CR

With all prerequisites met, we applied the ICP4ADeploy YAML CR and initiated the installation process.

4.1 Post-Installation Tasks

  • Access the Elasticsearch configuration.

  • Update the field size limit parameter to the desired value.

  • Restart the Elasticsearch service to apply the changes.

5. Testing and Validation

Testing is critical to ensure all components are functioning correctly.

5.1 Testing with ODM, BAA, BAW, and Process Mining

Collaborate with developers and users to import use cases and confirm everything is working as expected.

6. Finalizing Backup Configurations

To ensure reliable backups, we performed the following tasks:

6.1 Reconfigure IBM Storage Fusion

  • Uninstall the IBM Storage Fusion spoke and reinstall the hub version.

  • Configure Cloud Object Storage for backups and set up a regular backup schedule (weekly on weekends).

7. Database Maintenance

Migration presents an excellent opportunity for database maintenance.

7.1 Clean Up PostgreSQL Databases

Perform full vacuum and reindexes to optimize the database performance while there are no active connections.

Conclusion

Migrating CP4BA to a new cluster involves meticulous planning and execution. By following the steps outlined above, we successfully transitioned our deployments and paved the way for future upgrades. We hope this guide proves useful for other platform architects and aids the product team in enhancing the official documentation. For more detailed steps and additional resources, refer to the IBM CP4BA documentation.

Feel free to reach out for any clarifications or further assistance.

I hope this blog post meets your requirements. Let me know if there are any additional details or adjustments you'd like to make!


#CloudPakforBusinessAutomation

0 comments
4 views

Permalink