Skip to main content

Cross-Country render farm: flussi di rendering ottimizzati per lunghe distanze

Cifratura WireGuard · Controllo congestione BBR · Cache condivisa · Per team creativi distribuiti a livello globale.

Richiedi un'implementazione cross-countryVedi l'architettura

Perché il rendering cross-country è diverso

Il lavoro creativo moderno è sempre più distribuito. Una pipeline 3D può avere un art director a New York, un team di lighting a Berlino, look-dev artist freelance a Seul, e una render farm in un altro continente ancora. Quando i quattro siedono sulla stessa LAN gigabit, l'accesso alla render farm non è un problema. Quando non è così, il flusso di lavoro passa per l'internet pubblico, e ogni stranezza del routing a lunga distanza finisce per comparire nella timeline.

Tre problemi ricorrono in questo tipo di configurazione. Il primo è la latenza — tempi di round-trip di 150-250 ms tra continenti cambiano la sensazione di un desktop remoto e amplificano qualsiasi prolissità in un render manager o in un protocollo di streaming di asset. Il secondo è il jitter — i link internazionali viaggiano spesso al limite e il timing dei pacchetti varia. Il terzo è il costo e la contesa di banda — scaricare una scena da 40 GB attraverso un link intercontinentale una volta è accettabile; scaricarla venti volte perché ogni nodo di render ha la propria cache non lo è.

Una render farm locale aggira la maggior parte di tutto questo. I team che hanno già un cluster nella stessa regione del datacenter dei propri artisti non hanno bisogno della maggior parte di quello che descrive questa pagina. Il rendering cross-country diventa la scelta architetturale corretta quando vale uno dei seguenti punti:

  • Il team è distribuito tra regioni e ha bisogno di un unico parco di rendering condiviso.
  • La disponibilità o il costo dell'hardware rende la classe di GPU preferita dal cliente più facile da reperire in una regione che in un'altra.
  • Il team di artisti è disaccoppiato dall'hardware di render di proposito — per esempio, uno studio statunitense che affitta capacità dedicata in Asia per uno specifico progetto.
  • Lo storage cloud e i file di progetto vivono già in una regione, e il parco di rendering deve leggere da lì in ogni caso.

Quando una di queste condizioni è vera, la domanda diventa operativa: come fare in modo che una render farm dall'altra parte del mondo si comporti come parte della rete locale dell'artista. Il resto di questa pagina descrive come lo affrontiamo in Super Renders Farm.

Stack di ottimizzazione di rete

Stack di ottimizzazione di rete

Ottimizziamo i collegamenti cross-country con quattro componenti applicati insieme piuttosto che separatamente.

WireGuard per il trasporto cifrato a lunga distanza

Ogni connessione da un endpoint cliente alla render farm passa per WireGuard. La macchina del cliente diventa un peer WireGuard; il datacenter principale ospita un hub. La cifratura è automatica e end-to-end; il cliente non vede traffico in chiaro sull'internet pubblico, e noi neanche. WireGuard è anche abbastanza leggero da non diventare il collo di bottiglia su un link a lunga distanza — il suo overhead è nettamente inferiore a quello di uno stack IPsec tradizionale.

TCP BBR per il controllo della congestione

Il controllo della congestione di default del kernel Linux (CUBIC) è prudente di fronte a jitter e perdita di pacchetti — interpreta la perdita come segnale di rallentare, anche quando la perdita arriva da routing internazionale intermittente e non da reale congestione. BBR (Bottleneck Bandwidth and RTT) misura il prodotto banda-ritardo effettivo del link e tiene il tubo pieno finché c'è capacità disponibile. Su una rotta transcontinentale stabile, BBR fornisce comunemente da due a tre volte il throughput di CUBIC con lo stesso hardware. Su una rotta con jitter, il divario è maggiore.

Clamping MSS TCP per evitare buchi neri MTU

Quando un pacchetto attraversa un tunnel come WireGuard, la sua MTU effettiva è minore di quella dell'interfaccia sottostante. Se una connessione TCP negozia un MSS superiore a quello che il tunnel può trasportare, succedono due cose: i pacchetti piccoli passano, i pacchetti grandi vengono silenziosamente persi. Il sintomo è uno dei più frustranti nel lavoro remoto — SSH funziona, ping funziona, ma gli handshake TLS, le sessioni RDP e le copie di file SMB di dimensione significativa si bloccano tutte. Effettuiamo il clamping della MSS sul gateway WireGuard in modo che tutte le connessioni TCP negozino una dimensione di segmento che il tunnel può effettivamente consegnare.

Servizi DNS e tempo interni

Dentro la farm gestiamo `dnsmasq` per la risoluzione DNS interna e `chrony` per il tempo. Sono pezzi di infrastruttura silenziosi che contano più di quanto sembri. Il DNS interno fa sì che i nodi di render si riferiscano alla cache condivisa come `cache.lan` invece che a un indirizzo IP, il che rende sicuro riorganizzare la topologia. La sincronizzazione oraria conta perché la maggior parte dei render manager e delle pipeline di log tollera male lo scarto di clock — un nodo disallineato di 30 secondi rispetto al resto del parco può produrre comportamenti di assegnazione lavori confusi. Entrambi i servizi ascoltano solo sulla rete interna; nulla dall'internet pubblico parla loro direttamente.

Insieme, questi quattro componenti rendono una render farm a lunga distanza meno simile a una macchina remota e più simile a un'estensione LAN lenta della workstation dell'artista. Nessuno è esotico; il valore sta nell'applicarli come stack e nel tarare i parametri sulle rotte che il traffico del cliente prende davvero.

Architettura per lunghe distanze

La forma di deployment che usiamo per configurazioni cross-country è una topologia hub-and-spoke, con un singolo datacenter primario come hub e uno o più siti secondari collegati via WireGuard site-to-site.

Topologia hub-and-spoke: Main DC e sito secondario

Alcune scelte in questa topologia meritano una nota perché si ripresentano a ogni installazione.

L'edge e la cache girano su una sola box, non su tre. La stessa macchina Ubuntu che termina WireGuard dall'esterno ospita anche la cache Samba, il DNS interno e il servizio tempo. Non separiamo questi ruoli su più macchine se non c'è una ragione specifica. Il right-sizing è deliberato. Una sola box di cache dedicata ha un percorso di rete in ingresso e uno in uscita, il che semplifica la matematica del routing. Rende anche le modalità di guasto più facili da ragionare — se la cache è su, i servizi interni sono su; se è giù, niente di interno funziona, e quel singolo segnale è più facile da allertare di tre segnali separati.

WireGuard site-to-site gestisce la sede secondaria. Quando il deployment si estende su due sedi fisiche — per esempio, un datacenter principale più una sede affittata più piccola nella stessa area metropolitana — le due sono collegate da un tunnel WireGuard site-to-site sull'ISP pubblico. Il traffico tra loro, dalla prospettiva dell'host, sembra una grande sottorete. Il gruppo render B nella sede secondaria legge la cache nel Main DC nello stesso modo del gruppo A, solo con più salti.

La rete è instradabile Layer-3. Ogni nodo è un host IP reale che gli altri nodi possono indirizzare direttamente. Non imponiamo un render manager particolare. I team che preferiscono Deadline possono gestire il proprio repository Deadline su un nodo coordinatore lato cliente; i team che preferiscono altro possono farlo. La farm fornisce host, rete, cache e stack di ottimizzazione; lo strato di orchestrazione sopra è scelta del cliente.

Per un percorso più approfondito, la guida operativa di deployment copre l'intera procedura passo passo, e l'approfondimento architetturale entra nel dettaglio del design di WireGuard e cache.

Ottimizzazione della banda e cache condivisa

La banda intercontinentale è costosa in due sensi: costa denaro sulla fattura di egress cloud e costa tempo quando gli artisti aspettano che un asset arrivi giù per il tubo. Un parco di rendering che non ci pensa può spendere una frazione significativa del wall-time di ogni job a scaricare a freddo file di scena che sono già in cache da qualche altra parte nell'edificio.

Il pattern della cache condivisa è la leva più semplice e più grande. Un server di cache Samba (SMB3) nel datacenter principale tiene gli asset di progetto. Ogni nodo di render monta la cache e legge i file di scena via LAN. Quando un nuovo asset è referenziato da un job, la cache lo scarica dallo storage cloud del cliente una sola volta. Ogni nodo successivo che ne ha bisogno lo legge dalla copia LAN. Un parco da 20 nodi che altrimenti scaricherebbe una scena da 40 GB venti volte, la scarica una sola volta.

In linea di principio è lineare. In pratica, due pezzi del design contano.

Evitare la cache per-nodo. È tentante dare a ogni nodo di render un proprio SSD locale capiente e lasciarlo cachare quello che vuole. Per un parco da 20 nodi con 10 TB di dati di progetto, questo diventa 200 TB di storage duplicato senza logica di invalidazione condivisa. Non lo facciamo. La cache condivisa è l'unica cache; i nodi trattano i dischi locali come spazio scratch, non come archivio di progetto.

Pre-riscaldare la cache prima del D-day. Quando un cliente annuncia che un progetto parte lunedì, pre-riscaldiamo la cache durante il weekend. Il primo job di lunedì legge da una cache calda invece di innescare venti ore di pull a freddo. È il metodo più affidabile per far sentire veloce il primo render di un progetto.

Una nota sul right-sizing: la box di cache usa un singolo SSD SATA con filesystem ext4. Per una cache (rispetto allo storage primario), un layout a disco singolo è il compromesso corretto. La cache non è la fonte di verità — lo è lo storage cloud del cliente — e la cache può essere ricostruita ri-scaricando dal cloud o tramite rsync da un backup di progetto. Costruire un array ridondante su un volume cifrato aggiungerebbe costo e complessità senza cambiare la storia operativa; un nodo che perde la cache è una ricostruzione di una serata, non un evento di perdita dati. Dimensionare l'hardware di cache per il suo ruolo è uno dei modi più facili per mantenere il costo operazionale irrecuperabile prevedibile.

Per team che valutano un cluster permanente piuttosto che un singolo deployment cross-country, la pagina dedicated cluster options copre quell'assetto in dettaglio.

Caratteristiche di prestazione e adeguatezza

Caratteristiche di prestazione e adeguatezza

Le render farm cross-country non sono un'opzione universalmente migliore. Hanno senso per uno specifico tipo di flusso di lavoro e presentano compromessi prevedibili rispetto a una farm locale.

Qualità di stream per il lavoro 3D remoto

Per artisti che devono pilotare un nodo GPU in modo interattivo — per esempio, aprire una scena Cinema 4D con Redshift, fare preview IPR, o inquadrare render prima di inviare job completi — usiamo Moonlight come client e Sunshine come host. Entrambi usano la codifica hardware NVENC sulla GPU del nodo di render, il che produce uno stream notevolmente più fluido dei protocolli di desktop remoto codificati via software. Il video codificato su un link a lunga distanza tarato fornisce un'esperienza utilizzabile per lavoro reale, inclusa l'interazione di viewport ad alto dettaglio; lo stesso carico su RDP semplice spesso no. Parsec è configurato come fallback per i rari casi in cui Sunshine non riesce a negoziare una sessione.

Profilo di latenza, in termini generali

Un link intercontinentale ben tarato si attesta tipicamente sui 150-250 ms di round-trip. Il numero dipende dalla separazione geografica e dalla rotta che il traffico del cliente prende effettivamente. Non pubblichiamo una latenza specifica per coppia di città su questa pagina perché non si generalizza — il vostro stesso ISP, il vostro stesso peering e i vostri stessi hop locali dominano l'esperienza quanto qualsiasi numero potessimo citare. Possiamo eseguire una sonda da un endpoint candidato durante la fase di pianificazione e condividere le misurazioni effettive per la rotta che il vostro team userà.

Testato a dimensioni di parco significative

I nostri deployment cross-country hanno girato a scala di cluster da 20 nodi con GPU consumer di generazione attuale (hardware classe RTX 5090), con storage di progetto sulla piattaforma cloud del cliente. È circa la scala oltre la quale le scelte architetturali delle sezioni precedenti iniziano a contare — su parchi più piccoli, un setup meno ottimizzato può cavarsela con più.

Quando è il fit giusto

Il rendering cross-country è il fit giusto quando gli artisti sono distribuiti e il parco di rendering deve essere da qualche parte, quando i dati di progetto vivono già in una specifica regione cloud, quando il cliente ha bisogno di infrastruttura IP-isolata che le opzioni locali non possono fornire, o quando la disponibilità o il costo delle GPU favorisce una particolare regione.

Quando una farm locale è un fit migliore

Se tutti nel team lavorano dallo stesso ufficio o paese del parco di rendering, le ottimizzazioni di questa pagina sono per lo più overhead inutile. Una farm locale con tubi più corti e routing più semplice sarà più facile da operare e non beneficerà di BBR o del clamping MSS allo stesso modo. La contro-posizionamento onesto conta: non ogni team ha bisogno di questa architettura. Per carichi dove artisti e hardware di render possono stare nella stessa regione, la pagina standard render farm rental options copre bene il caso.

Domande frequenti

In termini generali, link a lunga distanza ben tarati si situano tra 150 e 250 millisecondi di round-trip, con il numero esatto che dipende dall'ISP dell'artista, dalla rotta che il traffico prende e dall'ubicazione geografica dell'endpoint. Possiamo eseguire una sonda da una workstation candidata durante la pianificazione e condividere i numeri effettivamente misurati per la vostra rotta.

Il controllo della congestione BBR è la mitigazione principale — mantiene il throughput stabile quando il link ha jitter, invece di collassare sulla perdita di pacchetti come fa CUBIC di default. WireGuard stesso è anche indulgente verso brevi interruzioni di rete perché non mantiene uno stato di sessione come un tunnel IPsec. Per cadute a livello ISP, il tunnel si riconnette appena la rotta upstream è ripristinata; i job di render in corso continuano lato farm indipendentemente dallo stato della connessione dell'artista.

Sì. Ogni link è cifrato WireGuard: endpoint artista verso il datacenter principale e site-to-site tra il Main DC e qualsiasi sito secondario. Non esiste un punto sull'internet pubblico in cui un osservatore possa leggere traffico in chiaro tra il vostro team e il parco di rendering. Non richiediamo fiducia in alcun trasporto intermedio; la cifratura è sul layer WireGuard, non aggiunta come opzione sopra.

Sì. L'hub WireGuard accetta peer multipli, quindi qualsiasi numero di artisti da qualsiasi numero di sedi può connettersi alla stessa farm contemporaneamente. Ogni artista esegue il client WireGuard sulla propria workstation, apre Moonlight e si connette al nodo di render che gli è stato assegnato. Servizi interni come cache e DNS sono condivisi sul parco, così due artisti che lavorano sulla stessa scena da continenti diversi vedono lo stesso set di asset.

Attraverso la cache SMB condivisa. Quando un job di render referenzia un asset che la cache non ha ancora visto, la cache lo scarica dallo storage cloud del cliente una sola volta. I nodi successivi che hanno bisogno dello stesso asset lo leggono dalla cache via LAN a velocità di linea, non sul link intercontinentale. Per progetti con date di inizio prevedibili, pre-riscaldiamo la cache prima del D-day in modo che il primo render del progetto benefici di una cache calda invece di innescare una cascata di pull a freddo.

Funziona allo stesso modo; la separazione geografica significa solo che il pull iniziale nella cache richiede più tempo che con storage in-regione. Una volta che un asset è in cache, la separazione geografica non conta più — i nodi di render leggono via LAN. In questo scenario di solito pre-riscaldiamo la cache così che il pull cross-regione avvenga dalla nostra parte prima che il progetto inizi, non durante il primo render.

La residenza dei dati dipende da dove il parco di rendering stesso è provisionato, cosa che pianifichiamo con il cliente in anticipo. Per team con requisiti di residenza specifici, la conversazione deve coprire dove sono tenuti i dati di progetto, dove sono prodotti i render, dove sono memorizzati i log e come i dati sono cancellati a fine ingaggio. È una conversazione di pianificazione piuttosto che una risposta singola sì-o-no; vi preghiamo di contattarci per discutere le specifiche del vostro caso.

Il render in sé continua. I job di render girano lato farm indipendentemente dallo stato del tunnel dell'artista — una volta che un job è distribuito, l'artista può disconnettersi completamente e i frame continuano a essere prodotti. Quando il tunnel torna, l'artista ristabilisce il suo peer WireGuard e si riconnette via Moonlight alla stessa sessione. La conseguenza pratica più frequente di una caduta di tunnel a metà render è che l'artista non può monitorare il progresso in tempo reale per la durata del disservizio; il render in sé non riparte.

Prossimi passi

Prossimi passi