En este documento se explica cómo ampliar tu sistema de renderizado on-premise para usar recursos de computación en Google Cloud. En este documento se da por hecho que ya has implementado una granja de renderizado local y que conoces los conceptos básicos de los efectos visuales y los procesos de animación, el software de gestión de colas y los métodos de licencia de software habituales.
Información general
Renderizar elementos en 2D o 3D para animaciones, películas, anuncios o videojuegos requiere mucho tiempo y capacidad de computación. Para renderizar estos elementos, se requiere una inversión considerable en hardware e infraestructura, así como un equipo especializado de profesionales de TI para desplegar y mantener el hardware y el software.
Cuando una granja de renderización local alcanza el 100 % de utilización, gestionar los trabajos puede convertirse en un problema. Las prioridades y dependencias de las tareas, el reinicio de los fotogramas perdidos y la carga de la red, el disco y la CPU forman parte de la compleja ecuación que debes monitorizar y controlar de cerca, a menudo con plazos ajustados.
Para gestionar estos trabajos, las empresas de efectos visuales han incorporado software de gestión de colas en sus procesos. El software de gestión de colas puede hacer lo siguiente:
- Despliega trabajos en recursos locales y basados en la nube.
- Gestionar las dependencias entre tareas.
- Comunícate con los sistemas de gestión de recursos.
- Proporcionar a los usuarios una interfaz de usuario y APIs para lenguajes comunes, como Python.
Aunque algunos softwares de gestión de colas pueden desplegar trabajos en trabajadores basados en la nube, sigues siendo responsable de conectarte a la nube, sincronizar recursos, elegir un marco de almacenamiento, gestionar plantillas de imágenes y proporcionar tus propias licencias de software.
Puede usar las siguientes opciones para crear y gestionar canalizaciones de renderizado y flujos de trabajo en un entorno de nube o de nube híbrida:
- Si aún no tienes recursos locales o en la nube, puedes usar un servicio de renderización basado en la nube de software como servicio (SaaS), como Conductor.
- Si quieres gestionar tu propia infraestructura, puedes crear e implementar los recursos en la nube que se describen en este documento.
- Si quieres crear un flujo de trabajo personalizado en función de tus requisitos específicos, puedes colaborar con partners integradores de servicios como Gunpowder o Qodea. Google Cloud Esta opción tiene la ventaja de ejecutar todos los servicios en la nube en tu propio entorno seguro. Google Cloud
Para determinar cuál es la solución ideal para tu centro, ponte en contacto con tuGoogle Cloud representante.
Nota: Las notas de producción aparecen periódicamente a lo largo de este documento. En estas notas se ofrecen prácticas recomendadas que puedes seguir para crear tu granja de renderizado.
Conectarse a la nube
En función de tu carga de trabajo, decide cómo se conectará tu centro aGoogle Cloud, ya sea a través de un proveedor de Internet asociado, una conexión directa o la red de Internet pública.
Conexión a través de Internet
Sin necesidad de una conectividad especial, puedes conectarte a la red de Google y usar nuestro modelo de seguridad integral accediendo a los Google Cloud servicios a través de Internet. Las utilidades, como la CLI de Google Cloud, y los recursos, como la API de Compute Engine, usan autenticación, autorización y cifrado seguros para proteger tus datos.
Cloud VPN
Independientemente de cómo te conectes, te recomendamos que uses una red privada virtual (VPN) para proteger tu conexión.
Cloud VPN te ayuda a conectar de forma segura tu red on-premise a tu red de nube privada virtual (VPC) de Google a través de una conexión VPN IPsec. Los datos en tránsito se cifran antes de pasar por una o varias túneles VPN.
Consulta cómo crear una VPN para tu proyecto.
VPN proporcionada por el cliente
Aunque puedes configurar tu propia pasarela VPN para conectarte directamente con Google, te recomendamos que uses Cloud VPN, que ofrece más flexibilidad y una mejor integración con Google Cloud.
Cloud Interconnect
Google ofrece varias formas de conectar tu infraestructura aGoogle Cloud. Estas conexiones de nivel empresarial, conocidas en conjunto como Cloud Interconnect, ofrecen una mayor disponibilidad y una latencia más baja que las conexiones a Internet estándar, así como precios de salida reducidos.
Cross-Cloud Interconnect te permite establecer una conectividad dedicada de gran ancho de banda con Google Cloudpara tus datos en otra nube. De esta forma, se reduce la complejidad de la red, los costes de transferencia de datos y se pueden crear granjas de renderizado multicloud de alto rendimiento.
Interconexión dedicada
Dedicated Interconnect proporciona conexiones físicas directas y comunicación RFC 1918 entre tu red on-premise y la red de Google. Ofrece capacidad de conexión a través de los siguientes tipos de conexiones:
- Una o varias conexiones Ethernet de 10 Gbps, con un máximo de ocho conexiones u 80 Gbps en total por interconexión.
- Una o varias conexiones Ethernet de 100 Gbps, con un máximo de dos conexiones o 200 Gbps en total por interconexión.
El tráfico de Interconexión dedicada no está cifrado. Si necesitas transmitir datos a través de una interconexión dedicada de forma segura, debes establecer tu propia conexión VPN. Cloud VPN no es compatible con Interconexión dedicada, por lo que debes proporcionar tu propia VPN en este caso.
Partner Interconnect
Partner Interconnect proporciona conectividad entre tu red on-premise y tu red de VPC a través de un proveedor de servicios compatible. Una conexión de Partner Interconnect es útil si tu infraestructura se encuentra en una ubicación física que no puede acceder a una instalación de colocación de Dedicated Interconnect o si tus necesidades de datos no justifican una conexión completa de 10 Gbps.
Otros tipos de conexiones
Puede que haya otras formas de conectarse a Google en tu ubicación. Si necesitas ayuda para determinar la mejor forma de conectarte aGoogle Cloudy la más rentable, ponte en contacto con tu representante de Google Cloud .
Proteger tu contenido
Para poder ejecutar su contenido en cualquier plataforma de nube pública, los propietarios de contenido, como los grandes estudios de Hollywood, requieren que los proveedores cumplan las prácticas recomendadas de seguridad definidas tanto internamente como por organizaciones como la MPAA. Google Cloud ofrece modelos de seguridad de confianza cero integrados en productos como Google Workspace, Chrome Enterprise Premium y BeyondProd.
Cada estudio tiene requisitos diferentes para proteger las cargas de trabajo de renderización. Puede consultar los informes técnicos de seguridad y la documentación de cumplimiento en cloud.google.com/security.
Si tienes alguna pregunta sobre el proceso de auditoría de cumplimiento de seguridad, ponte en contacto con tu representante deGoogle Cloud .
Organizar los proyectos
Los proyectos son un componente organizativo fundamental de Google Cloud. En tu centro, puedes organizar los trabajos en sus propios proyectos o dividirlos en varios proyectos. Por ejemplo, puedes crear proyectos independientes para las fases de previsualización, investigación y desarrollo, y producción de una película.
Los proyectos establecen un límite de aislamiento tanto para los datos de red como para la administración de proyectos. Sin embargo, puedes compartir redes entre proyectos con la VPC compartida, que proporciona a los proyectos independientes acceso a recursos comunes.
Notas de producción: crea un proyecto del host de VPC compartida que contenga recursos con todas tus herramientas de producción. Puedes designar todos los proyectos que se creen en tu organización como proyectos de servicio de VPC compartida. Esta designación significa que cualquier proyecto de tu organización puede acceder a las mismas bibliotecas, secuencias de comandos y software que proporciona el proyecto host.
El recurso Organization
Puedes gestionar proyectos en un recurso de organización, que puede que ya hayas creado. Migrar todos sus proyectos a una organización le ofrece una serie de ventajas.
Notas de producción: designa a los responsables de producción como propietarios de sus proyectos y a la gestión del estudio como propietarios del recurso Organización.
Definir el acceso a los recursos
Los proyectos requieren un acceso seguro a los recursos, así como restricciones sobre dónde pueden operar los usuarios o los servicios. Para ayudarte a definir el acceso,Google Cloud ofrece Gestión de Identidades y Accesos (IAM), que puedes usar para gestionar el control de acceso definiendo qué roles tienen qué niveles de acceso a qué recursos.
Notas de producción: para restringir el acceso de los usuarios solo a los recursos que necesiten para llevar a cabo tareas específicas en función de su rol, implementa el principio de mínimos accesos tanto en las instalaciones como en la nube.
Por ejemplo, considera un trabajador de renderizado, que es una máquina virtual (VM) que puedes desplegar desde una plantilla de instancia predefinida que usa tu imagen personalizada. El trabajador de renderización que se ejecuta con una cuenta de servicio puede leer datos de Cloud Storage y escribir en el almacenamiento conectado, como un archivo en la nube o un disco persistente. Sin embargo, no es necesario que añadas artistas a los proyectos deGoogle Cloud , ya que no necesitan acceso directo a los recursos en la nube.
Puedes asignar roles a los responsables de renderización o a los administradores de proyectos que tengan acceso a todos los recursos de Compute Engine, lo que les permite realizar funciones en recursos a los que otros usuarios no pueden acceder.
Define una política para determinar qué roles pueden acceder a qué tipos de recursos de tu organización. En la siguiente tabla se muestra cómo se asignan las tareas de producción habituales a los roles de gestión de identidades y accesos en Google Cloud.
| Tarea de producción | Nombre de rol | Tipo de recurso |
|---|---|---|
| Gestor de Studio | resourcemanager.organizationAdmin |
Organización Proyecto |
| Responsable de producción | owner, editor |
Proyecto |
| Wrangler de renderizado | compute.admin, iam.serviceAccountActor |
Proyecto |
| Cuenta de gestión de colas | compute.admin, iam.serviceAccountActor |
Organización Proyecto |
| Artista individual | [no access] | No aplicable |
Permisos de acceso
Los permisos de acceso te permiten controlar los permisos de una instancia en ejecución, independientemente de quién haya iniciado sesión. Puedes especificar ámbitos al crear una instancia o cuando tu software de gestión de colas implemente recursos a partir de una plantilla de instancia.
Los ámbitos tienen prioridad sobre los permisos de gestión de identidades y accesos de un usuario o una cuenta de servicio concretos. Esta precedencia significa que un ámbito de acceso puede impedir que un administrador de un proyecto inicie sesión en una instancia para eliminar un contenedor de almacenamiento o cambiar un ajuste de cortafuegos.
Notas de producción: de forma predeterminada, las instancias pueden leer datos de Cloud Storage, pero no escribir en él. Si tu canalización de renderizado escribe los renderizados terminados en Cloud Storage, añade el ámbito devstorage.read_write a tu instancia en el momento de la creación.
Elegir cómo desplegar recursos
Con el renderizado en la nube, puedes usar recursos solo cuando los necesites, pero puedes elegir entre varias formas de poner recursos a disposición de tu granja de renderizado.
Despliegue bajo demanda
Para optimizar el uso de los recursos, puedes implementar renderizadores solo cuando envíes un trabajo a la granja de renderizado. Puedes desplegar muchas VMs para que se compartan entre todos los fotogramas de un trabajo o incluso crear una VM por fotograma.
Tu sistema de gestión de colas puede monitorizar las instancias en ejecución, que se pueden volver a poner en cola si se ha retirado una VM y se pueden finalizar cuando se completen las tareas individuales.
Desplegar un grupo de recursos
También puedes desplegar un grupo de instancias que no estén relacionadas con ningún trabajo específico y a las que pueda acceder tu sistema de gestión de colas local como recursos adicionales. Si usas las máquinas virtuales de Spot de Google Cloud, un grupo de instancias en ejecución puede aceptar varios trabajos por máquina virtual, usando todos los núcleos y maximizando el uso de los recursos. Esta estrategia puede ser la más sencilla de implementar, ya que imita la forma en que se rellena una granja de renderización local con tareas.
Licencia del software
Las licencias de software de terceros pueden variar mucho de un paquete a otro. Estos son algunos de los esquemas y modelos de licencias que puedes encontrar en un flujo de trabajo de efectos visuales. En cada esquema, la tercera columna muestra el enfoque de licencias recomendado.
| Esquema | Descripción | Recomendación |
|---|---|---|
| Nodo bloqueado | Con licencia para una dirección MAC, una dirección IP o un ID de CPU específicos. Solo puede ejecutarlo un proceso. | Basado en instancias |
| Basado en nodos | Licencia para un nodo específico (instancia). Se puede ejecutar un número arbitrario de usuarios o procesos en un nodo con licencia. | Basado en instancias |
| Flotante | Se ha retirado de un servidor de licencias que monitoriza el uso. | Servidor de licencias |
| Licencias de software | ||
| Interactivo | Permite al usuario ejecutar software de forma interactiva en un entorno basado en gráficos. | Servidor de licencias o basado en instancias |
| Lotes | Permite al usuario ejecutar software solo en un entorno de línea de comandos. | Servidor de licencias |
| Licencias basadas en la nube | ||
| Basado en el uso | Se extrae solo cuando se ejecuta un proceso en una instancia de nube. Cuando el proceso finaliza o termina, se libera la licencia. | Servidor de licencias basado en la nube |
| Basado en el tiempo de actividad | Se ha retirado mientras una instancia está activa y en ejecución. Al detener o eliminar la instancia, se libera la licencia. | Servidor de licencias basado en la nube |
Usar licencias basadas en instancias
Algunos programas de software o complementos se licencian directamente al hardware en el que se ejecutan. Este enfoque de las licencias puede suponer un problema en la nube, donde los identificadores de hardware, como las direcciones MAC o IP, se asignan de forma dinámica.
Direcciones MAC
Cuando se crean, las instancias reciben una dirección MAC que se conserva mientras no se eliminen. Puedes detener o reiniciar una instancia y la dirección MAC se conservará. Puedes usar esta dirección MAC para crear y validar licencias hasta que se elimine la instancia.
Asignar una dirección IP estática
Cuando creas una instancia, se le asigna una dirección IP interna y, opcionalmente, una externa. Para conservar la dirección IP externa de una instancia, puedes reservar una dirección IP estática y asignársela a la instancia. Esta dirección IP se reservará solo para esta instancia. Como las direcciones IP estáticas son un recurso basado en proyectos, están sujetas a cuotas regionales.
También puedes asignar una dirección IP interna al crear una instancia, lo que resulta útil si quieres que las direcciones IP internas de un grupo de instancias estén dentro del mismo intervalo.
Adaptadores de hardware
Es posible que el software antiguo siga teniendo una licencia a través de un dongle, una llave de hardware programada con una licencia de producto. La mayoría de las empresas de software han dejado de usar llaves de hardware, pero es posible que algunos usuarios tengan software antiguo que esté vinculado a uno de estos dispositivos. Si te encuentras con este problema, ponte en contacto con el fabricante del software para ver si puede proporcionarte una licencia actualizada para tu software concreto.
Si el fabricante del software no puede proporcionarte una licencia de este tipo, puedes implementar un concentrador USB conectado a la red o una solución USB sobre IP.
Usar un servidor de licencias
La mayoría del software moderno ofrece una opción de licencia flotante. Esta opción es la más adecuada en un entorno de nube, pero requiere una gestión de licencias y un control de acceso más estrictos para evitar que se consuma en exceso un número limitado de licencias.
Para evitar superar la capacidad de tus licencias, puedes elegir qué licencias quieres usar y controlar el número de tareas que las usan como parte del proceso de la cola de tareas.
Servidor de licencias local
Puedes usar tu servidor de licencias local para proporcionar licencias a las instancias que se ejecutan en la nube. Si eliges este método, debes proporcionar a tus render workers una forma de comunicarse con tu red local, ya sea a través de una VPN o de otra conexión segura.
Servidor de licencias basado en la nube
En la nube, puedes ejecutar un servidor de licencias que proporcione servicio a las instancias de tu proyecto o incluso de varios proyectos mediante la VPC compartida. Las licencias flotantes a veces están vinculadas a una dirección MAC de hardware, por lo que una instancia pequeña y de larga duración con una dirección IP estática puede proporcionar licencias fácilmente a muchas instancias de renderización.
Servidor de licencias híbrido
Algunos softwares pueden usar varios servidores de licencias en orden de prioridad. Por ejemplo, un renderizador puede consultar el número de licencias disponibles en un servidor local y, si no hay ninguna, usar un servidor de licencias basado en la nube. Esta estrategia puede ayudarte a maximizar el uso de las licencias permanentes antes de probar otros tipos de licencia.
Notas de producción: define uno o varios servidores de licencias en una variable de entorno y define el orden de prioridad. Autodesk Arnold, un renderizador popular, te ayuda a hacerlo. Si el trabajo no puede adquirir una licencia mediante el primer servidor, intentará usar cualquier otro servidor que aparezca en la lista, como en el siguiente ejemplo:
export solidangle_LICENSE=5053@x.x.0.1;5053@x.x.0.2
En el ejemplo anterior, el renderizador Arnold intenta obtener una licencia del servidor x.x.0.1, puerto 5053. Si no lo consigue, intentará obtener una licencia del mismo puerto en la dirección IP x.x.0.2.
Licencias basadas en la nube
Algunos proveedores ofrecen licencias basadas en la nube que proporcionan licencias de software bajo demanda para tus instancias. La facturación de las licencias basadas en la nube suele hacerse de dos formas: en función del uso y en función del tiempo de actividad.
Licencias basadas en el uso
La facturación de las licencias basadas en el uso se realiza en función del tiempo que se utiliza el software. Normalmente, con este tipo de licencia, se extrae una licencia de un servidor basado en la nube cuando se inicia el proceso y se libera cuando se completa. Mientras una licencia esté prestada, se te facturará por el uso de esa licencia. Este tipo de licencia se suele usar para software de renderización.
Licencias basadas en el tiempo de actividad
Las licencias basadas en el tiempo de actividad o medidas se facturan en función del tiempo de actividad de tu instancia de Compute Engine. La instancia se configura para registrarse en el servidor de licencias basado en la nube durante el proceso de inicio. Mientras la instancia esté en ejecución, la licencia se habrá retirado. Cuando se detiene o se elimina la instancia, se libera la licencia. Este tipo de licencia se suele usar para los trabajadores de renderización que implementa un gestor de colas.
Elegir cómo almacenar los datos
El tipo de almacenamiento que elijas en Google Cloud depende de la estrategia de almacenamiento que hayas seleccionado, así como de factores como los requisitos de durabilidad y el coste.
Disco persistente
Puede que puedas evitar implementar un servidor de archivos por completo incorporando discos persistentes (PDs) a tu carga de trabajo. Los discos persistentes son un tipo de almacenamiento en bloque compatible con POSIX de hasta 64 TB, que la mayoría de las instalaciones de efectos visuales conocen bien. Los discos persistentes están disponibles como unidades estándar y unidades de estado sólido (SSD). Puedes conectar un disco persistente en modo de lectura y escritura a una sola instancia, o en modo de solo lectura a un gran número de instancias, como un grupo de renderizadores.
| Ventajas | Inconvenientes | Caso práctico ideal |
|---|---|---|
| Se monta como un volumen NFS o SMB estándar. Puede cambiar de tamaño de forma dinámica. Se pueden adjuntar hasta 128 discos persistentes a una sola instancia. El mismo PD se puede montar como de solo lectura en cientos o miles de instancias. |
Tamaño máximo de 64 TB. Solo se puede escribir en un disco persistente cuando está conectado a una sola instancia. Solo pueden acceder a él los recursos que se encuentren en la misma región. |
Pipelines avanzados que pueden crear un disco nuevo por trabajo. Canalizaciones que sirven datos que no se actualizan con frecuencia, como software o bibliotecas comunes, a los trabajadores de renderizado. |
Almacenamiento de objetos
Cloud Storage es un almacenamiento de alta redundancia y durabilidad que, a diferencia de los sistemas de archivos tradicionales, no está estructurado y tiene una capacidad prácticamente ilimitada. Los archivos de Cloud Storage se almacenan en segmentos, que son similares a las carpetas, y se puede acceder a ellos desde cualquier parte del mundo.
A diferencia del almacenamiento tradicional, el almacenamiento de objetos no se puede montar como un volumen lógico en un sistema operativo. Si decides incorporar el almacenamiento de objetos a tu canalización de renderizado, debes modificar la forma en que lees y escribes datos, ya sea mediante utilidades de línea de comandos, como la CLI de gcloud, o a través de la API Cloud Storage.
| Ventajas | Inconvenientes | Caso práctico ideal |
|---|---|---|
| Almacenamiento duradero y de alta disponibilidad para archivos de todos los tamaños. Una sola API para todas las clases de almacenamiento. Económico. Los datos están disponibles en todo el mundo. Capacidad prácticamente ilimitada. |
No cumple los requisitos de POSIX. Se debe acceder a través de una API o de una utilidad de línea de comandos. En una canalización de renderizado, los datos deben transferirse localmente antes de usarse. |
Renderizar pipelines con un sistema de gestión de recursos que pueda publicar datos en Cloud Storage. Renderiza las canalizaciones con un sistema de gestión de colas que pueda obtener datos de Cloud Storage antes de renderizar. |
Otros productos de almacenamiento
Otros productos de almacenamiento están disponibles como servicios gestionados a través de canales de terceros, como Cloud Marketplace, o como proyectos de código abierto a través de repositorios de software o GitHub.
| Producto | Ventajas | Inconvenientes | Caso práctico ideal |
|---|---|---|---|
| Filestore | Sistema de archivos en clúster que puede admitir miles de conexiones NFS simultáneas. Puede sincronizarse con un clúster NAS local. |
No hay forma de sincronizar archivos de forma selectiva. No hay sincronización bidireccional. | Estudios de efectos visuales medianos o grandes con cientos de terabytes de datos que se van a presentar en la nube. |
| Pixit Media, PixStor | Sistema de archivos escalable horizontalmente que puede admitir miles de clientes NFS o POSIX simultáneos. Los datos se pueden almacenar en caché bajo demanda desde un NAS local y las actualizaciones se envían automáticamente al almacenamiento local. | Coste y asistencia de terceros de Pixit. | Estudios de efectos visuales medianos o grandes con cientos de terabytes de datos que se van a presentar en la nube. |
| Google Cloud NetApp Volumes | Solución de almacenamiento totalmente gestionada en Google Cloud. Es compatible con entornos de NFS, SMB y multiprotocolo. Instantáneas de un momento específico con recuperación de instancias |
No está disponible en todas las Google Cloud regiones. | Instalaciones de efectos visuales con una canalización capaz de sincronizar recursos. Disco compartido entre estaciones de trabajo virtuales. |
| Cloud Storage FUSE | Montar segmentos de Cloud Storage como sistemas de archivos. Bajo coste. | No es un sistema de archivos compatible con POSIX. Puede ser difícil de configurar y optimizar. | Estudios de efectos visuales que puedan desplegar, configurar y mantener un sistema de archivos de código abierto, con una canalización que pueda sincronizar recursos. |
Hay otros tipos de almacenamiento disponibles en Google Cloud. Para obtener más información, ponte en contacto con tu Google Cloud representante.
Más información sobre las opciones de almacenamiento de datos
- Opciones de almacenamiento disponibles en Google Cloud
- Almacenamiento de archivos en Compute Engine
- Diseñar una estrategia de almacenamiento óptima para tu carga de trabajo en la nube
Implementar estrategias de almacenamiento
Puedes implementar varias estrategias de almacenamiento en las canalizaciones de producción de efectos visuales o animación. Para ello, debes establecer convenciones que determinen cómo gestionar tus datos, tanto si accedes a ellos directamente desde tu almacenamiento local como si los sincronizas entre el almacenamiento local y la nube.
Estrategia 1: Montar el almacenamiento local directamente
Si tu centro tiene una conectividad de Google Cloud al menos 10 Gbps y está cerca de una Google Cloud región, puedes montar tu NAS local directamente en los renderizadores de la nube. Aunque esta estrategia es sencilla, también puede requerir muchos costes y ancho de banda, ya que todo lo que crees en la nube y escribas en el almacenamiento se contabiliza como datos de salida.
| Ventajas | Inconvenientes | Caso práctico ideal |
|---|---|---|
| Implementación sencilla. Leer o escribir en el almacenamiento común. Disponibilidad inmediata de los datos, sin necesidad de almacenamiento en caché ni sincronización. |
Puede ser más caro que otras opciones. Es necesario estar cerca de un centro de datos de Google para conseguir una latencia baja. El número máximo de instancias a las que puedes conectarte con tu NAS local depende del ancho de banda y del tipo de conexión. |
Instalaciones cercanas a un centro de datos de Google que necesiten renderizar cargas de trabajo en la nube, donde el coste no sea un problema. Instalaciones con conectividad de Google Cloud de al menos 10 Gbps. |
Estrategia 2: Sincronizar bajo demanda
Puedes enviar datos a la nube o extraer datos del almacenamiento local (o viceversa) solo cuando sea necesario, por ejemplo, cuando se renderiza un fotograma o se publica un recurso. Si usas esta estrategia, la sincronización se puede activar mediante un mecanismo de tu canalización, como un script de monitorización, un gestor de eventos, como Pub/Sub, o un conjunto de comandos como parte de un script de trabajo.
Puedes realizar una sincronización mediante varios comandos, como el comando scp de la CLI de gcloud, el comando rsync de la CLI de gcloud o los protocolos de transferencia de datos basados en UDP (UDT). Si decides usar un TDU de terceros, como Aspera, Cloud FastPath, BitSpeed o FDT, para comunicarte con un segmento de Cloud Storage, consulta la documentación del tercero para obtener información sobre su modelo de seguridad y sus prácticas recomendadas. Google no gestiona estos servicios de terceros.
Método push
Normalmente, se usa el método push cuando se publica un recurso, se coloca un archivo en una carpeta de monitorización o se completa un trabajo de renderización. Después, se envía a una ubicación predefinida.
Ejemplos:
- Un trabajador de renderización en la nube completa un trabajo de renderización y los fotogramas resultantes se envían de nuevo al almacenamiento local.
- Un artista publica un recurso. Parte del proceso de publicación de recursos consiste en enviar los datos asociados a una ruta predefinida en Cloud Storage.
Método de extracción
El método de extracción se usa cuando se solicita un archivo, normalmente por una instancia de renderización basada en la nube.
Ejemplo: Como parte de una secuencia de comandos de un trabajo de renderización, todos los recursos necesarios para renderizar una escena se extraen en un sistema de archivos antes de la renderización, donde todos los trabajadores de renderización pueden acceder a ellos.
| Ventajas | Inconvenientes | Caso práctico ideal |
|---|---|---|
| Control total sobre qué datos se sincronizan y cuándo. Posibilidad de elegir el método y el protocolo de transferencia. |
Tu flujo de producción debe ser capaz de gestionar eventos para activar
sincronizaciones push o pull. Puede que se necesiten recursos adicionales para gestionar la cola de sincronización. |
Instalaciones pequeñas o grandes que tienen pipelines personalizados y quieren tener un control total sobre la sincronización de los recursos. |
Notas de producción: gestiona la sincronización de datos con el mismo sistema de gestión de colas que usas para gestionar los trabajos de renderización. Las tareas de sincronización pueden usar recursos de nube independientes para maximizar el ancho de banda disponible y minimizar el tráfico de red.
Estrategia 3: Almacenamiento on-premise y caché de lectura basado en la nube
Google Cloud ha ampliado y desarrollado una solución de almacenamiento en caché de KNFSD como opción de código abierto. La solución puede gestionar las demandas de rendimiento de la granja de renderización que superan las capacidades de la infraestructura de almacenamiento. El almacenamiento en caché de KNFSD ofrece un almacenamiento en caché de lectura de alto rendimiento, lo que permite que las cargas de trabajo se escalen a cientos o incluso miles de nodos de renderizado en varias regiones y grupos de almacenamiento híbridos.
El almacenamiento en caché de KNFSD es una solución de escalado horizontal que reduce la carga en el servicio principal de uso compartido de archivos. El almacenamiento en caché de KNFSD también reduce el efecto de sobrecarga cuando muchos nodos de renderizado intentan recuperar archivos del servidor de archivos al mismo tiempo. Al usar una capa de caché en la misma red de VPC que los nodos de renderización, se reduce la latencia de lectura, lo que ayuda a que los trabajos de renderización empiecen y finalicen más rápido. En función de cómo hayas configurado tu servidor de archivos de caché, los datos permanecerán en la caché hasta que:
- Los datos se eliminan o permanecen sin cambios durante un periodo determinado.
- Se necesita espacio en el servidor de archivos, momento en el que los datos se eliminan de la caché en función de su antigüedad.
Esta estrategia reduce la cantidad de ancho de banda y la complejidad necesarias para implementar muchas instancias de renderización simultáneas.
En algunos casos, puede que quieras precalentar la caché para asegurarte de que todos los datos relacionados con el trabajo estén presentes antes de renderizar. Para precalentar la caché, lee el contenido de un directorio que esté en tu servidor de archivos en la nube. Para ello, realiza una read
o una stat de uno o varios archivos. Si accedes a los archivos de esta forma, se activará el mecanismo de sincronización.
También puedes añadir un dispositivo físico local para comunicarte con el dispositivo virtual. Por ejemplo, NetApp ofrece una solución de almacenamiento que puede reducir aún más la latencia entre tu almacenamiento local y la nube.
| Ventajas | Inconvenientes | Caso práctico ideal |
|---|---|---|
| Los datos almacenados en caché se gestionan automáticamente. Reduce los requisitos de ancho de banda. Los sistemas de archivos en la nube agrupados se pueden escalar vertical u horizontalmente en función de los requisitos del trabajo. |
Puede incurrir en costes adicionales. Las tareas previas al trabajo deben implementarse si decides precalentar la caché. |
Grandes instalaciones que despliegan muchas instancias simultáneas y leen recursos comunes en muchos trabajos. |
Filtrar datos
Puedes crear una base de datos de tipos de recursos y condiciones asociadas para definir si se debe sincronizar un tipo de datos concreto. Es posible que no quieras sincronizar algunos tipos de datos, como los datos efímeros que se generan como parte de un proceso de conversión, los archivos de caché o los datos de simulación. También debes plantearte si quieres sincronizar los recursos sin aprobar, ya que no todas las iteraciones se usarán en las renderizaciones finales.
Realizar una transferencia inicial en bloque
Al implementar tu granja de renderizado híbrida, puede que quieras realizar una transferencia inicial de todo o parte de tu conjunto de datos a Cloud Storage, a un disco persistente o a otro almacenamiento basado en la nube. En función de factores como la cantidad y el tipo de datos que quieras transferir y la velocidad de tu conexión, es posible que puedas realizar una sincronización completa en el transcurso de unos días o semanas. En la siguiente figura se comparan los tiempos habituales de las transferencias online y físicas.
Si la carga de trabajo de la transferencia supera las limitaciones de tiempo o ancho de banda, Google ofrece varias opciones de transferencia para que pueda subir sus datos a la nube, como el Transfer Appliance de Google.
Archivado y recuperación tras desastres
Es importante tener en cuenta la diferencia entre el archivado de datos y la recuperación tras fallos. La primera es una copia selectiva del trabajo finalizado, mientras que la segunda es un estado de los datos que se puede recuperar. Quieres diseñar un plan de recuperación tras fallos que se adapte a las necesidades de tu centro y que proporcione un plan de contingencia externo. Ponte en contacto con el proveedor de tu almacenamiento local para obtener ayuda con un plan de recuperación ante desastres que se adapte a tu plataforma de almacenamiento específica.
Archivar datos en la nube
Una vez que se completa un proyecto, es habitual guardar el trabajo finalizado en algún tipo de almacenamiento a largo plazo, normalmente en cintas magnéticas, como LTO. Estos cartuchos están sujetos a requisitos medioambientales y, con el tiempo, puede ser difícil gestionarlos desde el punto de vista logístico. En ocasiones, las grandes instalaciones de producción albergan todo su archivo en una sala diseñada específicamente para ello, con un archivero a tiempo completo que se encarga de hacer un seguimiento de los datos y recuperarlos cuando se solicitan.
Buscar recursos, planos o grabaciones específicos en el archivo puede llevar mucho tiempo, ya que los datos pueden estar almacenados en varios cartuchos, la indexación del archivo puede ser incompleta o faltar, o puede haber limitaciones de velocidad al leer datos de cintas magnéticas.
Migrar tu archivo de datos a la nube no solo puede eliminar la necesidad de gestionar y almacenar archivos multimedia en las instalaciones, sino que también puede hacer que tus datos sean mucho más accesibles y se puedan buscar más fácilmente que con los métodos de archivo tradicionales.
Una canalización de archivado básica podría tener el siguiente aspecto, en el que se emplean diferentes servicios en la nube para examinar, categorizar, etiquetar y organizar archivos. En la nube, puedes crear una herramienta de gestión y recuperación de archivos para buscar datos mediante varios criterios de metadatos, como la fecha, el proyecto, el formato o la resolución. También puedes usar las APIs de aprendizaje automático para etiquetar y categorizar imágenes y vídeos, y almacenar los resultados en una base de datos en la nube, como BigQuery.
Otros temas que debes tener en cuenta:
- Automatizar la generación de miniaturas o proxies de contenido que se encuentre en clases de almacenamiento de Cloud Storage que tengan tarifas de recuperación. Utiliza estos proxies en tu sistema de gestión de recursos multimedia para que los usuarios puedan consultar los datos leyendo solo los proxies, no los recursos archivados.
- Considera la posibilidad de usar el aprendizaje automático para clasificar el contenido de acción real. Usa la API Cloud Vision para etiquetar texturas y fondos, o la API Video Intelligence para buscar y recuperar metraje de referencia.
- También puedes usar Vertex AI AutoML Image para crear un modelo de imagen personalizado que reconozca cualquier recurso, ya sea de acción real o renderizado.
- En el caso del contenido renderizado, te recomendamos que guardes una copia de la imagen de disco del trabajador de renderización junto con el recurso renderizado. Si necesitas volver a crear la configuración, tendrás disponibles las versiones de software, los complementos, las bibliotecas del SO y las dependencias correctos si necesitas volver a renderizar una toma archivada.
Gestionar recursos y producción
Trabajar en el mismo proyecto en varias instalaciones puede plantear retos únicos, sobre todo cuando el contenido y los recursos deben estar disponibles en todo el mundo. Sincronizar datos manualmente en redes privadas puede ser caro y requerir muchos recursos, además de estar sujeto a las limitaciones de ancho de banda locales.
Si tu carga de trabajo requiere datos disponibles a nivel mundial, puedes usar Cloud Storage, al que se puede acceder desde cualquier lugar en el que puedas acceder a los servicios de Google. Para incorporar Cloud Storage a tu canalización, debes modificarla para que interprete las rutas de los objetos y, a continuación, extraer o insertar los datos en los trabajadores de renderización antes de renderizar. Este método proporciona acceso global a los datos publicados, pero requiere que tu canal de distribución proporcione los recursos a donde se necesiten en un plazo razonable.
Por ejemplo, un artista de texturas de Los Ángeles puede publicar archivos de imagen para que los utilice un artista de iluminación de Londres. El proceso es el siguiente:
- El flujo de publicación envía los archivos a Cloud Storage y añade una entrada a una base de datos de recursos basada en la nube.
- Un artista de Londres ejecuta una secuencia de comandos para reunir los recursos de una escena. Las ubicaciones de los archivos se consultan en la base de datos y se leen desde Cloud Storage en el disco local.
- El software de gestión de colas recopila una lista de los recursos necesarios para el renderizado, los consulta en la base de datos de recursos y los descarga de Cloud Storage al almacenamiento local de cada trabajador de renderizado.
Si usas Cloud Storage de esta forma, también tendrás un archivo de todos tus datos publicados en la nube si decides usar Cloud Storage como parte de tu canalización de archivo.
Gestionar bases de datos
El software de gestión de recursos y producción depende de bases de datos duraderas y de alta disponibilidad que se sirven en hosts capaces de gestionar cientos o miles de consultas por segundo. Las bases de datos suelen alojarse en un servidor local que se ejecuta en el mismo rack que los renderizadores y están sujetas a las mismas limitaciones de energía, red y climatización.
Puede que te interese ejecutar tus bases de datos de producción de MySQL, NoSQL y PostgreSQL como servicios gestionados basados en la nube. Estos servicios tienen una alta disponibilidad y se puede acceder a ellos desde cualquier parte del mundo. Además, cifran los datos tanto en reposo como en tránsito y ofrecen una función de replicación integrada.
Gestionar colas
Programas de software de gestión de colas disponibles comercialmente, como Qube!, Deadline y Tractor se utilizan mucho en el sector de los efectos visuales y la animación. También hay opciones de software libre, como OpenCue. Puedes usar este software para implementar y gestionar cualquier carga de trabajo de computación en varios trabajadores, no solo en renderizaciones. Puedes implementar y gestionar la publicación de recursos, las simulaciones de partículas y fluidos, el horneado de texturas y la composición con el mismo marco de programación que usas para gestionar las renderizaciones.
Algunas instalaciones han implementado software de programación de uso general, como HTCondor de la Universidad de Wisconsin, Slurm de SchedMD o Univa Grid Engine en sus pipelines de efectos visuales. Sin embargo, el software diseñado específicamente para el sector de los efectos visuales presta especial atención a funciones como las siguientes:
- Dependencia basada en tareas, fotogramas y capas. Debes completar algunas tareas antes de poder empezar otros trabajos. Por ejemplo, ejecuta una simulación de fluidos por completo antes de renderizarla.
- Prioridad de los trabajos, que los responsables de renderización pueden usar para cambiar el orden de los trabajos en función de los plazos y las programaciones individuales.
- Tipos de recursos, etiquetas o destinos, que puedes usar para asociar recursos específicos con los trabajos que los requieran. Por ejemplo, puedes desplegar renderizaciones aceleradas por GPU solo en las VMs que tengan GPUs conectadas.
- Recoger datos históricos sobre el uso de recursos y ponerlos a disposición a través de una API o un panel de control para analizarlos más en profundidad. Por ejemplo, puedes consultar el uso medio de CPU y memoria de las últimas iteraciones de una renderización para predecir el uso de recursos de la siguiente iteración.
- Tareas previas y posteriores al vuelo. Por ejemplo, un trabajo previo al vuelo extrae todos los recursos necesarios en el trabajador de renderización local antes de renderizar. Un trabajo posterior al vuelo copia el fotograma renderizado resultante en una ubicación designada de un sistema de archivos y, a continuación, marca el fotograma como completado en un sistema de gestión de recursos.
- Integración con aplicaciones de software 2D y 3D populares, como Maya, 3ds Max, Houdini, Cinema 4D o Nuke.
Notas de producción: usa un software de gestión de colas para reconocer un conjunto de recursos basados en la nube como si fueran trabajadores de renderización locales. Este método requiere cierta supervisión para maximizar el uso de los recursos ejecutando tantas renderizaciones como pueda gestionar cada instancia, una técnica conocida como "empaquetamiento". Estas operaciones se suelen gestionar tanto de forma algorítmica como por los responsables de renderización.
También puedes automatizar la creación, la gestión y la finalización de recursos basados en la nube a petición. Este método se basa en el gestor de colas para ejecutar secuencias de comandos previas y posteriores a la renderización que crean recursos según sea necesario, los monitorizan durante la renderización y los finalizan cuando se completan las tareas.
Consideraciones sobre la implementación de tareas
Cuando implementes una granja de renderización que utilice almacenamiento local y en la nube, tu gestor de colas deberá tener en cuenta lo siguiente:
- Las licencias pueden ser diferentes en las implementaciones en la nube y en las locales. Algunas licencias se basan en nodos y otras en procesos. Asegúrate de que tu software de gestión de colas implemente trabajos para maximizar el valor de tus licencias.
- Añade etiquetas únicas a los recursos basados en la nube para asegurarte de que solo se usen cuando se asignen a tipos de trabajo específicos.
- Usa Cloud Logging para detectar instancias inactivas o sin usar.
- Cuando inicies trabajos dependientes, ten en cuenta dónde se almacenarán los datos resultantes y dónde deben estar para el siguiente paso.
- Si los espacios de nombres de las rutas son diferentes en el almacenamiento local y en el basado en la nube, considera la posibilidad de usar rutas relativas para que las representaciones no dependan de la ubicación. También puedes crear un mecanismo para intercambiar rutas en tiempo de renderización, en función de la plataforma.
- Algunos renderizados, simulaciones o posprocesos se basan en la generación de números aleatorios, que puede variar entre los fabricantes de CPUs. Incluso las CPUs del mismo fabricante, pero de diferentes generaciones de chips, pueden producir resultados distintos. Si tienes dudas, usa tipos de CPU idénticos o similares para todos los marcos de un trabajo.
- Si utilizas un dispositivo de caché de lectura, plantéate la posibilidad de implementar un trabajo previo para precalentar la caché y asegurarte de que todos los recursos estén disponibles en la nube antes de implementar los recursos en la nube. De esta forma, se reduce el tiempo que los renderizadores tienen que esperar mientras se mueven los recursos a la nube.
Almacenamiento de registros y monitorización
Registrar y monitorizar el uso de recursos y el rendimiento es un aspecto esencial de cualquier granja de renderizado. Google Cloud ofrece varias APIs, herramientas y soluciones para ayudar a obtener información valiosa sobre la utilización de recursos y servicios.
La forma más rápida de monitorizar la actividad de una VM es ver su salida del puerto serie. Esta salida puede ser útil cuando una instancia no responde a través de planos de control de servicios típicos, como el supervisor de gestión de colas de renderización.
Otras formas de recoger y monitorizar el uso de recursos en Google Cloud son las siguientes:
- Usa Cloud Logging para registrar el uso y los registros de auditoría, y para exportar los registros resultantes a Cloud Storage, BigQuery y otros servicios.
- Usa Cloud Monitoring para instalar un agente en tus VMs y monitorizar las métricas del sistema.
- Incorpora la API Cloud Logging a tus secuencias de comandos de la canalización para registrar datos directamente en Cloud Logging mediante las bibliotecas de cliente de los lenguajes de scripting más populares.
- Usa Cloud Monitoring para crear gráficos y comprender el uso de los recursos.
Configurar las instancias de trabajador de renderización
Para que tu carga de trabajo sea realmente híbrida, los nodos de renderizado locales deben ser idénticos a los nodos de renderizado basados en la nube, con versiones de SO, compilaciones de kernel, bibliotecas instaladas y software coincidentes. También es posible que tengas que reproducir los puntos de montaje, los espacios de nombres de las rutas e incluso los entornos de usuario en la nube, ya que están en las instalaciones.
Elegir una imagen de disco
Puedes elegir una de las imágenes públicas o crear tu propia imagen personalizada a partir de la imagen de tu nodo de renderizado local. Las imágenes públicas incluyen una colección de paquetes que configuran y gestionan cuentas de usuario y habilitan la autenticación basada en claves Secure Shell (SSH).
Crear una imagen personalizada
Si decides crear una imagen personalizada, tendrás que añadir más bibliotecas tanto a Linux como a Windows para que funcionen correctamente en el entorno de Compute Engine.
La imagen personalizada debe cumplir las prácticas recomendadas de seguridad. Si usas Linux, instala el entorno de invitado de Linux para Compute Engine para acceder a las funciones que proporcionan las imágenes públicas de forma predeterminada. Al instalar el entorno de invitado, puedes realizar tareas como acceder a metadatos, configurar el sistema y optimizar el SO para usarlo en Google Cloud. Para ello, puedes usar los mismos controles de seguridad en tu imagen personalizada que en las imágenes públicas.
Notas de producción: gestiona tus imágenes personalizadas en un proyecto independiente a nivel de organización. Este enfoque te permite controlar con más precisión cómo se crean o modifican las imágenes y aplicar versiones, lo que puede ser útil cuando se usan diferentes versiones de software o sistemas operativos en varias producciones.
Automatizar la creación de imágenes y el despliegue de instancias
Puedes usar herramientas como Packer para que la creación de imágenes sea más reproducible, auditable, configurable y fiable. También puedes usar una herramienta como Ansible para configurar los nodos de renderizado en ejecución y controlar con precisión su configuración y su ciclo de vida.
Elegir un tipo de máquina
En Google Cloud, puedes elegir uno de los tipos de máquina predefinidos o especificar un tipo de máquina personalizado. Si usas tipos de máquinas personalizadas, tendrás control sobre los recursos, por lo que podrás personalizar las instancias en función de los tipos de trabajos que ejecutes en Google Cloud. Cuando creas una instancia, puedes añadir GPUs y especificar el número de CPUs, la plataforma de la CPU, la cantidad de RAM y el tipo y el tamaño de los discos.
Notas de producción: en las canalizaciones que implementan una instancia por fotograma, considera la posibilidad de personalizar la instancia en función de las estadísticas históricas de los trabajos, como la carga de la CPU o el uso de la memoria, para optimizar el uso de los recursos en todos los fotogramas de una toma. Por ejemplo, puedes desplegar máquinas con un mayor número de CPUs para los fotogramas que contengan un desenfoque de movimiento intenso, lo que te ayudará a normalizar los tiempos de renderizado en todos los fotogramas.
Elegir entre máquinas virtuales estándar e interrumpibles
Las máquinas virtuales interrumpibles (MVI) hacen referencia al exceso de capacidad de Compute Engine que se vende a un precio mucho más bajo que las máquinas virtuales estándar. Compute Engine puede finalizar o interrumpir temporalmente estas instancias si otras tareas requieren acceso a esa capacidad. Las máquinas virtuales interrumpibles son ideales para cargas de trabajo de renderización tolerantes a fallos y gestionadas por un sistema de colas que registra los trabajos que se pierden debido a la interrupción.
Las máquinas virtuales estándar se pueden ejecutar indefinidamente y son ideales para servidores de licencias o hosts de administrador de colas que deben ejecutarse de forma persistente.
Las VMs interrumpibles se terminan automáticamente al cabo de 24 horas, por lo que no debes usarlas para ejecutar renderizaciones o simulaciones que duren más tiempo.
Las tasas de desalojo oscilan entre el 5% y el 15%, lo que probablemente sea tolerable para las cargas de trabajo de renderización habituales, dado el coste reducido. Algunas prácticas recomendadas para usar instancias de VM preemprivibles pueden ayudarte a decidir la mejor forma de integrar las PVMs en tu canalización de renderización. Si se interrumpe temporalmente tu instancia, Compute Engine le envía una señal de interrupción temporal, que puedes usar para activar tu programador para que finalice el trabajo actual y lo vuelva a poner en cola.
| VM estándar | Máquina virtual interrumpible |
|---|---|
| Se puede usar en tareas de larga duración. Ideal para trabajos de alta prioridad con plazos estrictos. Se puede ejecutar indefinidamente, por lo que es ideal para servidores de licencias o alojamiento de administradores de colas. |
Se termina automáticamente al cabo de 24 horas. Requiere un sistema de gestión de colas para gestionar las instancias con prioridad. |
Notas de producción: Algunos renderizadores pueden hacer una instantánea de un render en curso a intervalos especificados, por lo que, si se interrumpe la VM, puedes pausar y reanudar el render sin tener que reiniciar un fotograma desde cero. Si tu renderizador admite la creación de instantáneas y decides usar PVMs, habilita la creación de instantáneas de renderización en tu canalización para no perder el trabajo. Mientras se escriben y actualizan las instantáneas, se pueden escribir datos en Cloud Storage y, si se interrumpe el trabajador de renderización, se pueden recuperar cuando se implemente una nueva PVM. Para evitar costes de almacenamiento, elimina los datos de las copias de las renderizaciones completadas.
Conceder acceso a los trabajadores de renderización
IAM te ayuda a asignar acceso a los recursos en la nube a las personas que lo necesiten. En el caso de los renderizadores de Linux, puedes usar OS Login para restringir aún más el acceso en una sesión SSH, lo que te permite controlar quién es administrador.
Controlar los costes de una granja de renderizado híbrida
Al estimar los costes, debes tener en cuenta muchos factores, pero te recomendamos que implementes estas prácticas recomendadas habituales como política para tu granja de render híbrida:
- Usar instancias interrumpibles de forma predeterminada. A menos que tu tarea de renderización sea extremadamente larga (cuatro horas o más por fotograma) o tengas una fecha límite para entregar una toma, usa máquinas virtuales interrumpibles.
- Minimizar la salida. Copia solo los datos que necesites en el almacenamiento local. En la mayoría de los casos, estos datos serán los fotogramas renderizados finales, pero también pueden ser pases independientes o datos de simulación. Si vas a montar tu NAS local directamente o vas a usar un producto de almacenamiento que se sincronice automáticamente, escribe todos los datos renderizados en el sistema de archivos local del renderizador y, a continuación, copia lo que necesites en el almacenamiento local para evitar que se transfieran datos temporales e innecesarios.
- Ajusta el tamaño de las VMs. Asegúrate de crear tus trabajadores de renderizado con un uso óptimo de los recursos. Para ello, asigna solo el número necesario de vCPUs, la cantidad óptima de RAM y el número correcto de GPUs (si es necesario). También debes tener en cuenta cómo minimizar el tamaño de los discos adjuntos.
- Ten en cuenta que el tiempo mínimo es de un minuto. En Google Cloud, las instancias se facturan por segundo, con un mínimo de un minuto. Si tu carga de trabajo incluye renderizar fotogramas que tardan menos de un minuto, considera la posibilidad de agrupar las tareas para evitar desplegar una instancia durante menos de un minuto de tiempo de computación.
- Mantén grandes conjuntos de datos en la nube. Si usas tu granja de renderizado para generar grandes cantidades de datos, como EXRs profundos o datos de simulación, te recomendamos que utilices una estación de trabajo basada en la nube que esté más abajo en el proceso. Por ejemplo, un artista de efectos especiales puede ejecutar una simulación de fluidos en la nube y escribir archivos de caché en un almacenamiento basado en la nube. Un artista de iluminación podría acceder a estos datos de simulación desde una estación de trabajo virtual que esté enGoogle Cloud. Para obtener más información sobre las estaciones de trabajo virtuales, ponte en contacto con tu Google Cloud representante.
- Aprovecha los descuentos por uso continuado y por compromiso de uso. Si utilizas un conjunto de recursos, los descuentos por uso continuado pueden ahorrarte hasta un 30% del coste de las instancias que se ejecutan durante todo un mes. En algunos casos, también pueden ser útiles los descuentos por uso confirmado.
Ampliar tu granja de renderizado a la nube es una forma rentable de usar recursos potentes y de bajo coste sin gastos de capital. No hay dos pipelines de producción iguales, por lo que ningún documento puede abarcar todos los temas y requisitos únicos. Si necesitas ayuda para migrar tus cargas de trabajo de renderización a la nube, ponte en contacto con tu representante. Google Cloud
Siguientes pasos
- Consulta arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Centro de arquitectura de Cloud.