Skip to main content

Cross-Country render farm: Optimierte Workflows für lange Distanzen

WireGuard-Verschlüsselung · BBR-Überlastungskontrolle · Geteilter Cache · Für global verteilte Kreativteams.

Cross-Country-Bereitstellung anfragenArchitektur ansehen

Warum Cross-Country-Rendering anders ist

Moderne Kreativarbeit ist zunehmend verteilt. Eine 3D-Pipeline kann einen Art Director in New York, ein Lighting-Team in Berlin, freie Look-Dev-Künstler in Seoul und eine render farm auf einem weiteren Kontinent haben. Sitzen alle vier im selben Gigabit-LAN, ist der Zugriff auf die render farm kein Problem. Tun sie das nicht, läuft der Workflow durch das öffentliche Internet, und jede Eigenheit des Langstrecken-Routings macht sich in der Timeline bemerkbar.

Drei Themen treten in solchen Setups immer wieder auf. Erstens die Latenz — Roundtrip-Zeiten von 150 bis 250 ms zwischen Kontinenten verändern, wie reaktiv sich ein Remote-Desktop anfühlt, und sie verstärken jede Geschwätzigkeit in einem Renderer-Manager oder einem Asset-Streaming-Protokoll. Zweitens der Jitter — internationale Verbindungen laufen oft am Limit, und das Paket-Timing schwankt. Drittens die Bandbreitenkosten und der Wettbewerb darum — eine 40-GB-Szene einmal über eine interkontinentale Leitung zu ziehen ist akzeptabel; sie zwanzigmal zu ziehen, weil jeder Render-Knoten seinen eigenen Cache hat, ist es nicht.

Eine lokale render farm umgeht das meiste davon. Teams, die bereits einen Cluster in der gleichen Rechenzentrumsregion wie ihre Künstler haben, brauchen das meiste hier Beschriebene nicht. Cross-Country-Rendering wird zur richtigen architektonischen Wahl, wenn einer der folgenden Punkte zutrifft:

  • Das Team ist über Regionen verteilt und benötigt eine einzige geteilte Render-Flotte.
  • Hardware-Verfügbarkeit oder Kosten machen die vom Kunden gewünschte GPU-Klasse in einer Region leichter beschaffbar als in einer anderen.
  • Das Künstlerteam ist absichtlich von der Render-Hardware entkoppelt — zum Beispiel ein US-Studio, das projektbezogen dedizierte Kapazitäten in Asien mietet.
  • Cloud-Speicher und Projektdateien liegen bereits in einer Region, und die Render-Flotte muss sowieso von dort lesen.

Wenn eines davon zutrifft, wird die Frage operativ: Wie bringt man eine render farm auf der anderen Seite der Welt dazu, sich wie ein Teil des lokalen Netzwerks der Künstler zu verhalten. Der Rest dieser Seite beschreibt, wie wir das bei Super Renders Farm angehen.

Netzwerk-Optimierungs-Stack

Netzwerk-Optimierungs-Stack

Wir optimieren Cross-Country-Verbindungen mit vier Bausteinen, die zusammen angewendet werden statt einzeln.

WireGuard für verschlüsselten Langstreckentransport

Jede Verbindung von einem Kunden-Endpunkt zur render farm läuft über WireGuard. Der Rechner des Kunden wird zu einem WireGuard-Peer; das Haupt-Rechenzentrum betreibt einen Hub. Die Verschlüsselung ist automatisch und Ende-zu-Ende; der Kunde sieht im öffentlichen Internet keinen Klartextverkehr, und wir auch nicht. WireGuard ist außerdem schlank genug, um auf einer Langstreckenverbindung nicht zum Flaschenhals zu werden — sein Overhead ist deutlich kleiner als bei einem klassischen IPsec-Stack.

TCP BBR für die Überlastungskontrolle

Die Standard-Überlastungskontrolle des Linux-Kernels (CUBIC) ist bei Jitter und Paketverlust konservativ — sie deutet Verlust als Signal zum Drosseln, auch wenn der Verlust von sporadischem internationalen Routing kommt und nicht von echter Überlastung. BBR (Bottleneck Bandwidth and RTT) misst das tatsächliche Bandbreiten-Verzögerungs-Produkt der Leitung und hält die Pipe gefüllt, solange Kapazität vorhanden ist. Auf einer stabilen transkontinentalen Route liefert BBR typischerweise zwei- bis dreimal den Durchsatz von CUBIC bei gleicher Hardware. Auf einer instabilen Route ist der Unterschied größer.

TCP-MSS-Clamping zur Vermeidung von MTU-Blackholes

Wenn ein Paket durch einen Tunnel wie WireGuard läuft, ist seine effektive Maximum Transmission Unit (MTU) kleiner als auf dem unterliegenden Interface. Verhandelt eine TCP-Verbindung eine Maximum Segment Size (MSS), die größer ist als das, was der Tunnel übertragen kann, passieren zwei Dinge: kleine Pakete kommen durch, große Pakete werden lautlos verworfen. Das Symptom ist eines der frustrierendsten in der Remote-Arbeit — SSH funktioniert, Ping funktioniert, aber TLS-Handshakes, RDP-Sitzungen und SMB-Dateikopien jeder relevanten Größe hängen sich auf. Wir clampen die MSS am WireGuard-Gateway, sodass alle TCP-Verbindungen eine Segmentgröße aushandeln, die der Tunnel auch wirklich liefern kann.

Interne DNS- und Zeitdienste

Innerhalb der Farm betreiben wir `dnsmasq` für interne DNS-Auflösung und `chrony` für die Zeit. Das sind ruhige Infrastrukturteile, die mehr zählen, als es scheint. Internes DNS bedeutet, dass Render-Knoten den geteilten Cache als `cache.lan` ansprechen statt über eine IP-Adresse, was es sicher macht, das Layout neu zu ordnen. Zeitsynchronisierung zählt, weil die meisten Renderer-Manager und Log-Pipelines Uhren-Drift schlecht vertragen — ein Knoten, der 30 Sekunden vom Rest der Flotte abweicht, kann verwirrendes Job-Assignment-Verhalten erzeugen. Beide Dienste lauschen nur im internen Netz; nichts aus dem öffentlichen Internet spricht direkt mit ihnen.

Zusammen machen diese vier Bausteine eine Langstrecken-render-farm weniger wie eine entfernte Maschine und mehr wie eine Slow-LAN-Erweiterung der Künstler-Workstation. Keiner davon ist exotisch; der Wert liegt darin, sie als Stack anzuwenden und die Parameter auf die spezifischen Routen abzustimmen, die der Kundenverkehr tatsächlich nimmt.

Architektur für lange Distanzen

Die Bereitstellungsform, die wir für Cross-Country-Setups verwenden, ist eine Hub-and-Spoke-Topologie, mit einem einzigen primären Rechenzentrum als Hub und einem oder mehreren Sekundärstandorten, die über Site-to-Site-WireGuard verbunden sind.

Hub-and-Spoke-Topologie: Main DC und Secondary Site

Ein paar Entscheidungen in diesem Layout sind erwähnenswert, weil sie bei jedem dieser Setups wiederkehren.

Edge und Cache laufen auf einer Box, nicht auf dreien. Dieselbe Ubuntu-Maschine, die WireGuard von der Außenwelt terminiert, hostet auch den Samba-Cache, das interne DNS und den Zeitdienst. Wir trennen diese Rollen nicht auf mehrere Maschinen, solange es keinen bestimmten Grund dafür gibt. Das Right-Sizing ist beabsichtigt. Eine einzelne dedizierte Cache-Box hat einen Netzwerkpfad rein und einen raus, was die Routing-Mathematik einfach hält. Sie macht auch Fehlerfälle einfacher zu durchdenken — wenn der Cache läuft, laufen die internen Dienste; wenn nicht, läuft intern gar nichts, und dieses eine Signal ist leichter zu alarmieren als drei getrennte.

Site-to-Site-WireGuard übernimmt den Sekundärstandort. Wenn sich die Bereitstellung über zwei physische Orte erstreckt — zum Beispiel ein Haupt-Rechenzentrum plus ein kleinerer angemieteter Standort in derselben Metropolregion — sind die beiden über einen Site-to-Site-WireGuard-Tunnel über den öffentlichen ISP verbunden. Der Verkehr zwischen ihnen sieht aus Sicht des Hosts wie ein großes Subnetz aus. Rendergruppe B am Sekundärstandort liest aus dem Cache im Main DC genauso wie Rendergruppe A, nur mit mehr Hops.

Das Netzwerk ist Layer-3-routbar. Jeder Knoten ist ein echter IP-Host, den andere Knoten direkt adressieren können. Wir bestehen nicht auf einen bestimmten Renderer-Manager. Teams, die Deadline bevorzugen, können ein eigenes Deadline-Repository auf einem Kunden-Koordinator-Knoten betreiben; Teams, die etwas anderes bevorzugen, können das tun. Die Farm liefert die Hosts, das Netz, den Cache und den Optimierungs-Stack; die Orchestrierungsebene darüber ist die Wahl des Kunden.

Eine tiefere Begehung dazu liefert der operative Bereitstellungs-Guide Schritt für Schritt, und das Architektur-Deep-Dive geht detaillierter auf das WireGuard- und Cache-Design ein.

Bandbreitenoptimierung und geteilter Cache

Interkontinentale Bandbreite ist in zwei Sinnen teuer: Sie kostet Geld auf der Cloud-Egress-Rechnung, und sie kostet Zeit, wenn Künstler darauf warten, dass ein Asset durch die Leitung kommt. Eine Render-Flotte, die nicht darüber nachdenkt, kann einen relevanten Anteil der Wall-Time jedes Jobs damit verbringen, Szenendateien kalt zu ziehen, die anderswo im Gebäude schon im Cache liegen.

Das Shared-Cache-Muster ist der einfachste und größte Hebel. Ein Samba (SMB3) Cache-Server im Haupt-Rechenzentrum hält die Projekt-Assets. Jeder Render-Knoten mountet den Cache und liest Szenendateien über LAN. Wenn ein neues Asset von einem Job referenziert wird, zieht der Cache es einmal aus dem Cloud-Speicher des Kunden. Jeder folgende Knoten, der dasselbe Asset braucht, liest es aus der LAN-Kopie. Eine 20-Knoten-Flotte, die eine 40-GB-Szenendatei sonst zwanzigmal ziehen würde, zieht sie einmal.

Im Prinzip ist das geradlinig. In der Praxis zählen zwei Designteile.

Per-Node-Caching vermeiden. Es ist verlockend, jedem Render-Knoten eine eigene große lokale SSD zu geben und ihn cachen zu lassen, was er will. Für eine 20-Knoten-Flotte mit 10 TB Projektdaten werden daraus 200 TB duplizierter Speicher ohne gemeinsame Invalidierungslogik. Das machen wir nicht. Der Shared Cache ist der einzige Cache; die Knoten behandeln ihre lokalen Platten als Scratch-Space, nicht als Projektarchiv.

Den Cache vor dem D-Day vorwärmen. Wenn ein Kunde ankündigt, dass ein Projekt am Montag startet, wärmen wir den Cache über das Wochenende vor. Der erste Job am Montag liest aus einem warmen Cache statt zwanzig Stunden Cold-Pulls auszulösen. Das ist die zuverlässigste Methode, das erste Rendern eines Projekts schnell wirken zu lassen.

Eine Anmerkung zum Right-Sizing: Die Cache-Box nutzt eine einzelne SATA-SSD mit einem ext4-Dateisystem. Für einen Cache (im Gegensatz zu Primärspeicher) ist ein Single-Disk-Layout der richtige Kompromiss. Der Cache ist nicht die Wahrheitsquelle — das ist der Cloud-Speicher des Kunden — und der Cache kann durch Re-Pulls aus der Cloud oder Rsync aus einem Projekt-Backup neu aufgebaut werden. Eine redundante Array auf einem verschlüsselten Volume aufzubauen würde Kosten und Komplexität hinzufügen und die operative Geschichte nicht verändern; ein Knoten, der den Cache verliert, ist ein Aufbau über einen Abend, kein Datenverlust-Ereignis. Cache-Hardware passend zur Rolle zu dimensionieren ist eine der einfacheren Methoden, die Betriebskosten vorhersagbar zu halten.

Für Teams, die einen dauerhaften Cluster statt einer einzelnen Cross-Country-Bereitstellung erwägen, behandelt die Seite dedicated cluster options diese Anordnung im Detail.

Performance-Charakteristik und Eignung

Performance-Charakteristik und Eignung

Cross-Country-render-farms sind nicht generell die bessere Option. Sie ergeben für eine bestimmte Art Workflow Sinn und kosten gegenüber einer lokalen Farm vorhersehbar etwas.

Stream-Qualität für Remote-3D-Arbeit

Für Künstler, die interaktiv mit einem GPU-Knoten arbeiten müssen — zum Beispiel eine Cinema-4D-Szene mit Redshift öffnen, IPR-Vorschauen erstellen oder Frames vor Job-Einreichung framen — nutzen wir Moonlight als Client und Sunshine als Host. Beide nutzen NVENC-Hardware-Encoding auf der GPU des Render-Knotens, was einen merklich glatteren Stream liefert als Software-encoded Remote-Desktop-Protokolle. Encodiertes Video über eine getunte Langstreckenverbindung liefert ein für echte Arbeit nutzbares Erlebnis, einschließlich detaillierter Viewport-Interaktion; dieselbe Last über simples RDP oft nicht. Parsec ist als Fallback konfiguriert für die seltenen Fälle, in denen Sunshine eine Sitzung nicht verhandelt bekommt.

Latenzprofil, allgemein gefasst

Eine gut getunte interkontinentale Verbindung landet typischerweise bei 150 bis 250 ms Roundtrip. Die Zahl hängt von der geografischen Distanz und der Route ab, die der Verkehr des Kunden tatsächlich nimmt. Wir veröffentlichen auf dieser Seite keine spezifische Stadtpaar-Latenz, weil sie sich nicht verallgemeinert — Ihr eigener ISP, Ihr eigenes Peering und Ihre eigenen lokalen Hops dominieren das Erlebnis genauso wie jede Zahl, die wir nennen könnten. Wir können während der Planungsphase einen Probe-Lauf von einem Kandidaten-Endpunkt ausführen und die tatsächlichen Messungen für die Route teilen, die Ihr Team nutzen wird.

Bei sinnvoll großen Flotten getestet

Unsere Cross-Country-Bereitstellungen liefen mit aktuellen Consumer-GPUs in der RTX-5090-Klasse auf 20-Knoten-Cluster-Skala, mit Projektspeicher auf der eigenen Cloud-Plattform des Kunden. Das ist ungefähr die Skala, ab der die architektonischen Entscheidungen aus den vorherigen Abschnitten relevant werden — bei kleineren Flotten kommt ein weniger optimiertes Setup mit mehr durch.

Wann das passt

Cross-Country-Rendering passt, wenn Künstler verteilt sind und die Render-Flotte irgendwo sein muss, wenn Projektdaten bereits in einer bestimmten Cloud-Region liegen, wenn der Kunde IP-isolierte Infrastruktur braucht, die lokale Optionen nicht liefern können, oder wenn GPU-Verfügbarkeit oder -Kosten eine bestimmte Region begünstigen.

Wann eine lokale Farm besser passt

Wenn alle im Team im selben Büro oder Land arbeiten wie die Render-Flotte, sind die Optimierungen auf dieser Seite meistens unnötiger Overhead. Eine lokale Farm mit kürzeren Pipes und einfacherem Routing ist einfacher zu betreiben und profitiert nicht in derselben Weise von BBR oder MSS-Clamping. Ehrliche Gegenpositionierung zählt: nicht jedes Team braucht diese Architektur. Für Workloads, bei denen Künstler und Render-Hardware in derselben Region sitzen können, deckt die Standard-Seite render farm rental options den Fall gut ab.

Häufig gestellte Fragen

Allgemein gefasst landen gut getunte Langstreckenverbindungen im Bereich von 150 bis 250 Millisekunden Roundtrip, wobei die genaue Zahl vom ISP des Künstlers, von der Route des Verkehrs und davon abhängt, wo der Endpunkt geografisch liegt. Wir können während der Planung einen Probe-Lauf von einer Kandidaten-Workstation machen und die tatsächlich gemessenen Zahlen für Ihre Route teilen.

BBR-Überlastungskontrolle ist die primäre Maßnahme — sie hält den Durchsatz stabil, wenn die Verbindung Jitter zeigt, statt bei Paketverlust einzubrechen wie das Default-CUBIC. WireGuard selbst ist ebenfalls nachsichtig gegenüber kurzen Netzwerkaussetzern, weil es keinen Sitzungszustand pflegt wie ein IPsec-Tunnel. Bei ISP-Ausfällen verbindet sich der Tunnel wieder, sobald die Upstream-Route zurück ist; laufende Render-Jobs laufen farm-seitig unabhängig davon weiter, ob die Verbindung des Künstlers oben ist.

Ja. Jede Verbindung ist WireGuard-verschlüsselt: Künstler-Endpunkt zum Haupt-Rechenzentrum und Site-to-Site zwischen Main DC und jedem Sekundärstandort. Es gibt im öffentlichen Internet keinen Punkt, an dem ein Beobachter Klartextverkehr zwischen Ihrem Team und der Render-Flotte lesen kann. Wir verlangen kein Vertrauen in irgendeinen zwischengeschalteten Transport; die Verschlüsselung liegt auf der WireGuard-Schicht, nicht als optionales Add-on darauf.

Ja. Der WireGuard-Hub akzeptiert mehrere Peers, sodass beliebig viele Künstler aus beliebig vielen Orten gleichzeitig zur selben Farm verbinden können. Jeder Künstler startet den WireGuard-Client auf der Workstation, öffnet Moonlight und verbindet sich mit dem ihm zugewiesenen Render-Knoten. Interne Dienste wie Cache und DNS sind über die Flotte geteilt, sodass zwei Künstler, die von verschiedenen Kontinenten an derselben Szene arbeiten, denselben Asset-Satz sehen.

Über den geteilten SMB-Cache. Wenn ein Render-Job ein Asset referenziert, das der Cache noch nicht gesehen hat, zieht der Cache es einmal aus dem Cloud-Speicher des Kunden. Folgende Knoten, die dasselbe Asset benötigen, lesen aus dem Cache über LAN mit Leitungsrate, nicht über die interkontinentale Verbindung. Bei Projekten mit vorhersehbaren Startterminen wärmen wir den Cache vor dem D-Day vor, damit das erste Rendern des Projekts von einem warmen Cache profitiert und keine Kaltzieh-Kaskade ausgelöst wird.

Es funktioniert gleich; die geografische Trennung bedeutet nur, dass der erste Pull in den Cache länger dauert als bei In-Region-Speicher. Sobald ein Asset im Cache ist, spielt die geografische Trennung keine Rolle mehr — Render-Knoten lesen aus dem LAN. Wir wärmen den Cache in solchen Szenarien typischerweise vor, damit der Cross-Region-Pull bei uns passiert, bevor das Projekt beginnt, und nicht während des ersten Renderns.

Datenresidenz hängt davon ab, wo die Render-Flotte selbst bereitgestellt wird, was wir mit dem Kunden im Voraus planen. Für Teams mit spezifischen Residenz-Anforderungen muss das Gespräch abdecken, wo Projektdaten gehalten werden, wo Renders produziert werden, wo Logs gespeichert werden und wie Daten am Ende der Engagement-Phase gelöscht werden. Das ist ein Planungsgespräch und keine einzelne Ja-oder-Nein-Antwort; bitte kontaktieren Sie uns, um die Spezifika Ihres Falles zu besprechen.

Das Rendern selbst läuft weiter. Render-Jobs laufen farm-seitig unabhängig davon, ob der Tunnel des Künstlers oben ist — sobald ein Job verteilt ist, kann der Künstler komplett trennen und die Frames werden weiter produziert. Wenn der Tunnel zurück ist, baut der Künstler seinen WireGuard-Peer wieder auf und verbindet sich über Moonlight zur selben Sitzung. Die häufigste praktische Folge eines Tunnel-Abbruchs mitten im Rendern ist, dass der Künstler den Fortschritt für die Dauer des Ausfalls nicht live mitverfolgen kann; das Rendern selbst startet nicht neu.

Nächste Schritte

Nächste Schritte