Las actividades de mantenimiento del sistema incluyen una actualización automatizada de los componentes de software del pod para incluir nuevas funciones, así como correcciones y mejoras en la resistencia y la compatibilidad del servicio. La actividad de mantenimiento que actualiza un pod existente a un manifiesto más reciente se inicia desde el plano de nube para que se produzca en un día y a una hora determinados por el sistema. Para indicar su preferencia de que dicha actividad de mantenimiento del sistema debe iniciarse a una hora y un día determinados de la semana, use la consola para especificar la ventana de mantenimiento preferida de cada pod. Se entenderá que un pod sin una ventana de mantenimiento preferida especificada significa que VMware puede programar un mantenimiento en ese pod en cualquier momento, cuando VMware lo considere oportuno.

Cuando los componentes de software utilizados en un pod implementado se actualizan a una nueva versión, el número de manifiesto del pod aumenta a un número de versión superior, como 2632.0. Si hay mejoras consideradas importantes para las operaciones de mantenimiento y compatibilidad del pod, VMware puede crear un nuevo manifiesto que es una versión de punto, como 2632.1. La consola muestra el manifiesto de un pod en la página Capacidad.

Aspectos que debe conocer sobre el mantenimiento del pod

El mantenimiento de los componentes de software de VMware que componen el pod de Horizon Cloud implementado es una operación imprescindible para mantener el buen estado y la estabilidad de las aplicaciones y los escritorios virtuales aprovisionados por ese pod. Como se describe en el PDF de descripción del servicio de Horizon, VMware es responsable de los componentes de software que residen en el pod y que se descargan en ese pod desde el plano de control. En el documento de Descripción del servicio de Horizon también se describe lo siguiente:

  • Funciones y responsabilidades de VMware en relación con los procedimientos de administración de cambios para mantener el buen estado de los componentes de software que se descargan en el pod. Las actividades de mantenimiento incluyen la actualización de los componentes de software del pod.
  • Función y responsabilidades del cliente en torno a los procedimientos de administración de cambios, incluidos la cooperación con VMware cuando se requiera un mantenimiento programado o de emergencia.

El documento de Descripción del servicio de Horizon contiene una definición de mantenimiento programado, ventanas de mantenimiento y mantenimiento de emergencia. Consulte el documento para obtener información. En caso de discrepancias entre el contenido de esta página de documentación y el contenido del documento de Descripción del servicio de Horizon, el documento de Descripción del servicio de Horizon tendrá prioridad.

Atención: Antes de actualizar el pod, debe asegurarse de que todas las máquinas virtuales de imagen del pod, las máquinas virtuales de granja y las máquinas virtuales de escritorio VDI tengan el agente más reciente disponible para el pod. Si no los actualiza al agente más reciente antes de la actualización del pod, es posible que, después de la actualización del pod, ejecuten versiones de agente incompatibles, lo cual pondrá el pod en un estado no compatible. ¿Cómo puede saber si necesita actualizar alguno de los agentes? En la consola, consulte si hay algún punto azul junto a una imagen o una asignación. Si ve algún punto azul, el objetivo es conseguir que todos los puntos azules desaparezcan de la consola antes de la actualización del pod. Consulte Actualizaciones de pods de Horizon Cloud: pasos para obtener compatibilidad y soporte continuados con los agentes

Especificar la ventana de mantenimiento preferida del pod

Para indicar su preferencia para que cualquier actividad de mantenimiento en el pod se inicie a una hora y un día determinados de la semana, use la consola para especificar lo que se denomina la ventana de mantenimiento preferida para ese pod. En la página Capacidad, desplácese hasta la pestaña Mantenimiento en la página de detalles del pod. Busque la etiqueta Hora preferente de mantenimiento y, a continuación, siga los controles en pantalla para elegir el nombre y la hora (UTC) del día de la semana en ese día. Solo puede elegir entre los valores predeterminados predefinidos del sistema que se muestran.

Especifique la hora preferente de mantenimiento de cada pod por separado en la página de detalles de cada pod en la consola.

Nota: Se entenderá que un pod sin una ventana de mantenimiento preferida especificada significa que usted permite que VMware pueda programar un mantenimiento en ese pod en cualquier momento, cuando VMware lo considere oportuno.

El sistema leerá el día de la semana y la hora que especifique en la consola e incorporará los datos en su algoritmo de programación. Cuando se establece un nuevo manifiesto del pod como predeterminado en el plano de nube, el programador del sistema calculará el día de actualización real y la hora a la que ha determinado que la actualización puede ocurrir en cada pod del conjunto de pods. Aunque el sistema intentará en la medida de lo posible respetar las horas de inicio de mantenimiento preferidas especificadas en la pestaña Mantenimiento del pod, no hay garantías de que el sistema pueda amoldarse a esta hora de inicio de mantenimiento preferida para una operación de actualización específica.

Una vez establecido esto, el programador del sistema asigna cuatro (4) horas para la duración de la actividad de mantenimiento. La actualización típica del pod tarda menos tiempo que esta duración asignada.

Alertas y notificaciones de mantenimiento

El sistema alertará y notificará a los administradores del entorno de arrendatario cuando el sistema haya programado una fecha y una hora de calendario específicas para que se produzca el mantenimiento específico de un pod determinado. Estas alertas y notificaciones incluyen lo siguiente:

En la consola
  • Un banner persistente en la parte superior de la consola. La hora del banner es la hora de mantenimiento local de la zona horaria del navegador, tal como se visualiza en la consola. La siguiente captura de pantalla es un ejemplo en el que la actualización del pod se programa para que se produzca a las 16:00 de la zona horaria oriental de los Estados Unidos, el 7 de julio de 2020. Utilice el botón Ver para hacer clic en la página de detalles del pod y ver más información sobre el mantenimiento programado en la pestaña Mantenimiento del pod.
    Captura de pantalla de ejemplo del banner de la consola que proporciona información sobre el mantenimiento programado de un pod
  • En la pestaña Registros de auditoría del pod y en la pestaña Actividad > Registros de auditoría de la consola, un registro de auditoría mostrará que el equipo de operaciones de VMware tiene programada una actualización del pod. La línea del registro de auditoría incluirá el UUID del pod.
  • En la pestaña Mantenimiento del pod, la sección Mantenimiento programado mostrará información sobre el mantenimiento programado.
Correos electrónicos
El sistema enviará correos electrónicos sobre el mantenimiento del pod a los administradores del entorno de arrendatario, que se especifican en los ajustes de Configuración general > Cuentas de My VMware de la consola. Entre los correos electrónicos se incluye uno acerca del momento en que el sistema ha establecido la fecha y la hora de calendario específicos del mantenimiento programado. Algunos ejemplos de estos correos electrónicos son recordatorios periódicos en los días y las semanas anteriores a esa fecha y hora programadas, así como cuando la actividad de mantenimiento ha comenzado y cuando se ha completado.
Nota: Si desea volver a programar una fecha y una hora de mantenimiento programado, debe ponerse en contacto con el soporte técnico de VMware.

Comprobaciones previas del sistema antes de realizar el mantenimiento del pod

Si recibe un correo electrónico de notificación que indica que un pod tiene errores de actualización del pod, o si ve que la consola notifica errores de actualización para el pod, debe tomar medidas para rectificar la situación. Si esto sucede, siga las instrucciones en pantalla de la consola o las instrucciones del correo electrónico. La resolución habitual para estos errores normalmente implica realizar pasos en el portal de Microsoft Azure, en la suscripción del pod. Para obtener información adicional sobre las soluciones frente a errores típicos de actualización del pod, consulte Pods de Horizon Cloud: soluciones a errores comunes de comprobación previa.

¿Cuál es el objetivo de estas comprobaciones previas? La actividad de mantenimiento de una actualización del pod tiene lugar en los grupos de recursos del pod y la suscripción de Microsoft Azure. Un poco antes de que el sistema programe una fecha y una hora concretas para una actualización específica en un pod determinado, el sistema ejecuta una operación de comprobación previa para determinar si existen condiciones que pueden bloquear la actualización correcta de un pod. Como ejemplo de una de estas comprobaciones previas, el sistema comprueba si la suscripción de Microsoft Azure tiene suficientes vCores de la serie de máquinas virtuales apropiada para satisfacer los requisitos de la actualización. Si se produce un error en una de las comprobaciones previas y la condición requiere que se corrija su acción, se producen los siguientes problemas:

  • Se enviará un correo electrónico de notificación al usuario para alertarle de este hecho, con detalles sobre las acciones necesarias para rectificar el error.
  • La consola muestra una alerta visual que indica que se requieren acciones para rectificar los errores de comprobación previa de ese pod.
Importante: Si recibe notificaciones sobre errores de actualización del pod, realice las acciones especificadas para solucionar los errores de manera oportuna. Actuar a tiempo es fundamental. Si no se puede actuar para solucionar estos errores en el tiempo que VMware requiere, el pod pasará a un estado no compatible debido a la imposibilidad de solucionar el proceso de actualización del pod.

Actualizaciones del pod: descripción de nivel general

Cuando la actividad de mantenimiento es una actualización del pod a una versión de manifiesto más reciente, el sistema mueve correctamente 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.

El proceso de actualización del pod sigue el modelo de una técnica de la industria del software conocida como implementación azul-verde. Los componentes existentes del pod que se deben actualizar se consideran componentes azules.


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

Aunque básicamente la actualización del pod sigue un patrón azul-verde del sector, existen algunas diferencias menores con respecto a una actualización clásica de tipo azul-verde. La actualización del pod no duplica al 100 % cada recurso azul de la compilación verde. Algunos de los recursos azules existentes se reutilizan en la nueva compilación verde, como las NIC para las instancias de Unified Access Gateway. Otra diferencia es que 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, después de que el sistema migre el pod a la compilación verde y valide que el pod se esté ejecutando correctamente en la nueva versión de manifiesto, las máquinas virtuales azules más antiguas se eliminarán del grupo de recursos. (Una actualización clásica de tipo azul-verde por lo general conservaría los artefactos azules más antiguos después del cambio a verde, manteniendo las más antiguas en estado inactivo).

  • Los componentes del pod existentes que se actualizarán, como las máquinas virtuales del administrador de pods y las máquinas virtuales de Unified Access Gateway, se consideran los componentes azules.
  • El servicio crea automáticamente el conjunto verde necesario de componentes para el pod en la suscripción de Microsoft Azure: nuevas máquinas virtuales del administrador de pods verdes, máquinas virtuales Unified Access Gateway y la máquina virtual del conector de puerta de enlace (si la puerta de enlace externa se implementa en su propia red virtual).
  • Se crea automáticamente una máquina virtual de Jumpbox temporal en la suscripción del pod para organizar esta compilación verde. Esta máquina virtual de Jumpbox temporal y su grupo de recursos se eliminan después de que el entorno paralelo verde se haya compilado correctamente.
  • Los componentes recién creados en la compilación verde se crean junto con los componentes azules, en los mismos grupos de recursos.
  • El proceso de creación de la compilación verde no genera ningún tiempo de inactividad ni pérdida de datos, y las máquinas virtuales paralelas no afectan a las operaciones del pod.
  • El conjunto verde es un entorno paralelo que está a la espera de la actividad de mantenimiento programado que hará que cambie de azul a verde. La forma en que el sistema programa la actividad de mantenimiento en un pod se trata en las secciones anteriores.
  • Estas máquinas virtuales verdes se inician y se mantienen en ejecución hasta que se completa la actividad de mantenimiento programada, la actividad de mantenimiento que migra el azul al verde.
  • Después de que se haya completado la actividad de mantenimiento programada para migrar a la compilación verde y de que el pod se esté ejecutando correctamente en las nuevas instancias, el sistema elimina las máquinas virtuales azules de los grupos de recursos del pod. Algunos recursos, como las NIC para las instancias de Unified Access Gateway, se mantienen para conservar los valores de configuración necesarios para la próxima actualización del pod.
Nota: Debe evitar realizar cambios en el portal de Microsoft Azure y en la suscripción del pod que afecten a la compilación del sistema a través de los componentes verdes o afecten a los procesos de actualización y mantenimiento del pod del sistema.

Secuencia de actividad de mantenimiento

Esta secuencia describe la migración a la compilación verde: el cambio de azul a verde en la actualización del pod.

  1. El sistema comprueba la ventana de mantenimiento preferida del pod que especificó en la consola para utilizar esa información en el algoritmo del programador, con el objeto de programar la fecha y la hora real de la actividad de mantenimiento del pod.
  2. El programador del sistema selecciona la fecha y la hora reales para que se produzca el mantenimiento. Como se describe en las secciones anteriores, la consola muestra visualmente la fecha y la hora programadas y se envía un correo electrónico a los administradores del arrendatario.
  3. Importante: Antes de que se ejecute el mantenimiento programado:
    • Asegúrese de que todas las máquinas virtuales de imagen del pod, las máquinas virtuales de granja y las máquinas virtuales de escritorio VDI tengan el agente más reciente disponible para el pod. Si ve algún punto azul en la consola, el objetivo es conseguir que todos los puntos azules desaparezcan de la consola antes de que se produzca la actualización del pod. Consulte Actualizaciones de pods de Horizon Cloud: pasos para obtener compatibilidad y soporte continuados con los agentes
    • 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.

    Si las necesidades de su organización lo requieren, puede solicitar una fecha programada diferente para el mantenimiento. Para ello, póngase en contacto con el soporte técnico de VMware en cualquier momento antes de la hora de mantenimiento programada.

    Importante: La hora programada que aparece en la consola es local para la zona horaria del navegador.
  4. En el tiempo de mantenimiento programado, el servicio vuelve a implementar una máquina virtual de Jumpbox para organizar la actividad de mantenimiento. A pesar de que el proceso normalmente tarda hasta 20 minutos en completarse para los pods que tienen una configuración de Unified Access Gateway externa e interna, el sistema asigna cuatro (4) horas a la actividad de mantenimiento general, para garantizar un resultado correcto.

    Las siguientes limitaciones se aplican durante la actividad de mantenimiento:

    • 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 finalizado el mantenimiento, 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 la actividad de mantenimiento, 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.

  5. Una vez completada la actividad de mantenimiento, el sistema elimina los componentes que ya no se necesitan, como el grupo de recursos de Jumpbox y su contenido, y los componentes azules que no se reutilizan en la compilación verde, como las máquinas virtuales del administrador de pods y las máquinas virtuales Unified Access Gateway. Algunos artefactos, como algunas NIC para las instancias de Unified Access Gateway, se mantienen para conservar los valores de configuración necesarios para el próximo mantenimiento.

Después de la actividad de mantenimiento

Cuando finalice la actividad de mantenimiento, 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.

Atención: Después de una actualización del pod, asegúrese de que los agentes de todas las imágenes, las granjas y las asignaciones de VDI existentes estén actualizados a la versión disponible más reciente. Si los agentes instalados de esas máquinas virtuales no se actualizan, el pod tendrá una configuración no compatible. El proceso de mantenimiento no actualiza automáticamente esos agentes instalados. Si ve algún punto azul en la consola para sus imágenes o asignaciones, significa que es necesario actualizar los agentes. Actualizaciones de pods de Horizon Cloud: pasos para obtener compatibilidad y soporte continuados con los agentes.
Importante: Si el servidor Radius configurado está implementado en la misma red virtual, tras la actividad de mantenimiento, 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 actualice la asignación de DNS (a pesar de que esas conexiones directas de usuario seguirán funcionando), si la máquina virtual activa del administrador de pods se queda sin servicio, dichas conexiones no incluirán la conmutación por error de alta disponibilidad que un pod compatible con HA está diseñado para proporcionar. 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 arrendatario. 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 arrendatario 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.