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à.
Cos'è un carico di lavoro Deadline Cloud
Con AWS Deadline Cloud, puoi inviare lavori per eseguire le tue applicazioni nel cloud ed elaborare i dati per la produzione di contenuti o approfondimenti importanti per la tua azienda. Deadline Cloud utilizza Open Job Description
I carichi di lavoro vanno da semplici pacchetti di lavoro che gli utenti inviano a una coda con la CLI o una GUI generata automaticamente, a plug-in di invio integrati che generano dinamicamente un pacchetto di lavori per un carico di lavoro definito dall'applicazione.
In che modo i carichi di lavoro derivano dalla produzione
Per comprendere i carichi di lavoro nei contesti di produzione e come supportarli con Deadline Cloud, considera come si presentano. La produzione può comportare la creazione di effetti visivi, animazioni, giochi, immagini del catalogo di prodotti, ricostruzioni 3D per il Building Information Modeling (BIM) e altro ancora. Questo contenuto viene in genere creato da un team di specialisti artistici o tecnici che eseguono una varietà di applicazioni software e script personalizzati. I membri del team si scambiano i dati utilizzando una pipeline di produzione. Molte attività eseguite dalla pipeline comportano calcoli intensivi che richiederebbero giorni se eseguiti sulla workstation di un utente.
Alcuni esempi di attività in queste pipeline di produzione includono:
-
Utilizzo di un'applicazione di fotogrammetria per elaborare fotografie scattate da un set cinematografico per ricostruire una mesh digitale strutturata.
-
Esecuzione di una simulazione di particelle in una scena 3D per aggiungere livelli di dettaglio all'effetto visivo di un'esplosione per un programma televisivo.
-
Elaborazione dei dati per un livello di gioco nella forma necessaria per il rilascio esterno e applicazione delle impostazioni di ottimizzazione e compressione.
-
Rendering di una serie di immagini per un catalogo di prodotti, comprese le variazioni di colore, sfondo e illuminazione.
-
Esecuzione di uno script sviluppato su misura su un modello 3D per applicare un look creato su misura e approvato da un regista cinematografico.
Queste attività comportano la regolazione di molti parametri per ottenere un risultato artistico o per ottimizzare la qualità dell'output. Spesso è disponibile una GUI per selezionare i valori dei parametri con un pulsante o un menu per eseguire il processo localmente all'interno dell'applicazione. Quando un utente esegue il processo, l'applicazione ed eventualmente il computer host stesso non possono essere utilizzati per eseguire altre operazioni perché utilizza lo stato dell'applicazione in memoria e potrebbe consumare tutte le risorse di CPU e memoria del computer host.
In molti casi il processo è rapido. Nel corso della produzione, la velocità del processo rallenta quando aumentano i requisiti di qualità e complessità. Un test del personaggio che ha richiesto 30 secondi durante lo sviluppo può facilmente trasformarsi in 3 ore quando viene applicato al personaggio di produzione finale. Grazie a questa progressione, un carico di lavoro iniziato all'interno di una GUI può diventare troppo grande per essere contenuto. Il porting su Deadline Cloud può aumentare la produttività degli utenti che eseguono questi processi perché riprendono il pieno controllo della propria workstation e possono tenere traccia di più iterazioni dal monitor Deadline Cloud.
Ci sono due livelli di supporto a cui puntare quando si sviluppa il supporto per un carico di lavoro in Deadline Cloud:
-
Trasferimento del carico di lavoro dalla workstation dell'utente a una farm Deadline Cloud senza parallelismi o accelerazioni. Questo approccio potrebbe sottoutilizzare le risorse di calcolo disponibili nella farm, ma la possibilità di trasferire lunghe operazioni su un sistema di elaborazione batch consente agli utenti di fare di più con la propria workstation.
-
Ottimizzazione del parallelismo del carico di lavoro in modo che utilizzi la scala orizzontale della farm Deadline Cloud per completare rapidamente il processo.
A volte è ovvio come far funzionare un carico di lavoro in parallelo. Ad esempio, ogni fotogramma di un rendering di grafica computerizzata può essere eseguito indipendentemente. Tuttavia, è importante non rimanere bloccati su questo parallelismo. Tieni invece presente che l'offload di un carico di lavoro di lunga durata su Deadline Cloud offre vantaggi significativi, anche quando non esiste un modo ovvio per suddividere il carico di lavoro.
Gli ingredienti di un carico di lavoro
Per specificare un carico di lavoro di Deadline Cloud, implementa un job bundle che gli utenti inviano a una coda con la CLI di Deadline Cloud. https://github.com/aws-deadline/deadline-cloud
-
L'applicazione da eseguire. Il processo deve essere in grado di avviare i processi applicativi e richiede pertanto l'installazione dell'applicazione disponibile e le eventuali licenze utilizzate dall'applicazione, ad esempio l'accesso a un server di licenze mobili. L'installazione e la gestione delle licenze fanno in genere parte della configurazione della farm e non sono incorporate nel job bundle stesso.
-
Definizioni dei parametri di lavoro. L'esperienza utente durante l'invio del lavoro è fortemente influenzata dai parametri forniti. I parametri di esempio includono file di dati, directory e configurazione dell'applicazione.
-
Flusso di dati dei file. Quando un processo viene eseguito, legge l'input dai file forniti dall'utente, quindi ne scrive l'output come nuovi file. Per utilizzare gli allegati del lavoro e le funzionalità di mappatura dei percorsi, il lavoro deve specificare i percorsi delle directory o dei file specifici per questi input e output.
-
Lo script degli step. Lo script step esegue il binario dell'applicazione con le giuste opzioni della riga di comando per applicare i parametri di lavoro forniti. Gestisce inoltre dettagli come la mappatura del percorso se i file di dati del carico di lavoro includono riferimenti di percorso assoluti anziché relativi.
Portabilità del carico di lavoro
Un carico di lavoro è portabile quando può essere eseguito su più sistemi diversi senza modificarlo ogni volta che si invia un lavoro. Ad esempio, potrebbe essere eseguito su diverse render farm su cui sono montati diversi file system condivisi o su sistemi operativi diversi come Linux oWindows. Quando si implementa un pacchetto di lavoro portatile, è più facile per gli utenti eseguire il lavoro nella propria farm specifica o adattarlo ad altri casi d'uso.
Ecco alcuni modi per rendere portatile il Job Bundle.
-
Specificate in modo completo i file di dati di input necessari per un carico di lavoro, utilizzando i parametri del
PATHjob e i riferimenti alle risorse nel job bundle. Questo approccio rende il lavoro trasferibile alle farm basate su file system condivisi e alle farm che creano copie dei dati di input, come la funzione Deadline Cloud Job Allegments. -
Rendi i riferimenti al percorso dei file di input del lavoro trasferibili e utilizzabili su diversi sistemi operativi. Ad esempio, quando gli utenti inviano lavori dalle Windows postazioni di lavoro per eseguirli su una flotta. Linux
-
Utilizzate i riferimenti relativi al percorso dei file, in modo che se la directory che li contiene viene spostata in una posizione diversa, i riferimenti vengono comunque risolti. Alcune applicazioni, come Blender
, supportano la scelta tra percorsi relativi e assoluti. -
Se non puoi usare percorsi relativi, supporta i metadati di mappatura dei percorsi di OpenJD
e traduci i percorsi assoluti in base a come Deadline Cloud fornisce i file al lavoro.
-
-
Implementa i comandi in un lavoro utilizzando script portatili. Python e bash sono due esempi di linguaggi di scripting che possono essere usati in questo modo. Dovresti considerare di fornirli entrambi su tutti i lavoratori ospitanti delle tue flotte.
-
Utilizzate il binario dell'interprete di script, come
pythonobash, con il nome del file di script come argomento. Questo approccio funziona su tutti i sistemi operativiWindows, incluso, rispetto all'utilizzo di un file di script con il bit di esecuzione impostato. Linux -
Scrivi script bash portatili applicando queste pratiche:
-
Espandi i parametri del percorso del modello tra virgolette singole per gestire i percorsi con spazi e separatori di Windows percorso.
-
Quando è in esecuzioneWindows, presta attenzione ai problemi relativi alla traduzione automatica del percorso MinGW. Ad esempio, trasforma un AWS CLI comando like
aws logs tail /aws/deadline/...in un comando simile aaws logs tail "C:/Program Files/Git/aws/deadline/..."e non esegue correttamente la coda di un registro. Imposta la variabileMSYS_NO_PATHCONV=1per disattivare questo comportamento. -
Nella maggior parte dei casi, lo stesso codice funziona su tutti i sistemi operativi. Quando il codice deve essere diverso, usa un
if/elsecostrutto per gestire i casi.if [[ "$(uname)" == MINGW* || "$(uname -s)" == MSYS_NT* ]]; then : # Code for Windows elif [[ "$(uname)" == Darwin ]]; then : # Code for MacOS else : # Code for Linux and other operating systems fi
-
-
È possibile scrivere script Python portatili utilizzando
pathlibper gestire le differenze di percorso del file system ed evitare funzionalità operative specifiche. La documentazione di Python include annotazioni a tal fine, ad esempio nella documentazione della libreria Signal. https://docs.python.org/3/library/signal.htmlLinux-il supporto di funzionalità specifiche è contrassegnato come «Disponibilità: Linux».
-
-
Utilizzate i parametri del job per specificare i requisiti dell'applicazione. Utilizzate convenzioni coerenti che l'amministratore della farm può applicare negli ambienti di coda.
-
Ad esempio, è possibile utilizzare
CondaPackagesand/orRezPackagesi parametri nel processo, con un valore di parametro predefinito che elenca i nomi e le versioni dei pacchetti applicativi richiesti dal processo. Quindi, puoi utilizzare uno degli ambienti di coda conda o Rez di esempioper fornire un ambiente virtuale per il lavoro.
-