Configure DS8000 HyperSwap with Global Mirror

Configure HyperSwap connections and Global Mirror together for regional outage protection

Before you begin

This example scenario assumes that the you have experience with IBM Copy Services Manager (CSM) and managing an IBM System Storage DS8000. Before configuring HyperSwap and Global Mirror relationships in PowerHA, the CSM must be configured with a session type of Metro Mirror – Global Mirror w/Site 3 Global Mirror and the appropriate site storage volumes created.

These steps of the example scenario use the following setup parameters for the cluster:

Table 1. Example settings for the HyperSwap with Global Mirror using CSM

The storage devices in the scenario example are three DS8000 storage units with the following setup:

Table 2. Storage device information

The steps in the example begin with an established cluster environment, an administrative domain (if needed), and an IASP created at the primary site. Additionally, the cluster must be started. You also will need to know if your cluster nodes have the *SYSTEM certificate store created.

About this task

HyperSwap provides protection against hardware or software but due to the synchronous nature of HyperSwap, it limits the ability to recover from regional outages. When HyperSwap combines with PowerHA Global Mirror, the ability to switch a site’s workload to another system is gained. This ability to switch systems is important for disaster recovery (DR) planning.

This type of environment is split into two or more locations, geographically separated and linked through an asynchronous Global Mirror connection. HyperSwap is used to manage storage outages . In the event of regional outage, the Global Mirror connection performs a switch to the DR location. After recovery of the primary systems, data can be synchronized once more using Global Mirror.

The steps in the following example demonstrate how to configure a PowerHA cluster to use HyperSwap with Global Mirror for Copy Services Manager (CSM).

Procedure

A device description for the IASP must be available to the preferred target node.

1. Make a device description of the IASP for the preferred target node in the cluster. This can be done one of two ways:
   • Place the device description into the Cluster Administrative Domain as a Monitored Resource Entry (MRE). This will make the device description available to the other nodes in the cluster.
   • On the backup node, create a device description for the IASP with the same IASP name used on the preferred source node. In this scenario, IASP_1

2. Note: If you chose a different RDB name than the IASP name on the preferred source node, make sure to specify the same value on the preferred target node. If the RDB name and the IASP have the same name, use the default value of *GEN.

   The command to create the device description:

   CRTDEVASP DEV(IASP_1) RSRCNAME(IASP_1) RDB(*GEN)

   will create a resource IASP_1 for the IASP named IASP_1 using the default name for the associated RDB; in this case, the RDB will have the name IASP_1.

This configuration will require a Cluster Resource Group (CRG).

1. Create the CRG for managing this configuration. CRGs can be created:
   • typing the CRTCRG command and pressing 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.
   • or from the command line by entering the CRTCRG command and your parameters.
2. For this example, in the cluster PWRHA_CLU, a CRG named HYSGMIRCRG is needed to manage IASP_1.

   CRTCRG CLUSTER(PWRHA_CLU) CRG(HYSGMIRCRG) CRGTYPE(*DEV) EXITPGM(*NONE) USRPRF(*NONE) RCYDMN((NODE_1 *PRIMARY *LAST SITE1 *NONE)
   (NODE_2 *BACKUP 1 SITE2 *NONE) CFGOBJ((IASP_1 *DEVD *ONLINE ’10.0.0.1’))

   The CRTCRG command creates a device *DEV CRG, HYSGMIRCRG. Notice the additional parameters defined for the CRG:
   • this CRG has no exit programs (EXITPGM) or user profiles (USRPRF) associated with it, so *NONE is used in these fields.
   • the recovery domain node list (RCYDMN) defines which of the cluster nodes is the primary node and the order of the backup nodes in the cluster ((NODE_1) (NODE_2)).
   • a configuration object list (CFGOBJ) defines which objects are controlled by the CRG. In this example, this is IASP IASP_1, with an object type of *DEVD. Lastly, the configuration object (CFGOBJ) parameter *ONLINE indicates whether the IASP and the optional server takeover IP address should vary on after a failover or a switchover. Here, the selection *ONLINEdeclares that it should vary online.

3. Important: The CRG is created with these settings but the status is Inactive. At this point, the CRG should remain inactive until further configuration is complete.

A pair of auxiliary storage pool (ASP) copy descriptions are required for this example to define the HyperSwap relationship and the Global Mirror. Both sites require a copy description.

1. Add the ASP copy descriptions by running the Add ASP Copy Description (ADDASPCPYD) command.
   1. On the command line for the primary node create the copy description.

      ADDASPCPYD ASPCPY(IASPCPY1) ASPDEV(IASP_1) CRG(HYSGMIRCRG) SITE(SITE1) STGHOST(powerha ('password') ('10.60.1.1')) 
      LUN('IBM.2107-75ABC11' ('1000-1002') ('1100-1102')) STGHOST2(powerha ('password') ('10.60.1.2')) LUN2('IBM.2107-75DEF21' ('2000-2002') ('2100-2102'))

      Following this example's parameters, the command creates a copy description for the primary node containing the following information for PowerHA:
      • the STGHOST and LUN parameter values corresponding to the two DS8000 storage units required for HyperSwap. The order of the storage units does not matter in the command but the parameters and their values must match, STGHOSTmust correspond to LUN and STGHOST2 must correspond to LUN2.
      • the Global Mirror recovery domain and second recovery domain specify the connection information for each node in the CRG site recovery domain. The default value is *NONE.
   2. Create a copy description on the backup site system.

      ADDASPCPYD ASPCPY(IASPCPY2) ASPDEV(HYSGMIRASP) CRG(HYSGMIRCRG) SITE(SITE2) STGHOST(powerha ('password') ('10.60.1.3')) 
      LUN('IBM.2107-75GHA31' ('3000-3002') ('0200-0202'))

      This is required for the Global Mirror configuration.
2. Copy descriptions for the HyperSwap and the Global Mirror relationships have been created. As an alternative to the command line, use the Add ASP copy description (ASPCPYD) command screen to enter the information in through the menu. See the ADDASPCPYD command for additional information.

 
After creating copy descriptions, a configuration description is required. Configuration descriptions facilitate communication between PowerHA and the CSM controller. The communication used with the CSM storage controller takes place in HTTPS. Nodes in the cluster using HTTPS require the *SYSTEMcertificate store on the system and either:

• a valid, signed HTTPS certificate.
• or a self-signed certificate to be imported into the system.

Consult the section, Setting up secure connections for information about establishing a *SYSTEM certificate store, creating, or importing HTTPS certificates.

Otherwise, a PowerHA policy, defined prior to running the Add HA configuration (ADDHACFG) command can be implemented in your cluster. In this example, to put a PowerHA policy in place, you would use the ADDHAPCY command.

1. Add the PowerHA policy QHA_COMM_STRICT_CERT_CHECK to your cluster with the ADDHAPCY command.
   

    ADDHAPCY PCY(QHA_COMM_STRICT_CERT_CHECK) PCYDMN(NONE) QUAL('CFGD(*ALL)') *VALUE(*NO)
   
   This policy is defined to instruct the PowerHA environment to ignore the requirement to use trusted certificates.

With the certificate store and an HTTPS certificate ready or a defined PowerHA policy in place, the next step is to create an HA configuration description.

1. Enter the Add HA configuration description (ADDHACFGD) command and required parameters to create a configuration description that allows PowerHA to communicate with the CSM.
   

   ADDHACFGD CLUSTER(*) NAME(CSM1) TYPE(*STGCTL) SUBTYPE(*CSM) HOST(powerha ('password')('10.65.1.1:9559' '10.65.1.2:9559'))

   This command adds a configuration description which enables access to the CSM storage controller.

   Note

   1. The username specified on the ADDHACFGD command must have a role of Administrator on the CSM storage controller
   2. The default port number for many CSM instances is 9559. Any port number other than 443 must be added to the IP address of the host as is shown in the example above.
2. Start the CSM session by running the Start CSM Session (STRCSMSSN) command.
   

   STRCSMSSN SSN(HYSGMIRSSN) TYPE(*GLOBALMIR) CRG(HYSGMIRCRG)

   Tip

   The session name specified on the Session (SSN) parameter of the STRCSMSSN command does not need to match the name of the corresponding session on the Copy Services Manager storage controller. PowerHA automatically locates the correct session on the CSM storage controller and associates it with the PowerHA session

3. Start the CRG. Run the command:
   

   STRCRG CLUSTER(PWRHA_CLU) CRG(HYSGMIRCRG)

Results

After completing these steps, the IBM PowerHA SystemMirror for i Copy Services Manager HyperSwap with Global Mirror configuration is complete. The associated IASP is highly available for planned or unplanned site switches.

Example

Figure 1. The HyperSwap with Global Mirror configuration created in this example: