Recovering from a HyperSwap failover

This scenario shows how to recover from a HyperSwap failover in a HyperSwap environment with Global Mirror

Before you begin

This scenario uses the configuration created in the Configure HyperSwap with Global Mirror using Copy Services Manager (CSM). Review this configuration before proceeding with this failover recovery operation.

In order for the failover operation to successfully resume the Global Mirror replication:

• clustering must be active on the node that currently owns the IASP. Active clustering is required for recovering from this failover.

For the failover operation to recover HyperSwap protections, these conditions must still exist:

• all disk units in the IASP must be configured for the HyperSwap relationship.
• all of the HyperSwap relationships in the IASP must be synchronized.
• every HyperSwap relationship in the IASP must be replicating in the same direction. All disk units must have the same primary DS8000.

If these HyperSwap prerequisites are no longer in place, the failover operation may not recover properly.

About this task

In this scenario, the data on DS8000 A is configured for HyperSwap. All disk units in the IASP on DS8000 A correspond to disk units in DS8000 B and are linked across a synchronous connection. Both storage units are attached to the IBM i system named NODE_1. In addition to being configured for HyperSwap, the IASP also is configured for Global Mirror to a DR site with DS8000 C and a separate IBM i DR called NODE_2.

A failure of one DS8000 storage device takes place triggering a failover to the other local DS8000 with minimal downtime.

Procedure

The diagrams below depict the stages of a HyperSwap failover in an environment with Global Mirror replication.

1. Begin with the environment in normal operation as described above.
2. When an unplanned storage failure occurs, the system will automatically switch to use the secondary IBM System Storage Device as the primary. In this scenario from DS8000 A to DS8000 B
3. After the HyperSwap failover completes, the primary storage device will be the DS8000 B. PowerHA will attempt to keep the Global Mirror replication with the primary storage device. However, a successful the Global Mirror link connection to the new primary depends cluster activity.
   • If clustering is active the Global Mirror link is moved from DS8000 B to DS8000 C.
   • If clustering is inactive, the Global Mirror link is moved when clustering is started.
   • If the Global Mirror link is unable to be moved when clustering is started (for example, due to the CSM being down), the Global Mirror link is moved as part of the CHGHYSSTS *START operation.
4. After the failover operation completes and the failed storage unit, DS8000 A comes back online, the HyperSwap relationship must be restarted. Use the Change HyperSwap Status (CHGHYSSTS) command to restore HyperSwap protection.

   CHGHYSSTS OPTION(*START) NODE(*) ASPDEV(*ALL)

   This command restarts HyperSwap replication with DS8000 B as the primary.

Results

The HyperSwap relationship is restored after running the CHGHYSSTS command.