AIX in the cloud is now a “thing”.
When moving your AIX workloads from on-prem to the cloud, there are two big-ticket items to initially consider for planning and execution:
- Mapping Resources from on-prem to the cloud equivalent
- Techniques for the actual movement of the images
Mapping Resources
First, get a list of all the LPARs that are candidates for migration and capture the essential attributes like CPU allocation, memory, storage , IOPS, and expected network bandwidth required for each server. If you attempt to do a straight “lift and shift,” you may or may not be able to do an exact mapping in a pure self-service model. Why? Because cloud vendors typically have “safety caps” on some resources that prevent an untrained cloud user, or a run-away automation script from doing unwanted actions.
Look at your list, are there LPARs that stand out in either the number of resources or size? For example, do you have an LPAR that has 100+ disk volumes attached to it? Or a single disk volume that is defined as 8T? Or a server that is assigned 1000GB of memory? For the items that stick out, you will want to check with your cloud vendor on how to handle those properly.
The cloud migration might be an opportunity to do some cleanup. In one project, there was a customer that over 100 disk volumes assigned to an AIX server that had “accumulated” over time. Upon inspection, only a fraction of the total storage space was used, so the filesystem was able to be right-sized, and the number of assigned disks drastically reduced. The cloud vendor also had a 50 disk “default cap” in place per individual server. The cloud vendor would have let the customer “lift the cap” to 100, but in this case, just right-sizing the storage allocation solved the problem.
The default caps imposed by the cloud vendors are a “good” thing. In the cloud, there are “dozens” of tools and automation approaches that can be applied when provisioning servers or complex environments. Tools like: Chef, Puppet, Ansible, Cloud Vendor Rest-API, and Terraform are a few examples. So even though the guest OS is AIX, other VMs running Linux, Windows, or even VMs running on-prem, can be used to run automation scripts to create and configure AIX LPARs in the cloud.
Take for example this small snippet of pseudo code:
count = 0
i = 1
while i == 1:
…..{do commands to create a disk on a server}
…..count += 1
Do you see the error? The value of “i” is never incremented, so an infinite loop is created. That is why the default caps imposed by the cloud vendors are good. They are there to protect you from yourself. Another idea might be to use the cloud vendor’s “quota system” to impose reasonable limits while you are testing any automation. A quota will just provide another safety rail you can use while creating/debugging automation scripts.
Techniques for Moving Images and Data
The next big-ticket item to consider is how you will create cloud-based images. There are two main possibilities:
- Re-create them from “scratch” using a base bare-bones OS image
- Transfer in use images from on-prem to the cloud
Re-create from scratch
In this approach, you provision in the cloud a “bare bones” AIX LPAR with an OS image like 6.X or 7.X. This is just like creating a new LPAR right from the original OS media. Most of the cloud vendors will have “standard images” baked into their system that you can access from your account.
For this option, nothing from on-prem is included by default. You have to re-configure, re-load, re-install all your settings and software. If the application system running on the LPAR is simple and runs somewhat self-contained once in the cloud, then this might be an option. Or if you are planning to do “clean up” and “right-size” your servers as they move to the cloud, this might be the way to go. Everything will be recreated clean and optimal. The downside is that it will probably take a little bit of effort to create.
Transfer images from on-prem
If you take this path, you are going to attempt to “import” an AIX OS image from an on-prem server and have it run as-is in the cloud. Once booted, your rootvg will be just like it was on-prem and possibly all the volume groups with your data. Here are two paths that are possible, though each cloud vendor will have a unique approach:
a) mksyb / Nim Server
With this option, you use your existing mksysb backup images as a starting point. In the cloud, you create a utility LPAR running in your account with the Nim Server running on it. Then you upload all your mksysb files for other LPARs to that Nim Server in the cloud. Then you use standard Nim Server procedures to restore the mksysb / spot images over the top of empty LPARs also created in your cloud account.
After the rootvg is restored from the mksysb, you have to re-provision the required disks for each LPAR, and then upload the data back into the right files systems. The cloud vendors typically have several options for importing copies of application data. The common approach is to “upload” the data over the network. If the volumes are large, vendors have encrypted NAS disk arrays that they can send you. You copy all your data onto the device, then ship it to the cloud vendor’s data center, where it is copied into an intermediate storage location. From there, you can copy back down to your individual AIX LPARs.
b) Use vendor supplied technique
In Skytap (where I work as previously mentioned in other articles), we have a technique that is specific to our cloud. We have a script that will perform an “alt_disk_copy” of the rootvg, and then create Unix based ‘dd’ disk images of your data volumes, and then create an industry-standard “ovf” file of all the components. Then you upload that blob to the Skytap web portal, and behind the scenes, the LPAR is recreated from the pieces.
The approach described above can be a good alternative if you have a lot of small to medium-sized AIX LPARs. If you have giant disk volumes, this path is more difficult since the process is making image copies of all the disks.
SPECIAL NOTE
This is the “cloud”; it is not “server rehosting”. Depending on what vendor you choose, there will be different options available for importing/re-creating your original workload. But there is one word of warning. You will not be able to manipulate the cloud vendor’s back-end system that they use to create the virtualized AIX LPARs that are provisioned in your account. You won’t be able to hook up to the cloud vendor’s HMC or PowerVC infrastructure. You will only get access to the “provisioned LPARs” using their exposed portal mechanisms, but not the tooling behind the scenes that creates virtual LPARs from scratch.
One alternative to this is if you attach your on-prem network to the cloud vendor via a “direct connect” or VPN, then you will be able to see the LPARs running in the cloud as just another subnet from your on-prem network. So for example, it might be possible to use your existing on-prem Nim Server installation to manipulate an LPAR in the cloud. The Nim Server will see the cloud LPARs as just other servers no different than those on-prem.
Summary
There are some things to consider once you begin the path of moving your AIX workloads to the cloud. In addition to re-creating equivalent resources, you have to consider how to migrate your server images along with the data. Pick a strategy and do a test run against one single LPAR so you can discover all the unknowns. Once you have a system worked out, you can do a mass migration of all your LPARs.