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 i lavori in Deadline Cloud
Dopo aver creato un lavoro, AWS Deadline Cloud 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 di pianificazione controlla la distribuzione dei lavoratori tra i lavori.
Puoi impostare la configurazione della pianificazione utilizzando la console Deadline Cloud o chiamando le API [ CreateQueue ](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateQueue.html) or [ UpdateQueue](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_UpdateQueue.html).
Sono disponibili tre configurazioni di pianificazione:
+ **Priority, first-in-first-out ** (`priorityFifo`): pianifica la priorità più alta, il primo lavoro inviato per primo (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 in che modo i lavoratori sono distribuiti tra le diverse 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à, primo ad entrare, primo ad uscire
Priority, first-in-first-out (`priorityFifo`) è la configurazione di pianificazione predefinita per le nuove code. Deadline Cloud assegna per primi i lavoratori al 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 fasi sequenziali della pipeline o elaborazione in batch in cui ogni lavoro deve terminare prima dell'inizio di quello successivo.
Questa configurazione non ha parametri aggiuntivi.
### Priorità, bilanciata
Priorità, bilanciata (`priorityBalanced`) distribuisce i lavoratori in modo uniforme tra tutti i lavori al massimo livello di priorità. Quando esiste un solo lavoro con la massima priorità, Deadline Cloud assegna tutti i lavoratori a quel lavoro. Quando più lavori condividono la massima priorità, i lavoratori vengono suddivisi equamente tra loro. Se i lavoratori non possono essere divisi equamente, i lavoratori aggiuntivi vengono distribuiti tra i lavori con la massima priorità.
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 i lavoratori subito dopo l'invio.
Se un lavoro ha meno attività rimanenti rispetto alla sua quota di lavoratori, i lavoratori in eccesso 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 passano a posti di lavoro al successivo livello di priorità più alto.
Questa configurazione ha il seguente parametro:
`renderingTaskBuffer`
Controlla la viscosità del lavoratore. Un lavoratore passa dal lavoro corrente a un altro lavoro con la stessa priorità solo se la differenza nel rendering delle attività supera il `renderingTaskBuffer` valore. Un valore più elevato fa sì che i lavoratori continuino a svolgere le loro mansioni correnti più a lungo, riducendo il cambio di contesto. Il valore predefinito è `1`.
### Ponderato, bilanciato
Ponderato, bilanciato (`weightedBalanced`) utilizza una formula per calcolare un peso per ogni lavoro. Deadline Cloud assegna per primi i lavoratori al lavoro con il peso maggiore. Se più lavori hanno lo stesso peso, i lavoratori vengono distribuiti tra di essi.
Usa il bilanciamento ponderato quando hai bisogno di un controllo preciso sulla distribuzione dei lavoratori tra le mansioni con priorità, tassi di errore e tempi di invio variabili. Questa configurazione è appropriata per ambienti complessi di render farm in cui desideri regolare 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 al 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 primo piano. Inoltre, `errorWeight` è generalmente negativo, in modo che i lavori con errori non siano prioritari. È 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 eseguite per un lavoro. Un valore negativo indica che i lavori con meno lavoratori sono programmati successivamente. 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 le loro mansioni correnti. Il valore predefinito è `1`. Intervallo: `0` fino a`1000`.
`maxPriorityOverride`
Opzionale. Se impostato su`alwaysScheduleFirst`, i lavori con la massima priorità (100) vengono sempre programmati prima degli altri lavori, indipendentemente dalla formula ponderata. Quando più lavori hanno la massima priorità, i pareggi vengono interrotti utilizzando la formula ponderata standard. Quando l'eccezione è assente, i lavori con priorità massima utilizzano la formula ponderata standard senza alcun trattamento speciale.
`minPriorityOverride`
Opzionale. Se impostato su`alwaysScheduleLast`, i lavori con priorità minima (0) vengono sempre programmati dopo gli altri lavori, indipendentemente dalla formula ponderata. Quando più lavori hanno la priorità minima, i pareggi vengono interrotti utilizzando la formula ponderata standard. Quando l'eccezione è assente, i lavori con priorità minima utilizzano la formula ponderata standard senza alcun trattamento speciale.
## Determina la compatibilità della flotta
Le code e le flotte dividono il lavoro di routing dei lavori. Una coda organizza i lavori e controlla chi può inviarli e visualizzarli. I requisiti relativi alle flotte e agli host selezionano i lavoratori che eseguono ogni fase.
Per dedicare lavoratori specifici a determinati lavori, crea una flotta separata per quei lavoratori anziché una coda separata. Ad esempio, utilizza un parco macchine separato per macchine con hardware particolare o per macchine riservate a contenuti sensibili. Una coda può essere associata a più flotte e i requisiti host di ogni fase selezionano un parco macchine compatibile. Se arrivi da Deadline 10, i requisiti relativi alle flotte e agli host sostituiranno i gruppi di lavoratori. Per la mappatura concettuale completa, consulta. [Esegui la migrazione da Deadline 10 a AWS Deadline Cloud](migrate-from-deadline-10.md)
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 è impostato su. `NOT_COMPATIBLE` Inoltre, le altre fasi del lavoro vengono annullate. Se si associa un parco macchine compatibile alla coda in un secondo momento, i `NOT_COMPATIBLE` lavori esistenti non vengono riavviati automaticamente: per eseguirli, è necessario metterli in coda. Per ulteriori informazioni, consulta [Modifica un lavoro in Deadline Cloud](build-jobs-modifying.md).
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 compiti se la flotta non soddisfa i requisiti del lavoro.
**Importante**
La `workerCapabilities` dichiarazione a livello di flotta è il contratto di pianificazione. Lo scheduler valuta la compatibilità delle fasi esclusivamente rispetto alle funzionalità a livello di flotta: non ispeziona i singoli lavoratori. Se una fase `hostRequirements` supera i valori minimi dichiarati nella flotta`workerCapabilities`, la flotta viene valutata come non compatibile, anche se alcuni singoli lavoratori della flotta soddisferebbero i requisiti.
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
```
I mittenti impostano gli stessi requisiti tramite la scheda Requisiti dell'**host. ** Scegli ** Esegui su worker host che soddisfano i seguenti requisiti ** per impostare un sistema operativo, un'architettura della CPU e gli intervalli hardware senza modificare il modello.
Questo lavoro può essere programmato per un parco macchine 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 una 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 della flotta
Poiché lo scheduler valuta la compatibilità a livello di flotta, progettate le flotte gestite dal cliente in modo che quelle dichiarate `workerCapabilities` rappresentino le caratteristiche hardware minime garantite di ogni lavoratore della flotta:
+ Suddividi i lavoratori in più flotte in base alle caratteristiche hardware minime garantite (ad esempio, numero di GPU, VRAM o numero di CPU) anziché utilizzare una flotta eterogenea con ampi intervalli.
+ Assicurati che ogni lavoratore di una flotta soddisfi o superi i requisiti minimi dichiarati, anche se i lavoratori non dispongono di hardware identico.
+ Associa più flotte a un'unica coda in modo che lo scheduler selezioni una flotta compatibile in base a ciascuna fase. `hostRequirements`
Ad esempio, se hai lavoratori con 1 GPU (24 GiB di VRAM) e lavoratori con 4 GPU (96 GiB di VRAM), crea due flotte separate: una che dichiara almeno 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 associa entrambe le flotte alla stessa coda. I passaggi che richiedono 4 GPU vengono automaticamente indirizzati al parco macchine con un elevato numero di GPU.
Per ulteriori informazioni sulla creazione di una flotta gestita dal cliente, vedere. [Crea una flotta gestita dal cliente](create-a-cmf.md)
### Funzionalità personalizzate
Oltre alle funzionalità di lavoro integrate (vCPU, memoria, GPU, sistema operativo e architettura della CPU), è possibile definire quantità e attributi personalizzati su un parco macchine per esprimere ulteriori vincoli di pianificazione:
+ **Importi personalizzati**: valori numerici come spazio disponibile su disco o contatori hardware specializzati.
+ **Attributi personalizzati**: valori di stringa come software installato, versioni del risolutore o etichette del sito. Ad esempio, puoi definire `attr.sw.solvers` con valori come `["vray-6", "arnold-7"]` indirizzare i lavori che richiedono un software specifico.
A livello di parco macchine, dichiarate le combinazioni software o hardware nelle funzionalità personalizzate solo se è garantito che esistano per tutti i lavoratori della flotta.
Fleet-level le funzionalità personalizzate hanno i seguenti limiti:
+ Massimo 15 importi personalizzati per flotta
+ Massimo 15 attributi personalizzati per flotta
I nomi sono presenti nel modulo `amount.worker.*` e `attr.worker.*` sono riservati dal servizio per le funzionalità integrate. Usa altri prefissi per le tue funzionalità personalizzate.
L'esempio seguente indirizza i passaggi che richiedono un solutore specifico al parco macchine che lo fornisce. La flotta dichiara i solutori installati su tutti i suoi lavoratori in un attributo personalizzato. Questa configurazione del parco veicoli fa parte della richiesta: [CreateFleet](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateFleet.html)
```
"workerCapabilities": {
"vCpuCount": {"min": 4},
"memoryMiB": {"min": 16384},
"osFamily": "linux",
"cpuArchitectureType": "x86_64",
"customAttributes": [
{
"name": "attr.sw.solvers",
"values": ["vray-6", "arnold-7"]
}
]
}
```
Una fase che richiede uno dei valori dichiarati indica il requisito `hostRequirements` nel modello di lavoro:
```
steps:
- name: RenderWithVray
hostRequirements:
attributes:
- name: attr.sw.solvers
anyOf:
- vray-6
script:
actions:
onRun:
command: '{{Task.File.Render}}'
```
Il requisito mantiene l'`RenderWithVray`esclusione dalle flotte che non dichiarano`vray-6`. Non è vero il contrario: un provvedimento senza `attr.sw.solvers` prescrizioni è comunque compatibile con questa flotta e può essere programmato presso di essa.
**Nota**
Gli attributi personalizzati e i requisiti dell'host indirizzano il lavoro. Non sono un controllo di accesso. I requisiti per l'host vengono impostati nel modello di lavoro da chi invia il lavoro e un parco utenti che dichiara un attributo accetta comunque le fasi che non lo menzionano. Per riservare i lavoratori per contenuti sensibili, inseriscili nella propria flotta e associala solo alle code approvate. Per ulteriori informazioni, consultare [Controllo degli accessi e selezione dei lavoratori](#jobs-scheduling-access-control) e [Isola i carichi di lavoro con farm, flotte e code](farm-structure.md).
Per ulteriori informazioni sulla configurazione delle funzionalità personalizzate durante la creazione di una flotta, vedere. [Crea una flotta gestita dal cliente](create-a-cmf.md)
### 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 il worker agent segnala la memoria GPU.
L'agente worker di Deadline Cloud riporta la memoria * minima della * GPU su tutte le GPU del lavoratore, 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 in cui ogni GPU soddisfa tale requisito.
Ad esempio, se un lavoratore dispone di due GPU con rispettivamente 24 GiB e 48 GiB di VRAM, il worker agent riporta 24 GiB come valore di memoria della GPU.
A livello di parco macchine, impostate come `acceleratorTotalMemoryMiB` minimo la VRAM per GPU più bassa di cui è garantito il possesso per ogni lavoratore della flotta.
### Per-worker capacità
Quando è necessario tenere traccia dello stato operativo dei singoli lavoratori senza influire sulle decisioni di pianificazione, utilizzate le funzionalità per lavoratore. Ad esempio, potresti segnalare i lavoratori per la manutenzione, tenere traccia dello stato di implementazione del software o registrare gli indicatori di controllo dello stato di salute.
Puoi impostare le funzionalità per i singoli lavoratori utilizzando l'operazione `UpdateWorker` API. Per-worker le funzionalità * non vengono * utilizzate come contratto di pianificazione. Lo scheduler valuta la compatibilità esclusivamente rispetto alla dichiarazione a livello di flotta. `workerCapabilities`
Le `ListWorkers` operazioni `GetWorker` and non restituiscono le funzionalità dei lavoratori impostate. `UpdateWorker`
Per ulteriori informazioni, consulta [ UpdateWorker ](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_UpdateWorker.html) la sezione * Deadline Cloud API Reference*.
### Controllo degli accessi e selezione dei lavoratori
Deadline Cloud separa chi può utilizzare una risorsa da dove vengono eseguiti i lavori. Le policy IAM e le appartenenze di Centro identità AWS IAM utenti e gruppi controllano chi può visualizzare, inviare e gestire una farm, una coda o una flotta. Coda: le associazioni della flotta e i requisiti degli host controllano quali lavoratori eseguono ogni lavoro.
L'appartenenza a un gruppo su un parco veicoli consente alle persone di visualizzare e gestire il parco veicoli sul monitor. L'appartenenza non indirizza i lavori alla flotta né esclude i posti di lavoro da essa. Per indirizzare il lavoro verso o lontano da una flotta, utilizza le associazioni queue-fleet.
I requisiti relativi all'host fanno parte del modello di lavoro, quindi chi invia il lavoro li sceglie. Indirizzano il lavoro a flotte capaci e non costituiscono un sistema di controllo degli accessi. L'associazione tra code e flotte è il punto di applicazione: il servizio pianifica un passaggio solo per le flotte associate alla coda del lavoro, indipendentemente dai requisiti dell'host della fase. Per evitare che il lavoro non autorizzato sia riservato a una flotta soggetta a restrizioni, associa la flotta solo a code limitate e controlla chi può sottomettersi a tali code. Per ulteriori informazioni sui limiti di sicurezza tra le code e le flotte che condividono i lavoratori, consulta. [Isola i carichi di lavoro con farm, flotte e code](farm-structure.md)
## Scalabilità del parco veicoli
Quando un lavoro viene assegnato a una flotta compatibile con servizi gestiti, la flotta viene ridimensionata automaticamente. Il numero di lavoratori della flotta cambia in base al numero di attività disponibili per la flotta.
Quando un lavoro viene assegnato a una flotta gestita dal cliente, i lavoratori potrebbero già esistere o possono essere creati utilizzando il ridimensionamento automatico basato sugli 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 smontare l'ambiente. Ogni sessione è composta da una o più azioni che un lavoratore deve intraprendere.
Man mano che un lavoratore completa le azioni della sezione, è possibile inviargli ulteriori azioni della sessione. Il lavoratore riutilizza gli ambienti e gli allegati al lavoro esistenti nella sessione per completare le attività in modo più efficiente.
Nei fleet worker gestiti dal servizio, le directory delle sessioni vengono eliminate al termine della sessione, ma le altre directory vengono mantenute tra una sessione e l'altra. 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 in `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 e utilizzati come parte del pacchetto di lavoro CLI di Deadline Cloud. Puoi anche creare allegati di lavoro utilizzando l'opzione del comando. `--attachments` `create-job` AWS CLI Gli ambienti sono definiti in due posizioni: ambienti di coda collegati a una coda specifica e ambienti di lavoro e fasi definiti nel modello di processo.
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 scomporre l'ambiente delle fasi. Le sessioni create per questo processo 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 }}
```
### Pipelining delle azioni di sessione
La pipelining 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 analizza la durata dell'attività per determinare le assegnazioni future.
Affinché lo scheduler sia efficace, esistono regole sulla durata delle attività. Per le attività inferiori 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à che durano più di un minuto, lo scheduler assegna solo una nuova attività e il pipelining rimane disabilitato.
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 migliore 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 finirà tutto il lavoro assegnato in precedenza prima della fine della sessione corrente e verrà 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 una fase. Un passaggio con una dipendenza non viene pianificato fino al completamento di tutte le relative dipendenze.
Se il modello di job definisce una dipendenza circolare, il job viene rifiutato e lo stato del job è impostato su. `CREATE_FAILED`
Il seguente modello di lavoro crea un processo con due passaggi. `StepB`dipende da`StepA`. `StepB`viene eseguito solo dopo il `StepA` completamento con successo.
Dopo che il lavoro è stato creato, `StepA` è nello `READY` stato e `StepB` si trova nello `PENDING` stato. Dopo aver `StepA` terminato, `StepB` si trasferisce nello `READY` stato. Se `StepA` fallisce o `StepA` viene annullato, `StepB` passa allo `CANCELED` stato.
È possibile impostare una dipendenza su più passaggi. Ad esempio, se `StepC` dipende da entrambi `StepA` e`StepB`, `StepC` non verrà avviato fino al termine degli altri due passaggi.
Le dipendenze tra fasi presentano le seguenti restrizioni:
+ **Dipendenze per passaggio**: un passaggio può dipendere da un massimo di 128 altri passaggi.
+ **Consumatori per fase**: un massimo di 32 altre fasi possono dipendere da una singola fase.
```
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!
```