Como criar um farm de renderização híbrido

Este artigo fornece orientações sobre como ampliar seu farm de renderização existente no local para usar recursos de computação no Google Cloud Platform (GCP). Neste artigo, pressupomos que você já implementou um farm de renderização local e está familiarizado com os conceitos básicos de efeitos visuais (VFX, na sigla em inglês) e canais 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.

Algumas instalações pequenas ou médias que não dispõem dos recursos técnicos para implementar um farm de renderização híbrido podem usar o serviço de farm de renderização do Google, o Zync. Para ajudar a determinar a solução ideal para suas instalações, fale com seu representante do GCP.

Observação: as observações de produção aparecem periodicamente ao longo deste artigo. Elas oferecem práticas recomendadas a serem seguidas à medida que você cria seu farm de renderização.

Como se conectar à nuvem

Dependendo da sua carga de trabalho, decida como sua instalação se conecta ao GCP, seja por meio de um provedor parceiro, uma conexão direta ou pela Internet pública.

Como se conectar pela Internet

Sem qualquer conectividade especial, você pode se conectar à rede do Google e usar nosso modelo de segurança de ponta a ponta acessando os serviços do GCP 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 segura, autorização e criptografia 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.

O Cloud VPN ajuda a conectar a rede local com segurança à rede de nuvem privada virtual (VPC, na sigla em inglês) 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

Você pode configurar seu próprio gateway de VPN para se conectar diretamente ao Google, mas recomendamos usar o Cloud VPN, que oferece mais flexibilidade e melhor integração com o GCP.

Cloud Interconnect

O Google oferece várias maneiras de conectar sua infraestrutura ao GCP. 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, com preços de saída reduzidos.

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. Ele 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, mas se você precisar transmitir dados através da interconexão dedicada de maneira segura, é necessário estabelecer 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.

Partner Interconnect

A Partner Interconnect fornece conectividade entre sua rede local e sua rede VPC por meio de um provedor de serviços compatível. Uma conexão Partner Interconnect é útil se a infraestrutura estiver em um local físico que não possa alcançar uma instalação de colocação da Interconexão dedicada ou se as necessidades de dados não garantirem uma conexão totalmente de 10 Gbps.

Outros tipos de conexão

Outras maneiras de se conectar ao Google podem estar disponíveis em seu local específico. Se precisar de ajuda para determinar a melhor e mais econômica maneira de se conectar ao GCP, fale com seu representante do GCP.

Como proteger seu conteúdo

Para executar o conteúdo em qualquer plataforma de nuvem pública, os proprietários de conteúdo, como os grandes estúdios de Hollywood, exigem que os fornecedores cumpram as práticas recomendadas de segurança definidas internamente e por organizações como a MPAA.

Embora cada estúdio tenha requisitos levemente diferentes, proteger as cargas de trabalho de renderização proporciona práticas recomendadas para criar um farm de renderização híbrido. Também é possível encontrar whitepapers de segurança e documentação de conformidade em cloud.google.com/security.

Se você tiver dúvidas sobre o processo de auditoria da conformidade de segurança, fale com seu representante do GCP.

Como organizar seus projetos

Projetos são um componente organizacional principal do GCP. Em suas instalações, você pode organizar jobs sob um projeto próprio 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. Você pode designar todos os projetos criados em sua organização como projetos de serviço de VPC compartilhada. Essa designação indica que qualquer projeto em 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 ajudá-lo a definir o acesso, o GCP oferece o Cloud Identity and Access Management (Cloud IAM), que pode ser usado para gerenciar o controle de acesso definindo quais papéis têm que níveis de acesso a quais recursos.

Observações de produção: para restringir o acesso de usuários apenas aos recursos necessários para executar tarefas específicas com base no papel deles, implemente o princípio de menor privilégio 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 GCP, porque eles não precisam de acesso direto aos recursos da nuvem.

Você pode 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. A tabela a seguir mostra como tarefas típicas de produção são mapeadas para papéis do IAM no GCP.

Tarefa de produção Nome do papel Tipo de recurso
Gerente de estúdio resourcemanager.organizationAdmin Organização
Projeto
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 Organização
Projeto
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 intervalo 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 canal de renderização grava renderizações concluídas no Cloud Storage, adicione o escopo devstorage.read_write à instância no momento da gravaçã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. Essa estratégia é menos econômica que uma sob demanda, mas um grupo de instâncias em execução pode 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, fale com o fabricante do software para ver se eles podem fornecer uma licença atualizada para o 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 receber uma licença do servidor em x.x.0.1, porta 5053. Se essa tentativa falhar, ele tentará receber uma licença da 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 em 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 que adotado no Google Cloud Platform depende da estratégia de armazenamento escolhida e de fatores como custo e requisitos de durabilidade. Para saber mais sobre o Cloud Storage, consulte Servidores de arquivos no Compute Engine.

Disco permanente

Você pode evitar a implementação de um servidor de arquivos incorporando discos permanentes (PDs, na sigla em inglês) à 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 PDs podem ser anexados a uma única instância.

O mesmo PD pode ser ativado como somente leitura em centenas ou milhares de instâncias.
Tamanho máximo de 64 TB.

Só é possível gravar no PD quando conectado a uma única instância.

Pode ser acessado apenas por recursos que estão na mesma região.
Canais avançados que podem criar um novo disco por job.

Canais que disponibilizam dados atualizados com pouca frequência, como software ou bibliotecas comuns, para trabalhadores 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 intervalos, 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 entre as 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 canal 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.

Canais 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 GCP 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
Avere vFXT Alto desempenho e configurável.

O cache de leitura ajuda a minimizar a latência de fluxos de trabalho híbridos.

Pode sincronizar para o armazenamento local com o dispositivo FXT.
Custo, suporte de terceiros da Avere. Instalações de VFX de médio a grande porte com centenas de terabytes de dados para apresentar na nuvem.
Elastifile, Cloud File System (ECFS) Sistema de arquivos em cluster compatível com milhares de conexões NFS simultâneas.

Capaz de sincronizar com o cluster do ECFS no local.
O armazenamento local ou a sincronização em nuvem estão disponíveis, mas os dados podem ser sincronizados apenas em uma direção. Por exemplo, o ECFS local pode ler e gravar, mas o ECFS baseado na nuvem é somente leitura.

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.

É necessário manter servidores locais para uso em um cluster do ECFS.
Pixit Media, PixCache Cloud 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.
Cloud Filestore (Beta) Solução de armazenamento totalmente gerenciada no GCP.

Simples de implantar e manter.
Máximo de 64 TB por instância. O desempenho do NFS é fixo e não é dimensionado com o número de clientes ativos. Instalações de VFX de pequeno a médio porte com um canal capaz de sincronizar recursos.

Disco compartilhado entre estações de trabalho virtuais.
Cloud Storage FUSE Ative intervalos 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 GCP. Para mais informações, fale com seu representante do GCP.

Outras leituras sobre opções de armazenamento de dados

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

Ativação do armazenamento local diretamente de trabalhadores de renderização baseados em nuvem
Ativação do armazenamento local diretamente de trabalhadores de renderização baseados em nuvem

Se a instalação tem conectividade com o GCP de pelo menos 10 Gbps e está próxima de uma região do GCP, você poderá optar por ativar seu NAS local diretamente em trabalhadores 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 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 você pode conectar ao seu NAS 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 GCP de pelo menos 10 Gbps.

Estratégia 2: sincronizar sob demanda

Sincronização dos dados entre o armazenamento local e o armazenamento baseado em nuvem sob demanda
Sincronização dos dados entre o armazenamento local e o baseado em nuvem sob demanda

É possível optar por enviar dados para a nuvem ou receber dados do armazenamento 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 Cloud Pub/Sub, ou por um conjunto de comandos como parte de um script de job.

É possível executar uma sincronização usando vários comandos, como o comando scp da 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 Tervela Cloud FastPath, o BitSpeed ou o FDT para se comunicar com um intervalo 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 adicionais 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

Uso do seu armazenamento local com um cache de leitura baseado em nuvem
Uso do seu armazenamento local com um cache de leitura baseado em nuvem

Nessa estratégia, você implementa na nuvem um dispositivo de cache virtual, como o Avere vFXT, para atuar como um cache de leitura e um servidor de arquivos. Cada trabalhador de renderização na nuvem ativa o dispositivo de armazenamento em cache sob o protocolo NFS ou SMB como faria com um servidor de arquivos convencional. Se um trabalhador de renderização lê um arquivo que não está presente no cache, o arquivo é transferido do armazenamento local para o arquivador na nuvem. 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, você pode pré-aquecer seu cache para garantir que todos os dados relacionados ao job estejam presentes antes da renderização. Para pré-aquecer o cache, leia o conteúdo de um diretório que está em seu servidor de arquivos na nuvem executando 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, o Avere oferece um dispositivo de armazenamento físico FXT que pode reduzir ainda mais a latência entre o armazenamento 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 pré-aquecer 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 farm de renderização híbrido, você pode 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.

Comparação de tempos típicos para transferências on-line e físicas
Comparação de 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

Depois que um projeto é concluído, é comum salvar o trabalho finalizado em alguma forma de armazenamento de longo prazo, geralmente em mídia de fita magnética, como LTO. Esses cartuchos estão sujeitos a requisitos ambientais e, ao longo do tempo, podem ser logisticamente difíceis 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 machine learning para marcar e categorizar imagens e vídeos, armazenando os resultados em um banco de dados baseado em nuvem, como o BigQuery.

Um canal de arquivamento de recursos que inclui machine learning para categorizar o conteúdo
Um canal de arquivamento de recursos que inclui machine learning para categorizar o conteúdo

Outros tópicos a considerar:

  • Automatize a geração de miniaturas ou proxies para conteúdos das camadas Cloud Storage Nearline ou Cloud Storage Coldline. Use esses proxies em seu sistema de gerenciamento de recursos de mídia para que os usuários possam procurar dados ao ler apenas os proxies, não os recursos arquivados.
  • Use o machine learning para categorizar o conteúdo live-action. Use o Cloud AutoML Vision para rotular texturas e placas de fundo ou o Cloud Video Intelligence para ajudar na pesquisa e recuperação de imagens de referência.
  • Também é possível usar o Cloud AutoML Vision para criar um modelo de visão personalizado para reconhecer qualquer recurso, seja live-action 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:

Publicação de recursos no Cloud Storage
Publicação de recursos no Cloud Storage
  1. 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.
  2. 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.
  3. 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 HVAC.

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 como o Qube!, o Deadline e o Tractor estão disponíveis comercialmente e são amplamente usados no setor de efeitos visuais e animação. Você pode 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, na sigla em inglês). 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 em nuvem como se fossem workers de renderização 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 Stackdriver Logging para detectar instâncias não usadas ou ociosas.
  • 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, como um Avere vFXT, pense em implantar um job pré-renderização para pré-aquecer o cache e garantir que todos os recursos estejam disponíveis na nuvem antes de implantar os recursos da nuvem. 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 GCP 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.

Veja outras maneiras de coletar e monitorar o uso de recursos no GCP:

Como configurar as instâncias do trabalhador 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).

Como 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 para acessar a funcionalidade que as imagens públicas fornecem por padrão. Ao instalar o ambiente de convidado, você pode executar tarefas, como acesso a metadados, configuração do sistema e otimização do sistema operacional para uso no GCP, usando os mesmos controles de segurança da sua imagem personalizada usados 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 sistema operacional 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. Você também pode usar uma ferramenta como o Ansible para configurar os nós de renderização em execução e exercer o controle de granularidade fina na configuração e no ciclo de vida deles.

Para mais informações sobre como automatizar a criação de imagens e a configuração de instâncias, consulte as soluções Versões de imagens automatizadas com Jenkins, Packer e Kubernetes e Gerenciamento do Compute Engine com Puppet, Chef, Salt e Ansible (em inglês).

Como escolher um tipo de máquina

No GCP, é possível escolher um dos tipos de máquina predefinidos ou especificar um tipo de máquina personalizado. O uso de tipos de máquina personalizados permite controlar recursos para que você possa personalizar instâncias com base nos tipos de job executados no GCP. Ao criar uma instância, você pode adicionar GPUs e especificar o número de CPUs, a plataforma da CPU, a quantidade de RAM e o tipo e 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, na sigla em inglês) referem-se à capacidade extra do Compute Engine que é vendida a um preço muito mais baixo do que as VMs padrão. O Compute Engine poderá encerrar ou interromper essas 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 ajudá-lo 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 você pode usar 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, você poderá 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 trabalhadores de renderização

O Cloud IAM ajuda você a conceder acesso a recursos da nuvem a pessoas que precisam dele. Para os trabalhadores de renderização do Linux, você pode 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 farm de renderização 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 ativando seu NAS local diretamente ou usando um produto de armazenamento, como o Avere vFXT, que sincroniza automaticamente, grave todos os dados renderizados no sistema de arquivos local do worker de renderização e copie o que precisa para o armazenamento local para evitar a saída de dados temporários e desnecessários.
  • VMs de tamanho correto. Certifique-se de criar seus workers de renderização com o uso ideal de recursos, atribuindo apenas 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 GCP, 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. Assim, um artista de iluminação pode acessar esses dados de simulação de uma estação de trabalho virtual que está no GCP. Para saber mais informações sobre estações de trabalho virtuais, fale com seu representante do GCP.
  • 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.

Como comparar custos de farms de renderização locais e baseados em nuvem

Compare o custo de criar e manter um farm de renderização local e criar um farm de renderização baseado em nuvem. A análise de custos de exemplo a seguir compara os dois cenários (todos os custos em USD).

Custos de farm de renderização no local Custos de farm de renderização baseado em nuvem
Custos iniciais de criação
Preço por nó: US$ 3.800
Número de nós: 100
Hardware de rede, construção de sala vazia: US$ 100.000
Hardware de armazenamento: US$ 127.000
Conexão inicial da empresa de serviços públicos: US$ 20.000
Conectividade de provisionamento: US$ 2.000
Custos totais de criação: US$ 629.000
Custos iniciais de conectividade
Hardware de rede: US$ 10.000
Hardware de armazenamento: US$ 127.000
Conectividade de provisionamento: US$ 2.000
Custos totais de criação: US$ 139.000
Custos anuais
Contrato de suporte de rede: US$ 15.000
Contrato de suporte do servidor: US$ 34.050
Custos anuais
Contrato de suporte de rede: US$ 1.500
Contrato de suporte do servidor: US$ 19.050
Custos mensais
Largura de banda: US$ 2.500
Serviços públicos: US$ 8.000
Custo por pé quadrado: US$ 40
Pés quadrados necessários: 400
Equipe de TI/suporte: US$ 15.000
Custos mensais totais: US$ 41.500
Custos mensais
Largura de banda: US$ 2.500
Duas interconexões dedicadas: US$ 3.600
Saída de 100 GB: US$ 12
Custos mensais totais: US$ 6.112
Utilização do farm de renderização
Porcentagem de utilização mensal: 50%
Número de horas de renderização/mês: 36.500
Utilização do farm de renderização
Número de instâncias: 100
Tipo de máquina: n1-standard-32, preemptiva
Porcentagem de utilização mensal: 50%
Número de horas de renderização/mês: 36.500
Custo por hora de renderização: US$ 5,62 Custo por hora de renderização: US$ 1,46

Resumo

Estender seu farm de renderização existente para a nuvem é uma maneira econômica de aproveitar recursos poderosos e de baixo custo sem despesas de capital. Não há dois canais de produção iguais. Portanto, nenhum documento pode abranger todos os tópicos e requisitos únicos. Para ajuda sobre como migrar suas cargas de trabalho de renderização para a nuvem, fale com seu representante do GCP.

Mais informações

Outras soluções aplicáveis, algumas mencionadas neste artigo, estão disponíveis em cloud.google.com.

Teste outros recursos do Google Cloud Platform. Veja os tutoriais.

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…