Despliegue de render farm intercontinental: seis lecciones de campo en 2026

Introducción: los diagramas de arquitectura mienten, los logs de producción no

Plano de arquitectura limpio frente a la caótica realidad de producción

Hay una distancia entre el diagrama de arquitectura que dibujas en un documento de planificación y el sistema que realmente corre renderizados para un cliente un martes por la tarde. Cada render farm intercontinental que hemos desplegado ha cerrado esa distancia por las malas — a través de comandos que nos dejaron bloqueados fuera de nuestra propia gateway, a través de consultas DNS que expiraron silenciosamente mientras ICMP decía que la red estaba bien, a través de handshakes TCP que se completaron limpiamente y se cayeron en el momento en que un paquete grande intentó cruzar el túnel.

Este artículo no es un tutorial sobre cómo construir una render farm. Es un registro de lo que realmente hemos roto y arreglado desplegando clusters GPU dedicados para clientes cuyos artistas trabajan en un país mientras el hardware corre en otro. Las lecciones aquí son deliberadamente operativas, no arquitectónicas. Son el tipo de cosa que no aparece en la página de producto de un proveedor y rara vez llega a una charla pública de conferencia, porque se leen menos como ingeniería y más como notas de campo.

Llevamos operando una fully managed cloud render farm en Super Renders Farm más de una década. Cuando los equipos necesitan un cluster dedicado que abarque continentes — artistas a un lado, GPU al otro — estas son las seis lecciones que habríamos querido leer antes de nuestro primer despliegue en vez de después del tercero. También incluimos una sección honesta de contra-lecciones: los componentes que probamos, descartamos o deliberadamente no desplegamos. Lee este artículo junto a nuestra guía operativa completa y nuestro análisis profundo de arquitectura si quieres el cuadro completo.

Lección 1: la trampa de enrutamiento de una gateway dual-home

La primera vez que desplegamos una máquina gateway con dos interfaces de red — una hacia Internet público, otra hacia la LAN interna — cambiamos la ruta por defecto antes de haber fijado la ruta interna. En tres segundos, nuestra sesión SSH cayó. No pudimos reconectar. La máquina estaba en un rack de datacenter sin consola fuera de banda, y la única vía de vuelta era un ticket remote-hands.

Esta es la trampa de enrutamiento de una gateway dual-home, y ha mordido a cada operador que conocemos al menos una vez. La mecánica es simple: cuando una máquina tiene dos NIC, hay que decirle al kernel qué gateway atiende qué red. Si cambias la ruta por defecto para apuntar a la interfaz pública (para que el tráfico externo salga por el endpoint WireGuard, la salida NAT o lo que tu diseño exija), y aún no has fijado la ruta para la LAN interna, tu sesión SSH — que entra por la LAN interna — de repente no tiene ruta de vuelta. Cada paquete que envías de vuelta a tu portátil intenta salir por la interfaz pública, es descartado por el router upstream porque la IP de origen no tiene sentido desde esa dirección, y tu terminal se queda colgada.

El fix es mecánico: fija siempre primero la ruta interna, después cambia la por defecto. En una gateway Linux con Ubuntu 22.04, esa secuencia se ve aproximadamente así. Primero, añades una ruta explícita para la subred LAN vía la gateway del lado LAN. Luego, y solo entonces, cambias la ruta por defecto a lo que tu diseño de egress requiera.

# Paso 1: fijar la ruta LAN interna vía la gateway del lado LAN
sudo ip route add 10.0.0.0/24 via 10.0.0.1 dev eth1

# Paso 2: SOLO AHORA cambiar la ruta por defecto
sudo ip route replace default via <public-gateway-ip> dev eth0

Dos hábitos operativos lo hacen más seguro en la práctica. Primero, usa una herramienta como tmux o screen para cualquier cambio de enrutamiento. Si pierdes tu sesión, el trabajo sobrevive a la desconexión y puedes recuperarte en cuanto reconectas. Segundo, en cualquier cambio de gateway que toque la ruta por defecto, pon un watchdog: un cron job que revierte las tablas de enrutamiento a un estado conocido-bueno en cinco minutos a menos que lo canceles. Ese cron job nos ha salvado de un ticket remote-hands más de una vez.

La lección generalizable es que en cualquier máquina dual-homed, el orden de las operaciones importa más que la corrección del estado final. La misma configuración aplicada en el orden equivocado produce un resultado diferente que la misma configuración aplicada en el orden correcto — y la diferencia es si conservas tu shell o no.

Lección 2: la trampa de configuración WireGuard más DNS

Un nodo de render abre un túnel WireGuard a la gateway. El túnel sube. ICMP funciona en ambas direcciones — el operador del lado artista puede hacer ping a cada IP interna. Confiado en que la red está sana, el operador lanza un job de render. El job se atasca. Los logs muestran timeouts de resolución DNS. La confusión se instala, porque el operador acaba de probar con ping cada dirección interna y todas respondieron.

Esta es la trampa de configuración WireGuard más DNS. El patrón es una de las experiencias de debugging más contraintuitivas en un despliegue de render farm intercontinental, porque la comprobación estándar «¿está la red arriba?» (ICMP) devuelve verde mientras el fallo realmente visible para el usuario está ocurriendo en otra capa del protocolo.

La causa raíz es casi siempre dnsmasq — o el resolver DNS interno que estés ejecutando en la gateway — no configurado para escuchar en la interfaz WireGuard. Por defecto, dnsmasq se bindea a las interfaces que conoce en el arranque. La interfaz WireGuard (wg0) sube después de dnsmasq, y a menos que le hayas dicho explícitamente que escuche ahí, las consultas que llegan por el túnel nunca alcanzan al resolver. Expiran en el cliente, mientras cualquier otro protocolo — incluyendo ICMP, TCP a IP internas, incluso montajes SMB directos por IP literal — funciona.

El fix es una línea en la configuración de dnsmasq:

# /etc/dnsmasq.conf
interface=wg0
interface=eth1
bind-interfaces

La directiva bind-interfaces también es importante. Sin ella, dnsmasq escucha en el wildcard 0.0.0.0, lo que funciona en muchos casos pero interactúa mal con algunas configuraciones de firewall. Ser explícito sobre qué interfaces sirven DNS es más seguro.

La trampa diagnóstica es la parte peligrosa. Cuando ICMP funciona, el instinto humano natural es descartar la red y mirar la capa de aplicación. Hemos visto esta ruta de debug consumir horas: un operador persigue reglas de firewall en el nodo de render, luego comprueba servidores de licencias, luego sospecha una configuración stale de Deadline, luego por fin — tres horas después — ejecuta dig @internal-dns-ip cache.lan desde el lado artista y obtiene el timeout. Una vez has hecho esta sesión de debug, no la olvidas nunca. La lección general: añade la resolución DNS a tu smoke test de salud de red. ICMP solo no basta.

Lección 3: MSS clamping TCP para túneles largos

La tercera lección es la que más tiempo cuesta cuando no la has visto, porque el modo de fallo se parece a todo lo demás. Las operaciones pequeñas funcionan. Las sesiones SSH se mantienen conectadas. telnet a un puerto tiene éxito. Un GET HTTP corto devuelve headers. Luego alguien intenta montar un share SMB por el túnel, o iniciar un handshake TLS, o arrancar una sesión RDP — y la conexión se cuelga para siempre. Sin error, sin reset, solo silencio.

Este es el problema del agujero negro MTU, y en túneles largos está esencialmente garantizado a menos que hagas algo al respecto. WireGuard añade unos 60 bytes de overhead a cada paquete para el envoltorio cifrado más headers, lo que tira la MTU efectiva dentro del túnel por debajo de la MTU Ethernet estándar de 1500 bytes. Cuando dos endpoints intentan enviar un paquete de tamaño completo por el túnel, el router en medio o lo fragmenta (a menudo no permitido) o devuelve un mensaje ICMP «Fragmentation Needed» para que el emisor reintente más pequeño.

Los mensajes ICMP «Fragmentation Needed» son rutinariamente descartados por firewalls intermedios. Cuando el path MTU discovery se rompe de esta forma, el emisor sigue enviando paquetes sobredimensionados que fallan silenciosamente al atravesar el túnel. Los paquetes pequeños pasan; los grandes — handshakes TLS llevando certificados de servidor, negociaciones SMB, framing RDP — desaparecen. La sesión espera una respuesta que nunca llega.

El fix es MSS clamping TCP. En la gateway WireGuard, añades una regla iptables en la tabla mangle que reescribe la opción MSS TCP en cada paquete que sale por wg0 a lo que la path MTU realmente soporte. El kernel se encarga del cálculo:

sudo iptables -t mangle -A FORWARD -o wg0 \
  -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu

El diagnóstico para cazar esto antes que los usuarios es directo: envía un paquete deliberadamente grande por el túnel y observa qué pasa. Un ping -s 1400 con el bit don't-fragment activado fallará si falta el MSS clamping y PMTUD está roto. Lo añadimos a nuestro smoke test de despliegue junto al chequeo DNS de la Lección 2, porque los dos fallos juntos cubren la mayoría de los reportes «la red funciona pero la app no» que triamos.

La lección generalizable es que en cualquier overlay tunelizado, «TCP funciona» no es lo mismo que «TCP funciona para payloads grandes». Prueba siempre un paquete grande de extremo a extremo antes de declarar la red sana.

Lección 4: dimensionamiento justo frente a sobreingeniería

Hay una tentación operativa, cuando te sientas a diseñar un cluster de render dedicado, de especificar el tipo de stack de almacenamiento que encontrarías en un libro blanco de hyperscaler. RAID 10 sobre cuatro discos para redundancia, LUKS para cifrado en reposo, XFS para el sistema de ficheros de caché porque alguien dijo una vez que XFS maneja mejor los ficheros grandes. El diagrama queda impresionante. La lista de materiales añade tres discos y una controladora que no necesitabas. Y cada capa añadida es otra capa que puede fallar.

Para uno de los despliegues intercontinentales que hemos hecho, el plan original llamaba exactamente a ese stack. La realidad desplegada fue un único SSD SATA de 8 TB con ext4 y sin cifrado en reposo. El servidor de caché vive detrás de WireGuard, los datos en él se pueden replicar desde almacenamiento en la nube en horas en lugar de días, y el modelo de amenaza del cliente no incluía un atacante físico con acceso a un rack de datacenter tras varias capas de aislamiento de red. RAID 10 resolvía un problema que el despliegue no tenía. LUKS duplicaba cifrado que el almacenamiento del lado nube ya proporcionaba. XFS añadía una elección de sistema de ficheros para una carga (lecturas secuenciales de assets de escena cacheados) que ext4 maneja bien.

La regla general que aplicamos ahora: no añadas una capa a menos que la capa arregle un modo de fallo real en el despliegue real. La redundancia de almacenamiento en un servidor de caché es innecesaria cuando los datos maestros viven en almacenamiento en la nube y un re-warm completo de caché tarda unas horas. El cifrado en reposo es innecesario en hardware cuyo contenido ya está cifrado en tránsito y en la fuente cloud. Elegir un sistema de ficheros menos común por benchmarks teóricos es innecesario cuando la carga encaja bien dentro del envoltorio testeado de la opción por defecto.

El compromiso que reconocimos: un único SSD no tiene redundancia en el cluster. Si ese disco falla, el caché se pierde hasta que restauremos. Nuestra mitigación es directa — un rsync nocturno a un NAS aparte, monitorización de los contadores SMART del SSD y un procedimiento de re-warm documentado que reconstruye el caché desde almacenamiento en la nube dentro de la ventana SLA. El punto no es que la redundancia sea mala; el punto es que la redundancia pertenece donde arregla un modo de fallo articulable, no como reflejo por defecto.

La sobreingeniería también tiene un coste de legibilidad operativa. Cada capa es una capa que el siguiente operador tiene que entender para debuggear. Un único sistema de ficheros ext4 sobre un único SSD es algo que cualquier operador Linux puede solucionar desde principios primeros. Cuando el despliegue corre sin supervisión y un operador remoto tiene que recuperarlo a las 2 de la mañana, lo más simple gana.

Lección 5: pre-calentar el caché antes del día D

Un embalse llenándose de luz ante el resplandor de un plazo que se acerca

Las render farms esconden un problema de arranque en frío fácil de pasar por alto hasta el primer día de producción del cliente. El día uno, veinte nodos de render se conectan por primera vez y empiezan a tirar de los assets que necesitan. Si el caché está vacío, cada uno de esos nodos golpea el almacenamiento en la nube a la vez, compitiendo por el mismo ancho de banda de subida. Los rate limits del lado nube saltan. El tubo de Internet compartido se satura. La cola de render se atasca. La primera impresión del cliente sobre el cluster es que es más lento que su antigua workstation.

Este es el problema del cold-pull, y es totalmente evitable. La solución es pre-calentar el caché veinticuatro a cuarenta y ocho horas antes del primer render programado del cliente. La mecánica es simple: por adelantado al día D, trabaja con el cliente para obtener la lista de assets — los ficheros de proyecto, las texturas, los cachés de simulación, las bibliotecas de plugins que se referenciarán. Trae todo eso al servidor de caché mientras no hay carga de producción en el cluster, para que el día uno, los nodos de render encuentren un caché caliente esperándolos en la LAN local.

Una pasada de pre-warm también sirve como smoke test. Si la lista de assets contiene una ruta que no resuelve, lo descubres en la calma de la ventana de pre-warm en vez de en el pánico del primer render. Si hay un problema de permisos entre la cuenta cloud del cliente y la ruta de almacenamiento de la que tiras, también lo descubres. Si la lista de assets suma un volumen que no cabe en el caché, tienes tiempo de redimensionar el caché o negociar un alcance más ajustado. Ninguna de estas conversaciones debería ocurrir por primera vez cuando la cola de render ya está enviada.

Una práctica relacionada: un render smoke-test con un lote pequeño de frames antes de que entre el lote de producción. Veinte frames a plena calidad, de extremo a extremo por el pipeline, el día cero. Si algo está mal configurado — una licencia de plugin que falta, una ruta de salida equivocada, un drift OCIO entre la workstation del artista y el cluster — el smoke test lo saca a flote. Veinte frames son un seguro barato contra encontrar el mismo problema en el frame 800 de un lote de producción de 2.000 frames.

La lección general: el primer render en un cluster fresco es siempre más lento y más propenso a errores que el régimen estable. Diseña teniéndolo en cuenta. No entregues el cluster en frío.

Lección 6: la documentación es una herramienta operativa, no algo a posteriori

La sexta lección es una bonus, porque trata menos de un patrón técnico y más de cómo el despliegue se convierte en algo que el equipo puede soportar después. Hemos aprendido a construir el runbook durante el despliegue, no después.

Cada despliegue que operamos genera un build log en tiempo real: un changelog numerado de entradas en orden cronológico, con los comandos realmente ejecutados, las salidas realmente devueltas y comentarios del operador sobre por qué se tomó una decisión particular. No escribimos este log retrospectivamente, porque los detalles ya se fueron. Lo escribimos a medida que trabajamos, y lo tratamos como un entregable de peso equivalente a la infraestructura en marcha.

El build log tiene dos audiencias. La primera es el siguiente operador que toque el cluster — normalmente un compañero, a veces la versión futura del operador que lo montó. La segunda es el cliente, en forma de un documento de entrega que destila el build log en una referencia as-built limpia, los procedimientos de recuperación en caso de rotura y los límites operativos entre lo que posee su equipo y lo que poseemos nosotros.

El coste de documentar durante el despliegue es aproximadamente el quince por ciento del tiempo de despliegue. El coste de no documentar es un ciclo de soporte cada vez que algo tiene que recuperarse, y una curva de aprendizaje pronunciada para cualquier compañero que tome el sistema. El build log se ha amortizado en el primer mes cada vez.

Contra-lecciones honestas: lo que no hicimos

Hay una tentación, en cualquier informe operativo, de describir el stack final como si hubiera sido la elección obvia desde el principio. Rara vez lo es. Aquí están los componentes que consideramos, probamos o deliberadamente no desplegamos — incluidos para que no malgastes ciclos repitiendo experimentos que ya hicimos.

No desplegamos RustDesk para escritorio remoto. RustDesk es servible para trabajo de oficina general, pero la calidad de streaming y la fidelidad de color no estaban al nivel necesario para 3D y rendering GPU. Los artistas notaron artefactos de compresión en superficies texturizadas y cambios de color en las previsualizaciones de viewport. Estandarizamos en Moonlight con Sunshine, que usa codificación hardware NVIDIA NVENC y se diseñó para streaming de alta tasa de frames y alta fidelidad. Parsec es un fallback razonable; RustDesk no encaja en esta carga.

No desplegamos BBR versión 3. TCP BBR es un algoritmo de control de congestión que maneja enlaces internacionales largos y propensos al jitter mejor que el por defecto del kernel. Lo usamos — pero usamos BBR versión 1, no versión 3. BBRv3 es más nuevo, teóricamente mejorado, y no está aún en la madurez de kernel a la que lo pondríamos delante de un deadline de producción de cliente. BBRv1 está bien entendido, viene estándar en kernels Linux modernos, y hace el trabajo.

No corrimos el edge router como VM sobre el NAS. Un plan anterior contemplaba consolidar la gateway edge sobre una máquina virtual corriendo en la misma caja Network Attached Storage que aloja el caché. La realidad es la separación de preocupaciones: cuando el edge router y el caché viven en la misma máquina física, una actualización de kernel en el NAS tumba también la gateway. Un disco con mal comportamiento puede dejar a la gateway sin I/O. Una caja de caché dedicada que hace trabajo de caché y nada más es operativamente más limpia.

No desplegamos AWS Global Accelerator ni Cloudflare Tunnel. Ambos son componentes opcionales razonables, y cualquiera de los dos reduciría la latencia para algunos clientes. También son innecesarios para la baseline. El túnel WireGuard con BBR y MSS clamping maneja enlaces internacionales largos lo bastante bien como para que la mejora marginal no justifique la complejidad operativa. Hemos especificado Global Accelerator y Cloudflare Tunnel como componentes opcionales de fase dos en nuestra documentación de arquitectura, pero ninguno se embarcó con nuestros builds intercontinentales por defecto. Si los requisitos de latencia de un cliente resultan más ajustados de lo que la baseline puede soportar, revisitamos. Hasta entonces, no desplegamos lo que no necesitamos.

La contra-lección general: un informe honesto de despliegue debería incluir las cosas que no se embarcaron. De otro modo, el siguiente operador asume que el stack final era inevitable, y repite experimentos que ya pagamos.

Preguntas frecuentes

Q: ¿Cuánto se tarda en desplegar un cluster dedicado intercontinental de 20 nodos? A: Desde el aprovisionamiento de hardware hasta el cluster listo para el cliente, nuestro plazo típico va de dos a cuatro semanas. La construcción de hardware y el imaging de OS es la parte predecible. La configuración de red — WireGuard, BBR, MSS clamping, DNS, NTP, firewall — añade unos días. El pre-warm y el smoke testing consumen un día o dos más. La variabilidad viene de los prerrequisitos del lado cliente: aprovisionamiento de acceso a cuenta cloud, acuerdo sobre la lista de assets y alineación del setup de cliente artista.

Q: ¿Cuál es la causa más común de retraso de despliegue? A: El aprovisionamiento de credenciales y accesos del lado cliente. El trabajo de infraestructura va a tiempo. El cuello de botella es típicamente conseguir las credenciales de almacenamiento cloud del cliente en el cluster de forma compatible con su política de seguridad, e instalar las herramientas cliente del lado artista (WireGuard, Moonlight) en las workstations reales que usarán los artistas. Hemos aprendido a empezar esa conversación el día uno, no en la última semana.

Q: ¿Puedo seguir estas lecciones para mi propio setup DIY de render farm? A: Sí. Las lecciones aquí son patrones de infraestructura, no secretos de negocio. La trampa de enrutamiento dual-home, la trampa DNS, el MSS clamping y la disciplina de dimensionamiento justo se aplican todos a cualquier despliegue cross-network, diez nodos o doscientos. Si prefieres no operar la infraestructura tú mismo, nuestra fully managed render farm maneja todo esto sobre infraestructura compartida, y nuestra oferta de cluster dedicado hace lo mismo para clientes que quieren hardware que sea solo suyo.

Q: ¿Ofrecéis consultoría sobre infraestructura de render farm separada de vuestro servicio alojado? A: Nos centramos en operar la infraestructura nosotros mismos en vez de vender horas de consultoría. Para equipos que se debaten entre construir y alquilar, nuestra guía build versus cloud total cost expone la economía, y el equipo está encantado de hablar de cuestiones de arquitectura con clientes prospectivos que evalúan un cluster dedicado en nuestro hardware.

Q: ¿Cuál es el despliegue intercontinental de render farm más largo que habéis hecho en distancia? A: Los despliegues que operamos hoy abarcan continentes — artistas trabajando desde Norteamérica mientras el hardware de render corre en el sudeste asiático. Cuanto más largo es el enlace, más cuentan estas lecciones. Los despliegues solo-LAN cortos pueden ignorar el MSS clamping y el pre-warm. Los despliegues entre continentes no.

Q: ¿Cuál es el tamaño de cluster más pequeño donde estas lecciones aún aplican? A: La mayoría de estos patrones cuentan desde el primer nodo, no desde el vigésimo. La trampa de enrutamiento dual-home aplica a cualquier gateway con más de una interfaz. La trampa DNS más WireGuard aplica a cualquier overlay tunelizado con resolución de nombres interna. El requisito de MSS clamping aplica a cualquier tráfico TCP cruzando un túnel de longitud significativa. El pre-warm de caché importa más a medida que crece el número de nodos, porque la contención de ancho de banda en cold-pull escala con el número de nodos golpeando la nube a la vez.