Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Planifier des tâches dans Deadline Cloud

Une fois que vous avez créé une tâche, AWS Deadline Cloud planifie son traitement sur une ou plusieurs flottes associées à une file d'attente. La flotte qui traite une tâche particulière est choisie en fonction de la configuration de planification, des capacités configurées pour la flotte et des exigences de l'hôte pour une étape spécifique.

Les sections suivantes fournissent des informations détaillées sur le processus de planification d'une tâche.

Configurations de planification

Vous pouvez configurer la façon dont Deadline Cloud planifie les tâches dans une file d'attente en définissant une configuration de planification dans la file d'attente. La configuration de planification contrôle la façon dont les travailleurs sont répartis entre les tâches.

Vous pouvez définir la configuration de planification à l'aide de la console Deadline Cloud ou en appelant le CreateQueueou UpdateQueue APIs.

Trois configurations de planification sont disponibles :

Dans toutes les configurations de planification, les tâches en cours s'exécutent jusqu'à leur fin avant qu'une nouvelle décision de planification ne soit prise. Si vous modifiez la configuration de planification pendant que les tâches sont en cours d'exécution, la modification ne s'applique que lorsque les travailleurs seront affectés ensuite. Les tâches en cours ne sont ni interrompues ni réaffectées.

Priorité, first-in-first-out

La priorité first-in-first-out (priorityFifo) est la configuration de planification par défaut pour les nouvelles files d'attente. Deadline Cloud assigne d'abord les collaborateurs à la tâche la plus prioritaire. Lorsque plusieurs tâches partagent la même priorité, la tâche la plus ancienne (la plus ancienne soumise) reçoit en premier tous les travailleurs disponibles.

Utilisez le FIFO prioritaire lorsque vous souhaitez un ordre strict des tâches. Cette configuration est appropriée lorsque les tâches doivent être terminées une par une dans l'ordre dans lequel elles ont été soumises, comme les étapes séquentielles du pipeline ou le traitement par lots où chaque tâche doit se terminer avant le début de la suivante.

Cette configuration ne comporte aucun paramètre supplémentaire.

Priorité, équilibrée

Priority, balanced (priorityBalanced) répartit les travailleurs de manière égale entre tous les emplois au niveau de priorité le plus élevé. Lorsqu'une seule tâche a la priorité la plus élevée, Deadline Cloud affecte tous les collaborateurs à cette tâche. Lorsque plusieurs tâches ont la plus haute priorité, les travailleurs sont répartis équitablement entre eux. Si les travailleurs ne peuvent pas être répartis équitablement, les travailleurs supplémentaires sont répartis entre les emplois les plus prioritaires.

Utilisez l'équilibre des priorités lorsque plusieurs artistes ou utilisateurs soumettent des travaux avec la même priorité et que chaque utilisateur a besoin d'un feedback immédiat. Cette configuration garantit qu'aucune tâche ne monopolise tous les travailleurs disponibles, de sorte que tous les utilisateurs se voient attribuer des travailleurs peu de temps après leur soumission.

Si un emploi a moins de tâches restantes que sa part de travailleurs, les travailleurs excédentaires sont redistribués vers d'autres emplois ayant le même niveau de priorité. Si tous les emplois les plus prioritaires sont entièrement attribués, les travailleurs excédentaires accèdent aux emplois du niveau de priorité le plus élevé suivant.

Cette configuration possède le paramètre suivant :

Pondéré, équilibré

Weighted, balanced (weightedBalanced) utilise une formule pour calculer le poids de chaque tâche. Deadline Cloud assigne d'abord les travailleurs au poste le plus important. Si plusieurs emplois ont le même poids, les travailleurs sont répartis entre eux.

Utilisez l'équilibre pondéré lorsque vous avez besoin d'un contrôle précis sur la façon dont les employés sont répartis entre les tâches, avec des priorités, des taux d'erreur et des délais de soumission variables. Cette configuration convient aux environnements de parc de rendu complexes dans lesquels vous souhaitez trouver l'équilibre entre la priorité des tâches, l'âge de la tâche, la gestion des erreurs et la rigidité des travailleurs.

Le poids de chaque tâche est calculé comme suit :

weight = (job.Priority * priorityWeight) +
         (job.Errors * errorWeight) +
         ((currentTimeInSeconds - job.SubmissionTime) * submissionTimeWeight) +
         ((job.RenderingTasks - renderingTaskBuffer) * renderingTaskWeight)

Le renderingTaskBuffer composant n'est appliqué que si le travailleur travaille actuellement sur le poste. renderingTaskWeightIl est généralement défini sur une valeur négative afin que les tâches auxquelles des travailleurs ont été affectés reçoivent une pondération inférieure, plaçant ainsi les autres tâches en tête de la file d'attente. errorWeightIl est également généralement négatif, de sorte que les tâches comportant des erreurs ne sont pas hiérarchisées. Vous pouvez utiliser les remplacements de planification pour les tâches à priorité minimale et maximale.

Cette configuration comporte les paramètres suivants :

Déterminer la compatibilité de la flotte

Après avoir créé une tâche, Deadline Cloud vérifie les exigences en matière d'hôte pour chaque étape de la tâche par rapport aux capacités des flottes associées à la file d'attente à laquelle la tâche a été soumise. Si une flotte répond aux exigences de l'hôte, le poste est confié à l'READYÉtat.

Si une étape de la tâche comporte des exigences qui ne peuvent pas être satisfaites par une flotte associée à la file d'attente, le statut de l'étape est défini surNOT_COMPATIBLE. De plus, les autres étapes de la tâche sont annulées.

Les capacités d'une flotte sont définies au niveau de la flotte. Même si un travailleur d'un parc répond aux exigences du poste, aucune tâche ne lui sera affectée si son parc ne répond pas aux exigences du poste.

Le modèle de tâche suivant comporte une étape qui spécifie les exigences de l'hôte pour l'étape :

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

Cette tâche peut être planifiée pour une flotte dotée des fonctionnalités suivantes :

{
    "vCpuCount": {"min": 4, "max": 8},
    "memoryMiB": {"min": 1024},
    "osFamily": "linux",
    "cpuArchitectureType": "x86_64"
}

Cette tâche ne peut pas être planifiée pour une flotte dotée de l'une des fonctionnalités suivantes :

{
    "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.

Dimensionnement du parc

Lorsqu'une tâche est attribuée à un parc géré par des services compatibles, le parc est redimensionné automatiquement. Le nombre de travailleurs de la flotte varie en fonction du nombre de tâches pouvant être exécutées par la flotte.

Lorsqu'une tâche est attribuée à un parc géré par le client, il se peut que des employés existent déjà ou qu'ils puissent être créés à l'aide de la mise à l'échelle automatique basée sur les événements. Pour plus d'informations, consultez la section Utiliser EventBridge pour gérer les événements de dimensionnement automatique dans le guide de l'utilisateur d'Amazon EC2 Auto Scaling.

Séances

Les tâches d'une tâche sont divisées en une ou plusieurs sessions. Les travailleurs exécutent les sessions pour configurer l'environnement, exécuter les tâches, puis détruire l'environnement. Chaque session est composée d'une ou de plusieurs actions que le travailleur doit effectuer.

Au fur et à mesure qu'un collaborateur exécute des actions de section, des actions de session supplémentaires peuvent lui être envoyées. Le travailleur réutilise les environnements existants et les pièces jointes aux tâches au cours de la session pour effectuer les tâches de manière plus efficace.

Pour les employés de flotte gérés par des services, les répertoires de sessions sont supprimés à la fin de la session, mais les autres répertoires sont conservés entre les sessions. Ce comportement vous permet de mettre en œuvre des stratégies de mise en cache pour les données qui peuvent être réutilisées au cours de plusieurs sessions. Pour mettre en cache les données entre les sessions, stockez-les dans le répertoire personnel de l'utilisateur exécutant la tâche. Par exemple, les packages conda sont mis en cache dans le répertoire personnel de l'utilisateur à l'adresse C:\Users\job-user\.conda-pkgs on Windows workers et /home/job-user/.conda-pkgs on Linux workers. Ces données restent disponibles jusqu'à ce que le travailleur arrête ses activités.

Les pièces jointes aux tâches sont créées par l'émetteur que vous utilisez dans le cadre de votre offre de tâches Deadline Cloud CLI. Vous pouvez également créer des pièces jointes à des tâches à l'aide de l'--attachmentsoption de create-job AWS CLI commande. Les environnements sont définis à deux endroits : les environnements de file d'attente attachés à une file d'attente spécifique et les environnements de travail et d'étapes définis dans le modèle de travail.

Il existe quatre types d'actions de session :

Le modèle de tâche suivant comporte un environnement par étapes. Il contient une onEnter définition pour configurer l'environnement des étapes, une onRun définition qui définit la tâche à exécuter et une onExit définition pour démonter l'environnement des étapes. Les sessions créées pour cette tâche incluront une envEnter action, une ou plusieurs taskRun actions, puis une envExit action.

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 des actions de session

Le pipeline des actions de session permet à un planificateur de préattribuer plusieurs actions de session à un travailleur. Le travailleur peut ensuite exécuter ces actions de manière séquentielle, réduisant ou éliminant le temps d'inactivité entre les tâches.

Pour créer une affectation initiale, le planificateur crée une session avec une tâche, le collaborateur exécute la tâche, puis le planificateur analyse la durée de la tâche pour déterminer les futures affectations.

Pour que le planificateur soit efficace, il existe des règles relatives à la durée des tâches. Pour les tâches de moins d'une minute, le planificateur utilise un schéma de croissance basé sur la puissance de 2. Par exemple, pour une tâche d'une seconde, le planificateur affecte 2 nouvelles tâches, puis 4, puis 8. Pour les tâches de plus d'une minute, le planificateur n'assigne qu'une seule nouvelle tâche et le pipeline reste désactivé.

Pour calculer la taille du pipeline, le planificateur effectue les opérations suivantes :

Grâce au pipeline des actions de session, les employés commencent immédiatement de nouvelles tâches et il n'y a aucun temps d'attente entre les demandes du planificateur. Il améliore également l'efficacité des travailleurs et une meilleure répartition des tâches pour les processus de longue durée.

En outre, si une nouvelle tâche plus prioritaire est disponible, le travailleur terminera toutes les tâches précédemment assignées avant la fin de sa session en cours et une nouvelle session provenant d'une tâche plus prioritaire sera attribuée.

Dépendances des étapes

Deadline Cloud prend en charge la définition des dépendances entre les étapes afin qu'une étape attende la fin d'une autre étape avant de commencer. Vous pouvez définir plusieurs interdépendances pour une étape. Une étape comportant une dépendance n'est planifiée que lorsque toutes ses dépendances sont terminées.

Si le modèle de tâche définit une dépendance circulaire, la tâche est rejetée et son statut est défini surCREATE_FAILED.

Le modèle de tâche suivant crée une tâche en deux étapes. StepBdépend deStepA. StepBne s'exécute qu'une fois StepA terminé avec succès.

Une fois le travail créé, StepA il est dans l'READYétat et StepB est dans l'PENDINGétat. Après avoir StepA terminé, StepB passe à l'READYétat. En cas d'StepAéchec ou StepA d'annulation, StepB passe à l'CANCELEDétat.

Vous pouvez définir une dépendance pour plusieurs étapes. Par exemple, si StepC cela dépend des deux StepA etStepB, StepC ne démarrera pas tant que les deux autres étapes ne seront pas terminées.

Les dépendances entre les étapes sont soumises aux restrictions suivantes :

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!