Skip to main content

Cross-Country render farm: fluxos de renderização otimizados para longa distância

Cifragem WireGuard · Controlo de congestionamento BBR · Cache partilhada · Para equipas criativas distribuídas globalmente.

Pedir implementação cross-countryVer a arquitetura

Porque é que a renderização cross-country é diferente

O trabalho criativo moderno está cada vez mais distribuído. Uma pipeline 3D pode ter um diretor artístico em Nova Iorque, uma equipa de iluminação em Berlim, look-dev artists freelance em Seul, e uma render farm noutro continente. Quando os quatro estão na mesma LAN gigabit, o acesso à render farm não é problema. Quando não estão, o fluxo de trabalho atravessa a internet pública, e cada peculiaridade do encaminhamento de longa distância acaba a aparecer no calendário.

Três questões repetem-se neste tipo de configuração. A primeira é a latência — tempos de ida e volta de 150 a 250 ms entre continentes mudam a sensação de um ambiente de trabalho remoto e amplificam qualquer prolixidade num gestor de render ou num protocolo de streaming de assets. A segunda é o jitter — as ligações internacionais correm muitas vezes no limite, e o timing dos pacotes varia. A terceira é o custo e a contenção de largura de banda — puxar uma cena de 40 GB por uma ligação intercontinental uma vez é aceitável; puxá-la vinte vezes porque cada nó de render tem a sua própria cache não é.

Uma render farm local contorna a maior parte disto. As equipas que já têm um cluster na mesma região de datacenter que os seus artistas não precisam da maior parte do que esta página descreve. A renderização cross-country torna-se a escolha arquitetónica correta quando se verifica uma das seguintes:

  • A equipa está repartida entre regiões e precisa de um único parque de render partilhado.
  • A disponibilidade ou o custo do hardware torna a classe de GPU pretendida pelo cliente mais fácil de obter numa região do que noutra.
  • A equipa de artistas está desacoplada do hardware de render de propósito — por exemplo, um estúdio sediado nos Estados Unidos a alugar capacidade dedicada na Ásia para um projeto específico.
  • O armazenamento em cloud e os ficheiros de projeto já residem numa região, e o parque de render tem de ler de lá em qualquer caso.

Quando uma destas condições é verdadeira, a pergunta passa a ser operacional: como fazer com que uma render farm do outro lado do mundo se comporte como parte da rede local do artista. O resto desta página descreve como abordamos isto na Super Renders Farm.

Pilha de otimização de rede

Pilha de otimização de rede

Otimizamos as ligações cross-country com quatro peças, aplicadas em conjunto em vez de uma de cada vez.

WireGuard para transporte cifrado de longa distância

Cada ligação de um endpoint de cliente para a render farm passa por WireGuard. A máquina do cliente torna-se num peer WireGuard; o datacenter principal opera um hub. A cifragem é automática e ponta-a-ponta; o cliente não vê tráfego em claro na internet pública, e nós também não. O WireGuard é também leve o suficiente para não se tornar o gargalo numa ligação de longa distância — o seu overhead é claramente menor do que o de uma pilha IPsec tradicional.

TCP BBR para o controlo de congestionamento

O controlo de congestionamento por omissão do kernel Linux (CUBIC) é conservador perante jitter e perda de pacotes — interpreta a perda como sinal para abrandar, mesmo quando essa perda vem de encaminhamento internacional intermitente e não de congestionamento real. O BBR (Bottleneck Bandwidth and RTT) mede o produto largura-de-banda × atraso real da ligação e mantém o tubo cheio enquanto houver capacidade disponível. Numa rota transcontinental estável, o BBR entrega normalmente duas a três vezes o débito do CUBIC com o mesmo hardware. Numa rota com jitter, a diferença é maior.

Clamping de MSS TCP para evitar buracos negros de MTU

Quando um pacote atravessa um túnel como o WireGuard, a sua MTU efetiva é menor do que a da interface subjacente. Se uma ligação TCP negociar um MSS maior do que aquele que o túnel consegue transportar, acontecem duas coisas: os pacotes pequenos passam, os pacotes grandes são silenciosamente descartados. O sintoma é dos mais frustrantes no trabalho remoto — o SSH funciona, o ping funciona, mas os handshakes TLS, as sessões RDP e as cópias SMB de tamanho significativo bloqueiam todas. Fazemos o clamping da MSS no gateway WireGuard para que todas as ligações TCP negoceiem um tamanho de segmento que o túnel consegue entregar efetivamente.

Serviços internos de DNS e tempo

Dentro da farm corremos `dnsmasq` para resolução DNS interna e `chrony` para o tempo. São peças de infraestrutura silenciosas que importam mais do que parece. O DNS interno faz com que os nós de render se refiram à cache partilhada como `cache.lan` em vez de um endereço IP, o que torna seguro reorganizar a topologia. A sincronização de relógios importa porque a maioria dos gestores de render e pipelines de logs tolera mal desvios de relógio — um nó desfasado 30 segundos do resto do parque pode produzir comportamento confuso de atribuição de jobs. Ambos os serviços escutam apenas na rede interna; nada da internet pública lhes fala diretamente.

Em conjunto, estas quatro peças fazem com que uma render farm de longa distância se pareça menos com uma máquina remota e mais com uma extensão LAN lenta da workstation do artista. Nenhuma é exótica; o valor está em aplicá-las como pilha e em afinar os parâmetros para as rotas que o tráfego do cliente toma efetivamente.

Arquitetura para longa distância

A forma de implementação que usamos para configurações cross-country é uma topologia hub-and-spoke, com um único datacenter primário como hub e um ou mais sites secundários ligados por WireGuard site-to-site.

Topologia hub-and-spoke: Main DC e site secundário

Algumas decisões nesta topologia merecem nota porque se repetem em cada montagem.

O edge e a cache correm numa só caixa, não em três. A mesma máquina Ubuntu que termina o WireGuard a partir do exterior também aloja a cache Samba, o DNS interno e o serviço de tempo. Não dividimos estes papéis por várias máquinas a não ser que haja uma razão específica. O right-sizing é deliberado. Uma única caixa de cache dedicada tem um caminho de rede de entrada e outro de saída, o que simplifica a matemática do encaminhamento. Também torna os modos de falha mais fáceis de raciocinar — se a cache está em funcionamento, os serviços internos estão; se não está, nada interno funciona, e esse sinal único é mais fácil de alertar do que três sinais separados.

O WireGuard site-to-site trata da localização secundária. Quando a implementação se estende a dois locais físicos — por exemplo, um datacenter principal mais um site alugado mais pequeno na mesma área metropolitana — os dois ligam-se por um túnel WireGuard site-to-site sobre o ISP público. O tráfego entre eles, da perspetiva do host, parece uma sub-rede grande. O grupo de render B no site secundário lê a cache no Main DC da mesma forma que o grupo A, apenas com mais saltos.

A rede é encaminhável em Layer-3. Cada nó é um host IP real que outros nós podem endereçar diretamente. Não impomos um gestor de render em particular. As equipas que preferem Deadline podem correr o seu próprio repositório Deadline num nó coordenador do lado do cliente; as equipas que preferem outra coisa podem fazê-lo. A render farm fornece os hosts, a rede, a cache e a pilha de otimização; a camada de orquestração por cima é escolha do cliente.

Para um percurso mais profundo, o guia operacional de implementação cobre o procedimento completo passo a passo, e a análise arquitetónica aprofundada entra em mais detalhe no design de WireGuard e cache.

Otimização de largura de banda e cache partilhada

A largura de banda intercontinental é cara em dois sentidos: custa dinheiro na fatura de egress da cloud e custa tempo quando os artistas esperam que um asset desça pelo tubo. Um parque de render que não pensa nisto pode gastar uma fração significativa do wall-time de cada job a puxar a frio ficheiros de cena que já estão em cache noutro lado do edifício.

O padrão de cache partilhada é a alavanca mais simples e maior. Um servidor de cache Samba (SMB3) no datacenter principal guarda os assets do projeto. Cada nó de render monta a cache e lê os ficheiros de cena por LAN. Quando um novo asset é referenciado por um job, a cache puxa-o do armazenamento em cloud do cliente uma única vez. Cada nó subsequente que dele precise lê-o da cópia LAN. Um parque de 20 nós que de outra forma puxaria uma cena de 40 GB vinte vezes, puxa-a uma vez.

Em princípio é direto. Na prática, dois pedaços do design contam.

Evitar cache por nó. É tentador dar a cada nó de render o seu próprio SSD local grande e deixá-lo cachear o que quiser. Para um parque de 20 nós com 10 TB de dados de projeto, isto torna-se em 200 TB de armazenamento duplicado sem lógica de invalidação partilhada. Não fazemos isso. A cache partilhada é a única cache; os nós tratam os seus discos locais como espaço scratch, não como arquivo de projeto.

Pré-aquecer a cache antes do dia D. Quando um cliente anuncia que um projeto começa segunda-feira, pré-aquecemos a cache durante o fim de semana. O primeiro job de segunda lê de uma cache quente em vez de desencadear vinte horas de pulls a frio. É o método mais fiável para fazer com que a primeira renderização de um projeto pareça rápida.

Uma nota sobre right-sizing: a caixa de cache usa um único SSD SATA com sistema de ficheiros ext4. Para uma cache (por oposição a armazenamento primário), um layout de disco único é o compromisso correto. A cache não é a fonte de verdade — é-o o armazenamento em cloud do cliente — e a cache pode ser reconstruída ao re-puxar da cloud ou por rsync a partir de uma cópia de segurança do projeto. Montar um array redundante sobre um volume cifrado acrescentaria custo e complexidade sem mudar a história operacional; um nó que perde a cache é uma reconstrução de uma noite, não um evento de perda de dados. Dimensionar o hardware da cache para o seu papel é uma das formas mais simples de manter o custo de operação previsível.

Para equipas que ponderam um cluster permanente em vez de uma única implementação cross-country, a página dedicated cluster options cobre essa configuração em detalhe.

Características de desempenho e adequação

Características de desempenho e adequação

As render farms cross-country não são uma opção universalmente melhor. Fazem sentido para um tipo específico de fluxo de trabalho e apresentam compromissos previsíveis em relação a uma farm local.

Qualidade de stream para trabalho 3D remoto

Para artistas que precisam de pilotar um nó GPU de forma interativa — por exemplo, abrir uma cena Cinema 4D com Redshift, fazer previews IPR, ou enquadrar renders antes de submeter jobs completos — usamos Moonlight como cliente e Sunshine como host. Ambos usam codificação por hardware NVENC na GPU do nó de render, o que produz um stream consideravelmente mais fluido do que os protocolos de ambiente de trabalho remoto codificados por software. Vídeo codificado sobre uma ligação de longa distância afinada entrega uma experiência utilizável para trabalho real, incluindo interação de viewport em alto detalhe; a mesma carga sobre RDP simples frequentemente não. O Parsec está configurado como fallback para os casos raros em que o Sunshine tem dificuldade em negociar uma sessão.

Perfil de latência, em termos gerais

Uma ligação intercontinental bem afinada situa-se tipicamente entre 150 e 250 ms de ida e volta. O número depende da separação geográfica e da rota que o tráfego do cliente toma efetivamente. Não publicamos uma latência específica par-de-cidades nesta página porque não se generaliza — o vosso próprio ISP, o vosso próprio peering e os vossos próprios saltos locais dominam a experiência tanto como qualquer número que pudéssemos citar. Podemos executar uma sonda a partir de um endpoint candidato durante a fase de planeamento e partilhar as medições reais para a rota que a vossa equipa vai usar.

Testada a tamanhos de parque significativos

As nossas implementações cross-country correram a escala de cluster 20-nós com GPUs de consumo de geração atual (hardware classe RTX 5090), com armazenamento de projeto na própria plataforma cloud do cliente. É aproximadamente a escala a partir da qual as escolhas arquitetónicas das secções anteriores começam a importar — em parques mais pequenos, um setup menos otimizado pode safar-se com mais.

Quando este é o encaixe certo

A renderização cross-country é o encaixe certo quando os artistas estão distribuídos e o parque de render tem de estar algures, quando os dados de projeto já vivem numa região cloud específica, quando o cliente precisa de infraestrutura isolada por IP que as opções locais não conseguem fornecer, ou quando a disponibilidade ou o custo de GPUs favorece uma região em particular.

Quando uma farm local é um encaixe melhor

Se toda a gente na equipa trabalha do mesmo escritório ou país que o parque de render, as otimizações desta página são sobretudo overhead desnecessário. Uma farm local com tubos mais curtos e encaminhamento mais simples será mais fácil de operar e não beneficiará de BBR ou de clamping de MSS da mesma forma. A contra-posição honesta importa: nem toda a equipa precisa desta arquitetura. Para cargas em que artistas e hardware de render podem estar na mesma região, a página padrão render farm rental options cobre bem o caso.

Perguntas frequentes

Em termos gerais, ligações de longa distância bem afinadas situam-se entre 150 e 250 milissegundos de ida e volta, dependendo o número exato do ISP do artista, da rota que o tráfego toma e da localização geográfica do endpoint. Podemos executar uma sonda a partir de um posto candidato durante o planeamento e partilhar os números efetivamente medidos para a vossa rota.

O controlo de congestionamento BBR é a mitigação principal — mantém o débito estável quando a ligação tem jitter, em vez de colapsar perante a perda de pacotes como o CUBIC por omissão. O próprio WireGuard também é tolerante a breves interrupções de rede porque não mantém estado de sessão como um túnel IPsec. Para falhas ao nível do ISP, o túnel volta a ligar assim que a rota upstream regressa; os jobs de render em curso continuam do lado da farm independentemente do estado da ligação do artista.

Sim. Cada ligação é cifrada por WireGuard: endpoint do artista para o datacenter principal e site-to-site entre o Main DC e qualquer site secundário. Não existe nenhum ponto na internet pública em que um observador possa ler tráfego em claro entre a vossa equipa e o parque de render. Não exigimos confiança em qualquer transporte intermediário; a cifragem reside na camada WireGuard, não acrescentada como opção por cima.

Sim. O hub WireGuard aceita múltiplos peers, pelo que qualquer número de artistas em qualquer número de localizações pode ligar-se à mesma farm ao mesmo tempo. Cada artista corre o cliente WireGuard no seu posto, abre Moonlight, e liga-se ao nó de render que lhe foi atribuído. Os serviços internos como cache e DNS são partilhados pelo parque, pelo que dois artistas a trabalhar na mesma cena a partir de continentes diferentes veem o mesmo conjunto de assets.

Através da cache SMB partilhada. Quando um job de render referencia um asset que a cache ainda não viu, a cache puxa-o do armazenamento em cloud do cliente uma única vez. Os nós seguintes que precisem do mesmo asset leem-no da cache por LAN à velocidade da linha, não pela ligação intercontinental. Para projetos com datas de início previsíveis, pré-aquecemos a cache antes do dia D para que a primeira renderização do projeto beneficie de uma cache quente em vez de desencadear uma cascata de pulls a frio.

Funciona da mesma forma; a separação geográfica significa apenas que o pull inicial para a cache demora mais tempo do que com armazenamento na mesma região. Assim que um asset está na cache, a separação geográfica deixa de importar — os nós de render leem por LAN. Neste cenário normalmente pré-aquecemos a cache para que o pull cross-região aconteça do nosso lado antes do projeto começar, e não durante a primeira renderização.

A residência de dados depende de onde o próprio parque de render é aprovisionado, o que planeamos com o cliente com antecedência. Para equipas com requisitos de residência específicos, a conversa tem de cobrir onde são guardados os dados de projeto, onde os renders são produzidos, onde os logs são armazenados e como os dados são apagados no fim do contrato. É uma conversa de planeamento e não uma resposta única de sim ou não; por favor contactem-nos para discutir as particularidades do vosso caso.

A renderização em si continua. Os jobs de render correm do lado da farm independentemente do estado do túnel do artista — assim que um job é distribuído, o artista pode desligar-se completamente e os frames continuam a ser produzidos. Quando o túnel regressa, o artista restabelece o seu peer WireGuard e volta a ligar-se via Moonlight à mesma sessão. A consequência prática mais frequente de uma queda de túnel a meio de um render é que o artista não consegue acompanhar o progresso em direto durante a interrupção; a renderização em si não recomeça.

Próximos passos

Próximos passos