Estudios de VFX y renderizado 3D con NetDrive — granjas de render sin copia local
Cómo los estudios de VFX y renderizado 3D usan NetDrive para montar Google Cloud Storage como unidad, de modo que los nodos de render lean fotogramas y texturas sin presincronizar.
Un estudio de VFX de tamaño medio mantiene su biblioteca de planos en Google Cloud Storage: simulaciones de fluidos en caché, secuencias de fotogramas EXR y una biblioteca de texturas compartida que supera los 30 TB en los proyectos activos. Cada nodo de render de la granja necesita acceso de lectura a esa biblioteca, pero descargar todo el conjunto de trabajo a cada máquina antes de que empiece un trabajo desperdicia espacio en disco que podría dedicarse a archivos temporales locales, y retrasa cada render el tiempo que tarde la sincronización. Montar el bucket como unidad con NetDrive permite que cada nodo lea, bajo demanda, exactamente los fotogramas y texturas que un trabajo necesita, sin un paso previo de copia.

Montar almacenamiento en la nube en toda una granja de render
NetDrive hace que Google Drive, OneDrive, S3, SFTP, WebDAV y más aparezcan como unidades nativas en Windows y macOS — sin sincronizar, sin descargas completas.
- Las unidades de solo lectura evitan que los nodos de render modifiquen los recursos de origen
- Las opciones de tamaño de caché de hasta 1 TB absorben las lecturas repetidas de texturas
- El montaje automático al arrancar mantiene las unidades listas sin sesión de usuario
Prueba gratuita. Planes de por vida y de suscripción disponibles.
Por qué el acceso bajo demanda es mejor que la presincronización
Los nodos de una granja de render suelen aprovisionarse para ser idénticos y desechables: la premisa de partida es que cualquier nodo puede encargarse de cualquier trabajo. Eso choca con presincronizar toda una biblioteca de recursos al disco local, porque en cuanto un trabajo puede recaer en cualquiera de cincuenta nodos, o los cincuenta necesitan una copia local completa (una duplicación enorme y constantemente desactualizada), o hay que ejecutar un paso de sincronización antes de cada trabajo, añadiendo minutos de tiempo muerto a un render que quizá solo tarde segundos por fotograma.
NetDrive monta el bucket de Google Cloud Storage como una unidad de red o una unidad de solo lectura, y el motor de render ve una ruta de archivo corriente como R:\assets\textures\. Los fotogramas y texturas solo se transfieren cuando un trabajo realmente los lee, y la caché de NetDrive mantiene disponibles los archivos usados recientemente para el siguiente trabajo que necesite la misma textura, sin volver a obtenerla del bucket cada vez.

Configurar una unidad de recursos de solo lectura para nodos de render
- Abre NetDrive y haz clic en + Add Drive en el Drive Manager.
- Elige Google Cloud Storage en la lista de proveedores.
- Introduce las credenciales de la cuenta de servicio limitadas al bucket de la biblioteca de planos; para nodos que solo consumen recursos basta con un rol de IAM de solo lectura.
- Introduce el nombre del bucket.
- En Drive Type, selecciona Read-only drive. Los nodos de render no tienen motivo para escribir de vuelta en el bucket de recursos de origen, y un montaje de solo lectura elimina la posibilidad de que un trabajo mal configurado sobrescriba accidentalmente una textura compartida.
- Ajusta Mount on a Boot, ya que los nodos de render funcionan como máquinas desatendidas en lugar de estaciones de trabajo con sesión iniciada.
- En la configuración de la unidad, aumenta el tamaño de la caché: NetDrive admite tamaños de caché de 100 GB hasta 1 TB (añadido en la versión 3.16.589), lo cual importa para nodos de render que acceden repetidamente al mismo conjunto de texturas a lo largo de muchos fotogramas de una secuencia.
- Haz clic en Mount.

Escribir fotogramas de vuelta sin bloquear el render
El acceso de lectura cubre las texturas y las cachés de simulación, pero los fotogramas terminados igualmente necesitan un destino. Una segunda unidad, montada en modo lectura-escritura hacia un bucket de salida, se encarga de eso. El modo de subida en segundo plano de NetDrive escribe primero los fotogramas terminados en una caché local y luego los sube de forma asíncrona a Google Cloud Storage, de modo que el proceso de render pasa al siguiente fotograma en lugar de detenerse por E/S de red en cada escritura.

Esta separación —solo lectura para la biblioteca de recursos compartida, lectura-escritura con subida en segundo plano para la salida— evita que las dos rutas de datos interfieran entre sí. Un nodo de render que lee una textura 4K no compite con su propia cola de salida de fotogramas por la misma semántica de conexión.
Escalar a muchos nodos
Como cada nodo monta el mismo bucket de forma independiente, añadir capacidad a la granja se reduce a aprovisionar otra máquina con la misma configuración de unidad de NetDrive, en lugar de negociar la contención de un almacenamiento compartido. Los nodos que quedan fuera de línea a mitad de un trabajo no dejan un sistema de archivos compartido en un estado inconsistente, ya que cada uno solo mantiene su propia caché local: el bucket en sí sigue siendo la única fuente de verdad.
Para estudios que operan entornos mixtos, el mismo bucket se monta de forma idéntica en los nodos de render Windows y en las estaciones de trabajo de artistas con macOS, de modo que un artista que revisa un plano toma los datos de la misma estructura de rutas que usó la granja para renderizar.
Resumen
Montar el almacenamiento en la nube como unidad permite que una granja de render trate un bucket de Google Cloud Storage como rutas locales ordinarias, con montajes de solo lectura que protegen los recursos de origen y subidas en segundo plano que evitan que la salida de fotogramas bloquee el siguiente render. Para la configuración subyacente, consulta Montar Google Cloud Storage en Windows con NetDrive o Montar Google Cloud Storage en macOS con NetDrive. Los estudios que ejecutan pipelines de renderizado automatizados al estilo CI también pueden encontrar útil Fixtures de prueba de S3 para equipos de CI para el patrón de montaje al arrancar del que dependen los nodos desatendidos.
— Morgan, NetDrive