Skip to main content

Cross-Country render farm: flujos de renderizado optimizados para larga distancia

Cifrado WireGuard · Control de congestión BBR · Caché compartida · Para equipos creativos distribuidos globalmente.

Solicitar despliegue cross-countryVer la arquitectura

Por qué el renderizado cross-country es diferente

El trabajo creativo moderno está cada vez más distribuido. Un pipeline 3D puede tener un director de arte en Nueva York, un equipo de iluminación en Berlín, artistas look-dev freelance en Seúl y una render farm en otro continente. Cuando los cuatro están en la misma LAN gigabit, el acceso a la render farm no es problema. Cuando no lo están, el flujo de trabajo pasa por internet público y cada peculiaridad del enrutado de larga distancia acaba apareciendo en el calendario.

Tres problemas recurren en este tipo de configuración. El primero es la latencia — tiempos de ida y vuelta de 150 a 250 ms entre continentes cambian la sensación de un escritorio remoto y amplifican cualquier verbosidad en un gestor de renderizado o un protocolo de streaming de assets. El segundo es el jitter — los enlaces internacionales suelen ir al límite y el timing de paquetes varía. El tercero es el coste y la contención de ancho de banda — descargar una escena de 40 GB a través de un enlace intercontinental una vez es aceptable; descargarla veinte veces porque cada nodo de render tiene su propia caché no lo es.

Una render farm local evita la mayoría de esto. Los equipos que ya tienen un clúster en la misma región del datacenter que sus artistas no necesitan la mayor parte de lo que describe esta página. El renderizado cross-country se convierte en la elección arquitectónica correcta cuando se cumple alguna de las siguientes:

  • El equipo está repartido entre regiones y necesita un único parque de render compartido.
  • La disponibilidad o el coste del hardware hace que la clase de GPU deseada sea más fácil de obtener en una región que en otra.
  • El equipo de artistas está desacoplado del hardware de render a propósito — por ejemplo, un estudio de Estados Unidos alquilando capacidad dedicada en Asia para un proyecto específico.
  • El almacenamiento en la nube y los archivos del proyecto ya residen en una región, y el parque de render debe leer de allí en cualquier caso.

Cuando alguna de estas condiciones es cierta, la pregunta se vuelve operativa: cómo hacer que una render farm al otro lado del mundo se comporte como parte de la red local del artista. El resto de esta página describe cómo lo abordamos en Super Renders Farm.

Pila de optimización de red

Pila de optimización de red

Optimizamos los enlaces cross-country con cuatro piezas, aplicadas juntas en vez de una a una.

WireGuard para transporte cifrado de larga distancia

Cada conexión de un endpoint del cliente hacia la render farm pasa por WireGuard. La máquina del cliente se convierte en un peer WireGuard; el datacenter principal opera un hub. El cifrado es automático y extremo a extremo; el cliente no ve tráfico en claro en internet público, y nosotros tampoco. WireGuard también es lo bastante ligero para no convertirse en cuello de botella en un enlace de larga distancia — su overhead es notablemente menor que el de una pila IPsec tradicional.

TCP BBR para el control de congestión

El control de congestión por defecto del kernel Linux (CUBIC) es conservador ante jitter y pérdida de paquetes — interpreta la pérdida como señal para reducir velocidad, incluso cuando esa pérdida viene de enrutado internacional intermitente y no de congestión real. BBR (Bottleneck Bandwidth and RTT) mide el producto ancho-de-banda × retardo real del enlace y mantiene el tubo lleno cuando hay capacidad disponible. En una ruta transcontinental estable, BBR suele entregar dos a tres veces el throughput de CUBIC con el mismo hardware. En una ruta con jitter, la diferencia es mayor.

Clamping MSS TCP para evitar agujeros negros de MTU

Cuando un paquete viaja por un túnel como WireGuard, su MTU efectiva es menor que en la interfaz subyacente. Si una conexión TCP negocia un MSS mayor de lo que el túnel puede transportar, ocurren dos cosas: los paquetes pequeños pasan, los paquetes grandes se pierden silenciosamente. El síntoma es de los más frustrantes en trabajo remoto — SSH funciona, ping funciona, pero los handshakes TLS, las sesiones RDP y las copias SMB de tamaño significativo se cuelgan todas. Aplicamos clamping de MSS en el gateway WireGuard para que todas las conexiones TCP negocien un tamaño de segmento que el túnel pueda entregar realmente.

Servicios internos de DNS y tiempo

Dentro de la farm operamos `dnsmasq` para resolución DNS interna y `chrony` para el tiempo. Son piezas de infraestructura discretas que importan más de lo que parecen. El DNS interno hace que los nodos de render referencien la caché compartida como `cache.lan` en lugar de una dirección IP, lo que hace seguro reorganizar la topología. La sincronización horaria importa porque la mayoría de los gestores de render y pipelines de logs toleran mal el desvío de reloj — un nodo desfasado 30 segundos respecto al resto del parque puede producir un comportamiento confuso de asignación de trabajos. Ambos servicios escuchan solo en la red interna; nada de internet público les habla directamente.

Juntas, estas cuatro piezas hacen que una render farm de larga distancia se parezca menos a una máquina remota y más a una extensión LAN lenta del puesto del artista. Ninguna es exótica; el valor está en aplicarlas como pila y ajustar los parámetros a las rutas que el tráfico del cliente toma realmente.

Arquitectura para larga distancia

La forma de despliegue que usamos para configuraciones cross-country es una topología hub-and-spoke, con un único datacenter principal como hub y uno o más sitios secundarios conectados por WireGuard sitio-a-sitio.

Topología hub-and-spoke: Main DC y sitio secundario

Algunas decisiones de esta topología merecen mención porque se repiten en cada montaje.

El edge y la caché corren en una sola caja, no en tres. La misma máquina Ubuntu que termina WireGuard desde el exterior también aloja la caché Samba, el DNS interno y el servicio de tiempo. No separamos estos roles en varias máquinas salvo que haya una razón concreta. El right-sizing es deliberado. Una sola caja de caché dedicada tiene un camino de red de entrada y otro de salida, lo que simplifica el cálculo de enrutado. También hace los modos de fallo más fáciles de razonar — si la caché está arriba, los servicios internos lo están; si no, nada interno funciona, y esa señal única es más fácil de alertar que tres señales separadas.

WireGuard sitio-a-sitio gestiona la ubicación secundaria. Cuando el despliegue se extiende a dos ubicaciones físicas — por ejemplo, un datacenter principal más un sitio alquilado más pequeño en la misma metrópoli — los dos están conectados por un túnel WireGuard sitio-a-sitio sobre el ISP público. El tráfico entre ellos, desde la perspectiva del host, se ve como una subred grande. El grupo de render B en el sitio secundario lee la caché del Main DC igual que el grupo A, solo con más saltos.

La red es enrutable a nivel Layer-3. Cada nodo es un host IP real al que otros nodos pueden direccionar directamente. No imponemos un gestor de render concreto. Los equipos que prefieren Deadline pueden operar su propio repositorio Deadline en un nodo coordinador del cliente; los equipos que prefieren otra cosa pueden hacerlo. La farm aporta los hosts, la red, la caché y la pila de optimización; la capa de orquestación encima es elección del cliente.

Para un recorrido más profundo, la guía operativa de despliegue cubre todo el procedimiento paso a paso, y el análisis arquitectónico entra en más detalle del diseño WireGuard y caché.

Optimización de ancho de banda y caché compartida

El ancho de banda intercontinental es caro en dos sentidos: cuesta dinero en la factura de salida de la nube y cuesta tiempo cuando los artistas esperan que un asset baje por el tubo. Un parque de render que no piensa en esto puede gastar una fracción significativa del wall-time de cada trabajo descargando en frío archivos de escena que ya están en caché en otro lugar del edificio.

El patrón de caché compartida es la palanca más simple y mayor. Un servidor de caché Samba (SMB3) en el datacenter principal guarda los assets del proyecto. Cada nodo de render monta la caché y lee los archivos de escena por LAN. Cuando un nuevo asset es referenciado por un trabajo, la caché lo descarga del almacenamiento en la nube del cliente una sola vez. Cualquier nodo subsiguiente que lo necesite lo lee de la copia LAN. Un parque de 20 nodos que de otra forma descargaría una escena de 40 GB veinte veces, la descarga una.

En principio es directo. En la práctica, dos piezas del diseño importan.

Evitar caché por nodo. Es tentador dar a cada nodo de render su propio SSD local grande y dejar que cachee lo que quiera. Para un parque de 20 nodos con 10 TB de datos del proyecto, eso son 200 TB de almacenamiento duplicado sin lógica de invalidación compartida. No lo hacemos. La caché compartida es la única caché; los nodos tratan sus discos locales como scratch, no como archivo del proyecto.

Precalentar la caché antes del día D. Cuando un cliente anuncia que un proyecto empieza el lunes, precalentamos la caché durante el fin de semana. El primer trabajo del lunes lee de una caché caliente en vez de disparar veinte horas de descargas en frío. Es el método más fiable para que el primer renderizado del proyecto sienta rapidez.

Una nota sobre right-sizing: la caja de caché usa un SSD SATA único con sistema de archivos ext4. Para una caché (frente al almacenamiento primario), un layout mono-disco es el compromiso correcto. La caché no es la fuente de verdad — lo es el almacenamiento en la nube del cliente — y la caché puede reconstruirse re-descargando de la nube o por rsync desde un backup del proyecto. Montar un arreglo redundante sobre un volumen cifrado añadiría coste y complejidad sin cambiar la historia operativa; un nodo que pierde la caché es una reconstrucción de una tarde, no un evento de pérdida de datos. Dimensionar el hardware de caché para su rol es de las formas más fáciles de mantener el coste de operación predecible.

Para equipos que consideran un clúster permanente en vez de un único despliegue cross-country, la página dedicated cluster options cubre ese arreglo en detalle.

Características de rendimiento y encaje

Características de rendimiento y encaje

Las render farms cross-country no son una opción universalmente mejor. Tienen sentido para un tipo específico de flujo de trabajo y presentan compromisos predecibles frente a una farm local.

Calidad de stream para trabajo 3D remoto

Para artistas que deben pilotar un nodo GPU de forma interactiva — por ejemplo, abrir una escena Cinema 4D con Redshift, hacer previews IPR o encuadrar renders antes de enviar trabajos completos — usamos Moonlight como cliente y Sunshine como host. Ambos usan codificación por hardware NVENC en la GPU del nodo de render, lo que produce un stream notablemente más fluido que los protocolos de escritorio remoto codificados por software. El vídeo codificado sobre un enlace de larga distancia ajustado entrega una experiencia usable para trabajo real, incluida la interacción con el viewport en alta densidad; la misma carga sobre RDP simple frecuentemente no. Parsec se configura como fallback para los raros casos en que Sunshine no logra negociar una sesión.

Perfil de latencia, en términos generales

Un enlace intercontinental bien ajustado suele situarse entre 150 y 250 ms de ida y vuelta. La cifra depende de la separación geográfica y de la ruta que el tráfico del cliente toma realmente. No publicamos una latencia específica par-de-ciudades en esta página porque no se generaliza — su propio ISP, su propio peering y sus propios saltos locales dominan la experiencia tanto como cualquier número que pudiéramos citar. Podemos ejecutar una sonda desde un endpoint candidato durante la planificación y compartir las mediciones reales de la ruta que su equipo usará.

Probado a tamaños de parque significativos

Nuestros despliegues cross-country han operado a escala de clúster 20-nodos con GPUs de consumo de generación actual (hardware clase RTX 5090), con almacenamiento del proyecto en la propia plataforma cloud del cliente. Es aproximadamente la escala a partir de la cual las decisiones arquitectónicas de las secciones anteriores empiezan a importar — en parques más pequeños, un montaje menos optimizado puede tirar.

Cuándo es el encaje correcto

El renderizado cross-country encaja cuando los artistas están distribuidos y el parque de render debe estar en alguna parte, cuando los datos del proyecto ya viven en una región cloud específica, cuando el cliente necesita infraestructura aislada en IP que las opciones locales no pueden proveer, o cuando la disponibilidad o el coste de GPUs favorece una región particular.

Cuándo una farm local encaja mejor

Si todo el equipo trabaja desde la misma oficina o país que el parque de render, las optimizaciones de esta página son sobre todo overhead innecesario. Una farm local con tubos más cortos y enrutado más simple será más fácil de operar y no se beneficiará de BBR o del clamping MSS de la misma forma. La contraposición honesta importa: no todo equipo necesita esta arquitectura. Para cargas donde artistas y hardware de render pueden estar en la misma región, la página estándar render farm rental options cubre bien el caso.

Preguntas frecuentes

En términos generales, los enlaces de larga distancia bien ajustados se sitúan entre 150 y 250 milisegundos de ida y vuelta, dependiendo del ISP del artista, la ruta del tráfico y la ubicación geográfica del endpoint. Podemos ejecutar una sonda desde un puesto candidato durante la planificación y compartir las cifras realmente medidas para su ruta.

El control de congestión BBR es la mitigación principal — mantiene el throughput estable cuando el enlace tiene jitter, en vez de colapsar ante la pérdida de paquetes como hace CUBIC por defecto. El propio WireGuard también es tolerante a breves cortes de red porque no mantiene estado de sesión como un túnel IPsec. Para caídas a nivel ISP, el túnel se reconecta en cuanto la ruta upstream vuelve; los trabajos de render en curso continúan del lado de la farm independientemente del estado de la conexión del artista.

Sí. Cada enlace está cifrado con WireGuard: endpoint del artista al datacenter principal y sitio-a-sitio entre el Main DC y cualquier sitio secundario. No hay ningún punto en internet público donde un observador pueda leer tráfico en claro entre su equipo y el parque de render. No requerimos confianza en ningún transporte intermedio; el cifrado vive en la capa WireGuard, no como añadido opcional encima.

Sí. El hub WireGuard acepta múltiples peers, así que cualquier número de artistas desde cualquier número de ubicaciones puede conectarse a la misma farm a la vez. Cada artista ejecuta el cliente WireGuard en su puesto, abre Moonlight y se conecta al nodo de render que le ha sido asignado. Los servicios internos como caché y DNS se comparten en el parque, así que dos artistas trabajando en la misma escena desde continentes distintos ven el mismo conjunto de assets.

A través de la caché SMB compartida. Cuando un trabajo de render referencia un asset que la caché aún no ha visto, la caché lo descarga del almacenamiento en la nube del cliente una vez. Los nodos siguientes que necesiten el mismo asset lo leen de la caché por LAN a velocidad de línea, no por el enlace intercontinental. Para proyectos con fechas de inicio predecibles, precalentamos la caché antes del día D para que el primer renderizado del proyecto se beneficie de una caché caliente en lugar de disparar una cascada de descargas en frío.

Funciona de la misma forma; la separación geográfica solo significa que la descarga inicial a la caché tarda más que con almacenamiento en la misma región. Una vez el asset está en la caché, la separación geográfica deja de importar — los nodos de render leen por LAN. En este escenario solemos precalentar la caché para que la descarga cross-región ocurra en nuestro lado antes de que el proyecto empiece, no durante el primer render.

La residencia de datos depende de dónde se aprovisione el parque de render, lo que planificamos con el cliente con antelación. Para equipos con requisitos de residencia específicos, la conversación debe cubrir dónde se guardan los datos del proyecto, dónde se producen los renders, dónde se almacenan los logs y cómo se borran los datos al final del compromiso. Es una conversación de planificación, no una respuesta única de sí o no; por favor contáctenos para discutir las particularidades de su caso.

El render en sí continúa. Los trabajos de render se ejecutan del lado de la farm independientemente del estado del túnel del artista — una vez que un trabajo se ha distribuido, el artista puede desconectarse por completo y los frames se siguen produciendo. Cuando el túnel vuelve, el artista restablece su peer WireGuard y se reconecta vía Moonlight a la misma sesión. La consecuencia práctica más frecuente de una caída de túnel a mitad de render es que el artista no puede seguir el progreso en vivo durante la caída; el render en sí no se reinicia.

Próximos pasos

Próximos pasos