Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Jobs
Jobs sind die Arbeitseinheit, mit der begonnen wurde AWS Batch. Jobs können als containerisierte Anwendungen aufgerufen werden, die auf Amazon ECS-Container-Instances in einem ECS-Cluster ausgeführt werden.
Aufträge in Containern können auf ein Container-Image, einen Befehl und Parameter verweisen. Weitere Informationen finden Sie unter [JobDefinition](https://docs.aws.amazon.com/batch/latest/APIReference/API_JobDefinition.html).
Sie können eine große Anzahl von unabhängigen, einfachen Aufträgen senden.
**Topics**
+ [Tutorial: Einen Job einreichen](submit_job.md)
+ [Servicejobs in AWS Batch](service-jobs.md)
+ [Status der Job](job_states.md)
+ [AWS Batch Variablen der Arbeitsumgebung](job_env_vars.md)
+ [Automatisierte Auftragswiederholungen](job_retries.md)
+ [Abhängigkeiten von Job](job_dependencies.md)
+ [Timeouts bei der Job](job_timeouts.md)
+ [Stellenangebote bei Amazon EKS](eks-jobs.md)
+ [Parallel ausgeführte Aufträge mit mehreren Knoten](multi-node-parallel-jobs.md)
+ [Parallel ausgeführte Aufträge mit mehreren Knoten in Amazon EKS](mnp-eks-jobs.md)
+ [Ordnen Sie Jobs an](array_jobs.md)
+ [Führen Sie GPU-Jobs aus](gpu-jobs.md)
+ [AWS Batch Jobs in einer Job-Warteschlange anzeigen](view-jobs.md)
+ [AWS Batch Suchen Sie in einer Job-Warteschlange nach Jobs](searching-filtering-jobs.md)
+ [Netzwerkmodi für AWS Batch Jobs](networking-modes-jobs.md)
+ [AWS Batch Jobprotokolle in CloudWatch Logs anzeigen](review-job-logs.md)
+ [Überprüfen Sie die AWS Batch Jobinformationen](review-job-info.md)
# Tutorial: Einen Job einreichen
Nachdem Sie eine Auftragsdefinition registriert haben, können Sie sie als Job an AWS Batch eine Job-Warteschlange senden. Sie können viele der Parameter, die in der Auftragsdefinition angegeben sind, zur Laufzeit überschreiben.
**So senden Sie einen Auftrag**
1. Öffnen Sie die AWS Batch Konsole unter [https://console.aws.amazon.com/batch/](https://console.aws.amazon.com/batch/).
1. Wählen Sie in der Navigationsleiste die aus, die Sie verwenden AWS-Region möchten.
1. Wählen Sie im Navigationsbereich die Option **Jobs (Aufträge)** aus.
1. Wählen Sie **Neuen Job einreichen** aus.
1. Geben Sie unter **Name** einen eindeutigen Namen für Ihre Jobdefinition ein. Der Name kann bis zu 128 Zeichen lang sein. Er kann Groß- und Kleinbuchstaben, Zahlen, Bindestriche (-) und Unterstriche (\$1) enthalten.
1. Wählen Sie **unter Jobdefinition** eine bestehende Jobdefinition für Ihren Job aus. Weitere Informationen finden Sie unter [Erstellen Sie eine Auftragsdefinition mit einem Knoten](create-job-definition.md).
1. Wählen Sie für **Job-Warteschlange** eine bestehende Job-Warteschlange aus. Weitere Informationen finden Sie unter [Eine Job-Warteschlange erstellen](create-job-queue.md).
1. Wählen Sie für **Jobabhängigkeiten** die Option **Jobabhängigkeiten hinzufügen** aus.
1. Geben Sie **unter Job-ID** die Job-ID für alle Abhängigkeiten ein. Wählen Sie dann **Jobabhängigkeiten hinzufügen aus**. Ein Job kann bis zu 20 Abhängigkeiten haben. Weitere Informationen finden Sie unter [Abhängigkeiten von Job](job_dependencies.md).
1. (Nur Array-Aufträge) Geben Sie für **Array-Größe** eine Array-Größe zwischen 2 und 10.000 an.
1. (Optional) Erweitern Sie **Tags** und wählen Sie dann **Tag hinzufügen** aus, um der Ressource Tags hinzuzufügen. Geben Sie einen Schlüssel und einen optionalen Wert ein und wählen Sie dann **Tag hinzufügen** aus.
1. Wählen Sie „**Nächste Seite“**.
1. Gehen Sie im Abschnitt **Job-Overrides** wie folgt vor:
1.
(Optional) Geben Sie für **Planungspriorität** einen Wert zwischen 0 und 100 ein. Höhere Werte erhalten eine höhere Priorität.
1. (Optional) Geben Sie für **Auftragsversuche** ein, wie oft maximal AWS Batch versucht wird, den Job in einen `RUNNABLE` Status zu versetzen. Sie können eine Zahl zwischen 1 und 10 eingeben. Weitere Informationen finden Sie unter [Automatisierte Auftragswiederholungen](job_retries.md).
1. (Optional) Geben Sie für das **Ausführungs-Timeout** den Timeout-Wert (in Sekunden) ein. Das Ausführungs-Timeout ist die Zeitspanne, bis ein unvollendeter Job beendet wird. Wenn ein Versuch die Timeout-Dauer überschreitet, wird er gestoppt und erhält einen Status. `FAILED` Weitere Informationen finden Sie unter [Timeouts bei der Job](job_timeouts.md). Der Mindestwert beträgt 60 Sekunden.
**Wichtig**
Verlassen Sie sich nicht darauf, dass Jobs, die auf Fargate-Ressourcen ausgeführt werden, länger als 14 Tage laufen. Nach 14 Tagen sind die Fargate-Ressourcen möglicherweise nicht mehr verfügbar, und der Job wird wahrscheinlich beendet.
1. (Optional) Aktivieren Sie die Option Tags **weitergeben, um Tags** aus dem Auftrag und der Auftragsdefinition an die Amazon ECS-Aufgabe weiterzugeben.
1. Erweitern Sie **Additional configuration (Zusätzliche Konfiguration)**.
1. (Optional) Wählen Sie **unter Bedingungen für die Wiederholungsstrategie** die Option Beim Beenden **bewerten hinzufügen** aus. Geben Sie mindestens einen Parameterwert ein und wählen Sie dann eine **Aktion** aus. Für jeden Satz von Bedingungen muss **Aktion** entweder auf „**Erneut versuchen**“ oder „**Beenden**“ gesetzt sein. Diese Aktionen bedeuten Folgendes:
+ **Wiederholen** — AWS Batch Wiederholt die Versuche, bis die von Ihnen angegebene Anzahl von Auftragsversuchen erreicht ist.
+ **Beenden** — AWS Batch beendet die Wiederholung des Auftrags.
**Wichtig**
Wenn Sie „Beim **Beenden bewerten hinzufügen**“ wählen, konfigurieren Sie mindestens einen Parameter und wählen Sie entweder eine **Aktion** oder „Beim **Beenden auswerten entfernen**“.
1. Wählen Sie **unter Parameter** die Option **Parameter hinzufügen** aus, um Platzhalter für die Parametersetzung hinzuzufügen. **Geben Sie dann einen **Schlüssel** und einen optionalen Wert ein.**
1. Gehen Sie im Abschnitt **Container-Überschreibungen** wie folgt vor:
1. Geben Sie für **Command** die Befehle als entsprechende **JSON-String-Array-Entsprechung** in das Feld ein.
Dieser Parameter ist `Cmd` im Abschnitt [Erstellen eines Containers](https://docs.docker.com/engine/api/v1.38/#operation/ContainerCreate) der [Docker Remote-API](https://docs.docker.com/engine/api/v1.38/) und dem Parameter `COMMAND` von [https://docs.docker.com/engine/reference/commandline/run/](https://docs.docker.com/engine/reference/commandline/run/) zugeordnet. Weitere Informationen zum `CMD` Docker-Parameter finden Sie unter [https://docs.docker.com/engine/reference/builder/](https://docs.docker.com/engine/reference/builder/#cmd) \$1cmd.
**Anmerkung**
Dieser Parameter darf keine leere Zeichenfolge enthalten.
1. Geben Sie für **v CPUs** die Zahl von v einCPUs , die für den Container reserviert werden sollen. Dieser Parameter ordnet zu `CpuShares` im Bereich [Erstellen eines Containers](https://docs.docker.com/engine/api/v1.38/#operation/ContainerCreate) der [Docker Remote API](https://docs.docker.com/engine/api/v1.38/) und der Option `--cpu-shares` für die [https://docs.docker.com/engine/reference/commandline/run/](https://docs.docker.com/engine/reference/commandline/run/) zu. Jede vCPU entspricht 1.024 CPU-Anteilen. Sie müssen mindestens eine vCPU angeben.
1. Geben Sie für **Speicher** das Speicherlimit ein, das für den Container verfügbar ist. Wenn Ihr Container versucht, den hier angegebenen Arbeitsspeicher zu überschreiten, wird der Container angehalten. Dieser Parameter ordnet zu `Memory` im Bereich [Erstellen eines Containers](https://docs.docker.com/engine/api/v1.38/#operation/ContainerCreate) der [Docker Remote API](https://docs.docker.com/engine/api/v1.38/) und der Option `--memory` für die [https://docs.docker.com/engine/reference/commandline/run/](https://docs.docker.com/engine/reference/commandline/run/) zu. Sie müssen mindestens 4 MB Arbeitsspeicher für einen Auftrag festlegen.
**Anmerkung**
Um Ihre Ressourcennutzung zu maximieren, priorisieren Sie den Arbeitsspeicher für Jobs eines bestimmten Instance-Typs. Weitere Informationen finden Sie unter [Speicherverwaltung für Rechenressourcen](memory-management.md).
1. (Optional) Wählen Sie **unter Anzahl von** die Anzahl der aus GPUs, die für den Container reserviert werden GPUs soll.
1. (Optional) Wählen Sie für **Umgebungsvariablen** die Option **Umgebungsvariable hinzufügen** aus, um Umgebungsvariablen als Name-Wert-Paare hinzuzufügen. Diese Variablen werden an den Container übergeben.
1. Wählen Sie **Nächste Seite**.
1. Überprüfen Sie für **Job review** die Konfigurationsschritte. Wenn Sie Änderungen vornehmen müssen, wählen Sie **Edit** (Bearbeiten). Wenn Sie fertig sind, wählen Sie **Jobdefinition erstellen**.
# Servicejobs in AWS Batch
AWS Batch Serviceaufträge ermöglichen es Ihnen, Anfragen über AWS Batch Auftragswarteschlangen an AWS Dienste zu senden. AWS Batch Unterstützt derzeit SageMaker Schulungsjobs als Servicejobs. Im Gegensatz zu containerisierten Jobs, bei denen die zugrunde liegende Containerausführung AWS Batch verwaltet wird, ermöglichen Servicejobs die Bereitstellung von Funktionen AWS Batch zur Auftragsplanung und Warteschlangenbildung, während der AWS Zieldienst (z. B. SageMaker KI) die eigentliche Auftragsausführung übernimmt.
AWS Batch Für SageMaker Trainingsjobs ermöglicht es Datenwissenschaftlern, Trainingsjobs mit Prioritäten an konfigurierbare Warteschlangen zu senden. Dadurch wird sichergestellt, dass Workloads ohne Eingreifen ausgeführt werden, sobald Ressourcen verfügbar sind. Diese Funktion bewältigt häufig auftretende Herausforderungen wie die Ressourcenkoordination, die Vermeidung unbeabsichtigter Mehrausgaben, die Einhaltung von Budgetbeschränkungen, die Optimierung der Kosten mit Reserved Instances und die Eliminierung der Notwendigkeit manueller Koordination zwischen Teammitgliedern.
Serviceaufträge unterscheiden sich in mehreren wesentlichen Punkten von Aufträgen in Containern:
+ **Einreichung von Job**: Servicejobs müssen über die [SubmitServiceJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitServiceJob.html)API eingereicht werden. Serviceaufträge können nicht über die AWS Batch Konsole eingereicht werden.
+ **Auftragsausführung**: AWS Batch plant Serviceaufträge und stellt sie in eine Warteschlange, aber der AWS Zieldienst führt die tatsächliche Arbeitslast des Jobs aus.
+ **Ressourcen-Identifikatoren**: Dienstaufträge verwenden solche ARNs , die „service-job“ statt „job“ enthalten, um sie von containerisierten Aufträgen zu unterscheiden.
Informationen zu den ersten Schritten mit AWS Batch Serviceaufträgen für SageMaker Schulungen finden Sie unter. [Erste Schritte mit AWS Batch einer SageMaker KI](getting-started-sagemaker.md)
**Topics**
+ [Payloads für Servicejobs in AWS Batch](service-job-payload.md)
+ [Reichen Sie einen Servicejob ein in AWS Batch](service-job-submit.md)
+ [Zuordnen AWS Batch des Dienstauftragsstatus zum SageMaker AI-Status](service-job-status.md)
+ [Strategien zur Wiederholung von Serviceaufträgen in AWS Batch](service-job-retries.md)
+ [Überwachen Sie Serviceaufträge in einer Warteschlange AWS Batch](monitor-sagemaker-job-queue.md)
+ [Serviceaufträge beenden](terminate-service-jobs.md)
# Payloads für Servicejobs in AWS Batch
Wenn Sie Serviceaufträge mit senden [SubmitServiceJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitServiceJob.html), geben Sie zwei wichtige Parameter an, die den Job definieren:`serviceJobType`, und`serviceRequestPayload`.
+ Der `serviceJobType` gibt an, welcher AWS Dienst den Job ausführt. Für SageMaker Trainingsjobs ist dieser Wert`SAGEMAKER_TRAINING`.
+ Das `serviceRequestPayload` ist eine JSON-kodierte Zeichenfolge, die die vollständige Anfrage enthält, die normalerweise direkt an den Zieldienst gesendet würde. Für SageMaker Trainingsjobs enthält diese Payload dieselben Parameter, die Sie für die KI-API verwenden würden. SageMaker [CreateTrainingJob](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateTrainingJob.html)
Eine vollständige Liste aller verfügbaren Parameter und ihrer Beschreibungen finden Sie in der SageMaker [CreateTrainingJob](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateTrainingJob.html)AI-API-Referenz. Alle von unterstützten Parameter `CreateTrainingJob` können in Ihre Service-Job-Payload aufgenommen werden.
Beispiele für weitere Konfigurationen von Trainingsjobs finden Sie unter [APIsCLI und SDKs](https://docs.aws.amazon.com/sagemaker/latest/dg/api-and-sdk-reference-overview.html) im [SageMaker AI Developer Guide](https://docs.aws.amazon.com/sagemaker/latest/dg/gs.html).
Wir empfehlen, das pySDK für die Erstellung von Dienstaufträgen zu verwenden, da pySDK über Hilfsklassen und Hilfsprogramme verfügt. Ein Beispiel für die Verwendung von pySDK finden Sie unter [SageMaker KI-Beispiele](https://github.com/aws/amazon-sagemaker-examples) auf. GitHub
## Beispiel für eine Payload für Service-Jobs
Das folgende Beispiel zeigt eine einfache Payload für einen Servicejob für einen SageMaker Trainingsjob, der ein „Hello World“ -Trainingsskript ausführt:
Diese Payload würde beim Aufrufen als JSON-Zeichenfolge an den `serviceRequestPayload` Parameter übergeben. `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
}
}
```
# Reichen Sie einen Servicejob ein in AWS Batch
Um Serviceaufträge einzureichen AWS Batch, verwenden Sie die [SubmitServiceJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitServiceJob.html)API. Sie können Jobs mit dem SDK AWS CLI oder dem SDK einreichen.
Wenn Sie noch keine Ausführungsrolle haben, müssen Sie eine erstellen, bevor Sie Ihren Servicejob einreichen können. Informationen zum Erstellen der SageMaker AI-Ausführungsrolle finden Sie unter [So verwenden Sie SageMaker KI-Ausführungsrollen](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-roles.html) im *[SageMaker KI-Entwicklerhandbuch](https://docs.aws.amazon.com/sagemaker/latest/dg/whatis.html)*.
## Arbeitsablauf für die Einreichung von Serviceaufträgen
Wenn Sie einen Serviceauftrag einreichen, AWS Batch folgt dieser Arbeitsablauf:
1. AWS Batch empfängt Ihre `[SubmitServiceJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitServiceJob.html)` Anfrage und validiert die AWS Batch-spezifischen Parameter. Das `serviceRequestPayload` wird ohne Validierung übergeben.
1. Der Job wechselt in den `SUBMITTED` Status und wird in die angegebene Auftragswarteschlange gestellt
1. AWS Batch bewertet, ob in der Serviceumgebung Kapazität für `RUNNABLE` Jobs an der Spitze der Warteschlange verfügbar ist
1. Wenn Kapazität verfügbar ist, wird der Job verschoben `SCHEDULED` und der Job wurde an KI übergeben SageMaker
1. Wenn Kapazität erworben wurde und SageMaker KI die Serviceauftragsdaten heruntergeladen hat, beginnt die Initialisierung des Serviceauftrags und der Job wird zu `STARTING` geändert.
1. Wenn SageMaker KI mit der Ausführung des Jobs beginnt, wird sein Status auf `RUNNING` geändert.
1. Während SageMaker KI den Job ausführt, AWS Batch überwacht er seinen Fortschritt und ordnet den Dienststatus den AWS Batch Auftragsstatus zu. Einzelheiten darüber, wie die Status von Dienstaufträgen zugeordnet werden, finden Sie unter [Zuordnen AWS Batch des Dienstauftragsstatus zum SageMaker AI-Status](service-job-status.md)
1. Wenn der Serviceauftrag abgeschlossen ist, wird er verschoben `SUCCEEDED` und alle Ausgaben können heruntergeladen werden.
## Voraussetzungen
Stellen Sie vor dem Absenden eines Serviceauftrags sicher, dass Sie über Folgendes verfügen:
+ **Serviceumgebung** — Eine Serviceumgebung, die Kapazitätsgrenzen definiert. Weitere Informationen finden Sie unter [Erstellen Sie eine Serviceumgebung in AWS Batch](create-service-environments.md).
+ **SageMaker Job-Warteschlange** — Eine SageMaker Job-Warteschlange zur Job-Planung. Weitere Informationen finden Sie unter [Erstellen Sie eine Warteschlange für SageMaker Schulungsjobs in AWS Batch](create-sagemaker-job-queue.md).
+ **IAM-Berechtigungen — Berechtigungen** zum Erstellen und Verwalten von AWS Batch Jobwarteschlangen und Serviceumgebungen. Weitere Informationen finden Sie unter [AWS Batch IAM-Richtlinien, -Rollen und -Berechtigungen](IAM_policies.md).
## Reichen Sie einen Serviceauftrag ein
Die folgende Tabelle zeigt, wie Sie einen Servicejob entweder mit dem SageMaker Python-SDK oder der AWS CLI einreichen:
------
#### [ Submit using the SageMaker Python SDK ]
Das [SageMaker Python-SDK](https://sagemaker.readthedocs.io/en/stable/v3-examples/training-examples/aws_batch/sm-training-queues_getting_started_with_model_trainer.html) bietet integrierte Unterstützung für das Senden von Jobs an AWS Batch. Die folgenden Beispiele zeigen, wie Sie einen Modelltrainer erstellen, eine Trainingswarteschlange erstellen und einen Job einreichen. Ein vollständiges Beispiel finden Sie im [vollständigen Beispielnotizbuch](https://github.com/aws/sagemaker-python-sdk/blob/master/v3-examples/training-examples/aws_batch/sm-training-queues_getting_started_with_model_trainer.ipynb) unter GitHub.
Erstellen Sie eine`ModelTrainer`, die die Konfiguration des Trainingsjobs definiert.
```
from sagemaker.train.model_trainer import ModelTrainer
from sagemaker.train.configs import SourceCode, Compute, StoppingCondition
source_code = SourceCode(command="echo 'Hello World'")
model_trainer = ModelTrainer(
training_image="123456789012.dkr.ecr.us-east-1.amazonaws.com/pytorch-training:2.5-gpu-py311",
source_code=source_code,
base_job_name="my-training-job",
compute=Compute(instance_type="ml.g5.xlarge", instance_count=1),
stopping_condition=StoppingCondition(max_runtime_in_seconds=300),
)
```
Erstellen Sie ein `TrainingQueue` Objekt, das namentlich auf Ihre Job-Warteschlange verweist.
```
from sagemaker.train.aws_batch.training_queue import TrainingQueue
queue = TrainingQueue("my-sagemaker-job-queue")
```
Reichen Sie einen Job ein, indem Sie anrufen`queue.submit`.
```
job = queue.submit(
training_job=model_trainer,
inputs=None,
)
```
------
#### [ Submit using the AWS CLI ]
Im Folgenden wird gezeigt, wie Sie einen Servicejob mit der AWS CLI einreichen:
```
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"
```
Weitere Informationen zu den `serviceRequestPayload` Parametern finden Sie unter[Payloads für Servicejobs in AWS Batch](service-job-payload.md).
------
# Zuordnen AWS Batch des Dienstauftragsstatus zum SageMaker AI-Status
Wenn Sie Jobs mithilfe von, an eine SageMaker Job-Warteschlange weiterleiten [SubmitServiceJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitServiceJob.html), wird der Job-Lebenszyklus AWS Batch verwaltet und AWS Batch [Jobstatus den](job_states.md) entsprechenden SageMaker Trainingsstatus zugeordnet. Serviceaufträge, wie z. B. SageMaker Schulungsaufträge, folgen einem anderen Lebenszyklus als herkömmliche Container-Jobs. Servicejobs und Container-Jobs teilen sich zwar die meisten Status, führen jedoch den `SCHEDULED` Status ein und zeigen ein unterschiedliches Wiederholungsverhalten, insbesondere bei der Behandlung von Fehlern mit unzureichender Kapazität durch den Zieldienst.
Die folgende Tabelle zeigt den AWS Batch Auftragsstatus und den entsprechenden SageMaker SecondaryStatus Status/:
| Status der Batch | SageMaker Primärer Status der KI | SageMaker Sekundärer Status der KI | Description |
| --- | --- | --- | --- |
| SUBMITTED | – | – | Der Job wurde in die Warteschlange gestellt und wartet auf die Auswertung durch den Scheduler. |
| RUNNABLE | – | – | Der Job befindet sich in der Warteschlange und ist bereit für die Planung. Jobs in diesem Status werden gestartet, sobald genügend Ressourcen in der Serviceumgebung verfügbar sind. Jobs können auf unbestimmte Zeit in diesem Zustand verbleiben, wenn nicht genügend Ressourcen verfügbar sind. |
| SCHEDULED | InProgress | Pending | Der Serviceauftrag wurde erfolgreich an SageMaker AI übermittelt |
| STARTING | InProgress | Downloading | SageMaker Trainingsjob zum Herunterladen von Daten und Bildern. Die Kapazität für den Ausbildungsberuf wurde erworben und die Initialisierung des Jobs beginnt. |
| RUNNING | InProgress | Training | SageMaker Algorithmus zur Ausführung des Trainingsauftrags |
| RUNNING | InProgress | Uploading | SageMaker Trainingsjob zum Hochladen von Ausgabeartefakten nach Abschluss des Trainings |
| SUCCEEDED | Completed | Completed | SageMaker Die Schulungsaufgabe wurde erfolgreich abgeschlossen. Der Upload der Ausgabeartefakte wurde abgeschlossen. |
| FAILED | Failed | Failed | SageMaker Bei der Trainingsaufgabe ist ein Fehler aufgetreten, der nicht behebbar ist. |
| FAILED | Stopped | Stopped | SageMaker Der Trainingsjob wurde manuell beendet mit. StopTrainingJob |
# Strategien zur Wiederholung von Serviceaufträgen in AWS Batch
Strategien zur Wiederholung von Serviceaufträgen ermöglichen es AWS Batch , fehlgeschlagene Serviceaufträge unter bestimmten Bedingungen automatisch zu wiederholen.
Serviceaufträge können aus verschiedenen Gründen mehrere Versuche erfordern:
+ **Temporäre Serviceprobleme**: Interne Dienstfehler, Drosselung oder vorübergehende Ausfälle können dazu führen, dass Aufträge bei der Übermittlung oder Ausführung fehlschlagen.
+ **Fehler bei der Trainingsinitialisierung**: Probleme beim Starten des Jobs, wie z. B. Probleme beim Abrufen von Bildern oder Initialisierungsfehler, können bei einem erneuten Versuch behoben werden.
Durch die Konfiguration geeigneter Wiederholungsstrategien können Sie die Erfolgsquoten von Aufträgen verbessern und den Bedarf an manuellem Eingreifen reduzieren, insbesondere bei lang andauernden Schulungsaufgaben.
**Anmerkung**
Serviceaufträge wiederholen automatisch bestimmte Arten von Fehlern, wie z. B. Fehler bei unzureichender Kapazität, ohne dass Ihre konfigurierten Wiederholungsversuche unnötig werden. Ihre Wiederholungsstrategie behandelt in erster Linie andere Arten von Fehlern, wie z. B. Algorithmusfehler oder Serviceprobleme.
## Konfiguration von Wiederholungsstrategien
Strategien zur Wiederholung von Serviceaufträgen werden mithilfe von konfiguriert [ServiceJobRetryStrategy](https://docs.aws.amazon.com/batch/latest/APIReference/API_ServiceJobRetryStrategy.html), das sowohl einfache Wiederholungszahlen als auch bedingte Wiederholungslogik unterstützt.
### Wiederholungs-Konfiguration
Die einfachste Wiederholungsstrategie gibt die Anzahl der Wiederholungsversuche an, die unternommen werden sollen, wenn ein Serviceauftrag fehlschlägt:
```
{
"retryStrategy": {
"attempts": 3
}
}
```
Mit dieser Konfiguration kann der Serviceauftrag bis zu dreimal wiederholt werden, falls er fehlschlägt.
**Wichtig**
Der `attempts` Wert gibt an, wie oft der Auftrag insgesamt in den `RUNNABLE` Status versetzt werden kann, einschließlich des ersten Versuchs. Ein Wert von 3 bedeutet, dass der Job zunächst einmal versucht und dann, falls er fehlschlägt, bis zu zwei weitere Male wiederholt wird.
### Versuchen Sie die Konfiguration erneut mit evaluateOnExit
Sie können den `evaluateOnExit` Parameter verwenden, um Bedingungen anzugeben, unter denen Jobs wiederholt werden sollen oder unter denen sie fehlschlagen dürfen. Dies ist nützlich, wenn verschiedene Arten von Fehlern unterschiedlich behandelt werden müssen.
Das `evaluateOnExit` Array kann bis zu 5 Wiederholungsstrategien enthalten, von denen jede eine Aktion (`RETRY`oder`EXIT`) und Bedingungen spezifiziert, die auf Statusgründen basieren:
```
{
"retryStrategy": {
"attempts": 5,
"evaluateOnExit": [
{
"action": "RETRY",
"onStatusReason": "Received status from SageMaker: InternalServerError*"
},
{
"action": "EXIT",
"onStatusReason": "Received status from SageMaker: ValidationException*"
},
{
"action": "EXIT",
"onStatusReason": "*"
}
]
}
}
```
Diese Konfiguration:
+ Wiederholt Aufträge, die aufgrund von internen SageMaker AI-Serverfehlern fehlschlagen
+ Schlägt Aufträge, bei denen Validierungsausnahmen auftreten, sofort fehl (Client-Fehler, die nicht durch einen erneuten Versuch behoben werden können)
+ Beinhaltet eine Catch-All-Regel zum Beenden bei allen anderen Fehlertypen
#### Status, Grund, Musterabgleich
Der `onStatusReason` Parameter unterstützt den Musterabgleich mit bis zu 512 Zeichen. Muster können Platzhalter (\$1) verwenden und mit den von der SageMaker KI zurückgegebenen Statusgründen übereinstimmen.
Bei Serviceaufträgen wird Statusmeldungen von SageMaker KI das Präfix „Status erhalten von SageMaker:“ vorangestellt, um sie von AWS Batch-generierten Nachrichten zu unterscheiden. Zu den gängigen Mustern gehören:
+ `Received status from SageMaker: InternalServerError*`- Ordnen Sie interne Servicefehler zu
+ `Received status from SageMaker: ValidationException*`- Fehler bei der Client-Validierung abgleichen
+ `Received status from SageMaker: ResourceLimitExceeded*`- Fehler beim Ressourcenlimit abgleichen
+ `*CapacityError*`- Passen Sie kapazitätsbedingte Ausfälle an
**Tipp**
Verwenden Sie einen spezifischen Musterabgleich, um verschiedene Fehlertypen angemessen zu behandeln. Versuchen Sie es beispielsweise erneut mit internen Serverfehlern, schlagen Sie jedoch sofort bei Validierungsfehlern fehl, die auf Probleme mit den Auftragsparametern hinweisen.
# Überwachen Sie Serviceaufträge in einer Warteschlange AWS Batch
Sie können den Status der Jobs in Ihrer Warteschlange für SageMaker Schulungsaufträge mithilfe von`list-service-jobs`, und überwachen`get-job-queue-snapshot`.
Laufende Jobs in deiner Warteschlange anzeigen:
```
aws batch list-service-jobs \
--job-queue my-sm-training-fifo-jq \
--job-status RUNNING
```
Jobs anzeigen, die in der Warteschlange warten:
```
aws batch list-service-jobs \
--job-queue my-sm-training-fifo-jq \
--job-status RUNNABLE
```
Jobs anzeigen, die eingereicht wurden, SageMaker aber noch nicht laufen:
```
aws batch list-service-jobs \
--job-queue my-sm-training-fifo-jq \
--job-status SCHEDULED
```
Verschaffen Sie sich einen Überblick über die Jobs, die sich ganz oben in Ihrer Warteschlange befinden:
```
aws batch get-job-queue-snapshot --job-queue my-sm-training-fifo-jq
```
Dieser Befehl zeigt die Reihenfolge der anstehenden Serviceaufträge in Ihrer Warteschlange an.
## Erhalten Sie detaillierte Informationen zu Serviceaufträgen
Verwenden Sie diesen [https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeServiceJob.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeServiceJob.html)Vorgang, um umfassende Informationen zu einem bestimmten Serviceauftrag abzurufen, einschließlich seines aktuellen Status, der Dienstressourcen-IDs und detaillierter Informationen zu Versuchen.
Detaillierte Informationen zu einem bestimmten Job anzeigen:
```
aws batch describe-service-job \
--job-id a4d6c728-8ee8-4c65-8e2a-9a5e8f4b7c3d
```
Dieser Befehl gibt umfassende Informationen über den Job zurück, darunter:
+ Job-ARN und aktueller Status
+ Identifikatoren für Serviceressourcen (z. B. ARN für SageMaker Schulungsjobs)
+ Priorität einplanen und Konfiguration erneut versuchen
+ Payload der Serviceanfrage, die die ursprünglichen Serviceparameter enthält
+ Detaillierte Informationen zu den Versuchen mit Start- und Stoppzeiten
+ Statusmeldungen vom Zieldienst
## Überwachen Sie SageMaker Trainingsjobs
Wenn Sie SageMaker Trainingsjobs bis überwachen AWS Batch, können Sie sowohl auf die AWS Batch Jobinformationen als auch auf die zugrunde liegenden SageMaker Trainingsjobdetails zugreifen.
Die Dienstressourcen-ID in den Jobdetails enthält den ARN für den SageMaker Trainingsjob:
```
{
"latestAttempt": {
"serviceResourceId": {
"name": "TrainingJobArn",
"value": "arn:aws:sagemaker:us-east-1:123456789012:training-job/my-training-job"
}
}
}
```
Sie können diesen ARN verwenden, um weitere Informationen direkt zu erhalten von SageMaker:
```
aws sagemaker describe-training-job \
--training-job-name my-training-job
```
Überwachen Sie den Auftragsfortschritt, indem Sie sowohl AWS Batch den Status als auch den Status des SageMaker Schulungsauftrags überprüfen. Der AWS Batch Jobstatus zeigt den gesamten Joblebenszyklus, während der Status des SageMaker Schulungsauftrags dienstspezifische Details zum Trainingsprozess enthält.
# Serviceaufträge beenden
Verwenden Sie den [https://docs.aws.amazon.com/batch/latest/APIReference/API_TerminateServiceJob.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_TerminateServiceJob.html)Vorgang, um einen laufenden Serviceauftrag zu beenden.
Beenden Sie einen bestimmten Dienstauftrag:
```
aws batch terminate-service-job \
--job-id a4d6c728-8ee8-4c65-8e2a-9a5e8f4b7c3d \
--reason "Job terminated by user request"
```
Wenn Sie einen Dienstauftrag beenden, AWS Batch stoppt er den Job und benachrichtigt den Zieldienst. Bei SageMaker Schulungsaufträgen wird dadurch auch der Schulungsjob in SageMaker KI beendet.
# Status der Job
Wenn Sie einen Job an AWS Batch eine Auftragswarteschlange weiterleiten, wechselt der Job in den `SUBMITTED` Status. Danach durchläuft er die folgenden Zustände, bis er erfolgreich ist (Abschluss mit Code `0`) oder fehlschlägt (Abschluss mit einem Code ungleich null). AWS Batch -Aufträge können die folgenden Status haben:
`SUBMITTED`
Ein Job, der an die Warteschlange gesendet wurde und noch nicht vom Scheduler bewertet wurde. Der Scheduler überprüft den Auftrag, um zu bestimmen, ob offene Abhängigkeiten von der erfolgreichen Ausführung anderer Aufträge vorliegen. Wenn Abhängigkeiten vorhanden sind, wird der Auftrag in den Status `PENDING` verschoben. Sind keine Abhängigkeiten vorhanden, wechselt der Auftrag in den Status `RUNNABLE`.
`PENDING`
Ein Job, der sich in der Warteschlange befindet und aufgrund einer Abhängigkeit von einem anderen Job oder einer anderen Ressource noch nicht ausgeführt werden kann. Nachdem die Abhängigkeiten erfüllt sind, wird der Auftrag in den Status `RUNNABLE` verschoben.
Eltern eines Array-Jobs werden darüber informiert, `PENDING` wenn ein untergeordneter Job aktualisiert wird, `RUNNABLE` und behalten ihren `PENDING` Status, solange untergeordnete Jobs ausgeführt werden. Um diese Jobs anzuzeigen, filtern Sie nach `PENDING` Status, bis alle untergeordneten Jobs einen Endstatus erreicht haben.
`RUNNABLE`
Ein Auftrag, der sich in der Warteschlange befindet, keine ausstehenden Abhängigkeiten hat und daher für einen Host geplant werden kann. Jobs in diesem Status werden gestartet, sobald in einer der Rechenumgebungen, die der Warteschlange des Jobs zugeordnet sind, genügend Ressourcen verfügbar sind. Aufträge können jedoch für einen unbegrenzten Zeitraum in diesem Status verbleiben, wenn keine ausreichenden Ressourcen zur Verfügung stehen.
Wenn Ihre Jobs nicht weitergeführt werden`STARTING`, finden Sie [Jobs, die in einem `RUNNABLE` Status feststecken](job_stuck_in_runnable.md) im Abschnitt zur Fehlerbehebung weitere Informationen.
`STARTING`
Diese Aufträge wurden für einen Host geplant und die relevanten Vorgänge zur Container-Initiierung werden noch ausgeführt. Nachdem das Container-Image durch Pull-Übertragung abgerufen und der Container gestartet wurde, geht der Auftrag in den Status `RUNNING` über.
Die Dauer des Abrufs von Images, die Dauer der Fertigstellung von Amazon EKS InitContainer und die Dauer der Auflösung von Amazon ECS ContainerDependency erfolgen im Status STARTING. Die Zeit, die zum Abrufen eines Images für Ihren Job benötigt wird, entspricht der Zeit, in der sich Ihr Job im Status STARTING befindet.
Wenn es beispielsweise drei Minuten dauert, das Bild für Ihren Job abzurufen, befindet sich Ihr Job drei Minuten lang im Status START. Wenn die Ausführung von InitContainers insgesamt zehn Minuten dauert, wird Ihr Amazon EKS-Job zehn Minuten lang in STARTING sein. Wenn Sie Amazon ECS-ContainerDependencies-Sets in Ihrem Amazon ECS-Job haben, befindet sich der Job in STARTING, bis alle Container-Abhängigkeiten (ihre Laufzeit) aufgelöst sind. STARTING ist in den Timeouts nicht enthalten; die Dauer beginnt bei RUNNING. Weitere Informationen finden Sie unter [Jobstatus](https://docs.aws.amazon.com/batch/latest/userguide/job_states.html).
`RUNNING`
Der Job wird als Container-Job auf einer Amazon ECS-Container-Instance in einer Rechenumgebung ausgeführt. Wenn der Container des Auftrags beendet wird, bestimmt der Prozessbeendigungscode, ob der Auftrag erfolgreich war oder nicht. Der Beendigungscode `0` bedeutet eine erfolgreiche Ausführung und ein Beendigungscode ungleich Null bedeutet, dass ein Fehler aufgetreten ist. Wenn für den mit einem fehlgeschlagenen Versuch verbundene Aufträge verbleibende Versuche in der optionalen Wiederholungsstrategiekonfiguration vorhanden sind, wird der Auftrag erneut in den Status `RUNNABLE` verschoben. Weitere Informationen finden Sie unter [Automatisierte Auftragswiederholungen](job_retries.md).
Protokolle für `RUNNING` Jobs sind unter CloudWatch Logs verfügbar. Die Protokollgruppe ist`/aws/batch/job`, und das Format des Protokollstream-Namens lautet wie folgt:`first200CharsOfJobDefinitionName/default/ecs_task_id`. Dieses Format könnte sich in future ändern.
Nachdem ein Job den `RUNNING` Status erreicht hat, können Sie seinen Log-Stream-Namen mithilfe der [DescribeJobs](https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeJobs.html)API-Operation programmgesteuert abrufen. Weitere Informationen finden Sie unter [An CloudWatch Logs gesendete Protokolldaten anzeigen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#ViewingLogData) im *Amazon CloudWatch Logs-Benutzerhandbuch*. Standardmäßig laufen diese Protokolle nie ab. Sie können den Aufbewahrungszeitraum jedoch ändern. Weitere Informationen finden Sie unter [Aufbewahrung von Protokolldaten in CloudWatch Protokollen ändern](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SettingLogRetention.html) im *Amazon CloudWatch Logs-Benutzerhandbuch*.
`SUCCEEDED`
Der Auftrag wurde mit dem Beendigungscode `0` erfolgreich abgeschlossen. Der Auftragsstatus für `SUCCEEDED` Jobs wird AWS Batch für mindestens 7 Tage beibehalten.
Protokolle für `SUCCEEDED` Jobs sind unter CloudWatch Logs verfügbar. Die Protokollgruppe ist`/aws/batch/job`, und das Format des Protokollstream-Namens lautet wie folgt:`first200CharsOfJobDefinitionName/default/ecs_task_id`. Dieses Format kann sich in future ändern.
Nachdem ein Job den `RUNNING` Status erreicht hat, können Sie seinen Log-Stream-Namen mithilfe der [DescribeJobs](https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeJobs.html)API-Operation programmgesteuert abrufen. Weitere Informationen finden Sie unter [An CloudWatch Logs gesendete Protokolldaten anzeigen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#ViewingLogData) im *Amazon CloudWatch Logs-Benutzerhandbuch*. Standardmäßig laufen diese Protokolle nie ab. Sie können den Aufbewahrungszeitraum jedoch ändern. Weitere Informationen finden Sie unter [Aufbewahrung von Protokolldaten in CloudWatch Protokollen ändern](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SettingLogRetention.html) im *Amazon CloudWatch Logs-Benutzerhandbuch*.
`FAILED`
Der Auftrag wurde bei allen verfügbaren Versuchen nicht erfolgreich beendet. Der Auftragsstatus für `FAILED` Jobs wird AWS Batch für mindestens 7 Tage beibehalten.
Protokolle für `FAILED` Jobs sind unter CloudWatch Logs verfügbar. Die Protokollgruppe ist`/aws/batch/job`, und das Format des Protokollstream-Namens lautet wie folgt:`first200CharsOfJobDefinitionName/default/ecs_task_id`. Dieses Format kann sich in future ändern.
Nachdem ein Job den `RUNNING` Status erreicht hat, können Sie seinen Protokollstream mithilfe der [DescribeJobs](https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeJobs.html)API-Operation programmgesteuert abrufen. Weitere Informationen finden Sie unter [An CloudWatch Logs gesendete Protokolldaten anzeigen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#ViewingLogData) im *Amazon CloudWatch Logs-Benutzerhandbuch*. Standardmäßig laufen diese Protokolle nie ab. Sie können den Aufbewahrungszeitraum jedoch ändern. Weitere Informationen finden Sie unter [Aufbewahrung von Protokolldaten in CloudWatch Protokollen ändern](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SettingLogRetention.html) im *Amazon CloudWatch Logs-Benutzerhandbuch*.
# AWS Batch Variablen der Arbeitsumgebung
AWS Batch legt spezifische Umgebungsvariablen in Container-Jobs fest. Diese Umgebungsvariablen ermöglichen eine Introspektion der Container innerhalb von Jobs. Sie können die Werte dieser Variablen in der Logik Ihrer Anwendungen verwenden. Alle Variablen, die AWS Batch gesetzt werden, beginnen mit dem `AWS_BATCH_` Präfix. Dies ist ein geschütztes Umgebungsvariablenpräfix. Sie können dieses Präfix nicht für Ihre eigenen Variablen in Jobdefinitionen oder Überschreibungen verwenden.
Die folgenden Umgebungsvariablen stehen in Auftragscontainern zur Verfügung:
`AWS_BATCH_CE_NAME`
Diese Variable ist auf den Namen der Rechenumgebung gesetzt, in der Ihr Job platziert ist.
`AWS_BATCH_JOB_ARRAY_INDEX`
Diese Variable wird nur in untergeordneten Array-Aufträgen festgelegt. Der Array-Auftrags-Index beginnt bei 0 und alle untergeordneten Aufträge erhalten eine eindeutige Indexnummer. Beispielsweise weist ein Array-Auftrag mit 10 untergeordneten Aufträge die Indexwerte 0–9 auf. Sie können diesen Indexwert dazu verwenden, zu steuern, wie Ihre untergeordneten Array-Auftragselemente differenziert werden. Weitere Informationen finden Sie unter [Verwenden Sie den Array-Jobindex, um die Jobdifferenzierung zu steuern](array_index_example.md).
`AWS_BATCH_JOB_ARRAY_SIZE`
Diese Variable ist auf die Größe des übergeordneten Array-Jobs gesetzt. Die Größe des übergeordneten Array-Jobs wird in dieser Variablen an den untergeordneten Array-Job übergeben.
`AWS_BATCH_JOB_ATTEMPT`
Für diese Variable wird die Auftragsversuchsnummer festgelegt. Der erste Versuch erhält die Nummer 1. Weitere Informationen finden Sie unter [Automatisierte Auftragswiederholungen](job_retries.md).
`AWS_BATCH_JOB_ID`
Diese Variable ist auf die AWS Batch Job-ID gesetzt.
`AWS_BATCH_JOB_KUBERNETES_NODE_UID`
Diese Variable wird als Kubernetes UID des Knotenobjekts festgelegt, das sich im Kubernetes-Cluster befindet, auf dem der Pod ausgeführt wird. Diese Variable ist nur für Jobs festgelegt, die auf Amazon EKS-Ressourcen ausgeführt werden. Weitere Informationen finden Sie [UIDs](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#uids)in der *KubernetesDokumentation*.
`AWS_BATCH_JOB_MAIN_NODE_INDEX`
Diese Variable wird nur in parallelen Aufträgen mit mehreren Knoten festgelegt. Diese Variable ist auf die Indexnummer des Hauptknotens des Auftrags festgelegt. Ihr Anwendungscode kann den mit dem `AWS_BATCH_JOB_MAIN_NODE_INDEX` `AWS_BATCH_JOB_NODE_INDEX` auf einem einzelnen Knoten vergleichen, um festzustellen, ob es sich um den Hauptknoten handelt.
`AWS_BATCH_JOB_MAIN_NODE_PRIVATE_IPV4_ADDRESS`
Diese Variable wird nur in untergeordneten Knoten für parallel Jobs mit mehreren Knoten gesetzt. Diese Variable ist auf dem Hauptknoten nicht vorhanden, sondern auf die private IPv4 Adresse des Hauptknotens des Jobs gesetzt. Der Anwendungscode Ihres untergeordneten Knotens kann diese Adresse zur Kommunikation mit dem Hauptknoten verwenden.
`AWS_BATCH_JOB_NODE_INDEX`
Diese Variable wird nur in parallelen Aufträgen mit mehreren Knoten festgelegt. Diese Variable ist auf die Indexnummer des Knotens festgelegt. Der Knotenindex beginnt bei 0 und jeder Knoten erhält eine eindeutige Indexnummer. Beispielsweise weist ein paralleler Auftrag mit mehreren Knoten und 10 untergeordneten Aufträgen die Indexwerte 0–9 auf.
`AWS_BATCH_JOB_NUM_NODES`
Diese Variable wird nur in parallelen Aufträgen mit mehreren Knoten festgelegt. Diese Variable ist auf die Anzahl der Knoten gesetzt, die Sie für Ihren Paralleljob mit mehreren Knoten angefordert haben.
`AWS_BATCH_JQ_NAME`
Für diese Variable ist der Name der Auftragswarteschlange festgelegt, an die der Auftrag übermittelt wurde.
# Automatisierte Auftragswiederholungen
Sie können auf Ihre Aufträge und Auftragsdefinitionen eine Wiederholungsstrategie anwenden, mit der fehlgeschlagenen Aufträge automatisch wiederholt werden. Zu den möglichen Ausfallszenarien gehören die folgenden:
+ Ein Beendigungscode ungleich Null von einem Container-Auftrag
+ Ausfall oder Kündigung der Amazon EC2 EC2-Instance
+ Interner AWS Servicefehler oder Ausfall
Wenn ein Job an eine Auftragswarteschlange weitergeleitet und in den `RUNNING` Status versetzt wird, der als Versuch gewertet wird. Standardmäßig erhält jeder Auftrag einen Versuch, um entweder in den Auftragsstatus `SUCCEEDED` oder `FAILED` verschoben zu werden. Sowohl die Arbeitsabläufe für die Auftragsdefinition als auch für die Auftragsübermittlung können jedoch verwendet werden, um eine Wiederholungsstrategie mit einem bis zehn Versuchen festzulegen. Wenn [evaluateOnExit](job_definition_parameters.md#retryStrategy-evaluateOnExit)angegeben, kann sie bis zu 5 Wiederholungsstrategien enthalten. Wenn [evaluateOnExit](https://docs.aws.amazon.com/batch/latest/APIReference/API_EvaluateOnExit.html)angegeben, aber keine der Wiederholungsstrategien übereinstimmt, wird der Job erneut versucht. Fügen Sie für Jobs, die nicht mit Exit übereinstimmen, einen letzten Eintrag hinzu, der aus einem beliebigen Grund beendet wird. Dieses `evaluateOnExit` Objekt hat beispielsweise zwei Einträge mit der Aktion von `RETRY` und einen letzten Eintrag mit der Aktion von`EXIT`.
```
"evaluateOnExit": [
{
"action": "RETRY",
"onReason": "AGENT"
},
{
"action": "RETRY",
"onStatusReason": "Task failed to start"
},
{
"action": "EXIT",
"onReason": "*"
}
]
```
Zur Laufzeit wird die Umgebungsvariable `AWS_BATCH_JOB_ATTEMPT` auf die Nummer des entsprechenden Auftragsversuchs des Containers festgelegt. Der erste Versuch ist nummeriert`1`, und die nachfolgenden Versuche sind in aufsteigender Reihenfolge (z. B. 2, 3, 4).
Nehmen wir beispielsweise an, dass ein Jobversuch aus irgendeinem Grund fehlschlägt und die in der Konfiguration für die Wiederholung angegebene Anzahl von Versuchen größer ist als die `AWS_BATCH_JOB_ATTEMPT` Anzahl. Dann wird der Job wieder in den `RUNNABLE` Status versetzt. Weitere Informationen finden Sie unter [Status der Job](job_states.md).
**Anmerkung**
Aufträge, die storniert oder beendet wurden, werden nicht erneut versucht. Außerdem werden Jobs, die aufgrund einer ungültigen Jobdefinition fehlschlagen, nicht erneut versucht.
Weitere Informationen finden Sie unter [Wiederholungsstrategie](job_definition_parameters.md#retryStrategy)[Erstellen Sie eine Auftragsdefinition mit einem Knoten](create-job-definition.md), [Tutorial: Einen Job einreichen](submit_job.md) und [Fehlercodes für gestoppte Aufgaben](https://docs.aws.amazon.com/AmazonECS/latest/userguide/stopped-task-error-codes.html).
# Abhängigkeiten von Job
Wenn Sie einen AWS Batch Job einreichen, können Sie den Job angeben IDs , von dem der Job abhängt. Wenn Sie dies tun, stellt der AWS Batch Scheduler sicher, dass Ihr Job erst ausgeführt wird, nachdem die angegebenen Abhängigkeiten erfolgreich abgeschlossen wurden. Nachdem diese erfolgreich waren, wechselt der abhängige Auftrag von `PENDING` zu `RUNNABLE` und dann zu `STARTING` und `RUNNING`. Wenn eine der Auftragsabhängigkeiten fehlschlägt, wechselt der abhängige Auftrag automatisch von `PENDING` zu `FAILED`.
Beispielsweise kann Auftrag A eine Abhängigkeit von bis zu 20 anderen Aufträge haben. Diese müssen erfolgreich sein, bevor er ausgeführt werden kann. Sie können dann weitere von Auftrag A und bis zu 19 weiteren Aufträgen abhängige Aufträge senden.
Bei Array-Aufträgen können Sie eine `SEQUENTIAL`-Typabhängigkeit angeben, ohne eine Auftrags-ID anzugeben, sodass jeder untergeordnete Array-Auftrag sequentiell abgeschlossen wird (beginnend mit Index 0). Sie können auch eine `N_TO_N`-Typabhängigkeit mit einer Auftrags-ID festlegen. So muss jeder untergeordnete Index dieses Auftrags warten, bis der entsprechende untergeordnete Index jeder Abhängigkeit abgeschlossen ist. Weitere Informationen finden Sie unter [Ordnen Sie Jobs an](array_jobs.md).
Informationen zum Einreichen eines AWS Batch Jobs mit Abhängigkeiten finden Sie unter[Tutorial: Einen Job einreichen](submit_job.md).
[Ressourcenbewusste Planung](resource-aware-scheduling.md)ermöglicht es Ihnen, Jobs auf der Grundlage verbrauchbarer Ressourcen zu planen, die für die Ausführung Ihrer Jobs benötigt werden. Sie geben die verbrauchbaren Ressourcen an, die für die Ausführung eines Jobs benötigt werden, und Batch berücksichtigt diese Ressourcenabhängigkeiten bei der Planung eines Jobs. Sie können die Unterauslastung der Rechenressourcen verringern, indem Sie nur die Jobs zuweisen, für die alle erforderlichen Ressourcen verfügbar sind. Die ressourcenorientierte Planung ist sowohl für FIFO- als auch für Fair-Share-Scheduling-Richtlinien verfügbar und kann mit allen von Batch unterstützten Computerplattformen verwendet werden, einschließlich EKS, ECS und Fargate. Es kann mit Array-Jobs, Multi-Node-Parallel-Jobs (MNP) und mit regulären Batch-Jobs verwendet werden.
# Timeouts bei der Job
Sie können ein Timeout für Ihre Aufträge so konfigurieren, dass AWS Batch den Auftrag beendet, wenn die Ausführung länger als den angegebenen Wert dauert. Angenommen, Sie haben einen Auftrag, von dem Sie wissen, dass er nur 15 Minuten in Anspruch nehmen sollte. Manchmal bleibt Ihre Anwendung in einer Schleife hängen und wird endlos ausgeführt. Sie können also eine Zeitbeschränkung von 30 Minuten festlegen, bis der hängen gebliebene Auftrag beendet wird.
**Wichtig**
Standardmäßig AWS Batch gibt es kein Job-Timeout. Wenn Sie kein Job-Timeout definieren, wird der Job ausgeführt, bis der Container beendet wird.
Sie geben entweder in Ihrer Auftragsdefinition oder bei der Übermittlung des Auftrags einen `attemptDurationSeconds`-Parameter an, der einen Mindestwert von 60 Sekunden haben muss. Wenn diese Anzahl von Sekunden nach dem `startedAt` Zeitstempel des Auftragsversuchs vergangen ist, wird der Job AWS Batch beendet. Auf der Datenverarbeitungsressource empfängt Ihr Auftrags-Container ein `SIGTERM`-Signal, um Ihrer Anwendung die Möglichkeit zu geben, ordnungsgemäß zu schließen. Wenn sich der Container nach 30 Sekunden noch immer in der Ausführung befindet, wird ein `SIGKILL`-Signal gesendet, um den Container zwangsweise herunterzufahren.
Timeout-Beendigungen werden auf einer Best-Effort-Basis abgewickelt. Sie sollten nicht erwarten, dass Ihr Timeout genau dann beendet wird, wenn das Zeitlimit für den Jobversuch überschritten wird (es kann einige Sekunden länger dauern). Wenn Ihre Anwendung eine genaue Timeout-Ausführung benötigt, sollten Sie diese Logik innerhalb der Anwendung implementieren. Wenn Sie eine große Anzahl von Aufträgen haben, bei denen gleichzeitig Zeitüberschreitungen auftreten, werden die Timeout-Beendigungen in einer FIFO(First-in-First-out)-Warteschlange abgearbeitet, wobei Aufträge stapelweise beendet werden.
**Anmerkung**
Es gibt keinen maximalen Timeout-Wert für einen AWS Batch Job.
Wenn ein Job wegen Überschreitung der Timeoutdauer beendet wird, wird er nicht erneut versucht. Wenn ein Auftragsversuch fehlschlägt, kann er wiederholt werden, wenn Wiederholversuche aktiviert sind, und der Zeitüberschreitungs-Countdown wird für den neuen Versuch erneut gestartet.
**Wichtig**
Jobs, die auf Fargate-Ressourcen ausgeführt werden, können nicht damit rechnen, länger als 14 Tage zu laufen. Wenn die Timeout-Dauer 14 Tage überschreitet, sind die Fargate-Ressourcen möglicherweise nicht mehr verfügbar und der Job wird beendet.
Bei Array-Aufgaben haben untergeordnete Aufträge dieselbe Timeout-Konfiguration wie der übergeordnete Auftrag.
Hinweise zum Einreichen eines AWS Batch Jobs mit einer Timeout-Konfiguration finden Sie unter. [Tutorial: Einen Job einreichen](submit_job.md)
# Stellenangebote bei Amazon EKS
Ein Job ist die kleinste Arbeitseinheit in AWS Batch. Ein AWS Batch Job auf Amazon EKS hat eine one-to-one Zuordnung zu einem Kubernetes Pod. Eine AWS Batch Jobdefinition ist eine Vorlage für einen AWS Batch Job. Wenn Sie einen AWS Batch Job einreichen, verweisen Sie auf eine Jobdefinition, geben eine Job-Warteschlange als Ziel an und geben einen Namen für einen Job an. In der Auftragsdefinition eines AWS Batch Jobs auf Amazon EKS definiert der Parameter [eksProperties](https://docs.aws.amazon.com/batch/latest/APIReference/API_EksProperties.html) den Parametersatz, den ein Job AWS Batch auf Amazon EKS unterstützt. In einer [SubmitJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html)Anfrage ermöglicht der [eksPropertiesOverride](https://docs.aws.amazon.com/batch/latest/APIReference/API_EksPropertiesOverride.html)Parameter das Überschreiben einiger gängiger Parameter. Auf diese Weise können Sie Vorlagen von Jobdefinitionen für mehrere Jobs verwenden. Wenn ein Auftrag an Ihren Amazon EKS-Cluster gesendet wird, AWS Batch wandelt er den Auftrag in einen `podspec` (`Kind: Pod`) um. Der `podspec` verwendet einige zusätzliche AWS Batch Parameter, um sicherzustellen, dass Jobs korrekt skaliert und geplant werden. AWS Batch kombiniert Labels und Taints, um sicherzustellen, dass Jobs nur auf AWS Batch verwalteten Knoten ausgeführt werden und dass andere Pods nicht auf diesen Knoten ausgeführt werden.
**Wichtig**
Wenn der `hostNetwork` Parameter in einer Amazon EKS-Auftragsdefinition nicht explizit festgelegt ist, wird für den Pod-Netzwerkmodus AWS Batch standardmäßig der Hostmodus verwendet. Insbesondere werden die folgenden Einstellungen angewendet: `hostNetwork=true` und`dnsPolicy=ClusterFirstWithHostNet`.
AWS Batch bereinigt Job-Pods, kurz nachdem ein Pod seinen Job abgeschlossen hat. Um Pod-Anwendungsprotokolle zu sehen, konfigurieren Sie einen Protokollierungsdienst für Ihren Cluster. Weitere Informationen finden Sie unter [Verwenden Sie CloudWatch Logs, um AWS Batch Amazon EKS-Jobs zu überwachen](batch-eks-cloudwatch-logs.md).
**Topics**
+ [Tutorial: Ordnen Sie einen laufenden Job einem Pod und einem Knoten zu](eks-jobs-map-running-job.md)
+ [Tutorial: Ordnen Sie einen laufenden Pod seinem Job zu](eks-jobs-map-running-pod-to-job.md)
# Tutorial: Ordnen Sie einen laufenden Job einem Pod und einem Knoten zu
Für einen laufenden Job wurden die `podName` `nodeName` Parameter für den aktuellen Jobversuch festgelegt. `podProperties` Verwenden Sie den [DescribeJobs](https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeJobs.html)API-Vorgang, um diese Parameter anzuzeigen.
Es folgt eine Beispielausgabe.
```
$ 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"
}
}
}
]
}
```
Bei einem Job mit aktivierten Wiederholungsversuchen steht das `podName` `nodeName` Ende jedes abgeschlossenen Versuchs im `eksAttempts` Listenparameter des [DescribeJobs](https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeJobs.html)API-Vorgangs. Das `podName` Ende `nodeName` des aktuell ausgeführten Versuchs befindet sich im `podProperties` Objekt.
# Tutorial: Ordnen Sie einen laufenden Pod seinem Job zu
Ein Pod hat Beschriftungen, die das `jobId` `uuid` Ende der Rechenumgebung angeben, zu der er gehört. AWS Batch fügt Umgebungsvariablen ein, sodass die Laufzeit des Jobs auf Jobinformationen verweisen kann. Weitere Informationen finden Sie unter [AWS Batch Variablen der Arbeitsumgebung](job_env_vars.md). Sie können diese Informationen anzeigen, indem Sie den folgenden Befehl ausführen. Die Ausgabe sieht wie folgt aus.
```
$ 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
...
```
**Funktionen, die AWS Batch Amazon EKS-Jobs unterstützen**
Dies sind die AWS Batch spezifischen Funktionen, die auch für Kubernetes Jobs gelten, die auf Amazon EKS ausgeführt werden:
+ [Abhängigkeiten von Job](job_dependencies.md)
+ [Ordnen Sie Jobs an](array_jobs.md)
+ [Timeouts bei der Job](job_timeouts.md)
+ [Automatisierte Auftragswiederholungen](job_retries.md)
+ [Verwenden Sie Fair-Share-Scheduling, um Jobs besser planen zu können](fair-share-scheduling.md)
**Kubernetes und `Secrets` `ServiceAccounts`**
AWS Batch unterstützt Referenzierung Kubernetes `Secrets` und`ServiceAccounts`. Sie können Pods so konfigurieren, dass sie Amazon EKS-IAM-Rollen für Dienstkonten verwenden. Weitere Informationen finden Sie unter [Konfiguration von Pods für die Verwendung eines Kubernetes Servicekontos](https://docs.aws.amazon.com/eks/latest/userguide/pod-configuration.html) im [https://docs.aws.amazon.com/eks/latest/userguide/](https://docs.aws.amazon.com/eks/latest/userguide/).
**Verwandte Dokumente**
+ [Überlegungen zu Arbeitsspeicher und vCPUs für AWS Batch Amazon EKS](memory-cpu-batch-eks.md)
+ [Führen Sie GPU-Jobs aus](gpu-jobs.md)
+ [Jobs, die in einem `RUNNABLE` Status feststecken](job_stuck_in_runnable.md)
# Parallel ausgeführte Aufträge mit mehreren Knoten
Sie können parallel Jobs mit mehreren Knoten verwenden, um einzelne Jobs auszuführen, die sich über mehrere Amazon EC2 EC2-Instances erstrecken. Mit parallel Aufträgen mit AWS Batch mehreren Knoten (auch bekannt als *Gruppenplanung*) können Sie umfangreiche Hochleistungsrechneranwendungen und das Training verteilter GPU-Modelle ausführen, ohne Amazon EC2 EC2-Ressourcen direkt starten, konfigurieren und verwalten zu müssen. Ein parallel Job mit AWS Batch mehreren Knoten ist mit jedem Framework kompatibel, das IP-basierte Kommunikation zwischen Knoten unterstützt. Beispiele hierfür sind Apache MXNet TensorFlow, Caffe2 oder Message Passing Interface (MPI).
parallel Jobs mit mehreren Knoten werden als ein einziger Job eingereicht. Ihre Auftragsdefinition (oder Überschreibungen durch den Auftragsübergabeknoten) legt jedoch die Anzahl der Knoten fest, die für den Auftrag erstellt werden müssen, und welche Knotengruppen erstellt werden müssen. Jeder parallele Auftrag mit mehreren Knoten enthält einen **Hauptknoten**, der zuerst gestartet wird. Nachdem der Hauptknoten aktiv ist, werden die untergeordneten Knoten gestartet und gestartet. Der Job ist nur abgeschlossen, wenn der Hauptknoten beendet wird. Alle untergeordneten Knoten werden dann gestoppt. Weitere Informationen finden Sie unter [Knotengruppen](mnp-node-groups.md).
parallel Jobknoten mit mehreren Knoten sind Single-Tenants. Das bedeutet, dass auf jeder Amazon EC2 EC2-Instance nur ein einziger Job-Container ausgeführt wird.
Der letzte Auftragsstatus (`SUCCEEDED` oder `FAILED`) wird durch den letzten Auftragsstatus des Hauptknotens bestimmt. Um den Status eines parallel Jobs mit mehreren Knoten abzurufen, beschreiben Sie den Job anhand der Job-ID, die beim Absenden des Jobs zurückgegeben wurde. Wenn Sie die Details für untergeordnete Knoten benötigen, beschreiben Sie jeden untergeordneten Knoten einzeln. Sie können Knoten anhand der `#N` Notation adressieren (beginnend mit 0). Um beispielsweise auf die Details des zweiten Knotens eines Jobs zuzugreifen, beschreiben Sie *aws\$1batch\$1job\$1id* \$11 mithilfe der AWS Batch [DescribeJobs](https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeJobs.html)API-Operation. Die Informationen `started`, `stoppedAt`, `statusReason` und `exit` für einen parallelen Auftrag mit mehreren Knoten stammen aus dem Hauptknoten.
Wenn Sie Auftragswiederholungen angeben, führt ein Ausfall des Hauptknotens zu einem erneuten Versuch. Ausfälle von untergeordneten Knoten führen nicht zu weiteren Versuchen. Jeder neue Versuch eines parallelen Auftrags mit mehreren Knoten aktualisiert den entsprechenden Versuch seiner zugehörigen untergeordneten Knoten.
Um parallel Jobs mit mehreren Knoten ausführen zu können AWS Batch, muss Ihr Anwendungscode die Frameworks und Bibliotheken enthalten, die für die verteilte Kommunikation erforderlich sind.
**Topics**
+ [Umgebungsvariablen](mnp-env-vars.md)
+ [Knotengruppen](mnp-node-groups.md)
+ [Joblebenszyklus für MNP-Jobs](job-lifecycle.md)
+ [Überlegungen zur Rechenumgebung für MNP mit AWS Batch](mnp-ce.md)
# Umgebungsvariablen
Zur Laufzeit werden für jeden Knoten die Standardumgebungsvariablen konfiguriert, die alle AWS Batch Jobs erhalten. Darüber hinaus sind die Knoten mit den folgenden Umgebungsvariablen konfiguriert, die für parallel Jobs mit mehreren Knoten spezifisch sind:
`AWS_BATCH_JOB_MAIN_NODE_INDEX`
Diese Variable ist auf die Indexnummer des Hauptknotens des Auftrags festgelegt. Ihr Anwendungscode kann den mit dem `AWS_BATCH_JOB_MAIN_NODE_INDEX` `AWS_BATCH_JOB_NODE_INDEX` auf einem einzelnen Knoten vergleichen, um festzustellen, ob es sich um den Hauptknoten handelt.
`AWS_BATCH_JOB_MAIN_NODE_PRIVATE_IPV4_ADDRESS`
Diese Variable wird nur in untergeordneten Knoten für parallel Jobs mit mehreren Knoten gesetzt. Diese Variable ist auf dem Hauptknoten nicht vorhanden. Diese Variable ist auf die private IPv4 Adresse des Hauptknotens des Jobs gesetzt. Der Anwendungscode Ihres untergeordneten Knotens kann diese Adresse zur Kommunikation mit dem Hauptknoten verwenden.
`AWS_BATCH_JOB_NODE_INDEX`
Diese Variable ist auf die Indexnummer des Knotens festgelegt. Der Knotenindex beginnt bei 0 und jeder Knoten erhält eine eindeutige Indexnummer. Beispielsweise weist ein paralleler Auftrag mit mehreren Knoten und 10 untergeordneten Aufträgen die Indexwerte 0–9 auf.
`AWS_BATCH_JOB_NUM_NODES`
Diese Variable ist auf die Anzahl der Knoten festgelegt, die Sie für Ihren parallelen Auftrag mit mehreren Knoten angefordert haben.
# Knotengruppen
Eine Knotengruppe ist eine identische Gruppe von Auftragsknoten, die alle dieselben Containereigenschaften gemeinsam haben. Sie können AWS Batch damit bis zu fünf verschiedene Knotengruppen für jeden Job angeben.
Jede Gruppe kann ihre eigenen Container-Images, Befehle, Umgebungsvariablen und so weiter besitzen. Sie können beispielsweise einen Job einreichen, für den eine einzelne `c5.xlarge` Instanz für den Hauptknoten und fünf untergeordnete `c5.xlarge` Instanzknoten erforderlich sind. Jede dieser unterschiedlichen Knotengruppen kann unterschiedliche Container-Images oder Befehle angeben, die für jeden Job ausgeführt werden sollen.
Alternativ können alle Knoten in Ihrem Job eine einzelne Knotengruppe verwenden. Darüber hinaus kann Ihr Anwendungscode zwischen Knotenrollen wie dem Hauptknoten und dem untergeordneten Knoten unterscheiden. Dazu wird die `AWS_BATCH_JOB_MAIN_NODE_INDEX` Umgebungsvariable mit ihrem eigenen Wert für verglichen`AWS_BATCH_JOB_NODE_INDEX`. Sie können bis zu 1.000 Knoten in einem einzigen Job haben. Dies ist das Standardlimit für Instances in einem Amazon ECS-Cluster. Sie können [eine Erhöhung dieses Limits beantragen](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html).
**Anmerkung**
Derzeit müssen alle Knotengruppen in einem parallel Job mit mehreren Knoten denselben Instanztyp verwenden.
# Joblebenszyklus für MNP-Jobs
Wenn Sie einen parallel Job mit mehreren Knoten einreichen, erhält der Job den `SUBMITTED` Status. Anschließend wartet der Job darauf, dass alle Auftragsabhängigkeiten abgeschlossen sind. Der Job wird ebenfalls in den `RUNNABLE` Status versetzt. Schließlich wird die AWS Batch Instance-Kapazität bereitgestellt, die für die Ausführung Ihres Jobs erforderlich ist, und diese Instances werden gestartet.
Jeder parallele Auftrag mit mehreren Knoten enthält einen **Hauptknoten**. Der Hauptknoten ist eine einzelne Unteraufgabe, die das Ergebnis des eingereichten Auftrags mit mehreren Knoten AWS Batch überwacht und bestimmt. Der Hauptknoten wird zum ersten Mal gestartet und wechselt in den `STARTING`-Status. Der im `attemptDurationSeconds` Parameter angegebene Timeout-Wert gilt für den gesamten Job und nicht für die Knoten.
Wenn der Hauptknoten den `RUNNING` Status erreicht, nachdem der Container des Knotens ausgeführt wurde, werden die untergeordneten Knoten gestartet und nehmen ebenfalls diesen `STARTING` Status an. Die untergeordneten Knoten werden in zufälliger Reihenfolge angezeigt. Es gibt keine Garantien hinsichtlich des Zeitpunkts oder der Reihenfolge, in der die untergeordneten Knoten starten. Um sicherzustellen, dass sich alle Knoten der Jobs im `RUNNING` Status befinden, nachdem der Container des Knotens ausgeführt wurde, kann Ihr Anwendungscode die AWS Batch API abfragen, um Informationen über den Hauptknoten und den untergeordneten Knoten abzurufen. Alternativ kann der Anwendungscode warten, bis alle Knoten online sind, bevor eine verteilte Verarbeitungsaufgabe gestartet wird. Die private IP-Adresse des Hauptknotens ist als `AWS_BATCH_JOB_MAIN_NODE_PRIVATE_IPV4_ADDRESS`-Umgebungsvariable in jedem untergeordneten Knoten verfügbar. Ihr Anwendungscode kann diese Informationen verwenden, um Daten und die Kommunikation zwischen den einzelnen Aufgaben zu koordinieren.
Wenn einzelne Knoten beendet werden, wechseln sie je nach ihrem Beendigungscode zu `SUCCEEDED` oder `FAILED`. Wenn der Hauptknoten beendet wird, gilt der Auftrag als abgeschlossen und alle seine untergeordneten Knoten werden beendet. Wenn ein untergeordneter Knoten ausfällt, werden AWS Batch keine Aktionen für die anderen Knoten im Job ausgeführt. Wenn Sie nicht möchten, dass Ihr Job mit einer reduzierten Anzahl von Knoten fortgeführt wird, müssen Sie dies in Ihrem Anwendungscode berücksichtigen. Dadurch wird der Job beendet oder abgebrochen.
# Überlegungen zur Rechenumgebung für MNP mit AWS Batch
Es gibt mehrere Dinge, die Sie berücksichtigen sollten, wenn Sie die Datenverarbeitungsumgebungen so konfigurieren, dass parallele Aufträge mit mehreren Knoten mit AWS Batch ausgeführt werden.
+ parallel Jobs mit mehreren Knoten werden in `UNMANAGED` Computerumgebungen nicht unterstützt.
+ Wenn Sie parallel Jobs mit mehreren Knoten an eine Rechenumgebung senden möchten, erstellen Sie eine *Cluster-Platzierungsgruppe* in einer einzigen Availability Zone und ordnen Sie sie Ihren Rechenressourcen zu. Dadurch bleiben Ihre parallel Jobs mit mehreren Knoten in einer logischen Gruppierung von Instanzen mit hohem Netzwerkflusspotenzial nahe beieinander. Weitere Informationen finden Sie unter [Platzierungsgruppen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html) im *Amazon-EC2-Benutzerhandbuch*.
+ parallel Jobs mit mehreren Knoten werden in Computerumgebungen, die Spot-Instances verwenden, nicht unterstützt.
+ AWS Batch parallel Jobs mit mehreren Knoten verwenden den Amazon `awsvpc` ECS-Netzwerkmodus, der Ihren parallel Job-Containern mit mehreren Knoten dieselben Netzwerkeigenschaften wie Amazon EC2 EC2-Instances verleiht. Jeder Container eines parallelen Auftrags mit mehreren Knoten erhält seine eigene Elastic Network-Schnittstelle, eine primäre private IP-Adresse und einen internen DNS-Hostnamen. Die Netzwerkschnittstelle wird im gleichen VPC-Subnetz erstellt wie ihre Host-Datenverarbeitungsressource.
+ Ihrer Datenverarbeitungsumgebung sind möglicherweise nicht mehr als fünf Sicherheitsgruppen zugeordnet. Die Elastic Network-Schnittstellen, die erstellt und an eine MNP-Aufgabe angehängt werden, verwenden die in Ihrer Computerumgebung angegebenen Sicherheitsgruppen. Wenn Sie keine Sicherheitsgruppe angeben, wird die Standardsicherheitsgruppe für die VPC verwendet.
+ Der `awsvpc` Netzwerkmodus bietet keine elastischen Netzwerkschnittstellen für parallel Jobs mit mehreren Knoten und öffentlichen IP-Adressen. Um auf das Internet zuzugreifen, müssen Ihre Datenverarbeitungsressourcen in einem privaten Subnetz gestartet werden, das für die Verwendung eines NAT-Gateways konfiguriert ist. Weitere Informationen finden Sie unter [NAT-Gateways](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) im *Amazon VPC-Benutzerhandbuch*. Bei der Kommunikation zwischen den Knoten muss die private IP-Adresse oder der DNS-Hostname für den Knoten verwendet werden. parallel Jobs mit mehreren Knoten, die auf Rechenressourcen in öffentlichen Subnetzen ausgeführt werden, haben keinen ausgehenden Netzwerkzugriff. Weitere Informationen zum Erstellen einer VPC mit privaten Subnetzen und einem NAT-Gateway finden Sie unter [Erstellen einer Virtual Private Cloud](create-public-private-vpc.md).
+ Die Elastic Network-Schnittstellen, die erstellt und an Ihre Rechenressourcen angehängt werden, können nicht manuell getrennt oder von Ihrem Konto geändert werden. Dadurch soll verhindert werden, dass versehentlich eine elastic network interface gelöscht wird, die mit einem laufenden Job verknüpft ist. Um die Elastic Network-Schnittstellen für eine Aufgabe freizugeben, beenden Sie den Auftrag.
+ Ihre Rechenumgebung muss über genügend maximale V verfügenCPUs , um Ihren parallel Job mit mehreren Knoten zu unterstützen.
+ Ihr Amazon EC2 EC2-Instance-Kontingent beinhaltet die Anzahl der Instances, die für die Ausführung Ihres Jobs erforderlich sind. Nehmen wir zum Beispiel an, dass für Ihren Job 30 Instances erforderlich sind, Ihr Konto jedoch nur 20 Instances in einer Region ausführen kann. Dann bleibt Ihr Job im `RUNNABLE` Status hängen.
+ Wenn Sie in einem parallel Job mit mehreren Knoten einen Instanztyp für eine Knotengruppe angeben, muss Ihre Rechenumgebung diesen Instanztyp starten.
# Parallel ausgeführte Aufträge mit mehreren Knoten in Amazon EKS
Sie können AWS Batch Amazon Elastic Kubernetes Service verwenden, um parallel Multi-Node-Jobs (MNP) (auch bekannt als *Gang Scheduling*) auf Ihren verwalteten Clustern auszuführen. Kubernetes Diese Option wird häufig für große, eng gekoppelte Hochleistungsjobs verwendet, die nicht auf einer einzigen Amazon Elastic Compute Cloud-Instance ausgeführt werden können. Weitere Informationen finden Sie unter [Parallel ausgeführte Aufträge mit mehreren Knoten](multi-node-parallel-jobs.md).
Sie können diese Funktion verwenden, um von Amazon EKS verwaltete Kubernetes spezifische Hochleistungscomputeranwendungen, das Training großer Sprachmodelle und andere Jobs im Bereich künstliche Intelligenz (KI) /maschinelles Machine Learning (ML) auszuführen.
**Topics**
+ [MNP-Jobs ausführen](mnp-eks-running-mnp-jobs.md)
+ [Erstellen Sie eine Amazon EKS MNP-Jobdefinition](mnp-eks-create-eks-mnp-job-definition.md)
+ [Einen Amazon EKS MNP-Job einreichen](mnp-eks-submit-eks-mnp-job.md)
+ [Eine Amazon EKS MNP-Auftragsdefinition überschreiben](mnp-eks-override-eks-mnp-job-definition.md)
# MNP-Jobs ausführen
AWS Batch unterstützt MNP-Jobs auf Amazon Elastic Container Service und Amazon EKS mithilfe von Amazon EC2. Im Folgenden finden Sie weitere Einzelheiten zu den Instance- und Container-Parametern für die Funktion.
## Instanzkontingente für MNP auf Amazon EKS
+ Bis zu 1000 Instances können für einen einzelnen MNP-Job verwendet werden.
+ Bis zu 5000 Instances können einem einzelnen Amazon EKS-Cluster beitreten.
+ Bis zu 5 Computerumgebungen können geclustert und an eine Job-Warteschlange angehängt werden.
Sie können beispielsweise bis zu 5 geclusterte Rechenumgebungen in einer Job-Warteschlange und 1000 Instanzen in jeder Rechenumgebung skalieren.
Zusätzlich zu den Instanzparametern ist es wichtig zu beachten, dass Sie Fargate über keinen der beiden Dienste für MNP-Jobs verwenden können.
Sie können in jedem MNP-Job nur einen Instanztyp verwenden. Sie können den Instanztyp ändern, indem Sie die Rechenumgebung aktualisieren oder wenn Sie eine neue Rechenumgebung definieren. Sie können auch den Instanztyp angeben und vCPU- und Speicheranforderungen angeben, wenn Sie die Jobdefinition erstellen.
## Containerkontingente für MNP auf Amazon EKS
+ Ein parallel Job mit mehreren Knoten unterstützt einen Pod pro Knoten.
+ Bis zu 10 Container (oder 10 Init-Container). Weitere Informationen finden Sie unter [Init-Container](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/) in der *Kubernetes-Dokumentation.) in jedem* Pod.
+ Bis zu 5 Knotenbereiche in jedem MNP-Job.
+ Bis zu 10 verschiedene Container-Images in jedem Knotenbereich.
Sie können beispielsweise bis zu 10.000 Container in einem einzigen MNP-Job ausführen, der 5 Knotenbereiche und insgesamt 50 eindeutige Bilder enthält.
## Ausführung von MNP-Jobs in einer privaten Amazon VPC und einem Amazon EKS-Cluster
MNP-Jobs können auf jedem Amazon EKS-Cluster ausgeführt werden, unabhängig davon, ob er über ein öffentliches Internet verfügt oder nicht. Wenn Sie einen Amazon EKS-Cluster mit ausschließlich privatem Netzwerkzugriff verwenden, stellen Sie sicher, dass dieser auf die Amazon EKS-Steuerebene und den verwalteten Kubernetes API-Server zugreifen AWS Batch kann. Sie können den erforderlichen Zugriff über Amazon Virtual Private Cloud Cloud-Endpunkte gewähren. Weitere Informationen finden Sie unter [Konfiguration eines Endpunktdienstes](https://docs.aws.amazon.com/vpc/latest/privatelink/configure-endpoint-service.html).
Amazon EKS-Cluster-Pods können kein Image von einer öffentlichen Quelle herunterladen, da die private VPC keinen Internetzugang hat. Ihr Amazon EKS-Cluster muss Images aus einer Container-Registry abrufen, die sich in Ihrer Amazon VPC befindet. Sie können eine [Amazon Elastic Container Registry (Amazon ECR)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/Registries.html) in Ihrer Amazon VPC erstellen und Container-Images dorthin kopieren, damit Ihre Knoten darauf zugreifen können.
Sie können mit Amazon ECR auch eine Pull-Through-Cache-Regel erstellen. Sobald eine Pull-Through-Cache-Regel für eine externe öffentliche Registrierung erstellt wurde, können Sie einfach ein Bild aus dieser externen öffentlichen Registrierung mit Ihrer privaten Amazon ECR-Registrierungs-URI abrufen. Dann erstellt Amazon ECR ein Repository und speichert das Bild im Cache. Wenn ein zwischengespeichertes Image mithilfe des privaten Amazon-ECR-Registrierung-URI abgerufen wird, überprüft Amazon ECR die Remote-Registrierung, um festzustellen, ob eine neue Version des Images vorhanden ist, und aktualisiert Ihre private Registrierung bis zu einmal alle 24 Stunden. Weitere Informationen finden Sie unter [Erstellen einer Pull-Through-Cache-Regel in Amazon ECR.](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache-creating-rule.html)
## Benachrichtigung über einen Fehler
Wenn Ihre MNP-Jobs blockiert sind, können Sie Benachrichtigungen über The AWS-Managementkonsole und Amazon EventBridge erhalten. Wenn beispielsweise ein MNP-Job an der Spitze der Warteschlange feststeckt, können Sie über das Problem sowie Informationen zur Ursache des Problems informiert werden, sodass Sie umgehend Maßnahmen ergreifen können, um Ihre Job-Warteschlange zu entsperren. Optional können Sie den MNP-Job automatisch beenden, wenn innerhalb eines bestimmten Zeitraums, der in der Vorlage für die Auftragswarteschlange definiert werden kann, keine Aktion ausgeführt wird. Weitere Informationen finden Sie unter [Blockierte Ereignisse in der Job-Warteschlange](batch-job-queue-blocked-events.md).
# Erstellen Sie eine Amazon EKS MNP-Jobdefinition
Um MNP-Jobs auf Amazon EKS zu definieren und auszuführen, gibt es neue Parameter innerhalb der [https://docs.aws.amazon.com/batch/latest/APIReference/API_RegisterJobDefinition.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_RegisterJobDefinition.html)und [https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html)API-Operationen.
+ Verwenden Sie den [https://docs.aws.amazon.com/batch/latest/APIReference/API_EksProperties.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_EksProperties.html)Abschnitt unten, um Ihre MNP-Jobdefinition zu definieren.
+ Verwenden Sie die [https://docs.aws.amazon.com/batch/latest/APIReference/API_EksPropertiesOverride.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_EksPropertiesOverride.html)Option unter dem [https://docs.aws.amazon.com//batch/latest/APIReference/API_NodePropertyOverride.html](https://docs.aws.amazon.com//batch/latest/APIReference/API_NodePropertyOverride.html)Abschnitt, um die in der Jobdefinition definierten Parameter zu überschreiben, wenn Sie einen MNP-Job einreichen.
Diese Aktionen können durch API-Operationen und die AWS-Managementkonsole definiert werden.
## Referenz: Registrieren Sie die Payload für die Amazon EKS MNP-Jobdefinitionsanforderung
Das folgende Beispiel zeigt, wie Sie eine Amazon EKS MNP-Auftragsdefinition mit zwei Knoten registrieren können.
```
{
"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"
}
}
}
}
}
]
}
}
```
Um die Auftragsdefinition mithilfe von zu registrieren AWS CLI, kopieren Sie die Definition in eine lokale Datei mit dem Namen *MyEksMnpJobDefinition.json* und führen Sie den folgenden Befehl aus.
```
aws batch register-job-definition --cli-input-json file://MyEksMnpJobDefinition.json
```
Sie erhalten die folgende JSON-Antwort.
```
{
"jobDefinitionName": "MyEksMnpJobDefinition",
"jobDefinitionArn": "arn:aws:batch:us-east-1:0123456789:job-definition/MyEksMnpJobDefinition:1",
"revision": 1
}
```
# Einen Amazon EKS MNP-Job einreichen
Um einen Job mit der registrierten Jobdefinition einzureichen, geben Sie den folgenden Befehl ein. Ersetzen Sie den Wert von durch den Namen oder ARN einer bereits vorhandenen Auftragswarteschlange, die mit einer Amazon EKS-Rechenumgebung verknüpft ist.
```
aws batch submit-job --job-queue \
--job-definition MyEksMnpJobDefinition \
--job-name myFirstEksMnpJob
```
Sie erhalten die folgende JSON-Antwort.
```
{
"jobArn": "arn:aws:batch:region:account:job/9b979cce-9da0-446d-90e2-ffa16d52af68",
"jobName": "myFirstEksMnpJob",
"jobId": ""
}
```
Sie können den Status des Jobs anhand der zurückgegebenen jobId mit dem folgenden Befehl überprüfen.
```
aws batch describe-jobs --jobs
```
# Eine Amazon EKS MNP-Auftragsdefinition überschreiben
Optional können Sie die Details der Auftragsdefinition überschreiben (z. B. die Änderung der MNP-Auftragsgröße oder der Details des untergeordneten Auftrags). Im Folgenden finden Sie ein Beispiel für eine JSON-Anforderungs-Payload zum Senden eines MNP-Jobs mit fünf Knoten sowie Änderungen am Befehl des `test-eks-container-1` Containers.
```
{
"numNodes": 5,
"nodePropertyOverrides": [
{
"targetNodes": "0:",
"eksPropertiesOverride": {
"podProperties": {
"containers": [
{
"name": "test-eks-container-1",
"command": [
"sleep",
"150"
]
}
]
}
}
}
]
}
```
Um einen Job mit diesen Überschreibungen einzureichen, speichern Sie das Beispiel in einer lokalen Datei, *eks-mnp-job-nodeoverride.json*, und verwenden Sie die, um den Job mit den Überschreibungen AWS CLI zu senden.
# Ordnen Sie Jobs an
Ein Array-Job ist ein Job, der gemeinsame Parameter wie JobdefinitionCPUs, V und Speicher verwendet. Er wird als Sammlung verwandter, aber separater Basisjobs ausgeführt, die möglicherweise auf mehrere Hosts verteilt sind und gleichzeitig ausgeführt werden. Array-Jobs sind die effizienteste Methode, um extrem parallel Jobs wie Monte-Carlo-Simulationen, parametrische Sweeps oder umfangreiche Rendering-Jobs auszuführen.
AWS Batch Array-Jobs werden genauso wie normale Jobs eingereicht. Sie geben jedoch eine Array-Größe (zwischen 2 und 10.000) an. Diese legt fest, wie viele untergeordnete Aufträge im Array ausgeführt werden sollen. Wenn Sie einen Auftrag mit einer Array-Größe von 1000 senden, wird ein einzelner Auftrag ausgeführt und erzeugt 1000 untergeordnete Aufträge. Der Array-Auftrag ist eine Referenz oder ein Zeiger, um alle untergeordneten Aufträge zu verwalten. Auf diese Weise können Sie große Workloads mit einer einzigen Abfrage einreichen. Das im `attemptDurationSeconds` Parameter angegebene Timeout gilt für jeden untergeordneten Job. Der übergeordnete Array-Job hat kein Timeout.
Wenn Sie einen Array-Job einreichen, erhält der übergeordnete Array-Job eine normale AWS Batch Job-ID. Jeder untergeordnete Job hat dieselbe Basis-ID. Der Array-Index für den untergeordneten Job wird jedoch an das Ende der übergeordneten ID angehängt, z. B. `example_job_ID:0` für den ersten untergeordneten Job des Arrays.
Der übergeordnete Array-Job kann den `SUCCEEDED` Status `SUBMITTED``PENDING`,`FAILED`, oder annehmen. Ein übergeordneter Array-Job wird aktualisiert`PENDING`, wenn ein untergeordneter Job aktualisiert wird`RUNNABLE`. Weitere Hinweise zu Auftragsabhängigkeiten finden Sie unter[Abhängigkeiten von Job](job_dependencies.md).
Zur Laufzeit wird die Umgebungsvariable `AWS_BATCH_JOB_ARRAY_INDEX` auf die Nummer des entsprechenden Auftrags-Array-Index des Containers festgelegt. Der erste Array-Auftragsindex ist nummeriert`0`, und die nachfolgenden Versuche erfolgen in aufsteigender Reihenfolge (z. B. 1, 2 und 3). Sie können diesen Indexwert dazu verwenden, zu steuern, wie Ihre untergeordneten Array-Auftragselemente differenziert werden. Weitere Informationen finden Sie unter [Verwenden Sie den Array-Jobindex, um die Jobdifferenzierung zu steuern](array_index_example.md).
Für Array-Auftrags-Abhängigkeiten können Sie einen Typ für eine Abhängigkeit angeben (z. B. `SEQUENTIAL` oder `N_TO_N`). Sie können eine `SEQUENTIAL`-Typabhängigkeit angeben, ohne eine Auftrags-ID anzugeben, sodass jeder untergeordnete Array-Auftrag sequentiell abgeschlossen wird (beginnend mit Index 0). Wenn Sie z. B. einen Array-Auftrag mit einer Array-Größe von 100 senden und eine Abhängigkeit vom Typ `SEQUENTIAL` angeben, werden 100 untergeordnete Aufträge sequentiell erzeugt, wobei der erste untergeordnete Auftrag erfolgreich sein muss, bevor der nächste untergeordnete Auftrag startet. Die folgende Abbildung zeigt Auftrag A, einen Array-Auftrag mit einer Array-Größe von 10. Jeder Auftrag im untergeordneten Index von Auftrag A ist vom vorherigen untergeordneten Auftrag abhängig. Auftrag A:1 kann erst gestartet werden, wenn Auftrag A:0 beendet ist.
![\[Flowchart showing Job-A with sequential child jobs A:0 through A:9, connected by arrows.\]](http://docs.aws.amazon.com/de_de/batch/latest/userguide/images/sequential-dep.png)
Sie können auch eine Abhängigkeit vom `N_TO_N`-Typ mit einer Aufgaben-ID für Array-Aufgaben angeben. So muss jeder untergeordnete Index dieses Auftrags warten, bis der entsprechende untergeordnete Index jeder Abhängigkeit abgeschlossen ist. Die folgende Abbildung zeigt Job A und Job B, zwei Array-Jobs mit einer Array-Größe von jeweils 10.000. Jeder Auftrag im untergeordneten Index von Auftrag B ist abhängig von dem entsprechenden Index in Auftrag A. Auftrag B:1 kann erst gestartet werden, wenn Auftrag A:1 beendet ist.
![\[Two array jobs, Job-A and Job-B, with 10,000 indexed tasks each, showing N_TO_N dependency.\]](http://docs.aws.amazon.com/de_de/batch/latest/userguide/images/n-to-n-dep.png)
Wenn Sie einen übergeordneten Array-Auftrag abbrechen oder beenden, werden alle untergeordneten Jobs gleichzeitig storniert oder beendet. Sie können einzelne untergeordnete Jobs stornieren oder beenden (wodurch sie in einen `FAILED` Status versetzt werden), ohne dass sich dies auf die anderen untergeordneten Jobs auswirkt. Wenn jedoch ein untergeordneter Array-Auftrag fehlschlägt (eigenständig oder durch manuelles Abbrechen oder Beenden des Auftrags), schlägt auch der übergeordnete Job fehl. In diesem Szenario geht der übergeordnete Job zu dem `FAILED` Zeitpunkt über, zu dem alle untergeordneten Jobs abgeschlossen sind.
Weitere Informationen zum Suchen und Filtern von Array-Jobs finden Sie unter[Suchen Sie in einer Jobwarteschlange nach Jobs](searching-filtering-jobs.md).
**Topics**
+ [Beispiel für einen Array-Job-Workflow](example_array_job.md)
+ [Verwenden Sie den Array-Jobindex, um die Jobdifferenzierung zu steuern](array_index_example.md)
# Beispiel für einen Array-Job-Workflow
Ein üblicher Arbeitsablauf für AWS Batch Kunden besteht darin, einen vorausgesetzten Setup-Job auszuführen, eine Reihe von Befehlen für eine große Anzahl von Eingabeaufgaben auszuführen und dann mit einem Job abzuschließen, der Ergebnisse aggregiert und Zusammenfassungsdaten in Amazon S3, DynamoDB, Amazon Redshift oder Aurora schreibt.
Beispiel:
+ `JobA`: Ein standardmäßiger Nicht-Array-Job, der eine schnelle Auflistung und Metadatenvalidierung von Objekten in einem Amazon S3 S3-Bucket durchführt,`BucketA`. Die [SubmitJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html)JSON-Syntax lautet wie folgt.
```
{
"jobName": "JobA",
"jobQueue": "ProdQueue",
"jobDefinition": "JobA-list-and-validate:1"
}
```
+ `JobB`: Ein Array-Job mit 10.000 Kopien, der `JobA` davon abhängig ist und CPU-intensive Befehle für jedes Objekt ausführt `BucketA` und Ergebnisse in dieses hochlädt. `BucketB` Die [SubmitJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html)JSON-Syntax lautet wie folgt.
```
{
"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`: Ein weiterer Array-Job `JobB` mit 10.000 Kopien, von dem ein `N_TO_N` Abhängigkeitsmodell abhängig ist, das speicherintensive Befehle für jedes Element ausführt`BucketB`, Metadaten in DynamoDB schreibt und die resultierende Ausgabe dorthin hochlädt. `BucketC` Die [SubmitJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html)JSON-Syntax lautet wie folgt.
```
{
"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`: Ein Array-Job, der 10 Validierungsschritte ausführt, die jeweils DynamoDB abfragen müssen und mit jedem der oben genannten Amazon S3 S3-Buckets interagieren können. Jeder der Schritte in `JobD` führt denselben Befehl aus. Das Verhalten ist jedoch je nach Wert der `AWS_BATCH_JOB_ARRAY_INDEX` Umgebungsvariablen im Container des Jobs unterschiedlich. Diese Überprüfungsschritte werden sequentiell ausgeführt (z. B. `JobD:0` und dann`JobD:1`). Die [SubmitJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html)JSON-Syntax lautet wie folgt.
```
{
"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`: Ein letzter Job, der kein Array ist und einige einfache Bereinigungsvorgänge durchführt und eine Amazon SNS SNS-Benachrichtigung mit einer Meldung sendet, dass die Pipeline abgeschlossen wurde, und einem Link zur Ausgabe-URL. Die [SubmitJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html)JSON-Syntax lautet wie folgt.
```
{
"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"
}
]
}
```
# Verwenden Sie den Array-Jobindex, um die Jobdifferenzierung zu steuern
In diesem Tutorial wird beschrieben, wie Sie die `AWS_BATCH_JOB_ARRAY_INDEX` Umgebungsvariable verwenden, um die untergeordneten Jobs zu unterscheiden. Jeder untergeordnete Job ist dieser Variablen zugewiesen. In diesem Beispiel wird die Indexnummer des untergeordneten Jobs verwendet, um eine bestimmte Zeile in einer Datei zu lesen. Dann wird der mit dieser Zeilennummer verknüpfte Parameter durch einen Befehl im Container des Jobs ersetzt. Das Ergebnis ist, dass Sie mehrere AWS Batch Jobs haben können, die dasselbe Docker-Image und dieselben Befehlsargumente ausführen. Die Ergebnisse sind jedoch unterschiedlich, da der Array-Jobindex als Modifikator verwendet wird.
In diesem Tutorial erstellen Sie eine Textdatei, die – jeweils in einer eigenen Zeile stehend – alle Farben des Regenbogens umfasst. Anschließend erstellen Sie ein Einstiegsskript für einen Docker-Container, das den Index in einen Wert konvertiert, der für eine Zeilennummer in der Farbdatei verwendet werden kann. Der Index beginnt bei Null, aber die Zeilennummern beginnen bei Eins. Erstellen Sie ein Dockerfile, das die Farb- und Indexdateien in das Container-Image kopiert und `ENTRYPOINT` für das Bild das Entrypoint-Skript festlegt. Die Docker-Datei und die Ressourcen werden in einem Docker-Image erstellt, das an Amazon ECR übertragen wird. Anschließend registrieren Sie eine Jobdefinition, die Ihr neues Container-Image verwendet, reichen einen AWS Batch Array-Job mit dieser Jobdefinition ein und sehen sich die Ergebnisse an.
**Topics**
+ [Voraussetzungen](array-tutorial-prereqs.md)
+ [Erstellen Sie ein Container-Image](build-index-container.md)
+ [Übertragen Sie Ihr Bild auf Amazon ECR](push-array-image.md)
+ [Erstellen und registrieren Sie eine Jobdefinition](create-array-job-def.md)
+ [Reichen Sie einen AWS Batch Array-Job ein](submit-array-job.md)
+ [Zeigen Sie Ihre Array-Jobprotokolle an](#array-tutorial-logs)
# Voraussetzungen
Für diesen Tutorial-Workflow gelten die folgenden Voraussetzungen:
+ Eine AWS Batch Rechenumgebung. Weitere Informationen finden Sie unter [Erstellen Sie eine Rechenumgebung](create-compute-environment.md).
+ Eine AWS Batch Jobwarteschlange und eine zugehörige Rechenumgebung. Weitere Informationen finden Sie unter [Eine Job-Warteschlange erstellen](create-job-queue.md).
+ Die AWS CLI ist auf Ihrem lokalen System installiert. Weitere Informationen finden Sie unter [>Installation von AWS Command Line Interface im AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/installing.html) *Benutzerhandbuch*.
+ Das auf dem lokalen System installierte Docker. Weitere Informationen finden Sie unter [Über Docker CE](https://docs.docker.com/install/) in der Docker-Dokumentation.
# Erstellen Sie ein Container-Image
Sie können das `AWS_BATCH_JOB_ARRAY_INDEX` in einer Jobdefinition im Befehlsparameter verwenden. Wir empfehlen jedoch, stattdessen ein Container-Image zu erstellen, das die Variable in einem Entrypoint-Skript verwendet. In diesem Abschnitt wird beschrieben, wie Sie ein solches Container-Image erstellen.
**So erstellen Sie ein Docker-Container-Image:**
1. Erstellen Sie ein neues Verzeichnis zur Verwendung als Docker-Image-Workspace und wechseln Sie dort hin.
1. Erstellen Sie eine Datei mit dem Namen `colors.txt` in Ihrem Workspace-Verzeichnis und fügen Sie Folgendes ein.
```
red
orange
yellow
green
blue
indigo
violet
```
1. Erstellen Sie eine Datei mit dem Namen `print-color.sh` in Ihrem Workspace-Verzeichnis und fügen Sie Folgendes ein.
**Anmerkung**
Für die `LINE`-Variable ist `AWS_BATCH_JOB_ARRAY_INDEX` \$1 1 festgelegt, da der Array-Index bei 0 beginnt, die Zeilennummern aber bei 1. Die `COLOR` Variable wird auf die Farbe gesetzt`colors.txt`, die ihrer Zeilennummer zugeordnet ist.
```
#!/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. Erstellen Sie eine Datei mit dem Namen `Dockerfile` in Ihrem Workspace-Verzeichnis und fügen Sie den folgenden Inhalt ein. Diese Docker-Datei kopiert die vorherigen Dateien auf Ihren Container und legt fest, dass das entrypoint-Skript ausgeführt wird, wenn der Container gestartet wird.
```
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. Erstellen Sie das Docker-Image.
```
$ docker build -t print-color .
```
1. Testen Sie den Container mit dem folgenden Skript. Dieses Skript setzt die `AWS_BATCH_JOB_ARRAY_INDEX` Variable lokal auf 0 und erhöht sie dann, um zu simulieren, was ein Array-Job mit sieben untergeordneten Objekten bewirkt.
```
$ 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
```
Im Folgenden wird die Ausgabe dargestellt.
```
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.
```
# Übertragen Sie Ihr Bild auf Amazon ECR
Nachdem Sie Ihren Docker-Container erstellt und getestet haben, können Sie ihn in ein Image-Repository verschieben. In diesem Beispiel wird Amazon ECR verwendet, Sie können jedoch auch eine andere Registrierung verwenden, z. B. DockerHub
1. Erstellen Sie ein Amazon ECR-Image-Repository, um Ihr Container-Image zu speichern. In diesem Beispiel wird nur der verwendet AWS CLI, Sie können aber auch den AWS-Managementkonsole verwenden. Weitere Informationen finden Sie unter [Creating a Repository](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-create.html) im *Amazon Elastic Container Registry-Benutzerhandbuch*.
```
$ aws ecr create-repository --repository-name print-color
```
1. Kennzeichnen Sie Ihr `print-color` Bild mit Ihrer Amazon ECR-Repository-URI, die im vorherigen Schritt zurückgegeben wurde.
```
$ docker tag print-color aws_account_id.dkr.ecr.region.amazonaws.com/print-color
```
1. Melden Sie sich bei Ihrer Amazon ECR-Registrierung an. Weitere Informationen finden Sie unter [Registry-Authentifizierung](https://docs.aws.amazon.com/AmazonECR/latest/userguide/Registries.html#registry_auth) im *Benutzerhandbuch zu 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. Übertragen Sie Ihr Bild auf Amazon ECR.
```
$ docker push aws_account_id.dkr.ecr.region.amazonaws.com/print-color
```
# Erstellen und registrieren Sie eine Jobdefinition
Da sich Ihr Docker-Image nun in einer Image-Registry befindet, können Sie es in einer AWS Batch Jobdefinition angeben. Anschließend können Sie es später verwenden, um einen Array-Job auszuführen. In diesem Beispiel wird nur der verwendet AWS CLI. Sie können jedoch auch die verwenden AWS-Managementkonsole. Weitere Informationen finden Sie unter [Erstellen Sie eine Auftragsdefinition mit einem Knoten](create-job-definition.md).
**So erstellen Sie eine Auftragsdefinition:**
1. Erstellen Sie eine Datei mit dem Namen `print-color-job-def.json` in Ihrem Workspace-Verzeichnis und fügen Sie Folgendes ein. Ersetzen Sie den Image-Repository-URI durch den URI des Bildes.
```
{
"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. Registrieren Sie die Jobdefinition bei AWS Batch.
```
$ aws batch register-job-definition --cli-input-json file://print-color-job-def.json
```
# Reichen Sie einen AWS Batch Array-Job ein
Nachdem Sie Ihre Jobdefinition registriert haben, können Sie einen AWS Batch Array-Job einreichen, der Ihr neues Container-Image verwendet.
**Um einen AWS Batch Array-Job einzureichen**
1. Erstellen Sie eine Datei mit dem Namen `print-color-job.json` in Ihrem Workspace-Verzeichnis und fügen Sie Folgendes ein.
**Anmerkung**
In diesem Beispiel wird die im [Voraussetzungen](array-tutorial-prereqs.md) Abschnitt erwähnte Job-Warteschlange verwendet.
```
{
"jobName": "print-color",
"jobQueue": "existing-job-queue",
"arrayProperties": {
"size": 7
},
"jobDefinition": "print-color"
}
```
1. Reichen Sie den Job in Ihre AWS Batch Job-Warteschlange ein. Notieren Sie sich die Job-ID, die in der Ausgabe zurückgegeben wird.
```
$ aws batch submit-job --cli-input-json file://print-color-job.json
```
1. Beschreiben Sie den Status des Auftrags und warten Sie, bis der Auftrag den Status `SUCCEEDED` erhält.
## Zeigen Sie Ihre Array-Jobprotokolle an
Sobald Ihr Job den `SUCCEEDED` Status erreicht hat, können Sie die CloudWatch Protokolle im Container des Jobs einsehen.
**Um die Logs Ihres Jobs in CloudWatch Logs einzusehen**
1. Öffnen Sie die AWS Batch Konsole unter [https://console.aws.amazon.com/batch/](https://console.aws.amazon.com/batch/).
1. Wählen Sie im linken Navigationsbereich **Aufträge** aus.
1. Wählen Sie für **Auftragswarteschlange** eine Warteschlange aus.
1. Wählen Sie im Bereich **Status** die Option **erfolgreich** aus.
1. Zum Anzeigen aller untergeordneten Aufträge für den Array-Auftrag wählen Sie die Auftrags-ID aus, die im vorherigen Abschnitt zurückgegeben wurde.
1. Zum Anzeigen der Protokolle aus dem Container des Auftrags wählen Sie einen der untergeordneten Aufträge und dann die Option **Protokolle anzeigen** aus.
![\[Container-Protokolle für Array-Jobs\]](http://docs.aws.amazon.com/de_de/batch/latest/userguide/images/array-logs.png)
1. Zeigen Sie die Protokolle der anderen untergeordneten Protokolle an. Jeder Auftrag gibt eine andere Farbe des Regenbogens zurück.
# Führen Sie GPU-Jobs aus
GPU-Jobs helfen Ihnen dabei, Jobs auszuführen, die die einer Instanz verwenden. GPUs
Die folgenden GPU-basierten Instance-Typen von Amazon EC2 werden unterstützt. [https://aws.amazon.com/ec2/instance-types/trn2/](https://aws.amazon.com/ec2/instance-types/trn2/) [ 2 Dl1-Instances](https://aws.amazon.com/ec2/instance-types/dl1/) und [Amazon EC2 Dl2-Instances](https://aws.amazon.com/ec2/instance-types/dl2q/).
| Instance-Typ | GPUs | GPU-Arbeitsspeicher | v CPUs | Arbeitsspeicher | Netzwerkbandbreite |
| --- | --- | --- | --- | --- | --- |
| g3s.xgroß | 1 | 8 GiB | 4 | 30,5 GiB | 10 Gbit/s |
| g3.4xgroß | 1 | 8 GiB | 16 | 122 GiB | Bis zu 10 Gbit/s |
| g3.8xgroß | 2 | 16 GiB | 32 | 244 GiB | 10 Gbit/s |
| g3.16xgroß | 4 | 32 GiB | 64 | 488 GiB | 25 Gbit/s |
| g4dn.xgroß | 1 | 16 GiB | 4 | 16 GiB | Bis zu 25 Gbit/s |
| g4dn.2xgroß | 1 | 16 GiB | 8 | 32 GiB | Bis zu 25 Gbit/s |
| g4dn.4xgroß | 1 | 16 GiB | 16 | 64 GiB | Bis zu 25 Gbit/s |
| g4dn.8xgroß | 1 | 16 GiB | 32 | 128 GiB | 50 Gbit/s |
| g4dn.12xgroß | 4 | 64 GiB | 48 | 192 GiB | 50 Gbit/s |
| g4dn.16xgroß | 1 | 16 GiB | 64 | 256 GiB | 50 Gbit/s |
| g5.xgroß | 1 | 24 GiB | 4 | 16 GiB | Bis zu 10 Gbit/s |
| g5.2xlarge | 1 | 24 GiB | 8 | 32 GiB | Bis zu 10 Gbit/s |
| g5.4xlarge | 1 | 24 GiB | 16 | 64 GiB | Bis zu 25 Gbit/s |
| g5.8xlarge | 1 | 24 GiB | 32 | 128 GiB | 25 Gbit/s |
| g5.16xlarge | 1 | 24 GiB | 64 | 256 GiB | 25 Gbit/s |
| g5.12xlarge | 4 | 96 GiB | 48 | 192 GiB | 40 GBit/s |
| g5.24xlarge | 4 | 96 GiB | 96 | 384 GiB | 50 Gbit/s |
| g5.48xlarge | 8 | 192 GiB | 192 | 768 GiB | 100 Gbit/s |
| g5g.xlarge | 1 | 16 GiB | 4 | 8 GiB | Bis zu 10 Gbit/s |
| g5g.2xlarge | 1 | 16 GiB | 8 | 16 GiB | Bis zu 10 Gbit/s |
| g5g.4xlarge | 1 | 16 GiB | 16 | 32 GiB | Bis zu 10 Gbit/s |
| g5g.8xlarge | 1 | 16 GiB | 32 | 64 GiB | 12 Gbit/s |
| g5g.16xlarge | 2 | 32 GiB | 64 | 128 GiB | 25 Gbit/s |
| g5g.metal | 2 | 32 GiB | 64 | 128 GiB | 25 Gbit/s |
| g6.xlarge | 1 | 24 GiB | 4 | 16 GiB | Bis zu 10 Gbit/s |
| g6.2xlarge | 1 | 24 GiB | 8 | 32 GiB | Bis zu 10 Gbit/s |
| g6.4xlarge | 1 | 24 GiB | 16 | 64 GiB | Bis zu 25 Gbit/s |
| g6.8xlarge | 1 | 24 GiB | 32 | 128 GiB | 25 Gbit/s |
| g6.16xlarge | 1 | 24 GiB | 64 | 256 GiB | 25 Gbit/s |
| g6.12xlarge | 4 | 96 GiB | 48 | 192 GiB | 40 GBit/s |
| g6.24xlarge | 4 | 96 GiB | 96 | 384 GiB | 50 Gbit/s |
| g6.48xlarge | 8 | 192 GiB | 192 | 768 GiB | 100 Gbit/s |
| g6e.xlarge | 1 | 48 GiB | 4 | 32 GiB | Bis zu 20 Gbit/s |
| g6e.2xlarge | 1 | 48 GiB | 8 | 64 GiB | Bis zu 20 Gbit/s |
| g6e.4xlarge | 1 | 48 GiB | 16 | 128 GiB | 20 Gbit/s |
| g6e.8xlarge | 1 | 48 GiB | 32 | 256 GiB | 25 Gbit/s |
| g6e.16xlarge | 1 | 48 GiB | 64 | 512 GiB | 35 Gbit/s |
| g6e.12xlarge | 4 | 192 GiB | 48 | 384 GiB | 100 Gbit/s |
| g6e.24xlarge | 4 | 192 GiB | 96 | 768 GiB | 200 Gbit/s |
| g6e.48xlarge | 8 | 384 GiB | 192 | 1536 GiB | 400 Gbit/s |
| gr6.4xlarge | 1 | 24 GiB | 16 | 128 GiB | Bis zu 25 Gbit/s |
| gr6.8xlarge | 1 | 24 GiB | 32 | 256 GiB | 25 Gbit/s |
| p2.xgroß | 1 | 12 GiB | 4 | 61 GiB | Hoch |
| p2.8xgroß | 8 | 96 GiB | 32 | 488 GiB | 10 Gbit/s |
| p2.16xgroß | 16 | 192 GiB | 64 | 732 GiB | 20 Gbit/s |
| p3.2xgroß | 1 | 16 GiB | 8 | 61 GiB | Bis zu 10 Gbit/s |
| p3.8xgroß | 4 | 64 GiB | 32 | 244 GiB | 10 Gbit/s |
| p3.16xgroß | 8 | 128 GiB | 64 | 488 GiB | 25 Gbit/s |
| p3dn.24xgroß | 8 | 256 GiB | 96 | 768 GiB | 100 Gbit/s |
| p4d.24xgroß | 8 | 320 GiB | 96 | 1152 GiB | 400 Gbit/s |
| p4de.24xlarge | 8 | 640 GiB | 96 | 1152 GiB | 400 Gbit/s |
| p5.48xlarge | 8 | 640 GiB | 192 | 2 TiB | 3200 Gbit/s |
| p5e.48xlarge | 8 | 1128 GiB | 192 | 2 TiB | 3200 Gbit/s |
| p5en.48xlarge | 8 | 1128 GiB | 192 | 2 TiB | 3200 Gbit/s |
| p6-b200.48xlarge | 8 | 1440 GiB | 192 | 2 TiB | 100 Gbit/s |
| trn1.2xlarge | 1 | 32 GiB | 8 | 32 GiB | Bis zu 12,5 GBit/s |
| trn1.32xlarge | 16 | 512 GiB | 128 | 512 GiB | 800 Gbit/s |
| trn1n.32xlarge | 16 | 512 GiB | 128 | 512 GiB | 1600 Gbit/s |
| trn2.48xlarge | 16 | 1,5 TiB | 192 | 2 TiB | 3,2 Tbit/s |
| inf1.xlarge | 1 | 8 GiB | 4 | 8 GiB | Bis zu 25 Gbit/s |
| inf1.2xlarge | 1 | 8 GiB | 8 | 16 GiB | Bis zu 25 Gbit/s |
| inf1.6xlarge | 4 | 32 GiB | 24 | 48 GiB | 25 Gbit/s |
| inf1.24xlarge | 16 | 128 GiB | 96 | 192 GiB | 100 Gbit/s |
| inf2.xlarge | 1 | 32 GiB | 4 | 16 GiB | Bis zu 15 GBit/s |
| inf2.8xlarge | 1 | 32 GiB | 32 | 128 GiB | Bis zu 25 Gbit/s |
| inf2.24xlarge | 6 | 192 GiB | 96 | 384 GiB | 50 Gbit/s |
| inf2.48xlarge | 12 | 384 GiB | 192 | 768 GiB | 100 Gbit/s |
| dl1.24xlarge | 8 | 256 GiB | 96 | 768 GiB | 400 Gbit/s |
| dl2q.24xlarge | 8 | 128 GiB | 96 | 768 GiB | 100 Gbit/s |
**Anmerkung**
Für GPU-Jobs werden AWS Batch nur Instance-Typen unterstützt, die über NVIDIA GPUs verfügen. Die [https://aws.amazon.com/ec2/instance-types/g4/#Amazon_EC2_G4ad_instances](https://aws.amazon.com/ec2/instance-types/g4/#Amazon_EC2_G4ad_instances)Familie wird beispielsweise nicht für die GPU-Planung unterstützt. Sie können weiterhin [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 verwenden, AWS Batch indem Sie nur die vCPU- und Speicheranforderungen in der Auftragsdefinition definieren und dann direkt auf die Host-GPUs zugreifen, indem Sie [Benutzerdaten in einer Amazon EC2 EC2-Startvorlage](launch-templates.md#lt-user-data) mit einem rechneroptimierten AMI von Amazon ECS oder Amazon EKS oder einem benutzerdefinierten AMI für die Verwendung von AMD anpassen. GPUs
Instance-Typen, die eine ARM64 Architektur verwenden, werden für GPU-Jobs für benutzerdefinierte AMIs AWS Batch oder Amazon EC2 EC2-Benutzerdaten unterstützt, auf die GPUs durch benutzerdefinierten Code und Konfigurationen zugegriffen werden kann. Zum Beispiel die [https://aws.amazon.com/ec2/instance-types/g5g/](https://aws.amazon.com/ec2/instance-types/g5g/)Instance-Familie.
Der [ResourceRequirements-Parameter](job_definition_parameters.md#ContainerProperties-resourceRequirements) für die Jobdefinition gibt die Anzahl der an den Container GPUs anzuheften an. Diese Anzahl von GPUs ist für die Dauer dieses Auftrags für keinen anderen Job verfügbar, der auf dieser Instance ausgeführt wird. Alle Instance-Typen in einer Rechenumgebung, die GPU-Jobs ausführen`p3`, müssen zu den `g6` Instance-Familien `p4` `p5` `p6``g3`,`g3s`,`g4`,`g5`,,, oder gehören. Geschieht dies nicht, kann es sein, dass ein GPU-Job im `RUNNABLE` Status hängen bleibt.
Jobs, die das nicht verwenden, GPUs können auf GPU-Instanzen ausgeführt werden. Ihre Ausführung auf GPU-Instanzen kann jedoch mehr kosten als auf ähnlichen Nicht-GPU-Instanzen. Abhängig von der spezifischen vCPU, dem Arbeitsspeicher und der benötigten Zeit können diese Nicht-GPU-Jobs die Ausführung von GPU-Jobs blockieren.
**Topics**
+ [Erstellen Sie einen GPU-basierten Kubernetes Cluster auf Amazon EKS](create-gpu-cluster-eks.md)
+ [Erstellen Sie eine Amazon EKS-GPU-Auftragsdefinition](create-eks-gpu-job-definition.md)
+ [Führen Sie einen GPU-Job in Ihrem Amazon EKS-Cluster aus](run-gpu-job-eks-cluster.md)
# Erstellen Sie einen GPU-basierten Kubernetes Cluster auf Amazon EKS
Bevor Sie einen GPU-basierten Kubernetes Cluster auf Amazon EKS erstellen, müssen Sie die Schritte unter abgeschlossen haben. [Erste Schritte mit AWS Batch Amazon EKS](getting-started-eks.md) Beachten Sie außerdem Folgendes:
+ AWS Batch unterstützt Instance-Typen mit NVIDIA GPUs.
+ AWS Batch Wählt standardmäßig das Amazon EKS-beschleunigte AMI mit der Kubernetes Version aus, die Ihrer Amazon EKS-Cluster-Steuerebenenversion entspricht.
```
$ 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 verwaltet das NVIDIA GPU-Geräte-Plugin nicht in Ihrem Namen. Sie müssen dieses Plugin in Ihrem Amazon EKS-Cluster installieren und zulassen, dass es auf die AWS Batch Knoten abzielt. Weitere Informationen finden Sie unter [Enabling GPU Support in Kubernetes](https://github.com/NVIDIA/k8s-device-plugin#enabling-gpu-support-in-kubernetes) on GitHub.
Führen Sie die folgenden Befehle aus, um NVIDIA das Geräte-Plugin (`DaemonSet`) so zu konfigurieren, dass es auf die AWS Batch Knoten abzielt.
```
# 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
```
Es wird nicht empfohlen, rechenbasierte Workloads (CPU und Arbeitsspeicher) mit GPU-basierten Workloads in derselben Kombination aus Rechenumgebung und Jobwarteschlange zu kombinieren. Das liegt daran, dass Rechenaufträge GPU-Kapazität verbrauchen können.
Führen Sie die folgenden Befehle aus, um Jobwarteschlangen anzuhängen.
```
$ 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
```
# Erstellen Sie eine Amazon EKS-GPU-Auftragsdefinition
Derzeit `nvidia.com/gpu` wird nur unterstützt, und der von Ihnen festgelegte Ressourcenwert muss eine ganze Zahl sein. Sie können keine Bruchteile der GPU verwenden. Weitere Informationen finden Sie GPUs in der *KubernetesDokumentation* unter [Zeitplan](https://kubernetes.io/docs/tasks/manage-gpus/scheduling-gpus/).
Führen Sie die folgenden Befehle aus, um eine GPU-Auftragsdefinition für Amazon EKS zu registrieren.
```
$ 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
```
# Führen Sie einen GPU-Job in Ihrem Amazon EKS-Cluster aus
Die GPU-Ressource ist nicht komprimierbar. AWS Batch **erstellt eine Pod-Spezifikation für GPU-Jobs, bei der der Wert der **Anfrage dem Wert der Grenzwerte** entspricht.** Dies ist eine Kubernetes Anforderung.
Führen Sie die folgenden Befehle aus, um einen GPU-Job einzureichen.
```
$ 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"
}
```
# AWS Batch Jobs in einer Job-Warteschlange anzeigen
Sie können Ihre Jobs in anzeigen und filtern AWS Batch. Diese Funktion bietet die Möglichkeit, eine bestehende Auftragswarteschlange anzuzeigen und die zugehörigen Jobs nach einer von drei Optionen zu filtern.
Durch Suchen und Filtern können Jobs abgerufen werden, die sich nicht im Endstatus (`SUCCEEDED`oder`FAILED`) befinden. Sobald ein Job den Status „`SUCCEEDED`oder“ hat, sollten `FAILED` Sie ihn bis zu sieben Tage lang abrufen können. Sie können weiterhin die EventBridge Protokolle eines Jobs CloudWatch oder von Amazon einsehen.
Gehen Sie wie folgt vor, um alle Jobs in einer Job-Warteschlange in der AWS Batch Konsole aufzulisten. Verwenden Sie optional das Feld **Ergebnisse filtern**, um die Ergebnisse anhand der von Ihnen angegebenen Kriterien einzugrenzen.
1. Navigieren Sie zur [AWS Batch -Konsole](https://console.aws.amazon.com/batch/home).
1. Wählen Sie im Navigationsbereich **Jobs** aus.
1. Erweitern Sie die Dropdownliste **Job-Warteschlange** und wählen Sie die Job-Warteschlange aus, in der Sie suchen möchten.
**Anmerkung**
Sie können jeweils nur in einer Job-Warteschlange nach Jobs suchen.
1. Geben Sie im Feld **Ergebnisse filtern** Stichwörter ein, die in die Ergebnisse aufgenommen werden sollen. Sie können dieses Feld verwenden, um nach **Jobname**, **Status** oder **Job-ID** zu filtern. Je nach Eigenschaft müssen Sie möglicherweise zusätzliche Operatoren definieren, z. B. ist gleich (=) oder enthält (:).
**Anmerkung**
SageMaker Warteschlangen für Trainingsjobs unterstützen nur das Filtern nach **Jobname** und **Job-ID**
1. Wählen Sie **Search (Suchen)** aus.
# AWS Batch Suchen Sie in einer Job-Warteschlange nach Jobs
AWS Batch Mit der Jobsuche können Sie Ihre Job suchen und filtern. Diese Funktion bietet die Möglichkeit, in einer vorhandenen Jobwarteschlange zu suchen und deren Jobs zu filtern.
Durch Suchen und Filtern können Jobs abgerufen werden, die sich nicht im Endstatus (`SUCCEEDED`oder`FAILED`) befinden. Sobald ein Job den Status „`SUCCEEDED`oder“ hat, sollten `FAILED` Sie ihn bis zu sieben Tage lang abrufen können. Sie können weiterhin die EventBridge Protokolle eines Jobs CloudWatch oder von Amazon einsehen.
Verwenden Sie die **erweiterte Suchfunktion, um nach mehreren Kriterien gleichzeitig zu suchen**. Sie können beispielsweise einen oder alle der folgenden Filter verwenden: **Status**, **Datumsbereich** und **zusätzliche Kriterien** (z. B. einen Jobnamen, eine Jobdefinition oder eine Job-ID).
## AWS Batch Jobs suchen (AWS Konsole)
Gehen Sie wie folgt vor, um die Jobs in einer Auftragswarteschlange in der AWS Batch Konsole zu durchsuchen.
1. Navigieren Sie zur [AWS Batch -Konsole](https://console.aws.amazon.com/batch/home).
1. Wählen Sie im Navigationsbereich **Jobs** aus.
1. Aktivieren Sie die **erweiterte Suche**.
1. Erweitern Sie die Dropdownliste **Job-Warteschlange** und wählen Sie die Job-Warteschlange aus, in der Sie suchen möchten.
**Anmerkung**
Sie können jeweils nur in einer Job-Warteschlange nach Jobs suchen.
1. Für **Suchoptionen**:
1. In der Dropdownliste **Status** können Sie einen oder mehrere Status auswählen, nach denen gefiltert werden soll. Weitere Informationen erhalten Sie unter [Status der Job](job_states.md) und [Status des Serviceauftrags](service-job-status.md).
**Anmerkung**
Eltern von Array-Jobs werden darüber informiert, `PENDING` wenn ein untergeordneter Job aktualisiert wird, `RUNNABLE` und behalten ihren `PENDING` Status, solange untergeordnete Jobs ausgeführt werden. Um diese Jobs anzuzeigen, filtern Sie nach `PENDING` Status, bis alle untergeordneten Jobs einen Endstatus erreicht haben.
1. Wählen Sie **Datumsbereich**, um die Ergebnisse nach Datum und Uhrzeit zu filtern.
+ Wählen Sie den **Modus Relativ**, um nach Jobs zu suchen, deren Erstellungsdatum innerhalb eines Zeitbereichs liegt, der vom aktuellen Datum und der aktuellen Uhrzeit rückwärts gezählt wird.
+ Wählen Sie **den Modus Absolut**, um nach Jobs zu suchen, deren Erstellungsdatum innerhalb eines von Ihnen angegebenen Datums- und Zeitbereichs liegt.
1. Geben Sie im Feld **Zusätzliche Kriterien** Stichwörter ein, die in die Suchergebnisse aufgenommen werden sollen. Sie können dieses Feld beispielsweise verwenden, um nach **Jobname, Jobdefinition****, Job-ID** **oder **Share-ID**** zu suchen. Je nach Eigenschaft müssen Sie möglicherweise weitere Operatoren definieren, z. B. ist gleich (=) oder enthält (:).
**Anmerkung**
SageMaker Warteschlangen für Trainingsjobs unterstützen nur das Filtern nach **Jobname** und **Job-ID**
**Anmerkung**
Wenn Sie nach der **Share-ID** filtern, können Sie auch einen Jobstatus angeben. Dies ist eine Ausnahme von der Einschränkung, bei der andere Filter die Jobstatusfilterung ausschließen.
1. Wählen Sie **Search (Suchen)** aus.
## Suchen und filtern Sie AWS Batch Jobs (AWS CLI)
Gehen Sie wie folgt vor, um alle Jobs in einer Auftragswarteschlange mit dem aufzulisten AWS CLI. Verwenden Sie optional den Parameter **-filters**, um die Ergebnisse anhand der von Ihnen angegebenen Kriterien einzugrenzen.
------
#### [ Search job queue (AWS CLI) ]
Sie können den Befehl [list-jobs](https://docs.aws.amazon.com/cli/latest/reference/batch/list-jobs.html) verwenden, um eine Job-Warteschlange zu suchen und zu filtern.
Sie können beispielsweise eine Job-Warteschlange anhand des Jobnamens durchsuchen:
```
aws batch list-jobs \
--job-queue my-job-queue \
--filters name=JOB_NAME,values="my-job"
```
Jobs nach der gemeinsamen ID filtern:
```
aws batch list-jobs \
--job-queue my-job-queue \
--filters name=SHARE_IDENTIFIER,values="my-share"
```
Beim Filtern nach der Share-ID können Sie den Jobstatus angeben:
```
aws batch list-jobs \
--job-queue my-job-queue \
--job-status RUNNING \
--filters name=SHARE_IDENTIFIER,values="my-share"
```
Nehmen Sie im vorherigen Befehl die folgenden Änderungen vor:
+ *my-job-queue*Ersetzen Sie es durch den Namen Ihrer Job-Warteschlange.
+ *my-job*Ersetzen Sie es durch den Namen Ihres Jobs.
+ *my-share*Ersetzen Sie es durch die Share-ID, nach der Sie filtern möchten.
------
#### [ Search service job queue (AWS CLI) ]
Sie können den [list-service-jobs](https://docs.aws.amazon.com/cli/latest/reference/batch/list-service-jobs.html)Befehl verwenden, um eine Warteschlange für Serviceaufträge zu suchen und zu filtern.
Sie können beispielsweise eine Warteschlange für Serviceaufträge anhand des Auftragsnamens durchsuchen:
```
aws batch list-service-jobs \
--job-queue my-sm-queue \
--filters name=JOB_NAME,values="my-sm-job"
```
Serviceaufträge nach der gemeinsamen ID filtern:
```
aws batch list-service-jobs \
--job-queue my-sm-queue \
--filters name=SHARE_IDENTIFIER,values="my-share"
```
Nehmen Sie im vorherigen Befehl die folgenden Änderungen vor:
+ *my-sm-queue*Ersetzen Sie es durch den Namen Ihrer Service-Job-Warteschlange.
+ *my-sm-job*Ersetzen Sie es durch den Namen Ihres Serviceauftrags.
+ *my-share*Ersetzen Sie es durch die Share-ID, nach der Sie filtern möchten.
------
# Netzwerkmodi für AWS Batch Jobs
In der folgenden Tabelle werden die Netzwerkmodi und die typische Verwendung für AWS Batch Jobtypen beschrieben. Weitere Informationen zu Überlegungen und Verhaltensweisen finden Sie unter den Links in der Spalte „Jobtyp“.
| Aufgabentyp | Unterstützte Netzwerkmodi | Typische Verwendung |
| --- | --- | --- |
| [ECS-EC2 einfacher Job](jobs.md) | host | Wird für die am höchsten skalierbaren, peinlich parallel Batch-Workloads verwendet, die nur den Ausgang zu einer in Compute Environment definierten VPC erfordern. |
| [ECS-EC2-Paralleljob mit mehreren Knoten](multi-node-parallel-jobs.md) | awsvpc | Wird für eng gekoppelte, verteilte Workloads mit mehreren Hosts (Knoten) verwendet, die als einzelner Job mit koordinierter Kommunikation zwischen Task-Knoten modelliert werden. |
| [ECS-Fargate einfache Aufgabe](when-to-use-fargate.md) | awsvpc | Echt serverlos für peinlich parallel Batch-Workloads. Typischerweise das Jobmodell mit den niedrigsten Gesamtbetriebskosten und der höchsten Containerisolierung. |
| [EKS-EC2, einfacher Job](eks-jobs.md) | Host und Pod | Wird für hoch skalierbare, peinlich parallel Batch-Workloads verwendet, die nur einen Ausgang zu einer in Compute Environment definierten VPC erfordern. Die Standardeinstellung ist Host-Netzwerk. |
| [EKS-EC2-Paralleljob mit mehreren Knoten](mnp-eks-jobs.md) | Host und Pod | Wird für eng gekoppelte, verteilte Workloads mit mehreren Hosts (Knoten) verwendet, die als ein einziger Job mit koordinierter Kommunikation zwischen Pod-Knoten modelliert werden. Die Standardeinstellung ist Host-Netzwerke. |
# AWS Batch Jobprotokolle in CloudWatch Logs anzeigen
Sie können [Ihre AWS Batch Jobs so konfigurieren](using_cloudwatch_logs.md), dass Protokollinformationen an Amazon CloudWatch Logs gesendet werden. Auf diese Weise können Sie verschiedene Protokolle Ihrer Jobs bequem an einem zentralen Ort einsehen. Weitere Informationen finden Sie unter [CloudWatch Logs verwenden mit AWS Batch](using_cloudwatch_logs.md).
Sie können auch **Job-Logs** in der AWS Batch Konsole verwenden, um einen AWS Batch Job zu überwachen oder Fehler zu beheben.
1. Öffnen Sie die [AWS Batch -Konsole](https://console.aws.amazon.com/batch/home).
1. Wählen Sie **Jobs (Aufträge)** aus. Ausführlichere Informationen zum Sortieren und Filtern von Aufträgen in der Auftragswarteschlange finden Sie unter [AWS Batch Jobs in einer Job-Warteschlange anzeigen](view-jobs.md) und [Suchen Sie in einer Jobwarteschlange nach Jobs](searching-filtering-jobs.md)
1. Wählen Sie **Job Job-Warteschlange** die gewünschte Job-Warteschlange aus.
**Tipp**
Befinden sich mehrere Jobs in der Auftragswarteschlange, können Sie **Suchen und Filtern** aktivieren, um einen Job schneller zu finden. Weitere Informationen finden Sie unter [AWS Batch Suchen Sie in einer Job-Warteschlange nach Jobs](searching-filtering-jobs.md).
1. Wählen Sie unter **Status** den gewünschten Auftragsstatus aus.
1. Wählen Sie den gewünschten Job aus und die **Detailseite** wird geöffnet.
1. Scrollen Sie auf der Seite „**Details**“ nach unten zum **Namen des Protokollstreams** und wählen Sie den Link aus. Der Link öffnet die Amazon CloudWatch Logs-Seite für den Job.
1. (Optional) Wenn Sie die Protokolle zum ersten Mal einsehen, werden Sie möglicherweise um eine Autorisierung gebeten.
Geben Sie für **Autorisierung erforderlich** ein und wählen Sie dann **Autorisieren **OK****, um CloudWatch Amazon-Gebühren zu akzeptieren.
**Anmerkung**
Um Ihre Autorisierung für CloudWatch Gebühren zu widerrufen:
Wählen Sie im linken Navigationsbereich die Option **Berechtigungen** aus.
Wählen Sie für **Job-Logs** die Option **Bearbeiten** aus.
Deaktivieren Sie das CloudWatch Kontrollkästchen **Batch zur Verwendung autorisieren**.
Wählen Sie **Änderungen speichern ** aus.
# Überprüfen Sie die AWS Batch Jobinformationen
Sie können AWS Batch Jobinformationen wie Status, Jobdefinition und Containerinformationen überprüfen.
1. Öffnen Sie die [AWS Batch -Konsole](https://console.aws.amazon.com/batch/home).
1. Wählen Sie **Jobs (Aufträge)** aus.
1. Wählen Sie **Job Job-Warteschlange** die gewünschte Job-Warteschlange aus.
**Tipp**
Wenn sich mehrere Jobs in der Auftragswarteschlange befinden, können Sie **Suchen und Filtern** aktivieren, um einen Job schneller zu finden. Weitere Informationen finden Sie unter [AWS Batch Suchen Sie in einer Job-Warteschlange nach Jobs](searching-filtering-jobs.md).
1. Wählen Sie den gewünschten Job aus.
**Anmerkung**
Sie können auch das AWS Command Line Interface (AWS CLI) verwenden, um Details zu einem AWS Batch Job anzuzeigen. Weitere Informationen finden Sie unter [describe-jobs](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/batch/describe-jobs.html) in der [AWS CLI Befehlsreferenz](https://docs.aws.amazon.com/cli/latest/reference/).