In the first three parts of our Cloud Migration Series, we discussed the hybrid cloud and migration methods, provided an overview of HCX, and talked about the importance of the service mesh. These are all critical to understanding, but even more important are the aspects of planning, design and other considerations. Without proper planning, and really understanding your workloads, the outcome of your migration will be grim. To be successful, it’s important to understand the key considerations below.
Before virtual machines can be moved to the cloud, application dependencies between other VMs, applications, and services must be understood. A single virtual machine might be communicating with many other virtual machines and services. Let’s think about a very simple example – a three-tier application stack – there could be a variety of consequences if we migrate only a portion of the application stack. When interacting with the application, latency might introduce poor performance, or cause the app to not function at all. Egress traffic could incur additional costs that weren’t accounted for. If other applications are leveraging this stack, they could be impacted as well.
It’s imperative to understand the dependencies, and the process of doing so could be dramatically simplified by using tools such as vRealize Network Insight to see the communication between virtual machines and applications. This will not only assist in determining which applications need to migrate to the cloud together in groups but can also help estimate data egress charges if some data remains on-premises.
In addition to using tools, it helps to conduct an interview with application owners. This could bring additional information to light that normally wouldn’t be found by using tools such as application sensitivity and other constraints that need to be considered prior to migration.
Sizing your new cloud environment appropriately is incredibly important, and it’s a delicate juggling act from both performance and cost perspectives. The best way to approach sizing is to collect as much information as possible about the workloads you intend to move. I prefer to start off with everyone’s favorite – RVTools – and layer in data from vRealize Operations. Though, you can use any tool you wish to get the job done as long as it’s providing complete and accurate information. Once the data is collected, you can plug the numbers into the VMC Sizer to determine how your SDDC should be sized. Dan Florea wrote a couple of great articles detailing the general use of the sizer and using it for memory bound workloads.
Again, I can’t stress enough how much you need to understand the workloads and applications in your environment. This will aid in making design decisions around host and cluster types. For most workloads, I3 instances are perfect, but for workloads that have larger memory or storage footprints, R5 instances may be preferred. In addition, moving Tier 0 (mission-critical) applications may have higher SLAs and require a stretched cluster over a traditional cluster. These design requirements depend on the accuracy of the data collected and a good understanding of the applications and their dependencies.
The VMC Sizer will provide you with a full recommendation and breakdown of resources including the number of hosts, estimated cores and RAM used, estimated used and free storage, and breakdown of the storage footprint. It will also provide a list of assumptions made in the report.
In the previous parts of this series, we talked about the various migration methods available, including HCX. Now that we understand the applications and dependencies, we can start to categorize them into three buckets – Downtime, Minimal Downtime, and No Downtime. Categorizing them like this allows you to choose an acceptable migration method:
Downtime: Cold Migration, vCenter Converter
Minimal Downtime: HCX Bulk Migration, HCX OS Assisted vMotion
No Downtime: vMotion, HCX vMotion, HCX Replication Assisted vMotion
After putting the VMs into categories, we can start building out waves. The intent here is to migrate the VMs that can incur downtime first, and use them to pilot the actual migration, management, performance, and operational aspects. This will help weed out any potential issues before critical apps are migrated that cannot have any downtime.
VMware Cloud Migration Solution
There are a lot of moving parts when embarking on this journey – planning, sizing, building, configuring, testing, monitoring, and the list goes on. There is a human element to this that makes all of these tasks seem daunting, in fact, it would be pretty easy to miss a step along the way. As such, VMware has developed the Cloud Migration Solution to help.
This is a step-by-step migration guide divided into three sections: Plan, Build, and Migrate. Each section provides the steps necessary, in sequential order, from deploying your SDDC all the way through migrating your virtual machines. You’re provided a checklist to help keep track of your progress, and the steps include instructions, tools, and links to make your migration successful.
Cloud Migration Series
Part 1: Getting Started with Hybrid Cloud Migration
Part 2: VMware HCX Overview
Part 3: The HCX Interconnect and Multi-Site Service Mesh
Part 4: Planning and Considerations
- You can learn more about our VMware Cloud on AWS and HCX services at the VMware Cloud on AWS and VMware HCX websites
- Follow us on Twitter @vmwarecloudaws and @VMwareHCX and give us a shout with #VMWonAWS and #HCX
- Watch informative demos, overview videos, webinars and hear from our customers: VMware Cloud on AWS on YouTube
- Try the VMware Cloud on AWS Hands-on Lab for a first-hand immersive experience
- Read our latest VMware Cloud on AWS blogs
- Follow the VMware Cloud on AWS and VMware HCX Release Notes for continued updates
- Cloud Migration Solution Brief
- Cloud Migration Buyer’s Guide
- Cloud Migration Practitioner’s Guide