Este artículo es una breve introducción a Universal Broker, uno de los servicios del Plano de control de Horizon. Universal Broker es un servicio basado en la nube que permite el brokering de recursos que abarcan varias implementaciones de pods, independientemente de la infraestructura en la que se ejecutan. El servicio también toma decisiones de brokering inteligente en función de los sitios geográficos de los usuarios y los pods.

Descripción general de Universal Broker

Universal Broker, la tecnología de brokering basada en la nube más reciente de VMware, está disponible para su uso cuando el arrendatario tiene uno o varios de los siguientes elementos:

  • Pods de Horizon: pods basados en la tecnología de Horizon Connection Server
  • Pods de Horizon Cloud on Microsoft Azure, y todos ellos ejecutan el manifiesto del pod 2298.0 o una versión posterior.

Para obtener información detallada sobre cómo funcionan juntos los componentes del sistema de la solución de Universal Broker para administrar solicitudes de conexión del usuario a las asignaciones, consulte Arquitectura del sistema y componentes de Universal Broker.


Diagrama de alto nivel de arquitectura del sistema Universal Broker

Funciones principales

El Universal Broker ofrece las siguientes funciones clave:

  • FQDN de conexión única para todos los recursos remotos

    Los usuarios finales pueden acceder a las asignaciones de varias nubes de su entorno conectándose a un nombre de dominio completo (FQDN), que se define en los ajustes de configuración de Universal Broker. A través de una única FQDN de Universal Broker, los usuarios pueden acceder a las asignaciones desde cualquier pod participante de cualquier sitio de su entorno. No se requiere ninguna red interna entre los pods.


    Diagrama de conexión de FQDN única para Universal Broker
  • Conectividad de pods global y detección de un rendimiento óptimo

    Universal Broker mantiene la conectividad directa con cada pod que participa en las asignaciones de varias nubes y sigue detectando el estado de disponibilidad de cada pod. Como resultado, Universal Broker puede administrar las solicitudes de conexión de los usuarios finales y enrutarlas directamente a los recursos virtuales desde los pods. No se precisa recurrir al equilibrio de carga del servidor global (Global Server Load Balancing, GSLB) ni a ninguna comunicación de red entre pods que pueda causar problemas de reducción de rendimiento y latencia.

  • Gestión de agente inteligente

    Universal Broker pueden realizar brokering de recursos de las asignaciones a los usuarios finales en la ruta de red más corta, según el reconocimiento de los sitios geográficos y la topología del pod.

Brokering, grupos de escritorios de usuario final y aplicaciones remotas

Las asignaciones son entidades conceptuales de Horizon Universal Console. Con la consola, las asignaciones son la forma en la que se definen los grupos de aplicaciones remotas y escritorios virtuales de usuario final y se autorizan a los usuarios finales. Por ejemplo, en la consola, se pueden crear asignaciones de escritorios VDI o asignaciones de recursos RDSH y, a continuación, autorizar dichas asignaciones a los usuarios finales.

Universal Broker administra la solicitud de conexión de un usuario cliente a una asignación autorizada y negocia la sesión de conexión con un recurso adecuado que cumpla esa solicitud. Universal Broker detecta la localidad geográfica y la topología del pod. Mediante esta información, Universal Broker busca los mejores recursos para satisfacer las solicitudes de conexión de los usuarios en función de la configuración del sitio y la disponibilidad de recursos.

Consulte las siguientes secciones para obtener la lista de tipos de asignación disponibles, por tipo de pod.

Asignaciones de usuario final con recursos de pods de Horizon Cloud implementados en Microsoft Azure

Una vez completada la configuración de Universal Broker para los pods de Horizon Cloud del grupo de pods, estos tipos de asignación son posibles:

Asignaciones de usuario final con recursos de pods de Horizon conectados a la nube

Una vez completada la configuración de Universal Broker para los pods de Horizon del grupo de pods, estos tipos de asignación son posibles:

Notas

Al igual que sucede con cualquier aplicación de software, la versión actual tiene algunas limitaciones conocidas y consideraciones sobre las características. Para obtener más información, consulte Universal Broker: consideraciones sobre funciones y limitaciones conocidas.

Arquitectura del sistema y componentes de Universal Broker

Este artículo proporciona una ilustración detallada de los componentes del sistema de Universal Broker que se ejecutan dentro de los pods participantes y en el plano de control de Horizon Cloud. Universal Broker representa la tecnología de brokering basada en la nube más reciente de VMware y es el agente de conexión preferido para asignaciones de usuarios finales en nuevas implementaciones.

Para obtener una descripción general de las funciones clave de Universal Broker, consulte Introducción a VMware Horizon Service Universal Broker.

La arquitectura del sistema de la solución Universal Broker varía ligeramente en función de si los recursos de brokering residen en pods de Horizon (basados en la tecnología de Horizon Connection Server) o en pods de Horizon Cloud en Microsoft Azure.

Arquitectura del sistema Universal Broker para pods de Horizon

Los siguientes componentes incluyen la solución Universal Broker para el brokering basado en la nube de las asignaciones de varias nubes de pods de Horizon (basados en la tecnología de Horizon Connection Server).

  • El servicio Universal Broker es un servicio de nube de varios arrendatarios que se ejecuta dentro de la nube de Universal Broker, que está conectada a Horizon Cloud. Cada cliente se conecta al servicio Universal Broker mediante un FQDN único y dedicado que está configurado como se describe en Configurar los parámetros de Universal Broker.
  • El cliente de Universal Broker se ejecuta en cada una de las instancias de Horizon Cloud Connector correspondientes a los distintos pods de Horizon conectados a la nube. A partir de la versión 1.5 de ese conector, el cliente de Universal Broker forma parte de ese conector y se instala automáticamente cuando se empareja el Horizon Cloud Connector con el pod.
  • El complemento de Universal Broker se ejecuta en la instancia de Horizon Connection Server de cada pod conectado a la nube que participa en las asignaciones de varias nubes. Debe descargar e instalar el complemento en cada instancia de Connection Server dentro de un pod participante, como se describe en Pods de Horizon: instalar el complemento de Universal Broker en Connection Server.

El siguiente diagrama muestra cómo funciona Universal Broker con los componentes del entorno de pod de Horizon para administrar las solicitudes de conexión de los usuarios finales externos a los recursos remotos en una asignación.

Nota: El escenario representado implica el Horizon Client ubicado en una red externa, fuera de la red corporativa, con una instancia de Unified Access Gateway externa configurada en el pod.

Arquitectura del sistema Universal Broker para pods de Horizon

  1. Desde Horizon Client, el usuario final solicita un escritorio virtual conectándose al servicio de Universal Broker a través de la FQDN de brokering. El servicio utiliza el protocolo XML-API para autenticar el usuario de Horizon Client y administrar la sesión de conexión.
  2. Después de determinar que el pod 1 del sitio 1 es el mejor origen disponible para el escritorio, el servicio de Universal Broker envía un mensaje al cliente de Universal Broker, que se ejecuta en Horizon Cloud Connector emparejado con el pod 1.
  3. El cliente de Universal Broker reenvía el mensaje al complemento de Universal Broker, que se ejecuta en cada una de las instancias de Connection Server en el pod 1.
  4. El complemento de Universal Broker identifica el mejor escritorio disponible que cumple la solicitud del usuario final.
  5. El servicio Universal Broker devuelve una respuesta a Horizon Client que incluye el FQDN exclusivo del pod 1 (normalmente, el FQDN del equilibrador de carga del pod 1). Horizon Client establece una conexión con el equilibrador de carga para solicitar la sesión del protocolo con el escritorio.
  6. Después de pasar por el equilibrador de carga local, la solicitud pasa a la instancia de Unified Access Gateway para el pod 1. Unified Access Gateway valida que la solicitud es de confianza y prepara el servidor de túnel, la puerta de enlace segura PCoIP y la puerta de enlace segura de Blast.
  7. El usuario de Horizon Client recibe el escritorio especificado y establece una sesión basada en el protocolo secundario configurado (Blast Extreme, PCoIP o RDP).

Para obtener más información sobre los puertos utilizados para las comunicaciones de Universal Broker, consulte Pods de Horizon: requisitos de DNS, puertos y protocolos para Universal Broker.

Arquitectura del sistema de Universal Broker para pods de Horizon Clouden Microsoft Azure

Los siguientes componentes constituyen la solución Universal Broker para brokering basado en la nube de las asignaciones de VDI y RDSH de los pods de Horizon Cloud en Microsoft Azure.

  • El servicio Universal Broker es un servicio de nube de varios arrendatarios que se ejecuta dentro de la nube de Universal Broker, que está conectada a Horizon Cloud. Cada cliente se conecta al servicio Universal Broker mediante un FQDN único y dedicado que está configurado como se describe en Configurar los parámetros de Universal Broker.
  • Universal Broker Client se ejecuta dentro de cada pod de Horizon Cloud participante en Microsoft Azure.
Nota: El escenario representado implica el Horizon Client ubicado en una red externa, fuera de la red corporativa, con una instancia de Unified Access Gateway externa configurada en el pod.

Arquitectura del sistema de Universal Broker para pods de Horizon Cloud en Microsoft Azure

  1. Desde Horizon Client, el usuario final solicita un recurso virtual conectándose al servicio de Universal Broker a través del FQDN de brokering. El servicio utiliza el protocolo XML-API para autenticar el usuario de Horizon Client y administrar la sesión de conexión.
  2. Después de determinar que el Pod 1 del Sitio 1 es el mejor recurso disponible para la solicitud del usuario, el servicio de Universal Broker envía un mensaje a la instancia de Universal Broker Client que se ejecuta dentro del Pod 1.
  3. Universal Broker Client reenvía el mensaje al administrador de pods activo en el Pod 1.
  4. El administrador de pods activo identifica el mejor recurso disponible que cumple la solicitud del usuario final.
  5. El servicio de Universal Broker devuelve una respuesta a Horizon Client que incluye el FQDN exclusivo del Pod 1 (normalmente, el FQDN del equilibrador de carga de Microsoft Azure para el Pod 1). Horizon Client establece una conexión con el equilibrador de carga para solicitar una sesión del protocolo en el recurso.
  6. Después de pasar por el equilibrador de carga de Microsoft Azure, la solicitud pasa a la instancia de Unified Access Gateway para el Pod 1. Unified Access Gateway valida que la solicitud es de confianza y prepara el servidor de túnel, la puerta de enlace segura PCoIP y la puerta de enlace segura de Blast.
  7. El usuario de Horizon Client recibe el recurso especificado y establece una sesión basada en el protocolo secundario configurado (Blast Extreme, PCoIP o RDP).

Si desea obtener más información sobre los puertos utilizados para las comunicaciones de Universal Broker, consulte la sección "Puertos y protocolos requeridos por Universal Broker" en Requisitos de puertos y protocolos para un pod de Horizon Cloud en el manifiesto publicado en septiembre de 2019 o posteriormente.

Universal Broker: consideraciones sobre funciones y limitaciones conocidas

En esta página de documentación se proporcionan algunas de las consideraciones sobre funciones relacionadas con Universal Broker y una lista de las funciones de Horizon que tienen compatibilidad limitada o no tienen ningún tipo de compatibilidad.

Consideraciones sobre funciones

  • En un grupo de pods que contiene pods de Horizon y pods de Horizon Cloud, cada asignación de usuario final que cree debe constar de escritorios VDI de un solo tipo de pod. Por ejemplo, puede crear una asignación compuesta por escritorios que abarcan varios pods de Horizon o una asignación compuesta por escritorios que abarcan varios pods de Horizon Cloud. Sin embargo, no se puede crear una asignación compuesta por escritorios que abarque una combinación de pods de Horizon y pods de Horizon Cloud.
  • Se aplican consideraciones adicionales si ha pasado el arrendatario de una configuración de agente de pod único a Universal Broker. Consulte Novedades en el entorno de arrendatario después de la transición a Universal Broker.

Cantidad máxima de pods por asignación de varias nubes de VDI

La cantidad máxima admitida de pods en una asignación de varias nubes de VDI es cinco (5). Este límite se aplica tanto a los pods de tipo Horizon Connection Server como a los de tipo Horizon Cloud on Microsoft Azure. Usar más de cinco aumenta la carga simultánea en Universal Broker. Aumentar esa carga simultánea puede provocar que se produzca un error cuando los usuarios finales hagan clic en el mosaico que se muestra en el cliente de la asignación y el servicio intente iniciar la sesión del usuario en el escritorio virtual.

Recursos virtuales

Para el brokering de los recursos virtuales, esta versión de Universal Broker solo admite sistemas operativos Windows. No se admiten los escritorios basados en Linux.

Esta versión no es compatible con los accesos directos creados por el administrador a las aplicaciones y los escritorios.

Nota: Un usuario específico puede recibir como máximo un escritorio asignado de una asignación dedicada con brokering de Universal Broker, incluso si la asignación incluye escritorios de varios pods.

Horizon HTML Access y Horizon Client para Chrome

Los usuarios finales pueden solicitar recursos al servicio del Universal Broker ejecutando Horizon HTML Access en un navegador web compatible u Horizon Client para Chrome 5.4 (o una versión posterior). Si el servicio de Universal Broker redirecciona la solicitud a una instancia de Unified Access Gateway que utiliza un certificado autofirmado, la aplicación cliente indica en un mensaje de error que la entidad de certificación no es válida.

El diseño del producto determina este comportamiento. Para conectar con el recurso solicitado, el usuario puede aceptar el certificado autofirmado siguiendo las indicaciones del mensaje de error del certificado.

Métodos de autenticación

Esta versión de Universal Broker admite la autenticación de usuarios cliente a través del nombre de usuario y la contraseña de Windows, en los formatos UPN y NETBIOS.

También se admite la autenticación en dos fases a través de RADIUS o RSA, según el estado actual del grupo de pods del arrendatario, como se muestra en la siguiente lista.

Revise también la siguiente sección que describe la experiencia del usuario final cuando se utiliza Universal Broker en sus clientes y se configura la autenticación en dos fases. El comportamiento actual es diferente del que se produce cuando se utilizan los FQDN de puerta de enlace de un pod directamente.

Solo pods de Horizon
Se admiten las dos autenticaciones, RADIUS y RSA SecurID.
Solo implementaciones de Horizon Cloud on Microsoft Azure
Si todos los pods son del manifiesto 3139.x o una versión posterior y las opciones RSA SecurID y RADIUS están visibles para su selección cuando se ejecuta el asistente Editar pod en los pods, se admite indistintamente la autenticación RSA SecurID y RADIUS. En caso contrario, solo se admite el tipo RADIUS.
Combinación de pods de Horizon e implementaciones de Horizon Cloud on Microsoft Azure
En un grupo combinado, los tipos de autenticación compatibles dependen de si las implementaciones de Horizon Cloud on Microsoft Azure cumplen las condiciones para tener la opción RSA SecurID configurada en ellas:
  • Si las implementaciones de Horizon Cloud on Microsoft Azure no cumplen estas condiciones, solo se admite la autenticación RADIUS.
  • Si las implementaciones de Horizon Cloud on Microsoft Azure cumplen estas condiciones; se admiten las dos autenticaciones, RADIUS y RSA SecurID.

Las condiciones que se deben cumplir son que los pods ejecuten la versión de manifiesto 3139.x o una versión posterior y que cuando se abra el asistente Editar pod en los pods, se pueda seleccionar tanto la opción RSA SecurID como RADIUS.

Cuando se configura la autenticación en dos fases

Cuando se usa la autenticación en dos fases, los usuarios finales experimentarán un flujo de autenticación al utilizar el FQDN de Universal Broker que es ligeramente diferente del flujo que experimentan cuando se utiliza el FQDN de puerta de enlace de un pod directamente.

  • En el flujo de autenticación de Universal Broker, se solicitará a los usuarios finales que introduzcan sus credenciales de Windows Active Directory (AD) dos veces: primero, cuando se conecten por primera vez al FQDN de Universal Broker y, luego, cuando completen correctamente la autenticación de dos fases con los sistemas RADIUS o RSA SecurID configurados.
  • Cuando se utilice el flujo de autenticación de puerta de enlace de un pod, se solicitará a los usuarios finales que introduzcan sus credenciales de Windows Active Directory (AD) solo cuando se conecten por primera vez al FQDN de puerta de enlace del pod.
Nota: Para eliminar la visualización de dos mensajes de AD al utilizar Universal Broker, considere la integración con VMware Workspace ONE Access y configure la autenticación en dos fases en VMware Workspace ONE Access.

Métodos de acceso y autenticación de usuario no admitidos actualmente

En este momento, no se admiten los siguientes métodos de acceso y autenticación de usuario.

  • Tarjeta inteligente
  • Certificado
  • Autenticación SAML (fuera de la integración con VMware Workspace ONE)
  • Iniciar sesión como el usuario actual
  • Acceso anónimo

Cuando uno de los elementos no compatibles cumple con los requisitos para ser admitido, su entrada se eliminará de la lista anterior y el anuncio de compatibilidad se hará en la página titulada Para clientes actuales con pods existentes conectados a la nube: acerca de las versiones de Horizon Cloud Service. En esa página, la instrucción se mostrará en la sección que corresponda a la versión que ahora es compatible.

Funciones de escritorio remoto

No se admiten las funciones siguientes en esta versión de Universal Broker:

  • Redireccionamiento de contenido URL
  • Colaboración de sesiones

Otras funciones

Las siguientes funciones tampoco se admiten en esta versión de Universal Broker:

  • Modo de quiosco
  • Perfil de tiempo (para solucionar problemas de las sesiones de usuario)
  • Comprobaciones de conformidad de endpoints basados en OPSWAT