First-Gen Horizon Control Plane Architecture

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

• This chapter provides information about the Omnissa First-Gen Horizon Control Plane and the services it provides.
• For information on next-gen, see the chapter on Horizon Cloud Service - next-gen Architecture.

Introduction

The Omnissa First-gen 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:

• Cloud Monitoring Service – Monitor user sessions and virtual desktops. For more information, see Introducing the Cloud Monitoring Service's Unified Visibility and Insights, Health Monitoring, and Help Desk Features Provided in Horizon Cloud.
• Help Desk – Find detailed real-time information about a user’s sessions and functionality to troubleshoot issues with their experience. For more information, see Help Desk Features in Your Horizon Cloud Environment.
• Horizon Image Management Service – Manage golden images for virtual desktops and session or application hosts across pods with automatic replication and simplified pool or assignment updates. For more information, see First-Gen Horizon Cloud - Image Management Service (IMS) Guide.
• Horizon Service Universal Broker – Cloud-brokering technology built specifically for intelligently brokering users to resources in multi-cloud environments from a single URL For more information, see Introduction to Horizon Universal Broker.
• Application Management – App Volumes can be implemented in all Horizon pods on all infrastructure platforms. More detail can be found in the App Volumes Architecture and the Horizon Cloud on Microsoft Azure - first-gen chapters.

The capabilities of, or access to, each feature may be different based on the implementation of Omnissa Horizon (Horizon 8 or Horizon Cloud Service on Microsoft Azure) that you are using and the platform on which you are running Horizon.

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.

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 First-Gen Tenants - Horizon Cloud Deployments and Onboarding 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 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 8 or Horizon Cloud Service - first-gen pods, respectively. Furthermore, see the respective sections of the Horizon 8 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 First-Gen Tenants - Onboarding a Horizon Pod to Use First-Gen Horizon Control Plane Services with That Pod.

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

For an overview of the steps required to implement a Horizon Cloud Connector, see Horizon Cloud Connector in the Horizon 8 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 First-Gen Tenants - Horizon Cloud Dashboard - Health Visibility and Insights into Your Pod Fleet and Tenant Environment

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

Figure 3: Cloud Monitoring Service Architecture

Table 1: Implementation Strategy for Cloud Monitoring Service

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

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 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 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 Gallery – A 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.

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.

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.
• 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 Requirements for 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 Working with Sites in a Universal Broker Environment.

Table 4: Implementation Strategy for Universal Broker

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 reference architecture landing page and use the tabs, search, or scroll to select further 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 Omnissa products you are interested in including in your deployment, including Workspace ONE UEM, Access, Intelligence, Workspace ONE Assist, Horizon Cloud Service, Horizon 8, App Volumes, Dynamic Environment Manager, and Unified Access Gateway.
• Integration chapters cover the integration of products, components, and services you need to create the environment capable of delivering the services that you want to deliver to your users.
• Configuration chapters provide reference for specific tasks as you deploy your environment, such as installation, deployment, and configuration processes for Omnissa Workspace ONE, Horizon Cloud Service, Horizon 8, App Volumes, Dynamic Environment Management, and more.

Additional Resources

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

•        Horizon Cloud Service - first-gen documentation

• Knowledge Base

Changelog

The following updates were made to this guide:

Author and Contributors

This chapter was written by:

• Rick Terlep, Staff Architect, Omnissa.
• Graeme Gordon, Senior Staff Architect, Omnissa.

Feedback

Your feedback is valuable. To comment on this paper, either use the feedback button or contact us at tech_content_feedback@omnissa.com.