Admin Alert: Five Benefits of a High-Availability System

November 7, 2007 Joe Hertvik

I recently wrote a column describing i5/OS features that enable high availability functionality in your shop. This week, I’m narrowing the focus and discussing five benefits you can realize when installing a Capacity BackUp System (CBU) for System i failover in case of disaster. Some of these benefits are to be expected, but others might cause you to rethink your idea of a CBU and what it provides.

What Is a CBU?

As I described in my earlier piece, a CBU is a specially configured System i machine or partition that communicates with your main production box and replicates production data and applications through the use of high availability software installed on both machines. When configured correctly, the CBU duplicates your production system and, in the event of a disaster that takes out the main production box, the CBU can be switched over to “impersonate” the production box, and service your users, devices, and companion servers, with very little downtime. When the main production machine comes back up, the CBU can relinquish its role and production is switched back to the regular system.

While the benefits of a CBU as an understudy system are pretty well understood, a CBU system offers a number of other benefits, many of which depend on its ability to duplicate the database on your main system. In no particular order, here are five other benefits that I’ve realized in running a CBU.

Replacement for a Disaster Recovery System–Because a CBU is its own ready-to-go disaster recovery environment, a fully tested CBU system should automatically replace your disaster recovery contract and testing. If you co-locate your CBU at an off-site location that your organization already owns, such as a sister division, the cost of the CBU might be offset somewhat by the loss of your disaster recovery contract. But if you need to co-locate your CBU at an outside vendor center that is specifically set up for high availability, you may wind up replacing one lease for another.
Using the CBU as a Data Warehouse–This is a tricky proposition, but since the CBU contains up-to-date replicated copies of your entire database, you can theoretically use it as a data warehouse in order to reduce the strain of users and companion servers accessing data on your production box. This valid technique does have one downside: If and when you need to failover to the CBU and use it to impersonate your production system, your users and companion servers may lose access to the data warehouse on the CBU because the CBU machine will not be available as itself (domain name and IP address) while it’s impersonating your production system.
Possible Elimination of Maintenance Outages–A number of companies are not limiting CBU failover usage just to disasters. In some cases, a company may choose to failover to the CBU when performing production box maintenance that might cause your source system to be out of commission for a longer period of time. So if you decide to install a CBU and you’ve perfected your failover strategy so that you can change machines in a short period of time, you have the option of keeping your production applications and data available while you perform system maintenance or a system upgrade. I’ve even heard stories of some larger institutions that regularly cycle processing between the production machine and the CBU, leaving the CBU up for several days or even for a week at a time while they perform other work on the production box. Once you are able to failover to the CBU with relative ease, using the CBU for scheduled downtime becomes another valid option.
Increase Production Uptime by Eliminating (Almost) All Daily and Weekly Backups–If your production box needs to be available on a 24×7 basis, you can almost eliminate your backup window by taking your database and application backups from the target CBU box, instead of backing them up from your source production System i. Even if you are running a “save-while-active” backup, your saves can benefit by saving your data on a completely quiet system where all the databases are synchronized with each other and no updates are occurring. And while the daily, weekly, and monthly saves are being performed over your replicated CBU data, your production system can keep churning away without any interruption at all, providing pure 24×7 access. If you decide to use this approach, however, keep in mind that you will need to use the same type of backup media device on both the source and target machines so that you can freely restore files backed up on one machine to another machine. The other item to note is that this technique will not eliminate source system backups all together. You will still have to take a comprehensive backup on your source machine eventually, in case you need to restore the entire machine after a crash.
Rethinking the Idea of Off-Site Storage of Backup Media–Setting up a CBU as a backup machine can change your idea of how you treat backup media storage. Most sensible recovery scenarios and auditors require you to store backup media off-site so that you can still recover the data in the event a disaster takes out your whole data center. But how does that strategy change when you’re backing up your data on a CBU machine that is co-located in an entirely different location? Do you need to store your backup media off-site when the CBU you’re backing up from is already located off-site? Can you store your backup media in the same location as the CBU? A clever person might even make the argument that with a co-located CBU, you might not need to perform backups at all because the data is already stored in two different locations. I’m not an auditor but I would be interested in understanding what kind of backup media management policy auditors are recommending to their clients who want to use their CBU as a backup box. If anyone has any information or thoughts on this topic, please feel free to email me and I’ll be glad to print your comments in an upcoming column.

So as you can see, there are some benefits to running a CBU that extend beyond the its central purpose in life: backing up and replacing your production box in the event of an emergency. A CBU opens up some new ground in your shop, and it’s worth taking a little bit of time to understand everything it can do for you.

Correction: Adding Another System i HA Vendor to the List

In my Admin Alert on The System i High Availability Roadmap, I mentioned the different high availability solutions offered by Vision Solutions (MIMIX HA, iTera HA, and ORION HA) as well as the DataMirror products offered by IBM. However, Bruce Lesnick of Bug Busters Software Engineering wrote in to remind me that Bug Busters also offers System i HA in its latest version of its Remote Software Facility package, RSF 8.1. So if you are looking for HA solutions for your System i box, be sure to add Bug Busters RSF to your evaluation list.