Application and Virtual Machine (VM) on-boarding to infrastructure cloud platforms (Amazon, Google, Rackspace to name a few) has become mainstream, with the evolution of cloud migration tools, which facilitate in moving candidate source VMs and applications to a target cloud platform. A major challenge during the cloud migration process is creation of target cloud topologies. A topology typically describes the network, storage and compute attributes, however in the context of migration the network topology is the most important. The network topology characterizes VLANs, subnets, IP addresses, port groups, firewalls, load balancers etc.
An important question to be answered during cloud migration is whether we have the ability to replicate or re-create the source environment topology on the target cloud platform. The two aspects of addressing this requirement are:
- i) A mechanism of capturing the source network topologies and its dependencies as a blueprint.
- ii) A method to create the target cloud deployment blueprint as per the source environment at design time.
In this blog, we discuss the latter method, and explain the process with an example scenario.
Template Based Approach
Here, we introduce the notion of ‘deployment templates’, which characterize the target cloud topology elements (VLANs, subnets, routers etc.) and VM metadata. These templates are created at design time, and assigned to individual cloud migrations. We leverage AWS Cloud Formation and OpenStack Heat orchestration services for creating target cloud deployments to generate well-defined, standard, and custom deployments on the fly.
By using this approach, we further simplify the cloud migration process. Creation of the target deployment(s) a-priori allows the source VMs to be directly forklifted into the target setup, with pre-configured VM and network configurations required for functioning in the target cloud. This mechanism avoids the re-configuration of VM and network properties, which traditionally is done by logging into the Cloud Service Provider (CSP) console, after the VM image disk is forklifted.
Process Summary
Under the hood, the target deployment stack is created first via a User Interface (UI) driven mechanism. The UI captures all the mandatory and optional parameters required for stack creation and VM migration. This approach allows the end-user (migration engineer) to easily define the target topology, without having to ‘write’ the JSON manually. This is the one of the primary pain-point(s) we address, and leverage the same for the VM migration approach.
Once the JSON tree model (template) is created, the corresponding APIs (AWS / OpenStack) are invoked to create the required resources. At this stage, the source VM’s are ready to be forklifted into the target stack. To forklift the VM(s), the VM must be configured with the target cloud, target region, flavor type andstack name, as shown in the figure below.
The stack name (CMF Stack1) is selected from the list of stacks created. The selected stack which is characterized by network properties (VLANs, subnet etc.) is associated to the specific VM migration. For an individual migration scenario, the source VM can only be forklifted into a specific subnet created within the stack, which can be selected while assigning the stack name to the source VM in the configuration step.
To summarize, VM migrations are complex and time-consuming, involving a detailed level of configurations. To simplify the process, it is critical to have a clear vision of the detailed underlying aspects of a-priori. Our novel template-based approach helps in reducing the time and complexity of the overall migration process, thus facilitating the further adoption and on-boarding of applications to the cloud.
