Migrating to a different CPC or LPAR

Follow the steps here to move your Db2 Analytics Accelerator on Z installation to a different Central Processing Complex (CPC) in a different logical partition (LPAR) while keeping the storage devices unchanged.

Before you begin

If you are about to use new storage devices, mind that all storage devices must be "visible" to your accelerator LPARs. To make new devices "visible", follow the steps in Adding storage devices.

Attention: If you use GDPS® integration, GDPS will manage the storage replication. In this case, do not define more than one storage environment. Multiple storage environments are not supported in the GDPS context. For more information, see How to migrate DASD devices of Db2 Analytics Accelerator for z/OS defined for GDPS failover support.

About this task

The following description is based on a setup with the following hardware:

An IBM Z LPAR named A from which to migrate
An IBM Z LPAR named B to migrate to
A connected storage box that is left as is

The network devices and the FICON express ports remain unchanged, although this is not required. You could change network devices and the ports if you wanted to.

It is also not required to change the name of the CPC or the LPAR. If you do not change the names of any devices in your setup, you also need not migrate anything. You can just activate the LPAR on the new box by using the existing storage volumes in the storage box.

The example uses zFCP (SCSI) storage devices. The setup is very similar for ECKD storage devices, except that it is not necessary to identify FICON express ports in the “runtime_environments” section of your JavaScript Object Notation (JSON) configuration file. In all cases, the storage volumes are defined in the “storage_environments” section of the JSON configuration file.

Important:

In general, to change the number of LPARs, a complete reload of the accelerator and a fresh installation is required. For example, if you start with a three-drawer system with one LPAR each (as recommended), and then want to add a fourth drawer, create a new setup to reinstall the cluster with 4 drawers.
To extend a two-drawer system to a four-drawer system, you need not reinstall the entire system. Here, you can migrate normally. So instead of having two LPARs that share one drawer, you end up with one LPAR per drawer.
The recommendation is to use dedicated IFLs only. However, if you want to use a confined head node setup for shared IFL workloads, make sure that the LPARs that provide the shared workloads have a significantly lower priority than the LPARs of the confined head node cluster. This way, the slowing impact on the performance is kept at a minimum.

Procedure

Open the Admin UI of the accelerator.
On the home page, under Configuration, click Download the currently active configuration file for the Accelerator.
See Figure 1.
Figure 1. Downloading the active configuration file
In the sub-window with the title opening accelerator-config json, select Save File and click OK.
Edit the downloaded JSON configuration file and add the indicated block. Change the values of "cpc_name", "lpar_name", and other devices, so that these match the names in your environment. See the example in Figure 2.

Important: Make sure that the value of the "cpc_name" keyword (server name) in each runtime environment block resolves to a different IP address. If that is not possible, edit the JSON configuration so that it contains just a single runtime environment, in which the old block is replaced with the new one.

In Figure 2, an IBMZ15 block is added as a runtime environment to support the transition from z14 to z15. The "cpc_name": "IBMZ15" must resolve to a different IP address than "cpc_name": "IBMZ14". If both systems resolve to the same IP address, an error will occur when you upload the JSON file because duplicate IP addresses are not permitted in this context. Each CPC (central processor complex) must have a unique IP address. If this is not possible, add the new runtime environment and then remove the old one.

Figure 2. Second CPC/LPAR block added to "runtime_environments" section
On the home page, under Configuration, click Upload and validate an updated configuration file for the Accelerator, and upload your new JSON configuration file, which now contains the additional CPC and LPAR definitions.
See Figure 3.
Figure 3. Uploading and validating an updated configuration file
Click Apply the updated configuration file for the Accelerator.
You see a confirmation window like this:
Figure 4. Confirmation window
Click OK.
A final confirmation message is displayed at the top of the page:
Figure 5. Final confirmation message

The new accelerator needs to access the existing storage volumes. To this end, make sure that the following conditions are met:

The storage devices are correctly defined in the input/output definition file (IODF) on the new box.
The devices are visible to the LPARs.
If you use zFCP storage devices, make sure that the zoning or LUN masking configuration in your storage environment allows the new LPAR to find the existing FCP volumes.

Now an outage of roughly 30 minutes is required. The time is needed for the shutdown and administrative actions plus the time it takes to restart the accelerator. According to the example in this topic, this would be a shutdown of the accelerator on CPC IBMZ14 and a restart of the accelerator on CPC IBMZ15. Proceed with the following steps.

Stop query acceleration by running the following Db2 command:
```
-STOP ACCEL accelerator-name
```
where accelerator-name is the name of your accelerator.
On the Accelerator Components Health Status page of the Admin UI, click Shut Down to stop the accelerator.
See Figure 6
Figure 6. The Shut Down button on the Accelerator Components Health Status page
On the Hardware Management Console (HMC), you can now deactivate the SSC LPAR that you don't want to use anymore:
1. Open the HMC.
2. In the navigation tree on the left, under Systems Management, select the IBM Z system the SSC LPAR belongs to.
  All LPARs on that system are listed in the Partitions view (tab) on the main page.
3. In the Partitions view, right-click the name of the LPAR you want to deactivate and select Daily > Deactivate from the context menu.
See the example in Figure 7, where an LPAR named SVLSSC53 is deactivated.
Figure 7. Deactivating an SSC LPAR on the HMC
Bring the SSC LPAR you want to migrate to into the installer mode.
1. On the HMC, select the Customize/Delete Activation table.
2. In the navigation tree on the left, navigate to and select the SSC link.
3. Make sure that Secure Service Container installer is selected on the main page in the center.
See Figure 8.
Figure 8. Selecting the Secure Service Container installer
Activate the new SSC LPAR, that is, the LPAR you want to migrate to (in the example, this is LPAR IDAATEST15 on CPC IBMZ15).
To this end, go back to step 10 and complete sub-step 10.b. However, skip step 10.c and instead select Daily > Activate from the context menu in the Partitions view.
Log on to the Admin UI again. That is, enter the IP4 address of the new SSC LPAR in a web browser and provide the Master user ID and Master password.
You see the welcome page of the Secure Service Container Installer.
Click the icon on the right.
In the Install Software Appliance window, make sure that the following radio buttons are selected:
- Attach existing disk
- FICON DASD or FCP, according to the disk type that you use. For the example in the introduction of this topic, FCP would be the right choice.
From the Disk drop-down list, select the disk that contains the accelerator image.
In accordance with the example in this topic, this would be one of the zfcp_devices listed in the sample runtime environment shown at the beginning, probably 0.0.1b10.
To confirm that you picked the right disk, make sure that this or similar information is displayed under Appliance Details after you have selected a disk:
```
Name:     Db2 Analytics Accelerator for z/OS
Version:     7.5.xx
Description: Db2 Analytics Accelerator Appliance
```
Click Apply.
The accelerator starts on the new CPC (IBMZ15 in the example), and uses the new runtime environment that has been defined in the JSON configuration file. After that, it is ready for use.
Start query acceleration on the new accelerator by running the following Db2 command:
```
-START ACCEL accelerator-name
```
where accelerator-name is the name of your new accelerator.

What to do next

If the new setup works, you can clean up your JSON configuration and use the cleaned version of the file:

Remove the old accelerator definition from the "runtime_environments" section of your JSON configuration file.
Upload the cleaned version of the file by repeating the steps 5 through 6, and confirm by clicking OK.
The new accelerator can stay active during this process. An outage is not needed.

The migration of a multi-node accelerator works in much the same way. The only difference is that you have to define new runtime environments for all the LPARs (head, data1, data2, and so on), rather than just a single LPAR with one runtime environment.