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 programación, las capacidades configuradas para la flota y los requisitos de hospedaje de un paso específico.

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

Configuraciones de programación

Puede configurar la forma en que Deadline Cloud programa los trabajos de 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 al CreateQueuequirófano UpdateQueue APIs.

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 la programación mientras las tareas están en ejecución, el cambio solo se aplica cuando se asignen los siguientes trabajadores. Las tareas en ejecución no se interrumpen ni se reasignan.

Prioridad, first-in-first-out

La prioridad, first-in-first-out (priorityFifo) es la configuración de programación predeterminada para las colas nuevas. Deadline Cloud asigna primero a los trabajadores el trabajo de mayor prioridad. Cuando varios trabajos comparten la misma prioridad, el trabajo más antiguo (presentado 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 en el orden en que se enviaron, por ejemplo, en etapas de procesamiento secuenciales o en el procesamiento por lotes, donde cada trabajo debe finalizar antes de que comience el siguiente.

Esta configuración no tiene parámetros adicionales.

Prioridad, equilibrada

Priority, balanced (priorityBalanced) distribuye a los trabajadores de manera uniforme entre todos los puestos de trabajo 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 se pueden dividir en partes iguales, los trabajadores adicionales se distribuyen entre los trabajos de mayor prioridad.

Utilice el equilibrio de prioridades 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 se asignen trabajadores a todos los usuarios poco después de enviarlos.

Si a un trabajo le quedan menos tareas que la proporción de trabajadores que le corresponde, los trabajadores sobrantes se redistribuyen a otros trabajos con el mismo nivel de prioridad. Si todos los puestos de trabajo con la máxima prioridad se asignan en su totalidad, los trabajadores sobrantes se desplazan en cascada a los puestos del siguiente nivel de máxima prioridad.

Esta configuración tiene el siguiente parámetro:

Ponderado y equilibrado

Weighted, balanced (weightedBalanced) utiliza una fórmula para calcular el peso de 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 una ponderación equilibrada cuando necesite un control pormenorizado sobre la distribución de los trabajadores en los distintos trabajos, con diferentes prioridades, tasas de error y tiempos de entrega. Esta configuración es adecuada para entornos de granjas de renderizados complejas en los que desee ajustar el equilibrio entre la prioridad del trabajo, la antigüedad del trabajo, la gestión de errores y la dedicación 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 importancia, lo que hace que los demás trabajos ocupen el primer lugar de la lista. También errorWeight suele ser negativo, por lo que se pierde la prioridad de los trabajos con errores. Puede utilizar las anulaciones de programación para los trabajos de prioridad mínima y máxima.

Esta configuración tiene los siguientes parámetros:

Determine la compatibilidad de la flota

Tras crear un trabajo, Deadline Cloud compara los requisitos de alojamiento para cada paso del trabajo con las capacidades de las flotas asociadas a la cola a la que se envió el trabajo. Si una flota cumple con los requisitos de hospedaje, el trabajo pasa a manos del READY estado.

Si algún paso del trabajo tiene requisitos que una flota asociada a la cola no puede cumplir, el estado del paso se establece en. NOT_COMPATIBLE Además, el resto de los pasos del trabajo se cancelan.

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 tiene un paso que especifica los requisitos de anfitrión para el 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

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

{
    "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 capacidades:

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

Escalado de flotas

Cuando se asigna un trabajo a una flota compatible gestionada por un servicio, la flota se escala automáticamente. El número de trabajadores de la flota cambia en función del número de tareas disponibles para la flota.

Cuando se asigna un trabajo a una flota gestionada por el cliente, es posible que ya existan trabajadores o que se puedan crear mediante el escalado automático basado en eventos. Para obtener más información, consulte Uso EventBridge para gestionar eventos de autoescalado 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 dirigen 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 el trabajador debe realizar.

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 existentes y los adjuntos de trabajo en la sesión para completar las tareas de manera más eficiente.

En el caso de los trabajadores de flotas gestionados por el servicio, los directorios de las sesiones se eliminan una vez finalizada la sesión, pero los demás directorios se conservan entre sesiones. Este comportamiento le permite implementar estrategias de almacenamiento en caché para los datos que se pueden reutilizar en varias sesiones. Para almacenar en caché los datos entre sesiones, guárdelos en el directorio principal del usuario que ejecuta el trabajo. Por ejemplo, los paquetes 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 deje de trabajar.

El remitente crea los adjuntos de trabajo y los utilizas como parte de tu paquete de trabajos CLI de Deadline Cloud. También puede crear 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 escalones definidos en la plantilla de trabajos.

Hay cuatro tipos de acciones de sesión:

La siguiente plantilla de trabajo tiene un entorno escalonado. Cuenta con 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 acciones de sesión permite a un programador preasignar 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 tareas.

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

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

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

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

Además, si hay disponible un nuevo trabajo de mayor prioridad, el trabajador terminará todo el trabajo que se le asignó 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 permite definir las dependencias entre los pasos, de modo que un paso espere a que se complete otro paso antes de empezar. Puedes definir más de una dependencia para un paso. Un paso con una dependencia no se programa hasta que todas sus dependencias estén completas.

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 se encuentra en el READY estado y StepB se encuentra en el PENDING estado. Una vez StepA finalizado, StepB pasa al READY estado. Si StepA falla o StepA se cancela, StepB pasa al CANCELED estado.

Puede establecer una dependencia en varios pasos. Por ejemplo, si StepC depende de ambos StepA pasosStepB, StepC no empezará 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!