This article was originally posted by Deji Akomalafe, VMware on May 21, 2018. Please find this article here.
As enterprise IT teams, leadership and business owners continuously drive towards service improvements, they invariably look at the public cloud infrastructure as a possible target for their mission critical applications. Whereas virtualization is now generally accepted as the default platform for enterprise-grade applications, businesses looking to leverage the public cloud for most of these applications are still constrained in their ability to do so. These constraints can be directly attributed to the following (among others):
- Performance Concerns – is the target public cloud robust enough to meet the application’s scale and performance requirements?
- Vendor Support – is the target cloud platform certified for the application? Will the vendor provide the necessary technical support and assistance when (not if) the enterprise requires it?
- Level of Effort – mission critical applications demand considerable attention to configuration and other considerations beyond those required for lower-tiered applications and moving from one hosting platform to another may not be a simple or quick undertaking.
Now that we have addressed the “Performance” and “Vendor Support” parts of the aforementioned constraints in Part I of this blog series, let’s turn our focus to addressing the “complexity” part of the picture. Yes, “complexity” because, as we will demonstrate, moving Production Exchange Server workload from On-premise vSphere infrastructure to VMware Cloud on AWS is anything but complex.
One of the most thorny decisions application and business owners have to make during a workload relocation exercise is whether or not production workloads and the services they deliver will continue to be available throughout the relocation or, if not, whether or not the benefits of such move compensates for the expected revenue and production loss associated with the move. VMware vSphere administrators and customers are already benefiting from the very popular vMotion feature which has been a staple of vSphere for many years. vMotion allows an enterprise to gracefully move workloads between datacenters without service interruption. VMware Cloud on AWS provides the same capabilities to customers. VMware Cloud on AWS supports vMotion, meaning that we can move our Exchange Servers from our On-premise vSphere infrastructure to our new VMware Cloud on AWS SDDC.
Yipppppeee….Yaaaayyy… but wait! We are talking about a production Exchange Server workload here, right? What about the IP addresses of the migrated workloads needing to be changed? That requires a reboot, right? Downtime!!! Not really. VMware Cloud on AWS support VLAN/Subnet stretching. VMware Cloud on AWS leverages the NSX technologies for facilitate stretching an On-prem Subnet to include customer’s SDDC cloud instances. Our demo leverages the “Extended Network” feature of VMware Cloud on AWS to perform a cross-datacenter relocation of several VMs hosting Microsoft Exchange Server mailboxes. As we demonstrated, the Exchange Server VMs and the Exchange services they provide to remain alive and functional as we move them from On-premise environment to our SDDC on VMware Cloud on AWS. The “Extended Network” feature helps us ensure that we did not have to change the IP addresses of the migrated VMs.
The second video attached to this blog post is a demonstration of a use case scenario in which we have a need to relocate/evacuate some or all of our current On-Premise workloads and gracefully restore them and their services at our VMware Cloud on AWS SDDC. This calls for the recovery or relocation of multiple VMs hosting various, inter-dependent applications. For this use case, we assumed a scenario where customers can afford downtime, perhaps because they are evacuating an entire datacenter. So, we imagined a scenario where relocating just the Exchange Server VMs is not sufficient for service continuity. Perhaps a complete power outage occurred at the On-premise datacenter, interrupting services for all production workloads. Recovering just the Exchange Servers does not provide any benefit because their services do not become available without the presence of a functioning Active Directory Global Catalog server (a Domain Controller). Beyond that, bringing up the Exchange Server VMs BEFORE the Domain Controllers will still result in the same service outage.
This video demonstrates how the “Site Recovery” add-on feature in VMware Cloud on AWS enables us to overcome the aforementioned “complexities” and satisfy the dependencies requirement. Site Recovery enables us to migrate workloads and to also protect and recover from disaster events impacting one datacenter, and restore services and functionalities at the designated DR site. In our demonstration, our SDDC is the target DR site. We demonstrated two common capabilities of the “Site Recovery” feature, namely:
Planned Migration
- For when a workload must be relocated, but without the added pressure of a “disaster”
Test Disaster Recovery
- What is the worth of the best DR plan if you can verify that it actually works? Most enterprises have sound DR plans, but most cannot prove that their plans work. This is because most DR plans require service outage. What if we could simulate an actual DR event and soundly validate and tweak our plans without interrupting services or inducing production outage? Site Recovery provides this capability
We leveraged the “Hybrid Linked Mode (HLM)” feature of vSphere (available and supported in VMware Cloud on AWS) to facilitate our “Single-Pane-of-Glass” administrative view and control of both infrastructure. Our demo did not describe the process of enabling and configuring HLM because the setup is not peculiar to our setup and use case.
The heavy lifting involved in planning and successfully executing seamless workloads relocation between datacenters is one of the most difficult challenges for administrators and stakeholders. VMware Cloud on AWS provides ALL the tools and features required to make moving from On-premise vSphere infrastructure to VMware Cloud on AWS as seamless, efficient and unobtrusive as possible. As these videos demonstrate, migrating from a vSphere infrastructure to VMware Cloud on AWS, and that protecting and recovering them in our SDDC is administratively inexpensive.
This concludes our blog series. As we have demonstrated:
- The VMware Cloud on AWS infrastructure provides workload performance in parity with what a similarly configured workload will get in an On-premise vSphere infrastructure.
- That hosting and running production Exchange Server workloads in a VMware Cloud on AWS environment is supported.
- That, by leveraging the native and add-on features of VMware Cloud on AWS, moving On-premise workloads to our SDDC is very simplifies and does not require considerable amount of effort.
