Migrating to Cloud and Running Hybrid: Part 5 - Azure & AVS
For our final technical post in the series, we will look at Microsoft Azure as the public cloud to target for migrating workloads.
Similar to our previous post, we are going to look at some of the options that customers have available to them for migrating on-prem workloads to Azure – we’ll mention AVS later in the post, but that one is almost cheating.
Since our second post in the series got our data handled for being separated from the OS and replicated to the cloud, let’s see what we can use to move the workloads themselves this time around.
The first tool that we have available to us for moving workloads to Azure is called Azure Migrate, and this tool can help us to quickly evaluate an existing environment to configure our plans to migrate to Azure. This tool can perform discovery of both VMware and Hyper-V virtual environments, along with physical servers, and other cloud instances.
There is a virtual appliance for discovery of the virtual environments that can be deployed into vCenter or Hyper-V, or from a Windows server for the purpose of discovering physical servers. Each of these appliances has their own requirements for resources and permissions, but the existence of the appliance to ease the operational lift of the discovery phase is a significant timesaver.
Once these discoveries for each server type are performed, with the Azure portal you move to the assessment phase, and the assessment can be run in 2 methods: “as-is” or “performance-based”. The “as-is” assessment will use the server configuration to recommend Azure VMs based on the on-prem workload size. The “performance-based” assessment will use the dynamic performance data that was collected to recommend Azure VMs based on the data for CPU & memory utilization.
After these assessments are completed, the planning for the actual migration to Azure can begin based on an agent-based or agentless replication. Some of this setup and configuration will be based on the needs for the environment, such as which hypervisors or operating systems are being migrated to Azure, along with the number of workloads that are needing to be replicated. There is a full walkthrough of the configuration and use of Azure Migrate with vVols/Cloud Block Store on the Pure Storage support site here.
For the second option that Azure provides, Azure Site Recovery(ASR), you gain the ability to migrate & replicate workloads between your on-prem environment and Azure. Azure Site Recovery will handle the continuous replication of the boot volumes of your on-prem workloads to Azure.
Working with ASR begins with a similar planning process to Azure Migrate, where a PowerShell script is used to connect to the environment being targeted for replication to Azure. This deployment planner tool will collect data and profile the source environment based on the selection criteria input by the user running the tool.
The initial configuration of ASR requires that some Azure resources are provisioned to be used, primarily a storage account, Recovery Service Vault, and an Azure VNet/subnet. Once these configuration steps are completed, you can download the virtual appliance for the planning and configuration of disaster recovery to Azure for the following environments: VMware vSphere, Hyper-V, or physical servers.
This configuration server will also build the connectivity to Azure and connect to the on-prem source workloads/environments. It will also control the setting of all of the requirements and targeting for the on-prem workloads being migrated, and prepare the Azure environment to receive the replicated workloads.
It is possible to run workflows to failover from on-prem to Azure, as well as reprotect or failback workloads from Azure to on-prem, but it is advised to look into the steps to prepare for each of these actions before running the workflows. The complexity of this effort will obviously vary based on your own environment.
I’ll go ahead and repeat myself (by method of copy-paste) for some considerations every environment should make while looking at moving to a new platform…
For customers that are planning to run in a hybrid mode between on-prem and public cloud(s), you also need to give some consideration to IaC and automation. If you are able to completely separate the provisioning of your environment to be automated and even version controlled, your deployment methods may differ for each environment, but then your infrastructure becomes both composable and disposable.
Once you have made it to the maturity of being able to redeploy your OS platforms and applications as needed, you have reached a much better foundation where your concern can be focused on what is really important to your business – your data. At that point, everything else is tweaks in your code to decide to tweak your existing environment or deploy on a new one as needed.
Finally, we will quickly discuss your options with Azure VMware Solution (AVS), but these are not completely different than looking at a migration between vCenter environments across datacenters. There are some limitations with what is supported by the AVS solution due to its managed offering and the lack of full permissions within the environment, but most VMware customers probably have heard of HCX within the past few years.
VMware HCX is essentially the mainstream tool provided and used for migrating workloads across both datacenters and clouds, and HCX Enterprise is included with AVS for no additional cost. This means that with some basic configuration of NSX or a vSphere Distributed Switch, the HCX Network Extension can be put in place to easily facilitate migrations of vSphere VMs between your on-prem and AVS environments.
Some other tools which one would think could be used for this migration will give you trouble if you are running external storage for AVS, which everyone should consider for the features and cost savings, so in short – you can’t use SRM. Technically it all works, but it is unsupported – but reach out if you want to help to push to get this validated and supported for AVS.
There are some other options available if you are wanting to use AVS and external storage, such as Zerto and JetStream DR, which I hope to have some time to demonstrate or highlight in some future blog posts.
For now, this should be a feasible overview of the options for migrating to and from Azure and AVS, and we’ll wrap this series for now. I hope this helps you to understand what planning and considerations you should make for a cloud migration, or running in a hybrid model, and what options are available for you to research for your own needs and requirements.