Questo documento fornisce indicazioni su come estendere la tua farm 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 abbia familiarità con i concetti di base delle pipeline di animazione ed effetti visivi (VFX), con il software di gestione delle code e con i metodi di licenza software 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 ingenti investimenti in hardware e infrastruttura, oltre a una di professionisti IT per il deployment e la manutenzione di hardware e software.
Quando una farm di rendering on-premise è inutilizzata al 100%, la gestione dei job può diventare un problema. Priorità e dipendenze delle attività, riavvio dei frame interrotti e il carico di rete, disco e CPU diventano tutti parte della complessa equazione che devono monitorare e controllare attentamente, spesso con scadenze ravvicinate.
Per gestire questi lavori, le strutture VFX dispongono di un software di gestione code incorporato 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 job.
- Comunicare con i sistemi di gestione degli asset.
- Offri agli utenti un'interfaccia utente e API per i linguaggi più comuni come come Python.
Sebbene alcuni software di gestione delle code possano eseguire il deployment dei job su worker basati su cloud, rimane comunque tua responsabilità connetterti al cloud, sincronizzare gli asset, scegliere un framework di archiviazione, gestire i modelli di immagine e fornire le licenze del software.
Sono disponibili le seguenti opzioni per la creazione e la gestione delle 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 risorse cloud descritte in questo documento.
- Se vuoi creare un flusso di lavoro personalizzato basato sui 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 un ambiente Google Cloud sicuro.
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 per da seguire mentre crei la tua farm di rendering.
Connessione al cloud
A seconda del carico di lavoro, decidi come 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 alcuna connettività speciale, puoi connetterti alla rete di Google e utilizzare il nostro modello di sicurezza end-to-end accedendo ai servizi Google Cloud tramite internet. Utilità come Google Cloud CLI e risorse come API Compute Engine usano tutti autenticazione, autorizzazione e crittografia sicure per salvaguardare i tuoi dati.
Cloud VPN
Indipendentemente dal tipo di connessione, ti consigliamo di utilizzare una rete privata virtuale (VPN) per proteggere la connessione.
Cloud VPN ti aiuta a connettere in sicurezza la tua rete on-premise alla �� I dati in transito vengono criptati prima passa attraverso uno o più tunnel VPN.
Scopri come creare una VPN per il tuo progetto.
VPN fornita dal cliente
Sebbene tu possa configurare il tuo gateway VPN per connetterti direttamente a Google, ti consigliamo di utilizzare Cloud VPN, che offre maggiore flessibilità e un'integrazione migliore con Google Cloud.
Cloud Interconnect
Google supporta diversi modi per connettere la tua infrastruttura a Google Cloud. Queste connessioni di livello enterprise, note collettivamente come Cloud Interconnect, offrono una maggiore disponibilità e una latenza inferiore rispetto alle connessioni internet standard, nonché prezzi ridotti per il traffico in uscita.
Cross-Cloud Interconnect 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, riduci la complessità della rete, i costi di trasferimento dei dati e ottieni farm di rendering multicloud ad alta produttività.
Dedicated Interconnect
Interconnessione dedicata che fornisce connessioni fisiche dirette e comunicazioni RFC 1918 tra i tra la rete on-premise e la rete Google. Offre capacità di connessione tramite i 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 in totale per interconnessione.
Il traffico di Dedicated Interconnect non è criptato. Se devi trasmettere dati tramite Dedicated Interconnect in modo sicuro, devi stabilire la tua connessione VPN. Cloud VPN non è compatibile con Dedicated Interconnect, quindi in questo caso devi fornire la tua VPN.
Partner Interconnect
Partner Interconnect fornisce connettività tra la tua rete on-premise e la tua rete VPC tramite un provider di servizi supportato. Un Partner Interconnect è utile se l'infrastruttura si trova in una località fisica che non può raggiungere una struttura di colocation di Dedicated Interconnect le 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 per determinare il modo migliore e più conveniente per connetterti a Google Cloud, contatta il tuo rappresentante di Google Cloud.
Protezione dei contenuti
Per pubblicare i propri contenuti su qualsiasi piattaforma cloud pubblica, i proprietari di contenuti come i principali studi cinematografici di Hollywood richiedono ai fornitori di rispettare le best practice di sicurezza definite sia internamente sia da organizzazioni come la 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 white paper sulla sicurezza e 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.
Organizzare i progetti
I progetti sono un componente organizzativo fondamentale di Google Cloud. Nel tuo impianto, puoi organizzare i job in un progetto dedicato o suddividerli in più progetti. Ad esempio, è possibile creare file progetti per la previsualizzazione, la ricerca e lo sviluppo fasi di un film.
I progetti stabiliscono un confine di isolamento sia per i dati di rete sia per la gestione del progetto. Tuttavia, puoi condividere le reti tra progetti con VPC condiviso, che fornisce progetti separati con accesso a risorse comuni.
Note di produzione: crea un Progetto host VPC condiviso che contiene risorse con tutta la tua produzione i nostri strumenti. Puoi designare tutti i progetti creati nella tua organizzazione come progetti di servizio VPC condiviso. Questa designazione significa in modo che qualsiasi progetto della tua organizzazione possa accedere alle stesse librerie, agli stessi script e il software fornito dal progetto host.
La risorsa Organizzazione
Puoi gestire i progetti in una risorsa dell'organizzazione, che potresti aver già creato. Migrazione tutti i tuoi progetti in un'organizzazione fornisce una serie vantaggi.
Note di produzione: designa i gestori della produzione come proprietari dei singoli progetti e la gestione dello studio come proprietari della risorsa Organizzazione.
Definire l'accesso alle risorse
I progetti richiedono l'accesso sicuro alle risorse insieme a limitazioni su dove gli utenti o i servizi possono operare. Per aiutarti a definire l'accesso, Google Cloud offre Identity and Access Management (IAM). che puoi utilizzare per gestire il controllo dell'accesso definendo quali ruoli hanno livelli di accesso a quali risorse.
Note sulla produzione: per limitare l'accesso degli utenti accesso solo alle risorse necessarie per svolgere attività specifiche in base ai propri ruolo, implementa il principio del privilegio minimo sia on-premise che nel cloud.
Ad esempio, prendi in considerazione un worker di rendering, ovvero una macchina virtuale (VM) che puoi eseguire 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 Cloud Storage e scrittura nello spazio di archiviazione collegato, ad esempio un Cloud Filer un disco permanente o un disco permanente. Tuttavia, non è necessario aggiungere singoli artisti a nei progetti Google Cloud, perché non hanno bisogno dell'accesso diretto delle tue risorse cloud.
Puoi assegnare ruoli a responsabili della gestione dei rendering o amministratori di progetti che hanno accesso a tutte le risorse di Compute Engine, il che consente loro di eseguire funzioni su risorse inaccessibili ad altri utenti.
Definisci un criterio per stabilire quali ruoli possono accedere a determinati tipi di risorse che fa parte della tua organizzazione. La tabella seguente mostra la mappatura delle attività di produzione tipiche ai ruoli IAM in Google Cloud.
| Attività di produzione | Nome ruolo | Tipo di risorsa |
|---|---|---|
| Gestore di Studio | resourcemanager.organizationAdmin |
Progetto Organizzazione |
| Direttore di produzione | owner, editor |
Progetto |
| Esegui il rendering di Wrangler | compute.admin, iam.serviceAccountActor |
Progetto |
| Account di gestione della coda | compute.admin, iam.serviceAccountActor |
Progetto Organizzazione |
| Artista individuale | [no access] | Non applicabile |
Ambiti di accesso
Gli ambiti di accesso ti 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 personalmente 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 utente o account di servizio. Questa precedenza significa che un ambito di accesso può impedire a un amministratore del progetto di accedere a un'istanza per eliminare uno spazio di archiviazione un bucket o modificare un'impostazione del firewall.
Note sulla produzione: per impostazione predefinita, le istanze possono leggere, ma non scrivere in Cloud Storage. Se la pipeline di rendering scrive nuovamente i rendering finali in Cloud Storage, aggiungi l'ambitodevstorage.read_write all'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 da vari modi per rendere disponibili le risorse alla tua farm di rendering.
Deployment on demand
Per un utilizzo ottimale delle risorse, puoi scegliere di eseguire il deployment dei worker di rendering solo quando invii un job alla farm di rendering. Puoi eseguire il deployment di più VM da condividere tra tutti i frame di un job o anche creare una VM per frame.
Il sistema di gestione delle code può monitorare le istanze in esecuzione, che possono essere riassegnate alla coda se una VM viene prelevata e terminate al completamento delle 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.
Concedere in licenza il software
Le licenze software di terze parti possono variare notevolmente da pacchetto a pacchetto. Ecco alcuni degli schemi e dei modelli di licenza che si possono incontrare con un effetto VFX una pipeline o un blocco note personalizzato. Per ogni schema, la terza colonna mostra le licenze consigliate l'importanza di un approccio umile.
| Scheme | Descrizione | Consiglio |
|---|---|---|
| Nodo bloccato | Con licenza per un indirizzo MAC, un indirizzo IP o un ID CPU specifici. Può essere eseguito solo da un singolo 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. | In base all'istanza |
| Floating | Effettuato il check-out da un server delle licenze che tiene traccia dell'utilizzo. | Server licenza |
| Licenze software | ||
| Interattiva | Consente all'utente di eseguire il software in modo interattivo in un ambiente basato su grafica. | Server di licenze o basato su istanze |
| Batch | Consente all'utente di eseguire il software solo in un ambiente a riga di comando. | Server delle licenze |
| Licenze basate su cloud | ||
| Basato su utilizzo | Effettuato il check-out solo quando un processo viene eseguito su un'istanza cloud. Al termine o all'interruzione della procedura, la licenza viene rilasciata. | Server delle licenze basato su cloud |
| Basato sull'uptime | Eseguito il check-out mentre un'istanza è attiva e in esecuzione. Se l'istanza viene interrotta o eliminata, la licenza viene rilasciata. | Server delle 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 quando vengono eseguite per tempi più lunghi. Questo approccio alle licenze può presentare un problema nel cloud, in cui Gli identificatori hardware, come gli indirizzi MAC o IP, vengono assegnati in modo dinamico.
Indirizzi MAC
Quando vengono create, alle istanze viene assegnato un indirizzo MAC che viene conservato in modo che purché l'istanza non venga eliminata. Puoi interrompi o riavvia un'istanza e l'indirizzo MAC verrà mantenuto. Puoi usare questo 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, viene assegnato un indirizzo IP interno e, facoltativamente, uno esterno. Per conservare l'indirizzo IP esterno di un'istanza, puoi: prenotare un indirizzo IP statico e assegnarlo alla tua istanza. Questo indirizzo IP verrà riservato solo a questo in esecuzione in un'istanza Compute Engine. Poiché gli indirizzi IP statici sono risorse basate su progetti, soggetto 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 precedente potrebbe essere ancora concesso in licenza tramite un dongle, una chiave hardware programmata con una licenza di prodotto. La maggior parte delle società di software ha smesso di utilizzare chiavette hardware specifiche, ma alcuni utenti potrebbero disporre di software legacy di questi dispositivi. Se riscontri questo problema, contatta il produttore del software per verificare se può fornirti una licenza aggiornata per il software in questione.
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 licenze
La maggior parte dei software moderni offre un'opzione di licenza mobile. Questa opzione è più adatta in un ambiente cloud, ma richiede una gestione delle licenze e un controllo dell'accesso più rigorosi per evitare il consumo eccessivo di un numero limitato di licenze.
Per evitare di superare la capacità della licenza, puoi inserire le tue licenze nella coda dei job processo scegli le licenze da utilizzare e controlla il numero di job che utilizzano licenze.
Server di licenze on-premise
Puoi usare il tuo attuale server licenze on-premise per fornire licenze di Compute Engine in esecuzione nel cloud. Se scegli questo metodo, devi fornire ai tuoi worker di rendering un modo per comunicare con la tua rete on-premise tramite una VPN o un'altra connessione sicura.
Server delle licenze basato su cloud
Nel cloud, puoi eseguire un server di licenze che gestisce le istanze nel tuo progetto o anche tra progetti, utilizzando VPC condiviso. A volte le licenze mobili sono collegate a un indirizzo MAC hardware, quindi un piccolo un'istanza a lunga esecuzione con un indirizzo IP statico può facilmente fornire licenze di eseguire il rendering delle istanze.
Server delle licenze ibrido
Alcuni software possono utilizzare più server di licenze in un ordine prioritario. Per Ad esempio, un renderer potrebbe eseguire una query sul numero di licenze disponibili un server on-premise e, se non sono disponibili, utilizza una licenza basata su cloud server web. Questa strategia può aiutarti a massimizzare l'utilizzo delle licenze permanenti prima controlla altri tipi di licenze.
Note di produzione: definisci una o più licenze server in una variabile di ambiente e definiscono l'ordine di priorità; Autodesk Arnold, un renderer famoso, ti aiuta a farlo. Se il job non può acquisire utilizzando il primo server, il job tenta di utilizzare qualsiasi altro server come indicato nell'esempio seguente:
export solidangle_LICENSE=5053@x.x.0.1;5053@x.x.0.2
Nell'esempio precedente, il renderer Arnold cerca di ottenere una licenza dal
server su x.x.0.1, porta 5053. Se il tentativo non va a buon fine, il sistema 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 su richiesta per le tue istanze. In genere, le licenze basate su cloud vengono fatturate in due modi: in base all'utilizzo e in base al tempo di attività.
Licenze basate sull'utilizzo
Le licenze basate sull'utilizzo vengono fatturate in base al tempo di utilizzo del software. In genere, con questo tipo di licenze, una licenza viene ritirata da un server basato su cloud all'avvio del processo e viene rilasciata al suo completamento. Finché una licenza è in uso, ti viene addebitato l'utilizzo di quella licenza. Questo tipo di licenza viene in genere utilizzato per il software di rendering.
Licenze basate sull'uptime
Le licenze basate sul tempo di attività o misurate vengono fatturate in base al tempo di attività della tua istanza Compute Engine. L'istanza è configurata per essere registrata con un server di licenze basato su cloud procedura di avvio. Finché l'istanza è in esecuzione, la licenza viene controllata. Quando viene arrestata o eliminata, la licenza viene rilasciata. Questo tipo di licenza è generalmente utilizzato per i worker di rendering distribuiti da un gestore code.
Scegliere come archiviare i dati
Il tipo di spazio di archiviazione che scegli su Google Cloud dipende strategia di archiviazione insieme a fattori come i requisiti di durabilità e il costo.
Disco permanente
Potresti evitare del tutto l'implementazione di un file server incorporando unità disco permanenti (PD) nel tuo carico di lavoro. I PD sono un tipo di archiviazione a blocchi conforme a POSIX, con dimensioni massime di 64 TB, che sono familiari alla maggior parte delle strutture di VFX. I dischi permanenti disponibili sia come unità standard che come unità a stato solido (SSD). Puoi allegare un DP in modalità di lettura/scrittura a una singola istanza, o in modalità di sola lettura a un di istanze VM, ad esempio un gruppo di worker di rendering.
| Vantaggi | Svantaggi | Caso d'uso ideale |
|---|---|---|
| Viene montato come volume NFS o SMB standard. Ridimensionabile in modo dinamico. A una singola istanza possono essere collegati fino a 128 DP. Lo stesso PD può essere montato in modalità di sola lettura su centinaia o migliaia di istanze. |
Dimensioni massime di 64 TB. Può scrivere su DP solo se collegato a una singola istanza. Sono accessibili solo dalle 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, ad esempio software o librerie comuni, per eseguire il rendering dei worker. |
Archiviazione di oggetti
Cloud Storage è uno spazio di archiviazione altamente ridondante e durevole che, a differenza dei file system tradizionali, è non strutturato e ha una capacità praticamente illimitata. File attivati 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 della pipeline di rendering, devi modificare il modo in cui leggi e scrivi i dati, tramite utilità a riga di comando come gcloud CLI tramite API Cloud Storage.
| Vantaggi | Svantaggi | Caso d'uso ideale |
|---|---|---|
| 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 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 per gli utilizzi odierni. |
Esegui il rendering delle pipeline con un sistema di gestione delle risorse in grado di pubblicare i 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 NFS simultanei
e connessioni a Internet. Sincronizzazione con cluster NAS on-premise. |
Impossibile sincronizzare i file in modo selettivo. Nessuna sincronizzazione bidirezionale. | Strutture VFX di medie e grandi dimensioni con centinaia di TB di dati su cui presentare nel cloud. |
| Pixit Media, PixStor | File system scalabile in grado di supportare migliaia di client NFS o POSIX simultanei. I dati possono essere memorizzati nella cache on demand da NAS on-premise, con vengono restituiti 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 su cui presentare nel cloud. |
| Google Cloud NetApp Volumes | Soluzione di archiviazione completamente gestita su Google Cloud. Supporta ambienti NFS, SMB e multiprotocollo. Snapshot point-in-time con recupero dell'istanza |
Non disponibile in tutte le regioni Google Cloud. | Strutture per VFX con una pipeline in grado di sfruttare le risorse
la sincronizzazione dei dati. Disco condiviso tra workstation virtuali. |
| Archiviazione cloud FUSE | Monta 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 distribuire, configurare e mantenere un file system open source, con una pipeline in grado di gestire asset la sincronizzazione dei dati. |
Su 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
- Progettare una strategia di archiviazione ottimale per il carico di lavoro cloud
Implementazione di strategie di archiviazione
Puoi implementare una serie di strategie di archiviazione nelle pipeline di produzione di animazione o VFX stabilendo convenzioni che determinano come gestire i dati, indipendentemente dal fatto che tu acceda ai dati direttamente dallo spazio di archiviazione on-premise o se li sincronizzi tra lo spazio di archiviazione on-premise e il cloud.
Strategia 1: monta direttamente lo spazio di archiviazione on-premise
Se la tua struttura dispone di una connettività a Google Cloud di almeno 10 Gbps e si trova nelle immediate vicinanze di una regione Google Cloud, puoi scegliere di montare il tuo NAS on-premise direttamente sui worker di rendering cloud. Sebbene questa strategia sia semplice, può anche richiedere costi e larghezza di banda molto impegnativo, perché tutto ciò che si crea sul cloud e su cui si scrive 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, nessuna memorizzazione nella cache o sincronizzazione necessaria. |
Può essere più costoso rispetto ad altre opzioni. La vicinanza a un data center di Google è necessaria per ottenere una latenza di pochi millisecondi. Il numero massimo di istanze che puoi connettere Il NAS on-premise dipende dalla larghezza di banda e dal tipo di connessione. |
Strutture vicino a un data center Google che devono eseguire il burst di carichi di lavoro di rendering per
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 caricare i dati sul cloud o estrarre i dati dallo spazio di 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 monitoraggio, da un gestore di eventi come Pub/Sub o da un insieme di comandi all'interno di uno script di job.
Puoi eseguire una sincronizzazione utilizzando diversi comandi, ad esempio gcloud CLI scp il comando gcloud CLI 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, consulta la documentazione della terza parte per conoscere il suo modello di sicurezza e le best practice. Google non gestisce questi servizi di terze parti.
Metodo push
In genere utilizzi il metodo push per pubblicare un asset e inserire un file in una una cartella di visualizzazione o un job di rendering, dopodiché lo invii a una posizione predefinita.
Esempi:
- Un worker di rendering cloud completa un job di rendering e i frame risultanti viene eseguito il push back nello spazio di archiviazione on-premise.
- Un artista pubblica una risorsa. Parte del processo di pubblicazione delle risorse comporta il push dei dati associati a un percorso predefinito di archiviazione ideale in Cloud Storage.
Metodo pull
Il metodo pull viene utilizzato quando viene richiesto un file, in genere da un fornitore di un'istanza di rendering.
Esempio: nell'ambito di uno script del job di rendering, tutti gli asset necessari eseguire il rendering di una scena vengono inseriti in un file system prima del rendering, dove tutti i lavoratori 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. Per gestire la coda di sincronizzazione potrebbero essere necessarie risorse aggiuntive. |
Strutture piccole e grandi che hanno pipeline personalizzate e che vogliono controllo sulla sincronizzazione degli asset. |
Note sulla produzione: gestisci i dati la sincronizzazione con lo stesso sistema di gestione delle code utilizzato 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 completa basata su cloud
Google Cloud ha esteso e sviluppato Soluzione di memorizzazione nella cache di KNFSD come opzione open source. La soluzione può gestire le prestazioni della farm di rendering che superano le capacità dell'infrastruttura di archiviazione. KNFSD la memorizzazione nella cache ad alte prestazioni, in lettura carichi di lavoro scalabili 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 di scale out che riduce il carico sulla di condivisione file. La memorizzazione nella cache KNFSD riduce anche l'effetto di sovraccarico quando molti nodi di rendering tentano tutti di recuperare file dal file contemporaneamente. L'utilizzo di un livello di memorizzazione nella stessa rete VPC dei nodi di rendering 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 server file con cache, i dati rimangono nella cache fino a quando:
- I dati scadranno o rimangono invariati per un determinato periodo di tempo.
- È necessario spazio sul file server, a quel punto i dati vengono rimossi dalla cache in base alla data di creazione.
Questa strategia riduce la quantità di larghezza di banda e la complessità necessarie per eseguire il deployment di molte istanze di rendering in contemporanea.
In alcuni casi, ti consigliamo di preriscaldare la cache per assicurarti che tutti i dati relativi al job siano presenti prima del rendering. Per preriscaldare la cache, leggi il
contenuti di una directory sul tuo file server cloud eseguendo un 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 in loco per comunicare dell'appliance virtuale. Ad esempio, NetApp offre una soluzione di archiviazione che può ridurre ulteriormente la latenza tra lo spazio di archiviazione on-premise e il cloud.
| Vantaggi | Svantaggi | Caso d'uso ideale |
|---|---|---|
| I dati memorizzati nella cache vengono gestiti automaticamente. Riduce i requisiti di larghezza di banda. È possibile eseguire lo scale up o lo scale down dei file system cloud clusterizzati in base ai requisiti del job. |
Potrebbero essere applicati 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 simultanee e leggono 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 particolare tipo di dati. Forse non vorrai mai sincronizzare alcuni tipi di dati, ad esempio i dati temporanei generati come parte di un processo di conversione, memorizza nella cache file o dati di simulazione. Valuta anche se sincronizzare gli asset non approvati, perché non tutte le iterazioni verranno utilizzate il rendering finale.
Esecuzione di un trasferimento collettivo iniziale
Quando implementi la tua farm di rendering ibrida, ti consigliamo di eseguire un trasferimento iniziale di tutto o parte del tuo set di dati in Cloud Storage, su un disco persistente o su un altro spazio di archiviazione basato 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 nel corso di alcuni giorni o settimane. La figura che segue confronta gli orari tipici dei trasferimenti online e fisici.
Se il carico di lavoro di trasferimento supera i vincoli di tempo o di larghezza di banda, Google offre una serie di opzioni di trasferimento per caricare i dati sul cloud, inclusa la Transfer Appliance di Google.
Archiviazione e ripristino di emergenza
Vale la pena notare la differenza tra l'archiviazione dei dati e il recupero di emergenza. La prima è una copia selettiva del lavoro finito, mentre la seconda è un stato dei dati che può essere recuperato. Vuoi progettare un piano di ripristino di emergenza che soddisfi le esigenze della tua struttura e ti fornisca un piano di emergenza esterno. Rivolgiti al tuo fornitore di spazio di archiviazione on-premise per ricevere assistenza in caso di ripristino di emergenza più adatto alla tua specifica piattaforma di archiviazione.
Archiviazione dei dati nel cloud
Al termine di un progetto, è prassi comune salvare il lavoro finito in qualche forma di archiviazione a lungo termine, in genere su supporti magnetici come le LTO. Queste cartucce sono soggette a requisiti ambientali e, nel tempo, possono essere difficili da gestire dal punto di vista logistico. A volte le grandi strutture di produzione ospitano l'intero archivio in una stanza appositamente costruita con un archivista a tempo pieno che tiene traccia dei dati e li recupera quando richiesto.
La ricerca di specifiche risorse, inquadrature o filmati archiviati può richiedere molto tempo, poiché i dati potrebbero essere archiviati su più cartucce, l'indicizzazione in archivio potrebbe mancanti o incompleti oppure potrebbero esserci limitazioni di velocità per la lettura dei dati da nastro magnetico.
La migrazione dell'archivio di dati al cloud non solo elimina la necessità di gestire e archiviare i contenuti multimediali dell'archivio on-premise, ma rende anche 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, utilizzando da diversi servizi cloud per esaminare, classificare, taggare e organizzare gli archivi. Dal cloud è possibile creazione uno strumento di gestione e recupero degli archivi per cercare dati utilizzando come criteri di metadati come data, progetto, formato o risoluzione. Puoi anche utilizzare le API di 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 si trovano nelle classi di archiviazione di Cloud Storage con tariffe di recupero. Utilizza questi proxy all'interno del tuo sistema di gestione delle risorse multimediali in modo che gli utenti possano sfogliare i dati leggendo solo i proxy e non le risorse archiviate.
- Valuta la possibilità di utilizzare il machine learning per categorizzare i contenuti live-action. Utilizza la Cloud Vision per etichettare le texture e le lastre di sfondo oppure API Video Intelligence per agevolare la ricerca e il recupero dei filmati di riferimento.
- Puoi anche utilizzare Immagine AutoML Vertex AI per creare un modello di immagine personalizzato che riconosca qualsiasi asset, che si tratti di live action o il rendering.
- Per i contenuti visualizzati, valuta la possibilità di salvare una copia del disco del worker di rendering insieme all'asset visualizzato. Se devi ricreare la configurazione, avrai a disposizione le versioni software, i plug-in, le librerie OS e le dipendenze corrette se devi eseguire nuovamente il rendering di uno scatto archiviato.
Gestione degli asset e della produzione
Lavorare allo stesso progetto in più strutture può presentare le sfide, in particolare quando i contenuti e le risorse devono essere disponibili nel mondo. La sincronizzazione manuale dei dati su reti private può essere costosa e richiede molte risorse ed è soggetta a limitazioni di larghezza di banda locale.
Se il tuo carico di lavoro richiede dati disponibili a livello globale, potresti essere in grado di utilizzare Cloud Storage che sia accessibile ovunque sia possibile accedere ai servizi Google. Per incorporare Cloud Storage nella pipeline, devi modificarla in modo da comprendere i percorsi degli oggetti, quindi estrarre o inviare i dati ai worker di rendering prima del rendering. Questo metodo fornisce accesso globale ma richiede che la pipeline invii gli asset dove si trovano necessarie in un periodo di tempo ragionevole.
Ad esempio, un artista di texture a Los Angeles può pubblicare file immagine da utilizzare di un artista di luci di Londra. Il processo è il seguente:
- La pipeline di pubblicazione invia i file a 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. File le località vengono interrogate dal database e lette da Cloud Storage al disco locale.
- Il software di gestione code raccoglie un elenco di risorse necessarie automaticamente, esegue una query dal database di asset e li scarica Cloud Storage allo spazio di archiviazione locale di ogni worker di rendering.
Utilizzando Cloud Storage in questo modo, avrai anche a disposizione di tutti i dati pubblicati sul cloud, se scegli di usare Cloud Storage come parte della pipeline di archiviazione.
Gestione dei database
Il software di gestione delle risorse e della produzione si basa su database durevoli e ad alta disponibilità che vengono pubblicati su host in grado di gestire centinaia o migliaia di query al secondo. I database sono generalmente ospitati su un server on-premise sia in esecuzione nello stesso rack dei worker di rendering e sono soggetti alle stesse su alimentazione, rete e climatizzazione.
Potresti prendere in considerazione l'esecuzione dei database di produzione MySQL, NoSQL e PostgreSQL come servizi basati su cloud gestiti. Questi servizi sono ad alta disponibilità e accessibili a livello globale, criptano i dati sia at-rest sia in transito e offrono funzionalità di replica integrate.
Gestione delle code
Programmi software per la gestione delle code disponibili sul mercato come Qube!, Scadenza, e Trattore sono ampiamente utilizzate nel settore degli effetti visivi e dell'animazione. Esistono anche modelli open source le opzioni software disponibili, OpenCue. Puoi utilizzare questo software per eseguire il deployment e gestire qualsiasi carico di lavoro di calcolo su una serie di worker, non solo per i rendering. Puoi eseguire il deployment e gestire la pubblicazione degli asset, le simulazioni di particelle e fluidi, la baking delle texture e il compositing con lo stesso framework di pianificazione utilizzato per gestire i rendering.
Alcune strutture hanno implementato software di pianificazione generici come HTCondor dell'Università del Wisconsin, Slurm di SchedMD o Univa Grid Engine nelle loro pipeline VFX. Software progettato specificatamente per VFX settore, tuttavia, presta particolare attenzione a funzionalità quali:
- Dipendenza basata su job, frame e livello. Alcune attività devono essere completate prima di poter iniziare altri lavori. Ad esempio, esegui un'operazione completamente prima del rendering.
- Priorità dei job, che eseguono il rendering dei wrangler per cambiare l'ordine dei job in base a scadenze e programmi individuali.
- Tipi di risorse, etichette o target che puoi utilizzare per associare risorse specifiche ai job che le richiedono. Ad esempio, esegui il deployment dei rendering con accelerazione GPU solo sulle VM con GPU collegate.
- Acquisisci i dati storici sull'utilizzo delle risorse e rendili disponibili tramite un'API o una dashboard per ulteriori analisi. Ad esempio, guarda di utilizzo medio di CPU e memoria per le ultime iterazioni di un rendering prevedere l'utilizzo delle risorse per la prossima iterazione.
- Job pre e post-volo. Ad esempio, un job di preflight recupera tutti gli asset necessari nel worker di rendering locale prima del rendering. R il job post-flight copia il frame visualizzato risultante in una posizione su un file system e poi contrassegna il frame come completato in un asset completamente gestito di Google.
- Integrazione con applicazioni software 2D e 3D di uso comune come Maya, 3ds Max, Houdini, Cinema 4D o Nuke.
Note di produzione: utilizza un 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 certa supervisione per massimizzare delle risorse eseguendo il maggior numero di rendering che ogni istanza è in grado di gestire, tecnica nota come bin packing. Queste operazioni vengono in genere gestite sia in modo algoritmico sia tramite wrangler di rendering.
Puoi anche automatizzare la creazione, la gestione e il termine delle risorse basate su cloud su base on demand. Questo metodo si basa sul tuo gestore code per l'esecuzione pre e post-rendering script che creano risorse secondo le esigenze, le monitorano durante il rendering e terminarle al termine delle attività.
Considerazioni sul deployment del job
Quando implementi una farm di rendering che utilizza sia ambienti on-premise archiviazione basata su cloud, ecco alcune considerazioni che il gestore code potrebbe tieni presente:
- Le licenze potrebbero variare in base al deployment cloud o on-premise. Alcune licenza si basano sui nodi, altre sono basate sui processi. Assicurati che la coda che esegue 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 da usare solo quando vengono assegnati a tipi di prestazioni specifici.
- Utilizza Cloud Logging per rilevare istanze inutilizzate o inattive.
- Quando avvii job dipendenti, considera dove risiederanno i dati risultanti e dove devono trovarsi per il passaggio successivo.
- Se gli spazi dei nomi dei percorsi sono diversi tra lo spazio di archiviazione on-premise e quello basato su cloud, ti consigliamo di utilizzare percorsi relativi per consentire ai rendering di essere agnostici rispetto alla posizione. In alternativa, a seconda della piattaforma, puoi creare un meccanismo per scambiare i percorsi al momento del rendering.
- Alcuni rendering, simulazioni o post-elaborazione si basano sulla generazione di numeri random, che può variare in base al produttore della CPU. Anche le CPU lo stesso produttore, ma generazioni di chip diverse possono produrre che consentono di analizzare i dati e visualizzare i risultati. In caso di dubbi, utilizza tipi di CPU identici o simili per tutti i frame di un lavoro.
- Se utilizzi un'appliance cache di lettura, valuta la possibilità di eseguire il deployment di un job pre-flight per preriscaldare la cache e assicurarti che tutti gli asset siano disponibili nel cloud prima del deployment delle risorse cloud. Questo approccio riduce al minimo il tempo necessario per forzare i worker di rendering di attendere lo spostamento degli asset nel cloud.
Logging e monitoraggio
La registrazione e il monitoraggio dell'utilizzo delle risorse e delle prestazioni è 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 è visualizzarne l'output della porta seriale. Questa uscita può essere utile quando un'istanza non risponde tramite i piani di controllo dei servizi tipici, come il supervisore di gestione della coda di rendering.
Altri modi per raccogliere e monitorare l'utilizzo delle risorse su Google Cloud include:
- Utilizza Cloud Logging per acquisire i log di utilizzo e di controllo ed esportare i log risultanti in Cloud Storage, BigQuery e altri servizi.
- Utilizza le funzionalità di Cloud Monitoring di installare un agente sulle tue VM per monitorare il sistema metriche.
- Incorpora l'API Cloud Logging negli script della pipeline per generare log direttamente in Cloud Logging utilizzando le librerie client per i linguaggi di scripting più diffusi.
- usa Cloud Monitoring per creare grafici per comprendere l'utilizzo delle risorse.
Configurazione delle istanze di worker di rendering
Affinché il tuo carico di lavoro sia realmente 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 corrispondenti, librerie e software. Potresti anche dover riprodurre i punti di montaggio, e persino ambienti utente sul cloud, perché si trovano locali.
Scelta di un'immagine disco
Puoi scegliere una delle immagini pubbliche o creare la tua immagine personalizzata in base all'immagine del tuo nodo di rendering on-premise. Le immagini pubbliche includono un raccolta di di aste che configurano e gestiscono account utente e attivare l'autenticazione basata su chiave SSH (Secure Shell).
Creazione di un'immagine personalizzata
Se scegli di creare un'immagine personalizzata, dovrai aggiungere altre librerie al sia Linux che Windows affinché funzionino correttamente nell'ambiente Compute Engine.
L'immagine personalizzata deve rispettare le norme di sicurezza best practice. Se utilizzi Linux, installa l'ambiente guest Linux per Compute Engine per accedere alle funzionalità fornite per impostazione predefinita dalle immagini pubbliche. Installando l'ambiente guest, puoi eseguire attività come l'accesso ai metadati, la configurazione del sistema e l'ottimizzazione del sistema operativo per l'utilizzo su Google Cloud, utilizzando gli stessi controlli di sicurezza sull'immagine personalizzata che utilizzi sulle immagini pubbliche.
Note di produzione: gestisci le tue immagini personalizzate in un progetto separato a livello di organizzazione. Questo approccio ti offre un controllo più preciso sulla modalità di creazione o modifica delle immagini e ti consente di applicare versioni, che possono essere utili quando utilizzi software o versioni del sistema operativo diversi 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 una delle tipi di macchine predefinite o specifica tipo di macchina personalizzata. I tipi di macchine personalizzate ti permettono di controllare le risorse 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 di produzione: per le pipeline che implementano un'istanza per frame, valuta la possibilità di personalizzarla in base alle statistiche storiche dei job, come il carico della CPU o l'utilizzo della memoria, per ottimizzare l'utilizzo delle risorse in tutti i frame di un'inquadratura. Ad esempio, puoi scegliere di implementare macchine con un numero di CPU superiore per i frame che contengono sfocature di movimento elevate per contribuire a normalizzare i tempi di rendering in tutti i frame.
Scelta tra VM standard e prerilasciabili
Le VM prerilasciabili (PVM) fanno riferimento alla capacità in eccesso di Compute Engine venduta a un prezzo molto più basso 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 carichi di lavoro di rendering 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 server di licenza o code degli host amministrativi che devono essere eseguiti in modo permanente.
Le VM prerilasciabili vengono terminate automaticamente dopo 24 ore, quindi non utilizzarle per eseguire rendering o simulazioni più lunghi.
Le percentuali di prerilascio vanno dal 5% al 15%, che per i tipici carichi di lavoro di rendering probabilmente tollerabile dato il costo ridotto. Alcuni prerilasciabili best practice può aiutarti a decidere il modo migliore per integrare le VM nella tua pipeline di rendering. Se viene prerilasciata, Compute Engine invia segnale di prerilascio all'istanza, che puoi utilizzare per attivare lo scheduler e terminare il lavoro attuale e ripetere la coda.
| VM standard | VM prerilasciabile |
|---|---|
| Può essere utilizzato per job a lunga esecuzione. Ideale per job ad alta priorità con scadenze rigide. Può essere eseguito a tempo indeterminato, quindi è ideale per l'hosting di server delle licenze o di amministratori di code. |
Viene terminato automaticamente dopo 24 ore. Richiede un sistema di gestione delle code per gestire le istanze prelevate. |
Note di produzione. Alcuni renderer possono eseguire uno snapshot di un rendering in corso a intervalli specificati, quindi se la VM prerilasciata, puoi mettere in pausa e riprendere il rendering senza dover riavviare un frame partendo da zero. Se il tuo renderer supporta gli snapshot e scegli di utilizzare le VM private, attiva gli snapshot di rendering nella pipeline per evitare di perdere il lavoro. Mentre gli snapshot vengono scritti e aggiornati, i dati possono essere scritti in Cloud Storage e, se il worker di rendering viene prelevato, possono essere recuperati quando viene implementato un nuovo PVM. Per evitare costi di archiviazione, elimina i dati dello snapshot per rendering completati.
Concedere l'accesso ai lavoratori di rendering
IAM consente di assegnare l'accesso alle risorse cloud a singoli utenti che richiedono l'accesso. 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 su chi un amministratore.
Controllo dei costi di una farm di rendering ibrida
Quando stimi i costi devi considerare molti fattori, ma ti consigliamo di implementa queste best practice comuni come criteri per la tua farm di rendering ibrida:
- Utilizza le istanze prerilasciabili per impostazione predefinita. A meno che il job di rendering non sia estremamente lungo, con quattro o più ore per frame, o se hai una scadenza obbligatoria per l'invio di un'inquadratura, utilizza le VM prerilasciabili.
- Riduci al minimo il traffico in uscita. Copia solo i dati di cui hai bisogno sugli ambienti on-premise archiviazione. Nella maggior parte dei casi questi dati sono i frame sottoposti a rendering finali, ma Possono anche essere passaggi separati o dati di simulazione. Se stai montando il direttamente su NAS on-premise o con un prodotto di archiviazione che si sincronizza automaticamente, scrive tutti i dati di cui è stato eseguito il rendering al file system locale dei worker, quindi copia ciò che ti serve di nuovo lo spazio di archiviazione per evitare il traffico in uscita da dati temporanei e non necessari.
- Esegui il dimensionamento ottimale delle VM. Assicurati di creare i tuoi worker di rendering con prestazioni l'uso delle risorse, assegnando solo il numero necessario di vCPU, di RAM ed eventuale numero corretto di GPU. Considera inoltre 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 il rendering di frame che richiedono meno di un minuto, valuta la possibilità di raggruppare le attività 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, come EXR di alta qualità o dati di simulazione, valuta la possibilità di utilizzare una workstation basata su cloud più avanti nella pipeline. Ad esempio, un artista su FX potrebbe eseguire una simulazione fluida sul cloud, scrivere file della cache nello spazio di archiviazione basato su cloud. Un artista delle luci potrebbe quindi accedere a questi dati di simulazione da una workstation virtuale in Google Cloud. Per ulteriori informazioni sulle workstation virtuali, contatta il tuo rappresentante Google Cloud.
- Approfitta degli sconti per utilizzo sostenuto e per impegno di utilizzo. Se esegui una un pool di risorse, sconti per utilizzo sostenuto puoi risparmiare fino al 30% sul costo delle istanze eseguite per l'intera durata mese. In alcuni casi possono essere utili anche gli sconti per impegno di utilizzo.
Estendi la tua farm di rendering esistente al cloud è un modo conveniente per usano risorse potenti e a basso costo senza spese in conto capitale. Non è un ambiente di produzione le pipeline sono uguali, quindi nessun documento può riguardare ogni argomento requisito. Per ricevere assistenza in merito alla migrazione dei carichi di lavoro di rendering al cloud, contatta il tuo rappresentante Google Cloud.
Passaggi successivi
- Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Consulta il nostro Cloud Architecture Center.