Studios VFX et de rendu 3D avec NetDrive — des fermes de rendu sans copie locale

Un studio VFX de taille moyenne conserve sa bibliothèque de plans sur Google Cloud Storage — simulations de fluides mises en cache, séquences d’images EXR, et une bibliothèque de textures partagée qui dépasse 30 To sur l’ensemble des projets actifs. Chaque nœud de rendu de la ferme a besoin d’un accès en lecture à cette bibliothèque, mais télécharger l’intégralité du jeu de travail sur chaque machine avant qu’un job ne démarre gaspille de l’espace disque qui pourrait autrement accueillir des fichiers de travail locaux, et retarde chaque rendu du temps que prend la synchronisation. Monter le bucket comme lecteur avec NetDrive permet à chaque nœud de lire exactement les images et textures dont un job a besoin, à la demande, sans étape de copie préalable.

Monter le stockage cloud sur toute une ferme de rendu

Avec NetDrive, Google Drive, OneDrive, S3, SFTP, WebDAV et plus apparaissent comme des lecteurs natifs sur Windows et macOS — sans synchronisation ni téléchargement complet.

• Les lecteurs en lecture seule empêchent les nœuds de rendu de toucher aux assets sources
• Les options de taille de cache jusqu'à 1 To absorbent les lectures répétées de textures
• Le montage automatique au démarrage garde les lecteurs prêts sans session utilisateur

WindowsmacOS

Télécharger NetDrive →

Essai gratuit. Licences à vie et abonnements disponibles.

Pourquoi l’accès à la demande vaut mieux que la pré-synchronisation

Les nœuds d’une ferme de rendu sont généralement provisionnés pour être identiques et interchangeables — l’hypothèse de base est que n’importe quel nœud peut prendre en charge n’importe quel job. Cela va à l’encontre de la pré-synchronisation d’une bibliothèque d’assets entière vers le disque local, car dès qu’un job peut atterrir sur n’importe lequel de cinquante nœuds, soit les cinquante ont besoin d’une copie locale complète (une duplication énorme et constamment obsolète), soit une étape de synchronisation doit s’exécuter avant chaque job, ajoutant des minutes de temps mort à un rendu qui ne prend peut-être que quelques secondes par image.

NetDrive monte le bucket Google Cloud Storage comme un lecteur réseau ou un lecteur en lecture seule, et le moteur de rendu voit un chemin de fichier ordinaire comme R:\assets\textures\. Les images et textures ne transitent que lorsqu’un job les lit réellement, et le cache de NetDrive garde les fichiers récemment utilisés disponibles pour le prochain job qui a besoin de la même texture, sans avoir à la récupérer de nouveau depuis le bucket à chaque fois.

Configurer un lecteur d’assets en lecture seule pour les nœuds de rendu

1. Ouvrez NetDrive et cliquez sur + Add Drive dans le Drive Manager.
2. Choisissez Google Cloud Storage dans la liste des fournisseurs.
3. Saisissez les identifiants du compte de service limités au bucket de la bibliothèque de plans — un rôle IAM en lecture seule suffit pour des nœuds qui ne font que consommer les assets.
4. Saisissez le nom du bucket.
5. Dans Drive Type, sélectionnez Read-only drive. Les nœuds de rendu n’ont aucune raison d’écrire dans le bucket d’assets source, et un montage en lecture seule élimine le risque qu’un job mal configuré écrase accidentellement une texture partagée.
6. Réglez Mount on sur Boot, car les nœuds de rendu fonctionnent comme des machines sans surveillance plutôt que comme des postes de travail où quelqu’un est connecté.
7. Dans les paramètres du lecteur, augmentez la taille du cache — NetDrive prend en charge des tailles de cache de 100 Go jusqu’à 1 To (ajouté en 3.16.589), ce qui compte pour des nœuds de rendu qui accèdent à répétition au même ensemble de textures sur de nombreuses images d’une séquence.
8. Cliquez sur Mount.

Réécrire les images sans bloquer le rendu

L’accès en lecture couvre les textures et les caches de simulation, mais les images terminées doivent tout de même être stockées quelque part. Un second lecteur, monté en lecture-écriture vers un bucket de sortie, s’en charge. Le mode téléversement en arrière-plan de NetDrive écrit d’abord les images terminées dans un cache local puis les téléverse de manière asynchrone vers Google Cloud Storage, si bien que le processus de rendu passe à l’image suivante au lieu d’être bloqué par des E/S réseau à chaque écriture.

Cette séparation — lecture seule pour la bibliothèque d’assets partagée, lecture-écriture avec téléversement en arrière-plan pour la sortie — empêche les deux flux de données de se gêner mutuellement. Un nœud de rendu qui lit une texture 4K n’entre pas en concurrence avec sa propre file d’attente de sortie d’images pour la même sémantique de connexion.

Monter en charge sur de nombreux nœuds

Comme chaque nœud monte le même bucket indépendamment, ajouter de la capacité à la ferme revient simplement à provisionner une machine supplémentaire avec la même configuration de lecteur NetDrive, plutôt que de négocier une contention sur un stockage partagé. Les nœuds qui passent hors ligne en plein job ne laissent pas un système de fichiers partagé dans un état incohérent, puisque chacun ne détient que son propre cache local — le bucket lui-même reste la seule source de vérité.

Pour les studios qui exploitent des environnements mixtes, le même bucket se monte de façon identique sur les nœuds de rendu Windows et les postes de travail d’artistes macOS, de sorte qu’un artiste qui révise un plan puise dans la même structure de chemins que celle utilisée par la ferme pour le rendu.

En résumé

Monter le stockage cloud comme lecteur permet à une ferme de rendu de traiter un bucket Google Cloud Storage comme des chemins locaux ordinaires, avec des montages en lecture seule qui protègent les assets sources et des téléversements en arrière-plan qui empêchent la sortie d’images de bloquer le rendu suivant. Pour la configuration sous-jacente, voir Monter Google Cloud Storage sous Windows avec NetDrive ou Monter Google Cloud Storage sous macOS avec NetDrive. Les studios exploitant des pipelines de rendu automatisés de type CI pourront aussi trouver utile Fixtures de test S3 pour équipes DevOps pour le schéma de montage au démarrage dont dépendent les nœuds sans surveillance.

— Morgan, NetDrive