AVS (Azure VMware Solution) -OR- SDDC (Software Define Data Center) -OR- VaaS (VMware-as-a-Service Solution)

AVS (Azure VMware Solution) Deployment as a FREELANCER

What should we call? AVS (Azure VMware Solution), SDDC (Software Define Data Center), VaaS (VMware as a Services), Who cares? In fact I don't. What I really care it gives ability to transform your on premises VMware environment to VMware Private Cloud (within Azure Public Cloud)

Today, I finished with deployment of first AVS solution as FREELANCER and trying to share my experience. You wouldn't find all of stuff due to NDA reasons perhaps your suggestion, guidelines would always welcome.

The question is no longer “if or when”, it’s “how”

• Run your native VMware workloads in Azure using vCenter, vSAN, NSX-T and HCX

Azure VMware Solution (AVS) is a private cloud VMware-as-a-service solution, allowing customers to retain VMware related investments, tools, and skills, whilst taking advantage of the scale and performance of Microsoft Azure.

How Do I Connect from On-Premises to AVS?

Azure VMware Solution (AVS) leverages Azure’s Express Route (ExR) and Global Reach services to provide a Layer-3 (L3) service from end-to-end. This allows for the flexibility to connect to AVS from On-Premises as well as connect to Native Azure Services via the same L3 connection. This connectivity option provides flexibility for different AVS/Native Azure Deployment Models:

Planning

addresses the considerations and actions to be taken prior to starting the deployment of the AVS private cloud. This includes planning for resource placement, resource naming, cluster sizing, requesting host quota, registering the AVS provider, and network allocation.

Create Azure Subscription, Resource Group, Virtual Network, Region, and Resource Name

1. Log into the Azure portal
2. Click?Create a resource
3. Type “resource group” into the search bar and select the “Resource group” item.
4. Click?Create
5. Select the appropriate subscription, provide a name for the Resource Group, and select the desired region.
6. Click?Review + create,?then?Create

Subscription - Select your Azure subscription in which AVS resources will be deployed

Resource group - Select new or existing resource group that will contain AVS resources

Region - Select Your Region that can associates with AVS

Review + create        

Use Virtual Network to:

• Extend your datacenter
• Build distributed applications
• Remotely debug your applications

As with the Resource Group creation, select a?Subscription?you want to use, then select the?Resource Group?that was created in the previous step.?Next, give the virtual network (vnet) a?name?and select the same?Region?used in the Resource Group.?Click on the?Next?button to specify IP addresses.

Define an?IPv4 address space?that you wish to associate with the vnet.?This range can be very large or very small depending upon the size of the AVS deployment required and what other services might be running in parallel within the resource group.?For example purposes, a /20 or a few /24 address spaces?are?more than sufficient. Subnets?are contained within the IPv4 address space and help delineate network traffic based upon function.?To create a subnet, click on the?+ Add subnet?button.

Here I am repeating the?+Add subnet?procedure and create an additional /24 range called?default?(though any name can be used) which will be used later within this section for jumphost creation.

Select default and click Next:Security

Leave the Security options as default unless your environment requires a change then click on Review + create        

Once the vnet is validated click on?Create?to build it.

Create a Azure VMware Solution (AVS) Private Cloud

The AVS creation wizard will spawn.?Please note that a support request must be opened with Microsoft in order to have AVS resources allocated to the appropriate subscription ID?before?it can be deployed, with those prerequisites out of the way, the AVS creation wizard screenshot is shown below with individual field descriptions?broken out below.

1. Subscription:?Enter the Azure subscription that you requested to be used with AVS.
2. Resource group:?Select the Resource Group created earlier within this article.
3. Location:?Pick the region you used for the Resource Group, taking care that it also is supported by AVS.
4. Resource Name:?Provide a name for your AVS?private cloud.
5. SKU:?Pick a SKU to be used.?
6. ESXi hosts:?Select the number of ESXi hosts you want to associate with your AVS deployment.?The minimum number of hosts that must be used is three.
7. vCenter admin password:?Specify a complex password for the?[email protected]?username you will use to connect in to vCenter post-deployment.
8. NSX-T Manager password:?Specify a complex password that will be used for logging into NSX-T with the admin account post-deployment.?
9. Address block:? Enter a private, non-overlapping CIDR block that AVS will use for functions like management, vMotion and HCX.?This range?cannot?overlap with the range you specified in your vnet created earlier within this guide.
10. Virtual Network:?Select the vnet that was created earlier within this guide.?The AVS deployment will create an expressroute circuit between this network and the private address block specified in the previous step.

With all of the above fields completed, click on?Review + create?to validate the inputs prior to deployment.

Create a Windows Virtual Machine JumpHost in Azure

While waiting for the AVS deployment to build, another item to build is an Azure jumphost that we can use to access AVS (specifically vCenter,?NSX-T and VMs running on top of AVS)?once it has been built.

To get started, logon to the Azure portal and select?Virtual machines?followed by?Add.

Below is an attached image which shows a description for each of the highlighted fields.

1. Subscription:??Enter the Azure subscription that you requested to be used with AVS.
2. Resource group:??Select the Resource Group created earlier within this article.
3. Virtual machine name:??Provide a descriptive name for the virtual machine (e.g. Jumphost as been used above)
4. Region:??Pick the?same region you used for the Resource Group and AVS.
5. Availability options:??Depending on the SLA needed for this VM, you can add availability options for it here.
6. Image:??Select the operating system you wish to use to access AVS.?From the above example we are using Windows Server 2019 but other operating systems will certainly work.
7. Azure Spot instance:??We select?No?for in our example.
8. Size:??This selection allocates vCPUs?and RAM to the virtual machine via predetermined sizes.?
9. Username:??Select a username that will be used to login to the VM once created.
10. Password:??Enter a complex password for the user account.
11. Public inbound ports:??Since we are using this as a jumphost to access AVS, we clicked on?Allow selected ports.
12. Select inbound ports:??We choose?RDP?to enable RDP access to the jumphost.
13. Licensing:??Leave this as?No?unless you have a Windows key?available to use.

After the above fields have been filled out, click on?Next : Disks >?to proceed to the next step in the wizard. Unless your jumphost is?going to be running other applications that require a higher performance OS drive,?Standard SSD?should be sufficient for the jumphost function.?Click on the?Next : Networking >?button on the bottom of the screen to proceed. AFTER THIS CREATE VM in a?default?subnet as part of our AVS?vnet.?

vCenter, vSAN, NSX-T and HCX.....Migration, Disaster Recovery,

find in later post

• Migrating virtual machines into AVS is facilitated through VMware HCX.
• AVS can be managed, monitored, and automated with the vRealize portfolio products.
• Networking extensions are available from NSX Advanced Load Balancer and VMware SD-WAN.
• VMware Horizon on AVS is the supported cloud virtual desktop solution.
• VMware Site Recovery Manager is the primary disaster recovery to the cloud solution.

BONUS:

Some example scenarios where AVS may be able to resolve IT issues are as follows:

• Data centre contract is expiring or increasing in cost:
• Hardware or software end of life or expensive maintenance contracts
• Capacity demand, scale, or business continuity
• Security threats or compliance requirements
• Cloud first strategy or desire to shift to a cloud consumption model
• Local servers in offices are no longer needed as workforces become more remote

Azure VMware Solution uses the customers Azure account and subscription to deploy Private Cloud(s), providing a deep level of integration with Azure services and the Azure Portal. It also means tasks and features can be automated using the API. Each Private Cloud contains a vCenter Server, NSX-T manager, and at least 1 vSphere cluster using vSAN. A Private Cloud can have multiple clusters, up to a maximum of 64 hosts. Each vSphere cluster has a minimum host count of 3 and a maximum of 16.

AVS uses local all-flash vSAN storage with compression and de-duplication. Storage Based Policy Management (SBPM) allows customers to define policies for IOPS based performance or RAID based protection. Storage policies can be applied to multiple VMs or right down to the individual VMDK file. By default vSAN datastore is encrypted and AVS supports customer managed external HSM or KMS solutions as well as integrating with Azure Key Vault.

An AVS Private Cloud requires at least a /22 CIDR block on deployment, which should not overlap with any of your existing networks. Access to Azure services in your subscription and VNets is achieved using an Azure ExpressRoute connection, which is a high bandwidth, low-latency, private connection with automatically provisioned Border Gateway Protocol (BGP) routing. Access to on-premises environments is enabled using ExpressRoute Global Reach. The diagram below shows the traffic flow from on-premises to AVS using ExpressRoute Global Reach.

AVS Native Azure Integration

AVS is the native integration with Azure services using Azure’s private backbone network. Although the big selling point is of course operational consistency, eventually applications can be modernised in ways that will provide a business benefit or improved user experience. Infrastructure administrators that no longer have to manage firmware updates and VMware lifecycle management are able to focus on upskilling to Azure.Deployment of a Private Cloud with AVS takes as little as 2 hours, and some basic Azure knowledge is required?since the setup is done in the Azure Portal, and you’ll also need to create a Resource Group, VNets, subnets, a VNet gateway, and most likely an ExpressRoute too.

AVS (Azure VMware Solution) NODE TYPE

The standard node type used in Azure is the AV36, which is dedicated bare metal hardware with the following specifications:

• CPU: Intel Xeon Gold 6140 2.3 GHz x2, 36 cores/72 hyper-threads
• Memory: 576 GB
• Data: 15.36 TB (8 x 1.92 TB SSD)
• Cache: 3.2 TB (2 x 1.6 TB NVMe)
• Network: 4 x Mellanox ConnectX-4 Lx Dual Port 25GbE

Pre-requisites

• A new or existing Azure subscription associated with a Microsoft Enterprise Agreement (EA) or a Cloud Solution Provider (CSP) Azure plan. This guide assumes the subscription is under a Microsoft EA.
• If VMware HCX will be deployed and leveraged for cloud migration, the connection between the on-premises environment and Azure must meet the HCX Network Underlay Minimum Requirements At the time of this writing, HCX 4.1 is the currently deployed and supported version of HCX on AVS. This version requires an Azure ExpressRoute connection as the underlay.???
• Azure ExpressRoute is required to leverage VMware Site Recovery Manager for disaster recovery

Considerations/Recommendations

AVS is jointly engineered with Microsoft Azure as the operator. Periodic updates and fixes, remediation of failures, and general support are provided by Azure.

Configuration Maximums:

• Clusters per private cloud: 12
• Maximum hosts per cluster: 16
• Maximum hosts per private cloud: 96
• vCenter per private cloud: 1
• vSAN capacity limit: 75% of total usable space

Performance Considerations

vSphere runs on bare metal hardware, leveraging all-flash vSAN.

Network Considerations/Recommendations

• All gateways must support 4-byte Autonomous System Numbers (ASNs)
• AVS resources do not have public internet access enabled by default
• AVS requires a /22 CIDR network that does not overlap with any existing network segments deployed on-premises or in Azure
• Applications and workloads running in the AVS private cloud require DNS and DHCP services. You can deploy these services as virtual machines within the private cloud, configure and leverage the DNS and DHCP services provided by NSX, or extend these services from on-premises infrastructure

to be continue......