This article provides a detailed illustration of the system components of Universal Broker that run within participating pods and in the Horizon Cloud control plane. Universal Broker represents the latest cloud-based brokering technology from VMware and is the recommended connection broker for end-user assignments in new deployments.

For an overview of the key features of Universal Broker, see Introduction to VMware Horizon Service Universal Broker.

The system architecture of the Universal Broker solution differs slightly depending on whether the brokered resources reside in Horizon pods (based on Horizon Connection Server technology) or in Horizon Cloud pods in Microsoft Azure.

System Architecture of Universal Broker for Horizon Pods

The following components comprise the Universal Broker solution for cloud-based brokering of multi-cloud assignments from Horizon pods (based on Horizon Connection Server technology).

  • The Universal Broker service is a multi-tenant cloud service that runs within the Universal Broker cloud, which is connected to Horizon Cloud. Each customer connects to the Universal Broker service using a unique, dedicated FQDN that is configured as described in Configure Universal Broker Settings.
  • The Universal Broker client runs within the Horizon Cloud Connector for each of your cloud-connected Horizon pods. Starting with version 1.5 of that connector, the Universal Broker client is part of that connector and is automatically installed when you pair the Horizon Cloud Connector with your pod.
  • The Universal Broker plugin runs within the Horizon Connection Server for every cloud-connected pod that participates in multi-cloud assignments. You must download and install the plugin on each Connection Server instance within a participating pod, as described in Horizon Pods - Install the Universal Broker Plugin on the Connection Server.

The following diagram illustrates how Universal Broker works with the components in your Horizon pod environment to manage connection requests from your external end users to remote resources in an assignment.

Note: The depicted scenario involves the Horizon Client located on an external network, outside of your corporate network, with an external Unified Access Gateway configured on the pod.

System architecture of Universal Broker for Horizon pods

  1. From Horizon Client, the end user requests a virtual desktop by connecting to the Universal Broker service through the brokering FQDN. The service uses the XML-API protocol to authenticate the Horizon Client user and manage the connection session.
  2. After determining that Pod 1 in Site 1 is the best available source for the desktop, the Universal Broker service sends a message to the Universal Broker client, which runs on the Horizon Cloud Connector paired with Pod 1.
  3. The Universal Broker client forwards the message to the Universal Broker plugin, which runs on each of the Connection Server instances within Pod 1.
  4. The Universal Broker plugin identifies the best available desktop that fulfills the end user's request.
  5. The Universal Broker service returns a response to Horizon Client which includes the unique FQDN of Pod 1 (typically the FQDN of the Pod 1 load balancer). Horizon Client establishes a connection with the load balancer to request a protocol session with the desktop.
  6. After passing through the local load balancer, the request goes to the Unified Access Gateway for Pod 1. The Unified Access Gateway validates that the request is trusted and prepares the Blast Secure Gateway, PCoIP Secure Gateway, and tunnel server.
  7. The Horizon Client user receives the specified desktop and establishes a session based on the configured secondary protocol (Blast Extreme, PCoIP, or RDP).

For more information about the ports used for Universal Broker communications, see Horizon Pods - DNS, Ports, and Protocol Requirements for Universal Broker.

System Architecture of Universal Broker for Horizon Cloud Pods in Microsoft Azure

The following components comprise the Universal Broker solution for cloud-based brokering of VDI and RDSH assignments from Horizon Cloud pods in Microsoft Azure.

  • The Universal Broker service is a multi-tenant cloud service that runs within the Universal Broker cloud, which is connected to Horizon Cloud. Each customer connects to the Universal Broker service using a unique, dedicated FQDN that is configured as described in Configure Universal Broker Settings.
  • The Universal Broker client runs within each participating Horizon Cloud pod in Microsoft Azure.
Note: The depicted scenario involves the Horizon Client located on an external network, outside of your corporate network, with an external Unified Access Gateway configured on the pod.

System architecture of Universal Broker for Horizon Cloud pods in Microsoft Azure

  1. From Horizon Client, the end user requests a virtual resource by connecting to the Universal Broker service through the brokering FQDN. The service uses the XML-API protocol to authenticate the Horizon Client user and manage the connection session.
  2. After determining that Pod 1 in Site 1 has the best available resource for the user's request, the Universal Broker service sends a message to the Universal Broker client running within Pod 1.
  3. The Universal Broker client forwards the message to the active pod manager within Pod 1.
  4. The active pod manager identifies the best available resource that fulfills the end user's request.
  5. The Universal Broker service returns a response to Horizon Client which includes the unique FQDN of Pod 1 (typically the FQDN of the Microsoft Azure load balancer for Pod 1). Horizon Client establishes a connection with the load balancer to request a protocol session with the resource.
  6. After passing through the Microsoft Azure load balancer, the request goes to the Unified Access Gateway for Pod 1. The Unified Access Gateway validates that the request is trusted and prepares the Blast Secure Gateway, PCoIP Secure Gateway, and tunnel server.
  7. The Horizon Client user receives the specified resource and establishes a session based on the configured secondary protocol (Blast Extreme, PCoIP, or RDP).

For more information about the ports used for Universal Broker communications, see the "Ports and Protocols Required by Universal Broker" section in Ports and Protocols Requirements for a Horizon Cloud Pod at the September 2019 Release's Manifest or Later.