Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Pianifica lavori in Deadline Cloud

Dopo aver creato un lavoro, AWS Deadline Cloud ne pianifica l'elaborazione su una o più flotte associate a una coda. La flotta che elabora una particolare attività viene scelta in base alla configurazione di pianificazione, alle funzionalità configurate per la flotta e ai requisiti dell'host di una fase specifica.

Le sezioni seguenti forniscono dettagli sul processo di pianificazione di un lavoro.

Configurazioni di pianificazione

Puoi configurare il modo in cui Deadline Cloud pianifica i lavori in una coda impostando una configurazione di pianificazione sulla coda. La configurazione della pianificazione controlla il modo in cui i lavoratori vengono distribuiti tra i lavori.

Puoi impostare la configurazione di pianificazione utilizzando la console Deadline Cloud o chiamando le CreateQueueAPI o. UpdateQueue

Sono disponibili tre configurazioni di pianificazione:

In tutte le configurazioni di pianificazione, le attività in corso vengono completate prima che venga presa una nuova decisione di pianificazione. Se si modifica la configurazione di pianificazione mentre le attività sono in esecuzione, la modifica si applica solo alla successiva assegnazione dei lavoratori. Le attività in esecuzione non vengono interrotte o riassegnate.

Priorità, primo a entrare, primo a uscire

Priority, first-in-first-out (priorityFifo) è la configurazione di pianificazione predefinita per le nuove code. Deadline Cloud assegna innanzitutto ai lavoratori il lavoro con la massima priorità. Quando più lavori condividono la stessa priorità, il lavoro più vecchio (inviato per primo) riceve per primo tutti i lavoratori disponibili.

Usa la priorità FIFO quando desideri un ordine rigoroso dei lavori. Questa configurazione è appropriata quando i lavori devono essere completati uno alla volta nell'ordine in cui sono stati inviati, ad esempio nelle fasi sequenziali della pipeline o nell'elaborazione in batch in cui ogni lavoro deve terminare prima dell'inizio di quello successivo.

Questa configurazione non ha parametri aggiuntivi.

Priorità, equilibrata

Priority, balanced (priorityBalanced) distribuisce i lavoratori in modo uniforme tra tutti i posti di lavoro al livello di priorità più elevato. Quando esiste un solo lavoro con la massima priorità, Deadline Cloud assegna a tutti i lavoratori quel lavoro. Quando più lavori condividono la massima priorità, i lavoratori vengono suddivisi equamente tra loro. Se i lavoratori non possono essere suddivisi equamente, i lavoratori aggiuntivi vengono distribuiti tra i lavori con la priorità più alta.

Usa la priorità bilanciata quando più artisti o utenti inviano lavori con la stessa priorità e ogni utente ha bisogno di un feedback immediato. Questa configurazione garantisce che nessun lavoro monopolizzi tutti i lavoratori disponibili, in modo che a tutti gli utenti vengano assegnati lavoratori subito dopo l'invio.

Se un posto di lavoro ha meno mansioni rimanenti rispetto alla quota di lavoratori, i lavoratori in eccedenza vengono ridistribuiti ad altri lavori con lo stesso livello di priorità. Se tutti i posti di lavoro con la massima priorità sono interamente assegnati, i lavoratori in eccedenza vengono assegnati a cascata ai posti di lavoro con il livello di priorità successivo più elevato.

Questa configurazione ha il seguente parametro:

Ponderato, equilibrato

Weighted, balanced (weightedBalanced) utilizza una formula per calcolare un peso per ogni lavoro. Deadline Cloud assegna innanzitutto ai lavoratori il lavoro con il peso maggiore. Se più lavori hanno lo stesso peso, i lavoratori vengono distribuiti tra di essi.

Usa la bilancia ponderata quando hai bisogno di un controllo preciso sulla distribuzione dei lavoratori tra le mansioni con priorità, tassi di errore e tempi di invio diversi. Questa configurazione è appropriata per ambienti di render farm complessi in cui si desidera ottimizzare l'equilibrio tra priorità del lavoro, età del lavoro, gestione degli errori e fidelizzazione dei lavoratori.

Il peso per ogni lavoro viene calcolato come segue:

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

Il renderingTaskBuffer componente viene applicato solo se il lavoratore sta attualmente lavorando sul posto di lavoro. Di solito renderingTaskWeight è impostato su un valore negativo in modo che i lavori con lavoratori assegnati ricevano un peso inferiore, portando gli altri lavori in prima fila. Inoltre, di solito errorWeight è negativo, quindi i lavori con errori vengono ridotti in ordine di priorità. È possibile utilizzare le sostituzioni di pianificazione per i lavori con priorità minima e massima.

Questa configurazione ha i seguenti parametri:

Determina la compatibilità della flotta

Dopo aver creato un lavoro, Deadline Cloud verifica i requisiti dell'host per ogni fase del lavoro rispetto alle capacità delle flotte associate alla coda a cui è stato inviato il lavoro. Se una flotta soddisfa i requisiti dell'host, il lavoro viene assegnato allo stato. READY

Se una fase del lavoro presenta requisiti che non possono essere soddisfatti da una flotta associata alla coda, lo stato della fase viene impostato NOT_COMPATIBLE su. Inoltre, gli altri passaggi del processo vengono annullati.

Le capacità di una flotta sono impostate a livello di flotta. Anche se un lavoratore di una flotta soddisfa i requisiti del lavoro, non gli verranno assegnati i compiti previsti dal lavoro se la flotta non soddisfa i requisiti del lavoro.

Il seguente modello di lavoro contiene una fase che specifica i requisiti dell'host per la fase:

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

Questo lavoro può essere programmato per una flotta con le seguenti funzionalità:

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

Questo lavoro non può essere programmato per una flotta con nessuna delle seguenti funzionalità:

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

Best practice per la progettazione del parco veicoli

Poiché lo scheduler valuta la compatibilità a livello di flotta, progettate le flotte gestite dai clienti in modo che quelle dichiarate workerCapabilities rappresentino le caratteristiche hardware minime garantite di ogni lavoratore della flotta:

Ad esempio, se hai worker con 1 GPU (24 GiB VRAM) e worker con 4 GPU (96 GiB VRAM), crea due flotte separate: una che dichiara un minimo di 1 GPU e 24 GiB di memoria GPU e un'altra che dichiara un minimo di 4 GPU e 96 GiB di memoria GPU. Quindi associate entrambe le flotte alla stessa coda. I passaggi che richiedono 4 GPU vengono indirizzati automaticamente al parco di GPU elevate.

Per ulteriori informazioni sulla creazione di una flotta gestita dal cliente, consulta. Crea una flotta gestita dai clienti

Funzionalità personalizzate

Oltre alle funzionalità di lavoro integrate (vCPU, memoria, GPU, sistema operativo e architettura CPU), puoi definire importi e attributi personalizzati su una flotta per esprimere vincoli di pianificazione aggiuntivi:

A livello di flotta, dichiarate le combinazioni software o hardware con funzionalità personalizzate solo se è garantito che esistano su tutti i lavoratori di quella flotta.

Fleet-level le funzionalità personalizzate hanno i seguenti limiti:

I nomi sono nel modulo amount.worker.* e attr.worker.* sono riservati dal servizio per le funzionalità integrate. Usa altri prefissi per le tue funzionalità personalizzate.

Per ulteriori informazioni sulla configurazione delle funzionalità personalizzate durante la creazione di un parco veicoli, consulta. Crea una flotta gestita dai clienti

Rapporti sulla memoria GPU

Quando configuri flotte per GPU-intensive carichi di lavoro che richiedono una soglia VRAM specifica per GPU, scopri in che modo l'agente di lavoro segnala la memoria GPU.

Il worker agent di Deadline Cloud riporta la memoria GPU minima per tutte le GPU del worker, non la somma totale. amount.worker.gpu.memory Questo comportamento garantisce che i lavori che richiedono una quantità specifica di VRAM per GPU vengano indirizzati ai lavoratori laddove ogni GPU soddisfi tale requisito.

Ad esempio, se un worker ha due GPU con rispettivamente 24 GiB e 48 GiB di VRAM, l'agente di lavoro riporta 24 GiB come valore di memoria della GPU.

A livello di flotta, imposta come acceleratorTotalMemoryMiB valore minimo la VRAM per GPU più bassa che ogni lavoratore del parco macchine abbia la garanzia di avere.

Per-worker capacità

Quando è necessario monitorare lo stato operativo dei singoli lavoratori senza influire sulle decisioni di pianificazione, utilizza le funzionalità per singolo lavoratore. Ad esempio, è possibile contrassegnare i lavoratori per la manutenzione, tenere traccia dello stato di implementazione del software o registrare gli indicatori di controllo dello stato di salute.

È possibile impostare le funzionalità dei singoli lavoratori utilizzando l'operazione UpdateWorker API. Per-worker le funzionalità non vengono utilizzate come contratto di pianificazione. Lo scheduler valuta la compatibilità esclusivamente in base alla dichiarazione a livello di flotta. workerCapabilities

Le ListWorkers operazioni GetWorker e non restituiscono le funzionalità del lavoratore impostate. UpdateWorker

Per ulteriori informazioni, consulta UpdateWorkerDeadline Cloud API Reference.

Scalabilità della flotta

Quando un lavoro viene assegnato a una flotta compatibile gestita dai servizi, la flotta viene ridimensionata automaticamente. Il numero di lavoratori della flotta cambia in base al numero di attività disponibili per l'esecuzione della flotta.

Quando un lavoro viene assegnato a una flotta gestita dal cliente, è possibile che i lavoratori esistano già o possano essere creati utilizzando la scalabilità automatica basata su eventi. Per ulteriori informazioni, consulta Use EventBridge to handle auto scaling events nella Amazon EC2 Auto Scaling User Guide.

Sessioni

Le attività di un job sono suddivise in una o più sessioni. I lavoratori eseguono le sessioni per configurare l'ambiente, eseguire le attività e quindi demolire l'ambiente. Ogni sessione è composta da una o più azioni che un lavoratore deve intraprendere.

Quando un lavoratore completa le azioni della sezione, al lavoratore possono essere inviate azioni di sessione aggiuntive. Il lavoratore riutilizza gli ambienti e gli allegati di lavoro esistenti nella sessione per completare le attività in modo più efficiente.

Sui lavoratori della flotta gestiti dal servizio, le directory delle sessioni vengono eliminate al termine della sessione, ma le altre directory vengono conservate tra le sessioni. Questo comportamento consente di implementare strategie di memorizzazione nella cache per i dati che possono essere riutilizzati in più sessioni. Per memorizzare nella cache i dati tra le sessioni, memorizzali nella home directory dell'utente che esegue il processo. Ad esempio, i pacchetti conda vengono memorizzati nella cache nella home directory dell'utente del lavoro all'indirizzo C:\Users\job-user\.conda-pkgs on Windows workers e /home/job-user/.conda-pkgs on Linux workers. Questi dati rimangono disponibili fino alla chiusura del lavoratore.

Gli allegati di lavoro vengono creati dal mittente che utilizzi come parte del pacchetto di lavori CLI di Deadline Cloud. Puoi anche creare allegati di lavoro utilizzando l'opzione relativa al comando. --attachments create-job AWS CLI Gli ambienti sono definiti in due punti: ambienti di coda collegati a una coda specifica e ambienti di lavoro e fasi definiti nel modello di lavoro.

Esistono quattro tipi di azioni di sessione:

Il seguente modello di lavoro ha un ambiente a fasi. Ha una onEnter definizione per configurare l'ambiente delle fasi, una onRun definizione che definisce l'attività da eseguire e una onExit definizione per eliminare l'ambiente delle fasi. Le sessioni create per questo lavoro includeranno un'envEnterazione, una o più taskRun azioni e quindi un'envExitazione.

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

Pipeline delle azioni della sessione

La pipeline delle azioni di sessione consente a uno scheduler di preassegnare più azioni di sessione a un lavoratore. Il lavoratore può quindi eseguire queste azioni in sequenza, riducendo o eliminando i tempi di inattività tra le attività.

Per creare un'assegnazione iniziale, lo scheduler crea una sessione con un'attività, il lavoratore completa l'attività e quindi lo scheduler analizza la durata dell'attività per determinare le assegnazioni future.

Affinché lo scheduler sia efficace, esistono delle regole sulla durata delle attività. Per le attività di durata inferiore a un minuto, lo scheduler utilizza un modello di crescita power-of-2. Ad esempio, per un'attività di 1 secondo, lo scheduler assegna 2 nuove attività, quindi 4, quindi 8. Per le attività di durata superiore a un minuto, lo scheduler assegna solo una nuova attività e la pipelining rimane disabilitata.

Per calcolare le dimensioni della pipeline, lo scheduler esegue le seguenti operazioni:

Grazie alla pipeline delle azioni di sessione, i lavoratori iniziano immediatamente nuove attività e non ci sono tempi di attesa tra le richieste dello scheduler. Fornisce inoltre una maggiore efficienza dei lavoratori e una migliore distribuzione delle attività per i processi a lunga durata.

Inoltre, se è disponibile un nuovo lavoro con priorità più alta, il lavoratore terminerà tutto il lavoro precedentemente assegnato prima della fine della sessione corrente e prima che venga assegnata una nuova sessione da un lavoro con priorità più alta.

Dipendenze tra fasi

Deadline Cloud supporta la definizione delle dipendenze tra i passaggi in modo che un passaggio attenda il completamento di un altro passaggio prima di iniziare. Puoi definire più di una dipendenza per un passaggio. Un passaggio con una dipendenza non è pianificato fino al completamento di tutte le relative dipendenze.

Se il modello di lavoro definisce una dipendenza circolare, il lavoro viene rifiutato e lo stato del processo viene impostato su. CREATE_FAILED

Il seguente modello di lavoro crea un lavoro con due passaggi. StepBdipende daStepA. StepBviene eseguito solo dopo essere stato StepA completato con successo.

Dopo la creazione del lavoro, StepA si trova nello READY stato e StepB si trova nello PENDING stato. Al StepA termine, StepB passa allo READY stato. Se StepA fallisce o se StepA viene annullato, StepB passa allo CANCELED stato.

È possibile impostare una dipendenza su più passaggi. Ad esempio, StepC dipende da entrambi StepA eStepB, StepC non inizierà fino al termine degli altri due passaggi.

Le dipendenze dei passaggi hanno le seguenti restrizioni:

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!