Questo documento fornisce indicazioni su come estendere la farm di rendering on-premise esistente per utilizzare le risorse di calcolo su Google Cloud. Il documento presuppone che tu abbia già implementato una render farm on-premise e abbia familiarità con i concetti di base degli effetti visivi (VFX) e delle pipeline di animazione, del software di gestione delle code e dei metodi di licenza software più comuni.
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 sostanziale in hardware e infrastruttura, insieme a un team IT dedicato per il deployment e la manutenzione di hardware e software.
Quando una farm di rendering on-premise ha un utilizzo al 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 tutti parte della complessa equazione che devi monitorare e controllare attentamente, spesso con scadenze strette.
Per gestire questi job, le strutture VFX hanno incorporato un software di gestione code nelle loro pipeline. Il software di gestione code può:
- Esegui il deployment di job in risorse on-premise e basate su cloud.
- Gestisci le dipendenze tra job.
- Comunicare con i sistemi di gestione delle risorse.
- Fornisci agli utenti un'interfaccia utente e API per i linguaggi più comuni come Python.
Sebbene alcuni software di gestione delle code possano eseguire il deployment dei job ai worker basati su cloud, sei 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 licenze software.
Sono disponibili le seguenti opzioni per creare e gestire pipeline di rendering e flussi di lavoro in un ambiente cloud o cloud ibrido:
- Se non disponi già di risorse on-premise o cloud, puoi utilizzare un servizio di rendering basato su cloud (Software as a Service) (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 ha il vantaggio di eseguire tutti i servizi cloud nel tuo ambiente sicuro di Google Cloud.
Per determinare la soluzione ideale per la tua struttura, contatta il tuo rappresentante Google Cloud.
Nota: le note di produzione vengono visualizzate periodicamente in questo documento. Queste note offrono best practice da seguire durante la creazione della tua farm di rendering.
Connessione al cloud in corso...
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 tramite la rete internet pubblica.
Connessione tramite 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 tutte l'autenticazione, l'autorizzazione e la crittografia sicure per proteggere i dati.
Cloud VPN
A prescindere dalla tua connessione, ti consigliamo di utilizzare una rete privata virtuale (VPN) per proteggere la tua connessione.
Cloud VPN ti consente di connettere in modo sicuro la 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 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 disponibilità maggiore e minore latenza rispetto alle connessioni internet standard, oltre a prezzi per il traffico in uscita ridotti.
Cross-Cloud Interconnect ti consente di stabilire una connettività dedicata a elevata larghezza di banda a Google Cloud per i tuoi dati in un altro cloud. In questo modo si riducono la complessità della rete, i costi del trasferimento di dati e la creazione di farm di rendering multi-cloud ad alta velocità effettiva.
Dedicated Interconnect
Dedicated Interconnect fornisce connessioni fisiche dirette e comunicazioni RFC 1918 tra la rete on-premise e la rete Google. Fornisce capacità di connessione sui 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 in totale per interconnessione.
Il traffico di Dedicated Interconnect non è criptato. Se devi trasmettere dati su Dedicated Interconnect in modo sicuro, devi stabilire una connessione VPN personale. 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à potrebbero essere disponibili altri modi per connetterti a Google. Per assistenza su come determinare il modo migliore e più economico 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 di 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 protezione dei carichi di lavoro di rendering. Puoi trovare i white paper sulla sicurezza e la documentazione sulla conformità all'indirizzo cloud.google.com/security.
Se hai domande sul processo di controllo della conformità di 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 job all'interno di un progetto specifico o suddividerli in più progetti. Ad esempio, potresti voler creare progetti separati per le fasi di previsualizzazione, ricerca e sviluppo e produzione di un film.
I progetti stabiliscono un confine di isolamento sia per i dati di rete sia 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 sulla produzione: crea un progetto host VPC condiviso che contenga 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 significa che qualsiasi progetto nella tua organizzazione può accedere alle stesse librerie, agli stessi script e agli stessi software forniti dal progetto host.
La risorsa Organizzazione
Puoi gestire i progetti all'interno di una risorsa organizzazione, che potresti aver già stabilito. La migrazione di tutti i progetti in un'organizzazione offre una serie di vantaggi.
Note sulla produzione: nomina i responsabili di produzione come proprietari dei loro singoli progetti e la gestione di Studio come proprietari della risorsa Organizzazione.
Definizione dell'accesso alle risorse
I progetti richiedono l'accesso sicuro alle risorse e anche limitazioni relative alla località in cui 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 ruoli e 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.
Ad esempio, prendi in considerazione un render worker, 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, ad esempio un cloud filer 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 progetti che hanno accesso a tutte le risorse Compute Engine, in modo che possano eseguire funzioni su risorse non accessibili ad altri utenti.
Definisci un criterio per determinare quali ruoli possono accedere a determinati tipi di risorse nell'organizzazione. La tabella mostra come le attività di produzione tipiche vengono mappate ai ruoli IAM in Google Cloud.
| Attività di produzione | Nome ruolo | Tipo di risorsa |
|---|---|---|
| Gestore di Studio | resourcemanager.organizationAdmin |
Organizzazione Progetto |
| Direttore di produzione | owner, editor |
Progetto |
| Esegui il rendering di Wrangler | compute.admin, iam.serviceAccountActor |
Progetto |
| Account di gestione 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 personalmente un'istanza o quando il software di gestione 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 di 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 alla tua istanza al momento della creazione.
Scelta della modalità di deployment delle risorse
Con il rendering nel cloud, puoi usare le risorse solo quando necessario, ma puoi scegliere tra diversi modi per rendere le risorse disponibili 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, oppure creare una VM per frame.
Il sistema di gestione delle code può monitorare le istanze in esecuzione, che possono essere rilasciate in coda se una VM viene prerilasciata e terminate quando vengono completate le singole attività.
Esegui 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 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 popolata con job.
Concedere in licenza il software
Le licenze software di terze parti possono variare notevolmente da pacchetto a pacchetto. Di seguito sono riportati alcuni schemi e modelli di licenze 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 | Con licenza per un indirizzo MAC, un indirizzo IP o un ID CPU specifici. Può essere eseguito da un solo processo. | Basato sull'istanza |
| Basato su nodi | Concesso in licenza a un nodo (istanza) specifico. Un numero arbitrario di utenti o processi può essere eseguito su un nodo con licenza. | Basato sull'istanza |
| Floating | Effettuato il pagamento da un server di licenze che tiene traccia dell'utilizzo. | Server licenza |
| Licenze software | ||
| Interattivo | Consente all'utente di eseguire software in modo interattivo in un ambiente basato su grafica. | Basata su server di licenza o basata su istanza |
| Batch | Consente all'utente di eseguire il software solo in un ambiente a riga di comando. | Server licenza |
| Licenze basate su cloud | ||
| Basato su utilizzo | Selezionata solo quando un processo viene eseguito su un'istanza cloud. Al termine o alla fine della procedura, la licenza viene rilasciata. | Server di licenze basato su cloud |
| Basato sull'uptime | Check-out eseguito mentre un'istanza è attiva e in esecuzione. Quando l'istanza viene arrestata o eliminata, la licenza viene rilasciata. | Server di licenze basato su cloud |
Utilizzo delle licenze basate sulle istanze
Alcuni programmi software o plug-in sono concessi in licenza direttamente all'hardware su cui vengono eseguiti. Questo approccio alle licenze può presentare un problema nel cloud, dove gli identificatori hardware, come gli indirizzi MAC o IP, vengono assegnati in modo dinamico.
Indirizzi MAC
Durante la creazione, alle istanze viene assegnato un indirizzo MAC che viene conservato finché l'istanza non viene eliminata. Puoi interrompere o riavviare un'istanza e l'indirizzo MAC verrà mantenuto. Puoi usare l'indirizzo MAC per la creazione e la convalida della licenza, finché 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 regionali.
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.
Chiavette hardware
Il software meno recente potrebbe comunque essere concesso in licenza tramite una chiavetta, una chiave hardware programmata con una licenza di prodotto. La maggior parte delle aziende software ha smesso di utilizzare i dongle hardware, ma alcuni utenti potrebbero avere un software legacy collegato 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 un hub USB collegato alla rete o una soluzione USB over IP.
Utilizzo di un server licenze
La maggior parte dei software moderni offre un'opzione di licenza mobile. Questa opzione è più pertinente in un ambiente cloud, ma richiede gestione delle licenze e controllo dell'accesso più efficaci per evitare il consumo eccessivo di un numero limitato di licenze.
Per evitare di superare la capacità delle licenze, durante la procedura di 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 tuo server 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 rete on-premise, tramite VPN o altre connessioni sicure.
Server di licenze basato su cloud
Nel cloud, puoi eseguire un server di licenze che gestisce le istanze nel tuo progetto o anche in più progetti utilizzando un VPC condiviso. A volte le licenze mobili sono collegate a un indirizzo MAC hardware, quindi una piccola istanza a lunga esecuzione con un indirizzo IP statico può gestire facilmente le licenze per più istanze di rendering.
Server di licenze ibrido
Alcuni software possono utilizzare più server di licenze in un ordine prioritario. Ad esempio, un renderer potrebbe eseguire query sul numero di licenze disponibili da un server on-premise e, se non sono disponibili, utilizzare un server di licenze basato su cloud. Questa strategia può aiutarti a massimizzare l'utilizzo delle licenze permanenti prima di valutarne altri tipi.
Note sulla produzione: definisci uno o più server di licenza in una variabile di ambiente e definisci l'ordine di priorità. A questo scopo, Autodesk Arnold, un renderer molto diffuso, Se il job non può acquisire una licenza utilizzando il primo server, il job 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 nella porta x.x.0.1, nella porta 5053. Se il tentativo non va a buon fine, tenta 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 vengono generalmente fatturate in due modi: utilizzo e 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 estratta da un server basato su cloud all'avvio del processo e rilasciata al completamento del processo. Se una licenza viene acquistata, ti verrà addebitato l'utilizzo della licenza. Questo tipo di licenza viene in genere utilizzato per il software di rendering.
Licenze basate sull'uptime
Le licenze basate sull'uptime o sul consumo vengono fatturate in base al tempo di attività dell'istanza Compute Engine. L'istanza è configurata per essere registrata con il server di licenze basato su cloud durante il processo di avvio. Finché l'istanza è in esecuzione, la licenza viene esaurita. 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 code.
Scegliere come archiviare i dati
Il tipo di archiviazione che scegli su Google Cloud dipende dalla strategia di archiviazione selezionata, oltre a fattori come i requisiti di durabilità e il costo.
Disco permanente
Potresti riuscire a evitare del tutto l'implementazione di un file server incorporando i dischi permanenti (DP) nel carico di lavoro. I DP sono un tipo di archiviazione a blocchi compatibile con POSIX, con una dimensione massima di 64 TB, e sono familiari 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 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 |
|---|---|---|
| Viene montato come volume NFS o SMB standard. Può essere ridimensionato in modo dinamico. A una singola istanza possono essere collegati 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 in DP solo se collegato a una singola istanza. Sono accessibili solo da risorse che si trovano nella stessa regione. |
Pipeline avanzate che possono creare un nuovo disco in base al job. Pipeline che pubblicano dati aggiornati raramente, come software o librerie comuni, per eseguire il rendering dei worker. |
Archiviazione di oggetti
Cloud Storage è uno spazio di archiviazione a elevata ridondanza 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. Se decidi di incorporare l'archiviazione di oggetti nella pipeline di rendering, devi modificare il modo in cui leggi e scrivi i dati tramite utilità a riga di comando come gsutil o tramite 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. Conveniente. I dati sono disponibili in tutto il mondo. Capacità praticamente illimitata. |
Non conforme a POSIX. Deve essere accessibile 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 che può pubblicare dati su 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 un cluster NAS on-premise. |
Non c'è modo di sincronizzare selettivamente i file. 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 dai 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. |
| Google Cloud NetApp Volumes | Soluzione di archiviazione completamente gestita su Google Cloud. Supporta ambienti NFS, SMB e multiprotocollo. Istantanee point-in-time con recupero dell'istanza |
Non disponibile in tutte le regioni di Google Cloud. | Strutture VFX con una pipeline in grado di sincronizzare
le risorse. Disco condiviso tra workstation virtuali. |
| FUSE Cloud Storage | Montare i bucket Cloud Storage come file system. Costi ridotti. | Non è un file system compatibile con 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 saperne di più, contatta il tuo rappresentante Google Cloud.
Per approfondire le 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 di strategie di archiviazione
Puoi implementare una serie di strategie di archiviazione nelle pipeline di produzione di effetti visivi o animazioni stabilindo delle convenzioni che determinano come gestire i dati, se accedi ai dati direttamente dall'archiviazione on-premise o esegui la sincronizzazione tra archiviazione on-premise e cloud.
Strategia 1: montare direttamente lo spazio di archiviazione on-premise
Se la tua struttura dispone di connettività a Google Cloud di almeno 10 Gbps e si trova nelle vicinanze di una regione 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, perché tutto ciò che crei sul cloud e rescrivi 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 o sincronizzazione nella cache. |
Può essere più costoso rispetto ad altre opzioni. Per ottenere una bassa latenza, è necessaria la vicinanza a un data center Google. Il numero massimo di istanze che puoi connettere al tuo NAS on-premise dipende dalla larghezza di banda e dal tipo di connessione. |
Strutture vicino a un data center di Google che devono eseguire il burst di carichi di lavoro di rendering sul cloud, dove i costi non sono un problema. Strutture con connettività Google Cloud di almeno 10 Gbps. |
Strategia 2: sincronizzazione on demand
Puoi scegliere di eseguire il push dei dati nel cloud o il pull dei dati dall'archiviazione on-premise o viceversa solo quando i dati sono necessari, 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, ad esempio 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 serie di comandi, ad esempio il comando gcloud scp, il comando rsync gsutil o i protocolli di trasferimento di dati basati su UDP (UDT). Se scegli di utilizzare una funzione UDT di terze parti come Aspera, Cloud FastPath, BitSpeed o FDT per comunicare con un bucket Cloud Storage, fai riferimento alla documentazione di terze parti per conoscere il modello di sicurezza e le best practice. 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é lo invii in una posizione predefinita.
Esempi:
- Un worker di rendering cloud completa un job di rendering e i frame risultanti vengono inviati nuovamente allo spazio di archiviazione on-premise.
- Un artista pubblica una risorsa. Parte del processo di pubblicazione degli asset prevede il push dei dati associati a un percorso predefinito in Cloud Storage.
Metodo pull
Il metodo pull viene utilizzato quando viene richiesto un file, in genere da un'istanza di rendering basata su cloud.
Esempio: nell'ambito di uno script del job di rendering, tutti gli asset necessari per la visualizzazione di una scena vengono inseriti in un file system prima del rendering, da cui possono accedere tutti i worker.
| Vantaggi | Svantaggi | Caso d'uso ideale |
|---|---|---|
| Controllo completo su quali dati sincronizzare e quando. Possibilità di scegliere metodo di trasferimento e protocollo. |
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 piccole o 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 esigenze di prestazioni di rendering che eccedono le capacità dell'infrastruttura. La memorizzazione nella cache di KNFSD offre una memorizzazione nella cache di lettura ad alte prestazioni, che consente la scalabilità dei carichi di lavoro fino a centinaia, o addirittura migliaia, di nodi di rendering in più regioni e pool di archiviazione ibridi.
La memorizzazione nella cache di KNFSD è una soluzione di 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 contemporaneamente di recuperare file dal file server. Utilizzando un livello di memorizzazione nella cache sulla stessa rete VPC dei nodi di rendering, la latenza di lettura viene ridotta, il che consente di avviare e completare più rapidamente i job di rendering. A seconda di come hai configurato il tuo file server di memorizzazione nella cache, i dati rimangono nella cache fino a quando:
- I dati scadranno o rimarranno invariati per un determinato periodo di tempo.
- È necessario uno spazio sul file server. A questo punto i dati vengono rimossi dalla cache in base all'età.
Questa strategia riduce la larghezza di banda e la complessità necessarie per il deployment di molte istanze di rendering simultanee.
In alcuni casi potrebbe essere opportuno preriscaldare la cache per assicurarti che tutti
i dati relativi al job siano presenti prima del rendering. Per preriscaldare la cache, leggi i contenuti di una directory che si trova sul tuo file server cloud eseguendo un'operazione read o stat di uno o più file. Accedere 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. Se scegli di preriscaldare la cache, devi implementare le attività pre-job. |
Strutture di grandi dimensioni che eseguono il deployment di molte istanze simultanee e leggono gli asset comuni in molti job. |
Applicazione di filtri ai dati
Puoi creare un database di tipi di asset e 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 nell'ambito di un processo di conversione, file di cache o dati di simulazione. Valuta inoltre se sincronizzare gli asset non approvati, dato che non tutte le iterazioni verranno utilizzate per il rendering finale.
Esecuzione di un trasferimento collettivo iniziale
Quando implementi la tua farm di rendering ibrida, può essere opportuno eseguire un trasferimento iniziale di tutto o parte del set di dati su Cloud Storage, su un disco permanente o su un altro tipo di archiviazione basata su cloud. A seconda di fattori quali la quantità e il tipo di dati da trasferire e la velocità della connessione, potresti essere in grado di eseguire una sincronizzazione completa nell'arco di alcuni giorni o settimane. La figura seguente mette a confronto gli orari tipici dei trasferimenti online e fisici.
Se il carico di lavoro di trasferimento supera i limiti di tempo o di 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 dei dati che possono essere recuperati. Vuoi progettare un piano di ripristino di emergenza che soddisfi le esigenze della tua struttura e fornisca un piano di emergenza esterno al sito. Rivolgiti al tuo fornitore di spazio di archiviazione on-premise per ricevere assistenza in merito a un piano di ripristino di emergenza adatto alla tua piattaforma di archiviazione specifica.
Archiviazione di dati nel cloud
Al termine di un progetto, è pratica comune salvare il lavoro finito in una sorta di archiviazione a lungo termine, in genere supporti su nastro 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, 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, riprese o filmati archiviati può richiedere molto tempo, perché i dati potrebbero essere archiviati su più cartucce, l'indicizzazione dell'archivio potrebbe mancare o essere incompleta o potrebbero esserci limitazioni di velocità nella lettura dei dati da nastri magnetici.
La migrazione del tuo 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 tuoi dati molto più accessibili e ricercabili rispetto ai metodi di archiviazione tradizionali.
Una pipeline di archiviazione di base potrebbe avere l'aspetto del diagramma seguente e utilizzare 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 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 per il recupero. Utilizza questi proxy all'interno del sistema di gestione degli asset multimediali in modo che gli utenti possano sfogliare i dati solo mentre leggono i proxy, non gli asset archiviati.
- Prendi in considerazione l'utilizzo del machine learning per classificare i contenuti delle live. Utilizza Cloud Vision per etichettare le texture e le targhe di sfondo oppure l'API Video Intelligence per semplificare la ricerca e il recupero di filmati di riferimento.
- Puoi anche utilizzare immagine AutoML Vertex AI per creare un modello di immagine personalizzato al fine di riconoscere qualsiasi asset, sia in live action che in quello sottoposto a rendering.
- Per i contenuti visualizzati, valuta la possibilità di 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, i plug-in, le librerie del sistema operativo e le dipendenze corrette per eseguire nuovamente il rendering di uno scatto archiviato.
Gestione degli asset e della produzione
Lavorare allo stesso progetto in più strutture può presentare sfide uniche, soprattutto quando contenuti e asset devono essere disponibili in tutto il mondo. La sincronizzazione manuale dei dati tra reti private può essere costosa, richiede molte risorse ed è soggetta a limitazioni di larghezza di banda locali.
Se il tuo carico di lavoro richiede dati disponibili a livello globale, potresti essere in grado di utilizzare Cloud Storage, che è accessibile da qualsiasi luogo in cui sia possibile accedere ai servizi Google. Per incorporare Cloud Storage nella pipeline, devi modificare la pipeline per comprendere i percorsi degli oggetti, quindi eseguire il pull o il push dei dati ai worker di rendering prima del rendering. L'utilizzo di questo metodo fornisce un accesso globale ai dati pubblicati, ma richiede che la pipeline invii gli asset dove sono necessari in un periodo di tempo ragionevole.
Ad esempio, un artista di texture a Los Angeles può pubblicare file immagine da utilizzare da un artista di luci a Londra. La procedura è simile alla seguente:
- La pipeline di pubblicazione esegue il push dei file in Cloud Storage e aggiunge una voce a un database di asset basato su cloud.
- Un artista di Londra esegue un copione per raccogliere le risorse per una scena. Le posizioni dei file vengono interrogate dal database e lette da Cloud Storage sul disco locale.
- Il software di gestione code raccoglie un elenco di asset necessari per il rendering, ne esegue una query nel database di asset e li scarica da Cloud Storage nello spazio di archiviazione locale di ogni worker di rendering.
L'uso 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 pipeline di archiviazione.
Gestione dei database
Il software di gestione degli asset e della 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 in esecuzione nello stesso rack dei worker di rendering e sono soggetti alle stesse limitazioni di alimentazione, rete e climatizzazione.
Potresti eseguire i 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 integrata.
Gestione delle code
Programmi software per la gestione delle code disponibili in commercio come Qube!, Deadline e Trattore sono ampiamente utilizzati nel settore VFX e dell'animazione. Sono disponibili anche opzioni software open source, come OpenCue. Puoi utilizzare questo software per eseguire il deployment e gestire qualsiasi carico di lavoro di computing su diversi worker, non solo per il rendering. Puoi eseguire il deployment e gestire la pubblicazione di asset, le simulazioni di particelle e fluidi, il baking delle texture e la composizione con lo stesso framework di pianificazione che utilizzi per gestire i rendering.
Alcune strutture hanno implementato un software di pianificazione per uso generico come HTCondor della University of Wisconsin, Slurm di SchedMD o Univa Grid Engine nelle loro pipeline VFX. I software progettati specificatamente per il settore VFX, tuttavia, prestano 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 fluida per intero prima del rendering.
- Priorità dei job, che visualizza i wrangler per cambiare 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 a cui sono collegate GPU.
- Acquisire dati storici sull'utilizzo delle risorse e renderli disponibili tramite un'API o una dashboard per ulteriori analisi. Ad esempio, esamina 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-flight. Ad esempio, un job pre-flight estrae tutti gli asset necessari sul worker di rendering locale prima del rendering. Un job post-flight copia il frame visualizzato risultante in una posizione designata su un file system e quindi contrassegna il frame come completato in un sistema di gestione degli asset.
- Integrazione con applicazioni software 2D e 3D popolari, come Maya, 3ds Max, Houdini, Cinema 4D o Nuke.
Note di produzione: utilizza il software di gestione code per riconoscere un pool di risorse basate su cloud come se fossero worker di rendering on-premise. Questo metodo richiede una certa 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 in genere gestite sia tramite un algoritmo sia tramite 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 eseguire script di pre- e post-rendering che creano risorse secondo necessità, le monitorano durante il rendering e le terminano al termine delle attività.
Considerazioni sul deployment del job
Quando implementi una farm di rendering che utilizza archiviazione sia on-premise che basata su cloud, ecco alcune considerazioni che il tuo gestore code potrebbe dover tenere presente:
- Le licenze potrebbero essere diverse tra i deployment nel cloud e quelli on-premise. Alcune licenze sono basate su nodi, altre sono basate su processi. Assicurati che il software di gestione delle code esegua il deployment dei job per massimizzare il valore delle licenze.
- Valuta la possibilità di aggiungere etichette o tag univoci alle risorse basate su cloud per assicurarti che vengano utilizzate solo quando vengono assegnate a tipi di job specifici.
- Utilizza Cloud Logging per rilevare le istanze inutilizzate o inattive.
- Quando avvii job dipendenti, valuta dove verranno conservati i dati risultanti e dove devono essere per il passaggio successivo.
- Se gli spazi dei nomi dei percorsi sono diversi tra archiviazione on-premise e basata su cloud, valuta la possibilità di utilizzare percorsi relativi per consentire ai rendering di essere indipendenti dalla località. In alternativa, a seconda della piattaforma, potresti creare un meccanismo per scambiare i percorsi al momento del rendering.
- Alcuni rendering, simulazioni o post-processi si basano sulla generazione di numeri casuali, che può variare a seconda dei produttori di 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 pre-riscaldare la cache e assicurati che tutti gli asset siano disponibili nel cloud prima di eseguire il deployment delle risorse cloud. Questo approccio riduce al minimo il tempo in cui i worker di rendering sono costretti ad attendere lo spostamento degli asset nel cloud.
Logging e monitoraggio
La registrazione e il monitoraggio dell'utilizzo e delle prestazioni delle risorse è un aspetto essenziale di qualsiasi farm di rendering. Google Cloud offre una serie di API, strumenti e soluzioni per fornire insight sull'utilizzo di risorse e 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 del 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 i log di utilizzo e gli audit log ed esportare i log risultanti in Cloud Storage, BigQuery e altri servizi.
- Utilizza Cloud Monitoring per installare un agente sulle tue VM al fine di monitorare le metrics di sistema.
- Incorpora l'API Cloud Logging negli script della pipeline per accedere direttamente a Cloud Logging utilizzando le 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 realmente ibrido, i nodi di rendering on-premise devono essere identici a quelli basati su cloud, con versioni del sistema operativo, build del kernel, librerie installate e software corrispondenti. Potresti anche dover riprodurre punti di montaggio, spazi dei nomi dei percorsi e persino 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 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 Compute Engine.
L'immagine personalizzata deve essere conforme alle best practice per la sicurezza. Se utilizzi 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 per l'immagine personalizzata gli stessi controlli di sicurezza utilizzati nelle immagini pubbliche.
Note di produzione: gestisci le immagini personalizzate in un progetto separato a livello di organizzazione. Questo approccio ti offre un controllo più preciso sulle modalità di creazione o modifica delle immagini e ti consente di applicare versions, che possono essere utili quando utilizzi diversi software o versioni del sistema operativo in più produzioni.
Automatizzare la creazione di immagini e il deployment delle istanze
Puoi utilizzare strumenti come Packer per rendere la creazione di immagini più riproducibile, verificabile, configurabile e affidabile. Puoi anche utilizzare uno strumento come Ansible per configurare i nodi di rendering in esecuzione ed esercitare un controllo granulare sulla loro configurazione e sul loro ciclo di vita.
Scelta di un tipo di macchina
Su Google Cloud puoi scegliere uno dei tipi di macchine predefinite o specificare un tipo di macchina personalizzata. L'utilizzo di tipi di macchine personalizzate ti consente di controllare le risorse in modo da poter personalizzare le istanze in base ai tipi di job eseguiti 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, 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 alle statistiche dei job storici 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, puoi scegliere di eseguire il deployment di macchine con un numero di CPU più elevato per i frame che contengono una forte sfocatura di movimento, in modo da normalizzare i tempi di rendering in tutti i frame.
Scelta tra VM standard e VM prerilasciabili
Le VM prerilasciabili (PVM) si riferiscono all'eccesso di capacità 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 quella capacità. Le PVM sono ideali per il rendering di carichi di lavoro a tolleranza di errore e gestiti da un sistema di accodamento 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 di licenza o gli host degli amministratori di 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 più a lungo.
Le percentuali di prerilascio vanno dal 5% al 15%, che per i carichi di lavoro di rendering tipici è probabilmente tollerabile dato il costo ridotto. Alcune best practice prerilasciabili possono aiutarti a decidere il modo migliore per integrare le PVM nella tua pipeline di rendering. Se l'istanza è prerilasciata, Compute Engine invia un indicatore di prerilascio all'istanza, che puoi utilizzare per attivare lo scheduler in modo da terminare il job attuale e ripetere la coda.
| VM standard | VM prerilasciabile |
|---|---|
| Può essere utilizzato per job a lunga esecuzione. Ideale per i lavori ad alta priorità con scadenze rigorose. Può essere eseguito a tempo indeterminato, pertanto ideale per i server di licenza o l'hosting degli amministratori di code. |
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 specifici, 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 degli snapshot, 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 per eseguire il rendering dei worker
IAM consente di assegnare l'accesso alle risorse cloud a 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 avere il controllo sugli amministratori.
Controllare i costi di una farm di rendering ibrida
Per la stima dei costi devi considerare molti fattori, ma ti consigliamo di implementare queste best practice comuni come criteri per la tua farm di rendering ibrida:
- Utilizza istanze prerilasciabili per impostazione predefinita. Utilizza le VM prerilasciabili, a meno che il job di rendering non abbia una lunga durata (quattro o più ore per frame) o non abbia una scadenza fissa per la consegna di uno scatto.
- Riduci al minimo il traffico in uscita. Copia nell'archiviazione on-premise solo i dati di cui hai bisogno. Nella maggior parte dei casi, questi dati saranno i frame sottoposti a rendering finali, ma possono anche essere passaggi separati o dati di simulazione. Se installi direttamente il NAS on-premise o utilizzi un prodotto di archiviazione che si sincronizza automaticamente, scrivi tutti i dati di cui è stato eseguito il 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.
- Dimensioni giuste delle VM. Assicurati di creare 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. Considera anche come ridurre al minimo le dimensioni dei dischi collegati.
- Considera l'offerta minima di un minuto. Su Google Cloud, le istanze vengono fatturate al secondo con un 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à insieme per evitare di eseguire il deployment di un'istanza per meno di un minuto di tempo di calcolo.
- Conserva set di dati di grandi dimensioni nel cloud. Se utilizzi la tua farm di rendering per generare enormi quantità di dati, ad esempio file EXR approfonditi o dati di simulazione, valuta la possibilità di utilizzare una workstation basata su cloud più in basso nella 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 utilizzo sostenuto e per impegno di utilizzo. 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. In alcuni casi, possono essere utili anche gli sconti per impegno di utilizzo.
Estendere la tua farm di rendering esistente nel 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 specifico. Per ricevere assistenza in merito alla migrazione dei carichi di lavoro di rendering nel cloud, 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.