O tempo de computação e o tempo de GPU são os recursos mais caros em um pipeline moderno de produção de mídia. Seja em uma fazenda de renderização na nuvem, em uma operação editorial que opera 24 horas por dia ou em um pipeline híbrido de efeitos visuais (VFX) que combina infraestrutura local e na nuvem, a viabilidade econômica só é garantida quando a computação está produzindo, e não esperando.
O Qumulo Cloud Native na AWS já oferece desempenho de arquivos corporativos em escala de nuvem para seus dados, apoiado pela capacidade praticamente ilimitada do S3, com um único namespace global que abrange regiões e locais. O pré-aquecimento do cache vai um passo além. Ele permite que você informe ao cluster exatamente quais dados deseja que estejam prontos antes do início da carga de trabalho, para que seus artistas e nós de renderização comecem a trabalhar imediatamente todas as vezes.
A API
O aquecimento do cache é disponibilizado por meio de três interfaces, já disponíveis no Qumulo Core 7.8.3 e versões posteriores.
qq fs_fetch_tree percorre toda uma árvore de diretórios de forma recursiva e armazena todos os arquivos no cache. Um único comando prepara um projeto inteiro:
qq fs_fetch_tree --path "/caminho-da-pasta/"
qq fs_fetch_file destina-se a um único arquivo, o que é útil quando você sabe exatamente qual recurso é necessário ou deseja pré-aquecer apenas uma sequência antes de uma revisão:
qq fs_fetch_file --path "/caminho-para-o-arquivo"
Para equipes que estão integrando o aquecimento em suas próprias ferramentas de pipeline, essa mesma funcionalidade está disponível diretamente por meio do API REST, para arquivos individuais, um POST para /v1/files/{ref}/fetch-data. Isso facilita a incorporação de etapas de aquecimento em sistemas de despacho de renderização, ferramentas de orquestração de pipeline ou automação de transferência entre turnos.
Como funciona o cache do CNQ atualmente
O Qumulo, uma solução nativa da nuvem, armazena seus dados de arquivos de forma duradoura no S3 e os disponibiliza a partir de um cache local de alto desempenho em cada nó do cluster. À medida que você trabalha, o cluster gerencia de forma inteligente o que permanece no cache, mantendo seu conjunto de trabalho ativo acessível e à mão, enquanto todo o histórico do projeto fica armazenado com segurança no S3.
Além disso, o NeuralCache, o cache de leitura preditivo da Qumulo, adiciona uma camada inteligente que monitora os padrões de acesso e pré-busca os dados que antecipa que você precisará em seguida. Devido à natureza não linear e criativa do trabalho editorial e de finalização, o NeuralCache está constantemente se antecipando à carga de trabalho com base na forma como sua equipe realmente trabalha. O colorista que alterna entre sequências. O supervisor que analisa tomadas fora de ordem. Na maioria dos casos, o NeuralCache funciona de maneira imperceptível: as solicitações são atendidas a partir do cache com pouca ou nenhuma latência, e o sistema aprende os padrões ao longo do tempo.
Mas há momentos em que você já sabe o que é preciso fazer.
Por que criamos o aquecimento do cache
O principal fator para o aquecimento do cache é o Espaço de Nomes Global entre portais (topologia Hub e Spoke). Dentro de um único cluster, o NeuralCache é altamente eficaz: ele monitora padrões de acesso, prevê o que você precisará e transfere esses dados do S3 para o cache NVMe local com antecedência. A latência entre o nó na nuvem e o S3 é baixa o suficiente para que isso funcione perfeitamente para a maioria das cargas de trabalho. O desafio surge quando um Spoke está fornecendo dados por meio de uma relação de portal com um Hub em outra região ou fazendo uso de recursos da nuvem. O NeuralCache ainda consegue prever o que a carga de trabalho precisa, mas não consegue entregar esses dados a você com rapidez suficiente.
O “cache warming” complementa o NeuralCache ao adicionar uma camada proativa e direcionada. Em vez de prever o acesso, você o declara. Para cargas de trabalho conhecidas — uma renderização que começa às 6h, uma transferência que chega às 9h, um lote de efeitos visuais que é iniciado após a revisão, uma carga de trabalho do outro lado do planeta —, você pode garantir que os dados já estejam no cache local do Spoke antes que a primeira solicitação chegue.
É aqui que o aquecimento do cache realmente mostra seu valor: como uma ferramenta para as partes do seu pipeline que você pode planejar.
Os fluxos de trabalho que dão resultado
Renderização em rajadas: leve seus dados para a CPU
A renderização em nuvem é uma das ferramentas mais poderosas em um pipeline de produção moderno. É possível aumentar a escala para cem nós de renderização para cumprir um prazo e reduzi-la novamente quando o trabalho estiver concluído. Os benefícios econômicos são atraentes, mas dependem de um fator: esses nós precisam estar renderizando, e não aguardando dados.
Sem o aquecimento do cache, cada tarefa de renderização acarreta um custo de inicialização a frio. A fazenda é inicializada; os primeiros nós começam a solicitar arquivos de cena, texturas e caches de geometria, e o armazenamento começa a extrair esses dados do seu cluster local ou de um nó hub distante para preencher o cache no Spoke. A renderização avança, mas a uma fração de sua taxa de transferência potencial até que o conjunto de trabalho esteja aquecido. Em uma grande fazenda que processa grandes conjuntos de dados, esse período de aceleração ocorre em tempo real e acarreta um custo real de CPU.
Com o pré-carregamento do cache, você insere os dados importantes diretamente no NeuralCache. Quando o primeiro nó de renderização fica online, o conjunto de trabalho já está residente no NVMe. A fazenda de renderização atinge a taxa de transferência máxima desde o primeiro quadro. E se seus dados mestres estiverem no local — ingestão, finalização, arquivamento, décadas de histórico de projetos —, o pré-carregamento do cache elimina totalmente essa lacuna. Você envia os ativos de renderização para o Spoke na nuvem antes que a fazenda de renderização seja iniciada. Eles abrem o projeto, e os dados já estão lá.
Edição “Follow the Sun”
O Cloud Data Fabric da Qumulo permite uma topologia “hub-and-spoke” entre regiões e instalações. Um cluster atua como o “hub” para seus dados mestres. Os clusters “spoke” em outros locais compartilham o acesso a esse mesmo namespace por meio de uma relação de portal: os mesmos caminhos, os mesmos nomes de arquivos, um único projeto, em todos os lugares.
Uma unidade em Los Angeles opera o Hub. Uma equipe de finalização em Sydney trabalha por meio de um Spoke. Quando a equipe de Los Angeles encerra o expediente, a equipe de Sydney começa seu dia. Sem o pré-carregamento do cache, o desempenho fica limitado pela largura de banda da WAN; à medida que abrem sequências e carregam correções de cor, o Spoke vai preenchendo seu cache de forma orgânica, recurso por recurso.
O pré-carregamento do cache muda completamente esse processo. No final do dia em Los Angeles, o pipeline já sabe no que Sydney vai trabalhar amanhã. Você pré-carrega esses diretórios no Spoke de Sydney enquanto Los Angeles está encerrando o dia. Quando a equipe abre o Premiere pela manhã, todos os clipes já estão no cache. A navegação é suave. A reprodução é perfeita. A primeira hora é tão rápida quanto a última.
Mais rapidez: o qfetch para cargas de trabalho com grande número de arquivos
O recurso integrado qq fs_fetch_tree O comando funciona bem para pré-carregar arquivos grandes. Para um conjunto de dados de 500 GB com arquivos ProRes de produção, o processo é concluído em cerca de quatro minutos. Mas, para cargas de trabalho que envolvem milhares de arquivos, sequências de quadros, bibliotecas de texturas, faixas de áudio, placas EXR, fs_fetch_tree percorre a árvore de diretórios e busca os arquivos sequencialmente, um por vez. Para um conjunto de dados com 50.000 arquivos, essa abordagem sequencial levou mais de duas horas e meia em nossos testes.
Para resolver essa questão, a equipe de engenharia da Qumulo desenvolveu qfetch, uma ferramenta de código aberto que disponibilizamos à comunidade como exemplo de como integrar-se à nova API para controle programático. O qfetch distribui as solicitações de busca por meio de threads configuráveis de walkers e fetchers em paralelo, acessando a API por meio de dezenas de conexões simultâneas. Nesse mesmo conjunto de dados com 50.000 arquivos e 524 GB, o qfetch, com 32 “walkers” e 64 “workers”, concluiu o aquecimento em 3 minutos e 34 segundos.
qfetch --host <ip-do-cluster> --token-file token.json \
--path "/caminho-para-a-pasta/" \
--walkers 32 --workers 64
O qfetch está disponível no GitHub em https://github.com/Qumulo/qfetch.
Inteligentes e propositais, melhores juntos
O NeuralCache e o aquecimento de cache atuam em diferentes camadas do mesmo desafio.
O NeuralCache faz o trabalho pesado — observando como sua equipe trabalha, aprendendo os padrões de acesso e mantendo os dados certos no cache sem que ninguém precise se preocupar com isso. O aquecimento do cache funciona em conjunto com ele como um complemento direto, permitindo que você reforce o que o NeuralCache já está fazendo para cargas de trabalho que você pode planejar com antecedência. Você sabe que uma renderização está começando, que um turno está terminando ou que um novo site está sendo inicializado; assim, você garante que os dados cheguem lá primeiro. Juntos, eles garantem que o cache esteja à frente da sua carga de trabalho, independentemente de a próxima etapa ter sido prevista ou declarada, e essa combinação é fundamental quando os dados precisam atravessar uma WAN entre sites, onde uma falha no cache acarreta latência real e custo de largura de banda, em vez de apenas alguns milissegundos.
O que vem a seguir
O aquecimento de cache já está disponível como recurso em pré-lançamento por meio da CLI do qq no Cloud Native Qumulo na AWS, executando o Qumulo Core 7.8.3 ou superior
Se você estiver executando fluxos de trabalho de mídia na nuvem e quiser discutir como o pré-aquecimento do cache se encaixa no seu modelo de produção, Adoraríamos receber seu contato.