For the procedure described in this white paper to work, the minimum required IBM Db2 Analytics Accelerator on Z maintenance level is 7.5.3. If you are about to migrate an Accelerator on Z installation running an older maintenance level but do not want to upgrade the software before starting the migration, open an IBM support case.

How to do a box migration

In the following section, we describe how to do a migration from one box to another.

Sample scenario description

In our small sample scenario,

1. We have
   • One IBM Z mainframe with CPC name “IBMZ14”,
   • Another mainframe with CPC name “IBMZ15” to replace the original CPC and
   • An external storage box.
2. There is exactly one Secure Service Container (SSC) LPAR containing accelerator server (with maintenance level 7.5.4.)
3. We also want to change the LPAR name from “IDAATEST14” to “IDAATEST15”.

The following figure illustrates this sample setup:

In the example, the network devices and the FICON express ports are not changed. But it is neither required to keep the same devices and FICON express ports nor it is required to change CPC name and LPAR name. If nothing is changed (meaning: if you do not rename the CPC or the LPARs and also keep all devices identical in your current IO definition), no migration is required. You can activate the LPAR on the new box by using the existing storage volumes on the storage box retained.

In this example, zFCP/SCSI storage is used. For ECKD storage, it works similar, however FICON express ports do not have to be identified in the “runtime_environments” section of your JavaScript Object Notation (JSON) configuration file. In all cases, the storage volumes themselves are defined in the “storage environments” section of the JSON configuration file. 

Migration steps

Export JSON

To export the IDAA-on-Z configuration JSON, go the Accelerator Admin UI and perform the “Download the currently active configuration file for the Accelerator” action:

Alternatively, you can edit your existing JSON configuration file if you have it available.

The downloaded JSON might look like this figure:

At accelerator startup time, the system verifies the CPC name and the LPAR name currently used. Only matching runtime environments are used. So if you try to start this accelerator on a CPC with CPC name “IBMZ14” or in an LPAR name “IDAAPROD1”, no matching entry is found, leading to a failure at accelerator startup time.

Add new CPC/LPAR runtime environment

To make the configuration using the same external storage work on the new box, a new runtime environment for (in our sample scenario) cpc_name “IBMZ15”, lpar_name “IDAATEST15” needs to be added to the configuration. The updated JSON configuration might look like this, with the header section and the storage_environments section being unchanged:

Upload and apply updated JSON file

Now you have to upload and apply the updated JSON configuration file:

This task can be performed while the accelerator is still active on the original system, there is no planned outage required for this preparing task.

After you have applied the updated JSON (similar to what’s shown in Figure 4), the running accelerator contains both runtime environments – one for the old box, one for the new box. Before the actual configuration starts, a message box like this appears:

Press “OK” here. After a few seconds, a green box stating “Configuration updated” appears.

Storage definitions

Do not forget that your new box needs to get access to the existing storage volumes. Make sure

• The storage devices are correctly defined in the I/O configuration with IODF on the new box,
• The devices are visible to the LPARs and
• In case of an zFCP environment, the zoning or LUN masking configuration of your storage environment is done in a way the new LPAR can find the existing FCP volumes.

Deactivate Accelerator on the old box

Now a planned outage of the accelerator is required. We recommend to

• Disable query acceleration by using the STOP ACCEL Db2 command on z/OS.
• Quiesce the running accelerator by pressing the “Shutdown” button in the Admin UI.

After these actions, you can deactivate the accelerator SSC LPAR on your HMC.

The time of the outage needs to be about 30 minutes for shutdown and administrative actions plus at least the time it takes to re-start the accelerator once.

Activate Accelerator on the new box

Now you are ready to start the accelerator on the target system.

After starting the accelerator on the new box with the same set of storage volumes, the accelerator should come up correctly, using the new runtime environment. It is now time to restart query acceleration with the START ACCEL Db2 command.

JSON configuration cleanup

In our example scenario, the runtime environment section for cpc_name “IBMZ14”, lpar_name “IDAATEST14” still exists but it is fortunately ignored. However you may remove this section from your configuration JSON now, so the final JSON in our example should look like this:

You can upload the final JSON configuration right away. It can be applied while the accelerator on the new box is up and running.

Box migration in case of a multi-node installation

The box migration of a multi-node cluster installation is similar to the single node migration explained here except you need to update all runtime environments for all 6 LPARs (head, data1,…,data5), not just one LPAR with one runtime environment.