En este artículo se describen los requisitos que el entorno de arrendatario de Horizon Cloud debe cumplir para poder programar y completar la transición de un agente de pod único a un Universal Broker. También sigue los pasos de planificación y preparación para admitir el nuevo FQDN de conexión Universal Broker.

Para admitir el proceso de transición y las operaciones en curso de las asignaciones de varias nubes con brokering de Universal Broker después de la transición, compruebe que el entorno de arrendatario cumpla con los siguientes requisitos.

Requisitos para pods de Horizon Cloud (pods en Microsoft Azure nativo)

Compruebe que los pods implementados en la nube nativa de Microsoft Azure (también conocidos como pods de Horizon Cloud) cumplan los siguientes requisitos.

  • Se implementa al menos un pod de Horizon Cloud para el entorno de arrendatario.
  • Todos los pods se ejecutan en el manifiesto del pod 2298.0 o una versión posterior. Los siguientes requisitos también se aplican a determinados casos prácticos.
    • Si existe una integración entre el arrendatario de Horizon Cloud y Workspace ONE Access, todos los pods deben ejecutarse en el manifiesto 2474.0 o una versión posterior. Después de completar la transición del agente, debe actualizar la integración para adoptar el uso de Universal Broker, como se describe en Entorno de Horizon Cloud con Universal Broker: Integrar el arrendatario con los servicios de Workspace ONE Access e Intelligent Hub.
    • Si desea utilizar la función de cancelación de tareas o la función de protección contra eliminación después de la transición del agente, todos los pods deben ejecutarse en el manifiesto 2474.0 o una versión posterior. Estas funciones no se admiten si los pods se ejecutan en manifiestos anteriores a la versión 2474.0.
    Importante: Asegúrese de que todos los pods de Microsoft Azure estén en línea y en un estado correcto y listo. El servicio de Universal Broker debe comunicarse con los pods y realizar algunos pasos de configuración en los pods para completar el proceso de transición. Si alguno de los pods está sin conexión o no está disponible, no puede programar la transición. Si programa la transición, pero alguno de los pods se desconecta o deja de estar disponible mientras la transición está en curso, se produce un error en la configuración de Universal Broker.
  • No hay actualizaciones de pod programadas para que se produzcan al mismo tiempo que la transición.
  • Cada pod incluye al menos una instancia interna o externa de Unified Access Gateway.
    Nota: Si un pod incluye solo una instancia interna de Unified Access Gateway, Universal Broker anula la directiva de redes definida en la pestaña Rangos de redes de la página Agente y enruta a todos los usuarios a esa instancia de Unified Access Gateway, independientemente de su dirección IP.
    • Cada instancia de Unified Access Gateway debe estar en el nivel de versión 3.8 o posterior.
    • Cada instancia de Unified Access Gateway debe estar emparejada como máximo con un pod.
    • Todas las instancias de Unified Access Gateway de todos los pods deben estar en estado correcto y a punto.
    Importante: Si desea usar la autenticación en dos fases para Universal Broker tras la transición, cada pod debe tener al menos una instancia externa de Unified Access Gateway configurada con el servicio de autenticación RADIUS adecuado. Debe configurar todas las instancias de Unified Access Gateway externas en todos los pods participantes para que usen el mismo servicio de autenticación RADIUS.

Requisitos de DNS, puertos y protocolos para admitir Universal Broker

Compruebe los siguientes requisitos.

Requisitos de FQDN para admitir Universal Broker

Con el agente de pod único, los usuarios finales se conectan al nombre de dominio completo (FQDN) de cada pod de forma individual para acceder a las asignaciones desde el pod.

Después de la transición a Universal Broker, los usuarios pueden acceder a cualquier asignación, desde cualquier pod de cualquier sitio del entorno, mediante la conexión al FQDN del servicio de nube de Universal Broker. Universal Broker enruta cada solicitud de usuario al FQDN individual del pod más adecuado que puede satisfacer la solicitud.

Designe el FQDN Universal Broker en los ajustes de configuración de Universal Broker, como se describe en Programar y completar la transición del agente de pod único a Universal Broker. Puede crear el FQDN si agrega un prefijo con su subdominio válido al dominio estándar proporcionado por VMware, o bien puede configurar un FQDN totalmente personalizado.

Nota: Si decide configurar un FQDN personalizado, tenga en cuenta que este FQDN representa a su empresa u organización. Asegúrese de que es el propietario del nombre de dominio especificado en el FQDN personalizado, que pueda proporcionar un certificado que valide ese dominio y que tenga la autorización adecuada para usar el FQDN personalizado. El FQDN personalizado para Universal Broker debe ser único y distinto de los FQDN de todas las instancias de Unified Access Gateway dentro de los pods.

Planificar y preparar la transición del agente

Dado que la transición del agente implica cambios clave en el flujo de trabajo de asignación y de redes, asegúrese de realizar las acciones necesarias para preparar el entorno y los usuarios para el nuevo flujo de trabajo. Consulte la siguiente guía de planificación para ver los pasos adecuados de preparación y administración de cambios en función del caso práctico de transición.

Caso práctico de transición Pasos de planificación y preparación
El entorno consta de un solo pod y desea utilizar el FQDN existente del pod como FQDN de Universal Broker
  1. Durante la fase de configuración del proceso de programación de transición designe el FQDN existente del pod como FQDN personalizado para el servicio de Universal Broker.
  2. Programe la transición para una fecha y una hora que provocarán una interrupción mínima de las cargas de trabajo de asignación de los usuarios finales.
  3. Notifique y prepare a los usuarios finales para la próxima transición. Recuérdeles que deben guardar su trabajo y cerrar sesión en sus sesiones de conexión activas a medida que se aproxima el tiempo de transición.
  4. Poco antes de la transición, asigne una nueva dirección IP y un FQDN al pod.
  5. Una vez completada la transición, informe a los usuarios finales de que pueden reanudar sus sesiones de conexión con el FQDN anterior del pod, que ahora es el FQDN de Universal Broker.
El entorno consta de varios pods y desea configurar un nuevo FQDN como FQDN de Universal Broker
  1. Actualice los runbooks para incluir los procedimientos necesarios que deben seguirse antes, durante y después del proceso de transición.
  2. Durante la fase de configuración del proceso de programación de la transición, configure el nuevo FQDN para el servicio de Universal Broker.
  3. Programe la transición para una fecha y una hora que provocarán una interrupción mínima de las cargas de trabajo de asignación de los usuarios finales. Asigne un tiempo adecuado a la formación del usuario y la reconfiguración del software cliente, conforme a la escala de las implementaciones de pods.
  4. Notifique y prepare a los usuarios finales para la próxima transición. Recuérdeles que deben guardar su trabajo y cerrar sesión en sus sesiones de conexión activas a medida que se aproxima el tiempo de transición.
  5. Durante la transición, o poco después de la transición, vuelva a configurar Horizon Client en los sistemas cliente de los usuarios para conectarse al nuevo FQDN de Universal Broker, en lugar de los FQDN de los pods individuales.
  6. Informe a los usuarios finales de que ahora deben utilizar el nuevo FQDN de conexión de agente y que, en consecuencia, pueden obtener acceso universal a todos los pods de su entorno.