Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Actualizar entornos de computación
Después de crear un entorno de procesamiento que utilice EC2 recursos, puede actualizar muchos de los ajustes del entorno de procesamiento directamente. Sin embargo, para cambiar algunos de los ajustes es necesario que AWS Batch reemplace las instancias del entorno de computación.
importante
AWS Batch crea y administra varios AWS recursos en su nombre y dentro de su cuenta, incluidos Amazon EC2 Launch Templates, Amazon EC2 Auto Scaling Groups, Amazon EC2 Spot Fleets y Amazon ECS Clusters. Estos recursos gestionados están configurados específicamente para garantizar un AWS Batch
funcionamiento óptimo. La modificación manual de estos recursos gestionados por lotes, a menos que se indique explícitamente en la AWS Batch
documentación, puede provocar un comportamiento inesperado que provoque un entorno de INVALID
cómputo, un comportamiento de escalado de instancias subóptimo, un retraso en el procesamiento de la carga de trabajo o costes inesperados. El servicio no puede admitir estas modificaciones manuales de forma determinista. AWS Batch Utilice siempre el Batch compatible APIs o la consola Batch para gestionar sus entornos informáticos.
Actualización de los entornos AWS Fargate informáticos
Para los entornos de computación que utilizan recursos de Fargate, puede actualizar lo siguiente.
-
securityGroupIds
-
subnets
-
desiredvCpus
-
maxvCpus
-
minvCpus
AWS Batch tiene dos mecanismos de actualización. La primera es una actualización de escalado en la que se añaden o se borran instancias del entorno de computación. La segunda es una actualización de infraestructura en la que se sustituyen las instancias del entorno de computación. Una actualización de infraestructura lleva mucho más tiempo que una actualización de escalado.
Si actualiza los entornos de cómputo con AWS Batch, al cambiar solo estos ajustes, se produce una actualización de escalado: el v CPUs deseado, el v máximo CPUs (maxvCpus
), el mínimo v CPUs (minvCpus
), el rol de servicio (serviceRole
) y el estado (state
). desiredvCpus
nota
Al actualizar la configuración de desiredvCpus
, el valor debe estar entre los valores minvCpus
y maxvCpus
.
Además, el valor actualizado de desiredvCpus
debe ser mayor o igual que el valor actual de desiredvCpus
. Para obtener más información, consulte Mensaje de error al actualizar la configuración de desiredvCpus.
Si se cambia alguna de las siguientes configuraciones en un UpdateComputeEnvironmentLa acción de la API AWS Batch inicia una actualización de la infraestructura. Una actualización de la infraestructura requiere que la función de servicio esté configurada en AWSServiceRoleForBatch(la opción predeterminada) y que la estrategia de asignación sea BEST_FIT_PROGRESSIVE
SPOT_CAPACITY_OPTIMIZED
, oSPOT_PRICE_CAPACITY_OPTIMIZED
. BEST_FIT
no se admite. A excepción del rol de servicio, todos los ajustes que se pueden cambiar para una actualización de escalado también se pueden cambiar para una actualización de infraestructura.
nota
Se recomienda utilizar SPOT_PRICE_CAPACITY_OPTIMIZED
en lugar de SPOT_CAPACITY_OPTIMIZED
en la mayoría de los casos.
Durante una actualización de infraestructura, el estado del entorno de computación cambia a UPDATING
. Las nuevas instancias se lanzan con la configuración actualizada. Los nuevos trabajos están programados en las nuevas instancias. Los trabajos que se están ejecutando actualmente se envían de acuerdo con la política de actualización de la infraestructura. Para obtener más información consulte UpdateComputeEnvironment y UpdatePolicy en la Referencia de la API de AWS Batch .
En el tipo de datos UpdatePolicy
, considere las siguientes situaciones:
nota
En estas situaciones, se aplica lo siguiente. Cuando se termina una instancia, se detienen los trabajos en ejecución. De forma predeterminada, estos trabajos no se vuelven a intentar. Para volver a intentar uno de estos trabajos una vez finalizada una instancia, configura una estrategia de reintento de trabajo. Para obtener más información, consulte Reintentos automáticos de trabajo en la Guía del usuario de AWS Batch .
-
Si la configuración
terminateJobsOnUpdate
está establecida entrue
, los trabajos en ejecución finalizarán durante una actualización de la infraestructura. La configuraciónjobExecutionTimeoutMinutes
se omite. -
Si la configuración
terminateJobsOnUpdate
está establecida enfalse
, los trabajos se pueden ejecutar durante más tiempo después de que se haya realizado la actualización de la infraestructura. Este tiempo adicional se configura en la configuraciónjobExecutionTimeoutMinutes
. De forma predeterminada, la configuración dejobExecutionTimeoutMinutes
es 30 minutos.
A medida que se dispone de capacidad en el entorno de computación, se lanzan nuevas instancias con la configuración actualizada y se inician los trabajos en las nuevas instancias. A medida que se completan todos los trabajos en las instancias con la configuración anterior, las instancias antiguas se cancelan. Lo que significa que la capacidad disponible significa que el número deseado de v CPUs está CPUs por debajo del número máximo de v al menos en la misma cantidad de v CPUs que requiere el tipo de instancia más pequeño.
Actualizaciones de la infraestructura
Es necesaria una actualización de la infraestructura para cambiar algunos ajustes de un entorno de computación. Si se cambia alguna de las siguientes configuraciones, se inicia una actualización de la infraestructura:
importante
El entorno informático debe utilizar la función AWSServiceRoleForBatchvinculada al servicio para realizar cambios que requieran una actualización de la infraestructura.
Si el entorno de cómputo usa un rol vinculado a un servicio, no se puede cambiar para usar un rol de IAM normal. Del mismo modo, si el entorno de cómputo tiene un rol de IAM normal, no se puede cambiar para usar un rol vinculado a un servicio. Por lo tanto, solo puede realizar actualizaciones de infraestructura en entornos de computación que se hayan creado mediante un rol vinculado a un servicio.
-
La estrategia de asignación (
allocationStrategy
, debe serBEST_FIT_PROGRESSIVE
,SPOT_CAPACITY_OPTIMIZED
, oSPOT_PRICE_CAPACITY_OPTIMIZED
. Si la estrategia de asignación original esBEST_FIT
, no se admiten las actualizaciones de infraestructura).nota
Se recomienda utilizar
SPOT_PRICE_CAPACITY_OPTIMIZED
en lugar deSPOT_CAPACITY_OPTIMIZED
en la mayoría de los casos. -
Porcentaje de oferta (
bidPercentage
) -
EC2 configuración ()
ec2Configuration
-
Par de claves (
ec2KeyPair
) -
ID de imagen (
imageId
) -
Rol de instancia (
instanceRole
) -
Tipos de instancias (
instanceTypes
) -
Plantilla de lanzamiento (
launchTemplate
) -
Grupo de ubicación (
placementGroup
) -
Grupos de seguridad (
securityGroupIds
) -
Subredes de la VPC (
subnets
) -
EC2 etiquetas (
tags
) -
Tipo de entorno de computación (
type
, puede ser uno deEC2
oSPOT
) -
Si se debe actualizar a la AMI más reciente compatible AWS Batch durante una actualización de infraestructura
updateToLatestImageVersion
Actualización del ID de la AMI
Durante una actualización de infraestructura, el ID de AMI del entorno informático puede cambiar en función de si AMIs se especifica en alguna de estas tres configuraciones. AMIs se especifican en la plantilla imageId
(incomputeResources
), imageIdOverride
(inec2Configuration
) o de lanzamiento especificada enlaunchTemplate
. Supongamos que no IDs se especifica ninguna AMI en ninguna de esas configuraciones y que la updateToLatestImageVersion
configuración estrue
. A continuación, la última AMI optimizada para Amazon ECS compatible con AWS Batch se utiliza para cualquier actualización de infraestructura.
Si se especifica una ID de AMI en al menos una de estas configuraciones, la actualización depende de la configuración proporcionada por la ID de AMI utilizada antes de la actualización. Al crear un entorno de computación, la prioridad a la hora de seleccionar un ID de AMI es primero la plantilla de lanzamiento, después la configuración imageId
y, por último, la configuración imageIdOverride
. Sin embargo, si el ID de la AMI que se utiliza proviene de la plantilla de lanzamiento, al actualizar la configuración imageId
o imageIdOverride
, no se actualiza el ID de la AMI. La única forma de actualizar un ID de AMI seleccionado en la plantilla de lanzamiento es actualizar la plantilla de lanzamiento. Si el parámetro de versión de la plantilla de lanzamiento es $Default
o $Latest
, se evalúa la versión por defecto o la más reciente de la plantilla de lanzamiento especificada. Si se selecciona un ID de AMI diferente de forma predeterminada o se selecciona la última versión de la plantilla de lanzamiento, ese ID de AMI se utiliza en la actualización.
Si la plantilla de lanzamiento no se usó para seleccionar el ID de AMI, se usa el ID de AMI que se especifica en los parámetros imageId
o imageIdOverride
. Si se especifican ambos, se utiliza el ID de AMI especificado en el parámetro imageIdOverride
.
Supongamos que el entorno de computación utiliza un ID de AMI especificado por los parámetros imageId
, imageIdOverride
, o launchTemplate
, y usted desea utilizar la última AMI optimizada para Amazon ECS compatible con AWS Batch. A continuación, la actualización debe eliminar la configuración que proporcionaba la AMI IDs. Para imageId
, es necesario especificar una cadena vacía para ese parámetro. Para imageIdOverride
, es necesario especificar una cadena vacía para el parámetro de ec2Configuration
.
Si el ID de la AMI proviene de la plantilla de lanzamiento, puede cambiarlo AWS Batch por la última AMI optimizada para Amazon ECS que sea compatible con una de las siguientes formas:
-
Elimine la plantilla de lanzamiento especificando una cadena vacía para el parámetro
launchTemplateId
olaunchTemplateName
. Esto elimina toda la plantilla de lanzamiento, en lugar de solo el ID de la AMI. -
Si la versión actualizada de la plantilla de lanzamiento no especifica un ID de AMI, el parámetro
updateToLatestImageVersion
debe estar establecido entrue
.