Migrating LPARs to the Cloud

Rob McNelly April 26, 2022

Today I want to talk about migrating LPARs to the cloud.

Where are you on your cloud journey? Have you just begun thinking about it? Are all of your systems currently running in the public cloud? Are you running a proof of concept or some test and development machines in the cloud? Have you decided against the cloud altogether and for now you are choosing to run your LPARs in your own data centers? Even when you are running your own machines in your own data centers, there can be advantages to thinking of your own environment as a private cloud.

There are arguments to be made for whichever choice you have decided to pursue, but isn’t it nice that there are so many options to consider with Power Systems? As more public cloud providers and managed service providers offer Power Systems servers for customers to run their AIX and IBM i workloads on, that ultimately gives you more choices around where you end up running your applications.

Whichever physical location you choose, if you end up moving LPARs to another data center, you will have some choices around how you move your applications and data to get it running somewhere else. For many of us, this is nothing new.

For years admins have been setting up secondary disaster recovery locations, configuring replication between data centers, and migrating to completely new data centers and different colos for much of our careers.
On the other hand, some companies have a single machine running an application on a single server in a data center, while others have a machine running in a closet somewhere that seems to magically manage itself.

It is hard to come up with a one size fits all solution or recommendation as so many customers have so many different problems they are trying to solve.

If you are not comfortable tackling this type of project on your own, you could engage IBM Lab Services, or you could ask your IBM Business Partner to help you.

IBM published a document that gives several ideas and methods you could consider when you are ready to migrate your LPARs, maybe some of them can be incorporated in your plans as you think about your organization’s changing requirements.

Although this document is geared toward migrating to IBM’s own Power Cloud offering, many of these same techniques could be considered when moving between any two data centers, including two that you manage yourself, it does not have to be a cloud migration in order to consider these options.

The document mentions things like using IBM Cloud Object Storage, which can be used as an intermediary location to store your files. Think of this as an NFS mount point or some other storage solution you are using today where you can just copy your files. This is a great place to store your mksysb or savevg or OVA files before you are able to fully restore them to your new LPAR.

Mass Data Migration is a solution where you get an actual physical device hooked up in your existing data center, you copy your data to it, then you physically ship that device to the cloud data center where it can be copied to your target LPAR. Think of it conceptually like a removable USB drive you would use with a laptop for example. If you have massive amounts of data this might be an option to speed things up compared to trying to copy it all over a network. Sometimes a truck with a bunch of tapes is faster than a network transfer will be.

PowerVC OVA images could come into play if you are already running or plan to set up PowerVC in your environment. You would create your OVA image, copy that image to the cloud object storage, then use that image to deploy it to your new LPAR. Again, depending on network speeds and sizes of the image you are copying across the network this method could take a while.

The document touches on replication software that you would run in your LPAR like GLVM, or you could rely on application-level replication like Db2 HADR or Oracle Data Guard, or possibly even a simple rsync command.
There is also a section of the document that covers IBM i specific strategies including using BRMS, or geomirroring.

There are pros and cons to each of these methods. Some are much simpler than others, but depending on how long of an outage window you can get, or if you can get one at all, will help determine which option you choose.
A massive critical database with clusters of application servers will obviously require much different migration approaches compared to a small simple LPAR that can withstand a longer outage window.

The benefits of getting out of managing your own traditional infrastructure can be tremendous, but in order to have successful projects, it will require thoughtful planning, for some of you this is all a review of options you have already considered, but hopefully for some of you this is all food for thought.

As always, I appreciate your time, and thanks for watching.