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 [CreateQueue](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateQueue.html)quirófano [UpdateQueue](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_UpdateQueue.html) APIs. Hay tres configuraciones de programación disponibles: + **Prioridad, first-in-first-out** (`priorityFifo`): programa primero el trabajo de mayor prioridad y el primero enviado (predeterminado). + **Prioridad, equilibrada** (`priorityBalanced`): distribuye a los trabajadores de manera uniforme entre los trabajos de mayor prioridad. + **Ponderado, equilibrado** (`weightedBalanced`): utiliza una fórmula ponderada para determinar cómo se distribuyen los trabajadores entre los puestos de trabajo. 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: `renderingTaskBuffer` Controla la adherencia de los trabajadores. Un trabajador cambia de su trabajo actual a otro con la misma prioridad solo si la diferencia en la representación de las tareas supera el `renderingTaskBuffer` valor. Un valor más alto mantiene a los trabajadores en sus puestos de trabajo actuales durante más tiempo, lo que reduce el cambio de contexto. El valor predeterminado es `1`. ### 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: `priorityWeight` El peso que se aplica a la prioridad de un trabajo. Un valor positivo significa que los trabajos de mayor prioridad se programan primero. El valor predeterminado es `100.0`. Rango: 2 `0` a. `10000` `errorWeight` El peso aplicado al recuento de errores de un trabajo. Un valor negativo significa que los trabajos sin errores se programan primero. El valor predeterminado es `-10.0`. Rango: 2 `-10000` a`10000`. `submissionTimeWeight` El peso aplicado al tiempo de presentación de un trabajo (en segundos). Un valor positivo significa que los trabajos presentados anteriormente se programan primero. El valor predeterminado es `3.0`. Rango: 2 `0` a`10000`. `renderingTaskWeight` El peso aplicado al número de tareas que se están procesando actualmente para un trabajo. Un valor negativo significa que los próximos trabajos con menos trabajadores están programados. El valor predeterminado es `-100.0`. Rango: 2 `-10000` a`10000`. `renderingTaskBuffer` El número de tareas de renderizado antes de que surta efecto el peso de la tarea de renderizado. Un valor positivo mantiene a los trabajadores en sus puestos de trabajo actuales. El valor predeterminado es `1`. Rango: 2 `0` a`1000`. `maxPriorityOverride` Opcional. Si se establece en`alwaysScheduleFirst`, los trabajos con la máxima prioridad (100) siempre se programan antes que los demás trabajos, independientemente de la fórmula ponderada. Cuando varios trabajos tienen la máxima prioridad, los empates se rompen mediante la fórmula ponderada estándar. Cuando no existe la anulación, los trabajos de máxima prioridad utilizan la fórmula ponderada estándar sin ningún tratamiento especial. `minPriorityOverride` Opcional. Si se establece en`alwaysScheduleLast`, los trabajos con la prioridad mínima (0) siempre se programan después de otros trabajos, independientemente de la fórmula ponderada. Cuando varios trabajos tienen la prioridad mínima, los empates se rompen mediante la fórmula ponderada estándar. Cuando no existe la anulación, los trabajos de prioridad mínima utilizan la fórmula ponderada estándar sin ningún tratamiento especial. ## 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](https://docs.aws.amazon.com/autoscaling/ec2/userguide/automating-ec2-auto-scaling-with-eventbridge.html) 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: + `syncInputJobAttachments`— Descarga los archivos adjuntos al trabajo de entrada para el trabajador. + `envEnter`— Realiza las `onEnter` acciones de un entorno. + `taskRun`— Realiza las `onRun` acciones de una tarea. + `envExit`— Realiza las `onExit` acciones para un entorno. 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: + Utiliza la duración media de las tareas completadas + Su objetivo es mantener ocupado al trabajador durante un minuto + Considera solo las tareas de la misma sesión + No comparte los datos de duración entre los trabajadores 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. `StepB`depende de`StepA`. `StepB`solo 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` pasos`StepB`, `StepC` no empezará hasta que finalicen los otros dos pasos. Las dependencias escalonadas tienen las siguientes restricciones: + **Dependencias por paso**: un paso puede depender de un máximo de otros 128 pasos. + **Consumidores por paso**: un máximo de otros 32 pasos pueden depender de un solo paso. ``` 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! ```