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.

Planifiez 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 fonctionnalités configurées pour la flotte et des exigences de l'hôte pour une étape spécifique.

Les sections suivantes fournissent des détails 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 les UpdateQueue API CreateQueue ou.

Trois configurations de planification sont disponibles :

Dans toutes les configurations de planification, les tâches en cours sont exécutées jusqu'à leur achèvement 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 lors de la prochaine affectation des travailleurs. Les tâches en cours ne sont ni interrompues ni réaffectées.

Priorité, premier entré, premier sorti

Priority, first-in-first-out (priorityFifo) est la configuration de planification par défaut pour les nouvelles files d'attente. Deadline Cloud attribue les tâches les plus prioritaires aux employés en premier. 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 la priorité FIFO 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émarrage de la suivante.

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

Priorité, équilibre

Priorité et équilibre (priorityBalanced) répartit les travailleurs de manière égale entre tous les emplois au niveau de priorité le plus élevé. Lorsqu'il n'existe qu'une seule tâche prioritaire, Deadline Cloud affecte tous les travailleurs à cette tâche. Lorsque plusieurs emplois ont la priorité la plus élevée, les travailleurs sont répartis de manière égale entre eux. Si les travailleurs ne peuvent pas être répartis de manière égale, 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 offres 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 comporte moins de tâches que sa part de travailleurs, les travailleurs excédentaires sont redistribués vers d'autres emplois au même niveau de priorité. Si tous les emplois les plus prioritaires sont entièrement attribués, les travailleurs excédentaires se retrouveront en cascade vers les emplois du niveau de priorité le plus élevé suivant.

Cette configuration comporte le paramètre suivant :

Pondéré, équilibré

Pondéré, équilibré (weightedBalanced) utilise une formule pour calculer un poids pour chaque tâche. Deadline Cloud attribue en premier lieu aux travailleurs les tâches les plus importantes. 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 répartition des collaborateurs 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 ferme de rendu complexes dans lesquels vous souhaitez trouver un équilibre entre la priorité des tâches, leur âge, la gestion des erreurs et la fidélité des collaborateurs.

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 est appliqué uniquement si le travailleur travaille actuellement sur le poste. La valeur renderingTaskWeight est généralement négative, de sorte que les tâches auxquelles des travailleurs sont affectés reçoivent une pondération inférieure, plaçant les autres tâches en tête de la file d'attente. Le errorWeight est également généralement négatif, de sorte que les tâches contenant des erreurs ne sont pas prioritaires. Vous pouvez utiliser des modifications de planification pour les tâches à priorité minimale et maximale.

Cette configuration comporte les paramètres suivants :

Déterminer la compatibilité de la flotte

Les files d'attente et les flottes se répartissent le travail des tâches de routage. Une file d'attente organise les tâches et contrôle qui peut les soumettre et les consulter. Les exigences relatives aux flottes et aux hôtes déterminent les travailleurs qui exécutent chaque étape.

Pour affecter des travailleurs spécifiques à certains emplois, créez une flotte distincte pour ces travailleurs au lieu d'une file d'attente distincte. Par exemple, utilisez un parc distinct pour les machines dotées d'un matériel particulier ou pour les machines réservées au contenu sensible. Une file d'attente peut être associée à plusieurs flottes, et les exigences en matière d'hôte de chaque étape sélectionnent une flotte compatible. Si vous arrivez avant la date limite 10, les exigences relatives aux flottes et aux hôtes remplacent les groupes de travailleurs. Pour la cartographie conceptuelle complète, voirMigrer de Deadline 10 à AWS Deadline Cloud.

Une fois que vous avez 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, la tâche est attribuée à 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. Si vous associez ultérieurement une flotte compatible à la file d'attente, les NOT_COMPATIBLE tâches existantes ne redémarrent pas automatiquement. Pour les exécuter, mettez-les en file d'attente. Pour de plus amples informations, veuillez consulter Modifier une tâche dans Deadline Cloud.

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

Le modèle de tâche suivant comporte une étape qui spécifie les exigences en matière d'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

Les soumissionnaires définissent les mêmes exigences via l'onglet Exigences de l'hôte. Choisissez Exécuter sur des hôtes de travail qui répondent aux exigences suivantes pour définir un système d'exploitation, une architecture de processeur et des plages matérielles sans modifier le modèle.

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.

Meilleures pratiques en matière de conception de flotte

Étant donné que le planificateur évalue la compatibilité au niveau de la flotte, concevez vos flottes gérées par le client de manière à ce que les valeurs déclarées workerCapabilities représentent les caractéristiques matérielles minimales garanties pour chaque travailleur de la flotte :

Par exemple, si vos employés disposent d'un processeur graphique (24 Go de VRAM) et ceux de quatre processeurs graphiques (96 Go de VRAM), créez deux parcs distincts : l'un déclare au moins 1 processeur graphique et 24 Go de mémoire graphique, et l'autre déclare un minimum de 4 processeurs graphiques et 96 Go de mémoire graphique. Associez ensuite les deux flottes à la même file d'attente. Les étapes qui nécessitent 4 GPU sont automatiquement acheminées vers le parc de processeurs graphiques élevés.

Pour plus d'informations sur la création d'une flotte gérée par le client, consultez. Créez une flotte gérée par le client

Capacités personnalisées

Outre les fonctionnalités de travail intégrées (processeur virtuel, mémoire, processeur graphique, système d'exploitation et architecture du processeur), vous pouvez définir des montants personnalisés et des attributs personnalisés sur un parc afin d'exprimer des contraintes de planification supplémentaires :

Au niveau de la flotte, déclarez les combinaisons logicielles ou matérielles dans les fonctionnalités personnalisées uniquement si leur existence est garantie pour tous les travailleurs de cette flotte.

Fleet-level les fonctionnalités personnalisées présentent les limites suivantes :

Les noms figurent dans le formulaire amount.worker.* et attr.worker.* sont réservés par le service pour les fonctionnalités intégrées. Utilisez d'autres préfixes pour vos fonctionnalités personnalisées.

L'exemple suivant achemine les étapes qui nécessitent un solveur spécifique vers la flotte qui le fournit. La flotte déclare les solveurs installés sur tous ses travailleurs dans un attribut personnalisé. Cette configuration de flotte fait partie de la CreateFleet demande :

"workerCapabilities": {
    "vCpuCount": {"min": 4},
    "memoryMiB": {"min": 16384},
    "osFamily": "linux",
    "cpuArchitectureType": "x86_64",
    "customAttributes": [
        {
            "name": "attr.sw.solvers",
            "values": ["vray-6", "arnold-7"]
        }
    ]
}

Une étape qui nécessite l'une des valeurs déclarées indique l'exigence hostRequirements dans son modèle de tâche :

steps:
- name: RenderWithVray
  hostRequirements:
    attributes:
    - name: attr.sw.solvers
      anyOf:
      - vray-6
  script:
    actions:
      onRun:
        command: '{{Task.File.Render}}'

Cette exigence permet de maintenir l'RenderWithVrayécart entre les flottes qui ne déclarent vray-6 rien. L'inverse n'est pas vrai : une étape sans attr.sw.solvers exigence est toujours compatible avec cette flotte et peut être programmée sur celle-ci.

Pour plus d'informations sur la configuration des fonctionnalités personnalisées lors de la création d'une flotte, consultezCréez une flotte gérée par le client.

Rapports sur la mémoire GPU

Lorsque vous configurez des parcs pour des GPU-intensive charges de travail qui nécessitent un seuil VRAM par GPU spécifique, comprenez comment l'agent de travail enregistre la mémoire GPU.

L'agent de travail Deadline Cloud indique la quantité minimale de mémoire GPU sur tous les GPU du workeramount.worker.gpu.memory, et non la somme totale. Ce comportement garantit que les tâches nécessitant une quantité de VRAM par GPU spécifique sont acheminées vers les opérateurs où chaque GPU répond à cette exigence.

Par exemple, si un travailleur possède deux GPU avec respectivement 24 GiB et 48 GiB de VRAM, l'agent de travail indique 24 GiB comme valeur de mémoire GPU.

Au niveau de la flotte, définissez le acceleratorTotalMemoryMiB minimum sur la plus faible quantité de VRAM par GPU dont tout travailleur de la flotte est assuré de disposer.

Per-worker capacités

Lorsque vous devez suivre l'état opérationnel de chaque travailleur sans affecter les décisions de planification, utilisez les fonctionnalités par travailleur. Par exemple, vous pouvez signaler les travailleurs pour la maintenance, suivre l'état du déploiement des logiciels ou enregistrer les indicateurs de contrôle de santé.

Vous pouvez définir des fonctionnalités pour chaque travailleur à l'aide de l'opération UpdateWorker API. Per-worker les capacités ne sont pas utilisées comme contrat de planification. Le planificateur évalue la compatibilité exclusivement par rapport à la déclaration au niveau de la flotteworkerCapabilities.

Les ListWorkers opérations GetWorker et ne restituent pas les capacités des travailleurs qui ont été définiesUpdateWorker.

Pour plus d'informations, consultez la référence UpdateWorker de l'API Deadline Cloud.

Contrôle d'accès et sélection des travailleurs

Deadline Cloud distingue qui peut utiliser une ressource de l'endroit où les tâches sont exécutées. Les politiques IAM et les appartenances aux AWS IAM Identity Center utilisateurs et aux groupes contrôlent qui peut consulter, soumettre et gérer un parc, une file d'attente ou une flotte. Les associations entre la file d'attente et la flotte et les exigences de l'hôte contrôlent quels travailleurs exécutent chaque tâche.

L'appartenance à un groupe sur une flotte permet aux utilisateurs de visualiser et de gérer cette flotte sur le moniteur. L'adhésion n'achemine pas les emplois vers la flotte et ne permet pas de supprimer des emplois. Pour diriger le travail vers ou hors d'une flotte, utilisez les associations entre la file d'attente et la flotte.

Les exigences relatives à l'hôte font partie du modèle de poste, de sorte que la personne qui soumet le poste les choisit. Ils acheminent le travail vers des flottes compétentes et ne constituent pas un contrôle d'accès. L'association file d'attente et flotte est le point d'application : le service planifie une étape uniquement pour les flottes associées à la file d'attente de la tâche, quelles que soient les exigences de l'hôte de l'étape. Pour empêcher le travail non autorisé sur une flotte restreinte, associez la flotte uniquement à des files d'attente restreintes et contrôlez qui peut se soumettre à ces files d'attente. Pour plus d'informations sur les limites de sécurité entre les files d'attente et les flottes qui partagent des employés, consultezIsolez les charges de travail avec les fermes, les flottes et les files d'attente.

Dimensionnement du parc

Lorsqu'une tâche est attribuée à un parc géré par des services compatible, le parc est automatiquement redimensionné. Le nombre de travailleurs dans la flotte varie en fonction du nombre de tâches disponibles pour l'exécution de la flotte.

Lorsqu'une tâche est attribuée à une flotte gérée par le client, des travailleurs peuvent déjà exister ou peuvent ê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'un poste sont divisées en une ou plusieurs sessions. Les travailleurs organisent les sessions pour configurer l'environnement, exécuter les tâches, puis démolir l'environnement. Chaque session est composée d'une ou de plusieurs actions qu'un travailleur doit effectuer.

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

Pour les travailleurs de parc gérés par des services, les répertoires de session 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 sur plusieurs sessions. Pour mettre en cache les données entre les sessions, stockez-les dans le répertoire d'accueil de l'utilisateur qui exécute la tâche. Par exemple, les packages conda sont mis en cache dans le répertoire personnel de l'utilisateur de la tâche à 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 de fonctionner.

Les pièces jointes aux tâches sont créées par l'expéditeur 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 la 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 tâches et d'étapes définis dans le modèle de tâche.

Il existe quatre types d'actions de session :

Le modèle de poste suivant comporte un environnement par étapes. Il comporte une onEnter définition pour configurer l'environnement d'étapes, une onRun définition qui définit la tâche à exécuter et une onExit définition pour supprimer l'environnement d'étapes. Les sessions créées pour cette tâche comprendront 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 travailleur termine la tâche, puis le planificateur analyse la durée de la tâche pour déterminer les affectations futures.

Pour que le planificateur soit efficace, il existe des règles de durée des tâches. Pour les tâches de moins d'une minute, le planificateur utilise un modèle de croissance « power of 2 ». Par exemple, pour une tâche d'une seconde, le planificateur attribue 2 nouvelles tâches, puis 4, puis 8. Pour les tâches de plus d'une minute, le planificateur n'attribue 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 collaborateurs commencent immédiatement de nouvelles tâches et il n'y a pas de temps d'attente entre les demandes du planificateur. Il permet également d'améliorer 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 prioritaire est disponible, le travailleur terminera toutes les tâches qui lui ont été 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 entre étapes

Deadline Cloud prend en charge la définition des dépendances entre les étapes, de sorte qu'une étape attende la fin d'une autre étape avant de démarrer. Vous pouvez définir plusieurs dé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 permet de créer une tâche en deux étapes. StepBdépend deStepA. StepBne s'exécute qu'une fois StepA terminé avec succès.

Une fois l'emploi 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 en fonction de plusieurs étapes. Par exemple, StepC cela dépend des deux StepA et StepC ne StepB démarrera pas tant que les deux autres étapes ne seront pas terminées.

Les interdépendances entre é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!