Understanding IBM PowerHA HyperSwap and SVC HyperSwap Active‑Active Storage Solutions

IBM PowerHA SystemMirror 7.1 supports the HyperSwap feature; combined with DS8800 or DS8870 storage via Metro Mirror it can implement an active‑active dual‑site storage solution, allowing Power servers and DS8870 to provide business continuity across sites.

HyperSwap originated in 2002 on the IBM System z platform together with IBM Geographically Dispersed Parallel Sysplex/Peer‑to‑Peer Remote Copy (GDPS/PPRC). Both HyperSwap and Metro Mirror (also known as Peer‑to‑Peer Remote Copy) are now mature technologies.

PowerHA HyperSwap communicates between IBM Power servers and DS8000 storage using SCSI commands. When a storage, switch, or HBA failure occurs, Cluster Aware AIX (CAA) detects the fault, triggers PowerHA to issue SCSI commands for failover, and also invokes the AIX Path Control Module (PCM) to switch paths to the remote storage.

The typical PowerHA HyperSwap cluster topology includes two cross‑site DS8800 arrays, each site hosting two Power servers that together form a stretched cluster, with redundant intra‑site networking and DWDM equipment linking the sites.

When the primary storage fails, the Power servers detect the event and initiate a PPRC failover, transparently redirecting application I/O to the storage at the other site so that applications continue without interruption; during the HyperSwap switch the I/O is briefly frozen, resulting only in non‑fatal latency.

PowerHA HyperSwap is an AIX kernel extension that originally supported only IBM DS8800 devices; starting with SVC 7.5, SVC and V7000 also support HyperSwap, enabling heterogeneous mid‑range storage to achieve cross‑center active‑active high availability.

Spectrum Virtualize/SVC HyperSwap enhances the SVC ESC architecture, supporting platforms such as SVC, V7000, V5000, A9000 and A9000R, and can create a four‑copy data scheme with VDM. It works similarly to Power HyperSwap by using Metro Mirror to synchronize data between two I/O groups.

From an architectural perspective, SVC HyperSwap adopts the HyperSwap topology: at least two I/O groups are required, each I/O group contains two nodes located in the same site, and each site provides its own vDisk. Hosts map to four SVC nodes, increasing path redundancy.

Key components of SVC HyperSwap include:

Metro Mirror/Global Mirror: data synchronization.

Global Mirror with Change Volumes: ensures data consistency during incremental sync.

Non‑Disruptive Volume Move: automatically migrates volumes between I/O groups.

External virtualization license (required for a third‑site arbitration storage).

Standard OS multipathing (ALUA mode) without special multipath software, offering greater flexibility than PowerHA HyperSwap.

SVC Stretched Cluster uses a stretched topology where one site hosts a single SVC node (up to four I/O groups) and the two nodes of the same I/O group are split across sites; the storage appears as a single vDisk to the host.

Performance-wise, SVC HyperSwap utilizes more resources (multiple SVC nodes, network paths, SAN ports) and provides independent read/write caches at each site, so a site failure does not degrade performance because the remote cache remains active. The caches are independent and are not disabled when the opposite site fails.

In contrast, a Stretched Cluster consumes fewer resources and offers fewer vDisks; when one site fails, its cache is disabled and the system falls back to write‑through mode, reducing performance and halving the host’s storage access paths.

SVC HyperSwap introduces Volume Groups (consistency groups) that can combine multiple vDisks to maintain data consistency across sites. For example, if site A fails, site B continues to serve I/O; when site A recovers, the vDisks at site B synchronize back to site A, preserving consistency.

Without Volume Groups, recovery may be impossible because unsynchronized vDisks could contain data at different timestamps. With Volume Groups, even if synchronization is incomplete, the grouped vDisks remain usable, providing a consistent state.

A HyperSwap volume consists of:

Four vDisks (thick, thin, compressed, or encrypted).

One active‑active Remote Copy relationship (managed automatically).

Four FlashCopy Maps (used for Change Volumes, managed automatically).

An additional Access I/O Group to facilitate I/O group failover.

Data flow works as follows: when a host writes to the master vDisk, the change is captured in a Change Volume via FlashCopy; the Change Volume is later written back to the vDisk and synchronized to the remote site’s vDisk through SVC PPRC. Snapshots between vDisk and Change Volume are periodically paused and resumed automatically, continuously mirroring four copies of the data.

Read I/O originates from the local site’s SVC node, while write I/O follows a multi‑step process: the host sends a write request to a local SVC node, the node caches the write and acknowledges the host, then propagates the write to its own cache and to the remote site’s SVC nodes, which in turn write to their local storage.

In summary, compared with ESC (Enhanced Stretched Cluster) mode, HyperSwap provides true redundancy and site‑aware I/O optimization, supports Volume Groups for multi‑vDisk consistency, automatically selects the primary vDisk based on I/O volume, and avoids frequent primary‑aux switches by requiring sustained I/O dominance (over 75% of sectors for at least ten minutes).

For more details and related resources, scan the QR code below to follow the official account.