Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Jobs in Deadline Cloud planen Nachdem Sie einen Auftrag erstellt haben, plant AWS Deadline Cloud, dass er in einer oder mehreren Flotten bearbeitet wird, die einer Warteschlange zugeordnet sind. Die Flotte, die eine bestimmte Aufgabe verarbeitet, wird auf der Grundlage der Planungskonfiguration, der für die Flotte konfigurierten Funktionen und der Hostanforderungen eines bestimmten Schritts ausgewählt. In den folgenden Abschnitten wird detailliert beschrieben, wie ein Job geplant wird. ## Konfigurationen planen Sie können konfigurieren, wie Deadline Cloud Jobs in einer Warteschlange plant, indem Sie eine Planungskonfiguration für die Warteschlange festlegen. Die Planungskonfiguration steuert, wie die Mitarbeiter auf die Jobs verteilt werden. Sie können die Planungskonfiguration über die Deadline Cloud-Konsole oder durch Aufrufen von [CreateQueue](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateQueue.html)oder festlegen [UpdateQueue](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_UpdateQueue.html) APIs. Es gibt drei verfügbare Planungskonfigurationen: + **Priorität, first-in-first-out** (`priorityFifo`) — Plant den Job mit der höchsten Priorität und dem frühesten eingereichten Auftrag zuerst ein (Standard). + **Priorität, ausgewogen** (`priorityBalanced`) — Verteilt die Mitarbeiter gleichmäßig auf die Jobs mit der höchsten Priorität. + **Gewichtet, ausgewogen** (`weightedBalanced`) — Verwendet eine gewichtete Formel, um zu ermitteln, wie die Arbeitskräfte auf die einzelnen Stellen verteilt sind. In allen Planungskonfigurationen werden in Bearbeitung befindliche Aufgaben bis zum Abschluss ausgeführt, bevor eine neue Planungsentscheidung getroffen wird. Wenn Sie die Planungskonfiguration ändern, während Aufgaben ausgeführt werden, gilt die Änderung nur, wenn Mitarbeiter als Nächstes zugewiesen werden. Laufende Aufgaben werden nicht unterbrochen oder neu zugewiesen. ### Priorität, first-in-first-out Priorität, first-in-first-out (`priorityFifo`) ist die Standard-Planungskonfiguration für neue Warteschlangen. Deadline Cloud weist Mitarbeitern zuerst den Job mit der höchsten Priorität zu. Wenn mehrere Jobs dieselbe Priorität haben, erhält der älteste (am frühesten eingereichte) Job zuerst alle verfügbaren Mitarbeiter. Verwenden Sie FIFO mit Priorität, wenn Sie eine strikte Reihenfolge der Jobs wünschen. Diese Konfiguration eignet sich, wenn Jobs nacheinander in der Reihenfolge abgeschlossen werden sollen, in der sie übermittelt wurden, z. B. sequenzielle Pipeline-Phasen oder Batch-Verarbeitung, bei der jeder Job abgeschlossen werden muss, bevor der nächste gestartet wird. Diese Konfiguration hat keine zusätzlichen Parameter. ### Priorität, ausgewogen Priorität, ausgewogen (`priorityBalanced`) verteilt die Arbeitnehmer gleichmäßig auf alle Arbeitsplätze der höchsten Prioritätsstufe. Wenn nur ein Job mit der höchsten Priorität vorhanden ist, weist Deadline Cloud alle Mitarbeiter diesem Job zu. Wenn mehrere Jobs die höchste Priorität haben, werden die Mitarbeiter gleichmäßig auf sie aufgeteilt. Können die Arbeitskräfte nicht gleichmäßig aufgeteilt werden, werden die zusätzlichen Arbeitskräfte auf die Tätigkeiten mit der höchsten Priorität verteilt. Verwenden Sie eine ausgewogene Prioritätsverteilung, wenn mehrere Künstler oder Benutzer Jobs mit derselben Priorität einreichen und jeder Benutzer sofortiges Feedback benötigt. Diese Konfiguration stellt sicher, dass kein einziger Job alle verfügbaren Arbeitskräfte monopolisiert, sodass allen Benutzern kurz nach der Einreichung Mitarbeiter zugewiesen werden. Wenn für eine Stelle weniger Aufgaben übrig sind, als ihr Anteil an Arbeitskräften entspricht, werden die überschüssigen Arbeitskräfte auf andere Stellen mit derselben Prioritätsstufe umverteilt. Wenn alle Stellen mit der höchsten Priorität vollständig zugewiesen werden, wechseln überschüssige Arbeitskräfte automatisch zu Stellen mit der nächsthöheren Prioritätsstufe. Diese Konfiguration hat den folgenden Parameter: `renderingTaskBuffer` Steuert die Klebrigkeit der Arbeiter. Ein Worker wechselt nur dann von seinem aktuellen Job zu einem anderen Job mit derselben Priorität, wenn der Unterschied bei den Renderaufgaben den `renderingTaskBuffer` Wert übersteigt. Bei einem höheren Wert bleiben die Mitarbeiter länger bei ihren aktuellen Aufgaben, sodass weniger Kontextwechsel erforderlich sind. Der Standardwert ist `1`. ### Gewichtet, ausgewogen Gewichtet, ausgewogen (`weightedBalanced`) verwendet eine Formel, um für jeden Auftrag ein Gewicht zu berechnen. Deadline Cloud weist Mitarbeitern zuerst den Job mit der höchsten Gewichtung zu. Wenn mehrere Jobs das gleiche Gewicht haben, werden die Mitarbeiter auf sie verteilt. Verwenden Sie Gewichtet und ausgewogen, wenn Sie eine genaue Kontrolle darüber benötigen, wie Mitarbeiter mit unterschiedlichen Prioritäten, Fehlerquoten und Übermittlungszeiten auf die einzelnen Jobs verteilt werden. Diese Konfiguration eignet sich für komplexe Renderfarmumgebungen, in denen Sie das Gleichgewicht zwischen Auftragspriorität, Jobalter, Fehlerbehandlung und Mitarbeiterbindung einstellen möchten. Die Gewichtung für jeden Auftrag wird wie folgt berechnet: ``` weight = (job.Priority * priorityWeight) + (job.Errors * errorWeight) + ((currentTimeInSeconds - job.SubmissionTime) * submissionTimeWeight) + ((job.RenderingTasks - renderingTaskBuffer) * renderingTaskWeight) ``` Die `renderingTaskBuffer` Komponente wird nur angewendet, wenn die Arbeitskraft gerade an dem Job arbeitet. Der Wert `renderingTaskWeight` ist in der Regel negativ, sodass Jobs, denen Mitarbeiter zugewiesen sind, eine geringere Gewichtung erhalten, wodurch andere Jobs in der Warteschlange an erster Stelle stehen. Der `errorWeight` ist in der Regel auch negativ, sodass fehlerhafte Jobs die Priorität verlieren. Sie können Zeitplanüberschreibungen für Jobs mit minimaler und maximaler Priorität verwenden. Diese Konfiguration hat die folgenden Parameter: `priorityWeight` Die Gewichtung, die der Priorität eines Jobs zugewiesen wird. Ein positiver Wert bedeutet, dass Jobs mit höherer Priorität zuerst geplant werden. Der Standardwert ist `100.0`. Bereich: `0` bis. `10000` `errorWeight` Die Gewichtung, die auf die Fehleranzahl eines Jobs angewendet wird. Ein negativer Wert bedeutet, dass Jobs ohne Fehler zuerst geplant werden. Der Standardwert ist `-10.0`. Bereich: `-10000` bis`10000`. `submissionTimeWeight` Die Gewichtung, die auf die Übermittlungszeit eines Jobs angewendet wird (in Sekunden). Ein positiver Wert bedeutet, dass zuvor eingereichte Jobs zuerst geplant werden. Der Standardwert ist `3.0`. Bereich: `0` bis`10000`. `renderingTaskWeight` Die Gewichtung, die auf die Anzahl der Aufgaben angewendet wird, die derzeit für einen Job gerendert werden. Ein negativer Wert bedeutet, dass Jobs mit weniger Mitarbeitern als Nächstes geplant werden. Der Standardwert ist `-100.0`. Bereich: `-10000` bis`10000`. `renderingTaskBuffer` Die Anzahl der Renderaufgaben, bevor die Gewichtung der Renderaufgabe wirksam wird. Ein positiver Wert sorgt dafür, dass die Mitarbeiter weiterhin ihren aktuellen Aufgaben nachgehen. Der Standardwert ist `1`. Bereich: `0` bis`1000`. `maxPriorityOverride` Optional. Wenn diese Option auf gesetzt ist`alwaysScheduleFirst`, werden Jobs mit der höchsten Priorität (100) immer vor anderen Jobs geplant, unabhängig von der gewichteten Formel. Wenn mehrere Jobs die höchste Priorität haben, werden Gleichstände anhand der gewichteten Standardformel aufgehoben. Fehlt die Überschreibung, wird für Aufträge mit höchster Priorität die gewichtete Standardformel ohne besondere Behandlung verwendet. `minPriorityOverride` Optional. Wenn diese Option auf gesetzt ist`alwaysScheduleLast`, werden Jobs mit der niedrigsten Priorität (0) immer nach anderen Jobs geplant, unabhängig von der gewichteten Formel. Wenn mehrere Jobs die Mindestpriorität haben, werden Gleichstände anhand der gewichteten Standardformel aufgehoben. Fehlt die Überschreibung, wird für Jobs mit minimaler Priorität die gewichtete Standardformel ohne besondere Behandlung verwendet. ## Prüfen Sie die Flottenkompatibilität Nachdem Sie einen Job erstellt haben, vergleicht Deadline Cloud die Hostanforderungen für jeden Schritt im Job mit den Fähigkeiten der Flotten, die mit der Warteschlange verknüpft sind, an die der Job übermittelt wurde. Wenn eine Flotte die Hostanforderungen erfüllt, wird der Job in den `READY` Status versetzt. Wenn für einen Schritt des Jobs Anforderungen gelten, die von einer Flotte, die der Warteschlange zugeordnet ist, nicht erfüllt werden können, wird der Status des Schritts auf gesetzt`NOT_COMPATIBLE`. Außerdem werden die restlichen Schritte des Jobs storniert. Die Funktionen für eine Flotte werden auf Flottenebene festgelegt. Selbst wenn ein Mitarbeiter in einer Flotte die Anforderungen des Auftrags erfüllt, werden ihm keine Aufgaben aus dem Auftrag zugewiesen, wenn seine Flotte die Anforderungen des Auftrags nicht erfüllt. Die folgende Jobvorlage enthält einen Schritt, der die Hostanforderungen für den Schritt spezifiziert: ``` name: Sample Job With Host Requirements specificationVersion: jobtemplate-2023-09 steps: - name: Step 1 script: actions: onRun: args: - '1' command: /usr/bin/sleep hostRequirements: amounts: # Capabilities starting with "amount." are amount capabilities. If they start with "amount.worker.", # they are defined by the OpenJD specification. Other names are free for custom usage. - name: amount.worker.vcpu min: 4 max: 8 attributes: - name: attr.worker.os.family anyOf: - linux ``` Dieser Job kann für eine Flotte mit den folgenden Funktionen geplant werden: ``` { "vCpuCount": {"min": 4, "max": 8}, "memoryMiB": {"min": 1024}, "osFamily": "linux", "cpuArchitectureType": "x86_64" } ``` Dieser Job kann nicht für eine Flotte mit einer der folgenden Funktionen geplant werden: ``` { "vCpuCount": {"min": 4}, "memoryMiB": {"min": 1024}, "osFamily": "linux", "cpuArchitectureType": "x86_64" } The vCpuCount has no maximum, so it exceeds the maximum vCPU host requirement. { "vCpuCount": {"max": 8}, "memoryMiB": {"min": 1024}, "osFamily": "linux", "cpuArchitectureType": "x86_64" } The vCpuCount has no minimum, so it doesn't satisfy the minimum vCPU host requirement. { "vCpuCount": {"min": 4, "max": 8}, "memoryMiB": {"min": 1024}, "osFamily": "windows", "cpuArchitectureType": "x86_64" } The osFamily doesn't match. ``` ## Skalierung der Flotte Wenn ein Auftrag einer kompatiblen, servicemanagierten Flotte zugewiesen wird, wird die Flotte auto skaliert. Die Anzahl der Mitarbeiter in der Flotte ändert sich je nach der Anzahl der Aufgaben, die der Flotte zur Ausführung zur Verfügung stehen. Wenn ein Auftrag einer vom Kunden verwalteten Flotte zugewiesen wird, sind Mitarbeiter möglicherweise bereits vorhanden oder können mithilfe von ereignisbasierter Autoskalierung erstellt werden. Weitere Informationen finden Sie unter [Verwenden EventBridge zur Behandlung von Auto Scaling-Ereignissen](https://docs.aws.amazon.com/autoscaling/ec2/userguide/automating-ec2-auto-scaling-with-eventbridge.html) im *Amazon EC2 Auto Scaling Scaling-Benutzerhandbuch*. ## Sitzungen Die Aufgaben in einem Job sind in eine oder mehrere Sitzungen aufgeteilt. Die Mitarbeiter führen die Sitzungen durch, um die Umgebung einzurichten, die Aufgaben auszuführen und dann die Umgebung zu zerstören. Jede Sitzung besteht aus einer oder mehreren Aktionen, die ein Mitarbeiter ausführen muss. Wenn ein Mitarbeiter Abschnittsaktionen abschließt, können zusätzliche Sitzungsaktionen an den Mitarbeiter gesendet werden. Der Mitarbeiter verwendet in der Sitzung vorhandene Umgebungen und Jobanhänge wieder, um Aufgaben effizienter zu erledigen. Bei dienstverwalteten Flottenarbeitern werden Sitzungsverzeichnisse nach Ende der Sitzung gelöscht, andere Verzeichnisse werden jedoch zwischen den Sitzungen beibehalten. Dieses Verhalten ermöglicht es Ihnen, Caching-Strategien für Daten zu implementieren, die in mehreren Sitzungen wiederverwendet werden können. Um Daten zwischen Sitzungen zwischenzuspeichern, speichern Sie sie im Home-Verzeichnis des Benutzers, der den Job ausführt. Beispielsweise werden Conda-Pakete im Home-Verzeichnis des Job-Benutzers unter `C:\Users\job-user\.conda-pkgs` on Windows workers und `/home/job-user/.conda-pkgs` on Linux workers zwischengespeichert. Diese Daten bleiben verfügbar, bis der Worker heruntergefahren wird. Jobanhänge werden vom Einreicher erstellt, den Sie als Teil Ihres Deadline Cloud CLI-Jobpakets verwenden. Mit der `--attachments` Option für den Befehl können Sie auch Jobanhänge erstellen. `create-job` AWS CLI Umgebungen werden an zwei Stellen definiert: Warteschlangenumgebungen, die an eine bestimmte Warteschlange angehängt sind, und Job- und Schrittumgebungen, die in der Jobvorlage definiert sind. Es gibt vier Arten von Sitzungsaktionen: + `syncInputJobAttachments`— Lädt die Eingabe-Job-Anhänge an den Worker herunter. + `envEnter`— Führt die `onEnter` Aktionen für eine Umgebung aus. + `taskRun`— Führt die `onRun` Aktionen für eine Aufgabe aus. + `envExit`— Führt die `onExit` Aktionen für eine Umgebung aus. Die folgende Jobvorlage hat eine Schrittumgebung. Sie enthält eine `onEnter` Definition zum Einrichten der Schrittumgebung, eine `onRun` Definition, die die auszuführende Aufgabe definiert, und eine `onExit` Definition zum Abbau der Schrittumgebung. Die für diesen Job erstellten Sitzungen umfassen eine `envEnter` Aktion, eine oder mehrere `taskRun` Aktionen und dann eine `envExit` Aktion. ``` name: Sample Job with Maya Environment specificationVersion: jobtemplate-2023-09 steps: - name: Maya Step stepEnvironments: - name: Maya description: Runs Maya in the background. script: embeddedFiles: - name: initData filename: init-data.yaml type: TEXT data: | scene_file: MyAwesomeSceneFile renderer: arnold camera: persp actions: onEnter: command: MayaAdaptor args: - daemon - start - --init-data - file://{{Env.File.initData}} onExit: command: MayaAdaptor args: - daemon - stop parameterSpace: taskParameterDefinitions: - name: Frame range: 1-5 type: INT script: embeddedFiles: - name: runData filename: run-data.yaml type: TEXT data: | frame: {{Task.Param.Frame}} actions: onRun: command: MayaAdaptor args: - daemon - run - --run-data - file://{{ Task.File.runData }} ``` ### Pipelining von Sitzungsaktionen Durch das Pipelining von Sitzungsaktionen kann ein Scheduler einem Worker mehrere Sitzungsaktionen vorab zuweisen. Der Worker kann diese Aktionen dann sequenziell ausführen, wodurch die Leerlaufzeit zwischen Aufgaben reduziert oder ganz vermieden wird. Um eine erste Zuweisung zu erstellen, erstellt der Scheduler eine Sitzung mit einer Aufgabe, der Worker schließt die Aufgabe ab und anschließend analysiert der Scheduler die Aufgabendauer, um future Zuweisungen zu bestimmen. Damit der Scheduler effektiv ist, gibt es Regeln für die Aufgabendauer. Für Aufgaben unter einer Minute verwendet der Scheduler ein Power-of-2-Wachstumsmuster. Bei einer 1-Sekunden-Aufgabe weist der Scheduler beispielsweise 2 neue Aufgaben zu, dann 4 und dann 8. Für Aufgaben, die länger als eine Minute dauern, weist der Scheduler nur eine neue Aufgabe zu, und das Pipelining bleibt deaktiviert. Um die Pipeline-Größe zu berechnen, geht der Scheduler wie folgt vor: + Verwendet die durchschnittliche Aufgabendauer abgeschlossener Aufgaben + Zielt darauf ab, den Mitarbeiter eine Minute lang zu beschäftigen + Berücksichtigt nur Aufgaben innerhalb derselben Sitzung + Gibt Daten zur Dauer nicht an alle Mitarbeiter weiter Durch die Weiterleitung von Sitzungsaktionen können Mitarbeiter sofort mit neuen Aufgaben beginnen und es gibt keine Wartezeiten zwischen den Anfragen des Terminplaners. Es sorgt auch für eine höhere Effizienz der Mitarbeiter und eine bessere Aufgabenverteilung bei lang andauernden Prozessen. Wenn ein neuer Job mit höherer Priorität verfügbar ist, beendet der Mitarbeiter außerdem die gesamte ihm zuvor zugewiesene Arbeit, bevor die aktuelle Sitzung endet und eine neue Sitzung aus einem Job mit höherer Priorität zugewiesen wird. ## Abhängigkeiten der einzelnen Schritte Deadline Cloud unterstützt die Definition von Abhängigkeiten zwischen Schritten, sodass ein Schritt wartet, bis ein anderer Schritt abgeschlossen ist, bevor er gestartet wird. Sie können mehr als eine Abhängigkeit für einen Schritt definieren. Ein Schritt mit einer Abhängigkeit wird erst geplant, wenn alle Abhängigkeiten abgeschlossen sind. Wenn die Jobvorlage eine zirkuläre Abhängigkeit definiert, wird der Job abgelehnt und der Jobstatus wird auf gesetzt`CREATE_FAILED`. Mit der folgenden Jobvorlage wird ein Job in zwei Schritten erstellt. `StepB`hängt davon ab`StepA`. `StepB`wird erst ausgeführt, nachdem der `StepA` Vorgang erfolgreich abgeschlossen wurde. Nachdem der Job erstellt wurde, `StepA` befindet er sich im `READY` Status und `StepB` befindet sich im `PENDING` Status. Wenn der `StepA` Vorgang abgeschlossen ist, `StepB` wechselt er in den `READY` Status. `StepA`Schlägt fehl oder wurde der `StepA` Vorgang abgebrochen, `StepB` wechselt er in den `CANCELED` Status. Sie können eine Abhängigkeit von mehreren Schritten festlegen. Wenn beispielsweise von beiden `StepA` und `StepC` abhängt`StepB`, `StepC` wird erst gestartet, wenn die anderen beiden Schritte abgeschlossen sind. Für Schrittabhängigkeiten gelten die folgenden Einschränkungen: + **Abhängigkeiten pro Schritt** — Ein Schritt kann von maximal 128 anderen Schritten abhängen. + **Verbraucher pro Schritt** — Maximal 32 weitere Schritte können von einem einzigen Schritt abhängen. ``` name: Step-Step Dependency Test specificationVersion: 'jobtemplate-2023-09' steps: - name: A script: actions: onRun: command: bash args: ['{{ Task.File.run }}'] embeddedFiles: - name: run type: TEXT data: | #!/bin/env bash set -euo pipefail sleep 1 echo Task A Done! - name: B dependencies: - dependsOn: A # This means Step B depends on Step A script: actions: onRun: command: bash args: ['{{ Task.File.run }}'] embeddedFiles: - name: run type: TEXT data: | #!/bin/env bash set -euo pipefail sleep 1 echo Task B Done! ```