Azure Migrate for Azure VMware Solution

One of the key considerations when looking at data center exit is, “how am i going to size my existing on-premise estate to determine the required footprint in a VMware backed hyperscale cloud provider.” Lets face it, it’s not the most exciting activity in the world, but it is an activity which, carried out in a rushed fashion, or with out due care and attention. Can result in either an oversized or under sized cloud environment. Now you are probably reading this thinking, “But this is cloud, I pay for what I use.” This is true, you can pay on demand and indeed, pay for what you use. However, when customers are looking at consuming the VMware SDDC technology in a public cloud provider, the number one use case is normally data center exit, and ease of migration. With this in mind many customers look to consume the SDDC infrastructure on hosts which are paid for through a reserved instance (RI) commitment model in order to leverage well understood discount models over a 1 or 3 year term.

It’s at this point where you want to have a level of accuracy when it comes to how many hosts you plan to commit to. No one wants to be in the position where they are either, explaining why they spent too much money on reserved instances, or justifying why they need to go back to the business and ask for more money because they didn’t forecast and size correctly.

There are various tools out there to collect this type of information. Most VI Admins are familiar with RVTools, a really handy utility which you can download for free, run against your on-premise environment and quickly get a point in time snapshot of your on-premise vSphere estate from which you can pull metrics such as the;

• Number of VMs
• vCPU allocations
• vRAM allocations
• Storage Allocated and Consumed

From here you can start to see quickly what your estate looks like. The way I explain this to the customers I work with, it’s like taking a photograph of you virtual environment.

Other tools which are popular for gathering information include LiveOptics. LiveOptics takes this a step further and provides you with collector software which you run on a Windows VM in your environment to monitor vCenter and send the data to LiveOptics SaaS platform to crunch the data and provide you with dashboards and consolidated data which can be fed into a sizing tool to provide insight into the size of the required environment, LiveOptics already has integration with the vSan Sizer to automatically ingest this data to size vSan Ready Nodes.

But with this article I wanted to raise awareness of what Microsoft are doing with the Azure Migrate tool which now allows users to use this tooling to collect all of the relevant data about the on-premise vSphere environment and allow you to create an Assessment of the environment to calculate what you will need in terms of node counts within AVS.

The reason I like this approach comes down to the following issues which occur with sizing. Plus the fact that I hate sizing 😄

1. Standardizing on input metrics, very often people will change the input numbers or those numbers will come from outdated or unknown sources. Utilizing a standard automated solution for collecting the correct inputs is essential.
2. Removal of the potential for human error. We all know what can happen when you ask people to perform boring repetitive tasks, human error and the potential for mistakes in sizing activities with a large amount of manual steps creates risk to accuracy.
3. Bias. People are different, people interpret data differently and this has the potential to lead to different outputs when there is potential to adjust inputs, adjust calculations (sometimes this is needed) and interpret results.

Automation of the above is key to removing as much of the above issues and pain points as possible.

So, how does Azure Migrate help with this.

For those who are not familiar with Azure Migrate, this is a solution available as a service in Azure that will discover your on premise environment, and assist with migrations. Traditionally this tooling was used to migrate virtual machines to native Azure. But now it has additional functionality to allow you to collect the data that was originally used to inform users on which Azure native instance types to convert their virtual machines to, and now use that same data to size out what an Azure VMware Solution environment will need to be. Answering the issues I raised above

1. Standardization of the input values
2. Removal of human error
3. No bias, let the calculation engine do its thing.

I won’t go into the detail around how Azure Migrate works, or how to set this up, you can find that detail by going to the Azure Migrate Documentation and you can find a lot of detail here around the process for Azure VMware Solution Assessments.

You have choices around how you choose to collect the data. You can either download the pre-built VM as an OVA, or run the scripts and MSI files to install the collector capabilities on an existing Windows image in your environment, or you have the choice to populate a .csv template with the required fields which will be fed into the calculation engine.

Once the collector is up and running and configured to communicate between the vCenter in your on-premise environment and Azure, you will see the discovered virtual machines start to appear in the Azure Migrate solution in the Azure Portal.

There are other capabilities here around dependency mapping which is useful, and certainly worth considering when you are looking at Migrations, you don’t want to leave part of an application behind during a migration and then find you have just introduced higher latency into your application 😄.

Now that we have all this detail we can very easily create an assessment to move those workloads directly to Azure VMware Solution

Keep in mind that Azure Migrate does give you the option as part of an Azure VMware Solution Assessment to size based on performance metrics which the collector provides. This is useful if you are collecting data for migrating to Azure Native VMs as you can then convert to the right sized Azure instance type as part of the migration. When you are migrating vSphere virtual machines on-prem to vSphere infrastructure provided in Microsoft Azure. You need to take into account that the migration tooling, HCX, is going to move the VM without changing the underlying VM. So you want to ensure that you are sizing your environment correctly, either rightsizing your environment before migration. You can make use of vRealize Operations to run a VMware Optimization Assessment, VOA. Or accounting for this to be done as part of the post migration process.

As you can see you can see pricing detail, I have removed this until official pricing is available at General Availability, and you can see the host count you require.

But one thing that is most notable is the Readiness. All of these workloads are ready for Azure, no checking if the OS is supported, no checking if instance availability is going to be an issue. You can simply move the workload to Azure with no changes.

You can essentially, Hit the easy button on moving workloads to Azure VMware Solution.

Azure VMware Solution is going to make use of Hybrid Cloud Extension (HCX) and there are a number of blog posts out there which talk about this solution. As we go deeper into VMware Multi-Cloud offerings we will discuss this topic in more detail.