Managing FlashCopy in Power Virtual Server (7.5)

1 Background
2 Before you begin
- 2.1 Prerequisites
- 2.2 Determine the type of quiesce for the source copy
  - 2.2.1 Vary Off (*VARYOFF)
  - 2.2.2 Suspend Transactions (*SUSPEND)
  - 2.2.3 Force Data to Disk (*FRCWRT)
  - 2.2.4 None (*NONE)
3 Taking and Mounting a FlashCopy
4 Unmounting a FlashCopy
5 Viewing Current FlashCopy Status

Background

IBM Power Virtual Server FlashCopy provides the ability to take point-in-time snapshots of independent auxiliary storage pools (IASPs) and bring the snapshots online on another partition that is active in the cluster. Common use cases for FlashCopy include offloading backups to a secondary partition to reduce backup windows (offline backups), and test environments.

PowerHA provides native capabilities to automate the following functionality as part of FlashCopy:

Quiesce production IASP.
If the FlashCopy is at the target of replication, verifying the replication state prior to performing the FlashCopy and waiting for the quiesced at the target site.
Taking the snapshot
Mounting the snapshot
Varying on FlashCopy target IASP
Calling an exit program on the target node

In addition, when unmounting the FlashCopy, vary off the IASP on the FlashCopy target node.

Before you begin

Prerequisites

This scenario assumes that the following tasks have been completed prior to these steps:

Power Virtual Server FlashCopy has been configured. See Configuring PowerHA with Power Virtual Server FlashCopy (7.5).

Determine the type of quiesce for the source copy

FlashCopy creates a point-in-time copy of disk units. Therefore, any data that still resides in main memory and that is not committed to disk is not copied to the FlashCopy target LUNs. Therefore, it is recommended that local journaling is configured the environment. When you vary on the FlashCopy of the IASP, one of the steps during vary on is database recovery. This step ensures that data in the IASP is in a consistent state. When open transactions that did not reach a commit boundary are identified, these transactions are rolled back to the last commit point by using journal entries. You can then perform a save to tape from this consistent data.

IBM i provides various ways of quiescing an independent ASP. In the case of PowerHA FlashCopy this is referred to as the source ASP action (SRCASPACN). The following are options for the source ASP action:

Vary Off (*VARYOFF)

Performs a cold FlashCopy operation. When performing a cold FlashCopy operation, the *VARYOFF action initiates the following steps:

1. The source copy of the ASP is varied off if not already offline.
2. The FlashCopy operation is initiated.
3. If the source copy of the ASP was varied off as part of the operation, it is varied back online.

While *VARYOFF ensures that the FlashCopy is identical to the source ASP copy at the time of the FlashCopy, it involves ending applications accessing the IASP to take the FlashCopy. Therefore, in most environments other less impactful quiesce options are often chosen.

Suspend Transactions (*SUSPEND)

Performs a warm FlashCopy operation. When performing a warm FlashCopy operation, the *SUSPEND action initiates the following steps:
1. Suspend database transactions and Integrated File System (IFS) file change operations on the source ASP. Transactions that were started are allowed to continue until they reach a commit boundary (subject to a time limit). The initaiton of new transactions or new file (database or IFS) operations is termporarily halted.
2. Changed pages in memory on the source ASP are written to disk.
3. The FlashCopy operation is initiated.
4. Resume suspended transactions and IFS operations for the source ASP.

From a user application perspective, the system seems to respond more slowly than expected during the suspended time. Application transactions will not break unless the application uses timeouts and that time is exceeded. In other environments with long or interdependent commit cycles, it may be difficult to achieve a suspend point. For this reason, in some environments a less impactful quiesce option, such as *FRCWRT or *NONE may need to be chosen.

Force Data to Disk (*FRCWRT)

Flushes changed data that is in memory to disk, but does not attempt to reach a quiesce point prior to writing data to disk. This means that applications continue to run during this operation, but it can often still improve IASP vary on time and consistency on the FlashCopy target. Some applications may respond slower due to the extra disk paging involved with this option.

None (*NONE)

The source ASP is not quiesced automatically as part of the FlashCopy operation.

It is recommended to evaluate quiesce options starting at the top of the list and working down to find the option that balances production application impact with the need to have data at a precise moment in time. In cases where data is not quiesced and not journaled, it is possible that objects could be damaged on the target copy. Therefore, it is recommended that local journaling is used in a FlashCopy enviornment.

Taking and Mounting a FlashCopy

Use the Change Power Virtual Server (CHGPVSSSN) command with the *MOUNT option to mount a FlashCopy to the target partition. For example:

CHGPVSSSN SSN(FLASHSSN) OPTION(*MOUNT)
          SRCASPACN(*SUSPEND)
          TGTASPACN(*VARYON) TGTEXITPGM(QGPL/MYBACKUP)

The above command takes a new FlashCopy snapshot for the session named FLASHSSN and mounts it to the target node that was specified in the target copy description when starting the FlashCopy session.

In this case, because the source ASP action is *SUSPEND, the source copy of the IASP is suspended while the snapshot is being taken. After the snapshot is taken and the source ASP is resumed, the FlashCopy volumes are attached (mounted) to the target node. Then, the target ASP action of *VARYON specifies that the target copy of the ASP is varied online on the target node. Finally, the optional target exit program parameter in this case specifies that the program MYBACKUP in library QGPL is submitted to run on the target node. The command returns after the exit program is submitted without waiting for it to complete.

Upcoming Changes
Starting with the PowerHA June 2025 PTF, the above command needs the SNAPSHOT(*NEW) parameter to maintain the same behavior of taking a new snapshot and mounting it in one operation.

CHGPVSSSN SSN(FLASHSSN) OPTION(*MOUNT)
          SNAPSHOT(*NEW)
          SRCASPACN(*SUSPEND)
          TGTASPACN(*VARYON) TGTEXITPGM(QGPL/MYBACKUP)

Did you Know?
Since the PowerHA cluster provides a single point of management and control, like most PowerHA and cluster commands, the FlashCopy operation can be performed from any node in the cluster. PowerHA automatically performs the necessary operations on the appropriate node in the cluster.

Unmounting a FlashCopy

When done using a FlashCopy, the FlashCopy can be unmounted which detaches the copy from the target node, and deletes the snapshot from Power Virtual Server. This operation must be performed before a new snapshot can be mounted to the target node.

To unmount a FlashCopy, use the CHGPVSSSN with the *UNMOUNT parameter. For example:

CHGPVSSSN SSN(FLASHSSN) OPTION(*UNMOUNT)

This command specifies that the IASP is first varied off on the target node, if it is online. Then, the target copy of the IASP is detached from the target node, and deleted from Power Virtual Server.

Viewing Current FlashCopy Status

To view the current status of a FlashCopy session, use one of the following options:

The Display PVS Session (DSPPVSSSN) command. For example, DSPPVSSSN SSN(FLASHSSN).
The SQL Service table function QHASM.SESSION_INFO.