Understanding IBM’s PowerHA For i

June 12, 2017 Alex Woodie

When it comes to high availability on the IBM i platform, there are two main options: logical replication and PowerHA SystemMirror for i. While the architecture and benefits of logical replication solutions are well-established and well-known, PowerHA remains a bit of a mystery for many. We will try to shine some light on how PowerHA works, and whether it is the right choice for you.

There has been an increase in interest around HA so far in 2017, but many IBM i shops remain confused about the various options. In the first article in this HA series, we took a broad look at all of the options on the table. In this article, we’re drilling down into one of the most confusing options of all: PowerHA.

Origins Of PowerHA

The origins of PowerHA SystemMirror for IBM i stretch over decades, all the way back to the 1999 introduction of native clustering with OS/400 V4R4. While clustering didn’t take off as IBM had hoped, Big Blue kept chipping away at the technology stack and implementing core building blocks that would pay off down the line, including i5/OS V5R1’s introduction of independent auxiliary storage pools (iASPs), which is the heart of PowerHA today.

The iASP is the heart of the PowerHA product. (Image source: IBM PowerHA Basics chart.)

In the early 2000s, IBM Lab Services in Rochester, Minnesota, started offering the System i Copy Services toolkit, which used technologies like GlobalMirror, MetroMirror, and FlashCopy to replicate the contents of iASPs running on external disks, namely the TotalStorage DS8000 line of high-end storage area networks (SANs). Eventually, IBM productized the offering with the introduction of a switched-disks, dubbed cross site mirroring (XSM), that worked with the DS8000.

This XSM product, which was loosely based on the High Availability Cluster Multi Processing (HACMP) technology that IBM supported on RS/6000, pSeries, and System p Unix servers, eventually morphed into High Availability Solutions Manager (HASM) with the launch of IBM i 6.1 in 2008. At some point, before the launch of IBM i 7.1, HASM was reborn as PowerHA SystemMirror for i.

Development didn’t stop there. In 2013, IBM bolstered PowerHA by adding support for LUN-level switching on Storwize V7000 and SAN Volume Controller (SVC) arrays, in addition to the big DS8000s. In 2014, it added support for HyperSwap. And earlier this year, it officially rolled out another PowerHA option called Geographically Dispersed Resiliency.

HA And DR

“PowerHA is a shared storage clustering solution,” says Steve Finnes, worldwide product offering manager for PowerHA. “It’s a first cousin of PowerHA on AIX. Fundamentally the shared storage architecture has active operating systems on all the nodes in the cluster, so you can do all sorts of outage management, planned and unplanned, software upgrades and so forth.”

PowerHA supports a variety of high availability and disaster recovery topologies. (Image source: IBM PowerHA Basics chart.)

PowerHA today provides customers with a range of storage and replication options in support of a variety of high availability and disaster recovery architectural topologies (see graphic above). This also allows users to exploit the benefits of synchronous and asynchronous connectivity, which basically enable high availability and disaster protection, respectively.

Customers can use it like a straight-up switched-disk solution – with all data resident on a single SAN connected to multiple application servers and switched via LUNs – as it was originally designed. This provides high availability against outages on the IBM i processing node, but not disaster protection.

Secondly, they can use Metro or Global Mirror to replicate the production SAN data to a secondary local SAN, and switched on and off with LUN-level switching. This setup would use synchronous replication to ensure no data loss in the event of a SAN outage, but doesn’t protect against a site disaster.

A two-SAN setup could just use Global Mirror to asynchronously replicate data to a remote SAN, which would protect against a site outage but would not provide HA. Or it could use LUN-level switching on the primary SAN (providing HA protection from IBM i server outages) with Global Mirror used to replicate data to a second remote SAN, thereby providing enough geographic distance to protect against a site disaster.

A three-SAN setup across two sites could be set up this way: The primary SAN replicates data via Metro Mirror to a second SAN (providing HA). The second SAN in turn sends data asynchronously via Global Mirror to a remote third SAN (providing DR).

Lastly, customers can keep PowerHA confined to internal disk, and using the IBM i-based geographic mirroring protocol to replicate data to a second IBM i server.

“PowerHA is comprehensive and mission critical,” Finnes says. “In the IBM i world, it’s standard to have a multi-site cluster setup. Nearly 100 percent of my customers have at least two sites in their cluster configuration.”

PowerHA Editions

While it is spoken of as a single entity, PowerHA is actually a collection of various high availability and disaster recovery technologies, each of which brings its own capabilities and benefits. There are three main PowerHA SystemMirror for i packages:

PowerHA Standard Edition: Designed primarily for internal disk implementations (but can be used with SAN or direct-attached arrays). Uses the IP-based geographic mirroring protocol to replicate iASP data from one server to another. PowerHA workloads run on the IBM i server, not the SAN. Primarily used by shops with less than 4 TB of production data. When used with a SAN, supports FlashCopy to create superfast tape backups.
PowerHA Enterprise Edition: Includes everything in Standard Edition. Designed for SAN-based replication; PowerHA workloads run on the SAN, not the IBM i server. In a campus setting, synchronous Metro Mirror replicating delivers a recovery point objective (RPO) of zero, while asynchronous replication over Global Mirror provides support for three geographically dispersed sites.
PowerHA Express Edition: Adds support for HyperSwap, a mainframe technology that uses Metro Mirror’s peer to peer remote copy (PPRC) protocol to replicate data among SANs and provide for a nearly instantaneous role swap.

While there are many flavors and options, the core underlying principal and core enabling technology of PowerHA remains the same: iASP. At its heart, the capability of a server to switch from iASP to another iASP is what powers the various resiliency offerings that IBM sells under the PowerHA banner.

Pros And Cons

Every single piece of data that goes into the primary iASP gets replicated to a secondary iASP, which can sit on a SAN, on a direct-attached storage array, or on internal disk. Other important pieces, like user profiles, remain in *SYSBAS and are managed in the admin domain. In the event of unplanned outage, PowerHA’s heartbeat monitor will detect a problem, and initiate a failover. All of this can be managed from a single screen in PowerHA.

PowerHA supports both OS-based and storage-based data replication. (Image source: PowerHA SystemMirror for IBM i Cookbook.)

Because PowerHA is sending much more data over the network compared to logical replication, it requires a much bigger network – about four times the size, according to Matt Staddler, who sells and implements PowerHA and Maxava‘s logical replication solution at IT Solutions Group.

“When you’re doing logical replication, you’re replicating bits of data. If I change the zip code or something, I’m only changing a few characters,” Staddler tells IT Jungle. “With PowerHA you’re replicating a 4 KB block. For that same zip code change, in the PowerHA world, I’m going to send over multiple 4 KB blocks.”

While the network costs will be higher, the personnel costs will typically be lower for PowerHA. That’s a side effect of having basically everything in the IBM i environment flow through the pipe. With logical replication, the HA software must be configured to replicate a new file that’s been added to the database, whereas that’s not necessary with PowerHA. Out-of-synch conditions, a bugaboo in the logical replication environment, aren’t common in PowerHA.

“It takes literally no time to manage the product,” Staddler says. “It’s as close to set it and forget as you’ll see in an HA environment.”

To use PowerHA, a customer’s IBM i applications must be iASP enabled. This is a sticking point for some customers. SAP and Oracle have done a good job supporting iASPs with their IBM i-based ERP systems, according to Staddler. But some packages are not iASP enabled, including Infor, whose ERP XA (MAPICS) software is having trouble applying PTFs in an iASP environment, and therefore should not be used there, according to Staddler.

There’s another big caveat to geographic mirroring in PowerHA that must be mentioned: replication has to stop during a backup. So if the full system backup to tape lasts five hours, a customer is potentially exposing five hours’ worth of data. This situation is alleviated in PowerHA Enterprise Edition thanks to the FlashCopy function.

Misconceptions And Growth

While PowerHA has a reputation for being a SAN-only HA solution, that’s actually incorrect. In fact, the vast majority of PowerHA installs conducted by IT Jungle‘s Doug Bidwell’s Southern California consulting firm, DLB Systems Associates, involve internal disk and geographic mirroring.

Enterprise-grade PowerHA features like HyperSwap, GDR, and LUN-level switching may be used by the Fortune 500, but most customers don’t use those features. For most IBM i shops, geographic mirroring of iASPs running in direct-attach disks has become a real alternative to logical replication. This appears to be the setup that is fueling PowerHA’s growth.

While PowerHA has a long history and 2,000 installations by 2013, it really wasn’t until 2015 that the product became rock-solid enough for widespread use in the IBM i installed base, Finnes told IT Jungle at last month’s COMMON show.

Staddler seconds the notion. “We’ve been working with PowerHA from 2013 roughly,” he says. “Whenever we see a product, we want to make sure it’s ready for prime time. Finnes kept bugging us to become a partner. We said ‘dude, it’s not ready for prime time.’ Then around 2015 – it was with IBM i 7.1 –we tested it again, and at that point, it was rock solid. It’s a great product now.”

This Issue Sponsored By

Table of Contents

Content archive

Recent Posts

Subscribe

Pages

Search