As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Agende trabalhos no Deadline Cloud

Depois de criar um trabalho, AWS o Deadline Cloud o programa para ser processado em uma ou mais frotas associadas a uma fila. A frota que processa uma tarefa específica é escolhida com base na configuração de agendamento, nos recursos configurados para a frota e nos requisitos do host de uma etapa específica.

As seções a seguir fornecem detalhes do processo de agendamento de um trabalho.

Configurações de agendamento

Você pode configurar como o Deadline Cloud agenda trabalhos em uma fila definindo uma configuração de agendamento na fila. A configuração de agendamento controla como os trabalhadores são distribuídos entre os trabalhos.

Você pode definir a configuração de agendamento usando o console do Deadline Cloud ou ligando para o CreateQueueou UpdateQueue APIs.

Há três configurações de agendamento disponíveis:

Em todas as configurações de agendamento, as tarefas em andamento são executadas até a conclusão antes que uma nova decisão de agendamento seja tomada. Se você alterar a configuração de agendamento enquanto as tarefas estiverem em execução, a alteração se aplicará somente quando os trabalhadores forem designados em seguida. As tarefas em execução não são interrompidas nem reatribuídas.

Prioridade, first-in-first-out

Priority, first-in-first-out (priorityFifo) é a configuração de agendamento padrão para novas filas. O Deadline Cloud atribui primeiro aos trabalhadores o trabalho de maior prioridade. Quando vários trabalhos compartilham a mesma prioridade, o trabalho mais antigo (enviado mais cedo) recebe primeiro todos os trabalhadores disponíveis.

Use FIFO prioritário quando quiser uma ordenação estrita de trabalhos. Essa configuração é apropriada quando os trabalhos devem ser concluídos um por vez na ordem em que foram enviados, como estágios sequenciais do pipeline ou processamento em lote, em que cada trabalho deve ser concluído antes do início do próximo.

Essa configuração não tem parâmetros adicionais.

Prioritário, equilibrado

Priority, balanced (priorityBalanced) distribui os trabalhadores uniformemente em todos os trabalhos no nível de prioridade mais alto. Quando existe apenas um trabalho com a prioridade mais alta, o Deadline Cloud atribui todos os trabalhadores a esse trabalho. Quando vários trabalhos compartilham a maior prioridade, os trabalhadores são divididos igualmente entre eles. Se os trabalhadores não puderem ser divididos uniformemente, os trabalhadores extras serão distribuídos entre os empregos de maior prioridade.

Use o balanceamento de prioridade quando vários artistas ou usuários enviarem trabalhos com a mesma prioridade e cada usuário precisar de feedback imediato. Essa configuração garante que nenhum trabalho monopolize todos os trabalhadores disponíveis, de modo que todos os usuários recebam trabalhadores logo após o envio.

Se um trabalho tiver menos tarefas restantes do que sua parcela de trabalhadores, os trabalhadores excedentes serão redistribuídos para outros empregos no mesmo nível de prioridade. Se todos os trabalhos de maior prioridade forem totalmente alocados, os trabalhadores excedentes se transformarão em empregos no próximo nível de prioridade mais alta.

Essa configuração tem o seguinte parâmetro:

Ponderado, equilibrado

Weighted, balanced (weightedBalanced) usa uma fórmula para calcular um peso para cada trabalho. O Deadline Cloud atribui primeiro aos trabalhadores o trabalho de maior peso. Se vários trabalhos tiverem o mesmo peso, os trabalhadores serão distribuídos entre eles.

Use a balança ponderada quando precisar de um controle refinado sobre como os trabalhadores são distribuídos em trabalhos com prioridades, taxas de erro e tempos de envio variados. Essa configuração é apropriada para ambientes complexos de render farm em que você deseja ajustar o equilíbrio entre a prioridade do trabalho, a idade do trabalho, o tratamento de erros e a fidelidade do trabalhador.

O peso de cada trabalho é calculado da seguinte forma:

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

O renderingTaskBuffer componente é aplicado somente se o trabalhador estiver trabalhando atualmente no trabalho. Geralmente, renderingTaskWeight é definido como um valor negativo para que os trabalhos com trabalhadores designados recebam um peso menor, colocando outros trabalhos na frente da fila. Geralmente, também errorWeight é negativo, de modo que os trabalhos com erros não são priorizados. Você pode usar substituições de agendamento para trabalhos de prioridade mínima e máxima.

Essa configuração tem os seguintes parâmetros:

Determine a compatibilidade da frota

Depois de criar um trabalho, o Deadline Cloud verifica os requisitos do host para cada etapa do trabalho em relação aos recursos das frotas associadas à fila para a qual o trabalho foi enviado. Se uma frota atender aos requisitos do anfitrião, o trabalho será colocado no READY estado.

Se alguma etapa do trabalho tiver requisitos que não possam ser atendidos por uma frota associada à fila, o status da etapa será definido como. NOT_COMPATIBLE Além disso, as demais etapas do trabalho são canceladas.

As capacidades de uma frota são definidas no nível da frota. Mesmo que um trabalhador em uma frota atenda aos requisitos do trabalho, ele não receberá tarefas do trabalho se sua frota não atender aos requisitos do trabalho.

O modelo de tarefa a seguir tem uma etapa que especifica os requisitos de host para a etapa:

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

Esse trabalho pode ser programado para uma frota com os seguintes recursos:

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

Esse trabalho não pode ser programado para uma frota com nenhum dos seguintes recursos:

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

Dimensionamento da frota

Quando um trabalho é atribuído a uma frota compatível com gerenciamento de serviços, a frota é escalada automaticamente. O número de trabalhadores na frota muda com base no número de tarefas disponíveis para a frota executar.

Quando um trabalho é atribuído a uma frota gerenciada pelo cliente, os trabalhadores podem já existir ou podem ser criados usando o escalonamento automático baseado em eventos. Para obter mais informações, consulte Use EventBridge para lidar com eventos de auto scaling no Guia do usuário do Amazon EC2 Auto Scaling.

Sessões

As tarefas em um trabalho são divididas em uma ou mais sessões. Os trabalhadores executam as sessões para configurar o ambiente, executar as tarefas e, em seguida, destruir o ambiente. Cada sessão é composta por uma ou mais ações que um trabalhador deve realizar.

Quando um trabalhador conclui as ações da seção, ações adicionais da sessão podem ser enviadas ao trabalhador. O funcionário reutiliza os ambientes e os anexos de trabalho existentes na sessão para concluir as tarefas com mais eficiência.

Em trabalhadores de frotas gerenciados por serviços, os diretórios de sessão são excluídos após o término da sessão, mas outros diretórios são mantidos entre as sessões. Esse comportamento permite que você implemente estratégias de armazenamento em cache para dados que podem ser reutilizados em várias sessões. Para armazenar dados em cache entre as sessões, armazene-os no diretório inicial do usuário que está executando o trabalho. Por exemplo, os pacotes conda são armazenados em cache no diretório inicial do usuário do trabalho em C:\Users\job-user\.conda-pkgs on Windows workers e /home/job-user/.conda-pkgs on Linux workers. Esses dados permanecem disponíveis até que o trabalhador seja desligado.

Os anexos de trabalho são criados pelo remetente e você usa como parte do pacote de trabalhos da CLI do Deadline Cloud. Você também pode criar anexos de trabalho usando a --attachments opção do comando. create-job AWS CLI Os ambientes são definidos em dois lugares: ambientes de fila anexados a uma fila específica e ambientes de tarefas e etapas definidos no modelo de trabalho.

Há quatro tipos de ação de sessão:

O modelo de trabalho a seguir tem um ambiente de etapas. Ele tem uma onEnter definição para configurar o ambiente de etapas, uma onRun definição que define a tarefa a ser executada e uma onExit definição para derrubar o ambiente de etapas. As sessões criadas para esse trabalho incluirão uma envEnter ação, uma ou mais taskRun ações e, em seguida, uma envExit ação.

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 de ações de sessão

O pipeline de ações de sessão permite que um agendador pré-atribua várias ações de sessão a um trabalhador. O trabalhador pode então executar essas ações sequencialmente, reduzindo ou eliminando o tempo ocioso entre as tarefas.

Para criar uma atribuição inicial, o agendador cria uma sessão com uma tarefa, o trabalhador conclui a tarefa e, em seguida, o agendador analisa a duração da tarefa para determinar as atribuições futuras.

Para que o agendador seja eficaz, existem regras de duração da tarefa. Para tarefas com menos de um minuto, o agendador usa um padrão de crescimento de potência de 2. Por exemplo, para uma tarefa de 1 segundo, o agendador atribui 2 novas tarefas, depois 4 e depois 8. Para tarefas com mais de um minuto, o agendador atribui apenas uma nova tarefa e o pipeline permanece desativado.

Para calcular o tamanho do pipeline, o programador faz o seguinte:

Com o pipeline de ações da sessão, os trabalhadores iniciam novas tarefas imediatamente e não há tempo de espera entre as solicitações do agendador. Ele também fornece maior eficiência do trabalhador e melhor distribuição de tarefas para processos de longa execução.

Além disso, se houver um novo trabalho de maior prioridade disponível, o trabalhador concluirá todo o trabalho anteriormente atribuído antes que a sessão atual termine e uma nova sessão de um trabalho de maior prioridade seja atribuída.

Dependências de etapas

O Deadline Cloud suporta a definição de dependências entre as etapas para que uma etapa espere até que outra seja concluída antes de começar. Você pode definir mais de uma dependência para uma etapa. Uma etapa com uma dependência não é agendada até que todas as dependências estejam concluídas.

Se o modelo de trabalho definir uma dependência circular, o trabalho será rejeitado e o status do trabalho será definido como. CREATE_FAILED

O modelo de trabalho a seguir cria um trabalho com duas etapas. StepBdepende deStepA. StepBsó é executado após StepA ser concluído com sucesso.

Depois que o trabalho é criado, StepA está no READY estado e StepB está no PENDING estado. Depois de StepA terminar, StepB se muda para o READY estado. Se StepA falhar ou StepA for cancelado, StepB passa para o CANCELED estado.

Você pode definir uma dependência em várias etapas. Por exemplo, StepC depende de ambos StepA eStepB, StepC não começará até que as outras duas etapas terminem.

As dependências de etapas têm as seguintes restrições:

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!