New Guide: VMware Horizon Cloud Service - next-gen Network Ports Diagrams
VMware Horizon® Cloud Service™ - next-generation was for all customers on 11 August 2022, ending about 6 months of successful customer trials on the new platform. One of the design goals was to make the product simpler to implement and easier to scale. We accomplished this by moving critical functional components out of a customer domain.
To support this exciting release, we have published an accompanying asset—the . Organizing this level of detail in network diagrams can be a tedious process but one advantage is gaining intimate knowledge about how the product works. Because the Horizon Cloud Service - next-gen platform is simpler, there are fewer components within the customer domain and therefore, fewer diagrams to maintain.
You can see the difference in Figure 1 – the new Horizon Edge Gateway deployment is much simpler from a network communications point of view than Horizon Cloud on Microsoft Azure was.
If you'd like to examine the full resolution diagrams, compare Figure 1 in the Horizon Cloud Service on Azure Network Ports Diagrams doc and Figure 1 in the new Horizon Cloud Service - next-generation Network Ports Diagrams doc.
Figure 1: Comparison of Horizon Cloud on Microsoft Azure Ports Diagrams vs. Horizon Cloud Service - next-generation on Microsoft Azure Infrastructure Ports Diagram
Simplified networking in Horizon Cloud Service - next-generation
Let’s take a brief look at the development of this simplified solution. With Horizon Cloud on Microsoft Azure, we had to maintain nine separate diagrams for different user connection configurations. Some of the diagrams represented using the broker that existed on the Horizon Cloud on Microsoft Azure Pod Manager VM, and others depicted differences in routing customer access from an internal customer network. The Pod Manager VM maintained the current status and availability of resources in the pod, and each user’s entitlements. The Pod Manager VM was a critical piece of infrastructure and although it was hosted in a customer’s infrastructure, the Horizon Service had to make sure that it was available and operating well.
In 2019, we introduced the Universal Broker for Horizon Cloud Service which moved the brokering functionality to the Service and out of the customer domain, but the solution was still engineered to work with the Pod Manager VMs to lookup availability of resources and user entitlements. Although it improved a multi-pod deployment of Horizon Cloud Service, it was still reliant on the Pod Manager VM.
Figure 2: User Connections with Horizon Cloud Service - next-generation
With Horizon Cloud - next-generation on Microsoft Azure infrastructure, all connection brokering is done by the cloud service. Furthermore, canonical records of user assignments are stored in the service instead of in each individual pod. This makes a user’s connection simpler, because they only need to connect their Horizon Client to their tenant in the service to be assigned a resource, and then be routed to an appropriate resource in their own Horizon Edge deployments – wherever they exist. More details on deployment architecture can be found in the .
Canonical records on the fleet of virtual machines and their availability are also managed by the service, and we will explain that in an upcoming blog.
Simplicity does mean a change to the end-user networking requirements. Users must have access to the Horizon Cloud Service to make the brokering decision instead of relying on a pod-based broker. Deployments that would have restricted user access to the Horizon Cloud Service or the Internet in general for the initial connection to the deployment will require some changes to allow this service to work properly.
By documenting these details visually in diagrams, our goal is for architects to understand and apply relevant networking changes to accommodate the need for this change. Taking a step back, by simplifying the networking requirements of a traditional VDI and Remote Applications platform deployment, we hope to make the product more resilient to changes in customer environments, and simpler to troubleshoot, maintain, and satiate auditors.