Creare una fattoria di rendering ibrida

Questo articolo fornisce indicazioni sull'estensione della tua fattoria di rendering on-premise esistente per utilizzare le risorse di computing su Google Cloud (Google Cloud). L'articolo presuppone che tu abbia già implementato una farm di rendering on-premise e abbia familiarità con i concetti di base di effetti visivi e pipeline di animazione, software di gestione delle code e metodi di licenza software comuni.

Panoramica

Il rendering di elementi 2D o 3D per animazioni, film, pubblicità o videogiochi richiede tempo e capacità di calcolo. Il rendering di questi elementi richiede un consistente investimento in hardware e infrastruttura, oltre a un team dedicato di professionisti IT per il deployment e la manutenzione di hardware e software.

Quando una farm di rendering on-premise ha un utilizzo del 100%, la gestione dei job può diventare una sfida. Le priorità e le dipendenze delle attività, il riavvio dei frame persi e il carico di rete, disco e CPU fanno parte dell'equazione complessa che devi monitorare e controllare strettamente, spesso con scadenze strette.

Per gestire questi job, le strutture VFX hanno incorporato un software di gestione delle code nelle proprie pipeline. I software di gestione delle code possono:

  • Eseguire il deployment di job in risorse on-premise e basate su cloud.
  • Gestire le dipendenze tra i lavori.
  • Comunicare con i sistemi di gestione delle risorse.
  • Fornisci agli utenti un'interfaccia utente e API per i linguaggi comuni come Python.

Sebbene alcuni software di gestione delle code possano eseguire il deployment dei job sui worker basati su cloud, sarai comunque responsabile della connessione al cloud, della sincronizzazione degli asset, della scelta di un framework di archiviazione, della gestione dei modelli di immagine e della fornitura delle tue licenze software.

Alcune strutture di piccole o medie dimensioni che non hanno le risorse tecniche per implementare una farm di rendering ibrida possono utilizzare un servizio di farm di rendering basato su cloud, come Conductor. Per determinare la soluzione ideale per la tua struttura, parla con il tuo rappresentante di Google Cloud.

Nota: le note di produzione vengono visualizzate periodicamente in questo articolo. Queste note offrono le best practice da seguire per la creazione della farm di rendering.

Connessione al cloud

A seconda del carico di lavoro, decidi in che modo la tua struttura si connette a Google Cloud, tramite un ISP partner, una connessione diretta o la rete Internet pubblica.

Connessione a Internet

Senza connettività speciale, puoi connetterti alla rete di Google e utilizzare il nostro modello di sicurezza end-to-end accedendo ai servizi Google Cloud su Internet. Utilità come gli strumenti a riga di comando gcloud e gsutil come l'API Compute Engine utilizzano tutti l'autenticazione, l'autorizzazione e la crittografia sicure per proteggere i tuoi dati.

Cloud VPN

Indipendentemente dalla modalità di connessione, ti consigliamo di utilizzare una rete privata virtuale (VPN) per proteggere la tua connessione.

Cloud VPN ti aiuta a connettere in modo sicuro la rete on-premise alla rete Google Virtual Private Cloud (VPC) tramite una connessione VPN IPsec. I dati in transito vengono criptati prima di passare attraverso uno o più tunnel VPN.

Scopri come creare una VPN per il tuo progetto.

VPN fornita dal cliente

Anche se puoi impostare un gateway VPN personalizzato per connetterti direttamente a Google, ti consigliamo di utilizzare Cloud VPN, che offre maggiore flessibilità e una migliore integrazione con Google Cloud.

Cloud Interconnect

Google supporta diversi modi per connettere la tua infrastruttura a Google Cloud. Queste connessioni di livello enterprise, note collettivamente come Cloud Interconnect, offrono una disponibilità più elevata e una latenza inferiore rispetto alle connessioni a Internet standard, oltre a una riduzione dei prezzi del traffico in uscita.

Dedicated Interconnect

Dedicated Interconnect fornisce connessioni fisiche dirette e una comunicazione RFC 1918 tra la tua rete on-premise e la rete Google. Fornisce capacità di connessione sui seguenti tipi di connessione:

  • Una o più connessioni Ethernet a 10 Gbps, con un massimo di 8 connessioni o 80 Gbps in totale per interconnessione.
  • Una o più connessioni Ethernet a 100 Gbps, con un massimo di due connessioni o 200 Gbps in totale per interconnessione.

Il traffico di Dedicated Interconnect non è criptato, tuttavia se devi trasmettere i dati in Dedicated Interconnect in modo sicuro, devi stabilire la tua connessione VPN. Cloud VPN non è compatibile con Dedicated Interconnect, in questo caso devi fornire la tua VPN.

Partner Interconnect

Partner Interconnect fornisce la connettività tra la tua rete on-premise e la rete VPC tramite un provider di servizi supportato. Una connessione Partner Interconnect è utile se la tua infrastruttura si trova in una località fisica che non può raggiungere una struttura di colocation di Dedicated Interconnect o se le tue esigenze di dati non garantiscono un'intera connessione a 10 Gbps.

Altri tipi di connessione

Altri modi per connettersi a Google potrebbero essere disponibili nella tua località specifica. Per assistenza per determinare il modo migliore e più conveniente per connetterti a Google Cloud, rivolgiti al tuo rappresentante GCP.

Protezione dei contenuti

Per eseguire i loro contenuti su qualsiasi piattaforma cloud pubblica, i proprietari di contenuti, come le principali case di produzione di Hollywood, richiedono ai fornitori di rispettare le best practice definite internamente e da organizzazioni come la MPAA.

Sebbene ogni studio abbia requisiti leggermente diversi, la sicurezza dei carichi di lavoro di rendering fornisce best practice per la creazione di una farm di rendering ibrida. Puoi anche consultare i white paper sulla sicurezza e la documentazione sulla conformità all'indirizzo cloud.google.com/security.

Se hai domande sulla procedura di controllo della conformità della sicurezza, contatta il tuo rappresentante GCP.

Organizzazione dei progetti

I progetti sono un componente organizzativo principale di Google Cloud. Nella tua struttura, puoi organizzare i lavori nel loro progetto o suddividerli in più progetti. Ad esempio, potresti voler creare progetti separati per le fasi di previsualizzazione, ricerca e sviluppo e produzione per un film.

I progetti stabiliscono un limite di isolamento sia per i dati di rete che per l'amministrazione dei progetti. Tuttavia, puoi condividere le reti tra progetti con il VPC condiviso, che fornisce progetti separati con accesso alle risorse comuni.

Note di produzione: crea un progetto host in VPC condiviso contenente le risorse con tutti gli strumenti di produzione. Puoi designare tutti i progetti creati nella tua organizzazione come progetti di servizio VPC condivisi. Questa designazione prevede che qualsiasi progetto nell'organizzazione può accedere alle stesse librerie, script e software forniti dal progetto host.

La risorsa Organizzazione

Puoi gestire i progetti in una risorsa organizzazione, che potresti aver già stabilito. La migrazione di tutti i progetti in un'organizzazione offre una serie di vantaggi.

Note di produzione: designa i responsabili di produzione come proprietari dei singoli progetti e della gestione degli studi come proprietari della risorsa organizzazione.

Definizione dell'accesso alle risorse

I progetti richiedono l'accesso sicuro alle risorse e la limitazione su dove gli utenti o i servizi possono operare. Per aiutarti a definire l'accesso, Google Cloud offre Identity and Access Management (IAM), che puoi utilizzare per gestire il controllo dell'accesso tramite la definizione di quali ruoli hanno quali livelli di accesso a ogni risorsa.

Note di produzione: per limitare gli utenti' accedere solo alle risorse necessarie per eseguire attività specifiche in base al loro ruolo, implementare il principio del privilegio minimo sia on-premise che nel cloud.

Prendi ad esempio un lavoratore di rendering, che è una macchina virtuale (VM) di cui puoi eseguire il deployment da un modello di istanza predefinito che utilizza l'immagine personalizzata. Il worker di rendering in esecuzione in un account di servizio può leggere da Cloud Storage e scrivere nello spazio di archiviazione collegato, ad esempio un filer cloud o un disco permanente. Tuttavia, non è necessario aggiungere singoli artisti ai progetti Google Cloud, perché non hanno bisogno di accesso diretto alle risorse cloud.

Puoi assegnare ruoli ai wrangler o agli amministratori di progetto che hanno accesso a tutte le risorse di Compute Engine, il che consente loro di eseguire funzioni su risorse inaccessibili ad altri utenti.

Definisci un criterio per determinare quali ruoli possono accedere ai tipi di risorse nella tua organizzazione. La tabella seguente mostra come le attività tipiche di produzione vengono mappate ai ruoli IAM in Google Cloud.

Attività di produzione Nome ruolo Tipo di risorsa
Gestore di studio resourcemanager.organizationAdmin Organizzazione
Progetto
Gestore della produzione owner, editor Progetto
Visualizza wrangler compute.admin, iam.serviceAccountActor Progetto
Account per la gestione delle code compute.admin, iam.serviceAccountActor Organizzazione
Progetto
Artista individuale [nessun accesso] Non applicabile

Ambiti di accesso

Gli ambiti di accesso consentono di controllare le autorizzazioni di un'istanza in esecuzione, indipendentemente da chi ha eseguito l'accesso. Puoi specificare gli ambiti quando crei un'istanza autonomamente o quando il software di gestione delle code esegue il deployment delle risorse da un modello di istanza.

Gli ambiti hanno la precedenza sulle autorizzazioni IAM di un singolo account utente o di servizio. Questa precedenza significa che un ambito di accesso può impedire a un amministratore del progetto di accedere a un'istanza per eliminare un bucket di archiviazione o modificare un'impostazione del firewall.

Note di produzione: per impostazione predefinita, le istanze possono leggere ma non scrivere in Cloud Storage. Se il processo di scrittura della pipeline di rendering viene eseguito nuovamente in Cloud Storage, aggiungi l'ambito devstorage.read_write all'istanza al momento della creazione.

Scelta di come eseguire il deployment delle risorse

Con il rendering su cloud puoi usare le risorse solo quando necessario, ma puoi scegliere tra diversi modi per rendere le risorse disponibili per la tua farm di rendering.

Deployment on demand

Per un utilizzo ottimale delle risorse, puoi scegliere di eseguire il deployment dei worker di rendering solo quando invii un job alla farm di rendering. Puoi eseguire il deployment di molte VM da condividere tra tutti i frame di un job o persino creare una VM per frame.

Il tuo sistema di gestione delle code può monitorare le istanze in esecuzione, che possono essere accodate se una VM viene prerilasciata e terminata al completamento di singole attività.

Eseguire il deployment di un pool di risorse

Puoi anche scegliere di eseguire il deployment di un gruppo di istanze, non correlate a un job specifico, a cui il tuo sistema di gestione della coda on-premise può accedere come risorse aggiuntive. Sebbene sia economicamente conveniente rispetto a una strategia on demand, un gruppo di istanze in esecuzione può accettare più job per VM, utilizzando tutti i core e massimizzando l'utilizzo delle risorse. Questo approccio potrebbe essere la strategia più semplice da implementare perché imita il modo in cui una farm di rendering on-premise viene popolata con i job.

Concedere in licenza il software

Le licenze del software di terze parti possono variare notevolmente da pacchetto a pacchetto. Ecco alcuni schemi e modelli di licenza che potresti incontrare in una pipeline VFX. Per ogni schema, la terza colonna mostra l'approccio alle licenze consigliato.

Scheme Descrizione Suggerimento
Nodo bloccato Concesso in licenza a un indirizzo MAC, a un indirizzo IP o a un ID CPU specifico. Può essere eseguito solo da un singolo processo. Basata su istanza
Basata su nodo Concesso in licenza a un nodo specifico (istanza). È possibile eseguire un numero arbitrario di utenti o processi su un nodo concesso in licenza. Basata su istanza
Floating Effettuare il pagamento da un server delle licenze che tiene traccia dell'utilizzo. Server licenze
Licenze software
Interattiva Consente all'utente di eseguire software in modo interattivo in un ambiente grafico. Server licenze o basata su istanza
Batch Consente all'utente di eseguire software solo in un ambiente a riga di comando. Server licenze
Licenze basate su cloud
Basato su utilizzo Eseguito solo quando un processo è in esecuzione su un'istanza cloud. Quando il processo termina o termina, la licenza viene rilasciata. Server licenze basato su cloud
Tempo di attività basato Pagamento eseguito mentre un'istanza è attiva e in esecuzione. Quando l'istanza viene arrestata o eliminata, la licenza viene rilasciata. Server licenze basato su cloud

Utilizzo delle licenze basate sull'istanza

Alcuni programmi software o plug-in sono concessi in licenza direttamente all'hardware su cui sono in esecuzione. Questo approccio alle licenze può rappresentare un problema nel cloud, in cui gli identificatori hardware, come gli indirizzi MAC o IP, vengono assegnati in modo dinamico.

Indirizzi MAC

Quando vengono create, alle istanze viene assegnato un indirizzo MAC che viene conservato fino a quando l'istanza non viene eliminata. Puoi interrompere o riavviare un'istanza e l'indirizzo MAC verrà mantenuto. Puoi utilizzare questo indirizzo MAC per la creazione e la convalida delle licenze fino all'eliminazione dell'istanza.

Assegna un indirizzo IP statico

Quando crei un'istanza, gli viene assegnato un indirizzo IP interno e, facoltativamente, esterno. Per mantenere l'indirizzo IP esterno di un'istanza, puoi prenotare un indirizzo IP statico e assegnarlo alla tua istanza. Questo indirizzo IP sarà riservato solo a questa istanza. Poiché gli indirizzi IP statici sono una risorsa basata su progetti, sono soggetti alle quote per area geografica.

Puoi anche assegnare un indirizzo IP interno quando crei un'istanza. Questo è utile se vuoi che gli indirizzi IP interni di un gruppo di istanze rientrino nello stesso intervallo.

Dongle hardware

Il software meno recente potrebbe comunque essere concesso in licenza tramite chiavetta, un token hardware programmato con una licenza di prodotto. La maggior parte delle società di software ha smesso di utilizzare le chiavette hardware, ma alcuni utenti potrebbero avere software legacy legati a uno di questi dispositivi. Se riscontri questo problema, parla con il produttore del software per vedere se può fornirti una licenza aggiornata per il software specifico.

Se il produttore del software non può fornire una licenza di questo tipo, puoi implementare un hub USB collegato alla rete o una soluzione USB over IP.

Utilizzo di un server di licenze

Il software più moderno offre un'opzione di licenza mobile. Questa opzione è più sensata per l'ambiente cloud, ma richiede una gestione più efficace delle licenze e il controllo dell'accesso per prevenire il consumo eccessivo di un numero limitato di licenze.

Per evitare di superare la capacità delle licenze, come parte del processo della coda dei job puoi scegliere quali licenze utilizzare e controllare il numero di job che utilizzano le licenze.

Server licenze on-premise

Puoi utilizzare il tuo server delle licenze on-premise esistente per fornire licenze alle istanze in esecuzione nel cloud. Se scegli questo metodo, devi fornire ai worker di rendering un modo per comunicare con la tua rete on-premise, tramite una VPN o un'altra connessione sicura.

Server di licenze basato su cloud

Nel cloud puoi eseguire un server di licenze per la gestione delle istanze nel tuo progetto o anche tra progetti utilizzando il VPC condiviso. Le licenze mobili sono talvolta collegate a un indirizzo MAC hardware, quindi una piccola istanza di lunga durata con un indirizzo IP statico può gestire facilmente le licenze su molte istanze di rendering.

Server licenze ibrido

Alcuni software possono utilizzare più server di licenze in ordine di priorità. Ad esempio, un renderer potrebbe eseguire query sul numero di licenze disponibili da un server on-premise. Se non è disponibile nessuna licenza, utilizza un server di licenze basato su cloud. Questa strategia può aiutare a massimizzare l'utilizzo di licenze permanenti prima di prendere in considerazione altri tipi di licenze.

Note di produzione: definisci uno o più server di licenze in una variabile di ambiente e definisci l'ordine di priorità. Autodesk Arnold, un renderer popolare, ti aiuta in questo caso. Se il job non può acquisire una licenza utilizzando il primo server, tenta di utilizzare qualsiasi altro server elencato, come nell'esempio seguente:

export solidangle_LICENSE=5053@x.x.0.1;5053@x.x.0.2

Nell'esempio precedente, il renderer Arnold tenta di ottenere una licenza dal server sulla porta 5053, in x.x.0.1. Se il tentativo non va a buon fine, tenterà di ottenere una licenza dalla stessa porta all'indirizzo IP x.x.0.2.

Licenze basate su cloud

Alcuni fornitori offrono licenze basate su cloud che forniscono licenze software on demand per le tue istanze. Le licenze basate su cloud sono solitamente fatturate in due modi: basati sull'utilizzo e sull'uptime.

Licenze basate sull'utilizzo

Le licenze basate sull'utilizzo vengono fatturate in base al tempo di utilizzo del software. In genere, con questo tipo di licenze, la licenza viene estratta da un server basato su cloud all'avvio del processo e viene rilasciata al completamento del processo. Se una licenza è in fase di pagamento, ti sarà addebitato un costo per l'utilizzo di tale licenza. Questo tipo di licenza viene in genere utilizzato per il software di rendering.

Licenze basate sul tempo di attività

Le licenze basate sul tempo di attività o a consumo vengono fatturate in base al tempo di attività dell'istanza di Compute Engine. L'istanza è configurata per la registrazione con il server delle licenze basato su cloud durante la procedura di avvio. Se l'istanza è in esecuzione, la licenza è in fase di pagamento. Quando l'istanza viene arrestata o eliminata, la licenza viene rilasciata. Questo tipo di licenza viene in genere utilizzata per i worker di rendering di cui un gestore coda esegue il deployment.

Scegliere come archiviare i dati

Il tipo di archiviazione che scegli su Google Cloud dipende dalla strategia di archiviazione scelta, insieme a fattori come requisiti di durabilità e costi. Per saperne di più su Cloud Storage, consulta File server su Compute Engine.

Persistent Disk

Potresti evitare di implementare completamente un file server incorporando dischi permanenti (PD) nel tuo carico di lavoro. I DP sono un tipo di archiviazione a blocchi conforme a POSIX, con dimensioni fino a 64 TB, note alla maggior parte delle strutture VFX. I dischi permanenti sono disponibili sia come unità standard che come unità a stato solido (SSD). Puoi collegare un DP in modalità di lettura/scrittura a una singola istanza oppure in modalità di sola lettura a un numero elevato di istanze, ad esempio a un gruppo di worker di rendering.

Vantaggi Svantaggi Caso d'uso ideale
Monta come volume NFS o SMB standard.

Possibilità di ridimensionare in modo dinamico.

A ogni istanza è possibile collegare fino a 128 DP.

Lo stesso DP può essere montato in sola lettura su centinaia o migliaia di istanze.
Dimensione massima di 64 TB.

Può scrivere nel DP solo se è collegato a una singola istanza.

Sono accessibili solo le risorse che si trovano nella stessa area geografica.
Pipeline avanzate che possono creare un nuovo disco in base al lavoro.

Pipeline che pubblicano dati aggiornati di rado, come software o librerie comuni, per il rendering dei worker.

Archiviazione di oggetti

Cloud Storage è uno spazio di archiviazione altamente ridondante e a elevata durabilità, che, a differenza dei file system tradizionali, ha una capacità non strutturata e praticamente illimitata. I file in Cloud Storage sono archiviati in bucket, simili alle cartelle, e sono accessibili in tutto il mondo.

A differenza dell'archiviazione tradizionale, l'archiviazione di oggetti non può essere montata come volume logico da un sistema operativo. Se decidi di incorporare l'archiviazione di oggetti nella pipeline di rendering, devi modificare la modalità di lettura e scrittura dei dati, utilizzando utilità a riga di comando come gsutil o tramite l'API Cloud Storage.

Vantaggi Svantaggi Caso d'uso ideale
Archiviazione durevole e ad alta disponibilità per file di tutte le dimensioni.

Singola API per tutte le classi di archiviazione.

Non costa nulla.

I dati sono disponibili in tutto il mondo.

Capacità praticamente illimitata.
Non conforme a POSIX.

Devi accedere tramite API o riga di comando.

In una pipeline di rendering, i dati devono essere trasferiti in locale prima di essere utilizzati.
Visualizza le pipeline con un sistema di gestione degli asset che può pubblicare dati in Cloud Storage.

Esegui il rendering delle pipeline con un sistema di gestione delle code in grado di recuperare i dati da Cloud Storage prima di eseguirne il rendering.

Altri prodotti di archiviazione

Altri prodotti di archiviazione sono disponibili come servizi gestiti, mediante canali di terze parti come Cloud Marketplace o come progetti open source tramite repository software o GitHub.

Prodotto Vantaggi Svantaggi Caso d'uso ideale
Elastifile, Cloud File System (ECFS) [Acquisito da Google Cloud] File system in cluster in grado di supportare migliaia di connessioni NFS simultanee.

Capacità di sincronizzazione con il cluster NAS on-premise.
Sebbene sia disponibile l'archiviazione on-premise o la sincronizzazione nel cloud, i dati possono essere sincronizzati solo in una direzione. Ad esempio, il NAS on-premise può leggere e scrivere, ma l'ECFS basato su cloud è di sola lettura.

Non è possibile sincronizzare i file in modo selettivo. Nessuna sincronizzazione bidirezionale.
Strutture VFX di medie e grandi dimensioni con centinaia di TB di dati da presentare sul cloud.
Pixit Media, PixStor Scale out del file system in grado di supportare migliaia di client NFS o POSIX simultanei. I dati possono essere memorizzati nella cache on demand dal NAS on-premise, con gli aggiornamenti inviati automaticamente allo spazio di archiviazione on-premise. Costo, assistenza di terze parti da Pixit. Strutture VFX di medie e grandi dimensioni con centinaia di TB di dati da presentare sul cloud.
Filestore Soluzione di archiviazione completamente gestita su Google Cloud.

Semplice da implementare e gestire.
Massimo 64 TB per istanza. Le prestazioni NFS sono fisse e non scalano in base al numero di client attivi. Strutture VFX medio-piccole con una pipeline in grado di sincronizzare gli asset.

Disco condiviso tra workstation virtuali.
FUSSO DI Cloud Storage Montare bucket Cloud Storage come file system. Costi ridotti. Non è un file system conforme a POSIX. Può essere difficile da configurare e ottimizzare. Strutture VFX in grado di eseguire il deployment, configurare e gestire un file system open source, con una pipeline in grado di sincronizzare gli asset.

Su Google Cloud sono disponibili altri tipi di archiviazione. Per ulteriori informazioni, contatta il tuo rappresentante GCP.

Ulteriori informazioni sulle opzioni di archiviazione dei dati

Implementazione delle strategie di archiviazione

Puoi implementare una serie di strategie di archiviazione nelle pipeline di produzione di VFX o di animazione stabilendo convenzioni che determinano come gestire i dati, sia che tu acceda ai dati direttamente dallo spazio di archiviazione on-premise o che li sincronizzi tra il cloud e il cloud.

Strategia 1: montare l'archiviazione on-premise direttamente

Montaggio di archiviazione on-premise direttamente da worker di rendering basati su cloud
Montaggio dell'archiviazione on-premise direttamente da worker di rendering basati su cloud

Se la tua struttura ha una connettività a Google Cloud di almeno 10 Gbps e si trova nelle vicinanze di un'area geografica Google Cloud, puoi scegliere di montare il tuo NAS on-premise direttamente sui worker di rendering cloud. Sebbene questa strategia sia semplice, può anche richiedere un elevato dispendio di costi e larghezza di banda, perché tutto ciò che crei sul cloud e scrivi di nuovo nello spazio di archiviazione viene conteggiato come dati in uscita.

Vantaggi Svantaggi Caso d'uso ideale
Implementazione semplice.

Lettura/scrittura in uno spazio di archiviazione comune.

Disponibilità immediata dei dati, senza necessità di memorizzazione nella cache o sincronizzazione.
Può essere più costoso di altre opzioni.

La vicinanza a un data center di Google è necessaria per una bassa latenza.

Il numero massimo di istanze che puoi connetterti al NAS on-premise dipende dalla larghezza di banda e dal tipo di connessione.
Le strutture vicino a un data center di Google che devono burst eseguire il rendering dei carichi di lavoro nel cloud, in cui il costo non è un problema.

Servizi con connettività a Google Cloud di almeno 10 Gbps.

Strategia 2: sincronizzazione on demand

Sincronizzare i dati tra l'archiviazione on-premise e l'archiviazione basata su cloud on demand
Sincronizzazione dei dati tra archiviazione on-premise e archiviazione on demand basata su cloud

Puoi scegliere di eseguire il push dei dati nel cloud oppure eseguire il pull dei dati dallo spazio di archiviazione on-premise o viceversa, solo quando sono necessari i dati, ad esempio quando viene visualizzato un frame o viene pubblicato un asset. Se utilizzi questa strategia, la sincronizzazione può essere attivata da un meccanismo nella pipeline come uno script di visualizzazione, da un gestore di eventi come Pub/Sub o da un insieme di comandi come parte di uno script di job.

Puoi eseguire una sincronizzazione utilizzando una varietà di comandi, ad esempio il comando gcloud scp, il comando gsutil rsync o protocolli Data Transfer basati su UDP (UDT). Se scegli di utilizzare un UDT di terze parti come Aspera, Cloud FastPath, BitSpeed o FDT per comunicare con un bucket Cloud Storage, fai riferimento alla documentazione della terza parte per ulteriori informazioni sul modello di sicurezza e sulle best practice. Google non gestisce questi servizi di terze parti.

Metodo push

In genere, il metodo push viene utilizzato quando pubblichi un asset, posizioni un file in una cartella di visualizzazione o completi un job di rendering, dopodiché esegui il push in una posizione predefinita.

Esempi:

  • Un worker di rendering cloud completa un job di rendering e i frame risultanti vengono trasferiti nello spazio di archiviazione on-premise.
  • Un artista pubblica una risorsa. Parte del processo di pubblicazione degli asset prevede il trasferimento dei dati associati a un percorso predefinito su Cloud Storage.

Metodo di pull

Utilizzi il metodo pull quando viene richiesto un file, in genere da un'istanza di rendering basata su cloud.

Esempio: come parte di uno script di job di rendering, tutti gli asset necessari per visualizzare una scena vengono inseriti in un file system prima del rendering, dove tutti i worker di rendering possono accedervi.

Vantaggi Svantaggi Caso d'uso ideale
Controllo completo sui dati da sincronizzare e su quando.

Possibilità di scegliere il metodo e il protocollo di trasferimento.
La pipeline di produzione deve essere in grado di gestire gli eventi per attivare le sincronizzazioni push/pull.

Per gestire la coda di sincronizzazione potrebbero essere necessarie risorse aggiuntive.
Strutture di piccole e grandi dimensioni con pipeline personalizzate e che hanno il controllo completo della sincronizzazione degli asset.

Note di produzione: gestisci la sincronizzazione dei dati con lo stesso sistema di gestione delle code che utilizzi per gestire i job di rendering. Le attività di sincronizzazione possono utilizzare risorse cloud separate per massimizzare la larghezza di banda disponibile e ridurre al minimo il traffico di rete.

Strategia 3: archiviazione on-premise, cache di lettura basata su cloud

Utilizzo dello spazio di archiviazione on-premise con una cache read-through basata su cloud
Utilizzo dello spazio di archiviazione on-premise con una cache di lettura basata su cloud

In questa strategia, implementi un'appliance di memorizzazione nella cache virtuale nel cloud che funge da cache di lettura e da server di file. Ogni worker di rendering cloud esegue il montaggio dell'appliance di memorizzazione nella cache secondo il protocollo NFS o SMB, come si farebbe con un file server convenzionale. Se un worker di rendering legge un file che non è presente nella cache, il file viene trasferito dallo spazio di archiviazione on-premise al cloud filer. A seconda di come hai configurato il file server di memorizzazione nella cache, i dati rimangono nella cache fino a:

  • I dati invecchiano o non vengono toccati per un periodo di tempo specificato.
  • Lo spazio sul server dei file è necessario, dopodiché i dati vengono rimossi dalla cache in base all'età.

Questa strategia riduce la quantità di larghezza di banda e complessità richieste per il deployment di molte istanze di rendering simultanee.

In alcuni casi, potresti preriscaldare la cache per assicurarti che tutti i dati relativi al lavoro siano presenti prima del rendering. Per preparare la cache, leggi i contenuti di una directory sul server file cloud eseguendo un elemento read o stat su uno o più file. L'accesso ai file in questo modo attiva il meccanismo di sincronizzazione.

Puoi anche aggiungere un'appliance fisica on-premise per comunicare con l'appliance virtuale. Ad esempio, NetApp offre una soluzione di archiviazione che può ridurre ulteriormente la latenza tra il tuo spazio di archiviazione on-premise e il cloud.

Vantaggi Svantaggi Caso d'uso ideale
I dati memorizzati nella cache vengono gestiti automaticamente.

Riduce i requisiti di larghezza di banda.

I file system in cluster possono essere sottoposti a scale up o scale down a seconda dei requisiti del job.
Può comportare costi aggiuntivi.

Se scegli di preparare in anticipo la cache, devi implementare le attività preliminari.
Grandi strutture che eseguono il deployment di molte istanze in parallelo e leggono gli asset comuni in molti job.

Filtrare i dati

Puoi creare un database di tipi di risorse e condizioni associate per definire se sincronizzare un determinato tipo di dati. Non vorrai mai sincronizzare alcuni tipi di dati, ad esempio i dati temporanei generati nell'ambito di un processo di conversione, i file memorizzati nella cache o i dati di simulazione. Valuta anche se sincronizzare gli asset non approvati, perché non tutte le iterazioni verranno utilizzate nei rendering finali.

Eseguire un trasferimento collettivo iniziale

Quando implementi la farm di rendering ibrida, è consigliabile eseguire un trasferimento iniziale di tutto o parte del set di dati in Cloud Storage, un disco permanente o un altro spazio di archiviazione basato su cloud. A seconda di fattori come la quantità e il tipo di dati da trasferire e la velocità di connessione, potresti essere in grado di eseguire una sincronizzazione completa nel corso di alcuni giorni o settimane. La seguente figura mette a confronto i tempi tipici dei trasferimenti online e fisici.

Confronto tra orari tipici per i trasferimenti fisici e online
Confronto tra orari tipici per i trasferimenti online e fisici

Se il carico di lavoro di trasferimento supera i vincoli di tempo o larghezza di banda, Google offre una serie di opzioni di trasferimento per trasferire i dati nel cloud, tra cui Transfer Appliance di Google.

Archiviazione e ripristino di emergenza

Vale la pena notare la differenza tra l'archiviazione dei dati e il ripristino di emergenza. La prima è una copia selettiva del lavoro finito, mentre la seconda è uno stato di dati che può essere recuperato. Vuoi progettare un piano di ripristino di emergenza che si adatti alle esigenze della tua struttura e fornisca un piano di emergenza esterno al sito. Contatta il tuo fornitore di spazio di archiviazione on-premise per ricevere assistenza per un piano di ripristino di emergenza adatto alla tua piattaforma di archiviazione specifica.

Archiviazione dei dati nel cloud

Dopo aver completato un progetto, è comune salvare il lavoro finito in una qualche forma di spazio di archiviazione a lungo termine, in genere un supporto magnetico come LTO. Queste cartucce sono soggette ai requisiti ambientali e, nel tempo, possono essere difficili da gestire dal punto di vista logistico. A volte le grandi strutture di produzione ospitano l'intero archivio in una sala apposita con un archivio a tempo pieno per tenere traccia dei dati e recuperarli quando richiesto.

La ricerca di asset, filmati o filmati archiviati specifici può richiedere molto tempo, poiché i dati potrebbero essere archiviati su più cartucce, l'indicizzazione dell'archivio potrebbe risultare mancante o incompleta oppure potrebbero esserci limiti di velocità nella lettura dei dati da nastro magnetico.

La migrazione dell'archivio dei dati nel cloud può non solo eliminare la necessità di gestire e archiviare on-premise i supporti di archiviazione, ma può anche rendere i tuoi dati molto più accessibili e disponibili per la ricerca rispetto ai metodi di archiviazione tradizionali.

Una pipeline di archiviazione di base potrebbe assomigliare al diagramma seguente, utilizzando diversi servizi cloud per esaminare, classificare, taggare e organizzare gli archivi. Dal cloud puoi creare uno strumento di gestione e recupero degli archivi per cercare i dati utilizzando vari criteri di metadati, come data, progetto, formato o risoluzione. Puoi anche utilizzare le API Machine Learning per codificare e classificare immagini e video, archiviando i risultati in un database basato su cloud come BigQuery.

Una pipeline di archiviazione asset che include il machine learning per classificare i contenuti
Una pipeline di archiviazione degli asset che include machine learning per classificare i contenuti

Altri argomenti da considerare:

  • Automatizza la generazione di miniature o proxy per i contenuti che si trovano all'interno di classi di archiviazione di Cloud Storage con tariffe per il recupero. Utilizza questi proxy nel sistema di gestione degli asset multimediali in modo che gli utenti possano sfogliare i dati durante la lettura solo dei proxy, non degli asset archiviati.
  • Considera l'utilizzo del machine learning per classificare i contenuti live action. Utilizza Cloud Vision per etichettare texture e piastre di sfondo oppure l'API Video Intelligence per la ricerca e il recupero dei filmati di riferimento.
  • Puoi anche utilizzare l'immagine AutoML di Vertex AI per creare un modello di immagine personalizzato per riconoscere qualsiasi asset, in live streaming o sottoposto a rendering.
  • Per i contenuti visualizzati, potresti salvare una copia dell'immagine disco del worker di rendering insieme all'asset sottoposto a rendering. Se devi ricreare la configurazione, avrai a disposizione le versioni software, plug-in, librerie del sistema operativo e dipendenze corrette, se vuoi eseguire nuovamente il rendering di uno screenshot archiviato.

Gestione degli asset e produzione

Lavorare sullo stesso progetto in più strutture può presentare sfide uniche, soprattutto quando i contenuti e le risorse devono essere disponibili in tutto il mondo. La sincronizzazione manuale dei dati sulle reti private può essere costosa e ad alta intensità di risorse ed è soggetta a limitazioni della larghezza di banda locale.

Se il carico di lavoro richiede dati disponibili a livello globale, potresti essere in grado di utilizzare Cloud Storage, accessibile da qualsiasi luogo in cui tu possa accedere ai servizi Google. Per incorporare Cloud Storage nella tua pipeline, devi modificare la pipeline per comprendere i percorsi degli oggetti, quindi puoi eseguire il pull dei dati o eseguirne il push ai worker di rendering prima di eseguire il rendering. L'utilizzo di questo metodo fornisce l'accesso globale ai dati pubblicati, ma richiede che la tua pipeline fornisca gli asset nei punti in cui è necessario in un tempo ragionevole.

Ad esempio, un artista di texture a Los Angeles può pubblicare file immagine che devono essere utilizzati da un artista di illuminazione a Londra. La procedura ha il seguente aspetto:

Pubblicazione di asset in Cloud Storage
Pubblicazione di asset in Cloud Storage
  1. La pipeline di pubblicazione esegue il push dei file a Cloud Storage e aggiunge una voce a un database di asset basato su cloud.
  2. Un artista di Londra esegue un copione per raccogliere gli asset relativi a una scena. Viene eseguita una query sulle posizioni dei file dal database e vengono lette da Cloud Storage sul disco locale.
  3. Il software di gestione delle code raccoglie un elenco degli asset necessari per il rendering, li esegue query nel database degli asset e li scarica da Cloud Storage nella memoria locale di ogni worker di rendering.

L'uso di Cloud Storage in questo modo ti fornisce anche un archivio di tutti i tuoi dati pubblicati sul cloud se scegli di utilizzare Cloud Storage come parte della tua pipeline di archiviazione.

Gestione dei database

Il software di gestione di asset e produzione dipende da database durevoli e a disponibilità elevata, pubblicati su host in grado di gestire centinaia o migliaia di query al secondo. I database sono generalmente ospitati su un server on-premise che viene eseguito nello stesso rack dei worker di rendering e sono soggetti alle stesse limitazioni di alimentazione, rete e climatizzazione.

Puoi prendere in considerazione l'esecuzione dei database di produzione MySQL, NoSQL e PostgreSQL come servizi gestiti basati su cloud. Questi servizi sono ad alta disponibilità e accessibili a livello globale, criptano i dati at-rest e in transito e offrono funzionalità di replica integrate.

Gestione delle code

Programmi software di gestione delle code disponibili in commercio, come Qube!, Scadenza e Trattore sono ampiamente utilizzati nel settore VFX/animazione. Sono inoltre disponibili opzioni software open source, come OpenCue. Puoi utilizzare questo software per il deployment e la gestione di qualsiasi carico di lavoro di computing su una varietà di worker, non solo sul rendering. Puoi eseguire il deployment e gestire la pubblicazione di asset, le simulazioni di particelle e fluidi, la preparazione di texture e la composizione con lo stesso framework di pianificazione che utilizzi per gestire i rendering.

Alcune strutture hanno implementato software di pianificazione per uso generico, come HTCondor dall'Università del Wisconsin, Slurm da SchedMD o Univa Grid Engine nelle loro pipeline VFX. Software progettato specificamente per il settore VFX, tuttavia, presta particolare attenzione a funzionalità come le seguenti:

  • Dipendenza basata su job, frame e livelli. Alcune attività devono essere completate prima di poter iniziare altri job. Ad esempio, esegui una simulazione completa prima di eseguire il rendering.
  • Priorità dei job, che consente ai wrangler di rendering di cambiare l'ordine dei job in base a scadenze e programmi personalizzati.
  • Tipi di risorse, etichette o target che puoi utilizzare per abbinare risorse specifiche ai job che ne richiedono. Ad esempio, esegui il deployment del rendering con accelerazione GPU solo sulle VM a cui sono collegate GPU.
  • Acquisire i dati storici sull'utilizzo delle risorse e renderli disponibili tramite un'API o una dashboard per ulteriori analisi. Ad esempio, osserva l'utilizzo medio di CPU e memoria per le ultime iterazioni di un rendering per prevedere l'utilizzo delle risorse per l'iterazione successiva.
  • Lavori prima e dopo il periodo di pubblicazione. Ad esempio, un job pre-flight estrae tutti gli asset necessari sul worker di rendering locale prima del rendering. Un job successivo al periodo di pubblicazione copia il frame sottoposto a rendering risultante in una posizione designata su un file system, quindi contrassegna il frame come completato in un sistema di gestione degli asset.
  • Integrazione con le applicazioni software 2D e 3D più diffuse, come Maya, 3ds Max, Houdini, Cinema 4D o Nuke.

Note di produzione: utilizza il software di gestione delle code per riconoscere un pool di risorse basate su cloud come se fossero lavoratori di rendering on-premise. Questo metodo richiede una supervisione per massimizzare l'utilizzo delle risorse eseguendo tutti i rendering che ogni istanza può gestire, una tecnica nota come bin packing. In genere queste operazioni vengono gestite sia dagli algoritmi che dai wranangler di rendering.

Puoi anche automatizzare la creazione, la gestione e la terminazione delle risorse basate su cloud in modalità on demand. Questo metodo si basa sul gestore di code per eseguire script pre e post-rendering che creano risorse secondo necessità, monitorarle durante il rendering e terminarle al termine delle attività.

Considerazioni sul deployment dei job

Quando implementi una farm di rendering che utilizza spazio di archiviazione on-premise e basato su cloud, ecco alcuni aspetti che il gestore della coda potrebbe dover tenere a mente:

  • Le licenze potrebbero variare tra i deployment cloud e on-premise. Alcune licenze si basano sui nodi, altre sono basate sul processo. Assicurati che il software di gestione delle code esegua il deployment dei job per massimizzare il valore delle licenze.
  • Valuta la possibilità di aggiungere tag o etichette univoci alle risorse basate su cloud per assicurarti che vengano utilizzati solo quando vengono assegnati a tipi di job specifici.
  • Utilizza Cloud Logging per rilevare le istanze inutilizzate o inattive.
  • Quando avvii job dipendenti, considera dove si trovano i dati risultanti e dove devono essere per il passaggio successivo.
  • Se i tuoi spazi dei nomi del percorso sono diversi tra spazio di archiviazione on-premise e basato su cloud, valuta la possibilità di utilizzare percorsi relativi per consentire i rendering indipendenti dalla località. In alternativa, a seconda della piattaforma, puoi creare un meccanismo per scambiare i percorsi al momento del rendering.
  • Alcuni rendering, simulazioni o post-elaborazione si basano sulla generazione di numeri casuali, che possono differire tra i produttori di CPU. Anche le CPU dello stesso produttore ma di generazioni di chip diverse possono produrre risultati diversi. In caso di dubbi, utilizza tipi di CPU identici o simili per tutti i frame di un job.
  • Se utilizzi un'appliance di cache di lettura, valuta la possibilità di eseguire il deployment di un job di prova preliminare per preparare la cache e di assicurarti che tutti gli asset siano disponibili nel cloud prima di eseguire il deployment delle risorse cloud. Questo approccio riduce al minimo il tempo che i lavoratori di rendering sono costretti ad attendere mentre gli asset vengono spostati nel cloud.

Logging e monitoraggio

La registrazione e il monitoraggio dell'utilizzo e delle prestazioni delle risorse sono un aspetto essenziale di qualsiasi farm di rendering. Google Cloud offre una serie di API, strumenti e soluzioni per aiutarti a ottenere insight sull'utilizzo di risorse e servizi.

Il modo più rapido per monitorare l'attività di una VM è visualizzarne l'output della porta seriale. Questo output può essere utile quando un'istanza non risponde tramite i piani di controllo tipici del servizio come il responsabile della gestione della coda di rendering.

Altri modi per raccogliere e monitorare l'utilizzo delle risorse su Google Cloud includono:

  • Utilizza Cloud Logging per acquisire log di utilizzo e di controllo ed esportare i log risultanti in Cloud Storage, BigQuery e altri servizi.
  • Utilizza Cloud Monitoring per installare un agente sulle VM per monitorare le metriche di sistema.
  • Incorpora l'API Cloud Logging negli script delle pipeline per accedere direttamente a Cloud Logging utilizzando le librerie client per i linguaggi di script più diffusi. Per ulteriori informazioni, consulta questa soluzione di pipeline VFX.
  • Utilizza Cloud Monitoring per creare grafici e dashboard personalizzate, in modo da comprendere l'utilizzo delle risorse.

Configurazione delle istanze worker di rendering

Affinché il tuo carico di lavoro sia veramente ibrido, i nodi di rendering on-premise devono essere identici ai nodi di rendering basati su cloud, con versioni del sistema operativo corrispondenti, build del kernel, librerie installate e software. Potresti anche dover riprodurre i punti di montaggio, gli spazi dei nomi dei percorsi e persino gli ambienti utente sul cloud, perché sono on-premise.

Scegliere un'immagine disco

Puoi scegliere tra una immagini pubbliche o creare una tua immagine personalizzata basata sull'immagine del nodo di rendering on-premise. Le immagini pubbliche includono una raccolta di pacchetti che configurano e gestiscono account utente e abilitano l'autenticazione basata su chiave Secure Shell (SSH).

Creazione di un'immagine personalizzata

Se scegli di creare un'immagine personalizzata, dovrai aggiungere altre librerie sia a Linux che a Windows perché funzionino correttamente nell'ambiente di Compute Engine.

L'immagine personalizzata deve essere conforme alle best practice per la sicurezza. Se usi Linux, installa l'ambiente guest Linux per Compute Engine per accedere alla funzionalità fornita dalle immagini pubbliche per impostazione predefinita. Installando l'ambiente guest puoi eseguire attività come l'accesso ai metadati, la configurazione del sistema e ottimizzare il sistema operativo per l'utilizzo su Google Cloud, utilizzando gli stessi controlli di sicurezza nell'immagine personalizzata che usi sulle immagini pubbliche.

Note di produzione: gestisci le tue immagini personalizzate in un progetto separato a livello di organizzazione. Questo approccio ti offre un controllo più preciso sulla creazione o sulla modifica delle immagini e ti consente di applicare le versioni, che possono essere utili quando si utilizzano versioni software o sistema operativo diverse in più produzioni.

Automazione della creazione di immagini e del deployment delle istanze

Puoi utilizzare strumenti come Packer per rendere le immagini più riproducibili, verificabili, configurabili e affidabili disponibili. Puoi anche utilizzare uno strumento come Ansible per configurare i nodi di rendering in esecuzione e esercitare un controllo granulare sulla configurazione e sul ciclo di vita.

Per ulteriori informazioni su come automatizzare la creazione delle immagini e la configurazione delle istanze, consulta la pagina Automatizzare le build delle immagini con Jenkins, Packer e Kubernetes.

Scelta di un tipo di macchina

In Google Cloud, puoi scegliere uno dei tipi di macchine predefinite o specificare un tipo di macchina personalizzata. I tipi di macchina personalizzata consentono di controllare le risorse in modo da poter personalizzare le istanze in base ai tipi di job in esecuzione su Google Cloud. Durante la creazione di un'istanza, puoi aggiungere GPU e specificare il numero di CPU, la piattaforma CPU, la quantità di RAM e il tipo e le dimensioni dei dischi.

Note di produzione: per le pipeline che eseguono il deployment di un'istanza per frame, valuta la possibilità di personalizzare l'istanza in base alle statistiche storiche del job, come il carico della CPU o l'utilizzo della memoria, per ottimizzare l'utilizzo delle risorse in tutti i frame di uno scatto. Ad esempio, potresti scegliere di eseguire il deployment di macchine con un numero di CPU più elevato per i frame che contengono un'elevata sfocatura del movimento, per aiutare a normalizzare i tempi di rendering su tutti i frame.

Scelta tra VM standard e prerilasciabili

Le VM prerilasciabili si riferiscono alla capacità in eccesso di Compute Engine venduta a un prezzo molto inferiore rispetto alle VM standard. Compute Engine può terminare o prerilasciare queste istanze se altre attività richiedono l'accesso a tale capacità. Le VM sono ideali per il rendering di carichi di lavoro a tolleranza di errore e gestiti da un sistema di coda che tiene traccia dei job persi per un prerilascio.

Le VM standard possono essere eseguite a tempo indeterminato e sono ideali per server di licenze o host di amministrazione della coda che devono essere eseguiti in modo permanente.

Le VM prerilasciabili vengono terminate automaticamente dopo 24 ore, quindi non utilizzarle per eseguire rendering o simulazioni che durano di più.

I tassi di prerilascio vanno dal 5% al 15%, il che per i carichi di lavoro di rendering tipici è probabilmente tollerabile dato il costo ridotto. Alcune best practice prerilasciabili sono utili per decidere il modo migliore per integrare le PVM nella pipeline di rendering. Se l'istanza viene prerilasciata, Compute Engine invia un indicatore di prerilascio all'istanza, che puoi utilizzare per attivare lo scheduler per terminare il job attuale e la coda.

VM standard VM prerilasciabile
Può essere utilizzato per job a lunga esecuzione.

Ideale per lavori ad alta priorità con scadenze difficili.

Può essere eseguito a tempo indeterminato, quindi è l'ideale per i server delle licenze o per l'hosting degli amministratori della coda.
Terminata automaticamente dopo 24 ore.

Richiede un sistema di gestione delle code per gestire le istanze prerilasciate.

Note di produzione: alcuni renderer possono eseguire uno snapshot di un rendering in corso a intervalli specificati, quindi se la VM viene prerilasciata, puoi mettere in pausa e riprendere il rendering senza dover riavviare un frame da zero. Se il renderer supporta lo snapshot e scegli di utilizzare le PVM, abilita lo snapshot del rendering nella pipeline per evitare di perdere il lavoro. Durante la scrittura e l'aggiornamento delle istantanee, i dati possono essere scritti in Cloud Storage e, se il worker di rendering viene prerilasciato, viene recuperato quando viene eseguito il deployment di una nuova PVM. Per evitare costi di archiviazione, elimina i dati degli snapshot per i rendering completati.

Concessione dell'accesso ai worker di rendering

IAM ti aiuta ad assegnare l'accesso alle risorse cloud alle persone che ne hanno bisogno. Per i worker di rendering di Linux, puoi utilizzare il servizio OS Login per limitare ulteriormente l'accesso all'interno di una sessione SSH. In questo modo, puoi controllare chi è un amministratore.

Controllare i costi di una farm di rendering ibrida

Nella stima dei costi, devi prendere in considerazione molti fattori, ma ti consigliamo di implementare queste best practice comuni come criteri per la tua farm di rendering ibrida:

  • Utilizza le istanze prerilasciabili per impostazione predefinita. A meno che il tuo job di rendering non sia a lunga esecuzione, quattro o più ore per frame o hai una scadenza fissa per fornire uno scatto, utilizza VM prerilasciabili.
  • Riduci al minimo il traffico in uscita. Copia solo i dati necessari per l'archiviazione on-premise. Nella maggior parte dei casi, questi dati sono i frame con rendering finale, ma possono anche essere dati separati di pass o simulazione. Se stai montando direttamente il tuo NAS on-premise o utilizzando un prodotto di archiviazione che si sincronizza automaticamente, scrivi tutti i dati sottoposti a rendering nel file system locale del worker di rendering, quindi copia ciò che ti serve nello spazio di archiviazione on-premise per evitare il traffico in uscita di dati temporanei e non necessari.
  • VM di dimensioni corrette. Assicurati di creare i worker di rendering con un utilizzo ottimale delle risorse, assegnando solo il numero di vCPU, la quantità ottimale di RAM e il numero corretto di GPU, se presenti. Inoltre, valuta come ridurre al minimo le dimensioni di tutti i dischi collegati.
  • Prendi in considerazione il minimo di un minuto. Su Google Cloud, le istanze vengono fatturate al secondo con un minimo di un minuto. Se il carico di lavoro include frame di rendering che richiedono meno di un minuto, valuta la possibilità di suddividere le attività insieme per evitare il deployment di un'istanza per meno di un minuto di tempo di calcolo.
  • Conserva set di dati di grandi dimensioni sul cloud. Se utilizzi la tua farm di rendering per generare enormi quantità di dati, ad esempio EXR approfonditi o dati di simulazione, valuta l'utilizzo di una workstation basata su cloud più in basso nella pipeline. Ad esempio, un artista di FX potrebbe eseguire una simulazione fluida sul cloud, scrivendo file cache nello spazio di archiviazione basato su cloud. Un artista potrebbe quindi accedere ai dati di simulazione da una workstation virtuale su Google Cloud. Per ulteriori informazioni sulle workstation virtuali, contatta il tuo rappresentante GCP.
  • Sfrutta gli sconti per impegno di utilizzo e di utilizzo sostenuto. Se esegui un pool di risorse, gli sconti per utilizzo sostenuto possono farti risparmiare fino al 30% sul costo delle istanze eseguite per un mese intero. Gli sconti per impegno di utilizzo possono anche avere senso in alcuni casi.

Confronto dei costi delle farm di rendering on-premise e basate su cloud

Confronta i costi di creazione e gestione di una farm di rendering on-premise rispetto alla creazione di una farm di rendering basata su cloud. Il seguente esempio di ripartizione dei costi confronta i due scenari (tutti i costi in USD).

Costi farm di rendering on-premise Costi di farm di rendering basati su cloud
Costi di build iniziali
Prezzo per nodo: 3800 $
Numero di nodi: 100
Hardware di rete, build in camera bianca: 100.000 $
Hardware di archiviazione: 127.000 $
Collegamento iniziale di aziende di pubblici servizi: 20.000 $
Connettività di provisioning: 2000 $
Costi di build9 totali: 0
Costi di connettività iniziali
Hardware di rete: 10.000 $
Hardware di archiviazione: 127.000 $
Connettività di provisioning: 2000 $
Costi totali di build: 139.000 $
Costi annuali
Contratto di assistenza di rete: 15.000 $
Contratto di assistenza del server: 34.050 $
Costi annuali
Contratto di assistenza di rete: 1500 $
Contratto di assistenza del server: 19.050 €
Costi mensili
Larghezza di banda: 2500 $
Utilità: 8000 $
Costo per piedi quadrati: 40 $
Piq. richiesti: 400
Assistenza/Assistenza IT: 15.000 $
Costi mensili totali: 41.500 $
Costi mensili
Larghezza di banda: 2500 $
2x Dedicated Interconnect: 3600 $
100 GB in uscita: 12 $
Costi mensili totali: 6112 $
Utilizzo della farm di rendering
Percentuale di utilizzo mensile: 50%
Numero di ore di rendering al mese: 36.500
Utilizzo della farm di rendering
Numero di istanze: 100
Tipo di macchina: n1-standard-32, prerilasciabile
Utilizzo mensile percentuale: 50%
Numero di ore di rendering al mese: 36.500
Costo per ora di rendering: 5,62 $ Costo per ora di rendering: 1,46 $

Riepilogo

L'estensione della cloud di rendering esistente nel cloud è un modo conveniente per sfruttare risorse potenti e a basso costo senza spese in conto capitale. Non esistono due pipeline di produzione uguali, quindi nessun documento può coprire ogni argomento e requisito unico. Per assistenza con la migrazione dei carichi di lavoro di rendering nel cloud, contatta il tuo rappresentante GCP.

Letture aggiuntive

Altre soluzioni applicabili, alcune delle quali sono state menzionate in questo articolo, sono disponibili su cloud.google.com.

Esplora architetture di riferimento, diagrammi, tutorial e best practice su Google Cloud. Consulta il nostro Centro di architettura cloud.