VMware actualiza los componentes de software de Horizon Cloud de forma periódica para incluir las nuevas funciones, mejoras en la compatibilidad con el servicio y resiliencia, mejoras en la experiencia del usuario y correcciones de errores. VMware suele actualizar el entorno de administración en la nube de forma semanal y los componentes de software usados en el pod implementado de forma trimestral, aproximadamente. Cuando VMware actualiza los componentes de software utilizados en un pod implementado, el número de manifiesto del software del pod pasa a un número superior. Si hay mejoras consideradas importantes para las operaciones de soporte y la capacidad de servicio del pod, VMware pondrá a disposición un nuevo manifiesto incluso si la temporización se realiza dentro del mismo trimestre que la versión anterior del manifiesto. El proceso de actualización habitual tiene lugar sin provocar ningún tipo de inactividad del sistema.

Importante: Si el pod ya está integrado con la instancia de Workspace ONE Access alojada en la nube mediante la versión antigua del conector 2017.12.1.0 de Linux, se recomienda actualizar el conector a la versión compatible más reciente antes de actualizar el pod. Para elegir la versión del conector compatible con esta versión de Horizon Cloud, consulte las matrices de interoperabilidad de productos de VMware en https://www.vmware.com/resources/compatibility/sim/interop_matrix.php. A continuación, actualice el conector existente siguiendo los pasos para la versión del conector elegida que se encuentra en la documentación de VMware Workspace ONE Access. Después de completar la actualización del conector, actualice el pod.

Actualizar el pod implementado significa mover adecuadamente los componentes de infraestructura actuales del pod a un nivel de manifiesto de software superior. Los componentes de infraestructura son principalmente las máquinas virtuales del administrador de pods y las máquinas virtuales de Unified Access Gateway que están configuradas para el pod. Por ejemplo, una actualización de pod puede incluir actualizaciones para el software de administración de pods o para el software de Unified Access Gateway, o ambos.

Puede utilizar la página Capacidad para ver qué pods tienen actualizaciones disponibles para ellos. Acceda a Configuración > Capacidad. La columna Estado del pod mostrará el icono pendiente en lugar del punto verde. El número de versión del pod es un hipervínculo en lugar de texto estático y, cuando el cursor se desplaza sobre ese número de versión, un mensaje de información sobre herramientas indica que hay una actualización disponible. La siguiente captura de pantalla muestra el comportamiento descrito en la frase anterior.


Horizon Cloud on Microsoft Azure: captura de pantalla de la página Capacidad que muestra un pod con una actualización disponible y una flecha verde apuntando al lugar donde aparece la información sobre herramientas.

Puede ver los detalles de la actualización de un pod específico en su página de detalles. Cuando hay una actualización disponible, aparece un mensaje en pantalla que describe la actualización.


Horizon Cloud on Microsoft Azure: captura de pantalla de la página de detalles del pod que muestra mensajes de actualización.

Nota: Después de actualizar un pod desde versiones anteriores a las más recientes, puede actualizar el software relacionado con el agente en las imágenes, las granjas y las asignaciones de escritorio VDI ya publicadas del pod al mismo nivel de versión del agente que viene con la versión actualizada del pod. La actualización relacionada con el agente se realiza en un proceso independiente de la actualización del propio pod. Para conocer los pasos sobre cómo actualizar el software relacionado con el agente después de que se actualiza el pod, consulte Actualizar el software del agente para las imágenes RDSH en Horizon Cloud, Actualizar el software del agente para las asignaciones de escritorios VDI dedicados y Actualizar el software del agente para las imágenes utilizadas por las asignaciones de escritorios VDI flotantes.

El proceso de actualización del pod de Horizon Cloud sigue el modelo de una técnica de la industria del software conocida como implementación azul-verde.


Ilustración conceptual del proceso de actualización azul-verde.

Los componentes existentes del pod que se deben actualizar se consideran componentes azules. Poco después de que VMware Horizon Service lanza un nuevo manifiesto del pod, el equipo de operaciones de VMware ejecuta algunas comprobaciones previas y designa su cuenta de cliente de Horizon Cloud como disponible para utilizar la nueva versión de manifiesto. En el momento específico en que se designa la nueva versión de manifiesto en la cuenta de cliente, el servicio crea un conjunto verde de componentes para el pod en la suscripción de Microsoft Azure. Este conjunto verde es un entorno paralelo de los componentes azules existentes.

Nota: No todo el proceso de actualización del pod se ajusta exactamente al patrón de implementación azul-verde de la industria. Como ejemplo, en el proceso de actualización del pod, cuando las instancias más recientes se crean junto con las ya existentes, las más recientes se encienden y continúan en ejecución hasta que el pod ha completado la migración a las instancias nuevas. Además, una vez que el implementador validó que el pod se ejecuta correctamente en los componentes más recientes, se eliminan las máquinas virtuales más antiguas, en lugar de dejarlas en un estado inactivo.

Proceso de extremo a extremo

Desde el momento en que el equipo de operaciones de VMware designa la cuenta de cliente para utilizar la nueva versión de manifiesto, la secuencia de extremo a extremo es la siguiente:

  1. El servicio crea un grupo de recursos de Jump Box en la suscripción del pod e implementa una máquina virtual de Jump Box. Esta máquina virtual de Jump Box organiza la creación del conjunto verde de componentes.
  2. Se crea el conjunto verde de componentes junto con los componentes azules en los mismos grupos de recursos. En el grupo de recursos de administración del pod, se crean el conjunto verde de máquinas virtuales del administrador de pods y sus artefactos asociados, como NIC y discos. En los grupos de recursos relacionados con la puerta de enlace del pod, se crean el conjunto verde de máquinas virtuales de Unified Access Gateway y sus artefactos asociados. Estas máquinas virtuales verdes se inician y se mantienen en ejecución hasta que se completa toda la secuencia de extremo a extremo. La máquina virtual de Jump Box y su grupo de recursos se eliminan cuando los componentes verdes se compilan y se ejecutan correctamente.
    Importante: Desde este punto en la secuencia hasta el último paso de la secuencia, se ejecuta un número duplicado de máquinas virtuales: las máquinas virtuales azules y las máquinas virtuales verdes. Por lo tanto, es prudente programar el flujo de trabajo de actualización para realizar el cambio al nuevo software del pod tan pronto como se muestre el banner de notificación donde se indica que la actualización se encuentra disponible para el traspaso, y programarla en un día y una hora más temprano, en vez de más tarde.

    Este proceso no provoca ningún tiempo de inactividad y las máquinas virtuales paralelas no afectan a las operaciones del pod. A menos que el sistema encuentre errores que solo el usuario puede resolver en el entorno de Microsoft Azure, no se requiere ninguna acción en este punto. Al encontrar algún problema en la implementación de los componentes verdes, el servicio detecta si el usuario tiene el control de la solución para esos problemas. Si el servicio determina que el usuario puede solucionar los problemas, se mostrará una notificación en la consola administrativa. Dado que la solución está bajo control del usuario y VMware no puede resolver el problema, si se recibe una notificación de errores de actualización, deben completarse las acciones para resolverlas y, a continuación, ponerse en contacto con el equipo de soporte de VMware para continuar con el proceso de actualización del pod. Para obtener más información sobre los tipos de problemas que puede solucionar, consulte Núcleos necesarios para actualizar un pod de Horizon Cloud en Microsoft Azure y soluciones para errores de actualización de pod típicos. En caso de determinar que el equipo de operaciones de VMware puede resolver un problema, el servicio avisa a este equipo, el cual solucionará el problema sin ninguna acción del usuario.

  3. En la página de detalles del pod, aparece un banner donde se indica que hay una actualización disponible, y se pueden programar el día y la hora para hacer el cambio.
    Horizon Cloud on Microsoft Azure: captura de pantalla de la página de detalles del pod que muestra mensajes de actualización.

  4. A continuación, debe programar la actualización para que el pod pase de usar sus componentes y máquinas virtuales azules actuales a usar los verdes. Esta actualización se programa en la página de resumen del pod cuando se selecciona Actualizar > Programar actualizaciones. Configure un día y una hora para que el servicio cambie el pod de modo que utilice los nuevos componentes verdes. El servicio implementará una máquina virtual de Jump Box para configurar el programador en el pod y, posteriormente, eliminará la máquina virtual de Jump Box hasta la fecha y la hora programadas.
    Importante: Antes de que se ejecute la actualización, elimine en Microsoft Azure los bloqueos de administración que haya establecido en cualquiera de las máquinas virtuales (VM) del pod. Las máquinas virtuales con nombres que tengan una parte como vmw-hcs- podID, donde podID es el valor de ID del pod, pertenecen al pod. Microsoft Azure ofrece la posibilidad de usar el portal de Microsoft Azure para bloquear recursos con el fin de evitar que se realicen cambios en ellos. Estos bloqueos de administración se pueden aplicar en un grupo de recursos completo o en recursos individuales. Si usted o su organización aplicaron bloqueos de administración en las máquinas virtuales del pod, dichos bloqueos deben eliminarse antes de que se ejecute la actualización. De lo contrario, el proceso de actualización no se completará correctamente. Puede localizar el valor de ID del pod en la página de detalles del pod de la página Capacidad.

    Determine la hora más oportuna para que se realice la actualización. Normalmente, la actualización, o la migración de la versión existente a una nueva, tarda unos diez minutos. Como práctica recomendada, programe que se realice la actualización en una hora en la que el entorno esté menos ocupado. Una vez que la actualización está programada, la consola muestra la hora programada en un banner situado en la parte superior. Puede volver a programar la hora de la actualización en cualquier momento antes de la hora programada si se lo requiere en función de las necesidades de su organización.

    Importante: Al programar la actualización en la página de detalles del pod, debe proporcionar una fecha y una hora. Es la hora local en la zona horaria del navegador.

    Horizon Cloud on Microsoft Azure: captura de pantalla de la página Capacidad con el banner superior donde se muestra la hora de la actualización programada del pod.

  5. Al llegar el día y la hora seleccionados, el servicio implementará de nuevo una máquina virtual de Jump Box para organizar el cambio de modo que el pod use los componentes y las máquinas virtuales verdes. Los componentes verdes se convertirán en los componentes azules actuales. El proceso tarda entre cinco y quince minutos en completarse, con las horas más largas para los pods que tienen una configuración de Unified Access Gateway externa e interna. El proceso migra los datos y la configuración de la infraestructura existente del pod que se va a actualizar a la infraestructura nueva.

    Las siguientes limitaciones se aplican durante la migración:

    • No se pueden realizar tareas administrativas en el pod en el que se está llevando a cabo la actualización.
    • Los usuarios finales que no tengan sesiones conectadas con sus aplicaciones remotas o escritorios virtuales que se procesan en el pod de actualización y que intenten conectarse no podrán hacerlo.
    • Los usuarios finales que tengan sesiones conectadas que se procesan en el pod que se actualiza tendrán desconectadas esas sesiones activas. Una vez finalizada la migración, dichos usuarios pueden volver a conectarse. No se producirá pérdida de datos, a menos que se haya usado la opción Inmediatamente para el control del tiempo de espera en las granjas y las asignaciones de escritorios VDI.
    Precaución: Los usuarios con sesiones conectadas a aplicaciones remotas o escritorios que se procesan en las granjas y las asignaciones de escritorios VDI con la opción Salir de las sesiones desconectadas establecida en Inmediatamente se desconectarán de inmediato, y aquellas sesiones desconectadas también se cerrarán inmediatamente. En estas condiciones, se pierden todos los trabajos en curso del usuario.

    Para evitar la pérdida de datos en curso de los usuarios finales en esta situación, antes de que se inicie el proceso de migración, ajuste la configuración de la opción Cerrar sesión en las sesiones desconectadas en las granjas y asignaciones de escritorios VDI con un valor de tiempo que proporcione tiempo a los usuarios para guardar su trabajo. A continuación, cuando se completa la actualización, puede volver a establecer la configuración en su valor anterior.

  6. Una vez que todo se migre al nuevo entorno y el pod se ejecute correctamente en las nuevas instancias, el sistema eliminará las máquinas virtuales azules de los grupos de recursos del pod, así como el grupo de recursos de Jump Box y su contenido. Algunos artefactos, como las NIC para las instancias de Unified Access Gateway anteriores, se mantienen para conservar los valores de configuración necesarios para la próxima actualización del pod.

Una vez completado el proceso de extremo a extremo

Al finalizar la migración a los componentes verdes, puede realizar tareas administrativas en el pod. Para ver la versión del software que ejecuta actualmente un pod, seleccione Configuración > Capacidad y haga clic en el pod para abrir su página de resumen. La página muestra la versión del software que se está ejecutando en este momento. Haga clic en el número de la versión de software para ver la información asociada a la misma.

Después de la actualización

Importante: Si el servidor Radius configurado está implementado en la misma VNET, tras la migración a los elementos de infraestructura nuevos, deberá actualizar la configuración del servidor Radius para aceptar las nuevas direcciones IP privadas de las nuevas máquinas virtuales internas de Unified Access Gateway. Este es un requisito único para la primera actualización en el pod y no es necesario que se repita para las actualizaciones futuras del pod.
Importante: A partir de la versión de servicio trimestral de septiembre de 2019, la arquitectura del pod se actualiza para admitir la capacidad de tener alta disponibilidad (high availability, HA). Incluso cuando la función de alta disponibilidad no está habilitada, la nueva arquitectura compatible con HA incluye un equilibrador de carga de Microsoft Azure delante de la máquina virtual del administrador del pod. Después de actualizar el pod al manifiesto 1600, y si el pod se configuró para conexiones directas, debe volver a asignar la configuración de DNS para que apunte a la nueva dirección IP del equilibrador de carga Azure del administrador de pods que se mostrará en la página de detalles del pod actualizado. Hasta que se actualice la asignación de DNS, si bien las conexiones directas de los usuarios seguirán funcionando, no se podrá realizar una conmutación por error de alta disponibilidad de un pod compatible con HA si la máquina virtual del administrador que es el agente activo deja de funcionar. Para este caso de uso, debe asignar un FQDN a la dirección IP en el campo Dirección IP del equilibrador de carga del administrador de pods que se muestra en la página de detalles del pod, como se describe en Configurar certificados SSL directamente en las máquinas virtuales del administrador de pods, como cuando se integra el dispositivo de Workspace ONE Access Connector con el pod de Horizon Cloud en Microsoft Azure, para que Connector pueda confiar en las conexiones con las máquinas virtuales del administrador de pods. Antes de este manifiesto del pod 1600, esa dirección IP era la que se asignaba a la NIC de la máquina virtual del administrador del pod en la subred de tenant. A partir del manifiesto del pod 1600 o versiones posteriores, la dirección IP del pod que se asignará es la dirección IP privada del equilibrador de carga de Microsoft Azure que se utiliza para las máquinas virtuales del administrador de pods. Para los pods existentes que se actualizaron a la versión de manifiesto de esta versión, si configuró un nombre DNS para que apunte a la dirección IP del dispositivo tenant de un pod con el manifiesto 1493.1 o anterior, debe volver a asignar la configuración de DNS para que apunte a la nueva dirección IP que aparece para la etiqueta Dirección IP del equilibrador de carga del administrador de pods en la página de detalles del pod.