Questo documento fornisce indicazioni su come estendere il rendering on-premise esistente farm per utilizzare le risorse di computing su Google Cloud. Nel documento si presuppone che tu hanno già implementato una farm di rendering on-premise e hanno familiarità con concetti di base di effetti visivi (VFX) e pipeline di animazione, gestione code software e metodi di licenza comuni per il software.
Panoramica
Il rendering di elementi 2D o 3D per animazione, film, spot pubblicitari o videogiochi è sia ad alta intensità di calcolo che di tempo. 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 ha un utilizzo del 100%, la gestione dei job può diventa una sfida. 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 code può:
- Esegui il deployment di job in risorse on-premise e basate su cloud.
- Gestisci le dipendenze tra job.
- Comunicare con i sistemi di gestione delle risorse.
- 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 ai lavoratori basati su cloud, sono ancora responsabili della connessione al cloud, della sincronizzazione degli asset, scegliendo un framework di archiviazione, gestendo i modelli di immagine e fornendo i tuoi licenze 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 hai già risorse on-premise o cloud, puoi utilizzare un un servizio di rendering basato su cloud SaaS (Software as a Service), come Conduttore.
- 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 Polvere da sparo 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: vengono visualizzate le note sulla produzione periodicamente in questo documento. Queste note offrono best practice per da seguire mentre crei la tua farm di rendering.
Connessione al cloud in corso...
A seconda del carico di lavoro, decidi in che modo si connette la tua struttura tramite Google Cloud, tramite ISP partner, una connessione diretta sulla rete internet pubblica.
Connessione tramite internet
Senza connettività speciale, puoi connetterti alla rete Google e utilizzare le nostre modello di sicurezza end-to-end accedendo ai servizi Google Cloud su internet. Utilità come lo strumento gcloud e gsutil di strumenti a riga di comando e risorse, API Compute Engine usano tutti autenticazione, autorizzazione e crittografia sicure per salvaguardare i tuoi dati.
Cloud VPN
A prescindere dalla connessione utilizzata, ti consigliamo di utilizzare una rete privata virtuale (VPN) per proteggere la tua connessione.
Cloud VPN ti aiuta a connettere in sicurezza la tua rete on-premise al tuo Rete Virtual Private Cloud (VPC) attraverso una connessione VPN IPsec. I dati in transito vengono criptati prima passa attraverso uno o più tunnel VPN.
Scopri come crea una VPN per il tuo progetto.
VPN fornita dal cliente
Anche se puoi configurare il tuo gateway VPN per connetterti direttamente a Google, consiglia di utilizzare Cloud VPN, che offre maggiore flessibilità e migliore integrazione con Google Cloud.
Cloud Interconnect
Google supporta diversi modi per connettere la tua infrastruttura in Google Cloud. Queste connessioni di livello enterprise, dette collettivamente Cloud Interconnect offrono maggiore disponibilità e minore latenza rispetto alle connessioni internet standard, unitamente a 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 si riduce la complessità della rete, i costi di trasferimento dei dati e permette di eseguire farm di rendering multi-cloud ad alta velocità effettiva.
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 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. Per trasmettere dati attraverso Dedicated Interconnect in modo sicuro, devi stabilire la tua connessione VPN. Cloud VPN non compatibile con Dedicated Interconnect, quindi devi fornire privata VPN, in questo caso.
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 determinare il modo migliore e più conveniente per connettersi 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 Gli studi hollywoodiani richiedono ai fornitori di rispettare le best practice sulla sicurezza che sono definiti sia internamente che da organizzazioni come il MPAA. Google Cloud offre modelli di sicurezza Zero Trust integrati in come Google Workspace, Chrome Enterprise Premium e BeyondProd.
Ogni studio ha requisiti diversi per la protezione dei carichi di lavoro di rendering. Puoi di trovare i white paper sulla sicurezza documentazione di conformità alle cloud.google.com/security.
Se hai domande sul processo di controllo della conformità di sicurezza, contatta il tuo Rappresentante Google Cloud.
Organizzazione dei progetti
I progetti sono un componente organizzativo fondamentale di Google Cloud. Nel la tua struttura, puoi organizzare i lavori all'interno del loro progetto o interromperli in più progetti. Ad esempio, potresti voler creare criteri 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 che per il progetto dell'amministrazione pubblica. Tuttavia, puoi condividere le reti tra progetti con VPC condiviso, che fornisce a progetti separati l'accesso a risorse comuni.
Note di produzione: crea un Progetto host VPC condiviso che contiene risorse con tutta la tua produzione tools. Puoi specificare tutti i progetti creati nella tua organizzazione come Progetti di servizio VPC condivisi. 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 un'organizzazione resource, che potresti avere già stabilito. Migrazione tutti i tuoi progetti in un'organizzazione fornisce una serie vantaggi.
Note sulla produzione: designa la produzione i manager come proprietari dei singoli progetti e la gestione dello studio come proprietari della risorsa Organizzazione.
Definizione dell'accesso alle risorse
I progetti richiedono l'accesso sicuro alle risorse e limitazioni relative alla posizione sia consentito operare con utenti o servizi. Per aiutarti a definire l'accesso, Google Cloud offre Identity and Access Management (IAM). che puoi usare per gestire il controllo dell'accesso definendo quali ruoli hanno livelli di accesso alle 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, considera un render worker, ovvero una macchina virtuale (VM) puoi eseguire il deployment da un modello di istanza predefinito che utilizza la tua immagine personalizzata. Il worker di rendering in esecuzione in un account di servizio può leggere 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 necessitano dell'accesso diretto delle tue risorse cloud.
Puoi assegnare ruoli per eseguire il rendering di wrangler o amministratori di progetto che hanno l'accesso a tutte le risorse 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 tipiche attività di produzione ai ruoli IAM in Google Cloud.
| Attività di produzione | Nome ruolo | Tipo di risorsa |
|---|---|---|
| Gestore di Studio | resourcemanager.organizationAdmin |
Organizzazione Progetto |
| Direttore di produzione | owner, editor |
Progetto |
| Esegui il rendering di Wrangler | compute.admin, iam.serviceAccountActor |
Progetto |
| Account di gestione code | compute.admin, iam.serviceAccountActor |
Organizzazione Progetto |
| Artista individuale | [nessun accesso] | Non applicabile |
Ambiti di accesso
Gli ambiti di accesso consentono di controllare le autorizzazioni di un'istanza in esecuzione indipendentemente da chi ha eseguito l'accesso. Puoi specificare gli ambiti quando crei un'istanza o quando il software di gestione code esegue il deployment delle risorse da un modello di istanza.
Gli ambiti hanno la precedenza sulle autorizzazioni IAM di un singolo un account utente o di servizio. Questa precedenza significa che un ambito di accesso può impedire a un amministratore del progetto di accedere a un'istanza per eliminare uno spazio di archiviazione un bucket o modificare un'impostazione del firewall.
Note di produzione: per impostazione predefinita, le istanze possono
legge ma non scrive su Cloud Storage. Se la pipeline di rendering scrive
terminati i rendering in Cloud Storage, aggiungi l'ambito
devstorage.read_write alla tua istanza al momento della creazione.
Scelta della modalità di deployment delle risorse
Con il rendering nel cloud, puoi usare le risorse solo quando necessario, ma puoi scegliere 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 di inviare un job alla farm di rendering. Puoi eseguire il deployment di molte VM da condividere per tutti i frame in un job o perfino creare una VM per frame.
Il sistema di gestione delle code può monitorare le istanze in esecuzione, il che può essere in coda se una VM viene prerilasciata e terminata quando vengono eseguite singole attività completata.
Esegui il deployment di un pool di risorse
Puoi anche scegliere di eseguire il deployment di un gruppo di istanze non correlate a specifiche un job, a cui può accedere il sistema di gestione delle code on-premise Google Cloud. Se utilizzi Google Cloud VM spot, 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 il più semplice strategia da implementare perché imita il modo in cui una farm di rendering on-premise con 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 con un singolo processo. | Basato sull'istanza |
| Basato su nodi | Concesso in licenza a un nodo (istanza) specifico. Un numero arbitrario di utenti oppure processi possono essere eseguiti su un nodo con licenza. | Basato sull'istanza |
| Floating | Effettuato il pagamento da un server di licenze che tiene traccia dell'utilizzo. | Server licenza |
| Licenze software | ||
| Interattiva | Consente all'utente di eseguire software in modo interattivo in un ambiente completamente gestito di Google Cloud. | Basata su server di licenza o basata su istanza |
| Batch | Consente all'utente di eseguire il software solo in un ambiente a riga di comando. | Server licenza |
| Licenze basate su cloud | ||
| Basato su utilizzo | Selezionata solo quando un processo viene eseguito su un'istanza cloud. Quando il processo termina o termina, la licenza viene rilasciata. | Server di licenze basato su cloud |
| Basato sull'uptime | Check-out eseguito mentre un'istanza è attiva e in esecuzione. Se l'istanza viene interrotta o eliminata, la licenza viene rilasciata. | Server di licenze basato su cloud |
Utilizzo delle licenze basate sulle istanze
Alcuni programmi software o plug-in sono concessi in licenza direttamente all'hardware su cui 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 di 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, le viene assegnato uno interno e, facoltativamente, un all'indirizzo IP 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 indirizzo IP interno quando crei un'istanza, questo è utile se vuoi che l'IP interno di un gruppo di istanze devono rientrare nello stesso intervallo.
Chiavette hardware
Il software meno recente potrebbe comunque essere concesso in licenza tramite una chiavetta, una chiave hardware programmati 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 software per capire se può fornirti una licenza aggiornata per il tuo un particolare software.
Se il produttore del software non può fornire una licenza di questo tipo, puoi implementare un hub USB collegato a una rete USB over IP soluzione.
Utilizzo di un server licenze
La maggior parte dei software moderni offre un'opzione di licenza mobile. Questa opzione consente di ha più senso in un ambiente cloud, ma richiede una gestione delle licenze più efficace e controllo dell'accesso 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 consentono ai tuoi worker di rendering di comunicare con gli ambienti on-premise tramite VPN o altre connessioni sicure.
Server di licenze basato su cloud
Nel cloud, puoi eseguire un server di licenze che gestisce le istanze nel tuo progetto o anche 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 di 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 o 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 proveniente 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 per le tue istanze. Le licenze basate su cloud vengono generalmente fatturate in due in base all'utilizzo e all'uptime.
Licenze basate sull'utilizzo
Le licenze basate sull'utilizzo vengono fatturate in base al tempo di utilizzo del software. In genere con questo tipo di licenza, la licenza viene estratta da un server basato su cloud quando il processo viene avviato e viene rilasciato quando il processo vengono completate. Se una licenza viene acquistata, ti viene addebitato l'utilizzo la 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 con consumo vengono fatturate in base al tempo di attività di 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 esaurita. 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
Per evitare del tutto l'implementazione di un file server, incorporando dischi permanenti nel tuo carico di lavoro. I DP sono un tipo di archiviazione a blocchi conforme a POSIX, fino con una dimensione di 64 TB, ben nota alla maggior parte delle strutture 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 DP può essere montato in sola lettura su centinaia o migliaia di Compute Engine. |
Dimensione massima 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 a elevata ridondanza e a elevata durabilità che, a differenza dei file sistemi, non sono strutturati e hanno 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. 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 gsutil o tramite 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 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 degli asset in grado di pubblicare dati in
di archiviazione ideale 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 terze parti canali 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 altre connessioni. Sincronizzazione con cluster NAS on-premise. |
Non c'è modo di sincronizzare selettivamente i file. Nessuna sincronizzazione bidirezionale. | Strutture VFX di medie e grandi dimensioni con centinaia di TB di dati su cui presentare nel cloud. |
| Pixit Media, PixStor | File system con scale out in grado di supportare migliaia di NFS o NFS simultanei client POSIX. 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 di 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 | Montare i bucket Cloud Storage come file system. Costi ridotti. | Non è un file system compatibile con POSIX. Può essere difficile da configurare ottimizzare i risultati. | 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.
Per approfondire le opzioni di archiviazione dei dati
- Opzioni di archiviazione disponibili su Google Cloud
- Archiviazione di file su Compute Engine
- Progetta una strategia di archiviazione ottimale per il tuo carico di lavoro cloud
Implementazione di strategie di archiviazione
Puoi implementare varie strategie di archiviazione nella produzione di effetti visivi o animazioni pipeline mediante convenzioni che determinano la modalità di gestione dei dati, sia che tu acceda ai dati direttamente dall'archiviazione on-premise si sincronizzano tra l'archiviazione on-premise e il cloud.
Strategia 1: montare 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 vicinanze di un region, 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à Google Cloud di almeno 10 Gbps. |
Strategia 2: sincronizzazione on demand
Puoi scegliere push i tuoi dati nel cloud tira da archiviazione on-premise, o viceversa, solo quando sono necessari dati, come quando viene eseguito il rendering di un frame o viene pubblicato un asset. Se usi questa strategia, una sincronizzazione può essere attivata da un meccanismo nella pipeline, ad esempio un da un gestore di eventi come Pub/Sub o da un insieme di comandi come parte di uno script del job.
Puoi eseguire una sincronizzazione utilizzando diversi comandi, ad esempio 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 della parte interessata per conoscere meglio il 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 viene inserito in un file system prima del rendering, dove tutti i lavoratori possono accedervi.
| Vantaggi | Svantaggi | Caso d'uso ideale |
|---|---|---|
| Controllo completo su quali dati sincronizzare e quando. Possibilità di scegliere metodo di trasferimento e protocollo. |
La pipeline di produzione deve essere in grado di gestire eventi per attivare
sincronizzazioni push/pull. Potrebbero essere necessarie risorse aggiuntive per gestire la sincronizzazione in coda. |
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 usare risorse cloud separate per 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 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 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. Tramite un livello di memorizzazione nella cache sullo stesso VPC rete come i nodi di rendering, la latenza di lettura è ridotta, i job di rendering si avviano e vengono completati più velocemente. In base a come hai configurato del file server di memorizzazione nella cache, i dati rimangono nella cache fino a quando:
- I dati scadranno o rimarranno invariati per un determinato periodo di tempo.
- È necessario uno spazio sul file server, nel momento in cui i dati vengono rimossi da della cache in base all'età.
Questa strategia riduce la quantità di larghezza di banda e la complessità necessarie per l’implementazione molte istanze di rendering simultanee.
In alcuni casi, potresti voler preriscaldare la cache per assicurarti che tutte
i dati relativi al lavoro 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
meccanismo di sincronizzazione.
Puoi anche aggiungere un'appliance fisica in loco per comunicare dell'appliance virtuale. Ad esempio, NetApp offre una di archiviazione che possono ridurre ulteriormente la latenza tra l'archiviazione on-premise e 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 del job i tuoi requisiti. |
Può comportare costi aggiuntivi. Le attività pre-job devono essere implementate se scegli di preparare . |
Strutture di grandi dimensioni che eseguono il deployment di molte istanze simultanee e leggono contenuti comuni asset 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, potresti effettui un trasferimento iniziale di tutto o parte del set di dati a Cloud Storage, a un disco permanente e altro spazio di archiviazione basato su cloud. In base a fattori come la quantità e il tipo di dati da trasferire e la velocità della connessione, potresti essere in grado di eseguire la sincronizzazione nell'arco 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 tuoi limiti di tempo o larghezza di banda, Google offre diverse opzioni di trasferimento per trasferire i tuoi dati nel cloud, compresi i servizi Transfer Appliance.
Archiviazione e ripristino di emergenza
Vale la pena notare la differenza tra archiviazione dei dati e disastro e il ripristino di emergenza. Il primo è una copia selettiva del lavoro finito, mentre il secondo è dei dati che possono essere recuperati. 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 di dati nel cloud
Una volta completato un progetto, è pratica comune salvare il lavoro finito di archiviazione a lungo termine, tipicamente su nastro magnetico come LTO. Queste cartucce sono soggette ai requisiti ambientali e, nel tempo, possono da gestire dal punto di vista logistico. A volte grandi impianti di produzione ospitano l'intero archivio in una sala appositamente costruita con un archivista a tempo pieno che tenere traccia dei dati e recuperarli quando richiesto.
La ricerca di specifiche risorse, inquadrature o filmati archiviati può richiedere molto tempo, poiché i dati potrebbero essere memorizzati 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 del tuo archivio dati nel cloud non solo può eliminare la necessità di gestione e archiviazione on-premise dei contenuti multimediali di archivio, ma può anche molto più accessibili e ricercabili rispetto ai metodi tradizionali di archiviazione.
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 Machine Learning per taggare e classificare immagini e video, archiviando porta a un database basato su cloud come BigQuery.
Altri argomenti da considerare:
- Automatizzare la generazione di miniature o proxy per i contenuti che risiedono delle classi di archiviazione di Cloud Storage tariffe di recupero. Utilizza questi proxy all'interno del tuo sistema di gestione degli asset multimediali in modo che gli utenti possono sfogliare i dati mentre leggono solo i proxy, non gli asset archiviati.
- Prendi in considerazione l'utilizzo del machine learning per classificare i contenuti delle live. Utilizza la Cloud Vision per etichettare le texture e le lastre di sfondo oppure API Video Intelligence per facilitare 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 le versioni software, i plug-in, le librerie del sistema operativo e disponibili 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 tra reti private può essere costosa e ed è soggetto a limitazioni della 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. A incorporare Cloud Storage nella tua pipeline, devi modificare per comprendere i percorsi degli oggetti ed eseguire il pull o il push dei dati i worker 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. La procedura è simile alla seguente:
- La pipeline di pubblicazione esegue il push dei file a Cloud Storage e aggiunge un 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 dipende da disponibilità e durabilità nel tempo gestiti 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 valutare di eseguire l'ambiente di produzione MySQL, NoSQL e PostgreSQL come servizi gestiti basati su cloud. Questi servizi sono ad alta disponibilità accessibili a livello globale, criptano i dati at-rest e in transito e offrono e una funzionalità di replica integrata.
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 computing tra diversi worker, non solo per il rendering delle immagini. Puoi eseguire il deployment e gestire gli asset, ad esempio pubblicazione, particella e fluidità di simulazione, la texture di cottura e la compositing con lo stesso framework di pianificazione che utilizzi per gestire i rendering.
Alcune strutture hanno implementato un software di programmazione per uso generico come HTCondor presso la University of 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 livelli. Alcune attività devono essere completato prima di poter iniziare altri job. 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 destinazioni, che puoi utilizzare per trovare corrispondenze con job che le richiedono. Ad esempio, esegui il deployment con accelerazione GPU il rendering viene eseguito solo sulle VM a cui sono collegate GPU.
- Acquisizione di dati storici sull'utilizzo delle risorse e messa a disposizione 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-flight. Ad esempio, un job pre-flight estrae tutti gli asset necessari sul 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 popolari applicazioni software 2D e 3D come Maya, 3ds Max, Houdini, Cinema 4D o Nuke.
Note di produzione: utilizza la gestione delle code per riconoscere un pool di risorse basate su cloud come se erano 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 in genere vengono gestite in modo algoritmico e tramite wrangler di rendering.
Puoi anche automatizzare la creazione, la gestione e la terminazione dei di Google Cloud on demand base. 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 essere diverse tra i deployment nel cloud e quelli on-premise. Alcune sono basate sui nodi, mentre 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 le funzionalità di Cloud Logging per rilevare le istanze inutilizzate o inattive.
- Quando avvii job dipendenti, considera dove verranno collocati i dati risultanti e dove deve trovarsi per il passaggio successivo.
- Se gli spazi dei nomi dei percorsi sono diversi tra quelli on-premise e basati su cloud di archiviazione, valuta l'utilizzo di percorsi relativi per consentire il rendering della posizione agnostico. In alternativa, a seconda della piattaforma, puoi creare una meccanismo di scambio dei percorsi al momento del rendering.
- Alcuni rendering, simulazioni o post-processi si basano su numeri casuali , che può variare da un produttore di CPU all'altro. 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 e delle prestazioni delle risorse è un aspetto essenziale di qualsiasi farm di rendering. Google Cloud offre una serie di API, strumenti e soluzioni per fornire insight sull'utilizzo di risorse e servizi.
Il modo più rapido per monitorare l'attività di una VM è visualizzarne output della porta seriale. Questo output può essere utile quando un'istanza non risponde mediante una come il tuo supervisore della gestione delle code di rendering.
Altri modi per raccogliere e monitorare l'utilizzo delle risorse su Google Cloud include:
- Utilizza le funzionalità di 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.
- Incorporare il API Cloud Logging negli script della pipeline per accedere direttamente a Cloud Logging utilizzando librerie client per i linguaggi di scripting più diffusi.
- usa Cloud Monitoring per creare grafici per comprendere l'utilizzo delle risorse.
Configurazione delle istanze worker di rendering
Affinché il tuo carico di lavoro sia realmente ibrido, i nodi di rendering on-premise devono essere identici 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 oppure creare la tua immagine personalizzata basato sull'immagine del 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 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, configurazione e ottimizzazione del sistema operativo per l'utilizzo su Google Cloud mediante gli stessi controlli di sicurezza per l'immagine personalizzata utilizzati per le immagini pubbliche.
Note di produzione: gestisci le tue immagini personalizzate in un progetto separato a livello di organizzazione. Questo approccio offre un controllo preciso su come vengono create o modificate le immagini e consente versioni, che può essere utile quando si utilizzano diverse versioni di software o sistemi operativi produzioni.
Automatizzare la creazione di immagini e il deployment delle istanze
Puoi usare strumenti come Packer per rendere la creazione di immagini più riproducibile, verificabile, configurabile affidabile. Puoi anche usare uno strumento come Ansible per configurare i nodi di rendering in esecuzione ed esercitare un controllo granulare la configurazione e il 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 creando un'istanza, puoi aggiungere GPU e specificare il numero di CPU, piattaforma, la quantità di RAM e il tipo e le dimensioni dei dischi.
Note sulla produzione: per le pipeline di cui viene eseguito il deployment un'istanza per frame, valuta la possibilità di personalizzare l'istanza in base ai dati storici statistiche come il carico della CPU o l'uso della memoria per ottimizzare l'utilizzo delle risorse in tutti fotogrammi di una ripresa. Ad esempio, potresti scegliere di eseguire il deployment di macchine con Numero di CPU per i frame che contengono un'intensa sfocatura di movimento per contribuire a normalizzare il rendering in tutti i frame.
Scelta tra VM standard e VM prerilasciabili
VM prerilasciabili (PVM) si riferisce all'eccesso di capacità di Compute Engine venduta a un prezzo prezzo più basso rispetto alle VM standard. Compute Engine può terminare o prerilasciare se altre attività richiedono l'accesso a quella 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 i lavori ad alta priorità con scadenze difficili. Può essere eseguito a tempo indeterminato, quindi ideale per i server di licenza o le code l'hosting da parte dell'amministratore. |
Terminata automaticamente dopo 24 ore. Richiede un sistema di gestione delle code per gestire le istanze prerilasciate. |
Note di produzione. Alcuni renderer possono eseguire uno snapshot di un rendering in corso a intervalli specificati, quindi se la VM prerilasciata, puoi mettere in pausa e riprendere il rendering senza dover riavviare un frame partendo da zero. Se il renderer supporta la creazione di snapshot e scegli di utilizzare Le VM PVM abilitano lo snapshot del rendering nella pipeline per evitare di perdere il lavoro. Mentre gli snapshot vengono scritti e aggiornati, i dati possono essere scritti Cloud Storage e, se il worker di rendering viene prerilasciato, viene recuperato quando viene eseguito il deployment di una nuova PVM. Per evitare costi di archiviazione, elimina i dati dello snapshot per rendering completati.
Concessione dell'accesso per eseguire il rendering dei worker
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.
Controllare i 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 istanze prerilasciabili per impostazione predefinita. A meno che il tuo job di rendering non sia per una durata estremamente lunga, quattro o più ore per frame, oppure se si hanno per pubblicare uno scatto, usa 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.
- Dimensioni giuste 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 ricevono e vengono fatturati al secondo con un minimo di un minuto. Se il tuo carico di lavoro include i frame di rendering che richiedono meno di un minuto, considera il per evitare il deployment di un'istanza per meno di un minuto di calcolo.
- Conserva set di dati di grandi dimensioni nel cloud. Se usi la tua farm di rendering generare enormi quantità di dati, come EXR approfonditi o dati di simulazione, prendere in considerazione l'utilizzo di una workstation basata su cloud più in basso 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 può farti risparmiare fino al 30% sul costo delle istanze eseguite per l'intera durata mese. Sconti per impegno di utilizzo può avere senso in alcuni casi.
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. Dai un'occhiata al nostro Centro architetture cloud.