Skip to main content

1 de septiembre de 2026

Pods de Horizon Cloud: soluciones para errores comunes de comprobación previa

En este tema se describen las soluciones que se deben aplicar para los errores comunes de comprobación previa de mantenimiento. Cuando las comprobaciones previas del sistema revelan condiciones que pueden bloquear la actividad de mantenimiento en un pod, esos errores se exponen en Horizon Universal Console para que pueda realizar las acciones necesarias para solucionarlos.

Importante: Si recibe notificaciones sobre errores de actualización del pod, debe realizar 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 requiere el servicio, el pod pasará a un estado no compatible debido a la imposibilidad de solucionar el proceso de actualización del pod. .

Como se describe en Pods de Horizon Cloud: mantenimiento y actualizaciones, el sistema notifica las condiciones de bloqueo de mantenimiento que están bajo el control del usuario en el entorno de Microsoft Azure. Dado que la solución queda bajo el control del usuario y no podemos resolver nosotros, si ve una notificación de errores de actualización en la consola o recibe un correo electrónico de notificación acerca de dichos errores, debe completar las acciones para resolverlos y, a continuación, ponerse en contacto con el equipo de soporte de Horizon Cloud para continuar con la actividad de mantenimiento.

Errores de bloqueo de actualización que normalmente se pueden producir

Estos son los errores de bloqueo de actualización que normalmente se pueden producir y que se pueden solucionar en el entorno de Microsoft Azure.

  • Las directivas de suscripción bloquean el uso de las ofertas de Azure Marketplace por parte del editor del servicio.

    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 dichas ofertas en la suscripción, debe completar las acciones descritas en esa página de documentación para resolver los errores de bloqueo de actualización.

  • La suscripción no tiene suficientes núcleos (vCPU) o tamaños de máquina virtual adecuados disponibles para crear instancias de todas las máquinas virtuales para las máquinas virtuales que serán paralelas.

    Cuando se crean los componentes verdes, para cada máquina virtual del pod actual, se crea otra máquina virtual. Como resultado, la cantidad de máquinas virtuales del administrador de pods y máquinas virtuales de Unified Access Gateway se duplica desde el momento en que se crean los componentes verdes hasta que se produce la migración de los componentes azules a los verdes en el momento programado en la consola. Para admitir la creación de estas máquinas virtuales verdes, los niveles de cuota de la suscripción para núcleos (vCPU) de las familias de máquinas virtuales de Microsoft relevantes deben ser suficientes para alojar las máquinas virtuales que serán paralelas, junto con la cuota que ya se haya utilizado de la suscripción para sus pods asociados existentes. Consulte la tabla de cuota y núcleos que aparece a continuación para conocer los núcleos necesarios para los distintos tipos y usos de máquinas virtuales.

  • El pod se encuentra sin conexión o no puede comunicarse con Horizon Cloud.

    En la página Capacidad, compruebe que el pod que se va a actualizar informe del estado en línea. Inicie sesión en el portal de Microsoft Azure y compruebe si la máquina virtual del administrador de pods y sus máquinas virtuales de Unified Access Gateway (si el pod tiene alguna) están en ejecución. Si una máquina virtual no se está ejecutando, enciéndala. Para obtener más información sobre los grupos de recursos en los que se encuentran esas máquinas virtuales, consulte Arrendatarios de first-gen: grupos de recursos creados para un pod implementado en Microsoft Azure.

  • El permiso para crear o eliminar grupos de recursos no está habilitado para esta suscripción de Microsoft Azure.

    La comprobación previa del sistema valida que la entidad de servicio asociada con este pod tenga los permisos necesarios que requiere el servicio. Si el permiso para crear o eliminar grupos de recursos no está habilitado en la suscripción del pod, esa automatización se bloquea. Para solucionar esta situación, siga el mensaje de guía de validación sobre cómo habilitar los permisos necesarios mediante el portal de Microsoft Azure. Para obtener más información sobre los permisos que el servicio requiere que tenga la entidad de servicio para realizar las operaciones requeridas por el servicio, lea Cuando la organización prefiere usar una función personalizada.

Cuota y núcleos necesarios para el tiempo de implementación de las máquinas virtuales verdes cuando se completa la migración desde las máquinas virtuales azules

Si se le notifica un error de actualización debido a la falta de núcleos disponibles, utilice la siguiente tabla para ver la cuota adicional que necesita. Para los diversos tipos de máquinas virtuales que se utilizan en el pod actual tal como está, la tabla del final de este tema describe la cuota que utilizan esos tipos, la cuota adicional necesaria cuando se crean las máquinas virtuales del pod verde y la cuota total necesaria para ejecutar las máquinas virtuales azules y verdes desde el momento en que se crean las máquinas virtuales verdes hasta que se completa la migración a la compilación verde. Para obtener más información sobre los tipos y los núcleos de la familia de máquinas virtuales que utiliza un pod, consulte la página Requisitos de máquina virtual para un pod en la Guía de implementación.

Tipos de máquina virtual y sus núcleosDescripciónCuota total para la ejecución de máquinas virtuales azules y máquinas virtuales verdes hasta que se complete el cambio a verde
Standard_D4_v3 tipo de máquina virtual, 4 núcleos cada una Nota: Si el tipo de Standard_D4_v3 no está disponible en la región de Microsoft Azure, el pod suele utilizar Standard_D3_v2 tipo de máquina virtual. Ese tipo también utiliza 4 núcleos.Este tipo de máquina virtual se utiliza para las máquinas virtuales del administrador de pods.
  • Para un pod con una sola máquina virtual del administrador: su cuota debe permitir los 4 núcleos de la máquina virtual del administrador (azul) existente, además de los 4 núcleos adicionales de la futura máquina virtual del administrador paralela. Ocho (8) núcleos para cubrir este uso.
  • Para un pod con alta disponibilidad habilitada, que tiene dos máquinas virtuales del administrador: su cuota debe permitir los 8 núcleos de las máquinas virtuales del administrador (azules) existentes (2 máquinas virtuales de 4 núcleos cada una), además de los 8 núcleos adicionales de las máquinas virtuales del administrador que serán paralelas. Dieciséis (16) núcleos para cubrir este uso.
Según lo que elija al implementar el pod:
  • Standard_A4_v2 tipo de máquina virtual (tiene 4 núcleos)
  • Standard_F8s_v2 (tiene 8 núcleos)
Este tipo de máquina virtual se utiliza para las máquinas virtuales de Unified Access Gateway en las configuraciones de puerta de enlace del pod. La cantidad de núcleos que debe admitir la suscripción depende de los tipos de puerta de enlace configurados en el pod.
  • Para un pod con solo una puerta de enlace externa: esa puerta de enlace externa tiene dos máquinas virtuales de Unified Access Gateway, es decir, 2 máquinas virtuales multiplicadas por la cantidad de núcleos que tiene cada una. Para el conjunto futuro, su cuota debe permitir la cantidad total de núcleos de las máquinas virtuales de Unified Access Gateway existentes (azules) más una cantidad de núcleos duplicados para las máquinas virtuales de Unified Access Gateway verdes paralelas.
    • Por ejemplo, si las máquinas virtuales son del Standard_A4_v2 con 4 núcleos cada una, se necesitan 2 por 4 por 2, es decir, 16 núcleos para cubrir este uso.
    • Si las máquinas virtuales son de un tamaño de máquina virtual con 8 núcleos cada una, se necesitan 2 por 8 por 2, es decir, 32 núcleos para cubrir ese uso.
  • Para un pod con solo una puerta de enlace interna: esa puerta de enlace tiene dos máquinas virtuales de Unified Access Gateway, es decir, 2 máquinas virtuales multiplicadas por la cantidad de núcleos que tiene cada una. Para el conjunto futuro, su cuota debe permitir la cantidad total de núcleos de las máquinas virtuales de Unified Access Gateway existentes (azules) más una cantidad de núcleos duplicados para las máquinas virtuales de Unified Access Gateway verdes paralelas.
    • Por ejemplo, si las máquinas virtuales son del Standard_A4_v2 con 4 núcleos cada una, se necesitan 2 por 4 por 2, es decir, 16 núcleos para cubrir este uso.
    • Si las máquinas virtuales son de un tamaño de máquina virtual con 8 núcleos cada una, se necesitan 2 por 8 por 2, es decir, 32 núcleos para cubrir ese uso.
  • Para un pod con ambos tipos de puertas de enlace : esa puerta de enlace tiene cuatro máquinas virtuales de Unified Access Gateway, es decir, 4 máquinas virtuales multiplicadas por la cantidad de núcleos que tiene cada una. Para el conjunto futuro, la cuota debe permitir 4 veces los núcleos de las máquinas virtuales de Unified Access Gateway existentes (azules) más una nueva multiplicación por dos para las máquinas virtuales de Unified Access Gateway verdes en paralelo.
    • Por ejemplo, si las máquinas virtuales son del Standard_A4_v2 con 4 núcleos cada una, se necesitan 4 por 4 por 2, es decir, 32 núcleos para cubrir este uso.
    • Si las máquinas virtuales son de un tamaño de máquina virtual con 8 núcleos, se necesitan 4 por 8 por 2, es decir, 64 núcleos para cubrir ese uso.

¿Le resultó útil esta página?

Enviar comentarios sobre este tema

¿Le resultó útil este tema?

No incluya información personal ni confidencial.

Generando el enlace…