Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Programe trabajos en Deadline Cloud

Después de crear un trabajo, AWS Deadline Cloud lo programa para que se procese en una o más de las flotas asociadas a una cola. La flota que procesa una tarea en particular se elige en función de la configuración de la programación, las capacidades configuradas para la flota y los requisitos del anfitrión de una etapa específica.

Las siguientes secciones proporcionan detalles del proceso de programación de un trabajo.

Programación de configuraciones

Puede configurar la forma en que Deadline Cloud programa los trabajos en una cola estableciendo una configuración de programación en la cola. La configuración de programación controla cómo se distribuyen los trabajadores entre los trabajos.

Puede establecer la configuración de la programación mediante la consola de Deadline Cloud o llamando a las UpdateQueue API CreateQueue o.

Hay tres configuraciones de programación disponibles:

En todas las configuraciones de programación, las tareas en curso se completan antes de que se tome una nueva decisión de programación. Si cambias la configuración de programación mientras se están ejecutando las tareas, el cambio solo se aplicará cuando se asignen los siguientes trabajadores. Las tareas en ejecución no se interrumpen ni se reasignan.

Prioridad, primero en entrar, primero en salir

Prioridad: primero en entrar, primero en salir (priorityFifo) es la configuración de programación predeterminada para las nuevas colas. Deadline Cloud asigna primero a los trabajadores el trabajo de mayor prioridad. Cuando varios trabajos comparten la misma prioridad, el trabajo más antiguo (el que se envió más temprano) recibe primero a todos los trabajadores disponibles.

Utilice el FIFO prioritario cuando desee ordenar los trabajos de forma estricta. Esta configuración es adecuada cuando los trabajos deben completarse de uno en uno y en el orden en que se enviaron, como en las etapas de procesamiento secuenciales o en el procesamiento por lotes, donde cada trabajo debe terminar antes de que comience el siguiente.

Esta configuración no tiene parámetros adicionales.

Prioridad, equilibrada

Prioritario y equilibrado (priorityBalanced) distribuye a los trabajadores de manera uniforme en todos los trabajos con el nivel de prioridad más alto. Cuando solo existe un trabajo con la máxima prioridad, Deadline Cloud asigna a todos los trabajadores a ese trabajo. Cuando varios trabajos comparten la máxima prioridad, los trabajadores se dividen equitativamente entre ellos. Si los trabajadores no pueden dividirse equitativamente, los trabajadores adicionales se distribuyen entre los trabajos de mayor prioridad.

Usa el equilibrio de prioridad cuando varios artistas o usuarios envíen trabajos con la misma prioridad y cada usuario necesite comentarios inmediatos. Esta configuración garantiza que ningún trabajo monopolice a todos los trabajadores disponibles, de modo que a todos los usuarios se les asignen trabajadores poco después de su envío.

Si a un trabajo le quedan menos tareas de las que le corresponde, los trabajadores sobrantes se redistribuyen a otros trabajos del mismo nivel de prioridad. Si todos los puestos de máxima prioridad se asignan en su totalidad, los trabajadores sobrantes pasan a ocupar los puestos del siguiente nivel de máxima prioridad.

Esta configuración tiene el siguiente parámetro:

Ponderado y equilibrado

Ponderado, equilibrado (weightedBalanced) utiliza una fórmula para calcular una ponderación para cada trabajo. Deadline Cloud asigna primero a los trabajadores el trabajo con mayor peso. Si varios trabajos tienen el mismo peso, los trabajadores se distribuyen entre ellos.

Utilice el sistema de ponderación balanceada cuando necesite un control detallado sobre cómo se distribuyen los trabajadores entre los trabajos, con diferentes prioridades, tasas de error y tiempos de presentación. Esta configuración es adecuada para entornos complejos de granjas de renderizado en los que se desea ajustar el equilibrio entre la prioridad de los trabajos, la antigüedad de los trabajos, la gestión de errores y la persistencia de los trabajadores.

El peso de cada trabajo se calcula de la siguiente manera:

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

El renderingTaskBuffer componente se aplica solo si el trabajador está trabajando actualmente en el trabajo. Por lo general, renderingTaskWeight se establece en un valor negativo para que los trabajos con trabajadores asignados reciban una menor ponderación, lo que hace que otros trabajos pasen a primer plano. También errorWeight suele ser negativo, por lo que los trabajos con errores pierden prioridad. Puede usar anulaciones de programación para trabajos de prioridad mínima y máxima.

Esta configuración tiene los siguientes parámetros:

Determine la compatibilidad de la flota

Las colas y las flotas dividen el trabajo de enrutamiento. Una cola organiza los trabajos y controla quién puede enviarlos y verlos. Las flotas y los requisitos de hospedaje seleccionan qué trabajadores ejecutan cada paso.

Para dedicar trabajadores específicos a determinados trabajos, crea una flota separada para esos trabajadores en lugar de una cola separada. Por ejemplo, usa una flota separada para las máquinas con un hardware determinado o para las máquinas reservadas para contenido confidencial. Una cola se puede asociar a varias flotas, y los requisitos de alojamiento de cada paso seleccionan una flota compatible. Si vences de Deadline 10, las flotas y los requisitos de hospedaje sustituyen a los grupos de trabajadores. Para ver el mapa conceptual completo, consulteMigre de Deadline 10 a AWS Deadline Cloud.

Después de crear un trabajo, Deadline Cloud comprueba los requisitos del anfitrión para cada paso del trabajo comparándolos con las capacidades de las flotas asociadas a la cola a la que se envió el trabajo. Si una flota cumple los requisitos de hospedaje, el trabajo se asigna al READY estado.

Si algún paso del trabajo tiene requisitos que no puede cumplir una flota asociada a la cola, el estado del paso se establece en. NOT_COMPATIBLE Además, se cancelan el resto de los pasos del trabajo. Si más adelante asocias una flota compatible a la cola, los NOT_COMPATIBLE trabajos existentes no se reinician automáticamente; para ejecutarlos, vuelve a ponerlos en cola. Para obtener más información, consulte Modificar un trabajo en Deadline Cloud.

Las capacidades de una flota se establecen a nivel de flota. Incluso si un trabajador de una flota cumple con los requisitos del trabajo, no se le asignarán tareas del trabajo si su flota no cumple con los requisitos del trabajo.

La siguiente plantilla de trabajo contiene un paso que especifica los requisitos del anfitrión para dicho paso:

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

Los remitentes establecen los mismos requisitos a través de la pestaña de requisitos del anfitrión. Seleccione Ejecutar en hosts de trabajo que cumplan los siguientes requisitos para establecer un sistema operativo, una arquitectura de CPU y unos rangos de hardware sin editar la plantilla.

Este trabajo se puede programar para una flota con las siguientes funciones:

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

Este trabajo no se puede programar para una flota con ninguna de las siguientes funciones:

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

Mejores prácticas de diseño de flotas

Dado que el planificador evalúa la compatibilidad a nivel de flota, diseñe las flotas administradas por los clientes de manera que las declaradas workerCapabilities representen las características de hardware mínimas garantizadas para cada trabajador de la flota:

Por ejemplo, si tiene trabajadores con 1 GPU (24 GiB de VRAM) y trabajadores con 4 GPU (96 GiB de VRAM), cree dos flotas independientes: una que declare un mínimo de 1 GPU y 24 GiB de memoria de GPU, y otra que declare un mínimo de 4 GPU y 96 GiB de memoria de GPU. A continuación, asocie ambas flotas a la misma cola. Los pasos que requieren 4 GPU se redirigen automáticamente a la flota con mayor cantidad de GPU.

Para obtener más información sobre la creación de una flota gestionada por el cliente, consulte. Cree una flota gestionada por el cliente

Capacidades personalizadas

Además de las capacidades de trabajo integradas (vCPU, memoria, GPU, sistema operativo y arquitectura de CPU), puede definir cantidades y atributos personalizados en una flota para expresar las restricciones de programación adicionales:

A nivel de flota, declare las combinaciones de software o hardware en las funciones personalizadas solo si se garantiza que existen en todos los trabajadores de esa flota.

Fleet-level Las capacidades personalizadas tienen los siguientes límites:

Los nombres aparecen en el formulario amount.worker.* y attr.worker.* están reservados por el servicio para las funciones integradas. Utilice otros prefijos para sus capacidades personalizadas.

El siguiente ejemplo redirige los pasos que necesitan un solucionador específico a la flota que lo proporciona. La flota declara los solucionadores instalados en todos sus trabajadores en un atributo personalizado. Esta configuración de la flota forma parte de la CreateFleet solicitud:

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

Un paso que requiere uno de los valores declarados indica el requisito hostRequirements en la plantilla de trabajo:

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

Este requisito mantiene a RenderWithVray raya a las flotas que no declaranvray-6. Lo contrario no es válido: un escalón sin ningún attr.sw.solvers requisito sigue siendo compatible con esta flota y puede programarse para ello.

Para obtener más información sobre la configuración de capacidades personalizadas al crear una flota, consulteCree una flota gestionada por el cliente.

Informes de memoria de GPU

Cuando configures flotas para GPU-intensive cargas de trabajo que requieren un umbral de VRAM específico por GPU, debes entender cómo informa el agente de trabajo sobre la memoria de la GPU.

El agente de trabajo de Deadline Cloud informa sobre la cantidad mínima de memoria de GPU en todas las GPU de la máquina de trabajoamount.worker.gpu.memory, no sobre la suma total. Este comportamiento garantiza que los trabajos que requieren una cantidad específica de VRAM por GPU se envíen a los trabajadores en los que cada GPU cumpla ese requisito.

Por ejemplo, si un trabajador tiene dos GPU con 24 GiB y 48 GiB de VRAM respectivamente, el agente trabajador indica 24 GiB como valor de memoria de la GPU.

A nivel de flota, defina acceleratorTotalMemoryMiB como mínimo la VRAM por GPU más baja que se garantice que tendrá cualquier trabajador de la flota.

Per-worker capacidades

Cuando necesite realizar un seguimiento del estado operativo de los trabajadores individuales sin afectar a las decisiones de programación, utilice las capacidades por trabajador. Por ejemplo, puedes marcar a los trabajadores para que realicen tareas de mantenimiento, hacer un seguimiento del estado de implementación del software o registrar los indicadores de estado.

Puedes configurar las capacidades de los trabajadores individuales mediante la operación de la UpdateWorker API. Per-worker las capacidades no se utilizan como contrato de programación. El planificador evalúa la compatibilidad exclusivamente con la declaración a nivel de flotaworkerCapabilities.

Las ListWorkers operaciones GetWorker y no devuelven las capacidades de los trabajadores que están configuradas. UpdateWorker

Para obtener más información, consulte la referencia UpdateWorker de la API de Deadline Cloud.

Control de acceso y selección de trabajadores

Deadline Cloud separa quién puede usar un recurso del lugar donde se ejecutan los trabajos. Las políticas de IAM y las membresías de AWS IAM Identity Center usuarios y grupos controlan quién puede ver, enviar y administrar una granja, una cola o una flota. Lista de espera: las asociaciones de flotas y los requisitos de hospedaje controlan qué trabajadores ejecutan cada trabajo.

La pertenencia a un grupo en una flota permite a las personas ver y administrar esa flota en el monitor. La membresía no redirige los trabajos a la flota ni los mantiene alejados de ella. Para dirigir el trabajo a una flota o alejarla de ella, utilice asociaciones entre filas y flotas.

Los requisitos del anfitrión forman parte de la plantilla de trabajo, por lo que quien envía el trabajo los elige. Dirigen el trabajo a flotas capaces y no constituyen un control de acceso. La asociación entre la cola y la flota es el punto de referencia: el servicio programa un paso solo para las flotas asociadas a la cola del trabajo, independientemente de lo que digan los requisitos del anfitrión de la etapa. Para evitar trabajos no autorizados en una flota restringida, asocie la flota únicamente a las colas restringidas y controle quién puede acceder a esas colas. Para obtener más información sobre los límites de seguridad entre las colas y las flotas que comparten trabajadores, consulte. Aísle las cargas de trabajo con granjas, flotas y colas

Escalado de flotas

Cuando se asigna un trabajo a una flota compatible gestionada por servicios, la flota se escala automáticamente. La cantidad de trabajadores de la flota cambia en función de la cantidad de tareas disponibles para que la flota ejecute.

Cuando se asigna un trabajo a una flota gestionada por el cliente, es posible que los trabajadores ya existan o se puedan crear mediante el escalado automático basado en eventos. Para obtener más información, consulte Utilización EventBridge para gestionar eventos de escalado automático en la guía del usuario de Amazon EC2 Auto Scaling.

Sesiones

Las tareas de un trabajo se dividen en una o más sesiones. Los trabajadores ejecutan las sesiones para configurar el entorno, ejecutar las tareas y, a continuación, desmantelar el entorno. Cada sesión se compone de una o más acciones que debe realizar un trabajador.

A medida que un trabajador completa las acciones de la sección, se le pueden enviar acciones de sesión adicionales. El trabajador reutiliza los entornos y los archivos adjuntos de trabajo existentes en la sesión para completar las tareas de manera más eficiente.

En el caso de los trabajadores de flotas gestionadas por servicios, los directorios de sesión se eliminan una vez finalizada la sesión, pero los demás directorios se conservan entre las sesiones. Este comportamiento permite implementar estrategias de almacenamiento en caché para los datos que se pueden reutilizar en varias sesiones. Para almacenar datos en caché entre sesiones, almacénelos en el directorio principal del usuario que ejecuta el trabajo. Por ejemplo, los paquetes de conda se almacenan en caché en el directorio principal del usuario del trabajo, en C:\Users\job-user\.conda-pkgs on Windows workers y /home/job-user/.conda-pkgs on Linux workers. Estos datos permanecen disponibles hasta que el trabajador se cierre.

Los archivos adjuntos de trabajo los crea el remitente que utilizas como parte de tu paquete de trabajos de la CLI de Deadline Cloud. También puede crear archivos adjuntos de trabajo mediante la --attachments opción del create-job AWS CLI comando. Los entornos se definen en dos lugares: los entornos de cola adjuntos a una cola específica y los entornos de tareas y etapas definidos en la plantilla de trabajos.

Hay cuatro tipos de acciones de sesión:

La siguiente plantilla de trabajo tiene un entorno escalonado. Tiene una onEnter definición para configurar el entorno escalonado, una onRun definición que define la tarea que se va a ejecutar y una onExit definición para desmantelar el entorno escalonado. Las sesiones creadas para este trabajo incluirán una envEnter acción, una o más taskRun acciones y, a continuación, una envExit acción.

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 }}

Canalización de las acciones de la sesión

La canalización de las acciones de sesión permite al programador asignar previamente varias acciones de sesión a un trabajador. A continuación, el trabajador puede ejecutar estas acciones de forma secuencial, lo que reduce o elimina el tiempo de inactividad entre las tareas.

Para crear una asignación inicial, el programador crea una sesión con una tarea, el trabajador la completa y, a continuación, el programador analiza la duración de la tarea para determinar las asignaciones futuras.

Para que el planificador sea eficaz, existen reglas de duración de las tareas. Para las tareas de menos de un minuto, el planificador utiliza un patrón de crecimiento basado en la potencia de 2. Por ejemplo, para una tarea de 1 segundo, el programador asigna 2 tareas nuevas, luego 4 y, a continuación, 8. Para las tareas de más de un minuto, el planificador asigna solo una tarea nueva y la canalización permanece deshabilitada.

Para calcular el tamaño de la canalización, el planificador hace lo siguiente:

Con la canalización de las acciones de sesión, los trabajadores comienzan nuevas tareas de inmediato y no hay tiempo de espera entre las solicitudes del programador. También mejora la eficiencia de los trabajadores y una mejor distribución de las tareas para los procesos de larga duración.

Además, si hay un nuevo trabajo de mayor prioridad disponible, el trabajador terminará todo el trabajo que se le haya asignado anteriormente antes de que finalice la sesión actual y se le asigne una nueva sesión de un trabajo de mayor prioridad.

Dependencias escalonadas

Deadline Cloud admite la definición de dependencias entre los pasos para que un paso espere hasta que se complete otro paso antes de comenzar. Puede definir más de una dependencia para un paso. Un paso con una dependencia no se programa hasta que se hayan completado todas sus dependencias.

Si la plantilla de trabajo define una dependencia circular, el trabajo se rechaza y su estado se establece en. CREATE_FAILED

La siguiente plantilla de trabajo crea un trabajo en dos pasos. StepBdepende deStepA. StepBsolo se ejecuta después de que StepA se complete correctamente.

Una vez creado el trabajo, StepA está en el READY estado y StepB está en el PENDING estado. Cuando StepA termina, StepB pasa al READY estado. Si StepA falla o si StepA se cancela, StepB pasa al CANCELED estado.

Puede establecer una dependencia en varios pasos. Por ejemplo, StepC depende de ambos StepA y StepB StepC no comenzará hasta que finalicen los otros dos pasos.

Las dependencias escalonadas tienen las siguientes restricciones:

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!