This topic summarizes the main differences between Horizon Universal Broker and Cloud Pod Architecture and offers guidelines for choosing between the two brokering methods.

Choosing a Brokering Method

Horizon Universal Broker represents the latest cloud-based brokering technology from VMware and is the preferred brokering method for multi-cloud assignments in new deployments.

If you have already configured a Cloud Pod Architecture environment and want to provide your end users with a feature not supported by Horizon Universal Broker, choose Cloud Pod Architecture as your brokering method. For more information, see Feature Limitations of Horizon Universal Broker.

Horizon Universal Broker Cloud Pod Architecture
Use for new, greenfield deployments Use to configure multi-cloud assignments that include features not supported by Horizon Universal Broker
Single connection FQDN for all users in all sites Multiple connection FQDNs
No interpod network traffic required Dependent on interpod network traffic

About Horizon Universal Broker

Architecture diagram of Horizon Universal Broker system components

Horizon Universal Broker, the latest cloud-based brokering technology from VMware, provides the following key features:

  • Single connection FQDN for all multi-cloud assignments

    End users can access multi-cloud assignments in your environment by connecting to a single FQDN (or URL), which you define in the Horizon Universal Broker configuration settings. Through the single Horizon Universal Broker FQDN, users can access assignments from any participating Horizon 7 pod in any site in your environment. No internal networking between your pods is required.

    Diagram of single FQDN connection for Horizon Universal Broker
  • Global pod connectivity and awareness for optimal performance

    Horizon Universal Broker maintains direct connectivity with every pod participating in multi-cloud assignments and stays aware of the availability status of each pod. As a result, Horizon Universal Broker can manage connection requests and deliver virtual resources to end users directly from these pods. There is no need for global server load balancing (GSLB) or any interpod network communication that can cause reduced performance and latency issues.

  • Smart brokering

    By maintaining an awareness of your geographical sites and pod topology, Horizon Universal Broker can deliver desktops from multi-cloud assignments to end users along the shortest network route.

About Cloud Pod Architecture

Diagram of Cloud Pod Architecture system components

Cloud Pod Architecture uses standard Horizon components to link together multiple Horizon 7 pods in a single large desktop brokering environment, called a pod federation. Key features include:

  • Different connection FQDNs for each pod

    To access a multi-cloud assignment brokered by Cloud Pod Architecture, an end user connects to the Connection Server FQDN (or URL) for one of the participating pods. Since each pod has a distinct Connection Server FQDN, users have multiple points of entry into the Cloud Pod Architecture environment.

    Diagram of multiple connection FQDNs for Cloud Pod Architecture
  • Requires an interpod WAN network

    Cloud Pod Architecture requires that you set up an internal WAN network to handle communication between your pods. This interpod communication enables Cloud Pod Architecture to deliver a desktop from one pod to a user who is connected to another pod. For example, a user can connect to Pod A in San Francisco and receive a desktop from Pod B in New York.

  • Requires GSLB capabilities
  • To use Cloud Pod Architecture, you must deploy and configure a global load balancer. Cloud Pod Architecture requires global server load balancing (GSLB) to manage and direct connection requests to the best available resources in your environment.