Cloud Pak for Data Group

 View Only

What you should know about the pre-upgrade tasks for Cloud Pak for Data Upgrade

By Hong Wei Jia posted Tue March 29, 2022 08:47 AM

Pre-upgrade tasks for CPD upgrade
In the blog Cloud Pak for Data Upgrade Best Practice , I introduced that there are 3 key phrases for the Cloud Pak for Data upgrade including pre-upgradeupgrade implementation and post-upgrade. Let's walk through the pre-upgrade tasks in details in this article. 

1) Decide the target Cloud Pak for Data and OpenShift versions

Different customers may have different choices or preferences. Some customers always want the latest Cloud Pak for Data version. While others maybe more conservative. Compared to the latest major release, they would like to just upgrade their product to a prior major one which they deem as more stable.
But when deciding the target version, both the Cloud Pak for Data Life Cycle and the OpenShift 4.X Life Cycle should be taken into consideration. 
Once the target Cloud Pak for Data version decided, the OpenShift version and the storage can also be decided accordingly. 

2)Get an overview of CPD usage information before the upgrade
You can leverage the Questionnaire for Upgrade to get an overview about CPD services, OpenShift version and Storage related information. These information can help to make the upgrade plan.

3)Check whether there are any installed services deprecated in the target upgrade version
For example, when checking this link Removals and deprecations , you'll find the Streams and Streams flow are deprecated in Cloud Pak for Data 4.0.
And these two services should be uninstalled before the upgrade to Cloud Pak for Data 4.0.
4)Estimate the sizing or resource requirements of the CPD services with the target version
Different Cloud Pak for Data version may have some differences for the resource requirement. Refer to the hardware requirements for your evaluation. 
Beside, checking the resource utilization of current cluster to see if there's overload is recommended. It can help to reduce the risk of upgrade failure. Below command can help to check the resource utilization of each node.
oc get node --no-headers | while read node stat role age ver; do echo -ne "$node\t"; oc describe node $node | egrep '^ (cpu|memory)' | sed -r 's/\(|\)//g' | while read lbl x p1 y p2; do echo -n \ $p1 $p2 ; done; echo ""; done
If there's high resource utilization of current cluster, then more resource should be added to this cluster accordingly before the upgrade.

5)Evaluate and decide the time window

There will be service outrage during Cloud Pak for Data upgrade and a time window is required.The time window mostly depends on the services installed on the Cloud Pak for Data cluster.  Please refer to 2) about leveraging the questionnaire for getting the list of services.

In general, the upgrade for each service could be completed within 1 hour if it goes smoothly. But if the service depends on other shared assembly, e.g. Common Core Service and this service is the first service to be upgraded, then it will consume much more time as the upgrade of the dependency is included in the upgrade process.

The volume of production data also matters for the time required by the upgrade. For the upgrade fo some particular services, such as the upgrade of Watson Knowledge Catalog from 3.5 to 4.0  , the volume of production data will impact the chosen of the upgrade method (online or offline) which also means different time would be required for the upgrade.

It's recommended discussing with the end-users about the time window and timing about the upgrade as the production use would be impacted. And the end-users should be informed and get prepared for it. And an official notice for asking the end-users to stop the environment runtime, scheduled jobs, auto discovery jobs or quick scan jobs is recommended.

6) Take backup as part of the upgrade
The purpose of the backup is to ensure the production cluster could be restored in case there's critical upgrade failure. The backup of the cluster is comprised of  the Openshift part and the Cloud Pak for Data part.
There are some technical differences between the backup and restore service of CPD 3.5 and that of CPD 4.0. Depending on your Cloud Pak for Data version, you can implement the backup with the backup and restore service accordingly.
The backup supported by CPD 3.5 and 4.0 is still offline backup.

In addition to the backup and restore service provided by Cloud Pak for Data, you can also leverage the Cloud platform's back up utility  in case your cluster is deployed on AWS.

7) Review IBM documentation carefully when you are to upgrade your services to next major version
For the upgrade to next major version, there maybe some special tasks to be handled. And Different services may have different tasks.
a) Some services' upgrade  require a fresh install followed by some migration efforts, such as Data Virtualization's upgrade from 3.5.X to 4.0.Y.
b) For some of the Watson services, such as Watson Assistant and Watson Discovery, the upgrade have to be done via the corresponding backup and restore approach. 
c) Some of the services's upgrade may require the migration of the Environment Runtimes because of the library differences between Open-CE and WML-CE. And the notebook code changes should be taken into consideration for the upgrade.

Besides, there maybe particular pre-upgrade tasks required for your services' upgrade. For example, when upgrading Data Virtualization from 3.5.X to 4.0.Y, there are pre-upgrade tasks as follows.
You must export users from Data Virtualization on Cloud Pak for Data 3.5 before you upgrade to Cloud Pak for Data 4.0.1 or later. You must also copy any JAR files from JDBC drivers that you downloaded when you configured data source connections in Cloud Pak for Data 3.5.

8) Get the required images and libraries ready
It's not only about download but also about the validation of the the images and libraries for the upgrade.

A private image registry with images mirrored into it is recommended for the upgrade to Cloud Pak for Data 4.0.
9) Identify the order required to upgrade the services
Some services are closely integrated with each other, such as WSL could be closely integrated with WML and Decision Optimization. During these services' upgrade from 3.5 to 4.0.X, the order for the upgrade should be WSL -> WML -> DO.

10) Work out the runbook for the upgrade beforehand
The runbook may include the upgrade of OpenShift, Storage (e.g. Portworx, ODF) and Cloud Pak for Data. You can work out the runbook following IBM documentation. And it's recommended you validate it in a test cluster. A good runbook can greatly help to reduce the risk and time consumption for the upgrade.
11) Get the resource and necessary support from IT team

IT team's support should be ready for resolving any infrastructure related issues incurred during the upgrade including Network, Hardware, etc. An urgent contact list is recommended. 

12)Sort out the list of technical limitation or know issues related to your upgrade
This could be done by checking the Limitations and known issues in IBM documentation about each service to be upgraded. 

In this article, we walked through the Pre-upgrade tasks which does matter to the upgrade success. You can put the above tasks into a table and go through them one by one until all tasks are done. And once it's done, I believe you'll have much more confidence and be well prepared for the upgrade.