In diesem Dokument erfahren Sie, wie Sie Ihre vorhandene lokale Renderingfarm für die Verwendung von Rechenressourcen in Google Cloud erweitern. Dabei wird davon ausgegangen, dass Sie bereits eine Renderingfarm lokal implementiert haben und mit den grundlegenden Konzepten von Pipelines für visuelle Effekte (VFX) und Animation, Warteschlangen-Verwaltungssoftware und gängigen Methoden zur Softwarelizenzierung vertraut sind.
Überblick
Das Rendering von 2D- oder 3D-Elementen für Animation, Film, Werbespots und Videospiele ist sowohl rechenintensiv als auch zeitaufwendig. Neben erheblichen Investitionen in Hardware und Infrastruktur erfordert das Rendering dieser Elemente ein dediziertes Team von IT-Experten zur Bereitstellung und Wartung von Hard- und Software.
Wenn eine lokale Renderingfarm zu 100 % ausgelastet ist, kann die Verwaltung von Jobs zur Herausforderung werden. Die Prioritäten und Abhängigkeiten von Aufgaben, der Neustart von verworfenen Frames sowie die Auslastung von Netzwerk, Laufwerk und CPU sind alle Teil des komplexen Systems, das Sie engmaschig überwachen und steuern müssen – oft unter höchstem Zeitdruck.
Zur Verwaltung dieser Jobs sind VFX-Einrichtungen dazu übergegangen, Warteschlangen-Verwaltungssoftware in ihre Pipelines zu integrieren. Diese Software kann Folgendes übernehmen:
- Jobs in lokalen und cloudbasierten Ressourcen bereitstellen
- Abhängigkeiten zwischen Jobs verwalten
- Mit Asset-Verwaltungssystemen kommunizieren
- Nutzern eine Oberfläche und APIs für gängige Sprachen wie Python bereitstellen
Auch wenn manche Warteschlangen-Verwaltungssoftware in der Lage ist, Jobs für cloudbasierte Worker bereitzustellen, müssen Sie trotzdem noch die Verbindung zur Cloud herstellen, Assets synchronisieren, ein Speicher-Framework auswählen, Image-Vorlagen verwalten und Ihre eigene Softwarelizenzierung zur Verfügung stellen.
Für die Erstellung und Verwaltung von Rendering-Pipelines und ‑Workflows in einer Cloud- oder Hybrid-Cloud-Umgebung stehen die folgenden Optionen zur Verfügung:
- Wenn Sie noch keine On-Premises- oder Cloud-Ressourcen haben, können Sie einen cloudbasierten Rendering-Dienst wie Conductor verwenden.
- Wenn Sie Ihre eigene Infrastruktur verwalten möchten, können Sie die in diesem Dokument beschriebenen Cloudressourcen erstellen und bereitstellen.
- Wenn Sie einen benutzerdefinierten Workflow erstellen möchten, der Ihren spezifischen Anforderungen entspricht, können Sie mit Google Cloud-Dienstintegratoren zusammenarbeiten, wie Gunpowder oder Qodea. Bei dieser Option werden alle Cloud-Dienste in Ihrer eigenen sicheren Google Cloud-Umgebung ausgeführt.
Wenden Sie sich an Ihren Google Cloud-Ansprechpartner, um die beste Lösung für Ihre Einrichtung zu finden.
Hinweis: Dieses Dokument enthält immer wieder Produktionshinweise. Dabei handelt es sich um Best Practices, die Ihnen beim Erstellen Ihrer Renderingfarm als Orientierungshilfe dienen sollen.
Verbindung zur Cloud herstellen
Entscheiden Sie je nach Arbeitslast, wie Ihre Einrichtung eine Verbindung zu Google Cloud herstellen soll: über einen Partner-Internetanbieter, eine direkte Verbindung oder über das öffentliche Internet.
Zugriff über das Internet
Wenn Sie keine spezielle Verbindung haben, können Sie einfach über das Internet auf die Google Cloud-Dienste zugreifen. So können Sie eine Verbindung mit dem Netzwerk von Google herstellen und unser End-to-End-Sicherheitsmodell verwenden. Dienstprogramme wie die Google Cloud CLI und Ressourcen wie die Compute Engine API verwenden sichere Authentifizierungs-, Autorisierungs- und Verschlüsselungsmethoden, um Ihre Daten vor Missbrauch zu schützen.
Cloud VPN
Unabhängig von der Art Ihrer Verbindung empfehlen wir Ihnen, diese über ein virtuelles privates Netzwerk (VPN) zu sichern.
Mit Cloud VPN können Sie Ihr lokales Netzwerk über eine IPsec-VPN-Verbindung sicher an Ihr VPC-Netzwerk (Virtual Private Cloud) von Google anbinden. Die übertragenen Daten werden dann verschlüsselt, bevor sie einen oder mehrere VPN-Tunnel durchlaufen.
Wie Sie für Ihr Projekt ein VPN erstellen, erfahren Sie hier.
Vom Kunden bereitgestelltes VPN
Obwohl Sie auch ein eigenes VPN-Gateway zur direkten Verbindung mit Google einrichten können, empfehlen wir, Cloud VPN zu verwenden. Dadurch erhalten Sie mehr Flexibilität und eine bessere Einbindung in Google Cloud.
Cloud Interconnect
Google unterstützt mehrere Methoden zum Verbinden Ihrer Infrastruktur mit Google Cloud. Diese unter dem Sammelbegriff Cloud Interconnect bekannten Verbindungen sind auf Unternehmen ausgerichtet und bieten eine höhere Verfügbarkeit und geringere Latenz als standardmäßige Internetverbindungen. Außerdem sind die Kosten für ausgehenden Traffic niedriger.
Mit Cross-Cloud Interconnect können Sie eine dedizierte Verbindung mit hoher Bandbreite zu Google Cloud für Ihre Daten in einer anderen Cloud herstellen. Dadurch wird die Netzwerkkomplexität reduziert, die Kosten für die Datenübertragung gesenkt und Multi-Cloud-Renderingfarmen mit hohem Durchsatz ermöglicht.
Dedicated Interconnect
Dedicated Interconnect stellt direkte physische Verbindungen und RFC-1918-Kommunikation zwischen Ihrem lokalen Netzwerk und dem Netzwerk von Google bereit. Sie erhalten Verbindungskapazität für die folgenden Verbindungstypen:
- Eine oder mehrere 10-Gbit/s-Ethernet-Verbindungen mit maximal acht Verbindungen bzw. insgesamt 80 Gbit/s pro Interconnect-Verbindung
- Eine oder mehrere 100-Gbit/s-Ethernet-Verbindungen mit maximal zwei Verbindungen bzw. insgesamt 200 Gbit/s pro Interconnect-Verbindung
Dedicated Interconnect-Traffic wird nicht verschlüsselt. Wenn Sie Daten über eine Dedicated Interconnect-Verbindung sicher übertragen möchten, müssen Sie Ihre eigene VPN-Verbindung einrichten. Cloud VPN ist nicht mit Dedicated Interconnect kompatibel, sodass Sie in diesem Fall Ihr eigenes VPN bereitstellen müssen.
Partner Interconnect
Partner Interconnect stellt die Verbindung zwischen Ihrem lokalen Netzwerk und Ihrem VPC-Netzwerk über einen unterstützten Dienstanbieter her. Eine Partner Interconnect-Verbindung ist nützlich, wenn sich Ihre Infrastruktur an einem Standort befindet, von dem aus keine Colocations-Einrichtung für Dedicated Interconnect erreichbar ist, oder wenn Sie für Ihr Datenvolumen nicht 10-Gbit/s benötigen.
Andere Verbindungsarten
Vielleicht sind an Ihrem Standort andere Möglichkeiten zur Verbindungsherstellung mit Google verfügbar. Wenden Sie sich an Ihren Google Cloud-Ansprechpartner, um die beste und kostengünstigste Verbindung zu Google Cloud zu finden.
Inhalt sichern
Damit Rechteinhaber wie große Hollywood-Studios ihre Inhalte auf jeder öffentlichen Cloudplattform ausführen können, müssen die von ihnen genutzten Anbieter Best Practices für die Sicherheit einhalten, die sowohl intern als auch von Organisationen wie der MPAA definiert sind. Google Cloud bietet Zero-Trust-Sicherheitsmodelle, die in Produkten wie Google Workspace, Chrome Enterprise Premium und BeyondProd integriert sind.
Jedes Studio hat unterschiedliche Anforderungen an die Sicherung von Renderingarbeitslasten. Auf cloud.google.com/security stehen außerdem Whitepaper zur Sicherheit und Compliancedokumente zur Verfügung.
Wenn Sie Fragen zum Auditprozess für die Sicherheitscompliance haben, wenden Sie sich an Ihren Google Cloud-Ansprechpartner.
Projekte organisieren
Projekte sind ein zentrales Organisationselement von Google Cloud. In Ihrer Einrichtung können Sie Jobs unter einem eigenen Projekt organisieren oder auf mehrere Projekte aufteilen. Denkbar wäre beispielsweise, getrennte Projekte für die Phasen der Prävisualisierung, der Recherche und Entwicklung und der Produktion eines Films zu erstellen.
Projekte bilden eine isolierende Grenze sowohl für Netzwerkdaten als auch für die Projektverwaltung. Allerdings können Sie Netzwerke über eine freigegebene VPC für mehrere Projekte freigeben, sodass separate Projekte auf gemeinsame Ressourcen zugreifen können.
Produktionshinweise: Erstellen Sie ein Hostprojekt für eine freigegebene VPC mit Ressourcen, die alle Ihre Produktionstools enthalten. Dann können Sie alle Projekte, die unter Ihrer Organisation erstellt werden, als Dienstprojekte der freigegebenen VPC angeben. Durch diese Angabe kann jedes Projekt in Ihrer Organisation auf dieselben Bibliotheken, Skripts und Softwareprogramme zugreifen, die im Hostprojekt bereitgestellt sind.
Organisationsressource
Sie können Projekte unter einer Organisationsressource verwalten, die Sie vielleicht bereits eingerichtet haben. Die Migration aller Projekte in eine Organisation bietet eine Reihe von Vorteilen.
Produktionshinweise: Geben Sie Produktionsmanager jeweils als Inhaber ihrer eigenen Projekte an und Studiomanager als Inhaber der Organisationsressource.
Zugriff auf Ressourcen festlegen
Projekte erfordern sicheren Zugriff auf Ressourcen. Außerdem müssen Sie mithilfe von Beschränkungen vorgeben, wo Nutzer oder Dienste Vorgänge ausführen dürfen. Zur Definition des Zugriffs bietet Google Cloud Identity and Access Management (IAM) an, womit Sie die Zugriffssteuerung verwalten können, indem Sie festlegen, welche Rollen über welche Art von Zugriff auf welche Ressourcen verfügen.
Produktionshinweise: Damit Nutzer gemäß ihrer Rolle nur auf die Ressourcen zugreifen können, die sie zur Ausführung bestimmter Aufgaben benötigen, sollten Sie sowohl in Ihrer lokalen Umgebung als auch in der Cloud nach dem Prinzip der geringsten Berechtigung vorgehen.
Nehmen wir als Beispiel einen Render-Worker. Dies ist eine virtuelle Maschine (VM), in der Ihr benutzerdefiniertes Image verwendet wird und die Sie auf Basis einer vordefinierten Instanzvorlage bereitstellen können. Der unter einem Dienstkonto ausgeführte Render-Worker kann aus Cloud Storage lesen und in ein verbundenes Speicherlaufwerk wie einen Cloud-Filer oder nichtflüchtigen Speicher schreiben. Die einzelnen Künstler brauchen Sie Google Cloud-Projekten jedoch gar nicht hinzuzufügen, da diese keinen direkten Zugriff auf Cloud-Ressourcen benötigen.
Stattdessen können Sie Render-Wranglern oder Projektadministratoren Rollen mit Zugriff auf alle Compute Engine-Ressourcen zuweisen, damit diese Vorgänge für Ressourcen ausführen können, die anderen Nutzern nicht zugänglich sind.
Legen Sie in einer Richtlinie fest, welche Rollen auf welche Ressourcentypen in Ihrer Organisation zugreifen können. Die folgende Tabelle zeigt eine typische Zuordnung zwischen Produktionsaufgaben und IAM-Rollen in Google Cloud.
| Produktionsaufgabe | Rollenname | Ressourcentyp |
|---|---|---|
| Studiomanager | resourcemanager.organizationAdmin |
Organisation Projekt |
| Produktionsmanager | owner, editor |
Projekt |
| Render-Wrangler | compute.admin, iam.serviceAccountActor |
Projekt |
| Warteschlangen-Verwaltungskonto | compute.admin, iam.serviceAccountActor |
Organisation Projekt |
| Einzelner Künstler | [Kein Zugriff] | Nicht zutreffend |
Zugriffsbereiche
Zugriffsbereiche bieten eine Möglichkeit, die Berechtigungen einer laufenden Instanz unabhängig von angemeldeten Personen zu steuern. Sie können Bereiche angeben, wenn Sie eine Instanz selbst erstellen oder wenn die Warteschlangen-Verwaltungssoftware Ressourcen auf Basis einer Instanzvorlage bereitstellt.
Bereiche haben Vorrang vor den IAM-Berechtigungen einzelner Nutzer oder Dienstkonten. Sie können also mithilfe eines Zugriffsbereichs verhindern, dass sich ein Projektadministrator bei einer Instanz anmeldet, um einen Storage-Bucket zu löschen oder eine Firewalleinstellung zu ändern.
Produktionshinweise: Instanzen können standardmäßig Daten aus Cloud Storage lesen, jedoch nicht in diesen schreiben. Wenn Ihre Rendering-Pipeline abgeschlossene Renderings in Cloud Storage schreiben soll, müssen Sie der Instanz bei ihrer Erstellung den Bereich devstorage.read_write hinzufügen.
Bereitstellungsmethode für Ressourcen auswählen
Beim Rendering in der Cloud können Sie Ressourcen nur nutzen, wenn Sie sie gerade benötigen. Allerdings stehen Ihnen verschiedene Methoden zur Wahl, um Ressourcen für Ihre Renderingfarm verfügbar zu machen.
On-Demand-Bereitstellung
Wenn Sie Ressourcen optimal nutzen möchten, stellen Sie Render-Worker nur dann bereit, wenn Jobs an die Renderingfarm gesendet werden. Sie können viele VMs erstellen, die von allen Frames in einem Job gemeinsam genutzt werden, oder sogar eine eigene VM für jeden Frame.
Das Warteschlangen-Verwaltungssystem kann laufende Instanzen überwachen und wieder in die Warteschlange stellen, wenn eine VM präemptiv beendet wurde, oder nach dem Abschluss einzelner Aufgaben beenden.
Ressourcenpool bereitstellen
Sie können auch unabhängig von bestimmten Jobs eine Gruppe von Instanzen bereitstellen, auf die Ihr lokales Warteschlangen-Verwaltungssystem als zusätzliche Ressourcen zugreifen kann. Wenn Sie Spot-VMs von Google Cloud verwenden, kann eine Gruppe von laufenden Instanzen mehrere Jobs pro VM annehmen und dabei alle Kerne nutzen und die Ressourcenauslastung maximieren. Dieser Ansatz lässt sich vielleicht am einfachsten implementieren, da er die Methode nachbildet, mit der Jobs an eine lokale Renderingfarm übergeben werden.
Software lizenzieren
Die Lizenzierung von Drittanbieter-Software kann von Paket zu Paket stark variieren. Im Folgenden sind einige Lizenzierungsschemas und -modelle aufgeführt, die Sie in einer VFX-Pipeline antreffen könnten. Für jedes Schema wird in der dritten Spalte die empfohlene Lizenzierungsmethode angegeben.
| Schema | Beschreibung | Empfehlung |
|---|---|---|
| Knoten gesperrt | Lizenz für eine bestimmte MAC-Adresse, IP-Adresse oder CPU-ID. Kann nur von einem einzigen Prozess ausgeführt werden. | Instanzbasiert |
| Knotenbasiert | Lizenz für einen bestimmten Knoten (eine bestimmte Instanz). Auf einem lizenzierten Knoten kann eine beliebige Anzahl von Nutzern oder Prozessen ausgeführt werden. | Instanzbasiert |
| Floating | Lizenz wird von einem Lizenzserver ausgecheckt, der die Nutzung verfolgt. | Lizenzserver |
| Softwarelizenzierung | ||
| Interaktiv | Erlaubt Nutzern, Software interaktiv in einer grafikbasierten Umgebung auszuführen. | Lizenzserver oder instanzbasiert |
| Batch | Erlaubt Nutzern lediglich, Software in einer Befehlszeilenumgebung auszuführen. | Lizenzserver |
| Cloudbasierte Lizenzierung | ||
| Nutzungsbasiert | Lizenz wird nur ausgecheckt, wenn ein Prozess auf einer Cloudinstanz ausgeführt wird. Bei Abschluss oder Beendigung des Prozesses wird die Lizenz freigegeben. | Cloudbasierter Lizenzserver |
| Betriebszeitbasiert | Lizenz wird ausgecheckt, wenn eine Instanz aktiviert ist und ausgeführt wird. Bei Beendigung oder Löschung der Instanz wird die Lizenz freigegeben. | Cloudbasierter Lizenzserver |
Instanzbasierte Lizenzierung verwenden
Manche Softwareprogramme oder Plug-ins sind direkt für die Hardware lizenziert, auf der sie ausgeführt werden. Diese Methode der Lizenzierung kann in der Cloud ein Problem darstellen, wo Hardwarekennungen wie MAC- oder IP-Adressen dynamisch zugewiesen werden.
MAC-Adressen
Wenn Instanzen erstellt werden, wird ihnen eine MAC-Adresse zugewiesen. Diese bleibt erhalten, bis die Instanz gelöscht wird. Sie können eine Instanz beenden oder neu starten, ohne dass die MAC-Adresse verloren geht. Diese MAC-Adresse lässt sich zum Erstellen und Validieren von Lizenzen verwenden, bis die Instanz gelöscht wird.
Statische IP-Adresse zuweisen
Wenn Sie eine Instanz erstellen, wird ihr eine interne und optional eine externe IP-Adresse zugewiesen. Damit die externe IP-Adresse einer Instanz erhalten bleibt, können Sie eine statische IP-Adresse reservieren und Ihrer Instanz zuweisen. Die IP-Adresse ist dann nur für diese Instanz reserviert. Da statische IP-Adressen eine projektbasierte Ressource sind, gelten dafür regionale Kontingente.
Sie können beim Erstellen einer Instanz auch eine interne IP-Adresse zuweisen. Dies ist hilfreich, wenn die internen IP-Adressen einer Gruppe von Instanzen in denselben Bereich fallen sollen.
Hardware-Dongles
Ältere Software kann noch über einen Dongle lizenziert sein. Dabei handelt es sich um einen Hardwareschlüssel, der mit einer Produktlizenz programmiert ist. Die meisten Softwareunternehmen verwenden keine Hardware-Dongles mehr, allerdings können einige Nutzer noch mit Legacy-Software arbeiten, die mit einem dieser Geräte verbunden ist. Wenn Sie auf dieses Problem stoßen, fragen Sie den Softwarehersteller, ob er Ihnen eine aktualisierte Lizenz für die jeweilige Software zur Verfügung stellen kann.
Sollte der Softwarehersteller nicht in der Lage sein, eine solche Lizenz zur Verfügung zu stellen, könnten Sie eine mit dem Netzwerk verbundene USB-Hub- oder USB-Over-IP-Lösung implementieren.
Lizenzserver verwenden
Die meisten modernen Softwareprogramme bieten Floating-Lizenzen als Option. Diese Option ist für eine Cloudumgebung am sinnvollsten, erfordert jedoch eine strengere Lizenzverwaltung und Zugriffssteuerung, um eine übermäßige Verwendung einer begrenzten Anzahl von Lizenzen zu verhindern.
Damit Sie Ihr Lizenzkontingent nicht überschreiten, können Sie im Rahmen des Warteschlangenprozesses für Jobs steuern, welche Lizenzen zu verwenden sind und wie viele Jobs Lizenzen verwenden.
Lokaler Lizenzserver
Sie können Ihren vorhandenen lokalen Lizenzserver verwenden, um Lizenzen an Instanzen zu vergeben, die in der Cloud ausgeführt werden. Wenn Sie sich für diese Methode entscheiden, müssen Sie Ihren Render-Workern die Kommunikation mit Ihrem lokalen Netzwerk ermöglichen, entweder über ein VPN oder eine andere sichere Verbindung.
Cloudbasierter Lizenzserver
Über eine freigegebene VPC können Sie in der Cloud einen Lizenzserver ausführen, der Instanzen in Ihrem Projekt oder sogar projektübergreifend bedient. Floating-Lizenzen sind manchmal mit einer Hardware-MAC-Adresse verknüpft, sodass eine kleine, lang laufende Instanz mit einer statischen IP-Adresse leicht Lizenzen an viele Renderinginstanzen vergeben kann.
Hybrider Lizenzserver
Manche Softwareprogramme können mehrere Lizenzserver in priorisierter Reihenfolge verwenden. So könnte ein Renderer beispielsweise die Anzahl der Lizenzen abfragen, die auf einem lokalen Server verfügbar sind, und auf einen cloudbasierten Lizenzserver zurückgreifen, wenn lokal keine Lizenzen mehr zur Verfügung stehen. Mit dieser Strategie lässt sich die Verwendung permanenter Lizenzen maximieren, bevor andere Lizenztypen ausgecheckt werden.
Produktionshinweise: Definieren Sie einen oder mehrere Lizenzserver in einer Umgebungsvariablen und legen Sie die Prioritätsrangfolge fest. Der beliebte Renderer Autodesk Arnold kann Sie bei dieser Aufgabe unterstützen. Wenn ein Job über den ersten Server keine Lizenz abrufen kann, versucht er es bei einem der anderen aufgeführten Server. Beispiel:
export solidangle_LICENSE=5053@x.x.0.1;5053@x.x.0.2
Im vorherigen Beispiel versucht der Arnold-Renderer, eine Lizenz vom Server unter x.x.0.1 (Port 5053) abzurufen. Wenn dieser Versuch fehlschlägt, wird versucht, eine Lizenz vom selben Port unter der IP-Adresse x.x.0.2 abzurufen.
Cloudbasierte Lizenzierung
Einige Anbieter stellen cloudbasierte Lizenzierung mit On-Demand-Softwarelizenzen für Ihre Instanzen zur Verfügung. Cloudbasierte Lizenzierung wird allgemein auf zwei Arten abgerechnet: nutzungsbasiert und betriebszeitbasiert.
Nutzungsbasierte Lizenzierung
Bei der nutzungsbasierten Lizenzierung erfolgt die Abrechnung nach der Zeit, während der die Software in Verwendung ist. Bei dieser Art der Lizenzierung wird eine Lizenz normalerweise beim Start eines Prozesses von einem cloudbasierten Server ausgecheckt und wieder freigegeben, wenn der Prozess abgeschlossen ist. Solang eine Lizenz ausgecheckt ist, wird Ihnen deren Nutzung in Rechnung gestellt. Diese Art der Lizenzierung wird üblicherweise für Renderingsoftware verwendet.
Betriebszeitbasierte Lizenzierung
Betriebszeitbasierte oder getaktete Lizenzen werden nach der Betriebszeit Ihrer Compute Engine-Instanz abgerechnet. Die Instanz ist so konfiguriert, dass sie sich während des Startprozesses beim cloudbasierten Lizenzserver registriert. Solang die Instanz ausgeführt wird, bleibt die Lizenz ausgecheckt. Bei Beendigung oder Löschung der Instanz wird die Lizenz freigegeben. Diese Art der Lizenzierung wird üblicherweise für Render-Worker verwendet, die ein Warteschlangenmanager bereitstellt.
Art der Datenspeicherung auswählen
Welche Art der Speicherung Sie auf Google Cloud auswählen, hängt von der verwendeten Speicherstrategie und von Faktoren wie Langlebigkeitsanforderungen und Kosten ab.
Nichtflüchtiger Speicher
Wenn Sie nichtflüchtigen Speicher in Ihre Arbeitslast integrieren, sparen Sie sich unter Umständen die Implementierung eines Dateiservers. Ein nichtflüchtiger Speicher ist eine Art POSIX-konformer Blockspeicher mit bis zu 64 TB, der den meisten VFX-Einrichtungen ein Begriff ist. Nichtflüchtiger Speicher ist in Form von Standardlaufwerken und SSDs (Solid-State Drives) verfügbar. Sie können nichtflüchtigen Speicher einer einzelnen Instanz im Lese-/Schreibmodus oder einer großen Anzahl von Instanzen wie einer Gruppe von Render-Workern im Lesemodus hinzufügen.
| Vorteile | Nachteile | Idealer Anwendungsfall |
|---|---|---|
| Wird als Standard-NFS- oder SMB-Volume bereitgestellt. Kann die Größe dynamisch ändern Bis zu 128 nichtflüchtige Speicher können einer einzigen Instanz hinzugefügt werden. Derselbe nichtflüchtige Speicher kann auf Hunderten oder Tausenden von Instanzen im Lesemodus bereitgestellt werden. |
Maximale Größe von 64 TB. In den nichtflüchtigen Speicher kann nur geschrieben werden, wenn er einer einzigen Instanz hinzugefügt wurde. Nur Ressourcen, die sich in derselben Region befinden, können auf den nichtflüchtigen Speicher zugreifen. |
Erweiterte Pipelines, die ein neues Laufwerk pro Job erstellen können. Pipelines, die Render-Workern selten aktualisierte Daten wie Software oder gängige Bibliotheken bereitstellen |
Objektspeicher
Cloud Storage ist ein äußerst langlebiger Speicher mit hoher Redundanz, der im Gegensatz zu herkömmlichen Dateisystemen unstrukturiert ist und praktisch unbegrenzte Speicherkapazität bietet. Dateien werden in Cloud Storage in Buckets gespeichert, die Ordnern gleichkommen und weltweit zugänglich sind.
Objektspeicher kann nicht wie ein herkömmlicher Speicher von einem Betriebssystem als logisches Volume bereitgestellt werden. Wenn Sie Objektspeicher in Ihre Rendering-Pipeline einbinden möchten, müssen Sie Ihre Methode zum Lesen und Schreiben von Daten anpassen, entweder über Befehlszeilen-Dienstprogramme wie die gcloud CLI oder über die Cloud Storage API.
| Vorteile | Nachteile | Idealer Anwendungsfall |
|---|---|---|
| Langlebiger, hochverfügbarer Speicher für Dateien beliebiger Größe Eine API für alle Speicherklassen Kostengünstig Daten stehen weltweit zur Verfügung. Praktisch unbegrenzte Kapazität |
Nicht POSIX-konform Zugriff muss über die API oder ein Befehlszeilen-Dienstprogramm erfolgen. In einer Rendering-Pipeline müssen Daten vor ihrer Verwendung zuerst lokal übertragen werden. |
Rendering-Pipelines mit einem Asset-Verwaltungssystem, das Daten in Cloud Storage veröffentlichen kann. Rendering-Pipelines mit einem Warteschlangen-Verwaltungssystem, das Daten vor dem Rendering aus Cloud Storage abrufen kann |
Weitere Speicherprodukte
Weitere Speicherprodukte stehen als verwaltete Dienste zur Verfügung, über Drittanbieter-Kanäle wie Cloud Marketplace oder als Open-Source-Projekte über Software-Repositories oder GitHub.
| Produkt | Vorteile | Nachteile | Idealer Anwendungsfall |
|---|---|---|---|
| Filestore | Geclustertes Dateisystem, das Tausende von gleichzeitigen NFS-Verbindungen unterstützen kann. Kann mit einem lokalen NAS-Cluster synchronisiert werden |
Dateien lassen sich nicht selektiv synchronisieren. Keine bidirektionale Synchronisierung. | Mittlere bis große VFX-Einrichtungen mit Hunderten von TB an Daten, die in der Cloud dargestellt werden müssen. |
| Pixit Media, PixStor | Dateisystem mit horizontaler Skalierung, das Tausende von gleichzeitigen NFS- oder POSIX-Clients unterstützen kann. Daten lassen sich on demand aus dem lokalen NAS in den Cache schreiben, wobei Updates automatisch an den lokalen Speicher zurückgesendet werden. | Kosten, Drittanbieter-Support von Pixit | Mittlere bis große VFX-Einrichtungen mit Hunderten von TB an Daten, die in der Cloud dargestellt werden müssen. |
| Google Cloud NetApp Volumes | Vollständig verwaltete Speicherlösung in Google Cloud Unterstützt NFS-, SMB- und Multi-Protokoll-Umgebungen Snapshots zu einem bestimmten Zeitpunkt mit Instanzwiederherstellung |
Nicht in allen Google Cloud-Regionen verfügbar. | VFX-Einrichtungen mit einer Pipeline, die Asset-Synchronisierung ermöglicht. Für mehrere virtuelle Workstations freigegebenes Laufwerk |
| Cloud Storage FUSE | Stellt Cloud Storage-Buckets als Dateisysteme bereit. Geringe Kosten | Kein POSIX-konformes Dateisystem; kann schwierig zu konfigurieren und zu optimieren sein. | VFX-Einrichtungen, die ein Open-Source-Dateisystem bereitstellen, konfigurieren und verwalten können und eine Pipeline haben, die Asset-Synchronisierung ermöglicht. |
In Google Cloud stehen noch andere Speichertypen zur Verfügung. Weitere Informationen erhalten Sie von dem für Sie zuständigen Google Cloud-Mitarbeiter.
Weitere Informationen zu Datenspeicheroptionen
- In Google Cloud verfügbare Speicheroptionen
- Dateispeicher in der Compute Engine
- Optimale Speicherstrategie für eine Cloud-Arbeitslast entwickeln
Speicherstrategien implementieren
Wenn Sie Konventionen zur Handhabung Ihrer Daten einrichten, können Sie mehrere Speicherstrategien in Pipelines für die VFX- oder Animationsproduktion implementieren. Diese Konventionen legen fest, ob der Datenzugriff direkt auf Ihrem lokalen Speicher erfolgt oder Daten zwischen dem lokalen Speicher und der Cloud synchronisiert werden.
Strategie 1: Lokalen Speicher direkt bereitstellen
Wenn Ihre Einrichtung eine Verbindung mit mindestens zehn Gbit/s zu Google Cloud hat und sich in der Nähe einer Google Cloud-Region befindet, können Sie Ihren lokalen NAS direkt auf Render-Workern in der Cloud bereitstellen. Diese Strategie ist zwar einfach umzusetzen, aber möglicherweise auch kosten- und bandbreitenintensiv, da der gesamte Inhalt, der in der Cloud erzeugt und in den Speicher zurückgeschrieben wird, als ausgehender Traffic zählt.
| Vorteile | Nachteile | Idealer Anwendungsfall |
|---|---|---|
| Einfache Implementierung Lese-/Schreibzugriff auf gemeinsamen Speicher Daten stehen sofort zur Verfügung. Kein Caching bzw. keine Synchronisierung erforderlich. |
Kann teurer als andere Optionen sein. Ein Google-Rechenzentrum muss sich in der Nähe befinden, um die Latenz niedrig zu halten. Wie viele Instanzen Sie maximal mit Ihrem lokalen NAS verbinden können, hängt von Ihrer Bandbreite und Ihrem Verbindungstyp ab. |
Einrichtungen in der Nähe eines Google-Rechenzentrums, in denen Renderingarbeitslasten im Burst-Modus in die Cloud übertragen werden müssen und Kosten keine Rolle spielen. Einrichtungen mit einer Verbindung von mindestens zehn Gbit/s zu Google Cloud |
Strategie 2: On-Demand-Synchronisierung
Sie können wählen, Daten nur dann per Push in die Cloud zu übertragen oder per Pull aus dem lokalen Speicher abzurufen (oder umgekehrt), wenn Sie sie benötigen, beispielsweise wenn ein Frame gerendert oder ein Asset veröffentlicht wird. Bei Verwendung dieser Strategie kann die Synchronisierung durch einen Mechanismus in Ihrer Pipeline ausgelöst werden, wie etwa durch ein Watch-Skript, einen Event-Handler wie Pub/Sub oder eine Reihe von Befehlen in einem Jobskript.
Die Synchronisierung kann mit einer Vielzahl von Befehlen wie dem gcloud-Befehl scp, dem gcloud CLI-Befehl rsync oder UDP-basierten Datenübertragungsprotokollen (UDT) erfolgen. Wenn Sie ein Drittanbieter-UDT wie Aspera, Cloud FastPath, BitSpeed oder FDT zur Kommunikation mit einem Cloud Storage-Bucket verwenden, finden Sie Informationen zum Sicherheitsmodell und zu den Best Practices des Drittanbieters in der zugehörigen Dokumentation. Diese Drittanbieter-Dienste werden nicht von Google verwaltet.
Push-Methode
Die Push-Methode wird normalerweise verwendet, um ein Asset zu veröffentlichen, eine Datei in einem Watch-Ordner abzulegen oder einen Renderingjob abzuschließen und dann per Push in einen vordefinierten Speicherort zu übertragen.
Beispiele:
- Ein Render-Worker in der Cloud schließt einen Renderingjob ab und überträgt die resultierenden Frames wieder per Push in den lokalen Speicher.
- Ein Künstler veröffentlicht ein Asset. Im Rahmen dieser Asset-Veröffentlichung müssen die zugehörigen Daten per Push an einem vordefinierten Pfad in Cloud Storage abgelegt werden.
Pull-Methode
Sie verwenden die Pull-Methode, wenn eine Datei angefordert wird, in der Regel von einer cloudbasierten Renderinginstanz.
Beispiel: Bei Ausführung eines Skripts für einen Renderingjob werden alle Assets, die zum Rendern einer Szene benötigt werden, vor dem Rendering mit der Pull-Methode in ein Dateisystem übertragen, in dem alle Render-Worker darauf zugreifen können.
| Vorteile | Nachteile | Idealer Anwendungsfall |
|---|---|---|
| Volle Kontrolle darüber, welche Daten wann synchronisiert werden. Übertragungsmethode und -protokoll können ausgewählt werden. |
Ihre Produktions-Pipeline muss Event-Handling ermöglichen, um Push-/Pull-Synchronisierungen auszulösen. Möglicherweise werden zusätzliche Ressourcen zur Verwaltung der Synchronisierungswarteschlange benötigt. |
Kleine bis große Einrichtungen mit benutzerdefinierten Pipelines, die volle Kontrolle über die Asset-Synchronisierung wünschen. |
Produktionshinweise: Verwalten Sie die Datensynchronisierung mit demselben Warteschlangen-Verwaltungssystem, das Sie auch für Renderingjobs verwenden. Synchronisierungsaufgaben können getrennte Cloudressourcen nutzen, um die verfügbare Bandbreite zu maximieren und den Netzwerk-Traffic zu minimieren.
Strategie 3: Lokaler Speicher, cloudbasierter Lese-Cache
Google Cloud hat eine KNFSD-Caching-Lösung als Open-Source-Option erweitert und entwickelt. Die Lösung kann die Leistungsanforderungen der Renderfarm bewältigen, die über die Kapazität der Speicherinfrastruktur hinausgehen. Das KNFSD-Caching bietet ein hochleistungsfähiges Read-Through-Caching, mit dem sich Arbeitslasten auf Hunderte oder sogar Tausende von Rendering-Knoten in mehreren Regionen und Hybrid-Speicherpools skalieren lassen.
Das KNFSD-Caching ist eine Lösung zur horizontalen Skalierung, die die Auslastung des primären Dateifreigabedienstes reduziert. Das KNFSD-Caching reduziert auch den Überlastungseffekt, wenn viele Renderknoten gleichzeitig versuchen, Dateien vom Dateiserver abzurufen. Durch die Verwendung einer Caching-Ebene im selben VPC-Netzwerk wie die Renderknoten wird die Leselatenz reduziert, wodurch Renderjobs schneller gestartet und abgeschlossen werden. Je nach Ihren Konfigurationseinstellungen für den Caching-Dateiserver bleiben die Daten im Cache, bis:
- die Daten veraltet sind oder über einen bestimmten Zeitraum nicht verwendet wurden oder
- Speicherplatz auf dem Dateiserver benötigt wird. In diesem Fall werden Daten auf Basis ihres Alters aus dem Cache entfernt.
Diese Strategie verringert die benötigte Bandbreite und die Komplexität bei der Bereitstellung vieler gleichzeitiger Renderinginstanzen.
In manchen Fällen empfiehlt es sich, den Cache vorzuwärmen. Damit gewährleisten Sie, dass alle jobbezogenen Daten vor dem Rendering vorhanden sind. Zum Vorwärmen des Caches lesen Sie den Inhalt eines Verzeichnisses, das sich auf Ihrem Dateiserver in der Cloud befindet. Führen Sie zu diesem Zweck ein read oder stat für eine oder mehrere Dateien aus. Wenn Sie auf diese Weise auf Dateien zugreifen, wird der Synchronisierungsmechanismus ausgelöst.
Sie können auch eine physische lokale Appliance zur Kommunikation mit der virtuellen Appliance hinzufügen. NetApp bietet beispielsweise eine Speicherlösung, die die Latenz zwischen Ihrem lokalen Speicher und der Cloud weiter senken kann.
| Vorteile | Nachteile | Idealer Anwendungsfall |
|---|---|---|
| Im Cache gespeicherte Daten werden automatisch verwaltet. Reduziert den Bandbreitenbedarf Geclusterte Dateisysteme in der Cloud können je nach Jobanforderungen herauf- oder herunterskaliert werden. |
Kann zusätzliche Kosten verursachen. Wenn Sie den Cache vorwärmen möchten, müssen Aufgaben vor dem Job implementiert werden. |
Große Einrichtungen, die viele gleichzeitige Instanzen bereitstellen und gemeinsame Assets von vielen Jobs aus lesen. |
Daten filtern
Sie können eine Datenbank mit Asset-Typen und zugehörigen Bedingungen erstellen, um festzulegen, ob eine bestimmte Art von Daten synchronisiert werden soll. Manche Arten von Daten müssen vielleicht nie synchronisiert werden. Hierzu zählen zum Beispiel sitzungsspezifische Daten, die im Rahmen einer Konvertierung generiert werden, Cache-Dateien oder Simulationsdaten. Überlegen Sie sich auch, ob Sie nicht genehmigte Assets synchronisieren möchten, da nicht alle Iterationen in den finalen Renderings verwendet werden.
Erste Bulk-Übertragung ausführen
Bei der Implementierung Ihrer hybriden Renderingfarm können Sie eine erste Übertragung Ihres gesamten Datasets oder Teile davon in Cloud Storage, dem nichtflüchtigen Speicher oder einem anderen cloudbasierten Speicher ausführen. Je nach Faktoren wie der Menge und Art der zu übertragenden Daten und Ihrer Verbindungsgeschwindigkeit ist eine vollständige Synchronisierung unter Umständen nach ein paar Tagen oder Wochen abgeschlossen. In der folgenden Abbildung werden die Zeiten verglichen, die normalerweise für Online- und physische Übertragungen benötigt werden.
Wenn die Arbeitslast des Übertragungsvorgangs die festgelegten Zeit- oder Bandbreitenlimits überschreitet, können Sie auf eine Reihe von Übertragungsoptionen von Google wie Transfer Appliance zurückgreifen, um Ihre Daten in die Cloud zu verschieben.
Archivierung und Notfallwiederherstellung
Zwischen der Archivierung von Daten und der Notfallwiederherstellung ist zu unterscheiden. Erstere ist eine selektive Kopie einer abgeschlossenen Arbeit, während Letztere ein Datenzustand ist, der wiederhergestellt werden kann. Sie sollten einen Plan zur Notfallwiederherstellung entwickeln, der Ihre Anforderungen erfüllt und einen externen Alternativplan bereitstellt. Beraten Sie sich mit dem Anbieter Ihres lokalen Speichers, um den Plan zur Notfallwiederherstellung auf Ihre jeweilige Speicherplattform zuzuschneiden.
Daten in der Cloud archivieren
Wenn die Arbeit an einem Projekt abgeschlossen ist, wird das Ergebnis normalerweise in einem langfristigen Speicher abgelegt, wobei es sich meistens um Magnetbänder wie LTO handelt. Diese Kassetten müssen umweltrechtliche Anforderungen erfüllen und können mit der Zeit aus logistischer Sicht schwierig zu verwalten sein. Große Produktionseinrichtungen haben manchmal einen speziellen Raum, in dem ihr gesamtes Archiv untergebracht ist und ein Vollzeitarchivar die Daten betreut und bei Anforderung abruft.
Die Suche nach archivierten Assets, Aufnahmen oder Filmmaterialien kann viel Zeit verschlingen, da Daten auf mehreren Kassetten gespeichert sein können, eine Archivindexierung vielleicht fehlt oder unvollständig ist oder die Geschwindigkeit beim Auslesen der Daten vom Magnetband beschränkt ist.
Die Migration Ihres Datenarchivs in die Cloud kann nicht nur die lokale Verwaltung und Speicherung von Archivmedien überflüssig machen, sondern auch den Zugriff auf Ihre Daten und die Suche nach diesen wesentlich vereinfachen, was herkömmliche Archivierungsmethoden nicht bieten können.
Eine grundlegende Archivierungs-Pipeline könnte wie im folgenden Diagramm aussehen. Hier werden Archive mithilfe unterschiedlicher Clouddienste untersucht, kategorisiert, getaggt und organisiert. Sie können über die Cloud ein Tool zum Verwalten und Abrufen von Archiven erstellen, um anhand von verschiedenen Metadatenkriterien wie Datum, Projekt, Format oder Auflösung nach Daten zu suchen. Außerdem stehen Ihnen die Machine Learning APIs zur Verfügung, mit denen Sie Bilder und Videos taggen und kategorisieren können, um die Ergebnisse dann in einer cloudbasierten Datenbank wie BigQuery zu speichern.
Berücksichtigen Sie auch diese zusätzlichen Punkte:
- Automatisieren Sie die Erzeugung von Thumbnails oder Proxys für Inhalte, die sich in Cloud Storage-Speicherklassen befinden, für die Abrufgebühren anfallen. Verwenden Sie diese Proxys dann in Ihrem Verwaltungssystem für Medien-Assets, sodass Nutzer Daten suchen können und dabei nur die Proxys und nicht die archivierten Assets lesen.
- Ziehen Sie maschinelles Lernen in Betracht, um Inhalte von Realfilmen zu kategorisieren. Beschriften Sie Texturen und Hintergrundplatten mit Cloud Vision oder verwenden Sie die Video Intelligence API, um Referenzfilmmaterial leichter zu finden und abzurufen.
- Sie können auch ein Vertex AI AutoML-Image verwenden, um ein benutzerdefiniertes Bildmodell zu erstellen, um unterschiedliche Assets zu erkennen – sowohl Live-Aktion als auch gerendert.
- Überlegen Sie sich, ob Sie für gerenderte Inhalte das Laufwerk-Image des Render-Workers kopieren und zusammen mit dem gerenderten Asset speichern möchten. Wenn Sie die Einrichtung neu erstellen müssen, stehen Ihnen dann die korrekten Softwareversionen, Plug-ins, Betriebssystembibliotheken und Abhängigkeiten zur Verfügung, um eine archivierte Aufnahme noch einmal zu rendern.
Assets und Produktion verwalten
Die Arbeit am selben Projekt in mehreren Einrichtungen stellt eine besondere Herausforderung dar, insbesondere wenn Inhalt und Assets rund um die Welt verfügbar sein müssen. Die manuelle Synchronisierung von Daten in mehreren privaten Netzwerken kann teuer und ressourcenintensiv sein und unterliegt lokalen Bandbreitenbeschränkungen.
Wenn Ihre Arbeitslast voraussetzt, dass Daten global verfügbar sind, stellt die Verwendung von Cloud Storage eine Möglichkeit dar. Dieser Dienst ist an allen Standorten verfügbar, von denen aus Sie auf Google-Dienste zugreifen können. Damit Sie Cloud Storage in Ihre Pipeline einbinden können, müssen Sie diese so ändern, dass Objektpfade verarbeitet werden können. Dann übertragen Sie Ihre Daten per Pull oder Push an Ihre Render-Worker, bevor Sie mit dem Rendering beginnen. Diese Methode ermöglicht globalen Zugriff auf veröffentlichte Daten, setzt aber voraus, dass Ihre Pipeline Assets innerhalb eines angemessenen Zeitraums dorthin liefern kann, wo sie benötigt werden.
Ein Texture Artist in Los Angeles kann beispielsweise Bilddateien veröffentlichen, die ein Lighting Artist in London verwenden muss. Dieser Prozess sieht so aus:
- Die Veröffentlichungs-Pipeline überträgt Dateien per Push an Cloud Storage und fügt einer cloudbasierten Asset-Datenbank einen Eintrag hinzu.
- Ein Künstler in London führt ein Skript aus, um Assets für eine Szene abzurufen. Dazu werden Dateispeicherorte in der Datenbank abgefragt und Daten aus Cloud Storage in das lokale Laufwerk ausgelesen.
- Die Warteschlangen-Verwaltungssoftware listet die Assets auf, die für das Rendering benötigt werden, fragt diese aus der Asset-Datenbank ab und lädt sie aus Cloud Storage in den lokalen Speicher der einzelnen Render-Worker herunter.
Wenn Sie Cloud Storage auf diese Art verwenden, haben Sie gleichzeitig ein Archiv aller veröffentlichten Daten in der Cloud, sofern Sie Cloud Storage in Ihre Archivierungspipeline integrieren.
Datenbanken verwalten
Software für die Asset- und Produktionsverwaltung ist auf hochverfügbare, langlebige Datenbanken angewiesen, die auf Hosts bereitgestellt sind, die Hunderte oder Tausende von Abfragen pro Sekunde verarbeiten können. Datenbanken werden normalerweise auf einem lokalen Server gehostet, der im selben Rack wie Render-Worker ausgeführt wird, und unterliegen denselben Stromversorgungs-, Netzwerk- und HLK-Beschränkungen.
Überlegen Sie sich, ob Sie Ihre MySQL-, NoSQL- und PostgreSQL-Produktionsdatenbanken als verwaltete, cloudbasierte Dienste ausführen möchten. Diese Dienste sind hochverfügbar und global zugänglich, verschlüsseln Daten sowohl im inaktiven Zustand als auch bei der Übertragung und bieten eine integrierte Replikationsfunktion.
Warteschlangen verwalten
Kommerziell verfügbare Softwareprogramme zur Warteschlangenverwaltung wie Qube!, Deadline und Tractor sind in der VFX-/Animationsbranche weit verbreitet. Außerdem ist eine Reihe von Open-Source-Softwareoptionen verfügbar, z. B. OpenCue. Sie können mit dieser Software beliebige Rechenarbeitslasten auf einer Vielzahl von Workern bereitstellen und verwalten, nicht nur Renderings. Die Software ermöglicht die Bereitstellung und Verwaltung von Asset-Veröffentlichungen, Partikel- und Flüssigkeitssimulationen, Texture Baking und Compositing mit demselben Planungs-Framework, das Sie auch zum Verwalten von Renderings verwenden.
Einige Einrichtungen haben universelle Planungssoftware wie HTCondor von der Universität von Wisconsin, Slurm von SchedMD oder Univa Grid Engine in ihre VFX-Pipelines eingebunden. Allerdings wird in einer Software, die speziell für die VFX-Branche entwickelt wurde, ein besonderes Augenmerk auf Funktionen wie die folgenden gelegt:
- Abhängigkeit nach Job, Frame und Ebene: Manche Aufgaben müssen abgeschlossen sein, bevor Sie andere Jobs beginnen können. Führen Sie beispielsweise eine Flüssigkeitssimulation vollständig aus, bevor Sie mit dem Rendering beginnen.
- Jobpriorität, die es Render-Wranglern ermöglicht, die Reihenfolge von Jobs basierend auf individuellen Terminen und Zeitplänen zu ändern.
- Ressourcentypen, Labels oder Ziele, mit denen Sie Jobs bestimmte Ressourcen zuordnen können, die diese benötigen. So könnten GPU-beschleunigte Renderings nur auf VMs bereitgestellt werden, denen GPUs hinzugefügt wurden.
- Erfassung von Verlaufsdaten zur Ressourcennutzung und Bereitstellung dieser Daten über eine API oder ein Dashboard zur weiteren Analyse: Sie könnten sich beispielsweise die durchschnittliche CPU- und Arbeitsspeichernutzung für die letzten paar Iterationen eines Renderings ansehen, um die Ressourcennutzung für die nächste Iteration vorherzusagen.
- Preflight- und Postflight-Jobs: Ein Preflight-Job überträgt beispielsweise alle erforderlichen Assets per Pull in den lokalen Render-Worker, bevor das Rendering beginnt. Ein Postflight-Job kopiert den resultierenden gerenderten Frame an einen designierten Speicherort in einem Dateisystem und markiert den Frame dann in einem Asset-Verwaltungssystem als abgeschlossen.
- Integration in beliebte 2D- und 3D-Softwareanwendungen wie Maya, 3ds Max, Houdini, Cinema 4D oder Nuke.
Produktionshinweise: Mit Software zur Warteschlangenverwaltung kann ein Pool von cloudbasierten Ressourcen so erkannt werden, als würde es sich um lokale Render-Worker handeln. Diese Methode erfordert ein gewisses Maß an Überwachung, um die Ressourcennutzung zu maximieren und so viele Renderings auszuführen, wie die jeweilige Instanz bewältigen kann. Diese Technik wird Bin-Packing (effizientes Packen) genannt. Solche Vorgänge werden normalerweise algorithmisch und von Render-Wranglern bearbeitet.
Sie können auch die Erstellung, Verwaltung und Beendigung von cloudbasierten Ressourcen auf On-Demand-Basis automatisieren. Bei dieser Methode muss Ihr Warteschlangenmanager vor und nach dem Rendering Skripts ausführen, die Ressourcen bei Bedarf erstellen, während des Renderings überwachen und nach Abschluss von Aufgaben beenden.
Aspekte der Jobbereitstellung
Wenn Sie eine Renderingfarm implementieren, die sowohl lokalen als auch cloudbasierten Speicher verwendet, sollte Ihr Warteschlangenmanager folgende Punkte berücksichtigen:
- Die Lizenzierung von cloudbasierten und lokalen Bereitstellungen kann sich unterscheiden. Manche Lizenzen sind knotenbasiert, andere prozessabhängig. Achten Sie also darauf, dass Ihre Warteschlangen-Verwaltungssoftware die Jobs so bereitstellt, dass der Wert Ihrer Lizenzen voll ausgeschöpft wird.
- Fügen Sie cloudbasierten Ressourcen gegebenenfalls Tags oder Labels hinzu. So gewährleisten Sie, dass die Ressourcen nur dann verwendet werden, wenn sie bestimmten Jobtypen zugewiesen sind.
- Mit Cloud Logging können Sie nicht verwendete oder inaktive Instanzen identifizieren.
- Überlegen Sie sich beim Starten von abhängigen Jobs, wo die resultierenden Daten abgelegt werden und wo sie sich für den nächsten Schritt befinden müssen.
- Wenn sich Ihre Pfad-Namespaces für lokale und cloudbasierte Speicher unterscheiden, sollten Sie relative Pfade verwenden, damit Renderings vom Speicherort unabhängig sind. Alternativ können Sie je nach Plattform einen Mechanismus implementieren, der Pfade bei Beginn des Renderings austauscht.
- Manche Renderings, Simulationen oder nachgelagerte Prozesse sind auf die Erzeugung zufälliger Zahlen angewiesen, die bei verschiedenen CPU-Herstellern unterschiedlich sein können. Selbst CPUs vom selben Hersteller, die aus verschiedenen Chipgenerationen stammen, können unterschiedliche Ergebnisse liefern. Verwenden Sie im Zweifelsfall identische oder ähnliche CPU-Typen für alle Frames eines Jobs.
- Wenn Sie eine Lese-Cache-Appliance verwenden, sollten Sie die Bereitstellung eines Preflight-Jobs zum Vorwärmen des Caches in Betracht ziehen. So können Sie gewährleisten, dass alle Assets in der Cloud verfügbar sind, bevor Sie Cloud-Ressourcen bereitstellen. Mit dieser Methode wird die Zeit minimiert, die Render-Worker warten müssen, bis Assets in die Cloud verschoben wurden.
Logging und Monitoring
Die Aufzeichnung und das Monitoring der Ressourcennutzung und -leistung ist ein wesentlicher Aspekt jeder Renderingfarm. Daher stehen in Google Cloud verschiedene APIs, Tools und Lösungen zur Verfügung, die Ihnen einen Einblick in die Nutzung von Ressourcen und Diensten verschaffen.
Die Aktivität einer VM lässt sich am schnellsten anhand der Ausgabe ihres seriellen Ports überwachen. Diese Ausgabe kann hilfreich sein, wenn eine Instanz über typische Dienstkontrollebenen wie Ihrem Supervisor der Rendering-Warteschlangenverwaltung nicht mehr ansprechbar ist.
Weitere Möglichkeiten zum Erfassen und Überwachen der Ressourcennutzung in Google Cloud:
- Mit Cloud Logging können Sie Nutzungs- und Audit-Logs aufzeichnen und in Cloud Storage, BigQuery und andere Dienste exportieren.
- Mit Cloud Monitoring können Sie einen Agent zum Überwachen von Systemmesswerten auf Ihren VMs installieren.
- Binden Sie die Cloud Logging API in Ihre Pipeline-Skripts ein, um Logs mithilfe von Clientbibliotheken für gängige Skriptsprachen direkt in Cloud Logging zu schreiben.
- Mit Cloud Monitoring können Sie Diagramme erstellen, mit denen Sie die Ressourcennutzung nachvollziehen können.
Render-Worker-Instanzen konfigurieren
Damit Ihre Arbeitslast auch wirklich hybrid ist, müssen lokale und cloudbasierte Renderingknoten identisch sein und übereinstimmende Betriebssystemversionen, Kernel-Builds, Bibliotheksinstallationen und Software haben. Unter Umständen müssen Sie auch Bereitstellungspunkte, Pfad-Namespaces und sogar Nutzerumgebungen in der Cloud reproduzieren, da sich diese vor Ort befinden.
Laufwerkimage auswählen
Sie können eines der öffentlichen Images auswählen oder Ihr eigenes benutzerdefiniertes Image auf Basis des Images Ihres lokalen Renderingknotens erstellen. Öffentliche Images umfassen eine Reihe von Paketen, die Nutzerkonten einrichten und verwalten sowie die Authentifizierung auf Basis von SSH-Schlüsseln (Secure Shell) ermöglichen.
Benutzerdefiniertes Image erstellen
Wenn Sie ein benutzerdefiniertes Image erstellen, müssen Sie Linux und Windows mehr Bibliotheken hinzufügen, damit sie in der Compute Engine-Umgebung korrekt funktionieren.
Ihr benutzerdefiniertes Image muss sich an die Best Practices für die Sicherheit halten. Installieren Sie bei Verwendung von Linux die Linux-Gastumgebung für Compute Engine, um Zugang zu den Funktionen zu erhalten, die öffentliche Images standardmäßig bereitstellen. Wenn Sie die Gastumgebung installieren, können Sie Aufgaben wie das Abrufen von Metadaten, Konfigurieren des Systems und Optimieren des Betriebssystems für Google Cloud mit denselben Sicherheitskontrollen für Ihr benutzerdefiniertes Image ausführen, die Sie auch für öffentliche Images verwenden.
Produktionshinweise: Verwalten Sie Ihre benutzerdefinierten Images in einem eigenen Projekt auf Organisationsebene. Auf diese Weise können Sie präziser steuern, wie Images erstellt oder geändert werden. Außerdem haben Sie dann die Möglichkeit, Versionen anzuwenden. Dies kann nützlich sein, wenn für mehrere Produktionen unterschiedliche Software- oder Betriebssystemversionen verwendet werden.
Imageerstellung und Instanzbereitstellung automatisieren
Die Verwendung von Tools wie Packer macht die Erstellung von Images reproduzierbarer, überprüfbarer, konfigurierbarer und zuverlässiger. Sie können auch ein Tool wie Ansible verwenden, um Ihre laufenden Renderingknoten zu konfigurieren und deren Konfiguration und Lebenszyklus engmaschig zu kontrollieren.
Maschinentyp auswählen
In Google Cloud können Sie einen der vordefinierten Maschinentypen auswählen oder einen benutzerdefinierten Maschinentyp angeben. Mit benutzerdefinierten Maschinentypen erhalten Sie die Kontrolle über Ressourcen, sodass Sie Instanzen auf die Jobtypen zuschneiden können, die Sie in Google Cloud ausführen. Beim Erstellen einer Instanz können Sie z. B. GPUs hinzufügen, die Anzahl der gewünschten CPUs und die CPU-Plattform festlegen sowie die Menge an RAM und die Art und Größe der Festplattenlaufwerke angeben.
Produktionshinweise: Bei Pipelines, die eine Instanz pro Frame bereitstellen, sollten Sie die Instanz auf Basis historischer Jobstatistiken wie CPU-Auslastung oder Arbeitsspeichernutzung anpassen, um die Ressourcennutzung für alle Frames einer Aufnahme zu optimieren. So könnten Sie Maschinen mit mehr CPUs für Frames mit starker Bewegungsunschärfe bereitstellen, um die Renderingzeiten frameübergreifend zu normalisieren.
Zwischen Standard-VMs und VMs auf Abruf wählen
Bei VMs auf Abruf handelt es sich um überschüssige Compute Engine-Kapazität, für die wesentlich geringere Preise als für Standard-VMs berechnet werden. Compute Engine kann diese Instanzen vorzeitig beenden, wenn für andere Aufgaben Zugriff auf diese Kapazität benötigt wird. PVMs sind ideal für Renderingarbeitslasten, die fehlertolerant sind und von einem Warteschlangensystem verwaltet werden, das Jobs verfolgt, die aufgrund der Beendigung auf Abruf verloren gegangen sind.
Standard-VMs können auf unbestimmte Zeit ausgeführt werden und sind ideal für Lizenzserver oder Warteschlangenadministrator-Hosts, die dauerhaft ausgeführt werden müssen.
Da VMs auf Abruf nach 24 Stunden automatisch beendet werden, sollten Sie sie nicht für Renderings oder Simulationen verwenden, die länger laufen.
Die Raten für vorzeitiges Beenden gehen von 5 % bis 15 %, was für normale Renderingarbeitslasten in Anbetracht der geringeren Kosten wahrscheinlich tolerierbar ist. Verschiedene Best Practices für vorzeitiges Beenden können Ihnen dabei helfen, die beste Vorgehensweise für die Integration von PVMs in Ihre Rendering-Pipeline zu finden. Wenn Ihre Instanz vorzeitig beendet wird, sendet Compute Engine ein Signal zum vorzeitigen Beenden an die Instanz. Mit diesem Signal können Sie Ihren Planer dazu veranlassen, den aktuellen Job zu beenden und ihn wieder in die Warteschlange einzureihen.
| Standard-VM | VM auf Abruf |
|---|---|
| Kann für Jobs mit langer Ausführungszeit verwendet werden. Ideal für Jobs mit hoher Priorität und knapper Terminierung Kann auf unbestimmte Zeit ausgeführt werden und eignet sich daher ideal für Lizenzserver oder Warteschlangenadministrator-Hosting |
Wird nach 24 Stunden automatisch beendet. Erfordert ein Warteschlangen-Verwaltungssystem zur Handhabung von vorzeitig beendeten Instanzen |
Produktionshinweise: Manche Renderer können Snapshots eines laufenden Renderings in festgelegten Intervallen erstellen. So können Sie nach einer vorzeitigen Beendigung der VM unterbrechen und mit dem Rendering fortfahren, ohne einen Frame von vorn starten zu müssen. Wenn Ihr Renderer Snapshots unterstützt und Sie PVMs verwenden, sollten Sie das Erstellen von Rendering-Snapshots in Ihrer Pipeline aktivieren, um keine Arbeit zu verlieren. Während Snapshots erstellt und aktualisiert werden, können Daten in Cloud Storage geschrieben und bei einer vorzeitigen Beendigung des Render-Workers abgerufen werden, wenn eine neue PVM bereitgestellt ist. Damit Sie Speicherkosten sparen, sollten Sie Snapshot-Daten für abgeschlossene Renderings löschen.
Zugriff auf Render-Worker gewähren
Mit IAM können Sie Personen, die Zugang zu Cloud-Ressourcen benötigen, Zugriffsrechte erteilen. Für Render-Worker unter Linux steht Ihnen OS Login zur Verfügung, um den Zugriff innerhalb einer SSH-Sitzung weiter einzuschränken und zu steuern, wer ein Admin ist.
Kosten einer hybriden Renderingfarm kontrollieren
Beim Schätzen der Kosten müssen Sie viele Faktoren berücksichtigen. Wir empfehlen Ihnen allerdings, die folgenden allgemeinen Best Practices als Richtlinie für Ihre hybride Renderingfarm zu implementieren:
- Verwenden Sie standardmäßig Instanzen auf Abruf. Sofern Ihr Renderingjob keine extrem lange Ausführungszeit wie vier oder mehr Stunden pro Frame hat oder Sie eine Aufnahme nicht unter großem Zeitdruck liefern müssen, sollten Sie VMs auf Abruf verwenden.
- Minimieren Sie ausgehenden Traffic. Kopieren Sie nur die Daten, die Sie benötigen, wieder in den lokalen Speicher. In den meisten Fällen sind dies die finalen gerenderten Frames, es können aber auch separate Durchläufe oder Simulationsdaten sein. Wenn Sie Ihren lokalen NAS direkt bereitstellen oder ein Speicherprodukt mit automatischer Synchronisierung verwenden, sollten Sie alle gerenderten Daten in das lokale Dateisystem des Render-Workers schreiben. Kopieren Sie dann nur die Daten in den lokalen Speicher zurück, die Sie brauchen. So entsteht kein ausgehender Traffic durch temporäre und unnötige Daten.
- Dimensionieren Sie VMs richtig. Achten Sie darauf, Render-Worker mit optimaler Ressourcennutzung zu erstellen. Weisen Sie dazu nur die benötigte Anzahl von vCPUs, die optimale Menge an RAM und, bei Bedarf, die korrekte Anzahl von GPUs zu. Überlegen Sie sich auch, wie Sie die Größe von hinzugefügten Laufwerken minimieren können.
- Berücksichtigen Sie das Abrechnungsminimum von einer Minute. Instanzen werden in Google Cloud im Sekundentakt mit einem Minimum von einer Minute abgerechnet. Wenn das Rendering von Frames in Ihrer Arbeitslast weniger als eine Minute dauert, sollten Sie Aufgaben zusammenfassen, um keine Instanz für eine Rechenzeit von unter einer Minute bereitzustellen.
- Belassen Sie große Datasets in der Cloud. Wenn Sie mit Ihrer Renderingfarm riesige Datenmengen wie Deep-EXRs oder Simulationsdaten generieren, sollten Sie die Verwendung einer cloudbasierten Workstation in Betracht ziehen, die sich in der Pipeline weiter hinten befindet. Beispielsweise könnte ein FX-Artist eine Flüssigkeitssimulation in der Cloud ausführen und Cache-Dateien in einen cloudbasierten Speicher schreiben. Ein Lighting Artist könnte dann über eine virtuelle Workstation, die sich in Google Cloud befindet, auf diese Simulationsdaten zugreifen. Weitere Informationen zu virtuellen Workstations erhalten Sie von Ihrem Google Cloud-Ansprechpartner.
- Sichern Sie sich Rabatte für kontinuierliche und zugesicherte Nutzung. Wenn Sie einen Pool von Ressourcen ausführen, können Sie mit den Rabatten für kontinuierliche Nutzung bis zu 30% der Kosten von Instanzen sparen, die einen ganzen Monat ausgeführt werden. Auch die Rabatte für zugesicherte Nutzung können in manchen Fällen sinnvoll sein.
Die Erweiterung Ihrer vorhandenen Renderingfarm in die Cloud stellt eine kosteneffiziente Möglichkeit dar, um leistungsstarke, günstige Ressourcen ohne größere Ausgaben zu nutzen. Da keine zwei Produktions-Pipelines gleich sind, kann kein Dokument jedes Thema und jede einzelne Anforderung abdecken. Wenden Sie sich daher an Ihren Google Cloud-Ansprechpartner, wenn Sie Hilfe bei der Verlagerung Ihrer Renderingarbeitslasten in die Cloud benötigen.
Nächste Schritte
- Referenzarchitekturen, Diagramme und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center