View a markdown version of this page

¿Qué es una carga de trabajo de Deadline Cloud? - Deadline Cloud
Cómo surgen las cargas de trabajo de la producciónLos ingredientes de una carga de trabajoPortabilidad de la carga de trabajo

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

¿Qué es una carga de trabajo de Deadline Cloud?

Con AWS Deadline Cloud, puede enviar trabajos para ejecutar sus aplicaciones en la nube y procesar datos para la producción de contenido o información importante para su empresa. Deadline Cloud utiliza Open Job Description (OpenJD) como sintaxis para las plantillas de trabajo, una especificación diseñada para las necesidades de los procesos de procesamiento visual, pero aplicable a muchos otros casos de uso. Algunos ejemplos de cargas de trabajo son el renderizado de gráficos por ordenador, la simulación física y la fotogrametría.

Las cargas de trabajo van desde simples paquetes de trabajos que los usuarios envían a una cola con la CLI o una GUI generada automáticamente, hasta complementos de envío integrados que generan dinámicamente un paquete de trabajos para una carga de trabajo definida por la aplicación.

Cómo surgen las cargas de trabajo de la producción

Para entender las cargas de trabajo en contextos de producción y cómo apoyarlas con Deadline Cloud, ten en cuenta cómo se originaron. La producción puede incluir la creación de efectos visuales, animaciones, juegos, imágenes de catálogos de productos, reconstrucciones en 3D para el modelado de información de construcción (BIM), etc. Por lo general, este contenido lo crea un equipo de especialistas artísticos o técnicos que ejecutan una variedad de aplicaciones de software y scripts personalizados. Los miembros del equipo se transmiten datos entre sí mediante un proceso de producción. Muchas de las tareas que realiza la canalización implican cálculos intensivos que llevarían días si se ejecutaran en la estación de trabajo de un usuario.

Algunos ejemplos de tareas en estas canalizaciones de producción incluyen:

  • Usar una aplicación de fotogrametría para procesar fotografías tomadas en un set de filmación con el fin de reconstruir una malla digital texturizada.

  • Realizar una simulación de partículas en una escena 3D para añadir capas de detalle a un efecto visual de explosión para un programa de televisión.

  • Preparar los datos de un nivel de juego en la forma necesaria para su publicación externa y aplicar los ajustes de optimización y compresión.

  • Representación de un conjunto de imágenes para un catálogo de productos, incluidas las variaciones de color, fondo e iluminación.

  • Ejecutar un guion desarrollado a medida en un modelo 3D para aplicar un aspecto personalizado y aprobado por un director de cine.

Estas tareas implican muchos parámetros que deben ajustarse para obtener un resultado artístico o para ajustar con precisión la calidad de salida. A menudo, hay una GUI para seleccionar esos valores de parámetros con un botón o menú para ejecutar el proceso localmente dentro de la aplicación. Cuando un usuario ejecuta el proceso, la aplicación y, posiblemente, el propio equipo host no se pueden usar para realizar otras operaciones porque utilizan el estado de la aplicación en la memoria y pueden consumir todos los recursos de CPU y memoria del equipo host.

En muchos casos, el proceso es rápido. Durante el transcurso de la producción, la velocidad del proceso se ralentiza cuando aumentan los requisitos de calidad y complejidad. Una prueba de personaje que haya durado 30 segundos durante el desarrollo puede convertirse fácilmente en 3 horas si se aplica al personaje final de producción. Con esta progresión, una carga de trabajo que comenzó dentro de una interfaz gráfica de usuario puede llegar a ser demasiado grande como para caber en ella. La migración a Deadline Cloud puede aumentar la productividad de los usuarios que ejecutan estos procesos, ya que recuperan el control total de su estación de trabajo y pueden realizar un seguimiento de más iteraciones desde el monitor de Deadline Cloud.

Al desarrollar el soporte para una carga de trabajo en Deadline Cloud, hay dos niveles de soporte:

  • Transferir la carga de trabajo de la estación de trabajo del usuario a una granja de Deadline Cloud sin paralelismo ni aceleración. Este enfoque puede infrautilizar los recursos informáticos disponibles en la granja, pero la capacidad de transferir las operaciones largas a un sistema de procesamiento por lotes permite a los usuarios hacer más con su propia estación de trabajo.

  • Optimizar el paralelismo de la carga de trabajo para que utilice la escala horizontal de la granja de Deadline Cloud para completar sus tareas con rapidez.

Hay ocasiones en las que resulta obvio cómo hacer que una carga de trabajo se ejecute en paralelo. Por ejemplo, cada fotograma de un renderizado de gráficos por ordenador se puede realizar de forma independiente. Sin embargo, es importante no quedarse atrapado en este paralelismo. Por el contrario, comprenda que transferir una carga de trabajo de larga duración a Deadline Cloud ofrece importantes beneficios, incluso cuando no existe una forma obvia de dividir la carga de trabajo.

Los ingredientes de una carga de trabajo

Para especificar una carga de trabajo de Deadline Cloud, implemente un paquete de trabajos que los usuarios envíen a una cola con la CLI de Deadline Cloud. Gran parte del trabajo que se necesita para crear un paquete de trabajos consiste en escribir la plantilla de trabajo, pero hay otros factores, como la forma de proporcionar las aplicaciones que requiere la carga de trabajo. Estos son los aspectos esenciales que hay que tener en cuenta al definir una carga de trabajo para Deadline Cloud:

  • La aplicación que se va a ejecutar. El trabajo debe poder iniciar los procesos de la aplicación y, por lo tanto, necesita una instalación de la aplicación disponible, así como cualquier licencia que utilice la aplicación, como el acceso a un servidor de licencias flotante. La instalación y la concesión de licencias suelen formar parte de la configuración de la granja y no están integradas en el propio paquete de trabajos.

  • Definiciones de parámetros de trabajo. La experiencia del usuario al enviar el trabajo se ve afectada en gran medida por los parámetros que proporciona. Entre los parámetros de ejemplo se incluyen los archivos de datos, los directorios y la configuración de la aplicación.

  • Flujo de datos de archivos. Cuando se ejecuta un trabajo, lee la entrada de los archivos proporcionados por el usuario y, a continuación, escribe la salida como archivos nuevos. Para trabajar con las funciones de asignación de rutas y adjuntos del trabajo, el trabajo debe especificar las rutas de los directorios o archivos específicos para estas entradas y salidas.

  • El guion de pasos. El script paso a paso ejecuta el binario de la aplicación con las opciones de línea de comandos correctas para aplicar los parámetros de trabajo proporcionados. También gestiona detalles como la asignación de rutas si los archivos de datos de la carga de trabajo incluyen referencias de rutas absolutas en lugar de relativas.

Portabilidad de la carga de trabajo

Una carga de trabajo es portátil cuando se puede ejecutar en varios sistemas diferentes sin cambiarla cada vez que se envía un trabajo. Por ejemplo, puede ejecutarse en diferentes granjas de renderizado que tengan montados diferentes sistemas de archivos compartidos, o en diferentes sistemas operativos, como Linux oWindows. Al implementar un paquete de trabajos portátil, es más fácil para los usuarios ejecutar el trabajo en su granja específica o adaptarlo para otros casos de uso.

Estas son algunas maneras en las que puede hacer que su paquete de trabajos sea portátil.

  • Especifique completamente los archivos de datos de entrada que necesita una carga de trabajo, utilizando los parámetros del PATH trabajo y las referencias de activos del paquete de trabajos. Este enfoque permite transferir el trabajo a las granjas basadas en sistemas de archivos compartidos y a las granjas que hacen copias de los datos de entrada, como la función de adjuntar trabajos de Deadline Cloud.

  • Haga que las referencias de ruta de los archivos de entrada de la tarea sean reubicables y utilizables en diferentes sistemas operativos. Por ejemplo, cuando los usuarios envían trabajos desde Windows estaciones de trabajo para ejecutarlos en una flota. Linux

    • Utilice referencias de rutas de archivo relativas, de modo que si el directorio que las contiene se mueve a una ubicación diferente, las referencias se seguirán resolviendo. Algunas aplicaciones, como Blender, permiten elegir entre rutas relativas y absolutas.

    • Si no puedes usar rutas relativas, admite los metadatos de mapeo de rutas de OpenJD https://github.com/OpenJobDescription/openjd-specifications/wiki/How-Jobs-Are-Run#path-mapping y traduce las rutas absolutas de acuerdo con la forma en que Deadline Cloud proporciona los archivos a la tarea.

  • Implementa comandos en una tarea mediante scripts portátiles. Python y bash son dos ejemplos de lenguajes de programación que se pueden usar de esta manera. Deberías considerar la posibilidad de proporcionarlos a todos los anfitriones de trabajadores de tus flotas.

    • Utilice el binario del intérprete de guiones, como python obash, con el nombre del archivo del script como argumento. Este enfoque funciona en todos los sistemas operativosWindows, incluso en comparación con el uso de un archivo de script con el bit de ejecución activadoLinux.

    • Escriba scripts bash portátiles aplicando estas prácticas:

      • Amplíe los parámetros de ruta de la plantilla entre comillas simples para tratar las rutas con espacios y separadores de Windows rutas.

      • Cuando se ejecuteWindows, esté atento a los problemas relacionados con la traducción automática de rutas de MinGW. Por ejemplo, transforma un AWS CLI comando similar aws logs tail /aws/deadline/... en un comando similar a aws logs tail "C:/Program Files/Git/aws/deadline/..." un registro que no va al final de un registro correctamente. Defina la variable MSYS_NO_PATHCONV=1 para desactivar este comportamiento.

      • En la mayoría de los casos, el mismo código funciona en todos los sistemas operativos. Cuando el código deba ser diferente, utilice una if/else construcción para gestionar los casos. 

        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

    • Puede escribir scripts de Python portátiles pathlib para gestionar las diferencias de rutas del sistema de archivos y evitar funciones específicas de la operación. La documentación de Python incluye anotaciones para ello, por ejemplo, en la documentación de la biblioteca de señales. Linux-el soporte de funciones específicas está marcado como «Disponibilidad: Linux».

  • Utilice los parámetros del trabajo para especificar los requisitos de la aplicación. Utilice convenciones coherentes que el administrador de la granja pueda aplicar en los entornos de cola.

    • Por ejemplo, puede usar los CondaPackages and/or RezPackages parámetros de su trabajo con un valor de parámetro predeterminado que muestre los nombres de los paquetes de aplicaciones y las versiones que requiere el trabajo. A continuación, puede usar uno de los entornos de cola conda o Rez de ejemplo para proporcionar un entorno virtual para el trabajo.