Firstly, for something to be considered highly available it needs to be available “five nines” or 99.999% of the time, suffering less than 5 minutes downtime a year. Any figure larger than this and the application or service is not deemed to be highly available.
There are two distinct types of HA for IBM Power Systems running IBM i and these can be neatly categorized into hardware and software-based solutions.
Hardware-based solutions for IBM i include products such as PowerHA or LPM (Live Partition Mobility) both adopting an active/passive approach.
Software-based solutions like Maxava HA are almost exclusively based on remote journaling, an intrinsic part of the IBM i operating system since 1998. Remote journaling was introduced by IBM several years after local journaling and was designed with high availability in mind after several large environments started to voice this type of requirement for critical applications.
Hardware
IBM i running on IBM Power Systems is classed very much a modern server, and a steady increase in the utilization of external storage has been a factor in more hardware-based solutions being implemented for the platform. PowerHA, a popular choice especially with customers running smaller IBM Power Systems, is based on clustering technology, and is integrated with the operating system by way of a licensed program (5770-HAS) to provide protection for both data and applications. PowerHA is based on IASPs (Independent Auxiliary Storage Pools), and all application data must reside in an IASP for PowerHA to be able to protect and manage it. As a result, before implementing PowerHA you must migrate your data from *SYSBAS to an IASP. This task requires careful planning and should be conducted in association with 3rd party software providers, many of whom have published procedures on how to perform this migration. This switchable IASP is then “owned” by one of the two nodes in the cluster, and although both nodes can be active the data is only available to one. Users of PowerHA find this an attractive feature as it allows for maintenance without downtime to be conducted on the node that doesn’t currently own the IASP.
It’s worth noting that not everything on an IBM i can reside in an IASP, in fact there around 36 object types that can’t – they must continue to live in *SYSBAS, and while many of these objects are quite obscure, some are commonly used, and this can present a challenge to environments. With PowerHA there is a concept called the Administrative Domain where some of these objects can live, although not all. The Administrative Domain is extremely basic and does come with some limitations in both use and the number of objects that can be handled while maintaining consistency between the nodes in the cluster. You may also find that you will need to write some code to interface with the Administrative Domain in order automate some tasks that are intrinsic to software-based replication.
There are several different options with PowerHA:
Geographic mirroring, where the replication is done by the IBM i itself as opposed to the external storage and is designed for environments that typically have less than 4 TB of data. Geographic mirroring offers either synchronous, meaning both copies are identical and is designed for distances between the nodes not exceeding 30 kilometers, and asynchronous intended for larger distances at the expense of not having as current of a recovery point.
For those using external storage the options include Metro Mirror, which is a synchronous solution, meaning both copies of the data in the IASP are identical, and Global Mirror for those looking to replicate to up to three geographically dispersed locations where larger distances are involved. The latter being an asynchronous solution.
Hardware-based solutions like PowerHA require little day-to-day monitoring and can be an attractive option for those who have worked through the general malaise of migrating their data to an IASP.
PowerHA does not provide a mechanism for you to have your data visible on any other node other than the current “owner”, so tasks such as backups, reporting or BI will have to be conducted on the production server, potentially impacting system resources and requiring downtime windows.
An increasingly common mix in the IBM i user community is combining both hardware and software-based HA solutions, for example using PowerHA within the data center, along with a software-based logical replication tool like Maxava HA to get a copy of the data out of the data center and onto a partition in a co-location or the cloud for disaster recovery, backup, reporting or BI purposes.
Software
Software-based solutions in the form of logical replication do not require external storage or IASPs, although both are fully supported by Maxava HA, and are instead built upon remote journaling. This integral part of the IBM i operating system is both reliable and extremely efficient. While some software solutions utilize the IBM i Audit Journal (QAUDJRN) as a foundation for high availability, Maxava adopt a different approach. The primary use of the Audit Journal as the name itself denotes is auditing and security and using it for high availability can have an unwelcome impact on the source server’s resources such as CPU, plus in busy environments the audit journal can be a potential bottleneck causing a delay in transactions being processed and sent before being applied to the target machine, leaving you potentially exposed. Maxava’s innovative command intercept method has been designed to remove much of the resource required to maintain high availability away from the source server with most of the processing taking place on the target server, away from the production workload. Mavava’s compute requirements on the source server is negligible when compared to some other software-based high availability solutions.
Maxava’s software-based HA solution can replicate pretty much everything on IBM i including Db2, the IFS, IBM MQ and QDLS. It also provides the capability to conduct simulated role swaps that turns the target server into a simulated source server for testing purposes without impacting the source production machine or the user base. Self-monitoring and self-healing elements are also included as standard and designed to minimize day-to-day checks performed by System Administrators.
Software-based solutions can operate in either synchronous or asynchronous modes. Synchronous normally for environments which are physically close where an acknowledgement is received before the next transaction is processed, while the asynchronous mode can tolerate longer distances between the source and target partitions and is better suited to co-location, or the on-prem and cloud hybrid architecture mix. Asynchronous is generally faster as the remote journal communication transfer is initiated at the same time with the assumption that it will be successful, with verification and acknowledgment afterwards.
The flexibility offered by software-based HA solutions is evident and while it has a history of being used on-premise, it can also be utilized in the cloud, between on-premise and the cloud or increasingly popular as the engine for DRaaS to the cloud. Whatever your present and future IBM i environment looks like, software-based replication with Maxava HA fits.
This article is written by Ash Giddings, Product Manager at Maxava
