/
Configuring PowerHA with SVC Asynchronous Policy-based Replication (7.5)

Configuring PowerHA with SVC Asynchronous Policy-based Replication (7.5)

Background

Asynchronous Policy-based replication is a technology that is designed to be a replacement to Global Mirror and Global Mirror with Change volumes. Policy-based replication is designed to provide both simplified configuration and management by assigning a set of volumes to a volume group, and assigning a replication policy to the volume group.

Before you begin

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

  • A cluster between the nodes has been created, and the cluster nodes have a status of Active.

  • The nodes are all in the same device domain. When creating a cluster or adding a node to a cluster with default options, PowerHA automatically adds nodes to a single device domain.

  • An IASP has been created on the production node.

  • SSH Communication has been configured. See Preparing for an SSH connection between IBM i and SVC systems.

  • PowerHA requires a minimum of Spectrum Virtualize/FlashSystems software version 8.6.2.0 or later to manage and control asynchronous Policy based replication.

Procedure

Create the Cluster Resource Group

A cluster resource group (CRG) defines the following:

  • A recovery domain is a list of nodes that are potential hosts for the IASP along with the current role the node has (primary or backup).

  • A list of configuration objects, such as IASPs or IP addresses, that are switched between the nodes.

A CRG can be created using any of the following methods:

  • Type the CRTCRG command and press F4 to go to the Create Cluster Resource Group (CRTCRG) command screen.

  • Using the Work with Cluster (WRKCLU) command menu. Select option 9, Work with cluster resource groups, and use option 1, Create, and enter a name for the CRG to go to the Create Cluster Resource Group (CRTCRG) command screen.

  • From the command line, enter the CRTCRG command and your parameters.

For this example, a CRG is created using the following command:

CRTCRG CRG(MYCRG) CRGTYPE(*DEV) RCYDMN((PROD *PRIMARY *LAST MN) (DR *BACKUP *LAST TX)) CFGOBJ((MYIASP *DEVD *ONLINE))

This command creates a device CRG called MYIASP. The CRG defines two nodes: the first in a site named MN, and the second in a site named TX. The CRG has a single IASP device specified that is switched with the CRG called MYIASP. Additional IASPs or configurations can be added after the CRG is created using the Add CRG Device Entry (ADDCRGDEVE) command.

Automatic Failover

By default, a cluster resource group has automatic failover enabled. When a failure is detected, automatic failover will automatically switch the IASP to a backup node.

Disabling Automatic Failover

Automatic failover can be disabled using the QCST_CRG_CANCEL_FAILOVER PowerHA policy. The following example disables all automatic failover for the CRG named GEOCRG:

ADDHAPCY PCY(QCST_CRG_CANCEL_FAILOVER) PCYDMN(GEOCRG) QUAL('SCOPE(*CRG)') VALUE('EVENT(*ALL)')

For additional information on customizing automatic failover, see the QCST_CRG_CANCEL_FAILOVER policy.

Enhanced Automatic Failover with Cluster Monitor

In environments where automatic failover is desired, it is possible to enhance automatic failover to monitor for additional events via a Hardware Management Console (HMC) using cluster monitors. See Advanced Node Failure Detection for additional information.

Optional CRG Exit Program

CRG Exit programs provide a way to define a program to call whenever a cluster event occurs and enable enhanced automation. See the Cluster Resource Group Exit Program topic in the IBM i Documentation for more information.

Configuring Asynchronous Policy-Based Replication

PowerHA requires replication to be configured outside of PowerHA. After replication is configured, PowerHA manages the replication.

To configure asynchronous policy-based replication complete the following steps:

  1. Log into the storage system with a user that has enough authority.

  2. If you have not set up any remote copy connections between the two storage controllers, you must create a partnership between these systems.

a. Click Copy ServicesPartnerships and Remote Copy.

b. Click Create Partnership.

c. Select 2-site partnership.

d. Select the type of partnership, using either Fibre Channel or IP, and enter the required parameters.

Select to Use Policy Based Replication

It is important to select the checkbox to use policy-based replication for this partnership

e. Select Create to create the partnership.

  1. If you have not already created a replication policy in the storage, create a replication policy

a. Click Policies → Replication Policies.

b. Click Create replication policy.

c. Give the policy a name, select the location 1 and location 2 systems and enter an RPO objective. If the recovery point exceeds this value, the storage controller will generate an alert.

d. Click Create to create the replication policy.

  1. If the Independent ASP volumes are not already in a volume group in the storage, create a volume group

a. Click Volumes → Volume Groups.

b. Click Create Volume Group.

c. Give the volume group a name.

d. Select Choose Existing Volumes.

e. Click Next.

f. Select the volumes that are in the IASP to add to the volume group.

g. Click Create Volume Group.

  1. If a replication policy is not already assigned to the volume group, assign a replication policy.

a. Click Volumes → Volume Groups.

b. Click on the volume group name to view details for the volume group.

c. Click on the policies tab.

d. Click on Configure policy-based replication.

e. Follow the wizard to select the partnership, which system is the primary storage controller, selecting storage pools, and selecting a replication policy.

Target Volume Creation
The volumes on the target storage controller are created automatically as part of this process, greatly simplifying the configuration of replication.

Adding Copy Descriptions

A copy description gives PowerHA the information it needs to describe and manage a single copy of an IASP. With Asynchronous Policy-based replication, because the IASP is replicated, there are two copies of the IASP. Therefore, PowerHA requires two copy descriptions.

The information required in the copy description describes the location of the copy of the IASP it describes, along with the storage credentials and information describing the volumes for the copy description.

Adding the Primary (Source) Copy Description

The following is an example for adding a copy description for the source copy:

ADDSVCCPYD ASPCPY(MNCPY) ASPDEV(MYIASP) CRG(MYCRG) SITE(MN) NODE(*CRG) SVCHOST(powerha_myclu '/QIBM/UserData/HASM/hads/.ssh/id_rsa' '203.0.113.1') VRTDSKRNG((56 58 *ALL) (60 76 *ALL))

This command adds a copy description named MNCPY for asp device MYIASP. I describes this copy of the IASP being represented by the site named MN in the CRG called MYCRG. Specifying a node of *CRG indicates to the copy description that the lowest numbered backup node at the given site of the CRG currently owns the copy.

Next the copy description gives the authentication information required for communicating with the storage controller including the username, powerha_myclu in this example, the key file location to the private key that was configured in Preparing for an SSH connection between IBM i and SVC storage, and the IP address for the storage controller.

Storage Username Case-Sensitivity

The storage username field is case sensitive and must match what is configured on the SVC storage controller.

Finally, the copy description specifies virtual disk ranges, which gives PowerHA information on the volumes that represent the IASP on the storage system. In this instance the IASP has volumes 56 to 58 (3 volumes) and volumes 60 to 76 (17 volumes) for a total of twenty volumes.

The storage controller has an ID field that represents the volume IDs. The volume IDs are in various places on the storage command line and GUI interfaces. For example, from the GUI interface, the volume group details screen can be used:

  1. Log into the primary storage controller web interface.

  2. Click Volumes → Volume Groups.

  3. Click on the volume group name to view details for the volume group.

  4. Click on the volumes tab if it is not automatically selected.

  5. The list of volumes is displayed in the volume group.

  6. If necessary use the button at the far right of the table to show the volume ID column

    image-20241226-171432.png
  7. The ID column represents the volume IDs to use in the copy description. When volume IDs are contiguous, they can be entered as a single range such as 56 to 58.

Adding the Backup (Target) Copy Description

The following is an example for adding a copy description for the source copy:

ADDSVCCPYD ASPCPY(TXCPY) ASPDEV(MYIASP) CRG(MYCRG) SITE(TX) NODE(*CRG) SVCHOST(powerha_myclu '/QIBM/UserData/HASM/hads/.ssh/id_rsa' '203.0.113.2') VRTDSKRNG((10 29 *ALL))

This command adds a copy description named TXCPY for asp device MYIASP. I describes this copy of the IASP being represented by the site named TX in the CRG called MYCRG. Specifying a node of *CRG indicates to the copy description that the lowest numbered backup node at the given site of the CRG currently owns the copy.

Next the copy description gives the authentication information required for communicating with the storage controller including the username, powerha_myclu in this example, the key file location to the private key that was configured in Preparing for an SSH connection between IBM i and SVC storage, and the IP address for the storage controller.

Finally, the copy description specifies virtual disk ranges, which gives PowerHA information on the volumes that represent the IASP on the target storage system. In this instance the IASP has volumes 10 to 29 (20 volumes).

Starting a PowerHA Session

A session in PowerHA describes the relationship between copy descriptions, including the type of replication and is used to manage and control replication. A session can be started in this example using the following command:

STRSVCSSN SSN(MYSSN) TYPE(*GLOBALMIR) CRG(MYCRG) DETACHMODE(*ACTIVE)

This command specifies to start a session called MYSSN that is of type Global Mirror. PowerHA uses Global Mirror to represent asynchronous replication as is used with asynchronous policy-based replication. In addition, the command specifies that this session references the CRG named MYCRG. PowerHA automatically pulls together the CRG information and Copy Description information from the copy descriptions that describe sites in the CRG.

The parameter detach mode (DETACHMODE) with a value of *ACTIVE indicates that when the *DETACH operation in PowerHA is performed, the storage will continue replication to the storage in the background. While the data on the copy of the IASP that is accessible on the target node is still a point-in-time copy from when the detach was issued, the target storage controller continues to receive updates from the production storage controller, improving the recovery point and reducing the time required for re-synchronization after a reattach. Using *ACTIVE for detach mode protects the recovery point but uses more storage space on the target storage controller. If you have enough storage, it is recommended to use a detach mode of *ACTIVE.

Results

PowerHA management of Asynchronous Policy-based replication is now configured between the nodes in the CRG. To verify and monitor the status of replication, use one of the following:

  • The Display SVC Session (DSPSVCSSN) command. For example, DSPSVCSSN SSN(MYSSN).

  • The PowerHA web interface.

  • The SQL Service table function QHASM.SESSION_INFO.

 

Related content

Configuring PowerHA with SVC Asynchronous Policy-based Replication (7.4)
Configuring PowerHA with SVC Asynchronous Policy-based Replication (7.4)
More like this
Configuring PowerHA with Global Replication Services (7.5)
Configuring PowerHA with Global Replication Services (7.5)
More like this
Configuring PowerHA with Global Replication Services (7.4)
Configuring PowerHA with Global Replication Services (7.4)
More like this
Migrating from SVC Global Mirror or Global Mirror with Change Volumes to Asynchronous Policy-Based Replication with Limited Bandwidth or Storage Capacity (7.4)
Migrating from SVC Global Mirror or Global Mirror with Change Volumes to Asynchronous Policy-Based Replication with Limited Bandwidth or Storage Capacity (7.4)
More like this
Migrating from SVC Global Mirror or Global Mirror with Change Volumes to Asynchronous Policy-Based Replication with Limited Bandwidth or Storage Capacity (7.5)
Migrating from SVC Global Mirror or Global Mirror with Change Volumes to Asynchronous Policy-Based Replication with Limited Bandwidth or Storage Capacity (7.5)
More like this
Configuring Geographic Mirroring Between Two Systems (7.4)
Configuring Geographic Mirroring Between Two Systems (7.4)
More like this

Privacy Policy | Cookie Policy | Impressum
From time to time, this website may contain technical inaccuracies and we do not warrant the accuracy of any posted information.
Copyright © Fortra, LLC and its group of companies. All trademarks and registered trademarks are the property of their respective owners.