Migrating complex application environments consisting of multiple virtual machines to the public cloud can be a major headache for IT organizations. The Velostrata Runbook Automation tool simplifies this process by enabling automation and ordering of the migration process. By automating batches of VM migrations in a simplified manner, this tool accelerates cloud migration for multi-tier VMs as well as large-scale, mass migrations. The runbook automation tool runs in PowerShell and allows full customization of both testing and migrating workloads to the cloud. In this blog, we’ll walk through how to migrate a multi-tier application that relies on a number of VMs which must be started in a specific order.
Step 1: Create the Runbook template
Before using the Velostrata Runbook Automation tool, you’ll of course need to have Velostrata installed and connected to your cloud instances. Once you’ve done that and once you’re ready to start migrating, you’re ready to create your Runbook. To create the Runbook, run the following PowerShell command:
The system will prompt you for the vCenter address and login, or you can just enter it within the command:
./inventory-export.ps1 vCenterServer <string> -DatacenterName <string> vCenterUser <string> vCenterPassword <securestring>
Running this PowerShell script exports the entire virtual datacenter environment into a CSV template, consisting of the virtual machines and specs from the source environment.
Step 2: Customize the Runbook
Each VM is represented by a RunGroup number and followed by the additional specifications which include (but are not limited to): VM location and target cloud subnet, security group, instance type, etc. It will even report (via a validation probe) on whether a failed action should block further processing of the next RunGroup. For example, VMs in the 100 RunGroup will be moved (and started in the cloud) first, and when successful, the process will begin on the 200 RunGroup, and so on. VMs with the default RunGroup –1 are not migrated.
The Runbook also integrates with linked clones and allows for customization via custom tags when the instance is instantiated in the cloud. This is useful for adding tags such as department, owner, or cost center to the migrated VMs.
For our walkthrough, we have two database servers: HammerDB-SQL-1 and SugarCRM, and two web servers: HammerDB_WebTest-1 and SugarCRM_App. The database servers need to be running in the cloud first before their dependent web servers.
Step 3: Migration
Velostrata enables rapid movement of VMs into the cloud without having to perform a full data migration. We initiate the Runbook migration process from PowerShell and then Velostrata gets those VMs running in the cloud within 5 – 10 minutes. The data migration takes place in the background, but since the VM and application are already running live in the cloud, it allows for immediate in-cloud performance and validation testing. Or, since Velostrata’s WAN optimizations ensure normal application performance, simply use the apps as normal while they run in the cloud and the data transfers in the background.
As we can see from within the vSphere console, the two SQL servers are brought up first in the cloud, as indicated by the Velostrata icon overlaying the HammerDB and SugarCRM VMs. These tasks can also be monitored in PowerShell.
Once each of these servers are running in the cloud, the migration of the associated data kicks off in the background. Here we see the migration status for one of the VMs:
In addition to those servers having their data migrated in the background, the next servers in the Runbook will begin to run in the cloud as well. Once they’re running in the cloud, their data will migrate in the background as well. And so on and so forth for however many run groups there are. While this process is taking place, you can see from the cloud portal (we are using Azure for this walk through but you can also use AWS as your cloud destination) which VMs have begun running natively in the cloud.
Step 4: Detach
Once all of the RunGroups finish, you’ll have all of your servers running in the cloud. While the data migration takes place in the background (or after it has concluded), administrators are able to perform testing and validation of the VMs and associated applications before deciding to detach and go fully cloud-native with these applications. If an application is not working correctly, the VM(s) can be rolled back to on-premises in minutes to resolve these issues.
Once the data migration is complete and the VMs are working as desired in the cloud, they are ready to be detached from on-prem. This means the VM instances will shift from using a Velostrata cloud cache for storage (which was synchronizing with on-prem data for consistency) and instead switch to using native cloud disks only. After detaching, the administrator can delete these VMs from their vSphere environment if desired (or simply keep them shut off).
Organizations are moving quickly towards a ‘move now optimize later’ approach to cloud migration, which creates a need for cloud migration solutions that can seamlessly and easily handle multi-tiered applications and large-scale, mass migrations. That’s why Velostrata’s Runbook Automation tool is the perfect way to handle the complex components of any cloud migration with ease. If you’d like to learn more about Velostrata, be sure to check out our accelerated migration page or drop us a line to speak with one of our migration gurus.