Admin Alert: Four Ways To Move An IBM i Partition, Part 2

January 15, 2014 Joe Hertvik

In December, I began discussing four different approaches for moving an IBM i partition from an existing machine to a new location and the different tasks needed for each technique. I talked about using traditional system back-up and restore migration techniques last issue. This issue, I’ll focus on using high availability (HA) software to migrate a partition.

Four Ways To Move An IBM i

To review, there are four techniques for moving an IBM i partition to a different machine:

Restore the partition in place or to a new location using the same system name. This is a traditional restore where you take the old system down one night and bring it up on another system the next day.
Restore to a new location using a different system name. This technique allows you to run both old and new systems at the same time and to test one installation against the other before cutting over. This move still requires a cut-over period and it requires additional configuration.
Replicate to a different location using HA software. Working with your HA vendor to replicate your machine to a different partition and then switch over to that partition to complete the migration.
Using flash copy or another SAN technology to move a machine between connected networks. Many SANs including the IBM Storwize V7000, have flash-copy capabilities where you can flash a copy of an existing partition to another SAN. IBM‘s live partition mobility might be another example of this type of cloud-related migration.

Last issue, I covered the traditional techniques of using a full system backup and a system restore for partition migration (options 1 and 2). This week, I’ll look at using vendor HA software to migrate partitions to a different machine (option 3). Next issue, I’ll look at using SAN technology to migrate a partition (option 4).

Technique #3: Replicate to a different location using HA software.

Using this technique, you contract with a HA vendor to use their software to move your partition. Many HA vendors are now offering this as an alternative migration technique in lieu of traditional backup and restore migrations. An HA migration isn’t technically a move in the traditional sense. The gist is that you use HA technology to reduce the downtime needed to bring up a new partition.

Note: To keep the replication roles clear, let’s use HA terminology and refer to the existing partition that’s being migrated as the source system and the new partition it’s migrating to as the target system.

Here are the steps you might encounter in using HA technology to migrate an IBM i partition to a new machine.

Ready the hardware that the new target partition will be installed on. If you’ve ordered a new machine or an upgrade, install and make sure the hardware is working correctly. If you’re moving to the cloud or another existing machine (as you might do in a consolidation after a merger), make sure their hardware is ready to start hosting your partition.
Make sure your telecom lines, IP addresses, network configurations, and license keys for using your source partition in a new environment are in order. I discussed this in part 1.
Set up a basic IBM i target partition using a full system backup tape from your source system. The HA vendor may or may not want to restore all the user libraries and folders from the source system to the target system at this time (they may prefer to use their software to set up the user data). Make sure the target partition can communicate with the source partition.
Your HA vendor comes in and configures a replication instance from the source partition to your target partition and begins replication. You and possibly the vendor, run replication audits to ensure that all items are replicated from the source to the target system.
When you’re ready to bring the system up live, perform an HA switch from the source to the target system and the target system becomes your new source. You shut down the original source partition and your target partition becomes your new live source.

The big plus in using HA software to migrate a partition is time. When you’re ready to activate the new partition, the process is a relatively quick switch over rather than performing a full system rebuild, which may require you to take down your production machine for many hours.

In my shop, we’re in the middle of using Vision Solutions‘ MIMIX Availability product to migrate two partitions to other machines. While this is an in-process project, here are some of the downsides I see to using HA software for moving a partition.

Using HA software for migration is a paid service. You will have to budget for the project. If you’re buying Power systems hardware, IBM may offer you a service voucher or a TIP letter that can be used to buy services. Check with IBM or your business partner if you need financial help to use HA services for partition migration.
Your replication strategy and audits must be airtight to keep all relevant objects in sync between source and target machines. If you’re not careful with your replication lists, you could have missing or outdated objects on your target machine when it comes up as your new source partition.
The partition move could be complicated if your source partition is already part of another source→target high availability setup. You may have multiple high availability pairs to manage when you bring up the new source partition live. This can lead to additional configuration on cutover day. Make sure you plan for this situation when you contract with your HA vendor.
Watch out for user-defined objects in IBM libraries. A replication environment usually does not replicate objects in IBM libraries. IBM libraries generally start with a Q* (with some exceptions, such as QUSRSYS). If you’ve placed organization-specific objects (such as subsystems, job queues, modes, classes, output queues, etc.) in IBM libraries, these objects may not be replicated to your target system. Check to make sure that all non-IBM objects in IBM libraries are accounted for.
Make sure that IBM objects containing user data are accounted for. Some of these procedures may be handled in your switchover run book. I’m referring to things like the IBM i System Distribution Directory, which are not be replicated but need to be kept up to date. Go through your usual run book procedures as you switch machines to ensure any manual switch configurations are performed when your target partition becomes our new source partition.

Keep in mind that HA migration is a different animal from standard partition migration and you have to make different allowances when planning and executing a migration. If you’re using HA software for partition migration, be thorough and make sure everything is covered for a smooth switchover.

Follow Me On My Blog, On Twitter, And On LinkedIn

Check out my blog at joehertvik.com, where I focus on computer administration and news (especially IBM i); vendor, marketing, and tech writing news and materials; and whatever else I come across.

You can also follow me on Twitter @JoeHertvik and on LinkedIn.

Joe Hertvik is the owner of Hertvik Business Services, a service company that provides written marketing content and presentation services for the computer industry, including white papers, case studies, and other marketing material. Email Joe for a free quote for any upcoming projects. He also runs a data center for two companies outside Chicago. Joe is a contributing editor for IT Jungle and has written the Admin Alert column since 2002.