Horizon Control Plane Services 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 architecting VMware Horizon Control Plane Services.

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 the 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 Horizon Universal License 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.

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 chapters.

Horizon Cloud Connector

All Horizon Cloud on Microsoft Azure pods are automatically connected to Horizon Control Plane when deployed and use Horizon Cloud Service components to operate. For Horizon (vSphere-based) pods to connect to the Horizon Control Plane, you must implement the VMware 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.

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 1: 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.

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.
  • 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.

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

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.

Components of Image Management

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.
  • 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)

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

Basic Architecture of the Image Management Service

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

Figure 2: 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.

Table 3: Implementation Strategy for Image Management Service.

Decision

Image Management Service was not used for our environment.

Justification

The Image Management Service is not currently supported for use on the following infrastructure platforms:

  • VMware Cloud on AWS
  • Microsoft Azure – Azure VMware Solutions
  • Google Cloud Engine
  • Oracle Cloud
  • IBM Cloud
  • VMware Cloud Foundation

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 all cloud-connected Horizon pods, regardless of the infrastructure that they run on.

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

  • A single connection FQDN (Fully Qualified Domain Name) for all remote resources. Users can connect to a single FQDN to access any assignment in any Horizon pod.
  • 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.
  • 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.

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 the newest cloud-based brokering technology available from VMware. 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 not implemented for any pods.

Justification

At the time of our building the Reference Architecture implementation, the Universal Broker did not integrate with VMware Workspace ONE Access, which is a critical component in the deployment.

Universal Broker currently cannot broker RDS-based applications and session-based desktops on Horizon on vSphere environments. 

Universal Broker does not allow for multi-pod session based desktop or application assignments on Horizon Cloud on Microsoft Azure environments.

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.

 

What’s Next?

Now that you have come to the end of this chapter, you can return to the landing page and 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 explore the products you are interested in including in your platform, including Workspace ONE UEM, Workspace ONE Access, Workspace ONE Assist, Workspace ONE Intelligence, Horizon, App Volumes Dynamic Environment Manager, and Unified Access Gateway.
  • Integration chapters cover the integration of components and services you need to create the platform capable of delivering what you want.
  • Configuration chapters provide reference for specific tasks as you build your platform, such as installation, deployment, and configuration processes for Horizon, App Volumes, Dynamic Environment Management, and more.

Filter Tags

Horizon Horizon Cloud Service Document Reference Architecture Advanced Design Windows Delivery