VFX- und 3D-Renderstudios mit NetDrive — Render-Farmen ohne lokale Kopie

Ein mittelgroßes VFX-Studio hält seine Shot-Bibliothek in Google Cloud Storage vor — gecachte Fluidsimulationen, EXR-Frame-Sequenzen und eine gemeinsame Textur-Bibliothek, die über die aktiven Projekte hinweg auf mehr als 30 TB anwächst. Jeder Render-Node in der Farm braucht Lesezugriff auf diese Bibliothek, aber das Herunterladen des gesamten Arbeitsbestands auf jede Maschine, bevor ein Job startet, verschwendet Speicherplatz, der stattdessen lokale Scratch-Dateien aufnehmen könnte, und verzögert jeden Render um die Dauer der Synchronisierung. Das Mounten des Buckets als Laufwerk mit NetDrive lässt jeden Node genau die Frames und Texturen lesen, die ein Job tatsächlich benötigt — bei Bedarf und ohne vorgeschalteten Kopierschritt.

Cloud-Speicher über eine Render-Farm hinweg mounten

Mit NetDrive erscheinen Google Drive, OneDrive, S3, SFTP, WebDAV und mehr als native Laufwerke unter Windows und macOS — ohne Synchronisation, ohne vollständige Downloads.

• Read-only-Laufwerke verhindern, dass Render-Nodes Quell-Assets verändern
• Cache-Größenoptionen bis 1 TB fangen wiederholte Texturzugriffe ab
• Auto-Mount beim Booten hält Laufwerke ohne Benutzersitzung bereit

WindowsmacOS

NetDrive herunterladen →

Kostenlose Testversion. Lifetime- und Abo-Pläne verfügbar.

Warum Zugriff bei Bedarf besser ist als Vorab-Synchronisierung

Render-Farm-Nodes werden in der Regel identisch und austauschbar bereitgestellt — die Grundannahme ist, dass jeder Node jeden Job übernehmen kann. Das spricht gegen eine vorab durchgeführte Synchronisierung einer kompletten Asset-Bibliothek auf lokalen Speicher, denn sobald ein Job auf jedem von fünfzig Nodes landen könnte, brauchen entweder alle fünfzig eine vollständige lokale Kopie (eine enorme, ständig veraltende Duplizierung), oder vor jedem Job muss ein Synchronisierungsschritt laufen, der Minuten an Totzeit zu einem Render hinzufügt, der pro Frame vielleicht nur Sekunden dauert.

NetDrive mountet den Google-Cloud-Storage-Bucket als Netzlaufwerk oder Read-only-Laufwerk, und die Render-Engine sieht einen gewöhnlichen Dateipfad wie R:\assets\textures\. Frames und Texturen werden nur übertragen, wenn ein Job sie tatsächlich liest, und der Cache von NetDrive hält kürzlich genutzte Dateien für den nächsten Job bereit, der dieselbe Textur benötigt, ohne sie jedes Mal erneut aus dem Bucket abzurufen.

Ein Read-only-Asset-Laufwerk für Render-Nodes einrichten

1. NetDrive öffnen und im Drive Manager auf + Add Drive klicken.
2. Google Cloud Storage aus der Anbieterliste auswählen.
3. Die Service-Account-Anmeldedaten eingeben, die auf den Shot-Bibliothek-Bucket beschränkt sind — für Nodes, die Assets nur konsumieren, genügt eine Read-only-IAM-Rolle.
4. Den Bucket-Namen eingeben.
5. Unter Drive Type Read-only drive auswählen. Render-Nodes haben keinen Grund, in den Quell-Asset-Bucket zurückzuschreiben, und ein Read-only-Mount schließt die Möglichkeit aus, dass ein falsch konfigurierter Job versehentlich eine gemeinsame Textur überschreibt.
6. Mount on auf Boot setzen, da Render-Nodes als unbeaufsichtigte Maschinen laufen und nicht als angemeldete Arbeitsplätze.
7. In den Laufwerkseinstellungen die Cache-Größe erhöhen — NetDrive unterstützt Cache-Größen von 100 GB bis 1 TB (hinzugefügt in 3.16.589), was für Render-Nodes wichtig ist, die über viele Frames einer Sequenz hinweg wiederholt auf denselben Texturensatz zugreifen.
8. Auf Mount klicken.

Frames zurückschreiben, ohne den Render zu blockieren

Der Lesezugriff deckt Texturen und Simulations-Caches ab, aber fertige Frames müssen trotzdem irgendwo landen. Ein zweites, read-write gegen einen Output-Bucket gemountetes Laufwerk übernimmt diese Seite. Der Hintergrund-Upload-Modus von NetDrive schreibt fertige Frames zunächst in einen lokalen Cache und lädt sie asynchron zu Google Cloud Storage hoch, sodass der Render-Prozess zum nächsten Frame weitergeht, statt bei jedem Schreibvorgang auf Netzwerk-I/O zu warten.

Diese Trennung — read-only für die gemeinsame Asset-Bibliothek, read-write mit Hintergrund-Upload für die Ausgabe — verhindert, dass sich die beiden Datenpfade gegenseitig stören. Ein Render-Node, der eine 4K-Textur liest, konkurriert nicht mit der eigenen Frame-Ausgabewarteschlange um dieselbe Verbindungssemantik.

Skalierung über viele Nodes hinweg

Da jeder Node denselben Bucket unabhängig mountet, bedeutet das Erweitern der Farmkapazität lediglich, eine weitere Maschine mit derselben NetDrive-Laufwerkskonfiguration bereitzustellen, statt gemeinsam genutzten Speicher mit Konkurrenzzugriffen auszuhandeln. Nodes, die mitten in einem Job offline gehen, hinterlassen kein gemeinsames Dateisystem in einem inkonsistenten Zustand, da jeder nur seinen eigenen lokalen Cache vorhält — der Bucket selbst bleibt die einzige verbindliche Quelle.

Für Studios mit gemischten Umgebungen mountet derselbe Bucket identisch auf Windows-Render-Nodes und macOS-Artist-Workstations, sodass ein Artist, der einen Shot begutachtet, aus derselben Pfadstruktur zieht, gegen die die Farm gerendert hat.

Fazit

Cloud-Speicher als Laufwerk zu mounten lässt eine Render-Farm einen Google-Cloud-Storage-Bucket wie gewöhnliche lokale Pfade behandeln, wobei Read-only-Mounts Quell-Assets schützen und Hintergrund-Uploads verhindern, dass die Frame-Ausgabe den nächsten Render blockiert. Zum grundlegenden Setup siehe Google Cloud Storage unter Windows mit NetDrive mounten oder Google Cloud Storage unter macOS mit NetDrive mounten. Studios, die CI-artige automatisierte Render-Pipelines betreiben, finden möglicherweise auch S3-Testfixtures für CI-Teams nützlich für das Boot-Zeit-Mount-Muster, auf das unbeaufsichtigte Nodes angewiesen sind.

— Morgan, NetDrive