Hybrid Cloud - cloudecon.com https://cloudecon.com Cloud Architecture and Economics Tue, 19 Jan 2021 22:41:09 +0000 en-US hourly 1 https://wordpress.org/?v=6.8.5 Azure Hybrid Benefit Quick Reference https://cloudecon.com/2021/01/azure-hybrid-benefit-quick-reference/?utm_source=rss&utm_medium=rss&utm_campaign=azure-hybrid-benefit-quick-reference https://cloudecon.com/2021/01/azure-hybrid-benefit-quick-reference/#respond Tue, 19 Jan 2021 17:27:19 +0000 https://gvtechtalks.com/?p=1856 As I go through the day-to-day of analyzing the economics of various VMware software on Azure, I find myself constantly referring back…

The post Azure Hybrid Benefit Quick Reference first appeared on cloudecon.com.

]]>

As I go through the day-to-day of analyzing the economics of various VMware software on Azure, I find myself constantly referring back to nearly a dozen web pages for various Azure Hybrid Benefit information. The purpose of this article to collect the main points of the Azure Hybrid Benefit from the various publicly available places and organize it into a quick reference sheet.

Never make licensing decisions without talking to your Microsoft license specialist or a qualified partner.

Windows Server

Must have current Software Assurance

Azure VM (IaaS)

Legacy 2 physical socket licenses = 16 physical core licenses. Must license entire VM.

Azure Hybrid Benefit converts physical cores to virtual CPU (vCPU). Each Azure VM consumes a minimum of 8 core licenses.

Examples Per VM. Each VM uses a minimum of 8 core licenses.
1 vCPU = 8 physical core licenses
2 vCPU = 8 physical core licenses
3 vCPU = 8 physical core licenses
4 vCPU = 8 physical core licenses
5 vCPU = 8 physical core licenses
6 vCPU = 8 physical core licenses
7 vCPU = 8 physical core licenses
8 vCPU = 8 physical core licenses
9 vCPU = 9 physical core licenses
10 vCPU = 10 physical core licenses
11 vCPU = 11 physical core licenses
12 vCPU = 12 physical core licenses
13 vCPU = 13 physical core licenses
14 vCPU = 14 physical core licenses
15 vCPU = 15 physical core licenses
16 vCPU = 16 physical core licenses

Azure Dedicated Host

On-Premises licenses map core for core.
Example – 16 cores on-prem = 16 cores of Azure Dedicated Host
Various host sizes. Minimum licensing depends on the host choice. 

Azure VMware Solution (AVS)

On-Premises Licenses map core for core.
Minimum – 16 cores on-prem = 16 cores of AVS
The minimum cluster size is 3 hosts, 36 core each. Customers will have to buy or migrate 108 cores for the three hosts.

Info to Note

Standard licenses have a 180-day Dual-Use (on-prem and Azure) grace period.
Datacenter licenses have perpetual dual-use. 

SQL Server

Must have Software Assurance

Azure Native IaaS SQL Server VMs [1]

Microsoft shift from using the common vCPU term to the term vCore.  vCore and vCPU both reference a logical compute unit and are interchangeable [2]

Similar to on-premises 4 core licenses are the minimum number of licenses possible per SQL server [3].   

1 Enterprise physical core license = 1 Enterprise vCore (min 4 per server)
1 Enterprise physical core license = 4 Standard vCore (min 4 per server)
1 Standard physical core licenses = 1 Standard vCore (min 4 per server)

SQL Managed Instance and SQL Database Service [4]

SQL managed instance removes the minimum and is a more direct mapping. The delineation is between general-purpose, hyperscale,  and business-critical

1 Enterprise physical core license = 1 Business Critical vCore
1 Enterprise physical core license = 4 General Purpose vCore
1 Enterprise physical core license = 4 Hyperscale vCore
1 Standard physical core licenses = 1 General Purpose vCore

Azure Dedicated Host [5]

On-Premises licenses map core for core.
Example – 16 cores on-prem = 16 cores of SQL running on Azure Dedicated Host.

Alternatively, you could convert your licenses to vCPU and run SQL as an Azure VM running on Azure Dedicated Host using the above SQL Server VM method.

Linux

Azure VM (Azure Native IaaS)

Supported operating systems:

  • SUSE Linux Enterprise Server
  • Red Hat Enterprise Linux

Conditions

  • Must Deploy image from the marketplace and select existing Linux subscription
  • Must choose Paygo, 1- and 3-year reservations not eligible
  • Custom Images or BYOS imaged not yet supported.
  • Cannot stack SQL hybrid benefit and Linux Hybrid Benefit

“Reserved instances, Azure Dedicated Host instances, and SQL hybrid benefits are not eligible for Azure Hybrid Benefit if you’re already using the benefit with Linux VMs.” [6]

Azure Dedicated Host

Not currently supported

Azure VMware Solution

As of the date on this blog I suspect on Premises licenses can be brought to Azure VMware Solution. Subscriptions and compliance must be managed outside of Azure in the same method as used on-prem. Virtual Machines must be either moved from on-prem or built using VMware vCenter.

While it is documented that you can run RHEL and SUSE on AVS [7] I have not been able to find a document outlining the specifics.  Always speak to your Azure specialist or partner before making any decisions.

I hope you found this article helpful. I will update it as I learn more (or corrected) and as new and exciting benefits from Microsoft emerge. The Azure Hybrid Benefit can provide significant savings when understood and applied properly.

References

The post Azure Hybrid Benefit Quick Reference first appeared on cloudecon.com.

]]> https://cloudecon.com/2021/01/azure-hybrid-benefit-quick-reference/feed/ 0 HCX AVS Gateway Cutover https://cloudecon.com/2021/01/hcx-avs-gateway-cutover/?utm_source=rss&utm_medium=rss&utm_campaign=hcx-avs-gateway-cutover https://cloudecon.com/2021/01/hcx-avs-gateway-cutover/#comments Tue, 05 Jan 2021 22:34:22 +0000 https://gvtechtalks.com/?p=1795 The topic of L2 extensions with HCX comes up often when architecting HCX on AVS. Having the ability to do an L2…

The post HCX AVS Gateway Cutover first appeared on cloudecon.com.

]]>

The topic of L2 extensions with HCX comes up often when architecting HCX on AVS. Having the ability to do an L2 extension from on-premises to AVS allows customers to migrate VMware based workloads without re-IP the VM while at the same time maintaining default gateway and local security policies throughout the migration process.

In this blog post, we will walk you through the process of setting up an L2 extension with HCX and how to terminate and migrate your gateway from on-premise to the cloud once the migration is over.

The image below illustrates how our on-premise HCX appliance uses our express route connection to establish a tunnel with our HCX instance on AVS.

The green network represents our on-premises management network. The management components on AVS, including NSX, HCX, and vCenter are automatically created during the AVS provisioning process. 

Our focus for most of this blog will be on the blue network representing our on-premises L2 segments for our compute workloads. 

Note: For simplicity purposes, we decided only to represent a single L2 segment for our compute workloads; typically, customers would have multiple; however, the process for stretching and un-stretching L2 networks is the same regardless of the number of networks. 

Note: HCX does not currently support extending your on-premises networks used for vSphere management, such as vMotion and HCX components. For more details, please read the HCX user guide. https://docs.vmware.com/en/VMware-HCX/services/user-guide/GUID-BFD7E194-CFE5-4259-B74B-991B26A51758.html

In this blog post, we will not be covering the installation process for HCX. If you want more information on this topic, please see https://docs.microsoft.com/en-us/azure/azure-vmware/tutorial-deploy-vmware-hcx

From your on-premises vCenter, log into your HCX instance.

From the HCX UI, click on “Network Extension.”

Click on “Extend Networks”

Select the network you want to extend. In this case, we will be stretching our Contoso port group.

Note: This network can be VLAN backed, or VXLAN backed. The on-premise requirements for stretching networks with HCX are VDS (Virtual Distributed Switch), vSphere 5.5 or higher, express route, and an Intel-based processor.

Next, we need to enter the IP address of the gateway we want to extend into AVS. This process is the same regardless if your gateway is on a physical device or a virtual instance such as NSX. In our environment, the default gateway for our Contoso network is 10.255.255.1/24. 

I will be entering that information into the “Gateway IP Address” field and selecting my NSX-T1 router as the destination first-hop router in AVS. Keep in mind that this will not create another gateway on AVS; your default gateway will remain on-premise during the stretch. 

Note: For the “Extension Appliance” field, you more than likely will leave the default settings; however, if you want to stretch multiple portgroups and the aggregated bandwidth exceeds 2.5gbps, then it will be a good idea to deploy additional extension appliances to distribute the load.

The extension process should take a few minutes to complete.

At this point, our network is stretched into AVS. Please see the below diagram illustrating our network stretch.

As you can see, our default gateway is still on-premises. Keeping the gateway on-premises gives us the ability to continue to use our on-premises security stack while at the same time reducing significant network changes during the migration process.

 

While HCX provides the feature of having an L2 stretch, it is essential to note that the desired outcome is to eventually decommission the tunnel and the L2 extension once the migration is complete.

As long as the default gateway remains on-premises, any type of routing will have to be hair-pinned back to our local gateway; this will cause slower network speeds and egress charges through the express route.

As you can see from the diagram below, our red network is AVS native (non-stretched). If a VM on our blue network wants to communicate to a VM on the red network, the traffic will have to transverse through on-premises.

Once you have finished migrating every VM out of your stretched portgroup, you want to decommission the L2 stretch and migrate your gateway into AVS; this will eliminate the hair-pinning of the traffic. 

Note: Make sure you have pre-populated your security policies required to protect your workloads in your NSX AVS environment. 

 

The image below illustrates our desired network layout.

To migrate our default gateway, we need to “unexted” our stretched network from our on-premise HCX environment.

Select “Connect cloud network to cloud edge gateway after unextending” this will create a gateway in our AVS environment and attach it to our T1 router.

Once the network is unstretched, you should see the network being advertised back to your on-premise environment through BGP via your express route connection.

Note: This process should take a few minutes to complete.

Note: This process should cause a network outage since you need to decommission the gateway from on-premises to eliminate multiple routes to the same network. It is also recommended that you stop advertising the on-prem decommissioned network to reduce the downtime that BGP reconvergence would take. Depending on your setup you might also need to edit your roue filters to allow the new advertised subnet from AVS after unextending.

The post HCX AVS Gateway Cutover first appeared on cloudecon.com.

]]> https://cloudecon.com/2021/01/hcx-avs-gateway-cutover/feed/ 1 How to Access my vCenter and NSX Manager on AVS https://cloudecon.com/2020/10/how-to-access-my-vcenter-and-nsx-manager-on-avs/?utm_source=rss&utm_medium=rss&utm_campaign=how-to-access-my-vcenter-and-nsx-manager-on-avs https://cloudecon.com/2020/10/how-to-access-my-vcenter-and-nsx-manager-on-avs/#respond Fri, 23 Oct 2020 21:23:19 +0000 https://gvtechtalks.com/?p=1784 When you deploy a new instance of AVS (Azure VMware Solution), one of the first managerial tasks is to log in to vCenter and the NSX manager UI's.

The post How to Access my vCenter and NSX Manager on AVS first appeared on cloudecon.com.

]]>

When you deploy a new instance of AVS (Azure VMware Solution), one of the first managerial tasks is to log in to vCenter and the NSX manager UI’s. If you are unfamiliar with working in an Azure environment and how vNet’s operate, this task could seem a bit trivial. This post aims to walk you through the process of accessing these management components through a Bastion host.

 

When your SDDC finishes deploying, one of the first things you want to do is collect your vCenter’s and NSX managers’ URLs and credentials. You can do this by navigating into AVS from your Azure subscription portal.azure.com

Your “Identity” tab contains the URL’s to manage your vSphere and NSX environments. The IP’s used are provisioned based on the IP range you specified when you deployed your SDDC. You want to make a note of these URLs and the credentials required for each.

 

Note: that our management stack’s IP range is private and not routable over the public internet.

I will be using a VM residing in Azure Native as my bastion host in my lab environment. For more information about Bastion in Azure, please see https://azure.microsoft.com/en-us/services/azure-bastion/#get-started

 

The diagram below shows how my bastion host can reach my AVS management stack through the vNET gateway we used when we created our VMware Private Cloud in Azure. For more information on how to create a Private Cloud in Azure please see https://docs.microsoft.com/en-us/azure/azure-vmware/tutorial-configure-networking

Connecting via bastion is the recommended method, as opposed to RDP. With bastion, you don’t have to expose your jump box to the public internet, making it vulnerable to attacks.

Once you log into your Bastion instance, you can open a browser and navigate to your vCenter’s URL you collected from the “Identity” tab.

Enter the credentials collected.

You are now ready to start managing your vSphere environment!

The post How to Access my vCenter and NSX Manager on AVS first appeared on cloudecon.com.

]]> https://cloudecon.com/2020/10/how-to-access-my-vcenter-and-nsx-manager-on-avs/feed/ 0