Getting Started With Azure VMware Solution

What is Azure VMware Solution?

Azure VMware Solution (AVS) is a hybrid cloud service that allows for fully functioning VMware software-defined data centers (SDDC) within the Microsoft Azure Public Cloud.

Now in its second revision, AVS is a first-party solution fully managed and supported by Microsoft, verified by VMware and running atop Azure infrastructure. This means when you deploy AVS you get VMware's ESXi for compute virtualization, vSAN for hyper-converged storage and NSX for networking and security (find more information in the Components section below), all while taking advantage of Microsoft Azure's global presence, class-leading data center facilities and proximity to the rich ecosystem of native Azure services and solutions.

Azure VMware Solution use cases

AVS holds great potential for organizations looking to leverage it for hybrid cloud; however, time must be spent assessing strategy, costs and expectations to ensure success. With that in mind, below are a few reasons why customers might be interested in or are actively consuming AVS as part of their hybrid multicloud strategies.

Skillsets and operational tooling

It is not presumptuous to say that adopting and migrating to a public cloud can be an unsettling proposition without proper preparation and investment. One of the most significant reasons for this is an organization's need for new skillsets and operational tools.

With AVS, moving your workloads to and operating them within the Azure Cloud can be relatively simple since organizations already using VMware solutions can continue leveraging their existing skillsets and, in many cases, existing operational tools within the public cloud.

There are some foundational prerequisites in native Azure that are required to deploy AVS and get existing VMware administrators and IT operations up and running (e.g. Azure landing zone, networking and security), but once all those components have been established, organizations can manage and operate the AVS environment as easily as they would a VMware environment on-premises. This can lead to accelerated cloud migrations and a much smoother transition to a hybrid multicloud architecture.

OpEx financial strategy

An increasing number of finance departments are expressing a desire for more predictable, consumption-based cost models. Instead of enduring large capital expenditures every three to five years and the associated guesswork of predicting both the direction of technology and growing capacity requirements that far into the future, AVS allows organizations to have and consume VMware infrastructure as a monthly operating expense.

If more compute or storage capacity is required for a day, month or even permanently, additional VMware hosts can simply be added whenever they are needed directly from the Azure portal.

An AVS subscription also includes all the VMware licensing, so there is no co-terming or managing licenses for VMware vCenter, ESXi, vSAN or NSX.

However, please do consider at least some reserved capacity for AVS at the time of deployment as the savings are significant (up to approximately 34 percent for one-year reservations and approximately 53 percent for three-year reservations). For organizations with Windows Server 2012 and SQL Server 2012 workloads, there is additional financial incentive, as Microsoft will waive the extended security patch support fees for those workloads if migrated into AVS.

Migrations or disaster recovery

With the included VMware HCX licensing, organizations can migrate workloads back and forth between on-premises VMware infrastructure and AVS. This can be useful for retiring an aging data center facility or perhaps evacuating one due to an expired lease or a consolidation strategy.

Additionally, AVS can be used to host VMware workloads during data center maintenance activities or even as a Disaster Recovery (DR) site.

As already discussed, many operational tools already popular for use with VMware environments can still be used with AVS. As such, organizations may continue using VMware Site Recovery Manager (SRM) with AVS to protect their workloads by orchestrating DR plans for both testing and failover.

That said, if an organization is considering AVS purely for DR, cost should be considered as AVS clusters consume entire Azure bare metal instances unlike other, more economical native Azure services (e.g. Azure Virtual Machines).

An organization may opt for a strategy that will put at least some AVS capacity to work while reserving enough for a DR event.

Bursting or expanding

Organizations can leverage AVS for bursting VMware-based workloads to the public cloud or for general VMware site expansion.

For example, if an organization needs to increase compute and storage temporarily, a new VMware host or even entire cluster can be spun up in minutes and then removed later once it is no longer needed.

Alternatively, adding VMware hosts and clusters within AVS for either anticipated or required capacity growth is as simple as logging into the Azure portal and adding more hosts or clusters. This alone is a very attractive feature as any IT administrator can attest to the time and effort required to spec out physical infrastructure; place orders for the same; wait through long lead and shipping times; rack and cable gear; install, update and configure logical components; conduct acceptance testing; and finally make that additional capacity available to end users.

An entire AVS environment can be deployed within about an hour and a half, and an existing AVS environment could have seen an additional host integrated in the time it took to write this paragraph.

Organizations can focus IT personnel on more innovative and useful tasks like architectural planning, automation and security because, with AVS, there is no lifecycle management of underlying physical hardware and VMware components. All of that is handled for the customer, courtesy of Microsoft Azure.

Cloud adjacency and application transformation

Microsoft Azure employs fiber backbone, interconnecting, world-class data center facilities located in Azure Regions around the globe. Indeed, some savvy organizations build public cloud infrastructure in Azure with the intention of using that backend in place of a traditional Wide Area Network (WAN) — a perfectly valid strategy.

As more and more workforces go remote, or even mobile, the fact is that end users will likely see less network latency to an Azure site than they will to a traditional, on-premises corporate data center. This same Cloud adjacency argument applies to customer interactions, as well, which are increasingly via mobile applications.

Similarly, organizations are enlisting native cloud services to modernize and transform their applications, but some components might need to remain on VMware infrastructure for various reasons, creating network latency concerns if an organization's only VMware infrastructure is on-premises.

AVS can be employed in all of these situations to get VMware-based workloads closer to customers, end users and cloud-native services to achieve lower network latencies and thus better application performance and user experiences.

Components

When AVS is deployed, the initial cluster will include:

VMware ESXi hosts for compute virtualization with a vCenter server appliance for management.
VMware vSAN hyper-converged storage incorporating the physical storage assets of each ESXi host.
VMware NSX for virtual networking and security with an NSX Manager cluster for management.

VMware HCX is also included (advanced licensing as of this publishing), which is the magic sauce for integrating with your existing VMware environment(s) and migrating workloads.

Once HCX is deployed, organizations can create a site pairing between their existing VMware environment(s) and AVS to deploy network services for optimized interconnection and workload migration and even network extension for workload migration without changing IP addresses.

There is also an option with AVS to upgrade HCX to enterprise licensing, which provides additional features such as OS-assisted replication, mobility groups, replication-assisted vMotion (or RAV), SRM integration, and Mobility Optimized Networking (or MON).

See a comprehensive list of HCX features included with each license edition.

In WWT's Advanced Technology Center (ATC), we employed HCX to connect between our on-premises VMware Cloud Foundation environment and AVS, allowing us to demonstrate the ability to move workloads back and forth between on-premises and AVS as well as other VMware on public cloud solutions. For reference, please see the diagram below which represents the ATC environment.

Diagram representing WWT's Advanced Technology Center (ATC) environment. HCX is used to connect WWT's on-premises VMware Cloud Foundation environment and AVS

Planning

AVS does require some up-front planning. The first thing to consider is which Azure subscription will be used to deploy AVS. The subscription must be associated with a Microsoft Enterprise Agreement (EA) or a Cloud Solution Provider (CSP), so an organization may need to create a new subscription or convert an existing subscription to an EA. Alternatively, consider leveraging WWT as the CSP.

Skipping this step will result in the following error message when attempting to deploy AVS.

Users will receive an error message when deploying AVS if they do not have a subscription associated with a Microsoft Enterprise Agreement, Cloud Solution Provider or WWT.

From there, an organization must consider connectivity into Azure. An Azure ExpressRoute connection is required for production AVS deployment, and VMware recommends at least a 250Mbps connection for use with HCX.

Organizations looking to deploy AVS will need to work with either their telecom service provider or their colocation service provider to provision this connectivity if it does not already exist.

Please note that ExpressRoute Global Reach, an Azure native service, is also required for the network peering and exchanging of routes between AVS, any native Azure Virtual Network (VNET) belonging to the subscription and the ExpressRoute gateway.

Next, an organization should consider which global location, or Azure Region, to deploy AVS in. Currently, AVS is not available in every Azure Region, but more will be coming online in the very near future. Regardless, an organization must determine requirements and deploy into an available region that meets the business objectives and goals.

At this point, an organization can begin deploying AVS.

The first thing needed is a dedicated Azure Resource Group wherein you will deploy at least one native VNET, ExpressRoute and AVS. Current documentation reflects that an existing Resource Group may be used, but that assumes all previously mentioned requirements for Azure subscription, ExpressRoute and Region have been satisfied.

Next, determine the number of ESXi hosts that will be needed. Currently, there is only one Azure bare metal instance available to be used for AVS hosts (AVS36), though more bare metal instances may be supported in the future. The initial cluster size must be three hosts at minimum.

After the initial deployment, additional hosts can be added in increments of one or more up to 16 hosts maximum in a single cluster. Also during deployment, an IP network of /22 mask length must be provided for addressing all the VMware infrastructure components in the AVS environment (other IP address segments will be provisioned for VMware virtual machines later on in NSX Manager). This /22 block of IP addresses should not conflict with any other IP address spaces in use within the Azure Resource Group or within any of the organization's interconnected environments.

Armed with this information, an IT administrator can login to the Azure portal, search for AVS and deploy the solution. The screen capture below shows the AVS initial deployment screen.

The initial AVS deployment screen users will see when logging into the Azure portal

AVS will automatically deploy a VMware SDDC using the designated AVS36 instances as ESXi hosts in less than two hours.

Once the automated deployment completes, an organization can access their AVS environment's vCenter and NSX Manager to begin administrative and operational tasks as with any other VMware infrastructure.

One additional step will be to configure VMware HCX for interconnecting the AVS environment with, say, an existing, on-premises VMware environment. A high-level overview of this process is as follows: download and deploy the HCX OVA; configure a site pairing between the on-premises and AVS environments; create network profiles, compute profiles and service meshes; and finally, migrate workloads. These efforts will be further detailed in successive content that focuses on VMware HCX deployment, configuration and usage.

Conclusion

In summary, AVS is a great option for organizations interested in public cloud and wish to leverage existing VMware expertise, achieve an OPEX-based financial model, scale infrastructure elastically, migrate or protect virtualized workloads, or even transform applications and user experiences.

AVS is a mature and credible Azure service offering, and WWT recommends it to any organization for which it meets business requirements. With a little upfront deployment planning, integrating AVS into an organization's hybrid multicloud architecture will go smoothly.

For VMware administrators and operators, managing and maintaining AVS will be a familiar experience with many welcome advantages.