Este documento fornece orientações sobre como expandir a sua farm de renderização no local existente para usar recursos de computação no Google Cloud. Este documento pressupõe que já implementou uma render farm no local e que conhece os conceitos básicos dos efeitos visuais (VFX) e dos pipelines de animação, o software de gestão de filas e os métodos de licenciamento de software comuns.
Vista geral
A renderização de elementos 2D ou 3D para animação, filmes, anúncios ou videojogos requer muitos recursos de computação e tempo. A renderização destes elementos requer um investimento substancial em hardware e infraestrutura, juntamente com uma equipa dedicada de profissionais de TI para implementar e manter o hardware e o software.
Quando uma farm de renderização no local está a 100% de utilização, a gestão de tarefas pode tornar-se um desafio. As prioridades e as dependências das tarefas, o reinício de frames perdidos e a carga da rede, do disco e da CPU tornam-se parte da equação complexa que tem de monitorizar e controlar atentamente, muitas vezes com prazos apertados.
Para gerir estes trabalhos, as instalações de efeitos visuais incorporaram software de gestão de filas nos respetivos processos. O software de gestão de filas pode:
- Implemente tarefas em recursos no local e baseados na nuvem.
- Faça a gestão das dependências entre tarefas.
- Comunicar com sistemas de gestão de recursos.
- Oferecer aos utilizadores uma interface do utilizador e APIs para linguagens comuns, como o Python.
Embora algum software de gestão de filas possa implementar tarefas em trabalhadores baseados na nuvem, continua a ser responsável por estabelecer ligação à nuvem, sincronizar recursos, escolher uma estrutura de armazenamento, gerir modelos de imagens e fornecer o seu próprio licenciamento de software.
As seguintes opções estão disponíveis para criar e gerir pipelines de renderização e fluxos de trabalho num ambiente de nuvem ou nuvem híbrida:
- Se ainda não tiver recursos no local ou na nuvem, pode usar um serviço de renderização baseado na nuvem de software como serviço (SaaS), como o Conductor.
- Se quiser gerir a sua própria infraestrutura, pode criar e implementar os recursos na nuvem descritos neste documento.
- Se quiser criar um fluxo de trabalho personalizado com base nos seus requisitos específicos, pode trabalhar com Google Cloud parceiros integradores de serviços como Gunpowder ou Qodea. Esta opção tem a vantagem de executar todos os serviços na nuvem no seu próprio ambiente Google Cloud seguro.
Para ajudar a determinar a solução ideal para as suas instalações, contacte o seu Google Cloud representante.
Nota: as notas de produção aparecem periodicamente ao longo deste documento. Estas notas oferecem práticas recomendadas a seguir à medida que cria a sua render farm.
A estabelecer ligação à nuvem
Dependendo da sua carga de trabalho, decida como a sua instalação se liga ao Google Cloud, seja através de um ISP parceiro, uma ligação direta ou através da Internet pública.
Estabelecer ligação através da Internet
Sem qualquer conetividade especial, pode ligar-se à rede da Google e usar o nosso modelo de segurança ponto a ponto acedendo aos serviços Google Cloud através da Internet. As utilidades, como a CLI Google Cloud e os recursos, como a API Compute Engine usam autenticação, autorização e encriptação seguras para ajudar a proteger os seus dados.
Cloud VPN
Independentemente da forma como está ligado, recomendamos que use uma rede privada virtual (VPN) para proteger a sua ligação.
A Cloud VPN ajuda a ligar em segurança a sua rede no local à sua rede de nuvem virtual privada (VPC) através de uma ligação VPN IPsec. Os dados em trânsito são encriptados antes de passarem por um ou mais canais VPN.
Saiba como criar uma VPN para o seu projeto.
VPN fornecida pelo cliente
Embora possa configurar o seu próprio gateway de VPN para estabelecer ligação diretamente com a Google, recomendamos que use a Cloud VPN, que oferece mais flexibilidade e uma melhor integração com o Google Cloud.
Cloud Interconnect
A Google suporta várias formas de ligar a sua infraestrutura ao Google Cloud. Estas ligações de nível empresarial, conhecidas coletivamente como Cloud Interconnect, oferecem maior disponibilidade e menor latência do que as ligações à Internet padrão, juntamente com preços de saída reduzidos.
O Cross-Cloud Interconnect permite-lhe estabelecer uma conetividade dedicada de elevada largura de banda com a Google Cloudpara os seus dados noutra nuvem. Ao fazê-lo, reduz a complexidade da rede, os custos de transferência de dados e permite farms de renderização multicloud de elevado débito.
Interligação dedicada
O Dedicated Interconnect oferece ligações físicas diretas e comunicação RFC 1918 entre a sua rede no local e a rede da Google. Oferece capacidade de ligação através dos seguintes tipos de ligações:
- Uma ou mais ligações Ethernet de 10 Gbps, com um máximo de oito ligações ou 80 Gbps no total por interligação.
- Uma ou mais ligações Ethernet de 100 Gbps, com um máximo de duas ligações ou 200 Gbps no total por interligação.
O tráfego do Dedicated Interconnect não está encriptado. Se precisar de transmitir dados através da Interligação dedicada de forma segura, tem de estabelecer a sua própria ligação VPN. O Cloud VPN não é compatível com o Dedicated Interconnect, pelo que tem de fornecer a sua própria VPN neste caso.
Interligação de parceiro
O Partner Interconnect oferece conetividade entre a sua rede no local e a sua rede VPC através de um fornecedor de serviços suportado. Uma ligação Partner Interconnect é útil se a sua infraestrutura estiver numa localização física que não consiga alcançar uma instalação de colocation do Dedicated Interconnect ou se as suas necessidades de dados não justificarem uma ligação de 10 Gbps completa.
Outros tipos de ligações
Podem estar disponíveis outras formas de estabelecer ligação ao Google na sua localização específica. Para receber ajuda na determinação da melhor e mais económica forma de estabelecer ligação à Google Cloud, contacte o seu representante Google Cloud .
Proteger o seu conteúdo
Para executar o respetivo conteúdo em qualquer plataforma de nuvem pública, os proprietários de conteúdo, como os principais estúdios de Hollywood, exigem que os fornecedores ajam em conformidade com as práticas recomendadas de segurança definidas internamente e por organizações como a MPAA. AGoogle Cloud oferece modelos de segurança de confiança zero incorporados em produtos como o Google Workspace, o Chrome Enterprise Premium e o BeyondProd.
Cada estúdio tem requisitos diferentes para proteger cargas de trabalho de renderização. Pode encontrar documentos técnicos de segurança e documentação de conformidade em cloud.google.com/security.
Se tiver dúvidas acerca do processo de auditoria de conformidade de segurança, contacte o seu representante.Google Cloud
Organizar os seus projetos
Os projetos são um componente de organização essencial do Google Cloud. Na sua instalação, pode organizar os trabalhos no respetivo projeto ou dividi-los em vários projetos. Por exemplo, pode querer criar projetos separados para as fases de pré-visualização, investigação e desenvolvimento, e produção de um filme.
Os projetos estabelecem um limite de isolamento para os dados de rede e a administração do projeto. No entanto, pode partilhar redes entre projetos com a VPC partilhada, que oferece a projetos separados acesso a recursos comuns.
Notas de produção: crie um projeto anfitrião da VPC partilhada que contenha recursos com todas as suas ferramentas de produção. Pode designar todos os projetos criados na sua organização como projetos de serviço de VPC partilhada. Esta designação significa que qualquer projeto na sua organização pode aceder às mesmas bibliotecas, scripts e software que o projeto anfitrião fornece.
O recurso Organization
Pode gerir projetos num recurso de organização, que pode já ter estabelecido. Migrar todos os seus projetos para uma organização oferece várias vantagens.
Notas de produção: designe os gestores de produção como proprietários dos respetivos projetos individuais e a gestão do estúdio como proprietários do recurso de organização.
Definir o acesso aos recursos
Os projetos requerem acesso seguro aos recursos, juntamente com restrições sobre onde os utilizadores ou os serviços têm autorização para operar. Para ajudar a definir o acesso, o Google Cloud Google Cloud oferece gestão de identidade e de acesso (IAM), que pode usar para gerir o controlo de acesso definindo que funções têm que níveis de acesso a que recursos.
Notas de produção: para restringir o acesso dos utilizadores apenas aos recursos necessários para realizar tarefas específicas com base na respetiva função, implemente o princípio do menor privilégio no local e na nuvem.
Por exemplo, considere um render worker, que é uma máquina virtual (VM) que pode implementar a partir de um modelo de instância predefinido que usa a sua imagem personalizada. O render worker que está a ser executado numa conta de serviço pode ler a partir do Cloud Storage e escrever no armazenamento anexado, como um filer na nuvem ou um disco persistente. No entanto, não precisa de adicionar artistas individuais a projetos, porque não precisam de acesso direto aos recursos da nuvem.Google Cloud
Pode atribuir funções a organizadores de dados ou administradores de projetos que tenham acesso a todos os recursos do Compute Engine, o que lhes permite realizar funções em recursos inacessíveis a outros utilizadores.
Defina uma política para determinar que funções podem aceder a que tipos de recursos na sua organização. A tabela seguinte mostra como as tarefas de produção típicas são mapeadas para funções de IAM no Google Cloud.
| Tarefa de produção | Nome da função | Tipo do recurso |
|---|---|---|
| Gestor do Studio | resourcemanager.organizationAdmin |
Organização Projeto |
| Production manager | owner, editor |
Projeto |
| Render wrangler | compute.admin, iam.serviceAccountActor |
Projeto |
| Conta de gestão de filas | compute.admin, iam.serviceAccountActor |
Organização Projeto |
| Artista individual | [no access] | Não aplicável |
Âmbitos de acesso
Os âmbitos de acesso oferecem-lhe uma forma de controlar as autorizações de uma instância em execução, independentemente de quem tiver sessão iniciada. Pode especificar âmbitos quando cria uma instância ou quando o software de gestão de filas implementa recursos a partir de um modelo de instância.
Os âmbitos têm precedência sobre as autorizações da IAM de um utilizador ou uma conta de serviço individual. Esta precedência significa que um âmbito de acesso pode impedir que um administrador do projeto inicie sessão numa instância para eliminar um contentor de armazenamento ou alterar uma definição de firewall.
Notas de produção: por predefinição, as instâncias podem ler, mas não escrever no Cloud Storage. Se o pipeline de renderização escrever renderizações concluídas de volta para o Cloud Storage, adicione o âmbito devstorage.read_write à sua instância no momento da criação.
Escolher como implementar recursos
Com a renderização na nuvem, pode usar recursos apenas quando necessário, mas pode escolher entre várias formas de disponibilizar recursos à sua farm de renderização.
Implementação a pedido
Para uma utilização ideal dos recursos, pode optar por implementar trabalhadores de renderização apenas quando envia uma tarefa para a farm de renderização. Pode implementar muitas VMs para serem partilhadas em todos os frames de um trabalho ou até criar uma VM por frame.
O seu sistema de gestão de filas pode monitorizar instâncias em execução, que podem ser recolocadas na fila se uma VM for anulada e terminadas quando as tarefas individuais forem concluídas.
Implemente um conjunto de recursos
Também pode optar por implementar um grupo de instâncias não relacionadas com nenhuma tarefa específica, às quais o seu sistema de gestão de filas no local pode aceder como recursos adicionais. Se usar Google CloudVMs do Spot, um grupo de instâncias em execução pode aceitar várias tarefas por VM, usando todos os núcleos e maximizando a utilização de recursos. Esta abordagem pode ser a estratégia mais simples de implementar porque imita a forma como uma render farm no local é preenchida com tarefas.
Licenciar o software
O licenciamento de software de terceiros pode variar bastante de pacote para pacote. Seguem-se alguns dos esquemas e modelos de licenciamento que pode encontrar num pipeline de efeitos visuais. Para cada esquema, a terceira coluna mostra a abordagem de licenciamento recomendada.
| Esquema | Descrição | Recomendação |
|---|---|---|
| Nó bloqueado | Licenciados para um endereço MAC, um endereço IP ou um ID da CPU específicos. Só pode ser executado por um único processo. | Com base na instância |
| Baseado em nós | Licenciada para um nó específico (instância). Um número arbitrário de utilizadores ou processos pode ser executado num nó licenciado. | Com base na instância |
| Flutuante | Foi feito o check-out de um servidor de licenças que monitoriza a utilização. | Servidor de licenças |
| Licenciamento de software | ||
| Interativo | Permite que o utilizador execute software de forma interativa num ambiente baseado em gráficos. | Servidor de licenças ou com base na instância |
| Lote | Permite que o utilizador execute software apenas num ambiente de linha de comandos. | Servidor de licenças |
| Licenciamento baseado na nuvem | ||
| Baseado na utilização | São retiradas apenas quando um processo é executado numa instância da nuvem. Quando o processo terminar ou for interrompido, a licença é libertada. | Servidor de licenças baseado na nuvem |
| Com base no tempo de atividade | Fez check-out enquanto uma instância estava ativa e em execução. Quando a instância é parada ou eliminada, a licença é libertada. | Servidor de licenças baseado na nuvem |
Usar o licenciamento baseado em instâncias
Alguns programas de software ou plug-ins são licenciados diretamente para o hardware no qual são executados. Esta abordagem à licenciamento pode apresentar um problema na nuvem, onde os identificadores de hardware, como os endereços MAC ou IP, são atribuídos dinamicamente.
Endereços MAC
Quando são criadas, as instâncias recebem um endereço MAC que é mantido enquanto a instância não for eliminada. Pode parar ou reiniciar uma instância, e o endereço MAC é mantido. Pode usar este endereço MAC para a criação e validação de licenças até a instância ser eliminada.
Atribuir um endereço IP estático
Quando cria uma instância, é-lhe atribuído um endereço IP interno e, opcionalmente, um endereço IP externo. Para manter o endereço IP externo de uma instância, pode reservar um endereço IP estático e atribuí-lo à sua instância. Este endereço IP vai ser reservado apenas para esta instância. Uma vez que os endereços IP estáticos são um recurso baseado em projetos, estão sujeitos a quotas regionais.
Também pode atribuir um endereço IP interno quando cria uma instância, o que é útil se quiser que os endereços IP internos de um grupo de instâncias se enquadrem no mesmo intervalo.
Dongles de hardware
O software mais antigo ainda pode ser licenciado através de um dongle, uma chave de hardware programada com uma licença do produto. A maioria das empresas de software deixou de usar dongles de hardware, mas alguns utilizadores podem ter software antigo associado a um destes dispositivos. Se tiver este problema, contacte o fabricante do software para saber se pode fornecer-lhe uma licença atualizada para o seu software específico.
Se o fabricante do software não puder fornecer essa licença, pode implementar um hub USB ligado à rede ou uma solução de USB através de IP.
Usar um servidor de licenças
A maioria dos softwares modernos oferece uma opção de licença flutuante. Esta opção faz mais sentido num ambiente de nuvem, mas requer uma gestão de licenças mais forte e um controlo de acesso para evitar o consumo excessivo de um número limitado de licenças.
Para ajudar a evitar exceder a capacidade da sua licença, pode, como parte do processo da fila de tarefas, escolher que licenças usar e controlar o número de tarefas que usam licenças.
Servidor de licenças nas instalações
Pode usar o seu servidor de licenças no local existente para fornecer licenças a instâncias que estão a ser executadas na nuvem. Se escolher este método, tem de fornecer uma forma para os trabalhadores de renderização comunicarem com a sua rede nas instalações, através de uma VPN ou de alguma outra ligação segura.
Servidor de licenças baseado na nuvem
Na nuvem, pode executar um servidor de licenças que sirva instâncias no seu projeto ou mesmo em vários projetos através da VPC partilhada. Por vezes, as licenças flutuantes estão associadas a um endereço MAC de hardware. Por isso, uma instância pequena e de execução prolongada com um endereço IP estático pode disponibilizar facilmente licenças a muitas instâncias de renderização.
Servidor de licenças híbrido
Algum software pode usar vários servidores de licenças por ordem de prioridade. Por exemplo, um motor de renderização pode consultar o número de licenças disponíveis num servidor no local e, se não estiverem disponíveis, usar um servidor de licenças baseado na nuvem. Esta estratégia pode ajudar a maximizar a utilização de licenças permanentes antes de explorar outros tipos de licenças.
Notas de produção: defina um ou mais servidores de licenças numa variável de ambiente e defina a ordem de prioridade. O Autodesk Arnold, um renderizador popular, ajuda a fazê-lo. Se a tarefa não conseguir adquirir uma licença através do primeiro servidor, tenta usar quaisquer outros servidores listados, como no exemplo seguinte:
export solidangle_LICENSE=5053@x.x.0.1;5053@x.x.0.2
No exemplo anterior, o renderizador Arnold tenta obter uma licença do servidor em x.x.0.1, porta 5053. Se essa tentativa falhar, tenta obter uma licença a partir da mesma porta no endereço IP x.x.0.2.
Licenciamento baseado na nuvem
Alguns fornecedores oferecem licenciamento baseado na nuvem que disponibiliza licenças de software a pedido para as suas instâncias. Geralmente, a faturação das licenças baseadas na nuvem é feita de duas formas: com base na utilização e com base no tempo de atividade.
Licenciamento baseado na utilização
A faturação das licenças baseadas na utilização é feita com base no tempo de utilização do software. Normalmente, com este tipo de licenciamento, uma licença é retirada de um servidor baseado na nuvem quando o processo é iniciado e é libertada quando o processo é concluído. Enquanto uma licença estiver em uso, é-lhe cobrado o valor da utilização dessa licença. Normalmente, este tipo de licenciamento é usado para software de renderização.
Licenciamento com base no tempo de atividade
As licenças baseadas no tempo de atividade ou medidas são faturadas com base no tempo de atividade da sua instância do Compute Engine. A instância está configurada para se registar no servidor de licenças baseado na nuvem durante o processo de arranque. Enquanto a instância estiver em execução, a licença está atribuída. Quando a instância é parada ou eliminada, a licença é libertada. Normalmente, este tipo de licenciamento é usado para render workers que um gestor de filas implementa.
Escolher como armazenar os seus dados
O tipo de armazenamento que escolher no Google Cloud depende da estratégia de armazenamento escolhida, juntamente com fatores como os requisitos de durabilidade e o custo.
Disco persistente
Pode evitar a implementação de um servidor de ficheiros por completo incorporando discos persistentes (DPs) na sua carga de trabalho. Os PDs são um tipo de armazenamento de blocos compatível com POSIX, com um tamanho máximo de 64 TB, que é familiar para a maioria das instalações de efeitos visuais. Os discos persistentes estão disponíveis como discos padrão e SSDs. Pode anexar um PD no modo de leitura/escrita a uma única instância ou no modo de leitura a um grande número de instâncias, como um grupo de trabalhadores de renderização.
| Vantagens | Desvantagens | Exemplo de utilização ideal |
|---|---|---|
| Monta-se como um volume NFS ou SMB padrão. Pode ser redimensionado dinamicamente. É possível anexar até 128 PDs a uma única instância. O mesmo PD pode ser montado como só de leitura em centenas ou milhares de instâncias. |
Tamanho máximo de 64 TB. Só pode escrever no PD quando estiver anexado a uma única instância. Só pode ser acedido por recursos que estejam na mesma região. |
Pipelines avançadas que podem criar um novo disco por tarefa. Pipelines que fornecem dados atualizados com pouca frequência, como software ou bibliotecas comuns, aos trabalhadores de renderização. |
Armazenamento de objetos
O Cloud Storage é um armazenamento altamente redundante e duradouro que, ao contrário dos sistemas de ficheiros tradicionais, é não estruturado e tem uma capacidade praticamente ilimitada. Os ficheiros no Cloud Storage são armazenados em contentores, que são semelhantes a pastas, e estão acessíveis em todo o mundo.
Ao contrário do armazenamento tradicional, o armazenamento de objetos não pode ser montado como um volume lógico por um sistema operativo (SO). Se decidir incorporar o armazenamento de objetos no seu pipeline de renderização, tem de modificar a forma como lê e escreve dados, através de utilitários de linha de comandos, como a CLI gcloud, ou através da API Cloud Storage.
| Vantagens | Desvantagens | Exemplo de utilização ideal |
|---|---|---|
| Armazenamento duradouro e altamente disponível para ficheiros de todos os tamanhos. Uma única API em todas as classes de armazenamento. Barato. Os dados estão disponíveis em todo o mundo. Capacidade praticamente ilimitada. |
Não está em conformidade com a norma POSIX. Tem de ser acedido através da API ou do utilitário de linha de comandos. Num pipeline de renderização, os dados têm de ser transferidos localmente antes de serem usados. |
Renderizar pipelines com um sistema de gestão de recursos que possa publicar dados no Cloud Storage. Renderizar pipelines com um sistema de gestão de filas que pode obter dados do Cloud Storage antes da renderização. |
Outros produtos de armazenamento
Outros produtos de armazenamento estão disponíveis como serviços geridos, através de canais de terceiros, como o Cloud Marketplace, ou como projetos de código aberto através de repositórios de software ou do GitHub.
| Produto | Vantagens | Desvantagens | Exemplo de utilização ideal |
|---|---|---|---|
| Filestore | Sistema de ficheiros agrupado que pode suportar milhares de ligações NFS simultâneas. Capacidade de sincronização com o cluster NAS no local. |
Não existe forma de sincronizar ficheiros seletivamente. Sem sincronização bidirecional. | Instalações de efeitos visuais de média a grande dimensão com centenas de TBs de dados para apresentar na nuvem. |
| Pixit Media, PixStor | Sistema de ficheiros de expansão horizontal que pode suportar milhares de clientes NFS ou POSIX simultâneos. Os dados podem ser colocados em cache a pedido a partir do NAS no local, com as atualizações enviadas automaticamente de volta para o armazenamento no local. | Custo, apoio técnico de terceiros da Pixit. | Instalações de efeitos visuais de média a grande dimensão com centenas de TBs de dados para apresentar na nuvem. |
| Google Cloud NetApp Volumes | Solução de armazenamento totalmente gerida na Google Cloud. Suporta ambientes NFS, SMB e multiprotocolo. Instantâneos num momento específico com recuperação de instâncias |
Não está disponível em todas as Google Cloud regiões. | Instalações de efeitos visuais com um pipeline capaz de sincronizar recursos. Disco partilhado em estações de trabalho virtuais. |
| Cloud Storage FUSE | Monte contentores do Cloud Storage como sistemas de ficheiros. Baixo custo. | Não é um sistema de ficheiros compatível com POSIX. Pode ser difícil de configurar e otimizar. | Instalações de efeitos visuais capazes de implementar, configurar e manter um sistema de ficheiros de código aberto, com um pipeline capaz de sincronizar recursos. |
Outros tipos de armazenamento estão disponíveis em Google Cloud. Para mais informações, contacte o seu Google Cloud representante.
Leitura adicional sobre as opções de armazenamento de dados
- Opções de armazenamento disponíveis no Google Cloud
- Armazenamento de ficheiros no Compute Engine
- Crie uma estratégia de armazenamento ideal para a sua carga de trabalho na nuvem
Implementar estratégias de armazenamento
Pode implementar várias estratégias de armazenamento em pipelines de produção de efeitos visuais ou animação estabelecendo convenções que determinam como processar os seus dados, quer aceda aos dados diretamente a partir do seu armazenamento no local ou sincronize entre o armazenamento no local e a nuvem.
Estratégia 1: monte o armazenamento no local diretamente
Se a sua instalação tiver uma ligação de Google Cloud , pelo menos, 10 Gbps e estiver perto de uma Google Cloud região, pode optar por montar o seu NAS no local diretamente em trabalhadores de renderização na nuvem. Embora esta estratégia seja simples, também pode ser intensiva em termos de custos e largura de banda, porque tudo o que criar na nuvem e escrever novamente no armazenamento é contabilizado como dados de saída.
| Vantagens | Desvantagens | Exemplo de utilização ideal |
|---|---|---|
| Implementação simples. Ler/escrever no armazenamento comum. Disponibilidade imediata dos dados, sem necessidade de colocação em cache nem sincronização. |
Pode ser mais caro do que outras opções. É necessária uma grande proximidade a um centro de dados da Google para alcançar uma latência baixa. O número máximo de instâncias que pode associar ao seu NAS no local depende da largura de banda e do tipo de ligação. |
Instalações perto de um centro de dados da Google que precisam de aumentar as cargas de trabalho de renderização para a nuvem, onde o custo não é uma preocupação. Instalações com conetividade de Google Cloud de, pelo menos, 10 Gbps. |
Estratégia 2: sincronize a pedido
Pode optar por enviar dados para a nuvem ou extrair dados do armazenamento no local, ou vice-versa, apenas quando os dados são necessários, como quando um frame é renderizado ou um recurso é publicado. Se usar esta estratégia, a sincronização pode ser acionada por um mecanismo no seu pipeline, como um script de observação, por um controlador de eventos, como o Pub/Sub, ou por um conjunto de comandos como parte de um script de tarefa.
Pode fazer uma sincronização através de vários comandos, como o comando scp da CLI gcloud, o comando rsync da CLI gcloud ou os protocolos de transferência de dados baseados em UDP (UDT). Se optar por usar um TDU de terceiros, como o Aspera, Cloud FastPath, BitSpeed, ou FDT para comunicar com um contentor do Cloud Storage, consulte a documentação do terceiro para saber mais sobre o respetivo modelo de segurança e práticas recomendadas. A Google não gere estes serviços de terceiros.
Método push
Normalmente, usa o método de envio quando publica um recurso, coloca um ficheiro numa pasta de monitorização ou conclui uma tarefa de renderização, após o que o envia para uma localização predefinida.
Exemplos:
- Um trabalhador de renderização na nuvem conclui uma tarefa de renderização e os frames resultantes são enviados de volta para o armazenamento no local.
- Um artista publica um recurso. Parte do processo de publicação de recursos envolve o envio dos dados associados para um caminho predefinido no Cloud Storage.
Método de obtenção
Usa o método de obtenção quando um ficheiro é pedido, normalmente, por uma instância de renderização baseada na nuvem.
Exemplo: como parte de um script de tarefa de renderização, todos os recursos necessários para renderizar uma cena são transferidos para um sistema de ficheiros antes da renderização, onde todos os trabalhadores de renderização podem aceder aos mesmos.
| Vantagens | Desvantagens | Exemplo de utilização ideal |
|---|---|---|
| Controlo total sobre os dados que são sincronizados e quando. Capacidade de escolher o método e o protocolo de transferência. |
O seu pipeline de produção tem de ser capaz de processar eventos para acionar sincronizações push/pull. Podem ser necessários recursos adicionais para processar a fila de sincronização. |
Instalações pequenas a grandes que têm pipelines personalizados e querem ter controlo total sobre a sincronização de recursos. |
Notas de produção: faça a gestão da sincronização de dados com o mesmo sistema de gestão de filas que usa para processar tarefas de renderização. As tarefas de sincronização podem usar recursos na 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 baseada na nuvem
Google Cloud desenvolveu e expandiu uma solução de cache KNFSD como uma opção de código aberto. A solução pode processar exigências de desempenho da renderização em massa que excedem as capacidades da infraestrutura de armazenamento. O armazenamento em cache KNFSD oferece um armazenamento em cache de leitura direta de alto desempenho, o que permite que as cargas de trabalho sejam dimensionadas para centenas, ou mesmo milhares, de nós de renderização em várias regiões e conjuntos de armazenamento híbridos.
O armazenamento em cache do KNFSD é uma solução escalável que reduz a carga no serviço de partilha de ficheiros principal. O armazenamento em cache do KNFSD também reduz o efeito de sobrecarga quando muitos nós de renderização tentam obter ficheiros do servidor de ficheiros ao mesmo tempo. Ao usar uma camada de colocação em cache na mesma rede VPC que os nós de renderização, a latência de leitura é reduzida, o que ajuda as tarefas de renderização a iniciar e concluir mais rapidamente. Consoante a forma como configurou o servidor de ficheiros de colocação em cache, os dados permanecem na cache até:
- Os dados expiram ou permanecem inalterados durante um período especificado.
- É necessário espaço no servidor de ficheiros, altura em que os dados são removidos da cache com base na antiguidade.
Esta estratégia reduz a quantidade de largura de banda e a complexidade necessárias para implementar muitas instâncias de renderização simultâneas.
Em alguns casos, pode querer pré-aquecer a cache para garantir que todos os dados relacionados com o trabalho estão presentes antes da renderização. Para pré-aquecer a cache, leia o conteúdo de um diretório que se encontra no seu servidor de ficheiros na nuvem executando um read ou um stat de um ou mais ficheiros. O acesso aos ficheiros desta forma aciona o mecanismo de sincronização.
Também pode adicionar um dispositivo físico no local para 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 seu armazenamento no local e a nuvem.
| Vantagens | Desvantagens | Exemplo de utilização ideal |
|---|---|---|
| Os dados em cache são geridos automaticamente. Reduz os requisitos de largura de banda. Os sistemas de ficheiros na nuvem agrupados podem ser dimensionados para cima ou para baixo, consoante os requisitos do trabalho. |
Pode incorrer em custos adicionais. As tarefas pré-trabalho têm de ser implementadas se optar por pré-aquecer a cache. |
Grandes instalações que implementam muitas instâncias simultâneas e leem recursos comuns em muitas tarefas. |
Filtrar dados
Pode criar uma base de dados de tipos de recursos e condições associadas para definir se deve sincronizar um tipo específico de dados. Pode nunca querer sincronizar alguns tipos de dados, como dados efémeros gerados como parte de um processo de conversão, ficheiros de cache ou dados de simulação. Considere também se deve sincronizar recursos não aprovados, porque nem todas as iterações vão ser usadas nas renderizações finais.
Realizar uma transferência em massa inicial
Ao implementar a sua farm de renderização híbrida, pode querer fazer uma transferência inicial de todo ou parte do seu conjunto de dados para o Cloud Storage, o disco persistente ou outro armazenamento baseado na nuvem. Consoante fatores como a quantidade e o tipo de dados a transferir e a velocidade da sua ligação, pode conseguir fazer uma sincronização completa ao longo de alguns dias ou semanas. A figura seguinte compara os tempos típicos das transferências online e físicas.
Se a sua carga de trabalho de transferência exceder as restrições de tempo ou largura de banda, a Google oferece várias opções de transferência para transferir os seus dados para a nuvem, incluindo o Transfer Appliance da Google.
Arquivo e recuperação de desastres
É importante notar a diferença entre o arquivo de dados e a recuperação de desastres. A primeira é uma cópia seletiva do trabalho concluído, enquanto a segunda é um estado dos dados que podem ser recuperados. Quer conceber um plano de recuperação de desastres que se ajuste às necessidades das suas instalações e ofereça um plano de contingência externo. Consulte o fornecedor de armazenamento no local para obter ajuda com um plano de recuperação de desastres adequado à sua plataforma de armazenamento específica.
Arquivar dados na nuvem
Após a conclusão de um projeto, é prática comum guardar o trabalho concluído num formato de armazenamento a longo prazo, normalmente, suportes de fita magnética, como o LTO. Estes cartuchos estão sujeitos a requisitos ambientais e, ao longo do tempo, podem ser difíceis de gerir do ponto de vista logístico. Por vezes, as grandes instalações de produção albergam todo o seu arquivo numa sala construída para esse fim com um arquivista a tempo inteiro para monitorizar os dados e recuperá-los quando solicitado.
A pesquisa de recursos, planos ou filmagens específicos arquivados pode demorar muito tempo, porque os dados podem estar armazenados em vários cartuchos, a indexação do arquivo pode estar em falta ou incompleta, ou podem existir limitações de velocidade na leitura de dados da fita magnética.
A migração do seu arquivo de dados para a nuvem não só elimina a necessidade de gestão e armazenamento no local de suportes de arquivo, como também torna os seus dados muito mais acessíveis e pesquisáveis do que os métodos de arquivo tradicionais.
Um pipeline de arquivo básico pode ter o seguinte aspeto, usando diferentes serviços na nuvem para examinar, categorizar, etiquetar e organizar arquivos. Na nuvem, pode criar uma ferramenta de gestão e obtenção de arquivos para pesquisar dados através de vários critérios de metadados, como data, projeto, formato ou resolução. Também pode usar as APIs de aprendizagem automática para etiquetar e categorizar imagens e vídeos, armazenando os resultados numa base de dados na nuvem, como o BigQuery.
Outros tópicos a considerar:
- Automatizar a geração de miniaturas ou proxies para conteúdo que reside em classes de armazenamento do Cloud Storage que têm taxas de obtenção. Use estes proxies no seu sistema de gestão de recursos multimédia para que os utilizadores possam procurar dados enquanto leem apenas os proxies e não os recursos arquivados.
- Considere usar a aprendizagem automática para categorizar conteúdo de ação real. Use a Cloud Vision para etiquetar texturas e fundos, ou a Video Intelligence API para ajudar na pesquisa e obtenção de filmagens de referência.
- Também pode usar o Vertex AI AutoML image para criar um modelo de imagem personalizado para reconhecer qualquer recurso, quer seja de ação real ou renderizado.
- Para conteúdo renderizado, considere guardar uma cópia da imagem do disco do trabalhador de renderização juntamente com o recurso renderizado. Se precisar de recriar a configuração, terá as versões de software, os plug-ins, as bibliotecas do SO e as dependências corretas disponíveis se precisar de renderizar novamente uma tomada arquivada.
Gerir 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 têm de estar disponíveis em todo o mundo. A sincronização manual de dados em redes privadas pode ser dispendiosa e exigente em termos de recursos, e está sujeita a limitações de largura de banda locais.
Se a sua carga de trabalho exigir dados disponíveis globalmente, pode usar o Cloud Storage, que é acessível a partir de qualquer lugar onde possa aceder aos serviços Google. Para incorporar o Cloud Storage no seu pipeline, tem de modificar o pipeline para compreender os caminhos dos objetos e, em seguida, extrair ou enviar os dados para os trabalhadores de renderização antes da renderização. A utilização deste método oferece acesso global aos dados publicados, mas requer que o seu pipeline forneça recursos onde são necessários num período razoável.
Por exemplo, um artista de texturas em Lisboa pode publicar ficheiros de imagem para serem usados por um artista de iluminação em Londres. O processo tem o seguinte aspeto:
- O pipeline de publicação envia ficheiros para o Cloud Storage e adiciona uma entrada a uma base de dados de recursos baseada na nuvem.
- Um artista em Londres executa um script para reunir recursos para uma cena. As localizações dos ficheiros são consultadas na base de dados e lidas a partir do armazenamento na nuvem para o disco local.
- O software de gestão de filas recolhe uma lista de recursos necessários para a renderização, consulta-os na base de dados de recursos e transfere-os do Cloud Storage para o armazenamento local de cada trabalhador de renderização.
A utilização do Cloud Storage desta forma também lhe oferece um arquivo de todos os seus dados publicados na nuvem se optar por usar o Cloud Storage como parte do seu pipeline de arquivo.
Gerir bases de dados
O software de gestão de recursos e produção depende de bases de dados altamente disponíveis e duradouras que são servidas em anfitriões capazes de processar centenas ou milhares de consultas por segundo. Normalmente, as bases de dados são alojadas num servidor no local que está a ser executado no mesmo rack que os trabalhadores de renderização e estão sujeitas às mesmas limitações de energia, rede e HVAC.
Pode considerar executar as suas bases de dados de produção MySQL, NoSQL e PostgreSQL como serviços geridos baseados na nuvem. Estes serviços estão altamente disponíveis e são acessíveis a nível global, encriptam os dados em repouso e em trânsito, e oferecem funcionalidade de replicação incorporada.
Gerir filas
Programas de software de gestão de filas disponíveis comercialmente, como o Qube!, Deadline, and Tractor são amplamente usados na indústria de efeitos visuais/animação. Também existem opções de software de código aberto disponíveis, como o OpenCue. Pode usar este software para implementar e gerir qualquer carga de trabalho de computação numa variedade de trabalhadores, não apenas renderizações. Pode implementar e gerir a publicação de recursos, as simulações de partículas e fluidos, a renderização de texturas e a composição com a mesma estrutura de agendamento que usa para gerir as renderizações.
Algumas instalações implementaram software de agendamento de fins gerais, como o HTCondor da Universidade do Wisconsin, Slurm da SchedMD ou o Univa Grid Engine nas respetivas pipelines de efeitos visuais. No entanto, o software concebido especificamente para a indústria de efeitos visuais presta especial atenção a funcionalidades como as seguintes:
- Dependência baseada em tarefas, frames e camadas. Algumas tarefas têm de ser concluídas antes de poder começar outros trabalhos. Por exemplo, execute uma simulação de fluidos na íntegra antes da renderização.
- Prioridade da tarefa, que os organizadores de renderização podem usar para alterar a ordem das tarefas com base em prazos e agendamentos individuais.
- Tipos de recursos, etiquetas ou alvos, que pode usar para fazer corresponder recursos específicos a tarefas que os exigem. Por exemplo, implemente renderizações aceleradas por GPU apenas em VMs com GPUs anexadas.
- Capturar dados do histórico sobre a utilização de recursos e disponibilizá-los através de uma API ou um painel de controlo para análise adicional. Por exemplo, analise a utilização média da CPU e da memória nas últimas iterações de uma renderização para prever a utilização de recursos na próxima iteração.
- Tarefas pré e pós-voo. Por exemplo, um trabalho de pré-voo extrai todos os recursos necessários para o trabalhador de renderização local antes da renderização. Uma tarefa pós-voo copia o frame renderizado resultante para uma localização designada num sistema de ficheiros e, em seguida, marca o frame como concluído num sistema de gestão de recursos.
- Integração com aplicações de software 2D e 3D populares, como Maya, 3ds Max, Houdini, Cinema 4D ou Nuke.
Notas de produção: use software de gestão de filas para reconhecer um conjunto de recursos baseados na nuvem como se fossem trabalhadores de renderização no local. Este método requer alguma supervisão para maximizar a utilização de recursos através da execução do maior número possível de renderizações que cada instância consegue processar, uma técnica conhecida como bin packing. Normalmente, estas operações são processadas de forma algorítmica e por especialistas em renderização.
Também pode automatizar a criação, a gestão e o encerramento de recursos baseados na nuvem com base na procura. Este método baseia-se no gestor de filas para executar scripts de pré e pós-renderização que criam recursos conforme necessário, monitorizam-nos durante a renderização e terminam-nos quando as tarefas estão concluídas.
Considerações sobre a implementação de tarefas
Quando implementa uma render farm que usa armazenamento no local e baseado na nuvem, seguem-se algumas considerações que o gestor de filas pode ter de ter em conta:
- O licenciamento pode diferir entre implementações na nuvem e no local. Algumas licenças são baseadas em nós e outras são orientadas por processos. Certifique-se de que o software de gestão de filas implementa tarefas para maximizar o valor das suas licenças.
- Considere adicionar etiquetas ou identificadores únicos aos recursos baseados na nuvem para garantir que são usados apenas quando atribuídos a tipos de serviços específicos.
- Use o Cloud Logging para detetar instâncias não usadas ou inativas.
- Ao iniciar tarefas dependentes, considere onde os dados resultantes vão residir e onde têm de estar para o passo seguinte.
- Se os seus espaços de nomes de caminhos diferirem entre o armazenamento no local e baseado na nuvem, considere usar caminhos relativos para permitir que as renderizações sejam independentes da localização. Em alternativa, consoante a plataforma, pode criar um mecanismo para trocar os caminhos no momento da renderização.
- Alguns renderizações, simulações ou pós-processamentos baseiam-se na geração de números aleatórios, que pode variar entre os fabricantes de CPUs. Mesmo as CPUs do mesmo fabricante, mas de 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 uma tarefa.
- Se estiver a usar um dispositivo de cache de leitura, considere implementar uma tarefa de pré-lançamento para pré-aquecer a cache e garantir que todos os recursos estão disponíveis na nuvem antes de implementar recursos na nuvem. Esta abordagem minimiza o tempo que os trabalhadores de renderização são obrigados a esperar enquanto os recursos são movidos para a nuvem.
Registo e monitorização
A gravação e a monitorização da utilização de recursos e do desempenho são um aspeto essencial de qualquer render farm. Google Cloud oferece várias APIs, ferramentas e soluções para ajudar a fornecer estatísticas sobre a utilização de recursos e serviços.
A forma mais rápida de monitorizar a atividade de uma VM é ver a respetiva saída da porta série. Este resultado pode ser útil quando uma instância não responde através dos planos de controlo de serviços típicos, como o supervisor de gestão da fila de renderização.
Outras formas de recolher e monitorizar a utilização de recursos no Google Cloud incluem:
- Use o Cloud Logging para capturar registos de utilização e auditoria, e para exportar os registos resultantes para o Cloud Storage, o BigQuery e outros serviços.
- Use o Cloud Monitoring para instalar um agente nas suas VMs para monitorizar as métricas do sistema.
- Incorpore a Cloud Logging API nos seus scripts de pipeline para registar diretamente no Cloud Logging através das bibliotecas cliente para linguagens de scripting populares.
- Use o Cloud Monitoring para criar gráficos para compreender a utilização de recursos.
Configurar as instâncias de trabalho de renderização
Para que a sua carga de trabalho seja verdadeiramente híbrida, os nós de renderização no local têm de ser idênticos aos nós de renderização baseados na nuvem, com versões do SO, compilações do kernel, bibliotecas e software instalados correspondentes. Também pode ter de reproduzir pontos de montagem, espaços de nomes de caminhos e até ambientes de utilizador na nuvem, porque estão no local.
Escolher uma imagem de disco
Pode escolher uma das imagens públicas ou criar a sua própria imagem personalizada com base na imagem do nó de renderização no local. As imagens públicas incluem uma coleção de pacotes que configuram e gerem contas de utilizador e ativam a autenticação baseada em chaves Secure Shell (SSH).
Criar uma imagem personalizada
Se optar por criar uma imagem personalizada, tem de adicionar mais bibliotecas ao Linux e ao Windows para que funcionem corretamente no ambiente do Compute Engine.
A sua imagem personalizada tem de estar em conformidade com as práticas recomendadas de segurança. Se estiver a usar o Linux, instale o ambiente convidado do Linux para o Compute Engine para aceder à funcionalidade que as imagens públicas oferecem por predefinição. Ao instalar o ambiente de convidado, pode realizar tarefas como o acesso a metadados, a configuração do sistema e a otimização do SO para utilização no Google Cloud, através dos mesmos controlos de segurança na sua imagem personalizada que usa em imagens públicas.
Notas de produção: faça a gestão das suas imagens personalizadas num projeto separado ao nível da organização. Esta abordagem dá-lhe um controlo mais preciso sobre a forma como as imagens são criadas ou modificadas e permite-lhe aplicar versões, o que pode ser útil quando usa diferentes versões de software ou SO em várias produções.
Automatizar a criação de imagens e a implementação de instâncias
Pode usar ferramentas como o Packer para tornar a criação de imagens mais reproduzível, auditável, configurável e fiável. Também pode usar uma ferramenta como o Ansible para configurar os nós de renderização em execução e exercer um controlo detalhado sobre a respetiva configuração e ciclo de vida.
Escolher um tipo de máquina
No Google Cloud, pode escolher um dos tipos de máquinas predefinidos ou especificar um tipo de máquina personalizado. A utilização de tipos de máquinas personalizados dá-lhe controlo sobre os recursos para que possa personalizar as instâncias com base nos tipos de tarefas que executa no Google Cloud. Quando cria uma instância, pode 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.
Notas de produção: para pipelines que implementam uma instância por fotograma, pondere personalizar a instância com base no histórico de estatísticas de tarefas, como a carga da CPU ou a utilização de memória, para otimizar a utilização de recursos em todos os fotogramas de uma tomada. Por exemplo, pode optar por implementar máquinas com um número mais elevado de CPUs para frames que contenham um efeito de desfoque de movimento intenso, de modo a ajudar a normalizar os tempos de renderização em todos os frames.
Escolher entre VMs padrão e VMs preemptíveis
As VMs preemptíveis (PVMs) referem-se à capacidade excessiva do Compute Engine que é vendida a um preço muito inferior ao das VMs padrão. O Compute Engine pode terminar ou antecipar estas instâncias se outras tarefas exigirem acesso a essa capacidade. As PVMs são ideais para cargas de trabalho de renderização com tolerância a falhas e geridas por um sistema de filas que monitoriza as tarefas perdidas devido à preemptividade.
As VMs padrão podem ser executadas indefinidamente e são ideais para servidores de licenças ou anfitriões de administradores de filas que precisam de ser executados de forma persistente.
As VMs preemptíveis são terminadas automaticamente após 24 horas, por isso, não as use para executar renderizações ou simulações que demorem mais tempo.
As taxas de antecipação variam entre 5% e 15%, o que, para cargas de trabalho de renderização típicas, é provavelmente tolerável dado o custo reduzido. Algumas práticas recomendadas preemptíveis podem ajudar a decidir a melhor forma de integrar as PVMs na sua pipeline de renderização. Se a sua instância for anulada, o Compute Engine envia um sinal de anulação para a instância, que pode usar para acionar o seu programador para terminar a tarefa atual e colocá-la novamente na fila.
| VM padrão | VM preemptiva |
|---|---|
| Podem ser usados para tarefas de execução prolongada. Ideal para trabalhos de alta prioridade com prazos rigorosos. Pode ser executado indefinidamente, sendo ideal para servidores de licenças ou alojamento de administrador de filas. |
Terminada automaticamente após 24 horas. Requer um sistema de gestão de filas para processar instâncias antecipadas. |
Notas de produção: alguns renderizadores podem fazer uma captura de ecrã de uma renderização em curso a intervalos especificados. Por isso, se a VM for interrompida, pode pausar e retomar a renderização sem ter de reiniciar um frame do zero. Se o seu renderizador suportar a criação de instantâneos e optar por usar PVMs, ative a criação de instantâneos de renderização no seu pipeline para evitar perder trabalho. Enquanto as capturas instantâneas estão a ser escritas e atualizadas, os dados podem ser escritos no armazenamento na nuvem e, se o trabalhador de renderização for interrompido, são obtidos quando é implementado um novo PVM. Para evitar custos de armazenamento, elimine os dados de capturas instantâneas de renderizações concluídas.
Conceder acesso a trabalhadores de renderização
A IAM ajuda a atribuir acesso a recursos na nuvem a indivíduos que precisam de acesso. Para os trabalhadores de renderização do Linux, pode usar o Início de sessão do SO para restringir ainda mais o acesso numa sessão SSH, o que lhe dá controlo sobre quem é administrador.
Controlar os custos de uma farm de renderização híbrida
Ao estimar os custos, tem de considerar muitos fatores, mas recomendamos que implemente estas práticas recomendadas comuns como política para a sua farm de renderização híbrida:
- Use instâncias preemptíveis por predefinição. A menos que a sua tarefa de renderização seja de execução extremamente longa, quatro ou mais horas por fotograma, ou tenha um prazo rigoroso para entregar uma tomada, use VMs preemptivas.
- Minimizar a saída. Copie apenas os dados de que precisa de volta para o armazenamento no local. Na maioria dos casos, estes dados são os frames renderizados finais, mas também podem ser passes separados ou dados de simulação. Se estiver a montar o NAS no local diretamente ou a usar um produto de armazenamento que sincroniza automaticamente, escreva todos os dados renderizados no sistema de ficheiros local do trabalhador de renderização e, em seguida, copie o que precisa de volta para o armazenamento no local para evitar a saída de dados temporários e desnecessários.
- Ajuste o tamanho das VMs. Certifique-se de que cria os seus trabalhadores de renderização com uma utilização de recursos ideal, atribuindo apenas o número necessário de vCPUs, a quantidade ideal de RAM e o número correto de GPUs, se existirem. Considere também como minimizar o tamanho de quaisquer discos anexados.
- Considere o mínimo de um minuto. A partir de Google Cloud, as instâncias são faturadas por segundo, com um mínimo de um minuto. Se a sua carga de trabalho incluir a renderização de frames que demoram menos de um minuto, considere agrupar as tarefas para evitar implementar uma instância por menos de um minuto de tempo de computação.
- Mantenha grandes conjuntos de dados na nuvem. Se usar a sua render farm para gerar grandes quantidades de dados, como EXRs profundos ou dados de simulação, considere usar uma estação de trabalho baseada na nuvem que esteja mais abaixo no pipeline. Por exemplo, um artista de efeitos especiais pode executar uma simulação de fluidos na nuvem, escrevendo ficheiros de cache no armazenamento baseado na nuvem. Um artista de iluminação pode, em seguida, aceder a estes dados de simulação a partir de uma estação de trabalho virtual que esteja naGoogle Cloud. Para mais informações sobre estações de trabalho virtuais, contacte o seu Google Cloud representante.
- Tire partido dos descontos por utilização sustentada e de fidelidade. Se executar um conjunto de recursos, os descontos por utilização contínua podem poupar-lhe até 30% do custo das instâncias que são executadas durante um mês inteiro. Os descontos por utilização garantida também podem fazer sentido em alguns casos.
A extensão da sua farm de renderização existente para a nuvem é uma forma rentável de usar recursos poderosos e de baixo custo sem despesas de capital. Não existem dois processos de produção iguais, pelo que nenhum documento pode abranger todos os tópicos e requisitos únicos. Para obter ajuda com a migração das suas cargas de trabalho de renderização para a nuvem, contacte o seu Google Cloud representante.
O que se segue?
- Explore arquiteturas de referência, diagramas e práticas recomendadas sobre o Google Cloud. Consulte o nosso Centro de arquitetura na nuvem.