Questo documento fornisce indicazioni su come estendere la tua fattoria di 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) e delle pipeline di animazione, il software di gestione delle code e i metodi comuni di licenza software.
Panoramica
Il rendering di elementi 2D o 3D per animazioni, film, pubblicità o videogiochi richiede molte risorse di calcolo e di tempo. Il rendering di questi elementi richiede un sostanziale investimento in hardware e infrastruttura insieme a un team dedicato di professionisti IT per il deployment e la manutenzione di hardware e software.
Quando una farm di rendering on-premise è al 100% di utilizzo, 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 con scadenze strette.
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 in 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 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 del software.
Per la creazione e la gestione di pipeline e flussi di lavoro di rendering in un ambiente cloud o 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 (SaaS) Software as a Service, 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 di Google Cloud come Gunpowder o AppsBroker. Questa opzione offre il vantaggio di eseguire tutti i servizi cloud nel tuo ambiente Google Cloud sicuro.
Contatta il tuo rappresentante Google Cloud per individuare 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 la rete internet pubblica.
Connessione tramite Internet
Senza una connettività speciale, puoi connetterti alla rete Google e utilizzare il nostro modello di sicurezza end-to-end accedendo ai servizi Google Cloud tramite internet. Utilità come gcloud e gsutil gli strumenti a riga di comando e le risorse come l'API Compute Engine utilizzano tutti autenticazione, autorizzazione e crittografia sicure per contribuire a salvaguardare i tuoi dati.
Cloud VPN
Indipendentemente dalla modalità di 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 direttamente 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à superiore e una latenza minore rispetto alle connessioni internet standard, oltre a prezzi del traffico in uscita ridotti.
Cross-Cloud Interconnect consente di stabilire una connettività dedicata a larghezza di banda elevata a Google Cloud per i tuoi dati in un altro cloud. In questo modo si riduce la complessità della rete, si riducono i costi di trasferimento dei dati e si rendono possibili rendering farm multi-cloud ad alta velocità effettiva.
Dedicated Interconnect
Dedicated Interconnect fornisce connessioni fisiche dirette e comunicazione RFC 1918 tra la tua rete on-premise e la rete Google. Offre capacità di connessione sui seguenti tipi di connessioni:
- Una o più connessioni Ethernet a 10 Gbps, con un massimo di otto connessioni o 80 Gbps totali per interconnessione.
- Una o più connessioni Ethernet a 100 Gbps, con un massimo di due connessioni o 200 Gbps totali per interconnessione.
Il traffico di Dedicated Interconnect non è criptato. Se devi trasmettere dati su Dedicated Interconnect in modo sicuro, devi stabilire una connessione VPN personalizzata. 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 fornitore 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 nella determinazione del modo migliore e più conveniente per connettersi a Google Cloud, contatta il tuo rappresentante Google Cloud.
Protezione dei contenuti
Per eseguire 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 la MPAA. Google Cloud offre modelli di sicurezza Zero Trust integrati in prodotti come Google Workspace, BeyondCorp Enterprise 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.
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 confine di isolamento per i dati di rete e per l'amministrazione dei progetti. Tuttavia, puoi condividere reti tra progetti con il VPC condiviso, che fornisce a progetti separati l'accesso a risorse comuni.
Note sulla produzione: crea un progetto host VPC condiviso che contiene 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 nella tua organizzazione può accedere alle stesse librerie, script e software forniti dal progetto host.
La risorsa organizzazione
Puoi gestire i progetti in una risorsa organizzazione, che potresti aver già stabilito. La migrazione di tutti i tuoi progetti in un'organizzazione offre una serie di vantaggi.
Note sulla produzione: designa i manager di produzione come proprietari dei singoli progetti e la gestione degli studi come proprietari della risorsa organizzazione.
Definizione dell'accesso alle risorse
I progetti richiedono l'accesso sicuro alle risorse, insieme a limitazioni sulle 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 mediante la definizione di ruoli assegnati a determinati livelli di accesso a determinate risorse.
Note di 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 worker 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 con 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. Ciò consente loro di 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 di studio cinematografico | resourcemanager.organizationAdmin |
Organizzazione Progetto |
| Direttore di produzione | owner, editor |
Progetto |
| Wrangler di rendering | compute.admin, iam.serviceAccountActor |
Progetto |
| Account di gestione delle 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 un'istanza autonomamente o quando il software di gestione delle code esegue il deployment delle risorse da un modello di istanza.
Gli ambiti hanno la precedenza sulle autorizzazioni IAM di un singolo account utente o di servizio. Questa precedenza indica 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 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 una serie di 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 o persino crearne una per frame.
Il tuo sistema di gestione delle code può monitorare le istanze in esecuzione, che possono essere inserite in coda se una VM viene prerilasciata e terminata 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 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 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 | Consiglio |
|---|---|---|
| Nodo bloccato | Licenza concessa a un indirizzo MAC, a un indirizzo IP o a un ID CPU specifico. Può essere eseguito da un solo processo. | Basato su istanza |
| Basato su nodo | Licenza concessa a un nodo specifico (istanza). Un numero arbitrario di utenti o processi può essere eseguito su un nodo con licenza. | Basato su istanza |
| Floating | Il pagamento è stato effettuato da un server 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 su grafica. | Server licenze o basati 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 | Check-out solo quando un processo viene eseguito su un'istanza cloud. Quando il processo termina o termina, la licenza viene rilasciata. | Server di licenze basato su cloud |
| Basato sul tempo di attività | 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 su 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
Quando vengono create, alle istanze viene assegnato un indirizzo MAC che viene conservato a condizione che l'istanza non venga eliminata. Puoi arrestare o riavviare un'istanza e l'indirizzo MAC verrà conservato. Puoi utilizzare questo indirizzo MAC per la creazione e la convalida delle licenze 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 sul 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
I software meno recenti potrebbero ancora essere concessi in licenza tramite una chiavetta, ovvero una chiave hardware programmata con una licenza di prodotto. La maggior parte delle aziende produttrici di software ha smesso di utilizzare i dongle hardware, ma alcuni utenti potrebbero disporre di 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 è in grado di fornire una licenza di questo tipo, puoi implementare un hub USB collegato alla rete o una soluzione USB over IP.
Utilizzo di un server di licenze
La maggior parte dei software moderni offre un'opzione di licenza floating. Questa opzione è più adatta in un ambiente cloud, ma richiede una 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, nell'ambito del processo di coda dei job puoi scegliere le licenze da utilizzare e controllare il numero di job che le utilizzano.
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 rete on-premise, tramite una VPN o un'altra connessione sicura.
Server di licenze basato su cloud
Nel cloud puoi eseguire un server delle licenze che gestisce le istanze nel tuo progetto o anche tra progetti utilizzando VPC condiviso. A volte le licenze floating sono collegate a un indirizzo MAC hardware, pertanto una piccola istanza a lunga esecuzione con un indirizzo IP statico può fornire facilmente licenze a molte istanze di rendering.
Server di licenze ibrido
Alcuni software possono utilizzare più server di licenze in ordine di priorità. Ad esempio, un renderer potrebbe eseguire query sul numero di licenze disponibili da un server on-premise e, se non ci sono licenze disponibili, utilizzare un server di licenze basato su cloud. Questa strategia può aiutarti a massimizzare l'utilizzo di licenze permanenti prima di dare un'occhiata agli altri tipi di licenza.
Note sulla produzione: definisci uno o più server di licenza in una variabile di ambiente e definisci l'ordine di priorità; per farlo è utile Autodesk Arnold, un renderer molto diffuso. Se il job non può acquisire una licenza utilizzando il primo server, tenta di utilizzare qualsiasi altro server elencato, come nell'esempio seguente:
export solidangle_LICENSE=5053@x.x.0.1;5053@x.x.0.2
Nell'esempio precedente, il renderer Arnold tenta di ottenere una licenza dal
server su x.x.0.1, porta 5053. Se il tentativo non va a buon fine, prova 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, il pagamento della licenza da parte di un server basato su cloud viene eseguito all'inizio del processo e il suo rilascio avviene al termine del processo. Finché una licenza viene acquistata, ti verrà addebitato il relativo utilizzo. Questo tipo di licenza è solitamente utilizzato per il software di rendering.
Licenze basate sull'uptime
Le licenze basate sull'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 solitamente utilizzato per i worker di rendering di cui un gestore di code esegue il deployment.
Scegliere come archiviare i dati
Il tipo di archiviazione che scegli su Google Cloud dipende dalla strategia di archiviazione scelta e da fattori quali costi e requisiti di durabilità.
Disco permanente
Potresti evitare di implementare del tutto 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 che come unità a stato solido (SSD). Puoi collegare un DP in modalità di lettura/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. Possono essere ridimensionati in modo dinamico. È possibile collegare fino a 128 DP a una singola istanza. Lo stesso DP può essere montato in modalità di sola lettura su centinaia o migliaia di istanze. |
Dimensione massima: 64 TB. Può scrivere su DP solo se collegato a una singola istanza. Sono accessibili solo alle risorse che si trovano nella stessa regione. |
Pipeline avanzate che possono creare un nuovo disco per singolo job. pipeline che forniscono dati aggiornati raramente, come software o librerie comuni, per eseguire 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 di oggetti nella pipeline di rendering, devi modificare il modo in cui leggi e scrivi i dati, tramite utilità della 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. economico. I dati sono disponibili a livello mondiale. Capacità praticamente illimitata. |
Non conforme a POSIX. È necessario 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 cluster che può supportare migliaia di connessioni NFS simultanee. In grado di eseguire la sincronizzazione con un 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 Pixit. | Strutture VFX di medie e grandi dimensioni con centinaia di TB di dati da presentare sul cloud. |
| Volumi NetApp di Google Cloud | Soluzione di archiviazione completamente gestita su Google Cloud. Supporta ambienti NFS, SMB e multiprotocollo. Snapshot di point-in-time con il recupero delle istanze |
Non disponibile in tutte le regioni di 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. Costi ridotti. | File system non 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 ulteriori informazioni, 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 dell'animazione o VFX stabilendo convenzioni che determinano come gestire i dati, a prescindere dal fatto che tu acceda ai dati direttamente dallo spazio di archiviazione on-premise o che sincronizzi l'archiviazione on-premise con 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 tuo NAS on-premise direttamente sui worker di rendering nel cloud. Sebbene questa strategia sia semplice, può anche richiedere costi e larghezza di banda elevata, poiché tutto ciò che crei sul cloud e scrivi sullo 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 al tuo NAS on-premise dipende dalla larghezza di banda e dal tipo di connessione. |
Strutture vicine 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 i dati al cloud o push dall'archiviazione on-premise, o viceversa, solo quando sono necessari dati, ad esempio quando viene eseguito il rendering di un frame o quando viene pubblicato un asset. 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 protocolli di trasferimento 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, fai riferimento alla documentazione della terza parte per informazioni sul modello di sicurezza e sulle best practice. Google non gestisce questi servizi di terze parti.
Metodo push
In genere, utilizzi il metodo push quando pubblichi un asset, inserisci un file in una cartella di visualizzazione o completi un job di rendering. Successivamente, esegui il push in una posizione predefinita.
Esempi:
- Un worker di rendering cloud completa un job di rendering e i frame risultanti vengono sottoposti a push-back nello 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 su Cloud Storage.
Metodo pull
Puoi utilizzare il metodo pull quando viene richiesto un file, in genere da un'istanza di rendering basata su cloud.
Esempio: come parte dello 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 di piccole e grandi dimensioni 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 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 di rendering 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 ai carichi di lavoro di scalare fino a centinaia o addirittura migliaia di nodi di rendering in più regioni e pool di archiviazione ibridi.
La memorizzazione nella cache KNFSD è una soluzione a scalabilità orizzontale che riduce il carico sul servizio principale di condivisione file. La memorizzazione nella cache KNFSD riduce anche l'effetto di sovraccarico quando molti nodi di rendering tentano tutti di recuperare i file dal file server contemporaneamente. Utilizzando un livello di memorizzazione nella cache sulla stessa rete VPC dei nodi di rendering, si riduce la latenza di lettura, il che consente di avviare e completare più rapidamente i job di rendering. 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 in cui i dati vengono rimossi dalla cache in base all'età.
Questa strategia riduce la quantità di larghezza di banda e complessità necessarie per il deployment di molte istanze di rendering simultanee.
In alcuni casi, potrebbe essere necessario preparare la cache per garantire che siano presenti tutti i dati relativi al job prima del rendering. Per preriscaldare la cache, leggi i contenuti di una directory che si trova sul tuo file server cloud eseguendo 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 dei job. |
Può comportare costi aggiuntivi. Le attività pre-job devono essere implementate se scegli di preriscaldare la cache. |
Strutture di grandi dimensioni che eseguono il deployment di molte istanze in parallelo 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 nell'ambito di un processo di conversione, file memorizzati nella cache o dati di simulazione. Valuta inoltre se sincronizzare gli asset non approvati, poiché non tutte le iterazioni verranno utilizzate nei rendering finali.
Esecuzione di un trasferimento collettivo iniziale
Quando implementi la tua farm di rendering ibrida, potresti voler eseguire un trasferimento iniziale dell'intero set di dati o di una sua parte su Cloud Storage, un disco permanente o un altro spazio di archiviazione basato su cloud. A seconda di fattori come la quantità e il tipo di dati da trasferire e la velocità della 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 vincoli di tempo o larghezza di banda, Google offre una serie di opzioni di trasferimento per portare i tuoi dati nel cloud, tra cui Transfer Appliance di Google.
Archiviazione e ripristino di emergenza
Vale la pena notare la differenza tra l'archiviazione dei dati e il ripristino di emergenza. La prima è una copia selettiva del lavoro finito, mentre la seconda è uno stato di dati recuperabili. Vuoi progettare un piano di ripristino di emergenza adatto alle esigenze della tua struttura e che fornisca un piano di emergenza esterno. Rivolgiti al 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 qualche forma di archiviazione a lungo termine, in genere supporti su nastro magnetico come LTO. Queste cartucce sono soggette a requisiti ambientali e, nel tempo, possono essere logisticamente difficili da gestire. Le grandi strutture di produzione a volte ospitano l'intero archivio in una sala appositamente costruita con un archivista a tempo pieno che tiene traccia dei dati e recuperali 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 dell'archivio potrebbe essere mancante o incompleta o potrebbero esserci limitazioni di velocità per la lettura dei dati su nastro magnetico.
La migrazione dell'archivio dati nel cloud non solo elimina la necessità di gestire e archiviare on-premise i 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 di metadati, come data, progetto, formato o risoluzione. Puoi anche utilizzare le API Machine Learning per taggare e classificare immagini e video, memorizzando 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 nelle classi di archiviazione di Cloud Storage che prevedono costi di recupero. Utilizza questi proxy all'interno del sistema di gestione degli asset multimediali in modo che gli utenti possano sfogliare i dati durante la lettura solo dei proxy, non degli asset archiviati.
- Valuta la possibilità di usare il machine learning per classificare i contenuti live action. Utilizza Cloud Vision per etichettare texture e lastre 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, sia che si tratti di live action o di rendering.
- Per i contenuti sottoposti a rendering, 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 del sistema operativo corretti se dovrai 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 contenuti e risorse devono essere disponibili in tutto il mondo. La sincronizzazione manuale dei dati tra reti private può essere costosa e richiede molte 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, che è accessibile ovunque 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 per i worker di rendering prima del rendering. L'utilizzo di questo metodo fornisce un accesso globale ai dati pubblicati, ma richiede alla tua pipeline di inviare gli asset dove sono necessari in un periodo di tempo ragionevole.
Ad esempio, un texture artist di Los Angeles può pubblicare file immagine per l'utilizzo da un artista di luci a Londra. La procedura ha il seguente aspetto:
- 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 risorse per una scena. Le posizioni dei file vengono interrogate dal database e lette da Cloud Storage al disco locale.
- 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 ciascun worker di rendering.
L'utilizzo di Cloud Storage in questo modo fornisce inoltre un archivio di tutti i tuoi dati pubblicati sul cloud, se scegli di usare 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 e 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 in esecuzione sullo 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, caratterizzati da una disponibilità elevata e accessibili a livello globale, criptano i dati sia at-rest sia in transito e offrono funzionalità di replica integrata.
Gestione delle code
Programmi software di gestione delle code disponibili sul mercato come Qube!, Scadenza e Trattore sono ampiamente utilizzati nel settore delle animazioni/VFX. 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, la creazione di texture e la composizione con lo stesso framework di pianificazione che utilizzi per gestire i rendering.
Alcune strutture hanno implementato nelle loro pipeline VFX un software di pianificazione generico, come HTCondor dell'Università del Wisconsin, Slurm di SchedMD o Univa Grid Engine. Il software progettato appositamente per il settore VFX presta particolare attenzione a funzioni 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 completamente prima del rendering.
- Priorità dei job, che consente ai wrangler di 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 con GPU collegate.
- Acquisizione di dati storici sull'utilizzo delle risorse e resi 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.
- Lavori prima e dopo il volo. Ad esempio, un job pre-flight esegue il pull di tutti gli asset necessari sul worker locale del rendering 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 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 di rendering on-premise. Questo metodo richiede una supervisione per massimizzare l'utilizzo delle risorse eseguendo il numero di rendering che ogni istanza è in grado di gestire, una tecnica nota come bin packing. Queste operazioni sono in genere 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 al termine delle attività.
Considerazioni sul deployment dei job
Quando implementi una farm di rendering che utilizza l'archiviazione sia on-premise che basata su cloud, ecco alcune considerazioni di cui il gestore delle code potrebbe dover tenere a mente:
- Le licenze potrebbero variare tra i deployment nel cloud e on-premise. Alcune licenze sono basate sui nodi, altre sui processi. Assicurati che il software di gestione delle code esegua il deployment dei 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 i job dipendenti, valuta dove si troveranno i dati risultanti e dove dovranno essere per il passaggio successivo.
- Se gli spazi dei nomi dei percorsi sono diversi tra archiviazione on-premise e archiviazione basata su cloud, valuta l'utilizzo di 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 tra i produttori della CPU. Anche CPU dello stesso produttore, ma 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 la quantità di tempo che i worker di rendering sono costretti ad attendere mentre gli asset vengono spostati nel cloud.
Logging e monitoraggio
La registrazione e il monitoraggio dell'utilizzo e delle prestazioni delle risorse sono un aspetto essenziale di qualsiasi farm di rendering. Google Cloud offre una serie di API, strumenti e soluzioni per 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 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, nonché per esportare i log risultanti in Cloud Storage, BigQuery e altri servizi.
- Utilizza Cloud Monitoring per installare un agente sulle 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 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. Potresti anche dover 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 sulla tua immagine del nodo di rendering on-premise. Le immagini pubbliche includono una raccolta di pacchetti che configurano e gestiscono account utente e abilitano l'autenticazione basata su chiave di Secure Shell (SSH).
Creazione di un'immagine personalizzata
Se scegli di creare un'immagine personalizzata, dovrai aggiungere altre librerie sia a Linux sia a Windows affinché funzionino correttamente nell'ambiente 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 sull'immagine personalizzata gli stessi controlli di sicurezza che utilizzi per le immagini pubbliche.
Note sulla produzione: gestisci le immagini personalizzate in un progetto separato a livello di organizzazione. Questo approccio offre un controllo più preciso sul modo in cui le immagini vengono create o modificate e consente di applicare versions, che possono essere utili quando si utilizzano diversi software o versioni del sistema operativo in più produzioni.
Automazione della creazione di immagini e del deployment delle istanze
Puoi utilizzare strumenti come Packer per rendere la creazione di immagini più riproducibile, controllabile, configurabile e affidabile. Puoi anche utilizzare uno strumento come Ansible per configurare i nodi di rendering in esecuzione e 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 macchina predefinita o specificare un tipo di macchina personalizzata. L'uso di tipi di macchine personalizzate offre il controllo sulle risorse in modo da poter 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 le dimensioni 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 del job storiche, come il carico della CPU o l'utilizzo della memoria, per 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 di movimento, in modo da normalizzare i tempi di rendering per tutti i frame.
Scelta tra VM standard e prerilasciabili
Le VM prerilasciabili (PVM) si riferiscono alla capacità di Compute Engine in eccesso, venduta a un prezzo molto inferiore rispetto alle VM standard. Compute Engine potrebbe terminare o prerilasciare queste istanze se altre attività richiedono l'accesso a questa capacità. Le VM 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 per il prerilascio.
Le VM standard possono essere eseguite a tempo indeterminato e sono ideali per i server delle licenze o gli host amministratore di 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 che vengono eseguite più a lungo.
Le tariffe 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 viene 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 accodare di nuovo.
| VM standard | VM prerilasciabile |
|---|---|
| Può essere utilizzato per job a lunga esecuzione. Ideale per lavori ad alta priorità con scadenze difficili. Può essere eseguito a tempo indeterminato, ed è quindi l'ideale per i server delle licenze o per l'hosting dell'amministratore di code. |
Chiusura 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. Pertanto, 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 lo snapshot del rendering nella pipeline per evitare di perdere 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, dandoti la possibilità di controllare chi è un amministratore.
Controllo dei costi di una farm di rendering ibrida
Quando fai una 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 tuo job di rendering non sia a lunga esecuzione, quattro o più ore per frame o tu non abbia una scadenza rigida per ottenere un'istantanea.
- Riduci al minimo il traffico in uscita. Copia solo i dati di cui hai bisogno nello spazio di archiviazione on-premise. Nella maggior parte dei casi, questi dati saranno i frame visualizzati finali, ma possono anche essere passaggi separati o dati di simulazione. Se stai montando il tuo NAS on-premise direttamente o stai utilizzando un prodotto di archiviazione che si sincronizza automaticamente, scrivi tutti i dati sottoposti a rendering nel file system locale del worker di rendering, quindi copia ciò di cui hai bisogno nello spazio di archiviazione on-premise per evitare il traffico in uscita di dati temporanei e non necessari.
- Dimensioni giuste per le 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. Considera anche come ridurre al minimo le dimensioni dei dischi collegati.
- Considera il minimo 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à per evitare 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 dati EXR profondi o dati di simulazione, valuta la possibilità di utilizzare una workstation basata su cloud che si trovi più avanti 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 del settore luci può 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 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 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 economico per utilizzare risorse potenti e a basso costo senza spese di capitale. Non esistono due pipeline di produzione uguali, quindi nessun documento può coprire ogni argomento e requisito unico. Per assistenza con la migrazione dei carichi di lavoro di rendering nel cloud, contatta il tuo rappresentante 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. Dai un'occhiata al nostro Cloud Architecture Center.