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.
# Tareas
Los trabajos son la unidad de trabajo con la que se empieza. AWS Batch Los trabajos se pueden invocar como aplicaciones en contenedores que se ejecutan en instancias de contenedor de Amazon ECS dentro de un clúster de ECS.
Los trabajos en contenedores pueden hacer referencia a una imagen, comando o parámetros de contenedor. Para obtener más información, consulte [JobDefinition](https://docs.aws.amazon.com/batch/latest/APIReference/API_JobDefinition.html).
Puede enviar una gran cantidad de trabajos sencillos e independientes.
**Topics**
+ [
# Tutorial: envío de un trabajo
](submit_job.md)
+ [
# Trabajos de servicio en AWS Batch
](service-jobs.md)
+ [
# Estados de trabajo
](job_states.md)
+ [
# AWS Batch variables de entorno laboral
](job_env_vars.md)
+ [
# Reintentos automáticos de trabajo
](job_retries.md)
+ [
# Dependencias de trabajos
](job_dependencies.md)
+ [
# Tiempos de espera de trabajo
](job_timeouts.md)
+ [
# Trabajos de Amazon EKS
](eks-jobs.md)
+ [
# Trabajos paralelos de varios nodos
](multi-node-parallel-jobs.md)
+ [
# Trabajos paralelos de varios nodos en Amazon EKS
](mnp-eks-jobs.md)
+ [
# Trabajos de matrices
](array_jobs.md)
+ [
# Ejecución de trabajos de GPU
](gpu-jobs.md)
+ [
# Vea los AWS Batch trabajos en una cola de trabajos
](view-jobs.md)
+ [
# AWS Batch Busque trabajos en una cola de trabajos
](searching-filtering-jobs.md)
+ [
# Modos de red para AWS Batch trabajos
](networking-modes-jobs.md)
+ [
# Vea los registros de AWS Batch trabajos en CloudWatch los registros
](review-job-logs.md)
+ [
# Revise la información del AWS Batch trabajo
](review-job-info.md)
# Tutorial: envío de un trabajo
Después de registrar una definición de trabajo, puede enviarla como trabajo a una cola de AWS Batch trabajos. Muchos de los parámetros que se especifican en la definición de tareas pueden ignorarse en tiempo de ejecución.
**Envío de un trabajo**
1. Abra la AWS Batch consola en. [https://console.aws.amazon.com/batch/](https://console.aws.amazon.com/batch/)
1. En la barra de navegación, seleccione la Región de AWS que desee utilizar.
1. En el panel de navegación, seleccione **Trabajos**.
1. Seleccione **Enviar el trabajo**.
1. En **Nombre**, escriba un nombre único para la definición de trabajo. El nombre puede tener una longitud máxima de 128 caracteres. Puede contener letras mayúsculas y minúsculas, números, guiones (-) y guiones bajos (\$1).
1. En **Definición de trabajo**, seleccione una definición de trabajo creada anteriormente. Para obtener más información, consulte [Creación de una definición de trabajo de un solo nodo](create-job-definition.md).
1. En **Cola de trabajos**, elija una cola de trabajos existente. Para obtener más información, consulte [Creación de una cola de trabajos](create-job-queue.md).
1. En **Dependencias de trabajos**, elija **Añadir dependencias de trabajos**.
1. En **ID de trabajo**, introduzca el ID de trabajo de cualquier dependencia. A continuación, seleccione **Añadir dependencias de trabajos**. Un trabajo puede tener hasta 20 dependencias. Para obtener más información, consulte [Dependencias de trabajos](job_dependencies.md).
1. (Solo trabajos de matrices) En **Tamaño de matriz**, especifique un tamaño de matriz comprendido entre 2 y 10 000.
1. (Opcional) Amplíe **Etiquetas** y, a continuación, elija **Agregar etiqueta** para agregar etiquetas al recurso. Elija **Agregar nueva etiqueta** e introduzca la clave y el valor opcional.
1. Seleccione **Página siguiente**.
1. En la sección **Anulaciones de trabajos**:
1.
(Opcional) En **Prioridad de programación**, introduzca un valor de prioridad de programación entre 0 y 100. Los valores más altos tienen mayor prioridad.
1. (Opcional) En **Intentos de trabajo**, introduzca el número máximo de veces que AWS Batch intenta mover el trabajo a un estado `RUNNABLE`. Puede especificar un número comprendido entre 1 y 10. Para obtener más información, consulte [Reintentos automáticos de trabajo](job_retries.md).
1. (Opcional) En **Tiempo de espera de ejecución**, introduzca el valor del tiempo de espera (en segundos). El tiempo de espera de ejecución es el tiempo que transcurre antes de que finalice un trabajo pendiente. Si un intento supera el tiempo de espera, se detiene y el estado cambia a `FAILED`. Para obtener más información, consulte [Tiempos de espera de trabajo](job_timeouts.md). El valor mínimo es de 60 segundos.
**importante**
No confíe en que los trabajos que se ejecuten con los recursos de Fargate duren más de 14 días. Después de 14 días, es posible que los recursos de Fargate ya no estén disponibles y es probable que el trabajo se finalice.
1. (Opcional) Active **Propagar etiquetas** para propagar etiquetas desde el trabajo y la definición del trabajo a la tarea de Amazon ECS.
1. Expanda **Configuración adicional**.
1. (Opcional) Para las **Condiciones de la estrategia de reintento**, seleccione **Agregar evaluación al salir**. Introduzca al menos un valor de parámetro y, a continuación, elija una **Acción**. Para cada conjunto de condiciones, la **Acción** debe estar configurada como **Reintentar** o **Salir**. Estas acciones significan lo siguiente:
+ **Reintentar**: AWS Batch se vuelve a intentar hasta alcanzar el número de intentos de trabajo que especificó.
+ **Salir**: AWS Batch deja de volver a intentar el trabajo.
**importante**
Si elige **Añadir evaluación al salir**, configure al menos un parámetro y elija una **Acción** o elija **Eliminar evaluación al salir**.
1. En **Parámetros**, seleccione **Añadir parámetros** para añadir marcadores de sustitución de parámetros. Ingrese una **clave** y un **valor** opcional.
1. En la sección **Anulaciones de contenedores**:
1. En **Comando**, ingrese los comandos en el campo como su equivalente de matriz de cadenas **JSON**.
Este parámetro se asigna a `Cmd` en la sección [Creación de un contenedor](https://docs.docker.com/engine/api/v1.38/#operation/ContainerCreate) de la [API remota de Docker](https://docs.docker.com/engine/api/v1.38/) y el parámetro `COMMAND` se corresponde con [https://docs.docker.com/engine/reference/commandline/run/](https://docs.docker.com/engine/reference/commandline/run/). Para obtener más información sobre el `CMD` parámetro de Docker, consulte [https://docs.docker.com/engine/reference/builder/](https://docs.docker.com/engine/reference/builder/#cmd) \$1cmd.
**nota**
Este parámetro no puede contener una cadena vacía.
1. Para **v CPUs**, introduce el número de v CPUs que deseas reservar para el contenedor. Este parámetro se corresponde con `CpuShares` en la sección [Creación de un contenedor](https://docs.docker.com/engine/api/v1.38/#operation/ContainerCreate) de la [API remota de Docker](https://docs.docker.com/engine/api/v1.38/) y con la opción `--cpu-shares` de [https://docs.docker.com/engine/reference/commandline/run/](https://docs.docker.com/engine/reference/commandline/run/). Cada vCPU es equivalente a 1 024 cuotas de CPU. Debe especificar al menos una vCPU.
1. En **Memoria**, introduzca el límite de memoria disponible para el contenedor. Si su contenedor intenta superar la memoria especificada aquí, el contenedor se detiene. Este parámetro se corresponde con `Memory` en la sección [Creación de un contenedor](https://docs.docker.com/engine/api/v1.38/#operation/ContainerCreate) de la [API remota de Docker](https://docs.docker.com/engine/api/v1.38/) y con la opción `--memory` de [https://docs.docker.com/engine/reference/commandline/run/](https://docs.docker.com/engine/reference/commandline/run/). Debe especificar al menos 4 MiB de memoria para un trabajo.
**nota**
Para maximizar el uso de los recursos, priorice la memoria para los trabajos de un tipo de instancia específico. Para obtener más información, consulte [Administración de la memoria de recurso de computación](memory-management.md).
1. (Opcional) En **Número de GPUs**, elija el número de GPUs que desea reservar para el contenedor.
1. (Opcional) En el caso de **Variables de entorno**, seleccione **Agregar variable de entorno** para añadir variables de entorno como pares de nombre-valor. Estas variables se transfieren al contenedor.
1. Seleccione **Página siguiente**.
1. En **Revisión del trabajo**, revise los pasos de configuración. Si necesita realizar cambios, elija **Editar**. Cuando haya terminado, seleccione **Creación de definición de trabajo**.
# Trabajos de servicio en AWS Batch
AWS Batch los trabajos de servicio le permiten enviar solicitudes a AWS los servicios a través de colas de AWS Batch trabajos. Actualmente, AWS Batch admite trabajos SageMaker de formación como trabajos de servicio. A diferencia de los trabajos contenerizados, en los que se AWS Batch gestiona la ejecución subyacente del contenedor, los trabajos de servicio AWS Batch permiten programar los trabajos y hacer colas, mientras que el AWS servicio objetivo (como la SageMaker IA) se encarga de la ejecución real de los trabajos.
AWS Batch for SageMaker Training Jobs permite a los científicos de datos enviar los trabajos de formación con prioridades a colas configurables, lo que garantiza que las cargas de trabajo se ejecuten sin intervención en cuanto los recursos estén disponibles. Esta capacidad aborda desafíos comunes, como la coordinación de los recursos, la prevención de gastos excesivos accidentales, el cumplimiento de las restricciones presupuestarias, la optimización de los costos con instancias reservadas y la eliminación de la necesidad de coordinación manual entre los miembros del equipo.
Los trabajos de servicio se diferencian de los trabajos contenerizados en varios aspectos clave:
+ **Envío de trabajos**: los trabajos de servicio deben enviarse mediante la [SubmitServiceJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitServiceJob.html)API. Los trabajos de servicio no se pueden enviar a través de la consola de AWS Batch .
+ **Ejecución de trabajos**: AWS Batch programa y pone en cola los trabajos de servicio, pero el AWS servicio de destino ejecuta la carga de trabajo real.
+ **Identificadores de recursos: los** trabajos de servicio utilizan la ARNs palabra «trabajo de servicio» en lugar de «trabajo» para distinguirlos de los trabajos en contenedores.
Para empezar a utilizar los trabajos de AWS Batch servicio de formación, consulte. SageMaker [Primeros pasos con AWS Batch la SageMaker IA](getting-started-sagemaker.md)
**Topics**
+ [
# Cargas útiles de trabajos de servicio en AWS Batch
](service-job-payload.md)
+ [
# Envíe un trabajo de servicio en AWS Batch
](service-job-submit.md)
+ [
# Asignar el estado del trabajo del AWS Batch servicio al estado de la SageMaker IA
](service-job-status.md)
+ [
# Estrategias de reintento de trabajos de servicio en AWS Batch
](service-job-retries.md)
+ [
# Supervise los trabajos de servicio en una cola AWS Batch
](monitor-sagemaker-job-queue.md)
+ [
# Finalización de los trabajos de servicio
](terminate-service-jobs.md)
# Cargas útiles de trabajos de servicio en AWS Batch
Cuando envía trabajos de servicio utilizando [SubmitServiceJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitServiceJob.html), proporciona dos parámetros clave que definen el trabajo:`serviceJobType`, y`serviceRequestPayload`.
+ `serviceJobType`Especifica qué AWS servicio ejecutará el trabajo. Para los trabajos de SageMaker formación, este valor es`SAGEMAKER_TRAINING`.
+ `serviceRequestPayload` es una cadena codificada en JSON que contiene la solicitud completa que normalmente se envía directamente al servicio de destino. Para los trabajos de SageMaker formación, esta carga útil contiene los mismos parámetros que utilizaría con la [CreateTrainingJob](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateTrainingJob.html)API de SageMaker IA.
Para obtener una lista completa de todos los parámetros disponibles y sus descripciones, consulta la referencia de la [CreateTrainingJob](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateTrainingJob.html)API de SageMaker IA. Todos los parámetros que sean compatibles con `CreateTrainingJob` se pueden incluir en la carga útil del trabajo de servicio.
Para ver más ejemplos de configuraciones de trabajos de formación [APIs, consulte la CLI y SDKs](https://docs.aws.amazon.com/sagemaker/latest/dg/api-and-sdk-reference-overview.html) la [Guía para desarrolladores de SageMaker IA](https://docs.aws.amazon.com/sagemaker/latest/dg/gs.html).
Recomendamos utilizar PySDK para la creación de trabajos de servicio, ya que PySDK tiene clases y utilidades auxiliares. Para ver un ejemplo del uso de PySDK, consulta los [ejemplos de SageMaker IA](https://github.com/aws/amazon-sagemaker-examples) en GitHub.
## Ejemplo de carga útil de un trabajo de servicio
El siguiente ejemplo muestra una carga útil de trabajo de servicio sencilla para un trabajo de SageMaker formación que ejecuta un guion de formación que dice «hola mundo»:
Esta carga útil se pasará como una cadena JSON al parámetro `serviceRequestPayload` cuando se llame `SubmitServiceJob`.
```
{
"TrainingJobName": "my-simple-training-job",
"RoleArn": "arn:aws:iam::123456789012:role/SageMakerExecutionRole",
"AlgorithmSpecification": {
"TrainingInputMode": "File",
"TrainingImage": "763104351884.dkr.ecr.us-west-2.amazonaws.com/pytorch-training:2.0.0-cpu-py310",
"ContainerEntrypoint": [
"echo",
"hello world"
]
},
"ResourceConfig": {
"InstanceType": "ml.c5.xlarge",
"InstanceCount": 1,
"VolumeSizeInGB": 1
},
"OutputDataConfig": {
"S3OutputPath": "s3://your-output-bucket/output"
},
"StoppingCondition": {
"MaxRuntimeInSeconds": 30
}
}
```
# Envíe un trabajo de servicio en AWS Batch
Para enviar trabajos de servicio a AWS Batch, usa la [SubmitServiceJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitServiceJob.html)API. Puede enviar trabajos mediante el SDK AWS CLI o el SDK.
Si aún no tiene un rol de ejecución, debe crear uno antes de enviar el trabajo de servicio. Para crear la función de ejecución de SageMaker IA, consulte [Cómo utilizar las funciones de ejecución de SageMaker IA](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-roles.html) en la *[guía para desarrolladores de SageMaker IA](https://docs.aws.amazon.com/sagemaker/latest/dg/whatis.html)*.
## Flujo de trabajo para el envío del trabajo de servicio
Cuando envíes un trabajo de servicio, AWS Batch sigue este flujo de trabajo:
1. AWS Batch recibe su `[SubmitServiceJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitServiceJob.html)` solicitud y valida los parámetros AWS Batch específicos. `serviceRequestPayload` se pasa sin validación.
1. El trabajo entra en el estado `SUBMITTED` y se coloca en la cola de trabajos especificada
1. AWS Batch evalúa si hay capacidad disponible en el entorno de servicio para los `RUNNABLE` trabajos que se encuentran al principio de la cola
1. Si hay capacidad disponible, el trabajo se traslada a AI `SCHEDULED` y se ha transferido a AI SageMaker
1. Cuando se haya adquirido capacidad y la SageMaker IA haya descargado los datos del trabajo de servicio, el trabajo de servicio comenzará a inicializarse y el trabajo cambiará a`STARTING`.
1. Cuando la SageMaker IA comience a ejecutar el trabajo, su estado cambiará a`RUNNING`.
1. Mientras la SageMaker IA ejecuta la tarea, AWS Batch supervisa su progreso y asigna los estados del servicio a los estados de las AWS Batch tareas. Para obtener más información sobre cómo se asignan los estados de las tareas de servicio, consulte [Asignar el estado del trabajo del AWS Batch servicio al estado de la SageMaker IA](service-job-status.md).
1. Cuando se completa el trabajo de servicio, pasa a `SUCCEEDED` y cualquier salida estará lista para descargarse.
## Requisitos previos
Antes de enviar un trabajo de servicio, asegúrese de disponer de lo siguiente:
+ **Entorno de servicio**: entorno de servicio que define los límites de capacidad. Para obtener más información, consulte [Cree un entorno de servicios en AWS Batch](create-service-environments.md).
+ **SageMaker cola de trabajos: cola** de SageMaker trabajos que permite programar los trabajos. Para obtener más información, consulte [Creación de una cola de trabajos de entrenamiento de SageMaker en AWS Batch](create-sagemaker-job-queue.md).
+ **Permisos de IAM**: permisos para crear y administrar colas de trabajos y entornos de servicio de AWS Batch . Para obtener más información, consulte [AWS Batch Políticas, funciones y permisos de IAM](IAM_policies.md).
## Envíe un trabajo de servicio con la AWS CLI
A continuación, se muestra cómo enviar un trabajo de servicio mediante la AWS CLI:
```
aws batch submit-service-job \
--job-name "my-sagemaker-training-job" \
--job-queue "my-sagemaker-job-queue" \
--service-job-type "SAGEMAKER_TRAINING" \
--service-request-payload '{\"TrainingJobName\": \"sagemaker-training-job-example\", \"AlgorithmSpecification\": {\"TrainingImage\": \"123456789012.dkr.ecr.us-east-1.amazonaws.com/pytorch-inference:1.8.0-cpu-py3\", \"TrainingInputMode\": \"File\", \"ContainerEntrypoint\": [\"sleep\", \"1\"]}, \"RoleArn\":\"arn:aws:iam::123456789012:role/SageMakerExecutionRole\", \"OutputDataConfig\": {\"S3OutputPath\": \"s3://example-bucket/model-output/\"}, \"ResourceConfig\": {\"InstanceType\": \"ml.m5.large\", \"InstanceCount\": 1, \"VolumeSizeInGB\": 1}}'
--client-token "unique-token-12345"
```
Para obtener más información acerca de los parámetros `serviceRequestPayload`, consulte [Cargas útiles de trabajos de servicio en AWS Batch](service-job-payload.md).
# Asignar el estado del trabajo del AWS Batch servicio al estado de la SageMaker IA
Al enviar trabajos a una cola de SageMaker trabajos utilizando [SubmitServiceJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitServiceJob.html), AWS Batch gestiona el ciclo de vida de los trabajos y asigna los estados de los AWS Batch [trabajos a estados](job_states.md) de trabajo de SageMaker formación equivalentes. Los trabajos de servicio, como los de SageMaker formación, siguen un ciclo de vida estatal diferente al de los trabajos en contenedores tradicionales. Así como los trabajos de servicio comparten la mayoría de los estados con los trabajos de contenedores, también presentan el estado de `SCHEDULED` y muestran diferentes comportamientos de reintento, sobre todo al momento de gestionar errores de capacidad insuficiente del servicio de destino.
La siguiente tabla muestra el estado del AWS Batch trabajo y el SageMaker estado/ correspondiente: SecondaryStatus
| Estado del lote | SageMaker Estado principal de la IA | SageMaker Estado secundario de IA | Description (Descripción) |
| --- | --- | --- | --- |
| SUBMITTED | N/A | N/A | Trabajo enviado a la cola, a la espera de la evaluación del programador. |
| RUNNABLE | N/A | N/A | El trabajo está en cola y listo para su programación. Los trabajos en este estado se inician tan pronto como haya suficientes recursos disponibles en el entorno de servicio. Los trabajos pueden permanecer en este estado de forma indefinida si los recursos suficientes no están disponibles. |
| SCHEDULED | InProgress | Pending | El trabajo de servicio se envió correctamente a SageMaker AI |
| STARTING | InProgress | Downloading | SageMaker Trabajo de formación descargando datos e imágenes. Se adquirió la capacidad de trabajo de entrenamiento y comienza la inicialización del trabajo. |
| RUNNING | InProgress | Training | SageMaker Algoritmo de ejecución de tareas de entrenamiento |
| RUNNING | InProgress | Uploading | SageMaker Trabajo de entrenamiento cargando artefactos de salida después de completar el entrenamiento |
| SUCCEEDED | Completed | Completed | SageMaker El trabajo de formación se completó correctamente. Los artefactos de salida terminaron de cargarse. |
| FAILED | Failed | Failed | SageMaker El trabajo de formación detectó un error irrecuperable. |
| FAILED | Stopped | Stopped | SageMaker El trabajo de entrenamiento se dejó de utilizar manualmente. StopTrainingJob |
# Estrategias de reintento de trabajos de servicio en AWS Batch
Las estrategias de reintento de trabajos de servicio permiten AWS Batch reintentar automáticamente los trabajos de servicio fallidos en condiciones específicas.
Los trabajos de servicio pueden requerir varios intentos por diversos motivos:
+ **Problemas de servicio temporales**: los errores de servicio internos, las limitaciones o las interrupciones temporales pueden provocar que los trabajos fallen durante el envío o la ejecución.
+ **Fallos en la inicialización del entrenamiento**: los problemas durante el inicio del trabajo, como los problemas de extracción de imágenes o los errores de inicialización, pueden resolverse intentándolo de nuevo.
Con la configuración de las estrategias de reintentos adecuadas, se mejoran las tasas de éxito en el trabajo y se reduce la necesidad de intervención manual, especialmente en el caso de las cargas de trabajo de formación prolongadas.
**nota**
Los trabajos de servicio reintentan automáticamente ciertos tipos de errores, como los de capacidad insuficiente, sin consumir los reintentos configurados. La estrategia de reintentos se ocupa principalmente de otros tipos de errores, como los errores de algoritmo o los problemas de servicio.
## Configuración de estrategias de reintento
Las estrategias de reintentos de los trabajos de servicio se configuran mediante [ServiceJobRetryStrategy](https://docs.aws.amazon.com/batch/latest/APIReference/API_ServiceJobRetryStrategy.html), lo que admite tanto el recuento simple de reintentos como la lógica de reintentos condicional.
### Configuración de reintentos
La estrategia de reintentos más sencilla especifica el número de reintentos que se deben realizar si se produce un error en un trabajo de servicio:
```
{
"retryStrategy": {
"attempts": 3
}
}
```
Esta configuración permite volver a intentar el trabajo de servicio hasta 3 veces si se produce un error.
**importante**
El valor `attempts` representa la cantidad total de veces que se puede colocar el trabajo en el estado `RUNNABLE`, como el intento inicial. Un valor de 3 significa que, al principio, se intentará realizar el trabajo una vez y, si se produce un error, se volverá a intentar hasta 2 veces más.
### Vuelva a intentar la configuración con evaluateOnExit
Puede utilizar el parámetro `evaluateOnExit` para especificar las condiciones en las que se deben volver a intentar los trabajos o permitir que fallen. Esto resulta útil cuando distintos tipos de errores requieren un tratamiento diferente.
La matriz `evaluateOnExit` puede contener hasta 5 estrategias de reintento, cada una de las cuales especifica una acción (`RETRY` o `EXIT`) y condiciones según los motivos del estado:
```
{
"retryStrategy": {
"attempts": 5,
"evaluateOnExit": [
{
"action": "RETRY",
"onStatusReason": "Received status from SageMaker: InternalServerError*"
},
{
"action": "EXIT",
"onStatusReason": "Received status from SageMaker: ValidationException*"
},
{
"action": "EXIT",
"onStatusReason": "*"
}
]
}
}
```
Esta configuración:
+ Vuelve a intentar los trabajos que fallan debido a errores internos del servidor de la SageMaker IA
+ marca como fallidos los trabajos de forma inmediata que encuentran excepciones de validación (errores del cliente que no se resuelven mediante reintentos),
+ incluye una regla general para la salida en caso de cualquier otro tipo de fallo.
#### Patrón de coincidencias de motivos de estado
El parámetro `onStatusReason` admite el patrón de coincidencias con hasta 512 caracteres. Los patrones pueden usar caracteres comodín (\$1) y coincidir con los motivos de estado devueltos por SageMaker la IA.
En el caso de los trabajos de servicio, los mensajes de estado de la SageMaker IA llevan el prefijo «Estado recibido de SageMaker:» para distinguirlos de los mensajes generados por la AWS Batch IA. Los patrones comunes incluyen lo siguiente:
+ `Received status from SageMaker: InternalServerError*`: Coincide con errores internos del servicio
+ `Received status from SageMaker: ValidationException*`: Coincide con errores de validación del cliente
+ `Received status from SageMaker: ResourceLimitExceeded*`: Coincide con errores del límite de recursos
+ `*CapacityError*`: Coincide con los fallos relacionados con la capacidad
**sugerencia**
Utilice una coincidencia de patrones específica para gestionar los diferentes tipos de errores de forma adecuada. Por ejemplo, reintentar los errores internos del servidor, pero fallar inmediatamente si se trata de errores de validación que indiquen problemas con los parámetros del trabajo.
# Supervise los trabajos de servicio en una cola AWS Batch
Puede supervisar el estado de los trabajos de su cola de trabajos de SageMaker formación utilizando`list-service-jobs`, y`get-job-queue-snapshot`.
Cómo ver los trabajos en ejecución en la cola:
```
aws batch list-service-jobs \
--job-queue my-sm-training-fifo-jq \
--job-status RUNNING
```
Cómo ver los trabajos en espera en la cola:
```
aws batch list-service-jobs \
--job-queue my-sm-training-fifo-jq \
--job-status RUNNABLE
```
Vea los trabajos que se han enviado SageMaker pero que aún no están en ejecución:
```
aws batch list-service-jobs \
--job-queue my-sm-training-fifo-jq \
--job-status SCHEDULED
```
Cómo obtener una instantánea de los trabajos que están al comienzo de su lista:
```
aws batch get-job-queue-snapshot --job-queue my-sm-training-fifo-jq
```
Este comando muestra el orden de los próximos trabajos de servicio en la cola.
## Obtención de información detallada sobre el trabajo de servicio
Utilice la operación [https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeServiceJob.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeServiceJob.html) para obtener información completa sobre un trabajo de servicio específico, como su estado actual, los identificadores de recursos de servicio y la información detallada sobre los intentos.
Cómo ver la información detallada sobre un trabajo específico:
```
aws batch describe-service-job \
--job-id a4d6c728-8ee8-4c65-8e2a-9a5e8f4b7c3d
```
Este comando devuelve información completa sobre el trabajo, como:
+ el ARN del trabajo y estado actual,
+ Identificadores de recursos de servicio (como el ARN del trabajo de SageMaker formación)
+ la configuración de la prioridad de programación y reintentos,
+ la carga útil de solicitud de servicio que contiene los parámetros de servicio originales,
+ la información detallada sobre los intentos con las horas de inicio y finalización,
+ los mensajes de estado del servicio de destino.
## SageMaker Supervise los trabajos de formación
Al supervisar los trabajos de SageMaker formación AWS Batch, puede acceder tanto a la información del AWS Batch puesto como a los detalles subyacentes del puesto de SageMaker formación.
El identificador de recursos de servicio en los detalles del trabajo contiene el ARN del trabajo de SageMaker formación:
```
{
"latestAttempt": {
"serviceResourceId": {
"name": "TrainingJobArn",
"value": "arn:aws:sagemaker:us-east-1:123456789012:training-job/my-training-job"
}
}
}
```
Puedes usar este ARN para obtener detalles adicionales directamente de: SageMaker
```
aws sagemaker describe-training-job \
--training-job-name my-training-job
```
Supervise el progreso del trabajo comprobando tanto AWS Batch el estado como el estado del trabajo de SageMaker formación. El estado del AWS Batch puesto muestra el ciclo de vida general del trabajo, mientras que el estado del puesto de SageMaker formación proporciona detalles específicos del servicio sobre el proceso de formación.
# Finalización de los trabajos de servicio
Utilice la operación [https://docs.aws.amazon.com/batch/latest/APIReference/API_TerminateServiceJob.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_TerminateServiceJob.html) para detener un trabajo de servicio en ejecución.
Cómo finalizar un trabajo de servicio específico:
```
aws batch terminate-service-job \
--job-id a4d6c728-8ee8-4c65-8e2a-9a5e8f4b7c3d \
--reason "Job terminated by user request"
```
Cuando se termina un trabajo de servicio, AWS Batch se detiene el trabajo y se lo notifica al servicio de destino. En el SageMaker caso de los trabajos de formación, esto también detendrá el trabajo de formación en SageMaker IA.
# Estados de trabajo
Al enviar un trabajo a una cola de trabajos, el AWS Batch trabajo entra en ese estado. `SUBMITTED` A continuación, pasa por los estados siguientes hasta que termina de ejecutarse correctamente (finaliza con el código `0`) o no (finaliza con un código distinto de cero). Los trabajos de AWS Batch pueden tener los siguientes estados:
`SUBMITTED`
Un trabajo que se ha enviado a la cola, y que aún no ha sido evaluado por el programador. El programador evalúa el trabajo para determinar si tiene alguna dependencia pendiente de la correcta finalización de cualquier otro trabajo. Si hay dependencias, el trabajo pasa a `PENDING`. Si no hay dependencias, el trabajo pasa a `RUNNABLE`.
`PENDING`
Un trabajo que está en la cola y que aún no se ha podido ejecutar debido a una dependencia de otro trabajo o recurso. Una vez se cumplan las dependencias, el trabajo pasa a `RUNNABLE`.
Los padres de los trabajos de matriz se actualizan `PENDING` cuando se actualiza un trabajo secundario `RUNNABLE` y permanecen en `PENDING` su estado mientras los trabajos secundarios se están ejecutando. Para ver estos trabajos, filtre por `PENDING` estado hasta que todos los trabajos secundarios alcancen un estado terminal.
`RUNNABLE`
Un trabajo que está en la cola, que no tiene dependencias pendientes y, por tanto, que está listo para ser programado para un host. Los trabajos en este estado se inician tan pronto como haya recursos suficientes disponibles en alguno de los entornos de computación que se asignan a la cola del trabajo. Sin embargo, un trabajo puede permanecer en este estado de forma indefinida si los recursos suficientes no están disponibles.
Si los trabajos no progresan a `STARTING`, consulte [Trabajos bloqueados en estado `RUNNABLE`](job_stuck_in_runnable.md) en la sección de resolución de problemas.
`STARTING`
Estos trabajos se han programado para un host y las operaciones de inicio de contenedor pertinentes están en curso. Después de que la imagen de contenedor se extraiga y el contenedor esté en marcha, el trabajo pasa a `RUNNING`.
La duración de la extracción de imágenes, de la finalización de Amazon EKS InitContainer y de la resolución de Amazon ECS ContainerDependency ocurren con el estado STARTING. El tiempo que se tarda en extraer una imagen para un trabajo equivale al tiempo que el trabajo mostrará el estado STARTING.
Por ejemplo, si se tardan tres minutos en extraer la imagen de un trabajo, este mostrará el estado STARTING durante tres minutos. Si initContainers tarda un total de diez minutos en completarse, el trabajo de Amazon EKS mostrará STARTING durante diez minutos. Si tiene conjuntos containerDependencies de Amazon ECS en un trabajo de Amazon ECS, este mostrará STARTING hasta que se resuelvan todas las dependencias de contenedor (tiempo de ejecución). STARTING no está incluido en los tiempos de espera; la duración comienza cuando se ejecuta. Para obtener más información, consulte [Estados de trabajo](https://docs.aws.amazon.com/batch/latest/userguide/job_states.html).
`RUNNING`
El trabajo se ejecuta como un trabajo de contenedor en una instancia de contenedor de Amazon ECS dentro de un entorno de computación. Cuando el contenedor del trabajo se cierra, el código del proceso de salida determina si el trabajo ha finalizado correctamente o si ha fallado. Un código de salida `0` indica una correcta ejecución y cualquier código de salida distinto de cero indica error. Si al trabajo asociado a un intento fallido le quedan intentos en su configuración de estrategia de reintento opcional, el trabajo vuelve a pasar al estado `RUNNABLE`. Para obtener más información, consulte [Reintentos automáticos de trabajo](job_retries.md).
Los registros de los `RUNNING` trabajos están disponibles en CloudWatch Registros. El grupo de registros es `/aws/batch/job`, y el formato del nombre del flujo de registro es el siguiente: `first200CharsOfJobDefinitionName/default/ecs_task_id`. Sin embargo, esto puede cambiar en el futuro.
Cuando un trabajo alcanza el `RUNNING` estado, puedes recuperar mediante programación su nombre de flujo de registro con la operación de la [DescribeJobs](https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeJobs.html)API. Para obtener más información, consulte [Ver los datos de registro enviados a CloudWatch los registros](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#ViewingLogData) en la *Guía del usuario de Amazon CloudWatch Logs*. De forma predeterminada, estos registros nunca caducan. Puede modificar el periodo de retención de copia de seguridad. Para obtener más información, consulte [Cambiar la retención de datos de registro en CloudWatch los registros](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SettingLogRetention.html) en la *Guía del usuario de Amazon CloudWatch Logs*.
`SUCCEEDED`
El trabajo se ha completado correctamente con un código de salida `0`. El estado de los `SUCCEEDED` trabajos se mantiene AWS Batch durante al menos 7 días.
Los registros de los `SUCCEEDED` trabajos están disponibles en CloudWatch Registros. El grupo de registros es `/aws/batch/job`, y el formato del nombre del flujo de registro es el siguiente: `first200CharsOfJobDefinitionName/default/ecs_task_id`. Este formato puede cambiar en el futuro.
Cuando un trabajo alcanza el `RUNNING` estado, puedes recuperar mediante programación su nombre de flujo de registro con la operación de la [DescribeJobs](https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeJobs.html)API. Para obtener más información, consulte [Ver los datos de registro enviados a CloudWatch los registros](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#ViewingLogData) en la *Guía del usuario de Amazon CloudWatch Logs*. De forma predeterminada, estos registros nunca caducan. Puede modificar el periodo de retención de copia de seguridad. Para obtener más información, consulte [Cambiar la retención de datos de registro en CloudWatch los registros](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SettingLogRetention.html) en la *Guía del usuario de Amazon CloudWatch Logs*.
`FAILED`
El trabajo ha fallado en todos los intentos disponibles. El estado de trabajos `FAILED` persiste en AWS Batch durante al menos 7 días.
Los registros de los `FAILED` trabajos están disponibles en CloudWatch Logs. El grupo de registros es `/aws/batch/job`, y el formato del nombre del flujo de registro es el siguiente: `first200CharsOfJobDefinitionName/default/ecs_task_id`. Este formato puede cambiar en el futuro.
Una vez que un trabajo alcanza el `RUNNING` estado, puedes recuperar su flujo de registros mediante programación con la operación de la [DescribeJobs](https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeJobs.html)API. Para obtener más información, consulte [Ver los datos de registro enviados a CloudWatch los registros](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#ViewingLogData) en la *Guía del usuario de Amazon CloudWatch Logs*. De forma predeterminada, estos registros nunca caducan. Puede modificar el periodo de retención de copia de seguridad. Para obtener más información, consulte [Cambiar la retención de datos de registro en CloudWatch los registros](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SettingLogRetention.html) en la *Guía del usuario de Amazon CloudWatch Logs*.
# AWS Batch variables de entorno laboral
AWS Batch establece variables de entorno específicas en los trabajos de contenedores. Estas variables de entorno proporcionan una visión introspectiva de los contenedores que se encuentran dentro de los trabajos. Puede usar los valores de estas variables en la lógica de sus aplicaciones. Todas las variables que AWS Batch se configuran comienzan con el `AWS_BATCH_` prefijo. Se trata de un prefijo de variable de entorno protegido. No puede usar este prefijo para sus propias variables en las definiciones o anulaciones de trabajos.
Las variables de entorno siguientes están disponibles en los contenedores de trabajos:
`AWS_BATCH_CE_NAME`
Esta variable se establece en el nombre del entorno de computación en el que está situado el trabajo.
`AWS_BATCH_JOB_ARRAY_INDEX`
Esta variable solo se establece en los trabajos de matrices secundarios. El índice de trabajo de matriz empieza en 0, y cada trabajo secundario recibe un número de índice único. Por ejemplo, un trabajo de matriz con 10 elementos secundarios tiene valores de índice comprendidos entre 0 y 9. Puede utilizar este valor de índice para controlar la forma en la que se diferencian los elementos secundarios del trabajo de matriz. Para obtener más información, consulte [Uso del índice de trabajo de matriz para controlar la diferenciación de trabajos](array_index_example.md).
`AWS_BATCH_JOB_ARRAY_SIZE`
Esta variable se establece en el tamaño del trabajo de matriz principal. El tamaño del trabajo de matriz principal se pasa al trabajo de matriz secundario en esta variable.
`AWS_BATCH_JOB_ATTEMPT`
Esta variable se establece en el número de reintentos de trabajo. Al primer intento se le asigna el valor 1. Para obtener más información, consulte [Reintentos automáticos de trabajo](job_retries.md).
`AWS_BATCH_JOB_ID`
Esta variable se establece en el ID del AWS Batch trabajo.
`AWS_BATCH_JOB_KUBERNETES_NODE_UID`
Esta variable se establece como el UID de Kubernetes del objeto de nodo que se encuentra en el clúster de Kubernetes en el que se ejecuta el pod. Esta variable solo se establece para los trabajos que se ejecutan en los recursos de Amazon EKS. Para obtener más información, consulte [UIDs](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#uids) en la *documentación de Kubernetes*.
`AWS_BATCH_JOB_MAIN_NODE_INDEX`
Esta variable solo se establece en los trabajos paralelos de varios nodos. Esta variable se establece en el número de índice del nodo principal del trabajo. El código de la aplicación puede comparar `AWS_BATCH_JOB_MAIN_NODE_INDEX` con `AWS_BATCH_JOB_NODE_INDEX` en un nodo individual para determinar si es el nodo principal.
`AWS_BATCH_JOB_MAIN_NODE_PRIVATE_IPV4_ADDRESS`
Esta variable solo se establece en los trabajos paralelos de varios nodos. Esta variable no está presente en el nodo principal, pero está configurada en la IPv4 dirección privada del nodo principal del trabajo. El código de la aplicación del nodo secundario puede utilizar esta dirección para comunicarse con el nodo principal.
`AWS_BATCH_JOB_NODE_INDEX`
Esta variable solo se establece en los trabajos paralelos de varios nodos. Esta variable se establece en el número de índice del nodo. El índice del nodo comienza a partir de 0 y cada nodo recibe un número de índice único. Por ejemplo, un trabajo paralelo de varios nodos con 10 elementos secundarios tiene valores de índice comprendidos entre 0 y 9.
`AWS_BATCH_JOB_NUM_NODES`
Esta variable solo se establece en los trabajos paralelos de varios nodos. Esta variable se establece en el número de nodos solicitados para el trabajo en paralelo de varios nodos.
`AWS_BATCH_JQ_NAME`
Esta variable se establece en el nombre de la cola de trabajos a la que se ha enviado el trabajo.
# Reintentos automáticos de trabajo
Puede aplicar una estrategia de reintento a los trabajos y las definiciones de trabajo que permita reintentar automáticamente la ejecución de los trabajos con errores. Entre las posibles situaciones de error se incluyen:
+ Cualquier código de salida distinto de cero a partir de un trabajo de contenedor
+ Una finalización o error de la instancia de Amazon EC2
+ Error o AWS interrupción del servicio interno
El acto de enviar un trabajo a una cola de trabajos y que pase al estado `RUNNING` se considera un intento. De forma predeterminada, a cada trabajo se le concede un intento para pasar al estado `SUCCEEDED` o `FAILED`. Sin embargo, la definición de trabajo y los flujos de envíos de trabajo permiten especificar una estrategia de entre 1 y 10 reintentos. Si [evaluateOnExit](job_definition_parameters.md#retryStrategy-evaluateOnExit)se especifica, puede contener hasta 5 estrategias de reintentos. Si [evaluateOnExit](https://docs.aws.amazon.com/batch/latest/APIReference/API_EvaluateOnExit.html)se especifica, pero ninguna de las estrategias de reintento coincide, se vuelve a intentar el trabajo. En el caso de los trabajos que no coincidan con la salida, añada una última entrada que salga por cualquier motivo. Por ejemplo, este objeto `evaluateOnExit` tiene dos entradas con acciones de `RETRY` y una última entrada con una acción de `EXIT`.
```
"evaluateOnExit": [
{
"action": "RETRY",
"onReason": "AGENT"
},
{
"action": "RETRY",
"onStatusReason": "Task failed to start"
},
{
"action": "EXIT",
"onReason": "*"
}
]
```
En la ejecución, la variable de entorno `AWS_BATCH_JOB_ATTEMPT` se ajusta a la cantidad de reintentos de trabajo de contenedor correspondiente. Al primer intento se le asigna el `1`, y los intentos posteriores se enumeran en orden ascendente (por ejemplo, 2, 3, 4, etc.).
Por ejemplo, supongamos que un intento de trabajo falla por cualquier motivo y que el número de intentos especificado en la configuración de reintentos es superior al número de `AWS_BATCH_JOB_ATTEMPT`. A continuación, el trabajo se vuelve a colocar en el estado `RUNNABLE`. Para obtener más información, consulte [Estados de trabajo](job_states.md).
**nota**
Los trabajos que se cancelan o se terminan no se reintentan. De la misma manera, los trabajos que fallan debido a una definición de trabajo no válida tampoco se reintentan.
Para obtener más información, consulte [Estrategia de reintento](job_definition_parameters.md#retryStrategy), [Creación de una definición de trabajo de un solo nodo](create-job-definition.md), [Tutorial: envío de un trabajo](submit_job.md) y [ Códigos de error de tareas detenidas](https://docs.aws.amazon.com/AmazonECS/latest/userguide/stopped-task-error-codes.html).
# Dependencias de trabajos
Al enviar un AWS Batch trabajo, puede especificar el trabajo del IDs que depende. Al hacerlo, el AWS Batch programador se asegura de que el trabajo se ejecute solo después de que las dependencias especificadas se hayan completado correctamente. Una vez que estas terminen correctamente, el trabajo dependiente pasa del estado `PENDING` al estado `RUNNABLE` y, a continuación, a `STARTING` y a `RUNNING`. Si alguna de las dependencias del trabajo produce un error, el trabajo dependiente pasa automáticamente de `PENDING` a `FAILED`.
Por ejemplo, Job A puede expresar una dependencia de hasta 20 trabajos distintos que deben completarse correctamente para que pueda ejecutarse. A continuación, puede enviar trabajos adicionales que dependan de Job A y de hasta otros 19 trabajos.
En los trabajos de matrices, puede especificar una dependencia de tipo `SEQUENTIAL` sin especificar un ID de trabajo para que cada trabajo de matriz secundario se complete de forma secuencial, comenzando a partir del índice 0. También puede especificar una dependencia de tipo `N_TO_N` con un ID de trabajo. De esta forma, cada índice secundario de este trabajo debe esperar a que se complete el índice secundario correspondiente de cada dependencia antes de comenzar. Para obtener más información, consulte [Trabajos de matrices](array_jobs.md).
Para enviar un AWS Batch trabajo con dependencias, consulte. [Tutorial: envío de un trabajo](submit_job.md)
[Programación basada en los recursos](resource-aware-scheduling.md) permite programar los trabajos según los recursos consumibles requeridos para su ejecución. Estos recursos consumibles se deben especificar para ejecutar un trabajo, por lo tanto, Batch contempla dichas dependencias de recursos cuando realiza la programación de uno. La reducción de la infrautilización de los recursos de computación se lleva a cabo con la asignación de los trabajos que contienen todos los recursos necesarios. La programación basada en los recursos está disponible para las políticas de programación FIFO y de reparto justo, y se puede utilizar con todas las plataformas de computación compatibles con Batch, como EKS, ECS y Fargate. Así como con trabajos de matriz, trabajos paralelos de varios nodos (MNP) y trabajos habituales de Batch.
# Tiempos de espera de trabajo
Puede configurar una duración de tiempo de espera para sus trabajos de modo que si un trabajo se ejecuta durante más tiempo, AWS Batch lo finaliza. Por ejemplo, es posible que tenga un trabajo que sabe que solo debería tardar 15 minutos en completarse. A veces la aplicación se bloquea en un bucle y se ejecuta para siempre, por lo que puede establecer un tiempo de espera de 30 minutos para terminar el trabajo bloqueado.
**importante**
De forma predeterminada, AWS Batch no tiene un tiempo de espera para el trabajo. Si no define un tiempo de espera para el trabajo, el trabajo se ejecutará hasta que salga el contenedor.
Especifique un parámetro `attemptDurationSeconds`, que debe tener al menos de 60 segundos, en la definición del trabajo o al enviarlo. Cuando haya transcurrido este número de segundos después de la `startedAt` marca de tiempo del intento de trabajo, AWS Batch finaliza el trabajo. En el recurso de computación, el contenedor del trabajo recibe una señal `SIGTERM` para dar a la aplicación la posibilidad de que se apague correctamente. Si el contenedor se sigue ejecutando al cabo de 30 segundos, se envía una señal `SIGKILL` para forzar su cierre.
Las finalizaciones por haberse agotado el tiempo de espera se realizan en la medida que es posible. No espere que se produzcan exactamente en el momento en que se agota el tiempo de espera del intento de trabajo (pueden tardar algunos segundos más). Si su aplicación necesita una ejecución de tiempo de espera precisa, debe implementar esa lógica en la aplicación. Si tiene una gran cantidad de trabajos cuyo tiempo de espera se agota simultáneamente, las terminaciones por tiempo de espera se deben comportar como una cola del tipo "primero en entrar, primero en salir", donde los trabajos se terminen por lotes.
**nota**
No hay un valor de tiempo de espera máximo para un trabajo. AWS Batch
Si un trabajo se termina por superar la duración del tiempo de espera, no se vuelve a intentar. Si se produce un error en un intento de trabajo, se puede reintentar si se han habilitado los reintentos y la cuenta atrás del tiempo de espera comienza para el nuevo intento.
**importante**
Los trabajos que se ejecutan con recursos Fargate no pueden esperar funcionar durante más de 14 días. Si el tiempo de espera supera los 14 días, es posible que los recursos de Fargate ya no estén disponibles y el trabajo se cancelará.
En el caso de los trabajos de matriz, los trabajos secundarios tienen la misma configuración de tiempo de espera que el trabajo principal.
Para obtener información sobre el envío de un AWS Batch trabajo con una configuración de tiempo de espera, consulte. [Tutorial: envío de un trabajo](submit_job.md)
# Trabajos de Amazon EKS
Un trabajo es la unidad de trabajo más pequeña de AWS Batch. Un AWS Batch trabajo en Amazon EKS consiste en one-to-one mapear un Kubernetes pod. Una definición de AWS Batch trabajo es una plantilla para un AWS Batch trabajo. Cuando envía un AWS Batch trabajo, hace referencia a una definición de trabajo, selecciona una cola de trabajos y proporciona un nombre para el trabajo. En la definición de trabajo de un AWS Batch trabajo en Amazon EKS, el parámetro [eksProperties](https://docs.aws.amazon.com/batch/latest/APIReference/API_EksProperties.html) define el conjunto de parámetros que admite un trabajo en AWS Batch Amazon EKS. En una [SubmitJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html)solicitud, el [eksPropertiesOverride](https://docs.aws.amazon.com/batch/latest/APIReference/API_EksPropertiesOverride.html)parámetro permite anular algunos parámetros comunes. De esta forma, puede utilizar plantillas de definiciones de trabajos para varios trabajos. Cuando se envía un trabajo a su clúster de Amazon EKS, lo AWS Batch transforma en un `podspec` (`Kind: Pod`). `podspec`Utiliza algunos AWS Batch parámetros adicionales para garantizar que los trabajos se escalen y programen correctamente. AWS Batch combina etiquetas e imitaciones para garantizar que los trabajos se ejecuten únicamente en los nodos AWS Batch gestionados y que otros módulos no se ejecuten en esos nodos.
**importante**
Si el `hostNetwork` parámetro no está establecido de forma explícita en una definición de trabajo de Amazon EKS, el modo de red del pod AWS Batch pasa por defecto al modo host. Más específicamente, se aplican los siguientes ajustes: `hostNetwork=true` y `dnsPolicy=ClusterFirstWithHostNet`.
AWS Batch limpia los módulos de trabajos poco después de que un pod complete su trabajo. Para ver los registros de las aplicaciones del pod, configure un servicio de registro para su clúster. Para obtener más información, consulte [Utilice CloudWatch los registros para supervisar AWS Batch los trabajos de Amazon EKS](batch-eks-cloudwatch-logs.md).
**Topics**
+ [
# Tutorial: asignación de un trabajo en ejecución a un pod y un nodo
](eks-jobs-map-running-job.md)
+ [
# Tutorial: reasignación de un pod en ejecución a su función
](eks-jobs-map-running-pod-to-job.md)
# Tutorial: asignación de un trabajo en ejecución a un pod y un nodo
Los `podProperties` de un trabajo en ejecución tienen los parámetros `podName` y `nodeName` establecidos para el intento de trabajo actual. Utilice la operación [DescribeJobs](https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeJobs.html)de la API para ver estos parámetros.
A continuación, se muestra un ejemplo del resultado.
```
$ aws batch describe-jobs --job 2d044787-c663-4ce6-a6fe-f2baf7e51b04
{
"jobs": [
{
"status": "RUNNING",
"jobArn": "arn:aws:batch:us-east-1:123456789012:job/2d044787-c663-4ce6-a6fe-f2baf7e51b04",
"jobDefinition": "arn:aws:batch:us-east-1:123456789012:job-definition/MyJobOnEks_SleepWithRequestsOnly:1",
"jobQueue": "arn:aws:batch:us-east-1:123456789012:job-queue/My-Eks-JQ1",
"jobId": "2d044787-c663-4ce6-a6fe-f2baf7e51b04",
"eksProperties": {
"podProperties": {
"nodeName": "ip-192-168-55-175.ec2.internal",
"containers": [
{
"image": "public.ecr.aws/amazonlinux/amazonlinux:2",
"resources": {
"requests": {
"cpu": "1",
"memory": "1024Mi"
}
}
}
],
"podName": "aws-batch.b0aca953-ba8f-3791-83e2-ed13af39428c"
}
}
}
]
}
```
En el caso de un trabajo con los reintentos habilitados, el `podName` y `nodeName` de cada intento completado aparece en el parámetro de `eksAttempts` lista de la operación de [DescribeJobs](https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeJobs.html)API. El `podName` y el `nodeName` del intento en ejecución actual se encuentra en el objeto `podProperties`.
# Tutorial: reasignación de un pod en ejecución a su función
Un pod tiene etiquetas que indican la dirección `jobId` y el entorno `uuid` de cómputo al que pertenece. AWS Batch inyecta variables de entorno para que el tiempo de ejecución del trabajo pueda hacer referencia a la información del trabajo. Para obtener más información, consulte [AWS Batch variables de entorno laboral](job_env_vars.md). Puede ver esta información al ejecutar el siguiente comando. El resultado es el siguiente.
```
$ kubectl describe pod aws-batch.14638eb9-d218-372d-ba5c-1c9ab9c7f2a1 -n my-aws-batch-namespace
Name: aws-batch.14638eb9-d218-372d-ba5c-1c9ab9c7f2a1
Namespace: my-aws-batch-namespace
Priority: 0
Node: ip-192-168-45-88.ec2.internal/192.168.45.88
Start Time: Wed, 26 Oct 2022 00:30:48 +0000
Labels: batch.amazonaws.com/compute-environment-uuid=5c19160b-d450-31c9-8454-86cf5b30548f
batch.amazonaws.com/job-id=f980f2cf-6309-4c77-a2b2-d83fbba0e9f0
batch.amazonaws.com/node-uid=a4be5c1d-9881-4524-b967-587789094647
...
Status: Running
IP: 192.168.45.88
IPs:
IP: 192.168.45.88
Containers:
default:
Image: public.ecr.aws/amazonlinux/amazonlinux:2
...
Environment:
AWS_BATCH_JOB_KUBERNETES_NODE_UID: a4be5c1d-9881-4524-b967-587789094647
AWS_BATCH_JOB_ID: f980f2cf-6309-4c77-a2b2-d83fbba0e9f0
AWS_BATCH_JQ_NAME: My-Eks-JQ1
AWS_BATCH_JOB_ATTEMPT: 1
AWS_BATCH_CE_NAME: My-Eks-CE1
...
```
**Características compatibles con AWS Batch Amazon EKS Jobs**
Estas son las características AWS Batch específicas que también son comunes a los Kubernetes trabajos que se ejecutan en Amazon EKS:
+ [Dependencias de trabajos](job_dependencies.md)
+ [Trabajos de matrices](array_jobs.md)
+ [Tiempos de espera de trabajo](job_timeouts.md)
+ [Reintentos automáticos de trabajo](job_retries.md)
+ [Uso de una programación de reparto justo para ayudar a programar los trabajos](fair-share-scheduling.md)
**Kubernetes y `Secrets``ServiceAccounts`**
AWS Batch admite referencias Kubernetes `Secrets` y. `ServiceAccounts` Puede configurar los pods para utilizar los roles de IAM de Amazon EKS para las cuentas de servicio. Para obtener más información, consulte [Configurar los pods para usar una cuenta de servicio de Kubernetes](https://docs.aws.amazon.com/eks/latest/userguide/pod-configuration.html) en la [https://docs.aws.amazon.com/eks/latest/userguide/](https://docs.aws.amazon.com/eks/latest/userguide/).
**Documentos relacionados**
+ [Consideraciones sobre memoria y vCPU para AWS Batch en Amazon EKS](memory-cpu-batch-eks.md)
+ [Ejecución de trabajos de GPU](gpu-jobs.md)
+ [Trabajos bloqueados en estado `RUNNABLE`](job_stuck_in_runnable.md)
# Trabajos paralelos de varios nodos
Los trabajos paralelos de varios nodos le permiten ejecutar trabajos individuales que abarcan varias instancias de Amazon EC2. Los trabajos paralelos de varios nodos de AWS Batch (también denominados *programación por grupos*) le permiten ejecutar aplicaciones informáticas de alto rendimiento a gran escala estrechamente acopladas y entrenar modelos de GPU distribuida sin necesidad de lanzar, configurar y administrar los recursos de Amazon EC2 directamente. Un trabajo paralelo de AWS Batch varios nodos es compatible con cualquier marco que admita la comunicación entre nodos basada en IP. Algunos ejemplos son Apache MXNet TensorFlow, Caffe2 o Message Passing Interface (MPI).
Los trabajos paralelos de varios nodos se envían como un único trabajo. Sin embargo, la definición de trabajo (o las anulaciones de nodos de envío de trabajos) especifica el número de nodos que se deben crear para el trabajo y qué grupos de nodos deben crearse. Cada trabajo paralelo de varios nodos contiene un **nodo principal**, que se lanza en primer lugar. Una vez que el nodo principal está en marcha, se lanzan e inician los nodos secundarios. El trabajo finaliza solo si sale el nodo principal. A continuación, se detienen todos los nodos secundarios. Para obtener más información, consulte [Grupos de nodos](mnp-node-groups.md).
Los nodos de trabajo paralelos de varios nodos son de un solo inquilino. Esto significa que solo se ejecuta un contenedor de trabajos en cada instancia de Amazon EC2.
El estado final del trabajo (`SUCCEEDED` o `FAILED`) lo determina el estado final del trabajo del nodo principal. Para obtener el estado de un trabajo paralelo de varios nodos, puede describir el trabajo utilizando el ID de trabajo obtenido al enviar el trabajo. Si necesita los detalles de los nodos secundarios, deberá describir cada nodo secundario por separado. Puede direccionar los nodos mediante la notación `#N` (empezando por 0). Por ejemplo, para acceder a los detalles del segundo nodo de un trabajo, describe *aws\$1batch\$1job\$1id* \$11 mediante la operación de la AWS Batch [DescribeJobs](https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeJobs.html)API. La información `started`, `stoppedAt`, `statusReason` y `exit` de un trabajo paralelo de varios nodos se rellena desde el nodo principal.
Si especifica los reintentos de trabajo, un error en el nodo principal provocará otro intento. Los errores en los nodos secundarios no provocan que se produzcan más intentos. Cada nuevo intento de un trabajo paralelo de varios nodos actualiza el intento correspondiente de sus nodos secundarios asociados.
Para ejecutar trabajos paralelos de varios nodos AWS Batch, el código de la aplicación debe contener los marcos y las bibliotecas necesarios para la comunicación distribuida.
**Topics**
+ [
# Variables de entorno
](mnp-env-vars.md)
+ [
# Grupos de nodos
](mnp-node-groups.md)
+ [
# Ciclo de vida laboral para trabajos de MNP
](job-lifecycle.md)
+ [
# Consideraciones sobre el entorno de cómputo para MNP con AWS Batch
](mnp-ce.md)
# Variables de entorno
En tiempo de ejecución, cada nodo tiene configuradas las variables de entorno estándar que reciben todos los AWS Batch trabajos. Además, los nodos se configuran con las siguientes variables de entorno que son específicas para los trabajos paralelos de varios nodos:
`AWS_BATCH_JOB_MAIN_NODE_INDEX`
Esta variable se establece en el número de índice del nodo principal del trabajo. El código de la aplicación puede comparar `AWS_BATCH_JOB_MAIN_NODE_INDEX` con `AWS_BATCH_JOB_NODE_INDEX` en un nodo individual para determinar si es el nodo principal.
`AWS_BATCH_JOB_MAIN_NODE_PRIVATE_IPV4_ADDRESS`
Esta variable solo se establece en los trabajos paralelos de varios nodos. Esta variable no está presente en el nodo principal. Esta variable se establece en la IPv4 dirección privada del nodo principal del trabajo. El código de la aplicación del nodo secundario puede utilizar esta dirección para comunicarse con el nodo principal.
`AWS_BATCH_JOB_NODE_INDEX`
Esta variable se establece en el número de índice del nodo. El índice del nodo comienza a partir de 0 y cada nodo recibe un número de índice único. Por ejemplo, un trabajo paralelo de varios nodos con 10 elementos secundarios tiene valores de índice comprendidos entre 0 y 9.
`AWS_BATCH_JOB_NUM_NODES`
Esta variable se establece en el número de nodos solicitados para el trabajo en paralelo de varios nodos.
# Grupos de nodos
Un grupo de nodos es un conjunto de nodos de trabajo idénticos que comparten las mismas propiedades de contenedor. Se puede utilizar AWS Batch para especificar hasta cinco grupos de nodos distintos para cada trabajo.
Cada grupo puede tener sus propias imágenes de contenedor, comandos, variables de entorno, etc. Por ejemplo, puede enviar un trabajo que requiera una sola instancia `c5.xlarge` para el nodo principal y cinco nodos secundarios de la instancia `c5.xlarge`. Cada uno de estos grupos de nodos distintos puede especificar diferentes imágenes de contenedor o comandos para ejecutarlos en cada trabajo.
Como alternativa, todos los nodos de su trabajo pueden usar un único grupo de nodos. Además, el código de su aplicación puede diferenciar las funciones de los nodos, como el nodo principal y el nodo secundario. Para ello, compara la variable de entorno `AWS_BATCH_JOB_MAIN_NODE_INDEX` con su propio valor para `AWS_BATCH_JOB_NODE_INDEX`. Puede tener un máximo de 1000 nodos en un solo trabajo. Este es el límite predeterminado de las instancias de un clúster de Amazon ECS. Puede [solicitar un aumento de este límite](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html).
**nota**
Actualmente, todos los grupos de nodos de un trabajo paralelo de varios nodos deben usar el mismo tipo de instancia.
# Ciclo de vida laboral para trabajos de MNP
Al enviar un trabajo paralelo de varios nodos, el trabajo entra en el estado `SUBMITTED`. A continuación, el trabajo espera a que finalicen todas las dependencias del trabajo. El trabajo también pasa al estado `RUNNABLE`. Por último, AWS Batch aprovisiona la capacidad de instancia necesaria para ejecutar el trabajo y lanza estas instancias.
Cada trabajo paralelo de varios nodos contiene un **nodo principal**. El nodo principal es una subtarea única que AWS Batch supervisa para determinar el resultado del trabajo de varios nodos enviado. El nodo principal se lanza en primer lugar y pasa a tener el estado `STARTING`. El valor de tiempo de espera especificado en el parámetro `attemptDurationSeconds` se aplica a todo el trabajo y no a los nodos.
Cuando el nodo principal alcanza el estado `RUNNING` (después de que el contenedor del nodo se esté ejecutando), los nodos secundarios se lanzan y pasan al estado `STARTING`. Los nodos secundarios aparecen en orden aleatorio. No hay ninguna garantía sobre la sincronización o el orden del lanzamiento de los nodos secundarios. Para asegurarse de que todos los nodos de los trabajos están en el estado `RUNNING` después de que el contenedor del nodo se está ejecutando, el código de la aplicación puede consultar la API de AWS Batch para obtener información sobre el nodo principal y los nodos secundarios. Como alternativa, el código de la aplicación puede esperar hasta que todos los nodos estén en línea antes de iniciar cualquier tarea de procesamiento distribuido. La dirección IP privada del nodo principal está disponible en la variable de entorno `AWS_BATCH_JOB_MAIN_NODE_PRIVATE_IPV4_ADDRESS` de cada nodo secundario. El código de la aplicación puede utilizar esta información para coordinar y comunicar datos entre cada una de las tareas.
A medida que finalizan los nodos individuales, pasan al estado `SUCCEEDED` o `FAILED`, en función de su código de salida. Si finaliza el nodo principal, se considera que el trabajo ha finalizado y todos los nodos secundarios se detienen. Si un nodo secundario muere, AWS Batch no realiza ninguna acción en los demás nodos del trabajo. Si no desea que el trabajo continúe con una cantidad reducida de nodos, debe tenerlo en cuenta en el código de la aplicación. De este modo, se termina o se cancela el trabajo.
# Consideraciones sobre el entorno de cómputo para MNP con AWS Batch
Hay varios aspectos que es preciso tener en cuenta al configurar entornos de computación para ejecutar trabajos paralelos de varios nodos con AWS Batch.
+ Los trabajos paralelos de varios nodos no se admiten en entornos de computación `UNMANAGED`.
+ Si va a enviar trabajos paralelos de varios nodos a un entorno de computación, considere la posibilidad de crear un grupo con ubicación en *clúster* en una única zona de disponibilidad y asociarlo a los recursos de computación. Esto mantiene los trabajos paralelos de varios nodos en una agrupación lógica de instancias muy próxima al alto potencial de flujo de la red. Para obtener más información, consulte [Grupos de ubicación](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html) en la *Guía del usuario de Amazon EC2*.
+ Los trabajos paralelos de varios nodos no se admiten en entornos de computación que utilicen instancias de spot.
+ AWS Batch los trabajos paralelos de varios nodos utilizan el modo de `awsvpc` red Amazon ECS, que proporciona a los contenedores de trabajos paralelos de varios nodos las mismas propiedades de red que las instancias de Amazon EC2. Cada contenedor de trabajos paralelos de varios nodos obtiene su propia interfaz de red elástica, una dirección IP privada principal y un nombre de host DNS interno. La interfaz de red se crea en la misma subred de VPC como su recurso de computación de host.
+ El entorno de computación no puede tener asociados más de cinco grupos de seguridad. Las interfaces de red elásticas que se crean y se adjuntan a una tarea de MNP utilizarán los grupos de seguridad especificados en el entorno de computación. Si no desea especificar un grupo de seguridad, se utilizará el predeterminado de la VPC.
+ El modo de red `awsvpc` no proporciona las interfaces de red elásticas para los trabajos paralelos de varios nodos con direcciones IP públicas. Para obtener acceso a Internet, los recursos de computación deben lanzarse en una subred privada configurada para utilizar una puerta de enlace NAT. Para obtener más información, consulte [Gateways NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) en la *Guía del usuario de Amazon VPC*. La comunicación entre nodos debe utilizar la dirección IP privada o el nombre de host DNS para el nodo. Los trabajos paralelos de varios nodos que se ejecutan en recursos de computación dentro de subredes públicas no disponen de acceso de red saliente. Para crear una VPC con subredes privadas y una gateway NAT, consulte [Creación de una nube virtual privada](create-public-private-vpc.md).
+ Las interfaces de red elásticas que se crean y asocian a los recursos de computación no se pueden separar manualmente ni la cuenta puede modificarlas. De este modo, se evita la eliminación accidental de una interfaz de red elástica que esté asociada a un trabajo en ejecución. Para liberar las interfaces de red elásticas de una tarea, termine el trabajo.
+ Su entorno de cómputo debe tener un máximo de v suficiente CPUs para soportar su trabajo paralelo de varios nodos.
+ Su cuota de instancias de Amazon EC2 incluye la cantidad de instancias necesarias para ejecutar su trabajo. Por ejemplo, si el trabajo requiere 30 instancias, pero la cuenta solo puede ejecutar 20 en una región. Entonces, su trabajo se quedará estancado en el estado `RUNNABLE`.
+ Si especifica un tipo de instancia para un grupo de nodos en un trabajo paralelo de varios nodos, el entorno de computación debe ser capaz de lanzar ese tipo de instancia.
# Trabajos paralelos de varios nodos en Amazon EKS
Puede utilizarlos AWS Batch en Amazon Elastic Kubernetes Service para ejecutar trabajos paralelos (MNP) de varios nodos (también conocidos *como* programación de bandas) en los clústeres gestionados. Kubernetes Esta opción se suele utilizar para trabajos grandes, estrechamente acoplados y de alto rendimiento que no se pueden ejecutar en una sola instancia de Amazon Elastic Compute Cloud. Para obtener más información, consulte [Trabajos paralelos de varios nodos](multi-node-parallel-jobs.md).
Puede utilizar esta característica para ejecutar aplicaciones informáticas de alto rendimiento específicas de Kubernetes y gestionadas por Amazon EKS, entrenamiento del modelo lingüístico de gran tamaño y otros trabajos de inteligencia artificial (IA) o machine learning (ML).
**Topics**
+ [
# Ejecución de trabajos de MNP
](mnp-eks-running-mnp-jobs.md)
+ [
# Creación de una definición de trabajo de MNP de Amazon EKS
](mnp-eks-create-eks-mnp-job-definition.md)
+ [
# Envío de un trabajo de Amazon EKS MNP
](mnp-eks-submit-eks-mnp-job.md)
+ [
# Anulación de una definición de trabajo de MNP de Amazon EKS
](mnp-eks-override-eks-mnp-job-definition.md)
# Ejecución de trabajos de MNP
AWS Batch admite trabajos de MNP en Amazon Elastic Container Service y Amazon EKS mediante Amazon EC2. A continuación, se proporcionan más detalles sobre los parámetros de instancia y contenedor de la característica.
## Cuotas de instancias para MNP en Amazon EKS
+ Se pueden utilizar hasta 1000 instancias para un solo trabajo de MNP.
+ Se pueden unir hasta 5000 instancias a un único clúster de Amazon EKS.
+ Se pueden agrupar en clústeres y adjuntar hasta 5 entornos de computación a una cola de trabajos.
Por ejemplo, puede escalar verticalmente hasta 5 entornos de computación en clústeres agrupados en una cola de trabajos y 1000 instancias en cada uno de ellos.
Además de los parámetros de la instancia, tenga en cuenta que no puede usar Fargate para trabajos de MNP a través de ninguno de los dos servicios.
Solo puede utilizar un tipo de instancia en cada trabajo de MNP. Para cambiar el tipo de instancia, actualice el entorno de computación o defina uno nuevo. También puede especificar el tipo de instancia y proporcionar los requisitos de vCPU o memoria al crear la definición del trabajo.
## Cuotas de contenedor para MNP en Amazon EKS
+ Un trabajo paralelo de varios nodos admite un pod por nodo.
+ Hasta 10 contenedores (o 10 contenedores init). Para obtener más información, consulte [Init Containers](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/) (en la *documentación de Kubernetes*) en cada pod.
+ Hasta 5 rangos de nodos en cada trabajo de MNP.
+ Hasta 10 imágenes de contenedores distintas en cada rango de nodos.
Por ejemplo, puede ejecutar hasta un máximo de 10 000 contenedores en un solo trabajo de MNP que contenga 5 rangos de nodos y un total de 50 imágenes únicas.
## Ejecución de trabajos de MNP en una VPC de Amazon privada y un clúster de Amazon EKS
Los trabajos de MNP se pueden ejecutar en cualquier clúster de Amazon EKS, tanto si tiene Internet público como si no. Cuando utilice un clúster de Amazon EKS con acceso exclusivo a la red privada, asegúrese de que AWS Batch puede acceder al plano de control de Amazon EKS y al servidor de Kubernetes API gestionado. Puede conceder el acceso necesario a través de los puntos de conexión de Amazon Virtual Private Cloud. Para obtener más información, consulte [Configurar un servicio de punto de conexión](https://docs.aws.amazon.com/vpc/latest/privatelink/configure-endpoint-service.html).
Los pods de clústeres de Amazon EKS no pueden descargar una imagen de una fuente pública porque la VPC privada no tiene acceso a Internet. El clúster de Amazon EKS debe extraer imágenes de un registro de contenedores que esté en su Amazon VPC. Puede crear un [Amazon Elastic Container Registry (Amazon ECR)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/Registries.html) en su Amazon VPC y copiar las imágenes del contenedor para acceder a los nodos.
También puede crear una regla de caché de extracción con Amazon ECR. Una vez creada una regla de caché de extracción para un registro público externo, basta con extraer una imagen de ese registro público externo mediante la URI de su registro privado de Amazon ECR. A continuación, Amazon ECR crea un repositorio y almacena la imagen en la caché. Cuando se extrae una imagen en caché mediante el URI del registro privado de Amazon ECR, Amazon ECR verifica el registro remoto para ver si hay una nueva versión de la imagen y actualizará su registro privado hasta una vez cada 24 horas. Para obtener más información, consulte [Creación de una regla de caché de extracción en Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache-creating-rule.html).
## Notificación de error
Si tus trabajos de MNP están bloqueados, puedes recibir notificaciones a través de Amazon Consola de administración de AWS y Amazon EventBridge. Por ejemplo, si un trabajo de MNP está atascado en primer lugar en la cola, puede recibir una notificación sobre el problema junto con información sobre la causa para tomar medidas inmediatas y desbloquear la cola de trabajos. También puede finalizar automáticamente el trabajo de MNP si no se realiza ninguna acción en un período de tiempo determinado, que se puede definir en la plantilla de cola de trabajos. Para obtener más información, consulte [Eventos bloqueados en la cola de trabajos](batch-job-queue-blocked-events.md)
# Creación de una definición de trabajo de MNP de Amazon EKS
Para definir y ejecutar trabajos de MNP en Amazon EKS, hay nuevos parámetros en las operaciones de API de [https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html) y [https://docs.aws.amazon.com/batch/latest/APIReference/API_RegisterJobDefinition.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_RegisterJobDefinition.html).
+ Use [https://docs.aws.amazon.com/batch/latest/APIReference/API_EksProperties.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_EksProperties.html) en la sección [https://docs.aws.amazon.com/batch/latest/APIReference/API_NodeProperties.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_NodeProperties.html) para establecer una definición del trabajo de MNP.
+ Use [https://docs.aws.amazon.com/batch/latest/APIReference/API_EksPropertiesOverride.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_EksPropertiesOverride.html) en la sección [https://docs.aws.amazon.com//batch/latest/APIReference/API_NodePropertyOverride.html](https://docs.aws.amazon.com//batch/latest/APIReference/API_NodePropertyOverride.html) para anular los parámetros establecidos en la definición del trabajo al enviar un trabajo de MNP.
Estas acciones se pueden definir mediante las operaciones de API y Consola de administración de AWS.
## Referencia: registre la carga útil de la solicitud de definición de trabajo de Amazon EKS MNP
En el siguiente ejemplo, se muestra cómo puede registrar una definición de trabajo de Amazon EKS MNP con dos nodos.
```
{
"jobDefinitionName": "MyEksMnpJobDefinition",
"type": "multinode",
"nodeProperties": {
"numNodes": 2,
"mainNode": 0,
"nodeRangeProperties": [
{
"targetNodes" : "0:",
"eksProperties": {
"podProperties": {
"containers": [
{
"name": "test-eks-container-1",
"image": "public.ecr.aws/amazonlinux/amazonlinux:2",
"command": [
"sleep",
"60"
],
"resources": {
"limits": {
"cpu": "1",
"memory": "1024Mi"
}
},
"securityContext":{
"runAsUser":1000,
"runAsGroup":3000,
"privileged":true,
"readOnlyRootFilesystem":true,
"runAsNonRoot":true
}
}
],
"initContainers": [
{
"name":"init-ekscontainer",
"image": "public.ecr.aws/amazonlinux/amazonlinux:2",
"command": [
"echo",
"helloWorld"
],
"resources": {
"limits": {
"cpu": "1",
"memory": "1024Mi"
}
}
}
],
"metadata": {
"labels": {
"environment" : "test"
}
}
}
}
}
]
}
}
```
Para registrar la definición de trabajo mediante el AWS CLI, copia la definición en un archivo local denominado *MyEksMnpJobDefinition.json* y ejecuta el siguiente comando.
```
aws batch register-job-definition --cli-input-json file://MyEksMnpJobDefinition.json
```
Recibirá la siguiente respuesta JSON.
```
{
"jobDefinitionName": "MyEksMnpJobDefinition",
"jobDefinitionArn": "arn:aws:batch:us-east-1:0123456789:job-definition/MyEksMnpJobDefinition:1",
"revision": 1
}
```
# Envío de un trabajo de Amazon EKS MNP
Para enviar un trabajo con la definición de trabajo registrada, introduzca el siguiente comando. Sustituya el valor de por el nombre o el ARN de una cola de trabajos preexistente asociada a un entorno de computación de Amazon EKS.
```
aws batch submit-job --job-queue \
--job-definition MyEksMnpJobDefinition \
--job-name myFirstEksMnpJob
```
Recibirá la siguiente respuesta JSON.
```
{
"jobArn": "arn:aws:batch:region:account:job/9b979cce-9da0-446d-90e2-ffa16d52af68",
"jobName": "myFirstEksMnpJob",
"jobId": ""
}
```
Puede comprobar el estado del trabajo con el ID de trabajo devuelto mediante el siguiente comando.
```
aws batch describe-jobs --jobs
```
# Anulación de una definición de trabajo de MNP de Amazon EKS
Si lo desea, puede anular los detalles de la definición del trabajo (por ejemplo, cambiar el tamaño del trabajo de MNP o los detalles del trabajo secundario). A continuación, se proporciona un ejemplo de carga útil de solicitud de JSON para enviar un trabajo MNP de cinco nodos y cambios en el comando del contenedor `test-eks-container-1`.
```
{
"numNodes": 5,
"nodePropertyOverrides": [
{
"targetNodes": "0:",
"eksPropertiesOverride": {
"podProperties": {
"containers": [
{
"name": "test-eks-container-1",
"command": [
"sleep",
"150"
]
}
]
}
}
}
]
}
```
Para enviar un trabajo con estas anulaciones, guarda el ejemplo en un archivo local, *eks-mnp-job-nodeoverride.json*, y úsalo AWS CLI para enviar el trabajo con las anulaciones.
# Trabajos de matrices
Un trabajo de matriz es un trabajo que comparte parámetros comunes, como la definición del trabajoCPUs, v y la memoria. Se ejecuta como un conjunto de trabajos básicos relacionados, pero independientes, que se pueden distribuir en varios hosts y pueden ejecutarse de forma simultánea. Los trabajos de matrices son la manera más eficiente de ejecutar trabajos que ocurren todos en paralelo, como simulaciones Monte Carlo, barridos paramétricos o grandes trabajos de representación.
AWS Batch Los trabajos de matriz se envían igual que los trabajos normales. Sin embargo, es necesario especificar un tamaño de matriz (entre 2 y 10 000) para definir la cantidad de trabajos secundarios que deberían ejecutarse en la matriz. Si envía un trabajo con un tamaño de matriz de 1 000, se ejecuta un solo trabajo que genera 1 000 trabajos secundarios. El trabajo de matriz es una referencia o un puntero para administrar todos los trabajos secundarios. Esto permite enviar grandes cargas de trabajo con una sola consulta. El tiempo de espera especificado en el parámetro `attemptDurationSeconds` se aplica a cada trabajo secundario. El trabajo de matriz principal no tiene tiempo de espera.
Al enviar un trabajo de matriz, el trabajo de matriz principal recibe un ID de AWS Batch trabajo normal. Cada trabajo secundario tiene el mismo ID base. Cada trabajo secundario tiene el mismo ID de base, pero su índice de matriz se añade al final del ID principal, por ejemplo, `example_job_ID:0` para el primer trabajo secundario de la matriz.
El trabajo de matriz principal puede introducir un estado `SUBMITTED`, `PENDING`, `FAILED` o `SUCCEEDED`. El trabajo de matriz principal se actualiza a `PENDING` cuando se actualiza cualquier trabajo secundario a `RUNNABLE`. Para obtener más información acerca de estas dependencias, consulte [Dependencias de trabajos](job_dependencies.md).
Durante el tiempo de ejecución, la variable de entorno `AWS_BATCH_JOB_ARRAY_INDEX` se establece en el número de índice del trabajo de matriz correspondiente del contenedor. Al primer índice de trabajo de matriz se le asigna el número `0`, y los trabajos secundarios posteriores se numeran en orden ascendente (por ejemplo, 1, 2, 3, etc.). Puede utilizar este valor de índice para controlar la forma en la que se diferencian los elementos secundarios del trabajo de matriz. Para obtener más información, consulte [Uso del índice de trabajo de matriz para controlar la diferenciación de trabajos](array_index_example.md).
En las dependencias de trabajo de matriz, puede especificar un tipo para la dependencia, como, por ejemplo, `SEQUENTIAL` o `N_TO_N`. Puede especificar una dependencia de tipo `SEQUENTIAL` (sin especificar un ID de trabajo) para que cada trabajo de matriz secundario se complete de forma secuencial, comenzando a partir del índice 0. Por ejemplo, si envía un trabajo de matriz con un tamaño de matriz de 100, y especifica una dependencia de tipo `SEQUENTIAL`, se generan 100 trabajos secundarios de forma secuencial, cada uno de los cuales debe completarse correctamente para que comience el siguiente. En la ilustración siguiente se muestra Job A, un trabajo de matriz con un tamaño de matriz de 10. Cada trabajo del índice secundario de Job A depende del trabajo secundario anterior. Job A:1 no puede comenzar hasta que termine Job A:0.
![\[Flowchart showing Job-A with sequential child jobs A:0 through A:9, connected by arrows.\]](http://docs.aws.amazon.com/es_es/batch/latest/userguide/images/sequential-dep.png)
También puede especificar una dependencia de tipo `N_TO_N` con un ID de trabajo para los trabajos de matriz. De esta forma, cada índice secundario de este trabajo debe esperar a que se complete el índice secundario correspondiente de cada dependencia antes de comenzar. En la ilustración siguiente se muestran Job A y Job B, dos trabajos de matrices con un tamaño de matriz de 10 000. Cada trabajo del índice secundario de Job B depende del índice correspondiente de Job A. Job B:1 no puede comenzar hasta que termine Job A:1.
![\[Two array jobs, Job-A and Job-B, with 10,000 indexed tasks each, showing N_TO_N dependency.\]](http://docs.aws.amazon.com/es_es/batch/latest/userguide/images/n-to-n-dep.png)
Si cancela o termina un trabajo de matriz principal, todos los trabajos secundarios se cancelan o terminan con él. Puede cancelar o terminar trabajos secundarios por separado (con lo que adoptarán el estado `FAILED`) sin afectar al resto de trabajos secundarios. Sin embargo, si un trabajo de matriz secundario produce un error (durante su ejecución o por una cancelación/terminación manual), el trabajo principal también producirá un error. En este escenario, el trabajo principal cambia a `FAILED` cuando se completan todos los trabajos secundarios.
Para obtener más información sobre la búsqueda y el filtrado de trabajos de matriz, consulte[Buscar para trabajos en una cola de trabajos](searching-filtering-jobs.md).
**Topics**
+ [
# Ejemplo de un flujo de trabajos de matriz
](example_array_job.md)
+ [
# Uso del índice de trabajo de matriz para controlar la diferenciación de trabajos
](array_index_example.md)
# Ejemplo de un flujo de trabajos de matriz
Un flujo de trabajo habitual para AWS Batch los clientes consiste en ejecutar un trabajo de configuración previo, ejecutar una serie de comandos en un gran número de tareas de entrada y, a continuación, concluir con un trabajo que agregue los resultados y escriba datos resumidos en Amazon S3, DynamoDB, Amazon Redshift o Aurora.
Por ejemplo:
+ `JobA`: un trabajo estándar que no es de matriz, que realiza un listado rápido y una validación de metadatos de los objetos de un bucket `BucketA` de Amazon S3. La sintaxis de [SubmitJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html)JSON es la siguiente.
```
{
"jobName": "JobA",
"jobQueue": "ProdQueue",
"jobDefinition": "JobA-list-and-validate:1"
}
```
+ `JobB`: un trabajo de matriz con 10 000 copias que depende de `JobA`, que ejecuta comandos con un uso intensivo de la CPU en cada objeto de `BucketA` y que carga los resultados en `BucketB`. La sintaxis de [SubmitJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html)JSON es la siguiente.
```
{
"jobName": "JobB",
"jobQueue": "ProdQueue",
"jobDefinition": "JobB-CPU-Intensive-Processing:1",
"containerOverrides": {
"resourceRequirements": [
{
"type": "MEMORY",
"value": "4096"
},
{
"type": "VCPU",
"value": "32"
}
]
}
"arrayProperties": {
"size": 10000
},
"dependsOn": [
{
"jobId": "JobA_job_ID"
}
]
}
```
+ `JobC`: otro trabajo de matriz de 10 000 copias que depende de `JobB` con un modelo de dependencia `N_TO_N`, que ejecuta comandos con un uso intensivo de la memoria en cada elemento de `BucketB`, escribe los metadatos en DynamoDB y carga la salida obtenida en `BucketC` . La sintaxis de [SubmitJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html)JSON es la siguiente.
```
{
"jobName": "JobC",
"jobQueue": "ProdQueue",
"jobDefinition": "JobC-Memory-Intensive-Processing:1",
"containerOverrides": {
"resourceRequirements": [
{
"type": "MEMORY",
"value": "32768"
},
{
"type": "VCPU",
"value": "1"
}
]
}
"arrayProperties": {
"size": 10000
},
"dependsOn": [
{
"jobId": "JobB_job_ID",
"type": "N_TO_N"
}
]
}
```
+ `JobD`: un trabajo de matriz que realiza 10 pasos de validación que requieren consultar DynamoDB y que pueden interactuar con cualquiera de los buckets de Amazon S3 anteriores. Cada uno de los pasos de `JobD` ejecuta el mismo comando. Sin embargo, el comportamiento es diferente en función del valor de la variable de entorno `AWS_BATCH_JOB_ARRAY_INDEX` del contenedor del trabajo. Estos pasos de validación se ejecutan de forma secuencial (por ejemplo `JobD:0` y, a continuación, `JobD:1`). La sintaxis de [SubmitJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html)JSON es la siguiente.
```
{
"jobName": "JobD",
"jobQueue": "ProdQueue",
"jobDefinition": "JobD-Sequential-Validation:1",
"containerOverrides": {
"resourceRequirements": [
{
"type": "MEMORY",
"value": "32768"
},
{
"type": "VCPU",
"value": "1"
}
]
}
"arrayProperties": {
"size": 10
},
"dependsOn": [
{
"jobId": "JobC_job_ID"
},
{
"type": "SEQUENTIAL"
},
]
}
```
+ `JobE`: un trabajo final que no es de matriz, que realiza varias operaciones de limpieza sencillas, y que envía una notificación de Amazon SNS con un mensaje que indica que la canalización se ha completado y que incluye un enlace con la URL de salida. La sintaxis de [SubmitJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html)JSON es la siguiente.
```
{
"jobName": "JobE",
"jobQueue": "ProdQueue",
"jobDefinition": "JobE-Cleanup-and-Notification:1",
"parameters": {
"SourceBucket": "s3://amzn-s3-demo-source-bucket",
"Recipient": "pipeline-notifications@mycompany.com"
},
"dependsOn": [
{
"jobId": "JobD_job_ID"
}
]
}
```
# Uso del índice de trabajo de matriz para controlar la diferenciación de trabajos
En este tutorial se describe cómo utilizar la variable de entorno de `AWS_BATCH_JOB_ARRAY_INDEX` para diferenciar los trabajos secundarios. Cada trabajo secundario se asigna a esta variable. El ejemplo utiliza el número de índice del trabajo secundario para leer una línea específica de un archivo. A continuación, sustituye el parámetro asociado a ese número de línea por un comando incluido en el contenedor del trabajo. El resultado es que puede tener varios AWS Batch trabajos que ejecuten la misma imagen de Docker y los mismos argumentos de comando. Sin embargo, los resultados son diferentes porque el índice de trabajos de la matriz se usa como modificador.
En este tutorial, creará un archivo de texto que tiene todos los colores del arco iris, cada uno en su propia línea. A continuación, creará un script de punto de entrada para un contenedor de Docker que convierte el índice en un valor que se puede utilizar como número de línea en el archivo de colores. El índice comienza en cero, pero los números de línea comienzan en uno. Creará un Dockerfile que copia los archivos de colores y de índice en la imagen del contenedor y establece el valor `ENTRYPOINT` de la imagen en el script de punto de entrada. El Dockerfile y los recursos se compilarán en una imagen de Docker que se enviará a Amazon ECR. A continuación, registras una definición de trabajo que usa tu nueva imagen de contenedor, envías un trabajo de AWS Batch matriz con esa definición de trabajo y ves los resultados.
**Topics**
+ [
# Requisitos previos
](array-tutorial-prereqs.md)
+ [
# Creación de una imagen de contenedor
](build-index-container.md)
+ [
# Enviar la imagen a Amazon ECR
](push-array-image.md)
+ [
# Crear y registrar una definición de trabajo
](create-array-job-def.md)
+ [
# Envíe un trabajo AWS Batch de matriz
](submit-array-job.md)
+ [
## Ver los registros del trabajo de matriz
](#array-tutorial-logs)
# Requisitos previos
Este flujo de trabajo de tutorial tiene los requisitos previos siguientes:
+ Un entorno AWS Batch informático. Para obtener más información, consulte [Creación de un entorno de computación](create-compute-environment.md).
+ Una cola de AWS Batch trabajos y un entorno informático asociado. Para obtener más información, consulte [Creación de una cola de trabajos](create-job-queue.md).
+ Están AWS CLI instalados en su sistema local. Para obtener más información, consulte [ >Instalación de AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/installing.html) en la *Guía del usuario de AWS Command Line Interface *.
+ Docker debe estar instalado en el sistema local. Para obtener más información, consulte [About Docker CE](https://docs.docker.com/install/) en la documentación de Docker.
# Creación de una imagen de contenedor
Puede utilizar el `AWS_BATCH_JOB_ARRAY_INDEX` en una definición de trabajo en el parámetro de comando. Sin embargo, se recomienda crear una imagen contenedor que utilice la variable en un script de punto de entrada en su lugar. En esta sección, se describe cómo crear dicha imagen de contenedor.
**Para compilar la imagen de contenedor de Docker**
1. Cree un directorio nuevo para utilizarlo como espacio de trabajo de la imagen de Docker y desplácese a él.
1. Cree un archivo denominado `colors.txt` en el directorio del espacio de trabajo y pegue en él el contenido siguiente.
```
red
orange
yellow
green
blue
indigo
violet
```
1. Cree un archivo denominado `print-color.sh` en el directorio del espacio de trabajo y pegue en él el contenido siguiente.
**nota**
La variable `LINE` se establece en `AWS_BATCH_JOB_ARRAY_INDEX` \$1 1 debido a que el índice de matriz empieza en 0, pero los números de línea empiezan en 1. La variable `COLOR` se establece en el color de `colors.txt` que está asociado a su número de línea.
```
#!/bin/sh
LINE=$((AWS_BATCH_JOB_ARRAY_INDEX + 1))
COLOR=$(sed -n ${LINE}p /tmp/colors.txt)
echo My favorite color of the rainbow is $COLOR.
```
1. Cree un archivo denominado `Dockerfile` en el directorio del espacio de trabajo y pegue en él el contenido siguiente. Este Dockerfile copia los archivos anteriores en el contenedor y configura el script de punto de entrada para que se ejecute al iniciarse el contenedor.
```
FROM busybox
COPY print-color.sh /tmp/print-color.sh
COPY colors.txt /tmp/colors.txt
RUN chmod +x /tmp/print-color.sh
ENTRYPOINT /tmp/print-color.sh
```
1. Compile la imagen de Docker.
```
$ docker build -t print-color .
```
1. Pruebe el contenedor con el script siguiente. Este script establece la variable `AWS_BATCH_JOB_ARRAY_INDEX` en 0 localmente y, a continuación, incrementa su valor para simular lo que haría un trabajo de matriz con siete elementos secundarios.
```
$ AWS_BATCH_JOB_ARRAY_INDEX=0
while [ $AWS_BATCH_JOB_ARRAY_INDEX -le 6 ]
do
docker run -e AWS_BATCH_JOB_ARRAY_INDEX=$AWS_BATCH_JOB_ARRAY_INDEX print-color
AWS_BATCH_JOB_ARRAY_INDEX=$((AWS_BATCH_JOB_ARRAY_INDEX + 1))
done
```
Se genera la siguiente salida.
```
My favorite color of the rainbow is red.
My favorite color of the rainbow is orange.
My favorite color of the rainbow is yellow.
My favorite color of the rainbow is green.
My favorite color of the rainbow is blue.
My favorite color of the rainbow is indigo.
My favorite color of the rainbow is violet.
```
# Enviar la imagen a Amazon ECR
Ahora que ha compilado y probado el contenedor de Docker, debe enviarlo a un repositorio de imágenes. En este ejemplo se utiliza Amazon ECR, pero puede utilizar otro registro, como DockerHub.
1. Cree un repositorio de imágenes de Amazon ECR para almacenar la imagen de contenedor. En este ejemplo solo se utiliza el AWS CLI, pero también se puede utilizar el Consola de administración de AWS. Para obtener más información, consulte [Creación de un repositorio](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-create.html) en la *Guía del usuario de Amazon Elastic Container Registry*.
```
$ aws ecr create-repository --repository-name print-color
```
1. Etiquete la imagen `print-color` con el URI del repositorio de Amazon ECR que se obtuvo del paso anterior.
```
$ docker tag print-color aws_account_id.dkr.ecr.region.amazonaws.com/print-color
```
1. Inicie sesión en su registro Amazon ECR. Para obtener más información, consulte [Autenticación de registros](https://docs.aws.amazon.com/AmazonECR/latest/userguide/Registries.html#registry_auth) en la *Guía del usuario de Amazon Elastic Container Registry*.
```
$ aws ecr get-login-password \
--region region | docker login \
--username AWS \
--password-stdin aws_account_id.dkr.ecr.region.amazonaws.com
```
1. Envíe la imagen a Amazon ECR.
```
$ docker push aws_account_id.dkr.ecr.region.amazonaws.com/print-color
```
# Crear y registrar una definición de trabajo
Ahora que su imagen de Docker está en un registro de imágenes, puede especificarla en una definición de AWS Batch trabajo. Posteriormente, puede utilizarlo para ejecutar un trabajo de matriz. En este ejemplo se utiliza la API de AWS CLI. Sin embargo, también puede utilizar la Consola de administración de AWS. Para obtener más información, consulte [Creación de una definición de trabajo de un solo nodo](create-job-definition.md).
**Para crear una definición de trabajo**
1. Cree un archivo denominado `print-color-job-def.json` en el directorio del espacio de trabajo y pegue en él el contenido siguiente. Reemplace el URI del repositorio de imágenes por el URI de su propia imagen.
```
{
"jobDefinitionName": "print-color",
"type": "container",
"containerProperties": {
"image": "aws_account_id.dkr.ecr.region.amazonaws.com/print-color",
"resourceRequirements": [
{
"type": "MEMORY",
"value": "250"
},
{
"type": "VCPU",
"value": "1"
}
]
}
}
```
1. Registre la definición del trabajo con AWS Batch.
```
$ aws batch register-job-definition --cli-input-json file://print-color-job-def.json
```
# Envíe un trabajo AWS Batch de matriz
Después de registrar la definición de su trabajo, puede enviar un trabajo de AWS Batch matriz que utilice su nueva imagen de contenedor.
**Para enviar un trabajo AWS Batch de matriz**
1. Cree un archivo denominado `print-color-job.json` en el directorio del espacio de trabajo y pegue en él el contenido siguiente.
**nota**
En este ejemplo, se utiliza la cola de trabajos mencionada en la sección [Requisitos previos](array-tutorial-prereqs.md).
```
{
"jobName": "print-color",
"jobQueue": "existing-job-queue",
"arrayProperties": {
"size": 7
},
"jobDefinition": "print-color"
}
```
1. Envíe el trabajo a su lista de AWS Batch trabajos. Anote el ID de trabajo que se devuelve como resultado.
```
$ aws batch submit-job --cli-input-json file://print-color-job.json
```
1. Describa el estado del trabajo y espere a que el trabajo adopte el valor `SUCCEEDED`.
## Ver los registros del trabajo de matriz
Cuando su trabajo alcance el `SUCCEEDED` estado, podrá ver los CloudWatch registros desde el contenedor del trabajo.
**Para ver los registros de su trabajo en CloudWatch Registros**
1. Abre la AWS Batch consola en [https://console.aws.amazon.com/batch/](https://console.aws.amazon.com/batch/).
1. En el panel de navegación izquierdo, elija **Jobs (Trabajos)**.
1. En **Job queue (Cola de trabajos)**, seleccione una cola.
1. En la sección **Status (Estado)**, elija **succeeded (realizado correctamente)**.
1. Para mostrar todos los trabajos secundarios del trabajo de matriz, seleccione el ID de trabajo que se ha obtenido en la sección anterior.
1. Para ver los logs del contenedor del trabajo, seleccione uno de los trabajos secundarios y elija **View logs (Ver logs)**.
![\[Registros del contenedor de trabajos de matriz\]](http://docs.aws.amazon.com/es_es/batch/latest/userguide/images/array-logs.png)
1. Vea los logs del otro trabajo secundario. Cada trabajo devuelve un color diferente del arco iris.
# Ejecución de trabajos de GPU
Los trabajos de GPU le ayudan a ejecutar trabajos que utilizan los de una instancia. GPUs
Se admiten los siguientes tipos de instancias de Amazon EC2 basadas en GPU. Para obtener más información, consulte [instancias G3 de Amazon EC2](https://aws.amazon.com/ec2/instance-types/g3/), [instancias G4 de Amazon EC2](https://aws.amazon.com/ec2/instance-types/g4/), [instancias G5 de Amazon EC2](https://aws.amazon.com/ec2/instance-types/g5/), [instancias G6 de Amazon EC2](https://aws.amazon.com/ec2/instance-types/g6/), [instancias P2 de Amazon EC2](https://aws.amazon.com/ec2/instance-types/p2/), [instancias P3 de Amazon EC2](https://aws.amazon.com/ec2/instance-types/p3/), [instancias P4d de Amazon EC2](https://aws.amazon.com/ec2/instance-types/p4/), [instancias P5 de Amazon EC2](https://aws.amazon.com/ec2/instance-types/p5/), [instancias P6 de Amazon EC2](https://aws.amazon.com/ec2/instance-types/p6/), [instancias Trn1 de Amazon EC2](https://aws.amazon.com/ec2/instance-types/trn1/), [instancias Trn2 de Amazon EC2](https://aws.amazon.com/ec2/instance-types/trn2/), [instancias de Inf1 de Amazon EC2](https://aws.amazon.com/ec2/instance-types/inf1/), [instancias Inf2 de Amazon EC2](https://aws.amazon.com/ec2/instance-types/inf2/), [instancias Dl1 de Amazon EC2](https://aws.amazon.com/ec2/instance-types/dl1/) e [instancias Dl2 de Amazon EC2](https://aws.amazon.com/ec2/instance-types/dl2q/).
| Tipo de instancia | GPUs | Memoria de GPU | v CPUs | Memoria | Ancho de banda de la red |
| --- | --- | --- | --- | --- | --- |
| g3s.xlarge | 1 | 8 GiB | 4 | 30,5 GiB | 10 Gbps |
| g3.4xlarge | 1 | 8 GiB | 16 | 122 GiB | Hasta 10 Gbps |
| g3.8xlarge | 2 | 16 GiB | 32 | 244 GiB | 10 Gbps |
| g3.16xlarge | 4 | 32 GiB | 64 | 488 GiB | 25 Gbps |
| g4dn.xlarge | 1 | 16 GiB | 4 | 16 GiB | Hasta 25 Gbps. |
| g4dn.2xlarge | 1 | 16 GiB | 8 | 32 GiB | Hasta 25 Gbps. |
| g4dn.4xlarge | 1 | 16 GiB | 16 | 64 GiB | Hasta 25 Gbps. |
| g4dn.8xlarge | 1 | 16 GiB | 32 | 128 GiB | 50 Gbps |
| g4dn.12xlarge | 4 | 64 GiB | 48 | 192 GiB | 50 Gbps |
| g4dn.16xlarge | 1 | 16 GiB | 64 | 256 GiB | 50 Gbps |
| g5.xlarge | 1 | 24 GiB | 4 | 16 GiB | Hasta 10 Gbps |
| g5.2xlarge | 1 | 24 GiB | 8 | 32 GiB | Hasta 10 Gbps |
| g5.4xlarge | 1 | 24 GiB | 16 | 64 GiB | Hasta 25 Gbps. |
| g5.8xlarge | 1 | 24 GiB | 32 | 128 GiB | 25 Gbps |
| g5.16xlarge | 1 | 24 GiB | 64 | 256 GiB | 25 Gbps |
| g5.12xlarge | 4 | 96 GiB | 48 | 192 GiB | 40 Gbps |
| g5.24xlarge | 4 | 96 GiB | 96 | 384 GiB | 50 Gbps |
| g5.48xlarge | 8 | 192 GiB | 192 | 768 GiB | 100 Gbps |
| g5g.xlarge | 1 | 16 GiB | 4 | 8 GiB | Hasta 10 Gbps |
| g5g.2xlarge | 1 | 16 GiB | 8 | 16 GiB | Hasta 10 Gbps |
| g5g.4xlarge | 1 | 16 GiB | 16 | 32 GiB | Hasta 10 Gbps |
| g5g.8xlarge | 1 | 16 GiB | 32 | 64 GiB | 12 Gbps |
| g5g.16xlarge | 2 | 32 GiB | 64 | 128 GiB | 25 Gbps |
| g5g.metal | 2 | 32 GiB | 64 | 128 GiB | 25 Gbps |
| g6.xlarge | 1 | 24 GiB | 4 | 16 GiB | Hasta 10 Gbps |
| g6.2xlarge | 1 | 24 GiB | 8 | 32 GiB | Hasta 10 Gbps |
| g6.4xlarge | 1 | 24 GiB | 16 | 64 GiB | Hasta 25 Gbps. |
| g6.8xlarge | 1 | 24 GiB | 32 | 128 GiB | 25 Gbps |
| g6.16xlarge | 1 | 24 GiB | 64 | 256 GiB | 25 Gbps |
| g6.12xlarge | 4 | 96 GiB | 48 | 192 GiB | 40 Gbps |
| g6.24xlarge | 4 | 96 GiB | 96 | 384 GiB | 50 Gbps |
| g6.48xlarge | 8 | 192 GiB | 192 | 768 GiB | 100 Gbps |
| g6e.xlarge | 1 | 48 GiB | 4 | 32 GiB | Hasta 20 Gbps |
| g6e.2xlarge | 1 | 48 GiB | 8 | 64 GiB | Hasta 20 Gbps |
| g6e.4xlarge | 1 | 48 GiB | 16 | 128 GiB | 20 Gbps |
| g6g.8xlarge | 1 | 48 GiB | 32 | 256 GiB | 25 Gbps |
| g6e.16xlarge | 1 | 48 GiB | 64 | 512 GiB | 35 Gbps |
| g6e.12xlarge | 4 | 192 GiB | 48 | 384 GiB | 100 Gbps |
| g6e.24xlarge | 4 | 192 GiB | 96 | 768 GiB | 200 Gbps |
| g6e.48xlarge | 8 | 384 GiB | 192 | 1536 GiB | 400 Gbps |
| gr6.4xlarge | 1 | 24 GiB | 16 | 128 GiB | Hasta 25 Gbps. |
| gr6.8xlarge | 1 | 24 GiB | 32 | 256 GiB | 25 Gbps |
| p2.xlarge | 1 | 12 GiB | 4 | 61 GiB | Alto |
| p2.8xlarge | 8 | 96 GiB | 32 | 488 GiB | 10 Gbps |
| p2.16xlarge | 16 | 192 GiB | 64 | 732 GiB | 20 Gbps |
| p3.2xlarge | 1 | 16 GiB | 8 | 61 GiB | Hasta 10 Gbps |
| p3.8xlarge | 4 | 64 GiB | 32 | 244 GiB | 10 Gbps |
| p3.16xlarge | 8 | 128 GiB | 64 | 488 GiB | 25 Gbps |
| p3dn.24xlarge | 8 | 256 GiB | 96 | 768 GiB | 100 Gbps |
| p4d.24xlarge | 8 | 320 GiB | 96 | 1152 GiB | 400 Gbps |
| p4de.24xlarge | 8 | 640 GiB | 96 | 1152 GiB | 400 Gbps |
| p5.48xlarge | 8 | 640 GiB | 192 | 2 TiB | 3200 Gbps |
| p5e.48xlarge | 8 | 1128 GiB | 192 | 2 TiB | 3200 Gbps |
| p5en.48xlarge | 8 | 1128 GiB | 192 | 2 TiB | 3200 Gbps |
| p6-b200.48xlarge | 8 | 1440 GiB | 192 | 2 TiB | 100 Gbps |
| trn1.2xlarge | 1 | 32 GiB | 8 | 32 GiB | Hasta 12,5 Gbps |
| trn1.32xlarge | 16 | 512 GiB | 128 | 512 GiB | 800 Gbps |
| trn1n.32xlarge | 16 | 512 GiB | 128 | 512 GiB | 1600 Gbps |
| trn2.48xlarge | 16 | 1,5 TiB | 192 | 2 TiB | 3,2 Tbps |
| inf1.xlarge | 1 | 8 GiB | 4 | 8 GiB | Hasta 25 Gbps. |
| inf1.2xlarge | 1 | 8 GiB | 8 | 16 GiB | Hasta 25 Gbps. |
| inf1.6xlarge | 4 | 32 GiB | 24 | 48 GiB | 25 Gbps |
| inf1.24xlarge | 16 | 128 GiB | 96 | 192 GiB | 100 Gbps |
| inf2.xlarge | 1 | 32 GiB | 4 | 16 GiB | Hasta 15 Gbps |
| inf2.8xlarge | 1 | 32 GiB | 32 | 128 GiB | Hasta 25 Gbps. |
| inf2.24xlarge | 6 | 192 GiB | 96 | 384 GiB | 50 Gbps |
| inf2.48xlarge | 12 | 384 GiB | 192 | 768 GiB | 100 Gbps |
| dl1.24xlarge | 8 | 256 GiB | 96 | 768 GiB | 400 Gbps |
| dl2q.24xlarge | 8 | 128 GiB | 96 | 768 GiB | 100 Gbps |
**nota**
Para trabajos de GPU, AWS Batch solo admite tipos de instancias que tengan NVIDIA GPUs. Por ejemplo, la familia de [https://aws.amazon.com/ec2/instance-types/g4/#Amazon_EC2_G4ad_instances](https://aws.amazon.com/ec2/instance-types/g4/#Amazon_EC2_G4ad_instances) no es compatible con la programación de GPU. Puede seguir [https://aws.amazon.com/ec2/instance-types/g4/#Amazon_EC2_G4ad_instances](https://aws.amazon.com/ec2/instance-types/g4/#Amazon_EC2_G4ad_instances)utilizándolo AWS Batch definiendo solo los requisitos de vcpu y memoria en la definición del trabajo y, a continuación, accediendo a las GPU del host directamente mediante la personalización en una [plantilla de lanzamiento de Amazon EC2, los datos de usuario](launch-templates.md#lt-user-data.title) con una AMI optimizada para cómputo de Amazon ECS o Amazon EKS, o una AMI personalizada para usar AMD. GPUs
Los tipos de instancias que utilizan una ARM64 arquitectura son compatibles con los trabajos de GPU con datos de usuario personalizados AMIs proporcionados a Amazon EC2 AWS Batch o para acceder a ellos GPUs mediante códigos y configuraciones personalizados. Por ejemplo, las familias de instancias de [https://aws.amazon.com/ec2/instance-types/g5g/](https://aws.amazon.com/ec2/instance-types/g5g/).
El parámetro [ResourceRequirements](job_definition_parameters.md#ContainerProperties-resourceRequirements) de la definición del trabajo especifica el número de tareas que se van GPUs a fijar al contenedor. Este número de no GPUs está disponible para ningún otro trabajo que se ejecute en esa instancia durante ese trabajo. Todos los tipos de instancia de un entorno de computación que ejecutan los trabajos de GPU deben pertenecer a las familias de instancias de `p3`, `p4`, `p5`, `p6`, `g3`, `g3s`, `g4`, `g5` o `g6`. Si no lo hace así, un trabajo de GPU podría quedar bloqueado en el estado `RUNNABLE`.
Los trabajos que no utilizan el se GPUs pueden ejecutar en instancias de GPU. Sin embargo, es posible que su ejecución en las instancias de GPU cueste más que en instancias similares que no sean de GPU. En función de la vCPU específica, la memoria y el tiempo necesario, estos trabajos sin GPU pueden bloquear la ejecución de los trabajos de GPU.
**Topics**
+ [
# Creación de un clúster de Kubernetes basado en GPU en Amazon EKS
](create-gpu-cluster-eks.md)
+ [
# Creación de una definición de trabajo de GPU de Amazon EKS
](create-eks-gpu-job-definition.md)
+ [
# Ejecución de un trabajo de GPU en el clúster de Amazon EKS
](run-gpu-job-eks-cluster.md)
# Creación de un clúster de Kubernetes basado en GPU en Amazon EKS
Antes de crear un clúster de Kubernetes basado en GPU en Amazon EKS, debe haber completado los pasos que se indican en [Cómo empezar con AWS Batch Amazon EKS](getting-started-eks.md). Además, tenga en cuenta lo siguiente:
+ AWS Batch admite tipos de instancias con NVIDIA GPUs.
+ De forma predeterminada, AWS Batch selecciona la AMI acelerada de Amazon EKS con la Kubernetes versión que coincide con la versión del plano de control del clúster de Amazon EKS.
```
$ cat < ./batch-eks-gpu-ce.json
{
"computeEnvironmentName": "My-Eks-GPU-CE1",
"type": "MANAGED",
"state": "ENABLED",
"eksConfiguration": {
"eksClusterArn": "arn:aws:eks:::cluster/",
"kubernetesNamespace": "my-aws-batch-namespace"
},
"computeResources": {
"type": "EC2",
"allocationStrategy": "BEST_FIT_PROGRESSIVE",
"minvCpus": 0,
"maxvCpus": 1024,
"instanceTypes": [
"p3dn.24xlarge",
"p4d.24xlarge"
],
"subnets": [
""
],
"securityGroupIds": [
""
],
"instanceRole": ""
}
}
EOF
$ aws batch create-compute-environment --cli-input-json file://./batch-eks-gpu-ce.json
```
AWS Batch no administra el complemento del dispositivo NVIDIA GPU en su nombre. Debe instalar este complemento en su clúster de Amazon EKS y permitir que se dirija a los AWS Batch nodos. Para obtener más información, consulte [Habilitar GPU Support en Kubernetes](https://github.com/NVIDIA/k8s-device-plugin#enabling-gpu-support-in-kubernetes) on GitHub.
Para configurar el complemento del NVIDIA dispositivo (`DaemonSet`) para que se dirija a los AWS Batch nodos, ejecute los siguientes comandos.
```
# pull nvidia daemonset spec
$ curl -O https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v0.12.2/nvidia-device-plugin.yml
# using your favorite editor, add Batch node toleration
# this will allow the DaemonSet to run on Batch nodes
- key: "batch.amazonaws.com/batch-node"
operator: "Exists"
$ kubectl apply -f nvidia-device-plugin.yml
```
No se recomienda mezclar cargas de trabajo informáticas (CPU y memoria) con cargas de trabajo basadas en GPU en las mismas combinaciones de entorno de computación y cola de tareas. Esto se debe a que las tareas informáticas pueden consumir la capacidad de la GPU.
Para adjuntar colas de trabajos, ejecute los siguientes comandos.
```
$ cat < ./batch-eks-gpu-jq.json
{
"jobQueueName": "My-Eks-GPU-JQ1",
"priority": 10,
"computeEnvironmentOrder": [
{
"order": 1,
"computeEnvironment": "My-Eks-GPU-CE1"
}
]
}
EOF
$ aws batch create-job-queue --cli-input-json file://./batch-eks-gpu-jq.json
```
# Creación de una definición de trabajo de GPU de Amazon EKS
Solo `nvidia.com/gpu` se admite en este momento y el valor del recurso que establezca debe ser un número entero. No puede usar fracciones de GPU. Para obtener más información, consulte [Programación GPUs](https://kubernetes.io/docs/tasks/manage-gpus/scheduling-gpus/) en la *Kubernetesdocumentación*.
Para registrar una definición de trabajo de GPU para Amazon EKS, ejecute los siguientes comandos.
```
$ cat < ./batch-eks-gpu-jd.json
{
"jobDefinitionName": "MyGPUJobOnEks_Smi",
"type": "container",
"eksProperties": {
"podProperties": {
"hostNetwork": true,
"containers": [
{
"image": "nvcr.io/nvidia/cuda:10.2-runtime-centos7",
"command": ["nvidia-smi"],
"resources": {
"limits": {
"cpu": "1",
"memory": "1024Mi",
"nvidia.com/gpu": "1"
}
}
}
]
}
}
}
EOF
$ aws batch register-job-definition --cli-input-json file://./batch-eks-gpu-jd.json
```
# Ejecución de un trabajo de GPU en el clúster de Amazon EKS
El recurso de la GPU no se puede comprimir. AWS Batch **crea una especificación de módulo para los trabajos de GPU en la que el valor de la **solicitud** es igual al valor de los límites.** Se trata de un requisito de Kubernetes.
Para reiniciar un trabajo de GPU, ejecute los siguientes comandos.
```
$ aws batch submit-job --job-queue My-Eks-GPU-JQ1 --job-definition MyGPUJobOnEks_Smi --job-name My-Eks-GPU-Job
# locate information that can help debug or find logs (if using Amazon CloudWatch Logs with Fluent Bit)
$ aws batch describe-jobs --job | jq '.jobs[].eksProperties.podProperties | {podName, nodeName}'
{
"podName": "aws-batch.f3d697c4-3bb5-3955-aa6c-977fcf1cb0ca",
"nodeName": "ip-192-168-59-101.ec2.internal"
}
```
# Vea los AWS Batch trabajos en una cola de trabajos
Vea y filtre los trabajos de AWS Batch. Esta característica ofrece una opción para visualizar una cola de trabajos existente y filtrar trabajos según una de las tres opciones.
La búsqueda y el filtrado tienen la capacidad de recuperar trabajos que no están en un estado terminal (`SUCCEEDED` o `FAILED`). Una vez que el estado de un trabajo sea `SUCCEEDED` o `FAILED`, podrá recuperarlo durante un máximo de siete días. Aún puedes ver los EventBridge registros de un trabajo CloudWatch o de Amazon.
Utilice este procedimiento para enumerar todos los trabajos de una cola de trabajos en la AWS Batch consola. Si lo desea, utilice el campo **Filtrar results** para restringir los resultados en función de los criterios que especifique.
1. Vaya a la [consola de AWS Batch](https://console.aws.amazon.com/batch/home).
1. En el panel de navegación, seleccione **Trabajos**.
1. Expanda la lista desplegable **Cola de trabajos** y elija la cola de trabajos en la que desea buscar.
**nota**
Puede buscar trabajos en una sola cola de trabajos a la vez.
1. En el campo **Filtrar resultados**, introduzca las palabras clave que desee incluir en los resultados. Puede usar este campo para filtrar por **nombre**, **estado** o **ID del trabajo**. Según la propiedad, es posible que deba definir operadores adicionales, como igual a (=) o que contengan (:), que debe definir.
**nota**
SageMaker Las colas de trabajos de formación solo admiten el filtrado por **nombre e ID** de **trabajo**
1. Elija **Buscar**.
# AWS Batch Busque trabajos en una cola de trabajos
Puede buscar y filtrar sus trabajos AWS Batch mediante la búsqueda de empleo. Esta característica ofrece una opción para buscar en una cola de trabajos existente y filtrar sus trabajos.
La búsqueda y el filtrado tienen la capacidad de recuperar trabajos que no están en un estado terminal (`SUCCEEDED` o `FAILED`). Una vez que el estado de un trabajo sea `SUCCEEDED` o `FAILED`, podrá recuperarlo durante un máximo de siete días. Aún puedes ver los EventBridge registros de un trabajo CloudWatch o de Amazon.
Para buscar con varios criterios al mismo tiempo, utilice la característica **Búsqueda avanzada**. Por ejemplo, puede incluir uno o todos de los siguientes filtros: **Estado**, **Intervalo de fechas** y **Criterios adicionales** (como nombre del trabajo, definición del trabajo o ID del trabajo).
## Buscar AWS Batch trabajos (AWS consola)
Utilice este procedimiento para buscar los trabajos en una cola de trabajos en la AWS Batch consola.
1. Vaya a la [consola de AWS Batch](https://console.aws.amazon.com/batch/home).
1. En el panel de navegación, seleccione **Trabajos**.
1. Active la **Búsqueda avanzada**.
1. Expanda la lista desplegable **Cola de trabajos** y elija la cola de trabajos en la que desea buscar.
**nota**
Puede buscar trabajos en una sola cola de trabajos a la vez.
1. En las **opciones de búsqueda**:
1. En la lista desplegable de **Estados**, puedes elegir uno o más estados por los que filtrar. Para obtener más información, consulte [Estados de trabajo](job_states.md) y [Estado del trabajo de servicio](service-job-status.md).
**nota**
Los padres de los trabajos de matriz se actualizan `PENDING` cuando se actualiza un trabajo secundario `RUNNABLE` y permanecen en `PENDING` su estado mientras los trabajos secundarios se están ejecutando. Para ver estos trabajos, filtre por `PENDING` estado hasta que todos los trabajos secundarios alcancen un estado terminal.
1. (Opcional) Elija un **Intervalo de fechas** para filtrar los resultados en función de un rango de fechas y horas.
+ Seleccione el **Modo relativo** para buscar trabajos que tengan una fecha de creación en un intervalo de tiempo que cuente hacia atrás desde la fecha y la hora actuales.
+ Seleccione el **Modo absoluto** para buscar trabajos que tengan una fecha de creación en el intervalo de fechas y horas que especifique.
1. En el campo **Criterios adicionales**, introduzca las palabras clave que desee incluir en los resultados de búsqueda. Por ejemplo, puede usar este campo para buscar por **nombre de trabajo**, **definición de trabajo**, **ID de trabajo** o **identificador de recurso compartido**. Según la propiedad, es posible que deba definir operadores adicionales, como igual a (=) o que contengan (:), que debe definir.
**nota**
SageMaker Las colas de trabajos de formación solo admiten el filtrado por **nombre e ID** de **trabajo**
**nota**
Al filtrar por **identificador de recurso compartido**, también puede especificar el estado de un trabajo. Se trata de una excepción a la restricción, en la que otros filtros excluyen el filtrado del estado del trabajo.
1. Elija **Buscar**.
## Buscar y filtrar AWS Batch trabajos (AWS CLI)
Use este procedimiento para enumerar todos los trabajos de una cola de trabajos con AWS CLI. Si lo desea, utilice el parámetro **-filters** para restringir los resultados en función de los criterios que especifique.
------
#### [ Search job queue (AWS CLI) ]
Puede utilizar el comando [list-jobs](https://docs.aws.amazon.com/cli/latest/reference/batch/list-jobs.html) para buscar y filtrar una cola de trabajos.
Por ejemplo, puede buscar una cola de trabajos según el nombre del trabajo:
```
aws batch list-jobs \
--job-queue my-job-queue \
--filters name=JOB_NAME,values="my-job"
```
Filtrar trabajos por identificador de recursos compartidos:
```
aws batch list-jobs \
--job-queue my-job-queue \
--filters name=SHARE_IDENTIFIER,values="my-share"
```
Al filtrar por identificador de recurso compartido, puede incluir el estado del trabajo:
```
aws batch list-jobs \
--job-queue my-job-queue \
--job-status RUNNING \
--filters name=SHARE_IDENTIFIER,values="my-share"
```
En el comando anterior, realice los siguientes cambios:
+ *my-job-queue*Sustitúyalo por el nombre de la cola de trabajos.
+ *my-job*Sustitúyalo por el nombre de tu trabajo.
+ *my-share*Sustitúyalo por el identificador de recurso compartido por el que quieras filtrar.
------
#### [ Search service job queue (AWS CLI) ]
Puede usar el [list-service-jobs](https://docs.aws.amazon.com/cli/latest/reference/batch/list-service-jobs.html)comando para buscar y filtrar una cola de trabajos de servicio.
Por ejemplo, puede buscar una cola de trabajos de servicio según el nombre del trabajo:
```
aws batch list-service-jobs \
--job-queue my-sm-queue \
--filters name=JOB_NAME,values="my-sm-job"
```
Filtre los trabajos de servicio por identificador de recurso compartido:
```
aws batch list-service-jobs \
--job-queue my-sm-queue \
--filters name=SHARE_IDENTIFIER,values="my-share"
```
En el comando anterior, realice los siguientes cambios:
+ *my-sm-queue*Sustitúyalo por el nombre de la cola de trabajos de servicio.
+ *my-sm-job*Sustitúyalo por el nombre de tu trabajo de servicio.
+ *my-share*Sustitúyalo por el identificador de recurso compartido por el que quieras filtrar.
------
# Modos de red para AWS Batch trabajos
En la siguiente tabla se describen los modos de red y el uso típico de los tipos de AWS Batch trabajo. Consulte los enlaces de la columna “Tipo de trabajo” para obtener más información sobre las consideraciones y los comportamientos.
| Tipo de trabajo | Modos de redes compatibles | Uso normal |
| --- | --- | --- |
| [Trabajo sencillo ECS-EC2](jobs.md) | host | Se utiliza para las cargas de trabajo por lotes, fácilmente paralelas y escalables, que solo requieren la salida a la VPC definida en el entorno de computación. |
| [Trabajo paralelo de varios nodos ECS-EC2](multi-node-parallel-jobs.md) | awsvpc | Se utiliza para cargas de trabajo distribuidas entre varios host (nodos) estrechamente acopladas y modeladas como una sola tarea con comunicaciones coordinadas entre los nodos de tareas. |
| [Trabajo sencillo ECS-Fargate](when-to-use-fargate.md) | awsvpc | Tecnología sin servidor para cargas de trabajo por lotes fácilmente paralelas. Suele ser el modelo de trabajo con el menor costo total de propiedad y el mayor aislamiento de contenedores. |
| [Trabajo sencillo EKS-EC2](eks-jobs.md) | host y pod | Se utiliza para las cargas de trabajo por lotes, fácilmente paralelas y escalables, que solo requieren la salida a la VPC definida en el entorno de computación. El valor predeterminado es la red de host. |
| [Trabajo paralelo de varios nodos EKS-EC2](mnp-eks-jobs.md) | host y pod | Se utiliza para cargas de trabajo distribuidas entre varios host (nodos) estrechamente acopladas y modeladas como una sola tarea con comunicaciones coordinadas entre los nodos de pods. El valor predeterminado es la red de host. |
# Vea los registros de AWS Batch trabajos en CloudWatch los registros
Puede [configurar sus AWS Batch trabajos](using_cloudwatch_logs.md#using_cloudwatch_logs.title) para enviar información de registro a Amazon CloudWatch Logs. De esta manera, puede ver diferentes registros de sus trabajos en una ubicación práctica. Para obtener más información, consulte [Uso CloudWatch de registros con AWS Batch](using_cloudwatch_logs.md).
También puede usar **los registros de tareas** de la AWS Batch consola para supervisar o solucionar problemas de una AWS Batch tarea.
1. Abra la [consola de AWS Batch](https://console.aws.amazon.com/batch/home).
1. Elija **Jobs (Trabajos)**. Para obtener información más detallada sobre cómo ordenar y filtrar los trabajos de la cola de trabajos, consulte [Vea los AWS Batch trabajos en una cola de trabajos](view-jobs.md) y [Buscar para trabajos en una cola de trabajos](searching-filtering-jobs.md)
1. En **Cola de trabajos**, elija la cola de trabajos que desee.
**sugerencia**
Si hay varios trabajos en la cola de trabajos, puede activar la **Búsqueda y filtrado** para encontrar un trabajo más rápido. Para obtener más información, consulte [AWS Batch Busque trabajos en una cola de trabajos](searching-filtering-jobs.md).
1. En **Estado**, elija el estado del trabajo que desee.
1. Seleccione el trabajo que desee y se abrirá la página de **Detalles**.
1. En la página de **Detalles**, desplácese hacia abajo hasta el **Nombre del flujo de registro** y haga clic en el enlace. El enlace abre la página de Amazon CloudWatch Logs del trabajo.
1. (Opcional) Si es la primera vez que ve los registros, es posible que le pidan autorización.
Si **se requiere autorización**, introduce y**OK**, a continuación, selecciona **Autorizar** para aceptar CloudWatch los cargos de Amazon.
**nota**
Para revocar tu autorización de CloudWatch cobro:
En el panel de navegación de la izquierda, elija **Permisos**.
Para **Registros de trabajos**, seleccione **Editar**.
Desactive la CloudWatch casilla **Autorizar el uso de Batch**.
Seleccione **Save changes (Guardar cambios)**.
# Revise la información del AWS Batch trabajo
Puede revisar la información del trabajo AWS Batch , como el estado, la definición del trabajo y la información del contenedor.
1. Abra la [consola de AWS Batch](https://console.aws.amazon.com/batch/home).
1. Elija **Jobs (Trabajos)**.
1. En **Cola de trabajos**, elija la cola de trabajos que desee.
**sugerencia**
Si hay varios trabajos en la cola de trabajos, puede activar **Buscar y filtrar** para encontrar un trabajo más rápido. Para obtener más información, consulte [AWS Batch Busque trabajos en una cola de trabajos](searching-filtering-jobs.md).
1. Elija el trabajo que desee.
**nota**
También puede usar AWS Command Line Interface (AWS CLI) para ver los detalles de un AWS Batch trabajo. Para obtener más información, consulte [describe-jobs](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/batch/describe-jobs.html) en la [AWS CLI Referencia de comandos](https://docs.aws.amazon.com/cli/latest/reference/).