What is Azure Stack HCI?
Azure Stack HCI is a hyper-converged infrastructure (HCI) which consists of one or a cluster of specific physical hardware that is running the Azure Stack HCI operating system. Hyperconverged infrastructure is a server which integrates its own compute, networking and storage components and manages those components using software. Azure Stack HCI allows you to use the Azure portal to manage the HCI cluster and resources that are hosted on it. Supporting multiple Azure services such as Azure Virtual Desktop, Kubernetes service, SQL Server, storage, and more.
The Azure Stack HCI Operating Solution is created based on existing technologies such as Hyper-V, Storage Space Direct and Windows Admin Center. What makes this solution even more appealing is that, unlike traditional datacenter solutions, you can completely monitor the resources through the Azure Portal, which simplifies inventory management and management overhead. This allows you to take advantage of the governance and uniformity of the Azure platform, yet at the same time run your workloads in your datacenter instead of the cloud.
What is the difference with Azure ARC?
Azure Stack HCI essentially allows you to extend the service which Azure offers to your datacenter. For this to work, you will need the hardware and the dedicated Azure Stack HCI Operating System which enables you to run Azure services on hardware in your datacenter.
Azure Arc allows you to register and onboard existing on-premises workloads and govern them in a unified way using Azure Policy. Unlike Azure Stack HCI, which is deployed onto physical hardware and acts as the operating system/hypervisor, Azure Arc leverages an agent to connect your on-premises workloads to the Azure management plane.
What problems does AVD on Azure Stack HCI try to solve?
Why would you want to run Azure Virtual Desktop workloads on your Azure Stack HCI cluster? There are specific cases where you would want your session hosts closer to an application which is hosted on-premises. Such as reducing latency between the session host and the application hosted on-premises, while in turn increasing the performance and user experience.
Trusted virtualization stack with simplified management
Navigating the modern IT landscape presents a considerable challenge for companies. Dealing with numerous vendors and applications often means managing different credentials and connection protocols. Azure Stack HCI wants to step in to solve these complexities, offering a unified solution that streamlines connectivity and management across diverse systems and platforms. This is especially true for companies that are already making use of other Azure Services. Solving a part of this problem is achieved through being able to manage the cluster and the workloads using the Azure Portal.
Performance and latency requirements
When latency is a concern for your workloads, running Azure Virtual Desktop on Azure Stack HCI could be a solution. Because you have full control over where you deploy your Azure Stack HCI cluster, you can choose to deploy it close to, for example, your ERP system for the lowest latency resulting in a more optimal user experience.
In the above diagrams, the discovery and network flow from the session hosts to local resources is illustrated. The diagram on the left outlines the flows for session hosts hosted in the Azure Cloud. As shown, the discovery flow uses a VPN Connection to securely connect to the Azure Virtual Desktop Private Endpoint. From there, the same VPN connection is used to connect to resources which are only available from the internal network. When working with latency-prone applications, this can incur issues.
The diagram on the right illustrates the flows for session hosts deployed to an Azure Stack HCI Cluster. Because the Azure Stack HCI cluster is deployed close to the resources available on the local network, the latency will be significantly lower due to not having to traverse the VPN tunnel and overall fewer hops.
Related to this is the cost tied to the ingress and egress in Azure. When frequently accessing resources in the private datacenter and transferring large amounts of data, it might be a good idea to relocate the Azure Virtual Desktop environment to an Azure Stack HCI cluster deployment.
Additionally, when connectivity to the Azure public cloud is not very consistent or very slow, running the cluster locally and closer to the end users will increase performance tremendously.
Current limitations and challenges with this solution
The points discussed in the previous topic can be a trigger to innovate and deploy a virtual desktop infrastructure with Azure Virtual Desktop and Stack HCI. Microsoft has made this solution generally available, which in theory means that it is ready for production workloads. However, there are still quite some limitations with this entire solution. Allow us to explain.
Autoscaling
There is currently no autoscaling support for Azure Virtual Desktop workloads running on Azure Stack HCI. This means that, unlike on Azure, your session hosts cannot be shut down based on a scaling plan that is configured for that host pool. This is a major downside as with Azure Virtual Desktop workloads you can scale down the session hosts after business hours to cut back on costs and ramp them back up at the start of the day to meet session demands. This however is not possible with AVD on Azure Stack HCI.
A new blogpost on 11 April has announced the public preview of Autoscaling support for Stack HCI. This is a huge leap forward and a great step in the right direction, showing Microsoft is actively working on improving the current iteration of the Azure Stack HCI platform.
Cost Aspect
Secondly, we have the cost aspect, there are three main aspects that we need to take note of:
1. User Licensing
2. Azure Stack HCI Service Fee
3. Azure Virtual Desktop Service Fee
Let us review the costs for a VDI environment of 100 users. For multisession light workloads, Microsoft recommends 8vCPUs and 16GB RAM size for a session host which will facilitate 6 users per vCore. Let's take a conservative and safer look at the sizing and let's say we can facilitate 5 users per vCore for each situation. This means that each virtual machine can host 40 users, resulting in 3 session hosts to fulfil the user requirement. The Azure Stack HCI Sizer recommends a 2x40 core 512GB RAM server setup. This results in the following costs:
| Azure Virtual Desktop | AVD on Azure Stack HCI |
Azure Virtual Desktop Service Fee | N/A | € 0,01/vCore/hour * 8 * 3 * 730 |
Azure Stack HCI Service Fee | N/A | € 10,00/Physical Core/month * 80 |
Compute Cost | 3 * € 558/Month | N/A |
Intermediate Cost | € 1.674/Month | € 975,2/Month |
Autoscaling Percentage | 22 days 50% usage 8 days 0% usage | N/A |
Total Cost | € 613,8/month | € 975,2/Month |
It might seem that the cost for Azure Virtual Desktop on Azure Stack HCI is cheaper than roughly the same configuration when using session hosts in Azure. However, keep in mind that we can use autoscaling to reduce the uptime of the session hosts. In the field we usually see a ramp up at 7 am and a ramp down at 7 pm. This means we will run at a reduced amount of session hosts for 12 hours a day, cutting our computing costs in half! And if we even go for a smaller size, we will be able to scale even more efficiently than when using more scaled-up virtual machines. We have added a short calculation in the table above to highlight the difference.
To add to this, keep in mind that you will still need to acquire the physical servers to install the Azure Stack HCI Operating System, unlike on Azure where you can just deploy your required resources freely. And in turn, also remove them when they would not be required anymore.
No Entra ID Join option
At time of writing, the only join option for the session host is "Active Directory". This means that you can register the session hosts in Intune but are not able to make use of the rich features which Intune provides. Device management via Intune helps unify the deployment and management process of the virtual machines. Neither do you have the option to configure Single Sign On (SSO) for your end users when logging in with the Remote Desktop Application or Web Client. This is quite a big deal as you are unable to enforce multifactor authentication or validate the authentication request using Conditional Access Policies as this requires Entra ID joined or Hybrid Entra-Id Joined sessions hosts (Source: Microsoft Documentation)
In the future, it will be possible to create session hosts that are either Entra ID or Hybrid Entra ID joined. Consequently, this will also enable support for Intune management and the ability to leverage Conditional Access Policies to, for example, enforce Multifactor Authentication.
Of course, it is still very much possible to manage and implement restrictions on the session hosts when they have been joined to an Active Directory domain. In this case, we can implement restrictions and increase security measures through the use of Group Policies.
Currently existing clusters
Potentially, one of the biggest blockers for customers who are already making use of an Azure Stack HCI cluster is the fact that there currently is no upgrade path from a previous 22h2 Stack HCI version to the newest 23H2 Stack HCI version. This means that if you are already running a previous version of Azure Stack HCI on your cluster, you would need to create a completely new cluster setup to install the 23H2 version. This action entails a tremendous amount of rework and will be in a lot of cases not a feasible option, especially for small to medium-sized companies.
Another approach which will also require a large resource and monetary investment, would be to deploy a second cluster and install the required 23H2 version there. This will ensure that the workloads on the current cluster can keep functioning. The second step would then be to deploy the new Sessions hosts to this newly created HCI Cluster.
Potential Use Cases
Companies that want to make use of this service will want to take advantage of all the strong features and issues AVD on Stack HCI tries to solve. All this while not (fully) impacted by the current limitations it poses. Let's look at some possible use cases:
The first use case could be at a company whose Virtual Desktop Infrastructure will soon go out of support and are looking to innovate using the newest technologies hence they are already using Azure. As new physical hardware will be required, they are looking at implementing their Virtual Desktop environment using Azure Virtual Desktop. They can manage their AVD setup using the Azure portal, which they are already using. This in turn will reduce management complexity and will streamline their complete environment.
Secondly, a company with many distributed or more secluded locations can benefit from having their on-premises resource able to be managed through the same interface, read Azure Portal, as their already existing cloud environment. This reduces complexity in the complete environment and will improve efficient work due to not having multiple and sometimes, convoluted connection mechanisms to the resources. Additionally, this will increase the security of the environment as this reduces potentially exposed management IP addresses on the internet.
Lastly, with the management of the HCI cluster and workloads through the portal, you can enforce permissions to the cluster with PIM and approval flows. Also, logins to the Azure portal will require Multi-Factor Authentication which reduces the attack vector for accounts, resulting in an overall more secure management process.
Finally, we have a company which is currently already using an Azure Virtual Desktop setup but is having trouble achieving the latency and performance thresholds for their legacy application. In this use case, they can leverage the low latency and performance from having their local resource close to their Virtual Desktop infrastructure and for backwards compatibility options, they decide to use Windows Servers as the session hosts. They will domain join their session hosts so that they can manage them using GPOs as they are currently already doing for the rest of their on-premises workloads.
Conclusion
Azure Virtual Desktop on Azure Stack HCI tries to tackle issues such as Latency and performance requirements and tries to unify the management process of your complete Azure and on-premises environment. However, there are major blockers such as the cost associated with the service, no autoscaling support, no Entra ID join option for the session hosts and not getting native insights into the AVD environment. These are some very potent features of AVD which are NOT available in AVD on Azure Stack HCI. (yet?)
If your company is looking to build a virtual desktop infrastructure and is looking at Azure Virtual Desktop to fulfil those needs, make an in-depth analysis of which aspects are vital to a successful implementation. Be sure to weigh the limited added benefits to the current issues with the solution. Luckily, Microsoft is already implementing new changes to address these blockers. Once these are solved, the product seems interesting to solve some latency and performance issues and implement a simpler management layer and can be a strong competitor to already established VDI solutions in today's market
