Crea una farm di rendering ibrida

Questo documento fornisce indicazioni su come estendere il rendering on-premise esistente per utilizzare le risorse di calcolo su Google Cloud. Il documento presuppone che tu abbia già implementato una farm di rendering on-premise e che tu conosca i concetti di base degli effetti visivi (VFX), delle pipeline di animazione, del software di gestione delle code e dei metodi più comuni per le licenze software.

Panoramica

Il rendering di elementi 2D o 3D per animazioni, film, spot pubblicitari o videogiochi richiede molto tempo e risorse di calcolo. Il rendering di questi elementi richiede un investimento considerevole in hardware e infrastruttura e un team dedicato di professionisti IT per il deployment e la manutenzione di hardware e software.

Quando una farm di rendering on-premise raggiunge l'utilizzo del 100%, la gestione dei job può diventare una sfida. Priorità e dipendenze delle attività, riavvio dei frame interrotti e carico di rete, disco e CPU diventano parte di una complessa equazione che devi monitorare e controllare attentamente, spesso in tempi ristretti.

Per gestire questi job, le strutture VFX hanno incorporato un software di gestione delle code nelle loro pipeline. Il software di gestione delle code può:

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

Sebbene alcuni software di gestione delle code possano eseguire il deployment di job per i lavoratori basati su cloud, sei comunque responsabile della connessione al cloud, della sincronizzazione delle risorse, della scelta di un framework di archiviazione, della gestione dei modelli di immagine e della fornitura delle tue licenze software.

Per la creazione e la gestione di pipeline e flussi di lavoro di rendering in un ambiente cloud o cloud ibrido, sono disponibili le seguenti opzioni:

• Se non disponi già di risorse on-premise o cloud, puoi utilizzare un servizio di rendering basato su cloud (Software as a SaaS) come Conductor.
• Se vuoi gestire la tua infrastruttura, puoi creare ed eseguire il deployment delle risorse cloud descritte in questo documento.
• Se vuoi creare un flusso di lavoro personalizzato in base ai tuoi requisiti specifici, puoi collaborare con partner di integrazione di servizi Google Cloud come Gunpowder o AppsBroker. Questa opzione presenta il vantaggio di eseguire tutti i servizi cloud nel tuo ambiente Google Cloud sicuro.

Contatta il tuo rappresentante Google Cloud per determinare la soluzione ideale per la tua struttura.

Nota: le note sulla produzione vengono visualizzate periodicamente in tutto il documento. Queste note offrono best practice da seguire durante la creazione della farm di rendering.

Connessione al cloud

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

Connessione tramite internet

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

Cloud VPN

A prescindere dalla connessione, ti consigliamo di utilizzare una rete privata virtuale (VPN) per proteggerla.

Cloud VPN ti consente di connettere in modo sicuro la tua rete on-premise alla rete Virtual Private Cloud (VPC) di Google 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 configurare il tuo gateway VPN per la connessione diretta con Google, ti consigliamo di utilizzare Cloud VPN, che offre maggiore flessibilità e una migliore integrazione con Google Cloud.

Cloud Interconnect

Google supporta vari 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 minore rispetto alle connessioni internet standard, oltre a prezzi del traffico in uscita ridotti.

Cross-Cloud Interconnect ti consente di stabilire una connettività dedicata a Google Cloud a larghezza di banda elevata per i tuoi dati in un altro cloud. In questo modo si riducono la complessità della rete, i costi di trasferimento di dati e la velocità effettiva.

Dedicated Interconnect

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

• Una o più connessioni Ethernet da 10 Gbps, con un massimo di otto connessioni o 80 Gbps totali per interconnessione.
• Una o più connessioni Ethernet da 100 Gbps, con un massimo di due connessioni o 200 Gbps totali per interconnessione.

Il traffico di Dedicated Interconnect non è criptato. Se hai bisogno di trasmettere dati su Dedicated Interconnect in modo sicuro, devi stabilire una tua connessione VPN. Cloud VPN non è compatibile con Dedicated Interconnect, quindi in questo caso devi fornire la tua VPN.

Partner Interconnect

Partner Interconnect fornisce connettività tra la tua rete on-premise e la tua 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

Nella tua località specifica potrebbero essere disponibili altri modi per connetterti a Google. Per assistenza nel determinare il modo migliore e più conveniente per connettersi a Google Cloud, contatta il tuo rappresentante Google Cloud.

Protezione dei contenuti

Per pubblicare i propri contenuti su qualsiasi piattaforma cloud pubblico, i proprietari dei contenuti come i principali studi di Hollywood richiedono ai fornitori di rispettare le best practice di sicurezza definite sia internamente che da organizzazioni come l'MPAA. Google Cloud offre modelli di sicurezza Zero Trust integrati in prodotti come Google Workspace, Chrome Enterprise Premium e BeyondProd.

Ogni studio ha requisiti diversi per la sicurezza dei carichi di lavoro di rendering. Puoi trovare i white paper sulla sicurezza e la documentazione sulla conformità all'indirizzo cloud.google.com/security.

In caso di domande sul processo di controllo della conformità della sicurezza, contatta il tuo rappresentante Google Cloud.

Organizzazione dei progetti

I progetti sono un componente organizzativo fondamentale di Google Cloud. Nella tua struttura, puoi organizzare i lavori all'interno di un progetto specifico o suddividerli in più progetti. Ad esempio, potresti voler creare progetti distinti per le fasi di previsualizzazione, ricerca e sviluppo e produzione di un film.

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

Note sulla produzione: crea un progetto host del VPC condiviso che contiene le risorse con tutti i tuoi strumenti di produzione. Puoi designare tutti i progetti creati nella tua organizzazione come Progetti di servizio VPC condivisi. Questa designazione indica 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, già esistente. La migrazione di tutti i progetti in un'organizzazione offre una serie di vantaggi.

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

Definizione dell'accesso alle risorse

I progetti richiedono l'accesso sicuro alle risorse insieme a limitazioni 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'accesso definendo i ruoli con quali livelli di accesso a determinate risorse.

Note sulla produzione: per limitare l'accesso degli utenti solo alle risorse necessarie per eseguire attività specifiche in base al loro ruolo, implementa il principio del privilegio minimo sia on-premise che nel cloud.

Prendi ad esempio un lavoratore di rendering, ovvero una macchina virtuale (VM) di cui puoi eseguire il deployment da un modello di istanza predefinito che utilizza la tua 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, come un filer cloud o un disco permanente. Tuttavia, non è necessario aggiungere singoli artisti ai progetti Google Cloud perché non hanno bisogno dell'accesso diretto alle risorse cloud.

Puoi assegnare ruoli per eseguire il rendering di wrangler o amministratori di progetto che hanno accesso a tutte le risorse di Compute Engine. In questo modo possono eseguire funzioni su risorse inaccessibili ad altri utenti.

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

Attività di produzione	Nome ruolo	Tipo di risorsa
Responsabile dello studio cinematografico	resourcemanager.organizationAdmin	Organizzazione Progetto
Responsabile di produzione	owner, editor	Progetto
Rendering Wrangler	compute.admin, iam.serviceAccountActor	Progetto
Account gestione code	compute.admin, iam.serviceAccountActor	Organizzazione Progetto
Singolo artista	[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 autonomamente un'istanza 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 di progetto di accedere a un'istanza per eliminare un bucket di archiviazione o modificare un'impostazione del firewall.

Note sulla produzione: per impostazione predefinita, le istanze possono leggere ma non scrivere in Cloud Storage. Se la pipeline di rendering scrive i rendering completati in Cloud Storage, aggiungi l'ambito devstorage.read_write all'istanza al momento della creazione.

Scegliere come eseguire il deployment delle risorse

Con il rendering su cloud, puoi utilizzare le risorse solo quando necessario, ma puoi scegliere tra vari modi per rendere disponibili le risorse alla 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 crearne una per frame.

Il tuo sistema di gestione delle code può monitorare le istanze in esecuzione, che possono essere aggiunte alla coda se una VM viene prerilasciata e terminata quando vengono completate singole attività.

esegui il deployment di un pool di risorse

Puoi anche scegliere di eseguire il deployment di un gruppo di istanze, non correlato a un job specifico, a cui il sistema di gestione delle code on-premise può accedere come risorse aggiuntive. Se utilizzi le VM spot di Google Cloud, 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 compilata con i job.

Concessione in licenza del software

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

Scheme	Descrizione	Suggerimento
Nodo bloccato	Autorizzato a un indirizzo MAC, un indirizzo IP o un ID CPU specifico. Può essere eseguito da un unico processo.	Basato sull'istanza
Basato su nodo	Autorizzato a un nodo specifico (istanza). Su un nodo con licenza può essere eseguito un numero arbitrario di utenti o processi.	Basato sull'istanza
Floating	Effettuato il pagamento da un server di licenze che tiene traccia dell'utilizzo.	Server licenze
Licenze software
Interattivo	Consente all'utente di eseguire il software in modo interattivo in un ambiente basato sulla grafica.	Server licenza o basato su istanza
Batch	Consente all'utente di eseguire il software solo in un ambiente a riga di comando.	Server licenze
Licenze basate su cloud
Basato su utilizzo	Verificato solo quando un processo viene eseguito su un'istanza cloud. Al termine o al termine del processo, la licenza viene rilasciata.	Server licenze basato su cloud
In base al tempo di attività	Verificato 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 su istanze

Alcuni programmi software o plug-in sono concessi in licenza direttamente all'hardware su cui vengono eseguiti. Questo approccio alle licenze può rappresentare un problema nel cloud, dove 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 arrestare o riavviare un'istanza e l'indirizzo MAC verrà conservato. Puoi utilizzare questo indirizzo MAC per la creazione e la convalida della licenza fino a quando l'istanza non viene eliminata.

Assegna un indirizzo IP statico

Quando crei un'istanza, le viene assegnato un indirizzo IP interno e, facoltativamente, esterno. Per conservare l'indirizzo IP esterno di un'istanza, puoi prenotare un indirizzo IP statico e assegnarlo all'istanza. Questo indirizzo IP verrà riservato solo per questa istanza. Poiché gli indirizzi IP statici sono una risorsa basata su progetto, sono soggetti a quote per regione.

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

Dongle hardware

Il software meno recente potrebbe ancora essere concesso in licenza tramite una chiavetta, ovvero una chiave hardware programmata con una licenza per il prodotto. La maggior parte delle aziende di software ha smesso di utilizzare dongle hardware, ma alcuni utenti potrebbero avere software legacy associato a uno di questi dispositivi. Se riscontri questo problema, contatta il produttore del software per sapere se può fornirti una licenza aggiornata per il tuo software specifico.

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

Utilizzo di un server di licenze

La maggior parte dei software moderni offre un'opzione di licenza mobile. Questa opzione è più sensata in un ambiente cloud, ma richiede una gestione delle licenze e controllo dell'accesso più efficaci per evitare il consumo eccessivo di licenze.

Per evitare di superare la capacità della licenza, nell'ambito dell'elaborazione della coda dei job puoi scegliere quali licenze utilizzare e controllare il numero di job che utilizzano le licenze.

Server di licenze on-premise

Puoi utilizzare il server di 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 che gestisce le istanze nel tuo progetto o anche tra progetti utilizzando VPC condiviso. Le licenze mobili a volte sono collegate a un indirizzo MAC hardware, pertanto una piccola istanza di lunga esecuzione con un indirizzo IP statico può gestire facilmente le licenze per molte istanze di rendering.

Server ibrido delle licenze

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 e, se non ne è disponibile, utilizzare un server licenze basato su cloud. Questa strategia può aiutarti a massimizzare l'uso delle licenze permanenti prima di dare un'occhiata agli altri tipi di licenze.

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

export [email protected];[email protected]

Nell'esempio precedente, il renderer Arnold tenta di ottenere una licenza dal server alla porta x.x.0.1, porta 5053. Se questo tentativo non va a buon fine, proverà a 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 vengono generalmente fatturate in due modi: in base all'utilizzo e in base all'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 licenza, la licenza viene ritirata da un server basato su cloud all'avvio della procedura e viene rilasciata al completamento della procedura. Finché una licenza viene pagata, ti viene addebitato il relativo utilizzo. Questo tipo di licenza viene generalmente utilizzato per il rendering del software.

Licenze basate sull'uptime

Le licenze basate su uptime o a consumo vengono fatturate in base all'uptime dell'istanza di Compute Engine. L'istanza è configurata in modo da essere registrata con il server di licenze basato su cloud durante il processo di avvio. Finché l'istanza è in esecuzione, la licenza viene verificata. Quando l'istanza viene arrestata o eliminata, la licenza viene rilasciata. Questo tipo di licenza viene generalmente utilizzato per i worker di rendering distribuiti da un gestore di code.

Scelta della modalità di archiviazione dei dati

Il tipo di archiviazione che scegli su Google Cloud dipende dalla strategia di archiviazione scelta, oltre che da fattori come costi e requisiti di durabilità.

Disco permanente

Potresti riuscire a evitare del tutto l'implementazione di un file server incorporando dischi permanenti (DP) nel carico di lavoro. I DP sono un tipo di archiviazione a blocchi conforme a POSIX, con dimensioni fino a 64 TB, familiare alla maggior parte delle strutture VFX. I dischi permanenti sono disponibili sia come unità standard sia come unità a stato solido (SSD). Puoi collegare un DP in modalità di lettura e scrittura a una singola istanza o in modalità di sola lettura a un numero elevato di istanze, ad esempio un gruppo di worker di rendering.

Vantaggi	Svantaggi	Caso d'uso ideale
Si monta come volume NFS o SMB standard. Consente di ridimensionare in modo dinamico. Puoi collegare fino a 128 DP a una singola istanza. 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. È accessibile solo alle risorse che si trovano nella stessa regione.	Pipeline avanzate che possono creare un nuovo disco per singolo job. Pipeline che pubblicano dati aggiornati non di frequente, 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, non è strutturato e ha una capacità 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 (OS). Se decidi di incorporare l'archiviazione degli oggetti nella pipeline di rendering, devi modificare il modo in cui leggi e scrivi i dati, utilizzando le utilità a riga di comando come gsutil o l'API Cloud Storage.

Vantaggi	Svantaggi	Caso d'uso ideale
Spazio di archiviazione durevole e ad alta disponibilità per file di tutte le dimensioni. Un'unica API per tutte le classi di archiviazione. Poco costoso. I dati sono disponibili in tutto il mondo. Capacità praticamente illimitata.	Non è conforme a POSIX. Deve accedere tramite API o utilità a riga di comando. In una pipeline di rendering, i dati devono essere trasferiti localmente prima dell'uso.	Esegui il rendering delle pipeline con un sistema di gestione degli asset in grado di 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 del rendering.

Altri prodotti di archiviazione

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

Prodotto	Vantaggi	Svantaggi	Caso d'uso ideale
Filestore	File system in cluster in grado di supportare migliaia di connessioni NFS simultanee. In grado di sincronizzarsi con il cluster NAS on-premise.	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	File system con scale out in grado di supportare migliaia di client NFS o POSIX simultanei. I dati possono essere memorizzati nella cache on demand da un NAS on-premise, con gli aggiornamenti inviati automaticamente allo spazio di archiviazione on-premise.	Costo: assistenza di terze parti da parte di Pixit.	Strutture VFX di medie e grandi dimensioni con centinaia di TB di dati da presentare sul cloud.
Google Cloud NetApp Volumes	Soluzione di archiviazione completamente gestita su Google Cloud. Supporta gli ambienti NFS, SMB e multiprotocollo. Snapshot point-in-time con il recupero delle istanze	Non disponibile in tutte le regioni Google Cloud.	Strutture VFX con una pipeline in grado di sincronizzare gli asset. Disco condiviso tra workstation virtuali.
FUSE di Cloud Storage	Monta i bucket Cloud Storage come file system. A basso costo.	Non un file system conforme a POSIX. Può essere difficile da configurare e ottimizzare.	Strutture VFX in grado di eseguire il deployment, la configurazione e la gestione di un file system open source, con una pipeline in grado di sincronizzare gli asset.

In Google Cloud sono disponibili altri tipi di archiviazione. Per saperne di più, contatta il tuo rappresentante Google Cloud.

Ulteriori informazioni sulle opzioni di archiviazione dei dati

• Opzioni di archiviazione disponibili su Google Cloud
• Archiviazione di file su Compute Engine
• Progetta una strategia di archiviazione ottimale per il tuo carico di lavoro cloud

Implementazione delle strategie di archiviazione

Puoi implementare una serie di strategie di archiviazione nelle pipeline di produzione di VFX o di animazione stabilindo convenzioni che determinano come gestire i dati, se accedi ai dati direttamente dall'archiviazione on-premise o esegui la sincronizzazione tra l'archiviazione on-premise e il cloud.

Strategia 1: montare direttamente l'archiviazione on-premise

Se la tua struttura dispone di 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 NAS on-premise direttamente sui worker di rendering cloud. Sebbene questa strategia sia semplice, può anche richiedere costi e larghezza di banda elevata, poiché tutto ciò che crei sul cloud e riscrivi nello spazio di archiviazione viene conteggiato come dati in uscita.

Vantaggi	Svantaggi	Caso d'uso ideale
Implementazione semplice. Lettura/scrittura nello spazio di archiviazione comune. Disponibilità immediata dei dati, senza necessità di memorizzazione nella cache o sincronizzazione.	Può essere più costoso di altre opzioni. Per ottenere una bassa latenza, è necessaria la vicinanza a un data center di Google. Il numero massimo di istanze che puoi connettere alla tua rete NAS on-premise dipende dalla larghezza di banda e dal tipo di connessione.	Strutture vicino a un data center Google che devono eseguire il bursting dei carichi di lavoro nel cloud, dove i costi non sono un problema. Strutture con connettività a Google Cloud di almeno 10 Gbps.

Strategia 2: sincronizzazione on demand

Puoi scegliere di push dei dati al cloud o di push dei dati dallo spazio di archiviazione on-premise o viceversa solo quando i dati sono necessari, ad esempio quando viene eseguito il rendering di un frame o un asset viene pubblicato. Se utilizzi questa strategia, la sincronizzazione può essere attivata da un meccanismo nella pipeline, ad esempio uno script watch, 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 serie di comandi, come il comando gcloud scp, il comando gsutil rsync o i protocolli di trasferimento di dati 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, consulta la documentazione di terze parti per informazioni sul modello di sicurezza e sulle best practice corrispondenti. Google non gestisce questi servizi di terze parti.

Metodo push

In genere, utilizzi il metodo push 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 inviati allo spazio di archiviazione on-premise.
• Un artista pubblica una risorsa. Parte del processo di pubblicazione degli asset prevede il push dei dati associati in un percorso predefinito in Cloud Storage.

Metodo pull

Puoi utilizzare il metodo pull quando viene richiesto un file, in genere da un'istanza di rendering basato su cloud.

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

Vantaggi	Svantaggi	Caso d'uso ideale
Controllo completo su quali dati vengono sincronizzati e 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. Potrebbero essere necessarie risorse aggiuntive per gestire la coda di sincronizzazione.	Strutture da piccole e grandi che hanno pipeline personalizzate e vogliono il controllo completo sulla sincronizzazione degli asset.

Note sulla 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

Google Cloud ha esteso e sviluppato una soluzione di memorizzazione nella cache KNFSD come opzione open source. La soluzione è in grado di gestire richieste di prestazioni della farm che superano le capacità dell'infrastruttura di archiviazione. La memorizzazione nella cache di KNFSD offre una memorizzazione nella cache di lettura ad alte prestazioni, che consente di scalare i carichi di lavoro fino a centinaia o persino migliaia di nodi di rendering in più regioni e pool di archiviazione ibridi.

La memorizzazione nella cache di KNFSD è una soluzione a scale out che riduce il carico sul servizio principale di condivisione file. La memorizzazione nella cache di KNFSD riduce anche l'effetto di sovraccarico quando molti nodi di rendering tentano di recuperare contemporaneamente i file dal file server. Utilizzando un livello di memorizzazione nella cache sulla stessa rete VPC dei nodi di rendering, viene ridotta la latenza di lettura, il che consente di avviare e completare più velocemente i job. A seconda di come hai configurato il file server di memorizzazione nella cache, i dati rimangono nella cache fino a quando:

• I dati scadono o rimangono invariati per un determinato periodo di tempo.
• È necessario spazio sul file server, momento nel quale i dati vengono rimossi dalla cache in base all'età.

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

In alcuni casi, potrebbe essere necessario preparare la cache per assicurarti che tutti i dati relativi al job siano presenti prima del rendering. Per preriscaldare la cache, leggi il contenuto di una directory che si trova sul tuo file server cloud eseguendo un comando read o stat di 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 in grado di ridurre ulteriormente la latenza tra l'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. È possibile fare lo scale up o lo scale down dei file system cloud in cluster a seconda dei requisiti del job.	Può comportare costi aggiuntivi. Le attività pre-job devono essere implementate se scegli di pre-riscaldare la cache.	Strutture di grandi dimensioni che eseguono il deployment di molte istanze simultanee e leggono asset comuni in molti job.

Filtrare i dati

Puoi creare un database dei tipi di asset e delle condizioni associate per definire se sincronizzare un determinato tipo di dati. Potresti non voler mai sincronizzare alcuni tipi di dati, ad esempio i dati temporanei generati durante un processo di conversione, i file della cache o i dati di simulazione. Valuta inoltre se sincronizzare asset non approvati, dato che non tutte le iterazioni verranno utilizzate nei rendering finali.

Esecuzione di un trasferimento collettivo iniziale

Quando implementi la tua farm di rendering ibrida, potrebbe essere opportuno eseguire un trasferimento iniziale dell'intero set di dati o di una sua parte su Cloud Storage, disco permanente o altro spazio di archiviazione basato su cloud. A seconda di fattori quali la quantità e il tipo di dati da trasferire e la velocità di connessione, potresti essere in grado di eseguire una sincronizzazione completa nell'arco di alcuni giorni o settimane. La figura seguente mette a confronto i tempi tipici per i trasferimenti online e fisici.

Se il carico di lavoro per il trasferimento supera i limiti 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 archiviazione dei dati e ripristino di emergenza. La prima è una copia selettiva del lavoro finito, mentre la seconda è uno stato di dati recuperabile. Vuoi progettare un piano di ripristino di emergenza adatto alle esigenze della tua struttura e fornire un piano di emergenza fuori sede. Contatta il tuo fornitore di spazio di archiviazione on-premise per ricevere assistenza su un piano di ripristino di emergenza adatto alla tua piattaforma di archiviazione specifica.

Archiviazione dei dati nel cloud

Una volta completato un progetto, è pratica comune salvare il lavoro finito su una qualche forma di archiviazione a lungo termine, in genere supporti a nastro magnetico come LTO. Queste cartucce sono soggette a requisiti ambientali e, nel tempo, possono essere logisticamente impegnative da gestire. A volte le grandi strutture di produzione ospitano l'intero archivio in una stanza appositamente costruita con un archivista a tempo pieno per tenere traccia dei dati e recuperarli quando richiesto.

La ricerca di specifici asset, scatti o filmati archiviati può richiedere molto tempo, perché i dati potrebbero essere archiviati su più cartucce, l'indicizzazione degli archivi potrebbe essere mancante o incompleta o potrebbero essere presenti limitazioni di velocità per la lettura dei dati su nastro magnetico.

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

Una pipeline di archiviazione di base potrebbe essere simile al seguente diagramma, in cui vengono utilizzati 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 dei metadati, come data, progetto, formato o risoluzione. Puoi anche utilizzare le API Machine Learning per taggare e classificare immagini e video, archiviando i risultati in un database basato su cloud come BigQuery.

Altri argomenti da considerare:

• Automatizza la generazione di miniature o proxy per i contenuti che risiedono all'interno delle classi di archiviazione di Cloud Storage che prevedono tariffe di recupero. Utilizza questi proxy all'interno del tuo sistema di gestione degli asset multimediali, in modo che gli utenti possano sfogliare i dati mentre leggono solo i proxy, non gli asset archiviati.
• Valuta la possibilità di utilizzare il machine learning per categorizzare i contenuti live action. Utilizza Cloud Vision per etichettare texture e piatti di sfondo oppure l'API Video Intelligence per semplificare la ricerca e il recupero di filmati di riferimento.
• Puoi anche utilizzare immagine AutoML di Vertex AI per creare un modello di immagine personalizzato per riconoscere qualsiasi asset, in live action o sottoposto a rendering.
• Per i contenuti visualizzati, valuta la possibilità di salvare una copia dell'immagine del disco del worker di rendering insieme all'asset visualizzato. Se devi ricreare la configurazione, saranno disponibili le versioni software, i plug-in, le librerie del sistema operativo e le dipendenze del sistema operativo corretti nel caso in cui fosse necessario eseguire nuovamente il rendering di una ripresa archiviata.

Gestione degli asset e della produzione

Lavorare allo 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, richiede un uso intensivo delle risorse ed è soggetta a limitazioni della larghezza di banda locali.

Se il tuo carico di lavoro richiede dati disponibili a livello globale, potresti essere in grado di utilizzare Cloud Storage, accessibile ovunque sia possibile accedere ai servizi Google. Per incorporare Cloud Storage nella tua pipeline, devi modificare la pipeline per comprendere i percorsi degli oggetti, quindi eseguire il pull o il push dei dati per i worker di rendering prima del rendering. L'utilizzo di questo metodo fornisce un accesso globale ai dati pubblicati, ma richiede alla pipeline di caricare gli asset dove sono necessari in un periodo di tempo ragionevole.

Ad esempio, un artista di texture di Los Angeles può pubblicare file immagine da utilizzare da un artista di luci a Londra. Il processo è simile al seguente:

1. La pipeline di pubblicazione esegue il push dei file in Cloud Storage e aggiunge una voce a un database di asset basato su cloud.
2. Un artista di Londra realizza un copione per raccogliere risorse per una scena. Le posizioni dei file vengono interrogate dal database e lette da Cloud Storage al disco locale.
3. Il software di gestione delle code raccoglie un elenco di asset necessari per il rendering, li esegue query dal database degli asset e li scarica da Cloud Storage nello spazio di archiviazione locale di ogni worker di rendering.

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

Gestione dei database

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

Valuta la possibilità di eseguire i tuoi 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 sia at-rest che in transito e offrono funzionalità di replica integrate.

Gestione delle code

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

Alcune strutture hanno implementato nelle proprie pipeline VFX un software di pianificazione generico come HTCondor dell'Università del Wisconsin, Slurm di SchedMD o Univa Grid Engine. Il software progettato specificamente per il settore VFX, presta particolare attenzione a funzioni come le seguenti:

• Dipendenza basata su job, frame e livelli. È necessario completare alcune attività prima di poter avviare altri job. Ad esempio, esegui una simulazione fluida completamente prima del rendering.
• Priorità dei job, che consente ai wrangler di modificare l'ordine dei job in base a scadenze e pianificazioni individuali.
• Tipi di risorse, etichette o destinazioni, che puoi utilizzare per associare risorse specifiche ai job che le richiedono. Ad esempio, esegui il deployment di rendering con accelerazione GPU solo su VM con GPU collegate.
• Acquisire dati storici sull'utilizzo delle risorse e renderli disponibili tramite un'API o una dashboard per ulteriori analisi. Ad esempio, guarda l'utilizzo medio di CPU e memoria per le ultime iterazioni di un rendering per prevedere l'utilizzo delle risorse per l'iterazione successiva.
• Job pre e post-volo. Ad esempio, un job pre-flight esegue il pull di tutte le risorse necessarie 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 più diffuse applicazioni software 2D e 3D come Maya, 3ds Max, Houdini, Cinema 4D o Nuke.

Note sulla produzione: utilizza il software di gestione delle code per riconoscere un pool di risorse basate su cloud come se fossero worker on-premise. Questo metodo richiede una supervisione per massimizzare l'utilizzo delle risorse eseguendo il maggior numero di rendering che ogni istanza è in grado di gestire, una tecnica nota come bin packing. Queste operazioni sono generalmente gestite sia in modo algoritmico sia da wrangler di rendering.

Puoi anche automatizzare la creazione, la gestione e la terminazione delle risorse basate su cloud su base on demand. Questo metodo si basa sul gestore code per l'esecuzione di script pre e post-rendering che creano risorse secondo necessità, le monitorano durante il rendering e le terminano quando le attività vengono completate.

Considerazioni sul deployment del job

Quando implementi una farm di rendering che utilizza l'archiviazione sia on-premise che su cloud, ecco alcune considerazioni che il gestore di code potrebbe dover tenere presente:

• L'assegnazione delle licenze potrebbe variare tra i deployment nel cloud e on-premise. Alcune licenze sono basate su nodi, altre si basano su processi. Assicurati che il software di gestione delle code esegua il deployment di job per massimizzare il valore delle tue licenze.
• Valuta la possibilità di aggiungere etichette o tag 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 troveranno i dati risultanti e dove dovranno essere per il passaggio successivo.
• Se gli spazi dei nomi dei percorsi differiscono tra l'archiviazione on-premise e quella basata su cloud, valuta l'utilizzo di percorsi relativi per consentire ai rendering di essere indipendenti dalla località. In alternativa, a seconda della piattaforma, puoi creare un meccanismo per invertire i percorsi al momento del rendering.
• Alcuni rendering, simulazioni o post-processi si basano sulla generazione di numeri casuali, che possono differire tra i produttori della CPU. Anche 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 cache di lettura, valuta la possibilità di eseguire il deployment di un job pre-flight per preparare la cache e assicurarti che tutti gli asset siano disponibili sul cloud prima di eseguire il deployment delle risorse cloud. Questo approccio riduce al minimo il tempo di attesa per i worker forzati mentre gli asset vengono spostati nel cloud.

Logging e monitoraggio

La registrazione e il monitoraggio dell'utilizzo e delle prestazioni delle risorse sono aspetti essenziali di qualsiasi farm di rendering. Google Cloud offre una serie di API, strumenti e soluzioni per fornire informazioni sull'utilizzo delle risorse e dei servizi.

Il modo più rapido per monitorare l'attività di una VM è visualizzare l'output della porta seriale. Questo output può essere utile quando un'istanza non risponde tramite piani di controllo di servizio tipici, come il supervisore della gestione delle code 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 audit log ed esportare i log risultanti in Cloud Storage, BigQuery e altri servizi.
• Utilizza Cloud Monitoring per installare un agente sulle VM per monitorare le metrics di sistema.
• Incorpora l'API Cloud Logging negli script della pipeline per accedere direttamente a Cloud Logging utilizzando librerie client per i linguaggi di scripting più diffusi.
• Utilizza Cloud Monitoring per creare grafici per 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, build del kernel, librerie installate e software corrispondenti. Potrebbe anche essere necessario riprodurre i punti di montaggio, gli spazi dei nomi dei percorsi e persino gli ambienti utente nel cloud, perché sono on-premise.

Scelta di un'immagine disco

Puoi scegliere una delle immagini pubbliche o creare la tua immagine personalizzata basata sull'immagine del nodo di rendering on-premise. Le immagini pubbliche includono una raccolta di pacchetti che configurano e gestiscono gli account utente e abilitano l'autenticazione basata su chiave di 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 affinché 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 per impostazione predefinita dalle immagini pubbliche. Se installi l'ambiente guest, puoi eseguire attività come l'accesso ai metadati, la configurazione del sistema e l'ottimizzazione del sistema operativo per l'utilizzo su Google Cloud, utilizzando gli stessi controlli di sicurezza sull'immagine personalizzata che utilizzi nelle immagini pubbliche.

Note sulla produzione: gestisci le immagini personalizzate in un progetto separato a livello di organizzazione. Questo approccio ti offre un controllo più preciso sul modo in cui vengono create o modificate le immagini e consente di applicare versions, il che può essere utile quando si utilizzano diverse versioni del software o del sistema operativo in più produzioni.

Automatizzare la creazione delle immagini e il deployment delle istanze

Puoi utilizzare strumenti come Packer per rendere la creazione di immagini più riproducibili, controllabili, configurabili e affidabili. Puoi anche utilizzare uno strumento come Ansible per configurare i nodi di rendering in esecuzione e controllare in modo granulare la configurazione e il ciclo di vita.

Scelta di un tipo di macchina

In Google Cloud, puoi scegliere uno dei tipi di macchina predefinita o specificare un tipo di macchina personalizzata. L'uso di tipi di macchine personalizzate ti offre il controllo sulle risorse per personalizzare le istanze in base ai tipi di job eseguiti su Google Cloud. Quando crei un'istanza, puoi aggiungere GPU e specificare il numero di CPU, la piattaforma CPU, la quantità di RAM, il tipo e la dimensione dei dischi.

Note sulla produzione: per le pipeline che eseguono il deployment di un'istanza per frame, valuta la possibilità di personalizzare l'istanza in base a statistiche dei job storiche come il carico della CPU o l'uso della memoria, in modo da ottimizzare l'utilizzo delle risorse in tutti i frame di una ripresa. Ad esempio, potresti scegliere di eseguire il deployment di macchine con un numero di CPU maggiore per i frame che contengono una forte sfocatura del movimento, in modo da normalizzare i tempi di rendering in tutti i frame.

Scelta tra VM standard e prerilasciabili

Le VM prerilasciabili (PVM) fanno riferimento alla capacità di Compute Engine in eccesso, venduta a un prezzo molto più basso rispetto alle VM standard. Compute Engine può terminare o prerilasciare queste istanze se altre attività richiedono l'accesso a questa capacità. Le VM sono ideali per il rendering dei carichi di lavoro a tolleranza di errore e gestiti da un sistema di code che tiene traccia dei job persi a causa del prerilascio.

Le VM standard possono essere eseguite a tempo indeterminato e sono ideali per i server con licenze o gli host amministratore delle code che devono essere eseguiti in modo permanente.

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

Le velocità di prerilascio vanno dal 5% al 15%, probabilmente tollerabile per i tipici carichi di lavoro di rendering dato il costo ridotto. Alcune best practice prerilasciabili sono utili per decidere il modo migliore per integrare le VM nella tua pipeline di rendering. Se l'istanza viene prerilasciata, Compute Engine invia un indicatore di prerilascio all'istanza, che puoi utilizzare per attivare lo scheduler in modo che termini il job attuale e reinserisca.

VM standard	VM prerilasciabile
Può essere utilizzato per job a lunga esecuzione. Ideale per i lavori ad alta priorità con scadenze difficili. Può essere eseguito a tempo indeterminato, ed è quindi l'ideale per i server delle licenze o per l'hosting dell'amministratore di code.	Interruzione automatica dopo 24 ore. Richiede un sistema di gestione delle code per gestire le istanze prerilasciate.

Note sulla produzione: alcuni renderer possono eseguire uno snapshot di un rendering in corso a intervalli specificati. Di conseguenza, se la VM viene prerilasciata, puoi mettere in pausa e riprendere il rendering senza dover riavviare un frame da zero. Se il renderer supporta la creazione di snapshot e scegli di utilizzare le PVM, abilita la creazione di snapshot del rendering nella pipeline per evitare di perdere il lavoro. Durante la scrittura e l'aggiornamento degli snapshot, i dati possono essere scritti in Cloud Storage e, se il worker di rendering viene prerilasciato, possono essere recuperati 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 per eseguire il rendering dei worker

IAM consente di assegnare l'accesso alle risorse cloud alle persone che ne hanno bisogno. Per i worker di rendering Linux, puoi utilizzare OS Login per limitare ulteriormente l'accesso all'interno di una sessione SSH, in modo da poter controllare chi è un amministratore.

Controllo dei costi di una farm di rendering ibrida

Quando stimi i 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. Utilizza le VM prerilasciabili, a meno che il tuo job di rendering non sia a lunga esecuzione, che sia di quattro o più ore per frame o che tu non abbia una scadenza rigida per pubblicare un'inquadratura.
• Riduci al minimo il traffico in uscita. Copia solo i dati di cui hai bisogno nell'archiviazione on-premise. Nella maggior parte dei casi, questi dati saranno i frame visualizzati finali, ma possono anche essere tessere o dati di simulazione separati. Se stai montando direttamente il NAS on-premise o se utilizzi 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ò di cui hai bisogno nello spazio di archiviazione on-premise per evitare l'uscita di dati temporanei e non necessari.
• Dimensioni giuste delle VM. Assicurati di creare i tuoi worker di rendering con un utilizzo ottimale delle risorse, assegnando solo il numero necessario di vCPU, la quantità ottimale di RAM e il numero corretto di GPU, se presenti. Valuta anche come ridurre al minimo le dimensioni di eventuali dischi collegati.
• Considera l'importo minimo di un minuto. Su Google Cloud, le istanze vengono fatturate al secondo con un costo minimo di un minuto. Se il tuo carico di lavoro include frame di rendering che richiedono meno di un minuto, valuta la possibilità di suddividere le attività per evitare il deployment di un'istanza per meno di un minuto di tempo di calcolo.
• Mantieni set di dati di grandi dimensioni nel cloud. Se usi la tua farm di rendering per generare enormi quantità di dati, ad esempio EXR profondi o dati di simulazione, valuta la possibilità di utilizzare una workstation basata su cloud che si trovi in una fase più avanzata della pipeline. Ad esempio, un artista FX potrebbe eseguire una simulazione fluida sul cloud, scrivendo i file della cache in uno spazio di archiviazione basato su cloud. Un artista delle luci potrebbe quindi accedere a questi dati di simulazione da una workstation virtuale su Google Cloud. Per saperne di più sulle workstation virtuali, contatta il tuo rappresentante Google Cloud.
• Approfitta degli sconti per impegno di utilizzo e per impegno 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 intero mese. Anche gli sconti per impegno di utilizzo possono avere senso in alcuni casi.

L'estensione della farm di rendering esistente al cloud è un modo conveniente per utilizzare 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 al cloud dei carichi di lavoro di rendering, contatta il tuo rappresentante Google Cloud.

Passaggi successivi

• Esegui una proof of concept di una farm di rendering ibrida.
• Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Visita il nostro Cloud Architecture Center.