In this new blog post we are going to show the results and conclusions of our tests on virtual machine migration and replication functionalities with vCloud Availability, for hybrid cloud.
INTRODUCTION
This article is intended for administrators of cloud organizations (or tenants) based on vCloud Director, whom we’ll call OrgAdmins.
We will assume that OrgAdmin is also responsible for managing the rest of the company’s IT infrastructure.
In the hybrid cloud concept, a company runs applications in both public and private clouds, understanding public or private depending on whether or not the infrastructure is shared with other companies.
A basic functionality of hybrid cloud is to be able to migrate an application between clouds, with the least possible unavailability. Typical use cases are dealing with disaster recovery scenarios, or migrating applications across clouds to meet unexpected demand.
vCloud Availability (vCav for short) enables you to migrate or replicate virtual machines and vApps between clouds based on vCloud Director; or between vCloud Director and vSphere.
Once vCav is deployed and configured, it works as a plug-in in the HTML5 interfaces of vCloud Director or vCenter, allowing the OrgAdmin to self-manage the migration and replication processes. At high level it looks like the diagram below:
High-level component diagram in the case of migrations from on-premises to cloud
CAs we mentioned earlier, it is also possible to integrate two cloud providers with each other using vCloud Availability, so that an OrgAdmin that has vCloud Director organizations on both cloud providers can migrate virtual machines between those providers, without additional third-party intervention. See following diagram:
High-level component diagram in the case of cloud-to-cloud migrations.
This article is not intended to be a step-by-step on Availability configuration, but to show some tests developed and their results.
SUMMARY
Some thoughts on using vCloud Availability for hybrid cloud migrations:
– The unavailability caused by a migration and its respective rollback is drastically reduced. In our tests it was 10 minutes or less rollback plus migration.
– The migration / replication tasks and their respective rollbacks are self-managed by the OrgAdmin.
– In the case of on-premises migrations to vCloud Director, it is relatively simple to configure from the on-premises site side.
– In the case of migrations between vCloud Directors, it does not require the deployment of any additional component by the OrgAdmin.
– The client does not have to pay for any additional licensing.
– Customer must use vCenter 5.5 onwards to use Availability 3.x
– To use all the functionalities, the customer must have vCenter 6.5 U2 onwards.
We run these tests and these are the results:
Test
Expected result
Obtained result
Execute a migration of a virtual machine, and its return, 100% self-managed by OrgAdmin.
It is possible to run a migration and roll back using self-service tools, without any intervention from the vendor or third parties.
Success. The migration and rollback were run using the vCloud Director tenant management interface exclusively.
Take the time it takes to activate the replica and deactivate the origin, and vice versa.
Reduce unavailability times to an order of minutes.
Success. 5 minutes or less between shutdown of the source virtual machine, and power on at the destination site.
Review encryption of the connection for data passage between the on-premises site and the cloud.
Data traffic between on-premises and cloud is encrypted.
The traffic is encrypted using HTTPS.
RISKS AND TESTS
Every OrgAdmin that wants to migrate the on-premises infrastructure of their company to the cloud, has the challenge of achieving it in the shortest possible time, minimizing the risk of impact on the business.
Here we assess how vCloud Availability can mitigate some of those risks.
We take into account five basic attributes of any solution, such as performance, availability, recoverability, security and manageability.
Based on this, we scored the risks perceived by clients at different points in the migration processes to the cloud, and possible mitigations:
1. What if the performance of the cloud is not better or equal to that of on-premises infrastructure? (Performance)
Correctly size the allocation of cloud resources using objective metrics.
While VMware vCloud Availability does not improve cloud performance per se, it can help by rapidly migrating from cloud to on-premises or vice versa, in a fully self-managed way.
2. Will the cloud I’m migrating to have the same or better availability than on-premises infrastructure? (Availability)
While vCloud Availability does not directly affect platform availability per se, creating replicas of virtual machines between two sites can improve the availability of a given solution.
3. How do I reduce the unavailability of solutions during the migration process? (Availability).
In large-scale migrations, executing the migration of each component of each application can cause service losses (scheduled or not) of several hours, without having potentially dependent tasks on third parties such as moving physical media. vCloud Availability allows migrations without physical media transport, in the best case it can reduce the downtime to what it takes to shut down the VM at the source site and turn it on at the destination site.
4. How do I go back in case I want to go back to my on-premise platform? (Recoverability)
As we mentioned before, vCloud Availability allows total self-management regarding migrations (or going back from them), without the intervention of third parties.
5. How does the migration, once completed, affect my backup and recovery processes? (Recoverability)
The OrgAdmin must plan its backup and recovery methods at the vCloud Director site.
Vcloud Availability allows replicating virtual machines between two virtual data centers (VDCs) of the same cloud based on vCloud Director, so it could be used as a replication method.
6. What happens to the security of my data during and after the migration process? (Security)
By using vCloud Availability, you can avoid moving physical media between sites as Availability uses an encrypted connection between the two sites to transfer the data.
7. How do I manage the migration process, from a technical point of view? (Administrability).
With vCloud Availability, the customer can self-manage the migration and rollback of their virtual machines, between their on-premises site and the cloud, using the same HTML5 management interface as vCloud Director.
For testing purposes, we can group points 1,4,5,7 in one test, and points 2 and 3 in another.
High-level component diagram in the case of migrations from on-premises to cloud
As we mentioned earlier, it is also possible to integrate two cloud providers with each other using vCloud Availability, so that an OrgAdmin that has vCloud Director organizations on both cloud providers can migrate virtual machines between those providers, without additional third-party intervention. See following diagram:
High-level component diagram in the case of cloud-to-cloud migrations.
VCLOUD AVAILABILITY ARCHITECTURE
Before we talk about the test results, let’s talk a bit about the architecture of vCloud Availability from an OrgAdmin point of view.
In this section we assume that the cloud provider uses vCloud Director and also already has vCav implemented.
The appliance for tenant can be downloaded from the VMware website, and the necessary URLs and connectivity details can be provided by the cloud provider.
An additional authorization may be required from the cloud provider to use this service, but that will depend on the provider’s business policies.
In summary, the OrgAdmin must deploy an appliance, to which the services must be configured so that it can connect to the cloud provider.
vCloud Availability at the application level consists of three services:
Tunnel
-Establish the SSL VPN tunnel between sites
Replicator
– Generates replication and migration traffic, copying virtual machine data and redirecting it to the destination site using an encrypted connection to the Tunnel service.
Cloud Management
– Availability appliance management interface service. When the site has vCloud Director, it integrates with the Director HTML5 interface.
vCloud Availability has two versions of the appliance:
Tenant – for sites with vCenter.
-All services are concentrated in one appliance.
-This is the appliance that OrgAdmin deploys in the on-premise site.
Service provider – for sites with vCloud Director.
-These appliances are deployed one-time by cloud providers and are not managed or configured by OrgAdmin.
Below is a high-level component diagram, with the different services and connectivity of the Tenant appliance:
VCloud Availability architecture on the on-premises site. VMware
LABORATORY
We deployed a lab using nested virtualization on top of vCloud Director.
We will not go into detail about the lab deployment procedure, as we follow the standard procedures of the VMware documentation for all products.
In this laboratory we are going to simulate two sites:
Site A: vCloud Director 9.5 provider, with a cluster based on vCenter 6.5 U3
Site B – Customer’s on-premises site, with a vCenter 6.5 U3 cluster
See the following diagram of laboratory components:
High-level diagram of laboratory components.
RESULTS
Execute a migration and rollback of a virtual machine without third-party intervention.
This is not a detailed step-by-step, as the purpose is rather to show the result and how they are appreciated
Once Availability is installed and configured on both sites, using the vCloud Director HTML5 interface, it is possible to run a migration from an on-premises machine to the cloud (see next screenshot).
In this case, c01-vc03 is our ‘Site A’.
After that, we can configure the replica, which can be seen in this way in the following image. Note that Availability changes some machine names when it replicates, adding a suffix to them.
Replication view from on-premises to cloud
After the migration is executed, the machine can be seen in the virtual datacenter of the destination cloud, as in the following image:
Migrated VM details
Testing the reversal of migration
We see that it is first necessary to do a ‘reverse’, so that the flow of data replication changes direction. After this we can see that the type of replication appears as ‘Outgoing Replications’ → ‘to On-Prem’
After running the wizard to do the ‘Migrate’, we see the VM turned on again in the vCenter on-premise. The following image shows the VM imported back into vCenter.
Take the time it takes to activate the replica and deactivate the origin, and vice versa.
The tests were done from a fresh installation of CentOS 8, with 4GB RAM, 2 vCPUs and 16GB of RAM, virtual hardware version 10.
During both tests, the virtual machine is under load less than 10% of CPU and RAM, and with a negligible amount of IOPS.
Also, notice that in our lab, ‘Internet’ between the two sites was actually a LAN.
In our lab, migrating a VM took about 5 minutes, counting from shutdown at source to power on at destination.
The return process (cloud to on-premise), took approximately 5 minutes.
Examples of times since vCav shuts down the VM at the on-premises site, and powers it up at the cloud site, viewed from vCenter:
Review connection encryption for data passage between the on-premise site and the cloud.
Connections between sites are encrypted using the HTTPS protocol. In case you want to change the encryption methods by putting more restrictions on the encryption algorithms, just put reverse proxies between the appliances and the edge firewall.
TO FINISH
We find it satisfactory to use vCloud Availability to run migrations and replications of virtual machines between sites (see the table in the summary of this article).
It is my opinion that an OrgAdmin does not need significant support to migrate virtual machines between clouds once the vCav appliance is configured. It is possible that the OrgAdmin, when deploying the vCav appliance, may need support. But in both cases, I think a short and concise documentation on vCav deployment and usage by the cloud provider will cover most of the doubts.
On the other hand, the customer should upgrade their site to at least vCenter 5.5, or vCenter 6.5 U2 if they want to display the plugin in the vCenter interface. This is not essential to operate vCav through the HTML5 interface of vCloud Director.
ACKNOWLEDGEMENTS
To the Pyxis Research team for coordinating and executing the testing of the solution, and giving me feedback on it.
As always, to the Communication team for their willingness to help us make the entry look as good as possible.
With a 360° potential, our solutions matrix accompanies the lifecycle of any project, with skills and experience in Development, Design, Q&A, Devops, Operation & Deploy, and Architecture