IBM Pulls Back The Covers On Migrate While Active
January 13, 2025 Alex Woodie
Last month, IBM began selling subscriptions to Migrate While Active, a new offering designed to speed and simplify the migrations of IBM i workloads from customers’ on-prem installations to Power Virtual Server running in IBM Cloud. Big Blue also last month hosted an online Guided Tour webinar that provided some much-needed answers to questions about the new offering.
IBM launched the Migrate While Active in late October, a couple of weeks after unveiling the latest Technology Refreshes for IBM i 7.4 and 7.5. IBM didn’t provide a lot of initial information on the new offering, which was designed to allow customers to continue running their IBM i workloads while they migrate their data to PowerVS.
We did know some things about Migrate While Active, which became generally available on December 13, primarily that it’s based on Db2 Mirror, the continuous availability product that IBM launched with IBM i 7.4. We also knew that, while it leveraged Db2 Mirror’s replication mechanisms, Migrate While Active would not require the pricey RoCE adapters that provide ultra-fast connections between IBM i systems in a Db2 Mirror cluster, and that it could use standard TCP/IP connection over any distance (as opposed to the 10 kilometer limitation of Db2 Mirror)
But a lot of questions remained, including why IBM created the product, would it require a full Db2 Mirror license, what IBM i objects did it not support, and did users have to be PowerVS customers? IBM provided answers to these questions, and more, last month with a Guided Tour on Migrate While Active. The Guided Tour, which you can access here, was hosted by Kris Whitney, the Rochester software engineer who leads the Db2 Mirror development team.
IBM developed Migrate While Active to address challenges that IBM i customers experienced in migrating their production IBM i systems to IBM Cloud and PowerVS, Whitney said during the Guided Tour. One specific problem that has bedeviled IBM and its would-be cloud customers is: How do you get your data into the cloud?
“By far, the number one question we get, is ‘Can I send my tapes to IBM?’” Whitney said in the Guided Tour. “There is no service that we offer today to send your tapes via courier or any way to restore your system [via tape] to the IBM Cloud.”
The second most popular question is a variant of the first: Can I just hook up my IBM FlashSystem to the IBM Cloud and use Global Copy or Global Mirror to move my data into PowerVS? The answer to that is also no, Whitney said.
“Currently there’s no way to do that,” he said. “Yes, we do have FlashSystems in the IBM Cloud. But the challenge is they’re multi-tenant FlashSystems, and the replication between two Flash Systems is not multi-tenant. We can’t just hook them up and replicate your storage, so we’re kind of left with a save-restore type methodology.”
Instead of duplicating their on-prem environment, Whitney said, IBM has found that most IBM i customers moving to the cloud want to create their new IBM i environment from scratch, AKA perform a scratch install. In a typical scratch install, an IBM i customer will take quite a bit of time to save and restore their data – and test it – before switching over to the new environment.
The challenge with this type of scratch install is that it can take a long time, and can have a lot of downtime associated with it. During the days or weeks that it takes to restore and test the data, the production IBM i system will keep on running, creating more changes that eventually need to be saved and restored to the new cloud environment.
“So you can repetitively do that process of save restore, but you’re never going to get your window super small,” Whitney said, “So that’s been a challenge there. Media has been another challenge. There’s no D-mode way to do a scratch install. You have to use a network install-type methodology.”
IBM Cloud customers have typically used two types of virtual media to migrate their data to PowerVS and then perform the network install, via an NFS server living in IBM Cloud, Whitney said. Virtual optical is handy for booting and performing a scratch install, he said, whereas virtual tape is more scalable and uses bandwidth more efficiently thanks to compression and dedupe capabilities with IBM’s Aspera or VTL appliances from FalconStor or DSI.
And therein lies the rub: A veritable smorgasbord of different ways exist to move data into the cloud. Each has its advantages and disadvantages, but when you add it all up, it’s a confusing mush.
“There’s probably 20 to 50 different variants of how you could move data to the cloud,” Whitney said. “The problem we have is there’s too many choices, and there’s not a single pattern that we can follow and do it repetitively.”
And that is the number one goal of Migrate While Active: To provide a single way to migrate to PowerVS, in a manner that is efficient, performant, and straightforward as possible, with as little downtime as possible.
IBM claims that Migrate While Active can reduce the amount of downtime associated with a PowerVS migration from days or weeks to mere minutes or hours. That allows IBM i customers to keep their production systems running as they move to IBM’s cloud.
With that said, there is still downtime with Migrate While Active. In fact, there are two episodes of downtime: One at the beginning of the migration to create the checkpoint, and one at end to synch the source and target nodes.
And while Migrate While Active was developed to provide a single tool and method for migrations, IBM still gives customers some flexibility to use other methodologies and tools with the process. For instance, users can rely on VTLs to perform the initial data replication, and then rely on Db2 Mirror for the updates. They can also use remotely mounted optical servers to perform network installs.
“We’re trying to reduce the production downtime. We’re trying to produce automation that guides you through this,” Whitney said. “This will not be a 100 percent automated process. There are things in here…that are very hard to automate. So this is more of an assisted, guided path …where we’re going to automate what we can automate, and then we’re going to help guide you through the parts of it that we can’t automate.”
IBM i data estates that are 2 TB to 3 TB or less may be fine using Migrate While Active’s native replication method, depending on available network bandwidth. But for anything above 10 TB, the efficiency that VTL brings with compression and dedupe really helps, Whitney said.
Some customers might wonder if they can use their existing monthly backup (a full system save) for the initial save in Migrate While Active. “The answer is no, because we have to have a checkpoint of when we take the system save, because that’s when we’re going to start tracking changes that we’re going to sync to the cloud,” Whitney said.
Whitney pointed out that Migrate While Active doesn’t use IBM journaling to replicate data. Instead, it leverages an asynchronous data replication method from Db2 Mirror that is based on “tracking lists,” which minimizes the amount of storage required.
“These tracking lists don’t use a lot of storage relative to using journaling,” Whitney said. “We’re very efficient, relatively speaking, to journal-based system, where you have to track every change in a sequential order.”
One caveat to this approach is that the data is incomplete until the replication session is ended. That makes Migrate While Active worthless from a disaster recovery perspective. “This is not a DR solution; this is a migration solution,” he said. “We’re not trying to keep everything in lockstep while we’re migrating it.”
IBM developed a GUI to help Migrate While Active customers manage their migration process. The GUI, which can run either on the source or the target node, allows users to kick off migration processes and monitor the process. The GUI is important because, while Migrate While Active is mostly automated, there are certain steps that must be done manually, especially when the system is in a restricted state.
IBM also provides a greenscreen interface for Migrate While Active. And because there are a handful of new SQL Services created in the Db2 for i database as part of Migrate While Active, customers can always resort to calling those services directly, or even automating them via programmatic means or through a framework like Ansible.
While Migrate While Active is a Db2 Mirror product, it does not require customers to license the full Db2 Mirror product. IBM has rejiggered its Db2 Mirror licensing to account for the new Db2 Mirror product (i.e. Migrate While Active). Customers can now license the Db2 Mirror base product (5770-DBM 5050) at no charge, and then select either Option 1 – Continuous Availability (5101) or Option 2 – Migrate While Active (5102).
IBM offers several subscription offerings for Migrate While Active, which it licenses on a per-core basis. For instance, customers can get a 90-day subscription for $700 per core, or buy a one-year subscription for $2,000 per core. It also offers a 28-day test period for customers to play around with it. IBM i customers can also use $2,000 in earned cloud credits to play around with Migrate While Active.
With Migrate While Active, IBM has taken an existing product (Db2 Mirror) and adapted it to do something else. As IBM’s product manager Whitney made evident, there will be changes to Migrate While Active as well, as IBM figures out how customers are using it and makes adjustments accordingly.
You can access the recorded Guided Tour on Migrate While Active at this link. You can also access more information on the product at the IBM support site.
RELATED STORIES
IBM Unveils ‘Migrate While Active’ Cloud Offering, HA Subscriptions
Surprise! It’s 2024 Fall TR Time for IBM i
IBM Clarifies Where It’s Going with IBM i Subscriptions, Product Realignment