Pods de Horizon Cloud: mantenimiento y actualizaciones

En esta página de documentación se describen los aspectos clave que se deben conocer sobre el mantenimiento de los componentes de software que componen el pod de Horizon Cloud implementado.

Introducción

Las actividades de mantenimiento del sistema incluyen una actualización automatizada de los componentes de software del pod para incluir nuevas funciones, correcciones y mejoras en la resistencia y la compatibilidad del servicio.

Para completar una actualización de los dispositivos de puerta de enlace y pod con tiempo de inactividad prácticamente nulo, el sistema utiliza los recuentos de las sesiones de usuario final. El sistema utiliza los recuentos de sesiones con el fin de determinar el tiempo óptimo para completar la actualización cuando hay pocos usuarios conectados al entorno con sesiones activas.

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 el equipo de Horizon Cloud puede programar un mantenimiento en ese pod en cualquier momento a su conveniencia.

Nota: Como se describe en esta página de documentación, a partir de principios del año 2022, el servicio mejoró el código de actualización para utilizar mediante programación las ofertas que se proporcionan en Azure Marketplace. Cuando las comprobaciones previas a la actualización determinan que se evita el uso programático de nuestras ofertas en la suscripción, debe completar las acciones que se describen en esa página de documentación para resolver los errores de bloqueo de actualización.

Por ejemplo, si la entidad de servicio de Horizon Cloud asociada a las suscripciones utilizadas para el pod y sus configuraciones de puerta de enlace utiliza una función personalizada (atípica), asegúrese de que la función personalizada incluye estos dos permisos. El código de API de actualización mejorada se basa en estos permisos para recuperar la lista de ofertas de Marketplace y obtener nuestras ofertas. Si la función personalizada aún no incluye estos dos permisos, haga que se agreguen a la función personalizada antes de que tenga lugar el proceso de actualización del pod y la puerta de enlace.

Microsoft.MarketplaceOrdering/offertypes/publishers/offers/plans/agreements/read
Microsoft.MarketplaceOrdering/offertypes/publishers/offers/plans/agreements/write

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 soporte y la capacidad de servicio del pod, podemos crear un nuevo manifiesto que sea una versión de punto, como 2632.1. La consola muestra el manifiesto de un pod en la página Capacidad.

Información importante sobre la actualización de un pod desde manifiestos anteriores a la versión 3328

A partir de febrero de 2022, las NIC de las máquinas virtuales del administrador de pods siguen el mismo patrón de diseño de infraestructura que las NIC de las máquinas virtuales de Unified Access Gateway.

En las nuevas implementaciones de pods a partir de ese momento y en las actualizaciones de pods de manifiestos anteriores al manifiesto 3328, el implementador crea instancias de todas las redes necesarias para admitir la ejecución del pod y para las actualizaciones posteriores a lo largo del tiempo. El grupo de recursos del pod ahora tendrá 8 NIC:

• 4 NIC que reservan 4 direcciones IP de la subred de administración del pod
• 4 NIC que reservan 4 direcciones IP de la subred de la máquina virtual principal del pod (anteriormente denominada subred de arrendatario).

Estas 8 NIC del pod persistirán y seguirán reservando sus direcciones IP asignadas durante la vida útil del pod.

Este diseño admite actualizaciones de pods más rápidas y resistentes. Antes de este diseño, una actualización del pod requería la creación de nuevas NIC como parte de la compilación del pod verde y la obtención de direcciones IP para esas NIC de las subredes del pod en el momento de la actualización. Con ese diseño, podían producirse tiempos de espera en Azure e interrumpir el proceso de actualización.

En este diseño, en el que el implementador crea instancias de todas las redes necesarias por adelantado, las NIC y sus direcciones IP de las subredes de administración y de máquina virtual (arrendatario) se conservan para utilizarse en las actualizaciones posteriores del pod. Este diseño se alinea con el patrón utilizado para las instancias de Unified Access Gateway.

Cuando el pod aún no tiene las 8 NIC en el grupo de recursos del pod y está programado para actualizarse al manifiesto 3328 o una versión posterior, debe realizar estas acciones.

• Antes de actualizar el pod, asegúrese de que solo los elementos que crea y configura Horizon Cloud on Microsoft Azure tomen las direcciones IP de la subred de administración del pod y las direcciones IP de la subred de máquina virtual principal (arrendatario)

  • Subred de administración: solo las NIC específicas de la implementación de Horizon Cloud on Microsoft Azure que el implementador de pods haya creado y configurado deben utilizar direcciones IP de la subred de administración del pod. Estas NIC son las de los administradores de pods y las de la instancia de Unified Access Gateway del pod. La subred de administración del pod no debe tener elementos ni recursos no implementados por el pod asociados a ella ni que tomen direcciones IP de ella.
  • Subred de arrendatario: solo los equilibradores de carga y las NIC específicas de la implementación de Horizon Cloud on Microsoft Azure que crea y configura el implementador de pods deben utilizar direcciones IP de la subred de arrendatario del pod. La subred de arrendatario del pod no debe tener elementos ni recursos que no sean de implementación asociados a ella ni que tomen direcciones IP de ella. La Guía de implementación indica exactamente que las subredes que utiliza el pod no deben tener recursos adicionales asociados a ellas que no sean los recursos de la implementación del pod. Si creó recursos manualmente y asignó direcciones IP de la subred de arrendatario o de administración del pod a dichos recursos adicionales, debe eliminar esas direcciones IP de esos recursos antes de que se ejecute la actualización del pod. De lo contrario, se producirá un error en la actualización del pod y será necesario el soporte de Horizon Cloud.

• Después de actualizar el pod, asegúrese de agregar todas las direcciones IP reservadas por las NIC creadas por el implementador en el grupo de recursos del pod a las reglas de firewall vigentes antes de la actualización

  Es posible que existan reglas de firewall que rijan el tráfico desde las direcciones IP de las NIC de las máquinas virtuales del administrador de pods. Para que la comunicación del tráfico funcione después de la actualización del pod tal como funcionaba antes de ella, debe asegurarse de que las 8 direcciones IP reservadas por las NIC en el grupo de recursos del pod se reflejen en las reglas de firewall después de la actualización.

Aspectos que debe conocer sobre el mantenimiento de pods

El mantenimiento de los componentes de software 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 artículo de la base de conocimientos Horizon Cloud: detalles adicionales del servicio (87894), somos responsables de los componentes de software que residen en el pod y que se descargan en él desde el plano de control. El PDF Horizon Cloud: detalles adicionales del servicio adjunto a ese artículo de la base de conocimientos describe:

• Nuestra función y responsabilidades (de Omnissa) 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.
• El papel y las responsabilidades del cliente en torno a los procedimientos de gestión de cambios, incluida la cooperación con nosotros cuando se requiera un mantenimiento programado o de emergencia.

El documento Horizon Cloud: detalles adicionales del servicio contiene una definición de mantenimiento programado, ventanas de mantenimiento y mantenimiento de emergencia. Consulte el documento para obtener más información. En caso de discrepancias entre el contenido de esta página de documentación y el contenido del documento Horizon Cloud: detalles adicionales del servicio , el documento Horizon Cloud: detalles adicionales del servicio 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 que 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 nos permite programar un mantenimiento en ese pod en cualquier momento a nuestra conveniencia.

El sistema leerá el día de la semana y la hora que especifique en la consola e incorporará esos 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 grupo de pods. Aunque el sistema hará todo lo posible para acomodar las horas de inicio de mantenimiento preferidas especificadas en la pestaña Mantenimiento del pod, no hay garantías de que el sistema pueda acomodar esta hora de inicio de mantenimiento preferida para una operación de actualización específica.

Una vez redactado este documento, 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 está programada para que se produzca a las 16:00 de la zona horaria oriental de 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.

    

  • En la pestaña Registros de auditoría del pod y en Actividad > Registros de auditoría de la consola, un registro de auditoría indicará que Operaciones 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 el área de cuentas de la interfaz de usuario de Configuración general de la consola. Entre los correos electrónicos se incluye uno en el que el sistema ha establecido la fecha y la hora de calendario específicas 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 de Horizon Cloud.

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 del 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 más información sobre las soluciones para errores de actualización de pods típicos, consulte Pods de Horizon Cloud: soluciones para 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 y la suscripción de Microsoft Azure del pod. 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 podrían 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 adecuada 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. El tiempo es esencial. Si no se puede actuar para solucionar estos errores en el tiempo que se requiere, el pod pasará a un estado no compatible debido a la imposibilidad de solucionar el proceso de actualización del pod.

Actualizaciones de pods: descripción de nivel general

Cuando la actividad de mantenimiento es la actualización de un 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.

Aunque, en la mayoría de los casos, 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 nuevas instancias. Además, después de que el sistema migra el pod a la compilación verde y valida que el pod se está ejecutando correctamente en la nueva versión de manifiesto, las máquinas virtuales azules más antiguas se eliminan 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 de 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 VNet).
• 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 provoca 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 programada 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 que se necesitarán en 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, es decir, 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 y programar la fecha y la hora reales 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 contengan una cadena como hcs-podID, donde podID es el valor de ID del pod, pertenecen al pod. Microsoft Azure ofrece la posibilidad de utilizar 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 Horizon Cloud 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 momento del mantenimiento programado, el servicio inicia la actividad de actualización. El proceso completo suele tardar entre 20 y 30 minutos de principio a fin para los pods que tienen una configuración de Unified Access Gateway externa e interna.

   Nota: Durante los 20 o 30 minutos que tarda en completarse el proceso, la consola no permite realizar tareas administrativas en el pod en el que se realiza la actualización. Por ejemplo, hasta que los dispositivos del administrador de pods notifiquen al plano de nube que la actualización se ha completado, la acción Editar de la página de detalles del pod no estará disponible para hacer clic para cambiar las características de ese pod.

   • Acerca de las sesiones de usuario final y la actividad de actualización en los dispositivos de Unified Access Gateway

     Para que las sesiones de usuario final tengan un tiempo de inactividad prácticamente nulo, dentro del tiempo de actividad de mantenimiento general, el sistema utiliza los recuentos de las sesiones de usuario final en los dispositivos a fin de determinar el tiempo óptimo para completar la actualización de dichos dispositivos.

     La hora de finalización se optimiza para que se produzca en el momento en que haya pocos usuarios conectados al entorno con sesiones activas.

     En esa ventana de tiempo prácticamente nulo, se desconectarán las sesiones activas de los usuarios finales. A continuación, en unos minutos, esos usuarios podrán volver a conectarse.

     No se produce pérdida de datos, excepto en el caso de que se haya establecido la opción Inmediatamente para el control del tiempo de espera en las granjas y las asignaciones de escritorios VDI. En ese caso, los usuarios con sesiones activas en las que haya utilizado la opción Inmediatamente para el control del tiempo de espera se desconectarán inmediatamente, y esas sesiones también se cerrarán inmediatamente, de acuerdo con esa configuración. En estas condiciones, se perderá cualquier trabajo de usuario en curso. Para evitar la pérdida de datos en proceso 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, una vez finalizada la actualización, puede volver a establecer la configuración en su valor anterior.

     Además, durante esa ventana de tiempo prácticamente nulo, si un usuario final que aún no tiene una sesión conectada a su escritorio virtual o aplicación remota desde el pod intenta conectarse, no podrá conectarse hasta que se complete el proceso.

5. Una vez completada la actividad de mantenimiento, el sistema elimina los componentes que ya no se necesitan, como 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 de Unified Access Gateway. Algunos artefactos, como ciertas NIC para las instancias del administrador de pods y 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 de 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 actual del software que se está ejecutando.

• Después de una actualización del pod, asegúrese de que los agentes de todas las imágenes, granjas y 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 los 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.
• Si esta actualización se realizó desde un manifiesto anterior al manifiesto 3328, después de actualizar el pod, asegúrese de agregar a las reglas de firewall todas las direcciones IP de las NIC creadas por el implementador que se encuentran en el grupo de recursos del pod. Es posible que existan reglas de firewall que rijan el tráfico desde las direcciones IP de las NIC de las máquinas virtuales del administrador de pods. Para que la comunicación del tráfico funcione después de esta actualización del pod y las actualizaciones posteriores tal como funcionaba antes de ella, debe asegurarse de que las 8 direcciones IP reservadas por las NIC en el grupo de recursos del pod se reflejen en las reglas de firewall después de la actualización.
• Si el servidor de autenticación en dos fases configurado está implementado en la misma red virtual, tras la actividad de mantenimiento, deberá actualizar la configuración del servidor de autenticación en dos fases 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. Consulte Actualizar el sistema de autenticación en dos fases con la información requerida de puerta de enlace.
• 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 (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 de pods. Después de actualizar el pod al manifiesto 1600, 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 de 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 deja de funcionar, esas conexiones no tendrán la conmutación por error de alta disponibilidad que un pod habilitado para HA está diseñado para proporcionar. Para este caso práctico, se asigna 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 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 del 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 del 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 dirección IP que se muestra para la etiqueta Dirección IP del equilibrador de carga del administrador de pods en la página de detalles del pod actualizado.
• Antes del manifiesto de 2474.x, el sistema no comprobaba la desviación del reloj de los servidores de Active Directory registrados. Con 2474.x, se introdujo una comprobación del sesgo de reloj. Si los servidores registrados de Active Directory tienen algún problema de sincronización de hora (clockSkew > 4 minutes) ahora, cuando el pod se actualice a 2474.x o una versión posterior, esta validación del sistema se iniciará en ese pod. Como resultado, hasta que solucione el problema de la desviación del reloj, es posible que se produzcan errores en la detección de servidores de Active Directory, que afectarán a las solicitudes de conexión de escritorio de los usuarios finales a ese pod.