Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Jobs
I lavori sono l'unità di lavoro da AWS Batch cui è iniziata. I job possono essere richiamati come applicazioni containerizzate eseguite su istanze di container Amazon ECS in un cluster ECS.
I processi containerizzati possono fare riferimento a un'immagine, a un comando e ai parametri di un container. Per ulteriori informazioni, consulta [JobDefinition](https://docs.aws.amazon.com/batch/latest/APIReference/API_JobDefinition.html).
È possibile inviare un numero elevato di processi semplici e indipendenti.
**Topics**
+ [Tutorial: invia un lavoro](submit_job.md)
+ [Lavori di assistenza in AWS Batch](service-jobs.md)
+ [Job stati](job_states.md)
+ [AWS Batch variabili dell'ambiente di lavoro](job_env_vars.md)
+ [Ritentativi di lavoro automatizzati](job_retries.md)
+ [Dipendenze dal lavoro](job_dependencies.md)
+ [Job timeout](job_timeouts.md)
+ [Offerte di lavoro Amazon EKS](eks-jobs.md)
+ [Lavori paralleli multinodo](multi-node-parallel-jobs.md)
+ [Lavori paralleli multinodo su Amazon EKS](mnp-eks-jobs.md)
+ [Lavori di matrice](array_jobs.md)
+ [Esegui lavori GPU](gpu-jobs.md)
+ [Visualizza i AWS Batch lavori in una coda di lavoro](view-jobs.md)
+ [AWS Batch Cerca offerte di lavoro in una coda di lavoro](searching-filtering-jobs.md)
+ [Modalità di rete per i lavori AWS Batch](networking-modes-jobs.md)
+ [Visualizza i registri dei AWS Batch lavori in CloudWatch Logs](review-job-logs.md)
+ [Rivedi le informazioni sul AWS Batch lavoro](review-job-info.md)
# Tutorial: invia un lavoro
Dopo aver registrato una definizione di processo, è possibile inviarla come processo a una coda di AWS Batch lavoro. È possibile sovrascrivere molti dei parametri specificati nella definizione del processo in fase di esecuzione.
**Come inviare un processo**
1. Aprire la AWS Batch console all'indirizzo [https://console.aws.amazon.com/batch/](https://console.aws.amazon.com/batch/).
1. Dalla barra di navigazione, seleziona quello Regione AWS da usare.
1. Nel riquadro di navigazione scegliere **Jobs (Processi)**.
1. Scegli **Invia nuovo lavoro**.
1. In **Nome**, inserisci un nome univoco per la definizione del lavoro. Il nome può avere una lunghezza massima di 128 caratteri. Deve contenere lettere maiuscole e minuscole, numeri, trattini (-) e caratteri di sottolineatura (\$1).
1. Per **Job definition**, scegli una definizione di job esistente per il tuo job. Per ulteriori informazioni, consulta [Creare una definizione di processo a nodo singolo](create-job-definition.md).
1. Per **Job queue**, scegli una coda lavori esistente. Per ulteriori informazioni, consulta [Creare una coda di lavoro](create-job-queue.md).
1. Per **Job dependencies**, scegli **Add Job dependencies**.
1. Per **Job id**, inserisci l'ID del lavoro per eventuali dipendenze. Quindi scegli **Aggiungi dipendenze lavorative**. Un lavoro può avere fino a 20 dipendenze. Per ulteriori informazioni, consulta [Dipendenze dal lavoro](job_dependencies.md).
1. (Solo processi in array) Per **Array size** (Dimensione array), specifica una dimensione dell'array compresa tra 2 e 10.000.
1. (Facoltativo) Espandi **Tag**, quindi scegli **Aggiungi tag** per aggiungere tag alla risorsa. Inserisci una chiave e un valore opzionale, quindi scegli **Aggiungi tag**.
1. Scegli **Pagina successiva**.
1. Nella sezione **Job overrides:**
1.
(Facoltativo) Per **Priorità di pianificazione**, immettete un valore di priorità di pianificazione compreso tra 0 e 100. Ai valori più alti viene data una priorità maggiore.
1. (Facoltativo) In **Tentativi di lavoro**, immettete il numero massimo di volte in cui si AWS Batch tenta di spostare il lavoro a uno `RUNNABLE` stato. È possibile inserire un numero compreso tra 1 e 10. Per ulteriori informazioni, consulta [Ritentativi di lavoro automatizzati](job_retries.md).
1. (Facoltativo) Per il **timeout di esecuzione**, immettete il valore di timeout (in secondi). Il timeout di esecuzione è il periodo di tempo che intercorre prima che un lavoro incompiuto venga terminato. Se un tentativo supera la durata del timeout, viene interrotto e passa a uno stato. `FAILED` Per ulteriori informazioni, consulta [Job timeout](job_timeouts.md). Il valore minimo è 60 secondi.
**Importante**
Non fare affidamento sul fatto che i lavori eseguiti sulle risorse di Fargate durino per più di 14 giorni. Dopo 14 giorni, le risorse di Fargate potrebbero non essere più disponibili e il lavoro potrebbe essere interrotto.
1. (Facoltativo) Attiva i **tag Propagate** per propagare i tag dal processo e dalla definizione del processo al task Amazon ECS.
1. Espandere **Additional configuration (Configurazione aggiuntiva)**.
1. (Facoltativo) Per le **condizioni della strategia Retry**, scegli **Aggiungi** valutazione all'uscita. Inserisci almeno un valore di parametro, quindi scegli un'**azione**. Per ogni set di condizioni, **l'azione** deve essere impostata su **Riprova** o **Esci**. Queste azioni significano quanto segue:
+ **Riprova**: AWS Batch riprova fino al raggiungimento del numero di tentativi di lavoro specificato.
+ **Esci**: AWS Batch interrompe l'esecuzione di un nuovo tentativo.
**Importante**
Se scegli **Aggiungi valutazione all'uscita**, configura almeno un parametro e scegli un'**azione** oppure scegli **Rimuovi valutazione all'uscita**.
1. Per **Parametri**, scegli **Aggiungi parametri** per aggiungere segnaposto di sostituzione dei parametri. **Quindi, inserite una **chiave e un valore opzionale**.**
1. Nella sezione **Container overrides:**
1. Per **Command**, inserisci i comandi nel campo come equivalenti all'array di stringhe **JSON**.
Questo parametro è mappato a `Cmd` nella sezione [Crea un container](https://docs.docker.com/engine/api/v1.38/#operation/ContainerCreate) dell'[API remota Docker](https://docs.docker.com/engine/api/v1.38/) e al parametro `COMMAND` di [https://docs.docker.com/engine/reference/commandline/run/](https://docs.docker.com/engine/reference/commandline/run/). Per ulteriori informazioni sul `CMD` parametro Docker, vedere [https://docs.docker.com/engine/reference/builder/](https://docs.docker.com/engine/reference/builder/#cmd) \$1cmd.
**Nota**
Questo parametro non può contenere una stringa vuota.
1. Per **v CPUs**, inserisci il numero di v CPUs da riservare per il contenitore. Questo parametro è mappato a `CpuShares` nella sezione [Create a container](https://docs.docker.com/engine/api/v1.38/#operation/ContainerCreate) di [Docker Remote API](https://docs.docker.com/engine/api/v1.38/) e l'opzione `--cpu-shares` a [https://docs.docker.com/engine/reference/commandline/run/](https://docs.docker.com/engine/reference/commandline/run/). Ogni vCPU equivale a 1.024 condivisioni di CPU. Devi specificare almeno un vCPU.
1. Per **Memoria**, inserisci il limite di memoria disponibile per il contenitore. Se il container tenta di superare la memoria specificata qui, viene arrestato. Questo parametro è mappato a `Memory` nella sezione [Create a container](https://docs.docker.com/engine/api/v1.38/#operation/ContainerCreate) di [Docker Remote API](https://docs.docker.com/engine/api/v1.38/) e l'opzione `--memory` a [https://docs.docker.com/engine/reference/commandline/run/](https://docs.docker.com/engine/reference/commandline/run/). Per un processo, è necessario specificare almeno 4 MiB di memoria.
**Nota**
Per massimizzare l'utilizzo delle risorse, dai la priorità alla memoria per i lavori di un tipo di istanza specifico. Per ulteriori informazioni, consulta [Gestione della memoria delle risorse di calcolo](memory-management.md).
1. (Facoltativo) Per **Numero di GPUs**, scegli il numero GPUs da riservare per il contenitore.
1. (Facoltativo) Per **le variabili di ambiente**, **scegliete Aggiungi variabile di ambiente** per aggiungere variabili di ambiente come coppie nome-valore. Queste variabili vengono passate al contenitore.
1. Scegli **Pagina successiva**.
1. Per **Job review**, rivedi i passaggi di configurazione. Se devi apportare modifiche, seleziona **Edit** (Modifica). Quando hai finito, scegli **Crea definizione del lavoro**.
# Lavori di assistenza in AWS Batch
AWS Batch i lavori di assistenza consentono di inviare richieste ai AWS servizi tramite code di AWS Batch lavoro. Attualmente, AWS Batch supporta SageMaker Training jobs as service jobs. A differenza dei job containerizzati che AWS Batch gestiscono l'esecuzione del container sottostante, i service job consentono di AWS Batch fornire funzionalità di pianificazione e accodamento dei job mentre il AWS servizio di destinazione (come l' SageMaker IA) gestisce l'esecuzione effettiva del lavoro.
AWS Batch for SageMaker Training jobs consente ai data scientist di inviare lavori di formazione con priorità a code configurabili, garantendo che i carichi di lavoro vengano eseguiti senza intervento non appena le risorse sono disponibili. Questa funzionalità affronta sfide comuni come il coordinamento delle risorse, la prevenzione di spese eccessive accidentali, il rispetto dei vincoli di budget, l'ottimizzazione dei costi con istanze riservate e l'eliminazione della necessità di coordinamento manuale tra i membri del team.
I lavori di assistenza differiscono dai lavori containerizzati in diversi modi principali:
+ **Invio del lavoro**: i lavori di assistenza devono essere inviati utilizzando l'[SubmitServiceJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitServiceJob.html)API. I lavori di assistenza non possono essere inviati tramite la AWS Batch console.
+ **Esecuzione del lavoro**: AWS Batch pianifica e mette in coda i lavori di servizio, ma il AWS servizio di destinazione esegue il carico di lavoro effettivo.
+ **Identificatori di risorse**: i job di servizio utilizzano quelli ARNs che contengono «service-job» anziché «job» per distinguerli dai job containerizzati.
Per iniziare con AWS Batch Service Jobs for Training, consulta. SageMaker [Guida introduttiva AWS Batch all' SageMaker IA](getting-started-sagemaker.md)
**Topics**
+ [Carichi utili per lavori di assistenza in AWS Batch](service-job-payload.md)
+ [Invia un lavoro di assistenza in AWS Batch](service-job-submit.md)
+ [Mappatura dello stato AWS Batch del lavoro del servizio allo stato dell' SageMaker IA](service-job-status.md)
+ [Strategie di riprova di lavoro nell'assistenza in AWS Batch](service-job-retries.md)
+ [Monitora i lavori di assistenza in coda AWS Batch](monitor-sagemaker-job-queue.md)
+ [Interrompere i lavori di assistenza](terminate-service-jobs.md)
# Carichi utili per lavori di assistenza in AWS Batch
Quando si inviano lavori di assistenza utilizzando [SubmitServiceJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitServiceJob.html), si forniscono due parametri chiave che definiscono il lavoro:`serviceJobType`, e`serviceRequestPayload`.
+ `serviceJobType`specifica quale AWS servizio eseguirà il lavoro. Per i lavori di SageMaker formazione, questo valore è`SAGEMAKER_TRAINING`.
+ `serviceRequestPayload`è una stringa con codifica JSON che contiene la richiesta completa che normalmente verrebbe inviata direttamente al servizio di destinazione. Per i lavori di SageMaker formazione, questo payload contiene gli stessi parametri che utilizzeresti con l'API AI. SageMaker [CreateTrainingJob](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateTrainingJob.html)
Per un elenco completo di tutti i parametri disponibili e delle relative descrizioni, consulta il riferimento all'[CreateTrainingJob](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateTrainingJob.html)API SageMaker AI. Tutti i parametri supportati da `CreateTrainingJob` possono essere inclusi nel payload del job di servizio.
Per esempi di altre configurazioni dei lavori di formazione [APIs, consulta la CLI SDKs e [SageMaker la AI](https://docs.aws.amazon.com/sagemaker/latest/dg/gs.html) Developer](https://docs.aws.amazon.com/sagemaker/latest/dg/api-and-sdk-reference-overview.html) Guide.
Si consiglia di utilizzare PySDK per la creazione di lavori di assistenza perché PySDK dispone di classi e utilità di supporto. [Per un esempio di utilizzo di PySDK, vedi esempi di intelligenza artificiale su. SageMaker ](https://github.com/aws/amazon-sagemaker-examples) GitHub
## Esempio di service job payload
L'esempio seguente mostra un semplice payload di lavoro di servizio per un processo di SageMaker formazione che esegue uno script di formazione «hello world»:
Questo payload verrebbe passato come stringa JSON al `serviceRequestPayload` parametro durante la chiamata. `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
}
}
```
# Invia un lavoro di assistenza in AWS Batch
Per inviare lavori di assistenza a AWS Batch, si utilizza l'[SubmitServiceJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitServiceJob.html)API. Puoi inviare lavori utilizzando il AWS CLI o SDK.
Se non disponi già di un ruolo di esecuzione, devi crearne uno prima di poter inviare il lavoro di servizio. Per creare il ruolo di esecuzione SageMaker AI, consulta [Come utilizzare i ruoli di esecuzione SageMaker AI](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-roles.html) nella *[guida per sviluppatori SageMaker AI](https://docs.aws.amazon.com/sagemaker/latest/dg/whatis.html)*.
## Flusso di lavoro per l'invio dei lavori di assistenza
Quando invii un lavoro di assistenza, segui questo AWS Batch flusso di lavoro:
1. AWS Batch riceve la `[SubmitServiceJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitServiceJob.html)` richiesta e convalida i parametri AWS Batch specifici. `serviceRequestPayload`Viene passato senza convalida.
1. Il lavoro entra nello `SUBMITTED` stato e viene inserito nella coda dei lavori specificata
1. AWS Batch valuta se c'è capacità disponibile nell'ambiente di servizio per i `RUNNABLE` lavori in prima fila
1. Se la capacità è disponibile, il lavoro passa `SCHEDULED` e il lavoro è stato passato all'IA SageMaker
1. Quando la capacità è stata acquisita e l' SageMaker IA ha scaricato i dati del lavoro di servizio, il job di servizio inizierà l'inizializzazione e il lavoro verrà modificato in`STARTING`.
1. Quando l' SageMaker IA inizia a eseguire il lavoro, il suo stato viene modificato in`RUNNING`.
1. Mentre l' SageMaker IA esegue il lavoro, ne AWS Batch monitora l'avanzamento e mappa gli stati del servizio in base agli stati del AWS Batch lavoro. Per informazioni dettagliate su come vengono mappati gli stati di lavoro del servizio, consulta [Mappatura dello stato AWS Batch del lavoro del servizio allo stato dell' SageMaker IA](service-job-status.md)
1. Quando il lavoro di assistenza è completato, passa a `SUCCEEDED` e qualsiasi output è pronto per essere scaricato.
## Prerequisiti
Prima di inviare un lavoro di assistenza, assicurati di avere:
+ **Ambiente di servizio**: un ambiente di servizio che definisce i limiti di capacità. Per ulteriori informazioni, consulta [Crea un ambiente di servizio in AWS Batch](create-service-environments.md).
+ **SageMaker job queue**: una coda di SageMaker lavoro per fornire la pianificazione dei lavori. Per ulteriori informazioni, consulta [Crea una coda SageMaker di lavoro di formazione in AWS Batch](create-sagemaker-job-queue.md).
+ Autorizzazioni **IAM: autorizzazioni** per creare e gestire code di AWS Batch lavoro e ambienti di servizio. Per ulteriori informazioni, consulta [AWS Batch Politiche, ruoli e autorizzazioni IAM](IAM_policies.md).
## Invia un lavoro di assistenza con la AWS CLI
Di seguito viene illustrato come inviare un lavoro di servizio utilizzando 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"
```
Per ulteriori informazioni sui `serviceRequestPayload` parametri, vedere[Carichi utili per lavori di assistenza in AWS Batch](service-job-payload.md).
# Mappatura dello stato AWS Batch del lavoro del servizio allo stato dell' SageMaker IA
Quando si inviano lavori a una coda di SageMaker lavoro utilizzando [SubmitServiceJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitServiceJob.html), AWS Batch gestisce il ciclo di vita del lavoro e mappa gli stati dei lavori su [stati di AWS Batch lavoro](job_states.md) di SageMaker formazione equivalenti. I lavori di assistenza, come i lavori di SageMaker formazione, seguono un ciclo di vita a stati diverso rispetto ai tradizionali lavori in container. Sebbene i lavori di assistenza condividano la maggior parte degli stati con i lavori relativi ai container, essi introducono lo `SCHEDULED` stato e presentano comportamenti diversi per quanto riguarda i tentativi di ripetizione, in particolare per quanto riguarda la gestione di errori di capacità insufficiente del servizio di destinazione.
La tabella seguente mostra lo stato del AWS Batch lavoro e lo Status/ corrispondente: SageMaker SecondaryStatus
| Stato del Batch | SageMaker Stato primario dell'IA | SageMaker Status secondario dell'IA | Description |
| --- | --- | --- | --- |
| SUBMITTED | N/D | N/D | Job inviato in coda, in attesa di valutazione da parte dello scheduler. |
| RUNNABLE | N/D | N/D | Job è in coda e pronto per la pianificazione. I lavori in questo stato vengono avviati non appena sono disponibili risorse sufficienti nell'ambiente di servizio. I posti di lavoro possono rimanere in questo stato a tempo indeterminato quando non sono disponibili risorse sufficienti. |
| SCHEDULED | InProgress | Pending | Processo di assistenza inviato con successo a AI SageMaker |
| STARTING | InProgress | Downloading | SageMaker Lavoro di formazione nel download di dati e immagini. La capacità lavorativa di formazione è stata acquisita e l'inizializzazione del lavoro è iniziata. |
| RUNNING | InProgress | Training | SageMaker Algoritmo di esecuzione dei lavori di formazione |
| RUNNING | InProgress | Uploading | SageMaker Processo di formazione: caricamento degli artefatti di output dopo il completamento dell'addestramento |
| SUCCEEDED | Completed | Completed | SageMaker Lavoro di formazione completato con successo. Caricamento terminato degli artefatti di output. |
| FAILED | Failed | Failed | SageMaker Il processo di formazione ha riscontrato un errore irreversibile. |
| FAILED | Stopped | Stopped | SageMaker Il processo di formazione è stato interrotto manualmente. StopTrainingJob |
# Strategie di riprova di lavoro nell'assistenza in AWS Batch
Le strategie di ripetizione dei lavori di assistenza consentono AWS Batch di riprovare automaticamente i lavori di servizio non riusciti in condizioni specifiche.
I lavori di assistenza possono richiedere più tentativi per diversi motivi:
+ **Problemi temporanei di servizio**: errori interni del servizio, rallentamenti o interruzioni temporanee possono causare il fallimento dei lavori durante l'invio o l'esecuzione.
+ **Errori di inizializzazione dell'addestramento: i** problemi durante l'avvio del processo, ad esempio problemi di acquisizione delle immagini o errori di inizializzazione, possono essere risolti riprovando.
Configurando strategie di riprova appropriate, è possibile migliorare le percentuali di successo del lavoro e ridurre la necessità di interventi manuali, in particolare per carichi di lavoro di formazione di lunga durata.
**Nota**
I job di assistenza riprovano automaticamente determinati tipi di errori, ad esempio errori di capacità insufficiente, senza consumare i tentativi di riprova configurati. La strategia di riprova consente di gestire principalmente altri tipi di errori, ad esempio errori di algoritmo o problemi di servizio.
## Configurazione delle strategie di ripetizione dei tentativi
Le strategie di ripetizione dei processi di servizio sono configurate utilizzando [ServiceJobRetryStrategy](https://docs.aws.amazon.com/batch/latest/APIReference/API_ServiceJobRetryStrategy.html), che supporta sia il semplice numero di tentativi che la logica di ripetizione condizionale.
### Configurazione del nuovo tentativo
La strategia di riprova più semplice specifica il numero di tentativi di nuovo tentativo da effettuare se un job di servizio fallisce:
```
{
"retryStrategy": {
"attempts": 3
}
}
```
Questa configurazione consente di ritentare il job di servizio fino a 3 volte in caso di errore.
**Importante**
Il `attempts` valore rappresenta il numero totale di volte in cui il lavoro può essere collocato nello `RUNNABLE` stato, incluso il tentativo iniziale. Il valore 3 indica che il processo verrà tentato inizialmente una volta, quindi ritentato fino a 2 volte in caso di esito negativo.
### Riprova la configurazione con evaluateOnExit
È possibile utilizzare il `evaluateOnExit` parametro per specificare le condizioni in base alle quali i lavori devono essere ritentati o lasciati fallire. Ciò è utile quando diversi tipi di errori richiedono una gestione diversa.
L'`evaluateOnExit`array può contenere fino a 5 strategie di ripetizione, ognuna delle quali specifica un'azione (`RETRY`o`EXIT`) e condizioni basate sui motivi dello stato:
```
{
"retryStrategy": {
"attempts": 5,
"evaluateOnExit": [
{
"action": "RETRY",
"onStatusReason": "Received status from SageMaker: InternalServerError*"
},
{
"action": "EXIT",
"onStatusReason": "Received status from SageMaker: ValidationException*"
},
{
"action": "EXIT",
"onStatusReason": "*"
}
]
}
}
```
Questa configurazione:
+ Riprova i lavori che falliscono a causa di errori interni del server SageMaker AI
+ Fallisce immediatamente i lavori che presentano eccezioni di convalida (errori del client che non verranno risolti con un nuovo tentativo)
+ Include una regola generale per uscire da qualsiasi altro tipo di errore
#### Corrispondenza del motivo dello stato
Il `onStatusReason` parametro supporta la corrispondenza dei modelli con un massimo di 512 caratteri. I pattern possono utilizzare caratteri jolly (\$1) e corrispondere ai motivi di stato restituiti dall' SageMaker IA.
Per i lavori di assistenza, i messaggi di stato dell' SageMaker IA hanno il prefisso «Stato ricevuto da SageMaker:» per distinguerli dai messaggi AWS Batch generati. I modelli più comuni includono:
+ `Received status from SageMaker: InternalServerError*`- Rispondi agli errori interni del servizio
+ `Received status from SageMaker: ValidationException*`- Corrisponde agli errori di convalida del client
+ `Received status from SageMaker: ResourceLimitExceeded*`- Rispondi agli errori relativi al limite delle risorse
+ `*CapacityError*`- Risolvi gli errori relativi alla capacità
**Suggerimento**
Utilizza un pattern matching specifico per gestire in modo appropriato diversi tipi di errore. Ad esempio, riprovate a commettere errori interni del server, ma non riuscite immediatamente in caso di errori di convalida che indicano problemi con i parametri del lavoro.
# Monitora i lavori di assistenza in coda AWS Batch
Puoi monitorare lo stato dei lavori nella coda dei lavori di SageMaker Training utilizzando`list-service-jobs`, e`get-job-queue-snapshot`.
Visualizza i lavori in esecuzione nella tua coda:
```
aws batch list-service-jobs \
--job-queue my-sm-training-fifo-jq \
--job-status RUNNING
```
Visualizza i lavori in attesa in coda:
```
aws batch list-service-jobs \
--job-queue my-sm-training-fifo-jq \
--job-status RUNNABLE
```
Visualizza i lavori inviati SageMaker ma non ancora in esecuzione:
```
aws batch list-service-jobs \
--job-queue my-sm-training-fifo-jq \
--job-status SCHEDULED
```
Ottieni un'istantanea dei lavori in primo piano:
```
aws batch get-job-queue-snapshot --job-queue my-sm-training-fifo-jq
```
Questo comando mostra l'ordine dei lavori di assistenza imminenti nella coda.
## Ottieni informazioni dettagliate sulle mansioni di assistenza
Utilizzate l'[https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeServiceJob.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeServiceJob.html)operazione per ottenere informazioni complete su una specifica mansione di servizio, tra cui lo stato corrente, gli identificatori delle risorse di servizio e informazioni dettagliate sui tentativi.
Visualizza informazioni dettagliate su un lavoro specifico:
```
aws batch describe-service-job \
--job-id a4d6c728-8ee8-4c65-8e2a-9a5e8f4b7c3d
```
Questo comando restituisce informazioni complete sul lavoro, tra cui:
+ Job ARN e stato attuale
+ Identificatori delle risorse del servizio (ad esempio SageMaker Training job ARN)
+ Priorità di pianificazione e configurazione dei nuovi tentativi
+ Payload della richiesta di servizio contenente i parametri di servizio originali
+ Informazioni dettagliate sui tentativi con orari di inizio e fine
+ Messaggi di stato dal servizio di destinazione
## Monitora i lavori di SageMaker formazione
Quando si monitorano i lavori di SageMaker formazione tramite AWS Batch, è possibile accedere sia alle informazioni sulla AWS Batch mansione sia ai dettagli dei lavori di SageMaker formazione sottostanti.
L'identificatore della risorsa di servizio nei dettagli del lavoro contiene l'ARN del lavoro di SageMaker formazione:
```
{
"latestAttempt": {
"serviceResourceId": {
"name": "TrainingJobArn",
"value": "arn:aws:sagemaker:us-east-1:123456789012:training-job/my-training-job"
}
}
}
```
Puoi utilizzare questo ARN per ottenere ulteriori dettagli direttamente da: SageMaker
```
aws sagemaker describe-training-job \
--training-job-name my-training-job
```
Monitora l'avanzamento del lavoro controllando sia AWS Batch lo stato del lavoro che lo stato del lavoro di SageMaker formazione. Lo stato del AWS Batch lavoro mostra il ciclo di vita complessivo del lavoro, mentre lo stato del lavoro di SageMaker formazione fornisce dettagli specifici del servizio sul processo di formazione.
# Interrompere i lavori di assistenza
Utilizzare l'[https://docs.aws.amazon.com/batch/latest/APIReference/API_TerminateServiceJob.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_TerminateServiceJob.html)operazione per interrompere un processo di servizio in esecuzione.
Termina un lavoro di servizio specifico:
```
aws batch terminate-service-job \
--job-id a4d6c728-8ee8-4c65-8e2a-9a5e8f4b7c3d \
--reason "Job terminated by user request"
```
Quando si termina un lavoro di servizio, AWS Batch interrompe il lavoro e invia una notifica al servizio di destinazione. Per i lavori di SageMaker formazione, ciò interromperà anche il lavoro di formazione nell' SageMaker intelligenza artificiale.
# Job stati
Quando si invia un lavoro a una coda di AWS Batch lavoro, il lavoro entra nello `SUBMITTED` stato. Dopodiché passa per gli stati successivi, fino a quando non ha esito positivo (codice di uscita `0`) o negativo (codice di uscita diverso da zero). I processi di AWS Batch hanno gli stati seguenti:
`SUBMITTED`
Un lavoro che è stato inviato alla coda e non è stato ancora valutato dallo scheduler. Il pianificatore valuta il processo per stabilire se presenta dipendenze in sospeso relative al corretto completamento di altri processi. Se sono presenti dipendenze, il processo passa allo stato `PENDING`. Se non sono presenti dipendenze, il processo passa allo stato `RUNNABLE`.
`PENDING`
Un lavoro che si trova in coda e non è ancora in grado di essere eseguito a causa della dipendenza da un altro lavoro o risorsa. Quando le dipendenze sono state soddisfatte, il processo passa allo stato `RUNNABLE`.
I genitori di Array job vengono aggiornati a `PENDING` quando un job secondario viene aggiornato `RUNNABLE` e rimangono attivi mentre i job `PENDING` secondari sono in esecuzione. Per visualizzare questi lavori, filtra per `PENDING` stato finché tutti i lavori secondari non raggiungono lo stato terminale.
`RUNNABLE`
Un processo che si trova nella coda, che non presenta dipendenze in sospeso e che è quindi pronto per essere pianificato per un host. I lavori in questo stato vengono avviati non appena sono disponibili risorse sufficienti in uno degli ambienti di elaborazione mappati sulla coda del lavoro. Tuttavia, i processo possono rimanere in questo stato in modo indefinito se le risorse sufficienti non sono disponibili.
Se i tuoi lavori non procedono`STARTING`, consulta la sezione relativa alla risoluzione dei [Lavori bloccati in uno `RUNNABLE` status](job_stuck_in_runnable.md) problemi.
`STARTING`
Questi processi sono stati pianificati per un host e le operazioni di avvio del container pertinente sono in corso. Una volta che l'immagine del container è stata estratta e il container è in esecuzione, il processo passa allo stato `RUNNING`.
La durata del pull dell'immagine, la durata del completamento di Amazon EKS InitContainer e la durata della risoluzione di Amazon ECS ContainerDependency si verificano nello stato STARTING. La quantità di tempo necessaria per estrarre un'immagine per il tuo lavoro è equivalente alla quantità di tempo in cui il lavoro rimarrà nello stato INIZIALE.
Ad esempio, se occorrono tre minuti per estrarre l'immagine del lavoro, quest'ultimo rimarrà nello stato INIZIALE per tre minuti. Se InitContainers impiega un totale di dieci minuti per essere completato, il processo Amazon EKS rimarrà in modalità STARTING per dieci minuti. Se hai impostato Amazon ECS ContainerDependencies nel tuo job Amazon ECS, il processo rimarrà in STARTING fino a quando tutte le dipendenze del contenitore (il loro runtime) non saranno risolte. STARTING non è incluso nei timeout; la durata inizia da RUNNING. Per ulteriori informazioni, consulta [Job states](https://docs.aws.amazon.com/batch/latest/userguide/job_states.html).
`RUNNING`
Il processo viene eseguito come processo container su un'istanza di container Amazon ECS all'interno di un ambiente di calcolo. Al momento dell'uscita del container, il codice di uscita del processo determina l'esito positivo o negativo di quest'ultimo. Il codice di uscita `0` indica che il processo ha avuto esito positivo, mentre un codice di uscita diverso da zero indica che ha avuto esito negativo. Se il processo associato a un tentativo non riuscito presenta tentativi rimanenti nella sua configurazione opzionale della strategia relativa ai nuovi tentativi, il processo passa nuovamente allo stato `RUNNABLE`. Per ulteriori informazioni, consulta [Ritentativi di lavoro automatizzati](job_retries.md).
I registri dei `RUNNING` lavori sono disponibili in Logs. CloudWatch Il gruppo di log è`/aws/batch/job`, e il formato del nome del flusso di log è il seguente:. `first200CharsOfJobDefinitionName/default/ecs_task_id` Questo formato potrebbe cambiare in futuro.
Dopo che un processo raggiunge lo `RUNNING` stato, è possibile recuperare a livello di codice il nome del flusso di log con l'[DescribeJobs](https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeJobs.html)operazione API. Per ulteriori informazioni, consulta [Visualizza i dati di log inviati ai CloudWatch registri nella Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#ViewingLogData) *User* Guide. Per impostazione predefinita, questi log non scadono mai. Tuttavia, è possibile modificare il periodo di conservazione. Per ulteriori informazioni, consulta [Change Log Data Retention in CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SettingLogRetention.html) nella *Amazon CloudWatch Logs User Guide.*
`SUCCEEDED`
Il processo è stato completato correttamente e ha ricevuto il codice di uscita `0`. Lo stato del lavoro per i `SUCCEEDED` lavori viene mantenuto invariato AWS Batch per almeno 7 giorni.
I registri dei `SUCCEEDED` lavori sono disponibili in CloudWatch Registri. Il gruppo di log è`/aws/batch/job`, e il formato del nome del flusso di log è il seguente:. `first200CharsOfJobDefinitionName/default/ecs_task_id` Questo formato potrebbe cambiare in futuro.
Dopo che un processo raggiunge lo `RUNNING` stato, è possibile recuperare a livello di codice il nome del flusso di log con l'[DescribeJobs](https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeJobs.html)operazione API. Per ulteriori informazioni, consulta [Visualizza i dati di log inviati ai CloudWatch registri nella Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#ViewingLogData) *User* Guide. Per impostazione predefinita, questi log non scadono mai. Tuttavia, è possibile modificare il periodo di conservazione. Per ulteriori informazioni, consulta [Change Log Data Retention in CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SettingLogRetention.html) nella *Amazon CloudWatch Logs User Guide.*
`FAILED`
Il processo ha ottenuto un esito negativo per tutti i tentativi disponibili. Lo stato del lavoro per i `FAILED` lavori viene mantenuto invariato AWS Batch per almeno 7 giorni.
I registri dei `FAILED` lavori sono disponibili in CloudWatch Registri. Il gruppo di log è`/aws/batch/job`, e il formato del nome del flusso di log è il seguente:. `first200CharsOfJobDefinitionName/default/ecs_task_id` Questo formato potrebbe cambiare in futuro.
Dopo che un lavoro raggiunge lo `RUNNING` stato, è possibile recuperarne il flusso di log a livello di codice con l'[DescribeJobs](https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeJobs.html)operazione API. Per ulteriori informazioni, consulta [Visualizza i dati di log inviati ai CloudWatch registri nella Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#ViewingLogData) *User* Guide. Per impostazione predefinita, questi log non scadono mai. Tuttavia, è possibile modificare il periodo di conservazione. Per ulteriori informazioni, consulta [Change Log Data Retention in CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SettingLogRetention.html) nella *Amazon CloudWatch Logs User Guide.*
# AWS Batch variabili dell'ambiente di lavoro
AWS Batch imposta variabili di ambiente specifiche nei job dei container. Queste variabili di ambiente forniscono un'introspezione per i contenitori all'interno dei job. È possibile utilizzare i valori di queste variabili nella logica delle applicazioni. Tutte le variabili AWS Batch impostate iniziano con il `AWS_BATCH_` prefisso. Si tratta di un prefisso di variabile di ambiente protetto. Non è possibile utilizzare questo prefisso per le proprie variabili nelle definizioni o nelle sostituzioni dei processi.
Nei container dei processi sono disponibili le variabili di ambiente seguenti:
`AWS_BATCH_CE_NAME`
Questa variabile è impostata sul nome dell'ambiente di calcolo in cui si trova il lavoro.
`AWS_BATCH_JOB_ARRAY_INDEX`
Questa variabile viene impostata solo nei processi figlio in array. L'indice dei processi in array inizia da 0 e a ciascun processo figlio viene assegnato un numero di indice univoco. Ad esempio, i valori di indice di un processo in array con 10 elementi figlio sono compresi tra 0 e 9. È possibile utilizzare questo valore di indice per controllare il modo in cui vengono indicati i diversi elementi figlio dei processi in array. Per ulteriori informazioni, consulta [Utilizza l'array job index per controllare la differenziazione dei job](array_index_example.md).
`AWS_BATCH_JOB_ARRAY_SIZE`
Questa variabile è impostata sulla dimensione del job dell'array principale. La dimensione del job dell'array principale viene passata al job dell'array secondario in questa variabile.
`AWS_BATCH_JOB_ATTEMPT`
Questa variabile è impostata sul numero di tentativi del processo. Al primo tentativo viene assegnato il numero 1. Per ulteriori informazioni, consulta [Ritentativi di lavoro automatizzati](job_retries.md).
`AWS_BATCH_JOB_ID`
Questa variabile è impostata sull'ID del AWS Batch lavoro.
`AWS_BATCH_JOB_KUBERNETES_NODE_UID`
Questa variabile è impostata come Kubernetes UID dell'oggetto nodo che si trova nel cluster Kubernetes su cui viene eseguito il pod. Questa variabile è impostata solo per i job eseguiti su risorse Amazon EKS. Per ulteriori informazioni, [UIDs](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#uids)consulta la *Kubernetesdocumentazione*.
`AWS_BATCH_JOB_MAIN_NODE_INDEX`
Questa variabile viene impostata solo nei processi paralleli a più nodi. Questa variabile è impostata sul numero d'indice del nodo principale del processo. Il codice dell'applicazione può essere confrontato con `AWS_BATCH_JOB_MAIN_NODE_INDEX` quello di un singolo nodo per determinare se si tratta del nodo principale. `AWS_BATCH_JOB_NODE_INDEX`
`AWS_BATCH_JOB_MAIN_NODE_PRIVATE_IPV4_ADDRESS`
Questa variabile è impostata solo nei nodi figlio del lavoro parallelo a più nodi. Questa variabile non è presente nel nodo principale, ma è impostata sull' IPv4 indirizzo privato del nodo principale del processo. Il codice di applicazione del nodo figlio può utilizzare questo indirizzo per comunicare con il nodo principale.
`AWS_BATCH_JOB_NODE_INDEX`
Questa variabile viene impostata solo nei processi paralleli a più nodi. Questa variabile è impostata sul numero d'indice del nodo. L'indice del nodo inizia con 0 e a ciascun nodo viene assegnato un numero d'indice univoco. Ad esempio, un processo parallelo a più nodi con 10 figli ha valori d'indice compresi tra 0 e 9.
`AWS_BATCH_JOB_NUM_NODES`
Questa variabile viene impostata solo nei processi paralleli a più nodi. Questa variabile è impostata sul numero di nodi richiesti per il processo parallelo multinodo.
`AWS_BATCH_JQ_NAME`
Questa variabile è impostata sul nome della coda dei processi a cui viene inviato il processo.
# Ritentativi di lavoro automatizzati
Puoi applicare ai tuoi processi e alle definizioni di processo una strategia di nuovi tentativi che consenta la ripetizione automatica dei processi in caso di esito negativo. I possibili scenari di errore includono quanto segue:
+ Un codice di uscita diverso da zero ricevuto dal processo di un container
+ Errore o chiusura dell'istanza Amazon EC2
+ Errore o AWS interruzione del servizio interno
Quando un lavoro viene inviato a una coda di lavoro e inserito nello `RUNNING` stato considerato un tentativo. Per impostazione predefinita, a ogni processo viene assegnato un tentativo per passare allo stato `SUCCEEDED` o `FAILED`. Tuttavia, sia il flusso di lavoro di definizione che quello di invio del lavoro possono essere utilizzati per specificare una strategia di nuovo tentativo con un numero di tentativi compreso tra 1 e 10 tentativi. Se [evaluateOnExit](job_definition_parameters.md#retryStrategy-evaluateOnExit)specificato, può contenere fino a 5 strategie di nuovo tentativo. Se [evaluateOnExit](https://docs.aws.amazon.com/batch/latest/APIReference/API_EvaluateOnExit.html)viene specificato, ma nessuna delle strategie di nuovo tentativo corrisponde, il processo viene riprovato. Per i lavori che non corrispondono a exit, aggiungi una voce finale che termina per qualsiasi motivo. Ad esempio, questo `evaluateOnExit` oggetto ha due voci con azioni di `RETRY` e una voce finale con un'azione di`EXIT`.
```
"evaluateOnExit": [
{
"action": "RETRY",
"onReason": "AGENT"
},
{
"action": "RETRY",
"onStatusReason": "Task failed to start"
},
{
"action": "EXIT",
"onReason": "*"
}
]
```
In fase di runtime, la variabile di ambiente `AWS_BATCH_JOB_ATTEMPT` è impostata sul numero del tentativo corrispondente del processo del container. Il primo tentativo è numerato e `1` i tentativi successivi sono in ordine crescente (ad esempio, 2, 3, 4).
Si supponga, ad esempio, che un tentativo di lavoro abbia esito negativo per qualsiasi motivo e che il numero di tentativi specificato nella configurazione dei nuovi tentativi sia maggiore del numero. `AWS_BATCH_JOB_ATTEMPT` Quindi, il lavoro viene rimesso nello `RUNNABLE` stato. Per ulteriori informazioni, consulta [Job stati](job_states.md).
**Nota**
I lavori annullati o terminati non vengono ritentati. Inoltre, i lavori che falliscono a causa di una definizione di processo non valida non vengono ritentati.
Per ulteriori informazioni, vedere [Strategia per nuovi tentativi](job_definition_parameters.md#retryStrategy)[Creare una definizione di processo a nodo singolo](create-job-definition.md), [Tutorial: invia un lavoro](submit_job.md) e Codici di [errore delle attività interrotte](https://docs.aws.amazon.com/AmazonECS/latest/userguide/stopped-task-error-codes.html).
# Dipendenze dal lavoro
Quando invii un AWS Batch lavoro, puoi specificare il lavoro da IDs cui dipende il lavoro. In tal caso, lo AWS Batch scheduler garantisce che il processo venga eseguito solo dopo che le dipendenze specificate sono state completate con successo. Dopo il completamento delle dipendenze, il processo passerà dallo stato `PENDING` a `RUNNABLE`, quindi a `STARTING` e a `RUNNING`. Nel caso in cui qualsiasi dipendenza del processo abbia esito negativo, il processo passerà automaticamente dallo stato `PENDING` a `FAILED`.
Ad esempio, l'esecuzione del processo A può dipendere da un massimo di altri 20 processi che devono avere esito positivo. Dopodiché puoi inviare processi aggiuntivi che dipendono dal processo A e da un massimo di altri 19 processi.
Per i processi in array, puoi specificare una dipendenza di tipo `SEQUENTIAL` senza specificare un ID del processo, in modo che ogni processo figlio nell'array venga completato in maniera sequenziale a partire dall'indice 0. È anche possibile specificare una dipendenza tipo `N_TO_N` con un ID processo. In questo modo, prima di iniziare, ciascun figlio nell'indice di questo processo deve attendere il completamento del figlio nell'indice corrispondente di ciascuna dipendenza. Per ulteriori informazioni, consulta [Lavori di matrice](array_jobs.md).
Per inviare un AWS Batch lavoro con dipendenze, vedi. [Tutorial: invia un lavoro](submit_job.md)
[Pianificazione basata sulle risorse](resource-aware-scheduling.md)consente di pianificare i lavori in base alle risorse consumabili necessarie per eseguire i lavori. Si specificano le risorse consumabili necessarie per l'esecuzione di un processo e Batch tiene conto di queste dipendenze tra le risorse quando pianifica un lavoro. È possibile ridurre il sottoutilizzo delle risorse di elaborazione allocando solo i lavori che dispongono di tutte le risorse necessarie. La pianificazione basata sulle risorse è disponibile sia per le politiche di pianificazione FIFO che per quelle di condivisione equa e può essere utilizzata con tutte le piattaforme di elaborazione supportate da Batch, tra cui EKS, ECS e Fargate. Può essere utilizzato con i job Array, i job Multi-node parallel (MNP) e con i normali job Batch.
# Job timeout
Puoi configurare una durata del timeout per i tuoi processi, in modo che se un processo viene eseguito per più tempo, AWS Batch termina l'operazione. Ad esempio, potresti avere un lavoro che sai dovrebbe richiedere solo 15 minuti per essere completato. Talvolta, l'applicazione si blocca durante un ciclo e viene eseguita sempre, perciò è possibile impostare un timeout di 30 minuti per terminare il processo bloccato.
**Importante**
Per impostazione predefinita, AWS Batch non prevede un timeout di lavoro. Se non si definisce un timeout per il processo, il processo viene eseguito fino alla chiusura del contenitore.
Puoi specificare un parametro `attemptDurationSeconds` che deve essere pari almeno a 60 secondi, nella definizione del processo oppure quando lo invii. Trascorso questo numero di secondi dal `startedAt` timestamp del tentativo di lavoro, AWS Batch termina il processo. Nella risorsa di calcolo, il container del processo riceve un segnale `SIGTERM` per offrire alla tua applicazione la possibilità di arresto normale. Se il container è ancora in esecuzione dopo 30 secondi, viene inviato un segnale `SIGKILL` per forzare l'arresto del container.
Le chiusure di timeout sono gestite nel miglior modo possibile. Non dovresti aspettarti che la fine del timeout avvenga esattamente allo scadere del tentativo di lavoro (potrebbero essere necessari alcuni secondi in più). Se la tua applicazione richiede l'esecuzione di timeout precisi, è necessario implementare questa logica all'interno dell'applicazione. Se disponi di un numero elevato di processi con un timeout simultaneo, le cancellazioni dei timeout si comportano come una coda FIFO, in cui i processi vengono terminati in batch.
**Nota**
Non esiste un valore di timeout massimo per un lavoro. AWS Batch
Se un lavoro viene interrotto per aver superato la durata del timeout, non viene ritentato. Se il tentativo di un processo ha esito negativo, è possibile riprovare (se sono stati abilitati altri tentativi) e viene avviato il conteggio del timeout per il nuovo tentativo.
**Importante**
I lavori eseguiti su risorse Fargate non possono durare più di 14 giorni. Se la durata del timeout supera i 14 giorni, le risorse di Fargate potrebbero non essere più disponibili e il lavoro verrà interrotto.
Per i processi in array, i processi figlio hanno la stessa configurazione di timeout del processo padre.
Per informazioni sull'invio di un AWS Batch lavoro con una configurazione di timeout, vedere. [Tutorial: invia un lavoro](submit_job.md)
# Offerte di lavoro Amazon EKS
Un lavoro è l'unità di lavoro più piccola in AWS Batch. Un AWS Batch lavoro su Amazon EKS prevede una one-to-one mappatura su un Kubernetes pod. Una definizione di AWS Batch lavoro è un modello per un AWS Batch lavoro. Quando si invia un AWS Batch lavoro, si fa riferimento a una definizione di processo, si sceglie come target una coda di lavoro e si fornisce un nome per un lavoro. Nella definizione di un AWS Batch processo su Amazon [EKS, il parametro EksProperties](https://docs.aws.amazon.com/batch/latest/APIReference/API_EksProperties.html) definisce l'insieme di parametri supportati da un processo AWS Batch su Amazon EKS. In una [SubmitJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html)richiesta, il [eksPropertiesOverride](https://docs.aws.amazon.com/batch/latest/APIReference/API_EksPropertiesOverride.html)parametro consente di sostituire alcuni parametri comuni. In questo modo, è possibile utilizzare modelli di definizioni di lavoro per più lavori. Quando un lavoro viene inviato al tuo cluster Amazon EKS, AWS Batch trasforma il lavoro in un `podspec` (). `Kind: Pod` `podspec`Utilizza alcuni AWS Batch parametri aggiuntivi per garantire che i lavori siano scalati e pianificati correttamente. AWS Batch combina etichette e taint per garantire che i job vengano eseguiti solo su nodi AWS Batch gestiti e che altri pod non vengano eseguiti su tali nodi.
**Importante**
Se il `hostNetwork` parametro non è impostato in modo esplicito in una definizione di processo Amazon EKS, la modalità di rete pod è AWS Batch predefinita in modalità host. Più specificamente, vengono applicate le seguenti impostazioni: e. `hostNetwork=true` `dnsPolicy=ClusterFirstWithHostNet`
AWS Batch pulisce i job pod subito dopo che un pod ha completato il suo lavoro. Per visualizzare i log delle applicazioni dei pod, configura un servizio di registrazione per il tuo cluster. Per ulteriori informazioni, consulta [Usa CloudWatch Logs per monitorare i lavori AWS Batch su Amazon EKS](batch-eks-cloudwatch-logs.md).
**Topics**
+ [Tutorial: mappa un job in esecuzione su un pod e un nodo](eks-jobs-map-running-job.md)
+ [Tutorial: Riporta un pod in esecuzione al suo lavoro](eks-jobs-map-running-pod-to-job.md)
# Tutorial: mappa un job in esecuzione su un pod e un nodo
I `nodeName` parametri `podProperties` di un processo in esecuzione sono stati `podName` impostati per il tentativo di lavoro corrente. Utilizzate l'operazione [DescribeJobs](https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeJobs.html)API per visualizzare questi parametri.
Di seguito è riportato un output di esempio.
```
$ 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"
}
}
}
]
}
```
Per un lavoro con nuovi tentativi abilitati, `podName` la fine `nodeName` di ogni tentativo completato è inclusa nel parametro `eksAttempts` list dell'operazione [DescribeJobs](https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeJobs.html)API. La `podName` fine `nodeName` del tentativo di esecuzione corrente si trova nell'`podProperties`oggetto.
# Tutorial: Riporta un pod in esecuzione al suo lavoro
Un pod ha delle etichette che indicano `jobId` la fine `uuid` dell'ambiente di calcolo a cui appartiene. AWS Batch inserisce variabili di ambiente in modo che il runtime del lavoro possa fare riferimento alle informazioni sul lavoro. Per ulteriori informazioni, consulta [AWS Batch variabili dell'ambiente di lavoro](job_env_vars.md). È possibile visualizzare queste informazioni eseguendo il comando seguente. L'output è il seguente.
```
$ 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
...
```
**Funzionalità supportate da AWS Batch Amazon EKS jobs**
Queste sono le caratteristiche AWS Batch specifiche comuni anche ai Kubernetes job eseguiti su Amazon EKS:
+ [Dipendenze dal lavoro](job_dependencies.md)
+ [Lavori di matrice](array_jobs.md)
+ [Job timeout](job_timeouts.md)
+ [Ritentativi di lavoro automatizzati](job_retries.md)
+ [Usa la pianificazione con condivisione equa per aiutarti a pianificare i lavori](fair-share-scheduling.md)
**Kubernetes e `Secrets` `ServiceAccounts`**
AWS Batch supporta riferimenti Kubernetes `Secrets` e. `ServiceAccounts` Puoi configurare i pod per utilizzare i ruoli IAM di Amazon EKS per gli account di servizio. Per ulteriori informazioni, consulta [Configurazione dei pod per l'utilizzo di un account di Kubernetes servizio](https://docs.aws.amazon.com/eks/latest/userguide/pod-configuration.html) nella [https://docs.aws.amazon.com/eks/latest/userguide/](https://docs.aws.amazon.com/eks/latest/userguide/).
**Documenti correlati**
+ [Considerazioni su AWS Batch memoria e vCPU per Amazon EKS](memory-cpu-batch-eks.md)
+ [Esegui lavori GPU](gpu-jobs.md)
+ [Lavori bloccati in uno `RUNNABLE` status](job_stuck_in_runnable.md)
# Lavori paralleli multinodo
Puoi utilizzare processi paralleli a più nodi per eseguire singoli processi che si estendono su più istanze Amazon EC2. Con i processi paralleli a AWS Batch più nodi (noti anche come *pianificazione di gruppo*), puoi eseguire applicazioni di elaborazione su larga scala e ad alte prestazioni e addestrare modelli GPU distribuiti senza la necessità di avviare, configurare e gestire direttamente le risorse Amazon EC2. Un job parallelo AWS Batch multinodo è compatibile con qualsiasi framework che supporti la comunicazione tra nodi basata su IP. Gli esempi includono Apache MXNet TensorFlow, Caffe2 o Message Passing Interface (MPI).
I lavori paralleli multinodo vengono inviati come processo singolo. Tuttavia, la definizione del processo (o sostituzioni del nodo di invio del processo) specifica il numero di nodi da creare per il processo e quali gruppi di nodo creare. Ogni processo parallelo a più nodi contiene un **nodo principale**, che viene avviato prima. Dopo che il nodo principale è attivo, i nodi secondari vengono avviati e avviati. Il processo è terminato solo se il nodo principale viene chiuso. Tutti i nodi secondari vengono quindi interrotti. Per ulteriori informazioni, consulta [Gruppi di nodi](mnp-node-groups.md).
I nodi di lavoro paralleli multinodo sono single-tenant. Ciò significa che su ogni istanza Amazon EC2 viene eseguito un solo contenitore di job.
Lo stato del processo finale (`SUCCEEDED` o `FAILED`) è determinato dallo stato del processo finale del nodo principale. Per conoscere lo stato di un processo parallelo a più nodi, descrivi il lavoro utilizzando l'ID del lavoro restituito al momento dell'invio del lavoro. Se hai bisogno dei dettagli per i nodi secondari, descrivi ogni nodo figlio singolarmente. È possibile indirizzare i nodi utilizzando la `#N` notazione (a partire da 0). Ad esempio, per accedere ai dettagli del secondo nodo di un job, descrivi *aws\$1batch\$1job\$1id* \$11 utilizzando l'operazione AWS Batch [DescribeJobs](https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeJobs.html)API. Le informazioni `started`, `stoppedAt`, `statusReason` e `exit` per un processo parallelo a più nodi, vengono popolate dal nodo principale.
Se si specificano nuovi tentativi di lavoro, un errore del nodo principale causa un altro tentativo. Gli errori dei nodi secondari non causano ulteriori tentativi. Ogni nuovo tentativo di un processo parallelo a più nodi aggiorna il tentativo corrispondente dei suoi nodi figlio associati.
Per eseguire lavori paralleli a più nodi AWS Batch, il codice dell'applicazione deve contenere i framework e le librerie necessari per la comunicazione distribuita.
**Topics**
+ [Variabili di ambiente](mnp-env-vars.md)
+ [Gruppi di nodi](mnp-node-groups.md)
+ [Ciclo di vita del lavoro per i lavori MNP](job-lifecycle.md)
+ [Considerazioni sull'ambiente di calcolo per MNP con AWS Batch](mnp-ce.md)
# Variabili di ambiente
In fase di esecuzione, ogni nodo è configurato in base alle variabili di ambiente standard ricevute da tutti AWS Batch i job. Inoltre, i nodi sono configurati con le seguenti variabili di ambiente specifiche per i lavori paralleli a più nodi:
`AWS_BATCH_JOB_MAIN_NODE_INDEX`
Questa variabile è impostata sul numero d'indice del nodo principale del processo. Il codice dell'applicazione può essere confrontato `AWS_BATCH_JOB_MAIN_NODE_INDEX` con quello di un singolo nodo per determinare se si tratta del nodo principale. `AWS_BATCH_JOB_NODE_INDEX`
`AWS_BATCH_JOB_MAIN_NODE_PRIVATE_IPV4_ADDRESS`
Questa variabile è impostata solo nei nodi figlio del lavoro parallelo a più nodi. Questa variabile non è presente nel nodo principale. Questa variabile è impostata sull' IPv4 indirizzo privato del nodo principale del lavoro. Il codice di applicazione del nodo figlio può utilizzare questo indirizzo per comunicare con il nodo principale.
`AWS_BATCH_JOB_NODE_INDEX`
Questa variabile è impostata sul numero d'indice del nodo. L'indice del nodo inizia con 0 e a ciascun nodo viene assegnato un numero d'indice univoco. Ad esempio, un processo parallelo a più nodi con 10 figli ha valori d'indice compresi tra 0 e 9.
`AWS_BATCH_JOB_NUM_NODES`
Questa variabile è impostata sul numero di nodi che hai richiesto per il tuo processo parallelo a più nodi.
# Gruppi di nodi
Un gruppo di nodi è un gruppo identico di nodi di lavoro che condividono tutti le stesse proprietà del contenitore. È possibile utilizzare AWS Batch per specificare fino a cinque gruppi di nodi distinti per ogni job.
Ogni gruppo può avere immagini container, comandi, variabili d'ambiente propri. Ad esempio, è possibile inviare un processo che richiede una singola `c5.xlarge` istanza per il nodo principale e cinque nodi figlio di `c5.xlarge` istanza. Ciascuno di questi gruppi di nodi distinti può specificare diverse immagini o comandi del contenitore da eseguire per ogni processo.
In alternativa, tutti i nodi del job possono utilizzare un singolo gruppo di nodi. Inoltre, il codice dell'applicazione può differenziare i ruoli dei nodi, ad esempio il nodo principale e il nodo secondario. A tale scopo, confronta la variabile di `AWS_BATCH_JOB_MAIN_NODE_INDEX` ambiente con il proprio valore di`AWS_BATCH_JOB_NODE_INDEX`. È possibile avere fino a 1.000 nodi in un singolo processo. Questo è il limite predefinito per le istanze in un cluster Amazon ECS. Puoi [richiedere di aumentare questo limite](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html).
**Nota**
Attualmente tutti i gruppi di nodi in un processo parallelo multinodo devono utilizzare lo stesso tipo di istanza.
# Ciclo di vita del lavoro per i lavori MNP
Quando si invia un processo parallelo multinodo, il lavoro entra nello `SUBMITTED` stato. Quindi, il lavoro attende il completamento di eventuali dipendenze tra i lavori. Il lavoro passa anche allo stato. `RUNNABLE` Infine, AWS Batch fornisce la capacità dell'istanza necessaria per eseguire il job e avvia queste istanze.
Ogni processo parallelo a più nodi contiene un **nodo principale**. Il nodo principale è una singola sottoattività che AWS Batch monitora per determinare l'esito del processo multinodo inviato. Il nodo principale viene avviato prima e passa allo stato `STARTING`. Il valore di timeout specificato nel `attemptDurationSeconds` parametro si applica all'intero processo e non ai nodi.
Quando il nodo principale raggiunge lo `RUNNING` stato dopo l'esecuzione del contenitore del nodo, i nodi secondari vengono avviati e anch'essi passano allo `STARTING` stato. I nodi figlio si presentano in ordine casuale. Non ci sono garanzie sui tempi e sull'ordine di avvio del nodo secondario. Per garantire che tutti i nodi dei job abbiano `RUNNING` lo stato dopo l'esecuzione del contenitore del nodo, il codice dell'applicazione può interrogare l' AWS Batch API per ottenere le informazioni sul nodo principale e sul nodo secondario. In alternativa, il codice dell'applicazione può attendere che tutti i nodi siano online prima di avviare qualsiasi attività di elaborazione distribuita. L'indirizzo IP privato del nodo principale è disponibile come la variabile d'ambiente `AWS_BATCH_JOB_MAIN_NODE_PRIVATE_IPV4_ADDRESS` in ogni nodo figlio. Il tuo codice dell'applicazione può utilizzare queste informazioni per coordinare e comunicare i dati tra ciascuna operazione.
Quando i nodi singoli escono, passano allo stato `SUCCEEDED` o `FAILED`, a seconda del loro codice di uscita. Se il nodo principale esce, il processo viene considerato completo e tutti i nodi figlio vengono arrestati. Se un nodo figlio muore, AWS Batch non esegue alcuna azione sugli altri nodi del job. Se non vuoi che il tuo lavoro continui con un numero ridotto di nodi, devi tenerne conto nel codice dell'applicazione. In questo modo si interrompe o si annulla il lavoro.
# Considerazioni sull'ambiente di calcolo per MNP con AWS Batch
Durante la configurazione di ambienti di calcolo per eseguire processi paralleli a più nodi con AWS Batch, è necessario tenere presenti diversi aspetti.
+ I lavori paralleli multinodo non sono supportati negli ambienti di `UNMANAGED` elaborazione.
+ Se desideri inviare lavori paralleli multinodo a un ambiente di elaborazione, crea un gruppo di posizionamento del *cluster* in una singola zona di disponibilità e associalo alle tue risorse di elaborazione. In questo modo i processi paralleli multinodo su un raggruppamento logico di istanze restano vicini con un elevato potenziale di flusso di rete. Per ulteriori informazioni, consulta [Gruppi di collocamento](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html) nella *Guida per l'utente di Amazon EC2*.
+ I lavori paralleli multinodo non sono supportati negli ambienti di elaborazione che utilizzano istanze Spot.
+ AWS Batch i lavori paralleli a più nodi utilizzano la modalità di `awsvpc` rete Amazon ECS, che offre ai contenitori di lavori paralleli multinodo le stesse proprietà di rete delle istanze Amazon EC2. Ogni container di processo parallelo a più nodi ottiene la propria interfaccia di rete elastica, un indirizzo IP primario privato e un nome host DNS interno. L'interfaccia di rete viene creata nella stessa sottorete VPC della risorsa di calcolo host.
+ Il tuo ambiente di elaborazione potrebbe non avere più di cinque gruppi di sicurezza associati. Le interfacce di rete elastiche create e collegate a un'attività MNP utilizzeranno i gruppi di sicurezza specificati nell'ambiente di calcolo. Se non si specifica un gruppo di sicurezza, viene utilizzato il gruppo di sicurezza predefinito per il VPC.
+ La modalità `awsvpc` di rete non fornisce le interfacce di rete elastiche per lavori paralleli a più nodi con indirizzi IP pubblici. Per accedere a Internet, le risorse di calcolo devono essere avviate in una sottorete privata configurata per l'utilizzo di un gateway NAT. Per ulteriori informazioni, consulta [Gateway NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) nella *Guida per l'utente di Amazon VPC*. La comunicazione tra nodi deve utilizzare l'indirizzo IP privato o il nome host DNS del nodo. I lavori paralleli multinodo eseguiti su risorse di calcolo all'interno di sottoreti pubbliche non hanno accesso alla rete in uscita. Per creare un VPC con sottoreti private e un gateway NAT, consulta [Crea un cloud privato virtuale](create-public-private-vpc.md).
+ Le interfacce di rete elastiche create e collegate alle risorse di calcolo non possono essere scollegate manualmente o modificate dal tuo account. Questo serve a prevenire l'eliminazione accidentale di un'interfaccia elastica di rete associata a un processo in esecuzione. Per rilasciare le interfacce di rete elastiche per un'attività, interrompere il processo.
+ L'ambiente di elaborazione deve avere un valore massimo di v sufficiente CPUs per supportare il processo parallelo multinodo.
+ La quota di istanze Amazon EC2 include il numero di istanze necessarie per eseguire il processo. Ad esempio, supponiamo che il tuo processo richieda 30 istanze, ma che il tuo account possa eseguire solo 20 istanze in una regione. Quindi, il tuo lavoro rimarrà bloccato. `RUNNABLE`
+ Se si specifica un tipo di istanza per un gruppo di nodi in un processo parallelo a più nodi, l'ambiente di calcolo deve avviare quel tipo di istanza.
# Lavori paralleli multinodo su Amazon EKS
Puoi utilizzarlo AWS Batch su Amazon Elastic Kubernetes Service per eseguire processi paralleli a più nodi (MNP) (noti anche *come* pianificazione di gruppo) sui cluster gestiti. Kubernetes Questa opzione viene comunemente utilizzata per lavori di grandi dimensioni, strettamente accoppiati e ad alte prestazioni che non possono essere eseguiti su una singola istanza di Amazon Elastic Compute Cloud. Per ulteriori informazioni, consulta [Lavori paralleli multinodo](multi-node-parallel-jobs.md).
Puoi utilizzare questa funzionalità per eseguire applicazioni di elaborazione ad alte prestazioni gestite e Kubernetes specifiche di Amazon EKS, formazione su modelli linguistici di grandi dimensioni e altri lavori di intelligenza artificiale (AI) /machine learning (ML).
**Topics**
+ [Esecuzione di processi MNP](mnp-eks-running-mnp-jobs.md)
+ [Crea una definizione di processo Amazon EKS MNP](mnp-eks-create-eks-mnp-job-definition.md)
+ [Invia un lavoro Amazon EKS MNP](mnp-eks-submit-eks-mnp-job.md)
+ [Sostituisci una definizione di processo MNP di Amazon EKS](mnp-eks-override-eks-mnp-job-definition.md)
# Esecuzione di processi MNP
AWS Batch supporta i lavori MNP su Amazon Elastic Container Service e Amazon EKS utilizzando Amazon EC2. Di seguito vengono fornite ulteriori informazioni sui parametri dell'istanza e del contenitore per la funzionalità.
## Quote di istanze per MNP su Amazon EKS
+ È possibile utilizzare fino a 1000 istanze per un singolo processo MNP.
+ Fino a 5000 istanze possono unirsi a un singolo cluster Amazon EKS.
+ È possibile raggruppare e collegare fino a 5 ambienti di elaborazione in cluster a una coda di lavoro.
Ad esempio, è possibile scalare fino a 5 ambienti di elaborazione in cluster in una coda di lavoro e 1000 istanze in ogni ambiente di elaborazione.
Oltre ai parametri dell'istanza, è importante notare che non è possibile utilizzare i lavori Fargate for MNP tramite nessuno dei due servizi.
È possibile utilizzare un solo tipo di istanza in ogni job MNP. È possibile modificare il tipo di istanza aggiornando l'ambiente di calcolo o quando si definisce un nuovo ambiente di calcolo. È inoltre possibile specificare il tipo di istanza e fornire i requisiti di vCPU e memoria durante la creazione della definizione del processo.
## Quote di container per MNP su Amazon EKS
+ Un job parallelo multinodo supporta un pod per nodo.
+ Fino a 10 contenitori (o 10 contenitori init). Per ulteriori informazioni, consulta [Init Containers](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/) nella *documentazione di Kubernetes.) in ogni pod*.
+ Fino a 5 intervalli di nodi in ogni job MNP.
+ Fino a 10 immagini di contenitori distinte in ogni intervallo di nodi.
Ad esempio, è possibile eseguire fino a un massimo di 10.000 container in un singolo processo MNP che contiene 5 intervalli di nodi e un totale di 50 immagini uniche.
## Esecuzione di processi MNP in un Amazon VPC privato e in un cluster Amazon EKS
I job MNP possono essere eseguiti su qualsiasi cluster Amazon EKS, indipendentemente dal fatto che disponga di una rete Internet pubblica o meno. Quando utilizzi un cluster Amazon EKS con solo accesso alla rete privata, assicurati che AWS Batch possa accedere al piano di controllo di Amazon EKS e al server Kubernetes API gestito. Puoi concedere l'accesso necessario tramite gli endpoint Amazon Virtual Private Cloud. Per ulteriori informazioni, consulta [Configurare un servizio endpoint](https://docs.aws.amazon.com/vpc/latest/privatelink/configure-endpoint-service.html).
I cluster Pod Amazon EKS non possono scaricare un'immagine da una fonte pubblica poiché il VPC privato non dispone di accesso a Internet. Il tuo cluster Amazon EKS deve estrarre immagini da un registro di container che si trova all'interno del tuo Amazon VPC. Puoi creare un [Amazon Elastic Container Registry (Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/Registries.html)) nel tuo Amazon VPC e copiarvi le immagini dei container per l'accesso ai nodi.
Puoi anche creare una regola pull through cache con Amazon ECR. Una volta creata una regola pull through cache per un registro pubblico esterno, puoi semplicemente estrarre un'immagine da quel registro pubblico esterno utilizzando l'URI del tuo registro privato Amazon ECR. Quindi Amazon ECR crea un repository e memorizza l'immagine nella cache. Quando un'immagine memorizzata nella cache viene estratta utilizzando l'URI del registro privato di Amazon ECR, Amazon ECR controlla il registro remoto per verificare se esiste una nuova versione dell'immagine e aggiornerà il registro privato fino a una volta ogni 24 ore. Per ulteriori informazioni, consulta [Creazione di una regola pull through cache in Amazon ECR.](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache-creating-rule.html)
## Notifica di errore
Se i tuoi lavori MNP sono bloccati, puoi ricevere notifiche tramite Amazon Console di gestione AWS e Amazon EventBridge. Ad esempio, se un lavoro MNP è bloccato in testa alla coda, puoi ricevere una notifica sul problema insieme alle informazioni sulla sua causa, in modo da poter intervenire tempestivamente per sbloccare la coda dei lavori. Facoltativamente, è possibile terminare automaticamente il processo MNP se non viene intrapresa alcuna azione entro un determinato periodo di tempo, che può essere definito nel modello di coda dei lavori. Per ulteriori informazioni, consulta [Eventi bloccati in Job queue](batch-job-queue-blocked-events.md)
# Crea una definizione di processo Amazon EKS MNP
Per definire ed eseguire processi MNP su Amazon EKS, sono disponibili nuovi parametri all'interno delle operazioni [https://docs.aws.amazon.com/batch/latest/APIReference/API_RegisterJobDefinition.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_RegisterJobDefinition.html)e delle [https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html)API.
+ Utilizzali nella [https://docs.aws.amazon.com/batch/latest/APIReference/API_EksProperties.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_EksProperties.html)sezione per definire la definizione del processo MNP.
+ Utilizza nella [https://docs.aws.amazon.com/batch/latest/APIReference/API_EksPropertiesOverride.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_EksPropertiesOverride.html)sezione per sovrascrivere i parametri definiti nella definizione del processo quando si invia un lavoro MNP.
Queste azioni possono essere definite tramite le operazioni API e il. Console di gestione AWS
## Riferimento: registrare il payload della richiesta di definizione del processo Amazon EKS MNP
L'esempio seguente illustra come registrare una definizione di processo MNP di Amazon EKS con due nodi.
```
{
"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"
}
}
}
}
}
]
}
}
```
Per registrare la definizione del processo utilizzando AWS CLI, copia la definizione in un file locale denominato *MyEksMnpJobDefinition.json* ed esegui il comando seguente.
```
aws batch register-job-definition --cli-input-json file://MyEksMnpJobDefinition.json
```
Riceverai la seguente risposta JSON.
```
{
"jobDefinitionName": "MyEksMnpJobDefinition",
"jobDefinitionArn": "arn:aws:batch:us-east-1:0123456789:job-definition/MyEksMnpJobDefinition:1",
"revision": 1
}
```
# Invia un lavoro Amazon EKS MNP
Per inviare un lavoro utilizzando la definizione di lavoro registrata, inserisci il seguente comando. Sostituisci il valore di con il nome o l'ARN di una coda di lavoro preesistente associata a un ambiente di calcolo Amazon EKS.
```
aws batch submit-job --job-queue \
--job-definition MyEksMnpJobDefinition \
--job-name myFirstEksMnpJob
```
Riceverai la seguente risposta JSON.
```
{
"jobArn": "arn:aws:batch:region:account:job/9b979cce-9da0-446d-90e2-ffa16d52af68",
"jobName": "myFirstEksMnpJob",
"jobId": ""
}
```
È possibile controllare lo stato del lavoro utilizzando il JoBid restituito con il seguente comando.
```
aws batch describe-jobs --jobs
```
# Sostituisci una definizione di processo MNP di Amazon EKS
Facoltativamente, puoi sovrascrivere i dettagli della definizione del lavoro (ad esempio modificare le dimensioni del lavoro MNP o i dettagli del lavoro secondario). Di seguito viene fornito un esempio di payload di richiesta JSON per inviare un job MNP a cinque nodi e modifiche al comando del contenitore. `test-eks-container-1`
```
{
"numNodes": 5,
"nodePropertyOverrides": [
{
"targetNodes": "0:",
"eksPropertiesOverride": {
"podProperties": {
"containers": [
{
"name": "test-eks-container-1",
"command": [
"sleep",
"150"
]
}
]
}
}
}
]
}
```
Per inviare un lavoro con queste sostituzioni, salvate l'esempio in un file locale, *eks-mnp-job-nodeoverride.json*, e utilizzate il per inviare il lavoro con AWS CLI le sostituzioni.
# Lavori di matrice
Un array job è un job che condivide parametri comuni, come la definizione del jobCPUs, v e la memoria. Viene eseguito come una raccolta di processi di base correlati ma separati che potrebbero essere distribuiti su più host ed eseguiti contemporaneamente. I job di array sono il modo più efficiente per eseguire lavori estremamente paralleli come simulazioni Monte Carlo, sweep parametrici o lavori di rendering di grandi dimensioni.
AWS Batch i lavori di array vengono inviati proprio come i normali lavori. Tuttavia, devi specificare la dimensione dell'array (tra 2 e 10.000) per definire la quantità di processi figlio da eseguire nell'array. Se invii un processo con una dimensione dell'array di 1.000, un singolo processo viene eseguito e genera 1.000 processi figlio. Il processo in array è un riferimento o un puntatore per gestire tutti i processi figlio. In questo modo, puoi inviare carichi di lavoro di grandi dimensioni con una singola query. Il timeout specificato nel `attemptDurationSeconds` parametro si applica a ogni lavoro secondario. Il job dell'array principale non ha un timeout.
Quando si invia un processo di array, il job dell'array principale ottiene un ID di AWS Batch lavoro normale. Ogni job secondario ha lo stesso ID di base. Tuttavia, l'indice dell'array per il job secondario viene aggiunto alla fine dell'ID principale, ad esempio `example_job_ID:0` per il primo job figlio dell'array.
Il processo dell'array principale può immettere uno `SUCCEEDED` stato `SUBMITTED` `PENDING``FAILED`,,. Un processo principale dell'array viene aggiornato a `PENDING` quando viene aggiornato un processo figlio a`RUNNABLE`. Per ulteriori informazioni sulle dipendenze lavorative, vedere[Dipendenze dal lavoro](job_dependencies.md).
In fase di runtime, la variabile di ambiente `AWS_BATCH_JOB_ARRAY_INDEX` è impostata sul numero di indice dell'array del processo corrispondente del container. Il primo array job index è numerato e `0` i tentativi successivi sono in ordine crescente (ad esempio, 1, 2 e 3). È possibile utilizzare questo valore di indice per controllare il modo in cui vengono indicati i diversi elementi figlio dei processi in array. Per ulteriori informazioni, consulta [Utilizza l'array job index per controllare la differenziazione dei job](array_index_example.md).
Per le dipendenze di processi in array, puoi specificare un tipo di dipendenza, ad esempio `SEQUENTIAL` o `N_TO_N`. Puoi specificare una dipendenza di tipo `SEQUENTIAL` (senza specificare un ID del processo) in modo che ogni processo figlio nell'array venga completato in maniera sequenziale a partire dall'indice 0. Ad esempio, se invii un processo in array con una dimensione dell'array di 100 e specifichi una dipendenza di tipo `SEQUENTIAL`, 100 processi figlio vengono generati in sequenza, il primo dei quali deve avere esito positivo prima che il successivo processo figlio possa iniziare. L'illustrazione di seguito mostra il processo A, un processo in array con una dimensione dell'array di 10. Ciascun processo nell'indice dei figli del processo A dipende dal processo figlio precedente. Il processo A:1 non può iniziare fino a quando il processo A:0 non termina.
![\[Flowchart showing Job-A with sequential child jobs A:0 through A:9, connected by arrows.\]](http://docs.aws.amazon.com/it_it/batch/latest/userguide/images/sequential-dep.png)
Puoi anche specificare una dipendenza tipo `N_TO_N` con un ID processo per processi dell’array. In questo modo, prima di iniziare, ciascun figlio nell'indice di questo processo deve attendere il completamento del figlio nell'indice corrispondente di ciascuna dipendenza. La figura seguente mostra Job A e Job B, due job di array con una dimensione di array di 10.000 ciascuno. Ciascun processo nell'indice dei figli del processo B dipende dal corrispondente indice nel processo A. Il processo B:1 non può iniziare fino al completamento del processo 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/it_it/batch/latest/userguide/images/n-to-n-dep.png)
Se si annulla o si termina un processo di array principale, tutti i job secondari vengono annullati o terminati con esso. È possibile annullare o interrompere singoli lavori per bambini (il che li sposta a uno `FAILED` status) senza influire sugli altri lavori secondari. Tuttavia, se un job child array fallisce (da solo o annullando o interrompendo manualmente il lavoro), anche il lavoro principale fallisce. In questo scenario, il lavoro principale passa al completamento di tutti `FAILED` i lavori secondari.
Per ulteriori informazioni sulla ricerca e il filtraggio dei lavori relativi agli array, vedere. [Cerca offerte di lavoro in una coda di lavoro](searching-filtering-jobs.md)
**Topics**
+ [Esempio di flusso di lavoro di tipo array job](example_array_job.md)
+ [Utilizza l'array job index per controllare la differenziazione dei job](array_index_example.md)
# Esempio di flusso di lavoro di tipo array job
Un flusso di lavoro comune per AWS Batch i clienti consiste nell'eseguire un processo di configurazione con prerequisiti, eseguire una serie di comandi su un gran numero di attività di input e quindi concludere con un processo che aggrega i risultati e scrive dati di riepilogo su Amazon S3, DynamoDB, Amazon Redshift o Aurora.
Esempio:
+ `JobA`: un processo standard, non basato su array, che esegue una rapida elencazione e convalida dei metadati degli oggetti in un bucket Amazon S3,. `BucketA` La sintassi [SubmitJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html)JSON è la seguente.
```
{
"jobName": "JobA",
"jobQueue": "ProdQueue",
"jobDefinition": "JobA-list-and-validate:1"
}
```
+ `JobB`: Un lavoro di matrice con 10.000 copie da cui dipende che esegue comandi `JobA` che richiedono un uso intensivo della CPU su ogni oggetto in `BucketA` ingresso e carica i risultati su. `BucketB` La sintassi [SubmitJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html)JSON è la seguente.
```
{
"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`: Un altro processo di array di 10.000 copie che dipende `JobB` da un modello di `N_TO_N` dipendenza, che esegue comandi che richiedono molta memoria per ogni elemento in esso`BucketB`, scrive i metadati su DynamoDB e carica l'output risultante su. `BucketC` La sintassi JSON è la seguente. [SubmitJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html)
```
{
"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 processo di array che esegue 10 passaggi di convalida, ciascuno dei quali richiede una query su DynamoDB e che può interagire con uno qualsiasi dei bucket Amazon S3 di cui sopra. Ciascuno dei passaggi della procedura esegue lo stesso comando`JobD`. Tuttavia, il comportamento è diverso in base al valore della variabile di `AWS_BATCH_JOB_ARRAY_INDEX` ambiente all'interno del contenitore del lavoro. Questi passaggi di convalida vengono eseguiti in sequenza (ad esempio, `JobD:0` e poi`JobD:1`). La sintassi [SubmitJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html)JSON è la seguente.
```
{
"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 processo finale, non basato su array, che esegue alcune semplici operazioni di pulizia e invia una notifica Amazon SNS con un messaggio che la pipeline è stata completata e un collegamento all'URL di output. La sintassi [SubmitJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html)JSON è la seguente.
```
{
"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"
}
]
}
```
# Utilizza l'array job index per controllare la differenziazione dei job
Questo tutorial descrive come utilizzare la variabile di `AWS_BATCH_JOB_ARRAY_INDEX` ambiente per differenziare i lavori dei bambini. Ogni lavoro secondario viene assegnato a questa variabile. L'esempio utilizza il numero di indice del lavoro secondario per leggere una riga specifica in un file. Quindi, sostituisce il parametro associato a quel numero di riga con un comando all'interno del contenitore del lavoro. Il risultato è che puoi avere più AWS Batch job che eseguono la stessa immagine Docker e gli stessi argomenti di comando. Tuttavia, i risultati sono diversi perché l'array job index viene utilizzato come modificatore.
In questo tutorial creerai un file di testo contenente tutti i colori dell'arcobaleno, ciascuno su una riga. Quindi, si crea uno script di ingresso per un contenitore Docker che converte l'indice in un valore che può essere utilizzato per un numero di riga nel file a colori. L'indice inizia da zero, ma i numeri di riga iniziano da uno. Crea un Dockerfile che copia i file di colore e indice nell'immagine del contenitore e imposta `ENTRYPOINT` l'immagine nello script di ingresso. Il Dockerfile e le risorse sono creati su un'immagine Docker che viene inviata ad Amazon ECR. Quindi registri una definizione di processo che utilizzi la tua nuova immagine del contenitore, invii un AWS Batch array job con quella definizione di processo e visualizzi i risultati.
**Topics**
+ [Prerequisiti](array-tutorial-prereqs.md)
+ [Crea un'immagine del contenitore](build-index-container.md)
+ [Invia la tua immagine ad Amazon ECR](push-array-image.md)
+ [Crea e registra una definizione di lavoro](create-array-job-def.md)
+ [Invia un lavoro AWS Batch di array](submit-array-job.md)
+ [Visualizza i log dei lavori dell'array](#array-tutorial-logs)
# Prerequisiti
Questo flusso di lavoro tutorial presenta i seguenti prerequisiti:
+ Un ambiente AWS Batch di calcolo. Per ulteriori informazioni, consulta [Crea un ambiente di elaborazione](create-compute-environment.md).
+ Una coda AWS Batch di lavoro e l'ambiente di elaborazione associato. Per ulteriori informazioni, consulta [Creare una coda di lavoro](create-job-queue.md).
+ È AWS CLI installato sul sistema locale. Per ulteriori informazioni, vedere [>Installazione di AWS Command Line Interface nella](https://docs.aws.amazon.com/cli/latest/userguide/installing.html) *Guida per l'AWS Command Line Interface utente*.
+ Il Docker installato sul sistema locale. Per ulteriori informazioni, consulta la sezione relativa al [Docker CE](https://docs.docker.com/install/) nella documentazione del Docker.
# Crea un'immagine del contenitore
È possibile utilizzarlo `AWS_BATCH_JOB_ARRAY_INDEX` in una definizione di processo nel parametro di comando. Tuttavia, si consiglia di creare un'immagine del contenitore che utilizzi invece la variabile in uno script entrypoint. In questa sezione viene descritto come creare un'immagine del container di questo tipo.
**Per creare l'immagine del container Docker**
1. Crea una nuova directory da utilizzare come WorkSpace dell'immagine Docker e aprila.
1. Create un file denominato `colors.txt` nella directory del workspace e incollate quanto segue al suo interno.
```
red
orange
yellow
green
blue
indigo
violet
```
1. Crea un file denominato `print-color.sh` nella cartella del tuo spazio di lavoro e incolla quanto segue al suo interno.
**Nota**
La variabile `LINE` è impostata su `AWS_BATCH_JOB_ARRAY_INDEX` \$11 poiché l'indice dell'array inizia da 0, mentre i numeri di riga iniziano da 1. La `COLOR` variabile è impostata sul colore associato al numero di riga. `colors.txt`
```
#!/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. Crea un file denominato `Dockerfile` nella cartella del tuo spazio di lavoro e incolla il seguente contenuto al suo interno. Questo file copia i file precedenti nel container e imposta lo script entrypoint in modo che venga eseguito all'avvio del container.
```
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. Creazione dell'immagine Docker.
```
$ docker build -t print-color .
```
1. Esegui il test del container utilizzando lo script riportato di seguito. Questo script imposta la `AWS_BATCH_JOB_ARRAY_INDEX` variabile su 0 localmente e poi la incrementa per simulare il funzionamento di un array job con sette figli.
```
$ 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
```
Di seguito è riportato l'output.
```
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.
```
# Invia la tua immagine ad Amazon ECR
Ora che hai creato e testato il tuo contenitore Docker, inseriscilo in un archivio di immagini. Questo esempio utilizza Amazon ECR, ma è possibile utilizzare un altro registro, ad esempio DockerHub.
1. Crea un archivio di immagini Amazon ECR per archiviare l'immagine del contenitore. Questo esempio utilizza solo il AWS CLI, ma puoi anche usare il. Console di gestione AWS Per ulteriori informazioni, consulta [Creating a repository](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-create.html) nella *Amazon Elastic Container Registry User Guide*.
```
$ aws ecr create-repository --repository-name print-color
```
1. Etichetta l'`print-color`immagine con l'URI del repository Amazon ECR restituito dal passaggio precedente.
```
$ docker tag print-color aws_account_id.dkr.ecr.region.amazonaws.com/print-color
```
1. Accedi al tuo registro Amazon ECR. Per maggiori informazioni, consulta [Autorizzazioni del registro](https://docs.aws.amazon.com/AmazonECR/latest/userguide/Registries.html#registry_auth) nella *Guida per l'utente di 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. Invia la tua immagine ad Amazon ECR.
```
$ docker push aws_account_id.dkr.ecr.region.amazonaws.com/print-color
```
# Crea e registra una definizione di lavoro
Ora che l'immagine Docker si trova in un registro di immagini, puoi specificarla in una definizione di AWS Batch lavoro. Quindi, puoi utilizzarlo in un secondo momento per eseguire un processo di array. Questo esempio utilizza solo AWS CLI. Tuttavia, puoi anche usare Console di gestione AWS. Per ulteriori informazioni, consulta [Creare una definizione di processo a nodo singolo](create-job-definition.md).
**Per creare una definizione del processo**
1. Crea un file denominato `print-color-job-def.json` nella cartella del tuo spazio di lavoro e incolla quanto segue al suo interno. Sostituisci l'URI del repository di immagini con l'URI dell'immagine personalizzata.
```
{
"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. Registra la definizione del lavoro con AWS Batch.
```
$ aws batch register-job-definition --cli-input-json file://print-color-job-def.json
```
# Invia un lavoro AWS Batch di array
Dopo aver registrato la definizione del processo, è possibile inviare un lavoro di AWS Batch array che utilizzi la nuova immagine del contenitore.
**Per inviare un lavoro AWS Batch di array**
1. Crea un file denominato `print-color-job.json` nella cartella del tuo spazio di lavoro e incolla quanto segue al suo interno.
**Nota**
Questo esempio utilizza la coda dei lavori menzionata nella [Prerequisiti](array-tutorial-prereqs.md) sezione.
```
{
"jobName": "print-color",
"jobQueue": "existing-job-queue",
"arrayProperties": {
"size": 7
},
"jobDefinition": "print-color"
}
```
1. Invia il lavoro alla tua coda di AWS Batch lavoro. Annota l'ID del lavoro restituito nell'output.
```
$ aws batch submit-job --cli-input-json file://print-color-job.json
```
1. Descrivi lo stato del processo e attendi che il processo venga impostato su `SUCCEEDED`.
## Visualizza i log dei lavori dell'array
Una volta raggiunto `SUCCEEDED` lo stato del lavoro, puoi visualizzare CloudWatch i log dal contenitore del lavoro.
**Per visualizzare i log del lavoro in Logs CloudWatch**
1. Apri la AWS Batch console all'indirizzo. [https://console.aws.amazon.com/batch/](https://console.aws.amazon.com/batch/)
1. Nel riquadro di navigazione a sinistra, scegli **Jobs (Processi)**.
1. In **Job queue (Coda di processi)**, seleziona una coda.
1. Nella sezione **Status (Stato)**, scegli **succeeded (completato)**.
1. Per visualizzare tutti i processi figlio del processo in array, seleziona l'ID processo restituito nella sezione precedente.
1. Per visualizzare i log del container del processo, seleziona uno dei processi figlio e scegli **View logs (Visualizza log)**.
![\[Array Job Container logs\]](http://docs.aws.amazon.com/it_it/batch/latest/userguide/images/array-logs.png)
1. Visualizza gli altri log del processo figlio. Ciascun job restituisce un colore diverso dell'arcobaleno.
# Esegui lavori GPU
I job GPU consentono di eseguire lavori che utilizzano un'istanza. GPUs
Sono supportati i seguenti tipi di istanza Amazon EC2 basati su GPU. [https://aws.amazon.com/ec2/instance-types/trn1/](https://aws.amazon.com/ec2/instance-types/trn1/) [ 2 istanze Dl1 e istanze](https://aws.amazon.com/ec2/instance-types/dl1/) [Amazon EC2](https://aws.amazon.com/ec2/instance-types/dl2q/) Dl2.
| Tipo di istanza | GPUs | Memoria GPU | v CPUs | Memoria | Larghezza di banda di rete |
| --- | --- | --- | --- | --- | --- |
| g3s.xlarge | 1 | 8 GiB | 4 | 30,5 GiB | 10 Gb/s |
| g3.4xlarge | 1 | 8 GiB | 16 | 122 GiB | Fino a 10 Gb/s |
| g3.8xlarge | 2 | 16 GiB | 32 | 24 GiB | 10 Gb/s |
| g3.16xlarge | 4 | 32 GiB | 64 | 488 GiB | 25 Gb/s |
| g4dn.xlarge | 1 | 16 GiB | 4 | 16 GiB | Fino a 25 Gb/s |
| g4dn.2xlarge | 1 | 16 GiB | 8 | 32 GiB | Fino a 25 Gb/s |
| g4dn.4xlarge | 1 | 16 GiB | 16 | 64 GiB | Fino a 25 Gb/s |
| g4dn.8xlarge | 1 | 16 GiB | 32 | 128 GiB | 50 Gb/s |
| g4dn.12xlarge | 4 | 64 GiB | 48 | 192 GiB | 50 Gb/s |
| g4dn.16xlarge | 1 | 16 GiB | 64 | 256 GiB | 50 Gb/s |
| g5.xlarge | 1 | 24 GiB | 4 | 16 GiB | Fino a 10 Gb/s |
| g5.2xlarge | 1 | 24 GiB | 8 | 32 GiB | Fino a 10 Gb/s |
| g5.4xlarge | 1 | 24 GiB | 16 | 64 GiB | Fino a 25 Gb/s |
| g5.8xlarge | 1 | 24 GiB | 32 | 128 GiB | 25 Gb/s |
| g5.16xlarge | 1 | 24 GiB | 64 | 256 GiB | 25 Gb/s |
| g5.12xlarge | 4 | 96 GiB | 48 | 192 GiB | 40 Gb/s |
| g5.24xlarge | 4 | 96 GiB | 96 | 384 GiB | 50 Gb/s |
| g5.48xlarge | 8 | 192 GiB | 192 | 768 GiB | 100 Gb/s |
| g5g.xlarge | 1 | 16 GiB | 4 | 8 GiB | Fino a 10 Gb/s |
| g5g.2xlarge | 1 | 16 GiB | 8 | 16 GiB | Fino a 10 Gb/s |
| g5g.4xlarge | 1 | 16 GiB | 16 | 32 GiB | Fino a 10 Gb/s |
| g5g.8xlarge | 1 | 16 GiB | 32 | 64 GiB | 12 GBps |
| g5g.16xlarge | 2 | 32 GiB | 64 | 128 GiB | 25 Gb/s |
| g5g.metal | 2 | 32 GiB | 64 | 128 GiB | 25 Gb/s |
| g6.xlarge | 1 | 24 GiB | 4 | 16 GiB | Fino a 10 Gb/s |
| g6.2xlarge | 1 | 24 GiB | 8 | 32 GiB | Fino a 10 Gb/s |
| g6.4xlarge | 1 | 24 GiB | 16 | 64 GiB | Fino a 25 Gb/s |
| g6.8xlarge | 1 | 24 GiB | 32 | 128 GiB | 25 Gb/s |
| g6.16xlarge | 1 | 24 GiB | 64 | 256 GiB | 25 Gb/s |
| g6.12xlarge | 4 | 96 GiB | 48 | 192 GiB | 40 Gb/s |
| g6.24xlarge | 4 | 96 GiB | 96 | 384 GiB | 50 Gb/s |
| g6.48xlarge | 8 | 192 GiB | 192 | 768 GiB | 100 Gb/s |
| g6e.xlarge | 1 | 48 GiB | 4 | 32 GiB | Fino a 20 Gbps |
| g6e.2xlarge | 1 | 48 GiB | 8 | 64 GiB | Fino a 20 Gbps |
| g6e.4xlarge | 1 | 48 GiB | 16 | 128 GiB | 20 Gb/s |
| g6e.8xlarge | 1 | 48 GiB | 32 | 256 GiB | 25 Gb/s |
| g6e.16xlarge | 1 | 48 GiB | 64 | 512 GiB | 35 Gbps |
| g6e.12xlarge | 4 | 192 GiB | 48 | 384 GiB | 100 Gb/s |
| g6e.24xlarge | 4 | 192 GiB | 96 | 768 GiB | 200 Gb/s |
| g6e.48xlarge | 8 | 384 GiB | 192 | 1536 GiB | 400 Gb/s |
| gr6.4xlarge | 1 | 24 GiB | 16 | 128 GiB | Fino a 25 Gb/s |
| gr6.8xlarge | 1 | 24 GiB | 32 | 256 GiB | 25 Gb/s |
| p2.xlarge | 1 | 12 GiB | 4 | 61 GiB | Elevata |
| p2.8xlarge | 8 | 96 GiB | 32 | 488 GiB | 10 Gb/s |
| p2.16xlarge | 16 | 192 GiB | 64 | 732 GiB | 20 Gb/s |
| p3.2xlarge | 1 | 16 GiB | 8 | 61 GiB | Fino a 10 Gb/s |
| p3.8xlarge | 4 | 64 GiB | 32 | 24 GiB | 10 Gb/s |
| p3.16xlarge | 8 | 128 GiB | 64 | 488 GiB | 25 Gb/s |
| p3dn.24xlarge | 8 | 256 GiB | 96 | 768 GiB | 100 Gb/s |
| p4d.24xlarge | 8 | 320 GiB | 96 | 1152 GiB | 400 Gb/s |
| p4de.24xlarge | 8 | 640 GiB | 96 | 1152 GiB | 400 Gb/s |
| p5.48xlarge | 8 | 640 GiB | 192 | 2 TiB | 3200 Gbps |
| p5e.48xlarge | 8 | 128 GiB | 192 | 2 TiB | 3200 Gbps |
| p5en.48xlarge | 8 | 128 GiB | 192 | 2 TiB | 3200 Gbps |
| p6-b200.48xlarge | 8 | 1440 GiB | 192 | 2 TiB | 100 Gb/s |
| trn1.2xlarge | 1 | 32 GiB | 8 | 32 GiB | Fino a 12,5 Gb/s |
| 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 | Fino a 25 Gb/s |
| inf1.2xlarge | 1 | 8 GiB | 8 | 16 GiB | Fino a 25 Gb/s |
| inf1.6xlarge | 4 | 32 GiB | 24 | 48 GiB | 25 Gb/s |
| inf1.24xlarge | 16 | 128 GiB | 96 | 192 GiB | 100 Gb/s |
| inf2.xlarge | 1 | 32 GiB | 4 | 16 GiB | Fino a 15 Gb/s |
| inf2.8xlarge | 1 | 32 GiB | 32 | 128 GiB | Fino a 25 Gb/s |
| inf2.24xlarge | 6 | 192 GiB | 96 | 384 GiB | 50 Gb/s |
| inf2.48xlarge | 12 | 384 GiB | 192 | 768 GiB | 100 Gb/s |
| dl1.24xlarge | 8 | 256 GiB | 96 | 768 GiB | 400 Gb/s |
| dl2q.24xlarge | 8 | 128 GiB | 96 | 768 GiB | 100 Gb/s |
**Nota**
Per i lavori con GPU supporta AWS Batch solo i tipi di istanze con NVIDIA. GPUs Ad esempio, la [https://aws.amazon.com/ec2/instance-types/g4/#Amazon_EC2_G4ad_instances](https://aws.amazon.com/ec2/instance-types/g4/#Amazon_EC2_G4ad_instances)famiglia non è supportata per la pianificazione tramite GPU. Puoi comunque utilizzare [https://aws.amazon.com/ec2/instance-types/g4/#Amazon_EC2_G4ad_instances](https://aws.amazon.com/ec2/instance-types/g4/#Amazon_EC2_G4ad_instances)on AWS Batch definendo solo i requisiti di vcpu e memoria nella definizione del processo, quindi accedendo direttamente alle GPU host tramite la personalizzazione in un [modello di lancio di Amazon EC2, i dati utente con](launch-templates.md#lt-user-data.title) un'AMI ottimizzata per il calcolo Amazon ECS o Amazon EKS o un'AMI personalizzata per l'utilizzo di AMD. GPUs
I tipi di istanza che utilizzano un' ARM64 architettura sono supportati per i lavori GPU su dati AMIs forniti su misura AWS Batch o dati utente di Amazon EC2 a cui accedere GPUs tramite codice e configurazioni personalizzati. Ad esempio, la famiglia di istanze [https://aws.amazon.com/ec2/instance-types/g5g/](https://aws.amazon.com/ec2/instance-types/g5g/).
Il parametro [ResourceRequirements](job_definition_parameters.md#ContainerProperties-resourceRequirements) per la definizione del processo specifica il numero di GPUs da aggiungere al contenitore. Questo numero di non GPUs è disponibile per nessun altro processo eseguito su quell'istanza per la durata di tale processo. Tutti i tipi di istanze in un ambiente di calcolo che esegue processi GPU devono appartenere alle `p3` famiglie di `g6` istanze `p4` `p5``p6`,`g3`,`g3s`,`g4`,,`g5`, o. Se ciò non viene fatto, un job GPU potrebbe rimanere bloccato nello stato. `RUNNABLE`
I lavori che non utilizzano il GPUs possono essere eseguiti su istanze GPU. Tuttavia, l'esecuzione su istanze GPU potrebbe costare di più rispetto a istanze simili non GPU. A seconda della vCPU, della memoria e del tempo specifici necessari, questi job non GPU potrebbero bloccare l'esecuzione dei job GPU.
**Topics**
+ [Crea un Kubernetes cluster basato su GPU su Amazon EKS](create-gpu-cluster-eks.md)
+ [Crea una definizione di processo GPU Amazon EKS](create-eks-gpu-job-definition.md)
+ [Esegui un job GPU nel tuo cluster Amazon EKS](run-gpu-job-eks-cluster.md)
# Crea un Kubernetes cluster basato su GPU su Amazon EKS
Prima di creare un Kubernetes cluster basato su GPU su Amazon EKS, devi aver completato i passaggi indicati. [Guida introduttiva ad AWS Batch Amazon EKS](getting-started-eks.md) Inoltre, considera anche quanto segue:
+ AWS Batch supporta i tipi di istanze con NVIDIA GPUs.
+ Per impostazione predefinita, AWS Batch seleziona l'AMI accelerata Amazon EKS con la Kubernetes versione che corrisponde alla versione del piano di controllo del cluster 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 non gestisce il plug-in del dispositivo NVIDIA GPU per tuo conto. È necessario installare questo plug-in nel cluster Amazon EKS e consentirgli di indirizzare i AWS Batch nodi. Per ulteriori informazioni, consulta [Enabling GPU Support in Kubernetes](https://github.com/NVIDIA/k8s-device-plugin#enabling-gpu-support-in-kubernetes) on GitHub.
Per configurare il plugin del NVIDIA dispositivo (`DaemonSet`) per indirizzare i AWS Batch nodi, esegui i seguenti comandi.
```
# 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
```
Non è consigliabile combinare carichi di lavoro basati su calcolo (CPU e memoria) con carichi di lavoro basati su GPU nelle stesse combinazioni di ambiente di calcolo e coda di lavoro. Questo perché i processi di elaborazione possono utilizzare la capacità della GPU.
Per allegare code di lavoro, esegui i seguenti comandi.
```
$ 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
```
# Crea una definizione di processo GPU Amazon EKS
Al momento `nvidia.com/gpu` è supportata solo questa opzione e il valore della risorsa impostato deve essere un numero intero. Non puoi usare frazioni di GPU. *Per ulteriori informazioni, consulta [Schedule GPUs](https://kubernetes.io/docs/tasks/manage-gpus/scheduling-gpus/) nella Kubernetes documentazione.*
Per registrare una definizione di processo GPU per Amazon EKS, esegui i seguenti comandi.
```
$ 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
```
# Esegui un job GPU nel tuo cluster Amazon EKS
La risorsa GPU non è comprimibile. AWS Batch **crea una specifica del pod per i lavori GPU in cui il valore della **richiesta è uguale al valore dei limiti**.** Questo è un requisito. Kubernetes
Per inviare un job GPU, esegui i seguenti comandi.
```
$ 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"
}
```
# Visualizza i AWS Batch lavori in una coda di lavoro
Puoi visualizzare e filtrare i tuoi lavori in AWS Batch. Questa funzione offre la possibilità di visualizzare una coda di lavori esistente e filtrarne i lavori in base a una delle tre opzioni.
La ricerca e il filtro sono in grado di recuperare lavori che non si trovano in uno stato terminale (`SUCCEEDED`o`FAILED`). Una volta che lo stato di un lavoro è `SUCCEEDED` o `FAILED` dovresti essere in grado di recuperarlo per un massimo di sette giorni. Puoi comunque visualizzare i EventBridge log di un'offerta di lavoro CloudWatch o di Amazon.
Utilizza questa procedura per elencare tutti i lavori in una coda di lavori nella AWS Batch console. Facoltativamente, utilizzare il campo **Filtra risultati** per restringere i risultati in base ai criteri specificati.
1. Passare alla [console AWS Batch](https://console.aws.amazon.com/batch/home).
1. Nel riquadro di navigazione, scegli **Jobs**.
1. Espandi l'elenco a discesa **Job queue** e scegli la coda dei lavori in cui desideri cercare.
**Nota**
Puoi cercare offerte di lavoro all'interno di una sola coda di lavoro alla volta.
1. Nel campo **Filtra risultati**, inserisci le parole chiave da includere nei risultati. È possibile utilizzare questo campo per filtrare in base al **nome del lavoro**, **allo stato** o all'**ID del lavoro**. A seconda della proprietà, è possibile che sia necessario definire operatori aggiuntivi, ad esempio equals (=) o contains (:).
**Nota**
SageMaker **Le code dei lavori di formazione supportano solo il filtraggio in base al **nome del lavoro e all'ID del** lavoro.**
1. Selezionare **Search (Cerca)**.
# AWS Batch Cerca offerte di lavoro in una coda di lavoro
Puoi cercare e filtrare i tuoi lavori AWS Batch utilizzando Job search. Questa funzione offre la possibilità di cercare all'interno di una coda di lavoro esistente e filtrarne i lavori.
La ricerca e il filtro sono in grado di recuperare lavori che non si trovano in uno stato terminale (`SUCCEEDED`o`FAILED`). Una volta che lo stato di un lavoro è `SUCCEEDED` o `FAILED` dovresti essere in grado di recuperarlo per un massimo di sette giorni. Puoi comunque visualizzare i EventBridge log di un'offerta di lavoro CloudWatch o di Amazon.
Per eseguire la ricerca utilizzando più criteri contemporaneamente, utilizza la funzione **di ricerca avanzata**. Ad esempio, puoi includere uno o tutti i seguenti filtri: **Stato**, **intervallo di date** e **criteri aggiuntivi** (ad esempio nome, definizione del lavoro o ID del lavoro).
## Cerca AWS Batch offerte di lavoro (AWS Console)
Utilizzare questa procedura per cercare i lavori in una coda di lavoro nella AWS Batch console.
1. Passare alla [console AWS Batch](https://console.aws.amazon.com/batch/home).
1. Nel riquadro di navigazione, scegli **Jobs**.
1. Attiva la **ricerca avanzata**.
1. Espandi l'elenco a discesa **Job queue** e scegli la coda dei lavori in cui desideri cercare.
**Nota**
Puoi cercare offerte di lavoro all'interno di una sola coda di lavoro alla volta.
1. Per le **opzioni di ricerca:**
1. Nell'elenco a discesa **Stato** puoi scegliere uno o più stati in base ai quali filtrare. Per ulteriori informazioni, consultare [Job stati](job_states.md) e [Stato del lavoro di servizio](service-job-status.md).
**Nota**
Gli Array job parents vengono aggiornati sulla `PENDING` data di aggiornamento di un job secondario `RUNNABLE` e rimangono attivi mentre i job `PENDING` secondari sono in esecuzione. Per visualizzare questi lavori, filtra per `PENDING` stato finché tutti i lavori secondari non raggiungono lo stato terminale.
1. Scegli **Intervallo di date** per filtrare i risultati in base a un intervallo di data e ora.
+ Scegli **la modalità Relativa** per cercare lavori con una data di creazione all'interno di un intervallo di tempo contando a ritroso rispetto alla data e all'ora correnti.
+ Scegli **la modalità Assoluta** per cercare lavori con una data di creazione entro un intervallo di data e ora specificato.
1. Nel campo **Criteri aggiuntivi**, inserisci le parole chiave da includere nei risultati della ricerca. Ad esempio, puoi utilizzare questo campo per cercare in base al **nome del lavoro**, alla **definizione del lavoro**, all'**ID del lavoro** o all'**identificatore di condivisione**. A seconda della proprietà, è possibile che sia necessario definire operatori aggiuntivi, ad esempio equals (=) o contains (:).
**Nota**
SageMaker **Le code dei lavori di formazione supportano solo il filtraggio in base al **nome del lavoro e all'ID del** lavoro.**
**Nota**
Quando si filtra in base all'**identificatore di condivisione**, è anche possibile specificare lo stato del lavoro. Questa è un'eccezione alla restrizione in cui altri filtri escludono il filtraggio dello stato del lavoro.
1. Selezionare **Search (Cerca)**.
## Cerca e filtra i AWS Batch lavori ()AWS CLI
Utilizzare questa procedura per elencare tutti i lavori in una coda di lavoro con. AWS CLI Facoltativamente, utilizzare il parametro **-filters** per restringere i risultati in base ai criteri specificati.
------
#### [ Search job queue (AWS CLI) ]
È possibile utilizzare il comando [list-jobs](https://docs.aws.amazon.com/cli/latest/reference/batch/list-jobs.html) per cercare e filtrare una coda di lavori.
Ad esempio, puoi cercare una coda di lavoro in base al nome del lavoro:
```
aws batch list-jobs \
--job-queue my-job-queue \
--filters name=JOB_NAME,values="my-job"
```
Filtra i lavori per identificatore di condivisione:
```
aws batch list-jobs \
--job-queue my-job-queue \
--filters name=SHARE_IDENTIFIER,values="my-share"
```
Quando si filtra per identificatore di condivisione, è possibile includere lo stato del lavoro:
```
aws batch list-jobs \
--job-queue my-job-queue \
--job-status RUNNING \
--filters name=SHARE_IDENTIFIER,values="my-share"
```
Nel comando precedente, apporta le modifiche seguenti:
+ *my-job-queue*Sostituiscilo con il nome della tua coda di lavoro.
+ Sostituiscilo *my-job* con il nome del tuo lavoro.
+ Sostituisci *my-share* con l'identificatore di condivisione in base al quale desideri filtrare.
------
#### [ Search service job queue (AWS CLI) ]
È possibile utilizzare il [list-service-jobs](https://docs.aws.amazon.com/cli/latest/reference/batch/list-service-jobs.html)comando per cercare e filtrare una coda di lavori di assistenza.
Ad esempio, è possibile cercare una coda di lavori di assistenza in base al nome del lavoro:
```
aws batch list-service-jobs \
--job-queue my-sm-queue \
--filters name=JOB_NAME,values="my-sm-job"
```
Filtra i lavori di assistenza in base all'identificatore di condivisione:
```
aws batch list-service-jobs \
--job-queue my-sm-queue \
--filters name=SHARE_IDENTIFIER,values="my-share"
```
Nel comando precedente, apporta le modifiche seguenti:
+ Sostituisci *my-sm-queue* con il nome della tua coda di lavoro di assistenza.
+ *my-sm-job*Sostituiscilo con il nome della tua mansione di assistenza.
+ Sostituiscilo *my-share* con l'identificatore di condivisione in base al quale desideri filtrare.
------
# Modalità di rete per i lavori AWS Batch
La tabella seguente descrive le modalità di rete e l'utilizzo tipico dei tipi di AWS Batch job. Consulta i link nella colonna «Job type» per maggiori dettagli su considerazioni e comportamenti.
| Tipo di processo | Modalità di rete supportate | Utilizzo tipico |
| --- | --- | --- |
| [Un lavoro semplice con ECS-EC2](jobs.md) | host | Utilizzato per i carichi di lavoro batch imbarazzantemente paralleli più scalabili che richiedono solo l'uscita verso vpc definito in Compute Environment. |
| [Job parallelo multi-nodo ECS-EC2](multi-node-parallel-jobs.md) | awsvpc | Utilizzato per carichi di lavoro distribuiti su più host (nodi) strettamente accoppiati, modellati come un singolo lavoro con comunicazioni coordinate tra i nodi di attività. |
| [Un lavoro semplice con ECS-Fargate](when-to-use-fargate.md) | awsvpc | True serverless per carichi di lavoro in batch incredibilmente paralleli. In genere il TCO più basso e il modello di lavoro con il massimo isolamento dei container. |
| [Un lavoro semplice con EKS-EC2](eks-jobs.md) | host e pod | Utilizzato per carichi di lavoro batch altamente scalabili e incredibilmente paralleli che richiedono solo l'uscita verso vpc definito in Compute Environment. L'impostazione predefinita è la rete host. |
| [Job parallelo multi-nodo EKS-EC2](mnp-eks-jobs.md) | host e pod | Utilizzato per carichi di lavoro distribuiti su più host (nodi) strettamente accoppiati, modellati come un unico lavoro con comunicazioni coordinate tra i nodi del pod. L'impostazione predefinita è la rete host. |
# Visualizza i registri dei AWS Batch lavori in CloudWatch Logs
Puoi [configurare i tuoi AWS Batch lavori](using_cloudwatch_logs.md#using_cloudwatch_logs.title) per inviare informazioni di registro ad Amazon CloudWatch Logs. In questo modo, puoi visualizzare diversi log dei tuoi lavori in un'unica comoda posizione. Per ulteriori informazioni, consulta [Utilizzo dei CloudWatch registri con AWS Batch](using_cloudwatch_logs.md).
Puoi anche utilizzare i **Job logs** nella AWS Batch console per monitorare o risolvere un processo. AWS Batch
1. Apri la [AWS Batch console](https://console.aws.amazon.com/batch/home).
1. Scegliere **Jobs (Processi)**. Per informazioni più dettagliate sull'ordinamento e il filtraggio dei lavori nella coda dei lavori, consulta e [Visualizza i AWS Batch lavori in una coda di lavoro](view-jobs.md) [Cerca offerte di lavoro in una coda di lavoro](searching-filtering-jobs.md)
1. Per **Job queue**, scegli la coda lavori che desideri.
**Suggerimento**
Se ci sono diversi lavori nella coda dei lavori, puoi attivare **Ricerca e filtro per trovarli** più velocemente. Per ulteriori informazioni, consulta [AWS Batch Cerca offerte di lavoro in una coda di lavoro](searching-filtering-jobs.md).
1. In **Status**, scegli lo stato del lavoro che desideri.
1. Scegli il lavoro che desideri e si aprirà la pagina **Dettagli**.
1. Nella pagina **Dettagli**, scorri verso il basso fino a **Log stream name** e scegli il link. Il link apre la pagina Amazon CloudWatch Logs relativa al lavoro.
1. (Facoltativo) Se è la prima volta che visualizzi i log, ti potrebbe essere richiesta l'autorizzazione.
Per **Autorizzazione obbligatoria**, inserisci**OK**, quindi scegli **Autorizza** per accettare gli CloudWatch addebiti di Amazon.
**Nota**
Per revocare l'autorizzazione agli addebiti: CloudWatch
**Nel riquadro di navigazione a sinistra, scegli Autorizzazioni.**
Per **Job logs**, scegliete **Modifica**.
Deseleziona la CloudWatch casella di controllo **Autorizza Batch da usare**.
Scegli **Save changes** (Salva modifiche).
# Rivedi le informazioni sul AWS Batch lavoro
È possibile esaminare le informazioni sul AWS Batch lavoro come lo stato, la definizione del lavoro e le informazioni sul contenitore.
1. Apri la [AWS Batch console](https://console.aws.amazon.com/batch/home).
1. Scegliere **Jobs (Processi)**.
1. Per **Job queue**, scegli la coda lavori che desideri.
**Suggerimento**
Se ci sono diversi lavori nella coda dei lavori, puoi attivare la **ricerca e il filtro** per trovarli più velocemente. Per ulteriori informazioni, consulta [AWS Batch Cerca offerte di lavoro in una coda di lavoro](searching-filtering-jobs.md).
1. Scegli il lavoro che desideri.
**Nota**
Puoi anche usare AWS Command Line Interface (AWS CLI) per visualizzare i dettagli di un AWS Batch lavoro. [Per ulteriori informazioni, vedere [describe-jobs](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/batch/describe-jobs.html) nel Command Reference.AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/)