Neste documento, fornecemos orientações sobre como ampliar seu farm de renderização local atual para usar recursos de computação no Google Cloud. Neste artigo, consideramos que você já implementou um farm de renderização local e tem familiaridade com os conceitos básicos de efeitos visuais (VFX, na sigla em inglês) e pipelines de animação, software de gerenciamento de filas e métodos comuns de licenciamento de software.
Visão geral
A renderização de elementos 2D ou 3D para animações, filmes, comerciais ou videogames exige muita computação e tempo. Renderizar esses elementos requer um investimento substancial em hardware e infraestrutura, além de uma equipe dedicada de profissionais de TI para implantar e manter hardware e software.
Quando um farm de renderização local está a 100% de utilização, o gerenciamento de tarefas pode se tornar um desafio. As prioridades e dependências da tarefa, a reinicialização de frames ignorados e a carga de rede, disco e CPU tornam-se parte da complexa equação que você precisa monitorar e controlar de perto, geralmente com prazos apertados.
Para gerenciar esses jobs, as instalações de VFX incorporaram software de gerenciamento de filas nos canais. O software de gerenciamento de filas pode:
- implantar jobs em recursos locais e baseados em nuvem;
- gerenciar dependências entre jobs;
- comunicar-se com sistemas de gerenciamento de recursos;
- fornecer aos usuários uma interface de usuário e APIs para linguagens comuns, como o Python.
Embora alguns softwares de gerenciamento de filas possam implantar jobs em workers baseados em nuvem, você ainda é responsável por conectar-se à nuvem, sincronizar recursos, escolher uma estrutura de armazenamento, gerenciar modelos de imagem e fornecer seu próprio licenciamento de software.
As opções a seguir estão disponíveis para criar e gerenciar pipelines de renderização e fluxos de trabalho em um ambiente de nuvem ou de nuvem híbrida:
- Se você ainda não tiver recursos no local ou na nuvem, use um serviço de renderização de software como serviço (SaaS), baseado em nuvem, como o Conductor.
- Se quiser gerenciar sua própria infraestrutura, crie e implante os recursos de nuvem descritos neste documento.
- Se você quiser criar um fluxo de trabalho personalizado com base nos seus requisitos específicos, trabalhe com parceiros de integração de serviços do Google Cloud, como Gunpowder ou AppsBroker. Essa opção tem a vantagem de executar todos os serviços de nuvem no seu próprio ambiente seguro do Google Cloud.
Para ajudar a determinar a solução ideal para suas instalações, entre em contato com seu representante do Google Cloud.
Observação: as observações de produção aparecem periodicamente ao longo deste documento. Elas oferecem práticas recomendadas a serem seguidas à medida que você cria seu farm de renderização.
Como se conectar à nuvem
Dependendo de sua carga de trabalho, decida como sua instalação se conecta ao Google Cloud, seja por meio de um ISP parceiro, uma conexão direta ou pela Internet pública.
Como se conectar pela Internet
Sem conectividade especial, é possível se conectar à rede do Google e usar nosso modelo de segurança completo acessando os serviços do Google Cloud pela Internet. Utilitários, como as ferramentas de linha de comando gcloud e gsutil, e recursos, como a API do Compute Engine, usam autenticação, autorização e criptografia seguras para ajudar a proteger seus dados.
Cloud VPN
Não importa como você está conectado, recomendamos que você use uma rede privada virtual (VPN, na sigla em inglês) para proteger sua conexão.
Com o Cloud VPN, você conecta a rede local com segurança à rede de nuvem privada virtual (VPC) do Google por meio de uma conexão VPN IPsec. Os dados em trânsito são criptografados antes de passarem por um ou mais túneis VPN.
Saiba como criar uma VPN para o projeto.
VPN fornecida pelo cliente
Ainda que seja possível configurar seu próprio gateway de VPN para se conectar diretamente ao Google, recomendamos o uso do Cloud VPN, que oferece mais flexibilidade e melhor integração com o Google Cloud.
Cloud Interconnect
O Google dispõe de várias maneiras para conectar sua infraestrutura ao Google Cloud. Essas conexões de nível corporativo, conhecidas coletivamente como Cloud Interconnect, oferecem maior disponibilidade e menor latência que as conexões de Internet padrão, além de preços de saída reduzidos.
O Cross-Cloud Interconnect permite estabelecer uma conectividade dedicada e de alta largura de banda com o Google Cloud para seus dados em outra nuvem. Isso reduz a complexidade da rede, os custos de transferência de dados e permite farms de renderização de alta capacidade de processamento e várias nuvens.
Interconexão dedicada
A Interconexão dedicada fornece conexões físicas diretas e comunicação RFC 1918 entre redes locais e a rede do Google. Ela fornece capacidade de conexão nos seguintes tipos de conexões:
- Uma ou mais conexões Ethernet de 10 Gbps, com um máximo de oito conexões ou total de 80 Gbps por interconexão.
- Uma ou mais conexões Ethernet de 100 Gbps, com um máximo de duas conexões ou total de 200 Gbps por interconexão.
O tráfego da Interconexão dedicada não é criptografado. Se você precisar transmitir dados pela Interconexão dedicada de maneira segura, estabeleça sua própria conexão VPN. O Cloud VPN não é compatível com a Interconexão dedicada. Por isso, é necessário fornecer sua própria VPN nesse caso.
Interconexão por parceiro
Na Interconexão por parceiro, a conectividade entre a rede no local e a rede VPC é intermediada por um provedor de serviços autorizado. Uma conexão do tipo Interconexão por parceiro será útil se a infraestrutura estiver em um local físico sem acesso a uma instalação de colocation da Interconexão dedicada ou se as necessidades de dados não garantirem uma conexão completa de 10 Gbps.
Outros tipos de conexão
Outras maneiras de se conectar ao Google podem estar disponíveis no seu local. Se precisar de ajuda para determinar a maneira ideal e mais econômica de se conectar ao Google Cloud, entre em contato com seu representante do Google Cloud.
Como proteger seu conteúdo
Para exibir conteúdo em qualquer plataforma de nuvem pública, os proprietários dele, como os grandes estúdios de Hollywood, exigem que os fornecedores obedeçam tanto às práticas recomendadas de segurança definidas internamente quanto às prescritas por organizações como a MPAA (em inglês). O Google Cloud oferece modelos de segurança de confiança zero integrados em produtos como o Google Workspace, o Chrome Enterprise Premium e o BeyondProd.
Cada estúdio tem requisitos diferentes para proteger as cargas de trabalho de renderização. Também é possível encontrar artigos sobre segurança e documentação de conformidade em cloud.google.com/security.
Se você tiver dúvidas sobre o processo de auditoria de conformidade de segurança, entre em contato com seu representante do Google Cloud.
Como organizar seus projetos
Os projetos são um componente organizacional essencial do Google Cloud. Na sua instalação, é possível organizar jobs no próprio projeto ou dividi-los em vários projetos. Por exemplo, você pode criar projetos separados para as fases de pré-visualização, pesquisa e desenvolvimento e produção de um filme.
Os projetos estabelecem um limite de isolamento para dados de rede e administração de projetos. Entretanto, você pode compartilhar redes entre projetos com a VPC compartilhada, que oferece projetos separados com acesso a recursos comuns.
Observações de produção: crie um host de VPC compartilhada que contenha recursos com todas as suas ferramentas de produção. É possível designar todos os projetos criados na sua organização como projetos de serviço de VPC compartilhada. Essa designação indica que qualquer projeto na sua organização pode acessar as mesmas bibliotecas, scripts e software que o projeto host fornece.
O recurso Organização
Você pode gerenciar projetos em um recurso Organização que você já tenha estabelecido. Migrar todos os projetos para uma organização oferece vários benefícios.
Observações de produção: designe gerentes de produção como proprietários dos projetos individuais deles e os gerentes do estúdio como proprietários do recurso Organização.
Como definir o acesso a recursos
Os projetos requerem acesso seguro aos recursos e restrições sobre onde os usuários ou serviços podem operar. Para ajudar você a definir o acesso, o Google Cloud oferece o Identity and Access Management (IAM), que pode ser usado para gerenciar o controle de acesso com a definição de papéis e respectivos níveis de acesso a esses recursos.
Observações de produção: para restringir o acesso de usuários somente aos recursos necessários à execução de tarefas específicas ao papel de cada um, implemente o princípio de privilégio mínimo no local e na nuvem.
Por exemplo, considere um trabalhador de renderização, que é uma máquina virtual (VM, na sigla em inglês) que pode ser implantada de um modelo de instância predefinido que usa sua imagem personalizada. O trabalhador de renderização que está sendo executado em uma conta de serviço pode ler no Cloud Storage e gravar no armazenamento anexado, como um arquivador de nuvem ou um disco permanente. No entanto, você não precisa adicionar artistas individuais aos projetos do Google Cloud, já que eles não precisam de acesso direto aos recursos de nuvem.
É possível atribuir papéis para administradores de renderização ou administradores de projetos que tenham acesso a todos os recursos do Compute Engine, o que permite que executem funções em recursos inacessíveis a outros usuários.
Defina uma política para determinar quais papéis podem acessar quais tipos de recursos em sua organização. Na tabela a seguir, mostramos como as tarefas típicas de produção são mapeadas para os papéis do IAM no Google Cloud.
| Tarefa de produção | Nome do papel | Tipo de recurso |
|---|---|---|
| Gerente de estúdio | resourcemanager.organizationAdmin |
Projeto da organização |
| Gerente de produção | owner, editor |
Projeto |
| Administrador de renderização | compute.admin, iam.serviceAccountActor |
Projeto |
| Conta de gerenciamento de filas | compute.admin, iam.serviceAccountActor |
Projeto da organização |
| Artista individual | [sem acesso] | Não aplicável |
Escopos de acesso
Os escopos de acesso oferecem uma maneira de controlar as permissões de uma instância em execução, independentemente de quem esteja conectado. Você pode especificar escopos ao criar uma instância por conta própria ou quando o software de gerenciamento de filas implanta recursos de um modelo de instância.
Os escopos têm precedência sobre as permissões do IAM de um usuário individual ou conta de serviço. Essa precedência significa que um escopo de acesso pode impedir que um administrador de projeto faça login em uma instância para excluir um bucket de armazenamento ou alterar uma configuração de firewall.
Observações de produção: por padrão, as instâncias podem ler, mas não gravar no Cloud Storage. Se o pipeline de renderização faz a regravação de
renderizações concluídas no Cloud Storage, adicione o escopo
devstorage.read_write à sua instância no momento da criação.
Como escolher a maneira de implantar recursos
Com a renderização em nuvem, você pode usar os recursos somente quando necessário, mas pode escolher várias maneiras de disponibilizar os recursos em seu farm de renderização.
Implantar sob demanda
Para otimizar o uso de recursos, você pode optar por implantar os trabalhadores de renderização somente quando enviar um job para o farm de renderização. Você pode implantar várias VMs para serem compartilhadas em todos os frames de um job ou até mesmo criar uma VM por frame.
Seu sistema de gerenciamento de filas pode monitorar instâncias em execução, que podem ser recolocadas em fila se uma VM for rejeitada e encerrada quando as tarefas individuais forem concluídas.
Implantar um pool de recursos
Você também pode optar por implantar um grupo de instâncias, não relacionadas a qualquer job específico, que seu sistema de gerenciamento de filas no local possa acessar como recursos adicionais. Se você usar as VMs spot do Google Cloud, um grupo de instâncias em execução poderá aceitar vários jobs por VM, usando todos os núcleos e maximizando o uso de recursos. Essa abordagem pode ser a estratégia mais simples de implementar, já que simula como um farm de renderização local é preenchido com jobs.
Como licenciar o software
O licenciamento de software de terceiros pode variar muito de pacote para pacote. Veja alguns dos esquemas e modelos de licenciamento que você pode encontrar em um canal de VFX. Para cada esquema, a terceira coluna mostra a abordagem de licenciamento recomendada.
| Esquema | Descrição | Recomendação |
|---|---|---|
| Nó bloqueado | Licenciado para um endereço MAC, endereço IP ou código de CPU específico. Pode ser executado apenas por um único processo. | Com base em instância |
| Com base em nó | Licenciado para um nó específico (instância). Um número arbitrário de usuários ou processos pode ser executado em um nó licenciado. | Com base em instância |
| Flutuante | Verificado a partir de um servidor de licenças que controla o uso. | Servidor de licenças |
| Licenciamento de software | ||
| Interativo | Permite que o usuário execute o software de maneira interativa em um ambiente baseado em gráficos. | Servidor de licenças ou com base em instância |
| Lote | Permite que o usuário execute o software apenas em um ambiente de linha de comando. | Servidor de licenças |
| Licenciamento com base na nuvem | ||
| Com base no uso | Verificado apenas quando um processo é executado em uma instância de nuvem. Quando o processo termina ou é encerrado, a licença é liberada. | Servidor de licenças com base na nuvem |
| Com base no tempo de atividade | Verificado enquanto uma instância está ativa e em execução. Quando a instância é interrompida ou excluída, a licença é liberada. | Servidor de licenças com base na nuvem |
Como usar o licenciamento com base em instância
Alguns programas ou plug-ins são licenciados diretamente para o hardware em que são executados. Essa abordagem do licenciamento pode apresentar um problema na nuvem, em que identificadores de hardware, como endereços MAC ou IP, são atribuídos dinamicamente.
Endereços MAC
Quando eles são criados, as instâncias recebem um endereço MAC que fica retido enquanto a instância não é excluída. Você pode parar ou reiniciar uma instância. O endereço MAC será mantido. Você pode usar esse endereço MAC para criação e validação de licenças até que a instância seja excluída.
Como atribuir um endereço IP estático
Quando uma instância é criada, ela recebe um endereço IP interno e, se você quiser, um endereço IP externo. Para reter o endereço IP externo de uma instância, você pode reservar um endereço IP estático e atribuí-lo à sua instância. Esse endereço IP será reservado apenas para essa instância. Como os endereços IP estáticos são um recurso com base em projeto, eles estão sujeitos a cotas regionais.
Você também pode atribuir um endereço IP interno ao criar uma instância, o que é útil se você quiser que os endereços IP internos de um grupo de instâncias estejam dentro do mesmo intervalo.
Dongles de hardware
Produtos de software mais antigos ainda podem ser licenciados por meio de um dongle, uma chave de hardware programada com uma licença de produto. A maioria das empresas de software parou de usar dongles de hardware, mas alguns usuários podem ter softwares herdados que são vinculados a um desses dispositivos. Se você encontrar esse problema, entre em contato com o fabricante do software para ver se eles podem fornecer uma licença atualizada do software específico.
Se isso não for possível, você pode implementar um hub USB conectado à rede ou uma solução de USB por IP.
Como usar um servidor de licenças
A maioria dos softwares modernos oferece uma opção de licença flutuante. Essa opção faz mais sentido em um ambiente de nuvem, mas requer gerenciamento de licenças e controle de acesso mais rigorosos para evitar o consumo excessivo de um número limitado de licenças.
Para ajudar a evitar que sua capacidade de licenças seja excedida, você pode, como parte do processo da fila de jobs, escolher quais licenças usar e controlar o número de jobs que as utilizam.
Servidor de licenças local
Você pode usar seu servidor de licenças local existente para fornecer licenças a instâncias em execução na nuvem. Se você escolher esse método, é necessário providenciar uma maneira para os trabalhadores de renderização se comunicarem com a rede local, seja por meio de uma VPN ou alguma outra conexão segura.
Servidor de licenças com base na nuvem
Na nuvem, você pode executar um servidor de licenças que disponibilize instâncias em seu projeto ou até entre projetos usando a VPC compartilhada. Algumas vezes, as licenças flutuantes são vinculadas a um endereço MAC do hardware. Assim, uma pequena instância de longa duração com um endereço IP estático pode disponibilizar licenças facilmente a muitas instâncias de renderização.
Servidor de licenças híbrido
Alguns produtos de software podem usar vários servidores de licenças em uma ordem de prioridade. Por exemplo, um renderizador pode consultar o número de licenças disponíveis em um servidor local e, se nenhuma estiver disponível, usar um servidor de licenças com base em nuvem. Essa estratégia pode ajudar a maximizar o uso de licenças permanentes antes de você alocar outros tipos de licença.
Observações de produção: defina um ou mais servidores de licenças em uma variável de ambiente e defina a ordem de prioridade. O Autodesk Arnold, um renderizador bem conhecido, ajuda você a fazer isso. Se o job não puder adquirir uma licença usando o primeiro servidor, ele tentará usar outros servidores listados, como no exemplo a seguir:
export solidangle_LICENSE=5053@x.x.0.1;5053@x.x.0.2
No exemplo anterior, o renderizador Arnold tenta conseguir uma licença
do servidor em x.x.0.1, porta 5053. Se essa tentativa falhar, ele tentará conseguir
uma licença na mesma porta no endereço IP x.x.0.2.
Licenciamento com base na nuvem
Alguns fornecedores oferecem licenciamento na nuvem com licenças de software sob demanda para suas instâncias. O licenciamento na nuvem geralmente é faturado de duas maneiras: com base no uso e no tempo de atividade.
Licenciamento com base no uso
O licenciamento com base no uso é faturado com base em quanto tempo o software está em uso. Normalmente, com esse tipo de licenciamento, uma licença é registrada em um servidor com base na nuvem quando o processo é iniciado e liberada quando o processo é concluído. Enquanto uma licença é verificada, você é faturado pelo uso dessa licença. Normalmente, esse tipo de licenciamento é usado para software de renderização.
Licenciamento baseado em tempo de atividade
Licenças baseadas em tempo de atividade ou medidas são faturadas com base no tempo de atividade de sua instância do Compute Engine. A instância é configurada para registrar-se no servidor de licenças baseado na nuvem durante o processo de inicialização. Enquanto a instância estiver em execução, a licença ficará alocada. Quando a instância é interrompida ou excluída, a licença é liberada. Normalmente, esse tipo de licenciamento é usado para trabalhadores de renderização que um gerenciador de filas implanta.
Como escolher a maneira de armazenar seus dados
O tipo de armazenamento escolhido no Google Cloud depende da estratégia de armazenamento escolhida, além de fatores como requisitos de durabilidade e custo.
Disco permanente
É possível evitar a implementação de um servidor de arquivos incorporando discos permanentes (DPs) à sua carga de trabalho. Os PDs são um tipo de armazenamento em blocos compatível com POSIX, com tamanho de até 64 TB, conhecidos da maioria das instalações de VFX. Os discos permanentes estão disponíveis como unidades padrão e unidades de estado sólido (SSD, na sigla em inglês). Você pode anexar um PD no modo de leitura/gravação a uma única instância ou no modo somente leitura a um grande número de instâncias, como um grupo de trabalhadores de renderização.
| Prós | Contras | Caso de uso ideal |
|---|---|---|
| Ativado como um volume NFS ou SMB padrão. Pode ser redimensionado dinamicamente. Até 128 DPs podem ser anexados a uma única instância. O mesmo DP pode ser ativado como somente leitura em centenas ou milhares de instâncias. |
Tamanho máximo de 64 TB. Só é possível gravar no DP quando conectado a uma única instância. Só pode ser acessado por recursos que estão na mesma região. |
Canais avançados que podem criar um novo disco por job. Pipelines que disponibilizam dados atualizados com pouca frequência, como software ou bibliotecas comuns, para workers de renderização. |
Armazenamento de objetos
O Cloud Storage é um armazenamento altamente redundante e durável que, diferente de sistemas de arquivos tradicionais, é desestruturado e praticamente ilimitado em termos de capacidade. Os arquivos no Cloud Storage são armazenados em buckets, semelhantes a pastas, e são acessíveis em todo o mundo.
Diferente do armazenamento tradicional, o armazenamento de objetos não pode ser ativado como um volume lógico por um sistema operacional (SO). Se você decidir incorporar o armazenamento de objetos em seu pipeline de renderização, será necessário modificar a maneira de ler e gravar dados, seja por meio de utilitários de linha de comando, como a gsutil, ou por meio da API do Cloud Storage.
| Prós | Contras | Caso de uso ideal |
|---|---|---|
| Armazenamento durável e altamente disponível para arquivos de todos os tamanhos. API única em classes de armazenamento. Não muito caro. Os dados estão disponíveis em todo o mundo. Capacidade praticamente ilimitada. |
Não é compatível com POSIX. Precisa ser acessado por meio de API ou utilitário de linha de comando. Em um pipeline de renderização, os dados precisam ser transferidos localmente antes do uso. |
Canais de renderização com um sistema de gerenciamento de recursos que possa publicar dados no Cloud Storage. Pipelines de renderização com um sistema de gerenciamento de filas capaz de buscar dados do Cloud Storage antes da renderização. |
Outros produtos de armazenamento
Outros produtos de armazenamento estão disponíveis como serviços gerenciados, por meio de canais de terceiros, como o Cloud Marketplace, ou como projetos de código aberto por meio de repositórios de software ou do GitHub.
| Produto | Prós | Contras | Caso de uso ideal |
|---|---|---|---|
| Filestore | Sistema de arquivos em cluster compatível com milhares de conexões NFS simultâneas. Capaz de sincronizar com o cluster NAS no local. |
Não há maneira de sincronizar arquivos seletivamente. Não há sincronização bidirecional. | Instalações de VFX de médio a grande porte com centenas de terabytes de dados para apresentar na nuvem. |
| Pixit Media, PixStor | Sistema de arquivos em escala que pode aceitar milhares de clientes NFS ou POSIX simultâneos. Os dados podem ser armazenados em cache sob demanda a partir do NAS local, com as atualizações enviadas automaticamente de volta ao armazenamento local. | Custo, compatibilidade com terceiros da Pixit. | Instalações de VFX de médio a grande porte com centenas de terabytes de dados para apresentar na nuvem. |
| Google Cloud NetApp Volumes | Solução de armazenamento totalmente gerenciada no Google Cloud. Compatível com ambientes NFS, SMB e multiprotocolo. Snapshots pontuais com recuperação de instância |
Não está disponível em todas as regiões do Google Cloud. | Instalações de VFX com um pipeline capaz de sincronizar
recursos. Disco compartilhado entre estações de trabalho virtuais. |
| Cloud Storage FUSE | Ative buckets do Cloud Storage como sistemas de arquivos. Baixo custo. | Não é um sistema de arquivos compatível com POSIX. Pode ser difícil de configurar e otimizar. | Instalações de VFX capazes de implantar, configurar e manter um sistema de arquivos de código aberto, com um canal capaz de sincronizar os recursos. |
Outros tipos de armazenamento estão disponíveis no Google Cloud. Para saber mais, entre em contato com seu representante do Google Cloud.
Outras leituras sobre opções de armazenamento de dados
- Opções de armazenamento disponíveis no Google Cloud
- Armazenamento de arquivos no Compute Engine
- Projetar uma estratégia de armazenamento ideal para sua carga de trabalho na nuvem
Como implantar estratégias de armazenamento
Você pode implementar várias estratégias de armazenamento em canais de produção de animação ou VFX, estabelecendo convenções que determinam como manipular seus dados, quer você acesse os dados diretamente de seu armazenamento local ou sincronize entre o armazenamento local e a nuvem.
Estratégia 1: ativar o armazenamento local diretamente
Se sua instalação tiver conectividade com o Google Cloud de pelo menos 10 Gbps e estiver próxima de uma região do Google Cloud, será possível optar por ativar seu NAS no local diretamente nos workers de renderização na nuvem. Essa estratégia é simples, mas também pode ser cara em termos de custo e largura de banda, porque tudo que você cria na nuvem e grava de volta no armazenamento é contado como dados de saída.
| Prós | Contras | Caso de uso ideal |
|---|---|---|
| Implementação direta. Leitura/gravação no armazenamento comum. Disponibilidade imediata dos dados, sem necessidade de armazenamento em cache ou sincronização. |
Pode ser mais cara que outras opções. A proximidade de um data center do Google é necessária para alcançar baixa latência. O número máximo de instâncias que podem se conectar ao seu NAS no local depende da sua largura de banda e do tipo de conexão. |
Instalações próximas a um data center do Google que precisam disparar cargas de trabalho de renderização na nuvem, onde o custo não é uma preocupação. Instalações com conectividade com o Google Cloud de pelo menos 10 Gbps. |
Estratégia 2: sincronizar sob demanda
É possível optar por enviar dados para a nuvem ou receber dados do armazenamento no local, ou vice-versa, somente quando os dados forem necessários, como quando um quadro é renderizado ou um recurso é publicado. Se você usar essa estratégia, a sincronização poderá ser acionada por um mecanismo em seu pipeline, como um script de observação, por um manipulador de eventos, como o Pub/Sub, ou por um conjunto de comandos, como parte do script de um job.
É possível executar uma sincronização usando vários comandos, como o comando scp do gcloud, o comando rsync da gsutil ou os protocolos de transferência de dados baseados em UDP (UDT). Se você optar por usar um UDT de terceiros, como o Aspera, o Cloud FastPath, o BitSpeed ou o FDT para se comunicar com um bucket do Cloud Storage, consulte a documentação do fornecedor para conhecer o modelo de segurança e as práticas recomendadas dele. O Google não gerencia esses serviços de terceiros.
Método push
Normalmente, você usa o método push ao publicar um recurso, colocar um arquivo em uma pasta monitorada ou concluir um job de renderização. Depois disso, você o envia para um local predefinido.
Exemplos:
- Um worker de renderização na nuvem conclui um job de renderização e os frames resultantes são enviados de volta para o armazenamento local.
- Um artista publica um recurso. Parte do processo de publicação de recursos envolve enviar os dados associados para um caminho predefinido no Cloud Storage.
Método pull
Você usa o método pull quando um arquivo é solicitado, geralmente por uma instância de renderização baseada em nuvem.
Exemplo: como parte de um script de job de renderização, todos os recursos necessários para renderizar uma cena são enviados para um sistema de arquivos antes da renderização, onde todos os operadores de renderização podem acessá-los.
| Prós | Contras | Caso de uso ideal |
|---|---|---|
| Controle completo sobre quais dados são sincronizados e quando. Capacidade de escolher o método e o protocolo de transferência. |
Seu canal de produção precisa ser capaz de processar eventos para acionar sincronizações push/pull. Recursos extras podem ser necessários para processar a fila de sincronização. |
Pequenas e grandes instalações que têm canais personalizados e querem ter controle total sobre a sincronização de recursos. |
Observações de produção: gerencie a sincronização de dados com o mesmo sistema de gerenciamento de filas usado para processar jobs de renderização. As tarefas de sincronização podem usar recursos da nuvem separados para maximizar a largura de banda disponível e minimizar o tráfego de rede.
Estratégia 3: armazenamento no local, cache de leitura baseado em nuvem
O Google Cloud ampliou e desenvolveu uma solução de armazenamento em cache KNFSD como uma opção de código aberto. A solução pode lidar com demandas de desempenho do farm de renderização que excedem os recursos da infraestrutura de armazenamento. O armazenamento em cache do KNFSD oferece armazenamento em cache de leitura e alto desempenho, o que permite que as cargas de trabalho sejam escalonadas para centenas ou até milhares de nós de renderização em várias regiões e pools de armazenamento híbrido.
O armazenamento em cache do KNFSD é uma solução de escalonamento horizontal que reduz a carga no serviço de compartilhamento de arquivos principal. O armazenamento em cache do KNFSD também reduz o efeito de sobrecarga quando muitos nós de renderização tentam recuperar arquivos do servidor de arquivos ao mesmo tempo. Ao usar uma camada de armazenamento em cache na mesma rede VPC que os nós de renderização, a latência de leitura é reduzida, o que ajuda a iniciar e concluir jobs mais rapidamente. Dependendo de como você configurou o servidor de arquivos de armazenamento em cache, os dados permanecerão no cache até:
- os dados envelhecerem ou permanecem intocados por um período especificado;
- o espaço for necessário no servidor de arquivos, momento em que os dados serão removidos do cache com base na idade.
Essa estratégia reduz a quantidade de largura de banda e a complexidade necessárias para implantar muitas instâncias de renderização simultâneas.
Em alguns casos, é possível pré-aquecer seu cache para garantir que todos os dados relacionados ao job estejam presentes antes da renderização. Para preaquecer o cache, leia o
conteúdo de um diretório que está no servidor de arquivos na nuvem executando um read
ou stat de um ou mais arquivos. Acessar arquivos dessa maneira aciona o mecanismo de sincronização.
Também é possível adicionar um dispositivo físico local para se comunicar com o dispositivo virtual. Por exemplo, a NetApp oferece uma solução de armazenamento que pode reduzir ainda mais a latência entre o armazenamento no local e a nuvem.
| Prós | Contras | Caso de uso ideal |
|---|---|---|
| Os dados armazenados em cache são gerenciados automaticamente. Reduz os requisitos de largura de banda. Os sistemas de arquivos na nuvem em cluster podem ser ampliados ou reduzidos, dependendo dos requisitos do job. |
Pode haver custos adicionais. As tarefas pré-job precisam ser implementadas se você optar por preaquecer o cache. |
Grandes instalações que implantam várias instâncias simultâneas e leem recursos comuns em várias tarefas. |
Como filtrar dados
Você pode criar um banco de dados de tipos de recursos e condições associadas para definir se quer sincronizar um determinado tipo de dados. Pode não ser conveniente sincronizar alguns tipos de dados, como os efêmeros gerados como parte de um processo de conversão, os arquivos de cache ou os dados de simulação. Pense também se é necessário sincronizar recursos não aprovados, porque nem todas as iterações serão usadas em renderizações finais.
Como fazer uma transferência em massa inicial
Ao implementar seu render farm híbrido, é possível executar uma transferência inicial de todo ou parte de seu conjunto de dados para o Cloud Storage, disco permanente ou outro armazenamento baseado em nuvem. Dependendo de fatores como a quantidade e o tipo de dados a transferir e a velocidade de sua conexão, talvez você possa executar uma sincronização completa em poucos dias ou semanas. A figura a seguir compara os tempos típicos para transferências on-line e físicas.
Se sua carga de trabalho de transferência exceder suas restrições de tempo ou largura de banda, use uma das várias opções de transferência do Google para colocar seus dados na nuvem, incluindo o Transfer Appliance.
Arquivamento e recuperação de desastres
Vale a pena observar a diferença entre o arquivamento de dados e a recuperação de desastres. O primeiro é uma cópia seletiva do trabalho finalizado, enquanto o segundo é um estado de dados que pode ser recuperado. Convém criar um plano de recuperação de desastres que atenda às necessidades da sua instalação e ofereça um plano de contingência externo. Consulte seu fornecedor de armazenamento local para receber ajuda com um plano de recuperação de desastres adequado à sua plataforma de armazenamento específica.
Como arquivar dados na nuvem
Após a conclusão de um projeto, é comum salvar o trabalho concluído em alguma forma de armazenamento de longo prazo, normalmente mídia de fita magnética, como LTO (em inglês). Eles estão sujeitos a requisitos ambientais e, com o tempo, podem ser logisticamente desafiadores de gerenciar. As grandes instalações de produção abrigam, às vezes, todo o arquivo em uma sala construída para esse fim, com um arquivista em tempo integral para acompanhar os dados e recuperá-los quando solicitados.
A pesquisa de recursos, imagens ou filmagens arquivados específicos pode consumir muito tempo, já que os dados podem estar armazenados em vários cartuchos, a indexação de arquivos pode estar ausente ou incompleta, ou pode haver limitações de velocidade na leitura de dados da fita magnética.
Migrar seu arquivo de dados para a nuvem pode não só eliminar a necessidade de gerenciamento local e armazenamento da mídia de arquivamento, mas também pode tornar seus dados muito mais acessíveis e pesquisáveis do que os métodos tradicionais de arquivamento.
Um canal de arquivamento básico pode se parecer com o diagrama a seguir, empregando diferentes serviços de nuvem para examinar, categorizar, marcar e organizar arquivos. Da nuvem, você pode criar uma ferramenta de gerenciamento e recuperação de arquivos para pesquisar dados usando vários critérios de metadados, como data, projeto, formato ou resolução. Também é possível usar as APIs de aprendizado de máquina para marcar e categorizar imagens e vídeos, armazenando os resultados em um banco de dados baseado na nuvem, como o BigQuery.
Outros tópicos a considerar:
- Automatize a geração de miniaturas ou proxies para conteúdo que reside em classes de armazenamento do Cloud Storage que têm taxas de recuperação. Use esses proxies em seu sistema de gerenciamento de recursos de mídia para que os usuários possam procurar dados ao ler somente os proxies, não os recursos arquivados.
- Use o machine learning para categorizar o conteúdo live-action. Use o Cloud Vision para rotular texturas e placas de segundo plano ou a API Video Intelligence para ajudar com a pesquisa e a recuperação de filmagem de referência.
- Também é possível usar a imagem do AutoML na Vertex AI para criar um modelo de imagem personalizado para reconhecer qualquer recurso, seja de ação ao vivo ou renderizado.
- Para conteúdo renderizado, avalie a possibilidade de salvar uma cópia da imagem de disco do worker de renderização junto com o recurso renderizado. Se for necessário recriar a configuração, você terá as versões de software, os plug-ins, as bibliotecas do sistema operacional e as dependências corretas disponíveis se precisar renderizar novamente uma captura arquivada.
Como gerenciar recursos e produção
Trabalhar no mesmo projeto em várias instalações pode apresentar desafios únicos, especialmente quando o conteúdo e os recursos precisam estar disponíveis em todo o mundo. A sincronização manual de dados em redes privadas pode ser cara e consumir muitos recursos. Além disso, está sujeita a limitações de largura de banda local.
Se sua carga de trabalho exigir dados disponíveis globalmente, você poderá usar o Cloud Storage, que pode ser acessado de qualquer lugar em que você possa acessar os serviços do Google. Para incorporar o Cloud Storage em seu canal, você precisa modificar seu canal para entender os caminhos de objetos e, em seguida, receber por pull ou enviar por push seus dados para os trabalhadores de renderização antes da renderização. O uso desse método fornece acesso global a dados publicados, mas exige que seu canal forneça recursos onde eles são necessários em um período razoável.
Por exemplo, um artista de textura em Los Angeles pode publicar arquivos de imagem para serem usados por um artista de iluminação em Londres. O processo tem esta aparência:
- O pipeline de publicação envia arquivos para o Cloud Storage e adiciona uma entrada a um banco de dados de recursos baseado na nuvem.
- Um artista em Londres executa um script para reunir recursos para uma cena. Os locais dos arquivos são consultados no banco de dados e lidos do Cloud Storage para o disco local.
- O software de gerenciamento de filas reúne uma lista de recursos necessários para renderização, consulta-os a partir do banco de dados de recursos e faz o download deles do Cloud Storage para o armazenamento local de cada worker de renderização.
Usar o Cloud Storage dessa maneira também fornece um arquivo de todos os seus dados publicados na nuvem, se você optar por usar o Cloud Storage como parte de seu pipeline de arquivamento.
Como gerenciar bancos de dados
O software de gerenciamento de recursos e produção depende de bancos de dados duráveis e altamente disponíveis que são disponibilizados em hosts capazes de lidar com centenas ou milhares de consultas por segundo. Normalmente, os bancos de dados são hospedados em um servidor local que está em execução no mesmo rack que os trabalhadores de renderização e estão sujeitos às mesmas limitações de energia, rede e AVAC.
Você pode pensar em executar os bancos de dados de produção MySQL, NoSQL e PostgreSQL como serviços gerenciados baseados em nuvem. Esses serviços são altamente disponíveis e acessíveis globalmente, criptografam dados em repouso e em trânsito e oferecem funcionalidade de replicação incorporada.
Como gerenciar filas
Programas de software de gerenciamento de filas disponíveis comercialmente, como Qube!, Deadline e Tractor são amplamente utilizados no setor de animação/VFX. Também há opções de software de código aberto disponíveis, como o OpenCue (em inglês). É possível usar este software para implantar e gerenciar qualquer carga de trabalho de computação em vários trabalhadores, não apenas renderizadores. Você pode implantar e gerenciar a publicação de recursos, simulações de partículas e fluidos, cozimento de textura e composição com a mesma estrutura de programação usada para gerenciar renderizadores.
Algumas instalações implementaram software de programação de uso geral, como o HTCondor da Universidade de Winsconsin, o Slurm da SchedMD ou o Univa Grid Engine nos pipelines de efeitos visuais (VFX). O software projetado especificamente para o setor de VFX, no entanto, é dedicado especialmente a recursos como estes:
- Dependência baseada em job, frame e camada. Algumas tarefas precisam ser concluídas antes de começar outros jobs. Por exemplo, execute uma simulação de fluidos em sua totalidade antes de renderizar.
- Prioridade de jobs, que os administradores de renderização podem usar para mudar a ordem dos jobs com base em prazos e programações individuais.
- Tipos de recursos, rótulos ou destinos, que podem ser usados para relacionar recursos específicos com os jobs que os exigem. Por exemplo, implemente processamentos acelerados por GPU somente em VMs que tenham GPUs conectadas.
- Capturar dados históricos sobre o uso de recursos e disponibilizá-los por meio de uma API ou painel para análise mais profunda. Por exemplo, observe o uso médio de CPU e memória nas últimas iterações de uma renderização para prever o uso de recursos para a próxima iteração.
- Jobs pré e pós-renderização. Por exemplo, um job pré-renderização adquire todos os recursos necessários no worker de renderização local antes da renderização. Um job pós-renderização copia o frame renderizado resultante para um local designado em um sistema de arquivos e, em seguida, marca o frame como concluído em um sistema de gerenciamento de recursos.
- Integração com aplicativos de software 2D e 3D conhecidos, como o Maya, o 3ds Max, o Houdini, o Cinema 4D ou o Nuke.
Observações de produção: use o software de gerenciamento de filas para reconhecer um conjunto de recursos baseados na nuvem como se fossem workers de renderização no local. Esse método requer um pouco de supervisão para maximizar o uso de recursos executando o máximo de renderizadores que cada instância pode processar, uma técnica conhecida como empacotamento. Normalmente, essas operações são tratadas de forma algorítmica e por administradores de renderização.
Também é possível automatizar a criação, o gerenciamento e o encerramento de recursos baseados em nuvem sob demanda. Esse método depende do gerenciador de filas para executar scripts pré e pós-renderização que criam recursos conforme necessário, os monitoram durante a renderização e os encerram quando as tarefas são concluídas.
Considerações sobre a implantação de jobs
Quando você está implementando um farm de renderização que usa o armazenamento local e o baseado na nuvem, veja algumas considerações que seu gerente de filas pode precisar ter em mente:
- O licenciamento pode ser diferente entre implantações na nuvem e no local. Algumas licenças são baseadas em nós, outras são acionadas pelo processo. Certifique-se de que seu software de gerenciamento de filas implante jobs para maximizar o valor de suas licenças.
- Avalie a possibilidade de adicionar tags ou rótulos exclusivos a recursos baseados em nuvem para garantir que eles sejam usados somente quando atribuídos a tipos de job específicos.
- Use o Cloud Logging para detectar instâncias ociosas ou não usadas.
- Ao iniciar jobs dependentes, considere onde os dados resultantes residirão e onde eles precisam estar para a próxima etapa.
- Se os namespaces do seu caminho forem diferentes entre o armazenamento local e o baseado na nuvem, considere o uso de caminhos relativos para permitir que os renderizadores sejam independentes da localização. Como alternativa, dependendo da plataforma, é possível criar um mecanismo para trocar caminhos no momento da renderização.
- Alguns renderizadores, simulações ou pós-processos dependem da geração de números aleatórios, o que pode ser diferente entre os fabricantes de CPUs. Mesmo CPUs do mesmo fabricante, mas com diferentes gerações de chips, podem produzir resultados diferentes. Em caso de dúvida, use tipos de CPU idênticos ou semelhantes para todos os frames de um job.
- Se você estiver usando um dispositivo de cache de leitura, considere implantar um job de pré-renderização para pré-aquecer o cache e garantir que todos os recursos estejam disponíveis na nuvem antes de implantar recursos nela. Essa abordagem minimiza o tempo que os workers de renderização são forçados a aguardar enquanto os recursos são movidos para a nuvem.
Registro e monitoramento
Registrar e monitorar o uso e o desempenho de recursos é um aspecto essencial de qualquer farm de renderização. O Google Cloud oferece várias APIs, ferramentas e soluções para ajudar a fornecer insights sobre a utilização de recursos e serviços.
A maneira mais rápida de monitorar a atividade de uma VM é visualizar a saída da porta serial. Essa saída pode ser útil quando uma instância não responde por meio de planos típicos de controle de serviço, como o supervisor de gerenciamento de filas de renderização.
Outras maneiras de coletar e monitorar o uso de recursos no Google Cloud incluem:
- Uso do Cloud Logging para capturar registros de uso e auditoria e para exportar os registros resultantes para o Cloud Storage, BigQuery e outros serviços.
- Uso do Cloud Monitoring para instalar um agente nas suas VMs e monitorar as métricas do sistema.
- Incorporação da API Cloud Logging aos scripts de pipeline para fazer o registro diretamente no Cloud Logging usando as bibliotecas de cliente de linguagens de script conhecidas.
- Use o Cloud Monitoring para criar gráficos e entender o uso dos recursos.
Como configurar as instâncias do worker de renderização
Para que sua carga de trabalho seja verdadeiramente híbrida, os nós de renderização locais precisam ser idênticos aos nós de renderização baseados em nuvem, com versões do SO, compilações de kernel, bibliotecas instaladas e software correspondentes. Você também pode precisar reproduzir pontos de ativação, namespaces de caminhos e até ambientes de usuário na nuvem, porque eles estão no local.
Como escolher uma imagem de disco
É possível escolher uma das imagens públicas ou criar sua própria imagem personalizada baseada na imagem de nó de renderização no local. As imagens públicas incluem uma coleção de pacotes que configuram e gerenciam contas de usuário e permitem a autenticação baseada em chaves (SSH) Secure Shell.
Criar uma imagem personalizada
Se você optar por criar uma imagem personalizada, precisará adicionar mais bibliotecas ao Linux e ao Windows para que elas funcionem corretamente no ambiente do Compute Engine.
Sua imagem personalizada precisa estar em conformidade com as práticas recomendadas de segurança. Se você estiver usando o Linux, instale o ambiente de convidado do Linux para Compute Engine a fim de acessar a funcionalidade que as imagens públicas fornecem por padrão. Com a instalação do ambiente convidado, é possível executar tarefas, como acesso a metadados, configuração do sistema e otimização do SO para uso no Google Cloud, usando, na imagem personalizada, os mesmos controles de segurança que você usa em imagens públicas.
Observações de produção: gerencie suas imagens personalizadas em um projeto separado no nível da organização. Essa abordagem oferece um controle mais preciso sobre como as imagens são criadas ou modificadas e permite aplicar versões, o que pode ser útil ao usar diferentes versões de software ou SO em várias produções.
Como automatizar a criação de imagens e a implantação de instâncias
Você pode usar ferramentas como o Packer para tornar a criação de imagens mais reproduzível, auditável, configurável e confiável. Também é possível usar uma ferramenta como o Ansible para configurar os nós de renderização em execução e exercer controle refinado sobre a configuração e o ciclo de vida dos nós.
Como escolher um tipo de máquina
No Google Cloud, é possível escolher um dos tipos de máquinas predefinidos ou especificar um tipo de máquina personalizado. O uso de tipos de máquina personalizados permite que você controle os recursos para personalizar instâncias com base nos tipos de job executados no Google Cloud. Ao criar uma instância, é possível adicionar GPUs e especificar o número de CPUs, a plataforma de CPU, a quantidade de RAM e o tipo e o tamanho dos discos.
Observações de produção: para canais que implantam uma instância por frame, avalie a possibilidade de personalizar a instância com base nas estatísticas históricas do job, como carga da CPU ou uso da memória, para otimizar o uso de recursos em todos os frames de uma captura. Por exemplo, você pode optar por implantar máquinas com contagens de CPU mais altas para frames que contêm forte desfoque de movimento para ajudar a normalizar os tempos de renderização em todos os frames.
Como escolher entre VMs padrão e preemptivas
As VMs preemptivas (PVMs) referem-se à capacidade excessiva do Compute Engine que é vendida a um preço mais baixo que as VMs padrão. O Compute Engine pode encerrar ou forçar a interrupção dessas instâncias se outras tarefas exigirem acesso a essa capacidade. As PVMs são ideais para renderizar cargas de trabalho que são tolerantes a falhas e gerenciadas por um sistema de enfileiramento que monitora os jobs que foram perdidos para a preempção.
VMs padrão podem ser executadas indefinidamente e são ideais para servidores de licenças ou hosts de administrador de filas que precisam ser executados de maneira persistente.
As VMs preemptivas são encerradas automaticamente após 24 horas. Portanto, não as use para executar renderizações ou simulações que são executadas por mais tempo.
As taxas de preempção variam de 5% a 15%, o que é provavelmente tolerável para cargas de trabalho típicas de renderização, dado o custo reduzido. Algumas práticas recomendadas preemptivas podem ajudar a decidir a melhor maneira para integrar PVMs em seu canal de renderização. Se a instância for antecipada, o Compute Engine enviará um sinal de preempção para a instância, que pode ser usado a fim de acionar seu programador para encerrar o job atual e enfileirar novamente.
| VM padrão | VM preemptiva |
|---|---|
| Pode ser usada para jobs de longa duração. Ideal para jobs de alta prioridade com prazos rígidos. Pode ser executada indefinidamente. Portanto, é ideal para servidores de licenças ou hospedagem de administrador de filas. |
Encerrada automaticamente após 24 horas. Requer um sistema de gerenciamento de filas para lidar com instâncias preemptivas. |
Observações de produção: alguns renderizadores podem executar um instantâneo de uma renderização em progresso nos intervalos especificados. Portanto, se a VM for antecipada, será possível pausar e continuar a renderização sem precisar reiniciar um frame desde o início. Se o renderizador for compatível com geração de instantâneos e você optar por usar PVMs, ative a geração de instantâneos de renderização em seu canal para evitar a perda de trabalho. Enquanto os instantâneos estão sendo gravados e atualizados, os dados podem ser gravados no Cloud Storage e, se o trabalhador de renderização conseguir permissão, são recuperados quando uma nova PVM é implantada. Para evitar custos de armazenamento, exclua os dados de instantâneos de renderizações concluídas.
Como conceder acesso a workers de renderização
O IAM ajuda você a conceder acesso a recursos da nuvem a pessoas que precisam dele. Para os workers de renderização do Linux, é possível usar o Login do SO para restringir ainda mais o acesso a uma sessão SSH, concedendo a você controle sobre quem é um administrador.
Como controlar custos de um render farm híbrido
Ao estimar custos, você precisa considerar vários fatores, mas recomendamos que implemente essas práticas recomendadas comuns como política para seu farm de renderização híbrido:
- Use instâncias preemptivas por padrão. A menos que seu job de renderização seja extremamente demorado (quatro ou mais horas por frame) ou você tenha um prazo rígido para entregar uma imagem, use VMs preemptivas.
- Minimize a saída. Copie apenas os dados necessários de volta para o armazenamento local. Na maioria dos casos, esses dados serão os frames renderizados finais, mas também podem ser passagens separadas ou dados de simulação. Se você estiver montando o NAS no local diretamente ou usando um produto de armazenamento sincronizado automaticamente, grave todos os dados renderizados no sistema de arquivos no local do worker de renderização. Depois, copie o que você precisa de volta para o armazenamento no local para evitar a saída de dados temporários e desnecessários.
- VMs de tamanho correto. Crie seus workers de renderização com o uso ideal de recursos, atribuindo somente o número necessário de vCPUs, a quantidade ideal de RAM e o número correto de GPUs, se houver. Avalie também como minimizar o tamanho de qualquer disco conectado.
- Considere o mínimo de um minuto. No Google Cloud, as instâncias são cobradas por segundo com um mínimo de um minuto. Se sua carga de trabalho incluir frames de renderização que levem menos de um minuto, considere agrupar as tarefas em conjunto para evitar a implantação de uma instância por menos de um minuto de tempo de computação.
- Mantenha grandes conjuntos de dados na nuvem. Se você usar seu farm de renderização para gerar grandes quantidades de dados, como EXRs profundos ou dados de simulação, avalie a possibilidade de usar uma estação de trabalho baseada em nuvem que esteja mais além do pipeline. Por exemplo, um artista FX pode executar uma simulação de fluido na nuvem, gravando arquivos em cache no armazenamento baseado em nuvem. Um artista de iluminação pode acessar esses dados de simulação em uma estação de trabalho virtual no Google Cloud. Para mais informações sobre estações de trabalho virtuais, entre em contato com seu representante do Google Cloud.
- Aproveite os descontos por uso prolongado e contínuo. Se você executar um pool de recursos, os descontos por uso prolongado poderão economizar até 30% do custo das instâncias executadas durante um mês inteiro. Os descontos por uso contínuo também podem fazer sentido em alguns casos.
Estender seu farm de renderização atual para a nuvem é uma maneira econômica de usar recursos avançados e de baixo custo sem despesas de capital. Não há dois pipelines de produção iguais. Portanto, nenhum documento pode abranger todos os tópicos e requisitos específicos. Para receber ajuda com a migração das cargas de trabalho de renderização para a nuvem, entre em contato com seu representante do Google Cloud.
A seguir
- Executar prova de conceito de um farm de renderização híbrido.
- Confira arquiteturas de referência, diagramas, tutoriais e práticas recomendadas do Google Cloud. Confira o Centro de arquitetura do Cloud.