20-Node Dedicated GPU render farm grenzüberschreitend bereitstellen (2026)

Einleitung

Wenn ein Kreativteam nach einer dedizierten render farm fragt, die mehrere Standorte und einen Ozean überspannt, arbeitet es fast immer um eine Einschränkung herum, die eine SaaS render farm nicht lösen kann. Dabei kann es sich um ein Studio handeln, das vertraglich keinem Dritten erlauben darf, seine Anmeldedaten zu halten, um ein verteiltes Team, dessen Artists in einem Land Knoten in einem anderen Land bedienen, oder um ein Produktionshaus, dessen mehrmonatige Beauftragung Per-Frame-Abrechnung wirtschaftlich falsch macht.

Aus unserer Erfahrung beim Betrieb dedizierter Cluster besteht die Herausforderung selten darin, „mehr GPUs zu mieten". Es geht darum, die richtigen Teile zu verbinden: kundeneigenen Cloud-Speicher, eine private GPU-Flotte mit passender Größe, verschlüsselten grenzüberschreitenden Transport, der Jitter aushält, und eine Remote-Desktop-Schicht, die nicht bei einem schweren 3D-Viewport zusammenbricht. Stimmt ein Element nicht, läuft der Cluster, aber die Artists bemerken es — und der Auftrag erodiert leise.

Wir betreiben Super Renders Farm, eine Cloud render farm mit substanzieller CPU- und GPU-Flotte, und stellen außerdem dedizierte GPU-Cluster für Teams bereit, deren Workflows nicht auf unseren Managed Service passen. Dieser Artikel ist ein Praxisleitfaden aus diesen Bereitstellungen — wie wir eine dedizierte 20-Node GPU render farm architektonisch aufbauen, die zwei Standorte umspannt und entfernte Artists über Grenzen hinweg bedient, mit ehrlichen Anmerkungen zu unseren Entscheidungen, den zurückgenommenen Entscheidungen und den Lektionen, die wir nun standardmäßig anwenden. Wenn Sie dedizierte Infrastruktur gegen unseren Managed-render-farm-Service abwägen, hilft Ihnen dieser Leitfaden zu entscheiden, ob der dedizierte Weg den zusätzlichen architektonischen Aufwand wert ist.

Dedicated vs SaaS — Entscheidungskriterien

Die meisten Rendering-Workloads benötigen keinen dedizierten Cluster. Eine Managed Cloud render farm nimmt eine Szene entgegen, plant die Frames und rechnet pro Minute ab. Es gibt keine Infrastruktur zu besitzen, keine Firewall zu pflegen und kein Operations-Team kundenseitig einzuteilen. Für projektbasierte Arbeit — einen einzelnen Kurzfilm, eine 30-Sekunden-Werbung, eine Stapel Stills — gewinnt dieses Modell auf jeder relevanten Achse.

Ein dedizierter Cluster rechtfertigt seine Komplexität nur, wenn eines oder mehrere der folgenden Kriterien zutreffen:

• IP-Kontrolle ist vertraglich, nicht präferenzbedingt. Der Kundenvertrag verbietet Dritten, Szenedateien oder Render-Anmeldedaten zu halten. SaaS-Pipelines, die den Szenen-Upload vermitteln, verletzen diese Beschränkung selbst dann, wenn die zugrunde liegende Rechenleistung identisch ist.
• Der Auftrag läuft über Monate, nicht Tage. Arbeit mit fester Struktur — eine langlaufende Animationsserie, eine mehrquartalige Archviz-Pipeline, eine laufende Virtual-Production-Bühne — amortisiert die Vorab-Architekturkosten.
• Der Workflow ist so individuell, dass eine Managed-Pipeline ihn nicht hosten kann. Eigene DCC-Plugin-Stacks, hauseigene Render-Manager, simulationsschwere Pipelines, die in einen Shared Cache vorberechnen, oder proprietäre Toolchains drängen zu dedizierten Knoten.
• Bring-your-own-Cloud ist eine harte Anforderung. Wenn die Projekt-Assets in einer Cloud-File-Streaming-Plattform unter dem Konto des Kunden liegen, muss sich der Cluster als der Kunde anmelden, nicht als der Infrastrukturanbieter. Dies ist das unten beschriebene „Model B"-Muster.
• Netzwerksegmentierung muss über tenant-VLAN hinausgehen. Manche Workflows verlangen, dass der Cluster für das breitere Netzwerk des Anbieters nicht nur logisch, sondern auch per Routing unsichtbar ist.

Treffen keine dieser Kriterien zu, ist eine Managed render farm die richtige Wahl. Treffen zwei oder mehr zu, verschiebt sich das Gespräch hin zu dedizierter Infrastruktur. Die verbleibende Frage ist geografisch: Passt die Arbeit in ein Rechenzentrum, oder muss sie ein öffentliches ISP-Backbone überqueren, um die Artists zu erreichen?

Architekturüberblick

Die Architektur, die wir für grenzüberschreitende dedizierte Cluster bereitstellen, besteht aus drei Ebenen: einer Transportebene, einer Compute-Ebene und einer Storage-Acceleration-Ebene. Jede hat einen einzelnen Ausfallmodus, der in unserer Erfahrung den größten Teil der Betriebsschmerzen verursacht, wenn er bricht.

        [ Remote-Artist-Team ]
              │  WireGuard (UDP 51820, Ende-zu-Ende verschlüsselt)
              ▼
   ┌──────────────────────────────────────────────────┐
   │   Main DC (gute internationale Transit-Anbindung) │
   │                                                    │
   │   ┌──────────────────────────────────────────┐    │
   │   │  EDGE + CACHE BOX (einzelner Ubuntu-Host) │    │
   │   │   • WireGuard hub (NAT/MASQUERADE)        │    │
   │   │   • Samba SMB3 Cache (Single SSD, ext4)   │    │
   │   │   • dnsmasq (.lan-Zone)                   │    │
   │   │   • chrony (NTP)                          │    │
   │   │   • ufw + BBR + TCP MSS Clamp             │    │
   │   └────────────┬─────────────────────────────┘    │
   │                │ LAN                                │
   │     ┌──────────▼───────────┐                        │
   │     │ Group A — ~10 Nodes   │  RTX 5090              │
   │     │ (Sunshine + Cloud-    │  C4D / Redshift / usw. │
   │     │  File-Stream-Client + │                        │
   │     │  Cache-Mount)         │                        │
   │     └───────────────────────┘                        │
   │                                                    │
   │     WireGuard Site-to-Site (öffentlicher ISP-Pfad)  │
   └────────────────────┬───────────────────────────────┘
                        ▼
   ┌──────────────────────────────────────────────────┐
   │   Sekundärer Standort (gleiche Metropolregion)     │
   │     ┌───────────────────────┐                      │
   │     │ Group B — ~10 Nodes   │  liest Cache über    │
   │     │ (über Tunnel zurück   │  Inter-Site-Tunnel   │
   │     │  zum Main-DC-Cache)   │                       │
   │     └───────────────────────┘                       │
   └──────────────────────────────────────────────────┘

   Externe Cloud-File-Streaming-Plattform — der Kunde meldet sich an;
   der Infrastrukturanbieter hält keine Anmeldedaten.

Die Transportebene ist WireGuard, in einem Hub-and-Spoke-Muster für Remote-Artists plus einem Site-to-Site-Tunnel zwischen den beiden Compute-Standorten. Die Compute-Ebene besteht aus zwei Gruppen von zehn Windows 11 Pro Nodes, jede mit einer NVIDIA RTX 5090 mit 32 GB VRAM. Die Storage-Acceleration-Ebene ist eine einzelne Edge-und-Cache-Box am Hauptstandort, die eine Samba SMB3 Freigabe auf einer Single SSD mit ext4 hostet — zusammen mit den Netzwerkdiensten, von denen der Cluster abhängt (DNS, NTP, Firewall).

Eine zentrale Entwurfsentscheidung: Edge-Box und Cache-Box sind dieselbe Maschine. Eine frühere Version dieser Architektur platzierte das Edge-Gateway auf einem separaten Gerät und den Cache auf einem NAS, was Race Conditions bei Cold Pulls und zwei zu patchende Flächen erzeugte. Die Konsolidierung auf einen Ubuntu 22.04 LTS Host beseitigte beide Probleme. Die Box wird zu einer kritischen Ressource — aber die Projektdaten des Kunden liegen weiterhin in der Cloud-File-Streaming-Plattform, sodass sich der Cache nach jedem lokalen Ausfall von oben re-warmen lässt.

Für eine tiefere Behandlung siehe unseren Architektur-Detail-Artikel zu den Storage- und Transportentscheidungen.

Einrichtung eines 20-Node GPU-Clusters

Die Standardgröße für die hier beschriebenen Bereitstellungen ist zwanzig RTX 5090 Nodes — aufgeteilt zehn und zehn auf zwei Standorte. Diese Größe passt konsistent gut zu einem Kreativteam im Bereich von zehn bis zwanzig Artists, dem Band, in dem sich dedizierte Cluster für IP-sensible Workflows rechnen.

Jeder Node hat die gleiche Hardware-Konfiguration: eine RTX 5090 mit 32 GB VRAM, eine moderne Multi-Core-CPU, 64 GB oder 128 GB Arbeitsspeicher und eine NVMe-Lokaldiskette für OS und Scratch. Persistente Projektdaten liegen auf dem Shared Cache oder in der vorgelagerten Cloud-File-Streaming-Plattform — nie auf dem Node selbst.

Das Betriebssystem auf jedem Node ist Windows 11 Pro, von einem sauberen Image bereitgestellt. Wir laden bewusst keine DCC-Plugin-Stacks auf das Node-Image vor. Der Kunde steuert die Installation seiner eigenen DCC-Tools — Cinema 4D, Redshift, Houdini, After Effects, Blender und andere — sodass das Node-Image minimal und reproduzierbar bleibt. Wenn der Auftrag endet, wischen wir und imagen vom gleichen sauberen Baseline neu.

Wir wählten 32 GB VRAM pro Node bewusst. Moderne GPU-Renderer — Redshift, Octane, Arnold GPU, Cycles — laden zunehmend große texturierte Szenen, die einfach nicht in 24-GB-Karten passen. RTX 5090 mit 32 GB ist derzeit der Sweet Spot für Produktionsrenderer.

Group A und Group B sind identisch konfiguriert. Sobald der Inter-Site-WireGuard-Tunnel steht und der Cache gemountet ist, verhält sich der sekundäre Standort wie eine dünne Erweiterung des LAN des Hauptstandorts. Der Render Manager des Kunden (Deadline, Royal Render oder eigener) behandelt die gesamte Flotte als einen Pool; kein manuelles Job-Routing, und Rebalancing geschieht auf OS-Ebene über Tunnel-Routing.

Die Flotte ist Layer-3-routable — der Kunde installiert seinen eigenen Render Manager und reicht von einer entfernten Workstation ein, statt jeden Node per Remote Desktop zu steuern. Das macht einen größeren Unterschied, als die meisten erwarten: zwischen einem Cluster, mit dem Artists kämpfen, und einem Cluster, den Artists vergessen.

Customer-Owned Credentials (Model B)

Die einzelne architektonische Entscheidung, die einen dedizierten Cluster am häufigsten zur richtigen Antwort für IP-sensible Workflows macht, ist das, was wir Model B nennen: customer-owned credentials. In Model A — der Default für Managed render farms, einschließlich unseres eigenen SaaS-Service — hält der Infrastrukturanbieter die Anmeldedaten der Render-Pipeline. Der Kunde lädt Szenedateien hoch; die Pipeline des Anbieters vermittelt das Rendern.

In Model B liefert der Infrastrukturanbieter Hardware, Betriebssystem, Netzwerk und Cache-Schicht, hält aber niemals das Authentifizierungsmaterial des Kunden für die Cloud-File-Streaming-Plattform oder die Quelldaten des Projekts. Der Kunde meldet sich auf jedem Node an der Cloud-Plattform an, genau wie er es an seiner eigenen Workstation täte. Projektdateien streamen aus der Cloud des Kunden. Renders schreiben zurück in die Cloud des Kunden. Die Rolle des Anbieters endet an der Hardware-und-Pipeline-Schicht.

Das ist aus drei Gründen relevant:

• Vertraglich: Wenn die nachgelagerte Kundenkette eine NDA oder einen MSA enthält, die einschränkt, wo Anmeldedaten und Quelldateien gehalten werden dürfen, hält Model B den Anbieter aus dem Geltungsbereich dieser Einschränkungen heraus.
• Audit: Wenn der Kunde einem Sicherheitsprüfer demonstrieren muss, dass seine Render-Pipeline Anmeldedaten nicht gegenüber Dritten exponiert, gibt Model B eine saubere Antwort.
• Auftragsabschluss: Da der Anbieter nie Anmeldedaten hielt, ist die Bereinigung nach Auftragsende einfacher. Der Kunde widerruft seine eigenen Cloud-Sitzungen; der Anbieter wischt den Cache, imagen die Nodes neu und stellt eine schriftliche Bestätigung der Datenvernichtung aus.

Model B ist nicht für jeden geeignet. Es nimmt das Operations-Team des Kunden für den Credential-Lifecycle auf jedem Node in die Pflicht — zwanzig Rotationen zu koordinieren, falls Secrets monatlich rotiert werden. Teams mit dieser Operations-Praxis empfinden den Trade-off als akzeptabel. Teams ohne sie bleiben tendenziell bei Model A Managed Rendering. Für eine vollständigere Behandlung siehe unseren customer-owned credentials Tiefenartikel.

Cloud-File-Streaming-Integration

In den hier beschriebenen Konfigurationen liegen die Projekt-Assets des Kunden in einer Cloud-File-Streaming-Plattform — einem Dienst, der seine cloud-gestützte Projektstruktur als virtuelles Dateisystem auf jedem Node exponiert. Der Artist mountet das Projekt; der Node liest Dateien bedarfsgesteuert; die Plattform übernimmt Backing Storage, Versionierung und regionenübergreifende Replikation.

Wir integrieren mit einer generischen Cloud-File-Streaming-Plattform der Wahl des Kunden. Die Plattform sieht ein Sign-in-Ereignis von jedem Node mit dem Konto des Kunden; der Client der Plattform auf dem Node mountet die Projektstruktur an einem bekannten Pfad; die DCC-Anwendung des Kunden öffnet Dateien von diesem Pfad, exakt wie auf einer lokalen Workstation. Die Cloud-Plattform muss nicht wissen, dass der Node Teil eines Render-Clusters ist.

Was sich bei einem 20-Node-Cluster ändert, ist das Zugriffsmuster. Ein einzelner Artist an einer Workstation zieht eine Projektdatei nach der anderen bedarfsgesteuert. Zwanzig Render-Nodes, die zur gleichen Zeit dieselbe Szene für einen Frame-Bereich öffnen, erzeugen einen synchronen Burst von Cloud-Reads für dieselben Assets. Ohne Cache zieht jeder Node jede Textur, jede gecachte Simulation, jede Abhängigkeit parallel — was sowohl internationale Bandbreite verschwendet als auch auf dem ersten Frame jedes Bereichs langsam ist.

Deshalb existiert der Shared Cache. Asset-Pulls aus der Cloud werden einmal durch die Cache-Box konzentriert und dann an alle zwanzig Nodes über das LAN verteilt. Die Cloud-Plattform sieht nie zwanzig gleichzeitige Fetches derselben Textur — sie sieht einen Fetch plus warme SMB-Reads innerhalb unseres Netzwerks.

Das andere praktische Detail ist Write-Back. Wenn ein Render-Frame fertig wird, schreibt der Node die Ausgabe an die Cloud-File-Streaming-Plattform zurück — über das Konto des Kunden. Das Team des Kunden im entfernten Büro sieht die Frames in Echtzeit im Projektbaum erscheinen. Es gibt keinen manuellen Upload-Schritt, keine vom Anbieter vermittelte Übertragung.

Shared-Cache-Architektur

Der Shared Cache ist eine der zwei oder drei architektonischen Entscheidungen, die, wenn falsch getroffen, den Wert eines Clusters lautlos zersetzen. Wir haben sie in früheren Bereitstellungen falsch getroffen. Das Muster, das über mehrere Builds stabil geblieben ist, ist absichtlich konservativ.

Eine einzelne Edge-und-Cache-Box läuft Ubuntu 22.04 LTS, mit einer einzelnen 8 TB SATA SSD formatiert als ext4 und über Samba SMB3 für den Cluster freigegeben. Der Cache-Mount erscheint auf jedem Render-Node an einem festen Pfad (zum Beispiel \\cache.lan\proj). Wenn ein Node eine Projektdatei über den Cloud-File-Streaming-Client öffnet, streamt die Datei durch den lokalen Cache; spätere Reads derselben Datei auf einem beliebigen Node treffen die SSD direkt über das LAN.

Drei absichtliche Entscheidungen stecken in diesem Absatz.

Erstens, ein einzelner Cache, nicht Per-Node-Caches. Eine frühere Version speicherte Cache-Material pro Node. Bei zwanzig 5090-Nodes bedeutete das bis zu 200 TB redundantes Storage und zwanzig separate Cache-Zustände, die zu debuggen waren, wenn etwas divergierte. Die Konsolidierung auf einen Shared Cache reduziert den Storage-Footprint um den Faktor zwanzig.

Zweitens, eine Single SSD auf ext4, kein RAID 10 mit LUKS auf XFS. Der frühere Plan sah RAID 10 mit LUKS-Verschlüsselung auf XFS vor. Das war für die tatsächlich bereitgestellte Hardware überdimensioniert — eine SSD, ein Filesystem, ein Mount. Wir entfernten die RAID-Schicht, entfernten LUKS und nutzten ext4, weil der Cache nicht die Wahrheit ist. Die Cloud des Kunden ist die Wahrheit. Fällt die Cache-Disk aus, ersetzen wir sie und re-warmen von oben.

Drittens, den Cache vor dem ersten Render-Tag vorwärmen. Das ist die Lektion, die wir auf die harte Tour gelernt haben. Am D-Day ist jeder Cache-Miss der teuerste Read im Cluster — er durchquert die internationale Verbindung, zieht aus der Kunden-Cloud und schreibt zur lokalen SSD, bevor der Renderer konsumieren kann. Pre-Warming, ein strukturierter Walk durch den Asset-Baum am Vortag, wandelt D-Day-Reads von Cold-Cloud-Pulls in warme SMB-Reads um.

Standortübergreifend liest Group B den Cache über den Inter-Site-WireGuard-Tunnel. SMB über einen Tunnel ist empfindlich gegen MTU-Fehlkonfiguration, aber mit korrekt angewendetem MSS-Clamping war es für uns zuverlässig.

Grenzüberschreitende Netzwerkoptimierung

Die Transportebene entscheidet, ob ein grenzüberschreitender Cluster nahtlos oder kaputt wirkt. Die Standardverhalten von TCP/IP, IP-Fragmentierung und DNS-über-VPN sind für lange, verschlüsselte Tunnel mit SMB und Remote Desktop subtil falsch. Kernel- und Netzwerk-Tuning sind nicht optional; sie sind der Unterschied zwischen einem funktionierenden Cluster und einem, der große Pakete mysteriös droppt.

WireGuard, Hub-and-Spoke plus Site-to-Site. Jeder Artist verbindet sich von seiner Workstation über einen WireGuard-Client zum Hub am Hauptstandort. Die zwei Compute-Standorte haben außerdem einen WireGuard-Tunnel zwischeneinander. Aller Traffic ist Ende-zu-Ende verschlüsselt.

TCP BBR. Das Standard-Congestion-Control von Linux (CUBIC) wurde für Low-Latency-Verbindungen mit leichtem Paketverlust entworfen. Lange Public-ISP-Verbindungen mit verschlüsseltem Traffic sehen sehr anders aus — moderate Latenz, gelegentlicher Jitter, asymmetrische Verlustmuster. BBR produziert konsistent mehr nutzbaren Durchsatz auf diesen Verbindungen als CUBIC. Wir nutzen das Kernel-Standard-BBR (BBR v1); das neuere BBRv3 wurde in diesem Build nicht bereitgestellt.

TCP MSS Clamping. Das ist die häufigste Quelle für „der Cluster funktioniert meistens, außer bei großen Dateien"-Beschwerden. Wenn Traffic einen Tunnel durchquert, der die effektive MTU reduziert, werden große Pakete entweder fragmentiert (langsam) oder lautlos gedroppt (schlimmer). Kleine Pakete und Ping funktionieren einwandfrei, was das Problem schwer diagnostizierbar macht. Die Lösung: TCP MSS auf dem WireGuard-Router clampen.

dnsmasq mit aufgelisteter VPN-Schnittstelle. Ein subtiler Stolperstein: dnsmasq muss die WireGuard-Schnittstelle (zum Beispiel wg0) explizit in seiner Konfiguration auflisten, selbst wenn der Client eine private .lan-Adresse abfragt. Ohne das laufen DNS-Lookups über den Tunnel in einen Timeout — aber Ping funktioniert weiterhin, weil Ping nicht über DNS geht.

chrony für NTP. Zeitsynchronisierung klingt trivial, ist aber für Render Manager (Deadline timestamps Jobs), Log-Korrelation standortübergreifend und alle Auth-Tokens mit Zeitkomponente relevant. chrony handhabt Clock Drift über eine Long-Latency-Verbindung besser als das ältere ntpd.

Moonlight und Sunshine für Remote Desktop

Remote Desktop ist die Schicht, die Artists am direktesten erleben. Fühlt sich diese Schicht träge oder ruckelig an, spielt es keine Rolle, wie schnell der Renderer ist — die Hände des Artists sind langsam.

Wir nutzen Moonlight (Client) und Sunshine (Host auf jedem Node) für Remote Desktop. Die Kombination nutzt NVIDIAs NVENC Hardware-Encoder auf der RTX 5090, um den Framebuffer in Echtzeit zu kodieren und an die Workstation des Artists zu streamen. Da das Encoding auf der GPU geschieht, die ohnehin im Node ist, gibt es keine Konkurrenz mit dem Renderer.

Für 3D-Viewport-Arbeit zählt das in einer Weise, in der es für traditionelles Remote Desktop nicht zählt. Ältere Protokolle — RDP, VNC, Microsofts Standard Remote Desktop — wurden für Büro-Workloads entworfen. Sie handhaben Text, Dialoge und langsam wechselnde Fenster gut, brechen aber bei einem Full-Screen-3D-Viewport bei einer Turntable-Preview zusammen. Moonlight + Sunshine behandeln den Framebuffer als Video, was genau das richtige Modell für 3D-Arbeit ist.

Wir haben einen Quality-Gate-Test, den wir vor der Übergabe eines Nodes an einen Artist ausführen — informell „Test 8" — der eine definierte Sequenz von Viewport-Operationen unter Last ausübt und bestätigt, dass die Remote-Desktop-Erfahrung eine Baseline erfüllt.

Parsec ist ein gangbarer Fallback. Wir haben eine kleine Anzahl Nodes auf Parsec ausgeliefert, wenn Sunshine nicht zuverlässig konfiguriert werden konnte; die Artist-Erfahrung ist ähnlich. Wir standardisieren nicht auf Parsec, weil das kontogebundene Cloud-koordinierte Modell nicht so sauber zur Model-B-Credential-Handhabung passt wie selbst gehostetes Sunshine. Siehe unsere Moonlight, Parsec und RDP für 3D-Workflows Übersicht.

Hybrid-Infrastruktur (Owned + Rented)

Eine der Operations-Entscheidungen, die die Ökonomie dedizierter Cluster konsistent verbessern, ist das Mischen von eigenem und gemietetem Compute. Für die hier beschriebenen 20-Node-Konfigurationen konfigurieren wir typischerweise etwa zehn Nodes aus existierender Kapazität am Hauptstandort und etwa zehn Nodes aus angemietetem Raum an einem sekundären Standort.

Der erste Grund ist Kapitalflexibilität. Ein Cluster, der eigene und gemietete Kapazität mischt, erfordert keinen Vorab-Kauf von zwanzig neuen Nodes. Der Anbieter absorbiert ungefähr die Hälfte der Kapazität aus existierender Flotteninvestition, dann bezieht er die Restbalance über kurzfristige Vermietung an einer Partner-Einrichtung.

Der zweite Grund ist Kapazitätsplanung. Mehrmonatige Aufträge haben selten eine flache Bedarfskurve — Crunch-Wochen brauchen mehr Nodes, Stetigzustand-Wochen brauchen weniger. Ein Hybrid-Mix erlaubt es, den gemieteten Anteil wöchentlich zu skalieren, ohne den ganzen Auftrag neu zu verhandeln.

Beide Gruppen verhalten sich aus Kundensicht identisch — einheitlicher Render Manager, Cache-Schicht, WireGuard-Topologie und Cloud-Integration. Siehe unsere Hybrid Own + Rent Aufschlüsselung für das Finanzmuster.

Netzwerksegmentierung

Netzwerksegmentierung in einem solchen Cluster ist nicht optional. Der Kunde operiert auf der Infrastruktur des Anbieters, aber der Kunde darf nie das breitere Netzwerk des Anbieters sehen — nicht das NAS des Anbieters, nicht die Router-Admin-Oberflächen, nicht andere Mandanten. Gleichermaßen dürfen die internen Systeme des Anbieters nie den Workloads des Kunden ausgesetzt sein.

Wir implementieren Segmentierung in zwei Stufen.

Tier 1 — Edge-Firewall. Die Edge-und-Cache-Box führt ufw mit Default-Deny-Inbound aus. Nur der WireGuard-UDP-Port (51820) ist dem öffentlichen Internet ausgesetzt. SSH, SMB, DNS, NTP und alle anderen Dienste auf der Edge sind an interne Schnittstellen gebunden und von außen nicht erreichbar.

Tier 2 — Host-Firewall auf jedem Node. Jeder Render-Node hat seine eigene Windows-Firewall-Konfiguration, die die Edge-Haltung spiegelt — Inbound von Cluster-IPs für die benötigten Dienste annehmen (SMB, Remote Desktop, Render Manager) und alles andere droppen. Das ist nicht redundant; es ist Defense-in-Depth.

In der Praxis kann der Kunde nicht die anderen Systeme des Anbieters pingen oder scannen, selbst wenn er wollte. Keine geteilte Management-Ebene, kein geteilter Monitoring-Pfad, der andere Mandanten exponiert. Siehe unseren Network Security Architecture Artikel.

Lehren aus dem Betrieb

Diese fünf Operations-Lektionen haben uns bei jedem dedizierten Cluster, den wir aufgestellt haben, entweder Stunden Debugging gespart oder — wenn wir vergaßen, sie anzuwenden — Stunden Debugging gekostet.

1. Dual-Home-Gateway-Routing-Falle. Wenn die Edge-Box zwei Netzwerk-Schnittstellen hat (eine public, eine LAN), zählt die Reihenfolge der Operationen. Die LAN-Route muss konfiguriert werden, bevor die Default-Route geändert wird. Sonst kann die SSH-Sitzung in dem Moment droppen, in dem die Default-Route wechselt, und Sie sperren sich von der Box aus.

2. WireGuard und DNS. dnsmasq muss jede Schnittstelle, auf der es lauschen soll, explizit auflisten, einschließlich der WireGuard-Schnittstelle. Listen Sie nur die LAN-Schnittstelle, laufen DNS-Lookups von VPN-Clients in einen Timeout — aber Ping-Antworten funktionieren weiterhin.

3. TCP-MSS-Clamping ist nicht optional durch einen Tunnel. TLS-Handshakes, RDP-Sitzungen, SMB-Large-File-Reads — alles, was große Pakete senden will — droppt lautlos ohne MSS-Clamp. Das erste Symptom ist gewöhnlich „Moonlight läuft zehn Sekunden, dann friert es ein" oder „SMB listet Verzeichnisse, kann aber Dateien größer als 1 MB nicht lesen".

4. Storage richtig dimensionieren, nicht überengineering. Die frühere Version dieser Architektur spezifizierte RAID 10 mit LUKS-Verschlüsselung auf XFS. Die tatsächlich bereitgestellte Cache-Hardware war eine einzelne SSD. Wir entfernten die RAID-Schicht, entfernten LUKS und nutzten ext4 — weil der Cache nicht die Wahrheit ist, die Cloud-Plattform ist es.

5. Cache vorwärmen. Am D-Day kostet jeder Cache-Miss die internationale Verbindung und die Cloud-Plattform einen Round-Trip. Die erste Produktionsstunde auf einem kalten Cache fühlt sich auch dann langsam an, wenn alles andere korrekt konfiguriert ist. Wir planen jetzt ein Pre-Warm-Fenster in jeden Auftrag ein — gewöhnlich ein bis zwei Tage vor Produktionsstart.

Das sind Operations-Lektionen, keine architektonischen. Unsere Lessons Learned Sammlung deckt die Fälle ab, die nicht in diesen Artikel gemacht haben.

Fazit

Eine dedizierte grenzüberschreitende 20-Node GPU render farm ist die richtige Architektur, wenn IP-Kontrolle vertraglich ist, der Auftrag mehrmonatig ist, der Workflow individuelle Konfiguration braucht und Bring-your-own-Cloud-Authentifizierung nicht verhandelbar ist. Außerhalb dieser Bedingungen ist eine Managed render farm fast immer die bessere Antwort — die hier beschriebene architektonische Komplexität rechtfertigt sich nicht für projektbasierte Arbeit oder Teams ohne dedizierte Operations-Funktion.

Wenn die Bedingungen zutreffen, sind die hier beschriebenen Muster — Model-B-Credentials, Shared Cache auf ext4, WireGuard Hub-and-Spoke plus Site-to-Site, BBR mit MSS-Clamping, Moonlight + Sunshine für Remote Desktop, Two-Tier-Firewalling — das, was wir standardmäßig bereitstellen.

Das Team hinter Super Renders Farm betreibt sowohl Managed render farm Vermietung als auch dedizierte Cluster-Bereitstellungen — einschließlich der hier beschriebenen dedizierten GPU-Cluster-Konfigurationen und grenzüberschreitenden Topologien.

FAQ

Q: Wie lange dauert eine typische 20-Node-Dedicated-Cluster-Bereitstellung? A: Je nach Umfang, Hardware-Verfügbarkeit am Mietstandort und Cloud-File-Streaming-Setup des Kunden braucht ein typischer Auftrag von einigen Wochen Vorlaufzeit für Hardware und Netzwerk-Provisionierung bis zu einem Pre-Warm-Fenster von ein bis zwei Tagen vor Produktionsstart.

Q: Was, wenn mein Team über drei Kontinente verteilt ist? A: Der Customer-to-Hub-WireGuard-Tunnel skaliert auf zusätzliche Client-Standorte, ohne die Cluster-Architektur zu ändern. Jeder Remote-Artist führt einen WireGuard-Client aus und verbindet sich mit demselben Hub am Hauptstandort. Latenz aus jeder Region wird vom Public-Internet-Pfad bestimmt.

Q: Kann ich den Cluster vor einer mehrmonatigen Verpflichtung von meiner Seite aus sehen? A: Wir arrangieren typischerweise ein Proof-of-Concept-Fenster während des Scoping-Gesprächs. Die genaue Form hängt vom Projekt des Kunden ab — manchmal ist es eine einzelne Node-Remote-Desktop-Sitzung zur Prüfung der Artist-Erfahrung, manchmal ein kleinskaliger Render-Test zur Validierung der Cache- und Cloud-Integration.

Q: Wie wird Datensicherheit am Auftragsende gehandhabt? A: Da Model B Kunden-Credentials außerhalb unserer Hände hält, fokussiert sich der Auftragsabschluss auf Hardware- und Cache-Bereinigung. Wir wischen den SMB-Cache, imagen jeden Node von der sauberen Baseline neu und stellen eine schriftliche Bestätigung der Datenvernichtung aus. Der Kunde widerruft seine eigenen Cloud-Sitzungen.

Q: Was, wenn ich mehr als 20 Nodes brauche? A: Die 20-Node-Konfiguration ist die häufigste Form, die wir bereitstellen, aber die Architektur skaliert darüber hinaus. Wir haben größere Flotten durch zusätzliche Gruppen an zusätzlichen Standorten aufgestellt, mit demselben Site-to-Site-WireGuard-Modell. Die praktische Grenze ist gewöhnlich Cache-Bandbreite.

Q: Kann ich meine eigene Lizenz für Cinema 4D, Redshift oder andere DCC-Tools mitbringen? A: Das Lizenzmodell — Bring-your-own-License versus Anbieter-bereitgestellt — ist eine Geschäftsentscheidung, die vom spezifischen DCC und vom existierenden Lizenzinventar des Kunden abhängt. Manche Konfigurationen funktionieren sauber mit Kunden-Lizenzen; andere sind einfacher mit Anbieter-bereitgestellten. Wir klären das während des Scoping-Gesprächs.

Q: Wie handhaben Sie Cloud-Storage von EU- versus US-Anbietern? A: Die Cloud-File-Streaming-Plattform ist die Wahl des Kunden. Unser Cluster integriert mit jeder Plattform, die einen Sign-in-Client auf Windows ausführen und den Projektbaum des Kunden als gemountetes Dateisystem exponieren kann. Die geografische Lage der vorgelagerten Cloud beeinflusst die internationale Latenz des Customer-to-Cluster-Pfades.

Q: Was passiert, wenn der WireGuard-Tunnel droppt? A: WireGuard etabliert die Session automatisch neu, wenn sich das zugrunde liegende Netzwerk erholt; die Remote-Desktop-Sitzung des Kunden kann während des Re-Handshakes kurz pausieren. Droppt der Tunnel während eines laufenden Renders, läuft der Render selbst weiter auf dem Node, aber Write-Back zur Cloud queued, bis der Tunnel wiederhergestellt ist.