So, you want to run your desktops in the cloud? That’s great! We can help you navigate your public cloud options so your business can maximize the benefits that the cloud can bring to your organization. But hold on just a minute. Before we dive in headfirst, let’s take a step back and understand some of the nuances of running VMware Horizon in a public cloud. “Nuances?” you might ask. Absolutely! To start, make sure you have documented your business drivers and your technical and non-technical requirements for this move to the public cloud. Always make sure you have representation from both the technical and business side of your organization when declaring all your requirements, as this is key to a successful move to the cloud. While this article is not intended to cover design decisions for a Horizon public cloud deployment, we will discuss a couple for the purpose of integrating a few different services.
Now that you have your requirements defined, we can begin to help you understand the different public cloud options available for Horizon desktops. You might say, “I thought these public clouds were relatively the same?” Well, I know you hear this a lot, but the truth is: it depends! That’s why we start with business drivers and requirements, and then consider the nuances of the different public clouds. Although there are some similarities between them, they do not offer all the same options when it comes to Horizon desktops. Here are some considerations. Do you require or desire a Desktop as a Service (DaaS) offering or will you manage the Horizon infrastructure yourself? Are you using NSX features on-prem with your desktops today? Do you have a specific security requirement for the desktops provided by a 3rd party vendor? What software are you running within your desktop OS? Once these are answered, we can begin to help align your requirements to the different public cloud providers.
Today, I will be focusing on AWS, specifically, VMware Cloud on AWS (VMC on AWS). Although I won’t go into a lot of details on this offering, VMware Cloud on AWS is an integrated cloud offering jointly developed by AWS and VMware where you can run your vSphere workloads on AWS infrastructure that is managed by VMware. See here for more details.
Horizon Components
Let’s quickly review the components. The individual Horizon components will be the same as what you have running on-prem today. The exception could be if you are not currently using the Horizon Cloud Connector. For those of you that are new to Horizon, the following make up the Horizon infrastructure components:
- Horizon Cloud Connector
- Horizon Unified Access Gateways
- Horizon Connection Servers
- Load Balancer
- App Volumes
- VMs
For today’s discussion, we will be using the Cloud Connector, Connection Servers, and a Load Balancer.
Horizon Deployment Choices
For those of you who already run and support VMware Horizon today on-prem, deploying Horizon on VMC on AWS is similar. Let’s dive into the Horizon part a little more. There are two Horizon deployment options available to use with VMC on AWS as of today: the All-in SDDC Architecture and the Federated Architecture. The All-in SDDC option is what we will focus on and is similar to what you might already have deployed on-prem. For specific details on feature parity between Horizon on VMC on AWS and Horizon on-prem, see here.
The All-in SDDC architecture consists of deploying all the Horizon components inside the VMC on AWS Software Defined Data Center (SDDC). Your deployment choice will depend on your requirements. Below is a figure that shows the Logical Architecture diagram of the All-in SDDC deployment.
Figure 1: All-in SDDC Logical Architecture
Availability and Scale
Think about how much scale will you need and what type of availability do you require for your Horizon desktops. If you are running Horizon today on-prem, you most likely have heard of the Pod and Block concepts for Horizon. If you’re not familiar, a Pod is made up of a group of interconnected Connection Servers that broker connections to desktops or published application. A block, on the other hand, is what provides the capacity to the Pod. Each block contains one or more vSphere clusters, including its own vCenter. How do you determine how many Pods and Blocks will you need? Let’s go back to those requirements you defined in the beginning. If you have a requirement to scale beyond the size of a single Pod, you can build out multiple Pods. Today, we are deploying a single Pod with one resource block. With VMC on AWS, the resource block will be a single SDDC per the recommendations from VMware to avoid any protocol traffic hair pinning between SDDCs.
Now let’s consider the availability question. If you have a requirement to provide redundancy beyond what a single Pod can provide, we can deploy another Horizon Pod into a different VMC on AWS availability zone or region. By leveraging multiple regions, we now are protected against any regional outages in AWS. Although not a common problem, Availability Zone (AZ) and regional outages can occur. For reference, VMware offers a 99.9% SLA for a VMC on AWS deployment in a single Availability Zone.
You might be asking, “If we deploy across different AZs or regions, how would we broker connections across multiple Horizon Pods?” Remember that scaling your Horizon resources could be within a single region for additional capacity beyond what 1 POD can provide or across regions for DR requirements. There are two options today: Horizon Universal Broker (UB) and Cloud Pod Architecture (CPA). We will be focused on the Universal Broker; however, Cloud Pod Architecture has been around for a while, and you might even be using this for your on-prem Horizon deployments. Further details around CPA can be found here.
Here’s a quick intro to Universal Broker. It’s a cloud-based brokering technology and is part of the Horizon Control Plane services found in the fully managed VMware Horizon Cloud service. Universal Broker provides the ability to broker multi-cloud assignments that span multiple Horizon pod deployments regardless of the underlying infrastructure. Universal Broker can also broker sessions based on where the user’s and pods are located. Additional information on Universal Broker can be found here.
Please note that the End of Life (EOL) date for the Horizon Cloud Service First-Gen Control Plane is currently targeted for Jan 31, 2024. Details about that announcement are located here. The Next-Gen Horizon Control plane is available; however, Universal Broker has not been added to it yet. So, for now you will need to continue to use the First-Gen Control plane and submit an exception request using the link located in the KB I posted. Below is a figure that shows Horizon internal users using Universal Broker with multi-site pods on VMC on AWS.
Figure 2: Universal Broker with multi-site pods on VMC on AWS
Load Balancing
We now need to discuss and decide what services will need to be load balanced. Will the users be accessing Horizon desktops only from the Internet using UAGs or only from your internal network with or without internal UAGs or some combination of these options? The answers to these questions should have been defined in your requirements.
For this article, I will be focused on internal-only access without internal UAGs. When using Horizon Universal Broker (UB) with the internal traffic-only use case without internal UAGs, a load balancer will not sit in front of the Connection Servers. UB talks directly with the Connection servers. For the rest of this article, I will be building out a design using UB with the internal-only use case.
Back to the load balancing topic. Does this mean you won’t need a load balancer at all for this deployment type? I’ll let you decide but let me explain a few things first. Placing a load balancer in front of the Horizon connection servers can still provide benefits, specifically when trying to mitigate the risks in this type of design. Currently, the Cloud Broker Client Service within the Horizon Cloud Connector (HCC), which supports UB, is only available on the Primary node, thus deploying an HCC cluster does not mitigate against this single point of failure.
So, what happens if you experience a problem with the HCC or the Horizon control plane? Depending on your design and how many PODs you have available, one option is to redirect your users to a different FQDN until the issue is resolved. That FQDN could be a load balancer in front of your connection servers.
Since we are using VMware Cloud on AWS, we have a few options for load balancers. We can leverage a native AWS load balancer, VMware’s Advanced load balancer (formerly AVI), or a 3rd party Load Balancer. For this article, I have selected the AWS Application Load Balancer (ALB). I have deployed the AWS ALB in a customer AWS account. To connect and route the load balancer traffic to and from our SDDC, I have deployed a VMware SDDC group and configured a peering attachment to my AWS Transit Gateway. We will continue to build off this design in the following section based on other requirements for my use case. Additional details around SDDC groups can be found here.
The AWS ALB will only load balance the primary XML-API protocol over HTTPS traffic. The secondary protocol connection or Phase 2 traffic will be directly between the Client and the Desktop, assuming there is no tunneling through the Connection Servers. If you have PCoIP requirements, a different design and configuration will be required. The following figure shows a high-level architecture with an integrated AWS ALB in a customer VPC. You could also deploy the ALB in the “Connected VPC”.
Figure 3: AWS ALB for VMC on AWS
Networking and Security
Let’s go back to your requirements again. What are your connectivity requirements between your data center, end users, and the cloud? Where does your Internet egress and ingress point need to be? VMware Cloud on AWS includes NSX-T which handles all the networking functionality within the SDDC. NSX-T also has built in firewalling capabilities that are included with the current cost of this offering. Recently announced at Explorer 2023 Las Vegas, the NSX-T advanced firewall features will now be included for free. Some organizations can satisfy their requirements using the NSX-T firewall for their workloads, and if that applies to your organization, that’s great.
However, if you have specific requirements or existing skills with another firewall manufacturer, you can also leverage 3rd party firewalls deployed in AWS or a very limited use case deployed within VMC on AWS. For our discussion today, we are going to use a 3rd party firewall that we have deployed in AWS. While I won’t discuss a specific firewall vendor or the deployment of one now, Converge can help you navigate all your options and help you deploy the firewall(s) against best practices. Building off our deployment in this article, the following figure shows a 3rd party FW integrated with VMware Cloud on AWS.
Figure 4: 3rd Party FW in AWS for VMC on AWS
Conclusion
As you can see from some of the technologies we briefly discussed today, we can now provide a comprehensive solution for your Horizon desktops to operate in the public cloud. While we only touched on a few specific design decisions today, different requirements can change your design and deployment choices. Always define your technical requirements up front along with any business requirements to ensure a smooth transition to public cloud. As we discussed, you can scale your Horizon deployment within the same AZ, across AZs or across regions based on your requirements and continue to integrate your additional VMware Cloud on AWS SDDCs and Horizon PODs building off this design.
Converge is here to help you navigate your public cloud options and to ensure your public cloud journey is a successful one.
The following figure shows the technologies we integrated at a high level with VMware Cloud on AWS throughout this article.
Figure 5: Universal Broker, AWS ALB, 3rd Party FW with Horizon Desktops on VMC on AWS
Please reach out to [email protected] to start your cloud journey today.
