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 o. [CreateQueue[UpdateQueue](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_UpdateQueue.html)](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateQueue.html) APIs Sono disponibili tre configurazioni di pianificazione: + **Priority, first-in-first-out** (`priorityFifo`): pianifica per primo il lavoro inviato per primo e con la priorità più alta (impostazione predefinita). + **Priorità, bilanciata** (`priorityBalanced`): distribuisce i lavoratori in modo uniforme tra le mansioni con la massima priorità. + **Ponderato, bilanciato** (`weightedBalanced`): utilizza una formula ponderata per determinare la distribuzione dei lavoratori tra le mansioni. 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à, first-in-first-out 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: `renderingTaskBuffer` Controlla la viscosità dell'operatore. Un lavoratore passa dal lavoro corrente a un altro lavoro con la stessa priorità solo se la differenza nella resa delle attività supera il valore. `renderingTaskBuffer` Un valore più elevato consente ai lavoratori di continuare a lavorare più a lungo, riducendo il cambio di contesto. Il valore predefinito è `1`. ### 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 persistenza 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: `priorityWeight` Il peso applicato alla priorità di un lavoro. Un valore positivo indica che i lavori con priorità più alta vengono pianificati per primi. Il valore predefinito è `100.0`. Intervallo: `0` fino a. `10000` `errorWeight` Il peso applicato al conteggio degli errori di un lavoro. Un valore negativo indica che i lavori senza errori vengono pianificati per primi. Il valore predefinito è `-10.0`. Intervallo: `-10000` fino a`10000`. `submissionTimeWeight` Il peso applicato al tempo di invio di un lavoro (in secondi). Un valore positivo indica che i lavori inviati in precedenza vengono programmati per primi. Il valore predefinito è `3.0`. Intervallo: `0` fino a`10000`. `renderingTaskWeight` Il peso applicato al numero di attività attualmente renderizzate per un lavoro. Un valore negativo indica che i prossimi lavori con meno lavoratori sono programmati. Il valore predefinito è `-100.0`. Intervallo: `-10000` fino a`10000`. `renderingTaskBuffer` Il numero di attività di rendering prima che il peso dell'attività di rendering abbia effetto. Un valore positivo consente ai lavoratori di continuare a svolgere il loro lavoro attuale. Il valore predefinito è `1`. Intervallo: `0` fino a`1000`. `maxPriorityOverride` Opzionale. Se impostato su`alwaysScheduleFirst`, i lavori con la priorità massima (100) vengono sempre programmati prima degli altri lavori, indipendentemente dalla formula ponderata. Quando più lavori hanno la massima priorità, i pareggi vengono risolti utilizzando la formula ponderata standard. Quando l'override è assente, i lavori con priorità massima utilizzano la formula ponderata standard senza alcun trattamento speciale. `minPriorityOverride` Opzionale. Se impostato su`alwaysScheduleLast`, i lavori con la priorità minima (0) vengono sempre programmati dopo gli altri lavori, indipendentemente dalla formula ponderata. Quando più lavori hanno la priorità minima, i pareggi vengono risolti utilizzando la formula ponderata standard. Quando l'esclusione è assente, i lavori con priorità minima utilizzano la formula ponderata standard senza alcun trattamento speciale. ## 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 presenta 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. ``` ## Ridimensionamento 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](https://docs.aws.amazon.com/autoscaling/ec2/userguide/automating-ec2-auto-scaling-with-eventbridge.html) 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 dei lavori 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: + `syncInputJobAttachments`— Scarica gli allegati del lavoro di input per il lavoratore. + `envEnter`— Esegue le `onEnter` azioni per un ambiente. + `taskRun`— Esegue le `onRun` azioni relative a un'attività. + `envExit`— Esegue le `onExit` azioni per un ambiente. 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'`envEnter`azione, una o più `taskRun` azioni e quindi un'`envExit`azione. ``` 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: + Utilizza la durata media delle attività completate + Mira a mantenere il lavoratore occupato per un minuto + Considera solo le attività all'interno della stessa sessione + Non condivide i dati sulla durata tra i lavoratori 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. `StepB`dipende da`StepA`. `StepB`viene 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` e`StepB`, `StepC` non inizierà fino al termine degli altri due passaggi. Le dipendenze dei passaggi hanno le seguenti restrizioni: + **Dipendenze per fase**: una fase può dipendere da un massimo di 128 altre fasi. + **Consumatori per fase**: un massimo di altri 32 passaggi possono dipendere da un singolo passaggio. ``` 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! ```