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.
# Rechenumgebungen für AWS Batch
Job-Warteschlangen werden einer oder mehreren Rechenumgebungen zugeordnet. Rechenumgebungen enthalten die Amazon ECS-Container-Instances, die zur Ausführung von containerisierten Batch-Jobs verwendet werden. Eine bestimmte Rechenumgebung kann auch einer oder mehreren Auftragswarteschlangen zugeordnet werden. Innerhalb einer Job-Warteschlange haben die zugehörigen Rechenumgebungen jeweils eine Reihenfolge, anhand derer der Scheduler bestimmt, wo Jobs, die zur Ausführung bereit sind, ausgeführt werden sollen. Wenn die erste Rechenumgebung den Status hat `VALID` und über verfügbare Ressourcen verfügt, wird der Job für eine Container-Instance innerhalb dieser Rechenumgebung geplant. Wenn die erste Rechenumgebung den Status hat `INVALID` oder keine geeignete Rechenressource bereitstellen kann, versucht der Scheduler, den Job in der nächsten Rechenumgebung auszuführen.
**Topics**
+ [Verwaltete Computerumgebungen](managed_compute_environments.md)
+ [Nicht verwaltete Computerumgebungen](unmanaged_compute_environments.md)
+ [Erstellen Sie eine Rechenumgebung](create-compute-environment.md)
+ [Aktualisieren Sie eine Rechenumgebung in AWS Batch](updating-compute-environments.md)
+ [Ressource berechnen AMIs](compute_resource_AMIs.md)
+ [Verwenden Sie Amazon EC2 EC2-Startvorlagen mit AWS Batch](launch-templates.md)
+ [Konfiguration des Instanz-Metadatendienstes (IMDS)](imds-compute-environments.md)
+ [EC2 Konfigurationen](ec2-configurations.md)
+ [Strategien zur Zuweisung von Instance-Typen für AWS Batch](allocation-strategies.md)
+ [Speicherverwaltung für Rechenressourcen](memory-management.md)
+ [Fargate-Computerumgebungen](fargate.md)
+ [Amazon EKS-Rechenumgebungen](eks.md)
# Verwaltete Computerumgebungen
Sie können eine verwaltete Rechenumgebung verwenden, um die Kapazität und die Instanztypen der Rechenressourcen innerhalb der Umgebung zu AWS Batch verwalten. Dies basiert auf den Spezifikationen für Rechenressourcen, die Sie bei der Erstellung der Rechenumgebung definieren. Sie können wählen, ob Sie Amazon EC2 On-Demand-Instances und Amazon EC2-Spot-Instances verwenden möchten. Oder Sie können alternativ die Kapazität von Fargate und Fargate Spot in Ihrer verwalteten Computerumgebung verwenden. Wenn Sie Spot-Instances verwenden, können Sie optional einen Höchstpreis festlegen. Auf diese Weise werden Spot-Instances nur gestartet, wenn der Spot-Instance-Preis unter einem bestimmten Prozentsatz des On-Demand-Preises liegt.
**Wichtig**
Fargate Spot-Instances werden auf Windows containers on AWS Fargate nicht unterstützt. Eine Job-Warteschlange wird blockiert, wenn ein FargateWindows Job an eine Job-Warteschlange weitergeleitet wird, die nur Fargate Spot-Computerumgebungen verwendet.
**Wichtig**
AWS Batch erstellt und verwaltet mehrere AWS Ressourcen in Ihrem Namen und innerhalb Ihres Kontos, darunter Amazon EC2 Launch Templates, Amazon EC2 Auto Scaling Groups, Amazon EC2 Spot Fleets und Amazon ECS Clusters. Diese verwalteten Ressourcen sind speziell konfiguriert, um einen optimalen Betrieb zu gewährleisten. AWS Batch Die manuelle Änderung dieser AWS Batch verwalteten Ressourcen kann, sofern nicht ausdrücklich in der AWS Batch Dokumentation angegeben, zu unerwartetem Verhalten führen, einschließlich `INVALID` Rechenumgebungen, suboptimalem Verhalten bei der Instanzskalierung, verzögerter Workload-Verarbeitung oder unerwarteten Kosten. Diese manuellen Änderungen können vom Service nicht deterministisch unterstützt werden. AWS Batch Verwenden Sie immer den Support AWS Batch APIs oder die AWS Batch Konsole, um Ihre Computerumgebungen zu verwalten.
Zu den nicht unterstützten manuellen Änderungen gehören das Ausführen Ihrer eigenen Amazon ECS-Aufgaben oder -Services auf AWS Batch-verwalteten Amazon ECS-Clustern oder das Starten zusätzlicher Prozesse, Daemons oder Services direkt auf -verwalteten Instances. AWS Batch AWS Batch übernimmt die volle Kontrolle über die Rechenressourcen in einer verwalteten Rechenumgebung und kann jederzeit Instances beenden, Aufgaben beenden oder den Cluster skalieren. Alle Workloads, die Sie außerhalb von AWS Batch Job-Übermittlungen auf diesen verwalteten Ressourcen ausführen, können ohne Vorwarnung unterbrochen werden. Das Ausführen von AWS Batch AWS Batch Nicht-Workloads auf verwalteten Clustern und Instances kann auch die AWS Batch Jobplanung und Instanzskalierung beeinträchtigen.
Verwaltete Rechenumgebungen starten Amazon EC2 EC2-Instances in der VPC und den Subnetzen, die Sie angeben, und registrieren sie dann bei einem Amazon ECS-Cluster. Die Amazon EC2 EC2-Instances benötigen externen Netzwerkzugriff, um mit dem Amazon ECS-Serviceendpunkt zu kommunizieren. Einige Subnetze stellen Amazon EC2 EC2-Instances keine öffentlichen IP-Adressen zur Verfügung. Wenn Ihre Amazon EC2 EC2-Instances keine öffentliche IP-Adresse haben, müssen sie Network Address Translation (NAT) verwenden, um diesen Zugriff zu erhalten. Weitere Informationen finden Sie unter [NAT-Gateways](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) im *Benutzerhandbuch für Amazon VPC*. Weitere Informationen zum Erstellen einer VPC finden Sie unter[Erstellen einer Virtual Private Cloud](create-public-private-vpc.md).
Standardmäßig verwenden AWS Batch verwaltete Computerumgebungen eine aktuelle, genehmigte Version des für Amazon ECS optimierten AMI für Rechenressourcen. Möglicherweise möchten Sie jedoch aus verschiedenen Gründen Ihr eigenes AMI erstellen, das Sie für Ihre verwalteten Computerumgebungen verwenden können. Weitere Informationen finden Sie unter [Ressource berechnen AMIs](compute_resource_AMIs.md).
**Anmerkung**
AWS Batch aktualisiert das AMIs in einer Computerumgebung nicht automatisch, nachdem es erstellt wurde. Beispielsweise aktualisiert es die AMIs in Ihrer Computerumgebung nicht, wenn eine neuere Version des für Amazon ECS optimierten AMI veröffentlicht wird. Sie sind für die Verwaltung des Gastbetriebssystems verantwortlich. Dazu gehören alle Updates und Sicherheitspatches. Sie sind auch für jede zusätzliche Anwendungssoftware oder Hilfsprogramme verantwortlich, die Sie auf den Rechenressourcen installieren. Es gibt zwei Möglichkeiten, ein neues AMI für Ihre AWS Batch Jobs zu verwenden. Die ursprüngliche Methode besteht darin, die folgenden Schritte auszuführen:
Erstellen Sie eine neue Datenverarbeitungsumgebung mit dem neuen AMI.
Fügen Sie die Datenverarbeitungsumgebung einer vorhandenen Auftragswarteschlange hinzu.
Entfernen Sie die alte Datenverarbeitungsumgebung aus Ihrer Auftragswarteschlange.
Löschen Sie die alte Datenverarbeitungsumgebung.
Im April 2022 AWS Batch wurde erweiterte Unterstützung für die Aktualisierung von Computerumgebungen hinzugefügt. Weitere Informationen finden Sie unter [Aktualisieren Sie eine Rechenumgebung in AWS Batch](updating-compute-environments.md). Um die erweiterte Aktualisierung von Rechenumgebungen für Updates zu nutzen AMIs, folgen Sie diesen Regeln:
Legen Sie den Parameter service role ([https://docs.aws.amazon.com/batch/latest/APIReference/API_CreateComputeEnvironment.html#Batch-CreateComputeEnvironment-request-serviceRole](https://docs.aws.amazon.com/batch/latest/APIReference/API_CreateComputeEnvironment.html#Batch-CreateComputeEnvironment-request-serviceRole)) entweder nicht fest oder legen Sie ihn auf die **AWSServiceRoleForBatch**dienstverknüpfte Rolle fest.
Setzen Sie den Parameter Allocation Strategy ([https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResource.html#Batch-Type-ComputeResource-allocationStrategy](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResource.html#Batch-Type-ComputeResource-allocationStrategy)) auf`BEST_FIT_PROGRESSIVE`, `SPOT_CAPACITY_OPTIMIZED` oder`SPOT_PRICE_CAPACITY_OPTIMIZED`.
Stellen Sie den Parameter Update auf die neueste Image-Version ([https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-updateToLatestImageVersion](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-updateToLatestImageVersion)) auf ein`true`.
Geben Sie keine AMI-ID in [https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-imageId](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-imageId), [https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html#Batch-Type-Ec2Configuration-imageIdOverride](https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html#Batch-Type-Ec2Configuration-imageIdOverride)(in [https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html)) oder in der Startvorlage ([https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-launchTemplate](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-launchTemplate)) an. AWS Batch Wählt in diesem Fall das neueste Amazon ECS-optimierte AMI aus, das AWS Batch zum Zeitpunkt der Initiierung des Infrastruktur-Updates unterstützt wird. Alternativ können Sie die AMI-ID in den `imageIdOverride` Parametern `imageId` oder oder die durch die `LaunchTemplate` Eigenschaften identifizierte Startvorlage angeben. Wenn Sie eine dieser Eigenschaften ändern, wird ein Infrastruktur-Update gestartet. Wenn die AMI-ID in der Startvorlage angegeben ist, kann sie nicht durch die Angabe einer AMI-ID in den `imageIdOverride` Parametern `imageId` oder ersetzt werden. Sie kann nur durch Angabe einer anderen Startvorlage ersetzt werden. Oder, wenn die Version der Startvorlage auf `$Default` oder festgelegt ist`$Latest`, indem Sie entweder eine neue Standardversion für die Startvorlage festlegen (falls vorhanden`$Default`) oder indem Sie der Startvorlage eine neue Version hinzufügen (falls vorhanden`$Latest`).
Wenn diese Regeln befolgt werden, führt jedes Update, das ein Infrastruktur-Update startet, dazu, dass die AMI-ID erneut ausgewählt wird. Wenn die [https://docs.aws.amazon.com/batch/latest/APIReference/API_LaunchTemplateSpecification.html#Batch-Type-LaunchTemplateSpecification-version](https://docs.aws.amazon.com/batch/latest/APIReference/API_LaunchTemplateSpecification.html#Batch-Type-LaunchTemplateSpecification-version)Einstellung in der Startvorlage ([https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-launchTemplate](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-launchTemplate)) auf `$Latest` oder gesetzt ist`$Default`, wird die neueste Version oder Standardversion der Startvorlage zum Zeitpunkt des Infrastruktur-Updates ausgewertet, auch wenn sie nicht aktualisiert [https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-launchTemplate](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-launchTemplate)wurde.
## Überlegungen bei der Erstellung parallel Jobs mit mehreren Knoten
AWS Batch empfiehlt, dedizierte Rechenumgebungen für die Ausführung von Multi-Node-Parallel-Jobs (MNP) und Nicht-MNP-Jobs zu erstellen. Dies liegt an der Art und Weise, wie Rechenkapazität in Ihrer verwalteten Computerumgebung geschaffen wird. Wenn Sie beim Erstellen einer neuen verwalteten Rechenumgebung einen `minvCpu` Wert größer als Null angeben, AWS Batch wird ein Instanzpool erstellt, der nur für Nicht-MNP-Jobs verwendet werden kann. Wenn ein parallel Auftrag mit mehreren Knoten eingereicht wird, wird neue Instanzkapazität für die Ausführung der parallel Jobs mit mehreren Knoten AWS Batch erstellt. In Fällen, in denen sowohl Einzelknoten- als auch Paralleljobs mit mehreren Knoten in derselben Rechenumgebung ausgeführt werden, in der entweder ein `minvCpus` oder `maxvCpus` festgelegt ist, AWS Batch wird, falls die erforderlichen Rechenressourcen nicht verfügbar sind, bis die aktuellen Jobs abgeschlossen sind, bevor die Rechenressourcen erstellt werden, die für die Ausführung der neuen Jobs erforderlich sind.
# Nicht verwaltete Computerumgebungen
In einer nicht verwalteten Computerumgebung verwalten Sie Ihre eigenen Rechenressourcen. AWS Batch unterstützt nicht verwaltete Rechenumgebungen sowohl für Amazon ECS als auch für Amazon EKS, sodass Sie die Kontrolle über Ihre Infrastruktur behalten und gleichzeitig die Jobplanungsfunktionen von Batch nutzen können.
**Anmerkung**
AWS Fargate-Ressourcen werden in nicht verwalteten Computerumgebungen nicht unterstützt.
Für nicht verwaltete Amazon ECS-Rechenumgebungen müssen Sie sicherstellen, dass das AMI, das Sie für Ihre Rechenressourcen verwenden, der AMI-Spezifikation für Amazon ECS-Container-Instances entspricht. Weitere Informationen erhalten Sie unter [AMI-Spezifikation für Datenverarbeitungsressourcen](batch-ami-spec.md) und [Tutorial: Erstellen Sie ein Compute-Ressourcen-AMI](create-batch-ami.md).
Nachdem Sie Ihre nicht verwaltete Rechenumgebung erstellt haben, verwenden Sie den [DescribeComputeEnvironments](https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeComputeEnvironments.html)API-Vorgang, um die Details der Rechenumgebung anzuzeigen. Suchen Sie den Amazon ECS-Cluster, der mit der Umgebung verknüpft ist, und starten Sie dann Ihre Container-Instances manuell in diesem Amazon ECS-Cluster.
Der folgende AWS CLI Befehl stellt auch den Amazon ECS-Cluster-ARN bereit.
```
$ aws batch describe-compute-environments \
--compute-environments unmanagedCE \
--query "computeEnvironments[].ecsClusterArn"
```
Weitere Informationen finden Sie unter [Starten einer Amazon ECS-Container-Instance](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/launch_container_instance.html) im *Amazon Elastic Container Service-Entwicklerhandbuch*. Wenn Sie Ihre Rechenressourcen starten, geben Sie den Amazon ECS-Cluster-ARN an, den die Ressourcen mit den folgenden Amazon EC2 EC2-Benutzerdaten registrieren. *ecsClusterArn*Ersetzen Sie durch den Cluster-ARN, den Sie mit dem vorherigen Befehl erhalten haben.
```
#!/bin/bash
echo "ECS_CLUSTER=ecsClusterArn" >> /etc/ecs/ecs.config
```
In einer nicht verwalteten Amazon EKS-Rechenumgebung verwalten Sie Ihre eigenen Kubernetes-Knoten und kümmern sich gleichzeitig um die Planung und AWS Batch Platzierung von Jobs. Es ermöglicht Ihnen, Ihre Kubernetes-Infrastruktur im Hinblick auf Sicherheits-, Compliance- oder Betriebsanforderungen direkt zu kontrollieren. Sie sind für die Bereitstellung und Konfiguration Ihrer Amazon EKS-Knoten verantwortlich und lassen AWS Batch sich gleichzeitig in Ihren vorhandenen Amazon EKS-Cluster integrieren, um Jobs zu planen und auszuführen.
Weitere Informationen finden Sie unter [Tutorial: Erstellen einer nicht verwalteten Rechenumgebung mithilfe von Amazon EKS-Ressourcen](https://docs.aws.amazon.com/batch/latest/userguide/create-compute-environment-unmanaged-eks.html).
# Erstellen Sie eine Rechenumgebung
Bevor Sie Jobs ausführen können AWS Batch, müssen Sie eine Rechenumgebung erstellen. Sie können eine verwaltete Rechenumgebung erstellen, in der die Amazon EC2 EC2-Instances oder AWS Fargate-Ressourcen innerhalb der Umgebung auf der Grundlage Ihrer Spezifikationen AWS Batch verwaltet werden. Alternativ können Sie auch eine nicht verwaltete Rechenumgebung erstellen, in der Sie die Amazon EC2 EC2-Instance-Konfiguration innerhalb der Umgebung verwalten.
**Wichtig**
Fargate Spot-Instances werden in den folgenden Szenarien nicht unterstützt:
Windows containers on AWS Fargate
In diesen Szenarien wird eine Job-Warteschlange blockiert, wenn ein Job an eine Job-Warteschlange weitergeleitet wird, die nur Fargate Spot-Computerumgebungen verwendet.
**Topics**
+ [Tutorial: Erstellen Sie eine verwaltete Rechenumgebung mit Fargate-Ressourcen](create-compute-environment-fargate.md)
+ [Tutorial: Erstellen Sie eine verwaltete Rechenumgebung mithilfe von Amazon EC2 EC2-Ressourcen](create-compute-environment-managed-ec2.md)
+ [Tutorial: Erstellen Sie eine nicht verwaltete Rechenumgebung mithilfe von Amazon EC2 EC2-Ressourcen](create-compute-environment-unmanaged-ec2.md)
+ [Tutorial: Erstellen Sie eine verwaltete Rechenumgebung mithilfe von Amazon EKS-Ressourcen](create-compute-environment-managed-eks.md)
+ [Tutorial: Erstellen Sie eine nicht verwaltete Rechenumgebung mithilfe von Amazon EKS-Ressourcen](create-compute-environment-unmanaged-eks.md)
+ [Ressource: Vorlage für die Rechenumgebung](compute-environment-template.md)
+ [Instanztyp: Tabelle berechnen](instance-type-compute-table.md)
# Tutorial: Erstellen Sie eine verwaltete Rechenumgebung mit Fargate-Ressourcen
Gehen Sie wie folgt vor, um mithilfe von AWS Fargate Ressourcen eine verwaltete Rechenumgebung zu erstellen.
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 **Datenverarbeitungs-Umgebungen** aus.
1. Wählen Sie **Erstellen** aus.
1. Konfigurieren Sie die Rechenumgebung.
**Anmerkung**
Rechenumgebungen für Windows containers on AWS Fargate Jobs müssen mindestens eine vCPU haben.
1. Wählen **Sie für die Konfiguration der Rechenumgebung** **Fargate** aus.
1. Geben Sie unter **Name** einen eindeutigen Namen für Ihre Rechenumgebung an. Der Name kann bis zu 128 Zeichen lang sein. Er kann Groß- und Kleinbuchstaben, Zahlen, Bindestriche (-) und Unterstriche (\$1) enthalten.
1. Wählen Sie für die **Servicerolle** die dienstbezogene Rolle aus, mit der der AWS Batch Dienst in Ihrem Namen die erforderlichen AWS API-Operationen aufrufen kann. Wählen Sie zum Beispiel aus **AWSServiceRoleForBatch**. Weitere Informationen finden Sie unter [Verwenden von serviceverknüpften Rollen für AWS Batch](using-service-linked-roles.md).
1. (Optional) Erweitern Sie **Tags**. Um einen Tag hinzuzufügen, wählen Sie **Add tag (Tag hinzufügen)**. Geben Sie dann einen **Schlüsselnamen** und optional einen **Wert** ein. Wählen Sie **Add tag**.
1. Wählen Sie „**Nächste Seite“**.
1. Gehen Sie im Abschnitt **Instanzkonfiguration wie** folgt vor:
1. (Optional) Aktivieren **Sie Fargate Spot, um Fargate Spot-Kapazität verwenden** zu können. Informationen zu Fargate Spot finden Sie unter [Amazon EC2 Spot verwenden und Fargate\$1SPOT](https://docs.aws.amazon.com/AmazonECS/latest/bestpracticesguide/ec2-and-fargate-spot.html).
1. Wählen Sie für **Maximum v** die maximale Anzahl von v ausCPUs, auf CPUs die Ihre Rechenumgebung skaliert werden kann, unabhängig von der Nachfrage in der Jobwarteschlange.
1. Wählen Sie „**Nächste Seite“**.
1. Konfigurieren Sie das Netzwerk.
**Wichtig**
Datenverarbeitungsressourcen benötigen einen externen Netzwerkzugriff, um mit dem Amazon-ECS-Service-Endpunkt zu kommunizieren. Dies kann über einen Schnittstellen-VPC-Endpunkt oder über Ihre Datenverarbeitungsressourcen mit öffentlichen IP-Adressen sein.
Weitere Informationen zu Interface-VPC-Endpunkten finden Sie unter [Amazon-ECS-Schnittstellen-VPC-Endpunkte (AWS PrivateLink)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/vpc-endpoints.html) im *Amazon Elastic Container Service-Entwicklerhandbuch*.
Wenn Sie keinen Schnittstellen-VPC-Endpunkt konfiguriert haben und Ihre Datenverarbeitungsressourcen keine öffentlichen IP-Adressen haben, müssen Sie Netzwerkadressübersetzung (Network Address Translation, NAT) verwenden, um diesen Zugriff zur Verfügung zu stellen. Weitere Informationen finden Sie unter [NAT-Gateways](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) im *Amazon VPC-Benutzerhandbuch*. Weitere Informationen finden Sie unter [Erstellen einer VPC](create-a-vpc.md).
1. Wählen Sie für **Virtual Private Cloud (VPC) ID** eine VPC aus, in der Sie Ihre Instances starten möchten.
1. Wählen Sie für **Subnetze** die zu verwendenden Subnetze aus. Standardmäßig sind alle Subnetze innerhalb der ausgewählten VPC verfügbar.
**Anmerkung**
AWS Batch on Fargate unterstützt derzeit keine Local Zones. Weitere Informationen finden Sie unter [Amazon ECS-Cluster in Local Zones, Wavelength Zones und AWS Outposts](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/cluster-regions-zones.html#clusters-local-zones) im *Amazon Elastic Container Service Developer Guide*.
1. Wählen Sie für **Sicherheitsgruppen** eine Sicherheitsgruppe aus, um sie Ihren Instances anzufügen. Standardmäßig ist die Standardsicherheitsgruppe für Ihre VPC ausgewählt.
1. Wählen Sie **Nächste Seite.**
1. **Überprüfen Sie** die Konfigurationsschritte zur Überprüfung. Wenn Sie Änderungen vornehmen müssen, wählen Sie **Edit** (Bearbeiten). Wenn Sie fertig sind, wählen Sie **Create Compute Environment** aus.
# Tutorial: Erstellen Sie eine verwaltete Rechenumgebung mithilfe von Amazon EC2 EC2-Ressourcen
Gehen Sie wie folgt vor, um eine verwaltete Rechenumgebung mithilfe von Amazon Elastic Compute Cloud (Amazon EC2) -Ressourcen zu erstellen.
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 **Environments (Umgebungen)** aus.
1. Wählen Sie **Umgebung erstellen** und dann **Umgebung berechnen** aus.
1. Konfigurieren Sie die Umgebung.
1. Wählen Sie für die **Konfiguration der Rechenumgebung** **Amazon Elastic Compute Cloud (Amazon EC2)**.
1. **Wählen Sie als **Orchestrierungstyp** die Option Verwaltet aus.**
1. Geben Sie unter **Name** einen eindeutigen Namen für Ihre Rechenumgebung an. Der Name kann bis zu 128 Zeichen lang sein. Er kann Groß- und Kleinbuchstaben, Zahlen, Bindestriche (-) und Unterstriche (\$1) enthalten.
1. Wählen Sie für die **Servicerolle** die serviceverknüpfte Rolle aus, mit der der AWS Batch Dienst in Ihrem Namen die erforderlichen AWS API-Operationen aufrufen kann. Wählen Sie zum Beispiel aus **AWSServiceRoleForBatch**. Weitere Informationen finden Sie unter [Verwenden von serviceverknüpften Rollen für AWS Batch](using-service-linked-roles.md).
1. Wählen Sie im Feld **Instance-Role (Instance-Rolle)** ein neues Instance-Profil aus oder verwenden Sie ein bestehendes Instance-Profil, bei dem die erforderlichen IAM-Berechtigungen angefügt sind. Dieses Instance-Profil ermöglicht es den Amazon ECS-Container-Instances, die für Ihre Rechenumgebung erstellt wurden, die erforderlichen AWS API-Operationen in Ihrem Namen aufzurufen. Weitere Informationen finden Sie unter [Amazon ECS-Instance-Rolle](instance_IAM_role.md). Wenn Sie ein neues Instance-Profil erstellen, wird die erforderliche Rolle (`ecsInstanceRole`) für Sie erstellt.
1. (Optional) Erweitern Sie **Tags**.
1. (Optional) Wählen Sie für **EC2-Tags** **Tag hinzufügen** aus, um Ressourcen, die in der Rechenumgebung gestartet werden, ein Tag hinzuzufügen. Geben Sie dann einen **Schlüsselnamen** und optional einen **Wert** ein. Wählen Sie **Add tag**.
1. (Optional) Wählen Sie für **Tags** die Option **Tag hinzufügen** aus. Geben Sie dann einen **Schlüsselnamen** und optional einen **Wert** ein. Wählen Sie **Add tag**.
Weitere Informationen finden Sie unter [Kennzeichnen Sie Ihre AWS Batch Ressourcen](using-tags.md).
1. Wählen Sie **Weiter** aus.
1. Gehen Sie im Abschnitt **Instanzkonfiguration wie** folgt vor:
1. (Optional) **Aktivieren Sie unter Verwendung von Spot-Instances** die Option Spot. Weitere Informationen finden Sie unter [Spot-Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html).
1. (Nur Spot) Wählen Sie für den **On-Demand-Preis von maximal%** den maximalen Prozentsatz aus, den ein Spot-Instance-Preis im Vergleich zum On-Demand-Preis für diesen Instance-Typ vor dem Start der Instances betragen kann. Wenn Ihr Höchstpreis beispielsweise 20% beträgt, muss der Spot-Preis weniger als 20% des aktuellen On-Demand-Preises für diese EC2-Instance betragen. Sie zahlen immer nur den niedrigsten (Markt-) Preis und niemals mehr als Ihren maximalen Prozentsatz. Wenn Sie dieses Feld leer lassen, ist der Standardwert 100 % des On-Demand-Preises.
1. (Nur Spot) Wählen Sie für die **Spot-Flottenrolle** eine bestehende Amazon EC2 Spot Fleet IAM-Rolle aus, die Sie auf Ihre Spot-Computerumgebung anwenden möchten. Wenn Sie noch keine bestehende Amazon EC2 Spot Fleet IAM-Rolle haben, müssen Sie zuerst eine erstellen. Weitere Informationen finden Sie unter [Rolle der Amazon EC2-Spotflotte](spot_fleet_IAM_role.md).
**Wichtig**
Um Ihre Spot-Instances bei der Erstellung zu taggen, muss Ihre Amazon EC2 Spot Fleet IAM-Rolle die neuere von **Amazon EC2 SpotFleetTaggingRole verwaltete Richtlinie** verwenden. Die von **Amazon EC2 SpotFleetRole** verwaltete Richtlinie verfügt nicht über die erforderlichen Berechtigungen, um Spot-Instances zu taggen. Weitere Informationen erhalten Sie unter [Spot-Instances wurden bei der Erstellung nicht markiert](spot-instance-no-tag.md) und [Markieren Ihrer -Ressourcen mit Tags (Markierungen)](tag-resources.md).
1. Wählen Sie für **Minimum v CPUs** die Mindestanzahl von v ausCPUs , die Ihre Rechenumgebung unabhängig von der Nachfrage in der Job-Warteschlange beibehält.
1. Wählen Sie für **CPUsDesired v** die Anzahl von v ausCPUs , mit der Ihre Rechenumgebung gestartet wird. Wenn der Bedarf an Auftragswarteschleifen steigt, AWS Batch können Sie die gewünschte Anzahl von vCPUs in Ihrer Rechenumgebung erhöhen und EC2-Instances hinzufügen, bis zum Höchstwert von V. CPUs Bei sinkender Nachfrage AWS Batch kann die gewünschte Anzahl von v CPUs in Ihrer Rechenumgebung verringert und Instanzen bis auf das Minimum v entfernt werden. CPUs
1. Wählen Sie für **Maximum v** die maximale Anzahl von v ausCPUs, auf CPUs die Ihre Rechenumgebung skaliert werden kann, unabhängig von der Nachfrage in der Jobwarteschlange.
1. (Optional) Wählen Sie für **Verzögerung beim Herunterskalieren (Minuten)** die Mindestdauer (in Minuten) aus, nach der Instanzen nach Abschluss ihrer Jobs in der Rechenumgebung AWS Batch weiterlaufen.
1. Wählen Sie **unter Zulässige Instance-Typen** die Amazon EC2 EC2-Instance-Typen aus, die gestartet werden können. Sie können Instance-Familien angeben, um jeden beliebigen Instance-Typ innerhalb dieser Familien zu starten (z. B.`c5`,`c5n`, oder`p3`). Sie können auch bestimmte Größen innerhalb einer Familie angeben (z. B.`c5.8xlarge`). Instanztypen aus Metall gehören nicht zu den Instanzfamilien. Beinhaltet zum Beispiel `c5` nicht`c5.metal`.
AWS Batch kann den Instanztyp für Sie auswählen, wenn Sie eine der folgenden Optionen wählen:
+ `optimal`um Instance-Typen (aus den`c4`,, `m4` `r4` `c5``m5`, und `r5` Instance-Familien) auszuwählen, die den Anforderungen Ihrer Job-Warteschlangen entsprechen.
+ `default_x86_64`um x86-basierte Instance-Typen (aus den c7i Instance-Familien m6i c6ir6i,, und) auszuwählen, die den Ressourcenanforderungen der Job-Warteschlange entsprechen.
+ `default_arm64`um x86-basierte Instance-Typen (aus den c7g Instance-Familien m6g c6gr6g,, und) auszuwählen, die den Ressourcenanforderungen der Job-Warteschlange entsprechen.
**Anmerkung**
Ab dem 11.01.2025 `optimal` wird das Verhalten von entsprechend geändert. `default_x86_64` Während der Änderung könnten Ihre Instanzfamilien auf eine neuere Generation aktualisiert werden. Sie müssen keine Aktionen ausführen, damit das Upgrade durchgeführt werden kann. Weitere Informationen zu Änderungen finden Sie unter[ Optimale Konfiguration des Instance-Typs für den Empfang automatischer Updates der Instance-Familie Ab dem 11.01.2025 `optimal` wird das Verhalten von entsprechend geändert. `default_x86_64` Während der Änderung könnten Ihre Instanzfamilien auf eine neuere Generation aktualisiert werden. Sie müssen keine Aktionen ausführen, damit das Upgrade durchgeführt werden kann. AWS Batch hat eine einzige Option in **InstanceTypes** unterstützt, `optimal` um den Anforderungen Ihrer Job-Warteschlangen gerecht zu werden. Wir haben zwei neue Instance-Typ-Optionen eingeführt: und. `default_x86_64` `default_arm64` Wir verwenden, `default_x86_64` wenn Sie keinen Instanztyp auswählen. Mit diesen neuen Optionen werden automatisch kostengünstige Instance-Typen für verschiedene Familien und Generationen basierend auf Ihren Anforderungen in der Job-Warteschlange ausgewählt, sodass Sie Ihre Workloads schnell zum Laufen bringen können. Sobald ausreichend Kapazität neuer Instance-Typen in einem verfügbar ist AWS-Region, wird der entsprechende Standard-Pool automatisch mit dem neuen Instance-Typ aktualisiert. Die bestehende `optimal` Option wird weiterhin unterstützt und ist nicht veraltet, da sie von den zugrunde liegenden Standard-Pools unterstützt wird, um in Zukunft aktualisierte Instanzen bereitzustellen. Wenn Sie 'verwenden`optimal`, sind keine Maßnahmen Ihrerseits erforderlich. Beachten Sie jedoch, dass Only `ENABLED` und `VALID` Compute Environments (CEs) automatisch mit neuen Instanztypen aktualisiert werden. Falls Sie irgendwelche `DISABLED` oder haben `INVALID` CEs, erhalten sie Updates, sobald sie wieder aktiviert und auf einen bestimmten `VALID` Status gesetzt wurden. ](optimal-default-instance-troubleshooting.md#optimal-default-instance-troubleshooting.title).
**Anmerkung**
Die Verfügbarkeit der Instanzfamilien variiert je nach AWS-Region. Beispielsweise verfügen einige Server AWS-Region möglicherweise nicht über Instance-Familien der vierten Generation, sondern über Instance-Familien der fünften und sechsten Generation.
Wenn Sie unsere `default_arm64` Instance-Bundles verwenden`default_x86_64`, AWS Batch wählt die Instance-Familien auf der Grundlage eines ausgewogenen Verhältnisses zwischen Kosteneffektivität und Leistung aus. Instances der neueren Generation bieten zwar oft ein besseres Preis-Leistungs-Verhältnis, aber AWS Batch vielleicht entscheiden Sie sich für eine Instance-Familie einer früheren Generation, wenn diese die optimale Kombination aus Verfügbarkeit, Kosten und Leistung für Ihren Workload bietet. In einer AWS-Region Umgebung, in der sowohl c6i- als auch c7i-Instances verfügbar sind, AWS Batch könnten Sie sich für c6i-Instances entscheiden, wenn sie für Ihre spezifischen Aufgabenanforderungen eine bessere Kosteneffektivität bieten. [Weitere Informationen zu AWS Batch Instance-Typen und AWS-Region Verfügbarkeit finden Sie in der Berechnungstabelle für Instance-Typen.](instance-type-compute-table.md#instance-type-compute-table.title)
AWS Batch aktualisiert Ihre Instances in Standardpaketen regelmäßig auf neuere, kostengünstigere Optionen. Updates erfolgen automatisch, ohne dass Sie etwas unternehmen müssen. Ihre Workloads laufen während der Updates ohne Unterbrechung weiter.
**Anmerkung**
Wenn Sie eine Compute-Umgebung erstellen, müssen die Instance-Typen, die Sie für die Compute-Umgebung auswählen, dieselbe Architektur verwenden. Beispielsweise ist es nicht möglich, x86- und ARM-Instances in derselben Compute-Umgebung zu kombinieren.
**Anmerkung**
AWS Batch wird auf der GPUs Grundlage der erforderlichen Menge in Ihren Auftragswarteschlangen skaliert. Um die GPU-Planung verwenden zu können, muss die Rechenumgebung Instance-Typen aus den `g6` Familien `p3` `p4``p5`,`p6`,`g3`,`g3s`,`g4`,`g5`, oder enthalten.
1. Wählen Sie als **Allocation strategy (Zuordnungsstrategie)** die Zuordnungsstrategie aus, die bei der Auswahl von Instance-Typen aus der Liste der zulässigen Instance-Typen verwendet werden soll. **BEST\$1FIT\$1PROGRESSIVE** **ist normalerweise die bessere Wahl für EC2-On-Demand-Rechenumgebungen, SPOT\$1CAPACITY\$1OPTIMIZED und **SPOT\$1PRICE\$1CAPACITY\$1OPTIMIZED** für EC2-Spot-Compute-Umgebungen.** Weitere Informationen finden Sie unter [Strategien zur Zuweisung von Instance-Typen für AWS Batch](allocation-strategies.md).
1. Erweitern Sie **Additional configuration (Zusätzliche Konfiguration)**.
1. **(Optional) Geben Sie für Placement-Gruppe einen Placement-Gruppennamen ein, um Ressourcen in der Rechenumgebung zu gruppieren.**
1. (Optional) Wählen Sie für das **EC2-Schlüsselpaar** ein öffentliches und ein privates key pair als Sicherheitsanmeldedaten aus, wenn Sie eine Verbindung mit der Instance herstellen. Weitere Informationen zu Amazon EC2 EC2-Schlüsselpaaren finden Sie unter [Amazon EC2 EC2-Schlüsselpaare und Linux-Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html).
1. (Optional) Wählen Sie für die **EC2-Konfiguration** die Werte **Image-Typ** und **Image-ID** aus, um Informationen zur AWS Batch Auswahl von Amazon Machine Images (AMIs) für Instances in der Rechenumgebung bereitzustellen. Wenn die **Image-ID-Override** nicht für jeden **Image-Typ** angegeben ist, AWS Batch wird ein aktuelles [Amazon ECS-optimiertes AMI](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html) ausgewählt. Wenn kein **Image-Typ** angegeben ist, ist der Standard **Amazon Linux 2 für Instances** ohne GPU oder AWS Graviton.
**Wichtig**
Um ein benutzerdefiniertes AMI zu verwenden, wählen Sie den Image-Typ aus und geben Sie dann die benutzerdefinierte AMI-ID in das Feld **Image-ID Override** ein.
[Amazon Linux 2](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html#al2ami)
Standard für alle AWS Graviton-basierten Instance-Familien (z. B., `C6g` `M6g``R6g`, und`T4g`) und kann für alle Instance-Typen ohne GPU verwendet werden.
[Amazon Linux 2 (GPU)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html#gpuami)
Standard für alle GPU-Instanzfamilien (zum Beispiel `P4` und`G4`) und kann für alle Instance-Typen verwendet werden, die nicht auf AWS Graviton basieren.
[Amazon Linux 2023](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html)
AWS Batch unterstützt Amazon Linux 2023.
Amazon Linux 2023 unterstützt keine `A1` Instances.
[Amazon Linux 2023 (GPU)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html#gpuami)
Standard für alle GPU-Instance-Familien (zum Beispiel `P4` und`G4`) und kann für alle Instance-Typen verwendet werden, die nicht AWS auf Graviton basieren.
**Anmerkung**
Das AMI, das Sie für eine Compute-Umgebung auswählen, muss der Architektur der Instance-Typen entsprechen, die Sie für die betreffende Compute-Umgebung verwenden möchten. Wenn Ihre Datenverarbeitungsumgebung beispielsweise A1-Instance-Typen verwendet, muss das von Ihnen ausgewählte Compute-Ressourcen-AMI ARM-Ressourcen unterstützen. Amazon ECS verkauft sowohl x86- als auch ARM-Versionen des für Amazon ECS optimierten Amazon Linux 2-AMI. Weitere Informationen finden Sie unter [Amazon ECS-optimiertes Amazon Linux 2-AMI](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html#ecs-optimized-ami-linux-variants.html) im *Amazon Elastic Container Service Developer Guide*.
1. (Optional) Erweitern Sie **Launch-Vorlagen**
1. Wählen Sie für **Standard-Startvorlage** eine bestehende Amazon EC2 EC2-Startvorlage aus, um Ihre Rechenressourcen zu konfigurieren. Die Standardversion der Vorlage wird automatisch ausgefüllt. Weitere Informationen finden Sie unter [Verwenden Sie Amazon EC2 EC2-Startvorlagen mit AWS Batch](launch-templates.md).
**Anmerkung**
In einer Startvorlage können Sie ein benutzerdefiniertes AMI angeben, das Sie erstellt haben.
1. (Optional) Geben Sie **als Standardversion**, `$Default``$Latest`, oder eine bestimmte Versionsnummer ein, die verwendet werden soll.
**Anmerkung**
Hinweis: Wenn Sie eine der Ersatzvariablen (\$1Default oder \$1Latest) verwenden, wird die aktuelle Standard- oder neueste Versionsnummer zum Zeitpunkt des Speicherns dieser Konfiguration verwendet. Wenn sich die Standard- oder neueste Version in future ändert, müssen Sie die Informationen aktualisieren — sie werden nicht automatisch aktualisiert.
**Wichtig**
Wenn der Versionsparameter der Startvorlage `$Default` oder ist`$Latest`, wird die Standard- oder neueste Version der angegebenen Startvorlage bei einem Infrastruktur-Update bewertet. Wenn standardmäßig eine andere AMI-ID ausgewählt ist oder die neueste Version der Startvorlage ausgewählt ist, wird diese AMI-ID im Update verwendet. Weitere Informationen finden Sie unter [AMI-Auswahl bei Infrastruktur-Updates](infrastructure-updates.md#updating-compute-environments-ami).
1. (Optional) Wählen Sie unter **Startvorlage überschreiben** die Option **Startvorlage überschreiben hinzufügen**
1. (Optional) Wählen Sie unter **Startvorlage** eine bestehende Amazon EC2 EC2-Startvorlage aus, die für bestimmte Instance-Typen und Familien verwendet werden soll.
1. (Optional) Geben Sie für die **Standardversion** eine bestimmte Versionsnummer ein, die verwendet werden soll`$Default`, oder`$Latest`.
**Anmerkung**
Wenn Sie entweder die `$Latest` Variable `$Default` oder verwenden, AWS Batch werden die aktuellen Informationen zum Zeitpunkt der Erstellung der Rechenumgebung übernommen. Wenn sich die Standard- oder neueste Version in future ändert, müssen Sie die Informationen über [UpdateComputeEnvironment](https://docs.aws.amazon.com/batch/latest/APIReference/API_UpdateComputeEnvironment.html)oder über das AWS-Managementkonsole - aktualisieren AWS Batch.
1. (Optional) Wählen Sie für **Target-Instance-Typen** den Instance-Typ oder die Instance-Familie aus, auf die Sie die Override-Startvorlage anwenden möchten.
**Anmerkung**
Wenn Sie eine Startvorlage zum Außerkraftsetzen angeben, ist die Angabe der **Target-Instanztypen** erforderlich. Weitere Informationen finden Sie unter [LaunchTemplateSpecificationOverride. targetInstanceTypes](https://docs.aws.amazon.com/batch/latest/APIReference/API_LaunchTemplateSpecificationOverride.html#Batch-Type-LaunchTemplateSpecificationOverride-targetInstanceTypes).
**Anmerkung**
Wenn der Instanztyp oder die Familie, die Sie auswählen möchten, nicht in dieser Liste angezeigt wird, überprüfen Sie die Auswahl, die Sie in `Allowed instance types` getroffen haben.
1. Wählen Sie **Weiter** aus.
1. Gehen Sie im Abschnitt **Netzwerkkonfiguration** wie folgt vor:
**Wichtig**
Datenverarbeitungsressourcen benötigen einen externen Netzwerkzugriff, um mit dem Amazon-ECS-Service-Endpunkt zu kommunizieren. Dies kann über einen Schnittstellen-VPC-Endpunkt oder über Ihre Datenverarbeitungsressourcen mit öffentlichen IP-Adressen sein.
Weitere Informationen zu Interface-VPC-Endpunkten finden Sie unter [Amazon-ECS-Schnittstellen-VPC-Endpunkte (AWS PrivateLink)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/vpc-endpoints.html) im *Amazon Elastic Container Service-Entwicklerhandbuch*.
Wenn Sie keinen Schnittstellen-VPC-Endpunkt konfiguriert haben und Ihre Datenverarbeitungsressourcen keine öffentlichen IP-Adressen haben, müssen Sie Netzwerkadressübersetzung (Network Address Translation, NAT) verwenden, um diesen Zugriff zur Verfügung zu stellen. Weitere Informationen finden Sie unter [NAT-Gateways](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) im *Amazon VPC-Benutzerhandbuch*. Weitere Informationen finden Sie unter [Erstellen einer VPC](create-a-vpc.md).
1. Wählen Sie für **Virtual Private Cloud (VPC) ID** eine VPC aus, auf der Ihre Instances gestartet werden sollen.
1. Wählen Sie für **Subnetze** die zu verwendenden Subnetze aus. Standardmäßig sind alle Subnetze innerhalb der ausgewählten VPC verfügbar.
**Anmerkung**
AWS Batch auf Amazon EC2 unterstützt Local Zones. Weitere Informationen finden Sie unter [Local Zones](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html?icmpid=docs_ec2_console#concepts-local-zones) im *Amazon EC2 EC2-Benutzerhandbuch* und [Amazon ECS-Cluster in Local Zones, Wavelength Zones und AWS Outposts](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/cluster-regions-zones.html#clusters-local-zones) im *Amazon Elastic Container Service Developer Guide*.
1. (Optional) Wählen Sie für **Sicherheitsgruppen** eine Sicherheitsgruppe aus, die Sie Ihren Instances zuordnen möchten. Standardmäßig ist die Standardsicherheitsgruppe für Ihre VPC ausgewählt.
**Anmerkung**
Hinweis: Wenn Sie eine der Ersatzvariablen (\$1Default oder \$1Latest) verwenden, wird die aktuelle Standard- oder neueste Versionsnummer zum Zeitpunkt des Speicherns dieser Konfiguration verwendet. Wenn sich die Standard- oder neueste Version in future ändert, müssen Sie die Informationen aktualisieren — sie werden nicht automatisch aktualisiert.
1. Wählen Sie „**Nächste Seite“**.
1. **Überprüfen Sie** die Konfigurationsschritte zur Überprüfung. Wenn Sie Änderungen vornehmen müssen, wählen Sie **Edit** (Bearbeiten). Wenn Sie fertig sind, wählen Sie **Create Compute Environment** aus.
# Tutorial: Erstellen Sie eine nicht verwaltete Rechenumgebung mithilfe von Amazon EC2 EC2-Ressourcen
Gehen Sie wie folgt vor, um mithilfe von Amazon Elastic Compute Cloud (Amazon EC2) -Ressourcen eine nicht verwaltete Rechenumgebung zu erstellen.
****
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 auf der Seite **Compute Environments** die Option **Create** aus.
1. Konfigurieren Sie die Umgebung.
1. Wählen Sie für die **Konfiguration der Rechenumgebung** **Amazon Elastic Compute Cloud (Amazon EC2)**.
1. **Wählen Sie als **Orchestrierungstyp** die Option Unmanaged aus.**
1. Geben Sie **unter Name** einen eindeutigen Namen für Ihre Rechenumgebung an. 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 **Servicerolle** eine Rolle aus, mit der der AWS Batch Dienst in Ihrem Namen die erforderlichen AWS API-Operationen aufrufen kann.
**Anmerkung**
Sie können es nicht `AWSServiceRoleForBatch` für nicht verwaltete Rechenumgebungen verwenden.
1. Wählen Sie für **Maximum v** die maximale Anzahl von v ausCPUs, auf CPUs die Ihre Rechenumgebung skaliert werden kann, unabhängig von der Nachfrage in der Jobwarteschlange.
1. (Optional) Erweitern Sie **Tags**. Um einen Tag hinzuzufügen, wählen Sie **Add tag (Tag hinzufügen)**. Geben Sie dann einen **Schlüsselnamen** und optional einen **Wert** ein. Wählen Sie **Add tag**. Weitere Informationen finden Sie unter [Kennzeichnen Sie Ihre AWS Batch Ressourcen](using-tags.md).
1. Wählen Sie „**Nächste Seite“**.
1. **Überprüfen Sie** die Konfigurationsschritte zur Überprüfung. Wenn Sie Änderungen vornehmen müssen, wählen Sie **Edit** (Bearbeiten). Wenn Sie fertig sind, wählen Sie **Create Compute Environment** aus.
# Tutorial: Erstellen Sie eine verwaltete Rechenumgebung mithilfe von Amazon EKS-Ressourcen
Gehen Sie wie folgt vor, um eine verwaltete Rechenumgebung mithilfe von Amazon Elastic Kubernetes Service (Amazon EKS) -Ressourcen zu erstellen.
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 **Datenverarbeitungs-Umgebungen** aus.
1. Wählen Sie **Erstellen** aus.
1. Wählen Sie für die **Konfiguration der Rechenumgebung** **Amazon Elastic Kubernetes Service (Amazon EKS**).
1. Geben Sie **unter Name** einen eindeutigen Namen für Ihre Rechenumgebung an. 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 Instanzrolle** ein vorhandenes Instanzprofil aus, dem die erforderlichen IAM-Berechtigungen zugeordnet sind.
**Anmerkung**
Um eine Rechenumgebung in der AWS Batch Konsole zu erstellen, wählen Sie ein Instanzprofil mit den `eks:DescribeCluster` Berechtigungen `eks:ListClusters` und aus.
1. Wählen Sie für **EKS-Cluster** einen vorhandenen Amazon EKS-Cluster aus.
1. Geben Sie für **Namespace** einen Kubernetes Namespace ein, um Ihre AWS Batch Prozesse im Cluster zu gruppieren.
1. **(Optional) Erweitern Sie Tags.** Wählen Sie **Tag hinzufügen** und geben Sie dann ein Schlüssel-Wert-Paar ein.
1. Wählen Sie „**Nächste** Seite“.
1. (Optional) Aktivieren **Sie für EC2-Spot-Instances verwenden** die Option **Verwendung von Spot-Instances aktivieren, um Amazon EC2-Spot-Instances** zu verwenden.
1. (Nur Spot) Wählen Sie für den **On-Demand-Preis von maximal%** den maximalen Prozentsatz aus, den ein Spot-Instance-Preis im Vergleich zum On-Demand-Preis für diesen Instance-Typ vor dem Start der Instances betragen kann. Wenn Ihr Höchstpreis beispielsweise 20% beträgt, muss der Spot-Preis weniger als 20% des aktuellen On-Demand-Preises für diese EC2-Instance betragen. Sie zahlen immer nur den niedrigsten (Markt-) Preis und niemals mehr als Ihren maximalen Prozentsatz. Wenn Sie dieses Feld leer lassen, ist der Standardwert 100 % des On-Demand-Preises.
1. (Nur Spot) Wählen Sie für die **Spot-Flottenrolle** die Amazon EC2 Spot-Flotten-IAM-Rolle für die `SPOT` Rechenumgebung aus.
**Wichtig**
Diese Rolle ist erforderlich, wenn die Zuweisungsstrategie auf festgelegt `BEST_FIT` oder nicht angegeben ist.
1. (Optional) Wählen Sie für **Minimum v** die Mindestanzahl von v ausCPUs, CPUs die Ihre Rechenumgebung unabhängig von der Nachfrage in der Auftragswarteschlange verwaltet.
1. (Optional) Wählen Sie für **Maximum v** die maximale Anzahl von v ausCPUs, auf CPUs die Ihre Rechenumgebung skaliert werden kann, unabhängig von der Nachfrage in der Auftragswarteschlange.
1. (Optional) Wählen Sie für **Verzögerung beim Herunterskalieren (Minuten)** die Mindestdauer (in Minuten) aus, AWS Batch für die Instanzen nach Abschluss ihrer Jobs in der Rechenumgebung ausgeführt werden.
1. Wählen Sie **unter Zulässige Instance-Typen** die Amazon EC2 EC2-Instance-Typen aus, die gestartet werden können. Sie können Instance-Familien angeben, um jeden beliebigen Instance-Typ innerhalb dieser Familien zu starten (z. B.`c5`,`c5n`, oder`p3`). Sie können auch bestimmte Größen innerhalb einer Familie angeben (z. B.`c5.8xlarge`). Instanztypen aus Metall gehören nicht zu den Instanzfamilien. Beinhaltet zum Beispiel `c5` nicht`c5.metal`.
AWS Batch kann den Instanztyp für Sie auswählen, wenn Sie eine der folgenden Optionen wählen:
+ `optimal`um Instance-Typen (aus den`c4`,, `m4` `r4` `c5``m5`, und `r5` Instance-Familien) auszuwählen, die den Anforderungen Ihrer Job-Warteschlangen entsprechen.
+ `default_x86_64`um x86-basierte Instance-Typen (aus den c7i Instance-Familien m6i c6ir6i,, und) auszuwählen, die den Ressourcenanforderungen der Job-Warteschlange entsprechen.
+ `default_arm64`um x86-basierte Instance-Typen (aus den c7g Instance-Familien m6g c6gr6g,, und) auszuwählen, die den Ressourcenanforderungen der Job-Warteschlange entsprechen.
**Anmerkung**
Ab dem 11.01.2025 `optimal` wird das Verhalten von entsprechend geändert. `default_x86_64` Während der Änderung könnten Ihre Instanzfamilien auf eine neuere Generation aktualisiert werden. Sie müssen keine Aktionen ausführen, damit das Upgrade durchgeführt werden kann. Weitere Informationen zu Änderungen finden Sie unter[Optimale Konfiguration des Instance-Typs für den Empfang automatischer Updates der Instance-Familie](optimal-default-instance-troubleshooting.md).
**Anmerkung**
Die Verfügbarkeit der Instanzfamilien variiert je nach AWS-Region. Beispielsweise verfügen einige Server AWS-Region möglicherweise nicht über Instance-Familien der vierten Generation, sondern über Instance-Familien der fünften und sechsten Generation.
Wenn Sie unsere `default_arm64` Instance-Bundles verwenden`default_x86_64`, AWS Batch wählt die Instance-Familien auf der Grundlage eines ausgewogenen Verhältnisses zwischen Kosteneffektivität und Leistung aus. Instances der neueren Generation bieten zwar oft ein besseres Preis-Leistungs-Verhältnis, aber AWS Batch vielleicht entscheiden Sie sich für eine Instance-Familie einer früheren Generation, wenn diese die optimale Kombination aus Verfügbarkeit, Kosten und Leistung für Ihren Workload bietet. In einer AWS-Region Umgebung, in der sowohl c6i- als auch c7i-Instances verfügbar sind, AWS Batch könnten Sie sich für c6i-Instances entscheiden, wenn sie für Ihre spezifischen Aufgabenanforderungen eine bessere Kosteneffektivität bieten. [Weitere Informationen zu AWS Batch Instance-Typen und AWS-Region Verfügbarkeit finden Sie in der Berechnungstabelle für Instance-Typen.](instance-type-compute-table.md#instance-type-compute-table.title)
AWS Batch aktualisiert Ihre Instances in Standardpaketen regelmäßig auf neuere, kostengünstigere Optionen. Updates erfolgen automatisch, ohne dass Sie etwas unternehmen müssen. Ihre Workloads laufen während der Updates ohne Unterbrechung weiter
**Anmerkung**
Wenn Sie eine Compute-Umgebung erstellen, müssen die Instance-Typen, die Sie für die Compute-Umgebung auswählen, dieselbe Architektur verwenden. Beispielsweise ist es nicht möglich, x86- und ARM-Instances in derselben Compute-Umgebung zu kombinieren.
**Anmerkung**
AWS Batch wird auf der GPUs Grundlage der erforderlichen Menge in Ihren Auftragswarteschlangen skaliert. Um die GPU-Planung verwenden zu können, muss die Rechenumgebung Instance-Typen aus den `g6` Familien `p3` `p4``p5`,`p6`,`g3`,`g3s`,`g4`,`g5`, oder enthalten.
1. (Optional) Erweitern Sie **Zusätzliche Konfiguration**.
1. (Optional) Geben Sie unter **Platzierungsgruppe** einen Namen für die Platzierungsgruppe ein, um Ressourcen in der Rechenumgebung zu gruppieren.
1. Wählen Sie als **Zuweisungsstrategie** **BEST\$1FIT\$1PROGRESSIVE** aus.
1. (Optional) Wählen Sie für die **Konfiguration von Amazon Machine Images (AMIs)** die Option **Amazon Machine Images (amis) -Konfiguration hinzufügen** aus.
Sie können entweder ein Amazon EKS-optimiertes Amazon Linux-AMI oder ein benutzerdefiniertes AMI verwenden.
1. So verwenden Sie ein [Amazon EKS-optimiertes Amazon Linux-AMI](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-ami.html):
1. Wählen Sie als **Bildtyp** eine der folgenden Optionen aus:
+ [Amazon Linux 2](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-ami.html): Standard für alle AWS Graviton-basierten Instance-Familien (z. B., `C6g` `M6g``R6g`, und`T4g`) und kann für alle Instance-Typen ohne GPU verwendet werden.
+ [Amazon Linux 2 (beschleunigt)](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-ami.html): Standard für alle GPU-Instance-Familien (z. B. `P4` und`G4`) und kann für alle Instance-Typen verwendet werden, die nicht auf AWS Graviton basieren.
+ [Amazon Linux 2023](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-ami.html): AWS Batch unterstützt Amazon Linux 2023 (AL2023).
+ [Amazon Linux 2023 (beschleunigt)](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-ami.html): GPU-Instance-Familien, die für alle Instance-Typen verwendet werden können, die nicht AWS auf Graviton basieren.
1. Geben Sie für **KubernetesVersion** eine [KubernetesVersionsnummer](supported_kubernetes_version.md#supported_kubernetes_version.title) ein.
1. Um ein benutzerdefiniertes AMI zu verwenden:
1. Wählen Sie **unter Image-Typ** den AMI-Typ aus, auf dem das benutzerdefinierte AMI basiert:
+ [Amazon Linux 2](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-ami.html): Standard für alle AWS Graviton-basierten Instance-Familien (z. B., `C6g` `M6g``R6g`, und`T4g`) und kann für alle Instance-Typen ohne GPU verwendet werden.
+ [Amazon Linux 2 (beschleunigt)](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-ami.html): Standard für alle GPU-Instance-Familien (z. B. `P4` und`G4`) und kann für alle Instance-Typen verwendet werden, die nicht auf AWS Graviton basieren.
+ [Amazon Linux 2023](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-ami.html): AWS Batch unterstützt AL2023.
+ [Amazon Linux 2023 (beschleunigt)](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-ami.html): GPU-Instance-Familien, die für alle Instance-Typen verwendet werden können, die nicht AWS auf Graviton basieren.
1. Geben Sie für **Image ID Override** die benutzerdefinierte AMI-ID ein.
1. Geben Sie für **KubernetesVersion** eine [KubernetesVersionsnummer](supported_kubernetes_version.md#supported_kubernetes_version.title) ein.
1. (Optional) Wählen Sie **unter Startvorlage** eine vorhandene [Startvorlage](eks-launch-templates.md#eks-launch-templates.title) aus.
1. (Optional) Geben **Sie für Version der Startvorlage****\$1Default**,**\$1Latest**, oder eine Versionsnummer ein.
1. (Optional) Um eine **Überschreibung hinzuzufügen, wählen Sie unter Startvorlage** überschreiben die Option **Startvorlage hinzufügen** aus:
1. (Optional) Wählen Sie unter **Startvorlage** die Startvorlage aus, zu der Sie die Überschreibung hinzufügen möchten.
1. (Optional) Wählen Sie für **Launch Template Version** die Versionsnummer der Startvorlage`$Default`, oder`$Latest`.
1. (Optional) Wählen Sie für **Target-Instance-Typen** den Instance-Typ oder die Instance-Familie aus, auf die diese Überschreibung angewendet werden soll. Dies kann nur auf Instance-Typen und -Familien abzielen, die unter **Zulässige Instance-Typen** enthalten sind.
1. (Optional) Wählen Sie für **UserDataType** die EKS-Knoteninitialisierung aus. Verwenden Sie dieses Feld nur, wenn Sie ein AMI entweder im Launch Template oder als Launch Template Override angegeben haben. **Wählen Sie **EKS\$1NODEADM** für benutzerdefiniert AMIs basierend auf `EKS_AL2023` oder oder `EKS_AL2023_NVIDIA` oder EKS\$1BOOSTRAP\$1SH für und.** `EKS_AL2` `EKS_AL_NVIDIA` **Der Standardwert ist EKS\$1BOOSTRAP\$1SH.**
Sie würden **UserDataType** verwenden, wenn Sie eine [gemischte Umgebung haben, in der Sie sowohl als auch AL2 based custom in derselben Rechenumgebung](mixed-ami-environments.md#mixed-ami-environments.title) verwenden. AL2023 AMIs
1. **Wählen Sie „Nächste Seite“.**
1. Wählen Sie für **Virtual Private Cloud (VPC) ID** eine VPC aus, auf der die Instances gestartet werden sollen.
1. Wählen Sie für **Subnetze** die zu verwendenden Subnetze aus. Standardmäßig sind alle Subnetze innerhalb der ausgewählten VPC verfügbar.
**Anmerkung**
AWS Batch auf Amazon EKS unterstützt Local Zones. Weitere Informationen finden Sie unter [Amazon EKS and AWS Local Zones](https://docs.aws.amazon.com/eks/latest/userguide/local-zones.html) im *Amazon EKS-Benutzerhandbuch*.
1. (Optional) Wählen Sie für **Sicherheitsgruppen** eine Sicherheitsgruppe aus, die Sie Ihren Instances zuordnen möchten. Standardmäßig ist die Standardsicherheitsgruppe für Ihre VPC ausgewählt.
1. Wählen Sie **Nächste Seite.**
1. **Überprüfen Sie** die Konfigurationsschritte zur Überprüfung. Wenn Sie Änderungen vornehmen müssen, wählen Sie **Edit** (Bearbeiten). Wenn Sie fertig sind, wählen Sie **Create Compute Environment** aus.
# Tutorial: Erstellen Sie eine nicht verwaltete Rechenumgebung mithilfe von Amazon EKS-Ressourcen
Gehen Sie wie folgt vor, um mithilfe der Ressourcen von Amazon Elastic Kubernetes Service (Amazon EKS) eine nicht verwaltete Rechenumgebung zu erstellen.
1. Öffnen Sie die Konsole unter AWS Batch . [https://console.aws.amazon.com/batch/](https://console.aws.amazon.com/batch/)
1. Wählen Sie in der Navigationsleiste oben auf der Seite die aus, die Sie verwenden AWS-Region möchten.
1. Wählen Sie im Navigationsbereich **Datenverarbeitungs-Umgebungen** aus.
1. Wählen Sie **Erstellen** aus.
1. Konfigurieren Sie die Umgebung.
1. Wählen Sie für die **Konfiguration der Rechenumgebung** **Amazon Elastic Kubernetes Service (Amazon EKS**).
1. **Wählen Sie als **Orchestrierungstyp die Option Unmanaged** aus.**
1. Geben Sie **unter Name** einen eindeutigen Namen für Ihre Rechenumgebung an. Der Name kann bis zu 128 Zeichen lang sein. Er kann Groß- und Kleinbuchstaben, Zahlen, Bindestriche (-) und Unterstriche (\$1) enthalten.
1. Wählen Sie für **EKS-Cluster** einen vorhandenen Amazon EKS-Cluster aus. Um einen neuen EKS-Cluster zu erstellen, folgen Sie den Schritten auf der [Seite Amazon EKS-Cluster erstellen](https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html).
1. Geben Sie für **Namespace** einen Kubernetes Namespace ein, um Ihre AWS Batch Prozesse im Cluster zu gruppieren.
1. (Optional) Geben Sie für **Maximum v** die maximale Anzahl von v anCPUs, die aus Ihrer bereitgestellten Kapazität für die Jobplanung CPUs verfügbar sind.
1. (Optional) Erweitern Sie **Tags**. Wählen Sie **Tag hinzufügen** und geben Sie dann ein Schlüssel-Wert-Paar ein.
1. Wählen Sie „**Nächste** Seite“.
1. **Überprüfen Sie** die Konfigurationsschritte zur Überprüfung. Wenn Sie Änderungen vornehmen müssen, wählen Sie **Edit** (Bearbeiten). Wenn Sie fertig sind, wählen Sie **Create Compute Environment** aus.
**Zuweisen von Amazon EKS-Clusterknoten zu einer nicht verwalteten Rechenumgebung**
Nachdem Sie die nicht verwaltete Rechenumgebung erstellt haben, müssen Sie Ihre Amazon EKS-Knoten mit der UUID der Rechenumgebung kennzeichnen.
Rufen Sie zunächst die UUID der Rechenumgebung aus dem API-Ergebnis ab: `DescribeComputeEnvironments`
```
$ aws batch describe-compute-environments \
--compute-environments unmanagedEksCE \
--query "computeEnvironments[].{name: computeEnvironmentName, uuid: uuid}"
```
Holen Sie sich die Knoteninformationen:
```
kubectl get nodes -o name
```
Benennen Sie die Knoten mit der AWS Batch UUID der Rechenumgebung:
```
kubectl label batch.amazonaws.com/compute-environment-uuid=uuid
```
# Ressource: Vorlage für die Rechenumgebung
Das folgende Beispiel zeigt eine leere Vorlage für eine Rechenumgebung. Sie können diese Vorlage verwenden, um Ihre Rechenumgebung zu erstellen, die dann in einer Datei gespeichert und mit der AWS CLI `--cli-input-json` Option verwendet werden kann. Weitere Informationen zu diesen Parametern finden Sie [CreateComputeEnvironment](https://docs.aws.amazon.com/batch/latest/APIReference/API_CreateComputeEnvironment.html)in der *AWS Batch API-Referenz*.
**Anmerkung**
Mit dem folgenden AWS CLI Befehl können Sie eine Vorlage für die Rechenumgebung generieren.
```
$ aws batch create-compute-environment --generate-cli-skeleton
```
```
{
"computeEnvironmentName": "",
"type": "UNMANAGED",
"state": "DISABLED",
"unmanagedvCpus": 0,
"computeResources": {
"type": "EC2",
"allocationStrategy": "BEST_FIT_PROGRESSIVE",
"minvCpus": 0,
"maxvCpus": 0,
"desiredvCpus": 0,
"instanceTypes": [
""
],
"imageId": "",
"subnets": [
""
],
"securityGroupIds": [
""
],
"ec2KeyPair": "",
"instanceRole": "",
"tags": {
"KeyName": ""
},
"placementGroup": "",
"bidPercentage": 0,
"spotIamFleetRole": "",
"launchTemplate": {
"launchTemplateId": "",
"launchTemplateName": "",
"version": ""
},
"ec2Configuration": [
{
"imageType": "",
"imageIdOverride": "",
"imageKubernetesVersion": ""
}
]
},
"serviceRole": "",
"tags": {
"KeyName": ""
},
"eksConfiguration": {
"eksClusterArn": "",
"kubernetesNamespace": ""
}
}
```
# Instanztyp: Tabelle berechnen
In der folgenden Tabelle sind das AWS-Region Schlüsselwort Instanzfamilie und die verfügbaren Instanzfamilien aufgeführt. AWS Batch wird versuchen, eine Instance aus der neuesten Familie zuzuweisen, aber da die Verfügbarkeit der Instance-Familie je nach Familie unterschiedlich ist, kann es sein, dass AWS-Region Sie eine frühere Generation der Instance-Familie erhalten.
**default\$1x86\$164**
| Region | -Instance-Familien |
| --- | --- |
| Alles ist diese Unterstützung AWS-Region[AWS Batch](https://docs.aws.amazon.com/general/latest/gr/batch.html) | m6i, c6i, r6i c7 i |
**default\$1arm64**
| Region | -Instance-Familien |
| --- | --- |
| Alles AWS-Region ist diese Unterstützung [AWS Batch](https://docs.aws.amazon.com/general/latest/gr/batch.html) | 6mg, c6g, r6g c7 g |
**Optimal**
| Region | -Instance-Familien |
| --- | --- |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/batch/latest/userguide/instance-type-compute-table.html) | m4, c4, r4 |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/batch/latest/userguide/instance-type-compute-table.html) | m5, c5, r5 |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/batch/latest/userguide/instance-type-compute-table.html) | m6, c6, r6 |
# Aktualisieren Sie eine Rechenumgebung in AWS Batch
AWS Batch bietet mehrere Strategien für die Aktualisierung von Rechenumgebungen, die jeweils für spezifische Aktualisierungsszenarien und -anforderungen konzipiert sind. Diese Ansätze verwenden dieselbe zugrunde liegende Update-API, stellen jedoch unterschiedliche präskriptive Methoden für die effektive Verwaltung von Updates dar. Sie können diese Updates über die AWS Batch Konsole oder die verwalten. AWS CLI Wenn Sie diese Strategien kennen, können Sie die für Ihre Anforderungen am besten geeignete Methode auswählen und gleichzeitig Unterbrechungen Ihrer Workloads minimieren.
Dieses Thema bietet einen Überblick über die verfügbaren Aktualisierungsstrategien und gibt Hinweise, wann die einzelnen Ansätze zu verwenden sind. Ausführliche Verfahren finden Sie in den einzelnen Abschnitten der einzelnen Aktualisierungsstrategien.
**Wichtig**
AWS Batch erstellt und verwaltet mehrere AWS Ressourcen in Ihrem Namen und innerhalb Ihres Kontos, darunter Amazon EC2 Launch Templates, Amazon EC2 Auto Scaling Groups, Amazon EC2 Spot Fleets und Amazon ECS Clusters. Diese verwalteten Ressourcen sind speziell konfiguriert, um einen optimalen Betrieb zu gewährleisten. AWS Batch Die manuelle Änderung dieser AWS Batch verwalteten Ressourcen kann, sofern nicht ausdrücklich in der AWS Batch Dokumentation angegeben, zu unerwartetem Verhalten führen, einschließlich `INVALID` Rechenumgebungen, suboptimalem Verhalten bei der Instanzskalierung, verzögerter Workload-Verarbeitung oder unerwarteten Kosten. Diese manuellen Änderungen können vom Service nicht deterministisch unterstützt werden. AWS Batch Verwenden Sie immer den Support AWS Batch APIs oder die AWS Batch Konsole, um Ihre Computerumgebungen zu verwalten.
Zu den nicht unterstützten manuellen Änderungen gehören das Ausführen Ihrer eigenen Amazon ECS-Aufgaben oder -Services auf AWS Batch-verwalteten Amazon ECS-Clustern oder das Starten zusätzlicher Prozesse, Daemons oder Services direkt auf -verwalteten Instances. AWS Batch AWS Batch übernimmt die volle Kontrolle über die Rechenressourcen in einer verwalteten Rechenumgebung und kann jederzeit Instances beenden, Aufgaben beenden oder den Cluster skalieren. Alle Workloads, die Sie außerhalb von AWS Batch Job-Übermittlungen auf diesen verwalteten Ressourcen ausführen, können ohne Vorwarnung unterbrochen werden. Das Ausführen von AWS Batch AWS Batch Nicht-Workloads auf verwalteten Clustern und Instances kann auch die AWS Batch Jobplanung und Instanzskalierung beeinträchtigen.
**Topics**
+ [Strategien zur Aktualisierung der Rechenumgebung](#update-strategies)
+ [Auswahl der richtigen Aktualisierungsstrategie](#choosing-update-strategies)
+ [Überlegungen zum AMI-Update](#ami-update-considerations)
+ [Skalierungsupdates durchführen](scaling-updates.md)
+ [Führen Sie Infrastruktur-Updates durch](infrastructure-updates.md)
+ [Führen Sie blue/green Updates für Rechenumgebungen durch](blue-green-updates.md)
## Strategien zur Aktualisierung der Rechenumgebung
Wenn Sie Skalierung oder Infrastrukturupdates verwenden, wird Ihre Rechenumgebung an Ort und Stelle aktualisiert. Für die blue/green Aktualisierungsstrategie erstellen Sie eine neue Rechenumgebung (grün) und migrieren dann Ihre Arbeitslast von der alten Rechenumgebung (blau) zur neuen Rechenumgebung (grün).
AWS Batch bietet drei verschiedene Strategien für Updates der Rechenumgebung:
Skalierung von Updates
Skalierungsupdates passen die Kapazität Ihrer Rechenumgebung an, indem Instanzen hinzugefügt oder entfernt werden, ohne bestehende Instanzen zu ersetzen. Dies ist das schnellste Aktualisierungsszenario und erfordert keine Ausfallzeiten. Verwenden Sie Skalierungsupdates, wenn Sie die Kapazitätseinstellungen ändern müssen (vCPUs). Diese Updates sind in der Regel innerhalb von Minuten abgeschlossen.
Fargate-Updates werden mit den gleichen Verfahren wie Skalierungsupdates durchgeführt. Weitere Informationen finden Sie unter [Skalierungsupdates durchführen](scaling-updates.md).
Aktualisierungen der Infrastruktur
Infrastruktur-Updates ersetzen Instanzen in Ihrer Rechenumgebung durch neue Instanzen mit aktualisierten Einstellungen. Diese Updates erfordern spezielle Konfigurationen für die Servicerolle und die Zuweisungsstrategie, sorgen jedoch für minimale Ausfallzeiten, sodass laufende Jobs möglicherweise unterbrochen werden. Verwenden Sie Infrastruktur-Updates, wenn Sie Instance-Typen, AMI-Konfiguration, Netzwerkeinstellungen, Service-Rolle, Umgebungsstatus oder andere Infrastrukturkomponenten ändern müssen. Diese Updates sind je nach Abschluss des Auftrags in der Regel innerhalb von 10 bis 30 Minuten abgeschlossen.
Weitere Informationen finden Sie unter [Führen Sie Infrastruktur-Updates durch](infrastructure-updates.md).
Blaue/grüne Updates
Blue/green updates create a new compute environment alongside your existing environment, allowing gradual workload transition with zero downtime. This approach provides the safest update path but requires running two environments temporarily. Use blue/greenUpdates, wenn Sie keine Ausfallzeiten benötigen, Änderungen vor der vollständigen Bereitstellung testen möchten, schnelle Rollback-Funktionen benötigen oder Konfigurationen für Infrastruktur-Updates verwenden, die nicht unterstützt werden. Die Zeit bis zur Fertigstellung ist variabel und wird von Ihnen gesteuert.
Weitere Informationen finden Sie unter [Führen Sie blue/green Updates für Rechenumgebungen durch](blue-green-updates.md).
## Auswahl der richtigen Aktualisierungsstrategie
Verwenden Sie diesen Entscheidungsleitfaden, um die für Ihre Bedürfnisse am besten geeignete Aktualisierungsstrategie auszuwählen:
### Wählen Sie Skalierungsupdates aus, wenn
Wählen Sie die Strategie für Skalierungsaktualisierungen, wenn Sie nur die Rechenkapazität anpassen müssen (vCPUs). Skalierungsupdates sind ideal, wenn Sie schnelle Updates ohne Ausfallzeiten benötigen und keine Änderungen an der Infrastrukturkonfiguration erforderlich sind.
Die detaillierten Schritte finden Sie unter [Skalierungsupdates durchführen](scaling-updates.md).
### Wählen Sie Infrastruktur-Updates, wenn
Wählen Sie die Strategie für die Aktualisierung der Infrastruktur, wenn Sie Instance-Typen, AMI-Einstellungen, die Service-Rolle, den Umgebungsstatus oder die Netzwerkkonfiguration ändern müssen. Ihre Umgebung muss die *AWSServiceRoleForBatch*dienstbezogene Rolle und die Zuweisungsstrategie `BEST_FIT_PROGRESSIVE``SPOT_CAPACITY_OPTIMIZED`, oder `SPOT_PRICE_CAPACITY_OPTIMIZED` verwenden. Infrastruktur-Updates funktionieren gut, wenn eine Unterbrechung des Jobs während des Updates akzeptabel ist und Sie automatische Updates auf das neueste Amazon ECS-optimierte AMI wünschen.
Die detaillierten Schritte finden Sie unter [Führen Sie Infrastruktur-Updates durch](infrastructure-updates.md).
### Wählen Sie Updates wann blue/green
Wählen Sie die blue/green Aktualisierungsstrategie, wenn für Ihre Workloads keine Ausfallzeiten erforderlich sind oder wenn Sie Änderungen testen müssen, bevor Sie Produktions-Workloads umstellen. Dieser Ansatz ist wichtig, wenn schnelle Rollback-Fähigkeiten wichtig sind, Ihre Umgebung eine `BEST_FIT` Zuweisungsstrategie verwendet oder Ihre Umgebung die serviceverknüpfte Rolle nicht verwendet. *AWSServiceRoleForBatch* Blue/green Updates sind auch die beste Wahl, wenn Sie benutzerdefinierte Updates verwenden AMIs , die manuelle Updates erfordern oder größere Konfigurationsänderungen vornehmen müssen.
Die detaillierten Schritte finden Sie unter [Führen Sie blue/green Updates für Rechenumgebungen durch](blue-green-updates.md).
## Überlegungen zum AMI-Update
Der Aktualisierungsansatz AMIs hängt von der Konfiguration Ihrer Rechenumgebung ab.
### Aktualisierung des AWS Batch bereitgestellten Standard-AMI auf den neuesten Stand
AWS Batch kann bei [Infrastruktur-Updates](infrastructure-updates.md#infrastructure-updates.title) auf das neueste Amazon ECS-optimierte AMI aktualisieren, wenn alle folgenden Bedingungen erfüllt sind:
**Anmerkung**
Nach Abschluss des Infrastruktur-Updates `updateToLatestImageVersion` ist auf eingestellt. `false` Um ein weiteres Update zu initiieren, `updateToLatestImageVersion` muss die Einstellung auf gesetzt sein`true`.
+ Die Rechenumgebung verwendet die *AWSServiceRoleForBatch*serviceverknüpfte Rolle
+ Die Zuweisungsstrategie ist auf`BEST_FIT_PROGRESSIVE`,`SPOT_CAPACITY_OPTIMIZED`, oder eingestellt `SPOT_PRICE_CAPACITY_OPTIMIZED`
+ In der Vorlage`imageId`, `imageIdOverride` oder der Startvorlage ist keine AMI-ID explizit angegeben
+ Das `updateToLatestImageVersion` ist eingestellt auf `true`
### AMI-Updates mithilfe von blue/green Deployment
AMIs In den folgenden Szenarien müssen Sie blue/green Deployment verwenden, um Updates durchzuführen:
+ Bei Verwendung der `BEST_FIT` Zuweisungsstrategie (unterstützt keine Infrastrukturupdates)
+ Wenn die *AWSServiceRoleForBatch*[serviceverknüpfte](using-service-linked-roles-batch-general.md) Rolle nicht verwendet wird
### AMI-Updates für ein benutzerdefiniertes AMI
Wenn Sie in der Startvorlage der Rechenumgebung ein benutzerdefiniertes AMI angeben, aktualisiert der `imageId` Parameter oder der `imageIdOverride` Parameter in der EC2-Konfiguration Ihr benutzerdefiniertes AMI bei Infrastruktur-Updates nicht automatisch. AWS Batch Sie können eine benutzerdefinierte AMI-ID aktualisieren, indem Sie die neue ID in dem Parameter angeben, der ursprünglich bei der Erstellung der Compute-Umgebung verwendet wurde. Wenn Sie zur Verwendung eines von AWS Batch-bereitgestellten AMI wechseln möchten, können Sie dies tun, indem Sie die benutzerdefinierte AMI-ID in Ihrem Compute-Umgebungsupdate entfernen.
# Skalierungsupdates durchführen
Skalierungsupdates passen die Kapazität Ihrer Rechenumgebung an, indem Instanzen hinzugefügt oder entfernt werden. Dies ist die schnellste Aktualisierungsstrategie und erfordert keinen Austausch vorhandener Instanzen. Skalierungsaktualisierungen funktionieren mit jedem Servicerollentyp und jeder Zuweisungsstrategie und sind somit die flexibelste Aktualisierungsoption.
## Änderungen, die ein Skalierungsupdate auslösen
AWS Batch Führt ein Skalierungsupdate durch, wenn Sie nur die folgenden Einstellungen ändern. Wenn Sie eine dieser Einstellungen zusammen mit anderen Einstellungen der Rechenumgebung ändern, AWS Batch führt stattdessen ein [Infrastruktur-Update](infrastructure-updates.md#infrastructure-updates.title) durch.
Die folgenden Einstellungen lösen Skalierungsupdates aus, wenn sie ausschließlich geändert werden:
+ `desiredvCpus`— Legt die Zielzahl von v CPUs für die Umgebung fest.
+ `maxvCpus`— Definiert die maximale Anzahl von vCPUs , die gestartet werden können.
+ `minvCpus`— Gibt die Mindestanzahl von v anCPUs , die beibehalten werden sollen.
+ `minScaleDownDelayMinutes`— Gibt die Mindestzeit (in Minuten) an, die Instanzen nach Abschluss ihrer Jobs in der Rechenumgebung AWS Batch weiterlaufen lassen.
**Anmerkung**
`minScaleDownDelayMinutes`gilt nicht für Instanzen, die bei Infrastruktur-Updates ersetzt werden.
Für Fargate-Rechenumgebungen können Sie auch diese Einstellungen für die Skalierung von Updates ändern:
+ `securityGroupIds`— Sicherheitsgruppe IDs für die Rechenumgebung.
+ `subnets`— Subnetze für die Rechenumgebung.
**Anmerkung**
Wir empfehlen, es nicht `desiredvCpus` zu verwenden, um ein Skalierungsupdate zu initiieren, da AWS Batch es sich dynamisch anpassen `desiredvCpus` würde. Stattdessen sollten Sie aktualisieren`minvCpus`.
Bei der Aktualisierung `desiredvCpus` muss der Wert zwischen `minvCpus` und liegen`maxvCpus`. Der neue Wert muss größer oder gleich dem aktuellen sein`desiredvCpus`. Weitere Informationen finden Sie unter [Fehlermeldung beim Aktualisieren der `desiredvCpus` Einstellung](error-desired-vcpus-update.md).
**Wichtig**
Wenn Sie eine dieser Skalierungseinstellungen zusammen mit anderen Einstellungen der Rechenumgebung (wie Instance-Typen, AMI IDs oder Startvorlagen) ändern, AWS Batch führt statt eines Skalierungsupdates ein Infrastruktur-Update durch. Infrastruktur-Updates dauern länger und können bestehende Instances ersetzen.
------
#### [ Performing scaling updates using the AWS-Managementkonsole ]
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 Navigationsbereich **Umgebungen** und dann die Registerkarte **Rechenumgebungen** aus.
1. Wählen Sie die Rechenumgebung aus, die aktualisiert werden soll.
1. Wählen Sie **Aktionen** und dann **Bearbeiten**.
1. Ändern Sie eine oder mehrere [Einstellungen, die Skalierungsupdates unterstützen](#scaling-updates-triggers). Beispiel:
+ Geben Sie für **Minimum v CPUs** die Mindestanzahl von v einCPUs.
+ Geben Sie für **CPUsDesired v** die gewünschte Anzahl von v einCPUs.
+ Geben Sie für **Maximum v CPUs** die maximale Anzahl von v einCPUs.
1. Wählen Sie **Änderungen speichern ** aus.
1. Überwachen Sie den Status der Rechenumgebung. Das Update sollte schnell abgeschlossen sein, da es nur Skalierungsvorgänge beinhaltet.
------
#### [ Performing scaling updates using the AWS CLI ]
Verwenden Sie den **update-compute-environment** Befehl, um Skalierungsupdates durchzuführen. Die folgenden zwei Beispiele veranschaulichen gängige Skalierungsvorgänge. Sie können eine oder mehrere der folgenden [Einstellungen ändern, die Skalierungsupdates unterstützen](#scaling-updates-triggers)
+ In diesem Beispiel werden das gewünschte, minimale und maximale v aktualisiertCPUs:
```
aws batch update-compute-environment \
--compute-environment your-compute-environment-name \
--compute-resources minvCpus=2,maxvCpus=8
```
------
## Überwachung von Skalierungsaktualisierungen
Überwachen Sie Ihre Skalierungsupdates mithilfe der AWS Batch Konsole, um den Status der Rechenumgebung einzusehen und die Anzahl der Instanzen und die vCPU-Metriken zu überprüfen. Sie können den **describe-compute-environments** Befehl AWS CLI with the auch verwenden, um den Status zu überprüfen und die Anzahl der Instanzen und vCPU-Werte zu überwachen.
# Führen Sie Infrastruktur-Updates durch
Infrastruktur-Updates ersetzen die Instanzen in Ihrer Rechenumgebung durch neue Instanzen mit aktualisierten Einstellungen. Diese Aktualisierungsstrategie dauert länger als Skalierungsaktualisierungen und erfordert spezielle Einstellungen für die Servicerolle und die Zuweisungsstrategie. Infrastrukturupdates bieten eine Möglichkeit, grundlegende Konfigurationen der Rechenumgebung zu ändern und gleichzeitig die Serviceverfügbarkeit aufrechtzuerhalten.
**Wichtig**
Für Infrastrukturaktualisierungen sind die *AWSServiceRoleForBatch*dienstbezogene Rolle und eine Zuweisungsstrategie von `BEST_FIT_PROGRESSIVE``SPOT_CAPACITY_OPTIMIZED`, oder `SPOT_PRICE_CAPACITY_OPTIMIZED` erforderlich. Wenn Ihre Umgebung diese Anforderungen nicht erfüllt, verwenden Sie stattdessen blue/green Updates.
## Änderungen, die Infrastrukturaktualisierungen auslösen
AWS Batch Führt ein Infrastruktur-Update durch, wenn Sie eine der folgenden Einstellungen ändern. Infrastrukturaktualisierungen erfolgen auch, wenn Sie diese Einstellungen zusammen mit den Einstellungen für das Skalieren von Updates ändern.
Die folgenden Einstellungen lösen Infrastrukturaktualisierungen aus:
**Konfiguration berechnen**
+ `allocationStrategy`— Legt fest, wie Instanztypen AWS Batch ausgewählt werden.
+ `instanceTypes`— Gibt an, welche EC2-Instance-Typen verwendet werden sollen.
+ `bidPercentage`— Maximaler Prozentsatz des On-Demand-Preises für Spot-Instances.
+ `type`— Typ der Rechenumgebung (`EC2`oder`SPOT`).
**AMI und Startkonfiguration**
+ `imageId`— Spezifisches AMI, das für Instances verwendet werden soll.
+ `ec2Configuration`— EC2-Konfiguration einschließlich. `imageIdOverride`
+ `launchTemplate`— Einstellungen für die EC2-Startvorlage.
+ `ec2KeyPair`— SSH-Schlüsselpaar für Instanzzugriff.
+ `updateToLatestImageVersion`— Einstellung für automatische AMI-Updates.
**Netzwerk und Sicherheit**
+ `subnets`— VPC-Subnetze, in denen Instances gestartet werden (für EC2-Rechenumgebungen).
+ `securityGroupIds`— Sicherheitsgruppen für Instances (für EC2-Computerumgebungen).
+ `placementGroup`— Konfiguration der EC2-Platzierungsgruppe.
**Andere Einstellungen**
+ `instanceRole`— IAM-Rolle für EC2-Instances.
+ `tags`— Auf EC2-Instances angewendete Tags.
**Wichtig**
Wenn Sie Einstellungen für Infrastruktur-Updates zusammen mit Einstellungen für Skalierungsupdates (wie`desiredvCpus`, oder`minvCpus`) ändern`maxvCpus`, AWS Batch führt ein Infrastruktur-Update durch. Infrastrukturaktualisierungen dauern länger als Skalierungsaktualisierungen.
## AMI-Auswahl bei Infrastruktur-Updates
Während eines Infrastruktur-Updates kann sich die AMI-ID der Rechenumgebung ändern, je nachdem, ob AMIs sie in einer dieser drei Einstellungen angegeben ist. AMIs sind in der `imageId` (in`computeResources`), `imageIdOverride` (in`ec2Configuration`) oder der unter angegebenen Startvorlage angegeben`launchTemplate`. Nehmen wir an, dass in keiner dieser Einstellungen AMI angegeben IDs sind und die `updateToLatestImageVersion` Einstellung ist`true`. Anschließend wird das neueste Amazon ECS-optimierte AMI, das von unterstützt AWS Batch wird, für jedes Infrastruktur-Update verwendet.
Wenn in mindestens einer dieser Einstellungen eine AMI-ID angegeben ist, hängt das Update davon ab, welche Einstellung die vor dem Update verwendete AMI-ID bereitgestellt hat. Wenn Sie eine Rechenumgebung erstellen, ist die Priorität für die Auswahl einer AMI-ID zuerst die Startvorlage, dann die `imageId` Einstellung und schließlich die `imageIdOverride` Einstellung. Wenn die verwendete AMI-ID jedoch aus der Startvorlage stammt, wird durch das Aktualisieren der `imageId` `imageIdOverride` Oder-Einstellungen die AMI-ID nicht aktualisiert. Die einzige Möglichkeit, eine aus der Startvorlage ausgewählte AMI-ID zu aktualisieren, besteht darin, die Startvorlage zu aktualisieren. Wenn der Versionsparameter der Startvorlage `$Default` oder ist`$Latest`, wird die Standard- oder neueste Version der angegebenen Startvorlage ausgewertet. Wenn standardmäßig eine andere AMI-ID ausgewählt ist oder die neueste Version der Startvorlage ausgewählt ist, wird diese AMI-ID im Update verwendet.
Wenn die Startvorlage nicht zur Auswahl der AMI-ID verwendet wurde, wird die AMI-ID verwendet, die in den `imageIdOverride` Parametern `imageId` oder angegeben ist. Wenn beide angegeben sind, wird die im `imageIdOverride` Parameter angegebene AMI-ID verwendet.
Angenommen, die Rechenumgebung verwendet eine AMI-ID`imageId`, die durch die `launchTemplate` Parameter`imageIdOverride`, oder angegeben wird, und Sie möchten das neueste für Amazon ECS optimierte AMI verwenden, das von unterstützt wird AWS Batch. Anschließend muss das Update die Einstellungen entfernen, die AMI bereitgestellt haben IDs. Denn `imageId` dazu muss eine leere Zeichenfolge für diesen Parameter angegeben werden. Denn `imageIdOverride` dazu muss eine leere Zeichenfolge für den `ec2Configuration` Parameter angegeben werden.
Wenn die AMI-ID aus der Startvorlage stammt, können Sie zum neuesten Amazon ECS-optimierten AMI wechseln, das auf eine der folgenden Arten unterstützt wird: AWS Batch
+ Entfernen Sie die Startvorlage, indem Sie eine leere Zeichenfolge für den `launchTemplateName` Parameter `launchTemplateId` oder angeben. Dadurch wird die gesamte Startvorlage entfernt und nicht nur die AMI-ID.
+ Wenn die aktualisierte Version der Startvorlage keine AMI-ID angibt, muss der `updateToLatestImageVersion` Parameter auf gesetzt werden`true`.
## Auftragsabwicklung bei Updates
Konfigurieren Sie mithilfe der Aktualisierungsrichtlinie, wie laufende Jobs während eines Infrastruktur-Updates behandelt werden. Wenn Sie festlegen`terminateJobsOnUpdate=true`, werden laufende Jobs sofort beendet, die `jobExecutionTimeoutMinutes` Einstellung wird ignoriert und das Update wird fortgesetzt, sobald Instanzen ersetzt werden können. Wenn Sie festlegen`terminateJobsOnUpdate=false`, werden laufende Jobs für den angegebenen Timeout-Zeitraum mit einem Standard-Timeout von 30 Minuten fortgesetzt, und Jobs werden beendet, wenn sie das Timeout überschreiten.
**Anmerkung**
Um Jobs zu wiederholen, die während eines Updates beendet wurden, konfigurieren Sie eine Strategie zur Wiederholung von Aufträgen. Weitere Informationen finden Sie unter [Automatisierte Auftragswiederholungen](job_retries.md).
------
#### [ Performing infrastructure updates using the AWS-Managementkonsole ]
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 Navigationsbereich **Umgebungen** und dann die Registerkarte **Rechenumgebungen** aus.
1. Wählen Sie die Rechenumgebung aus, die aktualisiert werden soll.
1. Wählen Sie **Aktionen** und dann **Bearbeiten**.
1. Konfigurieren **Sie im Abschnitt Aktualisierungsverhalten**, wie laufende Jobs behandelt werden:
+ Wählen Sie **AMI auf neueste Version** aktualisieren, um das AMI auf die neueste Version zu aktualisieren.
+ Wählen Sie **Jobs sofort beim Update** beenden, um Jobs zu beenden, wenn der Aktualisierungsprozess ausgeführt wird.
+ Geben Sie unter **Timeout für die Jobausführung** die Anzahl der Minuten ein, die gewartet werden soll, bevor der Aktualisierungsvorgang gestartet wird.
1. Ändern Sie eine oder mehrere [Einstellungen, für die Infrastrukturupdates erforderlich sind](#infrastructure-updates-triggers). Beispiel:
+ **Rolle der Instanz**
+ **Verwenden Sie EC2-Spot-Instances**
+ **Zulässige Instance-Typen**
+ **Platzierungsgruppe**
+ **EC2 key pair**
+ **EC2-Konfiguration**
+ **Startvorlagen**
+ **Subnets**
+ **Sicherheitsgruppen**
1. Wählen Sie **Änderungen speichern ** aus.
1. Überwachen Sie den Status der Rechenumgebung. Die Umgebung wird `UPDATING` während des Aktualisierungsvorgangs angezeigt.
------
#### [ Performing infrastructure updates using the AWS CLI ]
Verwenden Sie den **update-compute-environment** Befehl, wenn Sie eine oder mehrere [Einstellungen ändern, für die Infrastrukturaktualisierungen erforderlich sind](#infrastructure-updates-triggers). Bei den folgenden drei Beispielen handelt es sich um gängige Infrastrukturoperationen.
+ In diesem Beispiel werden die Instanztypen aktualisiert und die Aktualisierungsrichtlinie konfiguriert:
```
aws batch update-compute-environment \
--compute-environment your-compute-environment-name \
--compute-resources instanceTypes=default_x86_64 \
--update-policy terminateJobsOnUpdate=false,jobExecutionTimeoutMinutes=30
```
+ In diesem Beispiel werden die VPC-Subnetze und Sicherheitsgruppen aktualisiert:
```
aws batch update-compute-environment \
--compute-environment your-compute-environment-name \
--compute-resources subnets=subnet-abcd1234,subnet-efgh5678 securityGroupIds=sg-abcd1234 \
--update-policy terminateJobsOnUpdate=true
```
+ Dieses Beispiel ermöglicht automatische Updates auf das neueste für Amazon ECS optimierte AMI:
```
aws batch update-compute-environment \
--compute-environment your-compute-environment-name \
--compute-resources updateToLatestImageVersion=true \
--update-policy terminateJobsOnUpdate=false,jobExecutionTimeoutMinutes=60
```
------
## Überwachung von Infrastruktur-Updates
Überwachen Sie Ihre Infrastruktur-Updates mithilfe der AWS Batch Konsole, um zu beobachten, wie sich der Status der Rechenumgebung ändert`UPDATING`, überwachen Sie den Fortschritt beim Austausch von Instanzen und suchen Sie nach fehlgeschlagenen Updates. Das Update ist erfolgreich, sobald der Status der Rechenumgebung erreicht ist`VAILD`. Sie können es auch verwenden CloudWatch , um Ereignisse beim Beenden von Instanzen zu verfolgen und den Jobstatus während des Updates zu überwachen. Mit dem können Sie den **describe-compute-environments** Befehl verwenden AWS CLI, um den Status zu überprüfen und Ereignisse im Instanzlebenszyklus zu überwachen.
# Führen Sie blue/green Updates für Rechenumgebungen durch
Eine blue/green Aktualisierung ist eine Aktualisierungsstrategie, die Ausfallzeiten und Risiken reduziert, indem neben Ihrer bestehenden Computerumgebung (blau) eine neue Rechenumgebung (grün) erstellt wird. Dieser Ansatz ermöglicht es Ihnen, Workloads schrittweise auf die neue Umgebung umzustellen und gleichzeitig die bestehende Umgebung betriebsbereit zu halten. Blue/green Updates bieten den sichersten Aktualisierungspfad und funktionieren mit allen Servicerollentypen und Zuweisungsstrategien.
## -Übersicht
Blaue/grüne Updates bieten mehrere Vorteile, weshalb sie sich ideal für Produktionsumgebungen eignen. Sie sorgen für *keine Ausfallzeiten*, da Ihre Workloads während des Aktualisierungsvorgangs kontinuierlich ausgeführt werden. Dieser Ansatz ermöglicht *einfache Rollback-Funktionen*, sodass Sie bei Problemen schnell zur ursprünglichen Umgebung zurückkehren können. Sie können eine *schrittweise Übergangsstrategie* implementieren und die Leistung der neuen Umgebung überprüfen, bevor Sie Ihre Produktionsworkloads vollständig umstellen. Diese Methode bietet auch eine hervorragende *Risikominderung*, da die ursprüngliche Umgebung unverändert und betriebsbereit bleibt, bis Sie sie entfernen.
### Wenn blue/green Updates erforderlich sind
In den folgenden Situationen müssen Sie blue/green Updates verwenden:
+ Wenn Ihre Computerumgebung eine `BEST_FIT` Zuweisungsstrategie verwendet (unterstützt keine Infrastrukturaktualisierungen)
+ Wenn Ihre Computerumgebung die *AWSServiceRoleForBatch*serviceverknüpfte Rolle nicht verwendet
+ Wenn Sie zwischen verschiedenen Servicerollentypen wechseln müssen
### Wann werden blue/green Updates empfohlen
Blue/green updates are particularly recommended for production environments where zero downtime is critical for your workloads. This approach works well when you need to test new configurations before transitioning production workloads, ensuring that changes meet your performance and reliability requirements. Choose blue/greenUpdates, wenn die Möglichkeit eines schnellen Rollbacks für Ihren Betrieb wichtig ist, insbesondere wenn Sie benutzerdefinierte Aktualisierungen AMIs mit wesentlichen Änderungen vornehmen. Diese Methode ist auch ideal, wenn Sie Leistungsmerkmale und Verhalten überprüfen möchten, bevor Sie Änderungen vollständig vornehmen, sodass Sie sich auf Ihren Aktualisierungsprozess verlassen können.
### Voraussetzungen
Bevor Sie ein blue/green Update durchführen, stellen Sie sicher, dass Sie über Folgendes verfügen:
+ Entsprechende [IAM-Berechtigungen](IAM_policies.md#IAM_policies.title) zum Erstellen und Verwalten von Computerumgebungen
+ Zugriff zum Anzeigen und Ändern der Einstellungen für die Job-Warteschlange
+ Strategien zur Wiederholung von Job, die für Ihre Jobdefinitionen konfiguriert wurden, um potenzielle Fehler während der Umstellung zu beheben. Weitere Informationen finden Sie unter [Automatisierte Auftragswiederholungen](job_retries.md).
+ Die AMI-ID für die neue Rechenumgebung. Dies kann entweder sein:
+ Eine aktuelle, genehmigte Version des für Amazon ECS optimierten AMI (standardmäßig verwendet)
+ Ein benutzerdefiniertes AMI, das die AMI-Spezifikation für Amazon ECS-Container-Instances erfüllt. Wenn Sie ein benutzerdefiniertes AMI verwenden, können Sie es auf eine der folgenden Arten angeben:
+ Verwenden Sie das **Image-ID-Override-Feld** in der EC2-Konfiguration
+ Geben Sie es in einer Startvorlage an
Weitere Informationen zum Erstellen benutzerdefinierter Elemente AMIs finden Sie unter[Tutorial: Erstellen Sie ein Compute-Ressourcen-AMI](create-batch-ami.md).
Bevor Sie die neue Umgebung erstellen, müssen Sie die Konfiguration Ihrer vorhandenen Computerumgebung aufzeichnen. Sie können dies entweder mit AWS-Managementkonsole oder mit dem tun AWS CLI.
**Anmerkung**
In den folgenden Verfahren wird detailliert beschrieben, wie ein blue/green Update durchgeführt wird, das nur das AMI ändert. Sie können andere Einstellungen für die neue Umgebung aktualisieren.
**Wichtig**
Wenn Sie die alte (blaue) Rechenumgebung entfernen, schlagen alle derzeit ausgeführten Jobs auf diesen Instanzen fehl, da die Instanzen beendet werden. Konfigurieren Sie Strategien zur Wiederholung von Jobs in Ihren Jobdefinitionen, um diese Fehler automatisch zu behandeln. Weitere Informationen finden Sie unter [Automatisierte Auftragswiederholungen](job_retries.md).
Sobald Sie mit der neuen Umgebung vertraut sind:
Bearbeiten Sie die Job-Warteschlange, um die alte Rechenumgebung zu entfernen.
Warten Sie, bis alle laufenden Jobs in der alten Umgebung abgeschlossen sind.
Löschen Sie die alte Datenverarbeitungsumgebung.
------
#### [ Performing blue/green updates using the AWS-Managementkonsole ]
1. Klonen Sie Ihre aktuelle Computerumgebung
1. Öffnen Sie die AWS Batch Konsole unter [https://console.aws.amazon.com/batch/](https://console.aws.amazon.com/batch/).
1. Wählen Sie Ihre bestehende Rechenumgebung aus.
1. Wählen Sie **Aktionen** und dann **Klonen**.
1. Geben Sie unter **Name** einen eindeutigen Namen für Ihre neue Rechenumgebung ein.
1. Wählen Sie **Weiter** aus.
1. Aktualisieren Sie im Abschnitt **Instanzkonfiguration** die AMI-Einstellungen:
1. Erweitern Sie **Additional configuration (Zusätzliche Konfiguration)**.
1. Geben Sie für die **EC2-Konfiguration** den neuen AMI-Typ im **Image-Typ** und die AMI-ID im Feld **Image-ID Override** an.
1. Wählen Sie **Weiter** aus.
1. Wählen Sie für die **Netzwerkkonfiguration** **Weiter** aus.
1. Überprüfen Sie die anderen Einstellungen, die automatisch aus Ihrer bestehenden Umgebung kopiert werden.
1. Wählen Sie **Rechenumgebung erstellen** aus.
1. Warten Sie, bis der Status der neuen Rechenumgebung erreicht ist`VALID`.
1. Ändern Sie die Reihenfolge der Job-Warteschleifen
1. Wählen Sie im Navigationsbereich **Job Queues** aus.
1. Wählen Sie die Job-Warteschlange aus, die Ihrer vorhandenen Computerumgebung zugeordnet ist.
1. Wählen Sie **Bearbeiten** aus.
1. Fügen Sie unter **Connected Compute-Umgebung** die neue Rechenumgebung hinzu:
+ Fügen Sie die neue Rechenumgebung mit einer höheren Ordnungsnummer als die bestehende Umgebung hinzu, um den Workload umzustellen.
+ Sobald Sie sich vergewissert haben, dass die neue Umgebung ordnungsgemäß funktioniert, können Sie sie zur primären Umgebung machen, indem Sie ihr eine niedrigere Bestellnummer zuweisen.
1. Wählen Sie **Auftragswarteschlange aktualisieren** aus.
1. Bereinigen
1. Überwachen Sie die Auftragsausführung in der neuen Umgebung, um sicherzustellen, dass alles wie erwartet funktioniert.
1. Sobald Sie mit der neuen Umgebung vertraut sind:
1. Bearbeiten Sie die Job-Warteschlange, um die alte Rechenumgebung zu entfernen.
1. Warten Sie, bis alle laufenden Jobs in der alten Umgebung abgeschlossen sind.
1. Löschen Sie die alte Datenverarbeitungsumgebung.
------
#### [ Performing blue/green updates using the AWS CLI ]
1. Verwenden Sie den folgenden Befehl AWS CLI, um die Konfiguration mit dem abzurufen:
```
aws batch describe-compute-environments \
--compute-environments your-compute-environment-name
```
Speichern Sie die Ausgabe als Referenz, wenn Sie die neue Umgebung erstellen.
1. Erstellen Sie eine neue Rechenumgebung mit der Konfiguration aus Ihrer vorhandenen Umgebung, jedoch mit dem neuen AMI. Hier ist ein Beispiel für eine Befehlsstruktur:
Ersetzen Sie die Beispielwerte durch Ihre tatsächliche Konfiguration aus dem vorherigen Schritt:
```
cat < ./blue-green-compute-environment.json
{
"computeEnvironmentName": "your-new-compute-environment-name",
"type": "MANAGED",
"state": "ENABLED",
"computeResources": {
"instanceRole": "arn:aws:iam::012345678901:instance-profile/ecsInstanceRole",
"type": "EC2",
"minvCpus": 2,
"desiredvCpus": 2,
"maxvCpus": 256,
"instanceTypes": [
"optimal"
],
"allocationStrategy": "BEST_FIT_PROGRESSIVE",
"ec2Configuration": [
{
"imageType": "ECS_AL2023",
"imageIdOverride": "ami-0abcdef1234567890"
}
],
"subnets": [,
"subnet-0abcdef1234567890"
],
"securityGroupIds": [
"sg-0abcdef1234567890"
]
}
}
EOF
```
```
$ aws batch create-compute-environment --cli-input-json file://./blue-green-compute-environment.json
```
1. Warten Sie, bis die neue Umgebung verfügbar ist:
```
aws batch describe-compute-environments \
--compute-environments your-new-compute-environment-name \
--query 'computeEnvironments[].status'
```
1. Fügen Sie die neue Rechenumgebung zu Ihrer Job-Warteschlange hinzu:
```
aws batch update-job-queue \
--job-queue your-job-queue \
--compute-environment-order order=1,computeEnvironment=your-existing-environment \
order=2,computeEnvironment=your-new-compute-environment-name
```
1. Führen Sie nach der Überprüfung erneut ein Update durch, um die neue Umgebung zur primären Umgebung zu machen:
```
aws batch update-job-queue \
--job-queue your-job-queue \
--compute-environment-order order=1,computeEnvironment=your-new-compute-environment-name
```
Wenn alle Jobs in der alten Umgebung abgeschlossen sind, deaktivieren Sie sie und löschen Sie sie dann:
```
aws batch update-compute-environment \
--compute-environment your-existing-environment \
--state DISABLED
```
```
aws batch delete-compute-environment \
--compute-environment your-existing-environment
```
------
# Ressource berechnen AMIs
Standardmäßig verwenden AWS Batch verwaltete Computerumgebungen eine aktuelle, genehmigte Version des für Amazon ECS optimierten AMI für Rechenressourcen. Möglicherweise möchten Sie jedoch Ihr eigenes AMI erstellen, das Sie für Ihre verwalteten und nicht verwalteten Computerumgebungen verwenden können. Wenn Sie eines der folgenden Dinge benötigen, empfehlen wir Ihnen, Ihr eigenes AMI zu erstellen:
+ Erhöhung der Speichergröße Ihrer AMI-Root- oder Datenvolumes
+ Hinzufügen von Instance-Speichervolumes für unterstützte EC2 Amazon-Instance-Typen
+ Anpassen des Amazon ECS-Container-Agenten
+ Anpassen von Docker
+ Konfiguration eines GPU-Workload-AMI, um Containern den Zugriff auf GPU-Hardware auf unterstützten EC2 Amazon-Instance-Typen zu ermöglichen
**Anmerkung**
Nachdem eine Datenverarbeitungsumgebung erstellt wurde, wird die AMIs in der Datenverarbeitungsumgebung AWS Batch nicht aktualisiert. AWS Batch aktualisiert die AMIs in Ihrer Computerumgebung auch nicht, wenn eine neuere Version des für Amazon ECS optimierten AMI verfügbar ist. Sie sind für die Verwaltung des Gastbetriebssystems verantwortlich. Dazu gehören alle Updates und Sicherheitspatches. Sie sind auch für jede zusätzliche Anwendungssoftware oder Hilfsprogramme verantwortlich, die Sie auf den Rechenressourcen installieren. Gehen Sie wie folgt vor, um ein neues AMI für Ihre AWS Batch Jobs zu verwenden:
Erstellen Sie eine neue Datenverarbeitungsumgebung mit dem neuen AMI.
Fügen Sie die Datenverarbeitungsumgebung einer vorhandenen Auftragswarteschlange hinzu.
Entfernen Sie die alte Datenverarbeitungsumgebung aus Ihrer Auftragswarteschlange.
Löschen Sie die alte Datenverarbeitungsumgebung.
Im April 2022 AWS Batch wurde erweiterte Unterstützung für die Aktualisierung von Computerumgebungen hinzugefügt. Weitere Informationen finden Sie unter [Aktualisieren Sie eine Rechenumgebung in AWS Batch](updating-compute-environments.md). Um die erweiterte Aktualisierung von Rechenumgebungen für Updates zu nutzen AMIs, folgen Sie diesen Regeln:
Legen Sie den Parameter service role ([https://docs.aws.amazon.com/batch/latest/APIReference/API_CreateComputeEnvironment.html#Batch-CreateComputeEnvironment-request-serviceRole](https://docs.aws.amazon.com/batch/latest/APIReference/API_CreateComputeEnvironment.html#Batch-CreateComputeEnvironment-request-serviceRole)) entweder nicht fest oder legen Sie ihn auf die **AWSServiceRoleForBatch**dienstverknüpfte Rolle fest.
Setzen Sie den Parameter Allocation Strategy ([https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResource.html#Batch-Type-ComputeResource-allocationStrategy](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResource.html#Batch-Type-ComputeResource-allocationStrategy)) auf `BEST_FIT_PROGRESSIVE``SPOT_CAPACITY_OPTIMIZED`, oder`SPOT_PRICE_CAPACITY_OPTIMIZED`.
Stellen Sie den Parameter Update auf die neueste Image-Version ([https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-updateToLatestImageVersion](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-updateToLatestImageVersion)) auf ein`true`.
Geben Sie keine AMI-ID in [https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-imageId](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-imageId), [https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html#Batch-Type-Ec2Configuration-imageIdOverride](https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html#Batch-Type-Ec2Configuration-imageIdOverride)(in [https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html)) oder in der Startvorlage ([https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-launchTemplate](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-launchTemplate)) an. Wenn Sie keine AMI-ID angeben, AWS Batch wählt das neueste Amazon ECS-optimierte AMI aus, das zum Zeitpunkt der Initiierung des Infrastruktur-Updates AWS Batch unterstützt wird. Alternativ können Sie die AMI-ID in den `imageIdOverride` Parametern `imageId` oder angeben. Sie können auch die Startvorlage angeben, die anhand der `LaunchTemplate` Eigenschaften identifiziert wird. Wenn Sie eine dieser Eigenschaften ändern, wird ein Infrastruktur-Update gestartet. Wenn die AMI-ID in der Startvorlage angegeben ist, kann die AMI-ID nicht durch die Angabe einer AMI-ID in den `imageIdOverride` Parametern `imageId` oder ersetzt werden. Die AMI-ID kann nur durch Angabe einer anderen Startvorlage ersetzt werden. Wenn die Version der Startvorlage auf `$Default` oder gesetzt ist`$Latest`, kann die AMI-ID ersetzt werden, indem entweder eine neue Standardversion für die Startvorlage festgelegt wird (if`$Default`) oder indem der Startvorlage eine neue Version hinzugefügt wird (if`$Latest`).
Wenn diese Regeln befolgt werden, führt jedes Update, das ein Infrastruktur-Update startet, dazu, dass die AMI-ID erneut ausgewählt wird. Wenn die [https://docs.aws.amazon.com/batch/latest/APIReference/API_LaunchTemplateSpecification.html#Batch-Type-LaunchTemplateSpecification-version](https://docs.aws.amazon.com/batch/latest/APIReference/API_LaunchTemplateSpecification.html#Batch-Type-LaunchTemplateSpecification-version)Einstellung in der Startvorlage ([https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-launchTemplate](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-launchTemplate)) auf `$Latest` oder gesetzt ist`$Default`, wird die neueste Version oder Standardversion der Startvorlage zum Zeitpunkt des Infrastruktur-Updates ausgewertet, auch wenn sie [https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-launchTemplate](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-launchTemplate)nicht aktualisiert wurde.
**Topics**
+ [AMI-Spezifikation für Datenverarbeitungsressourcen](batch-ami-spec.md)
+ [Tutorial: Erstellen Sie ein Compute-Ressourcen-AMI](create-batch-ami.md)
+ [Verwenden Sie ein GPU-Workload-AMI](batch-gpu-ami.md)
+ [Veraltete Amazon Linux-Version](al1-ami-deprecation.md)
+ [Amazon EKS Amazon Linux 2 AMI wird nicht mehr unterstützt](eks-al2-ami-deprecation.md)
+ [Amazon ECS Amazon Linux 2 AMI als veraltet](ecs-al2-ami-deprecation.md)
# AMI-Spezifikation für Datenverarbeitungsressourcen
Die grundlegende AMI-Spezifikation für AWS Batch Rechenressourcen umfasst Folgendes:
Erforderlich
+ Eine moderne Linux-Distribution, auf der mindestens Version 3.10 des Linux-Kernels auf einem AMI vom Typ HVM-Virtualisierung ausgeführt wird. Windows-Container werden nicht unterstützt.
**Wichtig**
parallel Jobs mit mehreren Knoten können nur auf Rechenressourcen ausgeführt werden, die auf einer Amazon Linux-Instance mit dem installierten `ecs-init` Paket gestartet wurden. Wir empfehlen, dass Sie bei der Erstellung Ihrer Datenverarbeitungsumgebung das standardmäßige, für Amazon ECS optimierte AMI verwenden. Sie können dies tun, indem Sie kein benutzerdefiniertes AMI angeben. Weitere Informationen finden Sie unter [parallel Jobs mit mehreren Knoten](multi-node-parallel-jobs.md).
+ Der Amazon ECS-Containeragent. Wir empfehlen, dass Sie die neueste Version verwenden. Weitere Informationen finden Sie unter [Installation des Amazon ECS Container Agent](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-agent-install.html) im *Amazon Elastic Container Service Developer Guide*.
+ Der `awslogs` Protokolltreiber muss als verfügbarer Protokolltreiber mit der `ECS_AVAILABLE_LOGGING_DRIVERS` Umgebungsvariablen angegeben werden, wenn der Amazon ECS-Container-Agent gestartet wird. Weitere Informationen finden Sie unter [Amazon ECS Container Agent Configuration](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-agent-config.html) im *Entwicklerhandbuch zum Amazon Elastic Container Service*.
+ Ein Docker-Daemon, auf dem mindestens Version 1.9 ausgeführt wird, und alle Abhängigkeiten von der Docker-Laufzeit. Weitere Informationen finden Sie unter [Check runtime dependencies](https://docs.docker.com/engine/installation/binaries/#check-runtime-dependencies) (Prüfen der Laufzeitabhängigkeiten) in der Docker-Dokumentation.
**Anmerkung**
Wir empfehlen die Docker-Version, die mit der entsprechenden Amazon ECS-Agentenversion, die Sie verwenden, geliefert wird und mit dieser getestet wurde. Amazon ECS stellt ein Changelog für die Linux-Variante des Amazon ECS-optimierten AMI on bereit. GitHub Weitere Informationen finden Sie unter [Änderungsprotokoll](https://github.com/aws/amazon-ecs-ami/blob/main/CHANGELOG.md).
Empfohlen
+ Ein Initialisierungs- und Nanny-Prozess zum Ausführen und Überwachen des Amazon ECS-Agenten. Das für Amazon ECS optimierte AMI verwendet den `ecs-init` Upstart-Prozess, und andere Betriebssysteme verwenden `systemd` ihn möglicherweise. Weitere Informationen und Beispiele finden Sie unter [Beispielskripte zur Konfiguration von Benutzerdaten für Container-Instances](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/example_user_data_scripts.html) im *Amazon Elastic Container Service Developer Guide*. Weitere Informationen zu `ecs-init` finden Sie im [`ecs-init`Projekt](https://github.com/aws/amazon-ecs-init) unter GitHub. Für verwaltete Rechenumgebungen muss der Amazon ECS-Agent mindestens beim Booten gestartet werden. Wenn der Amazon ECS-Agent nicht auf Ihrer Rechenressource läuft, kann er keine Jobs von annehmen AWS Batch.
Das für Amazon ECS optimierte AMI ist mit diesen Anforderungen und Empfehlungen vorkonfiguriert. Wir empfehlen, dass Sie das für Amazon ECS optimierte AMI oder ein Amazon Linux AMI mit dem `ecs-init` Paket verwenden, das für Ihre Rechenressourcen installiert ist. Wählen Sie ein anderes AMI, wenn Ihre Anwendung ein bestimmtes Betriebssystem oder eine Docker-Version benötigt, die in diesen AMIs noch nicht verfügbar ist. Weitere Informationen finden Sie unter [Amazon ECS-Optimized AMI](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html) im *Amazon Elastic Container Service Developer Guide*.
# Tutorial: Erstellen Sie ein Compute-Ressourcen-AMI
Sie können Ihr eigenes benutzerdefiniertes Compute-Ressourcen-AMI erstellen, das Sie für Ihre verwalteten und nicht verwalteten Computerumgebungen verwenden können. Anweisungen hierzu finden Sie im [AMI-Spezifikation für Datenverarbeitungsressourcen](batch-ami-spec.md). Nachdem Sie ein benutzerdefiniertes AMI erstellt haben, können Sie eine Rechenumgebung erstellen, die dieses AMI verwendet, dem Sie eine Auftragswarteschlange zuordnen können. Beginnen Sie zuletzt damit, Jobs an diese Warteschlange zu senden.
**So erstellen Sie ein benutzerdefiniertes Compute-Ressourcen-AMI**
1. Wählen Sie ein Basis-AMI aus, von dem aus Sie beginnen möchten. Das Basis-AMI muss HVM-Virtualisierung verwenden. Das Basis-AMI kann kein Windows-AMI sein.
**Anmerkung**
Das AMI, das Sie für eine Compute-Umgebung auswählen, muss der Architektur der Instance-Typen entsprechen, die Sie für die betreffende Compute-Umgebung verwenden möchten. Wenn Ihre Datenverarbeitungsumgebung beispielsweise A1-Instance-Typen verwendet, muss das von Ihnen ausgewählte Compute-Ressourcen-AMI ARM-Ressourcen unterstützen. Amazon ECS verkauft sowohl x86- als auch ARM-Versionen des für Amazon ECS optimierten Amazon Linux 2-AMI. Weitere Informationen finden Sie unter [Amazon ECS-optimiertes Amazon Linux 2-AMI](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html#ecs-optimized-ami-linux-variants.html) im *Amazon Elastic Container Service Developer Guide*.
Das für Amazon ECS optimierte Amazon Linux 2-AMI ist das Standard-AMI für Rechenressourcen in verwalteten Computerumgebungen. Das für Amazon ECS optimierte Amazon Linux 2-AMI ist vorkonfiguriert und wurde AWS Batch von AWS Technikern getestet. Es handelt sich um ein minimales AMI, mit dem Sie beginnen können und mit dem Sie Ihre Rechenressourcen AWS schnell zum Laufen bringen können. Weitere Informationen finden Sie unter [Amazon ECS Optimized AMI](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html) im *Amazon Elastic Container Service Developer Guide*.
Alternativ können Sie eine andere Amazon Linux 2-Variante wählen und das `ecs-init` Paket mit den folgenden Befehlen installieren. Weitere Informationen finden Sie unter [Installation des Amazon ECS-Container-Agenten auf einer Amazon Linux EC2 2-Instance](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-agent-install.html#ecs-agent-install-al2) im *Amazon Elastic Container Service Developer Guide*:
```
$ sudo amazon-linux-extras disable docker
$ sudo amazon-linux-extras install ecs-init
```
Wenn Sie beispielsweise GPU-Workloads auf Ihren AWS Batch Rechenressourcen ausführen möchten, können Sie mit dem [Amazon Linux Deep Learning AMI](https://aws.amazon.com/marketplace/pp/B01M0AXXQB) beginnen. Konfigurieren Sie dann das AMI für die Ausführung von AWS Batch Jobs. Weitere Informationen finden Sie unter [Verwenden Sie ein GPU-Workload-AMI](batch-gpu-ami.md).
**Wichtig**
Sie können ein Basis-AMI wählen, das das `ecs-init` Paket nicht unterstützt. In diesem Fall müssen Sie jedoch eine Methode konfigurieren, mit der der Amazon ECS-Agent beim Booten gestartet und weiter ausgeführt werden kann. Sie können sich auch mehrere Beispielskripts zur Konfiguration von Benutzerdaten ansehen, die `systemd` zum Starten und Überwachen des Amazon ECS-Container-Agenten verwendet werden. Weitere Informationen finden Sie unter [Beispiel für Konfigurationsskripte für Container-Instance-Benutzerdaten](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/example_user_data_scripts.html) im *Amazon Elastic Container Service Developer Guide*.
1. Starten Sie eine Instance von Ihrem ausgewählten Basis-AMI aus mit den entsprechenden Speicheroptionen für Ihr AMI. Sie können die Größe und Anzahl der angehängten Amazon EBS-Volumes oder Instance-Speicher-Volumes konfigurieren, sofern der von Ihnen gewählte Instance-Typ diese unterstützt. Weitere Informationen finden Sie unter [Launching an Instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/launching-instance.html) und [Amazon EC2 Instance Store](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html) im * EC2 Amazon-Benutzerhandbuch*.
1. Connect zu Ihrer Instance mit her SSH und führen Sie alle erforderlichen Konfigurationsaufgaben durch. Dies kann einen oder alle der folgenden Schritte beinhalten:
+ Installation des Amazon ECS-Container-Agenten. Weitere Informationen finden Sie unter [Installation des Amazon ECS Container Agent](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-agent-install.html) im *Amazon Elastic Container Service Developer Guide*.
+ Konfigurieren Sie ein Skript zum Formatieren von Instance-Speicher-Volumes.
+ Hinzufügen von Instance-Speicher-Volume- oder Amazon EFS-Dateisystemen zur `/etc/fstab` Datei, sodass sie beim Booten gemountet werden.
+ Konfiguration von Docker-Optionen, z. B. das Aktivieren des Debuggens oder das Anpassen der Basis-Image-Größe.
+ Installieren Sie Pakete oder kopieren Sie Dateien.
Weitere Informationen finden Sie unter [Herstellen einer Verbindung zu Ihrer Linux-Instance mithilfe von SSH](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstancesLinux.html) im * EC2 Amazon-Benutzerhandbuch*.
1. Wenn Sie den Amazon ECS-Container-Agenten auf Ihrer Instance gestartet haben, müssen Sie ihn beenden und alle persistenten Daten-Checkpoint-Dateien entfernen, bevor Sie Ihr AMI erstellen. Andernfalls, wenn Sie dies nicht tun, startet der Agent nicht auf Instances, die von Ihrem AMI aus gestartet werden.
1. Halten Sie den Amazon-ECS-Container-Agent an.
+ Amazon-ECS-optimiertes Amazon Linux 2-AMI:
```
sudo systemctl stop ecs
```
+ Amazon-ECS-optimiertes Amazon Linux AMI:
```
sudo stop ecs
```
1. Entfernen Sie die Checkpoint-Dateien für persistente Daten. Standardmäßig befinden sich diese Dateien im `/var/lib/ecs/data/` Verzeichnis. Verwenden Sie den folgenden Befehl, um diese Dateien zu entfernen, falls vorhanden.
```
sudo rm -rf /var/lib/ecs/data/*
```
1. Erstellen Sie ein neues AMI aus Ihrer laufenden Instance. Weitere Informationen finden Sie unter [Creating an Amazon EBS Backed Linux AMI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-an-ami-ebs.html) im * EC2 Amazon-Benutzerhandbuch*.
**Um Ihr neues AMI zu verwenden mit AWS Batch**
1. Nachdem das neue AMI erstellt wurde, erstellen Sie eine Rechenumgebung mit dem neuen AMI. Wählen Sie dazu den Image-Typ aus und geben Sie die benutzerdefinierte AMI-ID in das Feld **Image-ID Override** ein, wenn Sie die AWS Batch Rechenumgebung erstellen. Weitere Informationen finden Sie unter [Tutorial: Erstellen Sie eine verwaltete Rechenumgebung mithilfe von Amazon EC2 EC2-Ressourcen](create-compute-environment-managed-ec2.md).
**Anmerkung**
Das AMI, das Sie für eine Compute-Umgebung auswählen, muss der Architektur der Instance-Typen entsprechen, die Sie für die betreffende Compute-Umgebung verwenden möchten. Wenn Ihre Datenverarbeitungsumgebung beispielsweise A1-Instance-Typen verwendet, muss das von Ihnen ausgewählte Compute-Ressourcen-AMI ARM-Ressourcen unterstützen. Amazon ECS verkauft sowohl x86- als auch ARM-Versionen des für Amazon ECS optimierten Amazon Linux 2-AMI. Weitere Informationen finden Sie unter [Amazon ECS-optimiertes Amazon Linux 2-AMI](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html#ecs-optimized-ami-linux-variants.html) im *Amazon Elastic Container Service Developer Guide*.
1. Erstellen Sie eine Auftragswarteschlange und verknüpfen Sie Ihre neue Datenverarbeitungsumgebung. Weitere Informationen finden Sie unter [Eine Job-Warteschlange erstellen](create-job-queue.md).
**Anmerkung**
Alle Computing-Umgebungen, die mit einer Auftragswarteschlange verknüpft sind, müssen dieselbe Architektur verwenden. AWS Batch unterstützt nicht das Vermischen von Architekturtypen der Computing-Umgebung in einer einzigen Auftragswarteschlange.
1. (Optional) Übermitteln Sie einen Beispielauftrag an die neue Auftragswarteschlange. Weitere Informationen finden Sie unter [Beispiele für Berufsdefinitionen](example-job-definitions.md), [Erstellen Sie eine Auftragsdefinition mit einem Knoten](create-job-definition.md) und [Tutorial: Einen Job einreichen](submit_job.md).
# Verwenden Sie ein GPU-Workload-AMI
Um GPU-Workloads auf Ihren AWS Batch Rechenressourcen auszuführen, müssen Sie ein AMI mit GPU-Unterstützung verwenden. Weitere Informationen finden Sie unter [Arbeiten mit GPUs auf Amazon ECS und [Amazon ECS-Optimized AMIs](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-gpu.html) im *Amazon Elastic Container Service Developer Guide*.
Wenn in verwalteten Rechenumgebungen die Rechenumgebung irgendwelche`p3`,,,`p4`,`p5`, `p6` `g3` `g3s` `g4``g5`, oder `g6` Instance-Typen oder Instance-Familien spezifiziert, AWS Batch verwendet sie ein Amazon ECS-GPU-optimiertes AMI.
In nicht verwalteten Computerumgebungen wird ein GPU-optimiertes Amazon ECS-AMI empfohlen. Sie können die [GetParametersByPath](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParametersByPath.html)Operationen AWS Command Line Interface oder AWS Systems Manager Parameter Store [GetParameter](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameter.html), und verwenden [GetParameters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameters.html), um die Metadaten für das empfohlene AMIs GPU-optimierte Amazon ECS abzurufen.
**Anmerkung**
Die `p5` Instance-Familie wird nur in Versionen unterstützt, die dem Amazon ECS-GPU-optimierten AMI entsprechen oder später sind, und sie sind nicht mit `p2` Instance-Typen kompatibel. `20230912` `g2` Wenn Sie `p5` Instances verwenden müssen, stellen Sie sicher, dass Ihre Rechenumgebung keine `g2` OD-Instances enthält `p2` und das neueste Standard-Batch-AMI verwendet. Beim Erstellen einer neuen Rechenumgebung wird das neueste AMI verwendet. Wenn Sie Ihre Rechenumgebung jedoch so aktualisieren, dass sie inkludiert`p5`, können Sie sicherstellen, dass Sie das neueste AMI verwenden, indem Sie `true` in den `ComputeResource` Eigenschaften [https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-updateToLatestImageVersion](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResourceUpdate.html#Batch-Type-ComputeResourceUpdate-updateToLatestImageVersion)auf einstellen. Weitere Informationen zur AMI-Kompatibilität mit GPU-Instances finden Sie unter [Working with GPUs on Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-gpu.html) im *Amazon Elastic Container Service Developer Guide*.
Die folgenden Beispiele demonstrieren die Verwendung des [GetParameter](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameter.html)-Befehls.
------
#### [ AWS CLI ]
```
$ aws ssm get-parameter --name /aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended \
--region us-east-2 --output json
```
Die Ausgabe enthält die AMI-Informationen im `Value` Parameter.
```
{
"Parameter": {
"Name": "/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended",
"LastModifiedDate": 1555434128.664,
"Value": "{\"schema_version\":1,\"image_name\":\"amzn2-ami-ecs-gpu-hvm-2.0.20190402-x86_64-ebs\",\"image_id\":\"ami-083c800fe4211192f\",\"os\":\"Amazon Linux 2\",\"ecs_runtime_version\":\"Docker version 18.06.1-ce\",\"ecs_agent_version\":\"1.27.0\"}",
"Version": 9,
"Type": "String",
"ARN": "arn:aws:ssm:us-east-2::parameter/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended"
}
}
```
------
#### [ Python ]
```
from __future__ import print_function
import json
import boto3
ssm = boto3.client('ssm', 'us-east-2')
response = ssm.get_parameter(Name='/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended')
jsonVal = json.loads(response['Parameter']['Value'])
print("image_id = " + jsonVal['image_id'])
print("image_name = " + jsonVal['image_name'])
```
Die Ausgabe umfasst nur die AMI-ID und den AMI-Namen:
```
image_id = ami-083c800fe4211192f
image_name = amzn2-ami-ecs-gpu-hvm-2.0.20190402-x86_64-ebs
```
------
Die folgenden Beispiele demonstrieren die Verwendung von [GetParameters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameters.html).
------
#### [ AWS CLI ]
```
$ aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_name \
/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_id \
--region us-east-2 --output json
```
Die Ausgabe enthält die vollständigen Metadaten für die einzelnen Parameter:
```
{
"InvalidParameters": [],
"Parameters": [
{
"Name": "/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_id",
"LastModifiedDate": 1555434128.749,
"Value": "ami-083c800fe4211192f",
"Version": 9,
"Type": "String",
"ARN": "arn:aws:ssm:us-east-2::parameter/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_id"
},
{
"Name": "/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_name",
"LastModifiedDate": 1555434128.712,
"Value": "amzn2-ami-ecs-gpu-hvm-2.0.20190402-x86_64-ebs",
"Version": 9,
"Type": "String",
"ARN": "arn:aws:ssm:us-east-2::parameter/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_name"
}
]
}
```
------
#### [ Python ]
```
from __future__ import print_function
import boto3
ssm = boto3.client('ssm', 'us-east-2')
response = ssm.get_parameters(
Names=['/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_name',
'/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_id'])
for parameter in response['Parameters']:
print(parameter['Name'] + " = " + parameter['Value'])
```
Die Ausgabe enthält die AMI-ID und den AMI-Namen, wobei der vollständige Pfad für die Namen verwendet wird.
```
/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_id = ami-083c800fe4211192f
/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_name = amzn2-ami-ecs-gpu-hvm-2.0.20190402-x86_64-ebs
```
------
Die folgenden Beispiele demonstrieren die Verwendung des [GetParametersByPath](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParametersByPath.html)-Befehls.
------
#### [ AWS CLI ]
```
$ aws ssm get-parameters-by-path --path /aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended \
--region us-east-2 --output json
```
Die Ausgabe enthält die vollständigen Metadaten für alle Parameter unter dem angegebenen Pfad.
```
{
"Parameters": [
{
"Name": "/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/ecs_agent_version",
"LastModifiedDate": 1555434128.801,
"Value": "1.27.0",
"Version": 8,
"Type": "String",
"ARN": "arn:aws:ssm:us-east-2::parameter/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/ecs_agent_version"
},
{
"Name": "/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/ecs_runtime_version",
"LastModifiedDate": 1548368308.213,
"Value": "Docker version 18.06.1-ce",
"Version": 1,
"Type": "String",
"ARN": "arn:aws:ssm:us-east-2::parameter/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/ecs_runtime_version"
},
{
"Name": "/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_id",
"LastModifiedDate": 1555434128.749,
"Value": "ami-083c800fe4211192f",
"Version": 9,
"Type": "String",
"ARN": "arn:aws:ssm:us-east-2::parameter/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_id"
},
{
"Name": "/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_name",
"LastModifiedDate": 1555434128.712,
"Value": "amzn2-ami-ecs-gpu-hvm-2.0.20190402-x86_64-ebs",
"Version": 9,
"Type": "String",
"ARN": "arn:aws:ssm:us-east-2::parameter/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_name"
},
{
"Name": "/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/os",
"LastModifiedDate": 1548368308.143,
"Value": "Amazon Linux 2",
"Version": 1,
"Type": "String",
"ARN": "arn:aws:ssm:us-east-2::parameter/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/os"
},
{
"Name": "/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/schema_version",
"LastModifiedDate": 1548368307.914,
"Value": "1",
"Version": 1,
"Type": "String",
"ARN": "arn:aws:ssm:us-east-2::parameter/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/schema_version"
}
]
}
```
------
#### [ Python ]
```
from __future__ import print_function
import boto3
ssm = boto3.client('ssm', 'us-east-2')
response = ssm.get_parameters_by_path(Path='/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended')
for parameter in response['Parameters']:
print(parameter['Name'] + " = " + parameter['Value'])
```
Die Ausgabe enthält die Werte aller Parameternamen im angegebenen Pfad, wobei der vollständige Pfad für die Namen verwendet wird.
```
/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/ecs_agent_version = 1.27.0
/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/ecs_runtime_version = Docker version 18.06.1-ce
/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_id = ami-083c800fe4211192f
/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/image_name = amzn2-ami-ecs-gpu-hvm-2.0.20190402-x86_64-ebs
/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/os = Amazon Linux 2
/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended/schema_version = 1
```
------
Weitere Informationen finden Sie unter [Abrufen von Amazon ECS-optimierten AMI-Metadaten](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/retrieve-ecs-optimized_AMI.html) im *Amazon Elastic Container Service* Developer Guide.
# Veraltete Amazon Linux-Version
Das Amazon Linux AMI (auch Amazon Linux 1 genannt) hat am 31. Dezember 2023 sein Lebensende erreicht. AWS Batch hat den Support für Amazon Linux AMI eingestellt, da es ab dem 1. Januar 2024 keine Sicherheitsupdates oder Bugfixes erhalten wird. Weitere Informationen zu Amazon Linux end-of-life finden Sie in den [häufig gestellten Fragen zu AL](https://aws.amazon.com/amazon-linux-ami/faqs/).
Wir empfehlen, bestehende Amazon Linux-basierte Rechenumgebungen auf Amazon Linux 2023 zu aktualisieren, um unvorhergesehene Workload-Unterbrechungen zu vermeiden und weiterhin Sicherheits- und andere Updates zu erhalten.
Ihre Rechenumgebungen, die das Amazon Linux AMI verwenden, funktionieren möglicherweise auch nach dem 31. Dezember 2023 end-of-life weiter. Diese Computerumgebungen erhalten jedoch keine neuen Softwareupdates, Sicherheitspatches oder Bugfixes mehr von AWS. Es liegt in Ihrer Verantwortung, diese Rechenumgebungen anschließend auf dem Amazon Linux AMI aufrechtzuerhalten end-of-life. Wir empfehlen, AWS Batch Rechenumgebungen auf Amazon Linux 2023 oder Amazon Linux 2 zu migrieren, um optimale Leistung und Sicherheit zu gewährleisten.
Hilfe bei der Migration AWS Batch vom Amazon Linux AMI zu Amazon Linux 2023 oder Amazon Linux 2 finden Sie unter [Computerumgebungen aktualisieren — AWS Batch](https://docs.aws.amazon.com/batch/latest/userguide/updating-compute-environments.html).
# Amazon EKS Amazon Linux 2 AMI wird nicht mehr unterstützt
AWS wird die Unterstützung für Amazon EKS-optimiertes Amazon Linux 2 AMIs mit Wirkung zum 26.11.25 einstellen. Wir empfehlen, die AWS Batch Amazon EKS-Rechenumgebungen vor dem 26.11.25 auf Amazon Linux 2023 zu migrieren, um optimale Leistung und Sicherheit zu gewährleisten.
Sie können Amazon Linux 2, das von Batch bereitgestellte, für Amazon EKS optimierte Amazon Linux 2 auch nach AMIs dem 26.11.25 end-of-support weiterhin in Ihren Amazon EKS-Datenverarbeitungsumgebungen verwenden, diese Datenverarbeitungsumgebungen erhalten jedoch keine neuen Softwareupdates, Sicherheitspatches oder Bugfixes mehr von. AWS Es liegt in Ihrer Verantwortung, diese Rechenumgebungen anschließend auf dem für Amazon EKS optimierten Amazon Linux 2-AMI aufrechtzuerhalten end-of-life.
Weitere Informationen zu Amazon EKS AL2 end-of-life finden Sie unter [Amazon EKS AMI Deprecation FAQs](https://docs.aws.amazon.com/eks/latest/userguide/eks-ami-deprecation-faqs.html) im *Amazon EKS-Benutzerhandbuch*.
Hilfe zur Migration von AWS Batch Amazon EKS-Rechenumgebungen von Amazon Linux 2 auf Amazon Linux 2023 finden Sie unter[Wie führe ich ein Upgrade von EKS AL2 auf EKS durch AL2023](eks-migration-2023.md).
# Amazon ECS Amazon Linux 2 AMI als veraltet
AWS wird die Unterstützung für Amazon Linux 2 beenden. Ab Januar 2026 AWS Batch wird das Standard-AMI für neue Amazon ECS-Rechenumgebungen von Amazon Linux 2 auf Amazon Linux 2023 geändert. Wir empfehlen die Migration von AWS Batch Amazon ECS-Rechenumgebungen auf Amazon Linux 2023, um optimale Leistung und Sicherheit zu gewährleisten.
Weitere Informationen zu Amazon Linux 2 end-of-life finden Sie unter [Amazon Linux FAQs 2.](https://aws.amazon.com/amazon-linux-2/faqs/)
Informationen zu den Unterschieden zwischen Amazon Linux 2 und Amazon Linux 2023 finden Sie unter [Vergleichen von Amazon Linux 2023 und Amazon Linux 2](https://docs.aws.amazon.com/linux/al2023/ug/compare-with-al2.html) im *Amazon Linux 2023-Benutzerhandbuch*.
*Informationen zu Änderungen in Amazon Linux 2023 für Amazon ECS-optimiertes AMI finden Sie unter [Migration von einem Amazon Linux 2 zu einem Amazon ECS-optimierten AMI für Amazon Linux 2023 im Amazon ECS-Benutzerhandbuch](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/al2-to-al2023-ami-transition.html).*
Hilfe zur Migration von AWS Batch Amazon ECS-Rechenumgebungen von Amazon Linux 2 zu Amazon Linux 2023 finden Sie unter[So migrieren Sie von ECS AL2 zu ECS AL2 023](ecs-migration-2023.md).
# Verwenden Sie Amazon EC2 EC2-Startvorlagen mit AWS Batch
AWS Batch unterstützt die Verwendung von Amazon EC2 EC2-Startvorlagen in Ihren EC2-Rechenumgebungen. Mit Startvorlagen können Sie die Standardkonfiguration Ihrer AWS Batch Rechenressourcen ändern, ohne benutzerdefinierte Vorlagen erstellen zu müssen. AMIs
**Anmerkung**
Startvorlagen werden auf AWS Fargate-Ressourcen nicht unterstützt.
Sie müssen eine Startvorlage erstellen, bevor Sie sie mit einer Datenverarbeitungsumgebung verknüpfen können. Sie können eine Startvorlage in der Amazon EC2 EC2-Konsole erstellen. Sie können auch das AWS CLI oder ein AWS SDK verwenden. Die folgende JSON-Datei stellt beispielsweise eine Startvorlage dar, die die Größe des Docker-Datenvolumes für das AWS Batch Standard-Compute-Ressourcen-AMI ändert und es auch so festlegt, dass es verschlüsselt wird.
```
{
"LaunchTemplateName": "increase-container-volume-encrypt",
"LaunchTemplateData": {
"BlockDeviceMappings": [
{
"DeviceName": "/dev/xvda",
"Ebs": {
"Encrypted": true,
"VolumeSize": 100,
"VolumeType": "gp2"
}
}
]
}
}
```
Sie können die vorherige Startvorlage erstellen, indem Sie die JSON-Datei in einer Datei speichern, die aufgerufen wird, `lt-data.json` und den folgenden AWS CLI Befehl ausführen.
```
aws ec2 --region create-launch-template --cli-input-json file://lt-data.json
```
Weitere Informationen zu Startvorlagen finden Sie unter Launching [an Instance from a Launch Template](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-templates.html) im *Amazon EC2 EC2-Benutzerhandbuch*.
Wenn Sie eine Startvorlage verwenden, um Ihre Datenverarbeitungsumgebung zu erstellen, können Sie die folgenden vorhandenen Parameter der Datenverarbeitungsumgebung in Ihre Startvorlage verschieben:
**Anmerkung**
Nehmen wir an, dass einer dieser Parameter (mit Ausnahme der Amazon EC2-Tags) sowohl in der Startvorlage als auch in der Konfiguration der Rechenumgebung angegeben ist. Dann haben die Parameter der Rechenumgebung Vorrang. Amazon EC2-Tags werden zwischen der Startvorlage und der Konfiguration der Rechenumgebung zusammengeführt. Wenn der Schlüssel des Tags kollidiert, hat der Wert in der Konfiguration der Rechenumgebung Vorrang.
+ Amazon EC2 EC2-Schlüsselpaar
+ Amazon EC2 EC2-AMI-ID
+ Sicherheitsgruppe IDs
+ Amazon EC2-Tags
Die folgenden Parameter für Startvorlagen werden von ** AWS Batch ignoriert**:
+ Instance-Typ (Legen Sie beim Erstellen Ihrer Datenverarbeitungsumgebung die gewünschten Instance-Typen fest.)
+ Instance-Rolle (Legen Sie beim Erstellen Ihrer Datenverarbeitungsumgebung die gewünschte Instance-Rolle fest.)
+ Netzwerkschnittstellen-Subnetze (Legen Sie beim Erstellen Ihrer Datenverarbeitungsumgebung die gewünschten Subnetze fest.)
+ Optionen für den Instance-Markt (AWS Batch muss die Spot-Instance-Konfiguration steuern)
+ Deaktivieren Sie die API-Kündigung (AWS Batch muss den Instance-Lebenszyklus kontrollieren)
AWS Batch aktualisiert die Startvorlage nur bei Infrastruktur-Updates mit einer neuen Version der Startvorlage. Weitere Informationen finden Sie unter [Aktualisieren Sie eine Rechenumgebung in AWS Batch](updating-compute-environments.md).
## Startvorlagen als Standard festlegen und überschreiben
Sie können eine Standard-Startvorlage für die Rechenumgebung und eine Override-Startvorlage für bestimmte Instance-Typen und -Familien definieren. Dies kann für Sie nützlich sein, damit die Standardvorlage für die meisten Instance-Typen in den Rechenumgebungen verwendet wird.
Die Substitutionsvariablen `$Default` und `$Latest` können verwendet werden, anstatt eine bestimmte Version zu benennen. Wenn Sie keine überschriebene Startvorlage angeben, wird automatisch die Standard-Startvorlage angewendet.
Wenn Sie entweder die `$Latest` Variable `$Default` oder verwenden, AWS Batch werden die aktuellen Informationen zum Zeitpunkt der Erstellung der Rechenumgebung übernommen. Wenn sich die Standard- oder neueste Version in future ändert, müssen Sie die Informationen über [UpdateComputeEnvironment](https://docs.aws.amazon.com/batch/latest/APIReference/API_UpdateComputeEnvironment.html)oder über das AWS-Managementkonsole - aktualisieren AWS Batch.
Um zusätzliche Flexibilität zu bieten, können Sie definieren, dass Override-Startvorlagen auf bestimmte Compute-Instance-Typen oder -Familien angewendet werden.
**Anmerkung**
Sie können bis zu zehn (10) Override-Startvorlagen pro Rechenumgebung angeben.
Verwenden Sie den `targetInstanceTypes` Parameter, um den Instance-Typ oder die Instance-Familie auszuwählen, die diese Override-Startvorlage verwenden soll. Der Instance-Typ oder die Instance-Familie muss zuerst durch den [https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResource.html#Batch-Type-ComputeResource-instanceTypes](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResource.html#Batch-Type-ComputeResource-instanceTypes)Parameter identifiziert werden.
Wenn Sie Überschreibungen für Startvorlagen definieren und diese später entfernen möchten, können Sie ein leeres Array übergeben, um den [https://docs.aws.amazon.com/batch/latest/APIReference/API_LaunchTemplateSpecification.html#Batch-Type-LaunchTemplateSpecification-overrides](https://docs.aws.amazon.com/batch/latest/APIReference/API_LaunchTemplateSpecification.html#Batch-Type-LaunchTemplateSpecification-overrides)Parameter im [https://docs.aws.amazon.com/batch/latest/APIReference/API_LaunchTemplateSpecification.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_LaunchTemplateSpecification.html)API-Vorgang aufzuheben. Sie können sich auch dafür entscheiden, den `overrides` Parameter beim Absenden des `UpdateComputeEnvironment` API-Vorgangs nicht einzubeziehen. Weitere Informationen finden Sie unter [https://docs.aws.amazon.com/batch/latest/APIReference/API_LaunchTemplateSpecification.html#Batch-Type-LaunchTemplateSpecification-overrides](https://docs.aws.amazon.com/batch/latest/APIReference/API_LaunchTemplateSpecification.html#Batch-Type-LaunchTemplateSpecification-overrides)
Weitere Informationen finden Sie [https://docs.aws.amazon.com/batch/latest/APIReference/API_LaunchTemplateSpecificationOverride.html#Batch-Type-LaunchTemplateSpecificationOverride-targetInstanceTypes](https://docs.aws.amazon.com/batch/latest/APIReference/API_LaunchTemplateSpecificationOverride.html#Batch-Type-LaunchTemplateSpecificationOverride-targetInstanceTypes)im AWS Batch API-Referenzhandbuch.
## Amazon EC2 EC2-Benutzerdaten in Startvorlagen
Sie können Amazon EC2 EC2-Benutzerdaten in Ihrer Startvorlage angeben, die von [cloud-init ausgeführt wird, wenn Ihre Instances](https://cloudinit.readthedocs.io/en/latest/index.html) gestartet werden. Mit Ihren Benutzerdaten können gängige Konfigurationsszenarien durchgeführt werden, einschließlich, aber nicht beschränkt auf die folgenden:
+ [Einschließen von Benutzern oder Gruppen](https://cloudinit.readthedocs.io/en/latest/topics/examples.html#including-users-and-groups)
+ [Installieren von Paketen](https://cloudinit.readthedocs.io/en/latest/topics/examples.html#install-arbitrary-packages)
+ [Erstellen von Partitionen und Dateisystemen](https://cloudinit.readthedocs.io/en/latest/topics/examples.html#create-partitions-and-filesystems)
Amazon EC2 EC2-Benutzerdaten in Startvorlagen müssen im [mehrteiligen MIME-Archivformat](https://cloudinit.readthedocs.io/en/latest/topics/format.html#mime-multi-part-archive) vorliegen. Das liegt daran, dass Ihre Benutzerdaten mit anderen AWS Batch Benutzerdaten zusammengeführt werden, die für die Konfiguration Ihrer Rechenressourcen erforderlich sind. Sie können mehrere Benutzerdatenblöcke in einer einzelnen mehrteiligen MIME-Datei kombinieren. Beispielsweise möchten Sie vielleicht einen Cloud-Boothook, der den Docker-Daemon konfiguriert, mit einem Benutzerdaten-Shell-Skript kombinieren, das Konfigurationsinformationen für den Amazon ECS-Container-Agenten schreibt.
Wenn Sie den [AWS::CloudFormation::Init](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-init.html)Typ verwenden AWS CloudFormation, kann er zusammen mit dem Hilfsskript [cfn-init](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-init.html) verwendet werden, um allgemeine Konfigurationsszenarien durchzuführen.
Eine mehrteilige MIME-Datei umfasst folgende Komponenten:
+ Deklaration von Inhaltstyp und Teilgrenze: `Content-Type: multipart/mixed; boundary="==BOUNDARY=="`
+ Deklaration der MIME-Version: `MIME-Version: 1.0`
+ Ein oder mehrere Benutzerdatenblöcke, die die folgenden Komponenten enthalten:
+ Die Öffnungsgrenze, die den Beginn eines Benutzerdatenblocks signalisiert:`--==BOUNDARY==`. Sie müssen die Zeile vor dieser Grenze leer lassen.
+ Die Inhaltstypdeklaration für den Block: `Content-Type: text/cloud-config; charset="us-ascii"`. Weitere Informationen zu Inhaltstypen finden Sie in der [Cloud-Init-Dokumentation](https://cloudinit.readthedocs.io/en/latest/topics/format.html). Sie müssen die Zeile nach der Inhaltstyp-Deklaration leer lassen.
+ Der Inhalt der Benutzerdaten, z. B. eine Liste von Shell-Befehlen oder `cloud-init` -Direktiven.
+ Die schließende Grenze, die das Ende der mehrteiligen MIME-Datei signalisiert:`--==BOUNDARY==--`. Sie müssen die Zeile vor der schließenden Grenze leer lassen.
**Anmerkung**
Wenn Sie Benutzerdaten zu einer Startvorlage in der Amazon EC2 EC2-Konsole hinzufügen, können Sie sie als Klartext einfügen. Oder Sie können es aus einer Datei hochladen. Wenn Sie das AWS CLI oder ein AWS SDK verwenden, müssen Sie zuerst die Benutzerdaten `base64` codieren und diese Zeichenfolge beim Aufrufen als Wert des `UserData` Parameters angeben [CreateLaunchTemplate](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateLaunchTemplate.html), wie in dieser JSON-Datei gezeigt.
```
{
"LaunchTemplateName": "base64-user-data",
"LaunchTemplateData": {
"UserData": "ewogICAgIkxhdW5jaFRlbXBsYXRlTmFtZSI6ICJpbmNyZWFzZS1jb250YWluZXItdm9sdW..."
}
}
```
**Topics**
+ [Startvorlagen als Standard festlegen und überschreiben](#default-lt-and-overrides)
+ [Amazon EC2 EC2-Benutzerdaten in Startvorlagen](#lt-user-data)
+ [Referenz: Beispiele für Amazon EC2 EC2-Startvorlagen](launch-template-examples.md)
# Referenz: Beispiele für Amazon EC2 EC2-Startvorlagen
Im Folgenden finden Sie mehrteilige MIME-Beispieldateien, mit denen Sie Ihre eigenen Vorlagen erstellen können.
**Topics**
+ [Beispiel: Mounten Sie ein vorhandenes Amazon EFS-Dateisystem](#example-mount-an-existing-amazon-efs-file-system)
+ [Beispiel: Standardkonfiguration des Amazon ECS-Container-Agenten überschreiben](#example-override-default-amazon-ecs-container-agent-configuration)
+ [Beispiel: Mounten Sie ein vorhandenes Amazon FSx for Lustre-Dateisystem](#example-mount-an-existing-amazon-fsx-for-lustre-file-system)
## Beispiel: Mounten Sie ein vorhandenes Amazon EFS-Dateisystem
**Example**
Diese mehrteilige MIME-Beispieldatei konfiguriert die Rechenressource für die Installation des `amazon-efs-utils` Pakets und das Mounten eines vorhandenen Amazon EFS-Dateisystems unter. `/mnt/efs`
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="
--==MYBOUNDARY==
Content-Type: text/cloud-config; charset="us-ascii"
packages:
- amazon-efs-utils
runcmd:
- file_system_id_01=fs-abcdef123
- efs_directory=/mnt/efs
- mkdir -p ${efs_directory}
- echo "${file_system_id_01}:/ ${efs_directory} efs tls,_netdev" >> /etc/fstab
- mount -a -t efs defaults
--==MYBOUNDARY==--
```
## Beispiel: Standardkonfiguration des Amazon ECS-Container-Agenten überschreiben
**Example**
Diese mehrteilige MIME-Beispieldatei überschreibt die standardmäßigen Cleanup-Einstellungen des Docker-Images für eine Datenverarbeitungsressource.
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="
--==MYBOUNDARY==
Content-Type: text/x-shellscript; charset="us-ascii"
#!/bin/bash
echo ECS_IMAGE_CLEANUP_INTERVAL=60m >> /etc/ecs/ecs.config
echo ECS_IMAGE_MINIMUM_CLEANUP_AGE=60m >> /etc/ecs/ecs.config
--==MYBOUNDARY==--
```
## Beispiel: Mounten Sie ein vorhandenes Amazon FSx for Lustre-Dateisystem
**Example**
In dieser mehrteiligen MIME-Beispieldatei wird die Rechenressource so konfiguriert, dass sie das `lustre2.10` Paket aus der Extras-Bibliothek installiert und ein FSx für Lustre vorhandenes Dateisystem mit dem Mount-Namen `/scratch` einhängt. `fsx` Dieses Beispiel bezieht sich auf Amazon Linux 2. Installationsanweisungen für andere Linux-Distributionen finden Sie unter [Installation des Lustre-Clients](https://docs.aws.amazon.com/fsx/latest/LustreGuide/install-lustre-client.html) im *Amazon FSx for Lustre-Benutzerhandbuch*. Weitere Informationen finden Sie unter [Automatisches Mounten Ihres FSx Amazon-Dateisystems](https://docs.aws.amazon.com/fsx/latest/LustreGuide/mount-fs-auto-mount-onreboot.html) im *Amazon FSx for Lustre-Benutzerhandbuch*.
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="
--==MYBOUNDARY==
Content-Type: text/cloud-config; charset="us-ascii"
runcmd:
- file_system_id_01=fs-0abcdef1234567890
- region=us-east-2
- fsx_directory=/scratch
- amazon-linux-extras install -y lustre2.10
- mkdir -p ${fsx_directory}
- mount -t lustre ${file_system_id_01}.fsx.${region}.amazonaws.com@tcp:fsx ${fsx_directory}
--==MYBOUNDARY==--
```
Bei den Mitgliedern [volumes](https://docs.aws.amazon.com/batch/latest/APIReference/API_ContainerProperties.html#Batch-Type-ContainerProperties-volumes) und [mountPoints](https://docs.aws.amazon.com/batch/latest/APIReference/API_ContainerProperties.html#Batch-Type-ContainerProperties-mountPoints) der Containereigenschaften müssen die Einhängepunkte dem Container zugeordnet sein.
```
{
"volumes": [
{
"host": {
"sourcePath": "/scratch"
},
"name": "Scratch"
}
],
"mountPoints": [
{
"containerPath": "/scratch",
"sourceVolume": "Scratch"
}
],
}
```
# Konfiguration des Instanz-Metadatendienstes (IMDS)
Der Instance Metadata Service (IMDS) stellt Metadaten zu Ihren EC2 Instances für Anwendungen bereit, die auf diesen Instances ausgeführt werden. Verwenden Sie IMDSv2 ihn für alle neuen Workloads und migrieren Sie bestehende Workloads von IMDSv1 zu, um die Sicherheit IMDSv2 zu verbessern. Weitere Informationen zu IMDS und zur Konfiguration von IMDS finden Sie unter [Verwenden von Instance-Metadaten zur Verwaltung Ihrer EC2 Instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html) und [Konfigurieren von Instance-Metadatenoptionen für neue Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-IMDS-new-instances.html) im * EC2 Amazon-Benutzerhandbuch*.
## Konfigurationsszenarien
Wählen Sie die passende Konfigurationsmethode basierend auf der Konfiguration Ihrer Rechenumgebung aus:
### Standard-AMI ohne Startvorlage
Wenn Sie das AWS Batch Standard-AMI verwenden und keine Startvorlage angeben, wählen Sie eine der folgenden Optionen:
1. **Verwenden Sie das Standard-AMI von Amazon Linux 2023** — Amazon Linux 2023 erfordert IMDSv2 standardmäßig. Wenn Sie Ihre Rechenumgebung erstellen, wählen Sie **Amazon Linux 2023** als Image-Typ aus.
1. ** IMDSv2 Konfiguration auf Kontoebene festlegen** — Konfigurieren Sie Ihr AWS Konto so, dass es IMDSv2 für alle neuen Instances erforderlich ist. Diese Einstellung wirkt sich auf alle neuen Instances aus, die Sie im Konto starten. Anweisungen finden Sie im * EC2 Amazon-Benutzerhandbuch* unter [ IMDSv2 Als Standard für das Konto festlegen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-IMDS-new-instances.html#set-imdsv2-account-defaults).
**Anmerkung**
Die IMDS-Konfiguration auf Kontoebene kann durch eine Startvorlage oder eine AMI-Konfiguration außer Kraft gesetzt werden. Einstellungen für Startvorlagen haben Vorrang vor Einstellungen auf Kontoebene.
### Benutzerdefiniertes AMI ohne Startvorlage
Wenn Sie ein benutzerdefiniertes AMI ohne Startvorlage verwenden, wählen Sie eine der folgenden Optionen:
1. **Amazon Linux 2023 als Basis verwenden** — Erstellen Sie Ihr benutzerdefiniertes AMI mit Amazon Linux 2023 als Basis-Image. Informationen zum Erstellen benutzerdefinierter Daten AMIs für Batch finden Sie unter[Tutorial: Erstellen Sie ein Compute-Ressourcen-AMI](create-batch-ami.md).
1. ** IMDSv2 In Ihrem benutzerdefinierten AMI konfigurieren** — Wenn Sie Ihr benutzerdefiniertes AMI erstellen, konfigurieren Sie es nach Bedarf IMDSv2. Anweisungen finden [Sie unter Konfigurieren von Instance-Metadatenoptionen für benutzerdefiniertes AMI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-IMDS-new-instances.html#configure-IMDS-new-instances-ami-configuration) im * EC2 Amazon-Benutzerhandbuch*.
1. ** IMDSv2 Konfiguration auf Kontoebene einrichten** — Konfigurieren Sie Ihr AWS Konto so, dass es IMDSv2 für alle neuen Instances erforderlich ist. Diese Einstellung wirkt sich auf alle neuen Instances aus, die Sie im Konto starten. Anweisungen finden Sie im * EC2 Amazon-Benutzerhandbuch* unter [ IMDSv2 Als Standard für das Konto festlegen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-IMDS-new-instances.html#set-imdsv2-account-defaults).
**Anmerkung**
Die IMDS-Konfiguration auf Kontoebene kann durch eine Startvorlage oder eine AMI-Konfiguration außer Kraft gesetzt werden. Einstellungen für Startvorlagen haben Vorrang vor Einstellungen auf Kontoebene.
### Verwenden von Startvorlagen
Wenn Sie Startvorlagen in Ihrer Rechenumgebung verwenden, fügen Sie Ihrer Startvorlage nach Bedarf Metadatenoptionen hinzu IMDSv2. Weitere Informationen zur Verwendung von Startvorlagen mit Batch finden Sie unter[Verwenden Sie Amazon EC2 EC2-Startvorlagen mit AWS Batch](launch-templates.md).
```
{
"LaunchTemplateName": "batch-imdsv2-template",
"VersionDescription": "IMDSv2 only template for Batch",
"LaunchTemplateData": {
"MetadataOptions": {
"HttpTokens": "required"
}
}
}
```
Erstellen Sie die Startvorlage mit der AWS CLI:
```
aws ec2 create-launch-template --cli-input-json file://imds-template.json
```
# EC2 Konfigurationen
AWS Batch verwendet Amazon ECS, optimiert AMIs für EC2 EC2 Spot-Computing-Umgebungen. Die Standardeinstellung ist [Amazon Linux 2](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html#al2ami) (`ECS_AL2`). Ab Januar 2026 wird die Standardeinstellung auf [AL2023](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html#al2023ami) () `ECS_AL2023` geändert.
AWS wird die Unterstützung für Amazon Linux 2 beenden. Wir empfehlen, AWS Batch Amazon ECS-Rechenumgebungen auf Amazon Linux 2023 zu migrieren, um optimale Leistung und Sicherheit zu gewährleisten. Weitere Informationen finden Sie unter [Amazon ECS Amazon Linux 2 AMI als veraltet](ecs-al2-ami-deprecation.md).
Wir empfehlen, bestehende Amazon Linux-basierte Rechenumgebungen auf Amazon Linux 2023 zu aktualisieren, um unvorhergesehene Workload-Unterbrechungen zu vermeiden und weiterhin Sicherheits- und andere Updates zu erhalten.
Hilfe bei der Migration AWS Batch vom Amazon Linux AMI zu Amazon Linux 2023 finden Sie unter [So migrieren Sie von ECS AL2 zu ECS AL2 023](ecs-migration-2023.md)
**Topics**
+ [So migrieren Sie von ECS AL2 zu ECS AL2 023](ecs-migration-2023.md)
# So migrieren Sie von ECS AL2 zu ECS AL2 023
AL2023 ist ein Linux-basiertes Betriebssystem, das entwickelt wurde, um eine sichere, stabile und leistungsstarke Umgebung für Ihre Cloud-Anwendungen bereitzustellen. Weitere Informationen zu den Unterschieden zwischen AL2 und AL2 023 finden Sie unter [Vergleichen von Amazon Linux 2023 und Amazon Linux 2](https://docs.aws.amazon.com/linux/al2023/ug/compare-with-al2.html) im *Amazon Linux 2023-Benutzerhandbuch*.
Ab Januar 2026 AWS Batch wird das Standard-AMI für neue Amazon ECS-Rechenumgebungen von Amazon Linux 2 auf Amazon Linux 2023 geändert, da der [Support für Amazon Linux 2](https://aws.amazon.com/amazon-linux-2/faqs/) eingestellt AWS wird. Das Standard-AMI wird verwendet, wenn Sie beim Erstellen einer neuen Rechenumgebung keinen Wert für das Feld [ImageType.ec2Configuration](https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html) angeben. Wir empfehlen, AWS Batch Amazon ECS-Rechenumgebungen auf Amazon Linux 2023 zu migrieren, um optimale Leistung und Sicherheit zu gewährleisten.
Je nachdem, wie Ihre Computerumgebung konfiguriert ist, können Sie einen der folgenden Upgrade-Pfade von AL2 bis AL2 023 verwenden.
**Führen Sie ein Upgrade mithilfe von Ec2Configuration durch. ImageType**
+ Wenn Sie keine Startvorlage oder Startvorlagen-Überschreibungen verwenden, ändern Sie [Ec2Configuration. ImageType](https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html#Batch-Type-Ec2Configuration-imageType)zu `ECS_AL2023` (oder `ECS_AL2023_NVIDIA` bei Verwendung von GPU-Instanzen) und dann ausführen. [UpdateComputeEnvironment](https://docs.aws.amazon.com/batch/latest/APIReference/API_UpdateComputeEnvironment.html)
+ Wenn Sie eine [Ec2Configuration angeben. ](https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html#Batch-Type-Ec2Configuration-imageIdOverride)ImageIdOverride[dann Ec2Configuration. ImageType](https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html#Batch-Type-Ec2Configuration-imageType)muss dem in [Ec2Configuration angegebenen AMI-Typ entsprechen. ImageIdOverride](https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html#Batch-Type-Ec2Configuration-imageIdOverride).
Wenn Sie nicht übereinstimmen`ImageIdOverride`, `ImageType` funktioniert die Rechenumgebung möglicherweise nicht richtig.
**Führen Sie ein Upgrade mithilfe von Startvorlagen durch**
+ Wenn Sie eine Startvorlage verwenden, die ein AMI angibt, das auf basiert`ECS_AL2023`, stellen Sie sicher, dass Ihre Startvorlage mit Amazon Linux 2023 kompatibel ist. *Informationen zu Änderungen in Amazon Linux 2023 für Amazon ECS-optimiertes AMI finden Sie unter [Migration von einem Amazon Linux 2 zu einem Amazon ECS-optimierten AMI für Amazon Linux 2023 im Amazon ECS-Benutzerhandbuch](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/al2-to-al2023-ami-transition.html).*
+ Stellen Sie für AL2 023 sicher AMIs, dass alle benutzerdefinierten Benutzerdaten oder Initialisierungsskripts mit der 023-Umgebung und dem AL2 Paketverwaltungssystem kompatibel sind.
**Führen Sie ein Upgrade durch CloudFormation**
+ Wenn Sie Ihre Rechenumgebungen CloudFormation zur Verwaltung verwenden, aktualisieren Sie Ihre Vorlage, um die `ImageType` Eigenschaft im Feld `Ec2Configuration` von `ECS_AL2` bis zu `ECS_AL2023` (oder `ECS_AL2023_NVIDIA` bei Verwendung von GPU-Instanzen) zu ändern:
```
ComputeEnvironment:
Type: AWS::Batch::ComputeEnvironment
Properties:
ComputeResources:
Ec2Configuration:
- ImageType: ECS_AL2023
```
Aktualisieren Sie dann Ihren CloudFormation Stack, um die Änderungen zu übernehmen.
+ Wenn in Ihrer CloudFormation Vorlage ein benutzerdefiniertes AMI angegeben ist`ImageIdOverride`, stellen Sie sicher, dass die AMI-ID einem AL2 023-basierten AMI entspricht und der `ImageType` Einstellung entspricht.
## Überlegungen zur Migration
Beachten Sie bei der Migration von Amazon Linux 2 zu Amazon Linux 2023 Folgendes:
+ **Paketverwaltung** — Amazon Linux 2023 verwendet `dnf` statt `yum` für die Paketverwaltung.
+ **Systemdienste** — Einige Systemdienste und ihre Konfigurationen können sich zwischen AL2 0 AL2 und 023 unterscheiden.
+ **Container-Laufzeit** — AL2 Sowohl als auch AL2 023 unterstützen Docker, aber AL2 023 kann unterschiedliche Standardkonfigurationen haben.
+ **Sicherheit** — AL2 023 beinhaltet erweiterte Sicherheitsfunktionen und erfordert möglicherweise Aktualisierungen sicherheitsrelevanter Konfigurationen.
+ **Instanz-Metadatendienst Version 2 (IMDSv2)** — IMDSv2 ist ein sitzungsorientierter Dienst, der eine tokenbasierte Authentifizierung für den Zugriff auf EC2 Instanz-Metadaten erfordert und so erhöhte Sicherheit bietet. Weitere Informationen zu IMDS finden Sie unter und [So funktioniert der Instance Metadata Service Version 2](https://docs.aws.amazon.com/configuring-instance-metadata-service.html#instance-metadata-v2-how-it-works) im * EC2 Amazon-Benutzerhandbuch*.
Eine umfassende Liste der Änderungen und Überlegungen zur Migration finden Sie unter [Migration von einem Amazon Linux 2 zu einem Amazon ECS-optimierten AMI für Amazon Linux 2023 im *Amazon ECS-Benutzerhandbuch*](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/al2-to-al2023-ami-transition.html).
# Strategien zur Zuweisung von Instance-Typen für AWS Batch
Wenn eine verwaltete Rechenumgebung erstellt wird, AWS Batch wählt sie aus den `[instanceTypes](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResource.html#Batch-Type-ComputeResource-instanceTypes)` angegebenen Instanztypen aus, die den Anforderungen der Jobs am besten entsprechen. Die Zuweisungsstrategie definiert das Verhalten, wenn zusätzliche Kapazität AWS Batch benötigt wird. Dieser Parameter ist nicht auf Aufträge anwendbar, die auf Fargate-Ressourcen ausgeführt werden. Geben Sie diesen Parameter nicht an.
`BEST_FIT` (Standard)
AWS Batch wählt einen Instance-Typ aus, der den Anforderungen der Jobs am besten entspricht, wobei der Instance-Typ mit den niedrigsten Kosten bevorzugt wird. Wenn zusätzliche Instanzen des ausgewählten Instanztyps nicht verfügbar sind, AWS Batch wartet es, bis die zusätzlichen Instanzen verfügbar sind. Wenn nicht genügend Instances verfügbar sind oder wenn der Benutzer die [ EC2 Amazon-Servicekontingente](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) erreicht, werden zusätzliche Jobs erst ausgeführt, wenn die aktuell ausgeführten Jobs abgeschlossen sind. Diese Zuweisungsstrategie hält die Kosten niedriger, kann aber die Skalierung einschränken. Wenn Sie Spot-Flotten mit verwenden`BEST_FIT`, muss die IAM-Rolle Spot-Flotte angegeben werden. `BEST_FIT`wird bei der Aktualisierung von Rechenumgebungen nicht unterstützt. Weitere Informationen finden Sie unter [Aktualisieren Sie eine Rechenumgebung in AWS Batch](updating-compute-environments.md).
AWS Batch verwaltet AWS Ressourcen in Ihrem Konto. Computerumgebungen mit der BEST\$1FIT-Zuweisungsstrategie verwendeten ursprünglich standardmäßig Startkonfigurationen. Die Verwendung von Startkonfigurationen mit neuen AWS Konten wird jedoch im Laufe der Zeit eingeschränkt. Daher werden neu erstellte BEST\$1FIT-Rechenumgebungen ab Ende April 2024 standardmäßig Vorlagen starten. Falls Ihre Servicerolle nicht über die erforderlichen Berechtigungen zur Verwaltung von Startvorlagen verfügt, AWS Batch können Sie weiterhin Startkonfigurationen verwenden. Bestehende Computerumgebungen werden weiterhin Startkonfigurationen verwenden.
`BEST_FIT_PROGRESSIVE`
AWS Batch wählt zusätzliche Instanztypen aus, die groß genug sind, um die Anforderungen der Jobs in der Warteschlange zu erfüllen. Instanztypen mit niedrigeren Kosten für jede vCPU-Einheit werden bevorzugt. Wenn zusätzliche Instanzen der zuvor ausgewählten Instanztypen nicht verfügbar sind, AWS Batch wählt neue Instanztypen aus.
AWS Batch Wählt für [parallel Jobs mit mehreren Knoten](multi-node-parallel-jobs.md#multi-node-parallel-jobs.title) den optimalen verfügbaren Instanztyp aus. Wenn der Instance-Typ aufgrund unzureichender Kapazität nicht mehr verfügbar ist, werden andere Instance-Typen innerhalb der Familie nicht gestartet.
`SPOT_CAPACITY_OPTIMIZED`
AWS Batch wählt einen oder mehrere Instance-Typen aus, die groß genug sind, um die Anforderungen der Jobs in der Warteschlange zu erfüllen. Instanztypen, bei denen die Wahrscheinlichkeit einer Unterbrechung geringer ist, werden bevorzugt. Diese Zuweisungsstrategie ist nur für Spot-Instance-Datenverarbeitungsressourcen verfügbar.
`SPOT_PRICE_CAPACITY_OPTIMIZED`
Die preis- und kapazitätsoptimierte Zuweisungsstrategie betrachtet sowohl den Preis als auch die Kapazität, um die Spot-Instance-Pools auszuwählen, die am unwahrscheinlichsten unterbrochen werden und den niedrigstmöglichen Preis haben. Diese Zuweisungsstrategie ist nur für Spot-Instance-Datenverarbeitungsressourcen verfügbar.
Wir empfehlen, dass Sie `SPOT_PRICE_CAPACITY_OPTIMIZED` eher als `SPOT_CAPACITY_OPTIMIZED` in den meisten Fällen verwenden.
Die `BEST_FIT` Strategien `BEST_FIT_PROGRESSIVE` und verwenden On-Demand-Instances oder Spot-Instances, `SPOT_CAPACITY_OPTIMIZED` und die `SPOT_PRICE_CAPACITY_OPTIMIZED` Strategien verwenden Spot-Instances. AWS Batch Möglicherweise müssen diese jedoch überschritten werden, `maxvCpus` um Ihre Kapazitätsanforderungen zu erfüllen. Überschreitet `maxvCpus` in diesem Fall AWS Batch nie mehr als eine Instanz.
# Speicherverwaltung für Rechenressourcen
Wenn der Amazon ECS-Container-Agent eine Rechenressource in einer Rechenumgebung registriert, muss der Agent ermitteln, wie viel Speicher die Rechenressource zur Verfügung hat, um sie für Ihre Jobs zu reservieren. Aufgrund des Mehraufwands des Plattformspeichers und des vom Systemkernel belegten Speichers unterscheidet sich diese Zahl von der installierten Speichermenge für EC2 Amazon-Instances. Eine `m4.large`-Instance beispielsweise besitzt 8 GiB installierten Speicher. Dies entspricht jedoch nicht immer genau 8192 MiB Arbeitsspeicher, der für Jobs verfügbar ist, wenn die Rechenressource registriert wird.
Angenommen, Sie geben 8192 MiB für den Job an und für keine Ihrer Rechenressourcen stehen 8192 MiB oder mehr Arbeitsspeicher zur Verfügung, um diese Anforderung zu erfüllen. Dann kann der Job nicht in Ihrer Computerumgebung platziert werden. Wenn Sie eine verwaltete Rechenumgebung verwenden, AWS Batch müssen Sie einen größeren Instanztyp starten, um der Anfrage gerecht zu werden.
Das AWS Batch Standard-Rechenressourcen-AMI reserviert außerdem 32 MiB Speicher für den Amazon ECS-Container-Agenten und andere kritische Systemprozesse. Dieser Speicher ist für die Auftragszuweisung nicht verfügbar. Weitere Informationen finden Sie unter [Systemspeicher reservieren](ecs-reserved-memory.md).
Der Amazon-ECS-Container-Agent verwendet die Docker-Funktion `ReadMemInfo()` für die Abfrage des gesamten für das Betriebssystem verfügbaren Arbeitsspeichers. Linux stellt Befehlszeilenprogramme zur Verfügung, mit denen der Gesamtspeicher ermittelt werden kann.
**Example – Bestimmung des Gesamtspeichers für Linux**
Der **free** Befehl gibt den Gesamtspeicher zurück, der vom Betriebssystem erkannt wird.
```
$ free -b
```
Im Folgenden finden Sie eine Beispielausgabe für eine `m4.large` Instance, auf der das Amazon ECS-optimierte Amazon Linux AMI ausgeführt wird.
```
total used free shared buffers cached
Mem: 8373026816 348180480 8024846336 90112 25534464 205418496
-/+ buffers/cache: 117227520 8255799296
```
Diese Instance verfügt über einen Gesamtspeicher von 8373026816 Byte. Das bedeutet, dass 7985 MiB für Aufgaben zur Verfügung stehen.
**Topics**
+ [Systemspeicher reservieren](ecs-reserved-memory.md)
+ [Tutorial: Rechenressourcenspeicher anzeigen](viewing-memory.md)
+ [Überlegungen zu Arbeitsspeicher und vCPUs für AWS Batch Amazon EKS](memory-cpu-batch-eks.md)
# Systemspeicher reservieren
Wenn Sie mit Ihren Jobs den gesamten Arbeitsspeicher einer Rechenressource belegen, ist es möglich, dass Ihre Jobs mit kritischen Systemprozessen in Bezug auf den Arbeitsspeicher zu kämpfen haben und möglicherweise zu einem Systemausfall führen. Der Amazon ECS-Container-Agent stellt eine Konfigurationsvariable bereit, die aufgerufen wird`ECS_RESERVED_MEMORY`. Sie können diese Konfigurationsvariable verwenden, um eine bestimmte Anzahl von MiB Speicher aus dem Pool zu entfernen, der Ihren Jobs zugewiesen ist. Damit wird dieser Arbeitsspeicher für wichtige Systemprozesse reserviert.
Das AWS Batch Standard-Rechenressourcen-AMI reserviert 32 MiB Arbeitsspeicher für den Amazon ECS-Container-Agenten und andere kritische Systemprozesse. Wir empfehlen, einen Speicherpuffer von 5% für den Amazon ECS-Container-Agenten und andere kritische Systemprozesse zu reservieren.
# Tutorial: Rechenressourcenspeicher anzeigen
Sie können in der Amazon ECS-Konsole oder bei der [DescribeContainerInstances](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DescribeContainerInstances.html)API-Operation sehen, mit wie viel Speicher sich eine Rechenressource registriert. Wenn Sie versuchen, Ihre Ressourcennutzung zu maximieren, indem Sie Ihren Jobs so viel Speicher wie möglich für einen bestimmten Instance-Typ zur Verfügung stellen, können Sie den für diese Rechenressource verfügbaren Speicher beobachten und Ihren Jobs dann so viel Speicher zuweisen.
**Um den Arbeitsspeicher der Rechenressource anzuzeigen**
1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version](https://console.aws.amazon.com/ecs/v2) 2.
1. Wählen Sie **Cluster** und dann den Cluster aus, der Ihre anzuzeigenden Rechenressourcen hostet.
Der Cluster-Name für Ihre Computing-Umgebung beginnt mit dem Namen Ihrer Computing-Umgebung.
1. Wählen Sie **Infrastruktur** aus.
1. Wählen Sie unter **Container-Instances** die Container-Instance aus.
1. Im Abschnitt **Ressourcen und Netzwerke** wird der registrierte und verfügbare Speicher für die Rechenressource angezeigt.
Der Speicherwert für die **Gesamtkapazität** ist der Wert, den die Rechenressource bei Amazon ECS registriert hat, als sie zum ersten Mal gestartet wurde, und der Wert für **verfügbaren** Speicher ist der Wert, der noch keinen Aufträgen zugewiesen wurde.
# Überlegungen zu Arbeitsspeicher und vCPUs für AWS Batch Amazon EKS
In AWS Batch Amazon EKS können Sie die Ressourcen angeben, die einem Container zur Verfügung gestellt werden. Sie können beispielsweise `limits` OR-Werte für vCPU- und Speicherressourcen angeben`requests`.
Die folgenden Einschränkungen gelten für die Angabe von vCPU-Ressourcen:
+ Es muss mindestens eine vCPU `requests` oder ein `limits` Wert angegeben werden.
+ Eine vCPU-Einheit entspricht einem physischen oder virtuellen Kern.
+ Der vCPU-Wert muss in ganzen Zahlen oder in Schritten von 0,25 eingegeben werden.
+ Der kleinste gültige vCPU-Wert ist 0,25.
+ Wenn beide angegeben sind, muss der `requests` Wert kleiner oder gleich dem `limits` Wert sein. Auf diese Weise können Sie sowohl weiche als auch harte vCPU-Konfigurationen konfigurieren.
+ vCPU-Werte können nicht in MilliCPU-Form angegeben werden. `100m`Ist beispielsweise kein gültiger Wert.
+ AWS Batch verwendet den `requests` Wert für Skalierungsentscheidungen. Wenn kein `requests` Wert angegeben ist, wird der `limits` Wert in den `requests` Wert kopiert.
Die folgenden Einschränkungen gelten für die Angabe von Speicherressourcen:
+ Es muss mindestens ein Speicher `requests` oder `limits` Wert angegeben werden.
+ Speicherwerte müssen in mebibytes (MiBs) angegeben werden.
+ Wenn beide angegeben sind, muss der `requests` Wert dem `limits` Wert entsprechen.
+ AWS Batch verwendet den `requests` Wert für Skalierungsentscheidungen. Wenn kein `requests` Wert angegeben ist, wird der `limits` Wert in den `requests` Wert kopiert.
Die folgenden Einschränkungen gelten für die Angabe von GPU-Ressourcen:
+ Wenn beide angegeben sind, muss der `requests` Wert dem `limits` Wert entsprechen.
+ AWS Batch verwendet den `requests` Wert für Skalierungsentscheidungen. Wenn kein `requests` Wert angegeben ist, wird der `limits` Wert in den `requests` Wert kopiert.
## Beispiel: Jobdefinitionen
Mit der folgenden Jobdefinition in AWS Batch Amazon EKS werden Soft-vCPU-Shares konfiguriert. Dadurch kann AWS Batch Amazon EKS die gesamte vCPU-Kapazität für den Instance-Typ nutzen. Wenn jedoch andere Jobs ausgeführt werden, wird dem Job ein Maximum von `2` v CPUs zugewiesen. Der Arbeitsspeicher ist auf 2 GB begrenzt.
```
{
"jobDefinitionName": "MyJobOnEks_Sleep",
"type": "container",
"eksProperties": {
"podProperties": {
"containers": [
{
"image": "public.ecr.aws/amazonlinux/amazonlinux:2",
"command": ["sleep", "60"],
"resources": {
"requests": {
"cpu": "2",
"memory": "2048Mi"
}
}
}
]
}
}
}
```
Die folgende Auftragsdefinition in AWS Batch Amazon EKS hat einen `request` Wert von `1` und weist dem Auftrag ein Maximum von `4` v CPUs zu.
```
{
"jobDefinitionName": "MyJobOnEks_Sleep",
"type": "container",
"eksProperties": {
"podProperties": {
"containers": [
{
"image": "public.ecr.aws/amazonlinux/amazonlinux:2",
"command": ["sleep", "60"],
"resources": {
"requests": {
"cpu": "1"
},
"limits": {
"cpu": "4",
"memory": "2048Mi"
}
}
}
]
}
}
}
```
Die folgende Auftragsdefinition in AWS Batch Amazon EKS legt einen `limits` vCPU-Wert von `1` und einen `limits` Speicherwert von 1 GB fest.
```
{
"jobDefinitionName": "MyJobOnEks_Sleep",
"type": "container",
"eksProperties": {
"podProperties": {
"containers": [
{
"image": "public.ecr.aws/amazonlinux/amazonlinux:2",
"command": ["sleep", "60"],
"resources": {
"limits": {
"cpu": "1",
"memory": "1024Mi"
}
}
}
]
}
}
}
```
Wenn ein Job AWS Batch auf Amazon EKS in einen Amazon EKS-Pod AWS Batch übersetzt wird, wird der `limits` Wert in den `requests` Wert AWS Batch kopiert. Dies ist der Fall, wenn kein `requests` Wert angegeben ist. Wenn Sie die obige Beispiel-Jobdefinition einreichen, sieht der Pod wie `spec` folgt aus.
```
apiVersion: v1
kind: Pod
...
spec:
...
containers:
- command:
- sleep
- 60
image: public.ecr.aws/amazonlinux/amazonlinux:2
resources:
limits:
cpu: 1
memory: 1024Mi
requests:
cpu: 1
memory: 1024Mi
...
```
## CPU- und Speicherreservierungen für Knoten
AWS Batch stützt sich auf die Standardlogik der `bootstrap.sh` Datei für vCPU- und Speicherreservierungen. Weitere Informationen zur `bootstrap.sh` Datei finden Sie unter [bootstrap.sh](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh). Beachten Sie bei der Dimensionierung Ihrer vCPU- und Speicherressourcen die folgenden Beispiele.
**Anmerkung**
Wenn keine Instances ausgeführt werden, können sich vCPU- und Speicherreservierungen zunächst auf die AWS Batch Skalierungslogik und die Entscheidungsfindung auswirken. AWS Batch Passt die anfänglichen Zuweisungen an, nachdem die Instanzen ausgeführt wurden.
## Beispiel: CPU-Reservierung eines Knotens
Der CPU-Reservierungswert wird in Millikernen berechnet, wobei die Gesamtzahl der V verwendet wirdCPUs , die für die Instanz verfügbar sind.
| vCPU-Nummer | Prozentsatz reserviert |
| --- | --- |
| 1 | 6% |
| 2 | 1% |
| 3-4 | 0.5% |
| 4 und höher | 0,25% |
Unter Verwendung der vorherigen Werte ist Folgendes wahr:
+ Der CPU-Reservierungswert für eine `c5.large` Instance mit 2 v CPUs ist 70 m. Dies wird auf folgende Weise berechnet: *(1\$160) \$1 (1\$110)* = 70 m.
+ Der CPU-Reservierungswert für eine `c5.24xlarge` Instanz mit 96 v beträgt 310 m. CPUs Dies wird auf folgende Weise berechnet: (1\$160) \$1 (1\$110) \$1 (2\$15) \$1 (92\$12,5) = 310 m.
In diesem Beispiel stehen 1930 (berechnete 2000-70) Millicore-vCPU-Einheiten zur Ausführung von Jobs auf einer Instance zur Verfügung. `c5.large` Angenommen, Ihr Job erfordert `2` (2\$11000 m) vCPU-Einheiten, der Job passt nicht auf eine einzelne Instanz. `c5.large` Ein Job, der `1.75` vCPU-Einheiten erfordert, passt jedoch.
## Beispiel: Speicherreservierung für Knoten
Der Wert für die Speicherreservierung wird wie folgt in Mebibyte berechnet:
+ Die Instanzkapazität in Mebibyte. Eine 8-GB-Instance ist beispielsweise 7.748. MiB
+ Der `kubeReserved` Wert. Der `kubeReserved` Wert ist die Speichermenge, die für System-Daemons reserviert werden soll. Der `kubeReserved` Wert wird auf folgende Weise berechnet: *((11 \$1 maximale Anzahl von Pods, die vom Instance-Typ unterstützt wird) \$1 255)*. Informationen zur maximalen Anzahl von Pods, die von einem Instance-Typ unterstützt werden, finden Sie unter [eni-max-pods.txt](https://github.com/awslabs/amazon-eks-ami/blob/main/nodeadm/internal/kubelet/eni-max-pods.txt)
+ Der `HardEvictionLimit` Wert. Wenn der verfügbare Speicher unter den `HardEvictionLimit` Wert fällt, versucht die Instance, Pods zu entfernen.
Die Formel zur Berechnung des zuweisbaren Speichers lautet wie folgt: (*instance\$1capacity\$1in\$1MiB*) - (11 \$1 (*maximum\$1number\$1of\$1pods*)) - 255 - ()). *`HardEvictionLimit` value.*
Eine `c5.large` Instanz unterstützt bis zu 29 Pods. Für eine `c5.large` 8-GB-Instance mit einem `HardEvictionLimit` Wert von 100 MiB beträgt der zuweisbare Speicher 7074. MiB Dies wird wie folgt berechnet: *(7748 - (11 \$1 29) -255 -100) =* 7074 MiB. In diesem Beispiel passt ein 8.192 MiB Job nicht auf diese Instanz, obwohl es sich um eine 8 () -Instanz handelt. gibibyte GiB
## DaemonSets
Beachten Sie bei der Verwendung DaemonSets Folgendes:
+ Wenn AWS Batch auf Amazon EKS keine Instances ausgeführt werden, DaemonSets kann dies zunächst Auswirkungen auf die AWS Batch Skalierungslogik und die Entscheidungsfindung haben. AWS Batch weist zunächst 0,5 vCPU-Einheiten und 500 MiB für die erwarteten Werte zu. DaemonSets AWS Batch Passt die anfänglichen Zuweisungen an, nachdem die Instanzen ausgeführt wurden.
+ Wenn a vCPU- oder Speicherlimits DaemonSet definiert, haben Jobs AWS Batch auf Amazon EKS weniger Ressourcen. Wir empfehlen, die Anzahl der Aufträge, die AWS Batch Jobs zugewiesen sindDaemonSets, so gering wie möglich zu halten.
# Fargate-Computerumgebungen
Fargate ist eine Technologie, mit der Sie [Container](https://aws.amazon.com/what-are-containers) ausführen können AWS Batch , ohne Server oder Cluster von Amazon EC2 EC2-Instances verwalten zu müssen. Mit Fargate müssen Sie keine Cluster virtueller Maschinen mehr bereitstellen, konfigurieren oder skalieren, um Container auszuführen. Auf diese Weise müssen keine Servertypen mehr ausgewählt werden, es muss nicht entschieden werden, wann die Cluster skaliert werden oder das Cluster-Packing optimiert werden.
Wenn Sie Ihre Jobs mit Fargate-Ressourcen ausführen, verpacken Sie Ihre Anwendung in Containern, geben die CPU- und Speicheranforderungen an, definieren Netzwerk- und IAM-Richtlinien und starten die Anwendung. Jeder Fargate-Job hat seine eigene Isolationsgrenze und teilt den zugrunde liegenden Kernel, die CPU-Ressourcen, Speicherressourcen oder die elastic network interface nicht mit einem anderen Job.
**Topics**
+ [Wann sollte Fargate verwendet werden](when-to-use-fargate.md)
+ [Jobdefinitionen bei Fargate](fargate-job-definitions.md)
+ [Warteschlangen für Job auf Fargate](fargate-job-queues.md)
+ [Rechenumgebungen auf Fargate](fargate-compute-environments.md)
# Wann sollte Fargate verwendet werden
Wir empfehlen die Verwendung von Fargate in den meisten Szenarien. Fargate startet und skaliert die Berechnung so, dass sie den Ressourcenanforderungen, die Sie für den Container angeben, genau entspricht. Mit Fargate müssen Sie nicht zu viele Server bereitstellen oder für zusätzliche Server bezahlen. Sie müssen sich auch keine Gedanken über die Besonderheiten infrastrukturbezogener Parameter wie den Instance-Typ machen. Wenn die Rechenumgebung skaliert werden muss, können Jobs, die auf Fargate-Ressourcen ausgeführt werden, schneller gestartet werden. In der Regel dauert es einige Minuten, eine neue Amazon EC2 EC2-Instance hochzufahren. Jobs, die auf Fargate ausgeführt werden, können jedoch in etwa 30 Sekunden bereitgestellt werden. Die genaue benötigte Zeit hängt von mehreren Faktoren ab, darunter der Größe des Container-Images und der Anzahl der Jobs.
Wir empfehlen Ihnen jedoch, Amazon EC2 zu verwenden, wenn Ihre Jobs eine der folgenden Voraussetzungen erfordern:
+ Mehr als 16 V CPUs
+ Mehr als 120 Gibibyte (GiB) Speicher
+ EINE GPU
+ Ein benutzerdefiniertes Amazon Machine Image (AMI)
+ Jeder der [LinuxParameter-Parameter](job_definition_parameters.md#ContainerProperties-linuxParameters)
Wenn Sie eine große Anzahl von Jobs haben, empfehlen wir Ihnen, die Amazon EC2 EC2-Infrastruktur zu verwenden. Zum Beispiel, wenn die Anzahl der gleichzeitig ausgeführten Jobs die Drosselungsgrenzen von Fargate überschreitet. Dies liegt daran, dass mit EC2 Jobs schneller an EC2-Ressourcen als an Fargate-Ressourcen weitergeleitet werden können. Außerdem können mehr Jobs gleichzeitig ausgeführt werden, wenn Sie EC2 verwenden. Weitere Informationen finden Sie unter [Fargate Service Quotas](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-quotas.html#service-quotas-fargate) im *Amazon Elastic Container Service Developer Guide*.
# Jobdefinitionen bei Fargate
AWS Batch jobs on unterstützt AWS Fargate nicht alle verfügbaren Jobdefinitionsparameter. Einige Parameter werden überhaupt nicht unterstützt, und andere verhalten sich für Fargate-Jobs anders.
In der folgenden Liste werden Jobdefinitionsparameter beschrieben, die in Fargate-Aufträgen nicht gültig oder anderweitig eingeschränkt sind.
`platformCapabilities`
Muss als `FARGATE` angegeben werden.
```
"platformCapabilities": [ "FARGATE" ]
```
`type`
Muss als angegeben werden`container`.
```
"type": "container"
```
Parameter in `containerProperties`
`executionRoleArn`
Muss für Jobs angegeben werden, die auf Fargate-Ressourcen ausgeführt werden. Weitere Informationen finden Sie unter [IAM-Rollen für Aufgaben](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html) im *Entwicklerhandbuch zum Amazon Elastic Container Service*.
```
"executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole"
```
`fargatePlatformConfiguration`
(Optional, nur für Fargate-Jobdefinitionen). Gibt die Fargate-Plattformversion oder `LATEST` für eine aktuelle Plattformversion an. Mögliche Werte für `platformVersion` sind `1.3.0``1.4.0`, und `LATEST` (Standard).
```
"fargatePlatformConfiguration": { "platformVersion": "1.4.0" }
```
`instanceType``ulimits`
Gilt nicht für Jobs, die auf Fargate-Ressourcen ausgeführt werden.
`memory``vcpus`
Diese Einstellungen müssen in angegeben werden `resourceRequirements`
`privileged`
Geben Sie diesen Parameter entweder nicht an oder geben Sie an`false`.
```
"privileged": false
```
`resourceRequirements`
Sowohl die Speicher- als auch die vCPU-Anforderungen müssen mit [unterstützten Werten](job_definition_parameters.md#ContainerProperties-resourceRequirements-Fargate-memory-vcpu) angegeben werden. GPU-Ressourcen werden für Jobs, die auf Fargate-Ressourcen ausgeführt werden, nicht unterstützt.
Wenn Sie GuardDuty Runtime Monitoring verwenden, entsteht ein geringer Speicheraufwand für den GuardDuty Security Agent. Daher muss das Speicherlimit die Größe des GuardDuty Security Agents beinhalten. Informationen zu den Speicherlimits des GuardDuty Security Agents finden Sie unter [CPU- und Speicherlimits](https://docs.aws.amazon.com/guardduty/latest/ug/prereq-runtime-monitoring-ecs-support.html#ecs-runtime-agent-cpu-memory-limits) im *GuardDuty Benutzerhandbuch*. Informationen zu den bewährten Methoden finden Sie im *Amazon ECS-Entwicklerhandbuch* unter [Wie behebe ich Fehler bei Speichermangel bei meinen Fargate-Aufgaben nach der Aktivierung von Runtime Monitoring](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-guard-duty-troubleshooting.html#memory-error)?.
```
"resourceRequirements": [
{"type": "MEMORY", "value": "512"},
{"type": "VCPU", "value": "0.25"}
]
```
Parameter in `linuxParameters`
`devices``maxSwap``sharedMemorySize``swappiness``tmpfs`
Gilt nicht für Jobs, die auf Fargate-Ressourcen ausgeführt werden.
Parameter in `logConfiguration`
`logDriver`
Es werden ausschließlich `awslogs` und `splunk` unterstützt. Weitere Informationen finden Sie unter [Verwenden Sie den awslogs-Protokolltreiber](using_awslogs.md).
Mitglieder in `networkConfiguration`
`assignPublicIp`
Wenn an das private Subnetz kein NAT-Gateway angeschlossen ist, um Datenverkehr ins Internet zu senden, `[assignPublicIp](https://docs.aws.amazon.com/batch/latest/APIReference/API_NetworkConfiguration.html#Batch-Type-NetworkConfiguration-assignPublicIp)` muss "`ENABLED`" angegeben werden. Weitere Informationen finden Sie unter [AWS Batch Rolle „IAM-Ausführung“](execution-IAM-role.md).
# Warteschlangen für Job auf Fargate
AWS Batch Die Jobwarteschlangen an AWS Fargate sind im Wesentlichen unverändert. Die einzige Einschränkung besteht darin, dass die Rechenumgebungen, die in aufgeführt sind, alle Fargate-Rechenumgebungen (`FARGATE`oder`FARGATE_SPOT`) sein `computeEnvironmentOrder` müssen. EC2- und Fargate-Rechenumgebungen können nicht gemischt werden.
# Rechenumgebungen auf Fargate
AWS Batch Rechenumgebungen, die aktiviert sind, unterstützen AWS Fargate nicht alle verfügbaren Parameter der Rechenumgebung. Einige Parameter werden überhaupt nicht unterstützt. Andere haben spezielle Anforderungen für Fargate.
In der folgenden Liste werden Computing-Umgebungsparameter beschrieben, die in Fargate-Jobs nicht gültig oder anderweitig eingeschränkt sind.
`type`
Dieser Parameter muss sein. `MANAGED`
```
"type": "MANAGED"
```
Parameter im `computeResources` Objekt
`allocationStrategy``bidPercentage``desiredvCpus``imageId``instanceTypes``ec2Configuration``ec2KeyPair``instanceRole``launchTemplate``minvCpus``placementGroup``spotIamFleetRole`
Diese gelten nicht für Fargate-Rechenumgebungen und können nicht bereitgestellt werden.
`subnets`
Wenn an die in diesem Parameter aufgeführten Subnetze keine NAT-Gateways angeschlossen sind, muss der `assignPublicIp` Parameter in der Jobdefinition auf gesetzt werden. `ENABLED`
`tags`
Dies gilt nicht für Fargate-Rechenumgebungen und kann nicht bereitgestellt werden. Um Tags für Fargate-Rechenumgebungen anzugeben, verwenden Sie den `tags` Parameter, der nicht im `computeResources` Objekt enthalten ist.
`type`
Muss entweder `FARGATE` oder `FARGATE_SPOT` sein.
```
"type": "FARGATE_SPOT"
```
# Amazon EKS-Rechenumgebungen
[Erste Schritte mit AWS Batch Amazon EKS](getting-started-eks.md)bietet eine kurze Anleitung zur Erstellung von EKS-Rechenumgebungen. Dieser Abschnitt enthält weitere Informationen zu Amazon EKS-Rechenumgebungen.
![\[AWS Batch workflow diagram showing integration with Amazon EKS, ECS, Fargate, and EC2.\]](http://docs.aws.amazon.com/de_de/batch/latest/userguide/images/batch-on-eks.png)
AWS Batch vereinfacht Ihre Batch-Workloads auf Amazon EKS-Clustern durch die Bereitstellung verwalteter Batch-Funktionen. Dazu gehören Warteschlangen, Abhängigkeitsverfolgung, verwaltete Auftragswiederholungen und Prioritäten, Pod-Verwaltung und Knotenskalierung. AWS Batch kann mehrere Availability Zones und mehrere Amazon EC2 EC2-Instance-Typen und -Größen verarbeiten. AWS Batch integriert mehrere der Best Practices von Amazon EC2 Spot, um Ihre Workloads fehlertolerant auszuführen und so weniger Unterbrechungen zu ermöglichen. Sie können AWS Batch damit problemlos eine Handvoll Jobs über Nacht oder Millionen von geschäftskritischen Jobs ausführen.
![\[AWS Batch workflow on Amazon EKS, showing job queue, compute environment, and EC2 instances.\]](http://docs.aws.amazon.com/de_de/batch/latest/userguide/images/batch-on-eks-detail.png)
AWS Batch ist ein verwalteter Service, der Batch-Workloads in Ihren Kubernetes Clustern orchestriert, die von Amazon Elastic Kubernetes Service (Amazon EKS) verwaltet werden. AWS Batch führt diese Orchestrierung außerhalb Ihrer Cluster mithilfe eines „Overlay“ -Modells durch. Da es AWS Batch sich um einen verwalteten Dienst handelt, müssen keine Kubernetes Komponenten (z. B. Operatoren oder benutzerdefinierte Ressourcen) in Ihrem Cluster installiert oder verwaltet werden. AWS Batch Ihr Cluster muss lediglich mit rollenbasierten Zugriffskontrollen (RBAC) konfiguriert sein, die die Kommunikation mit dem AWS Batch API-Server ermöglichen. Kubernetes AWS Batch Aufrufe Kubernetes APIs zum Erstellen, Überwachen und Löschen Kubernetes von Pods und Knoten.
AWS Batch verfügt über eine integrierte Skalierungslogik zur Skalierung von Kubernetes Knoten auf der Grundlage der Auslastung der Auftragswarteschlangen mit Optimierungen im Hinblick auf die Zuweisung von Job-Kapazitäten. Wenn die Auftragswarteschlange leer ist, werden die Knoten auf die von Ihnen festgelegte Mindestkapazität AWS Batch herunterskaliert, die standardmäßig Null ist. AWS Batch verwaltet den gesamten Lebenszyklus dieser Knoten und schmückt die Knoten mit Beschriftungen und Markierungen. Auf diese Weise werden andere Kubernetes Workloads nicht auf die Knoten übertragen, die von verwaltet werden. AWS Batch Ausgenommen hiervon sind Knoten`DaemonSets`, die auf AWS Batch Knoten abzielen können, um Überwachungs- und andere Funktionen bereitzustellen, die für die ordnungsgemäße Ausführung der Jobs erforderlich sind. Außerdem werden AWS Batch keine Jobs, insbesondere Pods, auf Knoten in Ihrem Cluster ausgeführt, die nicht verwaltet werden. Auf diese Weise können Sie separate Skalierungslogik und Dienste für andere Anwendungen im Cluster verwenden.
Um Jobs an zu senden AWS Batch, interagieren Sie direkt mit der AWS Batch API. AWS Batch übersetzt Jobs in `podspecs` und erstellt dann die Anfragen zum Platzieren von Pods auf Knoten, die von AWS Batch in Ihrem Amazon EKS-Cluster verwaltet werden. Sie können Tools verwenden, `kubectl` um beispielsweise laufende Pods und Knoten anzuzeigen. Wenn ein Pod seine Ausführung abgeschlossen hat, AWS Batch löscht er den Pod, den er erstellt hat, um die Kubernetes Systemlast zu verringern.
Sie können beginnen, indem Sie einen gültigen Amazon EKS-Cluster mit verbinden AWS Batch. Hängen Sie dann eine AWS Batch Auftragswarteschlange an und registrieren Sie eine Amazon EKS-Auftragsdefinition mit `podspec` entsprechenden Attributen. Senden Sie zuletzt Jobs mithilfe des [SubmitJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html)API-Vorgangs, der auf die Auftragsdefinition verweist. Weitere Informationen finden Sie unter [Erste Schritte mit AWS Batch Amazon EKS](getting-started-eks.md).
## Amazon EKS
**Topics**
+ [Amazon EKS](#compute-environments-eks)
+ [Amazon EKS-Standard-AMI](eks-ce-ami-selection.md)
+ [Gemischte AMI-Umgebungen](mixed-ami-environments.md)
+ [Unterstützte Kubernetes-Versionen](supported_kubernetes_version.md)
+ [Aktualisieren Sie die Kubernetes Version der Rechenumgebung](updating-k8s-version-ce.md)
+ [Geteilte Verantwortung der Kubernetes Knoten](eks-ce-shared-responsibility.md)
+ [Führen Sie eine DaemonSet auf AWS Batch verwalteten Knoten aus](daemonset-on-batch-eks-nodes.md)
+ [Passen Sie die Amazon EKS-Startvorlagen an](eks-launch-templates.md)
+ [Wie führe ich ein Upgrade von EKS AL2 auf EKS durch AL2023](eks-migration-2023.md)
# Amazon EKS-Standard-AMI
Wenn Sie eine Amazon EKS-Rechenumgebung erstellen, müssen Sie kein Amazon Machine Image (AMI) angeben. AWS Batch wählt ein für Amazon EKS optimiertes AMI aus, das auf der Kubernetes Version und den Instance-Typen basiert, die in Ihrer [CreateComputeEnvironment](https://docs.aws.amazon.com/batch/latest/APIReference/API_CreateComputeEnvironment.html)Anfrage angegeben sind. Im Allgemeinen empfehlen wir, die Standard-AMI-Auswahl zu verwenden. Weitere Informationen zu Amazon EKS Optimized AMIs finden Sie unter [Amazon EKS optimized Amazon Linux AMIs](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-ami.html) im *Amazon EKS-Benutzerhandbuch*.
**Wichtig**
Amazon Linux 2023 ist AMIs die Standardeinstellung AWS Batch für Amazon EKS.
AWS wird den Support für Amazon EKS AL2 — optimiert und AL2 beschleunigt — ab dem AMIs 26.11.25 einstellen. Sie können das von Amazon AWS Batch EKS bereitgestellte, für Amazon EKS optimierte Amazon Linux 2 auch nach AMIs dem 26.11.25 end-of-support weiterhin in Ihren Amazon EKS-Datenverarbeitungsumgebungen verwenden. Diese Datenverarbeitungsumgebungen erhalten jedoch keine neuen Softwareupdates, Sicherheitspatches oder Bugfixes mehr von. AWS*Weitere Informationen zum Upgrade von AL2 auf AL2023 finden Sie [Wie führe ich ein Upgrade von EKS AL2 auf EKS durch AL2023](eks-migration-2023.md) im AWS Batch Benutzerhandbuch.*
Führen Sie den folgenden Befehl aus, um zu sehen, welcher AMI-Typ für Ihre Amazon EKS-Rechenumgebung AWS Batch ausgewählt wurde. Das folgende Beispiel ist ein Instance-Typ ohne GPU.
```
# compute CE example: indicates Batch has chosen the AL2 x86 or ARM EKS 1.32 AMI, depending on instance types
$ aws batch describe-compute-environments --compute-environments My-Eks-CE1 \
| jq '.computeEnvironments[].computeResources.ec2Configuration'
[
{
"imageType": "EKS_AL2",
"imageKubernetesVersion": "1.32"
}
]
```
Das folgende Beispiel ist ein GPU-Instanztyp.
```
# GPU CE example: indicates Batch has choosen the AL2 x86 EKS Accelerated 1.32 AMI
$ aws batch describe-compute-environments --compute-environments My-Eks-GPU-CE \
| jq '.computeEnvironments[].computeResources.ec2Configuration'
[
{
"imageType": "EKS_AL2_NVIDIA",
"imageKubernetesVersion": "1.32"
}
]
```
# Gemischte AMI-Umgebungen
Sie können Startvorlagen-Overrides verwenden, um Rechenumgebungen sowohl mit Amazon Linux 2 (AL2) als auch mit Amazon Linux 2023 (AL2023) AMIs zu erstellen. Dies ist nützlich, wenn Sie unterschiedliche AMIs Architekturen verwenden möchten oder wenn Sie während der Migration von zu wechseln. AL2 AL2023
**Anmerkung**
AWS wird den Support für Amazon EKS AL2 — optimiert und AL2 beschleunigt — ab dem AMIs 26.11.25 einstellen. Sie können zwar das von Amazon AWS Batch EKS bereitgestellte, für Amazon EKS optimierte Amazon Linux 2 auch nach AMIs dem 26.11.25 end-of-support weiterhin in Ihren Amazon EKS-Datenverarbeitungsumgebungen verwenden, diese Datenverarbeitungsumgebungen erhalten jedoch keine neuen Softwareupdates, Sicherheitspatches oder Bugfixes mehr von. AWS Gemischte AMI-Umgebungen können während der Übergangsphase nützlich sein, sodass Sie Workloads schrittweise migrieren AL2023 und gleichzeitig die Kompatibilität mit bestehenden AL2 basierten Workloads beibehalten können.
Beispielkonfiguration mit beiden AMI-Typen:
```
{
"computeResources": {
"launchTemplate": {
"launchTemplateId": "TemplateId",
"version": "1",
"userdataType": "EKS_BOOTSTRAP_SH",
"overrides": [
{
"instanceType": "c5.large",
"imageId": "ami-al2-custom",
"userdataType": "EKS_BOOTSTRAP_SH"
},
{
"instanceType": "c6a.large",
"imageId": "ami-al2023-custom",
"userdataType": "EKS_NODEADM"
}
]
},
"instanceTypes": ["c5.large", "c6a.large"]
}
}
```
# Unterstützte Kubernetes-Versionen
AWS Batch auf Amazon unterstützt EKS derzeit die folgenden Kubernetes Versionen:
+ `1.34`
+ `1.33`
+ `1.32`
+ `1.31`
+ `1.30`
+ `1.29`
Möglicherweise wird Ihnen eine Fehlermeldung angezeigt, die der folgenden ähnelt, wenn Sie den `CreateComputeEnvironment` API-Vorgang oder `UpdateComputeEnvironment` den API-Vorgang verwenden, um eine Rechenumgebung zu erstellen oder zu aktualisieren. Dieses Problem tritt auf, wenn Sie in `EC2Configuration` eine Kubernetes Version angeben, die nicht unterstützt wird.
```
At least one imageKubernetesVersion in EC2Configuration is not supported.
```
Um dieses Problem zu beheben, löschen Sie die Rechenumgebung und erstellen Sie sie dann mit einer unterstützten Kubernetes Version neu.
Sie können ein kleines Versions-Upgrade auf Ihrem Amazon EKS-Cluster durchführen. Sie können den Cluster beispielsweise von `1.xx` auf aktualisieren, `1.yy` auch wenn die Nebenversion nicht unterstützt wird.
Der Status der Rechenumgebung kann sich jedoch `INVALID` nach einem Update der Hauptversion auf ändern. Dies ist beispielsweise der Fall, wenn Sie ein Upgrade einer Hauptversion von `1.xx` auf durchführen`2.yy`. Wenn die Hauptversion von nicht unterstützt wird AWS Batch, wird eine Fehlermeldung angezeigt, die der folgenden ähnelt.
```
reason=CLIENT_ERROR - ... EKS Cluster version [2.yy] is unsupported
```
# Aktualisieren Sie die Kubernetes Version der Rechenumgebung
Mit AWS Batch können Sie die Kubernetes Version einer Rechenumgebung aktualisieren, um Amazon EKS-Cluster-Upgrades zu unterstützen. Die Kubernetes Version einer Rechenumgebung ist die Amazon EKS AMI-Version für die Kubernetes Knoten, die AWS Batch gestartet wird, um Jobs auszuführen. Sie können ein Kubernetes Versions-Upgrade auf ihren Amazon EKS-Knoten durchführen, bevor oder nachdem Sie die Version der Steuerungsebene des Amazon EKS-Clusters aktualisiert haben. Wir empfehlen, die Knoten nach dem Upgrade der Kontrollebene zu aktualisieren. Weitere Informationen finden Sie unter [Aktualisieren einer Amazon Kubernetes EKS-Cluster-Version](https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html) im *Amazon EKS-Benutzerhandbuch*.
Verwenden Sie den [https://docs.aws.amazon.com/batch/latest/APIReference/API_UpdateComputeEnvironment.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_UpdateComputeEnvironment.html)API-Vorgang, um die Kubernetes Version einer Rechenumgebung zu aktualisieren.
```
$ aws batch update-compute-environment \
--compute-environment \
--compute-resources \
'ec2Configuration=[{imageType=EKS_AL2,imageKubernetesVersion=1.32}]'
```
# Geteilte Verantwortung der Kubernetes Knoten
Die Wartung der Rechenumgebungen ist eine gemeinsame Verantwortung.
+ Ändern oder entfernen Sie keine AWS Batch Knoten, Labels, Taints, Namespaces, Startvorlagen oder Auto Scaling-Gruppen. Fügen Sie verwalteten Knoten keine Makel hinzu. AWS Batch Wenn Sie eine dieser Änderungen vornehmen, kann Ihre Rechenumgebung nicht unterstützt werden und es kommt zu Ausfällen, einschließlich Instanzen im Leerlauf.
+ Richten Sie Ihre Pods nicht auf AWS Batch verwaltete Knoten aus. Wenn Sie Ihre Pods auf die verwalteten Knoten ausrichten, kommt es zu einer unterbrochenen Skalierung und zu festgefahrenen Jobwarteschlangen. Führen Sie Workloads aus, die nicht AWS Batch auf selbstverwalteten Knoten oder verwalteten Knotengruppen verwendet werden. Weitere Informationen finden Sie unter [Verwaltete Knotengruppen](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html) im *Amazon-EKS-Benutzerhandbuch*.
+ Sie können festlegen, DaemonSet dass a auf AWS Batch verwalteten Knoten ausgeführt wird. Weitere Informationen finden Sie unter [Führen Sie eine DaemonSet auf AWS Batch verwalteten Knoten aus](daemonset-on-batch-eks-nodes.md).
AWS Batch aktualisiert die Rechenumgebung nicht automatisch AMIs. Es liegt in Ihrer Verantwortung, sie zu aktualisieren. Führen Sie den folgenden Befehl aus, AMIs um Ihre AMI-Version auf die neueste Version zu aktualisieren.
```
$ aws batch update-compute-environment \
--compute-environment \
--compute-resources 'updateToLatestImageVersion=true'
```
AWS Batch aktualisiert die Kubernetes Version nicht automatisch. Führen Sie den folgenden Befehl aus, um die Kubernetes Version Ihrer Computerumgebung auf zu aktualisieren*1.32*.
```
$ aws batch update-compute-environment \
--compute-environment \
--compute-resources \
'ec2Configuration=[{imageType=EKS_AL2,imageKubernetesVersion=1.32}]'
```
Bei der Aktualisierung auf ein neueres AMI oder die neuere Kubernetes Version können Sie angeben, ob Jobs beendet werden sollen, wenn sie aktualisiert werden (`terminateJobsOnUpdate`), und wie lange gewartet werden soll, bis eine Instance ersetzt wird, wenn laufende Jobs nicht abgeschlossen werden (`jobExecutionTimeoutMinutes`.) Weitere Informationen finden Sie unter [Aktualisieren Sie eine Rechenumgebung in AWS Batch](updating-compute-environments.md) und in der Richtlinie zur Aktualisierung der Infrastruktur ([https://docs.aws.amazon.com/batch/latest/APIReference/API_UpdatePolicy.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_UpdatePolicy.html)), die im [https://docs.aws.amazon.com/batch/latest/APIReference/API_UpdateComputeEnvironment.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_UpdateComputeEnvironment.html)API-Vorgang festgelegt wurde.
# Führen Sie eine DaemonSet auf AWS Batch verwalteten Knoten aus
AWS Batch setzt Fehler auf AWS Batch verwalteten Kubernetes Knoten fest. Mit den folgenden `tolerations` Optionen können Sie DaemonSet festlegen, dass a auf AWS Batch verwalteten Knoten ausgeführt wird.
```
tolerations:
- key: "batch.amazonaws.com/batch-node"
operator: "Exists"
```
Eine andere Möglichkeit, dies zu tun, ist die folgende`tolerations`.
```
tolerations:
- key: "batch.amazonaws.com/batch-node"
operator: "Exists"
effect: "NoSchedule"
- key: "batch.amazonaws.com/batch-node"
operator: "Exists"
effect: "NoExecute"
```
# Passen Sie die Amazon EKS-Startvorlagen an
AWS Batch auf Amazon unterstützt EKS Startvorlagen. Es gibt Einschränkungen in Bezug darauf, was Ihre Startvorlage leisten kann.
**Wichtig**
AWS Batch Läuft für AL2 AMIs EKS`/etc/eks/bootstrap.sh`. Führen Sie es nicht `/etc/eks/bootstrap.sh` in Ihrer Startvorlage oder Ihren cloud-init user-data Skripten aus. Sie können neben dem Parameter weitere `--kubelet-extra-args` Parameter zu [bootstrap.sh](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh) hinzufügen. Stellen Sie dazu die `AWS_BATCH_KUBELET_EXTRA_ARGS` Variable in der `/etc/aws-batch/batch.config` Datei ein. Einzelheiten finden Sie im folgenden Beispiel.
Für EKS AL2023 AWS Batch verwendet [NodeConfigSpec](https://awslabs.github.io/amazon-eks-ami/nodeadm/doc/api/#nodeconfigspec)From EKS, damit Instanzen dem EKS-Cluster beitreten. AWS Batch wird [NodeConfigSpec](https://awslabs.github.io/amazon-eks-ami/nodeadm/doc/api/#nodeconfigspec)für [ClusterDetails](https://awslabs.github.io/amazon-eks-ami/nodeadm/doc/api/#clusterdetails)den EKS-Cluster aufgefüllt und Sie müssen sie nicht angeben.
**Anmerkung**
Wir empfehlen, dass Sie keine der folgenden [https://awslabs.github.io/amazon-eks-ami/nodeadm/doc/api/#nodeconfigspec](https://awslabs.github.io/amazon-eks-ami/nodeadm/doc/api/#nodeconfigspec)Einstellungen in der Startvorlage festlegen, da AWS Batch diese Ihre Werte überschreiben würden. Weitere Informationen finden Sie unter [Geteilte Verantwortung der Kubernetes Knoten](eks-ce-shared-responsibility.md).
`Taints`
`Cluster Name`
`apiServerEndpoint`
`certificatAuthority`
`CIDR`
Erstellen Sie keine Labels mit dem Präfix `batch.amazonaws.com/`
**Anmerkung**
Wenn die Startvorlage nach dem Aufruf geändert [CreateComputeEnvironment](https://docs.aws.amazon.com/batch/latest/APIReference/API_CreateComputeEnvironment.html)wird, [https://docs.aws.amazon.com/batch/latest/APIReference/API_UpdateComputeEnvironment.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_UpdateComputeEnvironment.html)muss sie aufgerufen werden, um zu überprüfen, welche Version der Startvorlage ersetzt werden kann.
**Topics**
+ [Fügen Sie `kubelet` zusätzliche Argumente hinzu](#kubelet-extra-args)
+ [Konfigurieren Sie die Container-Laufzeit](#change-container-runtime)
+ [Bereitstellen eines Amazon EFS-Volumes](#mounting-efs-volume)
+ [IPv6 Unterstützung](#eks-ipv6-support)
## Fügen Sie `kubelet` zusätzliche Argumente hinzu
AWS Batch unterstützt das Hinzufügen zusätzlicher Argumente zum `kubelet` Befehl. Eine Liste der unterstützten Parameter finden Sie [https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/)in der *KubernetesDokumentation*. Im folgenden Beispiel für EKS AL2 AMIs `--node-labels mylabel=helloworld` wird der `kubelet` Befehlszeile hinzugefügt.
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="
--==MYBOUNDARY==
Content-Type: text/x-shellscript; charset="us-ascii"
#!/bin/bash
mkdir -p /etc/aws-batch
echo AWS_BATCH_KUBELET_EXTRA_ARGS=\"--node-labels mylabel=helloworld\" >> /etc/aws-batch/batch.config
--==MYBOUNDARY==--
```
Für EKS ist AL2023 AMIs das Dateiformat YAML. Eine Liste der unterstützten Parameter finden Sie [https://awslabs.github.io/amazon-eks-ami/nodeadm/doc/api/#nodeconfigspec](https://awslabs.github.io/amazon-eks-ami/nodeadm/doc/api/#nodeconfigspec)in der *KubernetesDokumentation*. Im folgenden Beispiel für EKS AL2023 AMIs `--node-labels mylabel=helloworld` wird der `kubelet` Befehlszeile hinzugefügt.
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="
--==MYBOUNDARY==
Content-Type: application/node.eks.aws
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
kubelet:
flags:
- --node-labels=mylabel=helloworld
--==MYBOUNDARY==--
```
## Konfigurieren Sie die Container-Laufzeit
Sie können die AWS Batch `CONTAINER_RUNTIME` Umgebungsvariable verwenden, um die Container-Laufzeit auf einem verwalteten Knoten zu konfigurieren. Im folgenden Beispiel wird die Container-Laufzeit auf „`containerd`when `bootstrap.sh` runs“ festgelegt. Weitere Informationen finden Sie [https://kubernetes.io/docs/setup/production-environment/container-runtimes/#containerd](https://kubernetes.io/docs/setup/production-environment/container-runtimes/#containerd)in der *KubernetesDokumentation*.
Wenn Sie ein optimiertes `EKS_AL2023` oder `EKS_AL2023_NVIDIA` AMI verwenden, müssen Sie die Container-Laufzeit nicht angeben, da nur **containerd** unterstützt wird.
**Anmerkung**
Die `CONTAINER_RUNTIME` Umgebungsvariable entspricht der `--container-runtime` Option von`bootstrap.sh`. Weitere Informationen finden Sie [https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/#options](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/#options)in der *KubernetesDokumentation*.
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="
--==MYBOUNDARY==
Content-Type: text/x-shellscript; charset="us-ascii"
#!/bin/bash
mkdir -p /etc/aws-batch
echo CONTAINER_RUNTIME=containerd >> /etc/aws-batch/batch.config
--==MYBOUNDARY==--
```
## Bereitstellen eines Amazon EFS-Volumes
Sie können Startvorlagen verwenden, um Volumes auf dem Knoten bereitzustellen. Im folgenden Beispiel werden die `runcmd` Einstellungen `cloud-config` `packages` und verwendet. Weitere Informationen finden Sie in der *cloud-initDokumentation* unter [Cloud-Konfigurationsbeispielen](https://cloudinit.readthedocs.io/en/latest/topics/examples.html).
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="
--==MYBOUNDARY==
Content-Type: text/cloud-config; charset="us-ascii"
packages:
- amazon-efs-utils
runcmd:
- file_system_id_01=fs-abcdef123
- efs_directory=/mnt/efs
- mkdir -p ${efs_directory}
- echo "${file_system_id_01}:/ ${efs_directory} efs _netdev,noresvport,tls,iam 0 0" >> /etc/fstab
- mount -t efs -o tls ${file_system_id_01}:/ ${efs_directory}
--==MYBOUNDARY==--
```
Um dieses Volume im Job zu verwenden, muss es im [eksProperties-Parameter](https://docs.aws.amazon.com/batch/latest/APIReference/API_EksProperties.html) hinzugefügt werden. [RegisterJobDefinition](https://docs.aws.amazon.com/batch/latest/APIReference/API_RegisterJobDefinition.html) Das folgende Beispiel ist ein großer Teil der Auftragsdefinition.
```
{
"jobDefinitionName": "MyJobOnEks_EFS",
"type": "container",
"eksProperties": {
"podProperties": {
"containers": [
{
"image": "public.ecr.aws/amazonlinux/amazonlinux:2",
"command": ["ls", "-la", "/efs"],
"resources": {
"limits": {
"cpu": "1",
"memory": "1024Mi"
}
},
"volumeMounts": [
{
"name": "efs-volume",
"mountPath": "/efs"
}
]
}
],
"volumes": [
{
"name": "efs-volume",
"hostPath": {
"path": "/mnt/efs"
}
}
]
}
}
}
```
Im Knoten wird das Amazon EFS-Volume im `/mnt/efs` Verzeichnis bereitgestellt. Im Container für den Amazon EKS-Job wird das Volume im `/efs` Verzeichnis bereitgestellt.
## IPv6 Unterstützung
AWS Batch unterstützt Amazon EKS-Cluster IPv6 mit Adressen. Für den AWS Batch Support sind keine Anpassungen erforderlich. Bevor Sie beginnen, empfehlen wir Ihnen jedoch, die Überlegungen und Bedingungen zu lesen, die unter [Zuweisen von IPv6 Adressen zu Pods und Services](https://docs.aws.amazon.com/eks/latest/userguide/cni-ipv6.html) im *Amazon EKS-Benutzerhandbuch* beschrieben sind.
# Wie führe ich ein Upgrade von EKS AL2 auf EKS durch AL2023
Die für Amazon EKS optimierten Produkte AMIs sind in zwei Familien erhältlich, die auf Amazon Linux 2 (AL2) und Amazon Linux 2023 (AL2023) basieren. AL2023 ist ein Linux-basiertes Betriebssystem, das entwickelt wurde, um eine sichere, stabile und leistungsstarke Umgebung für Ihre Cloud-Anwendungen bereitzustellen. Weitere Informationen zu den Unterschieden zwischen AL2 und AL2023 unter [Upgrade von Amazon Linux 2 auf Amazon Linux 2023](https://docs.aws.amazon.com/eks/latest/userguide/al2023.html) finden Sie im *Amazon EKS-Benutzerhandbuch*.
**Wichtig**
AWS wird den Support für Amazon EKS AL2 — optimiert und AL2 beschleunigt — ab dem AMIs 26.11.25 einstellen. Wir empfehlen, die AWS Batch Amazon EKS-Rechenumgebungen vor dem 26.11.25 auf Amazon Linux 2023 zu migrieren, um optimale Leistung und Sicherheit zu gewährleisten. Sie können zwar das von Amazon AWS Batch EKS bereitgestellte, für Amazon EKS optimierte Amazon Linux 2 auch nach AMIs dem 26.11.25 end-of-support weiterhin in Ihren Amazon EKS-Datenverarbeitungsumgebungen verwenden, diese Datenverarbeitungsumgebungen erhalten jedoch keine neuen Softwareupdates, Sicherheitspatches oder Bugfixes mehr von. AWS Es liegt in Ihrer [Verantwortung, diese Rechenumgebungen anschließend auf dem für Amazon EKS optimierten Amazon Linux 2-AMI aufrechtzuerhalten](eks-ce-shared-responsibility.md#eks-ce-shared-responsibility.title) end-of-life.
Je nachdem, wie Ihre Computerumgebung konfiguriert ist, können Sie einen der folgenden Upgrade-Pfade von AL2 bis verwenden AL2023.
**Führen Sie ein Upgrade mithilfe von Ec2Configuration durch. ImageType**
+ Wenn Sie keine Startvorlage oder Startvorlagen-Überschreibungen verwenden, ändern Sie [Ec2Configuration. ImageType](https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html#Batch-Type-Ec2Configuration-imageType)zu `EKS_AL2023` oder `EKS_AL2023_NVIDIA` und dann ausführen. [UpdateComputeEnvironment](https://docs.aws.amazon.com/batch/latest/APIReference/API_UpdateComputeEnvironment.html)
+ Wenn Sie eine [Ec2Configuration angeben. ](https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html#Batch-Type-Ec2Configuration-imageIdOverride)ImageIdOverride[dann Ec2Configuration. ImageType](https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html#Batch-Type-Ec2Configuration-imageType)muss dem in [Ec2Configuration angegebenen AMI-Typ entsprechen. ImageIdOverride](https://docs.aws.amazon.com/batch/latest/APIReference/API_Ec2Configuration.html#Batch-Type-Ec2Configuration-imageIdOverride).
Wenn Sie nicht übereinstimmen `ImageIdOverride` und `ImageType` der Knoten dem Cluster nicht beitritt.
**Führen Sie ein Upgrade mithilfe von Startvorlagen durch**
+ Wenn Sie `kubelet` zusätzliche Argumente in einer Startvorlage oder einer Startvorlagen-Überschreibung definiert haben, müssen diese auf das neue [Format für `kubelet` zusätzliche Argumente](eks-launch-templates.md#kubelet-extra-args.title) aktualisiert werden.
Wenn das Format der `kubelet` zusätzlichen Argumente nicht übereinstimmt, werden die zusätzlichen Argumente nicht angewendet.
+ Denn AL2023 AMIs **containerd** ist die einzige unterstützte Container-Laufzeit. Sie müssen die Container-Laufzeit für `EKS_AL2023` in der Startvorlage nicht angeben.
Sie können keine benutzerdefinierte Container-Laufzeit mit angeben`EKS_AL2023`.
+ Wenn Sie eine Startvorlage oder eine Startvorlagenüberschreibung verwenden, die ein darauf basierendes AMI spezifiziert, `EKS_AL2023` müssen Sie [userDataType](https://docs.aws.amazon.com/batch/latest/APIReference/API_LaunchTemplateSpecification.html) auf setzen. `EKS_NODEADM`
Wenn Sie das `userdataType` und AMI nicht übereinstimmen, tritt der Knoten dem EKS-Cluster nicht bei.