First-Gen Horizon Control Plane Architecture


This chapter is one of a series that make up the VMware Workspace ONE and VMware Horizon Reference Architecture, a framework that provides guidance on the architecture, design considerations, and deployment of Workspace ONE and Horizon solutions.

  • This chapter provides information about the First-Gen VMware Horizon Control Plane and the services it provides.

Introduction

The VMware Horizon Control Plane Services are feature-rich, cloud-based services that use a multi-tenant, cloud-scale architecture and enables administrators to choose where virtual desktops and applications reside. Example services enabled by First-Gen Horizon Control Plane include:

The capabilities of, or access to, each feature may be different based on the implementation of Horizon (Horizon on vSphere or VMware Horizon Cloud Service on Microsoft Azure) that you are using and the platform on which you are running Horizon. Example infrastructure platforms would be VMware vSphere, VMware Cloud on AWS, Azure VMware Solution, Microsoft Azure.

Refer to the product documentation for each feature listed previously for details on the platforms each feature serves.

Access to the Horizon Control Plane requires the use of a subscription license for your Horizon deployment. The Horizon universal license entitles you to any version of Horizon that you want through a single subscription entitlement. For more information, see the Compare tab titled Horizon Subscription SaaS on the VMware Horizon page.

You can acquire Horizon universal licenses from VMware or from partner resellers. After you acquire a Horizon universal license, you will receive an email that will begin your onboarding process for the Horizon Cloud Service. For more information, see Deployments and Onboarding to Horizon Cloud for Microsoft Azure and Horizon Pods.

Anyone who is currently using Horizon Cloud on Microsoft Azure is already using a subscription license. Each Horizon Cloud on Microsoft Azure pod is automatically connected to and leverages the Horizon Control Plane for functionality.

For a walk-through of the initial onboarding process for VMware Horizon Service, see the Horizon Service Journey page.

Horizon Cloud Administration Console

All of the services and functions provided by the Horizon Cloud Service are managed through the Horizon Cloud Administration Console. Functions managed by the Horizon Cloud Administration Console include:

  • The Cloud Monitoring Service which is used for all monitoring and reporting activity. In this user interface, administrators and Help Desk administrators can monitor all Horizon pods monitored or managed in their customer-tenant. Administrators can also schedule and run reports.
  • Access to the Help Desk features where administrators and Help Desk administrators can use the Search function to find user sessions that need troubleshooting.
  • All management and orchestration activities for Horizon Image Management Service. You can designate versions of images and publish or rollback images from your managed Horizon pods.
  • Configuration for Universal Broker and multi-cloud assignments to work with Universal Broker.

Pods

A key concept in a Horizon deployment is a pod. A pod is made up of a group of interconnected services that broker connections to desktops or published applications. A pod orchestrates and manages the infrastructure as required by the pod management services. Multiple pods can be deployed on supported infrastructure to increase scale and still managed as one environment.

You can find more details on Pods in the product documentation for Horizon or Horizon Cloud on Microsoft Azure pods, respectively. Furthermore, see the respective sections of the Horizon Architecture and Horizon Cloud on Microsoft Azure - first-gen chapters.

Horizon Cloud Connector

The Horizon Cloud Connector is a virtual machine that certifies your entitlement to the Horizon Cloud Service and enables you to leverage various cloud services delivered via the control plane for those Horizon pods. For more information, see High-Level Workflow When You are Onboarding an Existing Manually Deployed Horizon Pod as Your First Pod to Your Horizon Cloud Tenant Environment.

All Horizon Cloud on Microsoft Azure pods are automatically connected to Horizon Control Plane when deployed and use Horizon Cloud Service components to operate. The Horizon Cloud Connector components are run in the Horizon Cloud Pod Manager as a managed component of the pod manager.

For Horizon 8 pods to connect to the Horizon Control Plane, you must implement the VMware Horizon Cloud Connector appliance in each pod.  The Horizon Cloud Connector appliance(s) acts as a proxy for command, control, and information exchange between the Horizon pod components and the Horizon Cloud 

The Horizon Cloud Connector is delivered as an OVA Linux (Photon) appliance.  Services running on the Horizon Cloud Connector are run in Kubernetes containers for portability.  For additional services and capabilities, you may need to expand the Horizon Cloud Connector footprint by deploying additional “worker nodes” of the Horizon Cloud Connector. 

Figure 1: Horizon Cloud Connector Logical Overview

The Horizon Cloud Connector and its worker nodes create a Kubernetes Cluster that host service or application containers in the pod. The Horizon Cloud Connector cluster communicates with various Horizon & vSphere infrastructure components based on the needs of the cloud-based services.  All communications external to the Horizon Cloud Connector leverages the initial Horizon Cloud Connector as a proxy. 

You must run a Horizon Cloud Connector for each Horizon pod that you plan on using Horizon subscription licenses with. Details on the service and the Service Description can be found on the VMware EULA site

For an overview of the steps required to implement a Horizon Cloud Connector, see Horizon Cloud Connector in the Horizon Architecture chapter.

Managed and Monitored States for Pods using Horizon Cloud Connector

There are currently two possible states available that provide different functionality from the Horizon Cloud service. The Horizon Cloud Administration Console Capacity page displays the current state of Horizon Pods that are connected to your Horizon Cloud tenant under the State column.

Figure 2: Managed and Monitored pods on the Horizon Cloud Administration Console Capacity page.

The Dashboard page displays all pods in the Monitored state and provides an overall view of the pod’s health. The Capacity page also displays some details about monitored pods. Furthermore, the help desk service can be fully used with any monitored pod. For more details, see Health Visibility and Insights into your Cloud-Connected Pods Provided by the Cloud Monitoring Service in Horizon Cloud.

Pods that are in the Managed state have more functionality available to them. For example, you can create multi-site assignments with the Horizon Cloud Administration Console. For more information on using multi-site assignments with managed pods, see Managing Multi-Cloud Assignments in Your Horizon Cloud Tenant Environment.

Complete details on the functionality differences between monitored and managed pods are outlined in Horizon Pods – Enabling a Cloud Connected Pod for Multi-Cloud Assignments.

Cloud Monitoring Service

The Cloud Monitoring Service (CMS) allows you to monitor capacity, usage, and health within and across your fleet of cloud-connected pods, regardless of the deployment environments in which those individual pods reside. The Cloud Monitoring Service works if the pod is cloud-connected, regardless of the underlying infrastructure components that Horizon is running on.

The Cloud Monitoring Service obtains the capacity, health, and usage-related data from the pod and presents that data to you within the Horizon Cloud Administration Console. That console is your single pane of glass for working with your tenant's fleet of cloud-connected pods. The CMS organizes data into various dashboard views to help you see overall health and navigate to the health, capacity, and usage metrics at various levels. The CMS also provides data for many reporting views within the console's Reports page and within the user cards where you perform help desk operations to support your individual end users.

Components of Cloud Monitoring Service

Most CMS components run as a cloud service, but some components run within Horizon pods to gather required information for troubleshooting functionality within Help Desk.

  • Horizon Cloud Dashboard – The Horizon Cloud Administration Console provides the Dashboard page as a single location to view the overall health of your entire fleet of cloud-connected pods, and access real-time metrics and health information for all of the pods in your Horizon Cloud tenant environment. The data is provided by the Cloud Monitoring Service (CMS).
  • Reports – The Reports page in the Horizon Cloud Administrative Console provides access to reports related to end user’s desktop and application sessions. It also provides reports on the health of the Horizon Pod infrastructure.
  • Horizon Agent – The Horizon Agent collects metrics locally from the user’s virtual machine and reports those metrics back to the Horizon Control Plane.
  • CMS Agent – Formerly known as the vRealize Operation Desktop Agent Installed as a part of the Horizon Agent Installer, the CMS agent and is used to gathers most historic data used for CMS.
  • VMware Horizon Client – With the Horizon Client, users can connect to a resource provided by Horizon and can communicate with Help Desk administrators to troubleshoot if required.

Basic Architecture of Cloud Monitoring Service

Helpdesk leverages the Horizon Cloud Connector to communicate to facilitate command and control and data collection operations in the Horizon pod. 

Timeline

Description automatically generated

Figure 3: Cloud Monitoring Service Architecture

Table 1: Implementation Strategy for Cloud Monitoring Service

Decision

Cloud Monitoring Service was implemented in all pods.

Justification

CMS functionality works on all Horizon pods connected to the Horizon Cloud Control Plane, regardless of the infrastructure platform the pod is running on.

Help Desk

The Help Desk service is a component of the Cloud Monitoring Service. Help Desk allows you to monitor and troubleshoot live user sessions on any Horizon pod. After you have configured the optional role-based access configurations within the Horizon Cloud Administration Console, administrators or help desk staff can log in to the Horizon Cloud Administrative Console and use the Search function to look up users and troubleshoot whatever sessions they are using.

Help Desk provides the support staff with detailed information on each user’s session including metrics such as CPU usage, memory usage, network latency, disk performance, and so on.

Components of Help Desk

Most Help Desk components run as a cloud service, but some components run within Horizon pods to gather required information for troubleshooting functionality within Help Desk.

  • Search – The Horizon Cloud Administration Console’s Search feature enables administrators and Help Desk administrators to search across all Managed Horizon pods for user sessions to troubleshoot.
  • User Card – With a particular user’s user card, help desk administrators can examine a user’s session to troubleshoot desktop problems and other issues.
  • Horizon Agent – The Horizon Agent collects metrics locally from the user’s virtual machine and reports those metrics back to the Horizon Control Plane.
  • CMS Agent – Formerly known as the vRealize Operation Desktop Agent Installed as a part of the Horizon Agent Installer, the CMS agent gathers most live data used for Help Desk user cards.
  • VMware Horizon Client – With the Horizon Client, users can connect to a resource provided by Horizon and can communicate with Help Desk administrators to troubleshoot if required.
  • Workspace ONE Assist - With Workspace ONE Assist for Horizon, support staff can quickly launch support sessions and remotely view and control virtual desktops directly from the Horizon Universal console.

For more details on Help Desk, see the product documentation.

Basic Architecture of Helpdesk + Workspace ONE Assist

Helpdesk and Workspace ONE Assist leverages the Horizon Cloud Connector to communicate to facilitate command and control and data collection operations in the Horizon pod. 

Figure 4: Helpdesk + Workspace ONE Assist Architecture

Table 2: Implementation Strategy for Help Desk

Decision

Help Desk was implemented in all pods.

Justification

Help Desk functionality works for all Horizon pods connected to the Horizon Cloud Control Plane, regardless of the infrastructure platform that the pod is running on.

Horizon Image Management Service

Horizon Image Management Service is a cloud-based service that simplifies and automates the management of system images used by desktop assignments, such as desktop pools and farms, across your cloud-connected Horizon pods.

The Horizon Image Management Service simplifies and streamlines the process of managing images through a number or features and benefits.

  • A centralized catalog for images managed across all cloud-connected Horizon pods.
  • Automated replication of images across cloud-connected Horizon pods.
  • Automated version control and tracking of images.
  • Automate updates to desktop assignments with customized images by using desktop markers. With desktop markers, you can easily update desktop pools and farms with newer golden images or roll back to older versions of images as necessary.

The Image Management Service uses different infrastructure platform-specific components to handle some functionality, such as replicating images from one site to another, or from a Horizon or Horizon Cloud on Microsoft Azure pod location to another.

Components of Image Management for Horizon 7 and Horizon 8 Pods

Although the Image Management Service is primarily a cloud-based service, some components are required by the service to operate on different infrastructure platforms.

The Image Management Service components include:

  • Image Management Service – A collection of cloud-based services that perform functions to manage images. This includes several services:
    • Central Image Catalog – A service that stores metadata and location details about Horizon images that are being managed by the Image Management Service.
    • Image Replication and Publication Engine – Cloud-based orchestration component that keeps track of image management activities.
    • Historic record of activity – Image change management engine.
    • Pool Update Orchestration Module – Components that enable the automated updating of Horizon pools using Markers.
  • Horizon Cloud Connector – An Image Locality service resides on the Horizon Cloud Connector Server and works with the relevant Horizon pod to orchestrate image management functionality on behalf of the Image Management Service.
  • VMware vCenter Server – Management console used for managing vSphere infrastructure.
  • vCenter Content Library – Service running on the VMware vCenter that is used to orchestrate image placement, storage, and copying to other locations.  Image Management Service leverages APIs in vCenter Content Library running on vCenter directly.  There is no need for configuration or administration of vCenter Content Library outside of functionality exposed in the Horizon Universal Console.
  • Infrastructure Components – Depending on the infrastructure platform, this includes various components such as:
    • Infrastructure management tools such as vCenter Server or the Microsoft Azure Portal
    • Virtual Machines
    • Storage (virtual or physical)
    • Networks (virtual or physical)

Basic Architecture of the Image Management Service for Horizon 7 and Horizon 8 Pods

Horizon Image Management Service uses the components listed previously to orchestrate and manage images on behalf of the service within your Horizon environment.

For Horizon pods in a VMware SDDC, the service stores copies of image versions in datastores managed by the vCenter Server instances within participating pods. These stored copies correspond to the images listed in the tenant image catalog. During publishing, the service replicates image versions using the content library shared between the vCenter Server instances. The service then deletes the temporary objects in the content library that were used for the replication process.

 

Figure 5: Basic Architecture of Horizon Image Management Service

Horizon environments using Image Management Service leverage the vCenter Content Library component to handle image replication across Horizon pods that are managed by Horizon Cloud Service. Monitored pods do not have access to the Image Management Service functionality.

Image Management Service leverages the Horizon Cloud Connector to communicate to facilitate command and control and data collection operations in the Horizon pod.  The Horizon Cloud Connector is the client using APIs on the Horizon Connection Server(s) and vCenter Server(s) as endpoints.

Figure 6: Cloud Monitoring Service Agent

Components of Image Management Service for Horizon Cloud on Microsoft Azure

Although the Image Management Service is primarily a cloud-based service, some critical platform components are required by the service to operate on different infrastructure platforms.

 The Image Management Service components include:

  • Image Management Service – A collection of cloud-based services that perform functions to manage images. This includes several services:
    • Central Image Catalog – A service that stores metadata and location details about Horizon images that are being managed by the Image Management Service.
    • Image Replication and Publication Engine – Cloud-based orchestration component that keeps track of image management activities.
    • Historic record of activity – Image change management engine.
    • Pool Update Orchestration Module – Components that enable the automated updating of Horizon pools using Markers.
  • Microsoft Azure Shared Image GalleryA feature component of Microsoft Azure that is used by Image Management Service to replicate Horizon Cloud on Microsoft Azure images between pods.

Basic Architecture of the Image Management Service for Horizon Cloud on Microsoft Azure Pods

Image Management Service uses the Microsoft Azure Shared Image Gallery to replicate images to Horizon Cloud on Microsoft Azure pods. 

For Horizon Cloud pods in Microsoft Azure, the service stores copies of image versions in the Azure resource groups of participating pods. These stored copies correspond to the images listed in the tenant image catalog. During publishing, the service replicates image versions across different Azure regions and subscriptions using the Microsoft Azure Shared Image Gallery definitions within the pods. The service then discards the temporary objects in the Shared Image Gallery that were used for the replication. There is no setup or configuration that is required to enable Image Management Service for Horizon Cloud on Microsoft Azure.

Figure 7: Image Management Service for Horizon Cloud on Microsoft Azure Pods

Table 3: Implementation Strategy for Image Management Service.

Decision

Image Management Service was implemented in the environment. The Image Management Service was running on the two managed Horizon pods in our private datacenter, and on the two Horizon Cloud on Microsoft Azure pods running in Azure.

Justification

The Image Management Service is certified to run on Horizon pods located in private datacenters and on Horizon Cloud on Microsoft Azure pods.

Horizon Universal Broker

The Horizon Universal Broker is a cloud-based brokering technology that allows you to broker desktops and applications to end users across cloud-connected Horizon pods, regardless of the infrastructure that they run on.

The Universal Broker simplifies hybrid Horizon deployments with a few key features.

  • Universal Broker presents a single FQDN (Fully Qualified Domain Name) to the user for assignments from connected Horizon pods. This provides a single point of access for the users, regardless of which Horizon pod they get their Horizon resources from.
  • Each Horizon pod has its own unique external FQDN to facilitate user connections.
  • The Universal Broker provides connectivity awareness of Horizon pods, which allows for redirection of requests for resources from an unavailable pod to another pod with sufficient resources to handle the request.
  • No internal networking between pods is required.
  • Smart Brokering functionality can deliver desktops from multi-cloud assignments to end users along the shortest network route.

The Universal Broker is aware of geographical locality and pod topology. Using this information, the Universal Broker can make better resource-matching decisions and deliver desktops from multi-cloud assignments to end users along the shortest network route.

Graphical user interface

Description automatically generated

Figure 8: Multiple Entitlements Presented and Accessed Through Universal Broker

Multi-cloud Assignments

Universal Broker and multi-cloud assignments work together to give end users the perception of using a single resource while hiding the complexity around where those resources are sourced from. Universal Broker and multi-cloud assignments do not work in the same way for all platforms and capacity types.

Multi-cloud assignments are used to assign users or groups to resources. Either cloud-connected Horizon 8 or Horizon Cloud on Microsoft Azure resources can be managed with multi-cloud assignments. Universal Broker and multi-cloud assignments work together to give end users the perception of using a single resource, while hiding the complexity where those resources are sourced. Multi-cloud assignment (MCA) can include resources from multiple Horizon pods and sites. Any users or user groups belonging to the multi-cloud assignment are entitled to access virtual desktops and RDS published apps on multiple Horizon pods that are part of the assignment.

By using the Horizon Universal Broker with multi-cloud assignments, you can easily scale beyond the size of a single Horizon Pod by building out multiple Horizon Pod environments and presenting them through the Universal Broker. Universal Broker can be used to scale up a deployment, to build hybrid cloud, and to provide redundancy for business continuity and disaster recovery.

Components of Universal Broker

Although the Universal Broker is primarily a cloud-based service, there are a number of key components that are required to make it work:

  • Horizon Client – Users connect and authenticate to the Universal Broker with the Horizon Client.
  • VMware Unified Access Gateway – A Unified Access Gateway must be deployed and configured in each Horizon pod using the Universal Broker. For details on how to configure the Unified Access Gateway for use with the Universal Broker, see Horizon Pods – Configure Unified Access Gateway for Use with Universal Broker.
  • Horizon Cloud Connector (Horizon on vSphere pods only) – A Universal Broker Client resides on the Horizon Cloud Connector and proxies’ communication to / from the connection server.
  • Horizon Connection Server with Universal Broker Plug-in – The Universal Broker plug-in is an optional component that must be installed on each connection server in a Horizon pod using the Universal Broker. For details see Horizon Pods – Install the Universal Broker Plugin on the Connection Server.
  • Horizon Cloud on Microsoft Azure with the Universal Broker Plug-in (Horizon Cloud on Microsoft Azure Pods only) – The Universal Broker plug-in is already present and configured on each Horizon Cloud on Microsoft Azure pod.

Basic Architecture of Universal Broker

The Universal Broker is architected slightly differently on Horizon pods or on Horizon Cloud on Microsoft Azure pods.  Details about the system architecture of Universal Broker and their differences for each pod type can be found in System Architecture and Components of Universal Broker.

Sites in Universal Broker

A user’s distance to the resources that they are requesting can influence a brokering decision by Universal Broker. For Universal Broker to be aware of geographic differences between a user’s location and the location of the resources that they have available to server the request, you must associate each of your Horizon pods with a physical location.

Sites can serve as a useful part of a disaster recovery solution. For example, you can add pods in different data centers to different sites and entitle users and groups to an assignment that spans those sites. If a data center in one site becomes unavailable, Universal Broker can use desktops from an available site to fulfill user requests.

Figure 3: Universal Broker Sites on the Horizon Cloud Administration Console Capacity page

For location-based brokering decisions, by default, Universal Broker gives preference to:

  1. A user’s home site.
  2. The site physically closest to the user.
  3. Other available sites which have the resource requested by the user.

Pods that are added to the Horizon Cloud Service are automatically added to a default site called Default Site. You can configure new sites and move pods from the default site to other sites. For more details, see Configuring Sites and associating users with Default Sites.

Table 4: Implementation Strategy for Universal Broker

Decision

The Universal Broker was implemented for all Horizon pods in our private datacenter and for all Horizon Cloud on Microsoft Azure pods.

Multi-cloud assignments were used for all Horizon Cloud on Microsoft Azure VDI-based assignments. Multi-cloud assignments were used for VDI-based assignments for Horizon pods based on vSphere infrastructure. Single-pod assignments were used for farm-based workloads.

Different assignments were used for Horizon environments based on vSphere and for Horizon Cloud on Azure.

Justification

Universal Broker can be used on all pods in our Reference Architecture implementation.

Universal Broker does not currently allow for a single assignment that uses different infrastructure platforms. For example, you cannot have an assignment that draws resources from both vSphere and Microsoft Azure based resources. You can use Universal Broker for assignments that use the same infrastructure platform (vSphere with vSphere or Microsoft Azure with Microsoft Azure) in disparate clouds. However, end-users will be presented with all of their entitled assignments regardless of the underlying infrastructure platform.

See the Horizon Service release notes for the latest updates to the restrictions expressed in this table.

Summary and Additional Resources

Now that you have come to the end of this design chapter on First-Gen Horizon Control Plane, you can return to the landing page and use the tabs, search, or scroll to select your next chapter in one of the following sections:

  • Overview chapters provide understanding of business drivers, use cases, and service definitions.
  • Architecture chapters give design guidance on the products you are interested in including in your platform, including Workspace ONE UEM, Workspace ONE Access, Workspace ONE Assist, Workspace ONE Intelligence, Horizon Cloud Service, Horizon, App Volumes, Dynamic Environment Manager, and Unified Access Gateway.
  • Integration chapters cover the integration of products, components, and services you need to create the platform capable of delivering the services that you want to deliver to your users.
  • Configuration chapters provide reference for specific tasks as you build your platform, such as installation, deployment, and configuration processes for Workspace ONE, Horizon Cloud Service, Horizon, App Volumes, Dynamic Environment Management, and more.

Additional Resources

For more information about First-Gen VMware Horizon Control Plane, you can explore the following resources:

Changelog

The following updates were made to this guide:

Date

Description of Changes

2023-07-26

  • Added this Summary and Additional Resources section to list changelog, authors, and contributors within each design chapter.

2022-01-24

  • Updated with more details on Horizon Cloud Connector 2.x networking and architecture.

2021-09-30

  • Updated document links in the Introduction.
  • Added Workspace ONE Assist to Components of Help Desk.
  • Updated Horizon Image Management Service.
  • Updated Table 4 Universal Broker details in Sites in Universal Broker.

2021-05-21

  • Added details relative to feature enhancements for Universal Broker.

Author and Contributors

This chapter was written by:

  • Rick Terlep, Staff Technical Marketing Architect in End-User-Computing Technical Marketing, VMware.
  • Graeme Gordon, Senior Staff End-User-Computing (EUC) Architect in End-User-Computing Technical Marketing, VMware.

Feedback

Your feedback is valuable.

To comment on this paper, contact VMware End-User-Computing Technical Marketing at euc_tech_content_feedback@vmware.com.



Associated Content

home-carousel-icon From the action bar MORE button.

Filter Tags

Horizon Horizon Cloud Service Document Reference Architecture Advanced Design Windows Delivery