Skip to main content

Cross-Country render farm : workflows de rendu optimisés pour les longues distances

Chiffrement WireGuard · Contrôle de congestion BBR · Cache partagé · Pour les équipes créatives réparties dans le monde entier.

Demander un déploiement cross-countryVoir l'architecture

Pourquoi le rendu cross-country est différent

Le travail créatif moderne est de plus en plus distribué. Un pipeline 3D peut avoir un directeur artistique à New York, une équipe d'éclairage à Berlin, des artistes look-dev freelance à Séoul, et une render farm sur un autre continent encore. Quand les quatre sont sur le même LAN gigabit, l'accès à la render farm n'est pas un problème. Quand ce n'est pas le cas, le workflow passe par l'internet public, et chaque particularité du routage longue distance finit par apparaître dans le planning.

Trois problèmes reviennent dans ce type de configuration. Le premier est la latence — des temps d'aller-retour de 150 à 250 ms entre continents changent la sensation d'un bureau distant et amplifient la moindre verbosité d'un gestionnaire de rendu ou d'un protocole de streaming d'assets. Le second est la gigue — les liens internationaux sont souvent chargés, et le timing des paquets varie. Le troisième est le coût et la contention de bande passante — tirer une scène de 40 Go à travers un lien intercontinental une fois est acceptable ; la tirer vingt fois parce que chaque node de rendu a son propre cache ne l'est pas.

Une render farm locale contourne la majeure partie de cela. Les équipes qui ont déjà un cluster dans la même région de datacenter que leurs artistes n'ont pas besoin de la plupart de ce que décrit cette page. Le rendu cross-country devient le bon choix architectural quand l'une des conditions suivantes est vérifiée :

  • L'équipe est répartie entre régions et a besoin d'un parc de rendu partagé unique.
  • La disponibilité ou le coût du matériel rend la classe de GPU souhaitée plus facile à approvisionner dans une région que dans une autre.
  • L'équipe artistique est volontairement découplée du matériel de rendu — par exemple, un studio basé aux États-Unis qui loue de la capacité dédiée en Asie pour un projet précis.
  • Le stockage cloud et les fichiers projet vivent déjà dans une région, et le parc de rendu doit lire depuis ces emplacements de toute façon.

Quand l'une de ces conditions est vraie, la question devient opérationnelle : comment faire en sorte qu'une render farm de l'autre côté du monde se comporte comme une partie du réseau local de l'artiste. Le reste de cette page décrit notre approche chez Super Renders Farm.

Pile d'optimisation réseau

Pile d'optimisation réseau

Nous optimisons les liaisons cross-country avec quatre éléments appliqués ensemble plutôt que séparément.

WireGuard pour un transport longue distance chiffré

Chaque connexion d'un endpoint client vers la render farm passe par WireGuard. La machine du client devient un peer WireGuard ; le datacenter principal héberge un hub. Le chiffrement est automatique et de bout en bout ; le client ne voit pas de trafic en clair sur l'internet public, et nous non plus. WireGuard est aussi assez léger pour ne pas devenir le goulot d'étranglement sur un lien longue distance — son overhead est nettement plus faible que celui d'une pile IPsec classique.

TCP BBR pour le contrôle de congestion

Le contrôle de congestion par défaut du noyau Linux (CUBIC) est conservateur face à la gigue et aux pertes de paquets — il interprète la perte comme un signal de ralentissement, même quand cette perte vient du routage international intermittent et non d'une vraie congestion. BBR (Bottleneck Bandwidth and RTT) mesure le produit bande passante × délai réel du lien et garde le tuyau plein tant que de la capacité est disponible. Sur une route transcontinentale stable, BBR offre couramment deux à trois fois le débit de CUBIC pour le même matériel. Sur une route avec de la gigue, l'écart est plus grand.

Clamping MSS TCP pour éviter les trous noirs MTU

Quand un paquet traverse un tunnel comme WireGuard, son MTU effectif (Maximum Transmission Unit) est plus petit que celui de l'interface sous-jacente. Si une connexion TCP négocie un MSS (Maximum Segment Size) supérieur à ce que le tunnel peut transporter, deux choses arrivent : les petits paquets passent, les gros paquets sont silencieusement perdus. Le symptôme est l'un des plus frustrants en travail à distance — SSH fonctionne, ping fonctionne, mais les handshakes TLS, les sessions RDP et les copies de fichiers SMB de taille significative se bloquent toutes. Nous clampons le MSS au niveau du gateway WireGuard pour que toutes les connexions TCP négocient une taille de segment que le tunnel peut effectivement livrer.

Services DNS et de temps internes

À l'intérieur de la farm, nous faisons tourner `dnsmasq` pour la résolution DNS interne et `chrony` pour le temps. Ce sont des morceaux d'infrastructure discrets qui comptent plus qu'ils n'en ont l'air. Le DNS interne fait que les nodes de rendu désignent le cache partagé par `cache.lan` plutôt que par une adresse IP, ce qui rend la topologie sûre à réorganiser. La synchronisation horaire compte parce que la plupart des gestionnaires de rendu et des pipelines de logs tolèrent mal le décalage d'horloge — un node décalé de 30 secondes par rapport au reste du parc peut produire un comportement d'attribution de jobs déroutant. Les deux services écoutent uniquement sur le réseau interne ; rien depuis l'internet public ne leur parle directement.

Ensemble, ces quatre éléments rendent une render farm longue distance moins comparable à une machine distante et davantage à une extension LAN lente du poste de travail de l'artiste. Aucun n'est exotique ; la valeur vient de leur application en pile et du réglage des paramètres pour les routes que le trafic client emprunte réellement.

Architecture pour les longues distances

La forme de déploiement que nous utilisons pour les configurations cross-country est une topologie hub-and-spoke, avec un seul datacenter principal comme hub et un ou plusieurs sites secondaires reliés par WireGuard site-à-site.

Topologie hub-and-spoke : Main DC et site secondaire

Quelques décisions dans cette topologie méritent d'être soulignées car elles reviennent à chaque mise en place.

L'edge et le cache tournent sur une seule boîte, pas trois. La même machine Ubuntu qui termine WireGuard depuis l'extérieur héberge aussi le cache Samba, le DNS interne et le service de temps. Nous ne séparons pas ces rôles sur plusieurs machines sans raison spécifique. Le right-sizing est délibéré. Une seule boîte de cache dédiée a un chemin réseau en entrée et un en sortie, ce qui simplifie le calcul de routage. Cela rend aussi les modes de défaillance plus simples à raisonner — si le cache est en marche, les services internes le sont ; s'il est en panne, rien d'interne ne fonctionne, et ce signal unique est plus facile à monitorer que trois signaux séparés.

WireGuard site-à-site gère l'emplacement secondaire. Quand le déploiement s'étend sur deux sites physiques — par exemple, un datacenter principal plus un site loué plus petit dans la même métropole — les deux sont reliés par un tunnel WireGuard site-à-site sur l'ISP public. Le trafic entre eux ressemble, du point de vue de l'hôte, à un grand sous-réseau. Le groupe de rendu B au site secondaire lit le cache du Main DC de la même manière que le groupe A, juste avec plus de sauts.

Le réseau est routable Layer-3. Chaque node est un véritable hôte IP que les autres nodes peuvent adresser directement. Nous n'imposons pas de gestionnaire de rendu particulier. Les équipes qui préfèrent Deadline peuvent faire tourner leur propre dépôt Deadline sur un node coordinateur côté client ; les équipes qui préfèrent autre chose peuvent le faire. La farm fournit les hôtes, le réseau, le cache et la pile d'optimisation ; la couche d'orchestration au-dessus est le choix du client.

Pour une marche plus profonde, le guide opérationnel de déploiement couvre la procédure complète étape par étape, et l'analyse architecturale approfondie entre dans le détail de la conception WireGuard et cache.

Optimisation de la bande passante et cache partagé

La bande passante intercontinentale est chère dans deux sens : elle coûte de l'argent sur la facture de sortie cloud, et elle coûte du temps quand les artistes attendent qu'un asset descende le tuyau. Un parc de rendu qui n'y pense pas peut passer une fraction significative du wall-time de chaque job à tirer à froid des fichiers de scène déjà présents en cache ailleurs dans le bâtiment.

Le modèle de cache partagé est le levier le plus simple et le plus important. Un serveur de cache Samba (SMB3) dans le datacenter principal détient les assets du projet. Chaque node de rendu monte le cache et lit les fichiers de scène en LAN. Quand un nouvel asset est référencé par un job, le cache le tire du stockage cloud du client une seule fois. Chaque node suivant qui en a besoin le lit depuis la copie LAN. Un parc de 20 nodes qui tirerait sinon une scène de 40 Go vingt fois la tire une seule fois.

C'est simple en principe. En pratique, deux éléments de conception comptent.

Éviter le caching par node. Il est tentant de donner à chaque node de rendu son propre grand SSD local et de le laisser cacher ce qu'il veut. Pour un parc de 20 nodes avec 10 To de données projet, cela devient 200 To de stockage dupliqué sans logique d'invalidation partagée. Nous ne faisons pas cela. Le cache partagé est le seul cache ; les nodes traitent leurs disques locaux comme espace scratch, pas comme archive projet.

Préchauffer le cache avant le J. Quand un client annonce qu'un projet démarre lundi, nous préchauffons le cache durant le week-end. Le premier job du lundi lit depuis un cache chaud au lieu de déclencher vingt heures de pulls à froid. C'est la méthode la plus fiable pour rendre le premier rendu d'un projet rapide.

Une remarque sur le right-sizing : la boîte de cache utilise un SSD SATA unique avec un système de fichiers ext4. Pour un cache (par opposition au stockage primaire), un layout mono-disque est le bon compromis. Le cache n'est pas la source de vérité — le stockage cloud du client l'est — et le cache peut être reconstruit en re-tirant depuis le cloud ou en rsync depuis une sauvegarde projet. Construire une grappe redondante sur un volume chiffré ajouterait du coût et de la complexité sans changer l'histoire opérationnelle ; un node qui perd le cache est une reconstruction d'une soirée, pas un événement de perte de données. Dimensionner le matériel de cache pour son rôle est l'une des manières les plus faciles de garder le coût d'exploitation prévisible.

Pour les équipes qui envisagent un cluster permanent plutôt qu'un déploiement cross-country unique, la page dedicated cluster options couvre cet arrangement en détail.

Caractéristiques de performance et adéquation

Caractéristiques de performance et adéquation

Les render farms cross-country ne sont pas une meilleure option universelle. Elles ont du sens pour un type spécifique de workflow et présentent des compromis prévisibles par rapport à une farm locale.

Qualité de streaming pour le travail 3D distant

Pour les artistes qui doivent piloter un node GPU de manière interactive — par exemple, ouvrir une scène Cinema 4D avec Redshift, faire des previews IPR, ou cadrer des rendus avant de soumettre des jobs complets — nous utilisons Moonlight comme client et Sunshine comme hôte. Les deux utilisent l'encodage matériel NVENC sur le GPU du node de rendu, ce qui produit un flux notablement plus fluide que les protocoles de bureau distant encodés en logiciel. La vidéo encodée sur un lien longue distance tuné délivre une expérience utilisable pour du vrai travail, y compris l'interaction de viewport en haute densité ; la même charge sur du RDP simple souvent non. Parsec est configuré comme fallback pour les cas rares où Sunshine peine à négocier une session.

Profil de latence, en termes généraux

Un lien intercontinental bien réglé arrive typiquement à 150 à 250 ms d'aller-retour. Le chiffre dépend de la séparation géographique et de la route que le trafic du client emprunte effectivement. Nous ne publions pas de latence spécifique paire-de-villes sur cette page parce que ça ne se généralise pas — votre propre ISP, votre propre peering et vos propres hops locaux dominent l'expérience autant que tout chiffre que nous pourrions citer. Nous pouvons faire tourner une sonde depuis un endpoint candidat pendant la phase de planification et partager les mesures réelles pour la route que votre équipe utilisera.

Testé à des tailles de parc significatives

Nos déploiements cross-country ont tourné à l'échelle de cluster 20-nodes avec des GPU consumer de génération actuelle (matériel de classe RTX 5090), avec stockage projet sur la propre plateforme cloud du client. C'est à peu près l'échelle à laquelle les choix architecturaux des sections précédentes commencent à compter — sur des parcs plus petits, un setup moins optimisé peut s'en sortir avec plus.

Quand c'est le bon choix

Le rendu cross-country est le bon choix quand les artistes sont distribués et que le parc de rendu doit être quelque part, quand les données projet vivent déjà dans une région cloud spécifique, quand le client a besoin d'une infrastructure isolée IP que les options locales ne peuvent pas fournir, ou quand la disponibilité ou le coût des GPU favorise une région particulière.

Quand une farm locale est un meilleur choix

Si tout le monde dans l'équipe travaille depuis le même bureau ou pays que le parc de rendu, les optimisations de cette page sont essentiellement de l'overhead inutile. Une farm locale avec des tuyaux plus courts et un routage plus simple sera plus facile à exploiter et ne bénéficiera pas de BBR ou du clamping MSS de la même manière. La contre-positionnement honnête compte : toutes les équipes n'ont pas besoin de cette architecture. Pour les workloads où artistes et matériel de rendu peuvent se trouver dans la même région, la page standard render farm rental options couvre bien le cas.

Questions fréquentes

En termes généraux, les liens longue distance bien réglés se situent entre 150 et 250 millisecondes d'aller-retour, le chiffre exact dépendant de l'ISP de l'artiste, de la route que prend le trafic et de l'emplacement géographique de l'endpoint. Nous pouvons faire tourner une sonde depuis un poste candidat pendant la planification et partager les chiffres effectivement mesurés pour votre route.

Le contrôle de congestion BBR est la mesure principale — il maintient le débit stable quand le lien a de la gigue, plutôt que de s'effondrer sur la perte de paquets comme le fait CUBIC par défaut. WireGuard lui-même est aussi indulgent vis-à-vis des brèves coupures réseau parce qu'il ne maintient pas d'état de session comme un tunnel IPsec. Pour les pannes au niveau ISP, le tunnel se reconnecte dès que la route en amont est rétablie ; les jobs de rendu en cours continuent côté farm indépendamment de l'état de la connexion de l'artiste.

Oui. Chaque lien est chiffré par WireGuard : endpoint artiste vers le datacenter principal, et site-à-site entre le Main DC et tout site secondaire. Il n'existe aucun point sur l'internet public où un observateur peut lire du trafic en clair entre votre équipe et le parc de rendu. Nous ne demandons pas de confiance dans un quelconque transport intermédiaire ; le chiffrement est sur la couche WireGuard, pas posé en option dessus.

Oui. Le hub WireGuard accepte plusieurs peers, donc n'importe quel nombre d'artistes depuis n'importe quel nombre d'emplacements peuvent se connecter à la même farm en même temps. Chaque artiste fait tourner le client WireGuard sur son poste, ouvre Moonlight, et se connecte au node de rendu qui lui a été assigné. Les services internes comme le cache et le DNS sont partagés à travers le parc, donc deux artistes travaillant sur la même scène depuis des continents différents voient le même ensemble d'assets.

Par le cache SMB partagé. Quand un job de rendu référence un asset que le cache n'a pas encore vu, le cache le tire du stockage cloud du client une seule fois. Les nodes suivants qui ont besoin du même asset le lisent depuis le cache en LAN à pleine vitesse, pas sur le lien intercontinental. Pour les projets avec dates de démarrage prévisibles, nous préchauffons le cache avant le J pour que le premier rendu du projet bénéficie d'un cache chaud plutôt que de déclencher une cascade de pulls à froid.

Cela fonctionne de la même manière ; la séparation géographique signifie juste que le pull initial dans le cache prend plus de temps que pour du stockage en région. Une fois qu'un asset est dans le cache, la séparation géographique ne compte plus — les nodes de rendu lisent en LAN. Nous préchauffons typiquement le cache dans ce scénario pour que le pull cross-région se produise de notre côté avant que le projet commence plutôt que pendant le premier rendu.

La résidence des données dépend de l'endroit où le parc de rendu lui-même est provisionné, ce que nous planifions avec le client à l'avance. Pour les équipes avec des exigences de résidence spécifiques, la conversation doit couvrir où les données projet sont conservées, où les rendus sont produits, où les logs sont stockés et comment les données sont effacées en fin d'engagement. C'est une conversation de planification plutôt qu'une réponse oui-ou-non unique ; veuillez nous contacter pour discuter des spécificités de votre cas.

Le rendu lui-même continue. Les jobs de rendu tournent côté farm indépendamment de l'état du tunnel de l'artiste — une fois qu'un job est distribué, l'artiste peut se déconnecter complètement et les frames continuent d'être produites. Quand le tunnel revient, l'artiste rétablit son peer WireGuard et se reconnecte via Moonlight à la même session. La conséquence pratique la plus fréquente d'une coupure de tunnel en plein rendu est que l'artiste ne peut pas suivre la progression en direct pour la durée de la panne ; le rendu lui-même ne redémarre pas.

Prochaines étapes

Prochaines étapes