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 first-gen de Omnissa, está disponible para su uso cuando el arrendatario tiene una o varias de las siguientes opciones:
- 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 Universal Broker para administrar las solicitudes de conexión de los usuarios a las asignaciones, consulte Arquitectura del sistema y componentes de Universal Broker.
Funciones clave
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 las opciones de configuración de Universal Broker. A través del FQDN único de Universal Broker, los usuarios pueden acceder a las asignaciones desde cualquier pod participante en cualquier sitio del entorno. No se requiere ninguna red interna entre los pods.
-
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 conoce el estado de disponibilidad de cada pod. Como resultado, Universal Broker puede administrar las solicitudes de conexión de los usuarios finales y enrutarlas a los recursos virtuales directamente desde estos pods. No es necesario el equilibrio de carga del servidor global (GSLB) ni ninguna comunicación de red entre pods que pueda provocar problemas de reducción de rendimiento y latencia.
-
Gestión de agente inteligente
Universal Broker puede realizar brokering de recursos de las asignaciones a los usuarios finales a lo largo de 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 en 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, puede 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 reconoce la localidad geográfica y la topología del pod. Con 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 los 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:
- Una asignación de varias nubes que consta de escritorios VDI de uno o varios pods de Horizon Cloud. Para obtener más información, consulte Pods de Horizon Cloud en Microsoft Azure: crear y ver asignaciones de varias nubes de VDI en el entorno de first-gen.
- Una asignación de escritorios de sesión que consta de escritorios basados en sesiones de hosts RDS de Microsoft en un solo pod de Horizon Cloud. Para obtener más información, consulte Pods de Horizon Cloud: proporcionar sesiones de escritorio desde hosts RDS para los usuarios finales mediante la creación de una asignación de escritorios de sesión basada en RDS.
- Una asignación de aplicaciones remotas que consta de aplicaciones proporcionadas desde hosts RDS en pods de Horizon Cloud. Para obtener más información, consulte Aplicaciones remotas: crear una asignación de aplicación remota para aplicaciones remotas aprovisionadas por pods de Horizon Cloud en Microsoft Azure.
- Una asignación de aplicaciones App Volumes compuesta por aplicaciones App Volumes alojadas en escritorios VDI dentro de pods de Horizon Cloud. Para obtener más información, consulte Horizon Cloud: crear una asignación de App Volumes.
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:
- Una asignación de varias nubes que consta de escritorios VDI de uno o varios pods de Horizon. Para obtener información general sobre la configuración de asignaciones de varias nubes en función de los recursos de los pods de Horizon conectados a la nube del arrendatario de Horizon Cloud, consulte Asignaciones de varias nubes y Horizon Cloud Universal Broker de first-gen.
- Una asignación de escritorios de sesión que consta de escritorios basados en sesiones de hosts RDS de Microsoft en un solo pod de Horizon. Para obtener más información, consulte Pods de Horizon: configurar aplicaciones y escritorios RDSH para un entorno de Universal Broker.
- Una asignación de aplicaciones remotas que consta de aplicaciones proporcionadas desde hosts RDS en un solo pod de Horizon. Para obtener más información, consulte Pods de Horizon: configurar aplicaciones y escritorios RDSH para un entorno de Universal Broker.
Notas
Al igual que sucede con casi todo el software, la versión actual tiene algunas consideraciones sobre las características y limitaciones conocidas. 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 es el agente de conexión recomendado para las asignaciones de usuarios finales en implementaciones de Horizon Cloud - first-gen.
Para obtener una descripción general de las funciones clave de Universal Broker, consulte Introducción a Horizon Service Universal Broker.
La arquitectura del sistema de la solución Universal Broker difiere 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 de Universal Broker para pods de Horizon
Los siguientes componentes incluyen la solución Universal Broker para el brokering basado en la nube de 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 ajustes de Universal Broker.
- El cliente de Universal Broker se ejecuta dentro de Horizon Cloud Connector para cada uno de los pods de Horizon conectados a la nube. A partir de la versión 1.5 de ese conector, el cliente Universal Broker forma parte de ese conector y se instala automáticamente cuando se empareja Horizon Cloud Connector con el pod.
- El complemento de Universal Broker se ejecuta dentro de Horizon Connection Server para 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 en el 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 la instancia de Horizon Client ubicada en una red externa, fuera de la red corporativa, con una instancia externa de Unified Access Gateway configurada en el pod.
- Desde Horizon Client, el usuario final solicita un escritorio virtual conectándose al servicio Universal Broker a través del FQDN de brokering. El servicio utiliza el protocolo XML-API para autenticar al usuario de Horizon Client y administrar la sesión de conexión.
- Después de determinar que el pod 1 del sitio 1 es el mejor origen disponible para el escritorio, el servicio Universal Broker envía un mensaje al cliente de Universal Broker, que se ejecuta en Horizon Cloud Connector emparejado con el pod 1.
- 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.
- El complemento de Universal Broker identifica el mejor escritorio disponible que cumple con la solicitud del usuario final.
- El servicio Universal Broker devuelve una respuesta a Horizon Client que incluye el FQDN único 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 una sesión de protocolo con el escritorio.
- Después de pasar por el equilibrador de carga local, la solicitud pasa a Unified Access Gateway para el pod 1. Unified Access Gateway valida que la solicitud es de confianza y prepara la puerta de enlace segura de Blast, la puerta de enlace segura PCoIP y el servidor de túnel.
- 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 Cloud en Microsoft Azure
Los siguientes componentes incluyen la solución Universal Broker para el brokering basado en la nube de asignaciones VDI y RDSH de 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 ajustes de Universal Broker.
- El cliente de Universal Broker se ejecuta dentro de cada pod de Horizon Cloud participante en Microsoft Azure.
Nota: El escenario representado implica la instancia de Horizon Client ubicada en una red externa, fuera de la red corporativa, con una instancia externa de Unified Access Gateway configurada en el pod.
- Desde Horizon Client, el usuario final solicita un recurso virtual conectándose al servicio Universal Broker a través del FQDN de brokering. El servicio utiliza el protocolo XML-API para autenticar al usuario de Horizon Client y administrar la sesión de conexión.
- Después de determinar que el pod 1 del sitio 1 es el mejor recurso disponible para la solicitud del usuario, el servicio Universal Broker envía un mensaje al cliente de Universal Broker que se ejecuta dentro del pod 1.
- El cliente Universal Broker reenvía el mensaje al administrador de pods activo en el pod 1.
- El administrador de pods activo identifica el mejor recurso disponible que cumple la solicitud del usuario final.
- 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 de Microsoft Azure para el Pod 1). Horizon Client establece una conexión con el equilibrador de carga para solicitar una sesión de protocolo con el recurso.
- Después de pasar por el equilibrador de carga de Microsoft Azure, la solicitud pasa a Unified Access Gateway para el pod 1. Unified Access Gateway valida que la solicitud es de confianza y prepara la puerta de enlace segura de Blast, la puerta de enlace segura PCoIP y el servidor de túnel.
- 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).
Para 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.
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 realizado la transición del 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. Un uso por encima 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 la asignación en el cliente y el servicio intente iniciar la sesión del usuario en el escritorio virtual.
Recursos virtuales
Para el brokering de 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 Web Client y Horizon Client para Chrome
Los usuarios finales pueden solicitar recursos al servicio Universal Broker ejecutando Horizon Web Client en un navegador web compatible o ejecutando Horizon Client para Chrome 5.4 o una versión posterior. Si el servicio Universal Broker redirecciona la solicitud a una instancia de Unified Access Gateway que utiliza un certificado autofirmado, la aplicación cliente muestra un mensaje de error que indica que la entidad de certificación no es válida.
El diseño de este comportamiento se basa en dicho diseño. Para conectarse al recurso solicitado, el usuario puede aceptar el certificado autofirmado siguiendo las indicaciones del mensaje de error del certificado.
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 admiten las dos autenticaciones, RSA SecurID y RADIUS. De lo 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 admitidos 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 autenticaciones RADIUS y RSA SecurID. Las condiciones que se deben cumplir son que los pods ejecuten el 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 las opciones RADIUS.
Cuando se configura la autenticación en dos fases
Cuando se utiliza 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 al utilizar 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: una vez cuando se conecten por primera vez al FQDN de Universal Broker y otra vez después de completar correctamente la autenticación en dos fases con el sistema RADIUS o RSA SecurID configurado.
- Cuando se utiliza 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) una vez que se conecten por primera vez al FQDN de puerta de enlace del pod.
Nota: Para eliminar la visualización de dos mensajes de AD cuando se utiliza Universal Broker, considere la integración con Access y configure la autenticación en dos fases en Access.
Métodos de acceso y autenticación de usuario no admitidos actualmente
Actualmente no se admiten los siguientes métodos de acceso y autenticación de usuario.
- Tarjeta inteligente
- Certificados
- Autenticación SAML (fuera de la integración con Omnissa Access)
- Iniciar sesión como el usuario actual
- Acceso anónimo
Cuando uno de los elementos no compatibles cumple 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. En esa página, la instrucción aparecerá en la sección que corresponda a la versión en la que se agregó la compatibilidad.
Funciones de escritorios remotos
En esta versión de Universal Broker no se admiten las siguientes funciones:
- redireccionamiento de contenido URL
- Colaboración de sesiones
Otras características
Tampoco se admiten las siguientes funciones en esta versión de Universal Broker:
- Modo quiosco
- Perfil de tiempo (para solucionar problemas de sesiones de usuario)
- Comprobaciones de conformidad de endpoints basados en OPSWAT
¿Le resultó útil esta página?